Describe a process clearly before automating it

A process does not become understandable merely because arrows connect its steps. Before automation, triggers, information, responsibilities, decisions and exception paths must fit together. Otherwise technology may accelerate precisely the uncertainty previously resolved through informal questions. This article uses a fictional product-editing workflow to show how to describe work clearly enough to support a defensible implementation decision.

Start with the outcome rather than a tool

The initial proposal is that product changes should appear automatically on the website. Several unresolved decisions hide inside that sentence. Which changes are included? Where do they originate? Who decides whether they are correct? When is an update actually complete? Choosing an integration does not answer these questions, even when its technical capabilities look suitable.

Our example narrows the goal: an approved change to technical product information is associated with an existing product page, prepared editorially and published after review. At completion, the correct page visibly presents the checked version and the association is recorded. Receiving a message alone is not an instruction to publish immediately. The process must establish the authority and content behind that instruction.

Record what falls outside the activity too. Creating new products, negotiating prices and notifying customers can be separate processes. These boundaries stop a small initial description from quietly expanding into a model of the entire organization. A useful scope identifies its external dependencies without attempting to absorb every related responsibility.

Investigate how work happens today

Ask participants how the activity currently works. Where appropriate and permitted, examine a suitable completed case. Include handovers, notes and clarifying conversations absent from the official procedure. They often contain practical knowledge about why an apparently unnecessary step exists. Removing the visible step without understanding its purpose can remove an important check.

Separate today's working practice from the desired improvement. If editors currently resolve a question by telephone, record that first. Then assess whether the question can be avoided or handled differently. A proposed diagram that simply omits such work does not establish a saving. It may merely move the effort outside the description.

Digital.gov describes journey maps and service blueprints as different views of user experience and supporting operations. Here, separating the visible task from internal handovers helps the investigation. The example does not import a prescribed project duration or claim that real participants have already been interviewed.

Name the trigger and end state precisely

A trigger should be observable. “Product information needs improvement” is too vague for this purpose. “An approved technical change version is available” is more precise. Add how the approval is recognized and who provides it. An email headed “please update” does not automatically constitute the same evidence, even when the sender is familiar.

The end state likewise needs a checkable criterion. This workflow does not end when a draft is saved. It ends when the intended product page displays the reviewed new version and its relationship to the change record is documented. Successful data transfer can occur earlier. Treating that intermediate event as completion can create a false success report.

Name other possible endings. An unacceptable change can be rejected. A duplicate notification can be closed with a reference to the existing case. An unresolved failure remains open instead. These conditions should not all disappear under one generic “done” label because subsequent work and responsibility differ.

Create a concise process profile

This profile creates a shared starting point without replacing investigation of individual steps. Its value is exposing disagreement about the goal before implementation. Two participants should be able to recognize whether they mean the same process when examining one example. An impressive title is not enough if their definitions of completion differ.

Distinguish roles from actual authority

A role describes responsibility within the process. It need not correspond to one individual or a department name. A domain specialist confirms the technical claim. An editor checks understandable presentation. A designated publisher releases the result. In a small team, one person may hold several roles while the underlying decisions remain distinct and reviewable.

Technical permissions are an additional question. An account may be capable of publishing even though its intended task is only draft preparation. Automation needs alignment between role, permitted action and actual access. A broadly shared administrator account does not describe domain responsibility. It can also obscure who performed a particular operation when a problem requires investigation.

The GOV.UK guidance on working across organizational boundaries considers collaboration around broader tasks. Applied here, the editorial step matters alongside reliable handover from the domain team and onward to publication. Optimizing one department in isolation can leave the overall task unchanged or make another handover less clear.

Describe handovers as agreements

For each handover, specify the input, expected quality and next responsible role. “Receive product information” is insufficient. Editors need an unambiguous product reference and a traceable source version. If either is absent, the next path must be defined. Otherwise uncertainty simply moves more quickly between systems without becoming easier to resolve.

Also state how the sending party recognizes that the activity has been accepted. Sending a message does not prove that someone has started work. Some workflows can use a shared task list with explicit states. Others need a more formal handover mechanism. The solution should follow the task rather than assuming that every transition requires another product or notification channel.

Describe waiting states explicitly. “Awaiting domain clarification” differs from “ready for publication”. Mixing them makes it difficult to determine whether technology or a missing decision is delaying completion. A clear state also helps a substitute understand what action is currently appropriate without reconstructing an entire conversation.

Identify authoritative sources and versions

Name an authoritative source for each substantive piece of information. In our example, a technical property comes from an approved specification. An older webpage or casual chat response does not replace that source. Conflicting documents require a resolution path rather than an accidental choice based on whichever file is easiest to access.

An approval must refer to a specific version. If the draft changes afterwards, decide whether the previous review remains applicable. Without that association, a system can display “approved” while publishing different content. Version identity therefore belongs in the process description rather than being postponed as an implementation detail for the database designer.

{
  "case_id": "CHANGE-017",
  "product_ref": "PRODUCT-004",
  "source_version": "specification-version-3",
  "draft_version": "draft-2",
  "reviewed_draft_version": null,
  "status": "awaiting_review"
}

This invented record deliberately describes an outstanding review. It is not evidence that authorization was actually granted. Its purpose is to expose the necessary relationship between source, draft and reviewed version. A production record would need to reflect the organization's actual information model and evidence rather than copying illustrative identifiers.

Translate decisions into observable conditions

“If everything is fine” is not a sufficiently precise decision rule. Which information must exist? Who evaluates a conflict? Which draft version was checked? Express conditions that the responsible person can decide using identifiable information. Not every condition needs to be evaluated automatically. Some can remain explicit human judgments with a defined output.

The example initially has three routes. Incomplete materials return for clarification. Complete materials proceed to editorial preparation. A reviewed draft can be handed to publication when the agreed responsibility has actually been exercised. A machine checking field completeness does not itself grant that substantive approval. Distinguishing those steps avoids turning a useful validation into unjustified authority.

Where a decision has several legitimate outcomes, describe every route, including an explicit negative result. Rejection is not a technical failure and should not trigger endless automatic retries. The process should make it possible to stop or revise the work for a meaningful reason rather than treating every non-success as an obstacle to bypass.

Choose a notation people can read

A small team can begin with a numbered sequence, roles and a decision table. Several organizations and parallel activities may benefit from an established modelling language. The OMG BPMN 2.0.2 specification provides a formal basis. A freely drawn sketch does not automatically become a valid BPMN model merely because it resembles one.

Use symbols according to their actual meaning. A diamond should not arbitrarily stand for “important step”. In an executable model, decisions and outgoing paths must fit the selected notation. For initial domain discussion, a simple clearly labelled representation can be more useful than a decorative diagram with ambiguous symbols. Formality should improve shared understanding rather than conceal its absence.

Check readability using a concrete case. A participant should be able to identify where their work begins, which information they need and what follows a negative review. If they cannot, the representation is not yet sufficiently understandable. Adding more symbols will not necessarily resolve an unclear responsibility or missing input.

Separate human work from technical execution

Editorial assessment differs from transferring a record. Camunda's documentation for user tasks and service tasks illustrates this distinction in a particular process environment. It does not imply that our example requires that product.

The domain description should preserve the distinction independently of tooling. Transfer may succeed while substantive judgment remains outstanding. Conversely, approval can exist while publication fails technically. These situations need different states and responsible roles. A single generic completion flag cannot explain both without additional context.

An AI-generated draft also remains a draft in this example. If a later task is automated, specify which inputs it may receive and which outputs it may produce authoritatively. Naming a general tool does not establish that agreement. An automated step needs a bounded responsibility as clearly as a human participant does.

Review exceptions through concrete cases

These are invented review scenarios exposing decisions the description might omit. They are not statistics about actual failures. For a real workflow, participants add the important exception types they have observed. The table should remain related to evidence rather than growing into an unprioritized list of every imaginable inconvenience.

Do not confuse repetition with successful repair

Technical transfers can fail or end with an uncertain result. Retrying must account for whether the initial attempt already changed something. Otherwise duplicate cases or repeated messages may result. Describe how repeated handling of the same substantive event is recognized. The required identity should come from the business activity rather than an arbitrary new identifier created for every retry.

A repeatable technical step differs from a newly required human decision. Resubmitting a rejected draft does not approve it. A corrected version, in turn, needs the assessment appropriate to that version. This distinction stops a general retry mechanism from bypassing substantive boundaries in pursuit of a green technical status.

Camunda's exclusive-gateway documentation includes the situation without a matching condition or default path. The relevant planning lesson is to handle an uncovered state explicitly. It must not accidentally receive whichever success route happens to be most convenient.

Measure elapsed and working time separately

An editor can prepare a draft in a short period of concentrated work and then wait much longer for a specialist response. Both belong to the case while representing different causes. Faster text transfer does not automatically remove waiting. The measurement question must therefore match the suspected problem rather than defaulting to the easiest technical duration to collect.

The GOV.UK performance-metrics guide connects purpose, hypothesis and suitable observation. This example could separately record initiation, handovers, clarification and evidenced completion. It supplies no invented actual durations or universal savings percentage.

In a real evaluation, state which cases are included. A simple wording correction and a disputed technical change should not be treated as identical work without explanation. Context determines which comparisons support a conclusion. Record limitations so an encouraging result does not become an unsupported promise for every later workflow.

Walk through the described process together

Begin with one complete fictional change request. Each role explains the information received, decision made and output handed onward. Then remove an important input. Finally assume a technical failure after approval has already been granted. These walkthroughs examine different properties of the description without pretending to be an actual system deployment.

Record unresolved questions as findings. If nobody can identify who resolves conflicting source versions, that is useful information. Do not fill the gap with an invented automatic decision. Clarifying responsibility makes the next implementation step defensible. The purpose of the exercise is to expose missing agreements while they are still inexpensive to change.

A walkthrough is neither actual publication nor evidence of operation under load. It can show whether goals, handovers and exception paths are internally understandable. Describe that bounded evidence accurately instead of presenting the entire automation as already implemented successfully. Later technical verification must address the properties a discussion cannot establish.

Only then select suitable automation steps

Once the workflow is clear, assess individual activities deliberately. Checking whether required fields exist can be rule-based. Association with an existing product may require a unique key. Evaluating an unclear technical claim is a different task. These distinctions determine how support can be introduced without treating every activity as interchangeable data processing.

Start with a bounded part whose inputs and result are well described. Plan observation and fallback. Existing work must remain traceable during transition. Two conflicting case records maintained simultaneously can create more problems than the original manual handover. The migration itself therefore needs a clear owner and an authoritative source of status.

The main contribution of process description is a better decision. It exposes what can be automated, what should first be changed and which responsibility deliberately remains human. An elaborate technical solution does not replace that clarity. A smaller intervention may be more useful when it addresses the actual reason for delay or uncertainty.

Control changes to the process itself

The process description also has a version and an owner. When the source or publication rule changes, update the workflow traceably. An old diagram in a project folder and a new rule mentioned in conversation are not a dependable shared basis. State which description governs the next implementation stage.

Review affected handovers after each significant change. Another required field can alter intake checking. Another approval role can affect waiting and substitution. Another publication system can change how completion is evidenced. These are more concrete effects than asserting that the process is “still the same”. Identify the consequences before carrying old assumptions into new implementation.

Also decide what happens to cases already in progress. A new rule must not silently transfer an earlier approval to different content. A small editorial team might resolve this explicitly case by case. Many concurrent cases require a more systematic transition policy. Both start with an expressed decision about which rule version applies and what happens when a conflict cannot be resolved.

Describe the case where no change is needed

An incoming notification does not always require another publication. The existing product page may already contain precisely the approved information. First verify that the source, product association and content genuinely agree. Similar wording alone is insufficient. If the substantive task is already satisfied, the case can end with an appropriate documented outcome rather than an unnecessary new version.

This route differs from rejection and technical failure. It avoids needless editing while explaining why no new content was produced. State who may make that determination and which reference to the existing material is recorded. A system should not rewrite something merely because another case was opened. Process logic follows the intended result rather than an expectation that every run must generate a visible change.

Checklist before technical implementation

• Purpose and substantive outcome are concrete.
• The trigger and possible endings are observable.
• Current practice is separate from the desired process.
• Roles, authority and access agree.
• Every handover names required inputs and the next owner.
• Sources and approved versions are associated unambiguously.
• Decisions include negative and unresolved routes.
• Important exceptions have been explored through concrete cases.
• Retries and duplicate handling are considered.
• Measurement, operations and fallback belong to the implementation plan.

Frequently asked process-mapping questions

Must every process first be fully modelled in BPMN? Necessary detail depends on the task and intended execution. An understandable sequence may suffice for initial agreement. An executable model needs additional precise rules and verification. Choose the depth according to the decision being made.

Can description alone be useful? It can expose missing information, unnecessary handovers and unclear responsibility. Whether this leads to actual improvement depends on subsequent changes and suitable observation. Recognizing a problem is useful without pretending the benefit has already been measured.

When is enough described? When participants can trace normal and important exceptional cases and the outstanding implementation question is explicit. The next step should reduce a concrete uncertainty rather than merely produce a larger diagram with more arrows.