A purchase request leaves someone's desk. It needs an approval, a budget check, and a supplier confirmation before anything is ordered. In many organisations, that request travels by WhatsApp message, printed form, or a phone call — and it is genuinely unclear who is supposed to say yes. This is illustrative, not a description of any named client, but most operations leads reading it will recognise the shape of it.
That single unresolved handover is usually the real starting point of an ERP decision — not a sales brochure, not a competitor's shiny dashboard. An ERP decision starts with agreement about how work should move between people. Before you sit through a platform demonstration, it is worth preparing a discovery conversation that is actually useful: one grounded in your own workflow, your own data, and your own constraints.
This guide walks through six questions we ask — and that we think any serious implementation partner should ask — before recommending a platform, a phasing plan, or a go-live date.
Start With One Broken Handover, Not the Whole Business
Trying to map "the entire business" before an ERP conversation is a common way to stall. Instead, pick one recognisable, frustrating handover — a purchase request, a leave approval, a stock transfer between two sites — and trace it end to end.
Illustrative scenario: a purchase request for office supplies is raised verbally, approved by a manager over WhatsApp, and never recorded until the invoice arrives for payment. Nobody disputes that it happened; nobody can say, three weeks later, who approved what quantity at what price.
Write the workflow down as it actually happens today, not as the policy manual says it should happen. Note every handoff, every delay, and — importantly — every workaround your staff use because the official process is too slow or unclear. Those workarounds usually point directly at what an ERP needs to fix first.
Map the Full Path: Request, Approval, Receipt, Report
Once you have one workflow on paper, extend the same discipline to the surrounding steps:
- Request — who raises it, in what format, and how is it captured?
- Approval — who is authorised to approve, at what value thresholds, and what happens when they are unavailable?
- Receipt — how is delivery, completion, or fulfilment confirmed against the original request?
- Reporting — who needs to see the outcome, and in what timeframe, to make a decision?
Most organisations find gaps at the joins — not within any single step. The request is clear. The approval is clear. But the link between "approved" and "actually received" is where paper trails go missing and reconciliation becomes guesswork.
Assign an Owner to Every Master Record
An ERP is only as reliable as the master data behind it — customer records, supplier records, chart of accounts, item catalogues, employee records. Before configuration begins, answer three questions for each record type:
- Who owns it? Not who uses it — who is accountable for its accuracy.
- Who can approve a change? A new supplier, a new price list, a new general ledger account.
- Which exceptions need a human decision? A one-off discount, an emergency purchase, an off-cycle payroll adjustment.
If two departments both claim ownership of the same record — or neither does — that ambiguity will surface again inside the new system, just with a better user interface hiding it. Resolving ownership before implementation is far cheaper than resolving it during user acceptance testing.
Separate What the First Phase Needs From What Can Wait
Not every department has to go live on day one. Trying to satisfy every stakeholder's wish list in a single phase is one of the more common ways ERP projects lose momentum before they deliver anything.
Decide, in writing, what the first operating unit genuinely needs to function — usually the workflow you traced in the first step, plus its immediate dependencies (approvals, the relevant part of the chart of accounts, core reporting). Everything else becomes a later phase, sequenced deliberately rather than bolted on under pressure.
This is a scoping discipline, not a technical limitation of any particular platform. A configurable, multi-tenant ERP such as Kraal Code is designed to be implemented in phases — diagnose, configure, adopt, operate — precisely so that the first phase can be scoped to what one operating unit actually needs, with later units following once the first is stable.
Check Whether You Can Actually Rehearse the Change
Three practical questions decide whether a project can move at the pace a vendor proposes:
- Sample data quality. Can you export a redacted sample of your current records — customers, items, opening balances — clean enough to test against? If nobody can produce this without weeks of manual cleanup, that cleanup is itself a project phase, not a footnote.
- Staff availability. Will the people who actually process transactions have time to test workflows, attend training, and give feedback — or will testing fall to whoever is least busy that week, regardless of whether they touch the process daily?
- Ability to rehearse. Is there a way to run the new workflow in parallel with the old one for a short period, so problems surface before go-live rather than during it?
Answering these honestly, before a contract is signed, prevents the most expensive kind of surprise: discovering in week six of a twelve-week plan that the data was never usable in its current form, or that the one person who understood the procurement process was never available for training.
Decide: Go, Prepare First, or Defer
With the workflow mapped, ownership assigned, phasing agreed, and readiness assessed honestly, there are three sound outcomes — and all three are legitimate:
- Go. The first workflow is understood, one owner is accountable for each master record, sample data exists, and staff have time to test. Proceed to a scoped discovery conversation.
- Prepare first. The workflow makes sense, but data or ownership gaps need closing before a vendor conversation would be productive. Assign an internal owner to that preparation, with a date to revisit.
- Defer. The organisation has more urgent priorities, or the workflow chosen is not yet a real pain point. Documenting that honestly now saves everyone a rushed, under-resourced project later.
Each outcome needs one accountable next action and one accountable person — not a vague intention to "look into it."
A Worksheet You Can Use This Week
Before any platform demonstration, fill in one row per workflow:
| Workflow | Current pain | Record owner | Source record | Known exceptions | First-phase need? | Preparation action |
|---|---|---|---|---|---|---|
| e.g. Purchase request → payment | Approval untracked, no audit trail | ? | ? | Emergency purchases | Yes / No | ? |
Bring this — filled in for one real workflow, with company-identifying details redacted if needed — to a scoping conversation. A worksheet like this tells an implementation team more in twenty minutes than a generic feature list ever will.
Where Kraal Code Fits
Kraal Code is Chwezi's flagship ERP platform — financial control, inventory and warehousing, procurement, people and payroll, sales and CRM, assets and maintenance, approvals and audit trails, and field and mobile workflows, delivered through a diagnose–configure–adopt–operate implementation model. A product page describes the offer. It is not, on its own, proof that your organisation is ready — that is exactly what the questions above are for.
If your organisation is working through this readiness question, bring one mapped workflow and a redacted sample record to a Kraal Code scoping conversation. That single artefact will do more to focus the discussion than any generic requirements document.
Frequently Asked Questions
How long does an ERP readiness assessment take?
For one workflow, mapping the process, assigning record ownership, and checking data quality typically takes a few days of focused work, not weeks. A single workflow can usually be assessed within a week.
Do we need every department ready before starting an ERP project?
No. Scope the first phase to one operating unit's real needs and sequence other departments as later phases. Treating every department as a launch dependency is a common way ERP projects stall before delivering value.
What if our data quality is poor?
Poor sample data quality is common and not disqualifying. It means data cleanup is its own preparation step before implementation, not something to discover mid-project. Assign an owner and a date to close that gap, then revisit the go, prepare-first, or defer decision.
Is Kraal Code the right ERP for every organisation?
Kraal Code is designed for organisations that have outgrown spreadsheets or disconnected applications, need one source of operational truth across departments, and value approvals, audit trails, and reliable reporting. Fit depends on the workflow and readiness questions covered in this guide, not on the platform alone.
Continue with Configure or Customise Your ERP? Decide Before Development Starts. A third guide on agreeing your opening records before go-live is in preparation and will be linked here once published.
