One application, one accountable team, one governed record.
Adopting an industrial application requires a defined set of decisions about ownership, validity, approval, migration and operation of the underlying record. The implementation sequence is structured around those decisions.
- 0
- Phases from scope to widening
- 0
- Gates between them
- 0
- Application live when the first one ends
Implementation depends on client decisions as well as delivery work.
The application can enforce who may change a record, what makes an entry valid, who may approve it and how corrections are controlled. Those rules must first be defined by the organisation responsible for the record.
6 phases, each closed by a defined gate.
A gate is evidence that a required decision or artefact exists, such as an agreed record model, approved hierarchy or defined cut-over point. The next phase does not proceed until that evidence is in place.
Scope
Establish which record the application will own, and the boundary around it.
What it settles- The record class in scope, and the part of the organisation that keeps it
- Which existing systems stay exactly as they are
- What has to be demonstrable at the end, and to whom
Gate: One named record, one owning team, one stated boundaryStructure
Set up the structures the application hangs everything from.
What it settles- The hierarchy: organisation, site, project or asset, down to the level work is done at
- Shared registers; equipment, personnel, organisations, locations; created once and referenced
- Roles and tenancy, because identity is what every later control is enforced on
Gate: A hierarchy the team recognises as their ownRules
Configure the controls the application will hold the team to.
What it settles- Approval routes and segregation of duties, enforced on identity rather than on practice
- Templates and revisions, so an executed record keeps the version it was signed against
- Sequences that lock once configured, where the application works that way
Gate: The rules agreed in Getting Started, now enforced by the systemMigration
Decide what history comes across, and what stays where it is.
What it settles- Which historical records are brought in, and which remain in the system that holds them
- How a migrated record is marked, so its provenance is never ambiguous
- The point in time from which the application is the system of record
Gate: A stated cut-over date and a clean provenance ruleLive period
Run it on real work and check the derived figures against what the team knows.
What it settles- Whether office and field are genuinely on the same record
- Whether every derived figure can be traced back to the entries beneath it
- Which figures the application declines to produce, and whether that is understood
Gate: Derived figures the team is prepared to defendWiden
Decide whether a second application follows, and on what terms.
What it settles- Whether another team wants the next application on its own merits
- Which single named record would cross the boundary, if any
- What stays separate, which is usually most of it
A second application is adopted when another operational need justifies it.
There is no mandatory portfolio rollout. When another team adopts an application, the same implementation discipline is applied again. Integration is introduced only where a defined record genuinely crosses between the two areas of work.
- Each application is configured around its own team’s structures, not inherited from the first
- One named record crosses a boundary; nothing is merged and nothing is shared wholesale
- An application that is never adopted costs the ones you do run nothing at all
Four implementation roles, three owned by the client.
The people who already own, maintain and approve the record provide the decisions that determine whether the implementation is valid.
- Your side
Record owner
The person who maintains the register today. They decide what valid means, and they are the one the derived figures have to convince.
- Your side
Approver
Whoever currently signs. Segregation of duties is configured around them, which is often the first thing an implementation changes.
- Your side
Field users
The people entering the day where the work happens. If the record does not work for them, nothing above it is reliable.
- Zemerc side
Application team
The team that built the application, configuring it against your structures and answering what it does and does not compute.
Four things the implementation model deliberately avoids.
The implementation model is designed to avoid unnecessary platform-wide transformation, forced portfolio adoption and process change that is unrelated to the record in scope.
No big-bang programme
One application, one team, one record. There is no phase in which the whole portfolio arrives at once, because nothing requires that.
No custom fork
Applications are configured, not forked. What you set up is what everyone else on that application gets, which is why it keeps improving.
No replacement of what works
Areas already served by a system you are content with stay as they are. Each application owns one class of record and has no interest in the rest.
No figure without a basis
Migration does not manufacture history. Where a period has no supporting record, the application reports it as such rather than filling the gap.
Discuss a first application.
Bring one register, project or asset. We will identify the application that governs it and explain what the first implementation phase would need to establish.