As of late, the IT industry has been peddling various solutions to understand, monitor or optimize that nebulous beast called “process.” So what is a process and why should every CIO be focused first and foremost on business process?
Most of us have seen the now overused IPO diagram: the three boxes arranged in a line, and connected by arrows like the boxcars in a train. The first box contains “Inputs,” which move into the next box titled “Process,” which subsequently flows into the final box, titled “Outputs.”
| Other Articles by Patrick Gray | |
|
Design for IT Death By Deliverables If you want to comment on these or any other articles you see on CIO Update, we’d like to hear from you in our IT Management Forum. Thanks for reading. – Allen Bernard, Managing Editor.
|
This diagram is a model of simplicity, yet exposes a flaw in current thinking. Two thirds of the diagram is concerned with inputs and outputs, placing priority on “stuff” rather than how we actually change one form of “stuff” to another. While a simplification that fits neatly into the world of flowcharts, in the real world we often focus too narrowly on moving and changing “stuff” versus why we are changing inputs to outputs, and determining how to efficiently and portably change that “stuff.”
Process is the “why” to any business problem. IT has embraced process more than most other business units, at least on a superficial level. We are familiar with how to diagram a process, and nearly all of the project methodologies provide a provision for capturing, diagramming and understanding the “as-is” process, or the current state of affairs, before we seek to intervene and bring about a new state of affairs.
We also have myriad tools at our disposal for improving a process, either by increasing its speed, efficiency, accuracy or repeatability, in the form of powerful technologies from ERP systems to entire process management toolkits and software.
What we often lack however, is the ability to separate content, the inputs and outputs, from the process itself, which has hampered the ability of IT to implement successful projects that deliver the business benefit they initially sought.
IT has been built around content, both in terms of hiring and developing its staff, and in how it approaches IT projects in cooperation with a business unit. We hire and evaluate people that are experts in a particular technology, which is just another content area. We then approach a particular business problem as an issue of content. Why are our competitors more efficient? It must be due to their ERP system. Why did a new entrant to a market outfox us? They must have better decision support systems, etc.
We see a business problem as one of bolting new technology onto existing processes, wrongly assuming that by changing the content of the process, the process will change as well. This can only be expected when we have built organizations around experts in a particular area of technical content, and business experts familiar with the rules and nuances (more content) of a process, experts in the “how” rather than the “why.”