You know, I like a sexy powerpoint presentation as much as the next person, with nice graphics, well-thought out visuals, and chewy data. I’m a fan of Tufte, and of McLuhan, and always looking to better how I convey information. But there’s a problem which lurks in supply chain improvement efforts, and my team has to stress over and over to ‘the beginners’: the point of the project is not to create beautiful models, but to improve business performance.

In a good supply chain program (continuous, or discrete) at some point in the program we will probably work with a supply chain process model, an organizational model, probably an Enterprise Architecture model, and other representations of data about how the organization operations. Focusing on the Business Model of our program, we use diagrammatic models (Rummler-Brache usually), and as well as narratives, organized around our standard frameworks (SCOR, and so on). But the model is an ‘artifact’ as they say. The team has worked with business counterparts to understand how operations really work, successively refining the model and using it to reflect agreement from various participants that it ‘works’. It is like publishing the minutes of a meeting, and getting voting agreement that they’re accurate. The purpose of the business meeting wasn’t to create minutes!

A good model-creating process has: meetings together of people who use/own the processes, a way to communicate information about the model content, a way to get agreement, a conflict resolution, a sort of ‘research’ cycle. In the end where you might have had siloed processes of independent teams, you should find that you have a team who sees their work end-to-end, understand the reasons for work, material, and information flow, and understand their needed service levels. The model can be used to initiate a new cycle of change later, speeding up ‘level setting’ for the program.

A bad model-creating process has: groups of supply chain people who independently interview and collect process information, ‘closed door’ ratification of the model content, no process to handle disagreement on the model content, and no level-setting on definitions and cross-team information. Siloed teams can remain siloed, and the end-to-end view is lost. Few participants feel like they ‘own’ the outcome, and it may be rife with mistakes. Using it to seed new cycles of change are fraught with problems, and change management programs can fail, leaving the entire organization with no confidence in a Center of Expertise (COE) team.

Now, nobody is perfect – it’s not always easy to get entire teams together to review, and you may not always get everybody to agree, but information is being distributed and created to a high degree.

What are some symptoms of the supermodel obsessed?

  1. Modelling Tool Religion. I’m all for having everyone use the same tools to make it simpler and more efficient to create and distribute information, but at a certain scale, just go with what works. Not everyone has to be in the religious group. If you’re spending more time trying to get everyone to use a tool than to discuss business activities, then you’re in a rut. Have a couple of people be tool experts, and everyone else expert with the whiteboard and a marker.
  2. Frameworks Religion. Many people barely believe their ears when I advise abandoning frameworks at certain points in a project. As with modeling tools, the purpose of the project is not to use the framework, the purpose of a project is to solve business issues. If the framework is unnatural, wing it. I’ve seen many hung-up projects where everyone is being forced to learn SCOR or some framework language. Focus frameworks with a few experts, and let the business use more natural language. If the framework works, they’ll adopt it quickly.
  3. Russian Dolls. A Level-1 model. A Level-2 model. A Level-3 model. Then Level-4, Level-5, Level-… 1000? I’ve had frightened team members come to me with vast, complex documents almost in tears wondering ‘when to stop’. I usually advise: when the main questions are answered. Well, not meaning to be sphinx-like, I clarify: set the scope of the program, and keep any model development within that scope. If you’re not configuring SAP, then you don’t need level-5 workflows and such. We developed a rule of thumb: if there is an ‘if-then-else’ flow, you’re probably too far into workflow and not process. Stop!
  4. Spaghetti. Spaghetti is like Russian Dolls turned inside out. It happens with analysis, metrics, and enterprise architectures usually – incredibly complex, spidery diagrams of entire hierarchies flattened out. Really, if you’re dealing with more than a handful of key metrics, or cause-effects, or systems the business loses the ability to understand anything. The purpose is to understand and make decisions: if the business can’t make a decisions it’s wasted disc space.
  5. Powerpoints preceding program documents. A well-written program document with key features like scope, participants, process narratives, ideas, analysis and so forth, should be summarized into a presentation at some point for review. But I want to see detail and facts first, not sexy slides. Newbies will try to powerpoint because they feel it’s more important. Correct them!

Some of our best programs never had published models – they existed as intermediate program elements, and were re-used in other areas, but the program outcome was a series of  benchmarks, detailed process performance analyses, recommendations, project definitions – but no models to be seen! The implementation teams then took specific models and used them as input for detailed requirements, workflow, and configuration parameters, but again, the output was change, not more models.

If you want to present models, I suggest:

For C-Level, and Senior-VP levels, go no further than “Level 1” models to convey program scope. Level 1, in SCOR for example, speaks only to high-level business-to-business interactions around “Plan, Make, Source, Deliver, Return”.

For VP levels, Line-of-Business owners, go no further than specific “Level 2” models to convey varying business complexity. Level 2, in SCOR again, speaks only to variants on manufacturing complexity – build-to-order, build-to-stock, and retail, and so on.

For Director and Manager levels, go no further than specific “Level 3” models to convey general process steps. Level 3 in SCOR speaks of specific, generic tasks to execute “Delivery” for example.

Keep models to the minimum. Just the facts ma’am.