Do you build a software system to fit a new or modified business process, or do you implement the system first and then change the process?
I sometimes receive interesting questions from readers looking for advice to solve a problem they have. This question is about an issue that many organizations might have faced:
I overheard a phone conversation this morning in which someone said, “You can’t build the system first and then see where it fits into the process.” I realized that in most of the system development projects that I have been involved in, we hardly ever investigate to find out where the system fits into the process that is to be supported.
So my question is: At what point should we take this into consideration? I would imagine that knowing this would improve the stakeholder identification and, maybe, fine-tune the development of use cases. However, this might have the effect of limiting the user’s creativity to the scope of the portion to which they are confined in the particular process to be supported. What do you think?
There’s kind of a chicken-and-egg problem here. I suggest that the time to contemplate how a new information system will fit into your business processes is before you ever start the software development work.
In some cases, people expect that building a new software system will then drive improvements or changes in the business processes. This is problematic for several reasons. First, the way the application is used in operation might not lead to the expected or desired business process improvements. In addition, modifying business processes also involves culture changes and education of the users regarding both manual and automated activities. It’s difficult for a new information system to accomplish all that transformation.
There’s another problem, also. When I was a corporate software developer, sometimes people would refer to “Karl’s system,” meaning the one I was responsible for implementing. There was an implied expectation that, as the lead developer or project manager, I also was responsible for successfully rolling out the application to the user community and guiding the implementation of associated new business processes.
This is not a reasonable burden to place on either a new information system or its developers. I wouldn’t expect business users to eagerly accept a new application and new ways of doing their work just because some application developer says so.
It works better to devise a new business process first, and then assess what changes in your information systems architecture are needed to enable it. Properly supporting a new business process often also involves revising and integrating with multiple existing systems, which might not be apparent if you create the new system first and then hope it achieves the desired results.
Understanding the new or modified business process facilitates identifying its key stakeholders, which helps you identify the new application’s various user classes. The next step is to select appropriate representatives to serve as the literal voice of the customer for each of those user classes. If you build the application first, you might well overlook affected stakeholders and user classes. That oversight is sure to cause problems with the new system’s acceptance. It could lead to extensive rework before the solution is acceptable to the business users and their managers.
Developing the new system first poses other risks. It’s easy to “repave the cow paths,” re-implementing the inefficiencies and obsolete aspects of the existing business process. If you then modify the process afterwards to address those shortcomings, the new system might not work well with it.
It can be hard for requirements elicitation participants to look beyond the limitations of the current system to a paradigm shift in the process and how software could support it. I encountered this situation when I was leading a long-term computing strategy initiative for a huge corporate research laboratory. I suggested that the scientists imagine how they might perform their experiments more efficiently by first selecting components from several databases, combining them into hypothetical products in a particular way, and then seeing simulated results of the likely behaviors. We couldn’t do all that yet, but it seemed potentially feasible. The scientists had zero interest in that idea, even though it had the potential to greatly accelerate their research. It was too radical a leap into a new process for them to imagine.
There are risks with defining the new process first, too. A modified business process could require unexpected and extensive changes in existing applications and their interfaces. These modifications could expand the project scope (and its cost) well beyond what the decision makers anticipated. An ecosystem map is a helpful tool to understand the ripple effects of a major process change.
The ecosystem map in Figure 1 illustrates how a new system, an Online Ordering Site for a restaurant, connects to several other existing systems that would be affected by a new ordering process, both directly and indirectly. The planners will need to work with representatives who know those other systems to understand all of the implications and the changes they’ll need to make.
New or changed business processes and their supporting software applications are intertwined. In general, though, I think the process should drive the systems development, not the other way around. Creative business analysts and users can collaborate to determine the appropriate application scope and identify all the affected systems to develop or modify. Those discussions might lead to further changes in the proposed business process based on what a software solution can, and cannot, do.
So there’s some give and take involved, some iteration that could lead to the best outcome of both new software systems and new business processes.