E = MC² : The Equation That Never Gets Old

 

On Measurement, Continuous Improvement, and Customer Focus — Then and Now

 (A decade and half ago I wrote two linked blogs on Operational Excellence. They are referred at the bottom of this article. When I read them in the context of the world of today, many principles remail the same, but manifestations are different. This article is an attempt to revisit the idea of Operational Excellence in the era of AI and Agents)

There is a particular kind of excitement that technology companies are exceptionally good at, and a particular kind of discipline they are chronically bad at. The excitement is building. The discipline is running. Every new feature, every new product, every new platform gets showered with energy, talent, and attention. The unglamorous work of making sure it all actually works, consistently, reliably, at scale, day after day, gets left to whoever is available, measured by whatever is easy to measure, and improved only when something breaks badly enough to be embarrassing.

This is not a new observation. But it has become a vastly more consequential one. Because we are now deploying AI systems and autonomous agents into operational environments at a pace that far outstrips our willingness, or our ability, to govern them. And the cost of that gap is no longer measured in minor inefficiencies. It is measured in compounding, invisible failures,  in decisions that are wrong by design, in resources consumed by systems nobody is watching, and in customers quietly harmed by processes nobody is truly accountable for.

The answer to this is not more technology. It is better operational discipline. And the framework for that discipline is simpler than most people think.

We call it E = MC²: Excellence, derived from a culture that Measures relentlessly, pursues Continuous improvement, and never loses sight of Customer focus. These three elements are not independent. They are a virtuous cycle, each one feeding the others, each one incomplete without the others. Understanding how they connect, and how to make them real, is the central challenge of operational management in any era. Including this one.

Why Measurement is Hard, Even for People Who Handle Data for a Living

There is a paradox at the heart of the IT and services industries. These are sectors whose entire value proposition rests on data, on capturing it, organising it, analysing it, and making it useful. And yet, in practice, their internal operational measurement discipline is often surprisingly immature. The processes that organisations build for their customers are rarely applied with equal rigour to their own operations.

The reasons are not mysterious. The glamour in these industries flows toward novelty, toward "cool functions," "exciting features," and "latest gadgets." Boring pursuit of efficiency gains simply does not compete for talent or attention. When a senior engineer has a choice between building something new and spending six weeks instrumenting something old to understand why it sometimes fails, the outcome is predictable. And so operational measurement tends to happen reactively,  in response to a crisis, a customer complaint, or a regulator's inquiry,  rather than as a continuous, proactive discipline.

To learn how to do this differently, it helps to look at industries that never had the luxury of treating operations as an afterthought.

The hazardous chemical process industry is an instructive model, and not an intuitive one. It has been around for centuries, long enough to have matured its operational practices through hard experience. Its product lines are largely commoditised, which means margins are thin and efficiency is not optional, It is existential. The consequences of process failures are sometimes fatal, which means the scrutiny.  public, regulatory, and internal, is unrelenting. And its processes are integrated end-to-end, with limited visibility into what is actually happening inside the pipes at any given moment, which forces a culture of strong monitoring and control.

These are, in fact, exactly the conditions that characterise complex digital operations today. Thin margins. High stakes. Limited internal visibility. Regulatory scrutiny. The main difference is that the chemical industry has spent decades building the measurement culture to match these conditions, while the technology and services industries are still, in many cases, at the beginning of that journey.

From that more mature tradition, three elements of measurement discipline emerge as foundational.

The Three Pillars of Measurement

Flow Management: Count Every Transaction

The first pillar is what might be called micromanagement of the operation, not in the pejorative sense of hovering over people, but in the precise sense of tracking each input through each sub-process it was meant to traverse, confirming it arrived correctly and without error.

This sounds obvious. In practice, it is done poorly, or not at all, especially for processes that are still evolving. When a new system or workflow is still being refined, exceptions proliferate. And exceptions, in young computerised systems, have a dangerous tendency to become invisible,  swallowed by automated retry mechanisms, silently skipped, or classified as edge cases that never quite make it onto anyone's priority list.

The consequences of poor flow management are almost always financial and reputational, and they tend to be discovered embarrassingly late. A large bank once sent letters to its credit card customers admitting that it had not been tracking transactions correctly, and asking recipients to settle on the basis of their own personal records. The transactions were not hidden. They were not stolen. They had simply not been tracked. The systems were running; the accounting was not. When providers of transaction billing solutions are brought into organisations for the first time, the revenue leakage they surface, from transactions that fell through the cracks of inadequately monitored processes, is routinely staggering.

These are not exotic failures. They are the entirely predictable consequence of building systems without building the measurement infrastructure to watch over them.

Capacity Management: Know Where the Bottlenecks Are Before They Happen

The second pillar is the macro view, tracking the capacity of processes, people, service providers, and machines in order to anticipate bottlenecks before they become crises. This requires establishing trend measures for each element and monitoring them continuously, not just periodically.

Capacity management is especially treacherous in computerised environments for a structural reason: shared resources. Network infrastructure, compute capacity, database connections,  these are all consumed by multiple processes simultaneously, and the utilisation curve for each process grows differently. A system that appears to have adequate capacity for today's workload may have none for tomorrow's if the growth curves are not being watched and modelled.

Two particular categories of hidden capacity consumers deserve special attention, because they are pervasive and almost universally underestimated.

The first is queries. Every business generates a need for data extracts — for management reporting, regulatory compliance, customer service lookups, and ad hoc analysis. These queries consume the same production capacity as the operational processes. And they are disproportionately likely to be written inefficiently, because they are typically assigned to junior resources or business analysts who lack the training to optimise them, and because there is very little accountability for query performance until something breaks. A query that was meant to run once becomes a standard report. A standard report that runs nightly becomes a standard report that runs hourly. The cumulative resource consumption creeps upward invisibly until, one day, the system slows to a crawl during peak operational hours, and nobody can immediately explain why.

The second is design debt. For most software developers, the genuine satisfaction is in building features. Once a feature is live and functioning, interest moves on. The pressure to optimise, to refactor, to improve efficiency, runs directly against the incentive to ship the next thing. The result is that bespoke systems accumulate performance inefficiencies that are never addressed , not because fixing them is technically difficult, but because nobody is measuring the cost of leaving them in place, and nobody is accountable for the cumulative drag. In most organisations, there is scope for at least a hundred percent improvement in process efficiency simply by addressing the worst of these design inefficiencies,  but only if someone is measuring for them.

Service Levels: Commit to the Customer, Then Track the Commitment

The third pillar is where measurement connects most directly to purpose. The most powerful mechanism for ensuring that measurement and improvement activity stays focused and meaningful is to define, publicly and clearly, what the organisation is actually committing to deliver to its customers.

There is an important distinction to draw here between a Service Level Agreement and what might be called a Customer Service Commitment. An SLA is a floor — a formal definition of the minimum below which the organisation will try not to fall. It is a legal and contractual instrument, and it tends to create a culture of adequacy: as long as we are above the floor, we are fine. A Customer Service Commitment is something different. It is a genuine aspiration — a statement of what the organisation sincerely believes it can and should deliver, at a level meaningfully above the minimum.

This distinction matters because people and systems tend to optimise for what they are measured against. An organisation that measures against its SLAs will manage its operations to the SLA threshold. An organisation that measures against its Customer Service Commitments will manage its operations to the standard it actually believes in.

The mechanics of tracking these commitments deserve specific attention. Time-series data, tracking key performance parameters not just at a point in time, but continuously over time. is essential for detecting trends before they become crises. A single data point t ells you where you are today. A trend tells you where you are going. And it is the trend that matters operationally, because by the time a single bad reading turns into an obvious crisis, the window for preventive action has usually closed.

It is also worth having the team that tracks customer commitments sit separately from the team responsible for operations. This is not about distrust. It is about the structural reality that an operations team under pressure will, understandably, interpret ambiguous data in the most favourable light available. A separate tracking function provides the independent visibility that makes measurement honest.

Continuous Improvement: From Counting to Acting

All of this measurement serves one purpose: enabling the organisation to improve, continuously, before it is forced to by failure.

This is more difficult than it sounds, because the culture required to use data for continuous improvement is fundamentally different from the culture most organisations actually have. In most places, data tracking reports are either compliance artifacts — produced to satisfy an audit or a boss, or post-mortem instruments, pulled out after something has gone wrong to explain what happened. Neither of these uses generates improvement. They generate paper trails.

The culture of continuous improvement requires something harder: the regular, disciplined use of data to find problems that have not yet caused visible failures. This means looking at trend shifts before they become obvious. It means investigating unusual volatility in metrics that are still technically within acceptable bounds. It means preferring prevention over heroism — which runs directly against the organisational instinct that rewards the person who fixed the crisis rather than the person who avoided it.

To make this a habit rather than an occasional initiative, it has to become a ritual. The cadence of reviewing operational data, identifying trends, assigning root cause investigations, and tracking improvement actions has to be embedded into the organisation's regular rhythm, not treated as an additional burden on top of "real work." When it is done well, it does not feel like overhead. It feels like the organisation learning from itself in real time.

The AI Era Changes the Stakes, Not the Principles

Everything described above was relevant in 2009. It is more relevant now by an order of magnitude.

The introduction of AI systems and autonomous agents into operational environments does not render these principles obsolete. It makes them urgent. Because AI introduces a new category of operational actor, one that is more capable, more opaque, and more consequential than anything that preceded it,  into environments that, in many cases, barely had adequate measurement cultures to begin with.

The most important thing to understand about AI in operations is that it fails in ways that are qualitatively different from how conventional software fails. Traditional software fails visibly. A system crashes. A transaction errors out. A service goes down. These failures are, in their own way, manageable, because they announce themselves. AI fails silently. A model that has drifted from its training data continues to generate outputs that look confident and coherent, while producing decisions that are subtly, systematically wrong. A recommendation engine with a bias baked into its training data does not flag an anomaly; it just consistently disadvantages certain customers. A document processing agent that hallucinates does not throw an exception; it produces a confident, plausible, and incorrect result.

This is the flow management problem, rewritten for the age of AI. Every AI-powered process needs a systematic accounting not just of what it produces, but of the quality, reliability, and drift of those outputs over time. The input went in; the output came out, but was the agent's reasoning within acceptable bounds? Was its confidence calibrated? Were there exceptions that the system silently swallowed rather than escalating to a human? The revenue leakage and customer harm that flow from unmonitored AI processes make the untracked credit card transactions of an earlier era look quaint.

The capacity management problem is also fundamentally transformed. AI models are the most resource-intensive entities ever introduced into enterprise operations. A single large model inference can consume more compute than an entire legacy application stack, and when multiple agents run concurrently, as they increasingly do, in agentic architectures where AI systems orchestrate other AI systems, the shared infrastructure constraints become genuinely complex to manage. The hidden capacity consumers have multiplied: poorly designed prompts that generate verbose, expensive outputs; inefficient agent chains that make redundant calls; one-time AI automations that quietly become permanent fixtures eating into rate limits and GPU capacity. None of this shows up on a standard IT dashboard unless someone has specifically built the instrumentation to see it.

And the service levels question, always the most important one, has become the most morally loaded. When an AI agent makes a decision that affects a customer,  about a loan, a medical triage, a service entitlement, a pricing offer,  that customer has a right to understand it, challenge it, and have a human correct it. This is not only a regulatory requirement in an increasing number of jurisdictions. It is the operational definition of customer focus in a world where the agent, not the employee, is the primary interface. A Customer Service Commitment in the AI era must include commitments about explainability, human override, and recoverability, not just turnaround time and accuracy.

The Measurement Culture the AI Era Demands

Bringing this together, what does operational excellence actually look like for an organisation running AI at scale?

It looks like flow management that tracks not just whether transactions were processed, but whether the AI agents that touched those transactions acted within defined parameters, and that surfaces exceptions rather than silently absorbing them.

It looks like capacity management that instruments AI resource consumption with the same rigour that a hazardous chemical plant instruments its pressures and temperatures,  understanding not just current utilisation, but growth trajectories, shared resource constraints, and the hidden consumers that creep up over time.

It looks like Customer Service Commitments that extend into the AI layer,  that define not just what will be delivered, but how decisions will be explained, how errors will be corrected, and how human accountability will be maintained even where AI is the primary actor.

And it looks like an organisation where data is used not to satisfy bosses or produce compliance artifacts, but as a genuine tool for continuous improvement by everyone at every level. Where a shift in a trend line is treated as a signal worth investigating, not as noise to be explained away. Where prevention is valued as much as heroism. Where the excitement of building is matched, at last, by the discipline of running.

The Hardest Part Has Not Changed

In the end, the measurement framework, however well designed, is only as good as the culture that uses it. And culture is stubbornly human. The data is the easy part. The hard part is persuading organisations and the people within them to use data as a tool for honest self-improvement rather than as a performance to be staged for external audiences.

That challenge has not changed in sixteen years. It will not change in the next sixteen either. What changes is the cost of getting it wrong.

Give the people the facts, about their processes, their agents, their customers, their capacity, their failures, and their potential,  and they will, if the culture is right, do the right thing.

That is still the bet. It is a harder bet to lose than it has ever been. But it is the only bet worth making.

"The customer does not care about your dashboard. They care about what happened to them. Those are not always the same thing."

Retaled Posts

Learn to count- both Blessings and Failures

E = MC Squared

Scaling up: The Art of the Impossible - Part II

In Part I of this post, I had set the context for understanding uncertainty and its impact. Part II looks specifically at uncertainty and scale-up.

Generally we give a lot of attention to business uncertainty, but seldom do we give sufficient attention to operational uncertainty that is faced by the team members on their day work. Managing such operational uncertainty therefore is a very critical factor when we attempt to scale up any operation or any business.

Normally the core team that set up any operation or business successfully will consist of highly motivated, highly skilled, high performance individuals who are comfortable in decision making under uncertainty. Once the operations are on steam and ready to scale up we need to work with a different set of people. We cannot afford to have the same calibre people when the operation is scaled-up. It is not just a question of financial affordability; such people will not survive long in a regular operational environment. They are normally impatient lot and in constant search for new dreams.

Therefore we have to have processes to get work with ordinary, risk averse, simple people who want to be led. As Lee Iacocca pointed out “if you are a brilliant person you may be able to do the work of 30 people; but if you are a brilliant leader who can get work out of 1000 ordinary people and then you achieve much more”

One of the major weaknesses of normal people is their inability or discomfort to take decision under uncertainty. They need clear algorithm on how to address each eventuality. In the absence of such clear standard operating procedures (SOP), many people avoid taking decisions or become inefficient in taking decisions. In this case they are almost like computer software that hangs in the absence of sub routines to handle all cases. As in the case of elegant computer programs, the SOPs should have dependable error handling, clear exception reporting and escalation rules in place for un-programmed cases. Otherwise system hangs or misbehaves. Only then we can scale –up with “Intel people” like Google scale up with “Intel boxes”

We have to accept the reality that the vast majority of people need clear delineation of tasks to help them achieve maximum productivity. As Chris Argyris observes in the article ‘Empowerment: The Emperor’s New Clothes’ published in Harvard Business Review “Both research and practice indicate that the best results of reengineering occur when the jobs are rigorously specified and not when individuals are left to define them”

The first thing we need to do in our endeavour to reduce uncertainty is to map organizational goals to group deliverables and break down group deliverables preferably up to the individual level. Once the deliverables are broken down, then we should try to develop standard operating procedure or business rules for as many cases as possible. This has to be a continuous process and there should be process in place to continuously identify cases where SOPs or business rules are developed.

One of the risks when we have processes that depend on SOPs heavily is that the people get to be process oriented instead of result oriented. This is one of the major weaknesses of bureaucracy. It is here that we need to teach human beings to also use his human intelligence and not to behave like computer programs. We should clearly teach each person and team to appreciate what the SOPs are trying to achieve as results. We should empower the process owners to innovate and improvise on the SOPs when there are exceptions. Here again we should try to provide boundary conditions within which they have to flexibility. This will reduce uncertainty even with flexibility.

On the other hand we should also work towards helping people to learn the art of being comfortable under uncertainty because human beings who can make sensible judgement under uncertainty are key assets in any team. Although genetic trait influences this skill quite a lot, this is still a skill that can be strengthened by training and support.

We should also have a way to identify and encourage people who are adept at this skill. Most importantly we should ensure that people who rise up to leadership are the people who can handle uncertainty and also who can reduce uncertainty for their team. It is here that many organisations fail. They get impressed by people who have delivered excellent results based on their skill and knowledge in situations or functions where ambient uncertainty is low. Then we promote them to levels where they have to mange uncertainty which are outside their domain of expertise. This happens very often with respect to technical people. Then these poor souls (smart engineers, doctors, lawyers, accountants) like fish out of water fail and the whole team suffers.

When we develop our scale-up strategies this is one dimension we forget and we focus on everything else like process, technology, people, finance and so on. We have to include operational uncertainty management as a key dimension with which we qualify our scale-up strategies. Else the best of strategies will fail on account of minds that freeze under uncertain outcomes.

Beyond all this theory lie commitment, conviction and faith that is beautifully described in alchemist “If you believe in something the whole world will conspire to make it happen for you”.

“Nothing great has ever been achieved except by those who dared believe that something inside them was superior to circumstances.” Bruce Barton

Scaling up;The Art of the Impossible - Part I

There is one thing certain in our life; and that is uncertainty. Uncertainty about of life, our future, our family; everything in our life is uncertain. Most people are not comfortable to deal with uncertainty. But we have learned to accept such uncertainties on which we have absolutely no control, with certain amount of equanimity. Sometimes some of us try to reduce uncertainty about our future by visiting an astrologer, palm reader, so on and so forth. Linda Goodman and her ilk have made fortunes for themselves by exploiting this fear of uncertainty.

When it comes to areas where we have some control, like education, career, wealth etc, we are more uncomfortable with uncertainty. One of the primary reasons why we go to colleges and acquire degrees is to reduce uncertainty in our life. When we take up employment in a company instead of starting our own, we are trying to reduce uncertainty because the company has taken many of the key decisions with respect to the line of business, technology, product, process etc and we form a part of the team in implementing the strategies that have already been decided. Even in this case there may be still high level uncertainty as we go up in the ladder and/ or if we have direct business responsibility. When we take up a career in government we are still reducing uncertainty, as normally there is very limited systemic compulsion for results (as against process compliance) in many of the bureaucratic positions. (But there are many bureaucrats who try to do justice to their inner compulsion to make a difference)

I once did an experiment with a large group of my colleagues as a part of our internal training program. I gave three problems to all the participants and asked them to choose one problem they would take up to solve. The first problem was long, it had quite a lot of brute force computation to do; but the algorithm was sort of clear. The second problem was a logical puzzle. In this case the end result was quite measurable; it was evident that there would be an algorithm to solve, though the algorithm was not clear. The third problem had no clear algorithm or no one right answer. Most of the people chose problem 1, and only few chose problem 3. This kind of result will be common among most of the people.

There is one thing certain about uncertainty; that the success of any idea or project or company or organization is highly dependent on how we manage uncertainty for ourselves and for our teams.

To be continued ....

Certainty is the mother of quiet and repose, and uncertainty the cause of variance and contentions. Edward Coke

Ramblings on User Interfaces

I recently read an interesting fact about the way men’s loo has been designed in Schiphol airport, Amsterdam. The authorities etched image of a black housefly in to each urinal. The staff of Kieboom, the economist who directs Schipol’s building expansion, found out that these etchings of fly-in-the-urinals improved the aim and reduced ‘spillage’ by 80%.

In the modern wired world, we are now increasingly moving towards ‘self service’ in banks, in buying tickets, and to file tax returns. Even in such online machine based services, there is a need to be conscious about user interface. We see some online sites which have understood the normal human habits of observation, conscious and unconscious behaviours and are very intuitive for the user. The user is able to sail through the steps in a jiffy.

Very often the techies who design the systems get carried away by the functionalities and forget the user experience. At best (with or without the help of some creative types) they fill the interface pages with some wild graphics and gadgets which instead of guiding the users distracts them. They often consider the effort needed to understand the user a pain in the wrong place.

I think one of the key contributors of the wide following of Facebook in comparison with many other social networking sites is such an intuitive experience for the user. I am sure most of us will agree that the iPod and iPhone are outstanding examples how devices designed with user experience in mind often turn out to be winners.

But if we spend time and effort to really analyze the service being offered, the nature and expectation of the various users who visit the site or even the service counters we can identify very many ways to help the user and in turn get more out of the infrastructure we have created. This may even help us to reduce our service cost.

This becomes even more important if we are servicing mostly one time users or occasional users. In such cases we really have to spend time to anticipate the confusion that comes to the user’s mind. In such cases we should have a continuous process of taking feedback from a large cross section of users to refine our offering.

We need to remind ourselves that the primary purpose of the user interface is to make the user experience a pleasure and not to prove how bright the developers are.

Let us take a look at another important dimension to designing of user interfaces. Smart user interfaces can also act as a mechanism to influence client choice, especially the default options provided. This provides an opportunity as well as a moral responsibility to the designers of the interface. Some obvious example that comes to mind is the legal requirement that the acceptance button in the user agreement for by default should not be on “I Accept”.

We don’t need legal directions to act responsible. We have to take care that the default options we provide are not detrimental for the ‘absent minded’ user. In some of the developed societies legal boundaries have been defined to a good degree. With the rapid growth in online self service counters here in India we it is high time we give attention these 'human factors'.

Learn to count- both Blessings and Failures

In my previous posting "E = MC Squared” I had written about the three drivers of operational excellence that we focus on. They were Measurement, Continuous improvement and Customer focus. This posting is a little more detail on the framework of measurement that we try to institutionalize. There no rocket science here; just one of the ways for structuring and prioritizing various matrices.

The Information Technology (IT) and Service industries, in spite of their exposure to data handling, data mining and their familiarity with money value of transactions, often messes up in the discipline of systematic measurement for operational efficiency. Their operational measurement discipline is not yet matured because the glamour and focus in these industries are still ‘cool functions’, “exciting features” and “latest gadgets’ than boring pursuit of efficiency gains.

So we turned for some lessons to process industry; especially hazardous chemical industry. The reasons were manifold and can be summarised as below.

1. The process industry has been around for hundreds of years and has matured over period of time whereas IT and Services industries are quite young and still evolving.

2. Many of their product lines have been commoditized with very low operating margins unlike the IT and Service industries which still enjoy significant margins arising out of novelty and innovation. This meant that the process industry has to squeeze out efficiency wherever possible.

3. In chemical process industry the cost of process breakdowns and safety breaches are often fatal and therefore the extent of public attention, scrutiny and audits is quite severe.

4. In process industry mostly the processes are integrated end-to-end with less control and knowledge of what is happening inside the pipes. This necessitates strong monitoring and control.

The framework of measurement we evolved has thus been helped a lot by the learning from the process industry. The three key elements of this framework are the following.

1. Flow management (Micromanagement)

These are matrices that keep track of each of the inputs to ensure that it passes through each process/ sub-process it was meant to traverse and that too without error. This becomes even more critical when some of the processes are quite new and evolving because in such cases the exceptions gets to be the norm and tend to get ignored; especially in computerised processes.

These errors lead to customer discontent and even revenue leakage. I remember long ago when many people received a letter from one of the large banks which admitted that they had not tracked the credit card transactions correctly and enjoined the recipients to make a payment on the basis of their own bills. (I am not sure how many actually paid. This is not a made up story either).

One of my friends who provide transaction billing solutions to large number of banks and telcos shared with me the extent of leakage he is able to unearth when his system is introduced first time.

2. Capacity Management (Macro management)

These are matrices that track the capacity of processes, people, service providers and machines. We try to establish and evolve measures for trends in capacity utilisation of each element to avoid surprise bottlenecks.

This continuous monitoring is even more critical in computer based operations as many of the computer systems and network equipments are shared resources for multiple processes and the utilisation is build up for each of the processes would be different. Very often the process managers give scanty attention to the capacity requirement of their processes and how this capacity utilisation varies with volume.

In computerised processes there is another often neglected component of capacity grabber. The queries needed by the business or regulator. These queries on one side use the same production capacity. On the other end very often these queries are prepared by the junior most programmers who often develop quite in-efficient queries that hog resources. Mostly these onetime queries become a norm and end up quietly eating up resources.

Another area which eats up capacity is the weakness in the design itself. For most of the programmers, the kick is in developing features. Once the features are up and running he has lost his interest and is keen to move to the next project. At the time of feature development these cool cats seldom give importance to program efficiencies and once they are developed they are too lazy (and often don’t even know) to spend the time and effort to fine-in my experience there will be scope for at least 100% improvement in process efficiency in most of the bespoke programs.

3. Service Levels

The best way to ensure focus in measurement and improvement is to have clearly defined service levels that we are willing to commit to our customers. We call it the Customer Service Commitments (CSC). These involve commitments on Turn-Around- Time (TAT), Quality and Cost.

We try to build time-series data of these parameters at every key process and service provider level. This time series data provides early triggers in terms of trend shifts and unusual volatility.

We also try to have a separate team (other than the team responsible for operation) to track the commitments to the ultimate customer.

What Next?

The next thing to having data in place is how we use the data. I believe that is the more difficult part because it involves change in habits and practices of human beings. And that is not easy! Very often the data tracking reports are seen and used as measures for compliance or to satisfy whims of the bosses.

Excitement is in trouble shooting, exception handling and heroism. Not in prevention of trouble. It is more interesting to fix people than systems.

What we continuously try is to inculcate a spirit of looking at data as a tool for continuous improvement by everybody at all levels. To make this a culture and not a ritual.This is because we believe that we can scale-up and excel only when each of us learn the art of decision making that is founded on data.

“Give the people the facts, and they will do the right thing??”