The Power of Process

As of late, the IT industry has been talking a lot about process, 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.” 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 the “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 where 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 an 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 tout.

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.

Bringing all of this content knowledge to bear creates overly complex solutions, pushing out project deadlines and kindling animosity between project teams and “the Business.” A fundamentally flawed process is recreated in another technical solution, new rules being layered atop the old to compensate for new exceptions, or the strengths and weaknesses of the new solution.

IT is in a unique position to tackle these business problems from a different perspective. CIOs are beginning to realize that the future of IT lies not in being a cheap internal provider, evoked only at the whim of another business unit, but that IT can actually generate value for the corporation through the projects it implements. Just as a coder who is strong in one programming language can rapidly pick up a similar programming language, a cadre of process-savvy IT employees can redesign a process in finance just as easily as they rework one in HR.

IT projects that traditionally pitched a technical solution to every problem can now approach a business problem without a preconceived technical solution by attacking the process first and foremost. Imagine reporting to the CFO that you increased the efficiencies of the supply chain by 5%, and also discovered along the way that the ERP package under consideration really would not dramatically improve the supply, saving the money and pain associated with a large-scale software implementation.

A naysayer might argue that IT would be stepping outside its traditional purview by looking at process as the primary lever of business problem solving, and using technology as the grease that moves the lever all the more quickly. Many companies undertake sweeping process improvement initiatives with armies of consultants and internal resources with titles that make them sound more like ninjas than process gurus. Most of these initiatives tackle the same problems as past IT implementations, and often result in a recommendation to implement some kind of technical system. Would it not make sense to combine the two disciplines, turning IT into a cadre of process experts that also has access to a complete technology toolkit?

IT is already in the unique position of touching every business unit, with established contacts, relationships and expertise across the corporation. Most IT shops already have some level of process competency, and are generally quite accustomed to working in a project environment and all that it entails. As ongoing IT operations transition to low cost internal support organizations, or are outsourced, a process focus provides new relevance for IT, leveraging areas where it already excels and trading its content baggage for an unrelenting focus on process.