How Does Digital Transformation Consulting Build a Shared Technology Architecture for Multi-Company Groups?

Why do group companies need a shared architecture?

Group companies need a shared architecture because, even when subsidiaries run separate operations, they remain interdependent in areas such as data, finance, customers, identity, reporting, and management decisions. Independent technology investments may provide short-term flexibility, but without shared standards they can increase integration effort, data inconsistency, and governance complexity. Transformation should therefore make group-wide dependencies visible before attempting to standardize individual applications.

How does a technology inventory change transformation decisions?

The first step is not merely listing software products. The assessment should document which processes each application supports, what data it creates, which systems it exchanges data with, and who owns it technically and operationally. This extends how the digital transformation consulting process is planned to the group level and reveals critical dependencies. Management can then decide whether to retain or replace a system based on business value and architectural role rather than its product name.

• The process scope of ERP, CRM, DMS, BI, and custom applications should be identified.
• Data exchanges and manual transfers between systems should be mapped.
• Application, data, and process owners should be defined separately.
• Duplicated capabilities should be distinguished from company-specific requirements.
• Technical debt, integration dependency, and operational criticality should be assessed together.

The art challenges the technology, and the technology inspires the art. - John Lasseter

Which systems should be shared and which stay independent?

A system should be shared based not simply on whether multiple companies use it, but on process standardization, data integrity, security, and potential economies of scale. Group finance, identity management, consolidated reporting, or core data dictionaries may suit centralized management, while operations specific to an industry, production model, or competitive advantage may remain independent. The right target is not one system, but the right degree of sharing.

How should centralized and company-specific layers be separated?

The decision matrix should consider process similarity, regulatory or industry differences, data-sharing needs, integration intensity, and frequency of change. Two companies, for example, may not need the same ERP product, but they should have common rules governing how account, customer, product, or organizational data reaches group reporting. This turns enterprise system consolidation from mandatory product standardization into controlled architectural standardization.

• Capabilities requiring group-wide policy are candidates for centralization.
• Distinctive processes that create competitive advantage may remain at company level.
• Systems using shared data should follow centrally defined data definitions.
• Local applications should comply with integration and security standards.
• Consolidation decisions should consider licensing, operations, and transition impacts together.

How can different ERP and CRM systems share common data?

Different ERP and CRM systems can connect to a shared data architecture without converting every company to the same product, provided that the data model, master-data rules, integration contracts, and system responsibilities are explicitly defined. Integrations built before determining which application is authoritative for each data domain can create duplicate definitions of the same customer or product and produce inconsistent reporting.

What do a shared data layer and API management provide?

A group architecture may combine API management, event-driven integration, data warehouses, or lakehouse patterns according to the requirement. The goal is not to place every piece of data in one location, but to control where data originates and under what rules it is consumed. When planning enterprise software integration with ERP and CRM, system contracts, error handling, and data synchronization therefore need to be treated as architectural concerns rather than implementation details.

• A shared data dictionary should define critical business concepts consistently.
• An authoritative source and responsible system should be assigned to each master-data domain.
• API and integration contracts should follow versionable standards.
• Synchronization failures should be observable and capable of being reprocessed.
• Group reporting should be designed to preserve data lineage.

Where should centralized technology standards be established?

Centralized technology standards should be established first around architectural principles, security, identity, data, integration, observability, and lifecycle management rather than around product names. This gives every new company or application joining the group a clear set of requirements regardless of the technology brand it uses. The purpose of standards is not to remove team autonomy, but to create secure and sustainable interoperability across systems.

What is the difference between a standard and a technology mandate?

A standard can define how API authentication, logging, data classification, or access control must work. A technology mandate restricts that requirement to one product. If group companies vary significantly in scale and operating needs, enforcing one product at every layer can create unnecessary dependency. Shared security and integration principles, by contrast, can allow different products to operate within a manageable architecture while still satisfying group-level controls.

• Group-wide principles should govern identity and access management.
• API security, versioning, and monitoring standards should be shared.
• Data classification and retention rules should follow corporate policy.
• Minimum logging, observability, and incident-management requirements should be defined.
• New technology selections should undergo architectural conformity review.

How should group and company responsibilities be divided?

In a transformation program, the group level should manage target architecture, shared standards, common platforms, and portfolio priorities, while individual companies retain ownership of operational requirements, processes, and local applications. Without a written division of responsibilities, the central team can become a bottleneck that owns every decision, or subsidiaries can make independent investments that undermine the shared architecture. The governance model should explicitly distribute decision rights.

Which decision mechanisms should the governance model include?

An architecture board, data governance board, program management function, and company process owners should approach the same transformation from different levels. The model should define which decisions each body makes, which thresholds require approval, and how exceptions are handled. When assessing how a proposed transformation roadmap should be tested, decision mechanisms should also be examined to determine whether they translate into concrete deliverables.

• Group management should own shared architectural principles.
• Companies should own process requirements and operational acceptance.
• Data owners should be accountable for quality, definitions, and access rules.
• Architectural exceptions should be managed with documented reasons and time limits.
• The program office should track dependencies, risks, and cross-phase decisions.

In what sequence should the transformation program be phased?

The transformation program should be phased in an order that reduces dependencies and creates a shared foundation for later investments rather than simply replacing the most visible system first. Starting ERP consolidation or a group-wide platform investment before completing the inventory and target architecture can cause the scope to change continuously during implementation. Phasing should consider business value, risk, technical dependencies, data readiness, and organizational capacity together.

Can prioritization be based only on investment size?

No. A seemingly modest integration may resolve a critical master-data problem and accelerate several projects, while a large ERP program may delay expected benefits if data and process standards are not ready. The roadmap should therefore balance quick wins with foundational architectural investments. Each phase should clearly state its entry conditions, dependencies, acceptance criteria, and the capabilities it enables for the next phase.

• The first phase should clarify the current process and application landscape.
• Target architecture and shared data principles should precede major investment decisions.
• Highly dependent projects should begin after their required foundations are ready.
• Pilots should test the governance model as well as the technology.
• Each phase should close against measurable acceptance criteria.

What deliverables should a consulting provider produce?

A consulting provider should be expected to deliver more than a general digital transformation presentation; it should produce actionable architecture and governance outputs that support real decisions. The current-state inventory, target architecture, system rationalization, data model, integration principles, security approach, governance model, and phased roadmap should form a coherent set. A deliverable creates value when it becomes a concrete input to the next technology investment decision.

How can the proposal scope be made verifiable?

The proposal should describe each deliverable's scope, source information, participants, decision method, and acceptance criteria. A scope that only counts workshops or analysis days may not show which architectural decisions will exist at the end of the engagement. The provider should be capable of addressing ERP, CRM, integration, data, and organizational governance together. When evaluating firms, digital transformation consulting firm selection criteria should be reviewed alongside the technical deliverables.

• A current-state application and integration architecture should be delivered.
• The target technology and shared data architecture should be modeled explicitly.
• A decision matrix should support system consolidation choices.
• A governance model should define group and company responsibilities.
• The phased roadmap should include dependencies and acceptance criteria.
• Technical standards should be documented as actionable guidance.

How does shared architecture improve investment decisions?

A shared technology architecture allows group companies to manage technology investments as a coordinated portfolio rather than a series of isolated projects. Management gains clearer visibility into why a system should be retained, which integration should become a shared service, which data belongs in consolidated reporting, and which investments depend on others. Transformation budgets can therefore support sustainable enterprise capabilities rather than being directed only toward software acquisition.

What preparation should precede a consulting discussion?

Before the first discussion, the group should summarize its companies, major processes, critical applications, existing ERP and CRM environments, reporting problems, integration needs, and technology projects already underway. The inventory does not need to be perfect; its purpose is to help the consultant expose uncertainty through the right questions. Group management should also state which areas it wants to control centrally and which operational freedoms subsidiaries need to preserve. This framing helps establish the real scope of the enterprise transformation program and the consulting deliverables required.

• Group companies and their primary business models should be included in the initial scope.
• Critical systems and known integration problems should be summarized.
• Consolidated reporting and data requirements should be stated clearly.
• Ongoing technology investments and contractual dependencies should be disclosed.
• Decision makers and process owners should participate in the consulting engagement.