Our operating model

A clear way to turn
an idea into practice.

Lanttu’s operating model makes solution development manageable: first, we understand the need, then describe the process, implement the solution, and ensure a smooth rollout.

What it is about

First, we clarify
what needs to be solved.

Every business is different. That is why we do not begin with a predefined assumption. We first understand the process, the data, the users, and the everyday situations in which the solution needs to work.

A successful implementation begins with a shared understanding.

When the target process, data content, and user needs are clearly described, the solution can be built in a controlled manner. This reduces uncertainty, unnecessary manual work, and changes made at the wrong stage.

Need What slows down everyday work?
Process How should the work flow?
Data What information does the solution need?
Implementation How will the change become part of everyday work?
How we proceed

A simple model
that keeps the work manageable.

The operating model divides the work into clear stages. The customer can always see what is being done, why it is being done, and how the solution will be implemented.

Understanding

Needs and target process

We review the current state, users, exceptions, data content, and the target state of the process.

Development

Configuration and implementation

The solution is built around the selected functions, rules, and workflows.

Validation

Testing and piloting

Users test the solution, feedback is incorporated, and production readiness is verified.

Use

Rollout and support

The solution is introduced into production in a controlled manner, and users receive support for everyday situations.

Example

A clear workflow
for claims.

On the current page, the operating model is illustrated through the procurement claim process. The same principle remains: the process is first described clearly, after which the required functions can be built around it.

A claim is created

A deviation is identified during receipt. The claim can be created through integrations and directed to the responsible person’s work queue.

The supplier participates in the process

The claim can be added to a portal or used to generate a message for the supplier. The supplier provides a response.

The case is closed in a controlled manner

The claim is approved and marked as complete. The process remains visible from beginning to end.

Configuration

The solution is not a separate application,
but part of the process.

The goal of configuring the functions is to make processes efficient, clear, and easy to manage. Below are examples of functions that can be included in the claims process.

Creation and editing

A claim can be created, completed, and edited as the process progresses.

Work queues and processing

A claim can be added to a work queue and directed to the appropriate responsible person for processing.

Supplier communication

Sending the claim to the supplier and receiving the supplier’s response can be managed in a controlled manner.

Approval and closure

A claim can be approved, reconciled, and marked as complete at the end of the process.

Implementation and rollout

The solution is introduced
one stage at a time.

During the planning stage, the vision becomes a concrete plan. During implementation, ideas are turned into functioning solutions. Testing and piloting verify that the solution works before it is moved into production.

Planning The process, data content, and business rules are defined.
Implementation The solution is set up technically and developed iteratively.
Testing The application, processes, and user experience are tested before release.
Piloting Production readiness is verified within a limited scope before the wider rollout.
Rollout The solution is moved into production, and users are supported during the initial stage.
Continuous services

Support continues even
after the rollout.

The solution creates value only when it is used. That is why we support users, maintain the technical foundation, and develop the solution according to the customer’s needs.

User support

Users receive technical support, guidance, and advice on using the applications and resolving problems.

Technical maintenance

Maintenance includes updates, version management, and appropriate governance models.

Further development

The solution evolves through further development and modification work requested by the customer.

Governance model

Keep environments, access rights,
and changes under control.

Together with the customer, we agree on the project’s governance model, including environments, purposes of use, user groups, access rights, version management, updates, and communication.

Development environment

Used for developing new features and improving existing ones. Access rights are restricted to developers and administrators.

A limited data set for testing.

Test environment

New and modified features are moved into testing before production deployment. Access is restricted to developers, testers, and administrators.

Thorough testing before production.

Production environment

New and modified features that have passed testing are released into production in a controlled manner.

Contains production data.
Start in a controlled manner

Would you like to clarify
your process, data, or rollout?

Book a 30-minute consultation. Together, we will identify where the operating model could bring the most clarity to your everyday work.

Scroll to Top