End-to-End: the Energy Case (continued)

Details

Published: June 15, 2015

Written by Anatoly Belaychuk

As every experienced analyst knows, "what the customer asks is not what he wants and what he wants is not what he really needs." Applied to business processes, it means that what a customer calls a “process” is often a process fragment, really. And this is exactly the case.

Here is what the company CEO has told:

“It also happens that when the ordered pipes are finally delivered, they are partially used for emergency need, e.g. to fix a breakage happened elsewhere. As a result, the original customer won’t get the ordered goods. It won’t be a problem because often there is enough time to re-order but the point is that no one knows that the order will not be delivered.”

Interestingly, this was only revealed at the discussion with the company CEO. And it’s a lesson for business analysts, by the way: never limit your communication with a single representative of the customer, the so-called Subject Matter Expert. This approach generally doesn’t work well. Do your best to communicate with executives (in brief at least) to get their feeling of the business problem. It’s also very important to talk with those who really do the job. Typically the role of a subject matter expert is played by a middle manager and too often he/she tries to prevent communication between the analysts and others: “you don’t need them, I’ll tell you everything.” Don’t let it happen – nobody knows everything in any non-trivial business process; don’t forget that the analysis is your responsibility, not the expert’s.

Now what does this “little peculiarity” mean? The process scope wasn’t defined right from the very beginning!

The customer was talking about the process named “purchase order approval.” Therefore it starts with the needs list from a site and ends with the set of purchase requests approved to start a tender by each.

But is this enough? Obviously not.A purchase request may be perfectly filled and approved yet the site won’t get the ordered pipes because they were used elsewhere. So if we are targeting the business problem – that is, meeting the sites’ needs in the materials, equipment and services – then we can’t help extending the process scope by including the control of ordered goods delivery.

The incoming goods should be associated with a specific original site’s needs list. They were summed up during the approval, now the reverse operations should be performed: incoming total volumes should be split by the initial needs. This way we’ll be able e.g. to re-order the pipes if some of them were taken away.

Old saying “As you call a ship so it will float” is right for the case: if we called the process “purchase order approval” then the approved order would be the process result, period.

So we’ve found that “purchase order approval” isn’t the end-to-end process. So what should be the process scope and process name, then? What should be the process’ “ends”?

Anatoly Belaychuk has over 20 years of professional and managerial experience in software and consulting industry. He is acknowledged BPM (Business Process Management) expert, writer, key speaker at BPM conferences, blogger and trainer. His current position is as a BPM Evangelist at Comindware