Are Your Teams Using ERP Effectively? Measure task completion, quality and the problems people face.
People can sign in to an ERP every day while completing important decisions somewhere else. They can also use the system infrequently and perform a specialized task correctly whenever it is needed. Activity alone provides an incomplete picture of adoption.
A more useful question is whether the required way of working is taking hold: are people completing the right tasks, preserving controls, handing work forward cleanly, and managing exceptions with an appropriate level of support?
Measure those behaviors alongside the quality of the result and the friction involved. The proposed scorecard below helps process owners identify where work needs attention and choose a response. It is designed for improvement, with clear definitions and contextual evidence, rather than for ranking employees through a single adoption percentage.
Define adoption at the level of a business task
Choose a consequential task and state the behavior it requires. “Use purchasing” is too vague. A stronger definition might describe how a requester supplies required information, how an approver makes a decision, and how the resulting order reaches the receiving team.
Connect the behavior to a quality expectation. A completed task should satisfy the relevant policy, contain reliable data, and be usable by the next person. Fast completion that creates rework elsewhere is a weak adoption signal.
Then identify the business outcome the behavior is intended to support, such as reliable receipt matching or fewer preventable order holds. Treat the relationship as a hypothesis to examine. The outcome can also be affected by staffing, supplier behavior, demand mix, or upstream data quality.
Write one adoption statement per role and scenario: “This role can perform this task, to this quality, under these conditions, with this permitted support.” That gives supervisors and process owners a shared reference for observation and measurement.
Combine completion, quality and friction
A balanced scorecard needs signals that challenge one another. Start with a small set that the team can interpret and act on:
- Completion: Eligible tasks completed through the intended process within the relevant window
- First-time quality: Completed tasks accepted without a defined, avoidable correction or return
- Control adherence: Evidence that required approvals, checks, and exception routes were followed
- Support dependence: Help needed, its purpose, and whether the same question recurs
- Workaround reliance: Material steps performed outside the intended process and the need they serve
Define each measure precisely. For completion, the denominator should represent the work that was actually eligible and due. Otherwise, a team may look slow because records awaiting external information are counted as executable tasks. For first-time quality, decide which corrections count and where they are detected.
Avoid treating every help request as failure. Escalating an unfamiliar, consequential exception can be the correct behavior. Separate routine task assistance from legitimate expert consultation and from help made necessary by a system or data defect.
Show volumes alongside rates. A perfect result across a very small population may tell the team less than an improving result across varied, high-consequence work. State when a scenario has not occurred often enough to support a confident conclusion.
Add a measurement contract to each score
For each signal, write a short definition that includes the task, population, calculation, source, observation window, accountable owner, and known blind spots. Add the decision the measure is meant to inform.
For example, a purchase-request quality measure might count requests returned because mandatory information was missing. Its definition should distinguish missing requester input from new information demanded after submission. Those conditions imply different corrective actions.
Specify who can inspect the underlying records and how long identifiable detail is retained, following the organization's privacy and access requirements. Team-level learning often needs less personal information than a detailed activity trail. Collect the minimum evidence that supports the improvement question.
Check data quality before interpreting a score. Events may be recorded differently across locations, work may arrive in batches, and corrections may occur without a formally logged rejection. Pair system evidence with a small, purposeful sample of completed work to see what the metric misses.
The scorecard is itself a process that needs ownership. When task design or recording behavior changes, update the measure and mark any break in comparability. An apparent improvement caused by changing the denominator should not be presented as a behavior change.
Compare like work under visible conditions
Segment results where the operating context changes their meaning. Relevant distinctions may include role, site, shift, transaction complexity, time since training, or availability of local support. Choose segments because they explain the work, not because every available data field can produce a chart.
A team handling complex exceptions should not be compared directly with a team processing routine transactions. Nor should new starters be expected to display the same support dependence as experienced staff without considering what they have had the opportunity to practice.
Watch for work being displaced. A faster upstream step may leave downstream teams correcting incomplete records. Follow a sample across the handoff so that local improvement does not conceal a broader decline in quality.
Use caution with small groups. Their results can fluctuate sharply and may identify individuals indirectly. Combine periods or use qualitative evidence where that better supports a fair interpretation. The aim is to locate a problem that can be solved, not to manufacture precision from limited observations.
Diagnose before choosing training
When a signal deteriorates, observe the task with the person doing it and compare the evidence with the intended process. Ask what they were trying to achieve, where the work became difficult, and what they did next.
Test several possible causes:
- Skill: The person does not yet know or remember how to perform a defined task.
- Design: The intended workflow does not accommodate a legitimate scenario or creates unnecessary effort.
- Data: Required information is missing, late, inconsistent, or difficult to trust.
- Access: Permissions prevent the assigned role from completing approved responsibilities.
- Capacity: Workload, interruptions, or unavailable approvers make the process impractical within its deadline.
- Ownership: People disagree about who makes the decision or receives an exception.
More than one cause may apply. A user may need practice while also encountering a poorly designed exception route. Record the evidence supporting the diagnosis and what observation would challenge it.
Choose the intervention accordingly. Practice and coaching can address a skill gap. They cannot supply missing master data or free an overloaded approver. Treating every adoption problem as resistance risks repeating training while leaving the obstacle intact.
A hypothetical scorecard that changes the response
Imagine a hypothetical service business reviewing purchase-request adoption. Login activity is high, but requests frequently return to their creators. The initial suggestion is refresher training for all requesters.
The process owner segments returned requests by reason and scenario. Routine purchases are generally complete. Most returns involve a new service category whose required information differs from the standard form. A small group of inexperienced requesters also makes ordinary coding mistakes.
Observation shows that the form gives no clear route for the new category. Experienced staff have created a separate worksheet to collect missing detail. The worksheet then reaches the approver through an informal channel, creating an inconsistent evidence trail.
The response has two parts. The process owner clarifies the category requirements and tests a controlled way to capture them. Supervisors provide focused practice for the requesters who need help with ordinary coding. The team checks subsequent completion, return reasons, and the quality of the approval evidence.
If the results improve, the team can say they improved after the combined changes. It should avoid claiming that training alone caused the improvement. The scorecard supports a more precise intervention and a more honest interpretation of the result.
Make the review useful to the people being measured
Review the signals with supervisors, representative users, support staff, and the process owner. Begin with a concrete task and a small sample of evidence. Let the people doing the work challenge the interpretation before leaders assign a remedy.
Record the selected action, owner, expected observable change, and review event. “Improve adoption” is too broad. “Test the revised exception route and check whether the next reviewer receives complete evidence” gives the team a result it can examine.
Keep reporting safe. If a rising workaround count automatically triggers criticism, people may stop disclosing workarounds. Explain how the information will be used and recognize appropriate escalation. A temporary increase in reported friction can reflect better visibility rather than worse performance.
Retire measures that no longer inform a decision. Once a task is stable, a lighter operating check may be sufficient. Preserve attention for new roles, changed processes, consequential exceptions, and recurring sources of rework.
Start with one business task that attracts repeated complaints. Define acceptable completion, inspect a few completed and failed cases, and choose one quality measure and one friction measure. The resulting conversation will show more about real adoption than another report of who logged in.
