You might not believe me in this observation - it is written on 1 April - but try for a moment to imagine a 'controlled business process'. You can laugh already...
Nevertheless, when IT automates an operational business process using whatever "BMP" tool (you can laugh again because no BMP tools manage business processes, they execute predefined processes instead), the architects have two choices - go with 'BAU' and create an instrument consumed by business people or to create an instrument that consumes business people.
Let's take a business process with several actions and non-trivial business logic. Some of the actions may be automated, some - semi-automated, i.e. they require people to use automated instruments, others are just manual. If you look at this process by the 'business' eyes, it is not difficult to find that the process 'consumes' people who participate in the process. Thus, for the consumer of the business process, which we can identify as an 'End User', automated and manual activities of the process are non-distinguishable, they all serve the process. Moreover, the End User does not know and does not need to know about the process itself; the End User is interested in the business functionality provided and in the results or Real World Effect. In other words, this process appears as a service to the End User.
If we dig a bit into the internals of this process-service, we can find one of two process management models that reflect mentioned architectural choices - it is either a manually managed and controlled process or automatically controlled process. In the former case, a manager directs subordinates what next step in the process has to be, how to perform the activities and what automated instruments to use in which situation. This model is full of potential managerial and operational errors; results of one step may not match the input required for the next step as well as automated instruments may work in dissonance due to the absence of technical integrity. In the latter model, there is still a room for human mistakes but automated process controls allow to recognise and localise those mistakes much faster and with much less waste.
When I talk about automated process controls, I mean, for example, a process defined in BPEL that engages automated and manual services in its long-running Business Transactions. People performing manual operations are the parts of the process; they are not users of the process (and its automated parts) but the participants. The only user of the process is its consumer. This line of logic has a bit unexpected consequence for the process' GUI, e.g., Web pages. Particularly, it is the process that controls the content of and the flow of its user interface, e.g., the Web pages, and not other way around.
Here is an example. Assume we have a process written in BPEL with several steps. We are in the step N where a Draft of a document is prepared. The following 5 steps are: Review-1, Refine-1, Review-2, Refine-2, and Submission. The 'review' step is associated with a Workshop and discussions; the 'refine' step assumes changes in the document including some automated calculations.
When the process reaches the N+5 step - Submission - a change happens and it requires a modification of the document Draft. The Business Operator (BO) logs into the Web Site, navigates to the process stream and logs into the step where the Draft document is accessible. The BO performs a change and at this moment the automated control steps forward. It verifies whether the change done to the Draft document affects any of process steps between the step N and the step N+5. If a dependency is found, the process runs so-called Compensation T Transaction(s) that invalidates previous results. The Web server then automatically navigates to the Web page where the work has to be re-dune. The process disallows the BO to continue submitting the document because it is invalid after the change in the one of the previous steps. In particular, a change in the Draft document must be reviewed, i.e. the results of the Review-1 step must be automatically invalidated. If the review finds that more changes should be done to the document to preserve information integrity, the Rfine-1 step is also invalidates, which leads to invalidation of the step Review-2. The verification, 'undo' and 'redo' actions continue until the process reaches the same Submission step. If no more changes happen, the Submission step may be passed.
The automated control does not prevent cross-cutting by people, i.e. the BO can pretend having a real review in the step Review-1 and 'push' the process forward without a review. The process can partially control the review event requiring manual confirmation from the reviewer, which may be imitated. However, the process will record who acted in particular step and who should be kept responsible for the actions.
Some managers might criticise such control saying something like 'the life more complex and the process have to be altered on the fly' or 'the processes are for people, not vice versa'. It is a useless dispute - some processes are for the people disposal but others must be followed by the people. Try to argue at the intersection with a policeman that the process of semaphore has to serve you and show a green light when you want to move, and try to disobey this 'red-green' process...
My recommendation is never alter a process on the fly. Change the rational of the process first, and only then change the process. The major problem of 'changing on the fly' is in that we do not know all dependencies on other processes in the environment associated with particular step in our process. Business Analysts or even Architects who designed the process might had the reasons that they did not tell you and the break of those reasons for the sake of immediate advantage of your process may cost the company the price that is many times of your benefit.
Another consequence of automatically controlled process is that each step of the process must be justifiable. This should prevent creation of processes for the sake of the processes. The easiest way to avoid bogus process steps or entire processes is to look at each process step out-in or by the eyes of the process user. Does particular step work for the business functionality and promised business result or not? In other words, does particular step serve the business goal or not? The answer like 'we used to do such thing in this way' is unacceptable because nobody is interested in how we did it before, the question is about how to do it now for new business goal and objectives. In the process, each step is about servicing the final goal.
To go forward with automation of business activities and processes, we have to accept the fact that IT does not serve Business anymore; instead, IT partners with Business and technical resources are used in the process equally with the human resources. Such understanding comes naturally when we look at the business as at the service, top-down. This means that everything, which the lower level of operation is doing, serves the needs of the upper level. The end-user of the business process sees nothing else than a business result that is delivered by the collaborative work of people and technical automations, together.
Yes, exactly yesterday I was googling for "BPM Governance" tools, analogous to the "SOA Governance" registries concept within the company. Despite the theoretical concept can be there, I have not found any attempts of implementation so it seems to be beyond state of arts.
And agree with the embarrassing point that humans and roles would need to adapt themselves to (at least) some of the company procesess (rather than the opposite) so this BPM vision can take place. I guess it would require, for example, a high level of skills flexibility in companies and, the costs saved by this flexible processes can be paid by requiring flexibility in humans skills. This could have a lateral impact on job market and human mobility, or even environmental resources. Honestly, I do see human being prepared for it currently. Even worst, of course, in this credit crunch.
Lots of questions come to my mind related to your last paragraph:
* could the adveniment of eMarketplaces move CEOs automating companies processes? (i.e. applying the concept of algorithmic trading to other markets, the famous "extended company" idea),
* how can we try to automate inside the companies when the whole of the financial system is running on a unsustantable model (the Keynessian Model)? * These technical improvements can strongly enhance companies performance. But would highly performing companies create a better standards of life for humans? I do not have a response.
The huge impact of BPM is forcing us IMHO to think about the kind of society(ies) that we want (at least from the point of view of those trying to innovate). Has innovation currently found a clash with freedom?
In my opinion, at this moment, I do not see a large road for BPM, not for technical side, which can be forecasted, and there would be amazing things to come, neither for the lack of funding in the credit crunch, but for the unpredicted impact on human side. And this is a problem for we, the technical guys and our possibilities of innovation.
And response to these technical concerns are beyond IT itself, I think. Surprissingly is in areas as politics, ethics and philosophy. I thing IT guys have now to solve the issues that economists were unable to understand. Are we then in a crossroad?
Does it make any sense? These issues has been worring me for about 4-5 years now. If someone sees a clearer picture I would appreciate some references.
Adolfo
Hi Michael,
There are a couple of points to think about:
1) Systems serve people - this might not be obvious at all times, but even the traffic lights serve people, since they allow people to cross intersections safely. It as a question of abstraction.
2) No matter what or when you change - never make changes without thorough testing. Therefore you can change on the fly - but make sure it doesn't impact or even corrupt the current processes. This is why good systems have test environments that even automatically show the impact of your change. There are many cases where this works perfectly.
3) Systems are different to people - think people! People are the volatile part in this relationship and therefore their interests are of vital importance to any successful implementation. Especially with process automation, people will find ways to circumvent technology, if it is easier for them to get the work done or the system doesn't serve their needs. Therefore adaptation is an imperative for any process implementation to deliver its value. Make sure people can change processes and use them as tools instead of orders they need to obey.
Adolfo,
Thank you for such interesting comment.
I know that many people in modern movement of business organisation share the opinion of >. Even more, I participating in the group that discusses a concept of Value Networks where some participants believe that people have to be given a freedom to do business in the way they prefer and this with rocket business performances. In some industries it may be true while in some others this may be a life threatening idea.
I do not really see any embarrassing in the fact that when a person asks to be hired for a job, the job dictates certain rules how it should be done. If you do not like these rules, you can either look up for another employment with the rules you dislike less or you open your own enterprise and… enforce other to follow your rules. That is, automation here has no special role, nothing that is different from the already existing rules of business operation.
If one follows the rule “a process is for the man and not other way around� and tends to break a given process, there are only two possible results: 1) a break symbolises a defect in the process and, thus, leads to an innovation, and 2) a break causes to a chain of violations and breaks in other processes and results in trouble for the company. So, there are two categories of ‘men – those who use the process and the process is for them and those who provide the process, i.e. those who are for the process and no other way around.
I am not sure I really understand your statement about “a unsustantable model� in finance while an automation in the form of STP exists for a few years already.
As of “would highly performing companies create a better standards of life for humans�, we all know that there is a default conflict of interests between an enterprise/Employer and each Employee. Automation can help or hurt humans. Automation can release humans from monotone operations but also can make replace them making them unemployed. Everything, as usually, depends on the point of view.
Franz,
Thank you for the advices.
To your point >, I can add something like: ‘… but not all people; some people serve other people participating in complex systems’.
To your points >, I would say ‘agree/disagree’. It depends on the definition of “the work done�. As I said to Adolfo already, a way around prescribed process step can result in innovation or in troubles; in some cases an ‘easier ‘ job done results in the problems for the company and the question is: whose interests Technology has to preserve the first – the company’s or the person’s ones?
Also, if a system does not serve the needs of a person, it is necessary to find what these needs are and how they relate to the interests of the employer/company. System is not in fault always. Yes, people try to over-play systems but this is not necessary a good thing.