A comprehensive guide to Real-World Industry 4.0

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.

The Master Plan of Approach

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.

Master Plan of Approach Philosophy

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:

Individuals become highly motivated to make their solution work as part of the transformation. They will personally experience the benefits, and the solution will be his or her brainchild worth fighting for.
He or she will naturally create curiosity amongst direct colleagues, creating intrinsic motivation for journey participation from within the organization instead of via expensive and exhausting change programs.
This approach keeps the knowledge and experience within the organization, instead of a single individual or external resource.
It will reduce "island culture" and naturally integrates the organization horizontally and vertically.
This is the most cost-efficient approach to Industry 4.0.

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.

Before we start

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:

Provide Industry 4.0 transformation specific expertise and experience.
Lead, guide & facilitate the transformation process.
Do most of the work during the first three stages, relieving the organization.
Translate between disciplines, like technical and financial aspects to a functional level where every core-team member can develop an opinion and participate in the subject.
Provide wanted and unwanted advice.
Ask smart questions and challenges answers, results, and idea’s.
Facilitate decisions (but not necessarily make them).

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.

Warm-up phase

The warm-up phase is meant to create an initial support base for the organization’s transition to Industry 4.0.

STAGE 1: Create Awareness

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).

STAGE 2: Proof Real-World Value

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:

PoC requires a low budget, reducing barrier to entry.
Has high potential for value gain & success, resulting in a good ROI.
Gain value for one or multiple individual, for example making a task easier, more fun, or less boring.
Can be realized in a period between 1 and 4 weeks.

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:

1 day Select PoC & estimate ROI
1 day Draft high-level competing solutions
¼ day Select solution (and order parts if necessary)
¾ day Determine KPI’s to proof success
2 to 15 days Build Prototype
1 to 2 days Test prototype & Proof Concept success

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.

Transition phase

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.

STAGE 3: Envision, Strategize & Master planning

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.

Core-team

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.

Re-Imagine the future (Brainstorm)

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:

Mind Mapping
SWOT
Reverse brainstorming Think of problems instead of potential
Triggered brainstorming Triggering by open sentence like “production loss is caused by ___”
What if brain storming Answering open questions like, What is Superman had to fix this problem?, What if we were loosing against competition?, What would competitors do?

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!

Defining future goals

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:

1: Ensure the Core-Team knows and understands the organization's business strategy and business goals.
2: Remove or hide ideas from the brainstorm session, which are not likely to be realized. Our suggested approach is to remove ideas with a summed-up rating of 7 or higher.
3: Summarize the remaining brainstorm ideas in bullets, defining a draft long-term heading. This summary and its bullets must fully align- and be written- with the business strategy and business goals in mind. Harmony and alignment with the business strategy and business goals is a must. The heading should not contain any details or specifics.
4: Re-adjust the heading as new insights are found during the baseline determination and market research, described later in this document. The heading can be freely adjusted as long as the journey is in the 3th stage.
5: Challenge the heading with the company’s top management.

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:

1: The brainstorm ideas were categorized by vertical layers and colors. Strategically select categories on which the mid-term goal focuses.
2: Select ideas within the selected categories to potentially address within the duration of the mid-term goal. Ideas which were hidden or removed during the definition of the long-term heading can not be used for mid-term goal defining.
3: Define SMART mid-term goals on a 3-to-5-year level, based on the selected ideas. The mid-term definition should not contain individual ideas.
4: Ensure alignment with the earlier defined long-term heading.

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:

1: Select ideas from the sub-set of ideas, selected during the definition of the mid-term goal.
2: Define SMART short-term goals on a 1-to-2-year level, based on the selected ideas. The short-term goal definition should not contain individual ideas.
3: Ensure alignment with the earlier defined heading and mid-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.

Research market & determine baseline

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

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:

Cloud data & IoT services
AI Platforms
Big Data solutions
Data Science solutions
IoT & smart sensors
Industrial Data Acquisition systems
Centralized operational- or resource-managements systems like MES, MOM, TOS, LIMS, ERP, ...

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:

Ensure that the supplier understands that this meeting is meant as an introduction to learn what the supplier has to offer to your organization in relation to the industry 4.0 future heading and mid-term goals.
Share relevant information about your organization, challenges, opportunities, and future ambitions in order to enable the supplier to tailor the introduction meeting.
Ask the supplier to elaborate on their product range and to share their experience with previous similar projects.
Ask the supplier to elaborate on scalability of their products and solutions, both in technical as cost perspective, as this is essential for the bite-size incremental step concept of this approach.
Ask the supplier about openness, connectivity, and standardization of their products in order to determine the potential position of the product or solution in the bigger picture.

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:

Suitability of the product range in relation to the heading and goals.
Openness, connectivity, and standardization of the solutions.
Scalability of the solutions in technical and cost perspective.
Experience and Knowledge level of the supplier.
Scale of the vendors organization, and likeliness of long-term partnership / support.

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).

Determine Baseline

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

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:

Current connections between systems.
Possible connectivity options and all the system’s interfaces.
Accessibility of data within these systems.
Potential to modify these systems.
Mark any systems which are scheduled for replacement or upgrade.

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:

Machines, equipment, controllers, sensors, other OT, and IoT.
Third or Fourth generation SCADA systems.
Data acquisition systems.
Big Data solutions and tooling.
Data Science related systems and cloud services.
Any centralized operational or resource management systems like MES, MOM, TOS, LIMS, WMS, CMMS, or ERP.

Organization

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:

Attitude and will to change and innovate.
Will to actively contribute to a better future for individuals and the organization.
Estimated number of early adopters (those who are likely to be the first to contribute to incremental steps to Industry 4.0.)
Current knowledge level regarding Industry 4.0.
Fear of job loss as a result of Industry 4.0.
Amount of time that could be spent by the organization’s individuals to contribute to the journey.

Financial

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:

A small initial investment needs to be made to kickstart the journey. What commitment can be made to this initial investment?
A platform will be selected via a tender. This platform will be initially small but expanding significantly over time. Make sure that this expansion over time fits with internal tender and purchasing rules, without being forced to re-tender for each expansion, as this might result in scattered systems over time which negatively influences the journey in every aspect.
Does the organization’s financial system allow to reallocate returns on incremental steps to fund new incremental steps? This is required for the self-sustaining aspect of the journey.

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.

Platform

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:

Scalability, both in technical aspects and in cost through incremental progress.
Spreading of cost over time and improving cost effectiveness.
Horizontal and vertical integration and standardization.
Low barrier to improvement and innovation.
Reusability and uniform accessibility of data, features, and solutions.
Maintainability in short and long term.
Data governance and privacy.
Cyber Security by design.
Legacy system support.

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:

Result in scale-discounts.
Requires the organization to work with less different systems, allowing for a much deeper understanding of these systems.
Increases integration, as fewer systems need to be integrated, but at a deeper level.
Forces different departments to collaborate, boosting cross-departmental collaboration when guided properly.

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 support in Industry 4.0

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.

Platform architecture & systems selecting

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.

Request for Information (RFI)

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.

Request for Proposal (RFP)

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:

Possible platform architectures.
If products and solutions fit in a platform’s architecture and the long-term picture.
If proposed solutions are scalable, starting small and gradually expanding into the full-blown Industry 4.0 implementation.
What the cost and licensing structure looks like, what the initial investment would be, and what the cost of gradually expanding the platform in small steps looks like.
How flexible the solution is, and how well it is adaptable to the organization’s needs.

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.

RFP platform specification

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.

RFP specification checklist

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.

Introduction

Clarify the approach of the journey to Industry 4.0, based on small incremental steps and small investments to a lasting and uniform future of Industry 4.0.
Define what is meant by the platform:
- A set of systems as part of a scalable architecture, where each system has a clear functionality and purpose with minimal overlap between them, together resulting in the entire technical implementation of Industry 4.0 within the organization.
State the purpose of these specifications, being:
- Receiving a proposal for the design of an architecture and selection of systems in it, that suits mid-term needs and long-term incremental scaling towards the future heading.
Clarify that this specification describes the requirements for the fully implemented future platform and each of the subsystems.
Clarify that the initial purchase of the platform will only include a small part of the full future platform design, and the implemented platform will scale up as the journey to Industry 4.0 unfolds.
Required detailing level of the supplier’s proposal:
- Sufficient detail on the mid-term goal, displaying how mid-term goals are achievable with the proposal.
- High-level details in relation to the long-term heading, ensuring that systems and the mid-term implementation, would perfectly fit in the larger architecture in later stages when further growing towards the long-term heading.
Inform the supplier that his insights, comments, feedback, and critics on this specification, mid-term goal, and long-term heading are highly appreciated. Feedback might be processed and become part of the RFQ.
Clarify that a proposal is allowed to only offer a part of the total platform implementation. Partial proposals should still propose an architecture with their solution in it, and mark the other required systems out of their scope as grey “function-boxes”. The partial proposal might include suggestions for other supplier’s products, to fill in the gaps.

Short-term goal, Mid-term goal, and long-term heading

Include the short-term goal, mid-term goal, and long-term heading, allowing the supplier to tailor the proposal to the needs and envisioned future.

Future platform functionalities

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:

Process monitoring, scheduling, Track & Trace, and control features.
Data Science, Data analytics, data exploration, data catalog functionalities.
Data visualization and dashboarding functionalities.
Scripting and other customs task functionalities.
Support for 3D printing. (3D printers are not part of the platform but might be controlled & managed by the platform.)
Event & KPI functionalities.
Reporting functionalities.

Platform Architecture

Platform Architecture requirements might describe:

A Decentralized, Cloud, Client-Server, Three-Tier architecture.
Availability and redundancy requirements.
Use of edge nodes and/or IoT gateways.
Cyber Security aspects of the architecture.
Existing systems that will take part in the platform.
Integration with the existing environment.

(Advanced) Human Machine Interfacing (HMI)

(Advanced) Human Machine Interfacing (HMI) requirements, which could requirements in relation to:

Web-based, application-based, and/or mobile app-based user interfacing.
Advanced Human Machine Interfacing requirements, like Augmented Reality and Virtual Reality.

Use

Use requirements should describe the requirements for use, which might include:

A description of who is going to use the platform and how.
A description of what type of users are going to work with the platform.
A description of who is going to change, alter and develop on the platform.
Requirements stating how the platform must deal with multiple users developing simultaneously.
Requirements in relation to remote access to the platform.

Test environment & playground

Test environment & playground requirements might include:

Specify a test environment and/or playground, allowing for safe development and experimentation during incremental steps on the journey to Industry 4.0.
Think carefully about the needs during development when specifying the test environment and playground. Examples of such needs might include: A representative test environment and playground, available test and perhaps real-time production data, simulation tooling, unit testing tools.
Specify how the platform should facilitate development by “Untrusted” and/or remote working external developers. This requirement will bring great potential to out-sourcing particular tasks or incremental steps.
Define requirements in relation to the release pipeline, which enables controlled release of approved developments.

Data and connectivity

Data and connectivity related requirements:

Specify Connectivity, Data acquisition, and Bi-directional interfacing requirements. These requirements might include and relate to:
- OT systems, like PLCs, DCSs, VFDs, RTUs, SCADA.
- OT busses and interfaces, like PROFINET, EtherCAT, EtherNet/IP, etc..
- IoT devices.
- IT systems (upward & downward).
- Support for future protocols like MQTT, OPC DA, OPC UA, AMQP, REST, SOAP.
- API support.
- Support for common file types like CSV, flat files, and Excel files.
- Via the currently available interfaces, including legacy systems (include the technical baseline, created earlier)
Define requirement, or let the supplier comment, on the following properties for the proposed solutions:
- Supported data types and formats.
- Data acquisition sample times & throughput, mainly related to process data acquisition.
- Max number of tags or data flow to be handled by the proposed solution.
- Methods and systems for data storage, and options for standardized connectivity to these systems.
- Data catalogs and Metadata capabilities.
- Methods for structuring, organizing, modeling, and accessing Real-Time and Historic data, ensuring scalability over time.
- Data quality management.
- Openness and accessibility to all data stored within the solution for third-party systems via standardized interfaces.
Make a statement about data ownership and the right to share data, especially for Cloud solutions.
Data Governance requirements:
- Define requirement for Access control to data, and segments of data.
- Define requirements for Privacy, GDPR, and Anonymizing data.

Logging

Logging requirements might include:

State requirements in relation to logging of access, authentication, activities, data use, internal events, etc.

Cyber Security

Demand Cyber Security By Design:

Define applicable Cyber Security Standards like, IEC 62443, ISO 27001, NIST CSF, or CIS
Required Cyber Security level in relation to the requested standard.
State additional requirements regarding zoning, firewalling, encryption, and hardening.
State requirements regarding breach detection and data security.
Ensure alignment & integration of the specification with the organization’s Cyber Security strategy.

Identity & Access Management (IAM) / Identity Governance & Administration (IGA)

Identity & Access Management (IAM) / Identity Governance & Administration (IGA) requirements:

List requirements regarding IAM / IGA including SSO, MFA, RBAC.
State user management requirements.
State integration requirements with current user & domain management systems like Active Directory / LDAP.
Define IAM integration in the different aspects of the proposed solution.

Maintainability

Maintainability requirements:

Define back-up and restore requirements for the platform or parts of it.
Define patch, upgrade, configuration, and change management requirements for the platform and its configurations.
Define backward capability requirements, relieving pressure in case of partial or stepwise upgrade of the platform.

Scalability, Cost, and Licenses

Scalability, Cost, and Licenses requirements:

State clearly the requirement to stepwise scale up the platform.
Request the supplier to share its cost & licensing structure, as this is essential for the incremental growth of the journey and the platform.

Ownership and modification of the platform.

Requirements related to ownership and right to alter, change and modify the platform:

Incremental steps are realized on the platform by members of the organization and perhaps third parties. This requires a certain level of modifiability of the platform and its configuration.

Deployment & SLA

Requirements related to Deployment & SLA’s:

Define who should perform the initial platform deployment.
Define the Service Level Agreement.
Define who will maintain the platform.
Are updates & patches included?
Initial user and developer training.

Documentation requirements regarding:

Requirements related to documentation:

Architecture documentation requirements, including both the current systems, initial platform, as the future growth.
Instruction and training material requirements for both use and development on the platform.

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!

Request for Quotation (RFQ)

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.

Implementation

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:

Scalability of the individual systems.
Scalability of the system as part of the platform.
Scalability of the platform as a whole towards the mid-term goal and future heading.
Ensuring Cyber Security by design.
Integration with other parts of the current & future platform, and systems within the organization.
Intended use of the platform and its systems, and the translation of this to implementation & configurational choices.
Data governance & privacy implementation in relation to scalability.
Avoiding duplicity and overlap.
Scalable Identity and Access Management (IAM).

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.

STAGE 4: Self-sustaining Transition

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.

Strategic processes

As mentioned, strategic goals are meant to guide, govern, and empower the entire transition to Industry 4.0. There are three strategic processes defined.

Transformation governance

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:

Review the period since the last review.
Make adjustments to the transformation process and organization to improve the journey and its lasting results.
Set and adjust targets for the KPI’s of the other processes.
Asses and revise of the short-term goal, mid-term goal and long-term heading.
Initiate platform expansion and up-scaling.

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.

A small recap

The long-term heading defines where the organization roughly wants to go in the long term and allows all decisions to align with a long-term vision.

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.

Training, Guidance & Engagement

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:

Advertise the journey and the role of individuals in the transformation.
Provide training to the organization for use of the platform and realization of ideas.
Encourage, facilitate, and manage submission of new ideas & proposal.
Encourage individuals to realize their own ideas as part of an incremental or experimental sprint.
Provide guidance and assistance to those who are realizing their ideas.

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:

What is your idea?
Description of the opportunity or problem your idea is addressing.
How would you realize your idea, and what does it take to realize it?
What would your idea cost to realize? The answer might be given in Euro’s or in any other quantity like man-hours, parts, etc.
What kind of value, profit or return will your idea bring? The answer might be given in Euro’s, or in any other quantity like saved man-hours, saved material, less waste, higher quality, less down time, etcetera.
When do you consider your idea realized? In other words, when would you say your idea executed? (Definition of Done)
Do you want to help with the realization of your idea?
What is your name and phone number or mail address, the date, and department or process on which the idea applies?

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

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:

Updates & patching.
Technical exception handling, breakdown handling, and trouble shooting.
Maintenance and alteration of the platform’s configuration.
Data governance, including maintenance, cleaning, and alteration of:
1. Data acquisition
2. Data structures
3. Data access
4. Privacy and privacy-sensitive data
Identity and Access Management (IAM)
Maintenance of documentation and instructions.
Scaling of systems within the currently existing architecture, limited to:
1. Scaling licenses
2. Adding modules
3. Scaling configuration

All Platform Governance activities should be executed in line with the earlier made decisions, mainly defined and documented during the implementation of the platform.

Transformation Processes

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.

Transformation Owner

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.

He is:
1. Core-Team Member
2. Entrepreneurial thinker
3. Deeply aware of the long-term heading and short- & mid-term goals
Accountable for:
1. Maximizing value creation per sprint and overall
2. Alignment of the journey with the heading and goals
He does:
1. Interact with Core-Team & Stakeholders
2. Ensures maximal value creation
3. Filter transformation backlog input and manages the transition backlog
4. Defines the sprint planning and Sprint Backlog with the developers

The task of the Transformation Owner could be fulfilled by the Transformation Leader.

Transformation Master

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.

He is:
1. Core-Team Member
2. Facilitator and Servant Leader
3. Coach, Mentor & Teacher
Accountable for:
1. Guiding and Facilitating the Transformation process, both within the Transformation Team as its interaction with the organization.
He does:
1. Enable developers to work on the development with minimal distraction.
2. Ensure the developer availability for the amount of hours agreed with the organization. This is crucial for developers who are developing their own idea, as they are most likely part of the organization and have other duties which might distract them.
3. Facilitates the process.
4. Ensures agility of the process and organization.

Developers

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:

It is easier to teach a willing individual how to use the platform and tools to realize an idea, than to train an experienced developer all the ins and outs of the idea and opportunity.
The idea submitter, who is now implementing his or her own idea, will become the biggest supporter of this value generating implementation. He or she will likely not only promote use of the idea within the organization, but also the Transformation as a whole.
The idea submitter will most likely now search even harder for value generating idea’s, will post ideas of higher quality, and will be able to implement his or her second idea with much more ease.
This will further and further engage the organization over time, as success is shared from within. New ideas will become of higher quality and value over time, as individuals understand the goals and needs of the transformation to Industry 4.0 better and better. Realization of ideas will go smoother and smoother as more individuals within the organization gain experience in development.

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.

Stakeholders

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.

Transformation Backlog

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.

Item refinement

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:

Why does this item need to be done?
- How value will be created in-line with the transformation goals.
- SMART formulated Targets.
- Expected ROI. (Only for Incrementals)
What needs to be done?
- List of deliverables.
- Functional & Technical description.
- Test and acceptance specification.
- Deployment plan, describing technical and organizational deployment. (Only for Incrementals)
Definition of Done (Test & Acceptance criteria)
1. Reviewed deliverables.
2. Ensured compliance with platform guidelines. (Only for Incrementals)
3. Successfully completed test & acceptance specification.
4. Verified that SMART targets & ROI are met. (Only for Incrementals)
5. Documentation is written or updated.
6. Ready for deployment (Only for Incrementals)

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.

Item organization

All items should be tagged, providing insight in their nature, allowing filtering and search. Tags could be:

Experimental item, Incremental item
Idea, bugfix, Requirement, Enhancement, …
Urgency from business or operational perspective (in Months)
Estimated ROI (months)
Required investment (in currency, perhaps including man-hour cost)
Required work (man-hours)
Chance of success (in %)
Item / Idea submitter (Name)
Stake holders (Names)
Technical categories (as used during the brainstorm session)
Term (short-term, mid-term, aligning long-term heading)

Sprint

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:

To do
Items to be done during the sprint.
In-Progress
Items being done during the sprint.
Peer Review
Finished items being reviewed.
Testing
Items being tested.
Acceptance
Items being verified against acceptance criteria.
Done
Done items.

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.

Transformation events

Sprint planning

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.

Daily standup

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.

Sprint review

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:

Developers who worked as part of the last sprint.
Stakeholders who have a stake in the items completed during the last sprint or have a stake in the next sprint.
Anyone who might be interested.
Transformation Owner.
Transformation Master who leads the event.

The meeting should last between 1 and 4 hours, depending amount of work which reasonably can be completed during a single sprint.

Retrospective

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.

Cost allocation

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.

Feedback & celebration

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.

Now go start that journey to Industry 4.0

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

Real-World 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.

What is Operational Technology (OT)?

Operational Technology (OT) is hardware with a digital or electronical core or software, that interacts with the physical world. This interaction includes sensing, actuating, direct monitoring and direct control of physical systems and processes.

OT Cyber Security is different

Cybercrime could be a highly lucrative activity. Information could be stolen and sold, operations could be disrupted as paid criminal service or an entire company could be taken hostage for ransom. As soon as a company has value, it becomes a potential target for Cybercrime.

Recent development in digitalization and Industry 4.0 likely render OT environments not only defenseless against Cybercrime, but could even create a hard-to-close backdoor into your digital organization! IT Cyber Security applied within the OT environment will proof to be a poor fit. This is why OT Cyber Security must be approached correctly and prioritized at C-level.

AIVHY

Services

Expertise

+356 216 690 36 | info@aivhy.com