A practical approach to collaboration

In our recent meetings with Taiwanese companies, we saw a clear understanding of how each business contributes to the IoT value chain. The companies we met had defined areas of expertise. Some focused on hardware and connectivity, while others worked with sensors, gateways, energy systems, communications or software.

This kind of focus can help customers bring together the capabilities an IoT project needs. A company does not have to supply every layer of a solution to play an important role. It can concentrate on its strongest capability and work with partners whose products and services complement its own.

IoT projects often span devices, networks, data platforms, applications and services. When suitable partners can work together across those layers, customers have more ways to shape a solution around their operational needs.

FAVORIOT’s role in the stack

FAVORIOT provides an AIoT platform for operational visibility. It helps organisations collect data from connected assets, see what is happening and respond when action is needed.

We can work alongside companies that bring the sensors, devices, gateways, connectivity, specialist applications, deployment expertise or customer relationships. Each partner contributes a part of the solution, while the customer gets a clearer view of how the parts can work together.

Our aim is to make the platform useful within a wider ecosystem. Partners can bring their existing strengths and customer knowledge, while FAVORIOT provides the platform capabilities needed to connect data with operational awareness.

What customers can gain from multiple partners

A partner network with complementary capabilities can support customers in several ways:

• A more complete solution: Customers can bring together devices, connectivity, platforms and services from companies with relevant expertise.
• Clearer ownership: Each partner can define the work it is equipped to deliver and support.
• Access to more markets: Partners can introduce the group to customers and regions that may be difficult to reach alone.
• Quicker project starts: Existing products and experience can help teams avoid rebuilding every part of a solution.
• More suitable options: Customers can choose technologies that fit their budget, site conditions and technical requirements.
• Greater confidence: A customer’s trust in one partner can help begin conversations with other specialists in the group.
• More than one route to market: Partners can bring opportunities through different sales channels and customer relationships.
• Shared growth: A successful deployment can create new opportunities for services, joint offers and expansion into other markets.

Good collaboration starts with a clear understanding of the customer’s problem. The partners then need to agree on the project scope, responsibilities and how their products or services will work together. That gives each company a practical basis for contributing.

Making every role count

Our meetings in Taiwan reinforced the value of companies being clear about what they do well and open to working with others. For FAVORIOT, that means focusing on our role in operational visibility and connecting our platform with the strengths of partners across the IoT stack.

Customers benefit when the team around them brings the right capabilities and works towards a shared outcome. Partners benefit when they can contribute from their area of expertise and reach opportunities together.

That is the kind of ecosystem we want to build: each company brings a clear strength, the parts work together, and customers gain a practical path from connected assets to better operational awareness.

If you want to be part of Favoriot partner, contact us here.

Many facilities already generate large amounts of electrical data. The challenge is often not whether the data exists, but whether operations teams can see and understand it at the moment when action is still possible.

Maximum Demand provides a clear example. When multiple electrical loads operate simultaneously, total demand can rise rapidly. If operators only discover the peak through a later electricity bill or periodic report, the financial impact has already occurred.

An Operational Visibility approach changes this by connecting field measurements to continuous monitoring, alerts and historical analysis.

From Electrical Equipment to Operational Information

A real-time monitoring architecture can begin with electrical parameters such as voltage, current, power factor and demand.

These measurements can pass through industrial communication protocols and edge devices before being transmitted to an IoT platform. The platform then becomes the operational layer where data is stored, visualised, analysed and converted into alerts or other actions.

The architecture can be viewed simply as:

Physical Asset → Measurement → Connectivity → IoT Platform → Visibility → Action

Each layer serves a purpose, but the business value appears at the final two stages.

Connecting equipment alone does not solve operational blindness. The data must become understandable to the people responsible for operating the facility.

What Operational Visibility Changes

With continuous visibility, operations teams can move from asking what happened last month to asking what is happening now.

They can monitor whether demand is approaching a threshold, identify unusual changes, compare current conditions with historical patterns and investigate what operational activities coincide with peak periods.

In a real-world implementation, a monitoring system captured a demand peak of 664.8 kW, compared with a 680 kWMaximum Demand recorded for billing.

The significance is not simply measurement accuracy. It demonstrates that operational data can become visible while events are unfolding rather than after their financial consequences appear.

Connect, See and Act

This represents three fundamental stages of operational visibility.

Connect physical equipment and collect meaningful data.

See equipment conditions, patterns, abnormalities and changes as they occur.

Act through alerts, operational responses, maintenance decisions or automated rules.

Artificial intelligence and machine learning can extend this model further. Historical data can be analysed to detect abnormal consumption, recognise patterns associated with demand peaks and provide earlier warnings.

The system can gradually move from telling operators what is happening toward helping them understand what may happen next.

The Bigger Opportunity

Maximum Demand monitoring is only one use case. The same architecture can be applied to pumps, HVAC systems, generators, water infrastructure, renewable-energy assets, industrial machines and equipment distributed across remote sites.

The common problem is operational blindness.

Equipment may already be producing signals about changing conditions, but those signals often remain trapped inside machines, controllers, meters or isolated systems.

An Operational Visibility Platform connects those signals to the people who need them.

The objective is not to create more dashboards. It is to reduce the time between something changing in the physical world and somebody being able to respond.

That is where connected data begins to create operational value.

[Note: This is one of Favoriot‘s Use Case – Energy Monitoring]

The sensors are connected, data is reaching the cloud, dashboards are displaying information correctly and alerts are being generated. From a technical perspective, the IoT pilot has achieved what it was designed to demonstrate.

Yet this is often the point where the harder part begins.

At FAVORIOT, our experience working with IoT projects has taught us that proving a technology works does not automatically create a reason for an organisation to deploy it across more assets, sites or facilities. A technically successful pilot can still stop because the project has not demonstrated enough operational value to justify what comes next.

This distinction has changed how we believe IoT projects should be approached.

IoT Has Become Much Easier to Build

There was a time when organisations needed considerable technical knowledge just to experiment with IoT. Connecting sensors, configuring communication protocols, sending data to a cloud platform and creating dashboards required specialised skills.

That barrier has fallen considerably. Hardware such as ESP32 and Raspberry Pi is widely available, IoT platforms simplify device connectivity, and developers have access to extensive documentation and examples. Generative AI has lowered the learning barrier further by helping users generate code, troubleshoot errors and understand technical concepts.

Building an IoT prototype is no longer the biggest challenge for many organisations. The more difficult challenge is turning that prototype into something people depend on every day.

The Problem With Starting From Technology

Many IoT projects begin with a technology question: “Can we connect this equipment?”

There is nothing wrong with testing technical feasibility. The problem appears when connectivity becomes the primary measure of success. A pilot may demonstrate that sensors can collect data, MQTT can transport it and a platform can display it, but none of these automatically demonstrates operational value.

A stronger starting point is to ask what the organisation currently cannot see.

Perhaps maintenance teams do not know that a remote pump has stopped until someone visits the site. A facilities manager may not notice abnormal electricity consumption quickly enough. An environmental team may receive information too late to respond effectively, while operators managing remote assets may spend considerable time travelling to locations simply to check whether equipment is functioning.

These are operational problems. IoT is the mechanism for making them visible.

A Pilot Needs an Operational Owner

One of the most important questions should therefore be asked before the pilot begins: Who owns the operational problem?

An IT department may support connectivity and cybersecurity, while an engineering team manages equipment and another department controls the project budget. If nobody has responsibility for the outcome the IoT system is supposed to improve, moving beyond the pilot can become difficult.

The operational owner should be able to explain why the problem matters, what happens when it is not detected early and what action should follow when the IoT system identifies an abnormal condition.

This also changes how pilot success should be measured. Instead of measuring only whether devices connected successfully, organisations can measure whether the project reduced unnecessary site visits, shortened response times, detected problems earlier, reduced downtime or provided better visibility into energy and resource consumption.

The Dashboard Should Not Be the Destination

Dashboards have become almost synonymous with IoT, but a beautiful dashboard does not automatically mean that an organisation has improved its operations.

The more useful question is what happens after someone sees the information.

If a temperature exceeds a threshold, who receives the alert? If equipment suddenly stops, who investigates? If energy consumption becomes abnormal, what action follows? If environmental conditions deteriorate, how quickly can someone respond?

This is the thinking behind FAVORIOT’s Connect → See → Act™ approach. Connecting an asset provides data. Making that information visible creates awareness. Acting on the information is where operational value begins.

Five Questions to Ask Before Starting an IoT Pilot

Before investing in another proof of concept, organisations should be able to answer five practical questions:

1. What operational problem are we trying to solve? Define the problem before selecting sensors, devices or platforms.
2. What can we not see today? Identify the missing information that prevents faster or better decisions.
3. Who owns this problem? There should be someone responsible for the operational outcome, not merely the technology.
4. How will we measure success? Include operational measures such as response time, downtime, site visits, losses or resource consumption.
5. What happens if the pilot succeeds? Consider production deployment, support, maintenance, connectivity, cybersecurity, budgets and responsibilities before reaching the end of the pilot.

These questions may appear less interesting than discussing sensors, protocols or dashboards, but answering them early can determine whether an IoT project becomes part of daily operations or ends as another demonstration.

From Proof of Technology to Operational Visibility

The IoT industry has spent years proving that connected technology works. We no longer need every project to begin by proving that a sensor can communicate with the cloud. The bigger opportunity is proving that better visibility can improve how an organisation operates.

This is also why FAVORIOT increasingly approaches IoT through the lens of Operational Visibility. The objective is not simply to connect more devices. It is to help organisations see what is happening across physical assets, equipment and environments early enough for people to make better operational decisions.

Before asking “Which sensor should we use?” or “Which IoT platform should we choose?”, there is a more important conversation to have: What operational problem are we trying to make visible, who owns that problem, and what action should happen when we see it?

A pilot that answers those questions has a much stronger reason to continue beyond the demonstration stage. The goal is no longer simply to prove that IoT works. It is to make sure that when the technology works, something meaningful happens because of it.