ERP without target architecture: the main risks

Management challenge

Without architecture, ERP often automates historical workarounds: unclear roles, duplicate master data, inconsistent accounting rules and manual approvals.

When the problem becomes visible

• Users maintain parallel spreadsheets
• Master data deteriorates quickly
• Approvals depend on personal arrangements

How to design the solution

This approach keeps the discussion focused on management control rather than only on system functions.

• Define target processes
• Assign data owners
• Set master-data and integration rules
• Test management scenarios

Common mistakes

The most common mistakes appear when a team trades architecture quality for launch speed.

These mistakes may be hidden during a demonstration but become visible in production operation.

• Copy the old process into the new system
• Discuss only interface functions
• Postpone procedures and roles

Key takeaways

• ERP does not replace management architecture.
• Methodology precedes configuration.
• Master-data quality determines reporting quality.
• Acceptance should use business scenarios.

The decision in two paragraphs

Architecture should show which decision each component supports, which data it exchanges, who owns the interface and what happens when it changes or fails. An application diagram alone is insufficient. For this task, the initial evidence is “unclear historical-data scope”, and the decision boundary concerns master data and identifiers.

The practical focus is the integrity of the transactional core, master data, integrations and system transition. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is integration messages.

Applied analysis: ERP without target architecture: the main risks

The question “ERP without target architecture: the main risks” first requires agreement on the meaning of balances, commitments and open transactions. Different definitions produce different data, requirements and outcome assessments even when one system is used.

Use “unclear historical-data scope” as the scenario input and “map applications and data” as the testable response. Preserve the source, time and data version in the record.

Test the action “identify critical dependencies” in the operating environment connected to master data and identifiers. Separately document exception authority, escalation and evidence of execution.

• Working object: Master data and identifiers.
• Diagnostic signal: Unclear historical-data scope.
• Response action: Map applications and data.
• Controlled risk: Go-live with unresolved critical defects.

What belongs in scope

Describe the boundary through object records rather than system names. For master data and identifiers, record meaning, identifier, source, quality owner and update event; for balances, commitments and open transactions, also document the relationship rule.

Test the link between master data and identifiers and balances, commitments and open transactions using an end-to-end example. The team performs “identify critical dependencies”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Subject area 1: Financial and material documents. Verification basis: system of record, owner authority and the signal “different accounting rules across units”.
• Record 2. Object: Master data and identifiers. Required details: identifier, lineage, quality rule and update event. Signal: Critical operations without a rollback scenario.
• Control record 3. Object: Balances, commitments and open transactions. Observable signal: Misaligned master data. Accountability: semantic owner and quality owner.

Record lineage

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 balances, commitments and open transactions.

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 “unclear historical-data scope”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Object 5: Control reports and period close. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Unclear historical-data scope.
• Boundary 4. Object: Integration messages. Define the source, frequency, permitted transformations and response to “manual cross-system reconciliations”.
• Control record 3. Object: Balances, commitments and open transactions. Observable signal: Misaligned master data. Accountability: semantic owner and quality owner.

Services and critical dependencies

The method is a sequence of decisions rather than a universal checklist. For balances, commitments and open transactions, 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 master data and identifiers, 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 “map applications and data”.

• Decision 1: describe business services. The basis for the next step is integration messages.
• Step 2. Map applications and data. Output: control reports and period close.
• Record interfaces and owners is the action at stage 3. The output documents financial and material documents.
• At position 4, the action is “identify critical dependencies”; its result is master data and identifiers.

The decision point to resolve

The article addresses “ERP without target architecture: the main risks”. The adjacent management issue is the main risks. 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 “critical operations without a rollback scenario”, the material risk is “go-live with unresolved critical defects”, and the testable action is “identify critical dependencies”. This chain turns a broad term into a concrete decision.

• Decision 1: object — financial and material documents; signal — manual cross-system reconciliations; action — map applications and data.
• Decision 2: object — master data and identifiers; signal — unclear historical-data scope; action — record interfaces and owners.
• Decision 3: object — balances, commitments and open transactions; signal — different accounting rules across units; action — identify critical dependencies.

Starting situation and evidence

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

Review the signal “critical operations without a rollback scenario” 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.

• Diagnosis records “misaligned master data”, its recurrence and its impact on integration messages.
• Observation 2: Manual cross-system reconciliations. Required fields: frequency, source and consequence for control reports and period close.
• Signal: Unclear historical-data scope. Evidence includes an example, frequency and consequence for financial and material documents.

Process and data owners

Build the authority matrix around decisions concerning integration messages. 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 “map applications and data” concerning integration messages 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.

• In the decision matrix, business owner connects integration messages with the action “design target transitions”.
• Architect: decision area — control reports and period close; control action — describe business services.
• Data owner is accountable for financial and material documents and confirms the action “map applications and data”.
• Role: Project manager. Decision object: master data and identifiers; verified step: record interfaces and owners.

Baseline and actual outcome

The acceptance criterion for integration messages 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 “critical operations without a rollback scenario”, passes through an authorised decision and “identify critical dependencies”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1. Object: Financial and material documents. Test fields: baseline, target change, source and owner. Signal: Misaligned master data.
• 2. Acceptance object: master data and identifiers; compare the baseline sample, expected change and confirmed actuals. Test signal: Manual cross-system reconciliations.
• Evidence item 3 describes balances, commitments and open transactions, comparable test conditions and the person accountable for interpretation. Signal: Unclear historical-data scope.
• Test 4 concerns integration messages. The method, interpretation owner and outcome source are documented. Signal: Different accounting rules across units.

Assumptions, stop signals and rollback

The risk map starts with two conditions: “go-live with unresolved critical defects” and “copying legacy errors into the new system”. 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 “copying legacy errors into the new system” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Risk review starts with the condition “copying legacy errors into the new system”. The decision uses the action “identify critical dependencies” and data about financial and material documents.
• Risk record 2. Condition: Migration without control totals. Control action: Design target transitions. Evidence source: Master data and identifiers.
• Risk: Untested integration compatibility. Control: describe business services. Evidence: balances, commitments and open transactions.
• Risk condition 4: Go-live with unresolved critical defects. Response: Map applications and data. Testable evidence: Integration messages.

Initial working cycle

The first working session on master data and identifiers uses real material: a transaction example, report or plan, systems diagram, role list and the variance “unclear historical-data scope”. Participants select one scenario, identify data gaps and perform the action “map applications and data”.

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

• Decision 1: describe business services. The basis for the next step is integration messages.
• Step 2. Map applications and data. Output: control reports and period close.
• Test 4 concerns integration messages. The method, interpretation owner and outcome source are documented. Signal: Different accounting rules across units.
• Control record 5: Control reports and period close; data version, calculation rule, expected change and actual outcome. Signal: Critical operations without a rollback scenario.