Analytics at Work: Smarter Decisions, Better Results

1. 1Locate the "workhorse" repetitive decisions in a core process — the high-volume, well-defined-criteria decisions (e.g., pricing an insurance policy) — because these are the ones that reward embedding.
2. 2Map the target process onto the ladder of analytical applications: confirm you have clean, integrated, common data at the base before attempting any higher rung.
3. 3Climb the ladder in order — segmentation, then differentiated action, then predictive action — and refuse to skip rungs, since skipping produces "nasty falls" and compromises performance.
4. 4Redesign the process so the analytic output is applied automatically inside the workflow, rather than requiring a manager to interrupt work to run an analysis (the flaw that made early decision support systems fail).
5. 5At the institutional-action rung, wire prediction and differentiation into the ongoing process so it executes without human initiation; at the top rung, add real-time optimization so the process adjusts on the fly to hold optimal yield.
6. 6Ask four diagnostic questions per process area: How high have we climbed? How high can we climb? How high does the market want us to climb? Have we compromised performance by skipping or only partially covering a rung?
7. 7Keep tending lower rungs while you climb — data quality and segmentation below you still need attention as you move up.
8. 8Set up a small program management office to coordinate embedding projects across silos, and secure senior-executive support for the deployment methods, not just their nominal involvement.

Auto insurance pricing is the passages' explicit case of embedding done right. The decision is repetitive and has well-defined criteria, so you design an automated process around it instead of asking an underwriter to stop and run a manual analysis each time. Clean, integrated data on customers and events feeds statistical segmentation of policyholders; segmentation enables differentiated pricing per segment; predictive models forecast likely response or loss by segment; and at the institutional-action rung those predictions and differentiated actions are embedded so pricing is set automatically as each application flows through. Reach real-time optimization and the pricing process adjusts on the fly to maintain optimal yield. The insight is acted on routinely and automatically — which is what distinguishes embedding from a report a manager might consult, or might ignore.

• If the decision is repetitive and has well-defined criteria, then embed it as an automated process; if it is one-off or ambiguous, don't force a formal model on it.
• If the base data isn't accurate, consistent, integrated, accessible, and relevant, then stop climbing — fix data before attempting differentiated, predictive, or optimized action.
• If using an analytic tool forces managers to interrupt their work to run an analysis, then it isn't embedded — redesign it into the workflow.
• If you're tempted to spread embedding across many targets while the organization is still learning, then focus on one major target and a few minor ones instead.
• If the market only wants you at a lower rung, then don't over-invest climbing higher — match the rung to where payback is greatest.

• Skipping rungs — jumping to prediction without solid segmentation or clean data; the tell is unstable results and "nasty falls" in performance.
• Treating decision support as embedding — the tool sits beside the workflow, so managers must interrupt work to use it and the application "rarely had a significant impact."
• Leaving analytics as a scattered, siloed activity — pockets of analytical people or ad hoc apps built "on the sly"; the tell is no enterprise view and no automatic action.
• Partially covering a rung and moving on — the tell is compromised performance you can't explain until you audit which rung was left half-done.
• Spreading efforts too thin across too many targets before the organization has learned; the tell is many stalled embedding projects and no one differentiating win.

• ▸Target process — name the workhorse business process being embedded.
• ▸Repetitive decision + criteria — the recurring decision and its well-defined decision rules.
• ▸Current rung — where this process sits (data / segmentation / differentiated / predictive / institutional / real-time optimization).
• ▸Data readiness check — is base data accurate, consistent, integrated, accessible, relevant? (Y/N per attribute).
• ▸How high the market wants us — the rung customers/competition demand.
• ▸Skipped or partial rungs — list any rung below that's incomplete and needs attention.
• ▸Automation point — where in the workflow the insight is applied automatically, no manual interruption.
• ▸Next rung + action — the one rung up to pursue and the concrete change required.
• ▸Owner / PMO coordination — accountable analyst and program-office link plus the executive sponsor backing the method.

1. 1Separate data from transaction systems so analysts can find and manipulate it: build toward an enterprise data warehouse (EDW) that cuts across functions and business units, not proliferating single-purpose data marts. Access is the precondition for any analytical culture — you can't argue from data people can't reach.
2. 2Install front-end capture and validation processes so there is little cleanup later, then certify the trustworthy versions. Follow Montana State Fund: audit key data elements, and mark the official, audited versions so people know which numbers are authoritative and which are 'selected events and partial data.'
3. 3Reward the specific behavior of pushing back on unsupported claims. The tell that culture is shifting is when someone in a meeting says 'You can't use those isolated examples — here's a report based on all the data from that period.' Name and praise that move publicly when it happens.
4. 4Recruit leadership deliberately: you need the CEO in your corner to be a full analytical competitor, but any employee can move the organization more fact-based. Find analytical leaders who care about fact-based decisions, and let them mobilize people, money, and time toward it.
5. 5Focus analytics where a small improvement multiplies — Tom Anderson's test of a 'multiplicative' business (e.g., retail, where a small profit-margin or lift gain gets multiplied across many sales). Prove the culture with wins on high-leverage targets, not scattered projects.
6. 6Manage the equilibrium of supply (data, technology, analysts) and demand for analytics across the enterprise. When local owners hold data hostage, reward them for giving it up as an organizational resource — or slap their wrists for holding on to it.
7. 7Build over time, not all at once, and along multiple fronts: a portfolio of projects, some technical, some organizational/human. Be a 'plugger' — persistent — because changes to processes, systems, culture, and strategy do not happen overnight.
8. 8Blend art and science: teach leaders to use analytics whenever possible while knowing the limits — when to use intuition. A culture that pretends every decision reduces to data loses credibility as fast as one that runs on gut.

Montana State Fund, a workers-compensation insurer, had chronic data-quality and integration problems in the late 1990s and borrowed tactics from data-piracy prevention. In 2006 it launched an initiative certifying key reports and analyses with digital watermarks: over seventeen hundred data elements extracted from core applications were audited and marked as the official versions. Users could print watermarked reports but couldn't download the data without losing the watermark, keeping unofficial copies from circulating as if authoritative. The cultural payoff showed up in meeting behavior. Al Parisian, head of IT and strategy, described sitting in meetings where people argued from selected events and partial data — and watching others reply, 'You can't use those isolated examples. Here's a report based on all the data from that period.' Parisian knew the approach was working when he saw that pushback happen. The lesson: a trusted, watermarked data platform is what makes 'seek data, not stories' enforceable rather than aspirational.

• If someone could share your customers, markets, inventory, suppliers, or analytical projects now or in the future, then treat their data as part of one enterprise and align common definitions and infrastructure; if not, don't force integration.
• If a business unit and a distant unit share nothing operationally (GE's German wind-turbine clients vs. Thai washing-machine buyers), then don't share customer data across them — but do share where talent management or volume purchase agreements overlap.
• If you're picking an analytical target, then choose the 'multiplicative' spot where a small improvement gets multiplied across many transactions, and build the data warehouse (e.g., customer data) that supports that future strategy first.
• If a decision is being made on a story or isolated anecdote, then require a report based on all the data for the period before accepting the claim.
• If analytics can't decide it and judgment is required, then say so explicitly and use intuition — knowing the limits protects the credibility of the analytical culture.

• Proliferating data marts instead of an integrated EDW — the tell: two groups bring conflicting numbers to the same meeting and no one can say which is authoritative.
• Arguing from 'selected events and partial data' and having it stand unchallenged — the tell: anecdotes win debates and nobody asks for the full-period report.
• Pinning the whole effort on the CEO and waiting — the tell: analytical initiatives stall whenever the CEO is distracted, because no non-CEO leaders were empowered to push.
• Expecting fast transformation and abandoning ship — the tell: leaders quit after one project instead of plugging persistently across processes, systems, and culture.
• Over-integrating a diverse enterprise (forcing GE-wide customer analytics) or hoarding data locally — the tell: units either resent forced sharing or refuse to release data as an organizational resource.

• ▸Decision under review: state the claim or choice being made
• ▸Evidence type: is it a story/anecdote or data from all relevant records?
• ▸Data source & authority: which certified/audited (watermarked) report backs it?
• ▸Access check: could an analyst independently find and manipulate this data?
• ▸Pushback recorded: did anyone challenge unsupported points — who and how?
• ▸Leverage rating: does this decision sit in a multiplicative spot (small gain × many)?
• ▸Enterprise-share test: who else needs this same data to answer their questions?
• ▸Limits noted: where did judgment/intuition legitimately override analysis?
• ▸Action taken: what changed as a result of the analysis (not just discussed)?

1. 1Build an inventory of the analytical models and major decisions your business runs on, so you know what has to be reviewed. Do not rely on memory — write down each model, its purpose, and the assumptions it depends on.
2. 2Classify each decision by its attributes: governance (who plays what role), recurrence frequency, degree of structure, and what information supports it. Classification tells you which reviews matter most and creates common language for discussing them.
3. 3Set the review schedule against changing conditions rather than the calendar alone: business strategy, business models, market conditions, competitor initiatives, and customer expectations and behaviors. When any of these shifts, trigger a review of the models tied to it.
4. 4Implement enterprisewide model review and management (the stage 5 practice): move from ad hoc local checks to a governed process that reviews assumptions and management frameworks across the organization.
5. 5Test whether interventions actually cause the outcomes you attribute to them, distinguishing real effect from random statistical fluctuation, and revise models that no longer hold.
6. 6Assess managers on the process and information used for key decisions — not just results — and make this part of the performance review, as ABB does for some managers.
7. 7Practice metadecision analysis before major decisions: ask 'How should we make this decision?' and confirm the model or method still fits current conditions.
8. 8Resist complacency and static analytical tactics; treat continual review as ongoing work of finding new insights, not a one-time certification.

The 2007-2009 financial crisis shows the cost of failing to review. Banks ran subprime lending on financial models whose core assumption was that customers could pay off mortgages through refinancing as housing prices kept rising. When housing prices stopped rising in 2006, that assumption broke — refinancing was no longer possible — yet banks continued making subprime loans. They 'simply didn't monitor and revise their analytical models closely enough,' so the models kept producing decisions that were valid under old conditions and ruinous under new ones. The contrast is Progressive Insurance, which 'consistently reviewed its analytical orientation and developed new offerings over time,' pioneering innovations like segmenting high-risk drivers by their differing risk levels. The lesson: in an industry where analytics are key to success, continual review of models, assumptions, and management frameworks is not management hygiene but a means to survival.

• If a market condition changes (prices, competitor move, customer behavior), then trigger a review of every model whose assumptions depend on that condition — do not wait for the scheduled cycle.
• If you cannot state a model's underlying assumption in plain terms, then treat it as unreviewable and unfit for decisions until the analyst can explain it in straightforward terms.
• If a decision recurs frequently and is high-structure, then prioritize it for formal, repeated model review; if it is one-off, then apply metadecision analysis case by case.
• If observed results could be random statistical fluctuation rather than your intervention, then do not update the model on that basis — run rigorous testing first.
• If you have reached stage 5 with visible analytical competition, then enforce enterprisewide model review and management rather than local, ad hoc checks.

• Resting on laurels after early analytical wins. The tell: no review cadence exists and success stories are repeated while assumptions go unexamined.
• Continuing to operate a model after its founding assumption has broken — the banks' error of making subprime loans once refinancing was impossible. The tell: outcomes drift from predictions but the model keeps issuing the same decisions.
• Reviewing only the model math while ignoring management frameworks and assumptions. The tell: passing technical reviews yet still being blindsided by market shifts.
• Assessing only decision outcomes, which 'can get political quickly,' instead of the process and information used. The tell: managers rewarded or blamed for luck, and no one examines how the decision was actually made.
• Letting analysts snow leaders with methods and tools they cannot explain simply. The tell: assumptions no one can articulate remain embedded in production models unchallenged.

• ▸Model/decision name: what it is and which process it drives
• ▸Purpose/decision it supports: the business call it produces
• ▸Core assumptions: the conditions that must hold for it to be valid
• ▸Change triggers watched: which strategy/market/competitor/customer shifts invalidate it
• ▸Attributes: governance (who decides), recurrence frequency, structure level, supporting information
• ▸Last reviewed / next review: dates and what triggered the last check
• ▸Validity test used: how you confirmed effect is real, not statistical fluctuation
• ▸Plain-language owner sign-off: analyst who can explain assumptions in straightforward terms
• ▸Action / revision decision: keep, revise, or retire, with rationale

1. 1Identify the recurring decisions where you currently rely on the 'golden gut'—pricing, inventory levels, hiring, marketing spend—and flag which of them have available data that could replace unaided judgment.
2. 2Match the level of analysis to the decision at hand: use simple metrics and descriptive statistics (means, medians, modes) for new or data-poor domains, and reserve sophisticated methods (segmentation, propensity scoring, next-best-offer) for data-rich domains like customer behavior.
3. 3For a data-poor area such as environmental sustainability, create simple metrics of key activities (for example, a carbon footprint), report them on a regular basis, and act on the patterns that emerge.
4. 4Before running analysis, fix the master data that decisions depend on: select the reference data used in decision making (customer, product), standardize definitions, and eliminate or correct incomplete, inaccurate, and inconsistent records rather than trying to clean every data object.
5. 5Use exploratory visual analysis to 'stay close to the data'—plot points on a two-dimensional graph, look for patterns, outliers that require explanation, and values out of range before committing to a conclusion.
6. 6State explicitly, for each decision, whether it rests on facts or on gut; if it rests on gut, ask whether historical data (e.g., what consumers actually paid under similar past circumstances) exists to replace the hunch.
7. 7Embed the analytical step into the business process so fact-based decisions become routine, and revisit your approach periodically so you don't fall into a decision-making rut when conditions change.

Take the software company executive who reported on a recent sales seminar: attendees from 110 companies received a keynote designed to instill confidence and encourage cross-selling, and all twelve technical sessions were well received. He concluded that no decision needed to be made other than to keep holding the seminars at the same pace. That is exactly the unexamined decision the authors warn against—'It went fine' is a gut verdict dressed as a report. A fact-based approach would define objective measures: cross-selling actually generated by attendees, pipeline movement tied to the 110 companies, and revenue per session rather than qualitative 'well received.' With those metrics you can decide whether to continue, change the format, or reallocate the marketing dollars—the guide's example of testing whether marketing dollars are being most effectively deployed. The difference is not more effort but a shift from unaided judgment to data detailing outcomes.

• If a major decision is being made on the manager's gut and relevant historical data exists, then replace the hunch with analysis—the research says 40 percent of major decisions run on gut and often leave money on the table.
• If the domain is data-poor (new area like sustainability), then start with simple metrics and regular reporting; if the domain is data-rich (loyalty card, Web site), then a mere report is underachieving and you need segmentation and scoring.
• If you are launching an MDM effort, then start small on a pressing problem with sizable payoff and confirm you have money, time, and executive support before expanding.
• If analyses and decisions are working well, then still do not rest on your laurels—review periodically so you can adapt when conditions change.
• If a report says only 'it went fine' with no objective measures, then treat the decision as unexamined and demand metrics before continuing the activity.

• Attempting to clean up every data object in the company instead of the master data used in decisions—the tell is an MDM project that morphs into an unending purification ordeal and someone asking why it's taking so long and costing so much.
• Producing a mere report in a data-rich domain—the tell is rich customer data from loyalty programs or a Web site sitting unused while decisions stay generic.
• Relying on qualitative impressions ('well received,' 'looks the part') as if they were facts—the tell is confident conclusions with no numbers behind them, like the baseball scout picking players who look the part.
• Overusing sophisticated analysis where a simple metric would do, or under-analyzing where sophistication is warranted—the tell is a mismatch between the analytical level and the decision's stakes and data richness.
• Falling into a decision-making rut after early success—the tell is unchanged methods that no longer fit shifted conditions.

• ▸Decision described: name the recurring call (pricing, inventory, hiring, marketing spend).
• ▸Current basis: mark gut/experience or data/analysis for this decision.
• ▸Available data: list historical or operational data that bears on it (e.g., past prices paid).
• ▸Data domain: classify as data-poor or data-rich to set analysis level.
• ▸Master data check: note whether the key reference data (customer, product) is standardized and clean.
• ▸Analysis method: name the appropriate technique (descriptive stat, visual/EDA, segmentation, scoring).
• ▸Objective metric of success: define the number that will tell you if the decision worked.
• ▸Review cadence: state how often you will revisit so you don't get stuck in a rut.

1. 1Locate your organization on the five stages by testing for prerequisites first: if you lack data, analytical skills, or senior management interest, you are Stage 1 (Analytically Impaired), regardless of any isolated activity.
2. 2If prerequisites exist but activity is scattered — pockets of analysis not coordinated or aimed at strategic targets — place yourself at Stage 2 (Localized Analytics).
3. 3Rate each DELTA element separately against its own maturity path: Data (poor → usable → consolidated → integrated → innovative) and Leadership (none → local → aware → supportive → passionate); do the same for Enterprise, Targets, and Analysts.
4. 4Test the balance across the five elements. If one element (typically Data) runs far ahead while others lag, note the imbalance — this is the diagnostic signature of a stage stalled at 3 (Analytical Aspirations), where a critical DELTA factor is too hard to implement.
5. 5Distinguish Stage 4 from Stage 5 by strategic intent, not tool count: Stage 4 (Analytical Companies) applies analytics regularly and gets benefits across the business but has not made analytics its strategic ground or competitive weapon; Stage 5 (Analytical Competitors) uses analytics as a distinctive, enterprise-wide capability with passionate leadership and self-identifies as an analytical competitor.
6. 6Use the appendix table (DELTA factors x five stages) as your assessment grid to mark current position per element and the next cell to reach.
7. 7Set a realistic destination: not every organization needs Stage 5 — most should aim to move up one or two stages while competing primarily on product, customer relationships, or operational excellence.
8. 8Sequence advancement to move all five elements forward in rough proportion, and let early project wins generate the value evidence executives require before funding the next investments.

Consider an organization sitting at Stage 1 that wants to become a more analytical enterprise. The passages advise skipping the silo-based approach of Stage 2 entirely: if the executive team supports a cross-functional, enterprise-oriented approach, begin building an enterprise data warehouse directly. But you cannot jump from Stage 1 or 2 to Stage 4 or 5 — you still need the targets and vision that come only with engaged executives at Stage 3, because you need to know where to focus. Bank of America and Capital One illustrate mature-stage organizing choices: Capital One concentrates 'heavy-duty' PhD statisticians in a center of excellence, while Bank of America spreads analysts across the bank and compensates for the model's limits with regular conferences and an online portal. The passages also warn that the purely decentralized model — the most prevalent — reflects the immaturity of most corporations' analytical capabilities today, so finding a decentralized structure is itself a maturity signal (a low one).

• If any one prerequisite (data, analytical skills, or senior management interest) is missing, then classify as Stage 1 no matter how much local activity exists.
• If Data is ready but sits dormant because analysts, leadership, or targets aren't in place, then you have over-invested in one element and are stalled — rebalance rather than add more data.
• If you are at Stage 1 or 2 with a supportive CEO and executive team, then skip the silo stage and build enterprise capability directly, but do not attempt to leap to Stage 4/5 because human and data infrastructure takes time.
• If analytics deliver benefits across the business but strategy is not grounded in analytics, then you are Stage 4, not Stage 5 — competitive advantage, not regular use, is the gate.
• If you are stronger in one DELTA element, then use that strength to generate interest in bringing the others along, since a missing element causes delay and wasted effort.

• Counting tools or projects instead of testing prerequisites — the tell is claiming Stage 3+ while senior management interest is actually absent, which pins you at Stage 1.
• Racing one element (usually Data) far ahead of the rest — the tell is a data warehouse sitting dormant because analysts, targets, or leadership aren't ready.
• Mistaking scattered activity for maturity — the tell is 'pockets' of analysis uncoordinated and not tied to strategic targets, which is only Stage 2.
• Adopting or defending a purely decentralized analyst structure — the tell is inability to set enterprise priorities or share staff; effective only in rare large, diversified multibusiness firms with little in common.
• Assuming every organization must reach Stage 5 — the tell is forcing an analytical-competitor identity when the firm competes on product innovation, customer relationships, or operational excellence and only needs to move up a stage or two.

• ▸Prerequisite check: mark present/absent for data, analytical skills, senior management interest (any absent = Stage 1)
• ▸Data stage: poor / usable / consolidated / integrated / innovative
• ▸Leadership stage: none / local / aware / supportive / passionate
• ▸Enterprise, Targets, Analysts stage: rate each 1–5 against the appendix table
• ▸Balance gap: name the element furthest ahead and the one furthest behind
• ▸Overall stage: 1 Impaired / 2 Localized / 3 Aspirations / 4 Companies / 5 Competitors
• ▸Target stage: the one or two stages up you realistically aim for
• ▸Next move: the single next cell to reach and the DELTA element it belongs to
• ▸Evidence plan: the early win that will justify the next investment to executives

1. 1Locate your decisions on the six-cell matrix (past/present/future × information/insight). Inventory current activities; expect most 'business intelligence' work to cluster in the top information row (reporting, alerts, extrapolation).
2. 2Move selected questions down into the insight row: convert 'what happened' into 'how and why' via statistical modeling, 'what is happening' into 'what's the next best action' via recommendation, 'what will happen' into optimization and simulation.
3. 3Screen candidate targets against the six decision conditions: (1) complex/multi-variable decisions; (2) simple decisions needing consistency or legal compliance; (3) whole-process optimization; (4) decisions needing correlations and their significance; (5) decisions needing forecasts and downstream visibility; (6) processes with a low current success rate.
4. 4Integrate data across silos before analyzing—pull from sales, logistics, purchasing, and finance so decision makers can look upstream and downstream to see operational and financial impact.
5. 5Test whether the intervention actually caused the result. Use rigorous analytical testing to distinguish a real effect from random statistical fluctuation before declaring the activity 'working.'
6. 6Tie each target to a named benefit: steer the business in turbulent times, cut costs via optimization, manage risk with precise metrics, anticipate market shifts, or improve the decision itself over time.
7. 7Build the loop back in: use clear logic and explicit supporting data so you or someone else can re-examine the decision process later and improve it.

McKesson Pharmaceutical targeted its supply chain—one of the highest-volume distribution networks in the world, routing one-third of U.S. medicines to more than twenty-five thousand locations a day. Squeezed between major pharmaceutical manufacturers on the supply side and powerful retailers like Wal-Mart on the customer side, it had to run at high volume and high efficiency, making it a fit for conditions 3, 4, and 5. Building on a strong process orientation, McKesson brought together data from sales, logistics, purchasing, and finance to achieve integrated analysis and decision support. The result: managers throughout the supply chain can now look all the way up and downstream to evaluate the operational and financial impact of decisions about delivery schedules, transportation utilization, quantity adjustments, product dating, and drop shipping. The business result is consistent decisions across an interdependent, cross-functional process rather than local optimizations that suboptimize the whole.

• If a decision is complex with many variables and steps, or requires optimizing the whole rather than the parts, then route it to analytics rather than local rules of thumb.
• If a simple decision requires consistency or is legally constrained (like nondiscriminatory credit and lending), then use analytics to enforce consistent decisions even in unpredictable cases.
• If a process has a low average success rate—a poor 'batting average'—then treat it as ripe for improvement through analytics.
• If you cannot tell whether an intervention caused a change or it was random fluctuation, then run rigorous analytical testing before scaling the activity.
• If your information activities sit only in the top row (reporting/alerts/extrapolation), then push at least the priority ones into modeling, recommendation, or optimization to understand the dynamics of the business.

• Going with the gut—pricing on hunches about what the market will bear instead of data on what consumers actually paid under similar past circumstances. Tell: nobody can name the data behind the number.
• Declaring an activity a success without asking what it didn't reveal—the software firm's sales seminar 'went fine' with 110 companies, yet no one knew how many were prospects vs. customers or which were high-growth. Tell: warm satisfaction plus no decision left to make.
• Optimizing locally and suboptimizing the whole—decomposing a process and tuning each part in isolation. Tell: each function hits its own metric while total cost or service degrades.
• Mistaking correlation and random fluctuation for causation—crediting an intervention for gains it didn't produce. Tell: results can't be reproduced and no controlled test exists.
• Sitting on massive data yet failing to use it meaningfully—collecting information without moving from reporting to insight. Tell: rich dashboards, unchanged decisions.

• ▸Decision/process name: the specific decision or process under review.
• ▸Matrix cell: mark past/present/future and information/insight; note the target cell to move toward.
• ▸Condition check: tick which of the six conditions apply (complexity, consistency/legal, whole-process optimization, correlations, forecasting/visibility, low success rate).
• ▸Current success rate: state the 'batting average' or baseline outcome you want to improve.
• ▸Data sources to integrate: list the silos (e.g., sales, logistics, purchasing, finance) that must be joined.
• ▸Intended benefit: name the payoff—cost cut, risk managed, anticipation, better/repeatable decision.
• ▸Causation test plan: how you will verify the effect is real, not random fluctuation.
• ▸Upstream/downstream visibility: who needs to see effects of this decision on other steps.
• ▸Re-examination hook: what logic and supporting data you will record so the decision can be improved later.

1. 1Get senior executives to agree on a single definition and meaning for your primary analytical domain (usually 'customer') across the whole business — without this, integration fails downstream.
2. 2Separate analytical data from transaction systems (sales order management, general ledger) and locate it where analysts can actually find and manipulate it — build an enterprise data warehouse (EDW) that cuts across functions and business units, not siloed data marts.
3. 3Choose a data structure that matches your intended analysis: cubes for reporting and slicing/dicing, arrays for statistical work, nonnumeric for text — because structure limits the analyses you can do.
4. 4Establish clean data: assign a unique identifier per entity (e.g., per customer), verify names/addresses/histories are accurate, and integrate/reconcile data pulled from multiple sources so meaning is commonly understood.
5. 5Assign named stewardship roles to business managers (part-time is fine) covering business definitions/standards, information quality, information protection, and information life cycle — 'everyone's job' guarantees it is nobody's job.
6. 6Add speed and access infrastructure where needed: a data warehouse appliance for rapid queries, and certification mechanisms (audited 'official version' reports) so users argue from complete data, not partial anecdotes.
7. 7Set explicit privacy policies for the entities you gather most data on; comply with the strictest applicable jurisdiction (Europe's laws are particularly strict) and prevent loss via hackers or careless mistakes.
8. 8If full integration is infeasible or unaffordable, run the '10 percent solution' — sample ~10% of a domain (usually customers) to pilot analytics and prove the enterprise approach before committing.

Montana State Fund faced meetings where 'people argued based on selected events and partial data.' In 2006 it launched an initiative certifying key reports and analyses with digital watermarks: over seventeen hundred data elements extracted from core applications were marked as the official, audited versions. Users could print watermarked reports but couldn't download the data without losing the watermark. Al Parisian, head of IT and strategy, knew the improved data platform was working when he saw the culture shift — colleagues began pushing back with, 'You can't use those isolated examples. Here's a report based on all the data from that period.' The behavioral tell, not the technology, confirmed adoption.

• If integration across functions matters for advanced analytics, then build an enterprise data warehouse (EDW) rather than proliferating single-purpose data marts.
• If you need analytical answers fast and do high query volumes, then acquire a data warehouse appliance optimized for rapid queries; otherwise don't spend on it.
• If full integration of a domain (e.g., a complete customer information file) is too difficult or costly, then take a ~10% sample to pilot analytics before committing to enterprise-wide management.
• If assigning data responsibility, then use 'stewardship' (business managers) rather than 'ownership' — ownership is politically loaded and raises hackles.
• If your EDW is so large it overwhelms casual, nontechnical users, then add access tools/filtering — recognize the built-in contradiction between all-inclusive scope and accessibility.

• Leaving data inside transaction systems: analysts can't find or manipulate it. Tell — reports are pulled ad hoc from operational apps and no one can reconcile them.
• No common definition of 'customer' agreed by senior executives: data won't integrate. Tell — different functions report different customer counts and can't merge files.
• Making data 'everyone's job': accountability evaporates. Tell — quality problems recur and no named person owns the fix.
• Proliferating data marts instead of an integrated warehouse: advanced cross-functional analytics become impossible. Tell — each business unit has its own numbers that don't tie out.
• Choosing the wrong structure (tables/cubes for statistical modeling): the structure blocks the analysis. Tell — analysts fight the data format instead of the problem, and tables carry only 3–12 months of history.
• Ignoring privacy: harm from careless disclosure. Tell — a service interaction reveals private purchase records (the Clubcard/condoms case, defused only by a quick-thinking rep).

• ▸Primary analytical domain — name the entity (e.g., customer) and its agreed common definition
• ▸Unique identifier — the field that uniquely tags each entity; note current accuracy gaps
• ▸Source systems to integrate — list transaction systems feeding this domain and reconciliation status
• ▸Data structure choice — cube / array / nonnumeric, matched to the analyses planned
• ▸Access approach — EDW, data mart, appliance, or 10% sample; state rationale
• ▸Quality attributes — target accuracy, consistency, timeliness, validity, completeness
• ▸Named steward — business manager responsible (full/part time) for this domain
• ▸Privacy policy & jurisdiction — applicable laws (note strictest) and controls against loss/misuse
• ▸Executive sponsor & decision — senior owner who ratifies the common definition and scope

1. 1Start with the cross-functional test: for any planned analytics initiative, map which parts of the enterprise its data, decisions, and processes touch. If it touches multiple functions—and major performance-improving applications invariably do—refuse to manage it as a local project.
2. 2Define what 'enterprise' actually means for your organization before centralizing anything. The passages note the definition of 'enterprise' varies across organizations; establish whether it means a business unit, a division, a geography, or the whole firm for your specific analytical resources.
3. 3Move ownership of the three key resources—data, analysts, and technology—up to the enterprise level rather than the function. Because applications are cross-functional, managing these resources locally does not make sense.
4. 4Make the data owned enterprise-wide: require a unique identifier per entity (e.g., one customer ID), commonly understood meaning and use, and integration/consistency when drawn from several sources, accessible in warehouses or filterable on the fly.
5. 5Motivate management across silos to cooperate on analytical initiatives—not just fund a project, but agree on shared data definitions, shared analyst pools, and shared standards so initiatives compound instead of fragmenting.
6. 6Screen your initiative portfolio: if you find many small analytical projects but no significant ones, treat that as the signature of a missing enterprise perspective and consolidate.
7. 7Coordinate scattered analytical groups deliberately, as Jeanne Harris did at Accenture by mobilizing and coordinating the firm's multiple analytical consulting groups into a coherent capability rather than parallel fiefdoms.

The retail grocery chain in the passages shows the failure of enterprise orientation in miniature. Managers admitted they made more money selling their data to retail syndication firms than selling meat—then bought their own data back, mixed with competitors' data. Beyond selling it, they stored it on disk, then tape, then 'under a mountain so that it's safe from nuclear attack.' When pressed on what they did with it to manage the business, they confessed: 'Not much.' The data existed but was never coordinated into a shared, owned, analyzed enterprise asset serving decisions across functions—so a genuine resource sat inert. The tell is that they had massive data and made decisions, but never connected the two across the organization.

• If an application touches multiple parts of the enterprise, then do not manage its data, analysts, or technology locally—escalate ownership to the enterprise level.
• If you have many small analytical initiatives but few or no significant ones, then diagnose a missing enterprise perspective, not a lack of tools.
• If data is drawn from several sources, then require it to be integrated and consistent with a unique identifier and commonly understood meaning before analysts build on it.
• If management across silos is not motivated to cooperate, then the data-management challenges will stay hard—fix the cooperation incentive before scaling the technology.
• If you are starting small in a single function, then still define an enterprise perspective up front, because 'you won't get far without one.'

• Treating enterprise orientation as premature for small starts. The tell: the phrase 'why would we need an enterprise perspective?' Answer from the passages: you won't get far without one.
• Hoarding data as inert storage rather than a coordinated asset. The tell: the resource is described in terms of where it's stored (disk, tape, under a mountain) instead of what decisions it informs.
• Managing data, analysts, and technology locally when applications are cross-functional. The tell: each function has its own analysts and its own version of the data, so numbers don't reconcile across silos.
• Proliferating small, self-serving initiatives with no significant one. The tell: lots of activity, no material improvement in performance or competitiveness.
• Leaving key resources fragmented across parallel groups. The tell: multiple analytical teams doing overlapping work uncoordinated—the situation Accenture had to deliberately mobilize and coordinate.

• ▸Initiative name: state the analytical initiative in one line
• ▸Functions touched: list every part of the enterprise its data/decisions/process crosses
• ▸Enterprise definition: specify what 'enterprise' means here (unit, division, geography, whole firm)
• ▸Data ownership: mark whether the key data is owned locally or at enterprise level, with unique-identifier status
• ▸Analyst ownership: note whether analysts are pooled at enterprise level or trapped in a function
• ▸Technology ownership: note whether analytical software is shared or duplicated per silo
• ▸Cooperation incentive: state what motivates cross-silo management to cooperate on this initiative
• ▸Significance test: mark whether this is one of few significant initiatives or one of many small ones
• ▸Escalation decision: if cross-functional, record the decision to move ownership up to enterprise level

1. 1Identify who already manages by fact somewhere in the organization — analytical leadership exists at any level, not just the C-suite. Look for managers who ask for evidence before deciding.
2. 2Make senior leaders commit past specific projects to the broader goal: shifting decision-making styles and methods toward fact across the enterprise, not just applying analytics in a few useful areas.
3. 3Model the behavior yourself: refuse to make decisions without asking what the data says. Adopt Socrates-flipped — 'the unexamined decision isn't worth making' — as the standing expectation you set for your team.
4. 4Set explicit performance expectations that require evidence: when a report says an event 'went fine,' push back with the specific questions that reveal whether it actually worked.
5. 5Hire smart analysts and treat them as scarce, valuable talent — leaders must fund the people who build and maintain the models and who bring analytics to businesspeople.
6. 6Fund analytics where it makes a substantial difference, not everywhere. Even analytically inclined leaders won't write blank checks — direct resources at strategic targets with high potential return.
7. 7Insist that intuition be verified, not obeyed. When you or an influential person has a hunch, require that it be tested with data or a small-scale trial and expanded only if it works.
8. 8Build the surrounding ecosystem — accessible high-quality data, enterprise ownership of data/software/talent, and cooperation across silos — so fact-based decisions are actually possible.

An executive at a software company reported that a recent sales seminar 'went fine': 110 companies attended, the keynote landed, and all twelve technical sessions were well received. His first instinct was that no decision was needed beyond continuing twelve seminars per quarter. Analytical leadership shows up in what he did next — he voiced the disquieting questions the report never answered: How many attendees were existing customers versus prospects? Were there attendees from every customer and every prospect in the geographic area? Which were high-growth prospects, and how many had also attended the annual conference? Without those facts, the decision to keep running the seminars is a hunch about what 'went fine' means, and money is left on the table. The leadership move is not to accept the comfortable summary but to demand the data that turns a vague success into a measured one.

• If someone brings a hunch, then require verification by gathering and analyzing data, or by running a small-scale test — expand only if it seems to be working (Chris McCann's rule).
• If a decision touches only 'what feels comfortable' — inventory levels, pricing by gut, hiring by intuition — then treat that as money left on the table and demand the relevant historical data.
• If analytics funding is requested broadly, then don't write a blank check; fund it where the return will make a substantial difference against a strategic target.
• If a report says something 'went fine,' then ask the specific unanswered questions before approving any repeat decision.
• If key resources (data, analysts, technology) are being managed locally for a cross-functional application, then escalate to enterprise-level ownership.

• Committing to individual analytical projects but never to changing decision-making styles across the enterprise — tell: leaders celebrate a model's launch but still decide by gut everywhere else.
• Accepting the comfortable summary ('it went fine') as sufficient — tell: no one can answer basic follow-up questions about who, how many, or which segments.
• Managing data, analysts, and technology locally when applications are cross-functional — tell: many small initiatives, few or no significant ones.
• Treating analysts as interchangeable rather than scarce, valuable talent — tell: no one can both build the models and bring analytics to the wider business.
• Spending analytics budget evenly across everything — tell: talent spread thin, no targeted area where results clearly stand out.

• ▸Decision under review: state the decision currently being made or repeated.
• ▸Current basis: is it fact, hunch, or an unexamined 'it went fine'?
• ▸Unanswered questions: list the specific facts the current report does not reveal.
• ▸Data required: what data would answer those questions, and does it exist/access.
• ▸Verification plan: the small-scale test or analysis that will confirm or reject the hunch.
• ▸Strategic target link: which target (loyalty, supply chain, risk, hiring) this serves.
• ▸Analyst owner: who builds/maintains the model and brings it to the business.
• ▸Enterprise reach: which parts of the organization the decision touches.
• ▸Expected return: the substantial difference that justifies funding.

1. 1Inventory your existing analytical activity and map it against strategic value: at Stage 2 (Localized Analytics) you have pockets of work that are 'not coordinated or focused on strategic targets.' List every project and tag which are top-row 'business intelligence' (information-oriented) versus insight- and optimization-oriented.
2. 2Identify your distinctive capabilities — the processes that drive differentiation, not just efficiency. Candidate targets from the passages: strong customer loyalty, highly efficient supply chain performance, more precise asset and risk management, and hiring/motivating/managing high-quality people.
3. 3Screen each candidate for return, not just interest: analytical leaders 'are not going to write blank checks.' What gets attention is 'the potential return of employing analytics where it will make a substantial difference.' Rank candidates by size of impact.
4. 4Test whether the target rests on unique data or is copyable. Ask 'How can you tap into and exploit data that no one else has?' Prefer targets grounded in proprietary data (e.g., what your customers bought from you) over commercially available data any competitor can buy.
5. 5Apply the art layer to the shortlist: choosing the business area requires 'a mixture of intuition, strategy and management frameworks, and experience,' plus a vision of where the company, industry, and customer value are headed.
6. 6Confirm all five DELTA elements are available for the chosen target — accessible data, enterprise cooperation, leadership, and analysts. Move them 'forward in rough proportion' so leadership doesn't see a target and demand results the data or analysts can't yet deliver.
7. 7Concentrate scarce analytical talent on the winning targets and starve the low-value scatter, because 'analytical talent isn't plentiful enough to cover all bases' and 'you cannot be equally analytical about all aspects of your business.'

Progressive Insurance chose auto insurance underwriting as a strategic target and pursued unique data to serve it. In 1996 it became the first company in its industry to use consumers' credit scores as an input to underwriting. Whether you pay your bills turned out to be a surprisingly good predictor of whether you will crash your car — no one knows exactly why — but it gave Progressive a real edge on a high-value process. The target mattered because underwriting accuracy drives loss ratios and profit, the core of the business. It took competitors at least four years to start using this data, and some still haven't caught on. The lesson: Progressive did not scatter analytics; it aimed at a differentiating process and fed it data others weren't yet exploiting — though because a credit score is commercially available and insurers must publish underwriting approaches in regulatory filings, the advantage was inevitably copyable over time.

• If a candidate project is information-oriented (top row 'business intelligence') rather than insight- or optimization-oriented, then treat it as low-priority and push it toward questions about business dynamics.
• If a target would only produce marginal impact, then don't fund it — reserve scarce analysts for areas where analytics 'will make a substantial difference.'
• If the target depends only on commercially available data, then assume competitors will catch up (as Progressive's did) and either move first fast or seek genuinely proprietary data instead.
• If leadership wants results but the data or analysts aren't ready for that target, then either reprioritize a target where DELTA elements are in proportion or delay to close the gap.
• If a target sits at the center of your differentiation and rests on data no one else has (e.g., your own customers' purchase history), then prioritize it — a unique strategy requires unique data.

• Scattering effort across uncoordinated pockets — the Stage 2 tell: analytical activity exists but is 'not coordinated or focused on strategic targets,' so no project reaches large-scale results.
• Trying to be equally analytical about everything — the tell is thinly spread analysts and stalled projects, because talent 'isn't plentiful enough to cover all bases.'
• Aiming at copyable targets and calling it advantage — the tell is competitors matching you within a few years because 'competitive secrets don't stay secret for long,' especially where underwriting is published in regulatory filings.
• Leaving analytics stuck in the top row — the tell is lots of 'business intelligence' activity that describes what happened but never moves to insight about business dynamics.
• Choosing targets by pure intuition or pure model, ignoring the mix — the tell is either analysis with no strategic vision, or a model applied past the point where 'analytical models no longer apply.'

• ▸Candidate process/capability: name the business area under consideration
• ▸Value type: mark whether it drives differentiation or just efficiency
• ▸Question level: is it information-, insight-, or optimization-oriented?
• ▸Estimated impact: describe where and how much this 'makes a substantial difference'
• ▸Data uniqueness: is the required data proprietary, commercially available, or must be created (new metric)?
• ▸Copyability/time-to-catch-up: how long before a competitor could replicate it?
• ▸DELTA readiness: rate Data, Enterprise, Leadership, Analysts availability for this target
• ▸Art check: does this fit your vision of where the industry and customer value are heading?
• ▸Priority decision: fund now / defer until gap closed / drop

1. 1Treat analysts as a scarce, enterprise-owned resource, not a local one: managing data, analytical software, and talent locally fails because major applications 'invariably touch multiple parts of the enterprise' (chapter 3 rationale). Inventory where analytical talent currently sits and whether it is coordinated.
2. 2Assess your current stage for the Analysts element against the five-stage model — Analytically Impaired (lacking analytical skills entirely), Localized (uncoordinated pockets), Analytical Aspirations (established capabilities, slow progress), Analytical Companies (needed human resources applied regularly), Analytical Competitors (analytics as distinctive capability).
3. 3Move the Analysts element forward in rough proportion to the other four DELTA elements (Data, Enterprise, Leadership, Targets). If analysts lag while leadership 'sees targets and wants results,' the mismatch produces frustration and stalls initiatives.
4. 4Do not overspend on one element (typically data) and let analysts sit unaddressed — a ready element left 'dormant because none of the other ingredients are in place' is wasted effort.
5. 5Match analyst deployment to the six question types in the time-frame/innovation matrix: assign reporting work (past/known) to lower-skill staff, and reserve professional analysts for insight-generating work (future, new information) like the design research eBay runs.
6. 6Where you are stronger in analysts than in other elements, use that strength to 'generate interest in bringing the others along' rather than pushing analysts further ahead in isolation.
7. 7Cultivate leadership that has 'a passion for managing by fact,' since analyst capability only converts to results when senior managers are committed to fact-based decisions across processes and customer relationships.

eBay concentrates analytical talent on continuous product/site improvement: the company runs participatory design sessions, focus groups, iterative trade-off analysis, quantitative visual design research, eye-tracking studies, and diary studies to see how users feel about potential changes. The operating rule that reveals the talent commitment is that eBay 'will make no significant changes to its site without these analyses.' This requires analysts skilled across both qualitative and quantitative methods, deployed as a standing capability rather than a one-off project team. The passage credits this analytical orientation as 'clearly one factor' behind eBay sustaining 113 million items for sale across over fifty thousand categories. The lesson for talent: capability is an organizational property — 'an organizational capability that can be measured and improved' — not a collection of individual tool users.

• If applications are cross-functional, then do not manage analysts locally — pool them as an enterprise resource.
• If leadership wants results but analysts aren't ready, then hold targets in proportion and build analyst capability before promising outcomes.
• If you have many small analytical initiatives but no significant ones, then treat it as a signal you lack an enterprise perspective on talent, not that you lack more analysts.
• If one DELTA element (e.g., analysts) is far ahead, then use it to pull the laggards forward rather than pushing it further alone.
• If the question is about past/known information (reporting, forecasts by simple extrapolation), then it is not analyst-grade work — reserve professionals for insight and future-oriented questions.

• Treating analysts as a purely local function; the tell is coordinated-looking activity that never produces a significant, cross-functional result (stuck in Localized Analytics).
• Overinvesting in data while starving talent; the tell is a data warehouse that 'sits dormant' because analysts and other elements aren't in place.
• Letting one element sprint ahead; the tell is visible frustration when leadership 'sees targets and wants results, but the data or the analysts aren't ready.'
• Assuming buying tools equals capability; the tell is treating analytics as 'a way of looking at a particular problem' rather than a measurable, improvable organizational capability.
• Assigning insight-generating questions to reporting-level skill; the tell is decisions made on 'past information' extrapolation where genuine analysis (like eBay's design research) was needed.

• ▸Current Analysts stage (1-5): pick Impaired / Localized / Aspirations / Companies / Competitors
• ▸Talent location: list where analysts sit and whether coordinated or in pockets
• ▸Enterprise ownership: note whether analysts are managed locally or as a shared resource
• ▸Proportion check: rate Data, Enterprise, Leadership, Targets 1-5 and flag any gap >1 stage vs Analysts
• ▸Question-type deployment: map each analyst/team to a cell in the past/present/future × known/new matrix
• ▸Lagging element to pull: name the weakest DELTA element and how analyst strength can generate interest in it
• ▸Leadership fact-passion: note whether senior managers are supportive vs passionate about managing by fact
• ▸Next stage action: one specific move to advance the Analysts element one stage