Key Points of Day 3 Articles

Configuring an ERP System: Introducing Best Practices of Hampering Flexibility?
Similar to the lessons learned from the class discussions and other articles, implementation of ERP will not help unless you have a certain strategy with well-defined business processes, plans, and discipline. In this case, benefiting from each flexibility capability of the system makes things more complex and does not lead to anywhere. Rather, flexibility capabilities of the systems should be utilized in line with the organization’s business units’ strategies, plans, and rules.
Also, having employees in each business unit ready for implementation by believing that there is need for it is crucial in the success of the implementation project. In this case, design and implementation of the order management module became too difficult since marketing people – the key personnel knowing the flow well – were not enthusiastic and motivated for implementation. They did not believe in the benefits of ERP to their business and therefore were not helpful to the project team.
We have discussed the importance of having people knowing the flows well in the implementation project teams. It has been pointed out that from each key business unit related with each module to be implemented, people who know the work flows, processes, and the general practices well should be involved. This issue’s importance is also seen in this PSDC case. Order management is well known by marketing and sales people since they do the daily practices, but for reasons I have mentioned above, they do not get involved in the implementation preparation work. Rather, a manager in finance gets responsibility for this. However, the work gets stuck after a point since nobody in the team really knows the marketing-ordering-pricing procedures. So, it is understood that for every implementation case, people form the related departments should be involved.

A Framework for Evaluating ERP Implementation Choices:
Different from our class discussions, in describing ERP, the risks involved with its implementation, its benefits and the reasons for failure; the article points out that there is a gap between the producers of the system and the implementers. Sales staff of the ERP vendor and third party consultants physically contact with the organization (the implementer) rather than the system writers.
As another issue, it is pointed out that ERP is a package solution and it is designed for serving as many customers as it is possible. So, it is not a tool that is designed for individual organizations; rather, it is an industry best-practice application. Also, the article points out some researchers thinking that the systems are actually not universal indeed.

Customization:
The success of the implementation relies upon the fit between business processes and ERP systems. There is a positive correlation between the success and the fit. Accomplishing this fit is the main goal of customization.
Customization is defined in two parts: technical customization (adapting the system to the current business processes) & process customization (vice versa).

Technical Customization: There are three types: (1) module selection, (2) table configuration, and (3) code modification. Module selection consists of the least level of customization; there is no altering of the system but it is usually not sufficient for the needs of the organizations. Table configuration contains risk and necessitates a well understanding of the configurable options within the system. Code customization is the extreme of customization where the codes are re-written for some processes. While it provides the greatest flexibility to the organizations, it involves the highest risk among the technical customization options.

Process Customization: The categories are: (1) no change, (2) incremental change, and (3) radical change. If the company does not prefer to change the relationships among tasks and configurations of resources, then it goes with the no-change option. If improvements are decided to be made between the relationships among tasks and configurations of resources, it is the incremental change category. Or, the company may go with an extreme change of its processes; radical change. (Table 2 in the article).
For customization, it is clear that organizations must have some capabilities. These are classified under two headings in the article: Technical change capability & Process change capability; each related with technical customization and process customization, respectively.

Technical Change Capability: It is the overall capability for technical customization of the ERP systems. It includes understanding ERP configurations, options, the ability to develop large-scale software in every aspect, and the ability to manage this system with enough resources.

Process Change Capability: The capability to customize the organization’s business processes consists of having a ‘change’ capability on the enterprise scale with a design capability and creative thinking. As in the technical change capability case, it also necessitates managerial abilities for organizational change and project management.

Table 3 summarizes well that how the overall capability for customization is evaluated by the article.
These capabilities are not static; they can be improved in time by learning from experiences.
The Public University (PU) case shows that different levels of customizations according to the related capabilities of the organization may be applied for each module of the system. There is not only one way to customize general for the whole modules of the ERP system to be implemented since ERP implementation is actually not a single individual project. Rather, it is a portfolio of projects.
In conclusion, before implementation, the organizations should: (1) identify the fit between its own business processes and the selected ERP system, and (2) evaluate its own ability to manage these changes.