No off-the-shelf system can mimic all the peculiarities of the existing processes. As a result, re-creating old processes in the new system will invariably result in the need for extensive customisation.
The perils of this are illustrated by one public sector organisation that insisted on a 'like-for-like' replacement of a legacy system. An Auditor General's report found that this was so problematic that excessive customisation of the product eroded its inherent benefits and further increased costs.
The solution to overcoming complexity is in clearly understanding the business strategies and goals the new system is trying to support. One way to do this is to lay out the capabilities the system needs to support and distinguish between what is required on day 1 of go-live and what is not.
More importantly, consider the capabilities (see graphic below) that are common across the business units and those that are not. Those capabilities that are unique to a business lie within the scope of the project but could be designed and implemented outside of the system.
Common core capabilities
These capabilities are most critical and need to be implemented in the system in order to make sure the system fully meets the business goals. These will include capabilities that are required to meet legislative and/or regulatory requirements.
Common non-core capabilities
These capabilities should generally be considered for future enhancements. However if they are to be implemented on day 1, they should be accompanied by a robust business case detailing the impact to the business if this change is not included.
Unique core capabilities
Every organisation will have specialised core capabilities that will be used only by certain business units. These could be "must have" capabilities that are required only in a given region, or country. It is often wise to support these capabilities independent of the main system, to avoid the considerable risk inherent in trying to build a system that will be all things to all people.
Unique non-core capabilities
These are nice-to-have processes that are neither business drivers nor required, e.g. a complex report that only one local office wants. These should be kept standard. A large proportion of custom requests are likely to fall into this quadrant, but by strictly adhering to the standard, an organisation can significantly reduce the system's complexity, and thus its total cost of ownership.
This approach of only implementing the core capabilities is similar to the minimum viable product (MVP) strategy used by many startups during product development.
A minimum viable product has just those core features that allow the product to be deployed, and no more. By keeping the system to just the critical features in the first instance, an organisation can significantly reduce program complexity.
Sign up for Computerworld eNewsletters.