Engineering Value Creation Before the Cloud

JUBAP.Net, the organisation behind the GEPLAN suite, operates today as a complex-systems intelligence centre specialising in Operational AI Integrity and early-warning regime-change detection. Its roots trace back to the early 2000s — to an integrated operational platform built long before public cloud, commercial IoT or plug-and-play APIs existed.

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 centres, drivers, fleet availability, maintenance events, fuel control, electronic work orders, alerts and operational evidence into one decision-support layer.

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.

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. The promise was not that a module would add more screens or reports — it 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-centre 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.

Stewarded by The Integral Management Society / IMSV.org. JubAp.Net · info@jubap.net · jubap.net

Historical account. The client for the PEMEX-related work was TETSA (Transportes Especializados de Toluca, S.A. de C.V.), the hydrocarbon-transport concessionaire operating in PEMEX’s region; GEPLAN was a TETSA-side system deeply integrated with PEMEX logistics and operational processes, not a PEMEX-owned platform. Related full case study: GEPLAN — Mission-Critical Logistics Intelligence for PEMEX.

GEPLAN Suite

JUBAP.Net, the organization behind the GEPLAN suite, is today a complex-systems intelligence centre focused on Operational AI Integrity and early-warning regime-change detection. Its origins lie in the early 2000s — in a Mexico that was not yet speaking the language of “Industry 4.0,” but was already building a serious software and industrial-technology base.

Mexico before Industry 4.0

By the mid-2000s, Mexico was not yet speaking the language of “Industry 4.0,” but it was already building a meaningful software and industrial-technology base. Official planning documents from the period described a national ICT market expected to grow by around 12%, with software forecast to grow faster, at about 19%, while the sector already employed more than 137,000 people. Mexico had launched PROSOFT in 2002 to strengthen the software industry, and by 2005 had formalised MoProSoft as a national process model for software development and maintenance. By 2006, PROSOFT was already supporting more than 330 projects and thousands of companies, most of them small and medium-sized firms.

This mattered because the country was not relying only on imported enterprise software. Mexico already had a real software ecosystem: large firms such as Softtek, Grupo Tress and Zentrum, but also hundreds of smaller firms building custom solutions for logistics, manufacturing, retail, transport, fuel distribution and industrial operations. States such as Nuevo León, Guadalajara, Monterrey and Baja California were becoming important technology clusters, producing growing numbers of engineers and software developers while benefiting from proximity to the United States.

It was also a particular moment socially. Before the worst years of the drug war and generalised insecurity, Mexico was seen by many international professionals as an attractive place to live and work remotely, even before the term “digital nomad” became common. That was also the case for the founders of JUBAP.net and The Integral Management Society SAS. After working in Europe, including at the Nokia R&D center in Barcelona, and spending time in the United States, they eventually established themselves in Veracruz, Mexico. From there, they built systems not only for PEMEX-related logistics, but also for Latin America and the United States, working with Mexican developers who had experience in medium and large systems for companies such as CSAV and other logistics-intensive organisations.

PEMEX itself was operating in a highly digital and operationally demanding environment. Its 2008 annual report describes telecom modernisation, SCADA support, satellite communications, internal logistics and franchise-monitoring systems, and even a NASA-supported GEO PEMEX 3D viewer for emergency response and operational maintenance. In the same period, Invensys opened a gas-operations centre in Reynosa to support PEMEX and described Burgos as the largest SCADA system it had installed in Latin America. The relevant context is therefore not a “digitally empty” Mexico, but a large industrial landscape where major operators, vendors and local teams were all building serious control, monitoring and integration capabilities.

An installed suite with a SaaS mindset

GEPLAN was architected in an era before public cloud, commercial IoT platforms and ready-made APIs, yet it behaved conceptually like an early SaaS for industrial operations. It was delivered as an on-premise, installable suite based on Delphi, ASP.NET and MySQL, organised into interoperable modules for logistics operators, workshops, warehouses, fleets and service stations. The 2008 catalog already describes a coherent environment: inventory and budgeting, vehicle maintenance, logistics planning, fuel-consumption control, volumetric management, ERP-style integration, remote access and centralised operational reporting.

Because standard IoT stacks did not yet exist, the team relied heavily on reverse engineering to connect hardware, dispensers, telemetry devices and legacy SCADA environments directly into GEPLAN. The result was a de facto pre-IoT integration layer, reinforced by extensive scripting and early RPA-style automation to move data between industrial devices, back-office systems and field users without manual re-entry.

Modular architecture, pre-microservices

Technically, GEPLAN adopted a modular architecture designed to be adapted for different clients and operational contexts, even if the language of microservices was not yet in use. Modules such as GEPLAN/V for volumetric control could be deployed as part of a larger suite or as standalone components tightly integrated with existing infrastructure.

GEPLAN/V was a relatively advanced concept even by current standards. It could read dispensers from multiple brands such as Wayne and Gilbarco, integrate tank telemetry, monitor opening events, pressure and fuel levels, connect to PEMEX for transport, loading and unloading monitoring, and integrate invoicing with PEMEX franchise workflows. It also supported POS, ticket printing, inventory control and complete service-station management. What made it distinctive was not that each feature was unique by itself, but that all of them were integrated into one practical environment almost two decades before industrial IoT became mainstream.

Similarly, the private fleet-control environment developed around GEPLAN went beyond standard GPS tracking. It connected transport companies, dispatch centres, workshops, maintenance, fuel control, drivers, inventory and operational reporting. The PEMEX / TETSA control-centre document shows the same logic in live operation: Omnitracs satellite telemetry, data mining, alerts, reporting, electronic work orders, secure communications, evidence attachments, operational alerts and linkage to PEMEX estimation workflows.

SaaS as consulting-plus-software

What made GEPLAN particularly close to a SaaS model was not only its modularity but the way it was commercialised and implemented. Clients did not simply receive software licences: they engaged in a structured consulting process that began with job-profile mapping, process discovery and organisational re-engineering. In many cases, this journey led to ISO 9001-style process formalisation as a first step, before fully tailoring and deploying the system to the refined operational model.

The suite was therefore “consumed” together with organisational consulting, with JUBAP.Net acting as both software provider and integrator of management practices. This consulting-plus-software approach aligned strongly with the meaning of The Integral Management Society: a focus on managing the whole system rather than a single tool or department.

Commitments based on value, not features

Commercially, the company structured its commitments around value creation instead of feature delivery. Contracts did not centre on a checklist of functionalities; they focused on concrete business KPIs such as reducing inventory shrinkage, increasing the efficiency of scheduled trips, tightening fuel control or improving fleet availability.

The promise to each client was that a given module or configuration would generate measurable operational improvements, not just additional screens or reports. This value-based orientation pushed the engineering teams to design GEPLAN as a living part of the operation, continuously refined through field feedback, rather than as a static IT product. Over time, that discipline of tying technology architecture to real-world behaviour became the foundation of JUBAP.Net’s current work in Operational AI Integrity and early-warning regime-change detection, where systemic shifts are identified not by abstract theory but by their concrete operational signatures.

Chicontepec: ambition and outcome

The broader Chicontepec programme did not meet its original ambitions, and that should be stated clearly. The ASF’s 2010 performance audit describes Chicontepec as a strategic response to Cantarell’s decline, representing 40% of the country’s hydrocarbon reserves, with a plan based on drilling 16,000 development wells. The same audit explains that well productivity was very low — around 0.1 to 0.3 thousand barrels per day per well — and concluded that production targets were missed, and that the productive return from 2002 to 2008 was only 2.5 centavos for every peso invested.

That failure should be acknowledged directly. But it does not make the associated digital and operational systems irrelevant; if anything, it shows how ambitious the surrounding logistical and decision environment really was.

A fair international reading is this: GEPLAN was a technically serious, Mexican-built integration layer, developed in an environment where the country already had growing software clusters, formal process models, large industrial telecom and SCADA deployments, and domestic firms capable of building custom systems for demanding corporate and industrial use cases. In that sense, GEPLAN belongs to the early wave of practical industrial digitalisation in Latin America — before the later vocabulary of IIoT, control towers and Industry 4.0 made those architectures easier to describe.

2008 user manuals & suite catalog

Original period materials — 2008 GEPLAN user manuals and the JUBAP.net GEPLAN Suite catalog:

Stewarded by The Integral Management Society / IMSV.org. JubAp.Net · info@jubap.net · jubap.net

Historical account (2006–2010). The client for the PEMEX-related work was TETSA (Transportes Especializados de Toluca, S.A. de C.V.), the hydrocarbon-transport concessionaire operating in PEMEX’s northern region; GEPLAN was a TETSA-side system deeply integrated with PEMEX logistics and operational processes, not a PEMEX-owned platform. Related reading: GEPLAN — Mission-Critical Logistics Intelligence for PEMEX.

GEPLAN

Before Industry 4.0 became a global concept, one of the world’s most complex oil projects was already forcing the creation of real-time logistics-intelligence systems. GEPLAN integrated telemetry, fleet control, warehouses, maintenance, procurement and operational decision support years before these capabilities became common.

In the mid-2000s, PEMEX was operating in one of the most demanding industrial environments in the world. Mexico was not yet “Industry 4.0”, but large-scale oil, energy and logistics projects were already pushing the development of advanced telemetry, fleet control, remote operations, field intelligence and real-time coordination.

Chicontepec was one of the most ambitious unconventional oil projects globally, with more than 80 billion barrels in place and a scale comparable to some of the world’s largest tight oil plays. However, geological complexity, fragmented reservoirs, high drilling costs and operational challenges meant that it never achieved the production levels originally expected.

Even so, Chicontepec became an enormous learning laboratory. Many of the technologies, methods and operating models developed there anticipated later trends in industrial IoT, digital twins, logistics intelligence, predictive operations and Industry 4.0. In that context, JUBAP.net GEPLAN was not just a local system. It was an unusually advanced logistics intelligence platform for its time, integrating telemetry, fleet control, warehouses, procurement, maintenance and operational decision support years before these capabilities became common globally.

Background, Client and Executive Summary

Jubap.net (jubap.is) is the commercial name of The Integral Management Society SAS, a Mexican company with more than 20 years of experience in complex systems intelligence, mission-critical environments and operational decision support.

The organisation originally operated under the Corbera Networks brand in Latin America. It was created by a team with a background from the Nokia Research and Development center in Barcelona, and international experience in the United States and Canada from 2005 onward.

The client for this project was TETSA (Transportes Especializados de Toluca S.A. de C.V.), a company that for many years had operated as the main hydrocarbon transport concessionaire for PEMEX in its northern region.

In practice, TETSA functioned almost as an embedded logistics arm within PEMEX operations. Its teams, vehicles, workshops and control centres were deeply integrated into the day-to-day operation of transport, maintenance, field coordination and production support.

In 2006, PEMEX was engaging in the Chicontepec Megaproject — one of the most ambitious energy development programmes of its time — combining multi-billion-dollar investment, projected development at massive well count, technically difficult reservoirs and a highly experimental operating environment.

Conventional logistics models were not sufficient. The operation required a real-time intelligence layer capable of integrating information across contractors, maintenance activity, field execution and changing production realities, so logistics could continuously adapt to evolving operational conditions.

JUBAP.net GEPLAN was designed and implemented as an integrated platform connecting logistics, maintenance, inventory, procurement, telemetry and operational estimation in a single environment. The platform included:

• Real-time vehicle tracking and satellite communications
• Logistics planning and dispatch coordination
• Workshop, preventive and predictive maintenance
• Inventory, warehouse and spare parts management
• Procurement and supplier workflows
• Consignment inventory with third-party suppliers
• Production estimation and operational analytics
• Integration with PEMEX logistics and operational processes
• Dashboards, alerts and decision-support capabilities

Unlike traditional transformation programmes, GEPLAN was not designed as a large upfront investment requiring major CAPEX approval. It was conceived jointly by TETSA and our team as a gradual initiative to create unique value for PEMEX and strengthen the operational symbiosis between TETSA and PEMEX logistics.

The programme was intentionally designed to grow incrementally, validating each capability before expanding into the next one. It started with warehouse stabilisation, inventory clean-up and basic operational controls. Each improvement generated measurable operational and financial benefits, which funded the next phase: purchasing, remanufacturing, workshop intelligence, predictive maintenance, logistics and finally deeper integration with PEMEX. Positive benefits appeared within the first three months and were continuously reinvested into the next sprint.

GEPLAN eventually became more than a logistics platform. It became the operational backbone connecting transport, maintenance, field operations and decision-making across one of the most complex industrial environments in Mexico.

PEMEX / Chicontepec (2005–2008): geological complexity and megaproject scale

At the time, unconventional oil was beginning to reshape the global energy industry. Advances in horizontal drilling, hydraulic fracturing, telemetry and industrial control were making it possible to extract hydrocarbons from reservoirs that had previously been considered too difficult or too expensive to develop.

For Mexico, Chicontepec became one of the country’s most important strategic energy projects. At the same time that Cantarell — which had reached more than 2.1 million barrels per day in 2004 and represented close to two-thirds of Mexico’s oil production — was entering irreversible decline, Chicontepec was expected to become one of the main future sources of national production, fiscal income and energy security.

Chicontepec contained one of the largest accumulations of hydrocarbons in the world, with tens of billions of barrels of original oil in place and very large probable reserves. However, unlike Cantarell, the oil was trapped in highly fragmented sandstone formations with very low permeability, low pressure and complex internal geology.

This created a completely different economic model from conventional oil fields. In Cantarell, individual wells could produce between 5,000 and 15,000 barrels per day. In Chicontepec, many wells produced only around 100 to 300 barrels per day. To compensate for this, PEMEX planned to drill approximately 20,000 wells with an estimated investment of around USD 37 billion, with the objective of replacing the decline of Cantarell.

Due to low well production and geographic dispersion, traditional pipeline infrastructure was often not economically viable. Instead, much of the operation depended on hydrocarbon transport by road, temporary routes and ad hoc access corridors built specifically for field operations. This made transport, logistics coordination and operational visibility much more critical than in conventional oil environments.

The overall programme was highly experimental. New drilling methods, transport routines, production models and logistics capabilities had to be tested continuously in the field. Small operational failures could quickly translate into major production losses, environmental incidents or costly delays.

An unstructured industrial environment

Unlike mature industrial environments with stable infrastructure and predictable operating conditions, Chicontepec operated in a constantly changing environment.

• Roads were often little more than jungle tracks and rural access paths between dispersed communities, many being opened, expanded or modified specifically for the project
• Road conditions changed daily depending on weather, mud, heavy equipment traffic and field activity
• Some operational zones remained only partially mapped
• Satellite communication was not ubiquitous and had to be actively integrated with operational systems; many mobile units did not have permanent access
• Communication depended on a multi-channel mix of Omnitracs, radio, push-to-talk, partial cellular networks, informal relays, local supervisors and word-of-mouth across multiple entities
• Production per well was highly variable
• Storage capacity and remaining volume in tanks often lacked accurate metrology
• Absorption capacity at turbocompressors varied depending on crude density and operational conditions
• Incidents were frequent and frequently occurred simultaneously across different parts of the network
• Visibility of production, road conditions, fleet position, tank levels and transport availability was often partial, delayed or inconsistent without a single source of truth
• A failure could result in an environmental spill, operational shutdown or a multimillion-dollar interruption

Further operational complexity

The logistics challenge was far broader than crude oil from wells to separation batteries. It involved moving:

• Heavy machinery required to keep wells and field operations running
• Drilling fluids and other specialised materials
• Equipment for maintenance, recovery and emergency interventions
• Oversized loads requiring specialised manoeuvres and route coordination

The scale of heavy transport alone was enormous. Every day, the departure from Poza Rica city resembled a coordinated procession of heavy equipment extending for dozens of kilometres in multiple directions. Tankers, cranes, lowboys, drilling equipment, workshop vehicles, maintenance teams and support units had to move simultaneously across a fragmented and unstable territory.

Coordination had to be extremely precise. A delay, blockage or incorrect sequence in one convoy could create cascading effects across multiple routes, loading points, wells, workshops and receiving facilities. Crude transport itself was not a minor operation. The volumes involved represented most of the production of a territory comparable in size to a medium-sized European country. Managing this flow required constant balancing between production, storage, transport capacity, receiving capacity and operational risk.

Limited digital maturity

During the 2005–2008 period, concepts such as Industry 4.0 or Digital Transformation were not yet part of the vocabulary. Field staff and transport operators had limited exposure to digital tools. Most reporting depended on paper logs, spreadsheets and manual coordination.

This model had been broadly sufficient for the smaller-scale operations that existed before the megaproject. Operators knew the roads, routes, communities and local conditions from years of experience, and much of the operation depended on tacit knowledge and local relationships. However, as new roads were being opened continuously, the previous way of working was no longer enough. It required an entirely new suite of tools capable of supporting decisions.

From Tiger Teams to an early scaled-agile model

The Tiger Team

As the design had to evolve constantly due to the experimental nature of the megaproject, there was never a complete feature backlog. Therefore, we defined a model based on two-week sprints, with programmers and engineers embedded directly in the control centres or in the field. It was a disciplined mission-critical agile development style — more like a Tiger Team (a concept used in Apollo 13): small multidisciplinary teams working directly inside the operation, solving problems in real time and adapting the system continuously without compromising operational continuity.

Expert systems approach

The operational intelligence approach was based on rules, heuristics and what at the time were commonly called expert systems. That knowledge could not be invented centrally. It had to be acquired directly from operators, dispatchers, mechanics, supervisors and field personnel who understood the real constraints of the operation. Over time, this knowledge was translated into structured rules, scenarios and decision logic, supported by disciplined libraries of documents, procedures and approved rule versions that were continuously reviewed, consolidated and maintained.

The symbiotic user interface

In this environment, many operators were not digitally prepared. Information had to be heavily digested and presented in a very intuitive way. The platform aggregated fragmented information, applied predefined logic, highlighted risks and priorities, and presented operational data through simple dashboards and large action buttons where the most important information was immediately visible. Operators were not expected to navigate through multiple menus, apply filters or search for information. The system had to make decisions easier, faster and more reliable under pressure.

Technology stack and system architecture

GEPLAN was designed as an integrated industrial platform combining logistics, maintenance, inventory, procurement, telemetry and operational estimation within a single environment. The architecture was built around a central operational database and a modular ERP-style environment, connected to satellite systems, control centres and field operations.

Core technology stack

• Delphi-based application layer
• Microsoft SQL Server and MySQL databases
• Omnitracs satellite communications and fleet tracking
• Desktop interfaces for dispatchers, maintenance teams and control centres
• Real-time operational macros and event triggers
• Reporting and dashboard capabilities
• Workflow-based approvals and status transitions
• Integration with PEMEX operational environments

Core operational platform

GEPLAN was not a standalone logistics application. It operated as a central platform integrating logistics planning, fleet control, workshop and maintenance, inventory and warehouse, procurement and supplier management, and production estimation. The system functioned as a shared operational environment between TETSA, field operations, workshops, suppliers and PEMEX.

Real-time telematics and operational tracking

A critical component of the architecture was the integration with Omnitracs and satellite-based communication systems. This enabled real-time vehicle tracking, route monitoring, driver communication, field coordination in remote areas, visibility of unit status and manoeuvre execution, and operational alerts and exception handling.

Each kind of operation was broken down into multiple stages and checkpoints, creating full traceability for every movement; this allowed operations teams to identify exactly where delays, bottlenecks or failures were occurring in real time.

Asset lifecycle management

GEPLAN did not only manage logistics. It managed the full lifecycle of operational assets, especially transport units.

Workshop and maintenance intelligence

The workshop module included preventive maintenance, corrective maintenance, investment-based maintenance, scheduling by time and mileage, full maintenance history, real-time unit status, and visibility of delays and workshop backlog.

A particularly valuable feature was the estimation of workshop exit time for each vehicle.

This gave operations teams visibility into units currently in workshop, expected return-to-service date, operational readiness, and fleet availability for future assignments. This created a direct link between maintenance, availability and logistics planning. Maintenance status was not isolated from operations; it directly influenced route planning and dispatch decisions.

Warehouse and extended supply chain

The warehouse module was tightly integrated with maintenance and logistics. It included stock control, inventory movements, spare-parts assignments, linkage to maintenance orders, linkage to vehicles and operational units, warehouse requests, procurement requisitions and supplier-fulfilment workflows.

An advanced aspect of the model was the use of consignment inventory with external suppliers such as Kenworth.

This enabled visibility of third-party stock, hybrid ownership models, immediate access to critical spare parts, reduced downtime and faster repair cycles. It was an early form of vendor-integrated inventory management and extended supply-chain coordination.

Procurement and financial linkage

GEPLAN also included a procurement layer directly connected to operations: purchase requisitions, supplier-interaction workflows, procurement approvals, cost tracking, validation of operational purchases, and basic financial linkage to logistics and maintenance activities. Although it was not a full finance ERP module, procurement was directly connected to operational execution rather than managed separately.

Procurement decisions were linked to vehicle availability, maintenance demand and logistics priorities.

Planning layer vs execution layer

A major strength of the platform was the separation between planning and execution.

Planning layer

Origin and destination definition, volumes and priorities, route creation, assignment logic, capacity constraints, distances and travel times, waiting-time considerations, and operational restrictions.

Execution layer

Real-time vehicle tracking, driver communication, status transitions, route-execution monitoring, delays and exception handling, and full trip traceability. This effectively created a state-driven logistics execution engine.

Estimation and operational analytics

One of the most advanced components of GEPLAN was the estimation system. 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. These generated operational outputs including transported volumes, real versus planned production, kilometres travelled, fleet utilisation rates, bottleneck identification, capacity constraints, and congestion and delay analysis.

This estimation layer became one of the few consistent sources of truth across logistics, production and transport performance, enabling analysis at project, regional, cross-field, supplier and fleet level.

This transformed GEPLAN into an early industrial data and operational-intelligence platform.

Integration with PEMEX

GEPLAN was not simply connected to PEMEX systems. It became embedded within PEMEX logistics and operational processes, enabling structured operational data exchange, validation of execution, reconciliation of transport activity, support for PEMEX planning decisions, integration with estimation and reporting processes, and shared visibility between TETSA and PEMEX. This created a form of B2B operational integration with direct dependency on shared information flows.

Final positioning

GEPLAN was not an ERP and not simply a logistics system. It became a logistics-orchestration platform, an asset-lifecycle-management system, a real-time telematics environment, a supplier-integrated supply-chain platform, an estimation-and-analytics engine, and a decision-support layer connected to PEMEX. In practice, GEPLAN functioned as an end-to-end operational-intelligence and execution platform for hydrocarbon logistics and production support, combining planning, execution, maintenance, supply chain, telemetry and operational estimation in a single integrated environment.

From decentralised operations to centralised governance

GEPLAN could not be implemented without changing the operating model. The challenge was not only technological; it also required a complete redesign of governance, communication, decision-making and operational coordination. Before GEPLAN, the organisation worked through what were formally called “departments”, but in practice these behaved as largely independent companies.

Communication was based on prior-day documents, manual coordination, radio communication, informal escalation, and local supervisors with fragmented priorities. This created delayed reactions to operational changes, decentralised decision-making, low visibility across the operation, conflicting priorities between areas, strong dependency on local knowledge, and limited ability to coordinate logistics, maintenance and field operations at scale.

GEPLAN required a fundamental shift from fragmented local control to centralised operational governance. The new model introduced centralised operational control, real-time coordination across all entities, faster response to incidents and operational changes, continuous prioritisation based on live data, and shared visibility across logistics, maintenance and field operations.

Operations were coordinated through four integrated logistics control centres — Costa Rica, Tinajas, Altamira and the PEMEX logistics control centre. These centres operated on the same platform, shared the same operational information and worked under a common decision framework.

JUBAP.net GEPLAN became the core operational layer connecting all control centres. The other operational entities continued to exist as separate businesses, but their daily activities became coordinated through the control-centre structure. Operators no longer followed only the instructions of local supervisors; daily execution was increasingly driven by the integrated logistics-control model.

Process design and certification

The implementation of GEPLAN required the formal design, documentation and standardisation of operational processes: end-to-end logistics processes, maintenance and workshop processes, procurement and warehouse processes, incident-management workflows, operational-escalation procedures, decision rights and approval flows, reporting and traceability mechanisms, and roles and responsibilities across entities.

This process layer supported certification and audit readiness across multiple management standards, including ISO 9001 for quality management, OHSAS 18001 for occupational health and safety, and ISO 14001 for environmental management. The process model became a critical foundation for scaling operations, improving auditability and reducing dependency on informal practices.

JUBAP.net GEPLAN was not only a technology platform. It was also a process and governance transformation programme.

Human-in-the-loop decision architecture

GEPLAN was intentionally designed not to automate operational decisions completely. At the time, the complexity of the environment and the variability of field conditions made full automation impractical and potentially risky.

The role of the system was to aggregate and clean operational data, process information from multiple sources, highlight incidents and bottlenecks, suggest possible actions, present structured operational insights, and support faster and better decision-making. However, the system did not assign orders automatically and did not take final decisions. Operators in the control centres remained responsible for reviewing the situation, evaluating trade-offs, making final decisions, assigning transport orders, and escalating conflicts and priorities.

Expert system and decision support

Although GEPLAN was not an AI platform, it included expert-system characteristics: rule-based logic, predefined operational indicators, suggested actions, early warnings, prioritisation logic and pre-evaluated scenarios. These were designed to accelerate decisions, identify risks and support operators during incidents. However, the final decision always remained with the human operator.

Incident management as a core function

GEPLAN was designed around continuous incident handling. In this environment, disruptions were not exceptional — they were expected: delays, vehicle breakdowns, tank saturation, route disruptions, communication failures, maintenance conflicts, capacity constraints and weather-related incidents. The control centres functioned as real-time incident-management hubs, detecting issues quickly, understanding their impact across the wider system and coordinating the appropriate response.

Structured operational orders

Orders within GEPLAN were not simple dispatch instructions. Each operational order included multiple dimensions: assigned vehicle, assigned driver, origin point, destination point, assigned tank, separation battery, queue position, estimated loading time, estimated unloading time, estimated waiting time, estimated travel time, estimated arrival time, operational restrictions and priority level. This created fully structured operational instructions rather than basic trip assignments.

Trade-off management

One of the most important functions of the control centres was the continuous management of trade-offs. Operators constantly balanced maintenance versus operational continuity, fleet availability versus reliability, efficiency versus risk, urgency versus safety, and short-term execution versus long-term stability. For example, delaying maintenance could increase fleet availability in the short term but also increase risk of failure; prioritising maintenance could improve reliability but reduce immediate operational capacity. These trade-offs became visible in the system, were evaluated centrally and were resolved dynamically by operators.

GEPLAN did not simply digitise logistics. It enabled a transition from fragmented, semi-analog operations to a centrally coordinated operating model, in which decisions remained human, execution became system-supported, coordination became real time, governance became centralised, processes became standardised, and operations became auditable and scalable. It became the operational backbone for logistics, maintenance and field coordination across one of the most complex industrial environments in Mexico.

A self-financed, incremental delivery model

One of the strongest aspects of the GEPLAN case was that it was not implemented through a large upfront investment programme. The transport concessionaire, TETSA, was under constant pressure to maintain operational continuity and retain its contracts with PEMEX. There was no realistic CAPEX available for a large-scale digital transformation. As a result, the programme was designed as a bottom-up, self-financed transformation model. Instead of starting with the most complex areas, the work began where the fastest operational improvements could be achieved.

The programme also had a visible social impact inside TETSA. Part of the operational gains was reinvested into better working conditions for employees — better bonus structures, improved working conditions, new canteen facilities, better accommodation for drivers and field staff, and reduced operational pressure through better planning. This improved morale, reduced turnover and strengthened service quality.

As the system demonstrated measurable results, TETSA strengthened its position with PEMEX. GEPLAN eventually became a competitive differentiator in new contracts and was later accepted by PEMEX itself as a valuable operational model. From that point onward, parts of the system were progressively integrated into PEMEX logistics and operational processes.

Agile funding logic

The entire programme operated through short delivery cycles. Each sprint lasted approximately 15 days and focused on a very specific operational bottleneck. Every improvement generated measurable savings, service improvements or cash-flow benefits that unlocked funding for the next sprint. This meant the programme could continue growing without requiring a large initial CAPEX investment.

An early blueprint for complex-industrial operating models

Although GEPLAN was developed between 2007 and 2010, it can be seen as an early “proto-Industry 4.0” case. The platform was created before Cloud, IoT, smartphones, SaaS platforms and AI became standard industrial tools, yet it anticipated many of the concepts that today are considered central to digital transformation.

JUBAP.net GEPLAN implemented capabilities that are now widely recognised as best practices:

• Integrated logistics control towers across multiple operational centres
• Human-in-the-loop decision support instead of unreliable full automation
• Mission-critical Agile delivery through embedded Tiger Teams
• Predictive maintenance and asset intelligence
• Vendor-integrated inventory and extended supply-chain visibility
• Operational resilience designed for constant disruption, not ideal conditions

The most important lesson from the case is that the primary barrier to transformation is rarely the technology itself. The real challenge is creating visibility, governance, common processes and a shared operational language in environments where information is fragmented and local knowledge dominates. In Chicontepec, the value of GEPLAN came from creating a single operational source of truth across logistics, maintenance, inventory, procurement and field operations.

That challenge remains highly relevant today. Many organisations still struggle with departmental silos and conflicting priorities, heavy dependence on tacit knowledge, fragmented visibility and manual coordination, difficulty balancing efficiency, resilience and risk, and inability to fund large transformation programmes upfront.

Stewarded by The Integral Management Society / IMSV.org. JubAp.Net · info@jubap.net · jubap.net

Historical account of a field-deployed system (2006–2010). The client was TETSA (Transportes Especializados de Toluca, S.A. de C.V.), the hydrocarbon-transport concessionaire operating in PEMEX’s northern region; GEPLAN was a TETSA system deeply integrated with PEMEX logistics and operational processes, not a PEMEX-owned platform. GEPLAN was not an AI or LLM-agent system; its expert-system characteristics supported human decisions rather than replacing them.