Bold Group
The bank was already producing the record they planned to build.
A corporate finance team, part-way through digitizing how staff claim travel expenses. The next increment had already been scoped: a claims app.
The situation
The question was not how to capture receipts more accurately, but why they had to be captured at all.
The team had done good work. Paper forms had become a digital form, staff uploaded receipts, and exchange rates came in from the Bank of Thailand automatically. What remained was the part digitizing could not remove: every bill keyed in line by line, OCR misreading enough of them that finance reconciled by hand anyway, and staff still paying for company travel from their own accounts while they waited to be repaid.
The turn
More software was not the only next step.
The next step has to be more software.
Where does this information already exist in an authoritative form, and what are we about to build to reconstruct it?
The decision: establish where the record already exists in an authoritative form before scoping anything to reconstruct it.
Before
- Staff pay from own account
- Upload receipts
- Key in line by line
- Correct OCR misreads
- Staff repaid
The next increment on the table: an app to capture receipts more accurately.
After
- Pay on a company travel card
- Bank sends each transaction itemized, dated and converted
Cash spend, merchants that do not take cards, and policy exceptions still need a route, and the design has to state it.
Schematic, not to scale.
How we worked it
How the requirement was separated from the app.
- 01
Trace each field to its source
Follow every value on the claim form back to the moment it was created, and find where it already existed in complete, authoritative form.
- 02
Separate the requirement from the specification
Pin down what finance and audit must be able to evidence, as distinct from the application that had been proposed to evidence it.
- 03
Name what still has to be built
Define the controls, exceptions, cash spend and policy cases the card and statement do not cover, so the remaining scope is stated honestly rather than assumed away.
Traced each field on the claim back to where it was created, and kept the requirement apart from the app proposed to meet it.
Owns the policy, the banking relationship, and the route for everything the card does not cover.
What came of it
Paid on a company travel card, a transaction arrives from the bank itemized, dated and converted. The record the team was scoping an app to capture was already being produced.
This is a design. We do not claim the software build was cancelled or that any saving was realised. It illustrates requirement discipline; it is not a claim that custom software is generally avoidable.
How we label evidenceIs this your situation?
Signs
- A build has been specified before anyone examined the requirement it is meant to satisfy.
- The data being captured already exists somewhere authoritative, and is being reconstructed rather than used.
What it needs from you
- Someone who can state what must be evidenced, separately from how, and set the route for cash spend, non-card merchants and policy exceptions.
Start here
Bring the result you need, and the thing you have been told cannot change.
One hour with a founder. You leave with a first view of where the answer may sit, and which engagement, if any, fits.
Teerasak WongpiyaCo-Founder and Managing Director
60 minutes, in Thai or English, online or at your office.