There is no standard roadmap for OT/IT convergence, and eleven steps anyway

The most useful sentence in the Cigref report on IT/OT convergence is also the least satisfying.

There is no single organisational model or convergence roadmap. The right organisation is for each company to find, by enabling porosity and understanding between IT and OT teams, pooling skills and distributing responsibilities.

Consultants rarely quote it, because it undermines the premise of selling a methodology. It is still correct. But "no standard roadmap" does not mean "no structure", and the working group set out eleven steps that hold up well against what actually happens on site.

This is part 3 of 9 of the “OT/IT convergence” series; it follows part 2, what stops a programme and continues with part 4, measuring maturity.

The eleven steps

1. Identify the catalysts. Recognise what is actually triggering convergence here (a regulatory deadline, a data project, an incident, a new plant), and who is involved. A programme with no named catalyst has no sponsor either, and it will be the first thing cut.
2. Establish the current state. Assess what exists to determine needs and opportunities. It is the step most often skipped and the most expensive one to skip. The next article is entirely about doing it properly.
3. Recognise the specifics. Understand the differences in constraints, business processes and risks, and how much the two domains depend on each other. A one-day workshop will not do it; each side has to learn what the other actually carries.
4. Define vision and objectives. A shared vision and strategic objectives, backed by a sponsor at executive committee level. Without that sponsor, steps 6 to 11 do not survive their first budget cycle.
5. Create a space for experimentation. A shared place to try things and exchange knowledge, so that the two cultures start converging in practice and not only in policy. Cigref lists it as optional. In our experience it is the cheapest item on the list and one of the most effective.
6. A unified technical policy. A common technical policy and an overall information system architecture, data flows included. The data flow part is usually deferred, and then it decides every segmentation choice downstream.
7. Rationalise and standardise. Fund the reduction and standardisation of the technologies in use. Every non-standard component is a permanent tax on every later project.
8. Governance and organisation. Revise the governance of the systems concerned and the organisation end to end, with a common career path for managing skills and resources.
9. Monitoring tools. Shared reporting, common key performance indicators and a shared risk map. Shared KPIs matter more than they look: two teams measured on contradictory metrics will behave contradictorily, whatever the governance document says.
10. Support the change. Accompany the change, then roll out and industrialise the new practice. Covered in depth later in this series.
11. Publicise the wins. Communicate successes and their value to the business and to each function, in parallel with the work. Call it vanity if you like; it is how the sponsor from step 4 stays a sponsor.

What the list assumes but does not say

Three things are implicit in that sequence. They are worth spelling out, because that is where programmes go wrong.

First, the order matters. Steps 6 and 7 depend entirely on step 2 having been done honestly. A technical policy written against an inventory you assumed rather than checked describes an imaginary plant. In the same way, the shared risk map of step 9 needs the mutual understanding of step 3, or the two teams score the same risk differently and the map is noise.

Second, collaboration, pooled skills and a clear split of responsibilities have to exist, at least in embryo, before the programme starts. The report says convergence requires all three. If they are missing on day one, the eleven steps will document the disagreement instead of resolving it.

Third, the experimentation space carries more weight than it seems. Step 5 looks soft next to the others. It is where an IT engineer learns why a control engineer refuses a reboot window in the middle of a campaign, and where the control engineer finds out what the unpatched Windows 7 station beside the packaging line really exposes. No slide deck produces that understanding. People working on the same problem in the same room do, on a test bench where nothing breaks if they get it wrong.

The uncomfortable implication

If there is no standard roadmap, the outcome depends on the judgement of the people running the programme more than on the method they adopt. It is an unfashionable conclusion, and it is why the middle articles of this series deal with organisational models and with the human factor rather than with technology.

Next: how to establish the current state, digital maturity assessment, and the BioPhorum model.

The eleven steps are from the Cigref report cited below.

References

• Cigref, Convergence IT-OT : un rapprochement fructueux des systèmes industriels et des systèmes d’information, December 2019. cigref.fr