(Senior) Industrial Digitalization consultant
“AIVHY is looking for a passionate Industrial Digitalization consultant who would love to help companies with achievable innovation.”
Menu
Industry 4.0 holds an exciting future. A future that poses entirely new sources of business value and revenue. A disruptive transformation where organizations enter the 4th industrial revolution and leave their competitors behind through digitalization, integration, auto(no)mation, and insight.
Very exciting and crucial indeed, but how do real-world businesses with real-world budgets, real-world limitations, and perhaps operational legacy systems take part in this disruptive transformation?
This guide introduces a comprehensive real-world approach to lasting Industry 4.0. It enables real-world businesses to transform their organization with small value-generating steps, to a future of lasting uniform Industry 4.0.
AIVHY Ltd developed “The Master Plan of Approach”. A methodology that transforms real-world businesses to a future of lasting Industry 4.0. An approach for businesses where state-of-the-art and legacy systems might co-exist, large budgets do not just lay around, steep requirements for Return On Investment apply, and where people do not always look forward to change. The Master Plan of Approach addresses all the challenges on the real-world path to Industry 4.0 and transforms the organization into the driving motor behind the journey.
Before we dive in, we did wrote a dedicated article for those who first prefer an introduction into the concepts and principles of Industry 4.0. We elaborate on what Industry 4.0 exactly is, supported with real-world examples, and what challenges to face on the journey. Please follow the link to read more.
The transformation to real-world Industry 4.0 must be a self-sustaining journey, taking incremental bite-size steps with continuous value generation along the way.
The Master Plan of Approach is designed to break-up the transformation to Industry 4.0 into small bite-size steps. Each step requiring a small budget and realizing an excellent ROI. This methodology realizes a cost-efficient self-sustaining journey to a scalable, maintainable, and uniform future of Industry 4.0 while engaging the organization by design.
The approach is customizable to any organization’s specific needs and applicable for any business which relies on physical systems and machines in their operational processes.
The entire transformation exists out of 4 stages being:
The first two stages combined realize a warm-up phase that is meant to gain initial support from the organization. The third and fourth stages could be seen as the transformation phase, where the lasting transformation is taking place.
Stage one teaches the basic principles and value of Industry 4.0 to key players and engages them to explore potential in their own organization. Input from the first stage is used during the second stage where a prototype is realized to display a real-world example of the future which lays ahead. Stage two is designed to prove the value of the coming future while further engaging the organization.
A well-executed warm-up phase will raise the curiosity of the organization. Early adopters start showing interest and become eager to form a part of this journey. This is a crucial point in the transformation. From now on, all curiosity and initiatives must be aligned in the same direction, contributing to a single horizon of uniform Industry 4.0. The third stage must realize a future vision, master plan, and platform for the organization on which the transformation can be realized.
The path is now laid out and it is time to start moving on this self-sustaining amazing journey towards Industry 4.0. With that, the fourth stage has started.
The Master Plan of Approach is designed to make small incremental steps (called Incrementals), requiring small budgets with excellent ROI, towards a unified future of Industry 4.0 while engaging the organization by design. In fact, the approach is optimized to intrinsically motivate the organization to become the driving motor of the transformation.
Individuals in the organization like engineers, business controllers, operators, purchasers, quality assurance specialists, etc.., do know every aspect of their discipline. They know the domain, what works, what can be improved, and where great value is left for taking. The master plan of approach focuses to empower and guide these individuals to share and act on those insights. We believe that it is much more efficient to empower these individuals and guide them to a solution fitting the big picture, instead of explaining the opportunity to, for example, a data science expert who then instead tries to understand and solve it.
This approach knows significant advantages:
The transition is designed to be self-sustaining, as the return on the investments should be (partly) reinvested in further development.
The master plan of approach establishes a controlled environment, mainly materialized through a smart platform and an agile-based approach, to enable anyone to realize potential as part of the larger journey.
The transformation to Industry 4.0 involves long-term & organization-wide strategic decision making. The transformation must because of this be initiated and driven from the organization’s very top in order to be successful.
A transformation sponsor at C-level is required to interface between the top management and the transformation core-team (later more about this). This C-level sponsor will also be able to open doors and ensure involvement at the right organizational levels.
The transformation process to Industry 4.0 will be led by a Transformation Leader, assigned by the organization’s top. The transition leader is ideally an expert in the field of Industry 4.0 and experienced with the transformation process. It is his task, during the first three transformation stages, to:
The Transition Leader does not necessarily have a vote in decisions, but ensures that all facts, benefits, and drawbacks of every option are on the table. This way, he or she enables the decision-makers to make the best possible decisions. The role of Transformation Leader could excellently be fulfilled by an external consultant, who delivers the required experience and knowledge.
The warm-up phase is meant to create an initial support base for the organization’s transition to Industry 4.0.
Key players are the organization’s individuals who are active in the operational and strategical layers of an organization. The key players could include foreman, middle management, early adaptors, and perhaps certain specialists. Also higher management and C-level individuals are considered key players, as Industry 4.0 must be uniformly integrated across the entire organization, horizontally and vertically.
Warm-up sessions for these key players need to be organized, led by the Transformation Leader. Ideally a 20-min and a 30-min session is held, a week apart, involving key players from mixed departments. The first session is meant to educate basic principles of Industry 4.0 and train key players to recognize potential value through industry 4.0 in daily work scenarios. The first session could best be scheduled after the morning-meeting-madness and before the lunch, allowing the key players to apply their new insights the very same day.
In preparation for the second session, participants are requested to apply their new value recognizing skills by looking out for new value to be created during their daily work routines. Any form of value is welcome, no matter if this is personal gain, improved comfort or pleasure during work, or financial gain.
Each idea for new value needs to answer 3 questions in order to be valid:
The second session starts with 5 minutes of re-engaging the key players, putting them back in the mindset of Industry 4.0’s potential. The key players are then asked to share their ideas with the group. Depending on the flow of the session, an open discussion or small brainstorm exercise could be held to further discover potential and engage the individuals.
All ideas and suggestions need to be collected and documented by the Transformation Leader as they are required in the next stage(s).
The second stage implements a first bit of Industry 4.0 in the real world as a Proof of Concept (PoC) or Prototype. The ideas gathered from the key players during the first stage act as an excellent source to select a PoC from. The selected PoC has to meet certain requirements in order to maximize success:
The Proof of Concept should be accessible for any interested individual and advertised across the organizations. The more visual and attractive, the better. For larger organization, it would make sense to start multiple PoC’s.
Suggested steps to Proof of Concept:
Please note that the purpose of the Proof of Concept is not to build a lasting solution, but to Proof a Concept and engage the organization. This said, the concept will in a later stage be transferred to a lasting and scalable implementation for further & continues value creation. This allows the PoC to remain as small and agile as possible in this early stage of the transformation, and result in a much more robust solution in later stages.
Individuals becomes aware of Industry 4.0, its potential for their organization, and the strategic future minded ambitions of the company’s leadership. This is the time to set future goals and build a masterplan. We arrived at the “Envision, Strategize & Master planning” stage. A stage crucial for long-term success.
The next step in the journey to Industry 4.0 is to set a future heading and goals, shape a scalable architecture, and furnish all transformation processes.
At first, a strategic cross-departmental core-team needs to be assembled, consisting of individuals who are open to innovation, new ideas, and willing to think outside the box. This group should contain at least one C-level member being the high-level sponsor, representatives of different departments with strategic and floor level insights, domain experts, and the earlier introduced Transformation Leader.
The ideal group size lays between 5 and 8 members, plus the leader. Essential is that all key aspects and key departments of the organization are represented in this group. Think at least about Financial, Operations, Tech (OT), IT, Quality, HSE, R&D, and Supply Chain.
The group could temporarily be expanded on specific occasions with strategically selected customer or supplier representatives. This will not only give better insight into their needs and ideas but will also tighten the relationship and improves future integration across the supply chain.
Now the core-team is assembled, it is time to further educate and imagine the disruptive potential of Industry 4.0 with them. Ideally, a one-day session is planned in a remote location, away from the organization’s site. A new environment will relax the mood and facilitate free thinking.
The day is led by the Transformation Leader and must be as interactive as possible. The first half of the day aims to further educate the principles of Industry 4.0, teaches how new business value is generated, and which challenges to expect and address. The second part of the day, after lunch and a walk to process all new knowledge and clear the mind, consists of a working session.
This second part of the day is meant to envision an Industry 4.0 driven future for the organization. This vision will later be used to derive a future heading and goals.
Envisioning will start with brainstorm sessions where the target is to “imagine the organization fully operating in the fourth Industry revolution”. In essence, what does the company look like after 10 years of innovation? Any thoughts are welcome, and all ideas should be unfiltered and unaffected.
The Transformation Leader, leading the brainstorm sessions, has the important task to guide and stimulate the sessions by selecting and adjusting the brainstorm methods (multiple), adjusting the brainstorm target, and optimizing useful results. This requires experience in both brainstorming and Industry 4.0. Small breaks, brainstorming alone or in a group(s), and temporary changing surroundings might lead to new ideas. Brainstorming should go on, as long as new ideas are coming. All core-team members should be motivated to think within and outside of their own department and discipline.
Some brainstorm methodologies which have proven to be beneficial are:
All ideas will be organized with colored sticky notes and their position on a simplified process map on the wall. This process map should display the different functions of the organization in their rough logical / process order, from left to right. This process map should include the simplified supply chain and secondary processes.
The map should be vertically divided into categories, based on the ISA 95 and RAMI 4.0 model. These vertical categories are, from top to bottom:
Do not hesitate to increase the size of the process map on the wall, as there should be plenty space for ideas.
Known bottlenecks or high potential areas, for example, discovered through previous Business Process Analysis (BPA), could be highlighted on the process map to further focus the potential of Industry 4.0’s disruptive principles on these opportunities. Please note, that the other areas may never be neglected!
The ideas from the brainstorm session can be written on colored sticky-notes, as mentioned before, where each color has a different category.
The reason for the elaborate map is to help the core-team to think across their entire organization, and their own department in relation to others. The vertical & colored categories are important, as they will help in a later stage to define short-, mid-, and long-term goals. The abstraction level of the map is important, as overloaded with detail will force the team to think too much within the constraints of the current process, while a too low level of detail might exclude aspects from the brainstorm.
The brainstorm leader should add the ideas from the earlier warm-up brainstorm sessions at the start, during, or after the session to the map.
After the brainstorm session is completed, it is time to prioritize the ideas. Please note that for this day the brainstorm exercise is most important, and prioritization could be done on a later day. Each idea should be rated against three properties with a score between 1 and 3 (lower is better):
The result of the day will be a most elaborate illustration of the organization’s future variations and a rated collection of ideas for value creation. This approach chooses to not initiate a major BPA, as this will consume significant resources in time and money, most likely focuses on only specific parts of the business processes resulting in a less than full image of the reality, possibly loses part of the organization’s engagement as such an investigation could be perceived as invasive or forced, and represents only a brief moment in time.
Instead, this approach relies on the domain knowledge, experience, and creativity of the core-team to explore and rate potential, guided by a skilled Transformation Leader. Multiple re-imagination sessions could be held if this is deemed necessary by the Core-Team. Note that the vision does not have to be perfect, as the Master Plan of Approach allows for some level of error. It’s nearly impossible to predict the future.
The core-team does now definitely deserve a beer and I would like to suggest a dinner together! Well done!
An Industry 4.0 future for the organization needs to be specified. A direction and target on the horizon which aligns all choices during the transformation.
The future goal exists out of three parts:
The long-term heading provides an aim for the journey and drafts an ambitious but achievable future, 10 to 15 years ahead. This period is very far away by modern planning standards as the world seems to keep changing faster and faster. Because of this, the level of detail in the heading definition must make sense for over such a long period and need to provide AIM, rather than SMART goals. The long-term heading should fit on a single side of A4 paper, and not contain details.
Once a future heading is set, a SMART mid-term and short-term goal can be defined in line with the long-term heading. These mid- and short-term goals set concrete and measurable targets, enabling initial decision-making and purchases as part of the realization. In essence, the mid-term goal allows to set requirements for initial purchases, while the short-term goal allows scaling these purchases for an optimal investment for the short-term period. The initial purchases are made to set-up the scalable platform, which embodies the technical implementation of the journey. Much more on the platform follows later.
To define the long-term heading, the following steps should be taken:
A more concrete 3-to-5-year mid-term goal is required, allowing to define actions and make concrete decisions. Determining the mid-term goal requires:
The steps to a mid-term goal are:
The reason to select categories is that ideas in these categories typically require different technical solutions. By selecting particular categories, purchases could be better focused, leading to a better ROI.
The steps to a short-term goal:
Once the heading, mid-term goal, and short-term goal are defined, board-level approval is required. The C-level core-team member should facilitate this approval.
Two activities should take place in parallel with the future heading & goal defining steps. The first activity is market exploration and research, providing insight in available solutions and technical possibilities. The second activity is the determination of the organization’s baseline.
New ideas that come to mind during the market research & baseline determination should be added to the other ideas and rated likewise.
Market research as a potential customer is a joy. The goal of this research is to find solutions and suppliers who could contribute to the transformation and future goals. The relevant types of solutions and suppliers differ for each organization. The following keywords might get your search pointing in the right direction:
Use modern search engines like Google and Bing to explore the market, and visit one or two events in relation to industrial digitalization and Industry 4.0. Some of the most suitable solutions and events are nearly unfindable. The Transformation Leader should be able to help out and suggest relevant vendors, products, and events to speed up the market research. Also, feel free to contact AIVHY Ltd for assistance or a tailored list of solutions.
Create a shortlist of 5 to 15 suppliers who seem a good fit for the organization’s transformation. Approach them for an introduction meeting. When approaching these parties:
Maintain the shortlist and make notes about the different suppliers, as this information will be used later again. Notes for each suppier should at least elaborate on:
Remove or hide those from the shortlist which do not fit the goals or long-term heading. The remaining list should at least contain enough suppliers and solutions for the technical realization of the entire journey towards Industry 4.0.
Note that in some cases, a supplier is able to provide the entire technical implementation, where in most cases the final implementation relies on a smart architecture of solutions from different suppliers.
Determine for each of the remaining suppliers a “supplier rating”. This rating should be based on the organization’s purchasing requirements regarding supplier approval. This supplier rating might be based on:
Note that a higher score is better.
Some of the most promising solutions could be (partly) open-source. It is recommendable to utilize such open-source solutions via a specialized service provider, which ensures support for the solution during its lifetime. Using an open-source solution without a supporting body requires the organization to acquire a much deeper level of know-how. Also, the journey’s architectural design and system selection will become more challenging with community-only supported open-source solutions, as the comparison with other systems and architectural designs must be done entirely by the organization themselves while the in-depth knowledge is not present yet.
This market research excersize will be the first step in the platform selection process, later mentioned as Request For Information (RFI).
It is important to establish a baseline of the organization in relation to Industry 4.0. This baseline should provide insight in the following topics:
State of technology baseline, including IT systems, machines & equipment, and other Operational Technology (OT).
The found information could best be organized in an architectural diagram linked with a lightweight Configuration Management Database (CMDB). (A diagram drawing tool and spreadsheet could be used when no dedicated tools are available)
List and inventory all existing and relevant systems in the CMDB and architectural diagram. Also add systems that are planned for future intallation, marked as such. Add for each system the following information:
Most energy and time should be spent on systems which could become data sources or play a potential role in the journey’s technical implementation. Some of these systems could include, but not limited to:
Organization baseline, including all departments.
The found information could best be organized in a SWOT analysis. At least explore the following subjects when determining the organization’s baseline:
Financial baseline, including all financial aspects that might conflict with the Master Plan of Approach.
The found information could best be organized in a SWOT analysis. At least explore the following subjects when determining the financial baseline:
The baseline determination should provide enough insight to make better decisions and address unwanted surprises in the Master Planning before they even occur. Most organizations should be able to gather the required information from already existing documentation or individuals knowledge within the organization.
All findings need to be taken into account when defining the goal and developing the master plan.
The platform is the entire technical embodiment of the organization’s transformation to Industry 4.0
The platform consists of a set of strategically chosen systems and solutions in a clear and scalable architecture. Each system has a clear purpose and minimal overlap with other systems. All these systems together will result in the entire technical implementation of Industry 4.0, as a single and unified whole.
The initial platform implementation only consists of a small part of the total planned whole, facilitating only the needs to reach the short-term goal. The platform scales up, as it is meant to do by design, when the transformation to Industry 4.0 further unfolds.
The platform grows with the journey towards an uniform future of Industry 4.0
This “scaling platform approach” spreads the cost and implementation effort over time. The active platform implementation essentially pays for its own growth as it already generates a Return On Investment, hence the “self-sustaining journey”.
The platform ensures:
The platform design and implementation should facilitate safe development of incremental and experimental steps, aligning with the short-term goals. A dedicated test environment or “playground” should do the job. Successfully developed, tested, and approved incremental steps could be implemented in the platform’s operational environment.
The playground is not only essential to realize improvement by developers but is also crucial to involve the organization. A safe development environment essentially allows any individual with an idea to contribute to the journey, empowering individuals and engaging the organization.
The organizations must become the driving motor behind the transformation to Industry 4.0, and the platform with its safe playground facilitates this.
The number of different and overlapping systems should be reduced to a minimum resulting in fewer but larger systems. This less but larger systems approach tents to:
Many organizations already operate systems that could be used, or perhaps expanded for use, within the platform’s architecture. The earlier determined technical baseline should list these systems. When crafting the platform’s architecture and selecting its systems in preparation for the initial implementation, it is essential to consider these existing systems. This will reduce the total amount of systems across the organization and is likely more cost-efficient as in-depth knowledge for existing systems is already available.
More details on platform selection and architecture will follow later in the platform selection chapter.
Legacy systems pose a couple of challenges in relation to the transformation to Industry 4.0, but do they really? The major ones being:
Even though legacy systems are harder to connect with, they generally offer still plenty of connection points like data & control busses, legacy interfaces, and legions of opportunities to install sensors and manipulate controls. A smart platform architecture with the right decoupling points allows connecting these legacy connection points to the platform, providing plenty of opportunities for value creation. Specialized old-to-new-interfaces are available in the market which excellently fit in the architecture’s de-coupling positions.
A smart platform architecture allows replacement of legacy systems with minimal adaptions to the integration with the platform. Only small changes are required to optimize the new system’s Industry 4.0 integration, taking only a part of the initial resources as all the how-to knowledge was gained during the development of the incremental on the legacy system. This gained knowledge also leads to better, industry 4.0 ready, purchasing-requirements and purchases. The legacy’s replacement system will have more future potential than it would have had without the acquired knowledge during the legacy implementation.
I do agree, developing Industry 4.0 potential for legacy systems is not the ideal scenario, but it definitely is no reason to delay the journey to Industry 4.0.
Crafting the platform’s architecture and selecting its systems is a crucial step as it defines the technical implementation of the journey to Industry 4.0. The suggested “crafting” and selection process as part of the “Master Plan of Approach” is based on a three-step procurement approach, leveraging the knowledge and know-how of suppliers. The steps, well known by the organization’s purchasers, include a Request For Information (RFI), Request For Proposal (RFP), and Request For Quotation (RFQ). These three steps will in fact form the framework for the “crafting” and selection process, including more than just procurement steps.
Some lucky organizations are able to start the journey to Industry 4.0 entirely with existing systems and suppliers, perhaps with some additional licenses. This could be the near-ideal scenario, although it would still be wise to follow the RFI, RFP, RFQ approach, including the suppliers of the existing systems, in order to ensure future scalability and learn from all the suppliers during the process.
The journey could alternatively be realized with open-source systems if the organization is prepared for this approach or perhaps relies on service partners to address the hurdles of this direction. Again, the RFI, RFP, RFQ approached should be followed in order for an optimal and long term scalable platform.
The RFI is already completed during the Market Research exercise discussed earlier. This research gave insight into the technical possibilities and available solutions in the market. During the RFI, a shortlist was created as input for the RFP step.
The RFP deviates from the traditional RFP format, as it is utilized to invite suppliers to propose an platform architecture and suitable systems in it, to realize the entire transformation to Industry 4.0 until the long-term heading is achieved. The RFP is meant to design the scalable platform, using supplier’s knowhow.
Note that most suppliers are able to only offer a part of the total implementation, as they offer for example powerful AI tooling, but do not offer any data acquisition tooling. These suppliers should be asked to still propose an architecture with their solution in it, only with the required systems out of there scope as grey “function-boxes” or perhaps suggested product from other suppliers. This approach allows to still learn from the experience and knowhow of the supplier, even though they provide partial solutions.
It is important to inform the suppliers that the initial investment will be only a part of the proposed platform and will grow in incremental steps as the journey to Industry 4.0 continues.
The goal of the RFP is to explore:
The proposals as a result of the RFP need to be examined and ranked by the core team. The next step is an exciting one, as the time has come to design the platform’s scalable architecture for the entire Journey to Industry 4.0. The real-world experience of the Transformation Leader is essential in combination with the domain knowledge of the core-team members (especially the OT & IT representatives). It might also be necessary to bring in temporary expertise to design and challenge the architecture.
The architectural design should ideally include some options and variations, in order to receive multiple competing quotations in the next step. The next step in the process is to acquire quotations, which is the last step before implementation of the initial platform. But before we move on, we first need to have a look at the requirements and technical specifications of the platform in the next chapter.
An RFP inquiry should be paired with a specification. This specification will be written by the transformation leader based on input from the core-team. The specification should encourage the RFP respondents to share their insights, leveraging both their know-how as their in-depth knowledge of the offered products.
It takes roughly between 50 to 200 hours to write a platform specification by an experienced transformation leader, and roughly between 5 to 10 core-team meetings of 1.5 hours, assuming the previous steps are executed well. The specification should take between 10 and 35 pages.
A specification checklist is available below to help addressing all relevant subjects in the specification. Note that this checklist might be over-complete for some organizations while incomplete for others. It is the role of the Core-Team and transition leader to guard the completeness of the requirement specification.
Completeness of the RFP platform specification is crucial, as it addresses many of the challenges during the journey to Industry 4.0!
Make sure that the specification is structured in such a way that the supplier can easily and clearly confirm conformity with each requirement, suggest changes or improvement, and make comments where partly or completely non-conform. All requirements should be weighted, allowing to generate a “proposal compliance score” for each proposal (a higher score is better). Feel free to contact AIVHY Ltd for specification templates at the address stated at the bottom of this guide.
Next to the specification, a proposal scorecard should be specified and attached to the specification. This allows the suppliers to optimize the proposal and the core-team to rate proposals. The assessment criteria should be weighted and could involve:
The score per proposal could be calculated per the following formula:
Total proposal score [in %] =
+ [weight%] x (Proposal compliance score / Max score)
+ [weight%] x (Vendor rating / Max rating)
+ [weight%] x (100% - (Initial platform cost / Cost of heighest proposal))
+ [weight%] x (100% - (Cost of scaling / Cost of heighest proposal))
The total weight should add up to 100%.
A higher score is better.
Once the suppliers have proposed their platform solutions, a shortlist can be compiled by the core-team. This shortlist should at least contain 3 entries.
The input from the suppliers will likely lead to new insights and perhaps additional requirements. Process these new insights and requirements in the specification, mid-term goal, and long-term heading.
This chapter contains a list of items that could help to realize an as complete as possible specification. The list could be used to write the specification, or just to verify if nothing was forgotten.
Note that the checklist is a general tool, and might be more complete and applicable for some organizations than others. Feel free to contact AIVHY Ltd for guidance, expertise, or review.
Define required future platform functionalities, segmented in the layers used during the brainstorm session. Highlight the layers selected for the mid-term goal. Potential functionalities that might need to be defined in details, based on the goals and heading, could include:
Platform Architecture requirements might describe:
(Advanced) Human Machine Interfacing (HMI) requirements, which could requirements in relation to:
Use requirements should describe the requirements for use, which might include:
Test environment & playground requirements might include:
Data and connectivity related requirements:
Logging requirements might include:
Demand Cyber Security By Design:
Identity & Access Management (IAM) / Identity Governance & Administration (IGA) requirements:
Maintainability requirements:
Scalability, Cost, and Licenses requirements:
Requirements related to ownership and right to alter, change and modify the platform:
Requirements related to Deployment & SLA’s:
Requirements related to documentation:
The specification checklist states several checks regarding to flexibility, openness, connectivity, and access to the platform and its data from third party systems. These requirements are crucial for long lasting future potential and reduce the need and criticality for a perfect specification, as these requirements allow to address certain miss specified requirements. Ensure the these “openness & flexibility” requirement are clear and strong!
The last step of platform selection is the RFQ. The purpose of the RFQ is to receive actionable quotations for the purchase and implementation of the initial platform as part of the short-term goal realization.
Any new and valuable insights or feedback from the suppliers during the RFP should be processed in the specification, short-term goal, mid-term goals, and long-term heading, making them part of the RFQ. The RFQ inquiry should contain the updated specification, goals, long-term heading, and clear scope definition of the initial purchase aligning the short-term goal.
The last step is to select the most suitable quotation(s) and move forward to implementation, finally starting the very first concrete step towards uniform Industry 4.0, followed by incremental steps realizing fast business results.
As the systems for the initial platform are purchased and the platform architecture is determined, it is time for installation, configuration, and implementation of the initial platform and its systems. Most major design choices are already made during the RFP and RFQ, but many smaller but still important choices have to be made during the installation, configuration, and implementation. Make sure to make all these choices in line with the technical specification, goals, and heading. Pay extra attention to the choices which are hard to change after commissioning.
The following subjects require extra attention during this step:
Experience with scaling and Industry 4.0 implementations in a future proof manor is a requirement for long term success. The Transformation Leader should lead this stage. He might choose to acquire additional temporary expertise, or work with the supplier as implementation might be part of the scope of delivery.
At least document the following aspects, in order to continue the same path when expanding systems, changing configurations, or growing the platform within the set architecture.
The goals and heading are set, the platform is ready for use and the organization is excited for some action. Lets start to transform.
This chapter describes the actual transformation to Industry 4.0, and is in fact a journey of continues improvement. The transformation is governed by two main processes:
Strategic processes are meant to guide, govern, and empower the entire transition to Industry 4.0. These processes, for example, maintain the transformation goals and heading, provide training, and realize the scaling and maintenance of the platform.
Transformation processes realize the actual steps to the future of uniform Industry 4.0 in Agile Scrum-like sprints. These steps can be split into two main categories, being “Incrementals” and “Experimentals”.
Incremental steps (or Incrementals) implement ideas that must generate lasting value. Incrementals must meet certain requirements like being thoroughly tested, reliably implemented, and meet ROI targets.
Experimentals steps (or Experimentals) are like Incremental goals, except there is no need for a ROI, and such tight governance. Experimentals are meant to learn, test, or try an idea or concept, providing insight and knowledge which can later be used in Incrementals. Successful experiments could later be implemented as an incremental goal.
The earlier Proof of Concept during the warm-up phase was implemented as an Experimental, and should be one of the first Incrementals to be implemented in order to make this Proof-of-Concept part of the lasting journey.
As mentioned, strategic goals are meant to guide, govern, and empower the entire transition to Industry 4.0. There are three strategic processes defined.
This process manages the transition to Industry 4.0 as a whole. It ensures transformation performance, alignment with goals & heading, and maintains the short-term goal, mid-term goal, and long-term heading.
This governance is realized in periodical reviews, executed by the entire core-team. Periodical reviews should be held every 3, 6, or 12 months, depending on the velocity with which the journey is undertaken and dynamics of the market and environment. The periodical reviews should at least:
Reviews should be made, based on feedback from the core-team, active players as part of the journey, KPI’s, and results in relation to the set goals.
Changes to the long-term heading should be avoided when possible, as all decisions made so far and to be made in the future are be based on this heading. This said, the long-term heading might need to be adjusted when the market, environment, or business needs change. It is essential to keep the currently installed platform in mind when changing the long-term heading.
Mid-term goals are more flexible as they always align with the heading and for that reason must always change on the same axis. In fact, the mid-term goal needs to be adjusted as they should define SMART targets for over 3 to 5 years.
Short-term goals are most flexible, as they define the targets for the coming 1 or 2 years.
The mid-term goal sets a SMART target for over a period between 3 and 5 years and allows to prepare scaling of the platform and resources.
The short-term goal sets a SMART target for over a period of 1 or 2 years, for which the resources must be available in order to not restrict short-term progress.
Mid-term goals facilitate the infrastructure, while short-term goals scale within the infrastructure.
Changes in the short-term goals and mid-term goals might require further expansion of the platform. Expansion within the existing systems can be realized by the Platform Governance processes (discussed in a second), while new systems or bigger investments should always be handled by the core team. These bigger expansions should follow the RFI, RFP, RFQ process as described earlier and be initiated by this transformation governance process.
The Training, Guidance & Engagement processes empower and engage the organization on an individual level. These processes internally advertise the journey to Industry 4.0 and encourage involvement, provide training to those who are interested, and guide individuals to realize a Minimum Viable Idea within the platform.
The Training, Guidance & Engagement processes make the organization the driving power behind the transformation.
The Training, Guidance & Engagement processes should ensure the following activities:
Online training solutions are available, especially for the bigger systems, making training easily accessible to the organization. Guidance and assistance could be provided by a small and dynamic team of professionals. These professionals could potentially be freelancers, as their uniform platform and systems knowledge is what is required from them. (The knowledge about the transformation itself will be locked within the organization.) The use of freelancers allows for scalability in training and guidance processes, and these same freelancers could be engaged as developers where necessary.
Submitted ideas can be high-level, or very detailed. Some idea submitters would like to develop or contribute to the solution, where others just like to leave realization to others. Both variants are more than welcome although, most ideas require some guidance to be truly useful. Ideas could point in a direction of huge potential but fail to mention a solution or a rough cost and value estimation. Idea guidance is meant to make the submitter think a bit longer about his or her idea from different angles, resulting in a very first filtering and significantly higher quality and applicability of ideas.
An “idea box” must encourage the submitter to think and elaborate on the following subjects:
The idea submission form should use plain language without any technical or financial terms as the entire organization should feel welcome to submit ideas. These questions should be finetuned for the specific organization and align with the KPIs defined as part of the short-term and mid-term goal.
The idea box should best be realized in an already available system like a web forms tool. Ideas should only be accepted via this channel and idea submission should be possible to anyone within the organization, including temporary and freelance workers as their fresh insights could be eye-openers. We also recommend making the idea box available to customers and visitors, as their ideas could bring surprising new insights and strengthens relationships.
A small process behind the idea box is required, in order to determine quality & feasibility. Ideas might be returned to the submitter for finetuning or send to the Transformation Process where the Transformation Owner might log the idea for realization. (More about the transformation process and transformation owner in a bit.)
It is crucial to keep the submitter in the loop during the entire idea lifecycle! Leaving submitters uninformed about the status of their ideas for more than 2 weeks after submitting will result in gradual loss of the organization’s support for the journey. It is better to decline with an honest reason than to just not answer!
Successes must be advertised, putting both the idea submitter and the results in the spotlight! It will not only give the submitter credits for his idea but will motivate him and others to further engage and keep posting ideas.
Platform governance manages all technical activities that ensure the platforms Maintenance, Tidiness, and Scaling within the existing architecture. What these activities exactly look like depends on the platform’s implementation. Some platforms require significant manual maintenance where, for example, cloud platforms are likely to be fully serviced by the provider.
Independent of the chosen platform, the Platform Governance processes must ensure:
All Platform Governance activities should be executed in line with the earlier made decisions, mainly defined and documented during the implementation of the platform.
The realization of the journey to Industry 4.0 realizes ideas in incremental steps called sprints. This realization is managed by an agile scrum-like approach.
The high-level scrum-based approach goes as follows:
This process is led by two individuals, being the Transformation Owner and Transformation Master. The Transformation Owner is accountable for the technical realization and value creation, while the Transformation Master is accountable for the Transformation Process.
The process must be self-governing, meaning that the Transformation Owner and Transformation Master can make decisions and realize results within set boundaries of the journey.
Both the Transformation Owner and Transformation Master must work together closely and respect each other’s roles. Both roles require very different skills, as the Transformation Owner is more technically involved where the Transformation Master is more managerial and politically involved. These roles must be fulfilled by two different individuals, as focus on one of the two roles will dilute when fulfilled by a single individual. Also, both the Transformation Owner and Transformation Master cannot be developers, as they need to keep the bigger picture in mind.
The entire Transformation team includes the Transformation Owner, Transformation Master and developers.
The Transformation Owner is accountable for realization of the transformation itself. His tasks and responsibilities are similar to Agile Scrums Product Owner with a few distinct differences.
The task of the Transformation Owner could be fulfilled by the Transformation Leader.
The Transformation Master facilitates and guides the transformation process. His tasks and responsibilities are similar to Agile Scrums Scrum Master with a few distinct differences.
Developers are those who do the actual work in sprints. Here, the largest deviation in reference to Agile Scrum could be found as the developers-team is highly subject to change and individuals will work on very different projects.
The developers-team likely changes per each sprint and could exist of the following types of members:
The transformation should be mainly driven by the 1st category of team members, as the involvement of the organization is crucial, and the idea submitters will understand the idea and opportunity better than any other. These idea submitters have other tasks within the organization and because of that, only have limited time to realize their idea. A commitment has to be made by the developer and organization about the number of hours the developer can spend during the sprint on the idea realization. This type of developer also has to gain knowledge in order to execute their realization within the platform. The earlier mentioned ‘Training, Guidance & Engagement processes’ are there for supporting and guiding these developers.
This at first might seem inefficient, but is the right approach for a couple of reasons:
The 2nd category of developers might only be required for realization of bigger and more complex ideas. In fact, it would be better to allocate dedicated expertise to the ‘Training, Guidance & Engagement processes’, in order to guide and empower the organization to realize value.
The 3rd category could be used for clearly scoped sprint items. The problem could be handed over to a freelancer or agency working remotely, anywhere in the world, realizing value against minimal cost. An excellent example would be an already collected dataset, and a particular insight that should be predicted from this data. Like sensor and quality data over a period of 12 months, with as goal to use machine learning to predict quality on just the sensor data. This ‘problem’ could be outsourced as a fixed scope mini-project, and easily implemented in the platform by the ‘Platform Governance process’. Please note that it would be highly beneficial to keep outsourcing in mind during platform selection, as noted in the platform specification checklist.
Stake holders are those who benefit from the sprint results and frequently interface with the transformation owner. Examples of stake holders are:
The group of stakeholders will vary over time, as different sprints require different stakeholders. This said, the Core-Teams should always be present during stakeholder meetings as they represent the entire organization from the transformation perspective.
Stakeholders could even be external parties like supply chain participants, visitors, and customers.
Stakeholders are not part of the Transformation Team.
The Transformation Backlog, or backlog for short, is a dynamic and managed list containing all the work to be executed as part of the Transformation Process and should be the only source of work.
The backlog is managed by the Transformation Owner, who acts as a gatekeeper for new items, and prioritizes the list continuously based on the current needs of the business. This is one of the reasons that the Transformation Owner must have regular interaction with all stakeholders.
The items on the backlog could include:
All ideas from the earlier STAGE 3 brainstorm session should be added to the backlog.
Items on top of the backlog are most likely to be realized first and should have the highest value. This is also where prioritizing the backlog becomes challenging, as value can be subjective depending on which stakeholder is asked. Prioritization could be done on a combination of the following properties:
One could easily imagine that the backlog will become monstrously long. It is the task of the Transformation Owner to manage and own the list, combining items and hide obsolete ones. Items that have great potential and align with the long-term heading, but not fit in short- and mid-term goals should be marked as such. These long-term ideas should be reevaluated as short- and mid-term goals are updated and could in fact influence these goal revisions.
The backlog should be accessible for the stake holders & scrum team.
The higher an item is rated in the backlog, the more detailed it must be. Items planed 1 and 2 sprints away should become clear and detailed enough for implementation. Items between 2 to 4 sprints away require to be clarified on a less detailed level, and any items beyond 4 sprints away do not yet require any clarification, as they might never be realized.
The clarification and detailing of items is known as refinement and happens in collaboration between the idea submitter, Transformation Owner, and perhaps developers or other participants as required. The Transformation Owner is in charge of when the refinement is done. Refinement should be done as part of a sprint.
Each item on the backlog must be deliverable within a single sprint. Items that are too large for a single sprint should be divided into separate items during the refinement. Most sprints contain multiple items.
Each item could start as an idea, a required feature, an improvement, a bug fix, etc, and must be refined into a back-log item containing at least the requirements below before it can be planned for a sprint:
Note that Experimental items do need to meet fewer requirements, as they will generate knowledge or insight and will not be implemented in the platform for lasting value generation. Gained insights and knowledge could however lead to an incremental item that will be implemented for lasting value generation.
Documentation for each item should be written at the right abstraction level, reducing the required amount to a minimum. The right depth of documentation is reached when a manager can understand the functionality and gained value of the documented item, and a developer could understand the details of the implementation as he understands where to look in the implementation itself for details of the implementation. Schematics with guiding text will in most cases be the best approach, describing the functionality, high-level implementation, and architecture. The implementation itself must be complemented with clear comments.
All items should be tagged, providing insight in their nature, allowing filtering and search. Tags could be:
The sprint is where the actual work is done, where ideas are turned into business value. A sprint has a fixed duration between 2 and 4 weeks. All Industry 4.0 Transformation sprints are synchronized across the organization, all starting and stopping at the same moment.
The work to be done during a sprint is defined at the start of each sprint in a sprint planning meeting (more about this later). During this meeting, items from the Transformation backlog are transferred to the sprint backlog, which defines the work for that sprint. The sprint backlog provides real-time insight into the progress of the sprint. Each item on the sprint backlog will be assigned to a developer or small team of developers.
Each item on the sprint backlog moves through at least the following phases during that sprint:
Items might move forward and backward through the sprint phases, for example when work is reviewed and accepted (moving to Testing), or when work is declined during a review (Moving back to In-Progress or ToDo). The exact work to be done per phase, especially in the Review, Testing, and Acceptance phase will differ depending on the chosen platform and organization.
A sprint planning meeting is held directly before each sprint and is led by the Transformation Master. The Transformation Owner works together with the developers who will participate in the upcoming sprint, to select items from the Transformation Backlog and transfer them to the Sprint Backlog. The developers have the final say in the amount of work on the Sprint backlog. The Transformation Owner has a final say in which items can go on the sprint backlog.
The representative from the Platform Governance Process might be invited, as he might need to do some platform-related work as part of the sprint.
The transformation approach presented in this document does work with three levels of developers, as introduced earlier. Some developers work less than others, work on different days, and on different items.
The daily standup will still be held daily, and each developer active that day should join the daily stand-up meeting. Each developer should share his or her latest progress with the others and has the opportunity to request for help or insights during this meeting.
The meeting should take no longer than 15 minutes. Detailed help requests should be discussed outside of the meeting.
The Transformation Master typically joins this meeting, and the Transformation Owner is invited but could choose to join or pass the meeting.
The sprint review meeting is held at the end of every sprint. Its purpose is to showcase the done items, perhaps with demos, and receive feedback from the meeting’s attendants. Alterations or additions to the Transformation Backlog, as a result of the last sprint or recent events, can be discussed during this meeting and processed by the Transformation Owner.
Items that are not completed or “done” will be transferred back to the Transformation Backlog. Here, it is the task of the Transformation Owner in collaboration with the developers to stop further realization of Incrementals when ROI targets or general results seem unreachable.
Experimental items should be discussed during this meeting, no matter the results. Experimentals with promising results could be added again to the Transformation Backlog as an Incremental Item.
This meeting is an excellent occasion to also discuss the items who should be candidate for the next sprint.
As many relevant people as possible should be invited, at least including:
The meeting should last between 1 and 4 hours, depending amount of work which reasonably can be completed during a single sprint.
In contrast to the Sprint Review, the Retrospective event focuses on the Process. This meeting is meant to discuss the last sprint’s process and adjusts the process for the coming sprints. The meeting should last between 1 and 2 hours, depending on the duration of the sprint and size of the developers group.
Only developers who are active in the last or next sprint, the Transformation Master, and optionally the Transformation Owner are invited for this meeting.
Incremental items carry the cost of the transformation as they generate business value. This means that all start-up, platform, core-team, and Experimental-related costs should be allocated on Incrementals.
The transformation start-up cost during the first three transformation stages should at least be spread over Incrementals in a 2-to-5-year period, as this initial work will remain the valuable basis for the entire transformation.
Once the transformation arrived in the 4th and continues value-generating stage, it becomes more sensible to budget cost which is not directly allocatable to a single Incremental. These budgets can then be spread over Incrementals, realizing each Incremental to carry a part of the journey’s base cost. These budgeted costs during the fourth stage include platform base cost & maintenance cost, core-teams cost, and cost of Experiments.
Cost for a specific Incremental should be allocated to that specific incremental. These specific costs include some platform cost, as each incremental is using a certain amount of platform resources. The platform-related cost allocation could be harder to calculate in case of an on-premises implementation, or easier in case of a cloud subscription-based SaaS or PaaS platform solution.
The exact realization of this cost mapping is highly dependent on the platform’s implementation and organizational choices. Feel free to contact AIVHY Ltd for assistance in this matter.
Success needs to be celebrated and advertised. Realized ideas that improved the working environment of individuals or generate new business value need to be highly visible across the organization. The submitter of the idea should be publicly appreciated for his or her great idea, collaboration between departments should be highlighted, and the developers who realized the improvement should be celebrated.
It is crucial to motivate and empower your organization’s people who are willing to think and improve, as they drive the transformation and make a lasting difference for your organization. They know best where and how value can be generated, and they are in the best position to motivate the organization, from the inside, to adapt to changes and innovate. This is essential to make the transformation work.
Of course, some ideas are better than others. Even the idea submitters understand this and can handle honest feedback just fine. But do give them feedback! Not providing any feedback to idea submitters will slowly eliminate the support of the organization for the transformation, and with that the company’s future. Inform the idea submitters what is happening with their idea, why it might not now or never be executed, and help them to come up with better ideas in the future.
This methodology empowers you to get started and lead your company on the successful and lasting journey to uniform Industry 4.0. The journey and methodology should be tailored and adjusted to the organization’s needs in order to get optimal results!
Feel free to get in touch if you need any help or assistance with this exciting journey. AIVHY Ltd provides consultancy and a range of other services to help and guide organizations with this very amazing challenge. Our consultants are more than happy to set up a meeting. Our contact details are:
info@aivhy.com
+356 216 690 36
“AIVHY is looking for a passionate Industrial Digitalization consultant who would love to help companies with achievable innovation.”
“AIVHY is looking for a passionate Industrial Digitalization Engineer who loves developing and implementing digitalization solutions, based on the principles of Industrial IoT and Industry 4.0.”
Industry 4.0, an exciting future of digitalization, integration, and auto(no)mation. A future where organizations gain significant competitive advantage or fall behind. But what is Industry 4.0 exactly and what does it look like in the real world. Which challenges are there to overcome and how to do this?
This article provides an understanding in real-world Industry 4.0, lists achievable examples, and discusses the challenges that one most likely will encounter during the transformation. And finally, the article will introduce a comprehensive approach to the real-world Industry 4.0 transformation.
AIVHY | Soho office The Strand | Fawwara Building | Msida road | Gzira GZR 1401 | Malta
+356 216 690 36 | info@aivhy.com
© 2022 – Aivhy Ltd | Privacy