Tegrity.AI Case Study: GEPLAN – Mission-Critical Logistics Intelligence for PEMEX (2006-)
- Apr 12
- 17 min read
How 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
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, 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.
1. Background, Client and Executive Summary
Tegrity.AI 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 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 Chicontepec Megaproject—one of the most ambitious energy development programmes of its time—the programme combined 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.
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.
CASE STUDY PART 1: Operating Context & Core Challenge
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 geographically 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 of them 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
Therefore, 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 i 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.
Case Study Part 2. Development Style: From Tiger Teams to 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, - 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, 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.
Case Study Part 3. 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
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 maneuvers execution
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
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
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
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
Faster repair cycles
This 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.
Capabilities included:
Purchase requisitions
Supplier interaction workflows
Procurement approvals
Cost tracking
Validation of operational purchases
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
The planning layer included:
Origin and destination definition
Volumes and priorities
Route creation
Assignment logic
Capacity constraints
Distances and travel times
Waiting time considerations
Operational restrictions
Execution Layer
The execution layer included:
Real-time vehicle tracking
Driver communication
Status transitions
Route execution monitoring
Delays and exception handling
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
Workshop readiness
These inputs generated operational outputs including:
Transported volumes
Real versus planned production
Kilometres travelled
Fleet utilisation rates
Bottleneck identification
Capacity constraints
Congestion and delay analysis
This estimation layer became one of the few consistent sources of truth across logistics, production and transport performance.
It enabled analysis at:
Project level
Regional level
Cross-field level
Supplier level
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.
The platform enabled:
Structured operational data exchange
Validation of execution
Reconciliation of transport activity
Support for PEMEX planning decisions
Integration with estimation and reporting processes
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
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.
It combined planning, execution, maintenance, supply chain, telemetry and operational estimation in a single integrated environment.
CASE STUDY PART 4. Operating Model Transformation
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
Local supervisors and 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
Limited ability to coordinate logistics, maintenance and field operations at scale
From Decentralised Operations to Centralised Governance
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
Shared visibility across logistics, maintenance and field operations
Operations were coordinated through four integrated logistics control centres:
Costa Rica
Tinajas
Altamira
PEMEX logistics control centre
These centres operated on the same platform, shared the same operational information and worked under a common decision framework.
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.
This included:
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
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
ISO 14001 for environmental management
The process model became a critical foundation for scaling operations, improving auditability and reducing dependency on informal practices.
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 design principle was clear:
Human intelligence was prioritised over system automation. The system accelerated human decision-making rather than replacing it.
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
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
Escalating conflicts and priorities
Expert System and Decision Support
Although GEPLAN was not an AI platform, it included expert-system characteristics.
The platform incorporated:
Rule-based logic
Predefined operational indicators
Suggested actions
Early warnings
Prioritisation logic
Pre-evaluated scenarios
These capabilities 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.
Examples included:
Delays
Vehicle breakdowns
Tank saturation
Route disruptions
Communication failures
Maintenance conflicts
Capacity constraints
Weather-related incidents
The control centres functioned as real-time incident management hubs.
Their role was to detect issues quickly, understand their impact across the wider system and coordinate the appropriate response.
Structured Operational Orders
Orders within GEPLAN were not simple dispatch instructions.
Each operational order included multiple dimensions, such as:
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
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
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.
Final Positioning
GEPLAN did not simply digitise logistics.
It enabled a transition from fragmented, semi-analog operations to a centrally coordinated operating model.
In this new model:
Decisions remained human
Execution became system-supported
Coordination became real time
Governance became centralised
Processes became standardised
Operations became auditable and scalable
GEPLAN became the operational backbone for logistics, maintenance and field coordination across one of the most complex industrial environments in Mexico.
CASE STUDY PART 5. . Zero-CAPEX 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.
Phase 1 – Warehouse Stabilisation and Inventory Control
The first issue was warehouse performance. Inventory accuracy was poor, the legacy software did not reconcile stock correctly, and losses, delays and shortages were common.
The initial focus was therefore not on replacing software, but on stabilising the physical operation:
Cleaning and reorganising the central warehouse
Improving shelving, storage logic and operational controls
Cleaning master data and inventory records
Adding safeguards and controls around the legacy software
Rebuilding confidence in stock accuracy
These relatively small operational improvements immediately reduced losses, improved service levels and created the basis for a much more reliable inventory and order-control process.
Phase 2 – Extended Warehouse Management and Consignment Model
Once inventory reliability improved, TETSA was able to implement an extended warehouse management model with third-party suppliers.
Because suppliers could now trust the quality of inventory data, they agreed to leave parts on consignment instead of requiring immediate payment for all stock.
Suppliers could monitor inventory usage directly and replenish based on actual consumption. This created major working-capital benefits:
Lower cash tied up in inventory
Faster access to critical parts
Improved supplier relationships
Better liquidity and cash flow
These financial improvements released additional budget that could be reinvested into the next stages of the programme.
Phase 3 – Remanufacturing and Purchase Optimisation
The next step was the introduction of a remanufacturing model.
Instead of discarding damaged components or purchasing new parts immediately, used parts were routed to local workshops for repair and remanufacturing. Recovered parts were then returned into inventory at a significantly lower cost.
This generated major savings and supported the development of a more advanced purchasing model, including:
Demand forecasting for parts and consumables
Better purchasing visibility
Improved supplier coordination
Lower emergency purchases
Reduced waste and obsolescence
The savings created in this phase were reinvested into the workshop and maintenance systems.
Phase 4 – Workshop Intelligence and Predictive Maintenance
Once inventory and purchasing were stabilised, the programme moved into workshop management.
Initially, the focus was on preventive maintenance planning, service intervals and availability forecasting. Later, the model evolved into early predictive maintenance capabilities:
Anticipating when vehicles would likely fail
Identifying failure patterns by route type and terrain
Forecasting component replacement cycles
Improving workshop scheduling
Increasing vehicle availability
Reducing downtime and emergency repairs
This phase created some of the largest operational benefits in the programme because vehicle availability improved significantly while workshop costs and disruption decreased.
Phase 5 – Administration, Logistics and PEMEX Integration
Only after the previous operational layers had been stabilised did the programme move into the most complex area: logistics.
At this stage, GEPLAN expanded into:
GPS and vehicle tracking
Route control and trip management
Order management
Budget control
Integration with PEMEX logistics and operational processes
Real-time coordination between transport, maintenance and field operations
The programme also had a visible social impact inside TETSA.
Part of the operational gains was reinvested into better working conditions for employees, including:
Better bonus structures
Improved working conditions
New canteen facilities
Better accommodation for drivers and field staff
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.
GEPLAN delivered positive benefits within the first three months, and those gains were continuously reinvested into the next stage of the transformation.
GEPLAN was not funded through a traditional investment programme. It was funded through its own operational results.
CASE STUDY PART 5. CURRENT RELEVANCE
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.
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
Inability to fund large transformation programmes upfront
GEPLAN addressed these problems almost two decades ago through an incremental, self-funded and highly operational approach.
For this reason, it should not be viewed only as a historical project, but as an early blueprint for many of the operating models and decision-support systems now used in complex industrial environments.
More info on http://tegrity.AI info@tegrity.AI
Comments