Auto
Skip to Content

Transforming End-to-End Engineering & Project Operations with Odoo ERP for Aesthetix Global

Aesthetix Global: Odoo ERP for EPC Projects | KoderXpert

Engineering · EPC · System integration · Enterprise Odoo ERP

Aesthetix Global: EPC across six sectors and several countries, held together by email and personal follow-up

every project, every approval, one platform ✨

Aesthetix Global is an engineering and system integration company delivering turnkey solutions across Oil & Gas, Energy, Marine, Transportation, Utilities and Infrastructure. Their work is EPC in the truest sense: engineering, procurement and construction executed simultaneously, across multiple countries, under contractual deadlines where a single delayed approval can hold up an entire site. The complexity was real. The systems supporting it were not. KoderXpert put twelve Odoo modules and five departments on one governed data foundation.

A construction site crane lifting a crate, a revision-controlled engineering drawing, an approval stamp and a live dashboard tile, representing the twelve-module Odoo ERP built for Aesthetix Global's EPC projects material on site Rev C · approved one drawing, one trail budget vs actual, live
drawing to site, every approval on record ✨
wow!0Odoo modules live on one data foundation
0sectors served on one platform
0departments on shared data
0paper approval routes left
Client
Aesthetix Global
Industry
Engineering · EPC · System integration · Infrastructure
Platform
Odoo ERP, 12 modules
Implementation partner
KoderXpert Technologies
Headline result
One source of truth, zero paper approvals

01 · Overview

The 30-second version

  • Aesthetix Global is an engineering and system integration company delivering turnkey EPC solutions across Oil & Gas, Energy, Marine, Transportation, Utilities and Infrastructure, in multiple countries, under contractual deadlines.
  • Every project ran as its own island, held together by email, spreadsheets and personal follow-up. Drawings and MICs were approved by hand, budgets were reconciled after the money was spent, site data came back on paper, nobody had an asset register, and leadership saw numbers after the decision window had closed.
  • KoderXpert delivered twelve Odoo modules on one governed data foundation: a version-controlled engineering repository, a multi-level approval engine with MIC control, procurement tied to project demand, live budget and cost control, site, man-hour and asset management, and executive dashboards. Five departments, one source of truth, no paper approval routes left.

02 · Where the old way broke down

What was going wrong before Odoo?

Seven separate habits, one shared cause

Each department had built a workaround that functioned on its own. None of them connected. Every link between them was a person, an email or a spreadsheet, and every one of those links was a place the project could quietly fall behind. Each of these was survivable alone. Together they made the project the last thing anyone could see clearly.

Engineering worked apart from execution

Drawings, deliverables and revisions lived apart from the schedule they were meant to serve. Engineering, procurement, construction, finance and HR each held part of the truth, none held all of it.

The cost → five partial truths, no whole one

Documents approved by hand

Every drawing, MIC and deliverable moved through multi-level sign-off by email, chased manually one signature at a time, while site work waited on an inbox.

The cost → a stalled approval, a stalled site

Budgets reconciled after the fact

Project cost was assembled retrospectively in spreadsheets, long after the money had been committed. Profitability was a post-mortem, not a control.

The cost → cost control that was really accounting

Procurement ran on request and memory

Material requirements were raised informally with no structured link to project demand or logistics, so material arrived late, early, or in the wrong quantity.

The cost → the wrong material at the wrong time

Site data came back on paper

Man-hours, site services and construction progress were captured manually, re-typed into the office system, and trusted more than they deserved to be. Assets had no central register at all.

The cost → a trust gap between site and office

Management reported last

By the time leadership saw a number, the decision window had usually already closed. Decisions were made on stale data, or on instinct.

The cost → deciding after it mattered
the complexity was real, the systems were not

03 · The turnaround

Drag it and see the before & after yourself

Slide the orange handle. Left is the email-and-spreadsheet era, right is the governed platform.

✗ Before the implementation
  • Drawings, MICs and deliverables approved by email, one signature at a time
  • Project cost reconciled in spreadsheets after the money was committed
  • Material raised on request and memory, with no link to project demand
  • Man-hours and site progress on paper, re-keyed in the office
  • "How is this project doing?" took a week and four departments

the email chase 😵

one governed platform ✨

✔ After the implementation
  • Approvals raised, routed, escalated and closed with a full audit trail
  • Budget held in the project record, committed vs incurred cost live
  • Requisitions raised against project demand, logistics in the same flow
  • Timesheets, attendance and leave unified with man-hour planning
  • "How is this project doing?" means opening a dashboard

← drag toward the inbox · drag toward the platform →

04 · The plan

What we aimed to achieve

Eight objectives were agreed before the first module was configured; they group into six. Hover any goal to tick it off.

Digitise engineering and execution end to end: track milestones and deliverables against the plan, not against memory.

Automate procurement and logistics: tie purchasing directly to project demand.

Bring cost control forward: budget visibility during the project, not after it.

Centralise document management: controlled, auditable approvals for every drawing, revision and MIC.

Optimise manpower planning: structured man-hour tracking, plan against actual, per project.

Real-time dashboards on a platform built for scale: leadership sees live data, on a foundation ready for multi-country growth.

05 · What we delivered

What did KoderXpert build?

Five functions, one data foundation

The architecture question in EPC is not which tools are best. It is where the seams are. Engineering, procurement, construction, finance and HR now write to the same Odoo database, so documents and approvals are governed and auditable, procurement and cost are tied to live project demand, and site, labour and assets are captured where the work happens.

Block 01

Engineering document management

A single governed repository for engineering deliverables: version-controlled drawings and specifications, full revision history per deliverable, an auditable change trail by user and date, and one retrieval point for every discipline.

who changed what, and when
Block 02

Project master & milestone tracking

Each project carries a structured master record, with milestones tracked against the baseline plan and deliverables linked to the schedule, so slippage is visible while it can still be corrected.

slippage seen early, not at handover
Block 03

Approval engine & MIC control

Approvals rebuilt as a configurable workflow engine: raised in the project context, routed to the right approver, escalated when stalled, closed with a full audit trail. Material Inspection Certificates captured and approved inside the same system.

the email chase disappeared
Block 04

Procurement & logistics

Requisitions raised against project demand, structured vendor management, and logistics visible in the same flow, so there is no informal, off-system purchasing.

buying against real demand
Block 05

Budgeting & cost control

Project budgets held inside the project record and tracked live against committed and incurred cost, with variance visible during execution. Profitability became a control lever rather than a post-mortem.

cost control, not accounting
Block 06

Site, man-hours & assets

Site services and construction progress captured in the system rather than on paper; timesheets, attendance and leave unified with man-hour planning; and one central asset register with location, allocation, condition and lifecycle, across every project and every country.

no re-keying, no trust gap
drawing raised routed & approved requisition site timesheet live dashboard
no connectors, no nightly sync, no reconciliation job: all twelve modules write to the same record ✨

06 · Functional deep dive

How the connected system actually works

Twelve modules is a list. This is what they do for Aesthetix Global, from the engineering repository to the executive dashboard.

Documents and the project master

We started where EPC projects actually succeed or fail: control of documents and control of decisions.

  • One governed repository: every drawing, revision and specification held in one place, in Odoo Documents, with a clear trail of who changed what and when.
  • Revision history per deliverable: the current revision is never in dispute, and the previous ones are never lost.
  • Structured project master: each project carries milestones against the baseline plan and deliverables linked to the schedule.
  • Slippage surfaced early: because deliverables and schedule are one record, a late drawing shows up as a late milestone while it can still be corrected.

The approval engine and MIC control

A stalled approval is a stalled site. Approvals were rebuilt as a configurable workflow engine in Odoo Approvals, and this was deliberately the first thing to go live.

  • Raised in the project context: an approval belongs to the project, drawing or purchase it concerns, not to an email thread.
  • Routed, then escalated: requests go to the right approver automatically and escalate when they stall, so nothing waits in an inbox unnoticed.
  • Closed with a full audit trail: every decision records who approved what, and when.
  • MICs inside the system: Material Inspection Certificates, a compliance and quality choke point in EPC, are captured and approved with structure rather than living in a folder and being found only when someone goes looking.

Procurement tied to demand

Buying on request and memory is fast until material arrives late, early, or in the wrong quantity. Purchasing was tied directly to project demand.

  • Requisitions against project demand: a material requirement is raised from the project that needs it, so the link back to the schedule is a record.
  • Structured vendor management: vendors, orders and history in Odoo Purchase rather than in a personal contact list.
  • Logistics in the same flow: Inventory tracks material and its movement, so what is ordered, what has arrived and what is holding up site are the same question.
  • No off-system purchasing: because the requisition is the only route, informal buying stopped.

Budgeting and cost control, during the project

Cost data that arrives after commitment is not cost control, it is accounting. Budgets were built into the live project workflow.

  • Budget inside the project record: the number the project was bid on lives with the project, not in a separate file.
  • Committed vs incurred, live: Accounting records both as they happen, so the gap between what is promised and what is spent is always current.
  • Variance during execution: an overrun is visible while there is still time to act on it.
  • Profitability as a control: project margin moved from a retrospective report to a lever the project manager can pull.

Site operations and man-hours

Labour is the dominant variable cost in engineering services. Planning without actuals is guessing; actuals without planning is bookkeeping. Both together give a forecast you can bid on.

  • Site captured in the system: site services and construction progress entered where the work happens, closing the gap between what was happening on site and what the office knew.
  • Timesheets, Attendance and Leave unified: three HR modules feed one man-hour picture, so availability, presence and hours booked agree.
  • Labour cost per project: actual man-hours against plan, per project, which is what makes the next bid credible.
  • Employees as the central record: one workforce master behind every site and office team.

Assets and executive visibility

Assets used to live in someone's head. Leadership used to see a number after the decision window closed. Both were fixed by the same fact: everything now writes to the same system.

  • One asset register, every country: location, allocation, condition and lifecycle for every company asset, across every project.
  • Project health: milestones, deliverables and slippage in real time.
  • Budget vs actual and procurement status: while the project is still running: what is ordered, what has arrived, what is holding up site.
  • Man-hour consumption, approval bottlenecks, asset utilisation: plan against actual per project, where decisions are stuck and with whom, and what is deployed where. Management stopped waiting for reports. The report was always there.
one project approval requisition timesheet one record

Why the seams matter more than the tools

An approval, a requisition and a timesheet are three views of the same project, not three systems kept in step by a person. The moment engineering, procurement and construction live in separate tools, reconciliation becomes someone's full-time job, and the reconciliation is always late. Putting all twelve modules on one data model is what removed that job.

07 · How we built it

How was the Odoo project delivered?

Discovery to post-go-live support, with the approval engine landing first

The real EPC workflow was walked department by department before anything was touched in Odoo. Fixing approvals first delivered visible relief in weeks and bought the organisational trust needed for the harder modules that followed.

1

Requirement discovery walk the workflow first

The real EPC workflow was walked department by department, engineering to site to finance, before touching Odoo.

2

ERP solution design design around how projects actually run

Modules, data flow and approval logic were architected around how the client actually executes projects, not around a generic template.

3

Configuration, development & workflow automation standard plus custom

Standard configuration plus custom Python and Odoo ORM development and QWeb reporting. The approval engine, procurement flows and document control rules were built here, and the approval engine went live first.

4

Data migration bring the history

Existing project, vendor, asset and employee data moved into the new platform, so it started from the real state of the business.

5

User acceptance testing live project scenarios

Every workflow validated against live project scenarios with the client's own teams, so problems surfaced in testing rather than on site.

6

Training & go-live five departments

Engineering, procurement, site, HR and finance users trained on the flows they own, then the platform launched.

7

Post-go-live support stay through stabilisation

KoderXpert stayed with the client through stabilisation and adoption, rather than handing over at launch.

08 · Engineering notes

The decisions behind the platform

Why one platform, why approvals first, why budgets in execution, why timesheets with planning, and the question clients ask first: why Odoo.

One platform instead of best-of-breed tools

EPC fails at the seams. Engineering, procurement and construction have to share one version of the truth.

  • Separate systems mean reconciliation: the moment the functions live apart, keeping them in step becomes someone's full-time job, and the reconciliation is always late.
  • Twelve modules, one data model: all twelve went live on the same foundation, with no connectors, no nightly sync and no reconciliation job.
  • Five departments, one login: engineering, procurement, construction, finance and HR are modules of one product rather than products stitched together.

Document control and approvals came first

Sequencing was a deliberate call, and it is the one that earned the rest of the project.

  • A stalled approval is a stalled site: in EPC the approval chain is the critical path, so it was the first thing fixed.
  • Relief in weeks: the approval engine delivered visible relief early, which bought organisational trust for the harder modules that followed.
  • The email chase disappeared: raised, routed, escalated, closed, every step with an audit trail.

Budgeting baked into project execution

Cost data that arrives after commitment is not cost control. It is accounting.

  • Budget in the workflow: embedding the budget into the live project record converts a report into a decision.
  • Committed before incurred: a purchase commits cost the moment it is approved, so the variance shows before the invoice does.
  • Same ledger as operations: Accounting sits on the same database as Project and Purchase, so the books describe the events the project recorded.

Timesheets unified with man-hour planning

Labour is the dominant variable cost in engineering services, so this was not an HR nicety.

  • Plan and actual in one place: planning without actuals is guessing; actuals without planning is bookkeeping. Together they give a forecast you can bid on.
  • Three modules, one number: Timesheets, Attendance and Leave feed the same man-hour picture, so hours booked, presence and availability cannot disagree.
  • Captured on site: hours are entered where the work happens, which removed the re-keying step and the trust gap that came with it.

Why Odoo

The client needed twelve modules to talk to each other on day one, and to add more later without a re-platform.

  • Integrated by architecture: modules share one data model rather than being stitched together through connectors that need maintaining.
  • Open to customisation: Python, the Odoo ORM and QWeb let us build what EPC actually needs, MIC capture and approval routing, instead of bending the business to the product.
  • Extensible without re-platform: new modules join the same foundation, so growth into new countries does not trigger a rebuild.
  • Affordable against enterprise alternatives: the same functional coverage at a licence and implementation cost the client could commit to across a multi-country rollout.

Executive visibility was the point of all of it

Dashboards were not a module on the list. They were the reason the list existed.

  • Live by construction: because five functions write to the same system, leadership sees project health, budget vs actual, procurement status, man-hour consumption, approval bottlenecks and asset utilisation without anyone compiling a report.
  • Built last, on trusted data: reporting was layered on once the underlying records were governed, not over messy inputs.
  • Reporting versus running: the difference between a company that reports on its projects and a company that runs them.

09 · The impact

What changed after go-live?

Ten outcomes across efficiency, governance, collaboration and the speed of decisions

the part clients screenshot
0Odoo modules live on one data foundation
0sectors served on one platform
0departments working from shared data
0paper approval routes left
  • Project operations fully digitised: paper and email workflows replaced by a single, auditable system
  • Faster approval cycles: the approval engine removed the manual chase, so decisions move and so does the site
  • Budget and profitability visible: cost control shifted from retrospective reporting to live management
  • Procurement streamlined: purchasing and logistics tied to real project demand instead of informal requests
  • Document control centralised: one governed source for every engineering deliverable, revision and MIC
  • Man-hour tracking accurate: real labour cost per project, and a credible basis for the next bid
  • Collaboration improved: engineering, procurement, construction, finance and HR working from the same truth
  • Forecasting improved: better inputs produced better predictions
  • Leadership on real-time data: decisions made on current data, not last month's
  • The platform scales: ready for multi-country expansion without a rebuild

10 · Under the hood

Technologies & core skills

ERP · Odoo ERP, 12 modules on one database Backend · Python, Odoo ORM Frontend · XML, QWeb, HTML, CSS, JavaScript Database · PostgreSQL Reporting · QWeb reports & executive dashboards Modules · Project, Documents, Purchase, Inventory, Accounting, Employees, Attendance, Leave, Timesheets, Assets, Approvals, Dashboards
Project management EPC ERP Procurement automation Document management Asset management HRMS Workflow automation Business process analysis ERP consulting Data migration User training
the real change, in one line
Before: "How is this project actually doing?" required a week, four departments, and a spreadsheet nobody fully trusted. After: it required opening a dashboard.
That is the difference between a company that reports on its projects and a company that runs them.

11 · Quick questions, honest answers

Thinking about a similar build?

Yes. Aesthetix Global runs twelve Odoo modules on one database covering project management, documents, purchase, inventory, accounting, employees, attendance, leave, timesheets, assets, approvals and dashboards. Engineering, procurement, construction, finance and HR write to the same records, so there are no connectors, no nightly sync and no reconciliation job.

Because EPC fails at the seams. Engineering, procurement and construction have to share one version of the truth. The moment they live in separate systems, reconciliation becomes someone's full-time job, and the reconciliation is always late. One data model removes that job entirely.

An approval is raised in the project context, routed automatically to the right approver, escalated when it stalls, and closed with a full audit trail. It was built as a configurable workflow engine in Odoo Approvals with custom routing logic, and it was the first thing to go live, because in EPC a stalled approval is a stalled site.

Yes. MICs are a compliance and quality choke point in EPC, so they were brought into the system with structured capture and approval rather than living in a folder. Each MIC is a record tied to the project and material it concerns, with the same routing and audit trail as any other approval.

Through a single governed repository in Odoo Documents: version-controlled drawings and specifications, full revision history per deliverable, an auditable change trail by user and date, and one retrieval point for every discipline. Deliverables are linked to the project schedule, so a late drawing shows as a late milestone.

The budget is held inside the project record and tracked live against committed and incurred cost, with variance visible during execution. A purchase commits cost the moment it is approved, so an overrun shows before the invoice arrives. Profitability becomes a control lever rather than a post-mortem.

Requisitions are raised against the project that needs the material, vendor management is structured in Odoo Purchase, and logistics is visible in the same flow through Inventory. Because the requisition is the only route to a purchase, informal off-system buying stopped, and material stopped arriving late, early or in the wrong quantity.

Timesheets, attendance and leave were unified with man-hour planning, so plan and actual sit in one place. Hours are captured where the work happens rather than re-keyed in the office, which gives accurate labour cost per project and a credible basis for resourcing and bidding the next one.

Yes. Odoo's asset management gives one central register of company assets, with location, allocation, condition and lifecycle, across every project and every country. Asset utilisation, what is deployed, where and on what, is one of the six views on the executive dashboard.

Project health (milestones, deliverables and slippage), budget vs actual while the project is running, procurement status, man-hour consumption against plan, approval bottlenecks and who holds them, and asset utilisation. Because every department writes to the same system, the report is always there rather than compiled at month end.

Through a phased delivery: requirement discovery walked the real workflow department by department, the solution was designed around it, configuration and custom development followed, then data migration, user acceptance testing against live project scenarios, department-by-department training, go-live, and post-go-live support through stabilisation.

KoderXpert is an Odoo Ready Partner that walks the workflow before touching the software, sequences delivery so the most painful bottleneck is fixed first, and builds what EPC actually needs in Python and QWeb rather than bending the business to the product. Talk to KoderXpert about your projects.

a stalled approval is a stalled site

Running complex projects on disconnected systems?

Tell us where the seams are: drawings approved by email, budgets reconciled after the fact, material raised on memory, man-hours on paper. KoderXpert walks the workflow first and configures second, until every department is reading the same project.


the story continues...

More client stories

All case studies

Your business could be the next story here.

Same process, already proven across 20+ industries.

Your business is not a template. Your ERP should not be either.

Every project on this page started the same way: a conversation about how the business actually runs today, and where the manual hand-offs are. That is a good place to start yours too.