A decision algorithm for selecting enterprise software

The core decision

For “A decision algorithm for selecting enterprise software”, define the outcome as a change in management practice. The central object is decisions and role authority; it needs an agreed source, decision owner and observable state after the action “describe mandatory scenarios”.

The first evidence is not a solution presentation but a reproducible example of “requirements disconnected from a decision”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

Role of the Financial Strategy Forum source

The Financial Strategy Forum programme lists Maxim Kantarovich as a speaker on software selection. It supports his role in the programme but does not turn the event page into an authored article.

The selection algorithm includes gating criteria, controlled scenarios, a shared dataset, integration assessment, operating model and decision record.

Diagnosis before solution selection

Diagnosis examines a concrete episode involving the baseline process and its exceptions. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “unprepared data and roles” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Management signal 1: Different business and IT expectations. Use condition: a link to an actual example and to the baseline process and its exceptions.
• Diagnosis records “requirements disconnected from a decision”, its recurrence and its impact on decisions and role authority.
• Observation 3: Acceptance based only on an interface demonstration. Required fields: frequency, source and consequence for the release or pilot scope.

Gating criteria and verification

The method is a sequence of decisions rather than a universal checklist. For decisions and role authority, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For the baseline process and its exceptions, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “describe mandatory scenarios”.

• At position 1, the action is “describe mandatory scenarios”; its result is the baseline process and its exceptions.
• Stage 2: separate gating criteria from preferences. The working artefact describes decisions and role authority.
• Stage gate 3 connects the action “prepare one shared demonstration dataset” with the result “the release or pilot scope”.
• 4. Action: assess integrations and operations; verifiable result: user-readiness criteria.

From signal to decision

The article addresses “A decision algorithm for selecting enterprise software”. The adjacent management issue is decisions and role authority. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “unprepared data and roles”, the material risk is “a pilot using unrepresentative data”, and the testable action is “prepare one shared demonstration dataset”. This chain turns a broad term into a concrete decision.

• Decision 1: object — the baseline process and its exceptions; signal — different business and IT expectations; action — describe mandatory scenarios.
• Decision 2: object — decisions and role authority; signal — requirements disconnected from a decision; action — separate gating criteria from preferences.
• Decision 3: object — the release or pilot scope; signal — acceptance based only on an interface demonstration; action — prepare one shared demonstration dataset.

Objects under management

The subject model starts with two reference objects: the baseline process and its exceptions and decisions and role authority. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “prepare one shared demonstration dataset”.

The primary boundary is the baseline process and its exceptions. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Object 1: The baseline process and its exceptions. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Different business and IT expectations.
• Subject area 2: Decisions and role authority. Verification basis: system of record, owner authority and the signal “requirements disconnected from a decision”.
• Record 3. Object: The release or pilot scope. Required details: identifier, lineage, quality rule and update event. Signal: Acceptance based only on an interface demonstration.

Integration contract

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is decisions and role authority.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “requirements disconnected from a decision”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Boundary 5. Object: The outcome of the end-to-end scenario. Define the source, frequency, permitted transformations and response to “change without a durable owner”.
• Control record 4. Object: User-readiness criteria. Observable signal: Unprepared data and roles. Accountability: semantic owner and quality owner.
• Record 3. Object: The release or pilot scope. Required details: identifier, lineage, quality rule and update event. Signal: Acceptance based only on an interface demonstration.

End-to-end outcome test

The acceptance criterion for the release or pilot scope includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “unprepared data and roles”, passes through an authorised decision and “prepare one shared demonstration dataset”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Control record 1: The baseline process and its exceptions; data version, calculation rule, expected change and actual outcome. Signal: Acceptance based only on an interface demonstration.
• Criterion 2 uses decisions and role authority; the result is compared with the baseline using one method. Signal: Unprepared data and roles.
• Criterion 3: The release or pilot scope; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Change without a durable owner.
• Criterion 4. Object: User-readiness criteria. Test fields: baseline, target change, source and owner. Signal: Different business and IT expectations.

Authority and escalation

Build the authority matrix around decisions concerning the release or pilot scope. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “describe mandatory scenarios” concerning the release or pilot scope in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Role: Business owner. Decision object: the baseline process and its exceptions; verified step: separate gating criteria from preferences.
• Architect decides within decisions and role authority; the basis is prepared through “prepare one shared demonstration dataset”.
• For the release or pilot scope, the assigned role is Data owner; its control duty is to assess integrations and operations.
• Project manager: authority is linked to user-readiness criteria, and participation is tied to “record the decision and assumptions”.

Constraints and risk control

The risk map starts with two conditions: “a pilot using unrepresentative data” and “scaling before stabilisation”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “scaling before stabilisation” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• For the risk “scope growth without schedule review”, assign the action “describe mandatory scenarios” and evidence “the release or pilot scope” in advance.
• Risk review starts with the condition “formal training without a process change”. The decision uses the action “separate gating criteria from preferences” and data about user-readiness criteria.
• Risk record 3. Condition: A pilot using unrepresentative data. Control action: Prepare one shared demonstration dataset. Evidence source: The outcome of the end-to-end scenario.
• Risk: Accepting a feature instead of an outcome. Control: assess integrations and operations. Evidence: the baseline process and its exceptions.

First working session

The first working session on the baseline process and its exceptions uses real material: a transaction example, report or plan, systems diagram, role list and the variance “requirements disconnected from a decision”. Participants select one scenario, identify data gaps and perform the action “describe mandatory scenarios”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “a pilot using unrepresentative data” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• At position 1, the action is “describe mandatory scenarios”; its result is the baseline process and its exceptions.
• Stage 2: separate gating criteria from preferences. The working artefact describes decisions and role authority.
• Criterion 4. Object: User-readiness criteria. Test fields: baseline, target change, source and owner. Signal: Different business and IT expectations.
• 5. Acceptance object: the outcome of the end-to-end scenario; compare the baseline sample, expected change and confirmed actuals. Test signal: Requirements disconnected from a decision.