This week I was in Bologna and Vicenza helping launch the Italian edition of Operating Model Canvas.  The translation and funding for the Italian edition was provided by Kaizen Institute: who support companies wanting to improve their operations.  I was giving a presentation on the Canvas and toolkit.  There were also presentations from the Kaizen Institute explaining how they integrated the Canvas with their work on processes and change.  I wanted to share some observations and learnings.

First, the Kaizen approach is built around “value streams”: observe and document each value stream, imagine ways in which the value stream could be improved, try out the good ideas, then operationalize, then monitor and measure improvements.  The value stream focus of Kaizen is similar to the value chain focus of the Canvas.

Second, because the Canvas is looking at more than processes, it has been providing the Kaizen Institute consultants with a “whole system” way of understanding their client organisations and of explaining to their clients why they should be considering more than just process improvement.  Often process improvements are only possible if wider changes are made to the operating model and sometimes the improvements will only be sustained if reinforced by other changes in the operating model.

Third, the Kaizen approach exposed me to two aspects of what I call “management system” that I was previously aware of, but had not fully connected with management system.  The first is Hoshin Kanri, the process for “deploying” strategic ambitions through change projects. Companies, such as Danaher the US conglomerate, are devotes of Hoshin Kanri, using this management system to define “breakthrough” projects, set priorities and drive change. Clearly Hoshin Kanri is a part of “management system”.

The second aspect of the Kaizen approach that is part of management system is the upwards cascade of review meetings that starts with the daily team meeting of operators on the production line, then the daily meeting of shift or line supervisors to connect across teams, then the daily meeting of production managers, then the weekly meeting of functional heads including production and finally the monthly business meeting.  This upwards cascade helps correct issues speedily at the level where they occur, but also ensures that a small issue low down in the organisation that has a big business-wide impact is raised up to the business meeting, and does not rely only on more informal lines of communication.

This recognition that even the lowest level daily stand-up is part of the “management system” made me think about the management system of “agile”: backlogs defined by the team, product owners who prioritize the backlog, kanban boards showing the progress of items that are taken out of the backlog, daily stand up meetings, sprints, etc.  Agile is an operating model: it is an organisation structure (multifunctional teams or “squads” each part of a separate “mother function or chapter” linked together into a “tribe”) where the team members are co-located, typically operating out of one shared space, and everyone is guided by a management system, often called “scrum”.  So we have the work (backlog), the process (sprints), the organisation (squads, tribes, chapters and …), the location (one shared space), the information system (many visible displays) and the management system (backlog, kanban and scrum).  We are only missing the “suppliers” element from the Operating Model Canvas, which, of course, is very specific to the type of work that the agile team is doing.