In my previous article, I presented the idea of 3 views of the same process. Surely you can identify more, depending on the case.
I’d like to enforce the concept that the actual work done by the process are the consecution of tasks done by the actors, so the “Real view” is the current implementation of the process (of course, we see this at definition phase). The other views are just what the owner or the rule “think” that the process is.
When we collected all the data given by owners, documents and actors, we have to decide what portion of each is related to the actual process, and what will define the BP implementation we have to design.
So, I’ll start analyzing some aspects of the actors’ view that can help us to decide.
Actors are the ones that will carry out the tasks involved in a process. In some cases, their working routine might have some bad habits that slow down the process, complicate its flow, or even create mistakes in its results. But completely changing the actors’ habits will surely produce great resistance to implementation.
So it’s important to try to simplify the actors’ interactions with the process, avoiding redundant or repetitive tasks. They will be thankfull.
I had this case:
A guy was in charge of rutinary creation of some kind of orders. At the end of the year, he took every order from a physical file, copied it and its tickets in the copier (hundred of orders, each one with at least 2 tickets) and made a report summarizing all orders of the year. So he spent the last week of the year doing that, full of mistakes, and with serious headaches.
Possible solution? Now he creates orders in the scope of the BPM system (he previously did that in an old system), he scans the tickets of the day and associates them to the orders, and at end of year, he clicks “yearly report”, and all the job is done.
Now he does a little extra effort every day (actually he says he likes scanning, because is something out of his older routine); and no more headaches at the end of the year.
Actions repeated by several actors
Sometimes an action contained in several moments of the process is hard or slow to achieve. Maybe the owner of the process knows that the action is repeated, but does not know that each time it is done, it’s done from scratch.
This is a clear situation in which summarizing actors’ views of the process will be more useful than the owner’s view itself. We can detect slow-downs, or even bottlenecks.
How to solve it will depend on the problem itself, and the grade of automation the process will have.
Surely we can think of lots of other situations like these ones. Can you share others?