Building a standalone solution based on sensor technology is relatively straight forward if you have a decent understanding of the different sensors available, their specifications and limitations. You know how to filter, aggregate, extrapolate and interpret the data they produce, converting large volumes of data into more manageable information. Your sensor may already be capable of communicating its unique ID, but because you will want to identify what caused the data change or what it is linked to, you need to read a serial number, bar code or RFID tag of whatever it was that was producing the ‘events’ at the time they were created. Each brings its own set of variables and limitations into play and choice will be governed by operating environment and conditions.

Data possibly already exists scattered across multiple enterprise systems and sensor data can render this more meaningful or needs to be combined with or fed into the sensor data results. Either way you will be linking disparate data across physical and organisational boundaries

Of course your sensor solution will be somewhat more ambitious than illuminating a LED when the temperature gets too hot or warning that vibrations in a bearing exceeded preset threshold levels.

The real value comes from the design of the decision support systems and will be your reasons for developing the solution in the first place. You will have identified and established which processes you wish to improve or control and you will know how to communicate with and interface to your existing business processes and IT systems. Decision support algorithms will again filter and aggregate the information further refining it into something that could be called knowledge.

Effectively closing the information loops, will finally generate the knowledge which allows you to start exploiting the results of your solution and changing the way things were done before, assuming you are able to make it available to the right people or systems at the right time. Communicating or sharing knowledge per se brings up a few additional considerations. Who has access to what, push or pull? Security can be a potential show stopper unless properly addressed and ‘sold’ to all levels of people involved.

Should it be a standalone solution or would it be more sensible to have this new solution able to communicate with similar solutions? Either built by you or those produced by your competition? What happens if a merger or demerger changes your IT environment? Will you lose the results of your investment, your business advantage? What standards exist in all of the above technologies?

Vision does not guarantee success. In today’s investment climate your chances of getting your project approved are slimmer than ever before. You will have justified the costs even before you started. Is your solution intended to improve quality, reduce costs, improve image or add value to your existing products? Could it allow you to develop an entirely new business model? Can it differentiate you from the competition? Is this your ‘Blue Ocean’ opportunity?

Can all this prerequisite knowledge really exist in one enterprise?