The reasons to replace an existing system may be technical in nature such as upgrading the platform or notice that key software will no longer be supported by the vendor. Or, it may be due to changing business conditions and the need to respond quicker in an increasingly more dynamic market and customer demands. In these cases, the decision to replace the system is often accompanied by a mandate that there be no change to the underlying business process. The intent being that the user will perform essentially the same tasks but with a different tool. This focus on the technology could lead to the assumption that analysis and documentation of the underlying business processes need not be performed.
Developing System Interaction models to show the way the current system behaves and interacts with other systems is important to the design of the new system but it only provides one part of the picture. A comprehensive set of business requirements is needed whether the new system will be built in-house or if an RFP for a third-party package is being considered. To achieve this, a clear understanding of why the system exists is necessary. Information such as what the core business processes being supported by the system are, how the current system enables these processes, how the new system will need to enable them and how the user interacts with the system is fundamental not only to successful system development but also to creation of test plans, training materials and user manuals. If the correct foundation is not there to understand and communicate this information a major risk to business continuity exists.
An Organization that has a solid BPM methodology in place and treats its business processes as assets, will already be maintaining the current state, also known as the “as-is”, business process model. In fact, this is a fundamental part of its continuous improvement strategy. When the decision is made to replace a system, the foundation will already exist. This Organization already knows what the requirements are for the system that will support its business and can provide them quickly and confidently. The task then becomes one of validation rather than discovery. The current state Business Process model together with the System Interaction model mentioned above allows the project to move into the design stage earlier without the risk of incomplete requirements and erroneous assumptions. This is a good reason for maintaining business process documentation throughout the Business Process Life Cycle. Not only does this make the business process information available when needed, by showing the interactions with other business processes and systems, the risk of sub-optimizing associated processes and systems is eliminated.
However, if process documentation is not available or has not been maintained, the effort to develop this documentation must be built into the project schedule in the same manner as any other key deliverable. It will be a key component in developing requirements that are input to design and should be broad enough to include manual steps as well as identify other systems that are used during the execution of the related business processes. These manual steps are important to aid in the understanding of the business process as well as lending insight to the way the business uses the existing system and, equally as important, how it is not used and why. The documentation should also identify how other systems are used to help identify potential updates required to these systems. While the System Interaction model mentioned above should identify these, it is surprising how easily key information may be missed without the additional business process perspective.
The last member of this triad is a comprehensive set of Business Rules. Depending on the BPM maturity of the Organization, Business Rules may already be captured as part of the Business Process Model. These, together with the Business Process diagrams and the System Interaction diagrams and their Narratives, will allow the development of a comprehensive set of business requirements and pave the way for effective testing and training.
Another risk when doing a System Replacement project is failing to include the business users early in the project resulting in incorrect assumptions on how the system should be designed. Most business users have an excellent understanding of the systems they use and can be innovative in the way they use them. The more flexible the system, the more likely that someone has developed a way to accomplish a task it may not have originally been designed to perform. This system ‘functionality” has now become an integral part of the day-to-day business and, as such, is a real business need that may be unintentionally left out of the new system if only the system perspective is considered.
And finally, do just-in-time development methodologies such as Agile and Feature Driven Development (FDD) eliminate the need for comprehensive Business Process models? Some may believe this to be true but nothing could be further from the truth. In fact, this type of development makes it even more critical that the business processes be clearly understood so that the application components or features continue to support the business need. Paramount to, critical to, absolutely necessary is the mapping of the development components to the business processes they are enabling. Without this mapping, the feature may end up supporting only part of the business process and gaps may not be identified until late in the cycle adding additional rework and unnecessary costs. While these methodologies promote early involvement of the business user, it can be problematic without a common understanding of the purpose and role that is played by the development component in the Business Architecture and can dramatically increases the risk to the business.
To summarize, key considerations when doing a System Replacement project are:
- Business Process modeling is a value adding activity and should be planned for accordingly.
- Validate current state processes if they exist, create them if they don’t.
- Make sure you have the full picture by using a System Interaction model, Business Process model, Narratives and documented Business Rules.
- Involve the Business Users early.
- In order to support agile development, the underlying business strategy and business architecture must be well-defined and well-documented.
