Choose applications through the operating model

Application selection is an organisational design decision as well as a technology decision. A system introduces assumptions about who owns information, who can approve work, and how exceptions move between teams. When those assumptions conflict with the intended operating model, configuration becomes a negotiation over unresolved business choices.

A department can reasonably prefer a product that makes its own work easier. The enterprise has to consider the full journey. A purchasing application, for example, affects more than buyers: receiving, quality, inventory, finance, and production may all depend on its records. Their requirements should be visible before a preferred supplier becomes difficult to challenge.

Test one complete journey

My BA 809 coursework reinforced the value of connecting capabilities with value streams. A capability describes an ability the business needs; a value stream helps explain how those abilities contribute to an outcome. In selection, that connection provides a practical way to move from a long feature list to a meaningful operating scenario.

I would choose a journey such as procuring material and making it available for use. Trace the ordinary case from request through approval, ordering, receipt, inspection, and availability. Then introduce a realistic exception: the delivered quantity differs, the item needs inspection, or an engineering change affects its suitability. Ask each supplier to show how the proposed system handles the whole sequence.

The demonstration should use agreed business definitions. What makes material available? Does arrival count, or must inspection and identification be complete? Which role may release it? If functions answer these questions differently, the selection has uncovered an organisational decision. A vendor should not settle that decision implicitly through its default settings.

The same approach reveals application and infrastructure dependencies. A mobile workflow may rely on connectivity at the point of work. A shared record may require an integration with an existing system. A promised approval process may depend on identity information that is not maintained consistently. These conditions belong in the evaluation and implementation plan.

Decide where consistency matters

Enterprise alignment does not require every team to work identically. Sites may have legitimate differences in products, customer requirements, or operating conditions. The design should distinguish common definitions and controls from justified local variation. Otherwise, standardisation can impose unnecessary constraints while customisation can reproduce every historical workaround.

I would ask the process owner to explain each material difference. Does it protect a real business requirement, reflect a temporary constraint, or preserve a preference that no longer serves the strategy? This conversation helps the organisation decide which variation the application must support and which should be addressed through process change.

Selection criteria should then reflect those decisions. Feature coverage matters alongside integration, information ownership, support, adaptability, and the effort required to operate the chosen process. The scoring should make significant trade-offs visible rather than hide them within a single total that gives every requirement equal importance.

Before a final commitment, the business owner should be able to describe the future workflow and the changes required to reach it. Employees need to understand their responsibilities, and the receiving teams need to accept the proposed handoffs. Technical fit is much easier to assess when those business arrangements are explicit.

The best application for an enterprise is the one that supports the way it has deliberately chosen to operate. A disciplined selection process helps leaders make that choice before the organisation has paid to encode its disagreements in software.