Technical services around the application portfolio.
Zemerc supplies applications for your teams to operate, and provides the implementation, configuration, migration and deployment work around them. Every application runs without any of it; services are available where you want the work done with you, or done for you.
Three ways of working with Zemerc.
Which one applies is a commercial decision, not a technical one. Every application works the same way underneath.
- Option 01
Use our applications
License the application you need and operate it with your own team. Nothing else is required: no second Zemerc application, and no services.
View the applications - Option 02
Work with Zemerc
Implementation, configuration, data migration and deployment support, carried out alongside the team that keeps the record.
What is provided - Option 03
Deliver an outcome
Where it suits the requirement, Zemerc combines the applications with specialist capability to deliver an agreed piece of work. Scoped and agreed before anything starts.
Discuss a requirement
Services are never a condition of use. An application purchased on its own is a complete, independently operable application, and remains one whether or not Zemerc does any of the work around it.
4 areas, each with a boundary stated.
Every one of these is work the applications genuinely require somebody to do. The right-hand column is the part that stays with you, and it is not a formality.
Implementation
Run the six-phase implementation sequence with the team that owns the record.
- Work through scope, structure, rules, migration and the first live period with your record owner and approver
- Set up the application against the structures your team already recognises rather than a generic model
- Check what the application derives against what your team already knows to be true, and examine the record beneath wherever the two disagree
- Naming the record the application will own, and the team that owns it
- Deciding who may change it, what makes an entry valid and who may approve
- Judging whether the derived figures are ones you are prepared to defend
Configuration
Translate client rules into controls enforced by the application.
- Build the hierarchy the registers hang from, down to the level work is actually done at
- Establish shared registers for equipment, personnel, organisations and locations so each entity is maintained once and referenced consistently.
- Configure roles and tenancy, approval routes and segregation of duties, and the template revisions an executed record will be signed against
- The rules themselves: your approval authorities, your validity criteria, your retention expectations
- Confirming the hierarchy is one your team recognises as their own
- Deciding what locks, because several sequences are configured once per project and then fixed
Data migration
Migrate historical records while preserving provenance.
- Use the data management workspace, guided imports, exports and templates to migrate historical records with controlled provenance.
- Mark migrated records so their provenance is never ambiguous afterwards
- Establish the point in time from which the application becomes the system of record
- Deciding which history comes across and which stays in the system that holds it
- Confirming the cut-over date
- Accepting that migration does not manufacture history: where a period has no supporting record, the application reports it as such
Deployment
Establish the approved operating environment for the application.
- Establish which deployment modes the application you are adopting actually supports, and set the chosen one up
- Configure tenancy and identity, which is what every later access control is enforced on
- Hand over the sign-in arrangements for your applications, since each has its own and there is no shared public portal
- Choosing the deployment mode, including running in your own cloud tenancy or inside your own network where the application supports it
- Your own network, identity and infrastructure decisions
- Raising availability or continuity requirements so they are settled in the agreement for that application
The answers come from the people who keep the record.
An implementation is mostly your organisation deciding things about its own record: who may change it, what makes an entry valid, who may approve, and what happens when a value is corrected. The application enforces those answers. It does not supply them, and neither does Zemerc.
- Your record owner and your approver are the ones an implementation is built around
- The hierarchy has to be one your team recognises as their own before anything else proceeds
- Derived figures only count once the team is prepared to defend them
Five points where something is decided.
Not a sales process. Each of these is a point where an answer either exists or the engagement does not continue.
- 01
A working session
You bring one register, project, asset or vessel. The application that governs it is shown running against records like yours, with the people who keep the record and the person who signs it in the room.
- 02
The scoping questions
Which record the application would own, which existing systems stay exactly as they are, what has to be demonstrable at the end, and to whom. Those answers decide whether there is an engagement at all.
- 03
Deployment and commercial terms
Which deployment mode applies to that application, and the agreement covering it. Availability, continuity and support arrangements are settled here, for that application, rather than promised in advance on a website.
- 04
The first live period
The application runs on real work with office and field on the same record. The test is whether every derived figure can be traced back to the entries beneath it, and whether your team will defend them.
- 05
Whatever follows
A second application if another team wants one on its own merits. Nothing requires it, and an application you never adopt costs the ones you do run nothing at all.
Deployment is settled per application.
Several applications support three deployment modes: Zemerc-hosted, client cloud tenancy, or deployment within the client network. One application also supports fully offline operation. Availability is confirmed per application because not every product supports every mode.
- Tenant separation is enforced in the database itself, not only in the application
- Roles, tenancy and approval rights are enforced on identity
- Each application has its own sign-in; there is no shared public portal
Four things this page will not sell you.
A services page is more useful for what it refuses than for what it lists. None of the following is established, so none of it is offered.
Integration projects
Some applications carry an integration catalogue, but those integrations are disabled by default and have not been tested against real external systems. Governed import and export is how data moves between systems today, and a specific integration requirement is an open question rather than something already promised.
Custom builds
Applications are configured, never forked. You do not end up on a version only you run, which is why the application you adopt keeps improving.
Replacing systems that work
Each application owns one class of record and has no interest in the rest. An area already served by a system you are content with stays as it is.
Published service levels
No uptime figures, response times, severity targets or support tiers are published here. Those belong in the agreement covering a specific application and deployment, and are answered for that application when you ask.
The applications are products, not engagements.
All 27 applications are independently operable and commercially standalone. Nothing on this page changes that.
Services are not a licence condition
The applications are products. What Zemerc provides alongside them exists because organisations ask for it, not because the software needs it to run.
Nothing here creates a dependency
An application configured with help works identically to one configured without it. Adopting a service does not tie you to a second application or to Zemerc hosting.
The record stays yours
Your data, your approval authorities and your decisions about what a valid entry is. The application enforces those answers; it does not supply them, and neither does Zemerc.
Start with the record, not the engagement.
Bring one register, project or asset to a working session. What Zemerc would actually need to do follows from what we find there.