Along with defining a process, you have to name one person as its Process Owner. To be clear, I don't mean there is only one Process Owner in the whole company: that might happen somewhere, but it's not the normal case. What I mean is that each process has one Owner. Depending how things work at your place, it's possible that one person might end up owning a couple different processes, or possibly not.
The Process Owner is the go-to person for all issues, problems, or discussions related to that process. In more formal terms, the Process Owner is the (one) person who has authority to define the process or to change it, and who also has the responsibility to ensure that it works. Let's unpack this.
First, I say the Process Owner has the authority to define the process (or change it).I never say that he has to have the knowledge or expertise all by himself.
Of course he might. I once worked at a place where the Warehouse Manager knew the status of every order, every planned shipment, and every piece of inventory; he also knew more about the ins-and-outs of storage and shipment than anyone else in the company. He was awesome.
But it's not always true. I've also seen cases where one process (in this case, the product development process) was so fantastically complicated that there was a whole department devoted to keeping it current. The Process Owner was the overall VP of Engineering, but he had to rely on his experts to discuss the details.
It might happen that one process touches many departments, so that the Process Owner has to get multiple people to buy in before he can finalize his process and publish it. He probably has to align with the owners of the other processes that provide inputs into his, or of those to whom he provides his outputs in turn. All of this is possible.
But at the end of the day, there has to be one person who is responsible. If there isn't one Owner responsible, then in practice nobody is responsible. And in that case, if the process ever fails – or breaks down, or proves dysfunctional (and one day they all do) – nobody is really responsible to fix it. Yes, the organization will find ways to ignore the process or work around it. Work will still get done. But the official goals will all be missed and the formal indicators will all be red. And by then the process will have become just an obstacle, instead of a tool.
Second, I say that the Process Owner has the responsibility to ensure that the process works. This responsibility entails a couple of different things.
On the one hand, when the Process Owner defines the process, he had better insert steps to make sure associates are really following the process and the daily work is on track. These steps might be as simple as filling out a checklist or signing off a traveler, but they could also be a lot more complex if necessary.
On the other hand, the Process Owner also has to check the process performance, to make sure the company is getting the expected results. Then once he has checked the process performance, he has to report to Top Management. If the process is giving the results it is supposed to give, life is roses. If not, he had better find out why not. It might be just a routine blip in performance, a normal statistical deviation that doesn't worry anyone. Or it might be a sign that something is wrong, that the process no longer meets the company's needs and has to be adjusted. Of course you don't want to change your basic processes for light and transient causes; so in the first case it's probably best to sit tight and see if next quarter is better. But no process is perfect, and no process lasts forever. Sooner or later, they all have to be adjusted, reworked, or scrapped. Watch closely so you can tell when this has come to pass.
My third post in this sequence is about how to measure process performance. Reporting to Top Management takes place during Management Review, and I'll discuss that in the future (probably some months from now).
In other words, this post covers the basic What of the Process Owner's job. In the next post we'll start to discuss the How.
No comments:
Post a Comment