At a recent breakfast event, a CIO of a very large company commented that the firm was going to re-implement its enterprise resource planning (ERP) solution at a number of sites as part of a corporate roll-out. Apparently, in her view, the original implementations resulted in totally unsustainable systems. Apart from the direct cost implications of this decision, the disruption factor for businesses to re-implement ERP after a short time must have been enormous.
What factors then lead to a system becoming unsustainable and is it possible to avoid any pitfalls before an implementation? Or, if having already implemented a system, what are the symptoms of an unsustainable implementation and how can these be addressed? These questions do not only apply to ERP but to other systems in manufacturing businesses, such as process control and MES systems.
From a business perspective, if the system provides sustained value, if the resources for maintaining the system are not increasing out of proportion to the value, if the business processes are relatively static and well supported by the system, then these are good indicators that the system is healthy. On the other hand, if the system value is questionable (and people routinely resort to workarounds to do their jobs), if the maintenance costs are rising (perhaps as technology becomes obsolete) or if there is a high rate of change in the business, then there is a danger that the system can be unhealthy and perhaps unsustainable.
The design during an initial implementation is perhaps the most obvious contributor to the sustainability of a system. The premise is that the software is usually fit for purpose and will work. However, like designing and building a house, systems can be configured to accommodate future expansion and change, or they can be fast-tracked without consideration of future requirements to provide a rigid outcome that is suitable only for a while. If future change is not accommodated, then by definition after time the system will become irrelevant to the business and hence unsustainable.
The design during an initial implementation is perhaps the most obvious contributor to the sustainability of a system.
Gavin Halse, MD, ApplyIT
People`s acceptance of a system is probably even more important to its sustainability. End-user understanding of the system is critical, and if lacking, it can lead to failure in the long-term. But while end-user training is usually well planned, training of the support staff and administrators is sometimes lacking. What usually happens is that these specialised configuration skills leave soon after the project and the system maintenance is left in the hands of end-users and limited IT staff.
Assuming the system survives the first few years, what causes a system to die over time? Ongoing change in the business is clearly a major factor. Unless there is adequate capacity in the organisation to constantly adapt the system to a changing business model, it will start retarding and eventually erode value. Sometimes the changes in a company are more subtle, such as cultural or technology changes. Each of these has the effect of moving what was once a working system closer to the horizon of obscurity.
What then is the solution to these problems? Clearly an acceptance that IT systems do indeed die if left alone will lead to a more proactive approach. Management needs to have a realistic expectation of the expected life of a system, and plan for its retirement. This requires a bold and informed approach, such as planning a system re-implementation into medium- to long-term budgets.
Software vendors have built various models to avoid the technology obsolescence factor. Typically this is a maintenance fee, payable annually for software upgrades and enhancements. My advice to customers is to take the effort to understand the software vendor`s business and understand what benefits are included in this maintenance fee. In my experience, because of the relatively high cost of sale, software companies value annuity revenue more highly than the initial software licence fees, and many are willing to provide really useful services around a service agreement.
The best example in practice I have encountered is a routine system "health check" in which the vendor or consultant performs a detailed, focused audit on the use of the software in the business. This takes place perhaps once or twice a year. For as little as two days` effort, the value of the software can be assessed, any problems with user acceptance identified, and the technical health of the system addressed. Eventual obsolescence and retirement of the system can be predicted and planned for. Perhaps more importantly, if there is functionality in the system that is being under-used, then the vendor or consultant can usually see this clearly by virtue of their knowledge of how other companies use the system.
It is perhaps fair that past practices by software vendors and consultants have led to a cautious approach by companies which buy their services. However, it is also fair to say that with a proactive approach to partnering with these vendors and their consultants, at relatively low cost companies can ensure their systems are always finely tuned to the needs of the business, and thereby contribute towards the sustainability of the solution.
Share