A service path from work modelling to transformation
Our services form a path from work modelling to an organization-wide transformation. The starting point can be a single workshop, hands-on expertise or an existing process. Every step produces technology-independent specification that the client owns, and after every step you can stop: no stage commits you to the next one, or to any implementer.
01 // Specification workshop
Specification workshop: hands-on expertise into a structured model
The specification workshop is the fastest way to find out which of your processes are worth automating and in what order. The participants are the people who run the process, not only its owners: they describe their work step by step, and our platform structures the description into a model as they go. Participation requires no technical skills.
How the workshop runs
The workshop takes about half a day of the participants' time, and we prepare it in advance with the process owner. The work follows the real order of the process: where the work starts, what data is handled, where decisions are made and what counts as done. Facilitation makes sure that exceptions and hands-on expertise get captured too.
What you get
A structured process model, with the process decomposed into workflows and tasks, and prioritized automation targets with reasoning: what to automate first, where the human role remains and what is not worth automating. The model is the direct baseline for process specification if you proceed, and it remains your property even if you do not.
Q:Who should attend?
The people who do the work daily, plus the process owner. A typical group is from a few people to about ten.
Q:How much of our time does it take?
About half a day for the workshop itself. We handle the preparation together with the process owner.
Q:What happens after the workshop?
We walk through the results with you and recommend a next step only if it is justified. The model is useful on its own as well, for example for onboarding and work instructions.
02 // Process specification
Process specification: from workshop to an implementation-ready spec
In process specification, one business process is taken end to end into a machine-readable specification: the process is divided into workflows, workflows into agents and agents into technical tasks, and every step gets defined inputs, outputs, acceptance conditions and human control points. The result is a technology-independent whole that you can hand to your own team, a partner of your choice, or us to implement.
Specified with the people who do the work, not past them
The work builds on a series of specification workshops in which the people who run the process describe their work, and the specification sharpens round by round. Simulations are built along the way, so the team can see and correct the process flow before anything is implemented in production.
The human role and the risks are defined before implementation
Approval points are designed into every process: where a human reviews, approves or decides. Steps are risk-classified, and the specification passes through review gates before implementation is approved. Questions of responsibility are settled at the design table, not in production.
What you get
The machine-readable specification, process diagrams, work-instruction baselines and the foundation of the governance and compliance documentation (including EU AI Act assessment and ISO 42001 groundwork). Everything is generated from the same source, so documentation cannot drift from reality. Ownership is yours.
Q:How long does specification take?
A single workflow typically goes from workshop to a production-ready specification in weeks. The duration for a full process depends on the number of workflows, and we give an estimate in the discovery call.
Q:How much of our time does it require?
Most of the client's time is the practitioners' participation in workshops. We do the rest.
Q:Can our own IT team implement it?
Yes, and the model is designed exactly for that. The specification tells the builder unambiguously what done means.
03 // AI transformation
AI transformation: one process at a time, governed
AI transformation is a programme in which an organization's processes are specified and taken to production in a governed order. The model is built so that your own capability grows along the way: the first process is delivered with close support, the next ones lighter, and in the target state your own small developer team builds the processes on our platform with our technical support. Transformation is not handing tools to staff; it is rebuilding processes, and that is why it includes the human side: changing roles, designing the approval work and managing cognitive load.
A governed order, not everything at once
Processes are prioritized by impact and feasibility, and each follows the same path: specification, reviews, production. Learning carries from one process to the next, so delivery gets faster and cheaper as the programme proceeds.
Target state: your team builds, we support
We do not build dependency on ourselves. The target state is that a team of a few in-house developers builds and maintains the process portfolio, and our role narrows to the platform, technical consulting and independent verification. This is the single most important factor in the cost structure of a transformation.
People in the change
When agents handle the routine, people are left with oversight, exceptions and decisions. That is different work than before, and without design it overloads. The programme includes sizing the approval work, redesigning roles and supporting line managers, so that acceleration does not turn into exhaustion.
Q:How many processes does a programme include?
It is fitted to your organization. The programme advances one process at a time, and the scope can be adjusted along the way.
Q:Where do the processes run?
In your own cloud environment, on your own accounts. The data and the runtime stay with you.
Q:What happens if the cooperation ends?
The specifications, documentation and environment are your property, and your own team or a new partner continues from them. The whole point of the model is that continuity does not depend on us.
04 // Governance
Governance: control that survives an audit
The governance service keeps agentic processes under control in production as well: changes pass through reviews, every run leaves a trail, and the implementation in production is compared against the specification so the system still does what was agreed. Compliance documentation is produced and updated within the same structure, so you do not prepare for an audit separately; you are ready for one continuously.
Change management and reviews
Processes change, and change is where control usually breaks. In our model a change is made to the specification, reviewed through the same gates as the original, and only then implemented. The version history always shows what is in force and why.
Production is verified against the specification
Over time, implementation and documentation drift apart in almost every organization. In our model the implementation in production is compared against the specification, and deviations are surfaced and handled in a controlled way. This is the core task of an independent verifier.
Compliance as structure, not as a project
EU AI Act assessments, data protection documentation and ISO 42001 materials build on the same specification and run trail. When an auditor asks what the system does and who approved it, the answer is shown from the system, not assembled afterwards.
Q:Do we need governance if our own team builds the processes?
Especially then. Independent verification is most valuable when the builder and the verifier are not the same party.
Q:Does the service cover processes built by other vendors?
Yes, if a specification exists or is created to verify them against.
Q:Is this the same as technical maintenance?
No. Maintaining the runtime is the implementer's or IT's work. Governance is responsible for the whole staying specified, approved and verifiable.
05 // You control
You control
Everything we do is built so that control stays with you. You own the specifications, process descriptions and run trails. You can change implementer, continue with your own team, or use the platform independently. Independence is not just a promise; it is built into how we work.
You own the specifications
Every process, workflow and approval point is recorded in a machine-readable form that is your property. You can hand it to any implementer, platform or in-house team without having to redo the work.
No lock-in to us
We do not build dependency on ourselves. Our goal is that your own team can build and maintain processes independently, and we move into a supporting and independent verification role. You can also stop at any time and continue on your own terms.
Processes and data stay with you
The specification platform is a tool for describing and governing processes; it is our product and stays with us. Building the processes means turning specifications into production, and that happens in your environment, on your accounts. Data and runtime never move to us.
Q:Can we change implementer mid-project?
Yes. Because the specification is technology-independent and your property, a new implementer can continue from the same baseline.
Q:Can our own team manage the platform independently?
Yes. Our goal is that your team uses the platform independently and we support only when needed.
Q:What happens if we end the cooperation?
All specification, documentation and run trails remain with you. Processes run in your own environment, so continuity does not depend on us.