Can Lean, Blockchain, and Systems Thinking Be Combined?

Back in June,  Machiel Tesser co-authored and published a book entitled Lean Blockchain Systems Thinking: Reinventing Value Streams with John Dennis. This book shows that blockchain, together with Lean and Systems Thinking, can provide multiple advantages for societies and the environment and can be used effectively to meet sustainable development goals (SDGs).

When I spoke with Machiel in July, I asked him: “What are the benefits of combining Lean, Blockchain, and Systems Thinking?" Here is his complete answer:

Blockchain and Lean: Building the Lean Internet

Blockchain and Lean are a match made for the modern era, creating a Lean Internet. Where Lean empowers us to eliminate waste and streamline value, blockchain goes a step further: it prevents waste before it even arises.

Lean lays out the philosophy and methodology, while blockchain delivers the digital toolkit: digital identities, verifiable credentials, automated rules, workflows, and consensus on standards. This makes processes instantly verifiable, compliant with regulations, and building blocks for an intention economy.

What was once theoretical is now tangible: in the U.S., the GENIUS Act is shaping a robust framework for stablecoin issuance and programmable finance. In the EU, MiCA and eIDAS 2 have come into full force (since December 2024), providing regulatory guardrails for digital assets and trusted digital identities.

Now, blockchain and crypto aren’t speculation or hype; they’re legally programmable and digitally enforceable.

Lean workflows in Real-Time

Workflows become pull-based and real-time, backed by quality proofs from the source, just like Lean Kanban: only what’s needed, when it’s needed. Smart contracts automate verification and trigger actions instantly, eliminating manual or paper processes, reducing errors, carbon emissions, and admin overhead.

Continuous, Network-Wide Improvement

Direct feedback loops and transparency cultivate a shared understanding of the network’s intent. It brings stakeholders onto the same page who are willing to improve the system rather than just their own parts. 

Identifying and solving problems together aligns perfectly with the continuous improvement ethos of Lean. By making performance and objectives visible, stakeholders can respond quickly and collaboratively, making progress proactive rather than reactive.

By targeting root causes, not just symptoms, and listening to every voice across the network, this approach shifts us from reactive fixes to proactive systems design. It’s an inclusive, holistic transformation: the true promise of a Lean, a programmable internet, reinventing value streams.

Do you agree with Machiel's perspective? Has blockchain been integrated into your Lean initiative? If so, what have been the results?

Developing Lean Processes -- What are the Common Mistakes?

Just this month, Matthew J. Zayko and Eric M. Ethington published about Lean process development entitled The Power of Process: A Story of Innovative Lean Process Development, which explores Lean Process Creation and teaches the specific frames -- the 6CON model -- to look through to properly design any new process while optimizing the value-creating resources. The framing is applicable to create any process that involves people, technology, or equipment—whether the application is in manufacturing, healthcare, services, retail, or other industries.  The result is 30% to 50% improvement in first-time quality, customer lead time, capital efficiency, labor productivity, and floorspace that could add up to millions of dollars saved per year. 

When I spoke with both authors earlier in the month, I asked them: "What are the common mistakes made when developing Lean processes?" Here is their full response:

Although every situation is unique, the three lean process development mistakes we see most often are:

Confusing Tools with Goals -- This is often rooted in not understanding the true purpose of the many Lean tools at one’s disposal, coupled with a poor grasp of the current state of the existing processes.  This results in a patchwork of “Lean stuff” stitched together – a veritable Frankenstein of a process.  First, understand your situation (CONtext) and then apply the right tools at the right time to learn what you need to know.

Losing Sight of Targets -- New projects most likely have a business case.  Done properly, this business case is based on assumptions that have been documented.  These might include a particular margin level, production rates, volumes – and the list goes on.  Likewise, these assumptions are calculated from a variety of other expectations such as cycle times, process uptime, projected yields, and material costs.  Once the money is approved, progress towards some of the high-level metrics is sometimes tracked, but often the more basic expectations that fed the calculations get lost.  Additionally, these assumptions are rarely translated into metrics that make sense to the project teams earlier and earlier in the development process.  End-state targets need to be translated backward to meaningful targets at key points, earlier and earlier, in the development process.  What does a final target of 15% margin look like to someone who is developing early process concepts?

Treating Development as an Event instead of a Process --  It is amazing what a properly selected and inspired team can accomplish.  Just think about the impact a 3-day kaizen event can have.  Yet, the organizations that really excel with lean have figured out how to make improvement part of everyone’s daily work.  The same thinking applies to process development.  It is okay to start your journey to better process development with a great, focused team.  But make certain to capture lessons learned along the way to incorporate into your “process of process development.” 

What do you think of Matt and Eric's perspective on mistakes regarding Lean process development? Have you experienced the same problems in your company during your Lean initiative and process creation? 

For more information about the 6Con Model and Mat and Eric's book, please visit: https://www.thepowerofprocess.solutions/

Traditional Accounting Systems -- They Don't Properly Value Time

Lean advocates have long been critical of the fact that traditional accounting systems motivate over-production and promote building inventory. In her book, The Monetary Value of Time: Why Traditional Accounting Systems Make Customers Wait, the author, Joyce Warnacut, discusses the fact that traditional accounting systems don’t properly value time. I asked her directly: "How is this different from the Lean perspective?" and here is her complete response:

Lean objections are based on the fact that absorption costing requires overhead allocation. The cost per unit is driven down by making more and spreading the cost over a larger number of units. H. Thomas Johnson (Professor of Business Administration, Portland State University) wrote the following in his article Work Lean to Control Costs: “Producing more and more output to reduce average unit costs is a time-honored pathway to excess, delay, and abnormal variation – prime drivers of higher total cost.”

These concerns are valid, and yet the total impact of traditional accounting goes far beyond overhead allocation. The matching principle, one of the foundations of traditional accounting, requires matching of production cost to revenue. This means that if you spend $1,000 making a product this month, but don’t sell it until next month (or next year), the matching principle requires you to stash $1,000 away in inventory. This puts the $1,000 on your balance sheet as an asset and keeps $1,000 in production costs off your profit and loss. The $1,000 will be recorded as a cost of sales at the time the product sells (i.e., the cost will be “matched” to the revenue).

Note that the $1,000 cost – and the resulting profit from the transaction – is exactly the same whether the product sells today or several months from today. Is this true? Inventory costs (storage, handling, carrying costs, planning, expediting, moving, counting, potential obsolescence, etc.) are allocated in some fashion over production. The allocation may be as simple as units or hours (volume-based allocations are by far the most common) or a more complex allocation formula.

But no matter what formula is used, the cost recorded for that particular product is the same whether the product is sold immediately or held in inventory for months. Intuitively, most people would think that product sold directly off the production line contributes more to the bottom line than product that is carried on the books for a month or more. From an accounting perspective, however, this is generally not the case.

Resources that are invested in inventory are valued no differently than resources invested in product that can be converted to cash immediately. What if our accounting methods put a value on time? What if product cost increased for every day the product was held in inventory? What if our shop floor operations were evaluated based on how quickly they turn orders into cash? What different motivations might this create? What changes would be made in how we allocate resources?

Although accountants recognize the time value of money when comparing investment alternatives, the same principles are not applied in how we value inventory, how we allocate resources, nor in how we evaluate the profitability of our products. 

What do you think of Joyce Warnacut's perspective here? Does your organization function under a traditional accounting system? Have this system undercut the true value of your Lean initiative?

Boeing’s Problems: Lean Lessons Unlearned

You have undoubtedly heard about the latest developments in the Boeing soap opera, most recently the announcement of a delay in the first flight of the 747-8.

In his FlightBlogger blog, Jon Ostrower has done a good job of analyzing what when wrong. He attributes it to “resource constraints driven by the engineering responsibilities diverted by the 787 program.”

He also quotes one engineer as saying that, with the 787 Dreamliner, "workers are adjusting to building a new airplane. A lot of them have been moved around...so their work lacks continuity which leads to production errors."

What I find most interesting is Jon’s descriptions of problems stemming from early decisions about planning (or not planning).

Boeing decided against a full systems integration lab (SIL) for the 747-8 derivative aircraft, due to the influence of the legacy systems on the current design. However, because a SIL was unavailable, says a second 747-8 program engineer, many of the system level issues were encountered on the aircraft, rather than being caught in the lab.
In addition, without a universal computer model derived from Dassault Systemes CATIA v5 software, Boeing has found itself "trying to bridge the gap between 1969 and 2009," says a veteran engineer based at one of Boeing's 747-8 suppliers.
For example, the new wing design and enlarged empennage were designed through CATIA v5, while a portion of of the internal fuselage structure and other parts of the aircraft were built using legacy engineering drawings.
Some parts and their associated engineering drawings, the engineer says, have not changed since the 747-100, which in some instances has led to a loss of tolerance control in some areas.

All of this is very sad news about a company that knows as much about lean as Boeing. While following lean strategies and tactics might not, by itself, have been enough to avoid everything that has happened, certainly a greater attention to value stream mapping and management might have helped.

A lot of what Boeing learned over the years about lean seems to have been unlearned. Maybe when Alan Mulally is done at Ford he can return to Boeing.