Business process could be series of streamlined, lean, mature steps to achieve a business event say billing a customer, workflow for approving leaves etc. These series of activities may or may not translate to an activity to be performed in the system. However, systems enable the automation of most of the Business Process. In the due course of time these steps mature, new Business validations are brought in and it keeps growing. The process could swing either ways, it could get more complex over the period of time or it could get further simplified and become more robust. In other words a process along with all the changes which happened over the course of time including the changes in the Business Validations is an evolutionary process.
Having said that, who has the visibility and track of all the changes which happens and can be an authority on the current process nuances? Ideally it should be the Business Process Owner, who defines the process and ensures it meets the needs of the Organization.
But is it always true that the Business Process Owners are indeed the best custodians of the of change trail and can spell out all the scenarios? Do they track these processes so closely that the normal and exception cases are known inside out? Do they know the process in manner that they can point out what is supposed to happen and are in position to face Process Audits?
In case you feel the answer to most of the questions is no, then, you are not alone. More often than not, the Business Process owners rely on the expertise of the Solutions and Architects of the Business process in Systems for understanding how a typical process would behave. They cross-check with the System Architects on the validations which would come into picture for particular scenarios.
Why does this happen? It does happen that Business Process Owners do not have the best of the mechanisms to manage Change Management. Whereas for an Architect it is one of the critical activity before any release. Also this information is more updated with the Architect so much so that in discussions and decision making meetings, the most knowledgeable person on the Process is the Architect. Hence, when it comes to facing audits, when it comes to clarifying behavior for exception and normal scenarios, the person in demand is the Architect of the Solution.
Is it that the Business Process owners transfer the responsibility and accountability of owning the process to the other side of the table? Or is that the dependency on the Solution providers is so much that, the they become the pseudo owners?
Is this transfer of accountability justified? How do we make the Business Process owner the real owner?
More on how to address these scenarios in Part II of the blog.