Now, this depends on what exactly you're trying to accomplish with an IIoT adventure, but for most companies I would issue the following advice:  if your plan involves a charter or a steering committee…

You are hosed.

Let me expound on that a bit. 

Industrial IoT is a very short acronym that hides an enormously complex system, full of devilish little details.  So companies tend to treat it the same way they treat any major project, by throwing resources at it under the command of the Gantt Chart Brigade.  You see, project management in industry relies on ignoring or sweeping under a rug the minor details that get shaved off when a square peg is forced through a round hole.  Sometimes your accounting software can only ingest XML, so you have to create an intermediary batch process to transform your SQL every morning; sometimes you can't use the RS232 port and have to pipe out through 485 then join that up to 232 with an addiitonal hardware step; internal counters sometimes are cumulative that can only reset when they reach their byte limit instead of a button, so a human operator has to denote intermediate timestamps.  Things like these are easily solved by throwing human effort at the problem, and usually get relegated to footnotes on the big PowerPoint slide that screams SUCCESS.

Well….there's a few problems with that strategy in IoT.
 

1. There is no PM on the planet who understands the full breadth and depth of implementing a system like this.  You need
   electrical engineering knowledge at the bare metal level (you're bifurcating off from SCADA so the OPC/SCADA crowd normally assigned to this won't work; you have to negotiate directly with the PLC and sometimes with the sensor itself),
   telematics (which in of itself is a huge problem as it's a very broad and rapidly evolving field with no formal education possibilities),
   cloud architecture,
   data engineering (streaming data is a whole different ballgame),
   potentially data science,
   cybersecurity (which causes immense amounts of problems as ICS has been effectively unsecured for 50 years), networking;
   and all that is for retrofit of existing- if you need to install new now you have to coordinate all of that with the contractors designing and installing the new system(s).
    
2. Machines don't do exceptions.  They don't give a shit about your intermediate break/fix processes.  In a non-streaming world, you can do all manner of conversion and logic exceptions in the gaps between steps of the process; but when data streams from machine to machine everything must be precise.  The metaphorical square pegs must be lathed to a cylindrical shape with very specific tolerances as they're passing from one round hole directly to another in series and if one stops all the pegs behind it jam up.  If one tag stops reporting in and the json schema expects it to be there, the whole system breaks down.  Modbus RTU doesn't do authentication, and converting to Modbus TCP is a train wreck, so your security team is going to want additional hardware or routing on top of a hardware stack- which may or may not cause issues with your telemetry.  Some machines don't have a RS232 port; some only have a 232 that is used for both telemetry and diagnostics/config; some machines only speak German (seriously) and of course because of string length limitations and the German language you now have non-standard abbreviations of highly technical terms; sometimes you're getting composite ASCII strings that contain key-values, sometimes you're getting discrete data types from the registers and coils.  Any of these details may seem minor but can easily cascade to catastrophic failures in the system.
    
3. There's no cavalry coming.  It doesn't matter who you call: McKinsey, Bain, Gartner, PWC, Deloitte, even Microsoft or AWS; none of them can help you implement the full system because no one entity has ever done a full system.  Everyone wants to pass the buck at some phase and defer you to 'one of their trusted partners'.  Which is a fine approach, as long as you have your entire future plans drawn up at runtime (you're shit out of luck if you need to go back and wire up another sensor); and you don't mind paying an assload of money for the privilege of piecemealing out work to consultants.
    

So what to do?  Well, any great project is done by persons - not 'roles' or 'titles'.  Just as IIoT is far outside the traditional industrial thought box, you have to start thinking outside the traditional HR box.  You have to find the individual persons who bridge these venn diagram gaps of knowledge, and you're going to have to pay them what they're worth (as they are exceedingly rare), and you're going to have to impart authority (notice I did not use 'empower' here as it's a hollow buzzword) to them.  Consolidate the holistic knowledge and skills necessary to understand the project in its full scope to as small a team as possible, and that is your 'steering' committee.  Otherwise you will be mired in endless explanations, political posturing over butthurt feelings, and meetings to schedule meetings to talk about meetings with 3rd parties.

Or you can just hire us.

🙂