Joe Cooper and Malcolm Neumeyer spoke about "Applying TOC to Enterprise Architecture: Gaining Focus". It was an education on EA and a nice view of the challenges they see in the discipline.
Sanjeev Gupta of Realization gave the opening keynote on the second day of TOCICO. The talk was billed as "The Rising Importance of TOC" but ended up becoming "Solving the Projects Problem: It's not about buffers or behaviors" based on his experience with years and years of CCPM software and implementations.
How do you think about embedding TOC and flow into everything you do? "Engineering Reality at WiseTech Global: Core Conflict – Friend or Foe?" from James Powell was a fun talk from someone who clearly enjoys the work he is doing.
The lunchtime keynote was "30 Years of Success: TOC & Throughput Improvement at GM" by Jeff Miller (GM) & Kevin Kohls.
Steel companies have been using TOC in a variety of formats for many years. The steel industry is even featured in the TOC Insights self-learning program that were created in the early 1990's. There were a couple talks at TOCICO from steel companies.
Yaniv Dinur presented some of the challenges experienced in work with a large engineering-to-order company, "Engineering to Order – engineering, procurement, and production in one flow."
The first official day of the TOCICO conference started with a keynote from Kaoru (John) Watanabe talking about the long history of TOC implementations at Hitachi, "Enterprise wide TOC Implementation at $83B Conglomerate."
First workshop of TOCICO18. I sat in on the Demand Driven: A Practical Workshop on The Strategy of Flow by Debra Smith - she's one of the long time experts on this topic from her experience creating the concepts of DDMRP and implementing with many clients.
I always love it when I read one thing that relates to something else I've just read and conversations I've been having with people. Thinking and routine must work together for any kind of growth to happen - the daily practice only changes on reflection, rather than in rote execution.
Too high work-in-process (WIP) is dangerous for all sorts of reasons in almost any organization. It slows everything down like the molasses in winter. But simply saying “cut WIP” without understanding why it remains so high is a recipe for disaster. Let’s think about this a little.
Our daily practice says more about ourselves than we like to admit. If my practice has me multitasking, there must be something about it I enjoy. Is it possible to change my practice? Of course, it is.
My review of Making Work Visible by Dominica DeGrandis. This is another entry in the books about Kanban and the value behind making work visible. In DeGrandis formulation, the focus is on removing the five "time thieves" she identifies early on.
I first heard the term VUCA (volatile, uncertain, complex, ambiguous) five years ago when I started working with a client that epitomizes this view of the world. It's one of those terms that, once explained, seem to describe the world perfectly.But isn't this just a way of looking at the world?
The TOCICO (Theory of Constraints International Certification Organization) is holding its annual conference in Las Vegas on the 29th April - 1st May with some pre-conference workshops on Sunday the 28th.
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - Stephen Hawking, who died 14 March 2018.
The goal isn't efficiency. The goal is getting the right things done.
Eli Schragenheim did a nice TOC ICO webinar the other day on the topic of buffers, "Time Buffers, Stock Buffers and Buffer Management – The Key Insights and Their Universal Use."
Evgeny Zislis has a great piece on DevOps Transformation using Theory of Constraints, where he takes us through the 4 Questions for Technology. The short version of the discussion is that it is far too easy for people to apply the tools and outward signs of <pick your poison> without fully taking the change on board. And as a result, the power behind that change is never fully released.
When bringing a new way of doing things to organizations, we often get enamored with the physical or technical changes that support the new way of working. Surely if we have this THING, then we must be doing THAT.
But does this really mean that we have changed?
Best practices often get a bad name. But if they ossify into "the way we do things around here" then it becomes very difficult to install new ways of thinking operating and working. Even with all the cool tehcnology we have at our fingertips, the way we work can block many things.