The executive team in your organization just decided on a new set of goals for the next few years, including a 20% increase in net revenue. A lot of things will have to change to make that 20%, including organic growth in sales to current customers and adding new customers, new products, and perhaps new markets. Marketing also wants to implement a new sales channel. Operations will have to support all of it, somehow. You know your current operating model can’t support 20% more activity as you’re already running at over 90%. New products might require new processes, which in turn will almost certainly require new or modified capabilities. Adding a new sales channel is worse, and will need a host of new processes and capabilities. You identify three separate problems you have to address: increase capacity for your current operations, implement production for potential new products, and implement support for a new sales channel. You note, with a bit of concern, that the problem isn’t as simple as just adding capacity; you need to add capacity to the right processes.
The problem is knowing where to start. Some of your many processes have more influence on overall capacity than others, and it isn’t just the bottlenecks in the production lines. The immediate task is to identify those processes and capabilities you need to change, then how you need to change them. The processes you identify will fall into one of two categories: those to which you can simply add resources, and those that need more investment to change the cost structure, or “flatten” the cost curve.
You notice, yet again, that any effort to change the business starts with a bit of troubleshooting — or diagnosis. Before a physician can treat a patient, the doctor must first diagnose the problem. A physician observes symptoms, listens to what the patient says, and applies his or her knowledge of medicine to reach a likely diagnosis, which the doctor tests. If the test proves the diagnosis wrong, the cycle is repeated. Diagnosis, like troubleshooting, is thus a series of experiments in which you observe behavior, develop an hypothesis, test that hypothesis, and repeat until a reasonable conclusion is reached. Skilled troubleshooters follow this observe-hypothesize-test-repeat cycle instinctively, repeating the cycle several times when they first encounter a problem to eliminate common but unlikely causes. This cycle is so common, it has a formal name, which is likely familiar: the scientific method.
Good troubleshooters can not only solve problems when they come up, they can also spot a major problem well before it becomes obvious. A good example is the chief engineer or engineer’s mate on a ship, who can tell by the feel, sound, and smell when something is amiss. Much like the way a physician knows medicine, the engineer knows a ship inside and out, and a troubleshooter in the enterprise knows the inner workings of that enterprise. Knowledge of a specific patient, ship, or enterprise is useful, but not required; a good troubleshooter can learn the details of a specific instance very quickly.
Troubleshooting is among the most valuable skills in an enterprise. Every enterprise has people with these skills; the hard part is finding them. Some people seem naturally skilled in troubleshooting, but those people are very rare. Troubleshooting can be taught, but to really learn it takes time and practice at the hands of a skilled advisor, so the supply of skilled people is always scarce.
Enterprise architects often find themselves in the perfect position not only to spot trouble before it occurs, but also to know how to fix it. Knowing how to troubleshoot, and being good at it, is thus a primary skill for an enterprise architect. In fact, troubleshooting may be the primary skill. As I noted earlier, every project an enterprise architect undertakes starts with a fair bit of troubleshooting. No exceptions.
As important as it is, troubleshooting skill is just one ingredient for solving problems. A practiced sense of observation and knowledge of how the enterprise works are also required. We will focus on the latter, since time is the only way to achieve the former.
To understand how an enterprise works, you must understand its plumbing — the set of links between processes, customer (and other stakeholder) experiences, and business outcomes. Processes do not determine either customer experience or business outcome; they only make it possible for a set of experiences to occur, which in turn make possible a set of business outcomes. The actual experience for a customer and the customer’s response depend on a lot of factors outside the enterprise’s control. Business outcomes depend on the responses of customers, the rest of the market, and the economy at large. At best, then, a process that directly delivers a customer experience can only influence that experience, but that influence can be positive or negative, and the influence of one process can be greater than another. Hence, plumbing.
The plumbing of a building only provides potential paths for fluids. Fluids can flow in either direction, and the size of the pipe limits the rate at which they can flow. Applied to an enterprise, the links are the pipes, the direction of influence is the direction of flow, and the degree of influence is the rate of flow. Unlike the plumbing in a building, however, you can’t measure either the direction or degree of influence directly. Rather, you have to surmise those values by watching how measures of the customer experience and business outcomes change as you modify processes.
Enterprise architects are in the best position to understand the plumbing because they may have designed it, participated in building it, or have had to modify it in the past. Architects and process owners develop a feel for how changes to a process affect stakeholder experiences and business outcomes, and many can express those effects in terms of measures, even very simple measures (e.g., process A has more of a positive impact on customer experience than process B).
The enterprise architect takes this knowledge, combines it with the desired outcomes (the 20% increase in revenue, in our case), and works backward through the links to identify the set of processes that might need to be changed. The direction and degree of influence point them to those processes that might yield the best results for the investment. This set is refined by repeating the process multiple times.
It sounds like a lot of work, and it is. But all you have at this point is the hypothesis. Since you can only prove an hypothesis wrong, common practice is to test the null hypothesis, the condition that is true when the hypothesis is wrong. So, the next step is to devise a test that aims to show that a process should not be changed and still get the desired outcomes; that is, a test that fails when the process needs to be changed. There are a number of tools and techniques to conduct these tests without actually making the changes, but we’ll save those for another time.