Which ERP Requirements Matter Most? Separate essential needs from improvements that can wait.
Prioritize ERP requirements by describing what would happen if each need went unmet, then testing whether the business could operate acceptably another way. The result should identify genuine release blockers, bounded temporary arrangements, and improvements that can wait. A popularity vote cannot make those distinctions reliably.
This is especially useful when every department has submitted a long list of “must-haves.” The selection team needs to understand the consequence behind each label before it compares solutions. Otherwise, a familiar screen can receive the same priority as a control that prevents an unauthorized transaction.
The working method below is CuriousRubik’s proposed approach to that decision. It combines a requirement triage card with an evidence trail that survives selection, design, and testing. It is a practical aid to judgment, rather than a validated scoring standard.
Begin with the event that needs to work
A requirement such as “flexible approval workflow” leaves too much room for interpretation. It does not identify the transaction, the person making the decision, or the unacceptable outcome.
Write a requirement using this pattern:
“When [business event] occurs under [relevant conditions], [authorized role] must be able to [observable action], producing [evidence or outcome], while preventing [unacceptable result].”
For example, consider this hypothetical requirement: “When a buyer changes an approved order beyond the organization’s approved tolerance, the order must return to the designated approver before it is released, and the change and approval must remain traceable.”
That statement can be challenged and tested. The organization still needs to define the tolerance, affected order types, exceptions, and retention requirements. Those decisions belong to its process and control owners. They should not emerge accidentally from whichever configuration appears first in a demonstration.
Keep the need separate from the proposed mechanism. “Prevent unauthorized release” is the need. A particular button, message, or approval-screen layout is one possible mechanism. Preserving that distinction allows the team to accept a better process without pretending the underlying requirement has disappeared.
Ask five consequence questions
Discuss each contested requirement with the person accountable for the affected operation. Use evidence from transaction samples, exception logs, operating procedures, or policy requirements where available.
- What fails? Describe the specific operational, financial, customer, safety, or control consequence. “Users will be unhappy” needs further investigation; “the dispatch team cannot identify which orders are authorized for release” is actionable.
- Who encounters the failure, and when? Identify the role, location, transaction type, operating period, and downstream recipient. A requirement used infrequently may still be critical at a period end or during an exceptional event.
- Can the business detect the failure in time? A visible exception that stops a transaction is different from a silent error that reaches customers or financial reporting before anyone notices.
- Can an alternative contain the consequence? Describe the actual people, permissions, evidence, capacity, and checks required. “Handle it manually” is an unanswered question.
- How reversible is the decision? Consider whether deferral creates data that cannot be reconstructed, obligations that cannot readily be undone, or a design that becomes expensive to change.
Do not collapse these answers into a single score too early. Multiplying subjective severity and frequency ratings can make a rare but unacceptable event look harmless. First identify constraints that require a separate decision. Rank tradeable improvements afterward.
Separate four decision states
Use explicit states instead of a single crowded priority column.
Release blocker. The proposed release cannot proceed acceptably without the outcome, and no approved alternative currently contains the consequence. Record the affected release and approving authority. A blocker for one location may not block a different release boundary.
Controlled temporary workaround. The outcome can be maintained for a defined period through an approved arrangement. Record its workload limit, control evidence, owner, expiry condition, and replacement plan. This state is conditional, not a softer name for an unresolved blocker.
Planned enhancement. The need has a meaningful benefit, but the current operating approach remains acceptable within the agreed release scope. Give it a business owner and a future decision point. Avoid promising a delivery date without capacity and funding.
Preference. The request concerns convenience or presentation, and no material consequence has been demonstrated. Preserve the request and its reasoning. New evidence may justify a different classification later.
Classifications should be revisited when the release boundary, transaction volume, operating policy, or evidence changes. A workaround suitable for one team can become unacceptable when additional sites join. A preference can become an accessibility requirement when the relevant user need is understood. The label records the current decision; it does not establish a permanent truth.
Complete a requirement triage card
Use one card for each disputed need. Keep the answers concise enough for a decision meeting.
- Requirement ID and version: ______
- Business event, role, location, and release: ______
- Observable outcome and prohibited result: ______
- Consequence if unmet, including downstream effects: ______
- Evidence supporting that consequence: ______
- Applicable policy, contractual, or regulatory constraint and reviewer: ______
- Frequency or exposure, including peak and exceptional conditions: ______
- Alternative process, staffing, capacity limit, and residual risk: ______
- Detection method and recovery effort: ______
- Cost or difficulty of changing the decision later: ______
- Proposed state and accountable decision maker: ______
- Missing evidence, next action, owner, and decision date: ______
The card’s most important field is often “missing evidence.” An unknown should remain visible. It should not become a low priority because nobody has measured it, or a blocker simply because someone described it forcefully.
For a claimed legal or regulatory necessity, ask the qualified owner to identify the applicable obligation and the outcome it requires. The selection team should not independently reinterpret legal requirements or assume that one particular screen is mandated.
Test a workaround as seriously as a feature
Imagine a hypothetical distributor evaluating approval of changed purchase orders. One department proposes a daily report for reviewing changes after release. Another insists on preventing release until approval is complete.
The key question is when the consequence occurs. If a released order creates a commitment that the company cannot readily reverse, next-day detection may fail the requirement even when the report is complete. An attractive reporting feature does not resolve a preventive-control need.
A different alternative might hold the affected orders in a controlled queue. An authorized reviewer checks each one, records the approval, and releases it. Before accepting that arrangement, the team would need to establish who can bypass the queue, how absence is covered, how urgent orders are handled, and how the queue’s completeness is checked.
It would also need a volume boundary. The business owner could use representative transaction samples to estimate the review effort, then rehearse the process during a peak condition. The acceptable limit must come from the organization’s service and control requirements, not an invented industry benchmark.
If the arrangement is accepted, the decision should state the conditions under which it remains acceptable. For example: only the specified transaction population uses it; a named backup covers the reviewer; exceptions are checked at an agreed operating interval; and expansion to another site requires reassessment. Without these conditions, the team has approved an idea rather than an operating arrangement.
Resolve conflicts by examining the tradeoff
Some disagreements reflect genuinely competing outcomes. A sales team may value immediate release while a credit team requires a hold. Asking the teams to average their scores obscures the conflict.
Instead, have the facilitator write both consequences in the same decision record. Identify the shared business event, the information available at that moment, and the person with authority to accept the residual risk. Test options against both outcomes, including an exception route where appropriate.
Escalate only the unresolved choice. The executive sponsor should receive the alternatives, supporting evidence, operating impact, and consequences of delay. “Departments disagree” is too vague to support a decision.
Document dissent when a knowledgeable owner believes the chosen approach remains unsafe or unworkable. The decision maker may choose a different course, but the concern, response, and follow-up evidence should survive the meeting. Agreement that a decision was made is different from evidence that every concern was resolved.
Keep the evidence connected through delivery
Priority loses value if it disappears after selection. Give the requirement a stable identifier and link it to five records:
- Business need: the outcome, consequence, and accountable owner
- Scenario: the starting conditions and exception that reveal the need
- Demonstration evidence: what was actually observed and what remains unproven
- Design decision: the adopted process, configuration, integration, or accepted alternative
- Acceptance test: the evidence required before the release owner can accept the outcome
For the changed-order example, the demonstration might show an approval route but not a change after partial receipt. That gap should become a follow-up scenario, then a design question, then an acceptance test. It should not vanish because the broad requirement received a “supported” response.
Keep proof and priority separate. A requirement can be critical while its proposed solution remains unproven. Conversely, a beautifully demonstrated feature can remain low priority. Changing the priority to match available capability hides a business decision that deserves explicit approval.
Use three checks before closing prioritization
First, read only the release blockers. Can each owner explain the consequence, the supporting evidence, and why an alternative is unacceptable? Investigate vague answers.
Second, read only the temporary workarounds. Is someone funded and equipped to run each one? Does each have an operating limit and a retirement trigger? A list of unstaffed workarounds is unfinished scope.
Third, sample the enhancements and preferences. Did a quiet team’s material need get deferred without understanding it? Did a prominent stakeholder’s preferred mechanism become mandatory without justification?
The output should be a release decision the business can defend. Start with one disputed requirement, complete the triage card, and follow its evidence through a real scenario. If that conversation becomes more precise, the method is doing useful work.
