durand
durand
durand
durand
durand

The end user and the vendor are partners

Feb. 24, 2020
Insights from the IIC report on developing IIoT solutions.

The Industrial Internet Consortium (IIC) recently released “A Compilation of Testbed Results: Toward Best Practices for Developing and Deploying IIoT Solutions.”

We wanted to learn more about the white paper, so we connected with author Dr.

The IIC's Dr. Jacques Durand

Jacques Durand, member of the IIC Steering Committee and director of standards and engineering with Fujitsu North America, Inc. Take a look…

Smart Industry: What's a big misconception about IIoT project initiation?

Jacques: One misconception is that it is easy to know the end-user requirements. Requirements have two sides:

  1. Positive, i.e. what are the desirable improvements to achieve
  2. Negative, what are the constraints to comply with, the costs to avoid, including costs that are difficult to quantify, such as disruption, dependency on new skills for evolving a solution, fragility of a new process, added complexity or reconfigurations, etc.  In IIoT more than in other types of projects, requirements and hidden constraints will be unveiled over time and an IIoT solution will take time to adjust and settle. Plan for flexibility and change.

That business-related objectives can be set and committed to early on. An investigation phase is needed that has its own goals. Which technology? How to use it? What combination of technologies will help? Can we instrument this old equipment? What does the customer really want? What kind of disruption is acceptable/not? How committed is the end user operators or management? How much disruption can the end user take? What are the different options to explore? What is a reasonable time schedule?

Only then it is safe to set some business-related objectives and milestones.

Smart Industry: What's the most common brownfield constraint?

Jacques: Collecting data from legacy equipment. Heterogeneous equipment (machines, physical assets) are not easy to instrument to collect usage and status data. There is no silver-bullet solution. It is wise to define an investigation phase in the project to investigate this. The equipment vendor often needs to be contacted to explore alternatives or for reconfiguring the built-in data-collection devices.

Another side of data collection is capturing the context of use of the equipment: In which conditions was a machine used? What is the context of a machinery interruption? Skill and pressure of the intervening personnel? When the context is human operations, video signals have been used. When it is business data, coupling with back-end systems and ERP is important to contextualize data.

There is a limit to additional IT or monitoring equipment that the operational field and end users are willing to tolerate. Alternatives should be considered before adding more IT or sensor complexity that will need to be managed. IT skills are not necessarily available for this on a permanent basis. Reuse is better when possible, at least in a first phase, like reusing an in-factory LAN instead of installing a separate network, or using a production server to collect IIoT data instead of deploying a separate server.

Consider disruption caused by testing a solution in the real end-user industrial environment. Qualified personnel and needed resources may not be available on demand; have patience. There is not much time to test the system and change directions! Yet it is crucial to deploy and test the pilot as early as possible in real-world conditions. A lot more will be learned here than in lab testing. This true for AI systems as well. Advice: define a generous testing phase for this. Build a relationship with end-user personnel. Be there often.

Smart Industry: What is the most common mistake business leaders make in launching an IIoT initiative? 

Jacques: The below mistakes are more about project management. They all reflect on a higher management mistake that could be to not recognize the experimental aspect of an IIoT deployment. Many variables are not initially known that will only appear over time, during a pilot deployment and testing. It is a journey.

  • To believe that developing an IIoT solution is just a matter of a customer-vendor relationship. This should be a partnership. End users are partners in defining solutions; they have, in fact, the most valuable expertise about field operations and conditions. They own and understand requirements. Ideally, a team of partners should be put together: vendors, end user, third-party experts with different skills and backgrounds. Technology or product vendors tend to replicate what has worked for their past customers, but every IIoT solution is unique.
  • Not defining distinct phases of the projects and not defining clear metrics and targets for measuring what is supposed to be a success, at least for the very next phase, if not for subsequent phases (for which success may depend on the current phase results). This is a recipe for misunderstandings and disappointment. The process of doing this needs time and thinking, but will help clarify many requirements and hidden constraints.
  •  Overcommitting too early to business goals and not taking time to discover/assess hidden constraints. There is an experimental, unpredictable aspect to an IIoT project. Hidden constraints, limitations and costs take time to be discovered. This can be very disruptive and impractical. A successful demo is no guarantee for a viable solution over time.  

In general, and especially for specific technologies like AI, a successful prototype developed in lab conditions must be deployed as early as possible in real operating conditions (factory, etc.). Many adjustments will be needed when facing real-world conditions.

Smart Industry: Provide an example of a horizontal lesson from the testbeds that can be applied across IIoT deployments? 

Jacques: Project-management lessons: define an investigation phase first, which is not tied to business goals or pressure. Divide the project into phases that can be revisited.

The human side should not be neglected. Field operators can make or break the success of an IIoT solution. They should be empowered, not threatened. In many cases, the main value is visibility and better understanding of current operations, not so much increased automation. Personnel on site are empowered by the former, but threatened by the latter. In all cases, including AI deployments, human experts on the end-user side are key to the success of a solution.

Standards are a significant part of several testbeds...IoT standards, but also platform standards, specific technologies like localization or time-sensitive networks, etc. Reliance on standards will reassure end users and will help to scale up a solution, to interoperate better with the context. In the IIC context, governance of a testbed or pilot at the consortium level has some weight when submitting requirements for new or modified standards.

Smart Industry: Big picture: What's an overarching piece of advice for companies embarking on their IIoT journey? 

Jacques: Think in terms of team: stakeholders and partners in the project, both external and internal, with different interests. Seek the opinion of various experts and skills when developing a solution. An IIoT solution is part of a larger digital-transformation strategy for the organization, it has ramifications that should be thought through. The end user (customer of technology vendors) is a partner, not just a customer.

A successful system is a team effort, not a vendor feat. Business managers on the end-user side should also be stakeholders: the project will produce new business opportunities and challenge old models. Although there is some overhead in managing a disparate team, it will produce more value and stability over time than rushing to a demo.

Get the IIC white paper here.