How Many Clicks Does It Take?

We opened our session at From Pilots to Production, part of the Stellix Aspire event series, with a question we already knew the answer to: how many clicks, calls, or conversations does it take for someone in your organization to get the information they need to do their job?

The point , of course, is not actually tabulating this number, but rather highlighting how much time teams lose establishing and maintaining the context they need to work effectively.  Time that could be spent improving your daily operations is instead spent logging into various systems, attending status meetings, or chasing colleagues who have already lost some of their own time in establishing this baseline context. Too often, that context describes the past rather than the present.

But what if this wasn’t the case? What if, instead, this context was always available for you to consume with just a single click? What if the context you were seeing was of the present, enabling you to respond intelligently to what you can clearly see lies ahead?

That’s the promise of a Single Pane of Glass (SPOG), although the concept certainly needs more definition. Let’s dig in.

Beyond Dashboarding: SPOG as an Operational Strategy

As we framed it during our session:  a single pane of glass is not a technology project. It is an operational strategy.

The hard work is achieving enough organizational clarity to decide which personas need which information (and when), which scenarios deserve prioritized focus, and what a helpful presentation layer really looks like.

We describe SPOG displays as an ‘operational strategy’ because, while a good one gets you the information you need with minimal clicks, a great one anticipates and answers your next question with zero additional clicks.

Traditional dashboards are most often configured simply to display information – sometimes with true context, but more often with implicit context. That is to say, the data being presented can be interpreted to arrive at the true context, but, ultimately, the context is in the eye of the beholder. Coupled with the fact that refresh rates for some data can often best be measured in hours, this means that traditional dashboards are useful for seeing what has happened, but they do not tell you what is happening now and certainly not what actions you should be taking.

Buzzword Deep-Dive: “Persona-Aware” In Practice

One of the most important design principles that we presented in our session was that a single pane of glass only works if it’s built around the people using it.

A SPOG is a decision support tool. This means that data must be presented in a way that not only fits the type of information being presented, but also the intended audience (or “persona”) and the type of action that such a person might be expected to take in response to a given scenario. This is what we refer to as “persona-aware” design, and it’s intended to be dynamically aware.

Dashboards are configured with a specific audience in mind, and – while they may be useful to other audiences – they do not change to accommodate the viewer. SPOG displays, on the other hand, are built around operational context and can alter the level of detail and presentation layer to best serve the current viewer.

SPOG displays are not willed into existence; they are not trivial to build and cannot be built on disorganized and siloed data. Well-organized and contextualized data (and more specifically “data products”) are the foundations upon which these displays can be successfully built.

In our session we presented three questions that will help determine whether you’ve done the foundational work required to successfully implement this strategy:

• Do you have the right data in the right place and in the right contextual structure?
• Do you understand who needs the data you’re presenting and why?
• Do you have a firm understanding of the events that define your operations, and is your architecture structured in a way to deliver critical operations events to the people who most need them when they most need them?

Getting these foundations right is less visible and less exciting than building the front-end, but this work determines whether the front-end will come together at all, much less function as desired. While these questions may expose unfinished foundational work, they have less to say about how to accomplish such work. Let’s supplement them with some more practical points.

Foundations for Success

Context is understanding
Before machines can help, you need to understand your plant and process at a human level: who is doing what, where, when, how, and with which assets.

This information should be easy to recite for anyone working in a manufacturing plant; mission-critical work is most likely to succeed when the mission itself is clearly understood by all.

Because machines and systems are terrible at truly intuiting anything (yes, this applies to AI), humans need to translate context to a form that machines and systems can effectively use: Master Data. Of course, once this data is created it must be maintained through the human-led activity commonly called Master Data Management. Without such maintenance, the concept of building complex data models that contextualize these operations is lunacy.

Real-time v. Just-in-time
For  reasons ranging from resource constraints (e.g., on-prem compute, cloud-compute budget) to poor design, many dashboards refresh at intervals measured in hours; operations rarely move so slowly, and, even when they do, changes in steady-state are likely to be significant on a timescale measured in minutes.

This is where the SPOG is truly differentiated from the traditional dashboard, as they leverage an Event-Driven Architecture (EDA) to deliver information just-in-time rather than on a fixed polling schedule.

Trying to deliver information on a truly “real-time” basis is inefficient if the data doesn’t change by the second and no quality- or safety-critical control is being performed. But addressing this by slowing the trickle of data to a crawl almost assures that the data isn’t useful for hour-by-hour decision making. This trade-off may be fine for tracking training compliance or quality deviation trends, but it’s counterproductive for adaptive scheduling or responding to a bioreactor pH alarm before it becomes a lost batch.

Emergent design is good design
Data modelling has received significant attention in OT spaces over the last decade (and with good reason). However, the approach to data modelling that many organizations employ remains heavy-handed, inefficient, and ineffective.

Attempting to design and operationalize a data model whose first version accounts for every piece of data, every system, and every scenario has never worked, nor will it ever.  Even during the best attempts, the process moves too slowly for manufacturing organizations that need value in a practical timeframe.

 The better approach is to start with a well-defined use case and build your data model around it. Let the model evolve as the use case evolves. As your use cases mature, you get higher fidelity data models without waiting eighteen months to operationalize them.

Don’t display, enable
SPOG interfaces should be optimized to enable action, not just inform.

That has important implications for how information is presented, what actions the viewer may need to take, and how often they are expected to assess what they’re seeing. If someone is looking at a view every twenty minutes, it should be quickly and simply understood; if they’re looking every three to four hours, it may be appropriate to design additional complexity in exchange for deeper context. In addition to this, the display must be designed around events, highlighted by exception, and empowered by an EDA.

A static display that shows everything with no indication of what’s urgent is not a useful operations tool.

Managing Adoption, or How We Can Have Nice Things

Thus far, we’ve largely focused on technical considerations. However, the success of these solutions doesn’t depend solely on the technical. It’s important to take a step back and also consider the human and organizational components critical to successful adoption.

Few will be willing to adopt what they can’t easily access or understand. Critically, they must also understand why they should adopt a new solution, not just what it is. Communicating this clearly and regularly is the duty of not only organizational leaders but also technical leaders – if you can’t explain why you’re building a solution, should you be building it?

At the same time, over-adoption of a tool can create complacency and blind spots in operations teams. During our session, participants in round-table breakouts described cases where teams deployed operations boards and then became overdependent on them, doing only what the board showed. This is never the desired state; the SPOG interface is there to enable decisions, not make them.

The name usually given to such human-centric structural problems is ‘governance’. This is a critical, and somewhat messy, term used for managing adoption. The use of the term sometimes mistakenly collapses multiple scopes into one. This makes governance appear an almost insurmountable problem, as the owner of a SPOG display is probably not the same person who owns the data, who, in turn, is probably not the same person who owns the system generating and maintaining the data.

However, the usefulness of discussing ‘governance’ comes from identifying the shared problems that must be solved in complementary ways at all levels and across all scopes. In this understanding, ‘governance’ simply describes well-described and agreed-upon expected ways of working/communicating, and accountability structures. In standardizing how we discuss and approach problems, we take steps to avoid conflicting requirements and contextual misunderstandings.

Recap

During our session, we highlighted multiple SPOG use cases ranging from OT system Telemetry to Autonomous Robot Command Center to Batch Review and Release. These use cases share little in common beyond the principles described above, yet each can deliver great value to highly dynamic manufacturing organizations.

To successfully deploy any of these (or myriad other) use cases, however, requires work in several areas. It requires a truly Event-Driven Architecture that balances data refresh rates with the “context refresh rates” required by the humans using the solution. It requires a strong conceptual understanding of day-to-day operations and how these can be translated to machines as Master Data (to say little about how that Master Data is managed…a rich topic in itself). It requires the right systems and network design to ensure data (from various systems residing at various levels of the network) is readily available while also secure and trustworthy. It also requires the hard (and often messy) work of managing organizational adoption and driving cultural changes that make these tools an indispensable part of real-time decision making without becoming a crutch that encourages lazy and detrimental behavior.

While these are not trivial challenges, they are not insurmountable. We hope that our session during Aspire (for those who were able to attend) and this blog post help to clarify  some of these concepts as we present the Stellix vision of SPOG solutions. Moreso, we hope we have encouraged you to find and pursue impactful use cases where SPOG solutions can drive improved operations. Even if that means you have some foundational work to do first, we believe that this is a key to driving continuous improvement.

Tunde Ayodele is a Senior Innovation Consultant at Stellix.
Chris Puzzo is a Senior Solution Architect at Stellix.
Together they help life sciences and industrial organizations design operational intelligence strategies that reduce friction and accelerate decision making.