An AI readiness checklist for operations teams
An AI readiness checklist for businesses running an ERP and ecommerce: six things to have in order before the first automation ships.
Readiness is about your systems, not the model
The model is the one part of an AI project that arrives finished. What is not finished is the ground it stands on: which system owns which fact, whether the fields it reads are filled in, who may approve what it proposes, and whether anyone has counted the manual work it replaces. Projects stall on one of those, after the build has started, when the fix is expensive.
This checklist is the six things we want in writing before an automation is scoped, each with the reason it matters and what it looks like when missing.
1. Systems of record and their APIs
- For each fact that matters (price, stock, order status, vendor lead time): the one system that is its source of truth.
- For each system: whether it has an API, whether it allows writes, and its rate limits.
- For each export path (ERP to storefront, ERP to shipping): which fields it carries and which it drops.
Why it matters. An automation that writes the same fact to two systems creates two truths, and the business spends its time reconciling them. The rule we build to is one write destination per fact, every other system a reader or an exporter; the reasoning is in read widely, write narrowly. The rule needs the ownership map first.
Example. Butler, at PPC International (a Brdy Holdings portfolio company, so our own business), never writes a storefront directly. Prices and listings go into Odoo and Odoo's connector exports them to Shopify. Where the connector cannot carry a field, the automation cannot set it. That is a scoping fact, not a week-six bug.
2. Data quality in the fields that matter
- The specific fields the first automation will read. Not "the product data"; the actual columns.
- For each: how many records have it filled in, and whether its users believe the values.
- Where one entity has different identifiers in different systems (ERP SKU, storefront variant ID) and whether a mapping exists.
Why it matters. "Clean the data" as a general project never finishes. Cleaning the twelve fields one automation reads takes days. That decides whether the project starts this quarter.
Example. Purchase planning reads vendor lead times. In many ERPs that field defaults to zero when nobody has set it, and a reorder calculation that believes a zero lead time proposes ordering everything on the day it runs out. The model is not wrong; the field is. Checking one column first is the difference between a useful first run and a week of distrust.
3. Who approves what today
- For each action the automation might propose (raise a PO, confirm an order, send a reply, change a price): who signs off today, above what threshold.
- Where approval is implicit: the thing one person "just does" because they always have.
- Who covers when they are away.
Why it matters. An automation inherits an approval map; it cannot invent one. If the map is not written down, the build either guesses, which is how a model ends up issuing refunds, or routes everything to one person, who becomes the bottleneck. Our design is that the model proposes, code executes, and a named person approves; the alternatives and how they fail are in three ways an ops agent fails.
Example. A wholesale order arrives by email from an account on credit hold. The automation can draft the confirmation. Whether it is sent belongs to whoever owns that account, and the automation needs that name before the first email arrives. If no approver is named, the correct behavior is to stop and ask, and that rule is written down too.
4. Where the manual work actually is
- For one week, what each person in operations did, in half-hour blocks.
- Which blocks were re-keying (the same fact typed twice), reconciliation (checking two systems agree) and judgment (deciding something).
- Which spreadsheets live outside the ERP, and why.
Why it matters. The work people describe when asked is the judgment calls. The work that eats the day is re-keying and reconciliation, which nobody mentions because it is dull. Those are the parts that automate cleanly, because they contain no judgment. The log finds them.
Example. An end-of-day report that takes an hour is rarely an hour of analysis. It is forty minutes pulling numbers from the ERP, two storefronts and the shipping platform into a sheet, and twenty minutes writing three sentences. The forty minutes is a scheduled automation. The sentences can be drafted and checked. Neither shows up if you only ask what is hard.
5. Credentials and environments
- Every credential the automation will need, who issues it, whether it can be read-only, and how it is revoked.
- Whether a non-production copy of each system exists, with its own credentials.
- Where secrets will live: a secrets manager, a file on a server, or an old chat message.
Why it matters. The automation will be developed, tested and run in at least two places, each needing its own keys. If they share keys, the test environment can act on production. It is why our security practices treat environment separation as part of the system.
Example. In July 2026 a staging copy of Butler, at PPC International (a Brdy Holdings portfolio company, which is why we can publish this), still held production Slack credentials. From July 7 to July 15 it posted duplicate end-of-day drafts into real channels daily. The code was correct everywhere; one stack had the wrong secret. An inventory of which key sat in which stack would have shown it at once.
6. A measurement baseline before anything ships
- The one or two things the first automation should change: hours spent, orders re-keyed, days to reorder, tickets answered on time.
- How each will be counted, by whom, over what period, starting now.
- The current value, by that method, for a few weeks before anything ships.
Why it matters. Without a baseline, the project's result is somebody's impression, and impressions become percentages in board decks with no method behind them. We hold our own figures to the same test and it costs us numbers we would like to use; the reasoning is in the findings we can publish. A baseline measured by a written method is the only way the result survives a skeptical CFO.
Example. If the goal is fewer stock-outs, count them now, by SKU, by week, and agree what counts as one. If the goal is time, use the log from item four. The build then has a number to beat, with a method behind it.
What readiness is not
It is not a data warehouse, a data lake or a platform project. It is not a company-wide AI policy, though you will want one eventually. It is not having chosen a model. Every item above is a document an operations lead can produce with the people already in the building, and each is useful even if nothing is built on it.
If you want a second pair of eyes on it, that is the first half of an AI opportunity assessment; we describe what an assessment covers step by step. If the list is done and the manual work is mostly in the ERP and the storefronts, the AI automation for ERP and ecommerce operations page describes what a first project looks like.
Common questions
Do we need all six items before starting?
You need all six for the first automation, scoped to it. The systems and approval maps need only cover what it touches; the data check only the fields it reads. Done that way, the list is a week of work.
Our ERP has no API, or a very limited one. Are we not ready?
You are ready for a narrower project. Reading is usually possible through a database connection or exports even when writing is not. An automation that reads and proposes, with a person making the final entry, still removes real work.
Who should own the checklist?
The operations lead, with the ERP administrator for items one, two and five. Not IT alone, because items three and four are about how the business runs, and not a vendor, because the answers should exist before one is chosen.
Is a readiness checklist the same as an AI strategy?
No. The checklist establishes whether a specific automation can be built safely. An opportunity assessment decides which automations are worth building, in what order, using the checklist as input.
If you have worked through the list, or want help with it, a scoping conversation is the next step.