Posts Tagged ‘operations’

The Tortoise and not the Hare 2 – Principles

January 24th, 2010

Kanban

In my first post I introduced you to the Toyota Production System and the Kanban signalling system. At the core of the TPS the concept of maintaining efficiency and eliminating waste.  To govern this processes the TPS has a series of basic principles that articulate how this achieved:

  1. Create continuous flow to bring problems to the surface
  2. Use the “pull” system to avoid overproduction
  3. Level out or smooth the workload AKA “Heijunka” – be the tortoise not the hare
  4. Build a culture of stopping to fix problems, to get quality right from the first
  5. Standardized tasks are the foundation for continuous improvement and employee empowerment
  6. Use visual control so no problems are hidden
  7. Use only reliable, thoroughly tested technology that serves your people and processes.

I’ve skipped all the TPS rules around long-term thinking (for example the first principle of the TPS – Base your management decisions a long-term philosophy, even at the expense of short-term financial goals), corporate harmony, people development and organisational learning.  I haven’t skipped them because they aren’t important but because they aren’t immediately relevant to this discussion.  If you haven’t got the others right too though I suspect your organisation will go pear-shaped in other ways.

In each of the subsequent posts I am going to look at one of the seven principles I’ve articulated above, starting with exploring how you can make continuous flow work for you.

The Tortoise and not the Hare – Part 1

January 2nd, 2010

production line

The production line one of the marvels of the industrial era. I've always been fascinated with production lines in factories and how a product, like a car, gets constructed from individual components and grows until finally it rolls off the production line as a finished product.  In the last few years I've been thinking more and more about production lines and how they overlap with IT .  So do they have anything in common?  Can you draw parallels between building a car and running an IT operation? Damn right you can!

Production lines construct assets from components and then sells these assets.  IT shops also construct assets, in the form of software, infrastructure and services.  These assets are also constructed from components to make a functioning whole and are then sold to customers.  The perfect example hosting infrastructure.  A host constructed from hardware (CPU, storage, networking), software (operating system, applications) and configuration data and then delivered to a customer for use (or "sale"). I'm going to look at the core principles of production lines, specifically some of the methodologies around their management, and see if they offer value in running IT organisations and . I'm also going to demonstrate some work flow and how to use some tools (like and others) to model these principles in your own IT shop.

The production line relies heavily and continuous flow to function efficiently.  The asset moves through the line having actions performed it or components added to it. The objective an uninterrupted flow from beginning to end with enough of the right components, processes and people being introduced at the right time.  Getting this production life cycle right isn't easy. As a result, the study and practise of production line management has become a science.

One of the most famous methodologies the Toyota Production System or TPS. If you work anywhere where important – and that's pretty much every manufacturing organisation and almost every large corporate (including banks, insurance companies, transport, logistics and a flurry of others) – then you'll probably have heard of TPS and one of its integral components, Kanban. The TPS a lean/Just In Time (JIT) production practice model.  Lean practises are ones where the focus the activities that deliver customer value.  Resources that are expended other activities are always suspect and targets for elimination.  JIT attempts to improve ROI ("Return Investment") by streamlining production , managing demand and hence reducing the amount of inventory ("parts") carried so that only the parts needed are stored and then for the shortest possible time before being consumed for production.

So where does fit in? a demand management and signalling system that uses physical signs to act as triggers between processes.  I've stolen a very simple example from Wikipedia:

"A simple example of the system implementation might be a "three-bin system" for the supplied parts (where there no in-house manufacturing) — one bin the factory floor (demand point), one bin in the factory store and one bin at the suppliers' store. The bins usually have a removable card that contains the product details and other relevant information — the card. When the bin the factory floor becomes empty, i.e, there demand for parts, the empty bin and cards are returned to the factory store. The factory store then replaces the bin the factory floor with a full bin, which also contains a card. The factory store then contacts the supplier’s store and returns the now empty bin with its card. The supplier's inbound product bin with its card then delivered into the factory store completing the final step to the system. Thus the will never run out of product and could be described as a loop, providing the exact amount required, with only one spare so there will never be an issue of over-supply. This 'spare' bin allows for the uncertainty in supply, use and transport that are inherent in the system."

Simple huh?  You can also readily scale this example by adding multiple bins (which each have their own card).  This allows tights controls stock management (and hence costs!). 

So can we apply these concepts to IT infrastructure?  Hang onto your hats because in Part II of this series of posts I'm going to do exactly that.

Are security professionals failing?

May 11th, 2006

Noam Eppel at Vivica has published a fairly damning indictment of professionals and what he perceives as our failure to combat threats. It’s pretty strong reading and I suspect it’ll provoke some powerful responses. At first glance many of his arguments do seem valid. I am not sure however how many of the weaknesses he demonstrates are purely the responsibility or within the ability of most professionals to fix. Truly getting an edge the threats out there may well be impossible but if it at all feasible it will require the cooperations of vendors, professionals, corporations, companies and other organsations but most important – the end user. professionals alone cannot be expected to carry the burden as well the banner.

Bad man

June 28th, 2003

I am a bad, bad man. I left poor Mefcon last night in the downstairs club at the Civic. Left him dancing like a maniac with this very strange but very pretty half-Korean/half-Japanese girl from San Diego. He was seriously out of his depth and given his weakness for women who look like anime characters it was going down hill fast. She was there with G – the very, very big guy from one of the outlying offices (6’8″ and built like the side of a fucking barn). I seriously hope that nothing was going because Mark was heading towards being smitten and G could tear a truck apart with his bare hands.