/kevinbehr/home

When asked to improve, what is ITs obsession with the dream of total automation of everything?

Is it the ultimate exercise in black-and-white thinking? Given the reality of countless failed automation efforts marked by dead-bodies, is there a better middle road?

This basis of my ensuing posteriori-logic-trap becomes especially apparent when one begins to peel away at the thin veneer that obscures the complete failure of IT at large to operate in the realm of the scientific method.

In my dictionary, automation merely consists of  defined practices, values and expected outcomes committed to code. But I have found that in the crucial connective fascia between; Project Management, DEV, QA and Ops, IT often lacks substantive specification, accurate documentation which often yields non-deterministic untraceable outcomes (action x and y caused effect z).

Ok, this may be a pretty harsh statement, but one that is borne out of over 20 years in IT, working with hundreds of IT organizations that struggle to accurately articulate either the goal or the definition of IT operations.  If nearly every implicit destination defined below those two map coordinates is off by even single digit percentages and we consider the length and breadth of the IT journey, not to mention the height of the weeds we can get caught up in, well let’s just say chronic ITFAIL pain is both aft and on the horizon.

In the great book, Why Smart Executives Fail: And What You Can Learn from Their Mistakes the classic story of GMs “must replace labor with robots” fail is told in brutal hindsight.  The lessons are clear but are an order of magnitude harsher when one considers the lesson that history has now taught us.  Not only was the money they spent on those automation efforts lost to their deficient consitency of practice (automation just accelerated their rate of failure) but they could have purchased Nissan, Toyota, Honda and maybe even Mazda with the money they squandered on robots.

Only after years of trial and error have manufacturers struck a balance between automation and human involvement.  Shigeo Shingo, the first person to document the Toyota Production system author of many amazing books including, Kaizen and the Art of Creative Thinking - The Scientific Thinking Mechanism, formalized this approach by refining the Japanese concept of Jidoka or Autonomation.  Simply put, Autonomation is automation with human intelligence.  This is the direction we need to explore in IT for our command and control systems.

To help define just where the intersection and labor divisions should best occur there are several Toyota Production system terms that are worth investigating as a path to improving your shop’s performance

Muri - Overburden - Is every day an exercise in futility? The email piles up the issues escalated, phone calls from execs, standing daily or weekly outage conference calls? Is your IT organization behind or stuck on projects?  How many of these precious business projects are missing their commitment dates, over budget, under resourced because your team is overwhelmed with unplanned firefighting and drive-bys?

Mura- Inconsistency - Routine tasks and changes are like roulette with a two out of ten ending in unexplained failure that consumes your brightest staff for hours or days?  Is patching or upgrading a fearful event which is marked by all knocking on wooden or even wood veneered objects and the presence of a shaman or holy person to ward off evil fail spirits?

Muda -Waste-All of those operating expense dollars lost to firefighting, audit corrective action drive-bys, shadow IT projects, unauthorized changes and root cause analysis meetings that take weeks to recommend the same trifecta of we need more budget, more staff and more time to focus on proactive tasks?

Right now many IT organizations are looking at Muda or waste in order to drive down costs.  I posit that understanding Muri and Mura would be a much more valuable use of time and ultimately will reduce waste and increase IT throughput

Inevitably the solutions recommended by IT teams to these issues will involve automation or tools.  This is not all bad, but the focus should be on building more deterministic ways of working for humans and considering where automation may help humans interact with their IT infrastructure more consistently.

This process of self reflection or Hansei is important fuel for Kaizen (continuous improvement).  It becomes essential to distill all of the undesirable symptoms of overburden, inconsistency and waste and understand the few root causes that drive them all.

Did you know that the “Just In Time’ concept was pioneered by a group of Toyota Employees? These Toyota team members were lead by Taiichi Ono on a trip to the US in the 1950s to visit US auto manufacturers .  They journeyed to Michigan and walked through Ford plants and were generally unimpressed by the high amounts of inventory they required to operate and the variance in labor output from day to day.

During the visit they stopped by a Piggly Wiggly grocery store and were amazed by their inventory replenishment system that only requested new items when they were sold. From this focus on Kaizen and Hansei they developed what later became the famous Just-In-Time philosophy that has become a pillar of the Toyota Production System.

It is not merely enough to improve in this economy, we are faced with the imperative of only improving the most important functions so as to quickly improve execution and IT throughput. As we set out on our journeys and investigation of other practices let’s make sure we are attacking true root causes of overburden and rework not just merely their undesirable effects.

I think that the Toyota Production System offers us many valuable insights in to building better IT. I find the thinking behind the system to be more enlightening than the practices. I encourage you to view all TPS, Lean and “Best Practices” in this light. Often the answer to “why” is more important than the “what” IMHO.

I will be writing more about the intersections of TPS and IT.  I will be focusing on universal principles, that draw from Goldratt’s Theory of Constraints work, Steven Spear, Taiichi Ohno, Shingeo Shingo, Deming and the 10 years of research Gene Kim and I have done around IT high performance, in the coming weeks.

You can download the PDF of the article here.  This is a great overview of Visible Ops for execs.  If you want to talk to your boss about adopting Visible Ops, ITIL or just some of the concepts in the book. This document is nice and portable and has pretty colors (hint: execs love color).

If you are interested in improving your IT organization’s ability to focus on and complete planned work, such as projects and proactive info sec work, feel free to contact me here to find out about the workshops, benchmarking and briefings I do to help get folks started!

George Spafford has built an amazing resource with his Yahoo news group.  Read by executives in; audit, IT managemnt, the C-suite and consultants world-wide he provides some great information and links thought-provoking articles.  Highly recommended!

Mich Kabay wrote a very nice review of Visible Ops for Network World. 

He also wrote a great review of Visible Ops Security edition.

It’s 1999 about seven o’clock on a rainy evening and Gene Kim and I are sitting in the corner at Pazzos in Portland Oregon. By now the windows are fogging we are on our second or maybe fifth round of Widmer Hefewizens. Our voices are very animated and we are getting more excited by the minute. I remember feeling like I had met my mental twin.What were we talking about? Mostly about how screwed up IT was as a corporate function. Management made little sense at times. We traded IT disaster stories and even what we thought were some solutions. I parted feeling like I had made an important friend but not knowing where the friendship would lead.

Little did I know the significance of that evening in terms of the research projects, books and breakthroughs we would spearhead as a result of our friendship and collaboration over the next decade. We were put together by a mutual friend, Jon Speer. Jon felt like Gene and I spoke the same language and felt we needed to meet. Thanks Jon, you were dead on!

Over the course of several meetings we performed many brain and book dumps on each other. We both described the work we were doing for our respective CEOs and found a important vein to begin working on together.

In both of our day jobs we had customers that were stand outs because they behaved differently and spoke a different language. In my business these clients were more profitable and required less man hours to support. In Gene’s business these customers were using his software (Tripwire) for operations as opposed to security. We began to study what we suspected were high performing organizations and see what made them so radically different than the others.

Two years passed and we progressed from suspicions to deeply held beliefs and developed what is now known as the Visible Ops methodology. We found four areas of focus that separated these special teams from the rest. We normalized all of their self derived playbooks and terminology back to the common parlance and taxonomy of ITIL. We then laid out an easy-to-follow approach to stemming IT chaos and firefighting with four simple projects. After completion of the methodology we co-founded the IT Process Institute to continue our research work and teamed up with George Spafford to write the Visible Ops Guide.

Since the publishing of Visible Ops it has sold nearly one hundred thousand copies. The second book in the series “Visible Ops Security” is selling very well. Our empirical research and benchmarking has helped hundreds of IT organizations answer the questions of “where should we start?” when it comes to process improvement and ITIL adoption. We have isolated the 80/20 of IT controls and processes and know just what high performers do to get their amazing results.

Over the last decade Gene and I have spoken at dozens of conferences, hosted countless roundtables with CIOs, CSOs and Chief Audit Execs, consulted CIOs, VPs, taken interim executive roles, consulted large IT turn-around efforts, written dozens of articles and benchmarked hundreds of IT organizations. It has been an amazing ten years but I am most excited at what lies ahead. We have not only proven our deepest beliefs and confirmed our restless suspicions but we have done it with empirical research and science.

In the next blog entry I am going to examine a topic all too familiar to IT executives and staff. It is the “hidden sucking sound” present in all IT shops whether large or small. High Performing shops have much less of it and manage it very carefully. What am I talking about? Unplanned Work. You may not know it by this name but if you have worked in IT you will recognize this all too well.

till then-

kb