Decision guides
When should a spreadsheet become a business system?
Repeated re-entry, conflicting versions and unclear approval ownership can signal a process problem. A new application helps only when it makes that process clearer. Start with one workflow and its exceptions.
Planning guide. Examples are illustrative; they are not customer case studies or measured results.
Name the business event, not a list of screens
For an illustrative purchasing workflow, describe request creation, approval, purchase, receipt and reconciliation. For each event record the owner, required fields, evidence and next action. Include rejection, cancellation, partial receipt and a missing approver. This becomes a scope that staff can review against actual work.
Compare three options before commissioning development
Keep a spreadsheet when the workflow is small, changes are infrequent and one owner can control it. Evaluate an existing product when standard processes, permissions and integrations fit. Consider custom software when important handoffs, access rules or system connections remain unsupported. Compare export options, support and total operating cost, not feature counts alone.
Agree a source of truth for every record
List the identifiers, status values and reference data that must be consistent. If an accounting product owns a supplier record, decide how the new system references it. Write down the resolution for duplicates, missing identifiers and conflicting amounts. Avoid allowing two systems to silently overwrite the same field.
Rehearse a migration before switching
Take a permitted sample, clean it, import it and reconcile it with the source. Check totals, statuses, record counts and important exceptions. Record what could not be migrated. Agree a cutover owner, a fallback and a reconciliation method for any parallel-running period.
Accept the system through complete tasks
A successful login is not an acceptance test. Have each role perform representative tasks, including restricted actions, corrections and exports. Confirm that failed integrations are visible and recoverable. Before handover, agree hosting access, source-code rights, data exports, recovery procedures and the support boundary.
| Question | What to collect | How it changes the choice |
|---|---|---|
| Where does work wait? | A recent request and its handoffs | Prioritise the bottleneck rather than reproduce every sheet |
| Which records conflict? | Examples of duplicate or mismatched records | Set identifiers and a source of truth before integration |
| Who may approve or edit? | Roles, limits and exception rules | Test access and approval paths before rollout |
| What must survive a move? | Records, files, history and exports | Rehearse migration and verify recovery options |
Plan the next step
- One workflow and a named business owner.
- Anonymised examples of normal and exception cases.
- Existing products, API access and licensing constraints.
- Acceptance tasks, migration reconciliation and operating responsibility.
For a Malaysian business replacing fragmented tools, AAA Labs can help map the process and compare a bounded custom build with existing software. Describe the workflow before sending spreadsheets containing customer or employee data.
All decision guides