Process map
The flow of work as it runs today, with the places marked where something gets lost or sits waiting. If nobody in the company has seen the whole process in one piece before, this is the moment.
Maciej Nuzia · Advisory
First I work out what the system should do. Only then can it be estimated
When part of a process lives in spreadsheets, part in several applications and the rest in people’s heads, a feature list is not enough. I talk to the owners and the team, observe the work and map the process. That becomes a requirements document from which the system can be estimated and built.
Start with one sentence about what does not fit together today. I will ask for the rest.
Fit
When discovery makes sense and when to skip it
The second list matters more than the first. I would rather lose the job on a call than halfway through the project.
Worth it if
- the process works, but it holds together on paper notes, a spreadsheet and what a few people happen to remember
- you have quotes from several contractors and each one describes a different system, because each one guessed at the scope
- someone asks what this will cost, and nobody can answer until it is clear what actually gets built
- an earlier attempt stalled and nobody can point to the place where it stopped
- you suspect the trouble sits in the process itself, and the software only handles it
Not worth it if
- the requirements are written down and your team agrees on them. Discovery would repeat work you already have behind you
- the scope is narrow enough that the requirements document would outgrow the software it describes
- there is an off-the-shelf tool that covers this process. I check for that on the call and say so plainly when it exists
- nobody on your side has time for conversations and for showing the work on site. Without that, the document is guesswork
- a native mobile app is the heart of the idea. That is not work I take on
How the work goes
First I learn the process. Requirements come last
The order is the whole point. A document written after a single meeting describes what people believe the process to be, not the process.
01
Conversations with owners and team leads
I start with the people who answer for the result. The feature list waits its turn. What hurts most right now, and what nobody has a grip on. The answers sometimes contradict each other, and that in itself is worth knowing.
02
Time spent where the work happens
The shop floor, the warehouse, the packing bench, the desk where orders come in. A process described in a meeting room and the same process watched on site tell two different stories. The gap between them is usually the most interesting part of the job.
03
A process map
The whole run, from the event that sets it off to the moment the case is closed. Marked with the points where data gets copied from a note into a spreadsheet, and the points where work simply waits. I show the map to the people who do the job. They are the ones who spot what does not match.
04
Requirements and a proposed architecture
Only now. The requirements finally have something to describe.
What you get
You receive the material needed to estimate and build
Requirements document
What the system has to do, for whom, and in what order. Written so that a developer and a person from the shop floor can both read it. It also sets out the stages: what has to exist first so people can start using it before the whole thing is finished. And the risks: an integration nobody has looked at up close, data in a format that will not load, one person who knows every exception to the rule.
Proposed architecture
What to build this from, and the reasoning behind each choice. It marks the decisions that have to be made now and the ones that can wait.
Case
Raiseberry: from paper notes and whiteboards to a system on the floor
Before the system existed, production was planned on paper notes, in Excel and on whiteboards. The analysis and the planning happened on the shop floor, together with the owners and the team leads.
The scope did not come from a wish list drawn up around a table. It came from what was visible on site:
- production planning
- materials and bills of materials
- product routings
- progress tracking on tablets on the shop floor
- problem reporting
- packing and courier integrations
- reporting
The tablets went to the floor because that is where information about progress is created. A problem gets reported from the spot where it appeared.
How long it takes, and what comes next
Timing depends on the size and complexity of the process
I will not name a date before seeing what the process looks like. One department is one thing. An order that travels through several teams, two systems and a warehouse is another. What drives the length is how many people need to be heard, how many places need to be visited, and how quickly those visits fit into everyone's calendar. You and I settle the timing at the start, once those are known.
The document is yours. Take it to any contractor, send it to several and compare the answers against the same baseline. Discovery is not bait for a build.
Once you have the document you can stay, or take it elsewhere. Both are fine.
Talk
Let us start with the work that has the most manual steps
Who does it, where is the result recorded, and where does the work wait? Answers to those questions are enough for a first call. We will work out the rest together.