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.

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.