top of page
CUBENORTH-HORIZONTAL-1.png
Search

A CubeNorth perspective from Slava Gorbunov​, Chief Technology Officer

1 hour ago
4 min read
Why enterprise systems lose touch with operational reality and how technology can support better decisions

Portrait of Slava Gorbunov, Chief Technology Officer at CubeNorth

Organisations tend to invest heavily in systems that don't reflect how they actually operate or genuinely help people make better decisions… CubeNorth grew directly out of that frustration.  


What separates organisations that scale


Coherence.


The organisations that successfully scale treat their operating model as a living system. They make performance visible, connect strategy to daily execution, and adapt quickly when operational reality changes.


Those that struggle tend to respond by adding more reporting tools without changing the underlying logic. This accumulates complexity and makes ownership less clear, and this is how the system gradually stops reflecting how an organisation actually works.


Why transformation loses momentum


Most transformation initiatives are run as projects rather than as capabilities, and are designed around the rollout rather than the person expected to use it on the ground.


And if a system is difficult to use, does not match the realities of the work, or fails to show people the impact of their decisions, it will quietly be abandoned.


Momentum dies the moment a system stops earning its place in someone’s day.


Why CubeNorth created the High Performance Management System


Many organisations are rich in data but poor in decision-making, with strategy disconnected from what happens on the floor.


The CubeNorth High Performance Management System (HPMS) exists to make organisational performance visible in real time and connects it directly to operating reality.


The Blueprint, Value Chain, Continuous Improvement and the Maturity Matrix are not four disconnected tools; they work as a single, connected system.


Together, they connect strategic intent, organisational structure, operational performance and improvement activity. This enables an organisation to understand not only what is happening, but also why it is happening and where action is required. It closes the gap between data and decisions.


That connected design is also deliberately modular. Each capability (Blueprint, Value Chain, Continuous Improvement and the Maturity Matrix) can be adopted on its own, which means an organisation does not need to be a fully formed enterprise to benefit.


An organisation early in its journey can begin with a single module and add others as it matures, assembling the system piece by piece. The platform works as a constructor rather than a monolith, delivering value at every stage of maturity and scaling with the organisation, rather than requiring the organisation to scale first in order to use it.


Moving beyond rear-view-mirror reporting


Dashboards report what has already happened. They are a rear-view mirror.

They may present numbers clearly, but those numbers are often isolated, lagging metrics without the operational context needed to interpret them.


The HPMS models how the organisation actually works: its value chains, assets, processes and dependencies. This means performance can be understood through cause and effect, rather than as a collection of disconnected results.


The point is not to display more numbers. It is to drive decisions and improvement.


Where sophistication should live


Complex modelling should sit beneath the system so that the surface remains simple and relevant to each person’s role. People should see what matters to them, in language they understand and in a format that supports the decisions they need to make. If someone needs a manual to operate it, the system has failed.


As Slava explains, “accuracy and simplicity stop being a trade-off once the complexity is handled in the right layer”.

This simplicity is also critical during implementation. The best system in the world delivers nothing if it is not adopted (enterprise transformation fails on adoption far more often than on technology).


A platform that is fast to stand up and intuitive to use earns trust early. That early trust is what sustains momentum. Ease of implementation must therefore be treated as a design constraint.


Reflecting operational reality


From a technology perspective, reflecting operational reality means creating a data model that mirrors how the organisation genuinely operates: its real value chains, assets, dependencies and workflows.


It cannot be based on an idealised process map created in a workshop.


When the model matches reality, people trust the data, and better decisions follow naturally. When it does not, people quietly begin working around the system, and the system decays.


Technology as a strategic asset


There is also the question of what a platform like this is ultimately for. 

The ambition is not to support the business from the sidelines, but to contribute directly to it: to be strategic, connected to the top and bottom lines, and woven into how the organisation creates value.


When technology reflects the value chain and the way people work, it becomes part of the organisation’s ways of working rather than a cost that needs to be justified each year. 


The aim is architecture that helps drive value (not a software the business pays to keep running).


From systems of record to systems of decision


Slava sees enterprise technology shifting from systems of record to systems of decision.


Over the next five to ten years, less time will be spent assembling reports and more time will be spent acting on intelligence that is already contextual and, increasingly, predictive. Enterprise systems will become more tightly integrated, operating models will update in real time, and AI will be woven through everyday workflows rather than sitting beside them.


But AI does not make system architecture and operational models less important. It actually makes them more important.


AI is only as effective as the data and the model it reasons over. Give it disconnected, low-quality data built around a weak operating model, and it will only produce noise.


Strong architecture and an accurate operational model are what make AI useful and trustworthy. Which means… the fundamentals matter more in an AI-enabled environment, not less.


As CubeNorth’s platform matures and the environment changes, the constant will be ensuring that, as the technology evolves, it remains true to operational reality.


FAQs


Why does strong operational architecture matter for AI?

AI relies on the quality, structure and context of the data beneath it. Strong operational architecture connects that data to how the organisation operates, helping AI produce intelligence that is relevant and useful.

Systems of record primarily capture and store what has already happened. Systems of decision connect that information with operational context, helping people understand why something happened, what may happen next and where action is required.


 
 
 

Comments


bottom of page