Solutions

When the problem needs its own system.

Some problems fit one of our products. Others belong to one organisation only. For those, we build the system around the process, the data and the objective that are already there.

Discuss a process How a project runs

What we build

Five kinds of work, usually combined.

  • 01

    Applications and platforms

    Software shaped around how the organisation actually works, for the people who use it every day.

  • 02

    Assistants, agents and automation

    AI that prepares, checks or carries out defined steps of a process, inside limits people have set.

  • 03

    Connected data and systems

    The applications and records already in place, linked so that the same fact is the same everywhere.

  • 04

    Analysis, simulation and planning

    Models that let a team compare options and see the effect of a decision before taking it.

  • 05

    Implementation, support and evolution

    Putting the system into operation, keeping it running and extending it as the organisation changes.

The path

From a stated problem to a measured result.

01 Problem and objectiveWe write down, with you, what happens today, who decides, and what has to be different. If the objective cannot be stated, the project is not ready.
02 Feasibility checkWe look at the data, the systems and the constraints, and say plainly what can be built, what cannot, and what is still unknown.
03 DevelopmentWe build in stages, and the people who will use the system see each stage working.
04 IntegrationWe connect the system to the applications and data already in place and bring it into the daily activity.
05 Evaluating the resultWe compare what the system does against the objective written down at the start, and agree what comes next.

Scope, duration and price are set per project, after the feasibility check. We do not publish general figures.

Three examples

The kind of problem we mean.

These are illustrations of managerial and operational problems. They are not projects we have delivered, and they describe no customer.

  • 01

    Maintenance planned from three spreadsheets

    A maintenance department schedules interventions from separate lists of assets, crews and spare parts. A late delivery is discovered when the crew is already on site. The objective: one plan that changes when any of the three does.

    Illustrative example
  • 02

    Requests that stall between departments

    A service organisation receives requests by email and through two applications. Management cannot see where a request waits or why. The objective: every request has an owner, a state and a deadline that someone can see.

    Illustrative example
  • 03

    Routes re-planned by hand every morning

    A logistics operator rebuilds the day's routes whenever a vehicle or a driver is unavailable. The work takes the first hour of the day and depends on one person. The objective: a proposed re-plan that the dispatcher checks and approves.

    Illustrative example

Products and solutions

Built on the same principle.

Where one of our products covers the problem, we start from it. Where none does, we build new. Either way the work follows the same principle: understanding operations is part of product engineering. About the company

Contact

Bring us one concrete process.

Tell us what happens today, what has to be different, and which data and systems exist around it. We reply with how we would check whether it can be built.

[email protected] Explore the products