Digital Organization

From "Can We Build It" to "Will Anyone Use It"

Sessions 1–3 established what digital strategy is, what leadership execution requires, and how fast an AI-driven advantage can erode. Session 4 asks the question underneath all three: even with a sound strategy, capable leadership, and a genuinely differentiated capability, what organizational structure and culture actually determine whether it gets adopted? Pernod Ricard's KDPs (D-STAR, Matrix) are technically sound, in-house built, and proven in pilots — the entire remaining question in the case is organizational: how to get 70+ largely autonomous affiliates across 160+ countries to actually use them.

Why Pernod Ricard Is a Sharper Test Than DBS or GE

DBS (Session 1) and GE (Session 2) were both relatively centralized organizations executing a top-down digital vision. Pernod Ricard is structurally different: a deliberately decentralized group, historically built that way to respect local market autonomy and legal variation across alcohol regulation in 160+ countries. That decentralization is a genuine strategic asset for a spirits company — and it is precisely what makes company-wide adoption of centrally-built digital tools structurally harder than at DBS or even GE.

One Correction Now That the Deck Is Available

The slide deck's scope is wider than the article and case suggest. Adoption and culture are only half of it — the other half is technology outsourcing and partnership: the strategic grid for outsourcing, the four partnership models, build/buy/blend/partner, vendor selection, and cloud provider comparison. Neither the article nor the case covers that material, so Block 2 is where the exam- and journal-relevant frameworks actually live. Two in-class mini-cases (Nexus Financial, Alcotech) sit in Block 3.

The Session Is Half Structure, Half Partnership

The deck's stated aim, on its second content slide: examine the evolving organizational structures of technology-enabled businesses, and concepts and issues related to technology outsourcing and partnership. That second half is not a footnote — roughly half the slides deal with outsourcing, vendor selection, and partnership models, which the article and case barely touch. The whole deck converges on one question, stated verbatim on the "Organization and Partnership" slide:

Evolution of Digital Technologies in Business

Adapted from McFarlan & Nolan, the deck plots organizational learning against four eras: Centralized (1965–1980) → Decentralized (1980–1995) → Networked (1995–2010) → Ubiquitous (2010–2025: social, mobile, analytics, cloud, IoT, generative AI, AR, autonomous things, blockchain, edge, deep learning, BCI, quantum). The point of the S-curve is that organizational learning lags technology availability in every era — which is the whole premise of a "digital organization" session.

Does Technology Matter? Carr vs. McAfee

The deck opens the debate with Nicholas Carr's provocation — "spend less each year," "follow, don't lead," "focus on vulnerabilities, not on opportunities" — then answers it with Andrew McAfee's counter-framing: it depends entirely on which type of application you mean. The two McAfee slides are blank grids to be filled in live, so capture the professor's own answers; the expected pattern is roughly:

What Matters for Digital Transformation

Davenport & Redman's three-part answer, which the deck uses as the session's organizing spine:

• Business strategy and leadership — business and technology leaders must demonstrate strategic business value with every technology innovation and implementation.
• Information, technology and process talent — talent with both breadth and depth, to build efficient and effective processes and workflows.
• Organizational structure and culture — the right structure, plus a culture that promotes collaborative work and decision making.

Session 2 covered the first bullet (leadership) and the article covers the third (culture). This deck's contribution is the structural machinery underneath: federalization, governance, agile organization, and partnership.

The Shadow IT "Problem"

The deck defines shadow IT as systems deployed by departments other than central IT, "to work around the shortcomings of the central information systems" — departments hiring their own developers or buying their own software "without knowledge, buy-in, or supervision from a centralized IT department." Note the scare quotes around problem on the slide: shadow IT is a symptom, and what it is a symptom of (central IT being too slow, or business units being ungoverned) determines the fix. The professor asks the room directly: is there a shadow IT problem in your organization? — a guaranteed participation opening.

The Federalized Organization (Rockart et al., Sloan Management Review)

The core structural framework of the session. Centralized and decentralized each solve what the other breaks:

Federalization Happens at Three Levels

Map this onto the article's hub-and-spoke model in Block 4 and they line up almost exactly: the hub is strategic-level federalization, the shared services/CoE layer is the gray area, and the spokes are the operational teams.

Digital Governance and the Steering Committee

Digital governance = the structures, processes and roles responsible for decision making — deciding what new work to do (digital strategy) and how to manage existing work (digital execution). A steering committee of senior business and technology executives directs, reviews and approves digital plans, oversees major initiatives, and allocates resources. The deck is emphatic that it is the foundational governance practice: established officially, with defined roles and responsibilities for decision making, and meeting regularly.

The five governance principles, straight off the slide:

1. Centralize information about digital initiatives rather than the initiatives themselves.
2. Move from centralized to decentralized governance of digital initiatives as digital maturity grows.
3. Decentralize ideation but centralize idea evaluation and prioritization.
4. Make sure KPIs measure the real business impact you want each initiative to achieve.
5. Avoid siloed solutions — ensure data compatibility, technical consistency, and continuous integration with existing systems.

From "Machines" to "Organisms" — the Agile Organization

McKinsey's framing: traditional organizations operate like machines (rigid, top-down, slow to adapt) while agile organizations operate like living organisms (empowered teams responding quickly to change and customer needs). In traditional organizations departments work in isolation, producing bottlenecks and misalignment; agile organizations integrate business and technology functions with cross-functional collaboration, shared accountability, and rapid decision-making. The deck's vocabulary:

Challenges with the Agile Organization

The deck is notably even-handed here — three named limits, all worth having in your pocket as counterarguments:

From Vertical to Virtual Integration

A single diagram that reframes the whole outsourcing half of the deck: in the vertical model, IT sits inside the firm alongside R&D, marketing, logistics, manufacturing and customer service. In the virtual model, information technology becomes the connective layer through which those functions relate — including functions that no longer sit inside the firm at all. Once IT is the connective tissue rather than a department, "what do we outsource?" stops being a cost question and becomes an architecture question.

Technology Outsourcing — Scale and Motivations

Gartner's definition: "the use of external service providers to effectively deliver IT-enabled business process, application service and infrastructure solutions for business outcomes." Statista's numbers from the deck: the outsourcing market reached US$541 billion in 2024, growing at 8.5% annually to a projected US$813 billion by 2029. Major vendors named: AWS, TCS, CapGemini, Wipro, HCLTech, Cognizant, Infosys, NTT, IBM.

The motivations slide splits by who is asking:

Underneath, the deck splits the same list along a revenue orientation (improve business focus, access to world-class capabilities, accelerated process development, free up resources) versus a cost orientation (reduce operating costs, make capital funds available, resources not available internally, function difficult to manage). Which orientation you're outsourcing for determines what a "successful" contract even looks like.

Four practitioner insights the deck flags (G. Gulyas, IBM): outsourcing is for most organizations "a process of letting go"; it "uncovers all hidden costs" in the organization; a productive long-term relationship requires a "true partnership"; and the exit clause must be agreed beforehand.

Strategic Grid for Technology Outsourcing

The same McFarlan & Nolan grid from Session 2, repurposed as an outsourcing decision rule — worth noting the reuse out loud in class, since it's the deck's only recurring framework:

The deck sets this up with a warning from HBSP's P. Michelman: in theory outsourcing non-core activities is a no-brainer — shed assets, boost return on capital. In reality "it's really hard to figure out what's core and what's non-core." The grid is an attempt at that judgment, not a substitute for it.

From Outsourcing to Partnership Models

The deck's most modern slide, and the one most likely to appear in a discussion question. Two axes — integration (low → high) and strategic impact (low → high) — give four named models with real examples:

Build, Buy, Blend, or Partner for AI Capabilities

Per D.P. Piscione (HBR), companies are rejecting the binary build-vs-buy question in favour of four options:

Vendor Selection and the Magic Quadrant

The deck's eight vendor/consultant screening questions compress to four things: fit (do they understand your business and technology problem; have they done applicable work?), method (is the approach clearly and succinctly presented; what is their industry reputation?), people (who specifically is the project leader, and what is the team's background?), and terms (detailed fee breakdown including travel; do they guarantee the work and for how long; do they run a post-engagement review?).

Gartner's Magic Quadrant plots ability to execute against completeness of vision: Leaders execute well today and are positioned for tomorrow; Challengers execute well today but lack a roadmap for how the market will evolve; Visionaries understand where the market is going but don't execute well; Niche Players focus successfully on a small segment, or are simply unfocused. Ability to execute covers product/service quality, pricing, track record, marketing, customer experience and operations; completeness of vision covers market understanding, strategy and business model.

On cloud specifically, the deck's Gartner-sourced strengths and cautions: AWS — best price/performance and pace of innovation, but renewal pressure, offering complexity that often needs third-party consultants, and a large attack surface. Azure — strongest across all use cases with the broadest enterprise capability set and brand trust, but slow regional rollout, some outages, and complex licensing/contracting. GCP — near-full use-case coverage with real strength in data analytics and more features than competitors, but uneven customer experience and aggressive pricing that is likely to taper.

Two Fill-In-Class Discussions to Come Prepared For

Both are discussion prep, not submitted work — but both are high-value participation openings, and each maps onto one half of the deck.

Mini-Case 1 — Nexus Financial: What Should Ash Propose?

CIO Ash Patel notices IT support requests dropping — not because problems are solved, but because Finance, Marketing and HR have all quietly rolled out their own tools. COO Laura Jensen defends it as efficiency ("IT takes months to approve anything"). Head of Risk Ana Torres counters with three security gaps flagged last quarter from unsanctioned tools and asks who is accountable in a breach. CEO Daniel Kahn stops the argument and asks everyone back next week with a proposal. Ash's own closing thought is the real diagnosis: "the real challenge wasn't just IT oversight; it was getting leadership to agree on what kind of organization Nexus wanted to be."

A defensible proposal for Ash, built entirely from the deck:

• Name the structure, not the behaviour. Open by reframing shadow IT as the symptom: Nexus is running a decentralized reality with centralized accountability. Propose a federalized model — centralize what benefits from scale and consistency (architecture, security, data standards, vendor management), decentralize what needs local speed (tool selection within guardrails, prioritization within a business unit's own budget).
• Stand up a steering committee first. Per the deck this is the foundational governance practice — senior business and technology executives, officially established, defined decision rights, meeting regularly. Laura, Ana and Ash arguing in an exec meeting is exactly the vacuum a steering committee fills.
• Apply governance principle 1 immediately. Centralize information about initiatives, not the initiatives themselves — a register of what every department has bought and deployed. It costs nothing politically, it directly closes Ana's accountability gap, and it doesn't slow Laura down.
• Fix the root cause Laura named. If central IT approval genuinely takes months, no governance model survives; a pre-approved tool catalogue plus a tiered/risk-based approval path is the concession that makes the rest credible.
• Say the quiet part out loud. Ash should put the organizational question to Daniel explicitly rather than smuggling it into a process proposal — the decision is what kind of organization Nexus wants to be, and only the CEO can settle it.

Mini-Case 2 — Alcotech: Selecting a Cloud Services Provider

A mid-sized Florida company providing billing-and-payment processing to the alcoholic beverages industry, choosing a cloud provider for a new client-facing application — explicitly framed by the CIO as a first step before moving other resources and services into the cloud. Alcotech runs proprietary and locally customized package software, mostly Microsoft products. All three providers meet its well-documented requirements with only minor differences. The quotes:

Do the arithmetic before class: Microsoft is 4.5× Amazon, a delta of about $5,660/month or ~$68,000/year for one application at a medium-sized company. Amazon and Google are within 3% of each other, so the real decision is Microsoft versus not-Microsoft — Google only wins if analytics capability is the tiebreaker, and nothing in the brief says it is.

A position worth defending: recommend Azure, but conditionally — first send the quotes back. A 4.5× spread on requirements the case says are equivalent is itself a finding: either the Microsoft quote bundles licensing and support the others exclude, or the requirement spec wasn't scoped identically across the three. Establish that, then decide. If the gap survives scrutiny, Azure still likely wins on total cost of ownership across the full migration Alcotech is signalling, because ~$68k/year is small against retraining, re-platforming and integration on a stack the company doesn't run. If the CIO will only commit to this one app and nothing further, that argument collapses and Amazon is correct on price.

The counterargument to have ready: choosing a provider on the strength of your current Microsoft estate is how lock-in gets created — you're pricing tomorrow's flexibility at zero. A defensible reply is that the deck's own AWS caution (renewal pressure, offering complexity requiring third-party consultants) means lock-in is present on every option; the question is which lock-in you're already paying for.

Technology Isn't the Biggest Challenge. Culture Is.

Based on surveys of thousands of executives, the authors find most companies' AI efforts stall not from a lack of pilots but from a failure to scale past them — because scaling requires three organizational shifts most companies never make.

10 Ways to Derail an AI Program — the Shortlist Most Relevant to Pernod Ricard

• #7 — squandering time on enterprise-wide data cleaning instead of aligning data consolidation with the most valuable use cases first (echoes D-STAR's per-market data-availability constraints).
• #6 — isolating analytics from the business rather than letting analytics and business experts work closely together (the exact problem BCG's early involvement, then the GDA's structure, was designed to solve).
• #9 — neglecting to quantify bottom-line impact with a clear performance framework (Matrix's year-long TLO period before ROI was observable is a direct illustration of how long this can take even when done right).

From Absinthe to AI

Founded in 1805 by Henri-Louis Pernod, Pernod Ricard grew via a 1975 merger (called "the equivalent of a merger between General Motors and Ford" by the press) and an aggressive acquisition strategy — Seagram's Chivas/Glenlivet/Martell (2001), Allied Domecq's Ballantine's/Malibu/Mumm (2005), and Vin & Sprit's Absolut (2008) took the group from #7 to #2 globally in spirits. By 2023: 90+ production sites, 70+ largely autonomous affiliates, operations in 160+ countries, ~19,500 employees, €10.7B in FY2022 net sales, and €55B market cap.

Why Digital, Why Now

Three converging pressures: (1) competitive catch-up — rival Diageo had already launched Catalyst, a marketing analytics tool, in 2017, and investors began directly questioning Pernod Ricard's pace of digitalization; (2) portfolio complexity — 13 brands acquired 2015–2018 alone made traditional, human-heuristic brand management increasingly unmanageable ("if you have six blockbuster brands, it's relatively easy for the human brain to handle... but if you have 13 blockbusters, 15 craft brands, plus additional strategic local brands, it becomes increasingly complex"); (3) channel underperformance — mature markets like France held leadership in off-trade (retail) but lagged in on-trade (bars/restaurants), pushing senior executives toward digitalization as a lever.

The Four Key Digital Programs (KDPs)

Case-precision note: in April 2020 the executive committee prioritized six projects total — these four became the "core business KDPs"; two other, unnamed projects became separate "new business ventures" the case never revisits. Vista Rev-up and Maestria are core KDPs, not those ventures.

All four were built in-house rather than bought off-the-shelf — CDO Calloc'h's reasoning: off-the-shelf tools would need heavy recoding to match granularity requirements that vary market to market (a three-tier US market differs enormously from the UK), each KDP embeds ~50 sensitive business parameters the company didn't want to hand a third party, and qualified external vendors for this specific use case were scarce.

Why D-STAR Scaled Faster Than Matrix

Building the Global Digital Acceleration Team (GDA)

BCG got Pernod Ricard's digital transformation off the ground technically, but Jean-William Cousin's framing was blunt: "If you are following a partner, however strategic that partner is, you are not creating competitive advantage." Starting March 2021, Calloc'h and global data/analytics director David Lepicier internalized the capability — recruiting through "tech recruitment nights" (8–10 new hires in a few hours) and growing to a 130-person GDA team by 2022, with roughly half on freelance contracts to access highly specific, project-based skill profiles without long-term headcount commitments.

The Organizational Design Choice

The GDA adopted a network structure with a flatter management scheme — deliberately different from the traditional pyramid-shaped structure of Pernod Ricard's marketing and sales teams — with staff assigned to cross-functional squads for day-to-day work while remaining under the GDA umbrella. Lepicier's summary: "The reporting is not as interesting to me as how teams deliver. Lead data scientists are shaping programs and staff managers are shaping teams." This is close to a textbook version of Fountaine, McCarthy & Saleh's hub model — HQ held "the what" (business vision and product ownership), while market companies were "on the receiving end," dealing mainly with "the how."

Incentivizing Real Engagement, Not Just Compliance

As KDPs scaled, HQ shifted from a purely supportive posture to embedding KDP targets directly into affiliates' budgets and three-year strategic plans — e.g., if a project was expected to generate $1M in additional profit, HQ asked markets to commit at least 60% of that to their own targets, so overperformance became visible and rewarding rather than merely expected. This mirrors the article's "make businesses accountable" lever directly: ownership sits with the market, not the central digital team.

Format Reminder Before the Team Writes

Due Thursday 11:59pm before Session 4, based only on the Pernod Ricard case, two pages, 11-point font, written wholly by the team. This block is a structure check, not a draft.

Applying the Case Prep Protocol

Step 1 — Who and What

Decision maker: Pierre-Yves Calloc'h, chief digital officer. Core challenge: two of four KDPs (D-STAR, Matrix) are technically proven and generating measurable uplift (1.5–4.5% sales growth, up to 15% marketing efficiency) — the remaining problem is entirely about organizational adoption speed and consistency across a deliberately decentralized 70-affiliate structure, not further technology development.

Step 2 — Candidate Issues Grounded in Case Facts

1. Adoption gap between tools. D-STAR reached 85% adoption at scale versus Matrix's 60–70% — the same organization, same GDA support, materially different outcomes depending on which function (sales vs. marketing) owns the tool.
2. Emotional resistance in mature markets. France showed reluctance toward Matrix specifically due to managers' emotional attachment to brands they'd long managed, despite having richer underlying data than comparable markets like Germany.
3. Integration friction slows even willing markets. Germany's D-STAR skepticism was as much about the tool requiring double-effort (a separate system from existing sales software) as about substantive disagreement with its recommendations.
4. Data availability varies unpredictably by market. Japan's Matrix rollout was delayed weeks when weekly sales data assumed to not exist turned out to simply be undigitized — an avoidable delay that consumed pilot-phase confidence-building time.
5. Talent and continuity risk inside the GDA itself. With ~50% of the 130-person GDA on freelance contracts and marketing teams experiencing more turnover than sales teams, sustaining KDP momentum depends on a workforce structure the company deliberately built for flexibility rather than permanence.

Step 3 — A Position

Step 4 — 30-Second Cold-Call Answer

Likely Professor Questions

How to Contribute Distinctively

The Deck Is Now Available — Pick a Concept and Write the Entry Yourself

Per the syllabus (Appendix B) and the course's ban on generative AI in submitted work, this block only narrows down which slide concept to reflect on and offers prompts to help you surface your own real example. The 150–200 word concept description and the 150–200 word example both need to be written by you, in your own words — concept strictly from the Session 4 class slides, example strictly from your own professional or personal experience, never from the article or the Pernod Ricard case.

Prof. Mufti restated the rule on the deck's closing slide: reflect on one key concept from the class session slides, and apply it through one specific example from professional experience or personal observation.

Candidate Concepts — Straight From the Session 4 Slides

Questions to Surface Your Own Example

Use these to find the right real memory — the example has to be yours, not written up from the prompt itself:

• Where have you seen the same tool or change land at very different speeds in two teams inside the same organization — and what was actually different about what it asked of them? (The Redamo Labs IAM dashboard rollout, where the operations team adopted in days and the risk-review team resisted, is the obvious candidate — but write it in your own words and check it genuinely matches whichever concept you pick.)
• Where has a team you worked with built or bought its own tooling because the central function was too slow — and what did leadership do about it once they noticed?
• Where have you had to decide what to keep in-house versus hand to a vendor or agency, and what made something feel "core" enough to own?
• Where have you seen a restructuring officially endorsed at the top but quietly resisted by people whose decision rights it removed?
• Native, Owo, AfroShorts, Haven, Redamo Labs and Prodigy Education are all worth testing against whichever concept you choose — but the fit has to be genuine, not forced.

What to Walk Away Knowing

The Deck's Own Two Takeaways

Case Debrief — The Two Questions Prof. Mufti Poses

Looking Ahead — Session 5: Digital Architecture