Overview

Your AI Center of Excellence has successfully launched initiatives across five business functions. Procurement deployed supplier risk scoring that's preventing quality issues before they occur. Finance implemented invoice exception detection that reduced manual invoice review time by 60%. Compliance built violation pattern detection. HR is running a resume screening pilot. Sales is developing lead prioritization. Each project is succeeding individually. Their leaders are winning internal accolades. Their teams are proud. But last week, you discovered something concerning: Finance and Procurement are both building "supplier scoring" systems. One is score-based (0-100 rating of supplier reliability), the other is risk-based (predicting probability of future quality issues). Different data definitions. Different models. Different update schedules. They both pull from procurement systems but transform the data differently. Your CFO asked innocently: "Why are we funding two suppliers scoring systems? Why can't they share one?" You realized you have no good answer. Your CRO chimed in: "While you're looking at that, HR's resume screening just rejected someone who cleared our background check system. How did that happen?" That incident exposed another issue: different AI systems reaching different conclusions about the same entity (a candidate). Your HR director defended their model, saying background checks aren't part of their AI training data. The CRO pushed back: "But they should be. We're giving someone contradictory signals." This is the moment many organizations face: individual AI projects succeed, but the portfolio lacks coordination, creating duplication, conflicting standards, and suboptimal resource allocation.

This chapter teaches you how to coordinate AI at the enterprise level, creating a portfolio view of all AI activity, preventing duplication, aligning data and standards across functions, and making strategic resource allocation decisions that treat AI as an enterprise capability rather than a collection of department-specific projects.

The Portfolio Problem: From Projects to Programs

When AI starts in your organization, it typically begins with isolated projects: Finance funds invoice automation, Procurement funds supplier scoring, Compliance funds violation detection. Each project is managed by its own business leader, governed by its own timeline, and solves problems in its own function. This is fine for the first 2-3 projects. It's how pilot programs work. But as AI matures and you have 10, 15, 20 projects across different functions, the lack of coordination creates predictable problems:

Duplication: Two functions build AI systems solving the same problem (supplier scoring, candidate evaluation, risk detection) with different approaches, different data, different models. Result: Conflicting outputs, confusing business users, wasted resources building the same solution twice.

Conflicting standards: Finance defines "supplier" one way, Procurement defines it another way, Compliance defines it a third way. These entities overlap. They're all talking about the same suppliers, but the data definitions don't align. Result: AI systems can't share data or models because they're working with different semantic models of the business.

Isolated learning: Each project learns lessons specific to its domain but doesn't share those lessons across the organization. Finance learns that data quality is critical for accurate invoice automation. Procurement learns the same thing for supplier scoring. Compliance learns it for violation detection. But because projects are isolated, each learns this lesson expensively on their own.

Suboptimal resource allocation: When you have limited AI/data science resources and competing projects from different functions, who decides priority? Without an enterprise framework, the loudest executive wins or the first function to ask gets resources while others wait. Result: High-impact projects may be starved while lower-impact projects consume resources.

Governance gaps: One function's AI project goes through rigorous compliance review. Another function's project bypasses review because its leader is influential. A third function's project comes from an external vendor and nobody is clear who's responsible for monitoring its accuracy or managing incidents. Result: Inconsistent governance across the AI portfolio creates risk.

These problems don't emerge because people are incompetent. They emerge because nobody at the enterprise level is looking at the portfolio holistically.

Building the Portfolio View: Complete Visibility

The first step in portfolio coordination is establishing complete visibility into all AI activity in the organization.

For each AI system or initiative, capture:

• Basic identity: System name, business function, primary sponsor, CoE sponsor
  - Current status: In planning, in development, in deployment, live in production, mature (6+ months live)
  - Business impact: Financial value (quantified if possible), operational impact (speed, quality, cost), strategic importance (critical to strategy, important, nice-to-have)
  - Risk profile: Risk level (low=informational only, medium=influences decisions, high=autonomous execution), compliance sensitivity (GDPR, healthcare, finance regulated), fairness risk (impacts employee decisions, customer decisions, vendor decisions)
  - Resource requirements: How many people? What's the total cost (data science, engineering, deployment, maintenance)?
  - Data requirements: What data does it use? Does it overlap with other systems' data?
  - Related systems: What other AI systems does this depend on? What systems depend on this? What systems solve similar problems?
  - Key risks and blockers: What could cause this project to fail? Data quality issues? Technical complexity? Organizational adoption?

Capture this portfolio in a living document (spreadsheet, shared system, whatever tool you use for enterprise tracking). Update it quarterly. Never let it get stale. When the portfolio is current, you can actually see what you're doing across the organization. When it's out of date, you have no visibility.

Real example of portfolio discovery: A manufacturing company did this exercise and discovered: they had 17 AI initiatives across four functions. Ten were in active development or deployment, seven were live. But five of the 17 had "related systems" that solved similar problems. Two projects (supplier scoring and supplier risk assessment) were solving nearly identical problems with slightly different approaches. One project (candidate evaluation) and another (background check automation) both scored people but weren't sharing data or models. By mapping the portfolio, the company saw the duplication problem explicitly. Before the portfolio exercise, each project leader thought theirs was unique. The portfolio exercise proved otherwise.

Preventing Duplication: The Shared Solution Pattern

Duplication prevention starts early, at the moment a new AI initiative is proposed. When a function says "We want to build an AI system that does X," ask immediately: "Is anyone else solving this problem? Do we already have a system that does X?"

If no existing system solves that problem, proceed. If an existing system solves it, you have options:

Option 1: Use the existing system (Ideal, lowest cost)

Finance needs supplier scoring. Procurement already built supplier scoring. Finance uses the same system Procurement uses, configured for Finance's specific use case (Finance cares about payment behavior, Procurement cares about quality and delivery). Cost: $40-60K to customize for Finance. Time: 6-8 weeks. ROI: Fast, because most of the system exists. Ongoing: Finance and Procurement share maintenance costs.

Option 2: Extend the existing system (Good, medium cost)

Finance's scoring needs are slightly different from Procurement's. The existing system would need enhancement to serve Finance's use case well. The CoE extends the existing system to serve both functions. Cost: $150-250K. Time: 4-5 months. ROI: Medium, but one system serves two functions instead of two systems. Ongoing: One system to maintain rather than two.

Option 3: Build new system, design for alignment (Acceptable when justified, high cost but justified)

Finance's scoring needs are fundamentally different (different data sources, different business rules, different performance targets). They build their own system, but they design it to align with the Procurement system at key points: (1) both use the same supplier master data and definitions, (2) both output data to a common location with compatible schemas, (3) both follow the same governance and monitoring framework, (4) both contribute to a common data model. Cost: $300-450K. Time: 6-9 months. Benefit: Optimized for Finance's needs, but integrated into the enterprise ecosystem.

Option 4: Build independently (Avoid. This should almost never happen)

Different data, different definitions, different governance, no integration. This creates fragmentation. Only accept this option when you've exhausted the first three options and the new system's needs truly can't be met through options 1-3.

The key to preventing duplication is making this decision explicitly at a governance level (steering committee or portfolio management board), not locally within a function. Functions naturally want to optimize for their own needs. The enterprise has to look at the bigger picture.

Real example of duplication avoidance: A services company had built invoice exception detection for Finance (to flag suspicious invoices that should be reviewed by a human). Sales wanted to build contract exception detection (to flag contracts that deviate from company standards). Superficially, these are different problems. But the underlying capability is the same: anomaly detection based on comparing a transaction (invoice/contract) against historical norms and flagging significant deviations. The CoE recognized this and proposed extending the invoice exception system to also handle contracts. This required adding contract data to the model and retraining, but the core analytical approach could be shared. The extended system cost $80K (vs. $300K for a standalone contract exception system). Both Finance and Sales benefited from the same underlying AI capability.

Tip: Create a "solutions inventory" searchable by business problem. This inventory documents every AI system in your organization and what problems it solves. When a new initiative is proposed, the first step is searching: "Has anyone solved this problem before? Is there an existing system we can use or extend?" A well-maintained solutions inventory prevents thousands of dollars in duplication costs.

Data Alignment: The Foundation of Reusability

The deepest source of duplication and fragmentation isn't duplicated AI systems. It's duplicated data models. When Finance defines "Supplier" one way and Procurement defines it another way, and Compliance defines it a third way, you can't build a shared system serving all three because you don't have a shared definition of "Supplier."

What data misalignment looks like:

Finance uses supplier data from accounts payable system. Supplier = someone with an invoice. Procurement uses supplier data from procurement system. Supplier = someone with an active purchase agreement. Compliance uses supplier data from vendor management system. Supplier = someone who passed a compliance screening. All three systems have suppliers. All three suppliers data has overlapping entities (Company X is in all three systems). But the definitions aren't the same. Finance includes suppliers with one-time invoices that Procurement doesn't know about. Procurement includes suppliers under RFQ that haven't been approved by Compliance. Compliance includes suppliers that Finance hasn't transacted with yet. When you try to build an AI system that scores all suppliers consistently, these definition gaps create problems.

The solution: Define a common data model

Work across functions to define shared entities and their standard representations:

• Supplier entity: Unique ID (DUNS number or custom master ID), legal name, parent company, primary geography, industry classification, spend category (category of goods/services), compliance status (approved/pending/rejected), payment behavior (on-time payment history), quality history (defect rates), delivery reliability (on-time delivery %)
  - Invoice entity: Unique ID, supplier, amount, category (what was purchased), date, status (pending/approved/paid/disputed), pay-through method (direct/batched), approval chain
  - Contract entity: Unique ID, supplier, contract value, term dates, key terms (payment terms, delivery standards, quality expectations), approval signatures
  - Employee entity: Unique ID, name, job title, department, tenure, performance rating, skills, clearances

Once these entities are defined consistently, different systems can reference them. Finance's invoice system uses the standard Supplier entity. Procurement's sourcing system uses the standard Supplier entity. Compliance's vendor management system uses the standard Supplier entity. Now, when an AI system needs supplier data, it pulls from a single authoritative source (the master supplier database) rather than from three conflicting sources.

Why this matters for AI reuse: If Finance builds a supplier risk model and later Procurement wants to use it, they can do so if both are using the same Supplier entity definition. If the definitions are different, the model won't work for Procurement because "supplier" means something different.

Implementation approach: This is not a technical project. It's an organizational alignment project. You're asking Finance, Procurement, Compliance, and other functions to agree on what these entities mean. This requires cross-functional discussion and consensus. Once the definitions are agreed, the technical implementation (making sure all systems use these definitions) is straightforward.

Managing the Initiative Lifecycle: Governance Gates

As your AI portfolio grows, you need clear governance gates that every initiative passes through, regardless of which function it comes from.

Gate 1: Concept/Problem definition (Is this a real problem worth solving?)

Criteria: Clear problem statement, estimated impact (cost saved or value created), alignment with corporate strategy. Approval decision: Does the problem statement convince us this is worth investigating?

Gate 2: Feasibility assessment (Can we actually solve this with AI?)

Criteria: Data availability (do we have the data needed?), technical feasibility (what's the complexity?), risk assessment (what could go wrong?), rough ROI estimate. Approval decision: Is this technically feasible? Are risks manageable? Does ROI justify investment?

Gate 3: Project planning (What's the detailed approach?)

Criteria: Detailed timeline, resource requirements, success metrics, governance plan (who monitors this? how often? what triggers escalation?). Approval decision: Do we have the resources? Does the timeline fit with other priorities?

Gate 4: Pilot/deployment (Is this working in the real world?)

Criteria: Accuracy metrics (does the model work as predicted?), adoption metrics (are users actually using it?), business impact metrics (is it delivering promised value?). Approval decision: Are results meeting expectations? Are users adopting it? Do we go full production or iterate?

Gate 5: Production/sustainability (Is this running smoothly?)

Criteria: Monitoring and alerting in place (catching issues), incident response procedures defined (what to do when things go wrong), maintenance plan (updating the model as data changes), audit plan (annual compliance review). Approval decision: Is this stable enough to run in production? Do we have the resources to maintain it?

Every AI initiative passes through these gates. Not every gate takes the same amount of time (some projects may move through gates 1-3 in a month, others take three months), but every gate is a explicit decision point.

Who decides at each gate? Gates 1-2 (problem definition and feasibility) are typically decided by the function sponsor and CoE lead. Gates 3-4 (detailed planning and pilot) involve the function, CoE, and potentially compliance/audit. Gate 5 (production sustainability) involves the function, CoE, and ongoing governance oversight.

Resource Allocation: Strategic Priority Setting

You have limited CoE resources. You have competing initiatives from different functions. All of them are important. All of them have executive sponsors. You can't do all of them this year. How do you decide?

Build a prioritization framework:

Strategic alignment (weight: 30%): Does this initiative advance corporate strategy? High = directly enables a strategic priority. Medium = enables operational capability that supports strategy. Low = nice-to-have but not strategic. Example: If company strategy is "become the low-cost provider," supplier cost optimization AI is high strategic alignment. Resume screening AI is medium (HR improvement but not directly strategic).

Financial impact (weight: 40%): What's the estimated annual value (cost savings, revenue increase, risk avoidance)? High = >$500K annually. Medium = $100-500K. Low =
Important: Once you've made resource allocation decisions, commit to them. Nothing undermines portfolio governance faster than allowing powerful executives to bypass the prioritization framework and get their projects resourced anyway. If Procurement's executive sponsor complains that their project got deferred in favor of Finance's project, the steering committee must be able to explain why (Finance project scored higher on the prioritization framework). If the explanation is transparent and the framework is fair, the decision is defensible. If there are exceptions to the framework, governance collapses because everyone will demand exceptions.

Managing Conflicts: Escalation and Arbitration

Different functions have different, sometimes conflicting, business interests. Procurement wants to diversify suppliers to reduce risk. Finance wants to consolidate to a few suppliers to minimize costs. AI is built to optimize for specific objectives. When these objectives conflict, you have a problem.

Real conflict example: Supplier Scoring

Procurement builds supplier risk scores. Their model predicts quality and delivery risk. It scores supplier diversity as positive (diverse suppliers reduce supply chain risk) and consolidation as negative (too much dependence on single supplier). Finance's supplier cost score model predicts cost. It scores consolidation as positive (economies of scale, lower costs) and diversity as negative (higher administrative overhead, higher per-unit costs). When sourcing a new purchase, which score do you use? If you listen to Procurement's score, you diversify suppliers and costs go up. If you listen to Finance's score, you consolidate and supply chain risk increases. The organization can't have both equally. Something has to give.

Escalation path: When functions conflict on AI priorities, criteria, or outcomes, escalate to the steering committee. This is not an operational decision (CoE director decides). It's a strategic decision. The steering committee (which includes business leaders from multiple functions) makes the call: What's our priority, cost or supply chain risk? If cost is primary and supply chain risk is secondary, the AI systems are optimized with cost as the primary objective and risk as a constraint ("minimize cost while ensuring supply chain risk stays below X"). If supply chain risk is primary, reverse the weighting.

The role of operations is to make conflicts explicit: "Procurement's model and Finance's model reach different conclusions because they're optimizing for different objectives. You can't optimize for both equally. Which one is primary?" Once the business decides, AI systems are built and configured to reflect that decision.

Governance Standards: One Framework, Multiple Implementations

Your governance framework must be applied consistently across all AI systems, regardless of which function owns them, regardless of whether it was built internally or sourced externally, regardless of whether the project sponsor is the CEO or a team lead.

Enterprise standards that apply to every AI system:

Risk assessment: Every AI system goes through risk assessment using the same methodology. What are the potential harms if the system makes a wrong decision? Who is affected? What's the mitigation? Low-risk systems (informational AI used only internally) get lighter review. High-risk systems (autonomous decisions affecting customers) get deeper review. But all systems go through the same framework.

Monitoring and alerting: Every AI system has monitoring in place. What metrics are tracked? What thresholds trigger an alert (this system's accuracy dropped 5%, investigate)? All systems report key metrics to a central dashboard. No system is left unmonitored.

Incident response: Every AI system has an incident response plan. If the system makes a clearly wrong decision, who handles it? What's the escalation path? How is it communicated? All systems follow the same incident response process.

Annual compliance audit: Every AI system is audited annually. Is it still achieving its intended accuracy? Are any groups affected differently by the system (fairness concerns)? Is it still compliant with relevant regulations? All systems go through the same audit process.

Data definitions: Where systems share entities (supplier, employee, customer, contract), they use common data definitions from the enterprise data model. This isn't optional.

Portfolio reporting: Every AI system reports to the steering committee quarterly. Status, metrics, risks, new decisions needed. All systems report in the same format on the same cadence.

These standards apply even when a system is built by an external vendor, funded locally within a function, or built by the function's own data team outside the CoE. The governance framework is enterprise-wide, not optional.

Executing Portfolio Governance: Cadence and Process

Monthly: Portfolio status update (for CoE leadership)

Each week, the CoE director gets a brief status: What systems are on track? What systems are at risk? Any escalations? This is a lightweight check-in, not a major report. Its purpose is early problem detection, catching issues before they become crises.

Quarterly: Portfolio steering committee review (for executive leadership)

The steering committee (CEO/COO, CFO, business function leaders, CoE director) reviews the entire AI portfolio quarterly. Agenda: Portfolio overview (how many systems, how much impact?), individual system reviews (top 10 initiatives, latest metrics, any risks), new initiative screening (what's proposing to start?), resource allocation decisions (what gets resourced next quarter?), risk summary (any enterprise-level risks emerging?), learning and improvements (what are we doing better?).

This meeting is where portfolio governance comes alive. It's not a technical meeting. It's a business meeting about how the organization is strategically investing in AI. Decisions made here (prioritizing initiative X over initiative Y, deciding on the Procurement/Finance conflict, allocating resources) drive the organization's AI strategy.

Quarterly: Cross-functional knowledge-sharing forum (for all AI teams)

All teams working on AI initiatives (Procurement, Finance, Compliance, HR, Sales, CoE) gather to share learning. What challenges did we encounter? How did we solve them? What worked? What should we do differently next time? This forum prevents each initiative from reinventing the wheel. When Finance solves a data quality problem for invoice automation, Procurement learns from it so they don't face the same problem. When Compliance learns that a particular fairness concern needs audit attention, other functions know about it.

What to Do Monday Morning

• Create a complete AI portfolio inventory. Document every AI system and initiative, whether it's in planning, development, deployment, or production. Include: sponsor, function, status, estimated value, risk level, resources required, data used, related systems, key risks and blockers.
  - Analyze your portfolio for duplication. Are you building the same system twice? Are multiple functions solving similar problems independently? Which projects could be combined or consolidated?
  - Establish a common data model. Meet cross-functionally to define standard definitions for key entities (supplier, invoice, contract, employee, customer). Document these definitions. All AI systems going forward use these common definitions.
  - Create a solutions inventory. Document every AI system in your organization and what business problems it solves. Make it searchable and easily accessible. When a new initiative is proposed, the first step is searching: "Has anyone solved this problem before?"
  - Build a prioritization framework. Define criteria (strategic alignment, financial impact, risk reduction, feasibility) and weights. Use this framework to prioritize competing initiatives transparently. Don't let initiatives be approved based on executive influence. Use the framework.
  - Design governance gates. Define the decision points every AI initiative must pass through: problem definition, feasibility assessment, detailed planning, pilot results, production readiness. Document the criteria for each gate and who decides at each gate.
  - Set up portfolio governance cadence: weekly status check for CoE, monthly steering committee review, quarterly knowledge-sharing across all teams. Regular cadence prevents surprises and keeps the portfolio coherent.
  - Create an escalation path for conflicts. When two functions want incompatible things from an AI system (Procurement wants diverse suppliers, Finance wants consolidated costs), have a clear path to escalate: CoE tries to find a technical solution, steering committee makes a business decision.
  - Enforce governance consistently. Apply the same standards (risk assessment, monitoring, incident response, audit) to all systems. No exceptions based on who the sponsor is or whether it was built internally or externally. Consistency is what makes governance credible.

Key Takeaways

• Without enterprise portfolio coordination, AI projects multiply without visibility, creating duplication, conflicting standards, and wasted resources.
  - Build a complete portfolio view of all AI systems in the organization. You can't coordinate what you can't see. Keep the portfolio current; review quarterly.
  - Prevent duplication by establishing a solutions inventory ("Has anyone solved this problem?") and explicitly choosing how to handle similar solutions: use existing, extend existing, or build new aligned.
  - Align data definitions across functions through a common data model. When Finance, Procurement, and Compliance all use the same definition of "supplier," systems can share data and models.
  - Design governance gates that every initiative passes through: problem definition, feasibility, detailed planning, pilot validation, production readiness. Consistent gates prevent surprises.
  - Allocate limited resources using a transparent prioritization framework (strategic alignment, financial impact, risk reduction, feasibility). Make resource allocation decisions explicit and defensible.
  - Escalate conflicts between functions to the steering committee. If Procurement wants diverse suppliers and Finance wants consolidated costs, the business (steering committee) decides which is primary.
  - Apply enterprise governance standards (risk assessment, monitoring, incident response, audit) consistently across all systems, regardless of owner or origin. No exceptions.
  - Share learning across the portfolio. When one team solves a problem, document and share the solution so others don't repeat the work expensively.
  - Run portfolio governance on a regular cadence: weekly CoE check-in, monthly steering review, quarterly cross-functional learning forum. Regular touchpoints prevent drift and keep the portfolio coherent.