Deep dive · Semco Maritime × QAECY
Buy the commodity,model
What to do when the ERP reaches end of support, without buying the next lock-in.
This is the deep dive behind the ERP slide in block 01. Use it when the conversation turns to the ERP that is going out of support, or as a separate session with management, IT and finance. The claim: replacing one big system with another big system solves this year's problem and creates the next one. Ask first: who in the room owns the ERP decision, and what is the deadline?
01 ERP deep dive · The situation
The ERP is reaching end of support
The usual answer is a new ERP suite. Here is the path that answer takes.
Support ends No more updates, security fixes or new legal formats.
Select a suite Long RFP, demos, a shortlist of large vendors.
Fit-gap & customise Processes bent to the vendor's model. Gaps closed with custom code.
Migrate & go live Open items move. History often stays behind in an archive.
Locked in again The vendor's data model is now Semco's model, until the next end of support.
…and the cycle starts again
Every customisation is code to redo at the next upgrade, and a reason not to leave.
Engineering, the yard and the field still live outside it. The suite doesn't model a substation.
Your data leaves on the vendor's terms: their export, their format, their price.
Don't claim anything about Semco's current ERP or its contract: ask. When does support end? Which modules do you actually use? How much is customised? Then walk the path. Fragment 1: the loop back. A suite replacement doesn't remove the problem; it resets the clock on it. Fragment 2: the three things that make the next exit as hard as this one. Ask: when you left the last system, what did you leave behind?
01 ERP deep dive · The choice
Two ways out
The biggest cost isn't the licence. It's being locked in again for the next decade.
This is the decision in one slide. The left column isn't wrong for every company; it's wrong for a company whose value sits outside what an ERP models. Ask finance and IT separately: what would you need to see to trust the right-hand column? Write their answers down; the rest of the deck should answer them.
01 ERP deep dive · The rule
Buy, build, integrate
Buy Regulated and standard
Bookkeeping, payroll, VAT, e-invoicing. The law or the market defines how it works, and many vendors sell it. Doing it differently has no upside.
Would an auditor or a tax authority care how you did it? Buy it.
Build How Semco makes money
Change impact, interfaces, weight, park takeovers, work packs. Specific to substations and O&M, and spread across systems no vendor connects.
Would a competitor pay to know how you do it? Build it.
Integrate Everything in between
Each tool keeps its job. The model connects them: one identifier per thing, one master system per fact.
Does the fact live in one tool and matter in another? Model it.
Keep bought tools as standard as possible . Every customisation is a future migration.
Three tests, one per column. The interesting conversations are at the borders: purchasing is bought, but a PO linked to a transformer and a zone is Semco's. That's what "integrate" means. Ask: name one function where you're not sure which column it belongs in. We'll put it on the next slide.
01 ERP deep dive · Function by function
What goes where
Function Choice Why Example tools
Finance & bookkeeping Buy Statutory and audited. Same rules for everyone. Business Central, e-conomic, Uniconta Payroll Buy Tax law and collective agreements, per country Zenegy, Danløn (DK); local providers elsewhere Expenses Buy Standard flow: cards, receipts, approval Pleo, or the finance tool's own module E-invoicing NemHandel · Peppol Buy Regulated formats and networks Built into most Nordic finance tools Purchasing Buy · integrate Standard PO flow; POs link to equipment and zones The finance tool's purchasing module CRM Buy · integrate Standard pipeline; contracts and CRs feed the model HubSpot, Dynamics 365 Document control Buy · integrate Revisions and transmittals are standard; content isn't Aconex, SharePoint-based DMS Engineering / CAD Buy · integrate Specialist tools; the model reads their lists AVEVA and discipline tools Planning Buy · integrate Scheduling engines are mature Primavera P6 CMMS Buy · integrate Work orders are standard; work packs are not IFS, Maximo HR & competence Buy · integrate Contracts are HR; competence per task is Semco's The HR tool, plus matching built on the model QHSE Buy · integrate NCRs and incidents are standard; briefings are built Standard QHSE suites SCADA / CMS Integrate Owned by the park owner or the OEM; read the signals Power Factors (Greenbyte), OEM portals Yard progress Build Per location, specific to how Semco builds Built on the model Weight control Build Reconciles model, vendor data and reports Built on the model
Examples, not recommendations. We don't know which tools Semco uses.
Don't read the table out. Point at the shape: most rows are "buy" or "buy and integrate"; only a few are "build". Building is the exception, and it's reserved for what makes Semco different. Be explicit: the product names are examples from the Danish and Nordic market, not recommendations, and we are not claiming Semco uses any of them. Payroll is the one to watch: every country Semco employs people in has its own rules. Ask: which rows would you move? Which countries do you run payroll in?
ERP deep dive · Part 2
The model in the middle
One identifier per thing, one master per fact, and what it looks like in Turtle.
From here it gets more concrete. For management: the next two slides are the rules. For IT and engineering: the slides after that show actual modelling and validation code. Everything is in open W3C standards.
01 ERP deep dive · Architecture
Bought tools below, Semco's model in the middle
connector connector connector connector connector connector connector connector
Finance tool Payroll Expenses CRM Planning · P6 Doc. control CMMS HR tool Bought Bought Bought Bought Bought Bought Bought Bought
Kept standard, each one replaceable. Connectors read APIs, webhooks and exports, and map them to the model.
Cue Index
the semantic model Semco owns
Semantic model
One identifier per thing
Provenance
Permissions
Validation · SHACL
Orchestration
RDF · OWL · SPARQL
open standards, portable
MCP · SDK · SPARQL
Built on the model
apps and agents, small and many
Change impact
Interface register
Requirements traceability
Weight & CoG
AI agents
Park takeover due diligence
Work packs
Procedure briefings
Progress per location
PO variation
CR status
work order
Build it up in four steps. One: the bought tools, kept standard, each with a connector. Two: the Cue Index in the middle, with identity, provenance, permissions, validation and orchestration. Three: what Semco builds on top: small apps and agents, all reading the same model. Four: write-back. The model never writes into a tool's database; it calls the tool's API, like a user would, and only after the change has been validated. Ask IT: which of your systems has an API you trust today?
01 ERP deep dive · Identity
One identifier per thing
System Supplier Project Technician
Finance tool V-10318 P-2026-014 – CRM ACC-5521 OPP-0881 – P6 – OSS2-EPC AKR Doc. control VND-TRA-01 – – HR tool – – E-1187 Semco :sup-0042:OSS-2:anna-k
@prefix : <https://example.org/semco#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
:sup-0042 a :Supplier ;
rdfs:label "Transformer supplier A" ;
:knownAs [ :inSystem :FinanceTool ; :id "V-10318" ] ,
[ :inSystem :CRM ; :id "ACC-5521" ] ,
[ :inSystem :DMS ; :id "VND-TRA-01" ] .
:OSS-2 a :Project ;
:knownAs [ :inSystem :FinanceTool ; :id "P-2026-014" ] ,
[ :inSystem :P6 ; :id "OSS2-EPC" ] ,
[ :inSystem :CRM ; :id "OPP-0881" ] .
:anna-k a :Technician ;
:knownAs [ :inSystem :HRTool ; :id "E-1187" ] ,
[ :inSystem :P6 ; :id "AKR" ] .
Illustrative IDs · valid Turtle
This is the single most important rule for IT. Each tool keeps its own number for the supplier, the project, the person; we don't fight that. The model gives each thing one Semco identifier and remembers what every tool calls it. When the finance tool is replaced, you add the new vendor numbers to the same nodes, and every app, query and agent keeps working. Ask: how do you match a supplier between finance and the document system today? Who maintains that list?
01 ERP deep dive · Ownership
One master system per fact
Fact Master Everyone else
PO amount and lines Read it, link it to equipment and zones Customer contact Read it Baseline date Read it, flag conflicts Document revision Read it, link it to requirements Certificate expiry Read it, match it to planned tasks Requirement status Built app writes it; tools may read it Equipment ↔ requirement link No tool holds it today Weight and CoG per item Reconciled from model, vendor data and reports
The rule
No two-way sync. The graph orchestrates.
Each fact is written in one place. When it must change, the graph asks the master to change it through its API, then reads the result back.
Two-way sync between tools breaks quietly: two masters, conflicting edits, nobody knows which one is right.
The second rule. For every fact, decide which system is the master; everyone else reads. Point at the last three rows: these facts have no master today. They live in spreadsheets and people's heads, and they're exactly what Semco builds. The graph is their master. Ask the controller: which facts do you reconcile by hand today? Those are candidates for this table.
01 ERP deep dive · Modelling example 1
Commercial: change requests and purchase orders
raisedBy
underContract
varies
deliveredUnder
issuedTo
bookedTo
Customer cust-07 ChangeRequest CR-031 Contract ctr-OSS2 PurchaseOrder PO 4500-1832 Equipment T1 · substation model Supplier sup-0042 CostCode cc-2140
Vocabulary
:ChangeRequest a owl:Class . :PurchaseOrder a owl:Class .
:raisedBy rdfs:domain :ChangeRequest ; rdfs:range :Customer .
:underContract rdfs:domain :ChangeRequest ; rdfs:range :Contract .
:varies rdfs:domain :ChangeRequest ; rdfs:range :PurchaseOrder .
:issuedTo rdfs:domain :PurchaseOrder ; rdfs:range :Supplier .
:bookedTo rdfs:domain :PurchaseOrder ; rdfs:range :CostCode .
:costEstimate rdfs:domain :ChangeRequest ; rdfs:range xsd:decimal .Facts
:CR-031 a :ChangeRequest ;
rdfs:label "+10 % transformer rating" ;
:raisedBy :cust-07 ; :underContract :ctr-OSS2 ;
:varies :PO-4500-1832 ;
:costEstimate 420000.00 .
:PO-4500-1832 a :PurchaseOrder ;
:issuedTo :sup-0042 ; :bookedTo :cc-2140 .
Illustrative · valid Turtle, prefixes omitted
Read the diagram first, the code second. A change request is raised by a customer, under a contract, and varies a purchase order; the PO is issued to a supplier and booked to a cost code. The dashed node is the bridge to the substation model: T1 is delivered under PO 4500-1832. That one edge is what lets a change request find the documents, the zone and the schedule. Fragment: the facts, using the same IDs as the main deck. Ask finance: which of these exist in your system today, and which live in e-mail?
01 ERP deep dive · Modelling example 2
Substation: from module to requirement and zone
hasModule
contains
mustSatisfy
statedIn
locatedIn
coversZone
installs
deliveredUnder
Substation OSS-2 Module M3 Equipment T1 Zone L2-B PurchaseOrder commercial model Document SPEC rev 4 Requirement REQ-0412 WorkPackage WP-214
Vocabulary
:Equipment a owl:Class . :Requirement a owl:Class .
:hasModule rdfs:domain :Substation ; rdfs:range :Module .
:contains rdfs:domain :Module ; rdfs:range :Equipment .
:mustSatisfy rdfs:domain :Equipment ; rdfs:range :Requirement .
:statedIn rdfs:domain :Requirement ; rdfs:range :Document .
:locatedIn rdfs:domain :Equipment ; rdfs:range :Zone .
:coversZone rdfs:domain :WorkPackage ; rdfs:range :Zone .
:installs rdfs:domain :WorkPackage ; rdfs:range :Equipment .Facts
:OSS-2 a :Substation ; :hasModule :M3 .
:M3 a :Module ; :contains :T1 .
:T1 a :Equipment ; :mustSatisfy :REQ-0412 ;
:locatedIn :L2-B ; :deliveredUnder :PO-4500-1832 .
:REQ-0412 a :Requirement ; :statedIn :SPEC-rev4 .
:WP-214 a :WorkPackage ; :coversZone :L2-B ; :installs :T1 .
Illustrative · valid Turtle, prefixes omitted
The engineering side, in Semco's words, not in the ERP's. OSS-2 has module M3, which contains transformer T1; T1 must satisfy REQ-0412, which is stated in the client spec; T1 sits in zone L2-B, where work package WP-214 installs it. And again the bridge: T1 is delivered under the PO from the previous slide. None of these edges exist in an ERP. Ask engineering: what would you add? Rooms, cables, interfaces?
01 ERP deep dive · Modelling example 3
O&M: from bulletin to technician
inFarm
partOf
fromBatch
appliesTo
onComponent
inOrder
assignedTo
holds
follows
revisionOf
WindFarm Park A Turbine WTG C03 Component Pitch bearing B Batch 7731 Bulletin SB-2026-14 Certificate GWO-BST-1187 Technician Anna K. WorkOrder WO-88140 Task Inspect bearing B ProcedureRevision PR-118 rev 8 Procedure PR-118
Vocabulary
:inFarm rdfs:domain :Turbine ; rdfs:range :WindFarm .
:partOf rdfs:domain :Component ; rdfs:range :Turbine .
:fromBatch rdfs:domain :Component ; rdfs:range :Batch .
:appliesTo rdfs:domain :Bulletin ; rdfs:range :Batch .
:revisionOf rdfs:domain :ProcedureRevision ; rdfs:range :Procedure .
:follows rdfs:domain :Task ; rdfs:range :ProcedureRevision .
:onComponent rdfs:domain :Task ; rdfs:range :Component .
:inOrder rdfs:domain :Task ; rdfs:range :WorkOrder .
:assignedTo rdfs:domain :WorkOrder ; rdfs:range :Technician .
:holds rdfs:domain :Technician ; rdfs:range :Certificate .Facts
:C03 a :Turbine ; :inFarm :park-A .
:C03-PB-B a :Component ; :partOf :C03 ; :fromBatch :batch-7731 .
:SB-2026-14 a :Bulletin ; :appliesTo :batch-7731 .
:PR-118-r8 a :ProcedureRevision ; :revisionOf :PR-118 .
:task-1 a :Task ; :onComponent :C03-PB-B ;
:follows :PR-118-r8 ; :inOrder :WO-88140 .
:WO-88140 a :WorkOrder ; :assignedTo :anna-k .
:anna-k :holds :GWO-BST-1187 .
:GWO-BST-1187 :validUntil "2027-02-28"^^xsd:date .
Illustrative · valid Turtle, prefixes omitted
The O&M business. The chain the main deck showed in block 03, now as a model: bulletin SB-2026-14 applies to batch 7731; the pitch bearing on C03 comes from that batch; a task in WO-88140 inspects it, following PR-118 rev 8; the work order is assigned to Anna K., who holds a certificate valid until February. CMMS, HR tool and OEM portal each hold one piece; only the model holds the chain. Ask: which of these does the CMMS know about today?
01 ERP deep dive · From a tool to the graph
One PO line, from an API to the model
Finance tool API · JSON
{
"documentNo" : "4500-1832" ,
"lineNo" : 10 ,
"vendorNo" : "V-10318" ,
"jobNo" : "P-2026-014" ,
"description" : "Main power transformer T1" ,
"quantity" : 1 ,
"amount" : 3950000.00 ,
"currency" : "EUR" ,
"promisedReceiptDate" : "2027-03-15" ,
"lastModified" : "2026-10-14T09:12:44Z"
}
In the model · Turtle
:PO-4500-1832-L10 a :PurchaseOrderLine ;
:lineOf :PO-4500-1832 ;
:issuedTo :sup-0042 ; # from V-10318
:forProject :OSS-2 ; # from P-2026-014
:supplies :T1 ;
:amount "3950000.00"^^xsd:decimal ;
:currency "EUR" ;
:promisedDate "2027-03-15"^^xsd:date ;
prov:wasDerivedFrom :rec-fin-4500-1832-10 .
:rec-fin-4500-1832-10 a prov:Entity ;
:sourceSystem :FinanceTool ;
:recordId "4500-1832/10" ;
prov:generatedAtTime "2026-10-19T06:00:03Z"^^xsd:dateTime .
1 Map fields to the vocabulary
2 Resolve IDs: V-10318 → :sup-0042
3 Stamp provenance: system, record, time
Illustrative · field names generic, not a specific vendor's API
This is what a connector actually does. Left: one purchase-order line as it comes out of a finance tool's REST API. Right: the triples it becomes. Three things happen. The fields are mapped to Semco's vocabulary. The tool's own IDs are resolved to Semco identifiers, using the identity table from earlier. And every fact gets provenance: which system, which record, when it was read. That's what makes "no source, no fact" possible. Ask IT: which of your tools can give you a "changed since" query?
01 ERP deep dive · Validation
Check the model before anything is written
The rule, as a SHACL shape
:VariationReadyShape a sh:NodeShape ;
sh:targetClass :ChangeRequest ;
sh:property [
sh:path :approvedBy ;
sh:minCount 1 ; sh:class :Person ;
sh:message "No approver: PO variation blocked" ] ;
sh:property [
sh:path :costEstimate ;
sh:minCount 1 ; sh:datatype xsd:decimal ;
sh:message "No cost estimate: PO variation blocked" ] ."A change request needs an approver and a cost estimate before a PO variation can be created."
The data
:CR-031 a :ChangeRequest ;
:approvedBy :lars-m .
:lars-m a :Person .
Focus node :CR-031 Path :costEstimate Constraint sh:minCount 1 Severity sh:Violation Message No cost estimate: PO variation blocked
Output from pyshacl, trimmed · illustrative IDs
This is how business rules live in the model, not in the code of one app. SHACL is the W3C standard for describing what valid data looks like. The shape says: a change request needs an approver and a cost estimate. CR-031 has an approver but no estimate, so the orchestration stops before it calls the finance tool. Fragment 1: the actual validation report, trimmed. Fragment 2: once the estimate is added, the data conforms and the PO variation can go ahead. Shapes are data too: the controller can read them and change them, without waiting for a developer. Ask finance: which rules do you enforce by hand today before a PO is changed?
ERP deep dive · Part 3
The integration layer
Write-back, keeping current, what we build, and one change request end to end.
The model is the easy part to accept. The integration layer is where IT will push back, and rightly so. The next four slides show how writes happen, how data stays current, and what Semco ends up building.
01 ERP deep dive · Write-back
CR-031 approved: who does what, in which order
CRM Bought
Cue Index Model
Orchestration agent Built
Finance tool API Bought
Planner · P6 Person · bought
1 · CR-031 approved (webhook)
2 · event: change request approved
3 · validate VariationReadyShape
conforms ✓ · approver, estimate
4 · POST PO variation 4500-1832
201 Created · change no. 2
5 · record variation + provenance
6 · flag: new promised date moves T1 set-in to week 40. Planner decides, P6 stays master
Illustrative
One approved change request, step by step. The CRM tells the model the CR is approved. The orchestration agent picks up the event and validates the shape from the previous slide. Only then does it call the finance tool's API to create the PO variation, exactly as a buyer would. The finance tool answers; the model records the variation with its source. Last step: the new delivery date moves the transformer set-in, so the planner gets a flag. Note what we don't do: we don't write into P6. The planner owns the baseline. Ask IT: who would own the orchestration agent, and who approves its permissions in the finance tool?
01 ERP deep dive · Keeping current
Events in, agents react
Webhooks The tool pushes an event when a record changes. Preferred.
Polling Ask for "changed since" every few minutes when there are no webhooks.
Nightly reconciliation A full comparison catches whatever events missed.
Event From An agent…
PO promised date slips Finance tool Finds the equipment, zone and work package, and flags the planner New procedure revision Doc. control Diffs the revisions, finds affected tasks and technicians, queues briefings Certificate expires in 60 days HR tool Checks planned work orders, notifies the crew lead Change request approved CRM Validates it and proposes the PO variation Vendor datasheet revised Doc. control Re-checks linked requirements and weight New OEM bulletin OEM portal Finds components from the named batch, across all parks
Agents propose . People approve anything that writes to a master system.
How the model stays current. Webhooks where the tool supports them, polling on "changed since" where it doesn't, and a nightly full comparison to catch anything missed. Then the useful part: events that agents react to. Each row is a small, well-defined job. The rule at the bottom matters for trust: agents prepare and propose; a person approves anything that changes a master system. Ask: which of these events would you want first?
01 ERP deep dive · What Semco builds
The gap apps, and the model they use
Change impact A CR in, weight, documents, POs and schedule out.
Interface register Every interface with an owner, a status and the correspondence.
Requirements traceability Clause to item to evidence, with status.
Weight & CoG Model, vendor data and weight reports, reconciled continuously.
Park takeover DD The data room, read into one history per turbine.
Work-pack preparation Everything for one task on one turbine, before the boat leaves.
Procedure briefings What changed, for whom, in a format they use.
Progress per location Plan vs. reality per zone, with reasons from other systems.
Eight apps, one model . Each new app starts where the last one ended.
This is the "build" column made concrete. None of these exist as a product you can buy, because each one crosses systems no vendor connects. Look at the chips: the same classes come back again and again. Equipment, Document, PurchaseOrder. That reuse is why the second app is cheaper than the first, and why the model is the asset. Ask: which of these eight would you build first? Compare with the shortlist from the main workshop.
01 ERP deep dive · End to end
CR-031 through bought and built tools
1 Request
2 Impact
3 Approve
4 Vary the PO
5 Re-plan
6 Revise & report
CRM Bought
CR-031 logged: +10 % transformer rating
Estimate sent; customer approves
Status shared with the customer
Change impact Built
+18 t, CoG +0.6 m, 11 documents, PO, WP-214
Estimate added from the impact
Set-in at risk: flag to planner
Cue Index Model
Linked to OSS-2 and T1
Traverses T1 → docs, PO, zone
Shape check passes
Variation recorded, with source
Reads the new baseline
Tracks revisions to closure
Finance tool Bought
PO 4500-1832 varied via API (+9 weeks)
P6 Bought
Planner moves set-in to week 40
Doc. control Bought
11 revisions raised and tracked
Illustrative
One change request, start to finish. Read the columns left to right and the rows top to bottom. The bought tools each do one standard thing: log the request, change the PO, hold the baseline, hold the documents. The built app does the part that is specific to Semco: impact on a substation. The model runs through every step, and it's the only row that is never empty. The one orange cell is the only write-back into a bought tool, and it went through validation first. Ask: who does each of these steps today, and how many e-mails does it take?
01 ERP deep dive · When the ERP is no longer maintained
The exit plan
Get the data out first, then move the regulated functions. Rebuild nothing without a shadow run.
1
Freeze No new customisation. Agree the end date and what stays read-only.
2
Extract Everything, history included: ledgers, POs, suppliers, projects, hours, into the graph with provenance.
3
Regulated first Finance, payroll and e-invoicing to bought tools. Opening balances from the extract.
4
Shadow-run Anything rebuilt runs next to the old system, reconciled every period.
5
Switch per entity Entity by entity, after a clean year-end close. Archive the old system read-only.
Why extract first: the history is the asset. In the graph it stays queryable after the old system is switched off, whichever tools come next.
Why per entity: one company, one country at a time. A problem stops one entity, not the group.
Illustrative sequence; timing depends on Semco's entities and year-end
This is the direct answer to the end-of-support problem. Freeze first, so the problem stops growing. Extract everything, including history, into the graph, because the history is what a suite migration usually leaves behind in an archive nobody can query. Then move the regulated functions first: they're standard, the tools exist, and they carry the legal risk. Anything we rebuild runs in parallel with the old system until the numbers match. And switch one legal entity at a time, after a clean year-end close. Ask finance: how many legal entities, which countries, and when is year-end?
01 ERP deep dive · New buying criteria
Score the exit, not the demo
Procurement changes. When the tool is a commodity and the model is Semco's, the questions that matter are about getting data in and out, and leaving. A beautiful interface matters less when agents can build the interface each team needs. Concrete suggestion: put the data-ownership and export clause in every new contract, starting now, whatever is decided about the ERP. Ask IT and procurement: which of your current contracts would pass these five criteria?
01 ERP deep dive · Running it
A small team, plus agents
Model owner Owns the vocabulary and the shapes. Approves new classes and rules.
Integration engineer Connectors, write-back, monitoring. Owns the APIs of the bought tools.
Controller / domain expert Decides which system is master. Reconciles, closes, and signs off.
Agents Draft mappings, build apps, watch events. A person approves every write.
The integration layer becomes critical. Run it like it is.
Who runs this. Three roles, not a department, and agents doing most of the routine work. The model owner is the most important hire: someone who understands both the business and the vocabulary. The second point is honest: once finance depends on the integration layer, it is critical infrastructure. It needs monitoring, alerts and an on-call owner, like any system finance depends on. Ask: who in Semco could own the model today?
01 ERP deep dive · Phasing
Three steps. Each pays off on its own.
1
Read Connect the existing tools read-only, the old ERP included. One identifier per thing. First apps that only read: traceability, change impact, progress.
2
Write back, selectively A few objects, through the tools' APIs, with validation and approval: PO variations, CR status, work orders.
3
Replace pieces When support ends, move one function at a time to a bought tool. The model and the apps stay.
Step 1 can start before the ERP decision is made, and makes that decision easier.
The order matters. Step 1 changes nothing in any system and still pays off: the questions from the main deck get answered. It also gives the ERP decision real data: which modules are used, by whom, how much history there is. Step 2 adds writing, carefully. Step 3 is the ERP replacement itself, done piece by piece instead of as one programme. Ask: is there a reason not to start step 1 now?
01 ERP deep dive · Honest caveats
What this doesn't solve
Don't build these Trust takes calendar time A clean year-end close on the new setup. An audit that accepts it. People who trust the numbers. None of that goes faster because the code was written faster.
New responsibilities The integration layer is critical. The model needs an owner and discipline. Bad data in the old ERP comes along until someone cleans it.
Coding is fast now. Trust is not. Plan for closes and audits, not sprints.
Say this before they do. Some things should never be built in-house, and we'd say no if asked. The real constraint is not development time: it's a clean year-end close, an auditor who accepts the setup, and people who trust the numbers. That takes at least one full financial year, whatever the technology. And it shifts responsibility: the model and the integration layer need owners. Ask: what would your auditor need to see?
01 ERP deep dive · Your turn
Questions for Semco
Which systems do you run? Per business, per country. Which are customised, and who maintains them?
Which touch the outside world? Bank, tax, payroll, e-invoicing. These carry the legal risk and move first.
Which is no longer maintained? When does support end, and what has already been decided or budgeted?
Who would own the model? And which use case from today would you connect first?
End with their facts, not our slides. The third question is the urgent one: when support ends and what's already in motion. If a suite replacement is already budgeted, the useful next step is still step 1 of the phasing: read the old ERP into the model now, so the history is safe whatever is decided. Capture the answers; they shape the pilot.
×
by