What a Business Systems Assessment Should Actually Include

Assessment is one of the least protected words in professional services. It gets used for a list of subscriptions, for a two-hour discovery call that ends in a proposal, and for a genuine examination of how a business runs. Those are three different products with three different outcomes, and only one of them helps a leadership team make decisions.

This is what the third one includes when it is done by a senior operator with no product to sell.

What an assessment is not

Two adjacent things get mistaken for it constantly, and both are cheaper for good reason.

• A software inventory is a list of what you own, what it costs, and who administers it. Useful for procurement. It describes the stack without evaluating whether the stack fits the work, so it cannot recommend anything beyond consolidation.
• Vendor discovery is a scoping conversation performed by a party whose revenue depends on implementing something. The questions are competent and the conclusion is structurally predetermined. It is a sales step, not an assessment, and it should be read that way.

"An assessment you can only act on by buying the assessor's product was never an assessment."

The nine areas a real assessment covers

Scope varies with the size of the organization, but the categories do not. If a proposal is missing several of these, it is examining the tools rather than the business.

1. Current-state workflows

End-to-end paths through the business, documented as they actually happen rather than as the process document claims. This includes the exceptions, because exceptions are usually where the real cost lives.

2. Systems and integrations

What is in place, what each system is genuinely used for, where data crosses a boundary, and how it crosses. Manual handoffs get documented as integrations, because operationally that is what they are.

3. People and ownership

Who owns each system, each dataset, and each decision. Ownership gaps and key-person dependencies are findings in their own right, and they are frequently the highest-severity items in the report.

4. Data and reporting

Where the numbers leadership relies on originate, how they are assembled, and whether two systems can be reconciled at all. If a routine question cannot be answered the same way twice, that is a structural finding rather than a reporting preference.

5. Adoption

Whether the software in place is used as designed, partially, or performatively. A capable platform used at thirty percent is a different problem from a platform that does not fit, and the remedies have nothing in common.

6. Risk

Access and permissions, single points of failure, undocumented automations, data held in personal accounts, and continuity exposure if a specific person left this month. This section exists to be uncomfortable.

7. Bottlenecks and constraints

The specific steps that limit throughput, ranked. Most organizations have two or three real constraints and a long list of irritations, and treating them as equal is how improvement budgets get spent without anything getting faster.

8. Recommendations with rationale

Each recommendation tied to a named finding, with the reasoning visible and the tradeoffs stated. That includes the recommendations to leave something alone, which are often the most valuable ones in the document.

9. Prioritization and a sequenced roadmap

Not a wish list. A sequence, ordered by dependency and cost of delay, with an owner and a rough effort band for each item. Sequencing is the part that makes an assessment actionable, because it tells leadership what genuinely has to happen before anything else can.

What leadership should receive

• A written current-state picture leaders recognize as their own business.
• A ranked findings list with severity and estimated recurring cost.
• Recommendations that include process, ownership, and data changes, not only software.
• A phased roadmap with dependencies made explicit.
• A clear statement of what should not change right now, and why.

Why senior-led and vendor-neutral are not marketing words

Junior-led assessments produce accurate documentation and weak judgment. The value of this work is almost entirely in deciding which findings matter, which is a function of having run operations rather than having interviewed people who do. Vendor neutrality matters for a plainer reason: an assessor with an implementation practice attached has one recommendation available in every situation.

Neutrality also makes it possible to recommend nothing. A good assessment sometimes concludes that the stack is adequate and the problem is ownership or process discipline. That is a legitimate outcome and it is why the audit-first operating model puts examination before selection.

Before you commission one

Ask what the deliverable is, who does the work, what the assessor sells afterward, and whether the roadmap will include items that require no purchase. The answers separate an examination from a proposal in about four minutes.

Our version of this is documented on the technology assessment page, the methodology is published under frameworks, and what happens after the report is described in services.