Engineering Value Creation Before the Cloud: JUBAP.Net’s GEPLAN Case before SaaS and IoT Revolutions

JUBAP.Net’s GEPLAN Case Before the SaaS and IoT Revolutions

JUBAP.Net, the organisation behind the GEPLAN suite, operates today as a complex systems intelligence center specialising in Operational AI Integrity and state-of-the-art early warning regime change detection.

Its roots trace back to the early 2000s, when the practice operated through The Integral Management Society in the United States and Corbera Networks in Mexico. Built from a Nokia R&D engineering background and later grounded in Veracruz, the team developed mission-critical systems for logistics-intensive environments such as PEMEX, TETSA and regional transport operators.

GEPLAN was not conceived as a conventional software product. It was engineered as an integrated operational platform: a system capable of connecting logistics, maintenance, inventory, procurement, telemetry, volumetric control and operational estimation inside a single execution environment.

Engineering Before Commercial APIs

Long before public cloud, commercial IoT platforms and plug-and-play APIs became standard, GEPLAN functioned as an early on-premise predecessor to the Software-as-a-Service model for industrial operations.

The suite was built using Delphi, ASP.NET and MySQL, supported by a modular architecture designed to be adapted across different operational contexts. At the time, the language of microservices was not yet common in industrial environments, but GEPLAN already followed a separation of concerns across interoperable modules: logistics, fleet control, workshop management, warehouse operations, volumetric control, service-station administration and reporting.

Because commercial IoT infrastructure did not yet exist, the engineering team relied heavily on reverse engineering to connect industrial hardware, fuel dispensers, telemetry devices and legacy operational environments directly into the platform.

This created a practical pre-IoT integration layer. Data that would otherwise remain trapped in field devices, manual logs or isolated systems could be captured, normalised and transformed into operational intelligence.

The team also used scripting, macros, event triggers and early RPA-style automation to bridge gaps between industrial devices, back-office systems and field users. The objective was clear: reduce manual re-entry, eliminate operational blind spots and create a reliable data fabric where no commercial middleware was available.

Advanced Capabilities in a Pre-IoT Era

GEPLAN’s core modules connected logistics operators, workshops, warehouses, fleet companies and service-station environments into a unified operational platform.

The GEPLAN/V volumetric control module, for example, integrated tank telemetry, monitored fuel levels and connected with dispenser brands such as Wayne and Gilbarco. It linked operational data with PEMEX-related workflows for transport, loading, unloading, invoicing and franchise management.

This was not only fuel monitoring. It was an integrated control environment combining point-of-sale information, ticketing, inventory movements, tank status, fuel dispatch and service-station administration.

In parallel, the private fleet-control environment integrated Omnitracs satellite telemetry, dispatch centers, drivers, fleet availability, maintenance events, fuel control, electronic work orders, alerts and operational evidence into one decision-support layer.

This was more than GPS tracking.

It was an operational intelligence fabric connecting field execution, asset condition, logistics planning and management visibility in near real time.

Planning Layer and Execution Layer

One of the strongest engineering principles behind GEPLAN was the separation between planning and execution.

The planning layer handled origins, destinations, volumes, priorities, routes, capacity constraints, distances, travel times, waiting conditions and operational restrictions.

The execution layer handled vehicle tracking, driver communication, status transitions, route monitoring, delays, exceptions, field evidence and full trip traceability.

This effectively created a state-driven logistics execution engine. Each movement could be broken down into operational stages and checkpoints, allowing teams to identify bottlenecks, deviations and delays as they emerged.

In a fragmented industrial environment, this distinction was critical. Planning without execution visibility becomes theoretical. Execution without planning logic becomes reactive. GEPLAN connected both layers into a single operating model.

Asset Lifecycle and Maintenance Intelligence

GEPLAN also managed the lifecycle of operational assets, especially transport units.

The workshop and maintenance modules included preventive maintenance, corrective maintenance, investment-based maintenance, scheduling by mileage and time, full maintenance history, real-time unit status, workshop backlog and estimated return-to-service dates.

This created a direct connection between maintenance and logistics planning.

A vehicle in maintenance was not merely an accounting or workshop record. Its expected return date affected dispatch capacity, route planning, production support and future commitments. Maintenance status became part of the operational decision model.

The warehouse module was also integrated with maintenance and logistics. It managed stock control, inventory movements, spare-part assignments, warehouse requests, procurement requisitions and supplier fulfilment workflows.

One of the most advanced elements was the use of consignment inventory with external suppliers. This allowed visibility of third-party stock, faster access to critical spare parts, reduced downtime and tighter coordination between procurement, workshop activity and fleet availability.

Operational Estimation and Industrial Analytics

GEPLAN’s estimation layer was one of its most advanced components.

The platform combined operational inputs such as production per well, separation capacity, tank volumes, route distances, loading and unloading constraints, vehicle availability and workshop readiness.

From these inputs, the system generated outputs such as transported volumes, planned versus real production, kilometres travelled, fleet utilisation rates, capacity constraints, congestion points, delay patterns and bottleneck identification.

This transformed GEPLAN from a transactional system into an early industrial data and operational intelligence platform.

In practice, it became one of the few consistent sources of truth across logistics, production support, transport performance and operational readiness.

Driven by Organizational Consulting

What truly made GEPLAN function like a modern SaaS was not only its modularity, but its delivery model.

The platform was never deployed as software alone. Each implementation was bundled with deep organisational consulting, process mapping, job profiling, operational re-engineering and governance redesign.

In many cases, the journey led to ISO 9001-style process formalisation before the full deployment of the software. The reason was practical: a critical system cannot remain reliable if the underlying operation is undocumented, inconsistent or dependent only on informal habits.

The platform was then adapted to the refined operational model, ensuring that the technology served the operation instead of forcing the organisation into a rigid software shell.

This consulting-plus-software model aligned strongly with the meaning of The Integral Management Society: managing the whole system rather than optimising a single tool, department or interface.

Value Creation Over Features

The commercial philosophy was also engineering-driven.

Client commitments were based on measurable value creation rather than software features. Agreements focused on tangible operational KPIs: reducing inventory shrinkage, improving scheduled transport efficiency, tightening fuel control, increasing fleet availability, shortening maintenance cycles and improving operational visibility.

The promise was not that a module would add more screens or reports. The promise was that a configuration, process and system architecture would generate measurable operational improvement.

This pushed the engineering team to treat GEPLAN as a living part of the operation. Field feedback, control-center usage, maintenance constraints, telemetry gaps, operator behaviour and management reporting all became part of the engineering loop.

From Industrial Systems Engineering to Operational AI Integrity

Looking back, GEPLAN was not simply an ERP, not simply a logistics system and not simply a fleet-control tool.

It was an end-to-end operational intelligence and execution platform combining planning, execution, maintenance, supply chain, telemetry, estimation and governance in a single integrated environment.

That discipline of tying technology architecture to real-world behaviour became one of the foundations of JUBAP.Net’s current work in Operational AI Integrity and early warning regime change detection.

Systemic shifts are not identified only through abstract models. They are detected through concrete operational signatures: delays, abnormal consumption, inconsistent execution, changing capacity, maintenance degradation, bottlenecks, human workarounds, data gaps and weak signals distributed across the system.

GEPLAN’s value was that it forced those signals to become visible.

That is the engineering continuity behind JUBAP.Net today: building intelligent systems that do not merely process information, but understand the operational structure in which that information becomes meaningful.