Research on the floor
For two to three weeks I stand among your people and do the job. Not as an extra pair of hands, but to find the patterns and exceptions nobody notices any more because they are there every day. After that we know what should be built — or whether anything should be built at all.
Research rate €32 per hour excl. VAT
I work in your company for at most 8 hours a day, usually 10 to 15 working days. I am instructed like any new hire, I do the work for real — with help first, then without — and I stay long enough to run into the exceptions a written process never captures.
The goal is not output. The goal is to record which patterns repeat, which exceptions cut through them, and where two departments do the same thing under different names. You pay only for the hours I am there.
Choose the smallest step that works
Working alongside you is the heaviest form of research OmniTechs offers. Take it only when a conversation does not produce the answer.
| Situation | Responsible first step | What you need |
|---|---|---|
| One person can explain the process end to end | Solution Sprint: working session plus independent research | A process owner with time for a 60 to 90 minute session |
| Everyone describes the process slightly differently | Embedded research first, scope afterwards | Access to the floor and an introduction to the team |
| The exceptions cost more time than the normal route | Embedded research; exceptions only surface in practice | A representative period, busy days included |
| Earlier software is worked around in practice | Embedded research into the workaround before replacing anything | Willingness to hear that the process, not the software, is the problem |
| The bottleneck is known and bounded | No research; ask for a proposal directly | A description of the outcome you want and its constraints |
€1,250 excl. VAT
An organisation with a non-standard process or product problem that first needs to investigate users, dependencies, risks and scope.
Independent project work that clarifies the problem, users, dependencies, risks and scope before an implementation price is provided.
Implementation not included
Mapping processes, mapping business processes and process analysis here mean making the current route, exceptions and handovers visible by doing the work. Mapping work processes happens on the floor, not in a workshop model.
Process optimisation promises improvement. This research does not. First record what happens; only then decide whether a sprint, an integration, a web app or no software is the smallest responsible step.
The Solution Sprint opens with a 60 to 90 minute working session. That works when someone can explain the process: where it starts, where it ends, who decides, and what goes wrong. If you can do that, the sprint is faster and cheaper than having me on the floor. Say so — I will point you there.
Sometimes it does not work. Not because nobody knows their job, but because the knowledge is spread across five people, because the exceptions are the work, or because what people describe is the intended route rather than this morning's route. Then an hour of talking is an hour of guessing. Doing the work takes the answer from practice instead of from memory.
A usual rhythm, not a fixed schedule. The work sets the pace, and a busy week says more than a quiet one.
Patterns are work that recurs in the same shape even when it is called something different each time: decisions people make on instinct that still come out the same way, the same data entered in two places, and the moments somebody is standing there waiting.
Exceptions matter more than the happy path. What happens when it does not follow the normal route, which exception occurs often enough to be a rule, who gets called when the system has no answer, and which manual correction is quietly made afterwards? Software that handles the happy path is easy; software that does not know the exceptions gets worked around within a month.
At the end there is a description that matches practice rather than intent, and an order in which problems are best addressed.
The boundaries are stated here explicitly, because a misunderstanding about them makes the research worthless.
I have done this twice for myself, without anyone asking.
In a warehouse and shipping operation I worked on the floor for more than two years. In that time I built tools for myself — time tracking, task tracking, small automations — because I wanted to do my own job better. The most interesting part was put-away: how a storage location got chosen determined how much time every next item cost. Change that choice and more volume stops costing proportionally more time. You only see that after doing it yourself a hundred times.
In a production environment working with pipe stock I built an application that automated the decision of where pipe of each size and type gets stored. That decision lived in experience and habit. I made it explicit, so it became repeatable instead of depending on who was on shift.
I am not the best programmer in the Netherlands. What I am good at is seeing patterns on a work floor and turning those patterns into something that works. Neither of those was about the application; both were about there being a solution.
Only attended hours are invoiced; a shorter day counts as shorter.
If after the first week it turns out this is not the right form, we stop and you pay only for the hours worked. Implementation afterwards is quoted separately on scope, not on hours.
Working alongside you requires access to your floor. These agreements are recorded in the engagement confirmation before day one.
Mapping processes means working alongside you until the current route, exceptions and handovers are visible. It is process analysis of practice, not a software package and not a promise that process optimisation follows.
No. Process optimisation looks for improvement. Mapping business processes stops earlier: first see what happens. Improving, automating or doing nothing is a later decision.
Really do it. Observing gets you the tidy version. Doing it gets you the mistakes, and those are the interesting part.
No. I record the process, not individual performance. I say that to the team too, because otherwise I am shown nothing real.
Then this is heavier than you need. Take the Solution Sprint: one 60 to 90 minute working session plus independent research, at a fixed price.
By arrangement. Five days in a row gives the sharpest picture; three days a week over a longer period also works, for instance if you want peak days included.
A research rate of €32 per hour excl. VAT, at most 8 hours a day. 10 to 15 working days is usual. Only attended hours are invoiced; a shorter day counts as shorter.
No. The research is yours, including if you take it to someone else. An implementation price follows only after the research.
Yes. The method is not tied to a warehouse. Wherever people hand work to each other, patterns and exceptions appear.
Then I follow it, or I do not do that part myself and observe instead. Safety comes before completeness.
It falls under confidentiality. I do not use it in publications, cases or examples without your written permission.
If the hour is enough to get the problem clear, you will hear the smallest next step straight away and you will not need me further. If it is not — and that happens more often than people expect — that is exactly the signal that working alongside you is worth it.
