Scoping Use Cases for Foundry and AIP

Scoping Use Cases for Foundry & AIP

The goal of use case scoping is to take all the different problems your business or team faces, which are remotely linked to data in a way, and use the dots below to rank the priority of tackling these issues. Ideally, by going through these dots, you will eliminate some potential use cases, refine others, and merge some as well.

There are three essential areas to consider when prioritizing use cases. Although the list can be longer depending on one’s specific enterprise needs, these three items have come to be inevitable in evaluating whether a use case should move forward or not.

We will dive into each component in the following sections :

Business

Team or People

Data and Technology

Business Elements

Problem Statement

Fit for Foundry: More often than not, the best Foundry-shaped problems are those where the problem is loosely defined. You don’t need to have a precise solution in mind at this stage, but rather conviction on what pain this is currently causing to users, and why. User drive to get to a solution fast is a critical driver for successful use cases.

Team or People Elements

Another key item for prioritization is having a structured project team. Identifying key roles and individuals or focal points to take on specific responsibilities will not only help qualify the urgency and feasibility (therefore the priority) of a use case, but will also ensure a smooth journey in use case delivery.

Business availability

• As users are meant to be front and center of the use case, if they’re not able to commit time to your workflow, maybe your first priority should be focusing on what’s taking up all or most of their time.

Technical resources availability

• Technical resources availability is an obvious constraint, as if you have no one to scope or build the solution, you can’t move forward. The willingness to pull people off of other projects is another indicator of priority.

Steering team & project governance

• Having a formal steering team & project governance structure is less of a blocker, but they ensure your project will move from a prototype or idea to a production use case. They’re here to unblock the team, advocate for the project, and mitigate risks in accessing resources (people, data, financing,..).
• While their absence won’t necessarily prevent the kick off of the project, the inability to find someone willing to take on this role should raise questions regarding the risks and feasibility of the endeavor.
  • • Note that these aren’t necessarily all full time roles, and depending on the case one person can take on multiple roles.

Data and Tech Elements

Fit for Foundry: Data problems are Foundry problems, but they shouldn’t prevent the use case from moving forward. The dots above often offer ways to expand the footprint of a use case like adding data quality workflows, or setting up governance mechanisms in platform. Moreover, circumventing them in the nascent stages of a project are often necessary: sub direct connection for data extracts, to advance streams in parallel rather than in rigid sequence (connect data, build solution, test with users). 

After reviewing these items, you should be able to clearly articulate the problems the use case addresses, identify the key stakeholders and those affected, and outline the high-level flow of the proposed solution. Keep in mind that your initial solution flow may change significantly during technical scoping; for now, the goal is to broadly define the problem space.

These elements will help you assess the priority of the use case relative to other initiatives and determine whether—and how—to proceed.

Items for a Successful Use Case Kick Off

Team or People

• A Steering Committee cadence has been locked down with required attendees to help lift blockers and make informed decisions on use case direction.
• Beta users have been identified and allocated required bandwidth for reasonably quick iterations and testing. 
• A focal point has been defined for datasource exploration and integration.

Datasources and Technology

• Positive data assessment has been done or is on the road to completion 
• Validation to access data sources has been granted
• Validation to connect to data sources and ingest to target solution has been granted

Business

Workflow development sessions should be planned to reach the following goals :

• • Define the end-to-end user workflow and interface needs through user desk-sides and walkthroughs
    • • • Demos of their current systems, processes, and tools.
        • Identify inefficiencies, bottlenecks, and areas where the new solution will provide the most impact
        • Discuss current pain points and areas where automation or improvements are needed
        • Clarify expectations for how the new solution will change the existing process
  • Define integration logic and business rules with Subject Matter Experts and Product Owner
  • Define access control rules and user permissions

Project gate alignment :

• • Break down the use case into implementation phases and define key milestones
  • Process gates :
    • • • What is the Minimum Viable Product ?
        • What makes up the checklist to move to production ?
        • Create accountability through precisely assigned project management roles, and define clear goals the project team can evaluate the project against regularly.

This allows to terminate projects that aren’t mature enough, face irremediable blockers for the time being, or were mistakenly picked up in the first place. Another advantage is it allows to very easily report on project progress.

Other items to keep in mind but that shouldn’t be blockers working towards kicking off the use case post go-live support:

• • Agree on trainings for users that will need to be held. This also gives an idea of the documentation that will need to be created or provided
  • Agree on the go live strategy with all stakeholders
  • Define the long term maintenance plan and handovers that need to take place

Common Pitfalls in Use Case Scoping

When scoping out a use case, the key is most often to not apply a recipe, but rather seek to understand the problem in depth and at large, to figure out a long term solution that empowers users to work differently most of the time. 

Below is a non-exhaustive list of points to keep in mind when scoping or setting out to build a use case. 

• Technical scoping vs Business scoping
  • Technical scoping should come second, and even as late as possible so as to not influence the use case’s direction too much. Starting without any technical constraints allows for a broader understanding of the problem space, before slicing it up if needed.

• Reproducing an existing pattern or workflow as-is is often a mistake
  • When a solution exists, the common error is to reproduce the same workflow in Foundry (or other softwares) directly 
  • Question the bounds of the use case : what comes before the start ? what comes after the end ?
  • Question the user flow
  • Ignore the existing solution as much as possible (it’ll be there if you need it for the technical scoping)

• Focus on the operational problem, don't try to solve the technical problem immediately

• Tech alone does not solve problems: you need the business to be front and center from day one in the scoping and later on as you iterate on the solution. This means locking down user availability for rapid iterations, and embarking them as solution designers as well.

• Desk-sides and walkthroughs are a requirement
  • Nothing will replace looking at how your users work. What tools do they use? What tasks do they perform? Who do they talk to? What do they output? Abstract yourself from the process and think about the end to end. 

• The solution will evolve: scoping isn’t about getting to the perfect solution, it’s about understanding the problem, the value it has in being solved, and how to get to a first view of the end-to-end solution
  • Start building fast and iterate from there
  • Don’t expect to scope for months on end to capture everything, get started and refine along the way
  • Scoping output shouldn’t be a perfect design/mock-up, IT diagram, extensive list of user stories although it can contain some of those. Otherwise you’ll end up planning for a multiple month/year delivery instead of turning towards a rapid and iterative process of development

Sourcing the Data

Listing User Activities

Defining User Interactions with the Data

Providing a Business-friendly Data Asset

Augmenting Users in their Tasks...

... With Modeling Components

Mapping Security Requirements

Setting-Up Data Controls

这是一份关于 Foundry 与 AIP 用例定界（Scoping） 的完整技术指南与学习笔记。我将其翻译并重新组织，以确保逻辑清晰且易于在您的研究笔记中使用。

🚀 Foundry 与 AIP 用例定界指南

Scoping Use Cases for Foundry & AIP

用例定界的终极目标是从业务面临的繁杂问题中，筛选出那些真正能够通过数据驱动解决的挑战，并利用以下维度进行优先级排序、精炼或整合。

一、 用例评估的三大核心维度

在评估一个用例是否值得推进时，以下三个领域是不可或缺的指标：

1. 业务维度 (Business)

• 问题陈述 (Problem Statement)：清晰地描述痛点。
• Foundry 适配性：最适合 Foundry 的问题通常是定义模糊的问题。现阶段不需要精确的解决方案，但需要坚信目前的痛点对用户造成了多大伤害。
• 用户驱动力：用户渴望快速获得解决方案的迫切程度是成功的关键。

2. 团队与人员维度 (Team or People)

• 业务参与度 (Business Availability)：用户必须处于核心地位。如果用户没时间参与，那么首要任务应该是解决“是什么占据了他们所有时间”。
• Foundry 的迭代精神：通过“桌旁观察（Desk sides）”理解超越原始需求的问题。用户必须愿意在平台内进行迭代：快速构建、测试、进化。
• 技术资源可用性：如果没有人来定界或构建，用例就无法推进。
• 指导委员会与项目治理：负责扫清障碍、倡导项目并降低资源获取（人、数据、资金）的风险。

3. 数据与技术维度 (Data & Technology)

• Foundry 适配性：所有数据问题都是 Foundry 问题。数据质量不佳不应成为阻碍，反而可以通过在平台内建立治理机制来扩展用例的影响力。
• 灵活性：在初期可以先用数据抽样（Extracts）替代直接连接，以确保业务流逻辑与数据连接并行推进，而非死板的线性等待。

二、 用例启动成功清单 (Success Kick-Off Checklist)

三、 项目关卡对齐 (Project Gate Alignment)

为了避免项目陷入无休止的开发，必须设置明确的关卡：

• 最小可行产品 (MVP)：定义实现核心价值的最简版本是什么？
• 投产清单 (Production Checklist)：进入生产环境必须满足哪些硬性指标？
• 止损机制：允许终止那些不够成熟、面临不可调和障碍或最初选型错误的用例。

四、 用例定界的常见陷阱 (Common Pitfalls)

❌ 误区 1：技术定界优先于业务定界

修正： 技术定界应尽可能靠后。在不考虑技术约束的情况下理解问题空间，能获得更广阔的视野。

❌ 误区 2：照搬现有模式或流程

修正： 不要直接在 Foundry 中克隆旧系统。要质疑边界：“开始之前发生了什么？结束之后又接什么？” 忽略现有方案，专注于原始的业务目标。

❌ 误区 3：闭门造车，缺乏桌旁观察 (Desk-sides)

修正： 没有任何东西能替代现场观察。看用户用什么工具、谈论什么、产出什么。从端到端的角度思考，而非碎片化任务。

❌ 误区 4：追求完美的初始方案

修正： 定界不是为了得到完美的设计稿，而是为了理解问题的价值。快速构建，不断迭代。 避免花费数月进行设计，否则你会陷入传统的多年交付周期。

五、 实现路径：从数据到增益

1. 数据溯源 (Sourcing Data)：接入原始数据。
2. 用户活动清单 (Listing Activities)：梳理用户的真实工作步调。
3. 定义交互 (User Interactions)：确定用户如何与这些数据产生联系。
4. 提供业务友好型资产 (Business-friendly Asset)：将底层表转化为本体（Ontology）对象。
5. 增强任务执行 (Augmenting Tasks)：
   • 利用建模组件 (Modeling Components) 辅助决策。
   • 映射安全性需求 (Security Requirements)。
   • 设置数据控制机制 (Data Controls)。

5大关键问题 (The Big 5)

观察检查清单 (The Observation Checklist)

A. 数据流转（Data Flow）

• [ ] 用户是否在多个系统间手动复制粘贴数据？（识别集成价值）
• [ ] 是否存在“中间表”（Shadow IT）？（这些往往是 Ontology 中缺失的关键逻辑）
• [ ] 用户是否需要频繁进行数据格式转换（如：把 .pdf 手动录入 .xlsx）？

B. 时间成本（Time Sinks）

• [ ] 哪一步让用户开始“等待”？（系统运行慢？还是等待他人审批？）
• [ ] 用户在查找特定信息上花了多少时间？（搜索效率评估）
• [ ] 哪些步骤是完全机械化的、无需思考的？（AIP 自动化的首选目标）

C. 用户交互（UI/UX）

• [ ] 用户当前的屏幕布局是怎样的？（指导 Workshop 模块的布局设计）
• [ ] 用户是否经常需要查看历史记录？（指导 Ontology 的时间语义设计）
• [ ] 是否存在经常容易点错、或者需要反复核对的地方？（设置数据验证规则）

4. 观察后的“定界”输出 (Post-Observation Synthesis)

完成观察后，你应该能画出以下流程图：

1. 现有路径 (As-Is Process)：标记出所有的 Excel、手动录入、和长达数天的等待期。
2. Foundry 路径 (To-Be Process)：
   • 对象 (Objects)：哪些实体需要被建模？
   • 链接 (Links)：实体间如何关联？
   • 动作 (Actions)：用户最后那一键点击应该触发什么？

💡 深度洞察：为什么不问“你需要什么功能”？

在 Foundry 定界中，询问用户“想要什么功能”往往会得到一个改进版的旧系统。 更好的做法是： 通过桌旁观察发现用户的“隐形痛苦”。例如，用户可能已经习惯了每天花 2 小时对账，他们不会觉得这是个“需求”，但你作为架构师，在观察中会发现这是 Foundry 语义层 能够瞬间秒杀的痛点。