乐播传媒视频 / IT Consulting, Strategy & Outsourcing Services Company Tue, 22 Sep 2026 11:57:10 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 /wp-content/uploads/2020/03/itc-logo.png 乐播传媒视频 / 32 32 Data Modernization: The Missing Link Between Cloud and AI Value /blog/data-modernization-the-missing-link-between-cloud-and-ai-value/ Tue, 22 Sep 2026 11:57:10 +0000 /?p=49995 The post Data Modernization: The Missing Link Between Cloud and AI Value appeared first on 乐播传媒视频.

]]>

For many enterprises, the cloud journey is well underway. Applications have been modernized, workloads run in scalable cloud environments, and AI is increasingly embedded into business processes. Yet a fundamental gap remains: an enterprise cannot become truly AI-driven while intelligence is trapped inside application silos.

The real constraint is increasingly not access to AI, but access to the right data, in the right context, at the right time. Enterprise data remains distributed across applications, functions, and platforms, with different definitions, fragmented lineage, and limited understanding of the business relationships behind it. Organizations can therefore deploy intelligent applications without necessarily creating enterprise intelligence across the business.

That makes data modernization a critical step in the cloud-to-AI journey. The objective is not simply to consolidate data or build another modern platform, but to create an enterprise data foundation that understands the business: connecting data across domains, enriching it with semantics and relationships, and making it trusted, governed and consumable by AI, even while the underlying architecture remains distributed.

What counts as data modernization has therefore changed. A few years ago, moving data to the cloud or building a modern data platform could itself represent modernization. In an agentic environment, the bar is higher: data also has to be engineered for how people and AI agents will understand and consume it.

AI-ready data is specific to the job

The traditional view of data quality is often too general for AI. A dataset may be complete, consistent, and suitable for reporting, yet still fall short for the particular task a model or agent is expected to perform.

argues that data cannot be made 鈥淎I-ready鈥 in the abstract. Readiness depends on the use case, the AI technique, the required confidence level, and factors such as semantics, labelling, representativeness, lineage, operational performance, and cost. Conventional high-quality data does not automatically satisfy those requirements.

For agentic AI, data readiness increasingly includes business context: what a value represents, how it relates to other business objects, which definition applies and what policies constrain an action. Data modernization is therefore expanding from moving and cleansing data to engineering meaning around it.

Context is becoming part of data engineering

One way to think about this is as a semantic or context spine across the distributed data estate.

  • 聽An ontology defines business objects and relationships;
  • a knowledge graph makes those relationships explicit;
  • a context graph assembles what is relevant to a task; and
  • a semantic layer exposes consistent terms and metrics to people, applications and agents.

This direction is increasingly visible in the market. describes context layers combining semantics, governance and runtime context; discusses ontology-driven semantic layers and virtual knowledge graphs; and uses ontology as a shared business model. The intent is similar: give AI a governed model of what enterprise data means and how it relates.

Consider a hotel. Front-office teams and revenue managers may use the same property data but need different context. The front office may need room availability, guest preferences, and maintenance exceptions; revenue management may need demand, rate performance, and occupancy. The data product should reflect the consumer and use case.

A human also brings tacit knowledge that an agent lacks. Asked which room to offer and at what price, an agent may need to connect reservations, loyalty status, inventory, rates, maintenance, and policy rules. The context spine makes those relationships explicit rather than leaving the model to infer them.

Unstructured data needs more than a place to live

Cloud-native platforms can ingest PDFs, images, audio, diagrams, and other unstructured information. But getting all that content onto a modern platform does not suddenly make it useful to AI.

A PDF used by an AI application may be separated into text, tables, images, metadata, sensitivity labels, embeddings, summaries, and quality scores. McKinsey notes that these derived objects must remain connected to the source and to one another, preserving meaning, lineage, and control throughout the pipeline. If those connections are lost, fairly basic questions become surprisingly difficult to answer: Where did this response come from? Was the right version of the document used? Can the result be reproduced and verified?

Data engineering therefore has to extend beyond ingestion. Unstructured content must be classified, secured, and linked to relevant structured records so a contract, manual or communication connects to the business entities it describes.

Trust has to travel with the context

Once business context becomes reusable across applications and agents, governance has to travel with it. Master data establishes common identities; metadata, lineage, and provenance show where information came from; and policy controls determine what each user or agent can see and do.

This also affects trust in AI outputs. notes that systems working directly over raw enterprise schemas can end up guessing how tables fit together, producing inconsistent metrics and hallucinated answers. A governed semantic layer reduces that guesswork and makes responses easier to trace. As agents begin acting on enterprise information, BCG argues that data quality, lineage and provenance become risk priorities because flawed information can trigger actions before a person intervenes.

Domain expertise turns data into business context

Technology can make enterprise data accessible; domain expertise makes it meaningful. Ontologies, graphs, and semantic layers only become valuable when they reflect how the business actually works: which relationships matter, which definitions are valid, how industry processes connect and which policies shape decisions. That is how raw data becomes AI-ready business context.

This is where 乐播传媒视频’s deep domain expertise can make a fundamental difference. Our context-hub approach is intended to encode reusable industry concepts and relationships so intelligence can move beyond individual applications and operate with a richer understanding of the enterprise.

The next test of data modernization

So, what should leaders now expect from a modern data estate? The bar is clearly moving. As AI moves deeper into enterprise workflows, organizations will need to show that the information feeding those systems remains relevant, intelligible, traceable, and appropriately protected at the moment it is used. Having the data migrated, consolidated, or available on a cloud platform will tell only part of the story.

The harder work lies in making that data usable in context. Structured and unstructured information has to come together, business meaning needs to survive across systems, common identities and definitions have to hold, and governance must continue to work as data moves through retrieval and AI consumption. Once AI begins influencing more consequential decisions and actions, gaps in any of these areas become much harder to overlook.

Cloud modernization created the digital substrate for AI. Data modernization now has to create the business understanding that lets intelligence operate across it: a distributed foundation that can be logically unified, enriched with semantics and relationships, governed end to end and shaped for people and agents.

For CIOs, that gives data modernization a more practical measure of success: how confidently can the enterprise put its data to work through AI? As we move through 2026 and into 2027, that question will become increasingly important. Scaling AI will depend as much on the quality and context of the data underneath it as on the sophistication of the model sitting above it.

Author:

Shan Duggatimatad,
Vice President, DATA

The post Data Modernization: The Missing Link Between Cloud and AI Value appeared first on 乐播传媒视频.

]]> Beyond Code Generation: Where AI Creates Value Across the SDLC /blog/beyond-code-generation-where-ai-creates-value-across-the-sdlc/ Fri, 11 Sep 2026 06:14:58 +0000 /?p=49916 AI has already changed how quickly software can be built. Until recently, much of the excitement was around using AI to create prototypes or small applications. Today, AI can take […]

The post Beyond Code Generation: Where AI Creates Value Across the SDLC appeared first on 乐播传媒视频.

]]> AI has already changed how quickly software can be built. Until recently, much of the excitement was around using AI to create prototypes or small applications. Today, AI can take a new application much closer to production grade, speeding up the development process significantly.

But code generation is only one part of the software development lifecycle. From requirements and business analysis to technical design, development, testing, release, and ongoing maintenance, software moves through a much broader chain of activity before (and after) it reaches production.

That is why faster coding does not automatically translate into faster software delivery. that coding accounts for only 10鈥15% of the time from when an idea enters the queue until the product reaches customers. In BCG’s early GenAI pilots, developers generated code faster, but overall time-to-market changed little because constraints remained elsewhere in the lifecycle. notes that coding assistance is becoming table stakes and as coding accelerates, bottlenecks begin appearing in other stages such as code review and product management.

For large enterprises, there is an additional reality. The bulk of the software work is not about building new applications from scratch. It is maintenance: supporting, changing and upgrading applications that have accumulated over years and are often deeply integrated with one another.

This is where the harder problem begins. AI can increasingly generate or translate code. But can it understand why an application works the way it does, what business process it supports, what other applications depend on it and what might break when something changes?

The constraint is no longer code generation

Current AI tools can translate or recreate code remarkably well. What they cannot reliably infer are all the boundary conditions around an application: business rules, dependencies and integrations that cannot always be understood from code alone.

That explains why many enterprises remain cautious about modernization. The concern is not simply whether AI can rewrite the code. It is whether the organization knows enough about the application ecosystem to change it without disrupting the business. Given that most enterprise applications are built across different generations of technology and carry years of business logic that may no longer be adequately documented, that context is harder to build.

We are seeing this problem firsthand with a financial-services organization.

The company has 12 key systems supporting different areas of banking. Some applications are written in a proprietary fourth-generation language, while others contain Java code that is 15 to 18 years old. The applications are running well, but maintaining them is expensive. The proprietary technology is difficult to support, specialist expertise is limited and all 12 systems are integrated with one another.

That interconnectedness makes modernization particularly difficult. Modernize one part without understanding the rest of the ecosystem, and something elsewhere may fall apart.

Traditional modernization proposals have estimated roughly 24 months to transform the estate. For the bank, that introduces another problem: how does it continue introducing features and responding to business requirements while a two-year transformation is underway?

We are solving this by first building the ontology and knowledge graph for the application ecosystem. That may itself require six to eight months because AI has to reconstruct context from incomplete documentation, non-standard code, and fragmented institutional knowledge. However, once that context has been captured, the organization has created an asset that can support both ongoing maintenance and future modernization.

Building the context AI needs

The objective is no longer simply to convert old code into new code. For AI to create value across the SDLC, particularly in complex enterprise environments, we need to reconstruct context and teach AI how the enterprise application actually works.

By bringing together code, documentation, architecture diagrams, process definitions and design artefacts, enterprises can begin building an ontology of an application – mapping the relationship between the technology and the business process it supports. A knowledge graph can then capture that context in a form AI can work with.

Once that layer exists, the possibilities expand significantly. AI can support maintenance of the existing application, assess dependencies before changes are made, and eventually enable forward engineering into newer languages or architectures.

Extending AI across the SDLC

This context layer also changes how organizations should think about AI personas across software delivery.

A Business Analyst agent can work with richer knowledge of existing processes and requirements. A Tech Designer can evaluate proposed architectures against known application dependencies. Sprint planning can incorporate the likely downstream implications of change rather than treating every requirement as an isolated ticket. Knowledge Assistants can provide engineers with application-specific answers instead of generic technical guidance.

The same context can strengthen Test Engineering by identifying scenarios around business rules and integration points that might otherwise be missed. DevSecOps and release-management agents can evaluate changes against known application relationships before code reaches production.

In other words, the opportunity is not a collection of isolated copilots. It is a connected AI layer spanning requirements, design, development, testing, release and maintenance.

From one application to reusable enterprise intelligence

The longer-term opportunity is even larger. Ontologies do not have to remain application-specific.

A loan-origination ontology, for example, could provide a reusable foundation across financial-services environments. The same principle could apply to processes such as purchase-order generation or invoicing in manufacturing and CPG. Enterprises would still bring their own data, systems and business rules, but they would not necessarily have to reconstruct the entire process context from the beginning.

The work around application context, ontology and knowledge graphs is still evolving. We are building these capabilities into K-Fabrik 鈥 our unified enterprise AI platform. This reusable platform can then be taken across customers rather than solving every AI use case independently.

For organizations whose code itself represents intellectual property, deployment architecture becomes equally important. A fintech, for instance, may not want proprietary source code flowing through public AI services. Running these capabilities within a resident AI environment (inside the enterprise boundary) can allow organizations to apply AI to sensitive application estates without relinquishing control of their code and data.

The next frontier in AI-enabled software engineering will therefore be determined by more than how quickly an AI assistant can generate code. The larger advantage will come from how well AI understands the systems, processes, and dependencies behind that code. Once enterprises can build and preserve that context, AI can move from accelerating individual development tasks to changing the economics of the entire software lifecycle.

Author:

Ashish Agarwal,
Vice President, 乐播传媒视频

The post Beyond Code Generation: Where AI Creates Value Across the SDLC appeared first on 乐播传媒视频.

]]> The Cloud Cost Reckoning: Why FinOps Must Move from Visibility to Accountability /blog/the-cloud-cost-reckoning-why-finops-must-move-from-visibility-to-accountability/ Wed, 09 Sep 2026 11:15:01 +0000 /?p=49887 The post The Cloud Cost Reckoning: Why FinOps Must Move from Visibility to Accountability appeared first on 乐播传媒视频.

]]>

A monthly cloud review can now tell an enterprise a great deal: which accounts are driving spend, where utilization has increased, which resources are underused, and where rightsizing or commitments could improve the economics. The harder conversation begins once everyone has seen the dashboard. Who owns what happens next? And can the business explain what it received for the money spent?

For conventional cloud infrastructure, much of the technical machinery for cost management is already in place. FinOps practices have matured, platforms provide increasingly granular visibility, and enterprises have more ways to monitor and optimize consumption. The challenge is increasingly about turning that visibility into consistent governance and action across the organization.

AI makes that harder. GPU infrastructure, model consumption, token usage, data movement, and experimentation introduce new patterns of spend, often across multiple teams and environments. There are fewer established playbooks, and the economics can change quickly as use cases scale.

That is why the cloud cost conversation is moving beyond finding waste. The real question now is whether enterprises can build financial accountability into the way technology is designed, consumed, and operated.

AI changes the economics of cloud consumption

The scale of the change is already visible. The found that 98% of respondents now manage AI spend, up from 31% in 2024. It also points to a broader evolution in the discipline, with FinOps teams becoming involved earlier in technology decisions rather than only analysing spend after the fact.

The reason is fairly practical. AI costs do not always behave like traditional infrastructure costs.

There is no single optimization formula yet, but architectural choices matter. Retrieval-augmented approaches can reduce unnecessary use of larger models in some scenarios. Open-weight or smaller models may be more economical for certain workloads. Model selection, usage patterns, data movement, and the way an application is designed can all affect the eventual cost.

McKinsey鈥檚 research highlights how difficult that can become in practice. Its 2026 Enterprise AI FinOps survey found that 93% of qualified respondents had exceeded their AI budgets, while only 20鈥25% had mature AI FinOps capabilities. The research also found that AI expenditure is often spread across foundation-model contracts, copilots, APIs, AI-enabled software, experimentation environments, and business-unit purchases.

So the issue is not simply how much AI costs. Enterprises need to understand where the demand is coming from, what is driving it, and whether the consumption is justified by the outcome.

Cost decisions need to happen earlier

This changes when cost management needs to enter the conversation.

If a workload has already been architected, deployed, and scaled, the options available to a FinOps team are narrower. It can identify waste, recommend rightsizing, negotiate commitments, or flag unusual consumption. Some of the biggest economic decisions, however, may already have been made.

For AI workloads, choices around model selection, workload placement, retrieval architecture, context size, and the balance between proprietary and open-weight models can shape cost well before the first monthly bill arrives.

This is why FinOps is becoming more closely connected with architecture and engineering. Cost needs to be considered while workloads are being designed, alongside performance, scalability, resilience, and security. Forecasting also becomes more important because business teams need a clearer view of what happens to the economics when an AI use case moves from a pilot to wider adoption.

The goal is to make cost a design consideration rather than a correction exercise.

From cost insight to operational action

The other challenge is execution. A cost anomaly is useful only if someone can investigate it, decide what needs to change, and make that change without compromising service performance.

At 乐播传媒视频, we bring together capabilities such as SpendEffix, cloud optimization and modernization, cloud managed services, account management, ITSM, automated ticketing, and multi-cloud performance monitoring to support this operating model.

SpendEffix provides the FinOps layer for visibility and financial management, while cloud optimization and modernization help address workloads where inefficient consumption is rooted in the underlying architecture. Multi-cloud monitoring brings cost into the context of performance and utilization, while managed services, ITSM, and automation provide mechanisms for carrying an identified issue through to action.

That connection becomes important as cloud estates expand. Finding another optimization opportunity is rarely the difficult part. Making sure the right team owns it, understands its operational impact, and closes the action is where accountability begins.

Automation can help shorten that cycle further, particularly around anomaly detection, remediation, forecasting, and repetitive optimization activity. It also allows FinOps teams to spend less time chasing individual cost events and more time looking at patterns, architecture choices, and business value.

The real question is what the spend delivered

FinOps began by giving enterprises a clearer view of variable cloud consumption. That visibility remains essential, especially as AI creates another fast-growing category of technology spend. The next stage is about making that information useful in decisions.

As enterprises move through 2026 and into 2027, mature FinOps practices will increasingly need to connect consumption with ownership, architecture choices, forecasts, and business outcomes. The monthly bill will still tell leaders what they spent. The more valuable capability will be understanding what drove that spend, whether it was worth it, and who has the information and authority to act when the economics change.

Author:

Varoon Rajani
Sr. VP & SL Head 鈥 CS

The post The Cloud Cost Reckoning: Why FinOps Must Move from Visibility to Accountability appeared first on 乐播传媒视频.

]]> ZeroLag Manufacturing: The Connected Enterprise for Event Driven Decisions /blog/zero-lag-manufacturing-the-connected-enterprise-for-event-driven-decisions/ Wed, 12 Aug 2026 06:18:10 +0000 /?p=49814 The post ZeroLag Manufacturing: The Connected Enterprise for Event Driven Decisions appeared first on 乐播传媒视频.

]]>

In a manufacturing organisation, internal and external events are an integral part of the operating ecosystem. Supply delays, material shortages, equipment breakdowns, and changing dispatch priorities are common events with operational consequences that typically require a response within a short timeframe.

Other events have broader implications and may not require real-time action. For example, a new duty can alter sourcing economics, a geopolitical development can put a supply corridor at risk, or a competitor may introduce a product that begins to reshape customer expectations. The organisation may have more time to respond, but the impact of the decision often extends across the value chain.

Does every event require immediate attention and response? Not necessarily. The critical question is whether the organisation can recognise the event, understand its implications, and respond before the available response window closes.

This is the essence of ZeroLag Manufacturing. The objective is not universal real-time decision-making. Rather, it is to build the organisational and technology capabilities required to sense, analyse, decide, and act at the speed appropriate to each event.

Three dimensions shape the response

The nature of an event determines the type of response required. Three dimensions are particularly important: time, origin, and frequency.

The first is the time available. The relevant window may range from the current production cycle to several weeks of analysis and preparation. The urgency of the event, however, does not necessarily indicate the scale of its consequences.

The second is the origin of the event. Events may arise within operations or elsewhere in the value chain, but their effects rarely remain confined to where they began. A quality deviation may arise within the plant, while a regulatory change, logistics disruption, or customer request originates outside it. Yet the operational impact can be equally significant. Manufacturing can no longer be managed as an environment bounded by the factory walls.

The third is frequency. Supplier delays, demand variations, production interruptions, and material-quality issues are familiar operating conditions. Because they recur, organisations can progressively codify how they should be handled. They can establish decision rules, connect the relevant information, and automate parts of the response.

A tsunami affecting a sourcing region, an unexpected import restriction, or a major geopolitical event is harder to standardise. The business must assess multiple scenarios and consider consequences across products, suppliers, markets, and financial commitments. Technology can support that analysis, but experienced human judgement remains central.

This leads to an important distinction. The more repeatable and bounded an event becomes, the greater the scope for autonomous action. As its consequences broaden, the response requires a wider enterprise view and stronger executive oversight.

Two forms of integration support two different responses

Recurring operational events depend heavily on vertical integration.

For recurring operational events, competitive advantage comes not from detecting the event, but from closing the loop between detection, interpretation, decision, and execution. Organizations are moving from sense and monitor to sense, understand, decide and act. This is where the role of generative AI and agentic AI is becoming significant. Organizations with a connected operations ecosystem are integrating AI capabilities for autonomous actions for repetitive recurring events.

For example, one of ITC’s manufacturing plants leverages data from thousands of sensors to continuously monitor critical process parameters. Through vertical integration between the shop floor and operational systems, a Digital Twin analyses process conditions, compares them against golden-batch specifications, evaluates alternative scenarios, and interfaces with the SCADA environment to adjust process parameters when deviations are detected. The result is a closed-loop, autonomous decision cycle that identifies process variations, determines the appropriate corrective action, and executes it in near real time. By reducing the lag between detection, decision, and execution, the plant is able to maintain consistent product quality while minimising operational intervention.

Events with wider business implications require horizontal integration.

Consider a restriction on an imported material. The manufacturer must identify alternatives, determine whether they meet product and quality requirements, find suppliers capable of providing them, understand how production would need to adapt, and assess the effect on costs and customer commitments. No single application or function holds the complete answer.

A digital thread helps connect product, engineering, supplier, manufacturing, and business information across the value chain. It gives decision-makers a coherent view of the relationships affected by the change and allows them to explore alternatives before committing the organisation to a course of action.

A operation shows what this type of connected response can achieve. Faced with growing small-batch demand and the complexity of a five-tier distribution network, the company connected real-time customer-order management, AI-enabled planning, and a supply-chain control tower. It reported a 39% reduction in end-to-end delivery lead time, a 30% reduction in inventory days, and an 86% reduction in market defects.

The improvement did not come from optimising one production process. It came from connecting demand, planning, manufacturing, inventory, distribution, and service around a common operating view.

The ambition must reflect the installed reality

The ambition for ZeroLag manufacturing must also reflect the reality of the manufacturing estate. The challenge is that manufacturing estates are rarely uniform.

In one client conversation, a manufacturer of fuel-dispensing equipment described a large installed base in which many deployed units lacked the sensors required to capture operational data. As a result, analytics and predictive service models could not be deployed across those assets without first addressing the underlying instrumentation and connectivity gaps.

The same variation exists within large manufacturing groups. A modern facility designed around contemporary automation and information systems may operate alongside a site established many decades earlier. The economics of replacing machinery, implementing manufacturing applications or connecting legacy operational technology will differ significantly between them. As a result, the pace and path of digital transformation are rarely uniform across the manufacturing network.

There is no universal prescription for ZeroLag Manufacturing. The appropriate approach depends on the events being addressed, the value at stake, and the organisation’s starting point. In some cases, the immediate requirement may be to improve instrumentation and connectivity so that operational events can be identified and acted upon. In others, the priority may be to integrate legacy systems, strengthen the flow of information across functions, or establish the digital foundations needed to support more coordinated decision-making. The most suitable path will vary according to the installed technology estate, cybersecurity requirements, investment priorities, and the organisation’s ability to adapt and sustain change.

Workforce considerations are equally important. As systems become capable of recommending or executing production decisions, the roles of planners, supervisors, and operators begin to change. Their expertise remains indispensable, but it is increasingly applied through exception management, judgement, and the governance of autonomous systems rather than through every routine decision.

ZeroLag manufacturing ultimately provides a way to think more clearly about responsiveness. It asks leaders to identify the events that carry the greatest operational and business exposure, determine how much time the enterprise has to act, and build the horizontal or vertical connections needed to make a sound decision.

The most responsive manufacturer will not attempt to automate every choice or react immediately to every signal. It will understand which decisions can be codified, which require a broader view of the value chain, and where experienced judgement should remain firmly in control.

In our upcoming CXO exchange, we discuss this approach at length with some of the best minds in the industry. Stay tuned for more updates from the conversation.

Author:

Nitin Kumar Kalothia
Associate Partner – Business Consulting Group
乐播传媒视频

The post ZeroLag Manufacturing: The Connected Enterprise for Event Driven Decisions appeared first on 乐播传媒视频.

]]> Securing Multi-Cloud in the Age of AI Complexity /blog/securing-multi-cloud-in-the-age-of-ai-complexity/ Fri, 24 Jul 2026 07:25:34 +0000 /?p=49752 Multi-cloud has become the operating reality for large enterprises. Business units choose SaaS platforms for speed. Technology teams use different cloud providers for performance, scale, cost, regulatory or ecosystem reasons. […]

The post Securing Multi-Cloud in the Age of AI Complexity appeared first on 乐播传媒视频.

]]> Multi-cloud has become the operating reality for large enterprises. Business units choose SaaS platforms for speed. Technology teams use different cloud providers for performance, scale, cost, regulatory or ecosystem reasons. Legacy systems continue to support critical processes. AI is now entering this environment with a higher demand for trusted data, clean access models and consistent governance.

For CIOs, CISOs and risk leaders, the concern is not the size of the technology estate alone. The harder issue is fragmentation of control.

A cloud environment may look secure when viewed on its own. Risk builds when data, identities, applications, APIs and automation cross environments without a consistent security and governance model. AI makes that gap harder to carry because it relies on the foundations that are most difficult to manage across a distributed estate: data quality, access control, lineage, policy enforcement, observability, and response.

The real multi-cloud risk is control drift

Most enterprises have invested heavily in cloud security. Identity platforms, vulnerability tools, encryption standards, posture management, security monitoring and cloud-native controls are already in place. Yet many leadership teams still struggle to get fast, reliable answers to basic questions: who has access to what, where sensitive data is moving, which exposure creates the highest business risk, and whether policies are being applied consistently across environments.

We are witnessing a , where the speed of cloud adoption is outpacing the ability of security teams to maintain consistent visibility, detection and response.

In a multi-cloud estate, this becomes an operating model challenge. Each platform has its own way of managing identity, policy, logs, configurations and controls. When enterprises add more tools without connecting the control model, security teams are left correlating risk across systems that were not designed to work together.

For a CIO, the key cloud question is no longer, 鈥淒o we have controls?鈥 The better question is, 鈥淐an those controls work together when the business runs across multiple environments?鈥

AI raises the cost of weak governance

AI changes the security conversation because it brings data, access and action closer together. A model or AI-enabled workflow may draw from customer, transaction, operational, product, service or employee data, and then use that context to support decisions, trigger workflows or guide automated responses.

That puts far more pressure on the data foundation. If enterprise data is duplicated, poorly classified, inconsistently governed or difficult to trace, the issue is no longer only whether the data is secure. It is whether the enterprise can trust how that data is being used, who or what has access to it, and whether the outputs can be explained with confidence.

Agentic AI adds another layer to this challenge. has identified agentic AI as a top cybersecurity trend for 2026, citing unmanaged agents, unsecured code and compliance exposure as emerging risks. As AI systems begin to act across workflows, call tools, access systems and interact with enterprise data, governance has to extend beyond where data sits to what actions AI-enabled systems can take. The access question also changes. The identity estate now includes service accounts, API keys, workloads, automation scripts, machine identities and AI agents that can hold permissions, trigger actions, call systems and move across environments. Many are created for a specific use case and remain in place long after the original need has changed.

This is why AI-ready cloud security has to begin with an AI-ready data foundation. Applications may continue to run across different cloud and SaaS environments, but AI-relevant data needs stronger consolidation, governance and lineage, while non-human identities need clearer ownership, least-privilege access, credential lifecycle management and faster privilege revocation. Without that, enterprises carry cloud fragmentation into their AI programs, creating gaps in privacy, accuracy, auditability and decision confidence.

For leadership teams, the implication is clear: cloud security, data governance and AI governance need to be designed together. The highest-risk gaps will appear where AI needs the greatest confidence – in data access, policy enforcement, traceability and delegated action.

Security architecture needs to become more coherent

The answer is not to simplify ambition or slow down AI adoption. It is to make the control model more coherent.

Enterprises need a unified view of identity, data exposure, configuration, vulnerabilities, runtime behaviour and response across cloud environments. They need policy consistency across platforms rather than separate interpretations of the same security principle. They need vulnerability management that prioritizes exploitable paths to critical assets, not just severity scores in isolation. They also need resilience planning that assumes incidents may cross cloud, SaaS and legacy boundaries.

AI can help security teams with correlation, anomaly detection, triage and remediation. It can also be misused by attackers to identify gaps faster and at scale. That dual reality makes governance even more important. Human oversight, explainability, guardrails and clear accountability need to be built into AI-supported security workflows, especially where automated action is involved.

For CXOs, the agenda is clear. Multi-cloud security has to move from a platform-by-platform control exercise to an enterprise governance capability. The priority is to reduce fragmentation where it creates the greatest risk: identity, data governance, policy enforcement, observability, vulnerability prioritization and response.

AI will not wait for cloud estates to become simpler. Security architecture has to make them more governable.

Author:

Varoon Rajani
Sr. VP & SL Head – CS

The post Securing Multi-Cloud in the Age of AI Complexity appeared first on 乐播传媒视频.

]]> The Real AI Bottleneck May Be Your Cloud Foundation /blog/the-real-ai-bottleneck-may-be-your-cloud-foundation/ Wed, 22 Jul 2026 05:23:14 +0000 /?p=49773 For the last decade, cloud transformation has largely been measured by migration progress. How many workloads moved? How much infrastructure shifted? Which applications were rehosted, refactored or retired? For many […]

The post The Real AI Bottleneck May Be Your Cloud Foundation appeared first on 乐播传媒视频.

]]> For the last decade, cloud transformation has largely been measured by migration progress. How many workloads moved? How much infrastructure shifted? Which applications were rehosted, refactored or retired? For many enterprises, that was the right question at the time.

AI is changing the test.

As enterprises move from pilots to scaled adoption, cloud maturity is being measured less by where workloads sit and more by whether the cloud foundation can support trusted data, secure access, elastic compute, controlled spend, modern applications and resilient operations. That is where a gap is becoming visible.

The issue is not cloud adoption. Most enterprises have already made meaningful progress. The issue is that many cloud estates were built for application migration and infrastructure flexibility, while AI demands something more integrated: governed data, stronger security, cost discipline, modernized applications, and automation-led operations.

forecasts worldwide AI spending to reach $2.59 trillion in 2026, up 47% year over year, driven heavily by hyperscalers and vendors. That scale of investment will put pressure on enterprise cloud foundations that were never fully modernized for AI-grade workloads.

For CIOs, the maturity question is becoming sharper: is the cloud estate ready to carry enterprise AI, or will it amplify the debt already sitting inside the technology landscape?

Cost is becoming an AI readiness issue

Cloud cost has always been part of the CIO conversation. AI is making it harder to treat cost purely as a consumption management problem.

AI workloads introduce new cost patterns. GPU consumption, model training, inference, token usage, data movement, storage growth and experimentation cycles can all change the economics of cloud programs. In our client conversations, cloud cost control and FinOps are already among the most urgent areas of concern, especially as AI adds a new layer of consumption unpredictability.

The FinOps Foundation鈥檚 notes that FinOps has expanded beyond cloud into a proactive, technology-wide discipline, with AI now dominating the forward-looking agenda. This is an important signal. Cloud cost maturity can no longer depend only on monthly reports, budget alerts, or infrastructure optimization exercises. AI requires a more active cost model: tagging, ownership, workload-level visibility, consumption forecasting, governance policies, and automated controls built into the operating model.

For CIOs, FinOps has to move closer to architecture. The question is not simply whether cloud spend is rising. The better question is whether teams can connect spend to business value, workload design, data movement, performance needs, and modernization choices.

A lift-and-shift estate will usually cost more than expected because it carries old application assumptions into a consumption-based environment. AI makes that even more visible.

Security and privacy now sit at the center of cloud maturity

Security concerns around cloud migration have matured over time. Many enterprises are now comfortable running critical applications on cloud. AI, however, introduces a different security and privacy concern because enterprise data may be used to train, fine-tune, or power models and AI-enabled workflows.

The worry is straightforward: when data moves from enterprise-controlled environments into cloud-based AI services or model ecosystems, leaders want assurance that it remains secure, private, and governed.

It鈥檚 clear that cloud is increasingly central to enterprise AI strategy. At the same time cloud adoption has expanded the attack surface faster than traditional security models can protect it.

For CIOs and CISOs, this changes the cloud maturity conversation. Security cannot remain a layer applied after migration. It has to be embedded into landing zones, identity models, data governance, network design, policy enforcement, observability, and incident response.

This becomes even more important in multi-cloud and hybrid estates, where different platforms may have different security parameters, policies, controls, and monitoring structures. When data crosses environments, risk rises unless governance and visibility are consistent. Cloud maturity therefore has to include security posture, data protection, identity governance, and resilience across the full estate.

Data readiness is the hidden maturity gap

The most important AI gap may not be in cloud infrastructure at all. It may be in data readiness.

In many enterprises, data sits across source systems, warehouses, lakes, SaaS applications, and legacy platforms. Some of it is duplicated. Some is poorly governed. Some is not integrated with enterprise data platforms. Some lacks quality, lineage or metadata. That makes it difficult to use as reliable input for AI.

Cloud can help solve this, but only when used as a governed data foundation rather than just an infrastructure destination. Enterprises need to bring critical data stores, warehouses and governance layers into a more coherent cloud architecture so AI workloads can draw from trusted, classified, and well-managed data.

There is a practical reason for this. AI does not perform well on fragmented context. If customer, product, transaction, service and operational data are not connected, the enterprise cannot easily build correlation, dependency mapping or decision intelligence. Aggregating AI-relevant data in one place makes it easier to govern, correlate and use for AI with stronger security, privacy, and accuracy controls.

We recently helped an insurance organization migrate data to cloud and create a data layer with master data management and governance. Once that foundation was in place, the organization was able to run machine learning and AI algorithms more efficiently on the platform.

That is the deeper lesson for CIOs. AI readiness starts before the model 鈥 with data architecture, data governance and cloud design.

Modernization debt is becoming harder to carry

Many enterprises still carry applications built over 10, 15, or 20 years. These systems were often left unchanged because modernization was expensive, time-consuming and difficult to prioritize against new business initiatives. The result is technical debt that shows up as security risk, scalability limits, performance constraints, and operational fragility.

Cloud migration exposed some of this debt. AI will expose more of it.

A legacy application can be moved to cloud and still remain structurally unready for AI-era demands. If it cannot scale elastically, integrate easily, expose data securely, support automation, or operate with modern observability, it will limit the enterprise鈥檚 ability to use AI in meaningful workflows.

This is why modernization has to become part of the cloud maturity agenda. CIOs need a clear view of which applications can be retained, which can be rehosted, which need refactoring, which should be re-architected, which require database changes, and which should be retired.

The stronger point is that modernization should not always wait until after migration. In many cases, simply moving applications as-is creates higher cost, limited automation, and weak elasticity. Refactoring during migration can help applications use cloud-native capabilities more effectively and reduce the risk of carrying old inefficiencies into the cloud.

AI can also change the economics of modernization. AI-assisted modernization can significantly improve productivity in upgrading or transforming applications, turning programs that once took many months into shorter, more manageable initiatives.

Our recent engagement with a Tier-1 private sector bank in Southeast Asia shows how this can work in practice. The bank needed to modernize 21 legacy banking applications while maintaining business continuity, reducing technical debt, and improving release agility. 乐播传媒视频 helped the bank move to a more standardized, cloud-native modernization approach, creating a stronger foundation for scalability, security, and long-term cloud-first growth. The program delivered 35% faster release cycles, a 30% reduction in operational effort, and a repeatable modernization framework for future initiatives.

For CIOs, this creates a window to revisit modernization debt with a different business case. The goal is not modernization for its own sake. The goal is to build a cloud estate that can support secure, scalable, automated, and AI-ready operations.

A practical roadmap for CIOs

The cloud maturity gap cannot be closed through isolated initiatives. Security, cost, modernization, data, and operations are now tightly connected. A cost issue may be rooted in poor architecture. A security issue may be rooted in fragmented identity. A data issue may be rooted in incomplete modernization. An AI issue may be rooted in all of them.

A practical CIO roadmap can begin with five moves.

  • First, set up the landing zone correctly. This is the foundation for governance, security, identity, networking, and policy consistency.
  • Second, identify pilot applications and use them to validate the operating model before scaling migration or modernization.
  • Third, define tagging, ownership and FinOps pipelines early, so cost visibility and accountability are built into cloud adoption rather than added later.
  • Fourth, migrate and modernize with automation in mind. The goal is to reduce manual effort, strengthen consistency, and improve operational scalability.
  • Fifth, bring in monitoring, automation, and AIOps to manage cloud infrastructure and applications with greater intelligence and responsiveness.

For leadership teams, the broader shift is clear. Cloud maturity is no longer defined by migration completion. It is defined by whether the enterprise can support AI at scale without losing control of cost, security, data quality, modernization and resilience.

AI ambitions will keep growing. The cloud foundation has to catch up.

Author:

Varoon Rajani
Sr. VP & SL Head – CS

The post The Real AI Bottleneck May Be Your Cloud Foundation appeared first on 乐播传媒视频.

]]> SAP S/4HANA migration: Why waiting is becoming the more expensive investment decision /blog/sap-s4hana-migration/ Thu, 09 Jul 2026 10:27:49 +0000 /?p=49674 For many enterprises still running on SAP ECC, the delay around S/4HANA migration is not always about resistance to change. Often, it comes from a more practical concern: which path […]

The post SAP S/4HANA migration: Why waiting is becoming the more expensive investment decision appeared first on 乐播传媒视频.

]]> For many enterprises still running on SAP ECC, the delay around S/4HANA migration is not always about resistance to change. Often, it comes from a more practical concern: which path is right for us? And how much of the existing ECC estate should move into the future core?

The answer is difficult because most ECC environments are not clean. They carry years of custom code, Z reports, local process variants, acquired business processes, bespoke controls, third-party interfaces, and manual workarounds. Some of these are essential for running the business. Others exist because of old decisions, unresolved process gaps, poor data quality, or workarounds that became permanent.

Before an enterprise can choose between Greenfield, Brownfield, or Bluefield migration, it needs to answer a more useful set of questions: What should we preserve? What should we redesign? What should we retire? And what are we continuing to fund by waiting?

Why waiting is becoming more expensive

SAP has confirmed mainstream maintenance for SAP Business Suite 7 core applications until end-2027, with optional extended maintenance until end-2030. S/4HANA maintenance is committed until 2040, making the long-term direction clear. Yet the migration backlog remains significant: by end-2024, only about 39% of SAP鈥檚 35,000 ECC customers had moved to S/4HANA, and Gartner projected that nearly half could still be on ECC by the 2027 deadline.

The cost of waiting is a shrinking design window. A strong S/4HANA program needs time for custom code analysis, process mining, data-quality assessment, integration mapping, target architecture, business-case segmentation, change planning, and phased sequencing. When timelines compress, companies often reduce scope, preserve more legacy, accelerate testing, and push transformation into later waves.

Delay also creates market constraints. SAP talent, migration partners, testing capacity, and transformation governance become harder to secure as demand rises. Internally, businesses keep funding the technical debt – custom-code support, interface maintenance, regression testing, manual reconciliation, and fragmented reporting.

The AI agenda adds pressure. AI-enabled workflows depend on clean transactional data, process logic, and ERP structures. If the core remains fragmented, AI value may remain limited to isolated productivity gains.

Delaying the move can tie up capital, capacity, and leadership attention in an ERP core that no longer supports where the business needs to go.

Route selection is a business first consideration strongly underpinned by a debt-allocation decision

A route decision based mainly on speed or perceived disruption can miss the larger value question. The path to migration should be assessed through how the business outcomes need to be and the economics of legacy, not as generic implementation preferences.

  • A Greenfield path reimagines how the business operates and writes off more legacy debt upfront. It forces decisions on process standardization, target operating model, master data, governance, and clean core discipline early in the program. The business pays for higher change intensity, but gains the opportunity to reduce structural complexity before it hardens into the next platform.
  • A Brownfield path is the choice when the operating model is largely sound and business continuity matters. However, in a heavily customized estate, Brownfield can convert ECC technical debt into S/4HANA technical debt, with the remediation simply moving downstream.
  • A Bluefield or selective data transition (SDT) path allows the business to preserve what has value, redesign what constrains scale, and retire what no longer earns its keep. Debt is priced selectively. This can be powerful in complex mid-tier environments with acquisition history, uneven process maturity, and mixed appetite for change across entities. It also requires much sharper governance because selectivity without discipline becomes another form of complexity.

The decision should start with the ECC estate, not the migration label

The hardest part of S/4HANA readiness is not the identification of the customization quotient. It is classification of the same economically.

Some customizations protect margin, compliance, customer commitments, or industry-specific execution. Some exist because the business never standardized. Some compensate for poor data. Some support reports no one trusts but everyone still circulates. Some were built for a business structure that no longer exists.

Without this classification, migration planning becomes path-led instead of value-led. The enterprise starts asking whether it should go Greenfield, Brownfield, or Bluefield before understanding which custom objects, interfaces, controls, workflows, and data structures are still economically defensible.

A more mature assessment asks:

  • Which customizations protect margin, compliance, customer commitments, or industry-specific execution?
  • Which reports are still decision-critical, and which exist because users do not trust source data?
  • Which process variants are strategic, regulatory, or customer-driven?
  • Which integrations are essential to business flow, and which preserve architectural fragmentation?
  • Which data must be migrated for continuity, compliance, and analytics, and which data should be archived?

These questions make the path clearer. If most of the estate is high-burden and low-value, Greenfield becomes easier to justify. If the estate is disciplined and business-critical, Brownfield may be the right route. If value and complexity are unevenly distributed, Bluefield may offer the strongest balance.

The leadership move

S/4HANA migration may be triggered by a deadline, but the investment case is larger. It is a decision about what the enterprise is willing to fund for the next decade.

The better organizations understand the cost and value of their ECC estate, the more deliberately they can choose between Greenfield, Brownfield, and Bluefield, and the less likely they are to move to S/4HANA while carrying forward the constraints that made change difficult in the first place.

The strongest starting point is not 鈥淲hich migration path should we choose?鈥 It is: 鈥淲hat legacy is still worth carrying forward?鈥

Author:

Jayabrata Maitra
Technology Practice Head – ERP

The post SAP S/4HANA migration: Why waiting is becoming the more expensive investment decision appeared first on 乐播传媒视频.

]]> From Digital Thread to Agentic Operations: What Manufacturing Leaders Need Next /blog/from-digital-thread-to-agentic-operations-what-manufacturing-leaders-need-next/ Thu, 02 Jul 2026 11:24:13 +0000 /?p=49632 Manufacturing leaders have spent the past decade digitizing individual functions with the enterprise. Engineering teams modernized PLM. Plants invested in automation, sensors, robotics, and MES. Supply chains built planning systems […]

The post From Digital Thread to Agentic Operations: What Manufacturing Leaders Need Next appeared first on 乐播传媒视频.

]]> Manufacturing leaders have spent the past decade digitizing individual functions with the enterprise. Engineering teams modernized PLM. Plants invested in automation, sensors, robotics, and MES. Supply chains built planning systems and control towers. Quality teams adopted predictive quality control & analytics. Service organizations began using connected product data. These investments improved local performance, but they also created a new leadership problem: the enterprise may have become more digital, yet it鈥檚 still not more coherent.

That distinction is increasingly critical in today鈥檚 manufacturing environment. Our global manufacturing clients now operate with a level of product and operational complexity that was unimaginable a generation ago. This complexity propagates rapidly across functions and at speed. Products are more configurable, software-defined, connected, and tightly regulated. A single design change can ripple across supplier readiness, manufacturing processes, software configurations, field diagnostics, sustainability reporting, warranty exposure, and regulatory compliance. Similarly, a quality issue may originate as a component deviation, extend into production, surface in field performance, and ultimately impact customer trust. Even localized supply disruptions cascades across geographies and impact capacity, working capital, customer commitments, and service levels.

This is why the digital engineering conversation has moved beyond tooling. The question is no longer, 鈥淒o we have digital systems?鈥 Most large manufacturers already do. The sharper question is, 鈥淐an those systems create a trusted operating foundation for decisions across the product lifecycle?鈥

Old digital transformation question New CXO question
Do we have modern PLM? Can product truth move reliably across engineering, manufacturing, quality, supply chain, and service?
Do we have smart factories? Can operational signals trigger coordinated decisions across the enterprise?
Do we have AI pilots? Does AI have trusted product and process context to reason from?
Do we have compliance reporting? Is compliance evidence embedded into the flow of work?
Do we have digital adoption? Are roles, incentives, and routines changing with the technology?

Fig 1: What Changes for the CXO?

Why the Digital Thread Is Becoming the Enterprise Nervous System

That foundation is what the industry often calls the digital thread.

At its simplest, a digital thread is the connected flow of product and process information across the lifecycle, from concept, design, and engineering to manufacturing, quality, service, and eventual retirement. It links the 鈥渨hy鈥 of a product, such as customer requirements and engineering intent, with the 鈥渨hat鈥 of product structures and configurations, the 鈥渉ow鈥 of manufacturing processes, and the 鈥渉ow well鈥 of quality and field performance.

In our customer ecosystem, where a digital thread has been established, leaders are able to understand how decisions in one part of the lifecycle impact cost, quality, compliance, delivery, sustainability, and customer experience across the enterprise.

The digital thread enables synchronized execution of customer orders across design, manufacturing, supply chain, and service. It also provides traceability and accountability鈥攃apabilities that are particularly critical in automotive and industrial product segments.

However, the challenge in implementing digital thread is a manufacturing reality – product data rarely sits in one place. Companies leverage primarily PLM for managing product information and leverage MES, ERP, LIMS for executing shop floor operations.聽 Supply chain works across planning, procurement, logistics, inventory, supplier collaboration, and risk systems leveraging SAP and Supply chain solutions. Service adds its own layer of warranty, maintenance, asset performance, and customer usage data.

For years, enterprises tried to deal with this by integrating systems. The next challenge is deeper: integrating meaning.

AI has made that gap impossible to ignore. A senior engineer can often compensate for fragmented context because she understands the product, supplier history, plant constraints, and organizational workarounds. AI agents cannot depend on tribal memory. They need structured context, governed relationships, clean taxonomies, and boundaries for action.

Manufacturers cannot scale AI in engineering and operations while leaving product context trapped in silos.

The right approach to this integration can have significant impact. For instance, the integration of ERP (SAP), PLM (Enovia), production planning and scheduling (Ortems), and MES (Apriso) enabled the creation of a digital thread for an automotive manufacturer. These systems exchanged information seamlessly, providing end-to-end visibility, component- and process-level traceability, and enabling optimization at the enterprise level rather than within individual functions.

From Digital Engineering to Enterprise Complexity Management

Today, a product is no longer a static object progressing through a linear lifecycle. It is a dynamic system of hardware, software, data, suppliers, services, and regulatory obligations. An elevator illustrates this well. It has evolved from a standalone mechanical system into a connected, integrated solution within a building management ecosystem. Continuously updated and enhanced through new features and software upgrades.

Product complexity now begins well before production. It is created through configuration options, embedded software, supplier dependencies, sustainability requirements, regional regulations, material constraints, service models, and customer-specific variants. Once that complexity enters the lifecycle, it travels. A poorly governed change in design may become a manufacturing issue, a service issue, a quality issue, or a compliance issue months later.

AI is helping engineers explore alternatives, extract requirements, accelerate validation, generate design options, and reuse knowledge. Yet these capabilities become enterprise-grade only when they are connected to a governed product context. Without that context, AI speeds up isolated tasks while leaving the organization鈥檚 complexity problem untouched.

The more advanced manufacturers use model-based approaches, digital twins, knowledge graphs, and AI-enabled engineering workbenches to detect these dependencies earlier. They simulate how design choices affect manufacturability, cost, quality, and serviceability before those choices become expensive. They treat engineering knowledge as an enterprise asset rather than something rediscovered project by project.聽

The most serious manufacturing leaders are asking a harder question now: if AI agents are going to participate in engineering and operations, what enterprise context will they reason from?

Agentic Operations: The Move from Visibility to Coordinated Action

That question leads directly from digital thread to agentic operations.

Agentic AI systems can perceive context, reason through options, plan steps, trigger actions, and coordinate workflows within defined guardrails. In manufacturing, this has significant potential as the operating environment is full of decisions that are too dynamic for static dashboards and too coordination-heavy for manual workflows.

Consider a production supply chain disruption. A conventional dashboard shows a material shortage in the production plan, leading to a potential line stoppage. On the other hand, we鈥檝e developed an Early Warning & Autonomous Control System – an intelligent supply chain management solution 鈥 that goes beyond this basic reporting. It assesses the impact of the shortage on production and customer delivery commitments and dynamically re-prioritizes the production plan to maximize capacity utilization and efficiency, with the objective of minimizing financial impact while still meeting delivery commitments.

With a human in the loop, the system then executes the next-best actions. The real business value lies in compressing the time between signal, interpretation, decision, and action.

The same logic applies to maintenance, quality, manufacturing, planning, inventory optimization, energy management, warranty analysis, and field service. These are areas where manufacturers often have enough data to see problems; yet lack the connected process intelligence to act fast enough.

The temptation will be to treat agentic AI as another layer of automation. In manufacturing, autonomy without context is dangerous. An agent making recommendations on production sequencing, quality containment, maintenance prioritization, or supplier response must operate inside a governed architecture. It needs access to the right data, visibility into constraints, clearly defined authority, audit trails, escalation paths, and human oversight proportional to business risk.

The operating question is: which decisions can be safely accelerated because the enterprise has the data, process discipline, governance, and human accountability to support them?

Stage Capability Business value
Fragmented digital systems Function-specific tools across PLM, MES, ERP, quality, service Local efficiency
Digital thread Connected product and process context across lifecycle Lifecycle visibility and traceability
AI-ready product foundation Governed data, taxonomies, knowledge graphs, semantic relationships AI can reason over product context
Agentic operations AI agents coordinate decisions and workflows within guardrails Faster response, better resilience, lower friction
Intelligent manufacturing architecture Product truth + operational reality + governance + human oversight Enterprise-level performance improvement

Fig 2: From Digital Thread to Agentic Operations

The Workforce Is the Real Adoption Layer

Technology programs often underestimate the human system and, in our experience, this is one of the biggest challenges of Digital Transformation in the manufacturing organization. A supervisor who does not trust the data will work around the system. An engineer who sees PLM workflows as administrative overhead will keep using spreadsheets. A planner who cannot understand an AI recommendation will ignore it under pressure. A plant manager who sees digital transformation as corporate theatre will protect daily output first.

This is why manufacturing transformation depends on operating routines, incentives, skills, and trust. As AI systems take on more coordination and execution tasks, organizations will need to redesign roles around supervision, exception management, decision accountability, and continuous improvement. The workforce will need to become comfortable working with intelligent systems, questioning them, guiding them, and improving them over time. Increasingly, change management is an integral part of the digital transformation programs.聽

The CXO Agenda: Build the Operating Architecture for Intelligent Manufacturing

For manufacturing CXOs, the priority is not to choose between PLM modernization, smart manufacturing, planning tools, digital twins, GenAI, and agentic AI. These are connected parts of one operating architecture.

The digital thread provides trusted lifecycle context. PLM governs product truth. Smart manufacturing connects operational reality. Digital twins simulate decisions. GenAI changes how knowledge is accessed and created. Agentic AI coordinates action across workflows.

The sequencing will differ by enterprise. One manufacturer may begin with engineering change velocity. Another may focus on supplier-driven quality variation. A third may tackle software-defined product complexity. Another may target downtime, service performance, or regulatory evidence. The architecture can be common, but the value thesis must be specific.聽

The uncomfortable truth is that AI will expose fragmented enterprises faster than it fixes them. If product data is inconsistent, AI will surface inconsistency faster. If processes are poorly governed, agents will accelerate poor decisions. If engineering and manufacturing operate with different versions of truth, GenAI will produce confident confusion. If workforce adoption is treated as a training checklist, expensive systems will sit on top of unchanged behavior.

The manufacturing enterprise is becoming too complex to run through disconnected systems and retrospective intelligence. Leaders now need a digital engineering foundation that can understand the product, sense the operation, govern the decision, and coordinate the response.

That is the real journey from digital thread to agentic operations: building a manufacturing enterprise that can reason, adapt, and execute with discipline.

Author:

Nitin Kumar Kalothia
Associate Partner – Business Consulting Group
乐播传媒视频

The post From Digital Thread to Agentic Operations: What Manufacturing Leaders Need Next appeared first on 乐播传媒视频.

]]> PPWR Compliance Will Fail Without SKU-Level Packaging Data. Is your Company ready? /blog/ppwr-compliance-will-fail-without-sku-level-packaging-data.-is-your-company-ready/ Fri, 12 Jun 2026 09:19:13 +0000 /?p=49529 For Consumer Packaged Goods (CPG) companies selling into Europe, packaging is moving from a sustainability conversation to a compliance, cost, and market-access issue. The European Union Packaging and Packaging Waste […]

The post PPWR Compliance Will Fail Without SKU-Level Packaging Data. Is your Company ready? appeared first on 乐播传媒视频.

]]> For Consumer Packaged Goods (CPG) companies selling into Europe, packaging is moving from a sustainability conversation to a compliance, cost, and market-access issue.

The European Union (PPWR) entered into force in February 2025 and will generally apply from 12 August 2026, bringing new requirements around recyclability, recycled content, labelling, substances of concern, documentation, and Extended Producer Responsibility (EPR).

Many CPG companies believe they still have time to prepare for PPWR. However, operationally, they may already be too late. By the time enterprises identify non-compliant SKUs, validate supplier data, redesign packaging, and complete internal approvals, the remediation window may already be closing.

Beyond the deadline, PPWR is becoming one of the largest packaging data and operational readiness challenges many CPG companies have faced in years.

Why packaging data is now business-critical

A global CPG company may have thousands of Stock Keeping Units (SKUs) across markets, suppliers, plants, packaging formats, and material combinations.

A single beverage SKU, for example, is not just a bottle. It may include glass, an aluminum cap, a front label, a back label, a neck label, inks, adhesives, cartons, secondary packaging, and country-specific artwork. Each component has its own recyclability profile, material composition, supplier documentation, and compliance requirement.

That means a product cannot be assessed only at a broad packaging-family level. PPWR readiness needs visibility at the SKU level. This is where many enterprises discover the first challenge.

Packaging specifications may sit in Product Lifecycle Management (PLM) systems. Supplier declarations may arrive as PDF files. Procurement data may sit in Enterprise Resource Planning (ERP) systems. Sustainability reporting may run through separate tools. Certificates may be incomplete, outdated, or unaudited. Some data may still be managed through spreadsheets.

When compliance teams attempt to assess SKU-level readiness across markets, many discover that packaging information is incomplete, inconsistent, or difficult to trace across products, suppliers, and packaging components.

The cost of this fragmentation can be significant

For large CPG enterprises, fragmented packaging data can translate into millions in avoidable EPR costs, delayed product approvals, supplier non-compliance exposure, late-stage packaging redesigns, and increased audit risk.

For instance, if packaging uses virgin materials, EPR fees may be higher. If recycled content or recyclability scores are weak, redesign may be required. If supplier declarations cannot be verified, the Declaration of Conformity (DoC) becomes difficult to complete. In fact, supplier documentation is emerging as one of the biggest PPWR risk areas. Many companies still rely on incomplete declarations, outdated certificates, inconsistent material composition data, and manually validated supplier information.

The complexity also varies by country. While PPWR aims to harmonize packaging rules across the European Union (EU), companies still need to account for local EPR schemes, labelling expectations, and market-specific implementation across markets. This creates operational complexity across packaging, procurement, regulatory affairs, and supply chain teams.

What many executives underestimate is that PPWR is not just a reporting exercise. It directly impacts packaging design, supplier onboarding, product approvals, EPR cost exposure, and speed-to-market. Companies that wait too long may find themselves reacting through manual data hunts, emergency redesign programs, manual data collection and late-stage packaging redesign efforts.

So where should companies begin?

PPWR readiness begins with three practical steps:

  • Assess packaging data maturity
    Organizations need to identify where packaging data resides, how complete and reliable it is, and whether material composition can be traced consistently across SKUs, suppliers, and markets. Supplier documentation quality and data availability are also critical considerations.
  • Build SKU-level compliance visibility
    Teams should have centralized visibility into recyclability grades, material composition by weight, recycled content, supplier compliance status, EPR cost exposure, country-specific requirements, and supporting documentation readiness.
  • Connect systems and workflows
    PPWR data cannot remain isolated within PLM systems or sustainability reports. Organizations need integrated workflows connecting PLM, ERP, procurement, supplier platforms, documentation repositories, and reporting systems so compliance can be managed continuously rather than assembled manually before audits or reporting cycles.

Where Artificial Intelligence can help

AI can significantly accelerate PPWR readiness by extracting packaging information from supplier PDFs, certificates, lab reports, and specification sheets at scale. It can also identify compliance gaps, flag high-risk materials, benchmark suppliers, and prioritize remediation actions across thousands of SKUs.

Over time, AI-enabled compliance intelligence can also help companies track regulatory changes and understand what needs to be updated across products, suppliers, and markets.

The window to act is narrowing

PPWR readiness will not come from interpreting the regulation at the last minute. It will come from building the packaging data foundation now, while there is still time to trace materials, verify supplier documentation, assess recyclability, manage country-level variation, and redesign packaging where needed.

The organizations that move early will have more time to redesign packaging, renegotiate supplier requirements, reduce EPR exposure, and improve packaging readiness and reduce compliance risk. Those that delay may face rising costs, reactive packaging changes, fragmented supplier data, and increased regulatory pressure close to enforcement timelines.

For CPG companies, the question is whether their systems, suppliers, and teams can produce the evidence needed to prove compliance, control costs, and keep products moving across European markets.

The faster companies can bring packaging data together, the more confidently they can respond to PPWR and the wider shift toward circular packaging.

To explore how CPG enterprises can prepare for PPWR with a structured, data-led approach, read our whitepaper on packaging compliance and PPWR readiness.

Author:

Paritosh Singha
Principal Consultant at 乐播传媒视频

The post PPWR Compliance Will Fail Without SKU-Level Packaging Data. Is your Company ready? appeared first on 乐播传媒视频.

]]>