by Kathleen Melymula

Has IT process standardization gone too far?

News
Mar 9, 20097 mins

The move to standardize 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 and director of the Center for Digital Strategies at Dartmouth College’s Tuck School of Business, told Kathleen Melymuka why artistic processes are essential in IT and how to know when you need one.

Why do you say that process standardization has gone too far? CIOs and B-school faculty have been promoting process standardization as the road to the promised land. And there’s a lot that’s good about that. But we began to notice that there were cases where standardization went awry because we standardized a process that required more variability and flexibility than we were allowing. By standardizing, we ended up in a worse place. That whole idea was the genesis of this article: When and how does process standardization go awry? We’ve all seen cases where stuff got standardized 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 standardizing that process will shackle competitive advantage.

When IT puts its eyes on a customer-facing system and starts thinking of standardizing 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 U.S. 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 organization, 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 standardization. But standardization 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 organization. A brand-new business in the context of a large enterprise can be killed off by process standardization. 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 standardize it, you may be shackling it. Smart companies will take steps to avoid that sometimes. They know the standards of the enterprise many times are fatal.

But there are counterexamples. When a firm acquires a business, sometimes it’s best to standardize 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 standardize. Cisco is famous for bringing new businesses into its IT systems very quickly and standardizing 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 standardization 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 standardized process because speed is the objective. But you may need special processes for people working with executives who are traveling internationally, and 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 that executive in Asia really has a simple e-mail problem, so then he goes back into the standardized process. We call this drawing the line between art and science, and 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 standardization, 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 folks who understand not just IT but also the business, and [they] understand when you can standardize and when you need variability. Training those people means immersing them in the business so they can help the IT organization better deliver projects that match the organization’s need. That kind of training requires more of an apprenticeship than some other types of training. You might stick them into a marketing organization and have them actually be a marketing person for six months or a year — or HR or the CFO’s organization — 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 standardization is good in many places. Diffusion is when the freedom of the artist begins to get incorporated into a lot of places in the organization where you don’t want that. In the CIO’s organization, there are plenty of folks 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 very 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 center for e-mail problems, I need to stay on script. I’m not an artist.