Supply Chain Excellence

1. 1Start with education before any analysis. Brief executives on what the supply chain covers (finance, customers, employees, not only transportation and logistics) and on the payback of projects. The source holds that executives who understand the payback are more likely to fund and sponsor.
2. 2Find the informal coalition already in place and build on it. At Fowlers, a division VP's strategy had been encouraged by his president and passed to other executives, who became an informal 'gang.' Name the evangelist, the executive sponsor, and the core team before the charter is drafted.
3. 3Involve people early and in writing. Complete stakeholder interviews in Week One. Carry leftover interviews to the Week Two kickoff, and fold them into a revised project charter under a stakeholder expectations section.
4. 4Make the kickoff a shared-vision event. Combine three ingredients: the business context for improvement, SCOR education, and key points of the approved charter. Lead with the schedule, which is what most people care about, and give attendees time to sync their calendars to the design and steering team rhythm.
5. 5Build breadth into the brainstorm. Invite people close to day-to-day material movement, covering purchase-order, work-order, and sales-order levels, and stay below the top of the organization. Quantity of issues with examples matters most at this stage. Participants leave with a sense of the project's pace and carry its values to their departments.
6. 6Validate the analysis before the steering team sees it. Apply the five opportunity-analysis principles: constant revenue, realistic savings, documented assumptions, and objective validation resources that spar with the numbers and assumptions. Validators improve accuracy and gain a sense of ownership.
7. 7Secure ownership of quick-hit projects one layer at a time. Rank a short list of leaders from the extended team, each reporting through a steering-team department. Get steering-team consensus on one or two names. Have a steering member phone each candidate's boss, then meet each boss to commit the time allocation, then meet each candidate to discuss the mini-charter.
8. 8Watch for ownership signals and recognize them. When the implementation leader starts tweaking mini-charter action steps, timing, and responsibilities to fit their own expertise and style, ownership has taken hold. Publicly recognize the leader for taking on the responsibility.

At Fowlers Inc., COO Brian Dowell called after finding the Supply-Chain Council through a web search. The consultants found that David Able, VP of operations in the technology products group, had pieced together a supply chain strategy from limited background and a lot of operating pain. His division president encouraged it and brought it to other executives, who became an informal 'gang.' That coalition became the base of support. At the Week Two kickoff, David Able presented the business context, SCOR education, and key charter points, emphasizing the schedule and leaving time for attendees to sync calendars. Leftover stakeholder interviews were scheduled there and fed into a revised charter. For the quick-hit project, Able and Dowell shortlisted a buyer/planner for the largest Asian commodity purchases and a logistics engineer. Both had attended the disconnect brainstorm and reported through purchasing or logistics. Supplier relationships broke the tie, and the buyer/planner was chosen. They then met with the commodity manager in charge before sharing the news. Every step moved ownership from a few executives to people doing the work.

• If executives hesitate to fund or sponsor, then invest in education on payback (finance, customers, employees) before presenting more analysis.
• If a brainstorm invitee list skews senior, then replace them with people at the purchase-order, work-order, and sales-order level, because senior people struggle to give specific examples.
• If the steering team pushes back on savings numbers, then look to your assumptions first; document every assumption and have an objective validator test them before the review.
• If you pick a quick-hit leader, then require the leader's boss to commit the time allocation first, via a steering member's call and an individual meeting.
• If estimates feel like a WAG, then round to the nearest $100,000 or $50,000 and document assumptions; conservative realism is fine, gross sandbagging is not.

• Treating the supply chain as only transportation and logistics, so executives underestimate its payback. The tell: sponsors stay lukewarm and funding stalls.
• Skipping stakeholder interviews or the revised charter. The tell: people at the kickoff don't see their expectations reflected and treat the project as someone else's.
• Inviting senior managers to the brainstorm to look inclusive. The tell: vague issue lists with few concrete examples to drive root cause analysis.
• Sharing savings estimates with the steering team before validation, or with undocumented assumptions. The tell: debate centers on assumptions rather than the numbers, and validators were never given a chance to take ownership.
• Naming an implementation leader without the boss's buy-in. The tell: the leader is overloaded, the time commitment is unsupported, and no one tweaks the mini-charter, so ownership never shows.

• ▸Stakeholder / role: name each executive, sponsor, core team member, and quick-hit leader.
• ▸Current stance: record whether each is a supporter, neutral, or skeptic, and the evidence.
• ▸Education delivered: note what was explained (payback in finance, customers, employees) and when.
• ▸Stakeholder interview status: record whether interviewed, the date, and expectations captured in the charter.
• ▸Involvement touchpoint: list the kickoff, brainstorm, or validation role assigned to this person.
• ▸Boss commitment: record the time allocation agreed with the person's boss and who made the call or held the meeting.
• ▸Assumptions documented: list the assumptions behind any savings estimate this person will see.
• ▸Validator assigned: name who will test the numbers and assumptions before the steering review.
• ▸Ownership signal observed: note any changes the person made to the plan and the recognition given.

1. 1Name the system boundary first. Write the chain as SCOR does: supplier inputs (capital, human resources, raw materials), the organization (business processes and functions), the customer, competitors for supplies and customers, and other factors that touch the system. If a team member cannot draw these relationships, they are not yet reasoning as a process thinker.
2. 2Screen steering team members for process orientation before you seat them. Check four traits: level of authority, cross-functional relationships (a history of building relationships, not 'my way or the highway' casualties), a sense of how the whole business works, and the ability to cope with chaos. Hand-select a core group, because some steering members will not be forward thinking.
3. 3Restate every performance problem as an interaction between steps, not as a function's failure. Trace where the problem appears (P&L, balance sheet, KPIs, customer report cards) back through the process steps that produce it.
4. 4Use the SCOR cascade to link a result to its upstream causes. Order management costs cascade to customer service, outbound transportation, and finished goods warehouse costs. Read each metric through its Level Two and Level Three components rather than through one department's budget.
5. 5Review work in two passes. Pass one: read what is actually on the spreadsheet or map. Pass two (the more important one): list learning points, both old-but-forgotten knowledge and new discoveries. This second pass feeds the Week Seven disconnect analysis.
6. 6Hold the forest and the trees together. Do not judge the flow from the geographic map alone (forest), which prevents assigning relative values to compare issues. Do not fix each flow issue in isolation (trees), which ignores the efficiency of the total system. Assign dollar values so issues can be compared against each other.
7. 7Ask clarifying questions before giving opinions. Reviewers confirm they understand the material, bring a list of checking questions, and test the logic. Reserve opinion for decision forks, and give it only after dialogue and critique.
8. 8Flag silo behavior as it appears and address it early. The source treats it as one of the first big changes in a SCOR project, and reads it as an attempt to avoid chaos. Name it in the review and redirect to the cross-functional view.

In the Fowlers case, the Week Six review of the technology products material flow spreadsheet is split in two. Part one reads the numbers: the first four locations are corporate regional distribution centers and the last four are manufacturing sites. Of $450 million 2001 revenue, $150 million is OEM (served by manufacturing locations through CD-ROM replication, fulfillment, and life cycle management) and $300 million is retail (served by distribution centers selling optical drives and media). Warehouse expense totals $8.1 million, or 1.8 percent of sales. The team notes that distribution centers isolate finished goods handling only, while manufacturing sites accumulate both finished goods and raw materials/work-in-process, so the figures are not like-for-like. Part two, the more important one, records learning points that seed the Week Seven disconnect analysis. The reviewers also link the numbers to the SCOR cascade: order management costs flow into customer service, outbound transportation, and finished goods warehouse costs. They read the warehouse and transportation lines as one connected system, not as separate departmental budgets.

• If a steering candidate has a record of 'my way or the highway' relationships or cannot describe how the whole business works, then do not seat them in the core group, however senior they are.
• If a review drifts toward opinion before the team can restate the design logic, then stop and return to checking questions; opinion waits for the decision forks.
• If you are looking only at the geographic map, then add dollar values from the performance summary so issues can be compared; if you are fixing a single flow issue, then check its effect on total-system efficiency first.
• If a cost or performance problem is attributed to one function, then trace it through the SCOR cascade to the Level Two and Three components before assigning an owner.
• If a team member defends territory and shuts out cross-functional input, then treat it as silo behavior and surface it as one of the first changes to address.

• Forest-only analysis: the team reviews the geographic map and cannot rank one issue against another. The tell is a list of flow problems with no dollar values attached.
• Trees-only fixing: each material flow issue is resolved on its own. The tell is local fixes that raise cost or complexity elsewhere, and no total-system measure.
• Silo steering team: members guard functional turf, as in 'build a big wall.' The tell is each executive defending a departmental strategy without a combined blueprint, as with three VPs who each succeeded in their own areas but had no enterprise plan.
• Opinion-first review: reviewers judge before they understand the material. The tell is verdicts delivered without checking questions or logic walkthroughs.
• Functional organization against a horizontal system: rigid vertical functions direct AS IS practice while the ERP is organized by transaction flow. The tell is processes that automate yet start going wrong.

• ▸Process or issue under review: name the specific process step or performance problem.
• ▸System map: list supplier inputs, organization functions, customer, competitors, and other factors touching the system.
• ▸Functions involved: list every function whose steps interact to produce the result.
• ▸Metric cascade: write the Level Two and Three metrics that feed the result (e.g., order management to customer service, outbound transportation, finished goods warehouse).
• ▸Forest view: state the macro picture from the map or flow.
• ▸Trees view: list the individual flow issues, each with a dollar value.
• ▸Total-system effect: note how fixing each issue changes overall efficiency.
• ▸Learning points: record old-but-forgotten knowledge and new discoveries.
• ▸Silo signals: note any territorial behavior observed and the action to address it.

1. 1Start with education, not the project plan. The source's first lifecycle step is 'educating the enterprise about supply chain improvement to gain support.' Its first 'a-ha' is that executives who understand the payback of supply chain projects are more likely to fund and sponsor them. Run the education in public, so leaders learn in front of each other regardless of rank.
2. 2Name the three roles that carry readiness before kickoff: the Evangelist, the Active Executive Sponsor, and core team buy-in. These are the headings of the support-building chapter. For each role, write down the person, what they have been asked to do, and whether they have said yes.
3. 3Build the burning platform from measured gaps. The source sequence is benchmarks, competitive requirements, SCORcards, then gap analysis. Each gap is a measured statement of present pain against competitors. Put the gaps in front of the Steering Team before proposing any solution.
4. 4Convert pain into financial terms, because pain only counts if it exceeds transition cost. Use the source's cost-side steps: opportunity analysis, TO BE productivity spreadsheets, project portfolio, and return-on-investment analysis. Place the projected return beside the effort, resources, and disruption the change demands.
5. 5Test for resource and goal conflict before you commit. Check whether the same financial, human, and technical resources are promised to several initiatives. If they are, prioritize with the balanced project mix grid and the disconnect opportunity grid rather than adding projects.
6. 6Plan early visible wins. Use quick-hit mini-charters (Week Ten and Week Eleven) so the organization sees movement before the full blueprint lands. This builds the evidence that makes the longer transition believable.
7. 7Use the Steering Team Reviews (eight in the Fowlers case) as readiness checkpoints. At each one, ask whether sponsorship, understanding, and resource commitment are still intact. Decide go, adjust, or pause at that review rather than discovering resistance during implementation.
8. 8Check the culture shift explicitly. If the change moves the company from functional management to process management, name that move and test whether leaders view the organization as processes rather than silos.

Scenario Nine in the source: a vice president of administration is pressured by her colleagues to replace a two-year-old transactional system with a new, name-brand system offering advanced supply chain planning. The pressure is perceived pain, but her ROI analysis 'just wasn't adding up,' so the pain does not exceed the transition cost. She investigates further and finds that not every business leader is complaining. She finds a direct correlation between a leader's satisfaction and the effort that leader put into learning the existing system. A readiness reader draws the lesson: the complaint is a symptom of low learning effort, not of a gap that justifies the cost of replacement. She would take the ROI result and the satisfaction correlation to the complaining colleagues and put education ahead of purchase. The source does not report the final outcome, so treat this as a method for testing whether pain is real, not as a result. The test is to compute return, then check who is complaining and how much effort they invested.

• If leaders cannot explain the payback of the supply chain project in finance, customer, and employee terms, then run education before asking for funding or sponsorship.
• If the ROI analysis does not support the change (as in the system-replacement scenario), then do not proceed on pressure alone; investigate who is dissatisfied and why before spending.
• If several initiatives draw on the same financial, human, and technical resources, or goals conflict, then prioritize and align objectives before adding any new project (the forty-five-project scenario).
• If the sponsor is not personally learning and visibly engaged, then treat readiness as low regardless of team enthusiasm; the source says sponsors are better served by the educate-for-support behaviors.
• If the organization is functionally siloed while the change is process-based (the ERP scenario), then plan the shift from functional to process management as part of the change, not as a side effect.

• Pressure mistaken for pain: a project launches because colleagues demand it, but no measured gap or ROI supports it. The tell: the business case is built after the decision, and the numbers 'don't add up.'
• Brainstorm overload: a dozen managers produce a long list (forty-five projects) and everything starts at once. The tell: general managers are asked to support multiple initiatives with the same resources, and goals appear in conflict.
• Sponsor in name only: an executive approves funding but does not learn alongside the team. The tell: the sponsor avoids public learning forums and cannot answer the basic 'What is it? Why? How do we start?' questions.
• Education skipped for speed: the team jumps to design work without building understanding. The tell: executives do not grasp the payback and funding stalls at the portfolio and ROI stage.
• Culture ignored: a horizontal, transaction-flow change is installed on rigid vertical functions. The tell: things 'suddenly start to go wrong' as automation rolls out, because AS IS practices are still directed by functional silos.

• ▸Burning platform statement: Write the measured gap (benchmark, SCORcard, or gap analysis result) that defines present pain.
• ▸Pain in financial terms: State the quantified cost of staying as-is, from the opportunity and productivity analyses.
• ▸Transition cost: List projected spend, people, technical resources, and disruption from the project portfolio and ROI analysis.
• ▸Pain vs. cost verdict: Write 'pain exceeds cost,' 'cost exceeds pain,' or 'unknown,' and cite the numbers.
• ▸Executive sponsor status: Record the sponsor's name, what they have personally learned, and whether they act visibly in public.
• ▸Evangelist and core team buy-in: Note who is advocating and which core team members have not yet committed.
• ▸Resource and goal conflicts: List initiatives competing for the same financial, human, and technical resources, and any conflicting goals.
• ▸Culture fit: State whether the change requires moving from functional to process management and who is not yet seeing it.
• ▸Early-win plan: Name the quick-hit mini-charter, owner, and date that will show visible results.
• ▸Decision: Mark go, adjust, or pause, with the one action that must be done before the next review.

1. 1Start from the inputs, not a blank page. Pull the SCORcard gap analysis (actual vs. benchmark), the competitive requirements prioritized by product and channel, and the AS IS maps with their disconnects. These priorities govern the design phase, so any TO BE change that does not trace to one of them is out of scope.
2. 2Set the mapping level before drawing TO BE material flows. Use the highest level (product line or group before family, family before SKU) that still exposes tactical and strategic inefficiencies in service levels, transportation cost, lead time, and days of inventory. Map from the product (row) view of the supply chain definition matrix, because locations, commodities, and key suppliers group by row.
3. 3Redesign the material flow to close each disconnect. For every disconnect on the AS IS map, name the SCOR leading practice that addresses it, drawing from Appendix D (sorted by business area). Record the practice next to the changed flow so the redesign is a designed answer, not a preference.
4. 4Redesign work and information flow at SCOR process level. Define TO BE PLAN, SOURCE, MAKE, DELIVER, and RETURN processes with their inputs and outputs. Refine the productivity spreadsheet for each process, for example S1.1 schedule product deliveries, and pair a before swim diagram with an after swim diagram so the change in steps and hand-offs is visible.
5. 5Answer the two design-phase questions in writing for every redesign: what is the material flow problem and what is it worth to solve, and how efficient is the work and information flow and what is it worth to change. A redesign without a value attached is not ready for the portfolio.
6. 6Update the disconnect opportunity grid with the TO BE results. Then consolidate every redesign into one overall project portfolio, checking the mix with the balanced project mix grid. Express quick hits as mini-charters (Fowlers' Asia-Pacific transportation consolidation is the model).
7. 7Initiate the return-on-investment analysis on the portfolio and test the TO BE with business test scenarios, such as the purchase order scenario Fowlers used. Take the portfolio and projected ROI to the final steering team review. Stop at the portfolio; detailed project planning and rollout (initiate, plan, execute, close) comes after approval.

Fowlers, the book's running case, shows the sequence in Weeks 15 to 17. In Chapter 17 the team builds TO BE PLAN processes with inputs and outputs, and tests them with a purchase order business test scenario. In Week Sixteen (Chapter 18) it refines the TO BE productivity spreadsheet for S1.1, schedule product deliveries, and documents the change with a before swim diagram and an after swim diagram. It then revisits the disconnect opportunity grid first built in Chapter 11 and issues an updated version (Figure 18-4). The updated grid feeds the overall project portfolio (Figure 18-5), which includes quick-hit work of the kind shown in the Asia-Pacific transportation consolidation mini-charter. The team starts the ROI analysis here. In Week Seventeen (Chapter 19) the result is presented as the project portfolio and projected return on investment (Figure 19-1) at the final steering team review. The passages give the artifacts but not Fowlers' dollar figures, so treat the artifact chain as the model: disconnect, leading practice, before/after flow, value, grid, portfolio, ROI. For scale, the book reports an average 3 percent of sales operating income improvement for initial SCOR portfolios.

• If a proposed project cannot be traced to a SCORcard gap or a competitive requirement for a product or channel, then drop it or park it; the analysis phase set the priorities for the design phase.
• If a redesign does not answer 'what is it worth,' then it stays out of the portfolio until it is valued.
• If mapping detail at SKU level does not reveal anything more about service, transportation cost, lead time, or inventory days than the family or line level does, then stay at the higher level.
• If a TO BE flow changes only materials, then check the work and information flow too; the design phase treats both as key components and values each separately.
• If a project requires detailed planning to estimate, then keep the portfolio entry at charter or mini-charter depth and defer the planning to the implementation project cycle.

• Mapping at too fine a level (SKU for everything): the TO BE effort stalls and the maps hide strategic issues. The tell: weeks of mapping but no clear view of service, transport cost, lead time, or inventory-day gaps.
• Redesigning from opinion rather than leading practices: the TO BE reads as a wish list. The tell: no Appendix D-style practice is named beside any changed flow.
• Redesigning material flow but leaving information and work flow AS IS: the disconnect returns in the process. The tell: material maps are updated but there are no before/after swim diagrams or TO BE process input/output definitions.
• Portfolio built without values, or without a balanced mix: you get a list of ideas rather than a sequenced, valued set. The tell: no ROI column, and every project is large and long, with no quick-hit mini-charters.
• Treating the portfolio as the project plan: scope bloats into implementation detail. The tell: portfolio entries contain task schedules while the steering team still cannot see total value.

• ▸Project name: short label, such as a quick hit or a process redesign.
• ▸Linked disconnect: the disconnect-grid entry this project closes.
• ▸SCORcard gap / competitive requirement: the metric gap and the product or channel priority it serves.
• ▸Flow type: material, work, information, or a combination.
• ▸Leading practice applied: the named SCOR practice (Appendix D) behind the TO BE design.
• ▸AS IS vs. TO BE change: one line each, with reference to the before/after swim diagram or map.
• ▸Value estimate: what it is worth to solve, in the measure the SCORcard uses (cost, service, cash, inventory days).
• ▸Quick hit or larger project: category for the balanced project mix grid.
• ▸Business test scenario: the scenario that confirms the TO BE works, such as a purchase order walk-through.
• ▸Steering team decision: approved, deferred, or rejected, with the date.

1. 1Freeze the baseline before any project starts. Use the Week One Business Context Summary: consolidated income statement, balance sheet, and revenue and operating income by product group (the Fowlers tables 3-1 to 3-3 are the model). Realized shareholder gains can only be claimed against these numbers, so record them with the period they cover.
2. 2Build the SCORcard from all three metric families in the Chapter 4 templates: customer-facing (delivery reliability), internal-facing (cost, cash-to-cash, inventory), and shareholder-facing (operating income, ROI). Keep a balanced set. A card with only one family cannot show whether a gain in one came at the expense of another.
3. 3Fill each metric with your own actual and an industry benchmark from the comparison spreadsheet. Then run the gap analysis (Week Four) and attach competitive requirements to each metric. The gap and the requirement together define what an 'improvement' means, so a gain is judged against the gap, not against last year.
4. 4Score by product group as well as enterprise. Fowlers builds an enterprise SCORcard plus separate food products and technology products SCORcards. A blended number can hide a gain in one group and a loss in the other.
5. 5Tie every project to a named SCORcard metric. Trace gaps through the material flow performance spreadsheet, the disconnect fishbone (for example, poor planning) and the opportunity spreadsheet. The opportunity analysis is where you record which metric a fix is expected to move.
6. 6Convert the TO BE changes into productivity spreadsheets, then into a project portfolio, using the balanced project mix grid to include quick hits (Fowlers' Asia-Pacific transportation consolidation mini-charter). Initiate the ROI analysis (Week Sixteen) and publish projected ROI (Week Seventeen) as the forecast you will later test.
7. 7After implementation, re-measure on the same SCORcard, with the same metric definitions, benchmark set and product-group cuts. Compare actual to baseline and to the projection. Credit a gain to the SCOR effort only where a project in the portfolio maps to the metric that moved.
8. 8Report realized gains in the three families and in the order the chain runs: delivery reliability, then cost, cash-to-cash and inventory, then operating income and ROI. A shareholder number with no customer or internal movement beneath it is suspect.

The passages give Fowlers' structure but not its numbers, so this example shows the trace and marks where your own figures go. Fowlers has two product groups, food products and technology products, and Week One records revenue and operating income for each. Weeks Two to Four put customer-, internal- and shareholder-facing metrics on an enterprise SCORcard and on a SCORcard for each group, with benchmark gaps and competitive requirements. Suppose the technology group shows a delivery-reliability gap. The Week Seven brainstorm and fishbone point to poor planning as a root cause, and the Week Nine opportunity analysis assigns an expected effect to that cause. Separately, the Asia-Pacific transportation consolidation quick hit targets cost, an internal-facing metric. Week Seventeen projects ROI for the whole portfolio. Later, you re-read the technology SCORcard: delivery reliability [baseline → actual], cash-to-cash [baseline → actual], operating income [baseline → actual]. Gains are credited only where the planning project and the transport quick hit map to the metric that moved. Anything left over is reported as unattributed.

• If a metric moved but no portfolio project maps to it, then report it as unattributed rather than as a SCOR gain.
• If the enterprise number improves but a product-group SCORcard worsens, then report the group result first and investigate the mix.
• If operating income or ROI improves with no customer-facing or internal-facing movement, then treat the shareholder gain as unproven until you find the operational cause.
• If the metric definition, benchmark source, or period changed since the baseline, then restate the baseline before claiming a gain.
• If realized ROI falls short of the Week Seventeen projection, then compare the project-level assumptions in the TO BE productivity spreadsheets before blaming execution.

• Measuring against a moved baseline. The tell: the baseline figures cannot be traced to the Week One income statement, balance sheet or Week Four SCORcard.
• Reporting one metric family. The tell: you can quote delivery performance or cost savings, but not cash-to-cash, inventory or operating income alongside them.
• Enterprise-only reporting. The tell: there are no per-product-group SCORcards, so a weak group is hidden by a strong one.
• Claiming shareholder returns without a link to projects. The tell: operating income rose but no opportunity-analysis line names the metric a project was meant to move.
• Forecast never re-tested. The tell: the projected ROI from the final steering review is not revisited after implementation, so nobody can say whether the gain was realized.

• ▸Metric and family: name the SCORcard metric and mark it customer-, internal- or shareholder-facing.
• ▸Product group / scope: enterprise or a single group (for example, food products or technology products).
• ▸Baseline value and date: take it from the Week One and Week Four baseline and record the period.
• ▸Benchmark and competitive requirement: the industry comparison value and the requirement from the gap analysis.
• ▸Current value and date: re-measured with the same definition and scope.
• ▸Linked project(s): the portfolio project or quick hit expected to move this metric, with the opportunity-analysis line it came from.
• ▸Projected vs. realized effect: the Week Seventeen projection beside the measured change.
• ▸Attribution status: attributed, partly attributed, or unattributed, with a one-line reason.
• ▸Downstream check: the customer-facing or internal-facing movement that supports any shareholder-facing claim.

1. 1Pair the sponsor with the evangelist before anything else. The source treats them as two required roles: the evangelist has the passion to lead the project, and an executive with authority actively sponsors it. Name both in writing before the Discover phase starts.
2. 2Put the sponsor's own time into SCOR education. The source says both the evangelist and the executive must invest personal time to learn SCOR, and that if the executive delegates this initial learning, the organization will probably fail to sustain change. Book the workshops and executive briefings on the sponsor's calendar, with no delegate attending.
3. 3Teach the sponsor the payback in three terms: finance, customers, and employees. The source says executives who understand the payback of supply chain projects are more likely to fund and sponsor them. Do not argue the importance of supply chain management; show what the measured gaps are worth.
4. 4Fund the effort with a real budget line before kickoff. Fowlers' charter shows the form: coach 50 days at $2,000 ($100K), Supply-Chain Council membership $2K, competitive benchmarking $2K, total $104K. Ask the sponsor to approve the figure and own it.
5. 5Assemble a steering team with cross-functional authority. At Fowlers it included three group presidents, the CFO, the VPs of Sales and Marketing, the CIO, and the COO as project sponsor. Its stated roles include 'Ensure organizational commitment' and 'Resolve cross-functional issues.' The sponsor chairs it.
6. 6Fix the steering team's review dates on the calendar in advance. The roadmap has Steering Team Review Number One in Week 3 and Number Two in Week 5. Treat consistent availability of steering and design team members as a named project risk, as Fowlers does.
7. 7List executive sponsorship as the first risk and dependency in the charter. Fowlers lists 'Executive sponsorship from Fowlers' business units' first. Check it at every review: is sponsorship visible in each business unit, or only at the top?
8. 8Use the sponsor to settle resource conflicts. Scenario Four in the source shows the failure: forty-five high-priority projects drew on the same financial, human, and technical resources, and goals conflicted. Bring those conflicts to the sponsor to align objectives and prioritize.

Fowlers Inc. shows the structure of sponsorship. Brian Dowell, COO, is the named project sponsor on the organization chart. Above the design team sits a steering team of the Durable Products, Technology Products, and Food Products Group presidents, the CFO, the VPs of Sales and Marketing, and the CIO. Its roles include ensuring organizational commitment and resolving cross-functional issues. The charter commits $104K: $100K for 50 coach days at $2,000, plus $2K for Supply-Chain Council membership and $2K for benchmarking. Its first listed risk is executive sponsorship from the Fowlers business units, and its fourth is consistent availability of steering committee and design team members. Steering Team Review Number One falls in Week 3, after benchmarks and competitive requirements, and Number Two in Week 5, after the gap analysis is validated. The passages do not show Dowell's day-to-day actions, so read the structure rather than the behavior: a named sponsor, funded money, a cross-functional authority body, dated reviews, and sponsorship stated as a risk to be managed.

• If the executive proposes to delegate the initial SCOR learning, then hold the kickoff. The source ties delegated learning to a probable failure to sustain change.
• If the executive questions the value of the project, then show the finance, customer, and employee payback in measured terms. Do not argue that supply chain management matters in general.
• If projects compete for the same financial, human, and technical resources, then escalate to the sponsor and steering team to align objectives and prioritize. Do not let general managers negotiate it one by one.
• If sponsorship comes from only one executive while the work spans business units, then list business-unit sponsorship as a charter risk and recruit the unit heads onto the steering team.
• If steering or design team members cannot attend consistently, then raise it at the next steering review as a project risk. Do not absorb the gap quietly.

• Delegated sponsorship: a deputy attends the workshops and briefings. The tell is that the sponsor cannot explain the SCOR payback in their own words, and the change fades after the project ends.
• Title-only sponsor: a name sits on the organization chart but no budget line or calendar commitment exists. The tell is that the charter has no funding figure and the sponsor misses steering reviews.
• Selling the topic instead of the payback: you argue that supply chain matters rather than showing measured opportunity. The tell is polite interest with no funding decision.
• Portfolio overload: forty-five projects are launched with no prioritization. The tell is general managers asking for the same resources and goals in conflict.
• Unmanaged availability: steering and design team members attend inconsistently. The tell is that reviews slip, and Week 3 and Week 5 decisions stall.

• ▸Sponsor name and title: the executive with authority over the business units affected.
• ▸Evangelist name: the person with the passion to lead the project day to day.
• ▸Personal education commitments: list the workshops and executive briefings the sponsor will attend, with dates. No delegates.
• ▸Payback statement: the sponsor's own words on the finance, customer, and employee payback.
• ▸Approved budget: itemized, for example coach days x rate, council membership, benchmarking, with the total.
• ▸Steering team roster and roles: names, plus the duties 'ensure organizational commitment' and 'resolve cross-functional issues.'
• ▸Steering review dates: Review Number One (Week 3) and Number Two (Week 5), confirmed on calendars.
• ▸Sponsorship risks: business-unit sponsorship and team availability, each with a mitigation owner.
• ▸Resource-conflict escalation path: how competing project demands reach the sponsor and who decides priority.

1. 1Name the role before the project: the evangelist is the person best able to learn SCOR, sell it to upper management, pilot a project and gain early results, and become executive-level project manager for spreading it. If nobody steps up, the source says a SCOR-based project probably cannot succeed, so treat an empty seat as a stop condition.
2. 2Choose the route: self-selected or appointed from above. Either way, the evangelist's first assignment is typically project manager of the first SCOR project. Get the executive (the COO at Fowlers) to confirm the choice explicitly.
3. 3Screen the candidate against the resume the source lists. Check financial responsibility and accountability (building a P&L and balance sheet, telling the business story behind the numbers, defending executive critique, explaining bad news with confidence, preparing for operations reviews). Check experience aligning business goals with operations, and having worked on an enterprise project such as a large reengineering effort.
4. 4Verify the soft skills with the people who worked for the candidate, not with the candidate. At Fowlers, David Able's staff confirmed his ability to teach, communicate, resolve conflict, and add humor at the right time. Ask the same four questions.
5. 5Commit personal learning time up front. The evangelist and the executive sponsor must both be willing to invest personal time to learn SCOR. The model can't teach people who aren't ready to learn, so the evangelist learns first and does not hand the learning to others.
6. 6Run the education sell as a teaching job. Everyone arrives with preexisting ideas of what a supply chain is and how it fits operational strategy. Use SCOR's credibility as an industry standard, backed by a long list of successful case studies, to make the sell easier, but do the teaching yourself.
7. 7Pair the evangelist with an active executive sponsor and core steering team members, the other two education roles. The evangelist's reach into the business runs through them. At Fowlers, the COO confirmed David Able and then quickly became the sponsor.
8. 8Use the first project as the proof. Pilot it, produce early results, then spread the method through the business as executive-level project manager.

At Fowlers, Brian Dowell, the COO, had already pushed Joe, Martha, and Doris to look for outside help when the company began to build support. The first step was to develop an evangelist. David Able, vice president of operations in the technology products group, placed himself in the role. His reasons were his interest in supply chain integration, his diverse background, and his reputation as an effective, influential manager. Brian readily confirmed him and soon became the executive sponsor. The fit held up against the resume test: fifteen years at the company showed he knew how things work, and he had taken part in a large-scale reengineering effort a few years earlier, so he had seen how an enterprise project runs. People who worked for him confirmed he could teach, communicate, resolve conflict, and add humor at just the right time. As evangelist, he was also the first project manager of the first SCOR project.

• If no one credible steps up as evangelist, then pause the SCOR project; the source says it probably cannot succeed without one.
• If the candidate volunteers, then still require executive confirmation, as Brian Dowell gave David Able, before treating the role as filled.
• If the candidate lacks P&L and balance sheet fluency or cannot defend executive critique, then do not appoint them, however enthusiastic they are.
• If the executive wants to delegate the initial SCOR learning, then refuse; the source predicts the organization will probably fail to sustain change over time.
• If you must pick between passion and credibility with executives, then choose the person who can do both, because the role requires selling to upper management and managing conflict.

• Enthusiast without credentials: the candidate lacks financial accountability. The tell is that they cannot explain bad news or defend a number in an operations review.
• Delegated learning: the executive sends someone else to learn SCOR. The tell is that the sponsor cannot explain the model, and change fades after the first project.
• Trusting the model to sell itself: the evangelist leans on SCOR's case studies and skips teaching. The tell is that people who aren't ready to learn stay skeptical and keep their own definitions of supply chain.
• Solo evangelist: no active sponsor or core steering team members are in place. The tell is that you have passion but no executive access or backing for conflict.
• Evangelist with no project role: the person is called champion but does not manage the first project. The tell is no early results to show and no executive-level project management of the spread.

• ▸Candidate name and current role: record who, and whether self-selected or appointed from above.
• ▸Executive who confirms the role: name the person (e.g., COO) and the date of confirmation.
• ▸Financial responsibility and accountability: note evidence of P&L/balance sheet knowledge and defending executive critique.
• ▸Business-goal alignment and enterprise project experience: list reengineering or similar projects the candidate worked on.
• ▸Teach / communicate / resolve conflict / humor: record what direct reports said on each of the four.
• ▸SCOR learning commitment: state the personal time the evangelist will invest, and the sponsor's matching commitment.
• ▸First SCOR project and role: name the project and confirm the evangelist is its project manager.
• ▸Sponsor and steering team pairing: list the active executive sponsor and core steering members.
• ▸Gaps and action: note what's missing and who closes it before kickoff.

1. 1Fix the calendar before kickoff. The roadmap runs seventeen weeks, one chapter per week. Each week is two days of meetings plus follow-up assignments. Put all seventeen weeks on the calendar with the two meeting days blocked, so a missed week is visible as a slip.
2. 2Build Week One's three deliverables as the control baseline: the Business Context Summary, the Project Charter, and kickoff preparation (the agenda and the scope matrix). Everything later is checked against the charter and the project scope matrix. If they are vague, no later review has anything to test against.
3. 3Run each week as a deliverable, not an activity. Name the artifact due that week: metrics template and benchmark definitions (Wk 2), industry comparison data and the competitive requirements summary (Wk 3), SCORcards and gap analysis (Wk 4), and so on through the TO BE productivity summary and project portfolio (Wk 16). The two meeting days produce the draft. The follow-up assignments close it.
4. 4Assign every open item to a named owner who is responsible for completing and validating it. At Fowlers, David Able assigned the twelve consolidated problem statements to design team members, who led the root cause and opportunity analysis. If there are more problems than leaders, one leader takes several. Give each owner a plan to finish before the group disperses.
5. 5Hold the steering team reviews as gates, not status updates. Review Number One falls in Week Three, after benchmarks and the competitive requirements exercise. Further reviews follow the material flow analysis in Week Seven, the AS IS swim diagrams (Review Number Six), the TO BE blueprint (Review Number Seven, Week Fifteen), and the implementation plan (Review Number Eight, Week Seventeen). Prepare the deliverables for each review the week before it, as the roadmap does for Review One.
6. 6Follow each method's rules exactly. In the chip exercise, set one superior and one advantage per channel, with the other two attributes at parity. Hide the actual data from the players. Reach consensus. Repeat it with the design team, then the steering team, then each business team. Run fishbones to the second level of bones. Rule-following is what keeps the analysis comparable from week to week.
7. 7Treat change management and project management as work the roadmap does not do for you. The source says the roadmap tells you where to go but not how to drive. Plan these explicitly: who approves a scope or schedule change, who is told, and which deliverable is re-baselined. The source gives no procedure, so write your own into the charter.
8. 8Close at Week Seventeen with the implementation plan, the project portfolio and return-on-investment analysis, and the final steering review. The project is not finished until that review is held.

Fowlers in Week Three shows discipline applied to one deliverable. The design team ran the chip exercise with the coach facilitating. The coach reviewed the metric categories and definitions but did not reveal actual data, because people place the superior chip where they see the most improvement needed, not where the strategic advantage lies. The team used the five channels in scope from the project scope matrix (Table 3-5) as its baseline. For each channel it could set only one attribute at superior and one at advantage, with the other two at parity. It concluded that only three supply chains had unique requirements, because all of Fowlers' U.S. retail markets shared the same overall performance requirements. The result went into the competitive requirements summary (Figure 5-2) and fed Steering Team Review Number One. The steering team then repeats the exercise, and each business team repeats it again later. The same rigor shows up in Week Seven. David Able consolidated twelve problem statements, such as Poor Inventory Planning and No Formal Return Management. He assigned each to a design team leader for fishbone root cause analysis, and each leader owned the validated result.

• If the team is split on a close chip call, then assign numeric values (3 superior, 2 advantage, 1 parity) and drive to consensus. Do not let it ride to the review unresolved.
• If someone proposes showing real performance data during the chip exercise, then hold it back. The exercise is strategic, not goal-setting, and data pulls the superior chip toward the weakest spot.
• If a deliverable for the week is not validated by its owner, then it does not go to the steering team. Reviews test finished work, not drafts.
• If a request would change scope, schedule, or a deliverable, then route it through the change step you wrote into the charter and re-baseline the affected weeks. The roadmap does not do this for you.
• If a project is narrow or has quick wins, then keep the full roadmap sequence but size the deliverables to the charter's scope. Fowlers' quick-hit mini-charter for Asia-Pacific transportation consolidation shows a small project still gets a charter.

• The charter is written once and filed. The tell: by mid-project nobody can say what the scope matrix excludes, and new requests are accepted informally.
• Steering reviews become status updates. The tell: the meeting ends without a decision about the deliverable presented, and the next week starts without the review's feedback.
• Deliverables are marked done without a validating owner. The tell: the same problem statement or analysis resurfaces in later weeks because nobody was accountable for checking it.
• The method rules are bent to be comfortable, such as several superior chips per channel or data revealed up front. The tell: every channel is rated superior, or the results map to current pain points rather than the strategy driver.
• The roadmap is assumed to cover change and project management. The tell: schedule slips and scope changes appear with no log, no approver, and no re-baselined plan, because the source says these live between the lines of the roadmap.

• ▸Week and phase: the week number (1-17) and its phase (Discover, Analyze, Design).
• ▸Deliverable due: the named artifact for this week, for example the SCORcard or the TO BE productivity summary.
• ▸Meeting dates (two days): the two scheduled meeting days, so a missed one shows as a slip.
• ▸Owner and validator: the person responsible for completing the work and the person who confirms it is correct.
• ▸Follow-up assignments: items to finish after the meetings, each with an owner and a due date.
• ▸Charter and scope check: does the deliverable stay within the charter and project scope matrix? Yes or no, and why.
• ▸Steering review gate: the review this week feeds (for example Number One in Week Three), with its preparation done Y/N.
• ▸Change requests: any change to scope, schedule, or deliverables, with who approved it and what was re-baselined.
• ▸Status at week close: complete and validated, complete but not validated, or late, with the reason.

1. 1Print the blank SCORcard before any data is collected. Rows are the Level 1 metrics grouped by attribute: Delivery Reliability (Delivery Performance, Line Item Fill Rate, Perfect Order Fulfillment), Responsiveness (Order Fulfillment Lead Time), Flexibility (Supply Chain Response Time, Production Flexibility), Cost (Cost of Goods, Total Supply Chain Cost, SGA Cost, Warranty/Returns Processing Costs), Asset Management (Cash-to-Cash Cycle Time, Inventory Days of Supply, Asset Turns), and Shareholder metrics (Gross Margin, Operating Income, Net Income, Return on Assets). Columns are Actual, Parity (median of the statistical sample), Advantage (midpoint of parity and superior), Superior (90th percentile of the population), and Parity Gap (Parity minus Actual).
2. 2Assign each metric a source before collecting anything. Use the PMG benchmark data, available through the Supply-Chain Council's PMG contract, for customer-facing and supply chain-specific internal metrics. Use 10K financial data from Hoovers, Marketguide or Forbes for the standard internal and shareholder metrics. Note any internal benchmark sources that are relevant.
3. 3Walk through the PMG benchmark survey questions line by line with the design team. Use the SCOR metric definitions on the worksheets as the formula, and write the actual-data query for each SCORcard metric. This enforces the core rule: calculate actuals the same way the benchmarks are calculated.
4. 4Name one owner on the design team for each metric's actual-data collection, and record the owner next to the metric. Metrics without a named person do not get collected.
5. 5Build the industry comparison spreadsheet for the enterprise-level shareholder metrics (profitability, returns, share performance). Search the company on hoovers.com, click Financials, choose Annual Financials under Free, and copy the shareholder data into the sheet. Use the industry-group link to find other companies, and repeat for each public company.
6. 6Size the peer list at fifteen to twenty-five companies, across as many industries as needed to cover the competition at the business-group level, not just the corporate level.
7. 7Bring the completed actuals and benchmarks into the review session. Compute the Parity Gap for every row and read the operational metrics against the shareholder metrics, so each gap connects to the financial statements (the Fowlers data collection draws on the corporate controller, director of logistics and director of customer service roles).
8. 8Test measurement maturity at the outset using the competency matrix. Check whether customer-facing, internal-facing and shareholder-facing performance are all measured. Weak maturity signals larger opportunity (more than 3 percent); strong maturity signals less than 3 percent.

Fowlers Inc. is a billion-dollar conglomerate with food processing, optical technology and business services groups. On the second working day of Week Two, the Fowlers design team starts from the blank SCORcard. The team walks the PMG survey questions line by line and uses SCOR metric definitions as the formula for each actual-data query. Individual team members are assigned to collect each metric. The corporate controller, director of logistics and director of customer service are the roles named in the source as contributing. In parallel, the team plans an industry comparison spreadsheet fed from hoovers.com annual financials for fifteen to twenty-five public competitors. PMG data fills Delivery Performance, Fill Rate, Perfect Order Fulfillment and Cash-to-Cash Cycle Time, while 10K data fills Gross Margin, Operating Income, Net Income and Return on Assets. In Week Three the Parity, Advantage and Superior columns are compared to Actual, and the gap is read on each row. Because actuals were computed with the benchmark's own definitions, the gap reflects performance and not a difference in calculation.

• If a benchmark definition differs from how your company calculates a metric, recompute the actual using the benchmark's definition; never adjust the benchmark.
• If a metric is customer-facing or supply chain-specific (e.g., Perfect Order Fulfillment, Cash-to-Cash Cycle Time), source the benchmark from PMG; if it is a standard internal or shareholder metric (e.g., Gross Margin, Return on Assets), use 10K data.
• If the peer set has fewer than fifteen companies or covers only one industry, widen it until it reflects the competition at each business-group level (up to twenty-five).
• If the competency questions (strategy, organization, measurement, and so on) draw mostly yes answers, expect opportunity under 3 percent; mostly no, expect more than 3 percent.
• If a SCORcard metric has no named owner, do not proceed to benchmarking until one is assigned.

• Calculating actuals with internal definitions while comparing to PMG benchmarks. Tell: a gap that changes size when someone recomputes the metric using the SCOR worksheet formula.
• Scorecard skewed to one face of the business, such as only operational or only financial metrics. Tell: blank cells in the customer-facing, internal-facing or shareholder rows, so no gap connects operations to the financial statements.
• Thin or mismatched peer list, such as fewer than fifteen companies or corporate-level peers only. Tell: Parity medians that do not fit any one business group.
• Metrics without an owner, leaving actual data uncollected at review. Tell: empty Actual cells in Week Three.
• Treating the opportunity size as fixed rather than a function of maturity. Tell: expecting a uniform improvement percentage without having asked the competency questions.

• ▸Metric and attribute: Level 1 metric name and its performance attribute (e.g., Perfect Order Fulfillment, Delivery Reliability).
• ▸Benchmark source: PMG, 10K (Hoovers/Marketguide/Forbes), or internal.
• ▸SCOR definition used: Record the formula from the SCOR worksheet that both actual and benchmark follow.
• ▸Data owner: Design team member who collects the actual.
• ▸Actual: Company value computed with the stated definition.
• ▸Parity (median): Median of the statistical sample.
• ▸Advantage (midpoint): Midpoint between parity and superior.
• ▸Superior (90th percentile): 90th percentile of the population.
• ▸Parity Gap: Parity minus Actual, with a one-line note on the financial statement line it affects.

1. 1Start from the AS IS material flow performance summary (Table 8-1 style), not from opinion. Each disconnect you log must trace to a number or a place on a map: service level, transportation cost, lead-time (cycle time), or days of inventory.
2. 2Hold two views at once. The geographic map (for example, point-to-point distribution center shipments to customers) is the forest. Individual issues are the trees. The source warns that the map alone cannot assign relative values, and that solving each issue alone ignores total-system efficiency. Refine the maps until both views support the same list.
3. 3Confirm the mapping level before brainstorming. Use the highest level (product line or group, then family, then SKU) that still exposes both tactical and strategic inefficiencies. Map from the row (product) view, because locations, raw material commodities, and key suppliers group by row, and SCORcard data must cascade to the maps.
4. 4Plan the brainstorm session (Week Six, ahead of Week Seven). Bring the performance summary and the refined maps. Settle the participants, the time, and the output format, which is the disconnect summary (Table 9-1) and a blank fishbone (Figure 9-1).
5. 5Run the brainstorm by listing disconnects across material, work, and information flow. Tie every item to a process, location, or flow on the map. Park solutions; this step only identifies inefficiencies.
6. 6Cluster the disconnects into fishbone charts, one per major problem theme (Fowlers' example is a poor planning fishbone, Figure 10-1). Put the effect at the head and the causes on the bones. Keep asking why until a cause is something you could change. Record the result in the disconnect summary and present it at Steering Team Review Number Three.
7. 7In Week Eight, review and refine each fishbone, then start the opportunity analysis. Add each root cause to an opportunity spreadsheet (Table 10-1 style) with a quantified, gross value, so unlike problems can be compared on one scale.
8. 8In Week Nine, complete the opportunity analysis chart by chart (Table 11-1 does this for the poor planning fishbone). Plot the results on the disconnect opportunity grid (Figure 11-2). That grid and the opportunity summaries carry into TO BE material flow and Steering Team Review Number Four.

Fowlers' own poor planning fishbone (Figure 10-1) is the sequence to copy. The passages give only its title and its follow-on opportunity analysis (Table 11-1), not the figures, so the numbers below are placeholders. The source's introduction describes a similar pattern: cash-to-cash problems and falling customer satisfaction traced to raw materials shortages, mismatched capacity, poor forecasting, and inventory build-up. Step one is to read the performance summary and note where service level and days of inventory diverge. Step two is to brainstorm every disconnect tied to planning and tag each to a location or flow on the geographic map. Step three is to group them on one fishbone with poor planning as the effect. Forecasting, capacity mismatch, and material shortages become bones, and each is pushed down to a changeable root cause. Step four is to move each root cause to the opportunity spreadsheet and size it as a gross value ($ ___ or ___ days of inventory). Step five is to place the sized items on the disconnect opportunity grid, so the steering team sees relative value across planning, transportation, and other themes instead of one loud issue.

• If a disconnect cannot be tied to a metric or a map location, then park it and do not let it onto the fishbone until it can.
• If the map shows a vivid problem but you cannot compare it to other issues, then you are in the forest: go back to the performance summary and assign it a relative value.
• If you are resolving issues one by one with no view of total-system effect, then you are in the trees: step back to the geographic map and check that the fix does not worsen another metric.
• If mapping at SKU level is burying the team in effort, then move up to product family or line, provided the higher level still shows service, transportation cost, lead-time, and inventory-days inefficiencies.
• If a fishbone cause is a symptom (such as 'late shipments') rather than something you could change, then keep asking why before sizing it.

• Brainstorming from memory and opinion instead of the performance summary. The tell: disconnects arrive with no metric, location, or flow attached.
• Staying in the forest. The tell: the team debates the map's most dramatic lanes and cannot rank one problem against another.
• Staying in the trees. The tell: a long list of local fixes, and a fix in one area (a metric improved here) that quietly worsens another.
• Stopping the fishbone at symptoms. The tell: bones read 'poor forecasting' or 'late deliveries' with no changeable cause underneath, so the opportunity sizing is vague.
• Skipping quantification, so opportunities cannot be compared. The tell: the steering team reviews a list of problems with no gross values and cannot prioritize on the opportunity grid.

• ▸Disconnect statement: one sentence describing the inefficiency in material, work, or information flow.
• ▸Flow type and location: material, work, or information; name the process, site, or lane on the geographic map.
• ▸Evidence metric: the performance-summary measure that shows it (service level, transportation cost, lead-time, or days of inventory) and its current value.
• ▸Fishbone theme: the effect chart it belongs to (for example, poor planning).
• ▸Root cause: the deepest changeable cause reached by repeated 'why' questions.
• ▸Gross opportunity: the quantified size of the gain and the basis for the number.
• ▸Relative rank: position against other opportunities, so it can be placed on the disconnect opportunity grid.
• ▸Total-system check: other metrics or locations this fix could worsen.
• ▸Owner and review: who validates the line and which steering review it goes to.