PRACTICAL GUIDE
Business software selection: turn requirements into a reviewable pilot
Build a shortlist around real work, mandatory constraints and responsible evaluators. Compare demonstrated behavior, full operating scope and unresolved requirements rather than relying on a feature score.
Write the problem before comparing suppliers
A useful selection brief describes a recurring situation, the people affected and the consequence of leaving it unchanged. It should not begin as a collection of preferred features. Separate what must work, what would help and what can wait. This gives the team a reason to reject an attractive demonstration that does not solve the actual problem.
Give each requirement an owner and a test
A requirement such as better collaboration is too broad to verify. Rewrite it as an observable action: the delivery lead finds the agreed customer scope and identifies the next responsible person. Name who will judge the result and what evidence is sufficient. Keep mandatory regional, financial, access or specialist requirements separate from preferences; a high overall impression should not cancel a failed essential condition.
- Write one acceptance action for every essential requirement.
- Use the person who performs the work as an evaluator.
Compare the proposed configuration, not a headline
Record the actual products, seats, enabled modules, usage limits and retained systems for each candidate. Include setup, data preparation, training and administration in the review. For Tsumira, confirm optional channel enablement and its current JPY and Japanese consumption-tax finance boundary. Do not treat a planned feature, an untested connector or an assumed local accounting capability as an available part of the offer.
- Separate available behavior from proposals and future plans.
- Keep unresolved dependencies visible in the shortlist.
Use a pilot to reduce a specific uncertainty
Choose one representative workflow and a small group. State who owns new information during the trial, what remains in the existing environment and how the team can stop. Include an ordinary disruption such as a changed request or an absent owner. Review the result against the initial requirements rather than expanding the scope to justify the effort already invested.
- Define the decision before starting the pilot.
- Record evidence, limits and the remaining operating work.
A concrete workflow
Prepare the selection brief
Describe the problem and classify essential needs, preferences and deferred work. Assign evaluators and acceptance actions.
Shortlist with equal cases
Request the same realistic workflow from each candidate. Compare the actual configuration and keep missing evidence explicitly marked.
Decide from the pilot
Review results with operational owners. Choose a bounded adoption, retained system or rejection based on the evidence and documented limits.
An illustrative working example
Illustrative scenario: three teams selecting one workflow
Sales wants clearer customer records, delivery wants understandable handovers and finance requires a specific local process. The shortlist uses one customer engagement and three separate acceptance tests. A candidate can perform well in customer delivery while still failing the financial requirement. The decision must retain or solve that process explicitly rather than averaging it away in a feature score.
Questions about this topic
Should the longest feature list win?
No. Features that are irrelevant to the chosen workflow do not resolve missing essentials. Focus the comparison on the demonstrated requirements, configuration and responsibilities that matter to the organization.
How many pilot users are necessary?
Choose enough real roles to test the handover and access boundary. The purpose is to resolve a defined uncertainty, not to maximize the number of accounts or pretend a small pilot proves every workflow.
Can planned features count in the decision?
Keep them separate from available behavior. A roadmap item can be discussed, but it does not satisfy an essential requirement until the needed implementation is available and verified.
What should the final decision record contain?
The scope adopted, evidence reviewed, failed or deferred requirements, retained systems and the people responsible. Include the assumptions that would require a new review if they change.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
