As business leaders are navigating an increasingly complex digital landscape, the success of a true technology transformation is no longer about its going live but about whether it can keep delivering measurable business value long after execution. For large, process-intensive companies like those in the pharmaceutical industry, this consistency challenge becomes more crucial as ERP, SaaS, OT, data, and emerging technologies must align together without compromising business outcomes.
In an interaction with CIONOW, Chitti Babu, Group CIO at Aurobindo Pharma, discusses what sets transformations that deliver lasting value apart from those that fade; the key metrics of an operating model, the gap between technology design and business reality, and where blockchain justifies its complexity.
He also shares how organizations can balance global standardization with local flexibility, and outlines three principles that future CIOs should build into their operating models from day one.
What patterns do you see in digital transformations that sustain value versus those that fade after go-live?
The decisive factor is whether go-live is considered as the conclusion of delivery or the commencement of value capture. Programmes that fade typically showcase benefits owned by no one, funding that terminates at cutover, adoption measured by training attendance rather than behavioural telemetry, and an executive sponsor whose attention has moved elsewhere. Sustained transformations, by contrast, assign benefit ownership to named business leaders, retain persistent product teams beyond hypercare, and embed outcomes within the monthly operating review. A useful heuristic holds that the half-life of a transformation is determined in the ninety days following go-live, not in the year preceding it.
In practice, what should a transformation operating model include?
A credible operating model is based on three pillars: roles, rituals, and decision rights. The roles encompass a single accountable executive per value stream, a small and senior transformation office, empowered product and process owners, a change lead measured on behaviour rather than communications, and an architecture authority that enables rather than obstructs. The rituals compress a weekly decision forum with a genuine decision log, monthly value reviews tied to corrective action, and quarterly portfolio re-prioritization with explicit licence to terminate underperforming initiatives. Decision rights are the most neglected element that requires a one-page map identifying a single accountable decision-maker for each class of decision, supported by a 48-hour escalation service level.
In complex ERP/SaaS/OT environments, where do you most often see gaps between tech design and how the business actually works?
In ERP, SaaS, and OT landscapes, the voids are remarkably predictable. Systems are configured for the standard flow while the business operates on exceptions; master data drifts from operational reality; OT and IT assign different meanings to the same events; and end-to-end processes break across SaaS boundaries with no single owner. Beneath these symptoms lies a common root cause: design workshops engage process owners describing the process as it ought to be, rather than the practitioners who execute it daily. Direct observation of actual work invariably proves more instructive than any workshop documentation.
For which enterprise problems is blockchain truly the right tool for trust or coordination, and where is it overkill?
Blockchain earns its complexity only when four conditions coincide: multiple organisations that do not fully trust one another must agree upon a shared state, and no party is acceptable as the central operator; trade finance, supply-chain provenance, inter-company reconciliation, and tokenised settlement being the credible examples. It is overkill where a single enterprise owns both the data and the trust problem, where an acceptable central party already exists, or where the true deficiency is data quality at the source. The honest screening question is simply this: if the problem were solved with a shared database operated by a neutral party, what would materially break? If the answer is nothing of consequence, distributed ledger technology is not required.
What non-technical blockers have most slowed blockchain initiatives you’ve seen?
The impediments that prove fatal are rarely technical. Consortium governance, who funds, who operates, who admits members, and who owns the code; consumes two to three times longer than platform construction, and high-profile ventures such as TradeLens succumbed to precisely this, compounded by the bootstrap problem whereby no participant joins until critical mass exists. Legal enforceability, data ownership, and privacy concerns, immutability against erasure rights and metadata leakage among competitors, stall sign-off for years, while fragmented standards and business models that burden one party with costs and reward another with benefits complete the picture. What is noticeably missing from this catalogue of failure is the technology itself
How are blockchain-style ideas (immutable logs, shared state, programmable rules) influencing mainstream enterprise architecture, even without full DLT?
The most enduring legacy of the distributed ledger wave is separating its concepts from its platform. Immutable, append-only logs now support event sourcing and cryptographically verifiable audit trails; content-addressed integrity is appearing in software supply chains and regulatory reporting; programmable rules have re-emerged as policy-as-code; and decentralized identity is quietly maturing in KYC and credentialing. The pattern remains the same: enterprises kept the guarantees; integrity, provenance, shared truth, and executable agreements, while removing the consensus mechanism wherever a trusted operator exists.
How do you balance global standardisation with local flexibility when designing transformation programmes?
The efficient framing is to standardize decisions, not merely processes. This entails defining a deliberately small non-negotiable core: the data model, chart of accounts, master data, controls, and integration backbone, typically 60-80% of the whole, and classifying every local deviation request into three categories: legal mandate, genuine competitive differentiator, or inherited habit, the last of which constitutes the majority and must be absorbed into the standard. Localization must be engineered as a paved road through extension layers and configuration, never as a waiver, and regions must hold a formal voice in the design authority rather than recourse to escalation after the fact. Finally, sequencing should begin in a market of middling complexity and neither the simplest, which teaches nothing, nor the hardest, which overwhelms.
What three principles would you tell a future CIO to embed in their operating model from day one?
First, own outcomes rather than systems: structure the operating model around value streams with named business owners; for the moment, it is organised around applications and projects, and one is managing cost rather than transformation. Second, design for continuous change rather than episodic programmes, through stable, funded product teams, architecture as guardrails rather than gates, and rituals that render re-prioritisation routine. Third, treat data ownership and decision rights as first-class citizens of the operating model, since transformations are seldom undone by technology but almost always by unowned data and undecided decisions. Embed these three disciplines from the first day, and every subsequent challenge becomes materially easier to resolve.
