Which came first, the chicken or the egg? This question has haunted ancient philosophers for centuries, and as of now, there is no concrete solution.
When it comes to dealing with processes and tools, a similar quandary exists. Processes and tools go hand in hand, so the question again is which one comes first?
Interlocking of processes and tools
First, let me lay out the items that I'll deal with in the course of this piece.
A process is defined as a set of coordinated activities performed to obtain a targeted output. For example, to clean a car, the first step is to rinse it, wipe the body, and finally dry it. So, these three coordinated activities are basically achieving a single goal — a clean car.
A tool is an instrument that is developed to carry out a particular function — like a drill for drilling a hole. In the clean car example above, I could use a tool like a water pump to help me rinse the car with a flick of a button.
But what if I use a tool like a pressure washer? This tool has the potential to modify the existing process of car cleaning.
The burning question is do you define the process and then hunt for a tool or obtain a tool with capabilities and develop processes around it?
Let's consider both cases.
Tools first
Technology is ever evolving, and with tools resulting from technology, one can argue that tools must lead the way for the activities we perform.
Let's say that a company called TLS finds a particular tool useful, and although the tool doesn't serve their intended purpose one hundred percent, it's somewhat helpful and could come in handy when implemented full force. So the company goes ahead and procures the tool and then modifies the processes to meet the tool's needs.
The company changes some expected outputs to suit the tool's needs. The output starts to appear, just as they envisioned with the revised process.
Process first
A process is developed, without the aid of technology but with analytical reasoning and a good understanding of the objective it's trying to achieve.
PRC, a competitor of TLS, is made aware of TLS's new tool acquisition. PRC sits back, examines their processes, and maps it with the new tool. They don't like the possible adaptation.
They back their processes and shop around for a tool that will also back their process. They come up with a tool that doesn't have state-of-the-art technology. The developer is willing to customize it to their needs. The two parties agree, the customized tool is procured, and the output starts to pour in.
Compare the two approaches
TLS believed in technology, but tweaked their processes to suit the tool on hand. PRC, on the other hand, trusted their process and sought after a tool that could do what they wanted it to do.
TLS compromised their process for technology. PRC stuck with their process and instead compromised the tool's original configuration to suit the process.
Which is a better approach?
Remember what I said earlier: Processes are a set of coordinated activities that will achieve the goal you want to achieve. A tool is a means through which certain functions are carried out.
What counts is the end result, and the process's existence depends on the output it delivers. If it's a home run, it's all well and good, if it doesn't matter what tools were employed. But compromising a process, in the sense that the basic output could be altered, is a scary prospect.
PRC backed their processes and got the tool configured to their needs. They got the best out of both worlds. On the other hand, TLS had to do away with certain process configurations to fit the new master –the tool. PRC's approach is the right way to go about integrating process and technology.
Tools are meant to complement the process by enabling the process activities to be performed as per the design, and never the other way around.
But tools are important
I can't think of designing a process without understanding the capabilities of tools. I'm very much a tools person. But the tools listen to my design, and I don't succumb to their way of working.
It's important that while designing a process, you have a good awareness of what kinds of tools and capabilities are available in the market. That gives you a good starting point. Design the process keeping the objective in mind, but optimize the activities with the available tools.
Tools are undoubtedly vital; a process developer must exploit every aspect of the available tool and perhaps stretch it to imagination — and have it customized to complement the developed process.
How does a process consultant do it?
I have worked independently and with teams of process consultants in developing several processes for ISO 20K, ISO 27K1, and PCI DSS. So I can give you a fairly good idea of how a process consultant sews processes and tools together.
There are specific objectives that a process must achieve. The inputs, budgets, and other service-level requirements are in our possession before we start defining a process. Apart from this, we are aware of what the tool world has to offer.
The inputs are known and so are the expected outputs. Filling in the blanks with process activities is all that we do. Let me illustrate this with an example.
If you want to bake a veggie pizza, you know the ingredients you probably want — like a pizza base, sauce, cheese, olives, and tomatoes — and you know what this pizza looks and tastes like. The steps you take to prepare the pizza are like the individual process activities. The activities you do in order to make a pizza are coordinated — you pre-heat the oven, apply the sauce on the base, apply the cheese followed by vegetables, and then add more cheese. Then you put this in the oven for ten minutes to complete what you had on your mind. The output is just as you expected, and the oven served as a tool that enabled the process activities to be effective.
Summary
A process must always be the boss and lead the tool to its expectations.
build-access-manage on www.dayaciptamandiri.com
