Dima Trubnikov

← All work

Offshore oil-and-gas equipment procurement · via Softeq

EIT — Where a Procurement Argument Becomes an Interface

EIT — Where a Procurement Argument Becomes an Interface

EIT — Where a Procurement Argument Becomes an Interface

Buying a subsea separator is not a purchase. It is an argument about several hundred numbers, and it used to live in email.

Buying a subsea separator is not a purchase. It is an argument about several hundred numbers, and it used to live in email.

Client

Offshore oil-and-gas equipment procurement · via Softeq

My role

Product Designer — the specification model, the negotiation table and every role's view of it

Timeline

2019 – 2020

Impact

15 system types · 4 roles on one record · hundreds of parameters per specification · the most complex data model in the portfolio

The challenge

The challenge

Offshore equipment is not bought from a catalogue. A separator, a compressor, a subsea tree or a blow-out preventer is a specification of several hundred parameters, and buyer and supplier negotiate it for weeks. That negotiation ran on email and spreadsheets. Versions diverged, a comment about one parameter sat in a different thread than the parameter itself, and by the time a value was agreed nobody could say why. The cost of the package moved with every settled figure, and no one saw it move. Fifteen system types, each with its own parameter set and its own suppliers. Four roles who all write to the same record but must never see the same thing.

Offshore equipment is not bought from a catalogue. A separator, a compressor, a subsea tree or a blow-out preventer is a specification of several hundred parameters, and buyer and supplier negotiate it for weeks. That negotiation ran on email and spreadsheets. Versions diverged, a comment about one parameter sat in a different thread than the parameter itself, and by the time a value was agreed nobody could say why. The cost of the package moved with every settled figure, and no one saw it move. Fifteen system types, each with its own parameter set and its own suppliers. Four roles who all write to the same record but must never see the same thing.

What I did

What I did

1. Made the argument visible. Buyer and supplier were resolving hundreds of parameters in email, where a value and the reason for it lived in different threads. I put both sides on one row — designed value, requested value, agreed value — so a disagreement is a cell, not a correspondence.

1. Made the argument visible. Buyer and supplier were resolving hundreds of parameters in email, where a value and the reason for it lived in different threads. I put both sides on one row — designed value, requested value, agreed value — so a disagreement is a cell, not a correspondence.

2. Attached the conversation to the parameter, not the document. Comments thread on the individual row, deviations flag themselves the moment a requested value differs from the designed one, and the decision is recorded with a name and a date. Nobody has to remember why a number moved.

2. Attached the conversation to the parameter, not the document. Comments thread on the individual row, deviations flag themselves the moment a requested value differs from the designed one, and the decision is recorded with a name and a date. Nobody has to remember why a number moved.

3. Split progress into three meters instead of one status. A specification is never simply "in progress" — it is found but unanswered, or answered but unverified. Search, Collaboration and Validation each track their own share, which is what let a buyer see where a package was actually stuck.

3. Split progress into three meters instead of one status. A specification is never simply "in progress" — it is found but unanswered, or answered but unverified. Search, Collaboration and Validation each track their own share, which is what let a buyer see where a package was actually stuck.

4. Gave each role its own view of the same record. Buyer, supplier, inspection engineer and the contractor across projects see one specification rendered four ways — the supplier never sees a rival's quote, the engineer sees the points they have to sign off, the contractor sees cost rolling up across projects.

4. Gave each role its own view of the same record. Buyer, supplier, inspection engineer and the contractor across projects see one specification rendered four ways — the supplier never sees a rival's quote, the engineer sees the points they have to sign off, the contractor sees cost rolling up across projects.

Fig. 01 — One record, four ways in

Who sees what

01 · BUYER

Procurement engineer

Owns the specification and the budget

Search by parameters

Short list

Request to supplier

Negotiation table

Approve or reject

02 · SUPPLIER

Equipment manufacturer

Answers with what it can build

Incoming requests

Requested value per parameter

Deviation with a reason

Inspection points

03 · ENGINEER

Inspection & test

Signs off that it was verified

Witness & hold points

Request validation

Decision per parameter

Validation history

04 · CONTRACTOR

Across projects

The only role that sees more than one

Project list

Cost roll-up

Documentation

Progress by stage

Fifteen system types share this shape — separators, compressors, subsea trees and manifolds, blow-out preventers, drilling risers, pipelines, umbilicals. The supplier never sees a rival’s quote; the contractor is the only role that sees across projects.

Fig. 02 — What shipped

Delivered design, clickable

EIT, delivered design — Search: Search by specification: the buyer enters the process values the equipment has to meet.
01 / 16 · Search by specification: the buyer enters the process values the equipment has to meet.

The solution

The solution

A platform where the specification itself is the workspace: search by technical parameters across 15 system types, a short list, a request to the supplier, and then the negotiation table where every parameter is resolved in place. Threaded comments per row, deviation flags, inspection points tied to the values they verify, a validation history with who decided what and when, and a project cost that recalculates as the specification settles.

A platform where the specification itself is the workspace: search by technical parameters across 15 system types, a short list, a request to the supplier, and then the negotiation table where every parameter is resolved in place. Threaded comments per row, deviation flags, inspection points tied to the values they verify, a validation history with who decided what and when, and a project cost that recalculates as the specification settles.

What I’d do differently

What I’d do differently

I designed the table before I understood the argument. The three-column model came out of the data — designed, requested, agreed — and it was right, but I arrived at it by mapping the fields rather than by watching a negotiation. The threads, the deviation flags and the three progress meters all came later, once it was obvious that the hard part was not storing the values but knowing whose turn it was. I would start from the argument next time, and let the table fall out of it.

I designed the table before I understood the argument. The three-column model came out of the data — designed, requested, agreed — and it was right, but I arrived at it by mapping the fields rather than by watching a negotiation. The threads, the deviation flags and the three progress meters all came later, once it was obvious that the hard part was not storing the values but knowing whose turn it was. I would start from the argument next time, and let the table fall out of it.

More work

All case studies →

All case studies →

All case studies →

d.trubnikov@me.com

© 2026 Dima Trubnikov · Vilnius, Lithuania (EU)