Documenting business processes has become an important initiative for many Organizations. The advantages of identifying, understanding and evaluating key business processes to determine their effectiveness in meeting business objectives has been recognized for some time. There are many methodologies and tools available today to aid in capturing information about how a business performs its day-to-day activities in order to achieve desired efficiencies and cost reductions. A common approach integral to most methodologies is to develop an end-to-end process flow.
An important question to be answered before starting is what does end-to-end really mean? For the head of a Department it may mean viewing a business process from the time it enters the Department’s control until it is either completed or handed off to another Department or external Organization. It may mean only those processes owned and controlled by the Department. For a Division Executive, it may include all the Departments in the Division and be a means to identify gaps and overlaps to determine improvement opportunities. And yet another perspective is that of the CEO who wants to use a process-centric approach to the business rather than the typical functional view and achieve a means to assess the impacts of strategic decisions on the business processes critical to their Organization.
For centralized support groups such as Information Technology (IT), in addition to their own department’s business processes, they are responsible for all automated processes used by the business. Therefore, IT may see end-to-end as referring to the execution of specific software processes regardless of who uses them. For the purposes of this discussion, a software process is performed by a machine aided by technology. It starts when a user initiates a transaction, or triggers an event, and ends when the computer delivers a response or result. A business process, on the other hand, is performed by a human being and may or may not be enabled by one or more software processes. Take, for example, validating access to a building. The user swipes a card through a card reader initiating or triggering the transaction. The software process then takes over reading the data and passes it through various routines that evaluate the request using pre-defined business rules. As soon as the card is swiped, the person no longer has control over what occurs next and how it is executed. The result will either be a green light and release of the door lock, or a red light and denied access. In addition to swiping the card, let’s look at what other processes are involved with gaining access to the building. What might end-to-end mean in the case of building access? One prerequisite to this process is that the person has a card to swipe. Therefore, we need a process for obtaining the card. Usually the employee goes to a Security Office, shows proof of eligibility for the card and has their picture taken. A card is made and given to them. But wait, where does the proof of eligibility come from? Before the Security Office can validate eligibility, someone must establish the person’s right to have access to the building. Therefore, a request must be made to have an access card authorized for the incoming employee. Thus another business process is involved which, in turn, is part of a broader process for bringing in new employees.
How are all the different processes identified and put together to form a full end-to-end view? Where should it start and where should it end? Should a company document its business as one large process covering all aspects of day-to-day activities? Can the needs of the individual groups be met and still provide what is needed for the good of the whole Organization? Many Organizations try a centralized approach but end up going to a level of detail that is difficult to manage and maintain. They struggle with identifying the optimal level of detail and how much autonomy each group wants or is capable of when documenting their processes. The initiative often becomes mired in politics, disagreements over methodology and tools, what the “right” level of detail should be, process ownership and the sheer volume of information involved. Other Organizations allow Departments the freedom to decide what methods and tools to use for documenting their business processes with the expectation that they meet their performance goals and defined objectives. This approach can lead to efficiencies in individual areas which sub-optimize those in others. In most cases, the answer lies somewhere in the middle. The key to successful understanding of an Organization’s end-to-end processes is spending the time to answer questions like these to define a plan that creates the right balance between centralized and decentralized process documentation and provides people with the necessary tools to get the job done.
