Business process software development

From process to software

1. 01

   Map as-is

   Follow real cases from start to finish.

   Output: Current process map

2. 02

   Find waste

   Mark waiting, rework, hand-offs and duplicate checks.

   Output: Problem list

3. 03

   Redesign

   Simplify steps and agree new rules.

   Output: Target process

4. 04

   Measure baseline

   Record cycle time, volumes and errors.

   Output: Baseline figures

5. 05

   Build

   Software supports the simplified process.

   Output: Process software

Follow real cases, not the official chart

Official process diagrams often describe how work should flow rather than how it does. Following a handful of real cases, such as an order, a claim or a job, from first contact to completion shows the actual route: the emails, phone calls, spreadsheets and waiting. Ask the people involved at each step what they need, what they check and what usually goes wrong.

The gaps between the official and real process are where the most useful improvements hide.

Common sources of delay

Measures worth recording

Improvements that need no software

• Removing a step

  A check that never finds problems can often go.

• Changing who decides

  Letting the person closest to the work approve small items.

• Standard templates

  Agreed forms that capture what is needed.

• Clear rules

  Written criteria that end case-by-case debate.

Where software adds most

Once the process is simplified, software is most valuable where work moves between people, where rules must be applied consistently and where status needs to be visible. It can route cases to the right person, enforce required information, apply calculations, remind people of deadlines and show managers where cases are stuck. These are the parts of a process that people find hardest to do reliably by hand.

Example: simplifying before building

Involving the people who do the work

The people who handle a process every day know where it breaks, which rules are bent and which steps add nothing. Involve them in mapping and redesign, not only in testing at the end. Short workshops where each person describes their step, what they receive and what they pass on reveal hand-off problems that managers rarely see. People are also more willing to adopt a process they helped shape.

Make it safe to describe workarounds honestly; they are information, not failings.

Measuring after launch

Compare the same measures used for the baseline, such as cycle time, rework and staff time per case, a few weeks and a few months after launch. Improvements confirm the change worked; gaps show where further adjustment is needed. Sharing the results with the team reinforces the new way of working and builds support for the next improvement.

One process at a time

Improving and automating one process well, then moving to the next, is more manageable than redesigning several at once. Lessons from the first shape the rest.