Why you can skip business process analysis when purchasing COTS or cloud software

In an enterprise situation, business process analysis is a crucial part of software development. When an organization decides to write software to automate certain business processes, the early phases of the project involve business process analysis and optimization.

A key software development objective is to design the system in such a way that process improvements can be implemented by configuration changes, rather than having to change the underlying code. However, writing sophisticated enterprise software is an expensive and risky proposition for most organizations. Sometimes organizations can’t even finish what they start; for example see “An IT failure unicorn: Endless 19-year project in Massachusetts” by Michael Krigsman. If suitable software exists, it is usually far cheaper and less risky for an organization to buy the software than to try to write it themselves.

When buying commercial off-the-shelf (COTS) or cloud software that is a good fit with requirements, most of the processes needed will already be built in. The software vendor will have developed them with inputs from multiple customers. Many of these processes may have been optimized, and may be better than your existing ones. There may even be some included that you didn’t know you could use.

The process analysis question

The question is this: should business processes be analyzed and optimized before buying new off-the-shelf or cloud enterprise software? We would argue that in most situations this is not necessary. Doing so does not add significant value, and will delay the implementation of the new system.

Instead, the process owners should document their needs in detailed requirements. One of the best ways to do this is to use the technique of reverse engineering features from potential products back into a detailed list of requirements. Next, the process owners rate those requirements for importance. Then RFPs are sent out, and vendor responses captured. Finally, the gap analysis is done by scoring potential products against the requirements, and the winning product selected. This assumes each business process owner knows their processes well enough to judge how important the requirements are to the organization. Note that this is not always true in smaller, fast-growing companies. In these situations help is needed, e.g. from consultants with experience in those particular business areas.

One of the main reasons for software implementation projects exceeding budgets and schedules is the discovery of unknown requirements during implementation. Every time a new requirement is uncovered, that requirement must be evaluated for importance. If it is a showstopper, critical or even very important and is not supported by the software, work around solutions must be developed and implemented. When this happens too often, the project is delayed, and costs exceed the budget.

The core of the argument

The core of this argument is that the reason you don’t need to do the process analysis up front is because those processes are already built into the software. Any analysis done is not going to change the purchased code at all.

Rather, the time can be spent more effectively doing a thorough requirements analysis. This analysis should uncover and express all the processes as requirements, and ensure no new requirements will be discovered during implementation. Then the various process owners must decide how important those requirements are to their operations.

If detailed requirements are known before the implementation project starts, they will be planned for rather than causing unpleasant surprises during the implementation. Another factor is that detailed requirements may result in selecting software that is a better fit for the particular needs of the organization.

Any process analysis and optimization should be left for the implementation stage of the project rather than being done up front, because the purchased software has a significant impact on how processes are implemented in that system. Also, the software vendor’s best practices may obviate the need for much of the analysis and optimization work.

Conclusion

While business process analysis is critically important when developing software, it is not necessary when selecting off-the-shelf or cloud enterprise software because those processes are already built into the system. A much better use of time is to do a thorough requirements analysis and have the process owners decide how important those requirements are to their operations.