Manufacturing has always been a world of moving parts. Machines, people, materials, processes, vendors, energy, quality, safety, compliance, customer demand, dashboards, metrics - all working together, and often working against each other in ways that are not immediately visible.

For decades, the promise of industrial technology has been to make this world more measurable. First through automation. Then through SCADA, MES, ERP, sensors, dashboards, IIoT platforms and analytics. And now, of course, AI.

But as a firm that has been deep in industrial technology for the better part of 30 years, we believe the real advantage today lies elsewhere: in understanding the context around the problem.

That is what we mean by “See The Unseen” - which you see on the homepage of our site (and, increasingly, in internal conversations). But what do we mean by that?

Information in a manufacturing environment naturally sits in different places - production sees one part of the truth, maintenance sees another, quality sees another. IT sees systems, OT sees machines. Leadership sees business outcomes. But the actual problem lives somewhere between (and including) all of these.

A downtime issue may have its roots in operator behaviour, maintenance planning, training or environmental conditions. A quality deviation may begin long before inspection — in a raw-material change, process variable or shift-level workaround. A system that looks perfectly sensible in a boardroom may turn out to be awkward for the person expected to use it for eight hours on the shopfloor.

Seeing the unseen, therefore, is often about seeing across boundaries.

The boardroom and the shopfloor

Requirements can look very different once they encounter the reality of production - and indeed, the hands of those who use them on a daily basis.

In one Axcend engagement, a customer wanted tablet-based work instructions for operators. Technically, the requirement was straightforward. But observing how people actually worked revealed a practical problem: operators needed their hands free while performing the task.

Introducing a tablet would have added friction into the very process it was meant to improve. The solution was reframed around the operator rather than the interface. A foot-pedal controller allowed workers to navigate instructions without interrupting what they were doing.

The technology mattered - yes. But understanding the environment in which that technology would live mattered just as much.

Today and tomorrow

A solution can meet every requirement today and still create tomorrow’s problem. That is why we try to look beyond the immediate implementation. What happens if another line is added? Or another plant? What if a system needs to integrate with something that does not exist yet? Will today’s solution become tomorrow’s patchwork? Will today’s solve match tomorrow’s projected scale?

In one project, a client needed a point solution for a specific application. Instead of treating it as an isolated implementation, Axcend proposed a platform-based architecture that could accommodate future additions.

Futureproofing, to us, does not mean pretending we can predict everything. We cannot. It often means avoiding decisions today that unnecessarily narrow tomorrow’s options. In a way, we are giving our future selves flexibility.

One machine and the larger operation

Manufacturing systems do not operate independently. An intervention around a single piece of equipment can affect production schedules, maintenance practices, quality, IT architecture or the way information moves across the plant. Similarly, a problem that appears to sit inside one machine may actually be caused somewhere upstream or downstream.

This is where the ability to zoom in and zoom out becomes important. At the zoomed-in level, teams need to understand controllers, protocols, sensors, interfaces and workflows. At the zoomed-out level, they need to understand how those elements interact with the wider operation. Neither perspective is enough by itself.

The stated brief and the larger context

A requirements document necessarily simplifies reality. It tells you what has been asked for. It may not tell you everything surrounding that requirement.

In a global chiller-monitoring project, for example, the immediate requirement was to capture operating parameters across distributed locations. But dependable visibility also meant thinking about what happened when communication networks went down.

Axcend therefore designed a store-and-forward mechanism that retained data locally during communication outages and sent it onwards once connectivity returned. The architecture was also designed with future predictive-maintenance use cases in mind.

The implementation had to work for the requirement in front of us — but also for conditions and possibilities sitting just outside it.

That, in many ways, is the unseen.