What I review

  • The current process or system
  • Bottlenecks, manual handoffs, and data quality
  • What to build, buy, integrate, configure, or leave unchanged
  • Technical risks, dependencies, and operational constraints
  • Relevant data, systems, and integrations

What you receive

  • The main problems and risks
  • A written solution recommendation
  • A build-vs-buy-vs-integrate recommendation
  • Rough implementation scope, important dependencies, and next steps

Before you start

This is a bounded decision-making engagement, not an open-ended investigation. The proposal names the workflow, systems, people, tests, and output included.

Expected client involvement

  • One process owner for a kickoff conversation and one review of the draft findings.
  • The current steps, exceptions, and decision the audit must support.
  • Examples of normal and failed cases, with sensitive data removed where possible.

Access and information

  • Read-only access to relevant screens, documents, exports, or API documentation, as applicable.
  • Access to one person who understands the current process and one person who can confirm technical constraints.
  • The proposal specifies how access is shared safely.

Scope boundaries

  • One named workflow or system per audit unless the proposal says otherwise.
  • No production changes, data migration, implementation, or ongoing support.
  • Testing covers the agreed normal and exception paths. Unlisted systems or workflows are separate scope.

Timing and price basis

  • Timing and price are based on the number of workflows and systems, access available, interviews needed, and paths to test.
  • The proposal lists client time, access, deliverables, review, and assumptions before work starts.
  • If configuration, integration, or no custom software is the better answer, implementation is quoted separately.

Illustrative audit output

An invented approval workflow, to show what the report looks like.

Workflow under review

  • A request arrives by email or form.
  • A staff member enters it into the ERP.
  • An approver reviews and accepts or rejects it.
  • The approved record is exported for reporting.

Decision section

  • Risk: duplicate entry and missing fields.
  • Buy: use the ERP approval module if its rules fit.
  • Integrate: connect intake to the ERP and log failures.
  • Build: add a small internal screen only if existing tools cannot model the required rules.
  • Rough scope: map the current workflow, inspect the ERP interface, test one normal path and one error path, then document the boundary.

Recommendation: start with the audit. Do not assume that custom software is the answer before the current rules, data and system limits are checked.

Exact scope, timing, and price are confirmed before work starts. To begin, describe the process or application in a short inquiry. I will reply within one business day and we can decide whether the audit is the right next step. If a standard product, configuration, or no custom software is the better answer, the recommendation will say so.

Prices exclude VAT and are starting points. Scope, technical and regulatory complexity, deadlines, the state of existing systems, and other factors can change the final price, which is always confirmed in writing before work starts.