The rise of IT-industrialization

A few days ago I attended the analyst summit of one of Europe’s large service providers and the theme of industrialization rang through very clearly in many of the presentation and interview sessions. Those of you who followed my earlier writings know that applying the lessons of modern manufacturing to today’s IT, is a topic near to my heart.  Back in 2004, long before joining Gartner, I wrote an article on IT-dustrialization in CFO magazine , followed by many blogs, later bundled in “Lean and the art of cloud computing management”. At Gartner IT services industrialization is covered in my area under the topic of IUS (Infrastructure Utility Services) and I am currently working with two of my European colleagues – who have been covering IUS for several years – on a market map and compass for this IT industry area.

But, as mentioned earlier publishing in many cases precedes (best) practices, so it was refreshing to see how the ideas of industrialization were very much present during the mentioned analyst day. It would go too far (also given our blog policy) to list the whole story here, but let’s look at some of the more interesting bits and sound bites.

In a very open welcome talk, the CEO acknowledged that maintaining quality is one of the hardest things when moving to a more industrialized production method. To me this sounded a lot like the problems that the Japanese car industry faced when first importing into Europe. The cost of their cars was significantly lower, but they came with a quality level to match. Now we all know that in those years Dr. W. Edwards Deming made his first visits to Japan, introducing statistical analysis and simple tools to apply quality control at all stages, and the rest is history, with Japanese quality for many years matching or even exceeding global quality (Later the Deming circle formed an important foundation of other best practice movements in both manufacturing and IT).

The several ten thousand strong production department of this provider went through a similar transition. All staff was immersed in (on-line, multi-media and in person) training programs and  processes were defined and orchestrated to an extent comparable with the ballet-like orchestration you see in modern factories. Comparing itself with internal and external benchmarks was made a way of life and statistical measurement tools were applied widely. Inspiration for much of this came from conversations the head of production of this provider had with his customers: large manufacturing organizations employing several hundred thousands of factory workers with a high focus on product and process quality. (Note: Don’t mistake the term factory worker we use here for the traditional blue collar versus white collar division of labor. Today’s factory workers are often higher educated, better trained and in many cases even better paid than most clerical white collar jobs, while the production activities they are responsible for are more automated and supported by more robot technology than most regular office – or IT – work).

But in IT, even more than in manufacturing, changes are a major enemy of quality. And with the type industrialized scale we are talking about here that means that thousands or even tens of  thousands of change requests are to be applied each night or weekend. In manufacturing it is nowadays best practice that any factory worker can stop the production line when he/she feels quality is somehow at risk. But – as availability is one of our primary definitions of quality – stopping the line, a.k.a an outage,  is exactly what we don’t want to do in IT . So in this case a best practice from the airline industry was applied. Any change has to be checked by 4 eyes before being implemented into production. In other words, it has to be reviewed by at least two people, call it the pilot and the co-pilot. An intermediate step that at first may seem expensive – just like most people in the eighties felt it was crazy to have any worker be able to stop a multi-million dollar assembly line – but that in the end reduces overall cost. Also because doing things right the first time is – over time – always cheaper than incurring rework, penalties and other cost of non-quality.

But industrialization goes further, also for the customer who is at the receiving end of these industrialized services.  In this case the CIO of one of the global customers of this provider gave his insigtfull perspectives on the changes the industry is going through. Again a couple of soundbites.

This CIO is driving his organization toward obtaining “anything as a service”, which eventually – as he put it – enables CIO’s to separate the I from the T (allows focus on the Information, not the Technology). For providers this means moving from delivering traditional system integration projects, to standardized products that are delivered as a service. This change does not only impact how it is delivered, but also how it is procured. Again a car analogy. When this CIO was to order a new car, he did not go shopping around; he did not even test drive his final choice. As he had a history of good experiences with this manufacturer, a rough idea of the type of model he wanted (eg. 4 door sedan, no MPV, no SUV), and a number of minimum requirements (think of automatic, diesel, navigation), he basically picked the car unseen, as he knew it would be “good enough” for his requirements. I would classify this as a mature buyer in a mature market. Where the immature buyer will shop around, go on test drives in many makes and models (including in two door models he is not even allowed to order as a company car) and from manufacturers he may have never heard of, the mature buyer knows what he wants and rather spends his valuable time on stuff that really matters (in business terms: on activities that differentiate the company).

At this stage the market has not many mature buyers yet (even for cars, I know because I just selected mine and that took me more than a couple of calls). But mature buying also requires a mature market. In the car industry, buyers know that most of the major brands now deliver high quality and reliability. While the brands that did not reach that trusted status yet, offer warranty periods that even Charles Deming could only have dreamed off. It is this kind of trusted quality level the industry will need to reach.
As for cost, also there the ambitions and expectations are high. As Adam Smith showed in his wealth of nations, a traditional craftsman might manufacture one pin a day. A pin factory, however, created 48,000 pins a day using ten men. In the light of what Taylorism and scientific management did in manufacturing, the voiced ambition of reducing IT cost by 90% seems a lot more feasible. Especially when realizing that in some of today’s on-line “factories” (i.e. consumer web shops) the cost of an IT item already might be 1/10 of the TCO based cost that IT departments charge in their internal catalogs of IT services (and when procuring things as a service there is no “ownership”, so also no Total Cost of “Ownership”, although there may be other governance related cost).

I’ll finish off with a last (car) anecdote from this CIO: When Karl Benz and Gottlieb Daimler originally estimated the size of the overall addressable car market, they came to about 1 million cars (which is about as accurate as the max of 5 computers that Thomas Watson once arrived at). But more interesting than the overall number is the way they arrived at it. As there were no available statistics on cars, they estimated the number of households that would be wealthy enough to afford a chauffeur.  We now know that overwhelming majority of cars are bought by users who drive these cars themselves. When extending this to IT, the idea would be that future CIO’s would be like today’s chauffeurs, the people that drive IT in a very small set of special cases, while most of IT would be “bought and driven“ by users.  An interesting idea, let’s hope IT-industrialization can drive the required maturing of the supply side fast enough to be ready for this scenario.

Any comments/questions send me a mail at gregor.petri at gartner.com.