July 10, 2008 – 11:25 pm
I’m not a big fan of the one-size-fits-all approach to processes. I think that processes can be good, like when they formalize the way people do things and establish a single point of understanding. I think that processes can be bad, like when they’re so complex and unrelenting that they get in the way of actual work.
Some people think processes are the silver bullet to every problem. “That wouldn’t have happened if a process had been in place and followed,” they say. Other people think processes are a waste across the board. “We did just fine before management started making us follow this process, and now it adds three weeks to our work,” they insist.
The big question is, how do we meet halfway? How do we show the value of business processes while not forcing people to choke them down? How do we establish guidelines for business process management and still let people do their jobs in the way they are most productive?
The Daily WTF had a recent post (albeit fictionalized) about how a blind adherence to processes completely eclipsed common sense. I can’t personally believe that the people in that story would be so ignorant as to lose an entire day’s work from such a simple matter, but at the same time, the story does have a point: IT stuff is not trusted as much as they should be, and the checks and balances in place can cause more trouble than they’re worth. That’s not the fault of “business process management.” It’s the fault of the people who put the processes in place, ensure they’re being followed, and carry out the work involved. In other words, everyone.
On the other side of the coin, there are untold numbers of success stories that involve business processes that work. We never pay attention to the things that go right; we only care about the things that go wrong. Never mind that the electricity stays on when you pay your bill, or that your car hasn’t been repossessed because the bank paid your check to your lienholder. We ignore these things because we take the processes for granted, and because they are someone else’s problem.
What do you do when the process is choking the life out of your work? You change it. I’m reminded of a story I heard in a computer science class I took a long time ago:
I worked for a shipping company for several years in the data processing department, and since I did a good job and my programs worked, I eventually got promoted to supervisor. My job duties included everything I was already doing, with some extra responsibility over the other data processing clerks.
One Monday I came into the office and my manager called me into his office. “John, we need to talk about one of your clerks, Bill. The computer says he has processed an average 24 large shipments over the past three weeks, and the minimum threshold for data throughput is 30 shipments.”
I knew he had been having some trouble at home with a sick child, so I didn’t push him to work harder. And I didn’t even know there was a “minimum threshold for data throughput.”
“We want you to let him go,” my manager said. I was shocked and tried to change his mind, but he had the hard data showing my coworker’s productivity.
A week later my manager called me into his office. “I see you didn’t let Bill go. I’m glad you didn’t because his output exceeds the minimum by a large amount. But next time, talk to me before you go against what I say.”
I couldn’t fire Bill. He wasn’t the problem. It was the program. Some programmer had made an arbitrary decision to set a default value for a variable to 30–the number of days in the month of June, when the code was written–and I changed it to ‘0′. The “minimum threshold” that my boss was talking about was the initializer for a counter that tracked all processed large shipments by a user. Since the code was testing for values less than that “threshold,” an exception was thrown. Someone had written a business process around the code, instead of the other way around.
I think the moral of his story is “common sense prevails.”
Posted in Enterprise, Process | No Comments »
