Is all the secondary development of standard software done merely to satisfy the self-righteous whims of Party A enterprises?

"The secondary development of standard software is all made to cater to the self-righteousness of client enterprises." Recently, this remark from a project manager of a software company in a group chat instantly sparked heated discussions. The topic is sharp, but it is also a common fact that often leads to endless wrangles. In this process, software companies believe that enterprises ignore standards and change requirements randomly, while enterprises think software companies are disconnected from real business and force the so-called processes and standards of large factories. Eventually, the secondary development of software becomes the "solution" of mutual compromise for the conflicts between the two sides.

In Lao Yang's view, the secondary development of software itself is not a problem. The real problem lies in the lack of consensus and governance behind the secondary development. What is the root cause of the "self-righteousness"? In fact, both the client and the service provider are responsible, which stems from the "arrogance" of both sides, and eventually leads to mutual prejudice.

1. The "Self-Righteousness" of Software Companies: Standardization Does Not Equal Universal Correctness

A good set of standard software usually precipitates industry best practices, compliance requirements and mature processes, which can help enterprises avoid detours and reduce implementation and maintenance costs. In fact, there is commercial rationality for software vendors to adhere to standards: the more secondary development is carried out, the more complex the functions will be, the higher the delivery cost will be, the more difficult the subsequent upgrade will be, and the less replicable the product will be.

However, the problem is that many developers and implementation consultants directly equate the "standard process in the system" with the "correct process in business". They design functions in the office, have never been to workshops, warehouses or stores, and have never followed front-line business personnel to complete a full set of operations, but are convinced that "large factories all do this, so you should do the same". This "large factory mindset" leads to the following three typical misunderstandings.

First, ignore the differences in enterprise scale and resources.

The best practices of large factories are built on organizations with high standardization, strong execution and high digital literacy. If a manufacturing enterprise with hundreds of employees mechanically copies the processes of Huawei and Alibaba, it is likely to result in "three-level approval becoming a mere formality" and "one procurement requiring five rounds of approval". The process seems to be standardized, but the actual efficiency declines in the end.

Second, take "the system can run normally" as "the business can run normally".

The launch of the system only means that data can flow, not that front-line employees are willing to use it and can use it smoothly. The standard ERP requires scanning codes to record the start, reporting and completion of each work order. However, workshop workers have hands full of oil stains and the production line has a tight rhythm, so the standard interface may not be practical at all. If a software developer does not understand these scenarios, he is likely to attribute the front-line resistance to "you don't know how to use it". Therefore, when Lao Yang was managing the internal technology company back then, he often brought programmers to the front line of production to experience the site in person, so as to design and develop an empathetic system with "soul".

Third, use technical correctness to cover up the lack of management reform.

In the process of project implementation, we often hear software companies say "you need to adapt to the system, instead of the system adapting to you". This statement is valid in some cases, but if the enterprise does not have supporting training, system adjustment and performance mechanism, unilaterally requiring employees to adapt to the system is, in the final analysis, a kind of laziness in management.

2. The "Self-Righteousness" of Business Departments: Flexibility Does Not Equal Reasonableness, Nor Is It All Unreasonable

In the process of digital project construction, software companies often encounter such scenarios: obviously, the business departments of the enterprise have vague requirements and arbitrary management, with one idea today and one requirement tomorrow. The standard functions can obviously meet 80% of the needs, but they require major modifications for the remaining 20% of special scenarios, otherwise they will say "the software is not easy to use". This leads to a large number of inefficient secondary development of software, and even project out of control. Why does this happen? Lao Yang has analyzed it many times in previous articles, and here is a brief summary:

First, the business itself is complex and unstructured.

For the management of some traditional enterprises, the process and management are naturally highly uncertain. For example, a sales discount policy may be based on customer level today, project profit tomorrow, and payment collection cycle the day after tomorrow. The business department can't explain the rules clearly not because they are stupid, but because the business itself is difficult to be standardized.

Second, lack of management consensus and conflicting requirements.

The sales department wants flexibility, the finance department wants control, the production department wants stability, and the boss wants transparency. These demands are naturally conflicting, and the standard software is definitely difficult to meet them. What to do? Eventually all of them are turned into secondary development requirements for the software.

Third, departmental interests and habitual resistance.

Digitalization often means transparent processes and rearrangement of power. Some departments are unwilling to have the original gray space and discretionary power solidified by the system, so they use "the software is not easy to use" to resist the reform. How to solve this problem? The secondary development of software takes all the blame. It should be noted that this kind of "not easy to use" is an organizational political problem, not a technical problem.

Fourth, lack of requirements abstraction and translation capabilities.

Front-line personnel are familiar with business, but are not good at abstracting business into system rules. They can only say "I want to be as flexible as Excel", but can't explain clearly what rules, exceptions and approvals the "flexibility" specifically refers to. At this time, if the implementation party has no intention to guide, the two sides will fall into mutual accusations, and eventually think that the other side is "self-righteous".

From the above, it is not difficult to see that the arbitrary flexibility of the business department will indeed disrupt the project, but there are not only unreasonable habits, but also real business complexity and reasonable personalized demands. If software companies regard all their complaints as "not understanding management", it is a kind of arrogance in itself.

3. Secondary Development Is the Absence of Management Consensus

Lao Yang believes that the massive emergence of secondary development requirements is often not a simple technical problem, but a management problem.

Many enterprises regard ERP, MES and CRM as pure IT projects when carrying out digitalization: select a software, find an implementation partner, let the IT department take the lead, and the business department put forward requirements. The result is — improper selection, buying software that is not suitable for the enterprise, but trying to modify it through secondary development into the easy-to-use software in mind; many enterprises also lack process sorting, and do not do management standardization first, then directly move the chaotic offline processes into the system as they are; the senior management lacks sufficient support, all departments act independently, there is no priority for requirements, and the loudest voice prevails; the implementation method is wrong, no pilot, no training, no change management, expecting the system to automatically change behaviors after going online.

The common result of the above practices is: secondary development has become a buffer zone for compromise among all parties. The software side does not want to modify, but the enterprise side insists on modification; the business department can't explain the requirements clearly, and the implementation side is too lazy to ask, so they can only rely on secondary development to "patch" the system. This is not the self-righteousness of any single party, but the absence of the entire project governance mechanism.

There is also a deep-seated reason: vendors want less secondary development in the initial stage of implementation, because standardized products have low marginal cost and high profit; enterprises want more secondary development, because they want to fit their own business. However, after the system goes online, some software companies prefer enterprises to carry out more secondary development, because they can obtain more profits through this, while enterprises at this stage prefer lower prices while meeting their requirements. Therefore, the two sides are naturally opposed in terms of interests, and the secondary development requirements become negotiation chips, which further amplifies their respective "self-righteousness".

4. Several Criteria for Judging Whether Secondary Development Is Reasonable

Secondary development is not a scourge, nor is it a sign of enterprise backwardness. The key is to distinguish which secondary development is necessary and valuable, and which is inefficient and should be avoided.

Compliance and integration-oriented secondary development is usually necessary. For example, the financial voucher format with Chinese characteristics, tax interfaces, bank docking, data security requirements, etc. These are hard constraints, and the system cannot operate without them.

Core differentiated capabilities are worthy of secondary development. If a certain function is the real competitive barrier of the enterprise — special pricing engine, R&D process management, customer customized process — which cannot be covered by standard software, then secondary development is a strategic investment rather than a waste.

Be highly vigilant when moving old processes into the system as they are. Originally, it was "oral approval by leaders", now we need to make an "arbitrary flow" approval process in the system; originally, it was Excel manual ledger, now we require the system to completely replicate the free editing function of Excel. This kind of secondary development is equivalent to using the new system to solidify old habits, losing the management improvement significance of digitalization.

If the requirement can be solved by configuration, do not write code. Many requirements can be realized through parameter configuration, workflow, permissions, reports and low-code platforms, which do not necessarily require code-level secondary development. The implementation party has the responsibility to exhaust all configuration capabilities before talking about development.

Evaluate long-term costs and upgrade risks. Every secondary development will increase the difficulty of system upgrade. Enterprises need to understand: the adaptation cost they save today may be repaid with several times of upgrade costs in the future.

5. How to Get Rid of "Two-Way Arrogance"

To solve the dispute over secondary development of standard software, it is not to eliminate secondary development, nor to make one side give in completely, but to establish a governance mechanism that can distinguish reasonable and unreasonable requirements, and coordinate reform and implementation.

For software vendors and implementation partners: they need to go deep into the front line, understand the real business scenarios, help business departments translate requirements, and convert vague business language into clear system rules, which is exactly the value of implementation consultants.

For the enterprise side: carry out management standardization first, and then launch the system. If the offline process itself is chaotic, the system will only automate the chaos; it is necessary to establish a requirement governance mechanism, so that secondary development requirements have clear proposers, evaluation criteria, priorities and decision-making processes, and the loudest voice cannot prevail.

6. Final Summary

From the above content, it is not difficult to see that the sentence "the secondary development of standard software is all made to cater to the self-righteousness of client enterprises" captures the pain points of many failed projects, but the word "all" is too absolute. In real scenarios, the secondary development of software includes a large number of low-value compromises, as well as many necessary compliance, integration and differentiated requirements.

Digital transformation is an organizational reform. The tension between standardization and personalization, control and flexibility, technology and management will inevitably erupt in the secondary development requirements. If both sides can put down the arrogance of "I am the correct answer" and turn secondary development from "mutual compromise" into "disciplined joint design", then secondary development will no longer be the result of self-righteousness, but the only way for the growth of enterprise digital capabilities.

This article is from WeChat Official Account "Xiangjiang Digital Review" (ID: benpaoshuzi), author: Lao Yang, published with authorization from 36Kr.