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 Avoiding the Axe Death By Deliverables
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."