How to Assess an Acquired Company's AI Readiness in Two Weeks

A newly acquired company can have a compelling AI opportunity and still lack a reliable way to use its own records. A two-week readiness assessment gives the sponsor and management team a grounded decision: which workflow can they test now, which gap must they fix first, and who owns each step? The answer comes from observing work and checking actual systems, not from counting AI licences.

Days 1–2: choose the decision and two workflows

Start with the acquisition's value-creation plan. Ask the CEO and sponsor which operating measure they need to improve and who is accountable for it. For a regional B2B distributor, the answer might be the time staff spend resolving invoice disputes or the delay between a customer order and a confirmed delivery. Write down the current measure, its source, and the cost of a wrong result. If the business cannot yet measure it, the assessment must say so.

Choose two recurring workflows, with enough volume to observe during the fortnight. Ask a manager to nominate a process owner, a front-line operator, and the person who can grant system access for each. Agree on a short list of evidence: recent cases, process notes, system names, data exports or read-only views, access rules, and a sample of existing reports. Bain's post-acquisition guidance calls for an actionable value-creation plan shared by management and the sponsor. That plan gives the assessment its business question.

Set the boundary early. This review selects a first test and records the work needed to run it. It doesn't certify every company system or promise an AI return before a pilot has measured one.

Days 3–4: watch the work and its exceptions

Follow a live case with the people who do the work. In the distributor, an invoice dispute starts in a shared inbox. A coordinator finds the order in an ERP system, checks delivery proof, looks up a price agreement in a CRM system, and asks a manager to approve a credit if the customer has a valid claim. Record each handoff, the time spent finding context, and the decision that closes the case. Then watch a case that goes wrong: a partial delivery, a missing reference number, or a price agreed outside the normal system.

Take a small sample of recent completed cases to find the common paths and exceptions. Twenty cases can expose where to look next, but they cannot establish a precise error rate for the whole company. Ask operators which workarounds they trust, what they correct by hand, and where customers wait. Compare those answers with the formal process map. NIST's AI Risk Management Framework asks teams to define the intended task, business value, data suitability, and human oversight in the setting where an AI system will run.

Capture a baseline before proposing a tool: cases per week, time from arrival to resolution, the share that needs an approval, rework, and customer complaints. Use the company's own records where they exist and mark estimates as estimates.

Days 5–6: trace the records and systems

For each observed step, identify the record it uses and the system that owns it. The distributor's customer name may appear in its CRM, while the ERP holds invoices under a different identifier. Delivery proof may sit in a document store, and staff may copy the final decision into a spreadsheet. Ask who can correct each record, when it last changed, how a user gets access, and whether the system can supply a reliable read-only view. A screenshot proves that a person can see a record; it doesn't prove that a new application can retrieve the right version.

Check a few representative cases end to end. Can the team join an invoice to an order, delivery, customer agreement, and final adjustment without guessing? Which documents have no owner or clear retention rule? Record missing fields, conflicting definitions, stale updates, and manual transformations separately. Microsoft's AI readiness assessment includes data foundations, governance, infrastructure, and organisational capacity; a working sample shows how those broad areas affect this company's chosen task.

For each source, write one line with its business owner, technical owner, access route, update frequency, and known limitation. That small source map becomes the first integration plan if a pilot earns approval.

Day 7: check access and operating constraints

Ask IT and security to show how the pilot would authenticate, which records it could read, what it could write, where requests and outputs would be logged, and who could inspect those logs. Check customer contracts and the company's own data policies before sending records to any provider. If the acquired company still uses a seller-operated system under a transition agreement, establish who can grant access and when that agreement ends.

Separate drafting from action. An assistant can propose a dispute summary using approved records while a staff member decides whether to issue a credit. Automatic credits require dependable identity matching, authority limits, an audit trail, and a recovery path if the action is wrong. NIST's framework calls for clear roles, documented human oversight, and mapping third-party software and data risks. The assessment should name each missing control rather than award a vague governance score.

Day 8: name the people who can run the change

Interview the process owner, an operator, the data owner, and someone who maintains the systems. Ask who can approve a revised workflow, label examples of correct and incorrect outcomes, fix a data issue, support users, and pause the pilot. Check how much time those people can actually give over the next month. A named sponsor without an available operator cannot test the work; a keen operator without permission to change it will stall at the first exception.

Review tools already in use, including unofficial AI accounts, and ask where staff have found them helpful or unreliable. That conversation reveals adoption barriers and places where sensitive records may already leave approved systems. Make the manager responsible for explaining the pilot's scope, the review step, and the path for reporting a bad result.

Day 9: rate each workflow against its blockers

Rate readiness per workflow. For each candidate, answer five concrete questions: Is the business outcome measurable? Can staff describe the real work and its exceptions? Can the system read the right records with permission? Can a person review high-impact decisions? Is there an owner with time to run a test? Mark the workflow ready to test, conditional, or blocked, and write the evidence beside each answer. A high average score should not hide a missing permission or an unowned customer record.

In the distributor example, dispute triage may be ready for a narrow, read-only pilot: staff can supply past cases, the ERP and CRM records can be linked for most sampled disputes, and a coordinator will review every draft. Automatic credit issuance stays blocked if customer identifiers conflict or approval authority lives only in an email habit. Both opportunities use the same source systems, but they require different levels of certainty and control.

Record what would change each rating. A conditional workflow might need a maintained customer-ID crosswalk, a named data owner, or a tested access method. Give that task a person and a date. Leave an opportunity out of the first pilot if the team cannot close its blocker at a sensible cost.

Day 10: hand over a decision pack

Give management and the sponsor a short pack they can act on: the two workflow maps, baseline measures, source-and-owner map, exceptions, access and contract constraints, readiness ratings, and a costed first experiment. For the chosen pilot, state the cases it will handle, which actions stay with staff, how the team will measure quality and total effort, who can stop it, and the date of the next funding decision. Put unresolved facts on the first page.

For the distributor, the decision could be to test read-only dispute summaries on recent cases with a coordinator checking every draft, while IT repairs the customer-ID link before any automated credit work. Measure resolution time, correction effort, and wrong-document use against the existing process. If staff spend more time fixing summaries than they save finding records, stop or narrow the test. If the pilot clears its quality bar and reduces total effort, fund the integration and support work needed for wider use.

Two weeks are enough to make this first decision when the sponsor provides access to the people and records on day one. Where access or ownership is missing, report that as the finding. It gives the board a concrete task to fund before it asks the company to scale AI.