Digital Transformation is Not a Tooling Roadmap

\ A practical frameworkor engineering companies to choose the right direction before investing in PLM, ERP, MES, AI, or another platform. The failure usually starts with a seductive but weak question: What tool should we buy next? A new PLM platform, an ERP upgrade, a cloud migration, a data lake, an AI assistant, a new MES layer, a cybersecurity framework, a digital twin initiative. Each of these may be useful. None of them is, by itself, a transformation strategy. For engineering and manufacturing organisations, especially those operating in regulated or safety-critical environments, digital transformation must begin with a different question: What kind of company are we trying to become, and which digital capabilities are structurally necessary to get there? This question sounds simple. It is not. It requires leaders to connect business strategy, enterprise architecture, lifecycle management, governance, engineering change, safety assurance, cybersecurity, sourcing, and increasingly artificial intelligence into one coherent direction. The academic and professional literature gives us enough material to avoid improvising blindly. Digital transformation research explains why transformation is organisational rather than purely technological. Digital business strategy shows that digital capabilities reshape competitive positioning. Dynamic capabilities theory explains why firms must sense, seize, and reconfigure under uncertainty. IT governance, enterprise architecture, PLM, systems engineering, safety standards, cybersecurity frameworks, and AI risk management provide the control structures needed to make transformation durable. The problem is that these bodies of knowledge are often applied separately. Strategy teams talk about business models. IT teams talk about platforms. Engineering teams talk about configuration and traceability. Quality teams talk about evidence. Cybersecurity teams talk about controls. Executives ask for dashboards. Consultants propose roadmaps. The result is predictable: activity without direction. This article proposes a practical sequence for choosing the right digital transformation direction for an engineering company. It is written for organisations that do not want another fragmented programme, but a disciplined way to decide where to move next. 1. Start with strategic intent, not technology demand Digital transformation should begin with business strategy, but not in the abstract sense of vision statements and slogans. It should begin with the concrete logic of competitive advantage. Bharadwaj and colleagues argued that digital business strategy is not a subordinate IT strategy. It is an organisational strategy shaped by digital resources, digital scale, digital scope, and digital speed. Vial similarly described digital transformation as a process in which digital technologies trigger strategic responses that alter value creation paths. For engineering companies, this means transformation must be tied to the way the company competes. \ Each answer implies a different transformation direction. A company trying to reduce certification risk needs a different digital architecture from a company trying to optimise warehouse operations. A company scaling manufacturing needs a different roadmap from a company still trying to stabilise product requirements. A company operating in aerospace, nuclear, medical devices, or defence cannot copy the digital playbook of a consumer software firm without introducing unacceptable governance gaps. The first step is therefore to define the strategic problem in operational terms. A weak transformation statement says: “We need to implement AI and modernise our systems.” A stronger statement says: “We need to reduce engineering decision latency, strengthen requirements-to-evidence traceability, and create a governed digital thread that allows programmes to scale without losing certification control.” The second statement gives architecture a direction. 2. Diagnose the company’s capability gaps Once strategic intent is clear, the next task is to understand which capabilities are missing or immature. This is where dynamic capabilities theory becomes useful. Teece’s framework of sensing, seizing, and reconfiguring explains why firms survive technological and market shifts not simply by owning resources, but by renewing capabilities. In digital transformation, this matters because the question is not merely whether a system exists. The question is whether the organisation can continuously adapt its operating model, architecture, and governance as complexity changes. For an engineering company, the capability diagnosis should include at least six dimensions: This diagnosis should not be performed as a generic maturity survey. It should be tied to actual value streams. Follow a requirement from origin to design. Follow a change request from discovery to approval. Follow a defect from test to root cause. Follow a manufacturing non-conformance back to engineering decision-making. Follow a software change through verification and release. The truth of digital transformation is found in these flows, not in slide decks. 3. Map value streams before mapping systems Engineering organisations often map systems before they map work. This is backwards. A PLM system, an ALM system, an ERP system, an MES layer, a service management platform, a document control system, and a data platform only make sense when understood through the value streams they support. Lean thinking remains critical here. Digital transformation should not digitise waste. Many organisations automate approval chains, reporting structures, document templates, and reconciliation processes that should have been redesigned first. In regulated engineering, waste often hides behind respectable language. [ ] “Governance” may hide slow decision-making. [ ] “Compliance” may hide duplicated evidence creation. [ ] “Quality assurance” may hide poor upstream requirements. [ ] “Reporting” may hide untrusted source systems. [ ] “Cross-functional alignment” may hide unclear ownership. Mapping value streams exposes where the company loses time and control. It also reveals which digital capabilities are most valuable. For example: If engineering change is slow because impact analysis is manual, the priority may be traceability and configuration architecture, not a dashboard. If manufacturing readiness fails because design and production data are disconnected, the priority may be PLM–ERP–MES integration, not AI forecasting. If certification evidence is reconstructed after engineering work is complete, the priority may be evidence-by-design, not document automation. If teams constantly debate which data is correct, the priority may be master data governance and source-of-truth design, not analytics. This is the first major discipline of transformation direction: do not start with the platform; start with the flow of value and evidence. 4. Establish the digital backbone Ross, Weill, and Robertson’s work on enterprise architecture as strategy remains highly relevant because it reframes architecture as the foundation for execution. A company’s architecture defines what can scale, what can be standardised, and where local variation is allowed. In engineering companies, the digital backbone should support a controlled lifecycle. It should not be a random collection of best-of-breed tools connected by fragile integrations and heroic manual work. The backbone usually includes: Requirements management Product structure and configuration management Engineering change control Verification and validation records Manufacturing process and execution data Quality and non-conformance management Supplier and sourcing information Service and operational feedback Cybersecurity and access control Documented evidence for compliance and certification The strategic question is not whether each system exists. The question is whether the backbone supports end-to-end decision-making. [ ] Can a leader see how a requirement links to design, verification, configuration, manufacturing readiness, and certification evidence? [ ] Can an engineer understand the downstream impact of a change? [ ] Can quality teams trace recurring non-conformances to design, process, supplier, or requirement patterns? [ ] Can cybersecurity controls be applied consistently across identities, systems, data, and suppliers? [ ] Can AI use controlled data without bypassing governance? A company without this backbone may still produce impressive digital demonstrations. It will struggle to scale transformation. 5. Decide the role of PLM, ALM, ERP, and MES deliberately One of the most common mistakes in engineering transformation is unclear platform responsibility. PLM, ALM, ERP, and MES are often treated as technical systems. In reality, they represent different control logics. PLM is usually the backbone for product definition, configuration, lifecycle records, engineering change, and design intent. ALM controls software lifecycle artefacts, requirements, code, tests, releases, and software assurance. ERP manages financial, procurement, inventory, planning, and business execution records. MES governs manufacturing execution, shop-floor operations, work instructions, production quality, and operational feedback. The boundaries are not always clean, but they must be explicit. If platform ownership is ambiguous, the organisation will create duplicate records, inconsistent workflows, and uncontrolled data transformations. PLM literature from Stark, Grieves, Saaksvuori, and Immonen makes this point in different ways: product lifecycle management is not merely software. It is the management of product information and processes across the lifecycle. In complex engineering, PLM becomes part of organisational memory. For software-intensive systems, ALM and systems engineering integration become equally important. ISO/IEC/IEEE 15288 and 12207 show that system and software lifecycle processes cannot be governed as separate worlds. In modern aerospace, nuclear, automotive, industrial automation, and defence contexts, mechanical, electrical, electronic, and software disciplines converge. The digital architecture must reflect that convergence. The wrong question is: “Which system should own everything?” The better question is: “Which system owns which controlled object, and how does authority move across the lifecycle?” Without this clarity, digital transformation becomes a permanent negotiation between systems. 6. Treat traceability as a management capability Traceability is often treated as a compliance burden. This is a mistake. Gotel and Finkelstein’s work on the requirements traceability problem remains important because it explains why traceability is difficult: it is not just about links between artefacts. It is about maintaining meaningful relationships across changing requirements, decisions, stakeholders, and contexts. In regulated engineering, traceability is a management capability. It allows organisations to understand impact, control change, support safety arguments, and generate evidence. It is also becoming a precondition for serious AI adoption. AI systems can summarise, classify, recommend, and detect patterns only if the underlying relationships between artefacts are sufficiently reliable. A language model connected to uncontrolled engineering documents may produce fluent but unsafe advice. A model connected to a governed digital thread can support engineers by finding related requirements, identifying potential gaps, and surfacing historical decisions. Traceability should therefore be designed around decision needs. What must be traceable for safety? What must be traceable for certification? What must be traceable for engineering change? What must be traceable for supplier accountability? What must be traceable for cybersecurity and software assurance? What must be traceable for operational learning? A company does not need infinite traceability. It needs purposeful traceability. 7. Build governance into the architecture Weill and Ross showed that IT governance is about decision rights and accountability. Their “governance on one page” logic remains powerful because it forces organisations to clarify who makes which decisions. COBIT 2019, ITIL 4, ISO/IEC 20000, ISO/IEC 27001, NIST CSF 2.0, and NIST SP 800-207 add further structure. They help organisations define controls, service management practices, cybersecurity outcomes, and zero-trust principles. But governance should not live only in policies. In engineering transformation, governance must be embedded into the architecture. Access control should reflect role and lifecycle responsibility. Change control should be built into workflows, not performed after the fact. Evidence should be generated through normal engineering activity. Data ownership should be visible in systems. Cybersecurity should be designed into identity, integration, supplier access, and data movement. AI governance should be connected to data lineage, model use, human approval, and auditability. This is especially important for safety-critical domains. Standards such as SAE ARP4754A/B, ARP4761, RTCA DO-178C, IEC 61508, IEC 61513, and IAEA guidance for software important to safety all reinforce a basic principle: engineering decisions that affect safety must be controlled, justified, verified, and auditable. AI does not remove this requirement. It intensifies it. NIST AI RMF and ISO/IEC 42001 are useful because they shift AI governance from abstract ethics to management systems, risk categories, accountability, and operational control. For engineering companies, the practical rule is clear: AI should be allowed to assist decision-making only where the organisation can preserve accountability for the decision. 8. Use portfolio management to choose sequence, not just budget Many transformation portfolios are lists of projects competing for funding. This is too shallow. Jeffery and Leliveld’s work on IT portfolio management is useful because it treats technology investments as a portfolio of value, risk, and strategic alignment. For engineering companies, this means transformation initiatives should be sequenced according to capability dependency, not political urgency. Some initiatives are foundational. They may not look exciting, but they enable everything else. Examples include identity management, data ownership, PLM object model stabilisation, requirements taxonomy, change governance, integration standards, cybersecurity controls, and source-of-truth design. Other initiatives are value accelerators. They generate visible operational improvement once foundations exist. Examples include automated impact analysis, manufacturing dashboards, supplier performance analytics, AI-assisted engineering search, certification evidence generation, and predictive quality. A poor portfolio funds attractive accelerators without foundations. A strong portfolio builds the minimum foundation required for each next level of value. A practical sequencing model might look like this: | ==Transformation layer== | ==Purpose== | ==Example initiatives== | |:---|----|----| | Foundation | Create control and trust | Identity, data ownership, source-of-truth rules, cybersecurity baseline | | Lifecycle backbone | Connect product and process evidence | PLM, ALM, ERP, MES integration, change control, traceability | | Flow optimisation | Reduce delay and rework | Value stream redesign, automated handovers, process simplification | | Intelligence | Improve decisions | AI search, anomaly detection, risk prioritisation, forecasting | | Assurance | Prove and sustain control | Audit trails, safety cases, certification evidence, AI governance | The point is not that every company must follow the same roadmap. The point is that sequence matters. Building AI on top of weak lifecycle control is not transformation. It is automation theatre. 9. Include sourcing and vendor governance early Digital transformation depends not only on internal systems but also on the economic structure of the firm. Williamson’s transaction cost economics helps explain why organisations must decide what to build, buy, outsource, or govern through partnerships. Lacity and Willcocks’ work on IT outsourcing and sourcing governance reinforces the same point: sourcing is not procurement administration; it shapes capability, control, and risk. Engineering companies often underestimate this. A vendor may provide a platform, but the company must retain architectural authority. A system integrator may deliver implementation, but the company must understand its own operating model. A cloud provider may host infrastructure, but the company remains accountable for data, security, and compliance. An AI supplier may provide models, but the company must govern use cases, evidence, and decision accountability. The transformation direction should therefore include sourcing principles. 10. Define success through information system outcomes The DeLone and McLean IS Success Model is useful because it reminds leaders that system success is multidimensional. It is not enough that a system goes live. Information quality, system quality, service quality, use, user satisfaction, and net benefits all matter. For digital transformation, this means success metrics should be broader than delivery milestones. These metrics connect digital transformation to operational reality. They also prevent teams from declaring success merely because a platform has been deployed. 11. Select your transformation direction After completing the previous steps, a company can choose its transformation direction more intelligently. In practice, most engineering companies fall into one of several patterns. The fragmented systems company needs enterprise architecture and source-of-truth design before advanced automation. The document-heavy company needs lifecycle traceability and evidence-by-design before AI summarisation. The prototype-to-production company needs PLM–ERP–MES alignment and manufacturing readiness governance. The software-intensive product company needs stronger ALM, systems engineering integration, and software assurance workflows. The regulated scale-up needs governance that is light enough to move quickly but strong enough to survive certification and audit. The mature but slow enterprise needs flow redesign, product ownership for internal platforms, and portfolio rationalisation. The AI-curious company needs data lineage, use-case risk classification, cybersecurity controls, and human decision boundaries before scaling AI. The direction should be expressed as a capability thesis. For example: “Our next transformation phase should focus on building a governed digital thread across requirements, configuration, change, verification, and manufacturing readiness, because our main constraint is not lack of tools but lack of trusted lifecycle continuity.” Or: “Our transformation direction should prioritise software lifecycle governance and ALM integration because product complexity is shifting from mechanical design to software-defined behaviour, and our current assurance model is not keeping pace.” Or: “Our transformation direction should focus on PLM–MES integration and production feedback loops because the company is moving from engineering development into repeatable manufacturing.” A good transformation thesis does not describe a tool. It describes the capability gap that must be closed. 12. The practical sequence A company that wants to define its digital transformation direction can follow this sequence: Conclusion: transformation is a choice of capability Digital transformation is not a technology race. It is a choice about what kind of organisation the company needs to become. For engineering companies, especially those operating in regulated or safety-critical contexts, the most valuable transformation direction is rarely the most fashionable one. It is the one that strengthens the company’s ability to make controlled decisions, preserve lifecycle knowledge, manage change, generate evidence, protect systems, and learn faster than complexity grows. AI, digital thread, PLM, ALM, MES, ERP, cybersecurity, service management, and governance all matter. But they matter as parts of a coherent operating system, not as isolated initiatives. The question is not whether your company should transform. It already is, whether deliberately or accidentally. The real question is whether transformation is being directed by strategy, architecture, and evidence — or by the next attractive technology proposal. Companies that answer that question honestly will waste less money, create stronger platforms, and build digital capabilities that survive beyond the current wave of hype.