Anyone looking for a new system or having an application built is asked early on: how does this work in your business today? The answer seems easier than it is. The owner knows the workflow as it was designed. The staff know it as it really is - with the note stuck to the screen, the Excel list next to the system and the phone call to the warehouse when an order is urgent.

That difference is the reason to write workflows down before software is built. What is not written down, nobody can estimate, compare or build. And whatever runs differently at the desk than everyone assumed only shows up later, when the new software does not know the workaround.

Why write it down before building

Process documentation does three jobs. It is the basis for every quote: without it, the vendor estimates an idea, with it, a workflow. How a software estimate is made depends directly on it. It makes quotes comparable, because every vendor reads the same thing. And it often shows that part of the problem needs no software at all - an approval nobody needs any more, a list two departments keep in parallel.

The high-level and detailed concept are built on it later - if it is vague, so are they.

Watching instead of questionnaires

There are two ways to capture a workflow. One is the questionnaire: department heads describe how the work is done. The other is a visit to the workplace. We take the second route. We stand next to your staff, watch and ask questions, one morning per workstation, while the business carries on.

The reason is simple. The questionnaire says how it is supposed to be. At the desk you see how it is: the reach for the folder because the system does not hold the delivery address. The email to a colleague because otherwise the approval sits there. The three clicks everyone makes without remembering why. Exactly these spots decide later whether software fits.

Everything is written in the words your staff use. If the business calls it a “ticket”, the documentation says “ticket”, not “service request”. The real documents and lists are attached: the delivery note with the handwritten remarks, the sales team’s Excel list, the printout from the old system. They say more than any description.

What belongs in it

For each workflow, such as “handling a complaint” or “creating an order”:

  • The trigger: what sets the workflow in motion? A phone call, an email in the shared mailbox, an order from the shop, an appointment.
  • The steps: what happens in which order, and what is produced along the way - a quote, a delivery note, an entry in a list.
  • The people involved: who does what, who approves, who is only informed.
  • Systems and lists: which program each step happens in, which Excel lists, folders and slips of paper belong to it.
  • Exceptions and special cases: the key account with its own discount scale, the rush order, the return without a delivery note. Special cases are often the biggest part of the work.
  • Where it gets stuck: where people wait, retype, make mistakes or have to ask.

What does not belong in it

Process documentation describes what is, not what should be. The target workflow comes later, in the high-level concept - whoever mixes the two documents their wishes rather than their business.

Formal diagrams are not needed. There are standards for drawing processes, with fixed symbols for decisions, events and roles. Vendors sometimes find them useful; for the staff who are meant to check the description, they are a foreign language. A numbered list of sentences everyone understands is enough.

An assessment of the staff does not belong in it either. Anyone who reads in the documentation that they work “inefficiently” stops reading. The workaround almost always exists for a good reason - usually because the system could not do it.

How to tell it is accurate

The test is simple: your staff read the documentation of their own workstation and recognise themselves in it:

  • The clerk says “yes, exactly like that” and adds at most one more exception.
  • A new colleague could carry out the workflow from the description without asking.
  • Every document that turns up in daily work is described or attached.
  • The sticking points are in there the way people complain about them.
  • Nobody has to look up a symbol.

If one of these is missing, you go back and ask - you do not touch it up at your desk.

Useful even without a software project

Even if no software follows, the documentation keeps its value. New staff learn from it instead of copying everything from colleagues. During illness and holidays the stand-in knows where the list is and who approves. Knowledge that used to sit with one person is on paper. And when a workflow looks plainly too cumbersome as soon as it is written down, it can often be changed without touching any program.

The documents belong to the business, regardless of who produced them and whether a project follows. What can become of them is covered in the article on requirements and functional specifications.

How to proceed

  • Pick the workflows that cause the most trouble today - not all of them at once.
  • Capture them at the workplace, with the people who carry them out every day.
  • Write in their words and collect the real documents and lists.
  • Record exceptions and special cases, including those that “never really happen”.
  • Have the description checked by the people who appear in it.
  • Keep what is separate from what should be. The target workflow belongs to the next step.

If you would rather not do this yourself, or want an outside view: this is exactly how our process analysis begins - with the process documentation from which the high-level concept and the detailed concept with its estimate are developed.