words: andrew quibell
2025 is a point in time when many businesses and larger enterprises intend to have their industry 4.0 and quality 4.0 approaches to technology and manufacturing fully functional, contributing to their growth, prosperity, and bottom line.
the marriage of man, automation, and digital technology in this cyber-physical reality is here and consolidating ground now as a foundation for what will come next. you cannot afford to ignore it. have you or are you embarking on this journey? do you have a roadmap or game plan (hoshin plan) dictating your vision and immediate next moves?
this 4th industrial revolution has shaped up to be a springboard for the next step in our evolution: the age of ai – artificial intelligence – a 5th industrial revolution that will prosper over the next 20 years, resulting in the gradual and persistent takeover of many tasks currently done by human beings. the genie is very much out of the bottle, and i am not sure people realize what this has unleashed. it’s critical that we in the lean community focus on shaping and influencing these future outcomes: we can’t stop the migration towards ai and its domination over all other future technologies, but we can shape and influence how it is applied.
when i initially set about looking at what we would need to do on our 4.0 journey at cimpress, the first thing that came to my mind, from a lean perspective, was to strip out historical complexity in workflow architecture (establishing direct and straightforward workflow structures that have a flattened architecture). taking an approach i had learnt many years ago as a bama (blue grass automotive assoc.) facilitator, we applied the system, pathway, connection, activity methodology to help structure what we would be attempting to create next. for those interested, this methodology is described more thoroughly in the harvard business review article decoding the toyota dna written in part by dr. steven spear.
after coaching my team accordingly, we started to build a platform to easily connect and disconnect applications, allowing for more accessible data communication between one and another app. the aim was to eliminate and replace manual, repetitive tasks often performed by people that could now be done by digital technology and tools, harnessing machine learning or artificial intelligence. it was easier said than done talking it through with my team members at the time, but that was the path we had to go down.
at the 6 o’clock position, my hoshin plan had two very straightforward line objectives on 4.0, scoping to integration. moving clockwise, at the 9, 12, and 3 o’clock positions, the nitty-gritty details of what we intended to do were mapped out. my team framed hypotheses by initiating internal assessments of our current state and then conducting gap analysis towards our ideal state. using a pdca framework, we then started to build out our new approach to constructing a platform that was built for quality and leaner than before, more digital-centric, but not overly complex for those who had to navigate it.
it is essential to point out here that the decision rights of where an enterprise or business moves with 4.0 integration may fall to other stakeholders who sit in other technical or manufacturing functions far higher up the organizational chain of command than you. therefore, their vision and objectives may cut through or overshadow what you want to do from your own specific functional department’s perspective.
in these circumstances, your role as a lean thinker is to help influence and shape the desired quality outcomes. without creating conflict with the higher-level vision, it is your responsibility to highlight and map out the current complexity in the existing legacy systems (waste and redundancy) and explain what you wish to do to remove or eliminate such complexity by establishing the new, simpler, and more direct connection in future workflows. again, this influencing exercise is easier said than done, but must be performed and coupled with much coaching to point out to stakeholders that the existing setup does not work as intended. to win over influencer advocates who support your approach, point out what is a real chore for users to navigate and use in daily work and the workarounds to systems that manifest errors, create costs, and provide real-world case examples of where we are wasting time, money, and resources.
should you be interested in following a similar path, here are a few lessons we learned:
- all your company (quality) data needs to reside in one data lake. data for all applications you intend to use has one secure home location. with data residing in two or more places, you might potentially end up with conflicting results, data contamination, accuracy issues, and impaired data integrity.
- consider choosing a platform for quality that’s not dominated by the more prominent market software leaders, i.e., amazon, sap, or microsoft. you may find it hard or, in some cases, impossible to connect all the applications you need to run and talk to one another on your platform. software leaders often impose barriers to setting up or preventing competitors’ applications from gaining access or a path into their operating system. usually, if they don’t make or control the application, they can block or make access hard or costly for you. an example here is power apps by microsoft: it is a great package to build various digital applications and tools. but suppose your platform architecture is not microsoft compatible: in that case, it may not be able to operate or fully integrate as you would like without a complex or expensive third-party api hook-up.
- choose a platform where you can build applications without being tied to your it department and where you need their code programmers. why? when coding, you are at the mercy of the it departments’ priorities list and their availability to do work for you and other functions. coding is a premium skill that is always in demand. you want a platform to build applications with low code/now code.
- consider hiring a developer to write low code/no code for your platform or train an it-savvy team member to be your team’s applications builder. having this skillset on your team gives you complete autonomy from outside functions that you don’t or can’t control to set priorities to build your apps.
- establish one jump-off point or common start place for all users of your platform; try to pursue a philosophy of no more than three clicks away for what you want to reach, find, and use.
- view your data through one common dashboard application; because two or more dashboard apps add complexity, always pre-determine your dashboard layouts, and establish visual standardization. it will be hard to do if you have legacy systems in operation, since existing users always tend to lean back on them for information or second guess new apps.
- always canvass users about everything they feel or see is wrong or does not work correctly or efficiently with current legacy applications. then, apply pdca to all those negatives to correct these features on the next replace dashboard app, rank, and rate filters. couple the launch of that new dashboard app with pre and post-training and intense coaching sessions repetitively post-launch. the aim here is to gain and sustain new and existing app users.
- robustly de-bug and pilot test all launched apps while running in parallel the manual (as in, human dependent) or legacy applications you wish to replace until you are convinced that accuracy and user acceptance can be established for the new app. then decommission the old and block access back to legacy apps. set a future date by which access will be blocked, so that users can adjust to switch over, reminding them often of the termination date of legacy apps.
- harness ai now to start performing predictive and prescriptive analytics on all applications you use to capture, interrogate, and report data. many applications focus on the descriptive and diagnostic analytics (reactive), the “what” and “why” it happened. looking at our tomorrow and the advancement of ai, the 5.0 focus is about what’s likely to happen and what we can do to make our objectives possible.
i hope this article and the insights it contains make you curious to explore this topic further. it may offer you a start point or a checklist to confirm and reflect on what you have been doing in this area to date. is your approach towards shaping and harnessing the power of technology for the future similar to ours?
the author
andrew quibell is head of manufacturing quality and lean at vista print.