End-to-End: the Energy Case
Tuesday, March 14, 2023 / Updated: April 12, 2023
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”?
Let’s think together. Please leave your suggestions below. (To be continued in a week.)
“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”?
Let’s think together. Please leave your suggestions below. (To be continued in a week.)
Posted on: in Old posts from bpm.com