The move to standardise processes has gone overboard, say M Eric Johnson and Joseph M. Hall in this month's Harvard Business Review. Some processes, they argue, are more akin to art than science and need to be treated that way. Johnson, a professor of operations management at Dartmouth College, says artistic processes are essential in IT and explains how to know when you need one.
Why do you say that process standardisation has gone too far? CIOs and B-school faculty have been promoting process standardisation as the road to the promised land. And there's a lot which is good about that. But we began to notice there were cases where standardisation went awry, because we standardised a process that required more variability and flexibility than we were allowing. By standardising, we ended up in a worse place. That whole idea was the genesis of this article: when and how does process standardisation go awry? We've all seen cases where stuff got standardised that shouldn't have and it stifled innovation.
What is an artistic process and when might one be needed in the IT environment? When we say "artistic process" that language seems a little flaky, especially for CIOs. We define them by the way they operate. That is, an artistic process has to operate with lots of variability in inputs to the process, how it operates and in the outputs — and that variability is viewed positively by the customer. That's critical. If customers value variability in output, then standardising that process will shackle competitive advantage.
When IT puts its eyes on a customer-facing system and starts thinking of standardising that system, it should first ask the question, "Is this process one where customers value variability"?
Can you give me an example? Maybe the way you operate in France is different from the way you operate in Italy or the US. If you try to roll out a standard process, you may be destroying potential value for the firm.
How can an IT manager identify which processes should be science and which should be art? It's really all about whether the customer values the variability. As a CIO, you need to think about end customers and also customers in the organisation, and how both are valuing what you're doing. If the business requires more flexibility, then there is some value in variability and you have to be careful about process standardisation. But standardisation often makes tremendous sense in back-end processes.
You write that new processes often start as artistic and then settle into scientific. How does a CIO manage that? We see that when CIOs interact with innovative new businesses that spring up within an organisation. A brand-new business in the context of a large enterprise can be killed off by process standardisation. A CIO can look at that and know it's much more "artistic" — in quotes. We're not saying they're all poets — just that it requires more flexibility and variability in the ways it operates. The ways a new business goes to market can be changing over the first six to nine months, and if you try to standardise it, you may be shackling it. Smart companies will take steps to avoid that sometimes.
But there are counter examples. When a firm acquires a business, sometimes it's best to standardise those processes and bring them into the enterprise, because though it may be a new business for the enterprise, it may be reasonably mature and ready to standardise. Cisco is famous for bringing new businesses into its IT systems very quickly and standardising a lot of processes as a result. But it didn't do that with everything. With Linksys [home office systems], for example, Cisco left a lot alone because it's a consumer type of business that required more "art".
How should an IT manager measure the success of an artistic process? One of the key things we argue is that artistic processes create variability that the customer values. So if that's true, then you have to measure from a customer viewpoint and get real feedback from customers. You can convince yourself that customers value all kinds of things they really don't care about, and variability can really be kind of annoying to them. So you always have to measure from a strong customer-feedback point of view.
How does this work in practice? Take a CRM system. I know from lot of history that customers care about how long it takes to answer a question. I'm the CIO, and I'm doing a bunch of standardisation to speed that up. I don't have to survey customers to ask if they're getting happier. I know that reducing the time will make them happier.
But if it's more of an artistic process, where they're valuing more variability in outcome, I need to be talking to and understanding the customer and getting good feedback.
You write that artistic and scientific processes sometimes work together. Can you give an example? On an IT help desk there are a lot of examples. Maybe some customers with a very straightforward type of question can be triaged into a very standardised process because speed is the objective. But you may need special processes for people working with executives who are traveling internationally. They may be on different platforms and have different problems and wouldn't be so happy with the standard help desk process.
And sometimes through triaging, you find that the executive in Asia really has a simple email problem, so then he goes back into the standardised process. We call this drawing the line between art and science, where you have to know when to toss people back from one to the other.
You can see it in IT projects: there are parts where you're doing certain configurations or coding and you want a lot of standardisation, but where the process architects are bringing together the pieces, there's a lot more art in that.
How does an IT manager train people to perform an artistic process? Artists are people who understand not just IT but also the business, and [they] understand when you can standardise and when you need variability. Training those people means immersing them in the business so they can help the IT organisation better deliver projects that match the organisation's need. That kind of training requires more of an apprenticeship than some other types of training. You might stick them into a marketing organisation and have them actually be a marketing person for six months or a year — or HR or the CFO's organisation — and have them spend time and come back with that knowledge. That gives a deeper appreciation for when variability is needed.
What is "art diffusion", and why is it dangerous? We're not denying that standardisation is good in many places. Diffusion is when the freedom of the artist begins to get incorporated into a lot of places in the organisation where you don't want that. In the CIO's organisation, there are plenty of staff you don't want [getting artistic]. If your job is coding or monitoring the firewall, you want good standards and you don't want them making it up as they go along. Often, when you go to young start-up companies, they are very artistic, and pretty soon everybody feels like they're an artist, even if they're in accounts payable. You don't want that kind of feeling. So you always want to draw bright lines between what really is art and what is not. If I'm in the call centre for email problems, I need to stay on script. I'm not an artist.