Business Processes vs.
IT System Requirements -
They Really Are the Same
Business Processes Are Systems Too!
What are some examples of business processes that are systems? Accounting systems, customer tracking systems, invoicing systems and many others have existed in businesses for centuries. For most of business history, these business systems were manual systems. But they were and still are systems.
Sarbanes-Oxley (SOX) Process
The Building Requirements Consensus™ Methodology Definition of System
Building Requirements Consensus™ Methodology
definition of system is “a set or group of elements that exhibit behavior collectively.” Note the emphasis on producing behavior. Without behavior, there is no system! See
Use Case Basics.
It is clear that accounting systems, customer tracking systems and invoicing systems all meet that definition. Each one of them produces behavior. That behavior has proven to be beneficial to businesses over the centuries.
There have been some recent notable businesses that have failed because they did not perform one or more of these systems well. For example, the Enron accounting system turned out to be highly suspect.
Are Business Systems Really Different
from IT Systems?
From the perspective of the Building Requirements Consensus™ Methodology definition of system, business processes are systems. It does not matter how the system is implemented.
Do you think that a manual system and an automated system that produces the same behavior are different kinds of things? The Building Requirements Consensus™ Methodology declares that they are not different kinds of things.
That leads to an interesting question.
Why Are Business Processes Documented Differently than IT Systems?
Historically, business processes have been documented using concepts and notations that are different from those used by IT. However, it does not have to be that way!
Building Requirements Consensus™ Approach
uses a recursive model. That means that it can be applied equally well to all systems regardless of whether they are high level systems or low level systems. It works whether they are business systems or automated IT systems.
For example, the business process called "the shipping system" is a high level system. Large customers may have many different destinations. We need a midsized system to log and track the addresses of these destinations. Then we need a low level system to create shipping labels with the right address to put on individual packages.
Suppose an organization decides to automate its midsized system to log and track addresses and its low level system to create shipping labels. They must then define the requirements for the two systems to be automated.
Document Business Process Systems
and IT Systems the Same Way
By using the Building Requirements Consensus™ Methodology, you can document your business systems and your IT systems using the same concepts and techniques. A significant part of the historical miscommunication between business and IT comes from using different approaches.
Business notation is understood by business people and IT notation is understood by IT people. Few people understand both notations in depth. Business and IT are documenting in two different languages. Is there any wonder why communication is strained?
Now it is possible to document both business systems and IT systems using the same language.
How Is It Possible?
There are two reasons it is now possible for business and IT to speak the same language.
1) a unified methodology
2) mature analyst tools
We have already discussed how the Building Requirements Consensus™ Methodology unifies the business world and the IT world by the way it defines system.
Until recently, tools that are appropriate for both business systems and IT systems did not exist. Now they are mature enough to work well.
One Tool Uses Visual Simulation that Is Understandable by Everyone
Blueprint Requirements Center documents requirements for systems and presents them back in various formats depending upon how the viewer wants to see them. One of the formats is an interactive simulation.
A simulation of a business process or an IT system can be viewed by anyone. It is analogous to Adobe PDF files. You must have a license to produce PDF files but anyone can download a viewer and read the files. Requirements Center has a viewer and works the same way.
Simulations are interesting. First, you do not have to read pages and pages of text trying to figure out what it really means. Nor do you have to view architectural drawings, a language you are not fluent in. See
Using the Right Medium for System Requirements Gets Buy In
A simulation works one way. If it does not work the way someone expects, it will start a conversation. This locates and resolves issues before the business process or IT system is implemented and helps assure that the right system is built the first time.
Simulations can be thought of as playing a video game. Anyone can view the simulation and get what behavior the system delivers. No special training is needed to understand concepts notations. Viewers get a direct experience of the proposed system.
If a picture is worth a thousand words,
a simulation is worth a thousand pictures.
You can find interesting articles and more information on the
strategic nature of business process mapping and enterprise architecture here.
(Opens in new window)
From Business Processes vs. IT System Requirements
to Building Requirements Consensus™ Home