In most human systems communication in Business Processes is normally done via the “data transfer” (“fill form XYZ-02A1, sign it and give it to me”) where each participant transfers segments of data that are then somehow put in a bulk of data (“let me put this into your application folder and I’ll come back to you”). This approach considers:
- each source/sink of data an isolated element in the puzzle (“silos”)
- the sources/sink of data are difficult to interact with, and
therefore communication time should be optimized (reduced to the
minimum possible size) - interactions are not interactive, but mostly single-shot. This guarantees the integrity of process execution.
- each source/sink of data is a trusted participant:
- Business logic is somehow built in each one
- each knows how to do its task and does it correctly
- The whole bulk of aggregated data is passed from one source/sink to the next
AN EXAMPLE
Let us suppose that we have this long-running business process. It is some application that requires legal papers (visa/University/building a house/etc.). I choose this as example because I’ve seen an increase in the number of e-government initiatives, but most of them only give you access to some PDF document you can print.
I consider in this example that the application process is compatible (but not yet implemented) with the notion of “electronic record” or a dossier that can be made up of digital files.
If you take into account the tacit modeling principles listed above, no wonder why you receive mails like this after submission:
“We hereby confirm that we have received your application folder. Do not contact us. You should receive a response within 2 months. The processing delays are notified via our website.”
Besides, the bulk of data is built using non-scalable/non-incremental means, like hardcopies (“please print this form and include it in your application folder”) that do not support versioning, and that can only be changed by a total blocking of the processing.
Let us say that you receive, after 2 months waiting:
“Dear Mr./Mrs., we have found that section 13, paragraph B, line 3 is not readable. Please correct it and re-submit your application folder… Do not contact us. You should receive a response within 2 months after re-submitting. The processing delays are notified via our website.”
Sounds like realistic to you? Let us say now that you changed what you were told to change, but because of the processing times, a legal certification –valid for only 3 months– will expire during the resubmission. You were careful but he asynchronous nature (silo + slow communication) you cannot avoid it. Therefore, this will invalidate your application once more.
DEADLOCK IN PRE-BPM SYSTEMS
Let us suppose now that you guessed the expiration of this legal document might be a problem. You prevent
this issue and get your legal paper renewed after sending the application, just in time before the three months expiration delay.
You send it, so your application should be updated with a valid version of the legal paper. However, the application is considered as incomplete and will be sent back to you.
Why is this happening?
The processing team considers that adding a new element “is against the rules” and cannot be done without “opening the door to other people abusing the system”.
No smart administrative chief will agree on doing that.
Worst, the current, valid version of the legal paper is no longer in your hands, but somewhere in that organization.
Transfer Bulk of Data Patterns
The data-transfer approach in pre-SOA and pre-BPM makes the bulk of information of application X be on top of a pile in bureau of A, and then somewhere in bureau of B, and so on. When sensitive information cannot be seen by B, some person AB has to be included to hide/exclude that information from the bulk. Once B finishes his processing, then AB can rebuild the bulk X.
This introduces delays, complexity and, thus, increases the probability of errors. In a paper-based world, this is translated into more workload per employer, more focus on repetitive/tedious tasks than on doing value-adding work, and more stacks of papers and of procedures to process them.
Then, scalability gets even more compromised.
CONCLUSION
This is not flexible, this is not scalable, and this is not proper: the user is not satisfied, the process is not transparent, and the service provider cannot really assess where the problem is. Then, there is no improvement.
How come that we have technology to interact with the rest of the humanity (mostly for fun) and not with the processes that really add value to our jobs and even our lives?
This can have a great economic impact. In Switzerland, where I live, a study demonstrated that obtaining a working permit for an EU-national takes 10 weeks but that the real processing time takes only 15 minutes. For non-EU nationals this takes even longer.What is the cost of these delays? the lost revenue for all the stakeholders? the stress?
As the say here: Bouf! :-<
