Implementation notes of ERP: Secondary Development

Endless ERP implementation overtime, endless project implementation changes and delays, endless demand research, preparation of demand solutions, demand verification, and repeated handling of bugs caused by secondary development; the implementation process of the ERP project was dragged to death by the endless secondary development. After turning this article out, I would like to tell you that the customer has his own requirements, but for ERP consultants and project managers, not all requirements must be requirements. Please note that the ERP consultant's description of "customer awareness" in the behavioral attitude evaluation criteria: helps or serves the customer's wishes to meet their requirements, focuses on how to discover and meet customer needs (professional and close integration with the company's strategy and business ). Our goal is to meet the customer's requirements, but we need to focus on discovering and meeting the customer's needs through our professional capabilities. This means that the demand is mined and discovered by us, and is often not directly expressed by the customer. This is also why we have many projects that have undergone a lot of secondary development and the customer's satisfaction is not high, because we seem to meet the customer's requirements, but this is not his real demand.

--------------------------------------------------

After the endless implementation of ERP overtime, I finally ushered in a rare half-day rest, watching the movie "Trojan" at home makes me feel deeply-the invincible warrior Achilles' heel injury in ancient Greek mythology has become the fatal "Door of life ", in fact, ERP also has the most feared "destiny", which is a secondary development.

In most cases, secondary development will evolve into an endless modification process for the ERP system. In the end, users and vendors will be dragged into the quagmire and the development and implementation consultants will be broken down, life is worse than death.

Stubborn customers

On my first day as an ERP implementation consultant, my boss told me that the first rule was to be driven by user needs. Then, my boss told me the second principle: as an implementation consultant, I strongly disagree with users for too many secondary development tasks. Too many secondary development tasks will not only increase the instability of the software, it will also extend the implementation project cycle, so as to increase the project cost, to use a variety of ways to put user requirements to the ERP software existing process. These two seemingly conflicting rules make me feel worse during the implementation of a recent ERP project.

As an old state-owned enterprise, users put forward many special requirements on the interface and operations, and stubbornly demand secondary development based on their habits to meet their original operation mode. In general, in order to have a strong versatility, our ERP software products have been relatively standardized in terms of software functions, and the process settings are also relatively standardized. Although the parameters can be partially adjusted to meet the needs of different users, such "mild" flexibility may fail in many cases.

The user's stubbornness or prejudice is mainly manifested in the following aspects:

① Unwilling to change the existing operation habits. Users want to move their current manual processes and jobs to ERP without changing the changes. When I analyze the advantages and disadvantages of the existing ERP process and the existing process, the user will hold me down in one sentence, saying that we have been doing this and doing well, we are developing with such management means and getting the funds from your ERP system. We are still planning to manage them in the way we are used.

In addition to personalized requirements in terms of business processes, users often have personalized requirements arising from the particularity of enterprises that do not involve business processes, such as the format of documents/tables. Generally, ERP provides common document formats, and users have a set of document formats they prefer. Therefore, during the implementation, the Enterprise will ask whether to print in this format. In fact, this is the inverse of the original, as long as there is some content, there is no need to remain unchanged according to the original format.

This problem often occurs in the implementation of my participation. communication with users often makes me effort-consuming, So that I barely persuade the user to agree to try out the document format first. This will not only easily lead to project delays, but also focus on the peripheral processes of unrelated systems. This is often a thankless phenomenon.

The report style and content must be changed only when the parameters cannot be adjusted, or when the report function is not suitable for the user's needs. This kind of secondary development proposed due to operational habits mainly targets the query, printing format and field standardization of various report systems of users.

② Special process requirements caused by unreasonable management systems. Users' secondary development needs are caused by unreasonable management systems and processes. Therefore, the first thing we need to do is to judge the rationality of the requirements, and then go deep into the front-line to find out the real requirements. Countless facts prove that a large number of cases that require secondary development due to unreasonable management process requirements eventually fail.

③ The ERP software does not meet the requirements. Of course, each user does have some personalized business process requirements that ERP cannot meet. After all, ERP is a set of software, rather than customized according to the user. To address this need, even after a variety of implementation methods, there is no better way to handle it, so we have to perform secondary development.

Secondary Development Risks

When users explicitly propose that secondary development is required, problems such as project delays, unstable development programs, and errors may easily occur. Or, after a period of time, they want to modify the program, it was discovered that this was wrong at the beginning, but it may involve the leader interests of all Parties decided at the beginning, so no one dared to change it. As a result, the secondary development program became a chicken fault, no, neither.

① It is relatively simple to modify the report format or user query system without modifying the program code. Because the Software generally has the report generation function, any business personnel can set the report without a lot of computer knowledge, in this case, it is generally easier to solve the problem through full communication between the implementation consultant group and users.

② When the user needs to be personalized and involves modifying the program code, the work is very complicated and the ERP system often needs to provide tools to support secondary development, you may also need to have the source program support of the vendor's software, which is mostly subject to additional costs.

When a user asks for code-level secondary development, the implementation consultant must clearly communicate with the user; otherwise, the user will be more prone to Quagmire, because code-level secondary development may make the ERP system more and more complex, become a "Four is not" of the bloated and complex ERP system.

Generally, code-level secondary development involves three major risks:

① It is easy to cause system instability or crash. The ERP system is a complex system, and each module is an organic whole. To modify a function, it affects not only the current function, but also other functions. At present, the implementation consultant generally has a point of view on ERP code-level secondary development: Do not do it if you can. Because the ERP system is as complicated as the human blood, during the secondary development, if the new user personalized functions touch the original artery of ERP, otherwise the overall performance will be greatly affected, the cost of development and debugging is also very scary.

② Seriously affects the project implementation cycle. Code-level secondary development may take a few days, half a month, or January, or even several months, which may easily delay the project implementation process, this factor should be included when a contract is signed or a project implementation plan is formulated.

③ The risk of subsequent maintenance and upgrade is high. After the software is changed, subsequent software version upgrades will be affected. If you do not upgrade, the advantages of the new version cannot be applied. If it is upgraded, it is possible to re-develop it. This is because the ERP software supplier may not consider secondary development by a specific user on the old version when developing a new version of the ERP system. Therefore, we need to make a careful analysis and comparison before secondary development. Whether to modify the software, reform the current management procedures, or make some changes to both, the necessity, effect, and cost of the changes should be well known.

Reflecting on the gains and losses of secondary ERP development

Either the implementation consultant or the user may have such feelings: the ERP system has been completed with the user's approval after several months of initial discussions and project analysis, as a result, the system became more and more complex due to "Secondary Development", and the expected effect was getting farther and farther. Finally, the system was completely changed. Therefore, it is important to grasp the principle of secondary development.

① In terms of conceptual understanding, the implementation consultant should make users aware that the user's characteristics should not be emphasized too much. The management process in ERP software is extracted from many enterprises, advanced and rational. Many users' special points are caused by unreasonable processes. The ERP implementation should optimize or restructure the business processes of enterprises, rather than simply modifying the software to adapt to unreasonable processes.

② When secondary development is required, implementation consultants and Development Consultants should strictly abide by the basic principle of not Modifying core code. If secondary development is required, the functional modules made by secondary development should be made independent of the original ERP system. In this way, when the ERP system version is updated, the modules developed after the secondary development do not need to be modified or can be applied to the ERP system of the later version with only a few modifications.

③ The requirements for secondary development must be well controlled. do not perform secondary development before the functions of the ERP system are fully understood. Because the user's business process is not static, the process in ERP software is generally abstract, and the big aspect can be embedded with the user's business process, and the details can be modified without modification. At the same time, ERP software is not used by a single user. Every user can have his own ideas and cannot satisfy them. Some must obey the overall situation. The project is implemented on time and on a budget basis. Online operation is the overall situation in the implementation phase. What secondary development is required and what can not be done depends on whether the overall situation will be affected. Do what you can, and never do it.