Why the GEPLAN Suite Was Possible Before Industry 4.0
When the JUBAP.Net GEPLAN suite was developed between 2002 and 2008, terms such as Industry 4.0, Industrial IoT, digital twins and operational AI had not yet entered mainstream business language.
Yet Mexico already possessed many of the core ingredients needed to build advanced industrial software systems — and a small group of field-embedded engineers, architects and operators was quietly assembling them into something that would anticipate those concepts by nearly a decade.
The organization behind GEPLAN, JUBAP.Net, is today a complex systems intelligence center specialized in Operational AI Integrity. At the time, it operated through two entities: The Integral Management Society in the United States and Corbera Networks in Mexico.
Its founders came from a European and international telecommunications background, shaped in large part by former Nokia engineers who had worked across distributed R&D environments, mobility infrastructure, secure remote operations and large-scale digital infrastructure programs.
Rather than importing abstract methodologies, they built from the ground up within real operational environments. Over time, that field-based engineering discipline evolved beyond industrial software into a broader expertise in complex systems behavior, resilience and operational intelligence.
Those early foundations eventually gave rise to what is now JUBAP.Net’s state-of-the-art early warning regime change detection capability, whose conceptual and practical roots can be traced back to the GEPLAN era.
Why Mexico
Mexico was not selected for cost reasons.
It was selected because it had the right kind of engineering talent.
During the early 2000s, the country already supported a growing software ecosystem through public initiatives such as PROSOFT and MoProSoft, alongside industrial clusters in Monterrey, Guadalajara, Baja California and Mexico City.
Telecommunications, automotive, manufacturing, energy and logistics sectors were already generating complex digital demands that required practical engineering rather than purely theoretical IT delivery.
What made Mexican development teams particularly distinctive was their multidisciplinary range. Many engineers were capable of working across software architecture, databases, infrastructure, telecom, industrial operations and business processes — often simultaneously.
They were also accustomed to high-pressure operational environments such as PEMEX, field service organizations, transport operators and industrial maintenance facilities.
This combination of technical depth and operational fluency became a structural advantage that most offshore development models simply could not replicate.
The Tiger Team Model
The JUBAP.Net Tiger Team model did not emerge from a management framework.
It emerged from necessity.
Rather than relying on large documentation exercises, rigid UML pyramids or elaborate backlog management cycles, the JUBAP.Net GEPLAN teams operated through small, high-intensity Tiger Teams embedded directly inside client operations.
Engineers, architects and consultants spent time in workshops, warehouses, dispatch centers, maintenance areas and field operations — learning how the business functioned in practice before translating that knowledge into software architecture.
This was not “agile” in the later corporate sense.
At the time, the closest reference was extreme programming. But the practice went beyond programming. It combined direct field observation, rapid prototyping, operational reengineering, distributed technical collaboration, continuous feedback and immediate adaptation to real constraints.
The model was simple but demanding: stay close enough to the operation to understand it, technical enough to engineer it, and disciplined enough to turn field learning into reliable architecture.
This produced results that differed fundamentally from conventional enterprise software of the period.
Because the teams observed fleet availability issues, workshop bottlenecks, inventory delays, fuel losses, telemetry failures, maintenance scheduling conflicts and dispatch constraints first-hand, the system they built reflected those realities rather than an idealized process model.
Embedded Field Architecture
The return of the architect to the field was one of the defining traits of the JUBAP.Net Tiger Team model.
The architect was not limited to diagrams, requirements documents or executive workshops. The architect entered the control center, the warehouse, the workshop and the dispatch desk.
That proximity changed the quality of the architecture.
It made hidden constraints visible: informal workarounds, manual reconciliations, missing controls, weak data points, local power structures, operational risks and critical knowledge held by people who were rarely included in formal design processes.
In GEPLAN, this meant that software design, process reengineering, data modelling and operational governance evolved together.
The team did not simply automate an existing process. It discovered how the operation really worked, identified what had to be preserved, removed what created systemic fragility, and engineered a more reliable operating model around it.
Distributed Intelligence, Maximum Field Proximity
The Tiger Team model also combined two capabilities that are often treated as opposites: distributed intelligence and maximum field proximity.
The JUBAP.Net lineage carried experience from Nokia’s distributed R&D and mobility environments, where infrastructure, remote collaboration and information coordination were part of the work. After Nokia, those capabilities continued through technical forums, expert networks, remote collaboration and distributed practice communities.
In practice, the GEPLAN teams could combine local presence with distributed technical support. Field teams stayed close to dispatchers, mechanics, operators and supervisors, while remote specialists, developers and infrastructure capabilities supported rapid adaptation.
This was especially advanced for the time.
It was not remote work as distance. It was distributed work with operational intimacy.
That combination later became one of the distinctive patterns of JUBAP.Net: small teams capable of entering complex environments, learning rapidly from the field, integrating remote expertise, and producing working systems under pressure.
An Integrated Architecture Ahead of Its Time
The outcome was a software suite that was unusually integrated for its era.
JUBAP.Net GEPLAN combined logistics, maintenance, fleet control, telemetry, warehouse management, fuel control, inventory, purchasing and decision support into a single operational environment — a degree of convergence that most enterprise platforms would not attempt until years later.
In retrospect, JUBAP.Net GEPLAN anticipated several ideas that only became mainstream under the labels of Industry 4.0, Industrial IoT, control towers, digital twins and operational intelligence.
It did so not through theoretical foresight, but through the discipline of engineering from within the operation rather than above it.
The Operating Pattern
The early JUBAP.Net Tiger Team model can be summarized as an operating pattern:
- enter the field directly;
- observe how the operation really behaves;
- identify hidden constraints, informal controls and weak signals;
- translate field learning into architecture;
- build in short technical cycles;
- validate through operational use;
- standardize only what has been understood;
- integrate software, process, data and governance together;
- keep distributed expertise connected to the field;
- measure success through operational value, not feature delivery.
This is why the model was different from conventional software delivery.
It was not an IT team serving the business from outside.
It was an embedded architecture unit learning from the operation while transforming it.
The Return of the Field Architect
That same model is becoming relevant again today.
As AI deployments grow larger and more operationally critical, organizations increasingly need architects and engineers who understand not only technology stacks, but how complex systems behave under real industrial conditions — where schedules slip, equipment fails, data is incomplete, incentives distort behaviour and human judgment still plays a decisive role.
The architect is returning to the field.
In that sense, JUBAP.Net GEPLAN was never simply an early software suite developed in Mexico.
It was the product of a Mexican engineering ecosystem that was already far more mature, practically oriented and industrially capable than most international observers recognized at the time.
It was also the origin of a JUBAP.Net operating model: compact, embedded, distributed, technically rigorous and accountable to the real behaviour of the system.
From Tiger Teams to Operational AI Integrity
The relevance of the Tiger Team model did not end with GEPLAN.
It became one of the practical foundations for JUBAP.Net’s current work in Operational AI Integrity and early warning regime change detection.
Operational AI cannot be built only from abstract models, dashboards or generic data pipelines. It requires the same discipline that shaped GEPLAN: field proximity, systems understanding, distributed expertise, weak-signal detection, governance awareness and the capacity to identify when an operating regime is beginning to change.
That is why the JUBAP.Net Tiger Team model remains central.
It is the human and engineering pattern behind the technology: the way complex operational reality is observed, understood, translated and transformed into intelligent infrastructure.
Before Industry 4.0 had a name, JUBAP.Net’s Tiger Teams were already practicing its hardest part: engineering from inside the operation.