Week 09

With today’s acceleration in use of technology in every aspect of the human lives it is impossible to subtract the business environment from this phenomenon. As a result organizations and their business processes are getting more dependent on technology every day. Although the use of software systems (services) can be traced since 1960s, but there was an exponential growth in adopting new information systems by organizations (either as the first time or as replacing their legacy systems) during last decade (Elisabeth et al., 2002).

Hence enterprises are trying to gain competitive advantage and ease their business operations by implementing enterprise resource planning (ERP) systems. ERP systems refer to commercially available software packages which their purpose is to integrate organization’s data and processes and enhance seamless information flow within organizational departments. There are different types of ERP systems developed to fulfill organization’s needs (general or specific). For example ERP system implemented by an insurance company is different from the one used by a manufacturing company.

Moreover each ERP system consists of different modules. Each one designed and developed to perform particular tasks, such as financial and accounting information module, human resource information module, supply chain management module, customer information module, etc. So organizations can implement the modules required by their business processes (SAP, 2013).

However not all business processes can be found within ERP software packages. In fact ERP vendors try to include the most common required business processes, best practices and modules in their software packages. But some organizations operate with totally unique business process. This approach has its own advantages and disadvantages because it would give the organization a competitive advantage to its business rivals but it would also make the organization unable to use the best practices and functionalities provided by software suppliers (ERP vendors).

However in case of organizations which their business processes cannot be matched with any of the software packages available in the market the situation becomes sophisticated and risky. As previously mentioned the need for implementing a proper information system is a must in today’s business environment for any company which wants to keep up with its competitors. As the diagram below indicates there are 4 possibilities for implementing an ERP system in a company (Suresh et al., 2009).

 

1. Small-r – refers to the minimal organizational process changes and also minimal software package customization. This will happen when an organization adopts the best practices offered by the vendor.
2. Extensive software customization and minimal process re-engineering – which is similar to the scenario mentioned above. It involves massive modification in the software which can cause problems in the whole system integration and increase the upgrading difficulties. It is also so risky, costly and time consuming. An example of a company which used this approach is Nestle enterprise.
3. Extensive process re-engineering and minimal software customization – this refers to vanilla implementation of the system because there is a low or no modification of the software package.
4. Big-R – consist of extensive software customization and extensive process re-engineering. Hence the organization get the advantage of using the unique functionalities of the system and also sharing some of the risks and costs with the ERP partner (vendor), but it is so resource consuming and also the update/upgrade of the system is difficult to implement, Boeing is an example of the organizations who get benefits from this procedure.

However in case of organizations which don’t tend to change their business processes there are two options which mentioned above. First to develop an information system based on their business needs from the ground, which is so costly and time consuming and it’s more applicable to large organizations. The second option is that although they cannot adopt the whole ERP system, instead they can try to get the most out of the different modules available in the system. For example in case of a company consist of financial department, manufacturing and delivery department and human resource department it t is possible that the organization is unable to find the required capabilities in the software packages offer by ERP vendors for its manufacturing operations, but they can use the system for their financial and human resource departments and try to adapt the manufacturing module to the organization’s business strategies. But this will lead to a massive customization which mentioned in number 2 of the above diagram and is not recommended by ERP professionals.

 References

ELISABETH, J. U., RONALD, R. H. & UMBLE, M. M. 2002. Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research, 146, 241-257.

SAP. 2013. SAP ERP Features & Functions [Online]. SAP Solutions. Available: http://www.sap.com/solutions/business-suite/erp/featuresfunctions/index.epx 2013].

SURESH, S., MOHAMED, T. & KRISHNANKUTTY, K. V. 2009. The role of BPR in the implementation of ERP systems. Business Process Management Journal, 15, 653-668.

Week 08

ERP Project Manager Skills and Attributes

Implementing an enterprise resource planning (ERP) system like developing any other software product requires several steps to be followed in a defined methodology. As a result after all the requirement gathering, consultation with experts, vendor selection, etc. the final phase is implementing the actual system. The role of a project manager gets apparent in this stage. It is such an important task that for large system implementation there is a need for a project management team (Cerpa and Verner, 2009).

Skills required by a successful project manager can be divided into three categories (El-Sabaa, 1999):

Human Skills:

this can be referred to the project manager’s ability to communicate with other people in the project (human interaction), no matter their level or position; from top-management (executives) to operational level. It is very important for a project manager to communicate with people in their own context. These skills also mainly imply the way a project manager perceives people around him and behave according to their attitudes

A project manager with strong human skills can help organization to get more benefit        from flatten structure and enhanced communication among staff involved in a development project. Project manager would also use these skills to select/hire the proper personnel required by any task. Leadership quality is also an advantage as human skills for a project manager which can be used to motivate or inspire individuals or teams to boost their productivity.

Conceptual Skills

First of all a good project manager should be an experienced and talented business manager (Ara and Al-Mudimigh, 2011). It means he/she should be familiar with all the business aspects of the organization. Some authors define another group of skills required by a project manager called organizational skills which are interrelated with the conceptual skills (El-Sabaa, 1999). This group covers most of the critical attributes that a good project manager should offer, such as:

• Able to cope with crisis, uncertainty and suspense during the project life cycle (problem solving/decision making in critical moments)
• Having the ability to observe/evaluate the project as a whole and understand  how different functions/modules of the project depend on each other and what would be the effect of change in any of them on the others
• Clearly define the objective and goal of the project (ERP system)
• Being responsible for developing an effective plan in order to achieving the defined goals
• Proper resource management
  • accurately estimates budget and time
  • clearly define the milestones (scheduling)
  • efficiently allocate required skilled staff to different modules of the project
• Being able to plan and lead a proper change management procedure in order to cope with any unexpected issue arise after system implementation
• Identify changes in role of each department after implementation of the ERP system
• Proper evaluation of the risks associated with the project (Risk management)

Technological Skills

Apart from business and managerial skills a successful project manager requires having the proper knowledge about the technical aspect of the project as well. In fact generally project managers are assumed as the interface between the technical side and management side in an organization.

For developing/implementing any IT project it is crucial to assign the suitable project manager to it. They should have extensive knowledge and experience about the required technologies by the project. In the case of ERP system implementation the selected project manager should be an ERP professional. They should be aware of all the modules and functionalists offered by the system; moreover being able to use the available tools and techniques beside their knowledge/other skills to match (align) the system modules with business processes of the organization.

References:

ARA, A. & AL-MUDIMIGH, A. S. 2011. The Role and Impact of Project Management in ERP project implementation life cycle. Global Journal of Computer Science and Technology, 11.

CERPA, N. & VERNER, J. M. 2009. Why Did Your Project Fail? Communications of the ACM, 52, 130-134.

EL-SABAA, S. 1999. The skills and career path of an effective project manager. International Journal of Project Management, 19, 1-7.

Week 06

Legacy system

Legacy systems refer to the old and out dated computer systems or application programs which continue to be used by an organization to fulfill its requirement. The actual reason for existence of the legacy systems is due to cost of replacing them (Sudhakar and Sakthivel, 2012). Because replacing an old legacy system with new information system in large organizations could also require some changes in the organization’s infrastructure which can cost the organization a fortune. The other issue is that organizations are afraid if the new system not being capable of perform organizational business operations better or like it used to be. However during the time legacy software used by an organization they would undergo frequent updates and changes but because of their poor capabilities and competitiveness to the up-to-date systems they required to be replaced.

Fictional case – Stuff-up.org

Stuff-up.org (our factious organization) decided to hand-out the task of evaluating, selecting and implementing its new ERP system to its IT department. There is no argument about the importance of the IT department involvement during the system implementation, but selecting and evaluating a new ERP system in order to replace the legacy systems in an organization requires extensive managerial skills. Unfortunately most of IT people working in a company lack such skills.

As (Kimberling, 2012) states it should be clearly defined in the first place that the ERP system implementation is not an IT initiative. It means that if an organization expects all the phases involve in implementing a new system getting done by its IT department (from requirement gathering, vendor evaluation, software selection, system implementation, staff training, etc.) they should also expect high probability of failure. Although the system can be implemented and gets operational, but probably it won’t be able to deliver the expected functionalists required by the organization’s business processes. This situation can be considered as a failure for a system.

As previously mentioned IT department plays a very important role in any ERP system implementation, because they handle all the tasks related to the technical side of the project such as system configuration, required customization, etc. (Tsai et al., 2012). But any organization can divided into different hierarchy levels according to the role/position of its personnel, from executive board (top-management) to the operational level (functional).

There is a fact that IT staff are not business professionals and most of them lack the essential skills require to drive an ERP project from its initiation. They don’t have the business and managerial vision like a Chief operating officer (COO) or a project manager (PM). In fact their perspective is technological and they evaluate the project only from the technical view. They don’t even tend to have the authority to make critical decisions which affect the organization’s operation. Yet unfortunately often in some organizations IT departments have given critical tasks such as choosing, implementing and adopting an entirely new approach to doing business.

In implementing an ERP system IT department should be involved like all other departments in the company. Here is a summary of their critical duties (Kimberling, 2012):

• Consulting with executives and middle-management to determine the gap exist between legacy system and company’s business processes. (determine the need of implementing a new ERP system)
• consult with executive board and give them advice about the nominated software packages on the table (final selection decision will be made by top-management)
• Participating in the ERP software selection by evaluating and reviewing the business processes and functionalists include in the system
• Evaluate the “to-be” business processes and identify any need of customization
• Implement the new ERP system consist of different modules and assist the organization to migrate from its legacy system to the new integrated ERP system
• provide technical solutions to align the organization’s required functionalists and system capabilities
• provide proper education and training to the staff about the technical aspects of the system

 References:

KIMBERLING, E. 2012. ‘The Real Role of the IT Department in an ERP Implementation’ [Online]. Panorama Consulting Solution. Available: http://panorama-consulting.com/the-real-role-of-the-it-department-in-an-erp-implementation/ 2013].

SUDHAKAR, P. & SAKTHIVEL, P. 2012. ‘Reengineering Legacy to Modern System with One Time Checker for Information System Evolution’. American Journal of Applied Sciences, 9, 832-841.

TSAI, W.-H., LEE, P.-L., SHEN, Y.-S. & LIN, H.-L. 2012. ‘A Comprehensive Study of the Relationship Between Enterprise Resource Planning Selection Criteria and Enterprise Resource Planning System Success’. Information & Management, 49, 36-46.

Week 05

Why many experienced ERP implementers recommend the organizations to not customize their ERP systems?

As discussed in the week three blog entry, companies have two choices when coming to implementing an ERP system, ERP system customization or organizational adoption (business process reengineering) (Zach and Munkvold, 2012). As a matter of fact there is a strong debate among ERP experts about organizations to avoid customizing their ERP packages, they believe that organizations should undertake business process reengineering (BPR) to adopt an ERP and not modifying the software packages (Sharma et al., 2012). They list some of customization disadvantages as:

• Update/upgrade the customized system is difficult and cost the company time and money
• Customizing an ERP system requires coding, so it seeks skilled programmer/developer
• Manipulating/modifying the original code can cause disturbance in the system functionality/operation
• Customization can use the vital resources of the company which may be required in the other sections

But we should bear in mind that any organization adopting an ERP system may need to do some customization, because it’s quite impossible to implement pure vanilla ERP system and get the desired functionalities from all the modules, In a report done by Panaroma Consulting (Sharma et al., 2012) they claim that only 23% of companies implementing ERP systems using vanilla ERP packages with no or few customization, so the level of modification is different; in fact vendors cannot develop a system which covers all the business processes and fulfills the needs of all companies.

So organizations should try to avoid crossing the system boundaries set by the vendor (which leads to high customization)

Although many researches indicate that highly customization can be a main factor of system failure, some authors believe the opposite way. As Liang and Xue (2004) argue that the ERP system should be customizable in different levels with minimal need of BPR (Zach and Munkvold, 2012).

What are the risks of the ERP system customization?

Here is the summary of ERP customization risks (BABIC, 2009):

• Go-Live – customization is a time consuming process, so it can delay the Go-Live stage of the system and the more it takes, the less the organization gets benefit of ERP.
• Official support (Help) – Usually vendors are responsible for the standard package they offer, so extensive amount of customization can terminate the support of the vendor.
• Upgrade – Normally ERP development lifecycle is 2-3 years, whereas ERP implementation lifecycle can takes between 5-10 years, so upgrading in the middle of implementation phase for highly customized systems would be a big problem.
• Regression – An ERP package consists of different business processes and functionalities, so customizing module A of the package can cause incorrect functionality from module B, so the greater the customization the higher the risk of malfunction in other modules.
• Know-how – There is always people with the knowledge of the standard ERP systems to hire
• Vendor lock-in – One of the advantages of a standard ERP system is that the organizations are able to switch between their partners easily

What does a need to customize say about the willingness of an organization to affect BPR?

For some organizations the unique business process is their competitive advantage to the others, so it is quite impossible for them to adopt their business process to the ERP system (BPR) (Sharma et al., 2012). This is mostly common among small or medium size companies which majority of them only implements some modules/elements of the ERP system in order to facilitate their business operation. So they prefer to take the risk and customize the ERP system. In fact the research done by (Zach and Munkvold, 2012) shows that openness of the ERP system in order to implementing it is one of the key selection criteria.

There are also other reasons for organizations to customize their ERP packages that we can divide them in two stages (Zach and Munkvold, 2012, Rothenberger and Srite, 2009):

1-      Prior to Going-Live

1. Resistance to change
2. Unique business process
3. Specific organization structure
4. Functional misfit
5. Ownership type (mostly applicable for small/medium size companies which owner is the CEO)
6. Motivation of the ERP implementation (Technical Vs. Strategic)

2-      After Going Live (post ERP implementation)

1. Stage of growth – business is dynamic and companies are growing, so more functionalities needed by time
2. Maturity of the ERP system – mostly applicable to local vendors

Other authors (Rothenberger and Srite, 2009) also include some other elements in the list such as shortage of IT competence, or lack of knowledge and experience with the ERP system, but these problems influence the customization indirectly, because they can be avoided with the help of consultants working along with the system implementation team.

References:

BABIC, V. 2009. Top 7 reasons why to avoid (much) customization [Online]. navigate Into Success. Available: http://navigateintosuccess.com/blog/top-7-reasons-why-to-avoid-much-customization.

ROTHENBERGER, M. A. & SRITE, M. 2009. An Investigation of Customization in ERP System Implementations. IEEE Transactions on Engineering Management, 56, 663-676.

SHARMA, R. R. K., PATIL, S. M. & TANDON, A. 2012. CUSTOMIZATION AND BEST PRACTICES MODEL FOR ADOPTING ERP SYSTEM: AN ANALYSIS. International Journal of Business Strategy, 12, 1-9.

ZACH, O. & MUNKVOLD, B. E. 2012. Identifying reasons for ERP system customization in SMEs: a multiple case study. Journal of Enterprise Information Management, 25, 462-478.

Week 04

What are the implications of maintenance/upgrade for organizations adopting an ERP system?

During last decade there was a dramatic growth in the number of organizations implementing ERP systems within the industry, with aim of data integration and enhancement of information flow among their departments through a unique and centralized system (Sharma et al., 2012). Implementing such complex systems are risky and come with cost for companies. There are two stages in the life cycle of an ERP system implementation, before “Go-Live” stage and after “Go-Live” which sometimes refers to post-implementation stage (Zach and Munkvold, 2012). In fact ERP projects are never finished.

Researches show that system maintenance annually cost the organizations near 25% of the total original implementation budget (Jose and Cristina, 2010). So it is a costly operation and will start from the moment system is going live until retire from operation in organization. Although not all the maintenance/upgrade operations are successful. Sometimes they can overrun time and budget constraints, or unable to satisfy the user expectations, even they can cause damages to the overall system performance. So if maintenance/upgrade of a running system does not fit, it may cause the system to become useless.

As we know ERP system is a standard software package adjusted to do specific tasks to fulfill an organization needs. But maintaining and upgrading such a system is different from normal software, because of the size, scope and the organization impact that it has.

Unfortunately there is no certain structured methodology for following as a guarantee to successfully doing the ERP maintenance. But one of the key factors is that the organizations business processes and their ERP system should be aligned to get best results from maintenance operation (Jose and Cristina, 2010).

Do you think the text captured the complexity of this?

No, I believe the text book did not debate/explain the scope of the complexity for maintaining process. But here we can discuss the main reasons involved in maintenance stage and categorized them as follows (Jose and Cristina, 2010):

1-      Rapid changes in the business environment

Business is dynamic and organizations are growing in size and scope of services/activities; they should be able to keep up with these changes in order to remain in competition. So although an ERP system can serve an organization well for a while, it needs maintenance and upgrade in order to be able to satisfy user needs and perform all the functionalities desired

2-      User support

By undergoing maintenance the organizations give vendors/developers the chance of implementing the system to enhance its functionality and improve any malfunctions detected by users during system usage (obviously not all the errors/malfunctions can be detected before Go-Live stage)

3-      Usual software update/maintenance

As mentioned before ERP system is a software package, but in larger scale and specific functionalities, so like any other software it needs modification/improvement. Some updates are general for systems like usual security updates, but some updates are developed for a specific task and modifying a specific module of a system.

There are also risks associated with upgrading an ERP system, specially customized ones. Because usually vendors offer a standard package are responsible for the systems they provide and implement for the organization, so if there are so much customization to that system vendor can terminate the support for that. This can cost more and cause problems for the company because they need to do in-house coding/development which is risky, time consuming and costly.

References:

JOSE, L. S. & CRISTINA, L. 2010. A multicriteria approach for risks assessment in ERP maintenance. The Journal of Systems & Software, 83, 1941-1953.

SHARMA, R. R. K., PATIL, S. M. & TANDON, A. 2012. CUSTOMIZATION AND BEST PRACTICES MODEL FOR ADOPTING ERP SYSTEM: AN ANALYSIS. International Journal of Business Strategy, 12, 1-9.

ZACH, O. & MUNKVOLD, B. E. 2012. Identifying reasons for ERP system customization in SMEs: a multiple case study. Journal of Enterprise Information Management, 25, 462-478.

Week 03

Intro – Best practice

Best practice is a technique or a well-defined methodology which has been proven in research and experience (theory and empirical) (Rouse, 2007).

Implementing best practices in business operations is one of the main benefits of an ERP system for organization; General goal of best practice is to reduce any chance of failure during ERP implementation process, in fact success of an ERP system depends on how effectively an organization can use best practices. ERP vendors offer their successful experiences as best practices to the organizations to use them for effective and efficient implementation.

1-    If an organization is unwilling to change its business processes, can it gain any value from an ERP? How could this be achieved?

The main reason of implementing an ERP system is to improve and maintain the information flow between different departments of the organization, and in order to implementing it successfully organizations face two choices (Zach and Munkvold, 2012):

• Organizational adaption – Adapt their business processes to the ERP best practices provided by the vendor (business process reengineering)

• ERP Customization – Configure the ERP system to meet their desired functionality

Many authors in their researches debate the fact that low ERP system customization is the key success element in an ERP implementation project (Zach and Munkvold, 2012).

But here the situation is the second option; it means the company is unwilling to change its business process, so it has to do some customization and modifications in the ERP system at some level depends on its needs in order to get the most out of the system. Here are few reasons why organization may do so (Sharma et al., 2012) such as:

• Required functionalities are not provided by the vendor in the package
• To improve the efficiency
• To implement the business process (best practice) required by the organization in the ERP system
• Lack of power in the implementation team to avoid customization
• To improve the acceptance level of the new system among users
• To simplify and facilitate the transition
• Cost reduction by decreasing the number of staff in the organization

So the organizations which believe the vendor best practices cannot full fill their needs and they require to adapt the system to their business process can do this via implementing only some parts/modules of the ERP system; by this the organization prevent the implementation of the unnecessary modules with keeping the original structure of the ERP system, or they can modify the code in order to align the ERP functionalities with their business process. This method can be done in three different ways (Rothenberger and Srite, 2009):

I.           By choosing suitable system components and modify them within the boundaries allowed by the developers

II.         Implementing third-party software (bolt-on) which is developed to work with the ERP system and supplement its functionality.

III.       Developing custom features on top of the ERP platform/code using standard programming languages

2-    What are the risks?

“ERP customization is problematic and may increase the cost and limit maintainability” (Zach and Munkvold, 2012)

There are two kinds of motivation for organizations in order to implementing an ERP system, technical and strategic (Zach and Munkvold, 2012). Some organizations only want to replace their old unsatisfactory legacy systems with a modern integrated one but without changing their business processes (technical motivation), this is quite common among small or medium size companies.

There are certain risks associated with that (adapting ERP to the business process) such as:

• Problem with maintenance/upgrade for the to the current and future system needs
• High risk of failure because of adopting unproven methodology/technique (not using proven ERP best practices)
• Unable to get the desired/expected functionality from the system
• Cross the time/budget limits

References:

ROTHENBERGER, M. A. & SRITE, M. 2009. An Investigation of Customization in ERP System Implementations. IEEE Transactions on Engineering Management, 56, 663-676.

ROUSE, M. 2007. Best Practice [Online]. TechTarget. Available: http://searchsoftwarequality.techtarget.com/definition/best-practice 2012].

SHARMA, R. R. K., PATIL, S. M. & TANDON, A. 2012. CUSTOMIZATION AND BEST PRACTICES MODEL FOR ADOPTING ERP SYSTEM: AN ANALYSIS. International Journal of Business Strategy, 12, 1-9.

ZACH, O. & MUNKVOLD, B. E. 2012. Identifying reasons for ERP system customization in SMEs: a multiple case study. Journal of Enterprise Information Management, 25, 462-478.

Week 02

Shadow Systems

What are the possible causes for existence of shadow systems?

First we need a clear definition of shadow systems which is: “Shadow systems are systems which replicate in full or in part data and/or functionality of the legitimate systems (the ES) of the organization” (Jones et al., 2004, Behrens, 2009)

The shadow systems generally did not designed or meant to be created, but they develop by accident. The business user needs to get the information from the system to produce results which they are looking for. So they get the initial data from the ERP system or data warehouse (DW), but because it’s not complete and does not fulfill their needs they add some outsource data to that and put them in a spreadsheet or database and with some manipulation on them getting the results desired (Sherman, 2004).

In fact one of the main reasons is the scope of the businesses today, which makes it difficult and time consuming for many of enterprises to develop an ERP or data warehouse with standard ETL and BI (business intelligence) tools, otherwise any user prefers to get more complete and higher quality data from the ERP system, but eventually they only want (and care) to make their works done.

What is the threat of shadow systems on data integration?

Shadow systems can be divided into 3 different types which each of them can cause problems for data integrity in the enterprises:

• Quasi-Shadow – which is not considered as a true shadow system, but it includes downloaded information from ERP into an outsource database or spreadsheet that get manipulated, printed and then deleted after use.
• Real Shadow Systems – which same as Quasi shadow systems included downloading data from ERP into a database or spreadsheet and manipulating it, but with adding additional information to that and using them in business processes. Here shadow system can cause the problem because the data can be retained and become out of sync with the ERP data, which also causes decrease in the system accuracy.
• Auxiliary Shadow Systems – this type of shadow systems is a complete application system (mostly third-party) which can interface with the ERP system through extracted or common data and indexes which are not part of the ERP itself.

So by using the shadow systems in business processes users feeding them and make them bigger and more complex, that also means increase the gap between the ERP and the shadow system data which will affect the data integrity and can cause catastrophic consequences for the enterprise businesses.

Who/What will affected by shadow systems?

Shadow systems can affect the business process and being a thread to the organization as a whole, so by eliminating them the enterprises can benefit in many ways such as (Jones et al., 2004):

• Cost reduction
• Growth increase
• Business process improvement
• Heightened productivity
• Increase agility of the organization as a whole

Bear in mind that it can also help the business users to increase their productivity by focusing on their work rather than caring about how to get the data and from where.

 

References:

BEHRENS, S. 2009. Shadow Systems: The Good, The Bad and The Ugly. Communications of the ACM, 52, 124-129.

JONES, D., BEHRENS, S., JAMIESON, B. J. & TANSLEY, E. E. 2004. The rise and fall of a shadow system [electronic resource] : lessons for enterprise system implementation / David Jones, Sandy Behrens, Kieren Jamieson [and] Elizabeth Tansley, Hobart, Tas. : University of Tasmania, 2004.

SHERMAN, R. 2004. Shedding Light on Data Shadow Systems [Online]. Ahena IT Solutions. Available: http://www.athena-solutions.com/bi-brief/may04-issue12.html 2012].