Are Businesses Really Unique?
Many vendors consider their market to be a series of different industries with their product claiming different industry specific features for many. Some vendors consider their market limited to a few or even a single marketplace (for example process or A&D). This market definition by the vendors indicates that they think different industries have different requirements.
One study indicates that 42.16% of ERP customers have modified their systems "Quite a lot". Why do these companies modify their systems? The only reason could be that the system does not do all that the company requires or in a way which is not appropriate for that company. It must be that these companies have unique requirements or the vendors would supply them in their standard systems.
Vendors targeting different markets and 42.16% of their customers modifying the products "Quite a lot" mean that companies are unique one system does not fit all.
What Has Happened And Why
Standard application software, for the most part, has been designed to meet the needs of multiple companies in multiple industries. As applications have grown deeper and richer in functionality, they have extended beyond simple accounting and control systems to become decision support and optimization systems. The requirement for the system to match the reality of the business has therefore increased.
Vendors are driven by investors and ego to become larger. To grow, most have attempted to broaden their market by addressing additional industries. To meet the needs of different industries, vendors have added many industry specific functions.
These added features increase the ability of the company to address additional industries. However, normally, no single company is in more than one or two different industries. Although the fit is improved in one industry, the cost of this fit is feature software bloat. The Online Computing Dictionary defines software bloat as "The result of adding new features to a program or system ... to the point where the benefit of the new features is outweighed by the extra resources consumed (e.g., RAM, disk space or performance) and complexity of use."
Many of the added functions apply to only a few of the various industries addressed meaning that all other industries must suffer the consequences of these non-essential functions. Even if two or more industries need the same function, they often have minor differences or need to interrelate to different industry specific functions. Bloat, in the form of complex program logic is required not to execute the function, but to determine which of many paths the program must take.
The cost of bloat is real. Code complexity leads to quality problems. Code complexity means support become more difficult. Enhancements and modifications prove more costly and error prone. Implementations are more lengthy and difficult. Upgrades from release to release become more time consuming and error prone.
A recent study states that the average percent of available functions that were actually used was 27% with only 15% used regularly. The study also concluded that there was objective bloat (functions unused by almost every user) and subjective bloat (functions used only by certain subsets of users). One person's bloat is another's favorite function.
the article, "What's
Wrong With Application Software? Business Changes, Software Must Change With
The Business" we discussed the cost of modifying software. A major
cost driver in the cost of modifications is the complexity of the code that
is driven by bloat.
The cost of ownership for a bloated product is higher. Support, modifications and enhancements, implementations, training, upgrades, and other activities across the software lifecycle all cost more. Complex code means lower quality, a common complaint in recent years.
What We Need Lean Software
Lean software has only the functions we need. It does not suffer from the complexities of trying to do too much. But the definition is "the functions we need" this is a difficult list to develop. To start with, the list is industry specific but it is also company specific. Software must address the fundamentals of how a business operates, including the basic assumptions about the nature of the products, the channels the industry uses to reach its customers, the commercial terms used to buy and sell, and other factors. In order to avoid adding to the current problem of complexity of code, different applications should be designed and developed for different industries and it must be practical to modify and extend these applications to account for company specific issues.
It is not enough to be able to "turn off" features with configuration switches, which may help users but only further increase the complexity of the code.
characteristics of Lean Software include:
should leverage best practice business processes. These should reflect general
business needs (financial applications for example) and industry specific
(auto industry issues, food & beverage, etc.)
|Mix and Match
with different divisions in different industries, the central systems should
reflect common needs while the division systems should be industry specific.
The components should work together as is.
||Since no system
can cover all of a specific enterprises needs, the system should allow for
this reality (see What's
Wrong With Application Software? Business Changes, Software Must Change
With The Business)
||The cost of
support should make the support of each product into a viable business proposition
for the vendor.
The current generation of application software has helped standardize many best practices. But businesses are still unique and they must be able to serve their customers and to compete. Application software has grown increasingly complex because it is trying to support too many conflicting features for different industries. Application software needs to evolve so that it recognizes the reality that businesses are unique, but not by adding bloat to existing products. They need to build lean products that serve specific sets of customers plus allow the customer to build in their own, individual needs.
Thompson is a principal of Process ERP Partners. He
has over 25 years experience as an executive in the software industry. Olin
has been called "the Father of Process ERP." He is a frequent author
and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce
and the impact of technology on industry.
can be reached at Olin@ProcessERP.com.