ERP Architecture and Technology Foundations

Introduction and Context

Enterprise resource planning (ERP) systems are integrated information platforms that coordinate transactions, master data, business processes, controls, and analytical information across an enterprise. Their value does not arise merely from installing a large software package. It arises from creating a dependable technological foundation through which finance, procurement, production, sales, logistics, human resources, service, and management can operate from consistent information and shared process rules.

ERP architecture describes how these capabilities are organized and connected. It includes data storage, application services, user interfaces, workflow engines, integration mechanisms, security controls, infrastructure, and external systems. For operations managers, architecture is not an exclusively technical concern. Architectural choices affect process standardization, planning speed, data quality, resilience, compliance, scalability, and the organization's ability to respond to supply-chain and market changes.

Modern ERP environments are rarely isolated suites. They interact with customer relationship management (CRM), supply-chain management (SCM), manufacturing execution systems (MES), product lifecycle management (PLM), Internet of Things (IoT) devices, banks, tax authorities, logistics providers, marketplaces, suppliers, and analytical platforms. Consequently, ERP architecture must be evaluated as an ecosystem rather than as a single application.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the principal layers and deployment patterns of ERP architecture.
2. Distinguish operational databases, analytical stores, master data, and transactional records.
3. Analyze workflows, APIs, middleware, event integration, and service-oriented architectures.
4. Compare on-premises, hosted, private-cloud, public-cloud, and hybrid ERP models.
5. Evaluate mobile access and ERP integration with CRM, SCM, MES, PLM, IoT, and external ecosystems.
6. Assess architectural decisions using criteria such as fit, scalability, security, resilience, interoperability, and total cost.
7. Identify governance, ethical, regulatory, and implementation risks in ERP technology decisions.

1. The Architectural Logic of an ERP System

An ERP system can be understood through six related layers:

These layers are logically distinct even when a commercial ERP product packages them together. A change in one layer can affect the others. For example, introducing mobile warehouse scanning changes the experience layer, but it also requires authorization controls, inventory transactions, barcode interpretation, network resilience, and potentially integration with a warehouse-management system.

A useful architectural principle is separation of concerns: presentation should not contain complex accounting rules; integration should not silently alter master data without governance; and analytical workloads should not degrade critical transactional processing. Separation does not mean that components are disconnected. It means that responsibilities and interfaces are explicit.

Integrated versus Best-of-Breed Architectures

An integrated suite provides common data models, standardized controls, and fewer interfaces. It can reduce reconciliation effort and simplify accountability. However, a suite may be less capable in a specialized domain than a best-of-breed application. A best-of-breed architecture combines products selected for particular capabilities, such as advanced planning, shop-floor control, or product design. Its potential advantages are functional depth and flexibility; its costs include interface complexity, duplicated data, inconsistent user experiences, and more difficult upgrades.

The strategic question is not whether one architecture is universally superior. It is whether the chosen boundaries reflect the enterprise's capabilities, risk tolerance, process differentiation, and integration maturity.

2. Databases, Data Models, and Information Quality

Transactional Data

ERP transactions record economically or operationally significant events: a sales order, goods receipt, invoice, production confirmation, payment, inventory movement, or employee time entry. Most core ERP systems rely on relational database management systems because relational structures support integrity constraints, transactions, concurrency control, and structured querying.

A database transaction should satisfy the ACID properties:

• Atomicity: all required changes occur, or none occur.
• Consistency: valid rules and constraints are preserved.
• Isolation: concurrent transactions do not produce unacceptable interference.
• Durability: committed changes survive an appropriate failure.

For example, posting a goods receipt may increase inventory, update an order status, create an accounting document, and record the responsible user. If only the inventory increase occurred, the enterprise would have an inconsistent state. Atomic transaction processing helps prevent this outcome.

Master, Reference, and Transaction Data

Master data describes relatively persistent business objects: materials, customers, suppliers, plants, work centers, employees, chart-of-accounts elements, and bills of material. Reference data supplies controlled values such as currencies, countries, units of measure, tax codes, and order statuses. Transaction data records events involving those objects.

Master-data quality is often more consequential than the sophistication of the database technology. A duplicated supplier, incorrect unit conversion, obsolete bill of material, or missing planning lead time can produce incorrect purchasing and production decisions while leaving the system technically available.

Important governance practices include:

• ownership of each data domain;
• controlled creation, modification, and retirement;
• validation rules and duplicate detection;
• effective dates and versioning;
• defined “system of record” responsibilities;
• monitoring of completeness, accuracy, timeliness, and consistency.

Operational and Analytical Data

Operational databases are optimized for frequent inserts and updates with strong consistency. Analytical platforms are optimized for aggregation, historical analysis, and combining data from multiple sources. A data warehouse commonly uses dimensional structures such as facts and dimensions, while a data lake may retain large volumes of semi-structured or unstructured data.

Separating analytical workloads from mission-critical transaction processing can improve performance and stability. However, extraction, transformation, and loading processes introduce latency and reconciliation questions. Near-real-time replication reduces latency but increases design, cost, and governance requirements. Managers should therefore define the required decision latency rather than assume that every report must be real time.

3. Application Layers and Business Logic

ERP application services translate organizational policies into executable rules. Typical services include order management, inventory management, procurement, production planning, costing, asset management, human capital management, and financial accounting.

Business logic may include:

• pricing and discount determination;
• credit and exposure checks;
• available-to-promise calculations;
• material requirements planning;
• tax and statutory rules;
• approval thresholds;
• segregation-of-duties restrictions;
• posting and period-closing controls.

A three-tier model separates presentation, application, and data services. In a multi-tier model, additional services may include identity, workflow, integration, reporting, and notification. The separation supports maintainability and scaling, but it also introduces network dependencies and operational monitoring requirements.

Configuration, Extension, and Customization

Configuration uses capabilities provided by the ERP product, such as organizational structures, document types, tolerances, and approval rules. Extensions add functionality through supported mechanisms, such as add-ons, low-code services, or APIs. Customization changes the core product code.

A disciplined preference is usually: configure where the process is generic, extend where differentiation is genuine and stable, and customize the core only when legal, operational, or strategic necessity justifies the long-term cost. Excessive customization can make upgrades expensive, complicate testing, increase security exposure, and preserve inefficient legacy practices.

4. Workflows and Process Orchestration

A workflow is a defined sequence or network of activities through which work, information, and decisions move. ERP workflows can be human-centered, system-centered, or hybrid. A purchase requisition may be automatically checked, routed to a budget owner, escalated when overdue, converted into a purchase order, and matched with a receipt and invoice.

Workflows commonly contain:

• events that initiate processing;
• activities performed by people or systems;
• gateways that apply conditions;
• roles and authorization rules;
• timers, escalations, and exception paths;
• audit trails and completion criteria.

The most important design distinction is between the happy path and exception management. A workflow that works only when data are complete and suppliers are punctual is operationally weak. Exceptions should be modeled explicitly: partial delivery, quantity variance, price variance, failed credit check, machine stoppage, or missing approval.

Business process management (BPM) treats workflows as objects that can be designed, measured, improved, and governed. Process mining can reconstruct actual process paths from event logs. If a purchasing process frequently bypasses approval or repeatedly returns invoices for correction, process-mining evidence can reveal the gap between the designed process and the enacted process.

Workflow automation should not eliminate judgment indiscriminately. Automation of a low-risk, repetitive activity may improve speed and control; automation of a high-impact decision may require explainability, human review, and documented accountability.

5. APIs, Middleware, and Integration Patterns

An application programming interface (API) defines how one system requests data or services from another. Common API styles include RESTful interfaces using HTTP and JSON, SOAP services using structured XML messaging, GraphQL interfaces for client-specified data queries, and event interfaces that publish notifications when something happens.

An effective API contract specifies authentication, authorization, data structures, required and optional fields, error handling, versioning, rate limits, idempotency, and service-level expectations. Idempotency means that repeating the same request does not create an unintended duplicate effect. It is essential when networks fail after a server has processed a request but before the client receives confirmation.

Integration patterns include:

Middleware provides mediation, transformation, routing, monitoring, retries, and security. Enterprise service buses historically emphasized centralized mediation. Contemporary integration platforms may combine API management, message queues, event streaming, workflow, and cloud connectors.

Point-to-point integration can be quick initially, but the number of connections can grow rapidly. If each of n systems connects directly to every other system, the maximum number of undirected connections is:

Here, C is the number of potential connections and n is the number of systems, assuming one connection per system pair. With six systems, C = 6 × 5 ÷ 2 = 15. This simple relationship illustrates why unmanaged integration becomes difficult as the ecosystem expands. In practice, not every pair requires a connection, and shared platforms can reduce the effective integration burden.

Integration failures are not merely technical failures. A delayed shipment event can cause incorrect customer promises; a duplicate invoice message can create financial risk; and a lost production confirmation can distort inventory and capacity information. Monitoring should therefore include business reconciliation, not only server availability.

6. Service-Oriented and Event-Driven Architectures

Service-oriented architecture (SOA) organizes capabilities as services with defined contracts. A service may expose customer validation, inventory availability, payment posting, or shipment status. Services are intended to be reusable and relatively independent of the consuming application.

Microservices are a more granular architectural style in which independently deployable services own specific business capabilities and often their own data stores. They can support rapid, independent release and targeted scaling, but they increase operational complexity, distributed transaction challenges, observability requirements, and the need for mature DevOps practices. Microservices are not automatically superior to a well-designed modular monolith.

Event-driven architecture (EDA) communicates through events such as “SalesOrderCreated,” “GoodsReceived,” or “MachineTemperatureExceeded.” Events represent facts that have occurred; commands request that something occur. EDA can reduce temporal coupling and allow multiple consumers to react independently. Its difficulties include eventual consistency, event ordering, duplicate delivery, schema evolution, replay management, and more complex troubleshooting.

A useful design decision is whether a business interaction requires an immediate authoritative response. If a customer must receive an immediate credit decision, synchronous processing may be appropriate. If several systems need to react to a completed shipment, publication of a shipment event may be more scalable. Hybrid designs are common.

7. Deployment and Cloud Models

ERP deployment choices include:

Cloud service responsibility is shared. The vendor may secure physical facilities, core infrastructure, and platform services, while the customer remains responsible for identities, configuration, data classification, user access, and lawful use. “Cloud” does not remove governance; it changes where responsibilities are located.

Relevant evaluation criteria include data residency, regulatory obligations, availability objectives, disaster recovery, exit portability, integration capability, customization policy, pricing transparency, and vendor financial stability. Service-level agreements should define measurable service commitments, maintenance windows, incident communication, recovery objectives, and remedies.

Two important continuity concepts are recovery point objective (RPO) and recovery time objective (RTO). RPO states the maximum tolerable amount of data loss measured in time; RTO states the target time to restore service. They are management requirements, not merely technical settings. A process requiring near-continuous production visibility may need a tighter RPO and RTO than a low-frequency administrative report.

8. Mobile Access and Edge Operations

Mobile ERP access supports field service, warehouse scanning, delivery confirmation, approvals, inventory counts, and production reporting. Mobile design must account for small screens, intermittent connectivity, device loss, battery limitations, camera and barcode functions, and the operational context in which users work.

A robust mobile solution should minimize data entry, provide role-specific views, validate input at the point of capture, and support safe offline behavior where necessary. Offline operation creates synchronization questions: which record is authoritative, how are conflicts resolved, and how are duplicate submissions prevented? A mobile application must not be treated as merely a smaller desktop interface.

Edge computing places processing or data collection close to machines, sensors, vehicles, or sites. It can reduce latency and maintain local operation during network disruption. The ERP remains a system of enterprise coordination, while edge and operational systems may execute time-sensitive control. A safety-critical machine-control loop should not depend on a distant ERP transaction completing successfully.

9. Integration with the Extended Enterprise

CRM

CRM integration connects customer, quotation, order, service, billing, and profitability information. It can provide a consistent view of customer commitments and reduce re-entry. However, customer identity, product catalogs, pricing, credit status, and consent preferences require explicit ownership and synchronization rules.

SCM

SCM integration links demand, sourcing, inventory, transportation, suppliers, and fulfillment. ERP often supplies authoritative orders and financial postings, while specialized SCM applications may provide advanced planning, network optimization, supplier collaboration, and transportation execution. Integration must distinguish planned quantities, firm orders, forecasts, and actual movements.

MES

MES manages detailed shop-floor execution, work instructions, dispatching, labor reporting, quality checks, and equipment status. ERP commonly supplies production orders, routings, and material requirements; MES returns confirmations, scrap, labor, quality, and completion data. The interface must preserve unit-of-measure, operation, lot, serial, and time relationships.

PLM

PLM governs product requirements, designs, engineering changes, configurations, and versions. ERP requires released and executable product structures, routings, and costing information. The integration challenge is lifecycle governance: an engineering design may be valid for development but not yet released for production.

IoT and Industrial Data

IoT devices generate sensor observations, machine states, location signals, and condition indicators. A common architecture filters and contextualizes high-frequency data at an edge or IoT platform, then sends business-relevant events or aggregates to ERP. Sending every raw sensor reading into the ERP database can create unnecessary volume and obscure the difference between physical observations and business transactions.

IoT integration creates cybersecurity and safety concerns because connected devices may be poorly patched, physically accessible, or connected to operational technology. Device identity, certificate management, network segmentation, least privilege, and secure update processes are essential.

External Ecosystems

Banks, tax platforms, customs authorities, carriers, marketplaces, suppliers, and contractors may exchange data through APIs, EDI, portals, or managed networks. External integration should address partner onboarding, legal authority, message non-repudiation where relevant, privacy, operational support, and fallback procedures. An ecosystem is resilient when the organization can detect, contain, and recover from a partner failure rather than assuming uninterrupted connectivity.

10. Security, Governance, and Responsible Use

ERP security protects confidentiality, integrity, availability, and accountability. Core controls include identity federation, multifactor authentication, role-based access, privileged-access management, encryption in transit and at rest, secure development, vulnerability management, logging, backup, and tested recovery.

Segregation of duties prevents incompatible responsibilities from being concentrated in one identity. For example, creating a supplier, approving a purchase, receiving goods, and releasing payment may require separation or compensating controls. Access should be reviewed periodically, especially after transfers and departures.

Governance should establish architecture principles, data ownership, integration standards, change control, exception approval, and lifecycle accountability. Regulatory concerns may include financial reporting, tax records, labor data, privacy, export controls, industry traceability, and records retention. The exact obligations depend on jurisdiction and sector; legal review is necessary rather than assuming that a generic ERP control is sufficient.

Artificial intelligence may assist forecasting, anomaly detection, invoice matching, service classification, or maintenance prediction. It introduces risks involving biased training data, opaque recommendations, privacy, model drift, automation bias, and accountability. AI outputs should be governed according to decision impact. High-impact recommendations require validation, traceability, human override, and monitoring of error patterns.

11. Architecture Evaluation and Implementation Practice

A graduate-level architecture assessment should combine technical and managerial analysis. Useful criteria include:

• business-process fit and differentiation;
• total cost of ownership and cost predictability;
• scalability and performance;
• resilience, RPO, and RTO;
• integration openness and data portability;
• security and regulatory compliance;
• upgradeability and technical debt;
• usability and adoption;
• vendor and ecosystem dependence;
• sustainability and energy implications.

Implementation should begin with business capabilities and critical value streams, not with a list of screens. The organization should identify authoritative data sources, process owners, non-negotiable controls, integration events, exception paths, and measurable outcomes. A phased approach can reduce risk, but temporary interfaces and transitional data models must have retirement plans.

Testing should include unit, integration, performance, security, migration, user acceptance, disaster recovery, and operational-readiness testing. Mock conversions and reconciliation are particularly important. A successful technical deployment can still fail if users do not understand new responsibilities, if master data are defective, or if performance is unacceptable at peak volume.

Applied Case: Northstar Components (Illustrative)

Background

Northstar Components, a fictional mid-sized industrial manufacturer, operates three plants, sells through direct channels and distributors, and uses separate legacy systems for finance, customer orders, production execution, and warehouse operations. Managers lack a consistent view of available inventory and production status.

Problem

Sales representatives promise delivery dates using spreadsheet estimates. Production confirmations arrive in batches, supplier changes are re-entered manually, and engineering changes are not always reflected in manufacturing bills of material. The organization experiences expediting, excess safety stock, invoice disputes, and weak traceability.

Analysis

The central problem is not simply that Northstar has old software. It has unclear data ownership and poorly designed integration. Customer orders, inventory balances, production status, and engineering versions have different sources of truth. Point-to-point interfaces have also created silent failures that are discovered only during reconciliation.

Approach and Solution

Northstar designs a modular ERP-centered architecture. ERP becomes authoritative for orders, inventory valuation, purchasing commitments, and financial postings. MES remains authoritative for detailed production execution and machine-level events. PLM controls engineering revisions and releases approved product structures to ERP and MES. A managed integration platform provides API management, message transformation, event monitoring, and reconciliation reports.

The organization introduces a common material identifier, effective-dated bills of material, and explicit event definitions. A released engineering change generates an event; the integration platform validates the revision and sends it to the appropriate manufacturing systems. Production completion events update ERP inventory and accounting, while high-frequency machine data remain in the IoT platform unless they create a business-relevant condition.

Mobile warehouse applications support barcode-based receiving and picking. Offline behavior is restricted to defined operations, with conflict rules and reconciliation queues. Access is role-based, and supplier creation is separated from payment approval.

Outcome

In the illustrative case, Northstar reduces manual re-entry and gains a consistent order-to-production view. The most important improvement is not a particular software feature but the explicit allocation of data authority, process responsibility, and integration monitoring. Management can now distinguish a genuine material shortage from a delayed message or unconfirmed production transaction.

Learning Points

1. Architecture should follow business capabilities and control requirements.
2. ERP, MES, PLM, and IoT systems can coexist when responsibilities are explicit.
3. Integration quality requires business reconciliation as well as technical monitoring.
4. Mobile and event-driven capabilities require careful treatment of offline behavior and duplicate messages.
5. Data governance is a prerequisite for reliable planning and reporting.

Challenges and Limitations

ERP architecture involves unavoidable trade-offs. Standardization may improve control but reduce local flexibility. Real-time integration may improve visibility but increase coupling and operating cost. Cloud SaaS may accelerate adoption but constrain deep customization. Microservices may enable independent release but demand advanced observability and platform engineering. Centralized data governance may improve consistency but slow local experimentation if decision rights are unclear.

Architectural diagrams can also mislead when they show systems but omit human work, exception handling, data semantics, and accountability. A technically elegant architecture can fail because incentives encourage workarounds. Architecture should therefore be assessed through actual process performance, user behavior, control evidence, and business outcomes.

Contemporary Developments

Current ERP environments increasingly use composable services, managed integration platforms, event streaming, embedded analytics, low-code extensions, digital twins, and AI-assisted operations. These developments can improve responsiveness, but they also increase the number of components and providers that must be governed. Organizations should avoid adopting novelty without a clear capability, risk, and lifecycle rationale.

A mature architecture is not the one with the greatest number of technologies. It is the one that makes important business facts trustworthy, enables appropriate decisions, protects stakeholders, and can evolve without uncontrolled complexity.

Chapter Summary

ERP architecture organizes user experience, applications, workflows, integration, data, infrastructure, and security into a coordinated operating platform. Relational transactional databases support integrity, while analytical stores support historical and cross-functional analysis. Master-data governance is essential because defective materials, suppliers, customers, and structures undermine every downstream process.

Workflows translate policies into controlled sequences of activities and must include exception paths. APIs, middleware, EDI, synchronous calls, batch transfers, and event-driven patterns provide different means of integration. SOA and microservices emphasize modular services, while event-driven architecture reduces temporal coupling but introduces eventual consistency and monitoring challenges.

Cloud, on-premises, hosted, and hybrid models differ in control, scalability, cost, responsibility, and portability. Mobile and edge computing extend ERP into warehouses, field operations, and factories but require careful offline and security design. CRM, SCM, MES, PLM, IoT, and external ecosystems should be integrated through explicit data ownership and business contracts.

Finally, architecture is a governance and operations-management decision. Security, segregation of duties, privacy, resilience, regulatory compliance, responsible AI, testing, adoption, and vendor dependence must be evaluated alongside functionality. The strongest ERP architecture is coherent, observable, secure, adaptable, and aligned with the enterprise's operating model.

Key Terms

ERP architecture: The organized structure of ERP layers, components, interfaces, data, and infrastructure.

Master data: Persistent data describing core business objects such as materials, customers, and suppliers.

Transactional data: Records of business events such as orders, receipts, invoices, and production confirmations.

ACID: Atomicity, consistency, isolation, and durability properties of reliable database transactions.

System of record: The authoritative source for a defined category of data.

Workflow: A controlled sequence of activities, decisions, roles, and exceptions.

API: A defined interface through which software requests data or services.

Middleware: Software that routes, transforms, monitors, and secures interactions among systems.

Idempotency: The property that repeating a request does not create an unintended additional effect.

SOA: An architecture that exposes reusable capabilities as contract-based services.

Microservices: Independently deployable services organized around relatively bounded business capabilities.

Event-driven architecture: An architecture in which systems communicate through events representing completed facts.

RPO: Recovery point objective, or the maximum tolerable data-loss interval.

RTO: Recovery time objective, or the target time for restoring service.

CRM: Customer relationship management system or capability.

SCM: Supply-chain management system or capability.

MES: Manufacturing execution system.

PLM: Product lifecycle management system or capability.

IoT: Internet of Things, involving connected devices and sensors.

Segregation of duties: A control separating incompatible responsibilities among roles or identities.

Review Questions

Short Answer Questions

1. What are the six principal layers commonly used to describe ERP architecture?
2. Why is master-data governance important to operational planning?
3. Distinguish a synchronous API call from an event-driven integration.
4. Define RPO and RTO.
5. Why should high-frequency IoT data not automatically be stored in the ERP database?

Long Answer Questions

1. Compare integrated-suite and best-of-breed ERP architectures, including their operational and governance implications.
2. Explain how ACID properties support reliable ERP transaction processing.
3. Analyze the benefits and risks of SOA, microservices, and event-driven architecture in an ERP ecosystem.
4. Compare on-premises, public-cloud SaaS, and hybrid ERP deployment models.
5. Explain how ERP should integrate with CRM, SCM, MES, PLM, and external partners while preserving data authority.

Analytical / Application Questions

1. An organization has eight systems and is considering direct point-to-point integration among all of them. Using C = n(n − 1) ÷ 2, calculate the maximum number of undirected system-pair connections and recommend an alternative integration strategy.
2. Design an architecture for a manufacturer that requires real-time machine alerts, controlled engineering revisions, financial inventory valuation, and mobile warehouse operations. Identify the system of record and integration pattern for each major information flow.
3. A cloud ERP provider offers rapid upgrades but restricts core customization and stores some data outside the organization's country. Develop a decision framework addressing process fit, regulatory risk, portability, security, resilience, and total cost.

Multiple Choice Questions with Answers

Question 1

Which ERP layer is primarily responsible for routing messages, transforming data, and connecting applications?

A. Experience layer

B. Integration layer

C. Data layer

D. Infrastructure layer

Correct Answer: B. Integration layer

Question 2

Which ACID property ensures that a committed database change survives an appropriate system failure?

A. Atomicity

B. Consistency

C. Isolation

D. Durability

Correct Answer: D. Durability

Question 3

Which statement best describes master data?

A. A temporary system error log

B. A record of every individual network packet

C. Persistent information about business objects such as materials and suppliers

D. Only historical financial statements

Correct Answer: C. Persistent information about business objects such as materials and suppliers

Question 4

What is the main purpose of idempotency in an API?

A. To encrypt every database field

B. To prevent repeated requests from creating unintended duplicate effects

C. To guarantee that every request is processed synchronously

D. To eliminate the need for authentication

Correct Answer: B. To prevent repeated requests from creating unintended duplicate effects

Question 5

Which integration pattern allows multiple consumers to react independently to a published business occurrence?

A. Publish-subscribe event integration

B. Manual spreadsheet transfer

C. Single-user batch entry

D. Point-in-time database deletion

Correct Answer: A. Publish-subscribe event integration

Question 6

A company has six systems. Under the simplified pair-connection assumption, how many potential undirected point-to-point connections exist?

A. 6

B. 12

C. 15

D. 36

Correct Answer: C. 15

Question 7

Which system is generally most closely associated with detailed shop-floor execution and machine-level production reporting?

A. CRM

B. MES

C. PLM

D. Accounts receivable

Correct Answer: B. MES

Question 8

What does RPO measure?

A. The maximum tolerable period of data loss measured in time

B. The number of users who can access a system

C. The target time to approve a purchase order

D. The average duration of a production cycle

Correct Answer: A. The maximum tolerable period of data loss measured in time

Question 9

Which is a principal risk of excessive ERP core customization?

A. Improved standard upgradeability

B. Reduced need for testing

C. Higher upgrade cost and technical debt

D. Automatic elimination of data-quality problems

Correct Answer: C. Higher upgrade cost and technical debt

Question 10

Why is segregation of duties used in ERP governance?

A. To concentrate all responsibilities in one expert user

B. To separate incompatible activities and reduce fraud or error risk

C. To remove the need for audit logs

D. To ensure that every process is performed manually

Correct Answer: B. To separate incompatible activities and reduce fraud or error risk