Skip to main content

Approach / 01 of 05

  1. 01 Discovery
  2. 02 Design & Build
  3. 03 Testing
  4. 04 Governance
  5. 05 Support

Start with the workflow, not the technology.

Henswick maps how work actually moves across people, systems, approvals and exceptions before deciding what should change.

The work as it really happens

The documented process is rarely the whole process.

A process may look simple on paper, while the real operation contains the handoffs, side records, approvals, waits and exceptions that actually determine how the work moves.

Documented

  1. 01 Request
  2. →
  3. 02 Review
  4. →
  5. 03 Approval
  6. →
  7. 04 Complete

Observed in practice

■ On the documented map    □ Only in practice

  1. 01 System Request received Arrives in the CRM.
  2. 02 Person Record checked Looked up in a second system. Manual lookup
  3. 03 Person Data re-entered The same value, typed again. Duplicate entry
  4. 04 Handoff Owner notified Sent by email to someone else. Unclear owner
  5. 05 Approval Approval requested Sign-off sits outside the system. Approval boundary
  6. 06 Exception Exception resolved Tracked in a spreadsheet. Side record
  7. 07 System Downstream record updated Finally updated, days later. Waiting

Four of these seven events appear in the documented process. The rest only show up when someone watches the work happen.

System boundaries

The boundary matters as much as the automation.

Before anything is built, Discovery fixes where Henswick starts, where it stops, and who decides at the edge.

Architecture sketch · ownership marked

1

Trigger

2

System of record

Existing system

Data originates here

Owner: system owner

Today

Operational gap

Work carried by hand

Owner today: unclear

3

What Henswick touches

Connected work

Henswick

Moves work between systems

Owner: operations lead

5

Decision boundary

Owner: named approver

7

Completion

4

System of record

Downstream system

Completion is recorded here

Owner: system owner

6

Exceptions go to a named owner, not to an inbox.

  1. 1

    What triggers the workflow

  2. 2

    Where data originates

  3. 3

    What Henswick touches

  4. 4

    What remains inside existing systems

  5. 5

    Who owns decisions

  6. 6

    Where exceptions go

  7. 7

    What completion actually means

Seven answers, fixed before design begins.

Drawn on the sketch

Discovery marks each step of the mapped workflow as one or the other.

Automate

  • Repetitive transfer
  • Routing
  • Synchronization
  • Validation
  • Routine follow-through

Keep human

  • Judgment
  • Approval
  • Accountability
  • Exceptions
  • Decisions

Automation is not the goal. Better operations are.

Henswick identifies not only what should move automatically, but also what should remain intentionally controlled by people or by the client's existing systems.

What comes out of discovery

A clearer system before we build one.

Discovery ends with an operating model the build can start from, not a slide deck to file away.

  • A shared picture of how the work really runs.
  • A defined edge for what Henswick touches.
  • A short, ordered list of what to build first.

Discovery output

Operating model · illustrative extract

Change request to fulfilment

Mapped as practised, then marked for what to change and what to keep.

01

Mapped workflow

Seven events from request to completion, as practised.

→ the baseline

02

System boundaries

Touches: intake and ticketing. Stays inside: ERP and ledger.

→ the scope of the build

03

Handoff inventory

Intake to operations by email. Operations to finance by spreadsheet.

→ what to remove

04

Ownership

Request: operations lead. Exceptions: team manager.

→ named, not assumed

05

Approval points

Spend over the limit: finance approver.

→ the control points

06

Exception paths

Missing data returns to the requester, with a reason.

→ defined, not improvised

07

Candidate automations

A: intake to ticket. B: status sync. C: reminder chase.

→ the build list

08

Implementation priorities

A first. B once A is stable. C after review.

→ the order of work

Sheet

Operating model

Status

Ready to build from

Chapter

01 of 05

Next chapter / 02

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
Design & Build

Turn the mapped workflow into a working system.

Start here

Have a workflow that causes more friction than it should?

We can start by mapping how the work actually moves today.

Discuss your workflow