Build Operate Transfer for Energy Sector IT: Delivery Guide
Energy sector IT has characteristics that make it structurally harder to staff than most other industries. The systems are old, safety-critical, and deeply integrated with operational technology. The regulatory environment adds compliance obligations that general IT contractors are not familiar with. And the gap between what senior SAP PM, COBOL, or OT/IT integration engineers earn in Western Europe and what the market can absorb in energy IT budgets is wider than in most other sectors.
The Build Operate Transfer (BOT) model addresses this gap by providing a mechanism to build a permanent offshore IT delivery center, staffed with energy-sector-experienced engineers, under the client's direct technical direction. The provider manages the operational overhead. The client manages the work.
Below: the systems a BOT center covers for energy sector IT, the roles it staffs, what the economics look like, and the specific risks that energy operators need to plan for.
Why Energy Sector IT Fits the BOT Model
Energy sector IT fits the BOT model for three structural reasons.
SAP Plant Maintenance, asset management, and operational data platforms are not project-based systems. An oil and gas operator with SAP PM running maintenance scheduling across 200 assets generates continuous development and enhancement demand: configuration changes, integration updates, regulatory reporting changes, mobile maintenance extensions. The same is true for utilities running SAP IS-U for meter-to-cash processes. This demand does not end.
SAP PM and IS-U consultants with energy sector experience are thin on the ground in Western Europe. COBOL engineers who understand batch settlement and trading system interfaces are rarer still. Eastern Europe — Romania, Poland, Bulgaria — has concentrations of this talent from major energy companies and shared service centers that established IT operations there in the 2000s and 2010s.
An oil and gas operator headquartered in Amsterdam or Aberdeen has no infrastructure for employing 15 engineers in Bucharest. The BOT provider handles the employer-of-record function during the Operate phase, manages employment compliance, and transfers fully structured employment relationships when the client is ready to own them.
Systems Covered in an Energy BOT Center
| System category | Technologies | Energy use case |
|---|---|---|
| Asset management ERP | SAP PM, SAP S/4HANA Asset Management, IBM Maximo | Equipment master, maintenance orders, failure analysis, turnaround planning |
| Utilities ERP | SAP IS-U, SAP S/4HANA for Utilities | Meter-to-cash, billing, grid management integration |
| COBOL and legacy | COBOL, PL/1, legacy Java | Trading settlements, batch processing, financial ledgers |
| OT/IT integration | OSIsoft PI (AVEVA PI System), OPC-UA, custom middleware | Sensor data collection, real-time equipment monitoring |
| Cloud platforms | Azure, AWS, GCP | Data lakes, infrastructure modernisation, IoT ingestion |
| Data & Analytics | Databricks, Snowflake, Power BI, Azure Synapse | Asset performance analytics, energy trading data, ESG reporting |
| Regulatory reporting | Custom reporting systems, SAP BW/BI | REMIT, EMIR, emissions reporting, grid code compliance |
SAP for Energy: PM, IS-U, and S/4HANA
SAP Plant Maintenance
SAP PM is the most common SAP module in upstream oil and gas, petrochemicals, and utilities. A BOT center covering SAP PM for an energy operator typically includes:
- SAP PM Functional Consultants: equipment master configuration, maintenance strategies, work order management, turnaround planning support
- SAP PM Mobile: Fiori apps for field technicians, offline mobile maintenance
- SAP QM Integration: quality notifications linked to maintenance processes
- ABAP Developers: custom maintenance reports, interface enhancements, BAPIs for third-party CMMS integration
Salary benchmarks for SAP PM in Romania (gross monthly): €4,000–€6,500 for senior functional consultant. Germany equivalent: €7,500–€11,000.
SAP IS-U for Utilities
Utilities running SAP IS-U (Industry Solution — Utilities) for meter-to-cash processes require specialists who understand the full billing cycle, device management, and grid connection management. SAP IS-U is complex, rarely taught in generic SAP training programs, and the consultant pool is small. Romania has utility-sector SAP experience from shared service centers established by major European energy groups.
S/4HANA Migration in Energy
S/4HANA migration programs in the energy sector are long, complex, and require deep domain knowledge of energy-specific processes — commodity pricing, trading, regulatory reporting. BOT centers supporting energy S/4HANA migrations typically run 24–36 months, covering both the migration program and steady-state production support.
Legacy Systems in Energy IT
COBOL in Energy Trading and Settlement
Energy trading desks at utilities and oil and gas companies run COBOL-based settlement and position management systems that process billions in commodity transactions daily. These systems were built in the 1980s and 1990s and have never been fully replaced — the operational risk of migrating live trading systems is too high, and the business continuity requirements too strict.
COBOL engineers with energy trading domain knowledge — understanding REMIT reporting, physical vs financial settlement, nomination and scheduling interfaces — are extremely scarce in Western Europe. Eastern European BOT centers, particularly in Romania and Poland, have engineers with this background from financial and energy industry exposure.
Legacy Java and Middleware
Energy sector IT typically has a layer of early Java (J2EE, WebLogic, JBoss) middleware connecting SCADA systems, trading platforms, and ERP. This middleware was built by internal teams in the mid-2000s and is now maintained by engineers who are approaching retirement. BOT centers can absorb this maintenance burden and, over the Operate phase, document and progressively modernise the integration layer.
OT/IT Integration and Data Engineering
OSIsoft PI (AVEVA PI System)
The AVEVA PI System (formerly OSIsoft PI) is the dominant real-time data historian in oil and gas, power generation, and utilities. A BOT center covering OT/IT integration for an energy operator typically includes PI System engineers who can:
- Configure and maintain PI Server, PI AF (Asset Framework), PI Vision
- Build custom OPC-UA connectors for SCADA integration
- Extract PI historian data into cloud data lakes (Azure Data Explorer, Databricks) for analytics
Energy Data Analytics
Energy data analytics has grown: asset performance management, predictive maintenance, ESG reporting, energy trading analytics, and grid stability analytics all generate demand for senior data engineers and data scientists.
A data engineering cohort within an energy BOT center:
| Layer | Technologies | Energy use case |
|---|---|---|
| Ingestion | Kafka, Azure Event Hubs, AVEVA PI connectors, Fivetran | Real-time sensor data, SAP delta, trading data feeds |
| Processing | Databricks, Spark, dbt | Asset performance calculation, emissions modelling |
| Consumption | Power BI, SAP Analytics Cloud, Tableau | Asset health dashboards, ESG reporting |
| Governance | Collibra, Great Expectations | Asset data quality, regulatory data lineage |
Cost Benchmarks
Indicative monthly per-head BOT rates for an energy sector delivery center in Romania:
| Role | Romania gross salary (€/month) | BOT per-head rate (est.) |
|---|---|---|
| SAP PM Consultant (senior) | €4,000–€6,500 | €5,200–€8,500 |
| SAP IS-U Consultant (senior) | €4,500–€7,000 | €5,800–€9,100 |
| ABAP Developer (senior) | €4,000–€6,500 | €5,200–€8,500 |
| COBOL Developer (energy domain) | €4,000–€6,000 | €5,200–€7,800 |
| Data Engineer (Databricks/PI) | €4,500–€7,000 | €5,800–€9,100 |
| Azure Cloud Engineer | €4,000–€6,500 | €5,200–€8,500 |
| OT/IT Integration Engineer | €3,800–€6,000 | €5,000–€7,800 |
Build Phase Considerations for Energy
The Build phase for an energy BOT center has two considerations that differ from generic technology sector setups.
Energy infrastructure operators in the EU are subject to NIS2 Directive requirements covering critical infrastructure IT. The BOT provider must conduct enhanced background screening for engineers joining a center that accesses operational or trading systems. This adds 2–4 weeks to the hire-to-start timeline for affected roles.
Domain knowledge transfer is not optional. An ABAP developer who does not understand SAP PM work order confirmation flow in the context of an oil platform maintenance program will write incorrect code. The Build phase must include structured knowledge transfer covering both system architecture and business process context. Energy operators who treat this as optional typically spend the first 6 months of the Operate phase correcting errors.
Recommended Build phase timeline for a 12-person energy BOT center:
| Milestone | Timing |
|---|---|
| Legal/EOR structure and security protocols agreed | Week 2–3 |
| First hire — senior anchor role | Week 8–10 |
| Full team at 12 FTE | Month 4–5 |
| Domain knowledge transfer (on-site, week 1) | Month 2 |
| Domain knowledge transfer (on-site, week 2) | Month 4 |
| NIS2-compliant access controls live | Month 3 |
| Governance and SLA framework live | Month 5 |
Regulatory and Security Considerations
NIS2 Directive. EU energy operators classified as essential entities under NIS2 must apply appropriate security measures to their IT supply chain, including BOT provider relationships. The BOT contract must address: data classification, access control standards, incident reporting obligations, and audit rights. This is not optional — NIS2 enforcement began in October 2024.
REMIT and energy market reporting. BOT centers supporting energy trading systems must operate within REMIT (Regulation on Wholesale Energy Market Integrity and Transparency) compliance boundaries. Engineers with access to trading data are subject to information barrier requirements. This should be addressed in the BOT contract's data governance annex.
Data residency. For EU energy operators, data residency within the EU is generally required for operational and trading data. Romania is an EU member state — data processed by a Romanian BOT center does not leave the EU. This resolves the residency question for European energy operators that is more complex when using Indian or Philippine delivery locations.
Frequently Asked Questions
Can a BOT center support safety-critical systems in energy?
BOT centers can and do support safety-critical-adjacent systems — SAP PM maintenance scheduling, inspection management, permit-to-work integration — but the safety-critical control layer (SIS, PLC, DCS) is outside the scope of IT delivery centers. The BOT center handles the IT systems that support and inform the safety process; the OT systems themselves remain the responsibility of OT engineering teams. The contractual boundary between IT and OT scope must be defined clearly in the BOT agreement.
How do energy companies handle NIS2 compliance in a BOT arrangement?
NIS2 requires essential entities to impose security obligations on their suppliers. In a BOT context, this means: background screening standards written into the employment framework agreement, access control policies agreed before the Build phase is complete, incident reporting SLAs in the operational agreement, and audit rights for the client over the BOT provider's security practices. Providers with existing energy sector clients will have NIS2-aligned processes in place. This should be verified, not assumed.
Is Romania suitable for energy sector BOT delivery given the COBOL and SAP PM requirements?
Romania has active SAP talent with energy sector exposure, primarily from shared service centers established by European energy groups. The SAP PM and ABAP pool is strong. COBOL talent with energy trading domain knowledge requires active headhunting — it exists but is not available through standard job postings. For a center combining SAP PM, data engineering, and COBOL, Romania handles the SAP and data components well, with the COBOL roles requiring more sourcing lead time (10–14 weeks vs 6–8).
What happens to COBOL system knowledge at BOT transfer?
This is one of the most important questions for energy operators using BOT for legacy COBOL maintenance. The contract must require progressive documentation during the Operate phase — not a documentation sprint at the end. Runbooks, batch dependency maps, known failure mode registers, and interface specifications should be living documents updated throughout the engagement. At Transfer, the client receives these documents alongside the employment contracts. Without them, institutional knowledge exists only in the team's heads rather than in transferable form.
How does a BOT center handle on-call requirements for operational energy systems?
Operational energy IT systems — trading settlement, meter-to-cash billing, SCADA integration middleware — require on-call coverage for production incidents. The BOT operating agreement should specify on-call rotation structure, response time SLAs, and escalation paths. Romania (UTC+2/+3) covers European business hours fully. For 24/7 coverage, a follow-the-sun arrangement combining a European BOT center with an Indian resource is standard. On-call compensation structures must comply with Romanian labour law and should be agreed in the employment framework annex.