Internal Sharing内部分享

This deck contains confidential bid material. Enter the access code to continue.本材料含投标内部信息，请输入访问口令继续。

Solution Architect · Internal Experience Sharing · 2026.08 解决方案架构师 · 集团内部经验分享 · 2026.08

Large-Deal Bidding:
Key Moves & Hard-Won Lessons 大型项目招投标：
关键打法与实战经验

How a cloud-migration bid evolved into a full-stack strategic partnership — a complete walkthrough of the XLSmart Indonesia telecom deal, from pre-RFP positioning to winning the contract. 一场云迁移投标如何演变为全栈战略合作——完整复盘 XLSmart 印尼电信项目，从标前引导到最终中标的每一步打法。

Author作者：Adam 王垂豹 Dec 17, 2025 · Notice of Award2025.12.17 · 中标通知 Technical score: #1 through to the end技术评标：全程第一
6
Bid stages投标阶段
1,400+
SoC requirementsSoC 应答条目
100%
Full Comply完全合规
4
SoC workbooksSoC 工作簿
A3 portrait ratio · English only · print-ready A3 竖版比例 · 纯英文 · 可直接打印
Tencent Cloud InternationalSolution Architecture · Internal Training
APAC2
New Hire Training

Bidding Process
& XLSmart Case

How large overseas deals are really won — the standard bid lifecycle, the plays that decide the outcome, and a full walkthrough of the XLSmart Indonesia telecom cloud-migration bid.

Topic 1

Large-deal bid process and the key strategies there

The standardized bidding lifecycle for large overseas deals — where the outcome is actually decided, how evaluators score you, the hard boundaries consulting firms draw, and four reusable plays.

RFI → RFP → Award Six-stage lifecycle FC / PC / NC scoring Hard boundaries Four reusable plays
Topic 2

Let's walk through the XLSmart case

An Indonesian telecom cloud-migration bid whose scope was rewritten three times by competitors — how the team turned scope inflation into a barrier to entry and held the technical #1 to the end.

Scope 36 → 1,400+ PoC anchoring Turnkey delivery Architecture & team Honest retrospective
What you will take away
1

Read the scoring rules first, then design the response backward from the score points.

2

The outcome is mostly decided before the RFP is final — pre-RFP positioning and PoC.

3

Turn scope inflation into a barrier: the wider the scope, the fewer can self-prove.

6
Bid stages
1,400+
SoC requirements
100%
Full Comply
#1
Technical score
adamcwang
Presenter
adamcwang
Solution Architect · Tencent Cloud International, APAC2
Session
90 min · EN
2026.09
Topic 1主题一

Large-deal bid process and the key strategies there大型项目招投标流程与关键策略

The standardized bidding lifecycle for large overseas deals — where the outcome is actually decided, how evaluators score you, what hard boundaries the consulting firms draw, and the four reusable plays that work in any large deal. 大型海外标的的标准化招投标生命周期——胜负真正在哪里决定、评委如何打分、咨询公司划下哪些硬性边界，以及在任何大标中都可复用的四类打法。

1.1 Bid Pipeline1.1 招投标流程RFI → RFP → Evaluation → Clarification → AwardRFI → RFP → 评标 → 述标 → 决标
1.2 Six-Stage Lifecycle1.2 投标全周期六阶段Where the winning move really sits胜负手真正所在的位置
1.3 Scoring System1.3 评分体系Weights, FC/PC/NC rubric, veto items权重、FC/PC/NC 量化、否决项
1.4 Hard Boundaries1.4 硬性边界Consulting firms' compliance / method / scoring lines咨询公司的合规 / 方法 / 评分红线
1.5 Four Reusable Plays1.5 四类可复用打法PoC anchoring · industrialized SoC · scope-for-commitment · compatibility mapPoC 锚定 · SoC 产线化 · 范围换承诺 · 兼容映射
1.6 Five Keys to the Proposal1.6 技术标书五关键How evaluators see professionalism at a glance如何让评委一眼看到专业度
Case-independent与项目无关 · reusable可复用 Sections板块: Bid Process · Key Strategies
Topic 1 · 1.1–1.4主题一 · 1.1–1.4

Large-Deal Bid Process & Key Strategies大型项目招投标流程与关键策略

Before diving into the XLSmart case, understand the standardized bidding lifecycle for large overseas deals — and where the outcome is actually decided. 在进入 XLSmart 案例之前，先理解大型海外标的的标准化招投标生命周期——以及胜负真正在哪里决定。

The Standard Telecom Bid Pipeline电信行业标准化招投标流程

In the Indonesian telecom industry, professional consulting firms (e.g. McKinsey, Accenture) act as the "top-level designers" — writing the RFP, scoring vendors, and supervising delivery. Bidders must follow their templates strictly. 在印尼通信行业，专业咨询公司（如麦肯锡、埃森哲）扮演"顶层设计者"——编写 RFP、评估厂商、监督交付。投标方必须严格遵循其模板流程。

01

RFI信息征询

Request for Information — market & capability survey.信息摸底，了解市场与厂商能力。

›
02

RFP招标文件

Request for Proposal — line-by-line response + SoC.逐条应答 + SoC 工作簿应答。

›
03

Evaluation评标

Technical + commercial, weighted scoring.技术 + 商务双线，权重评分。

›
04

Clarification述标

On-site presentation & Q&A defense.现场澄清答疑与答辩。

›
05

Award决标

Notice of award & contract granting.中标通知与合同授予。

The Six-Stage Bid Lifecycle投标全周期六阶段

Most teams pour resources into proposal design and SoC responses — but those only answer questions under fixed rules. The real outcome is decided in the first two stages. 多数团队把资源压在"方案设计"与"SoC 应答"上，但这两个阶段本质是在既定规则下答题。真正决定胜负的是标前引导与 PoC。

STAGE 01

Pre-RFP Positioning标前引导

Earliest window最早窗口期
  • Help shape the RFP; use large migration cases as reference standard帮客户 RFP 出谋划策，用大型迁移案例作标杆
  • Frontline architect + sales proactively fight for PoC approval一线架构师 + 销售主动争取 PoC 立项
  • Pick two representative business apps选取两个代表性业务应用
Winning move:胜负手： Get the validation window before competitors, and shift the baseline to measured results.能否比对手更早拿到验证窗口，并把评估基准改为实测结果。
STAGE 02

PoC ValidationPoC 验证

Aug · 4 weeks8 月 · 为期 4 周
  • Five domains: network / IaC / monitoring / app / database五大验证域：网络 / IaC / 监控 / 应用 / 数据库
  • 37 functional cases, all passed功能用例 37 个全通过
  • PoC members become key delivery members laterPoC 成员即后续交付关键成员
Winning move:胜负手： When competitors follow, hold the evaluation baseline with depth.友商跟进后，能否靠深度守住已建立的评估口径。
STAGE 03

Solution Design方案设计

Build differentiation构建差异化
  • Seven differentiators mapped to client scenarios & competitor gaps七大差异化对齐客户场景与友商短板
  • Architecture across region / network / CI-CD / security落地区、网络、CI/CD、安全四层架构设计
  • Batch migration plan + cutover windows分批迁移方案与切换窗口规划
Winning move:胜负手： Every differentiator must be one "we can prove, they must compromise".每个差异化都能找到"我方能自证、友商需妥协"的支点。
STAGE 04

SoC ResponseSoC 应答

Win on completeness以完整性取胜
  • 4 workbooks / 40 volumes / 1,400+ items4 份工作簿 / 40 分册 / 1,400+ 条
  • Item-level RACI + mandatory evidence chain条目级责任矩阵 + 证据链强制
  • Unified terminology; drive non-FC items to zero术语口径统一 + 非 FC 项归零
Winning move:胜负手： Turn scope expansion into a scoring advantage on "completeness".在"完整性"维度上把范围膨胀变成得分项。
STAGE 05

Clarification & Q&A澄清与答疑

Eliminate doubts消除疑虑
  • 102-item PaaS mapping for replacement risk针对 PaaS 替换风险给出 102 条映射表
  • Exit & transition plan for capability handover针对能力移交给出退出与过渡计划
  • Resource & person-day model for delivery risk针对交付风险给出资源与人天模型
Winning move:胜负手： Convert client "uncertainty" into "a list with plans".把客户的"不确定风险"转为"有方案的清单"。
STAGE 06

Commercial & Award商务与决标

Trade for strategy换取战略定位
  • Full-stack coverage in exchange for long-term strategic supplier status以全栈覆盖换长期战略供应商定位
  • Commit to 12-month joint operation + phased handover承诺 12 个月联合运营 + 分阶段移交
  • TCO advantage to answer cost-savings goal以 TCO 优势回应成本节约目标
Winning move:胜负手： Turn a one-off transaction into a long-term partnership.把一次性交易谈成长期合作关系。
💡

The outcome is mostly decided in the first two stages胜负在前两阶段就已大半决定

Proposal design and SoC responses are about answering questions under fixed rules. The only window to rewrite the rules themselves is pre-RFP positioning and PoC. The XLSmart team established an objective baseline at the PoC stage, giving all 1,400+ subsequent responses a unified evidence foundation. Treat PoC as a formality, and no matter how thick the proposal, you stay reactive.方案设计与 SoC 应答是在既定规则下答题；唯一能改写规则本身的窗口是标前引导与 PoC。XLSmart 团队正是在 PoC 阶段建立了客观基准，后续 1,400+ 条应答才有了统一证据底座。若把 PoC 当流程走，后面标书写多厚都是被动应对。

🤖

AI assist: every stage above can be augmented by AI — requirement extraction, draft generation, duplicate-check, scoring assistance and more.AI 辅助：上述每个阶段都可由 AI 增强——需求提取、初稿生成、查重合规、评分辅助等。 See the full six-stage AI map →查看完整六阶段 AI 能力图谱 →

How Large Deals Are Scored大型标的如何打分

A "qualification gate + technical scoring + commercial bidding + weighted award" system. Never compete on only one dimension. "资格门槛 + 技术量化 + 商务竞价 + 综合加权"的完整体系——不要只盯技术或只拼价格。

Evaluation Weights评标维度与权重

4 dimensions四维加权
Technical solution技术方案45%
Architecture · migration · SoC · SLA架构 · 迁移 · SoC · SLA
Commercial price商务报价30%
Full-lifecycle TCO全生命周期 TCO
Delivery & implementation实施与交付15%
Project plan · resources · PoC项目计划 · 资源 · PoC
Qualification & localization资质与本地化10%
Data sovereignty · local support · references数据主权 · 本地支持 · 案例
Pass line: any single item ≥ 0.5 and board ≥ 70%. Veto items: data sovereignty, missing qualification, key SoC (RPO/RTO) NC, over-budget. 合格线：单项 ≥ 0.5 且板块 ≥ 70%。否决项：数据主权、关键资质缺失、关键 SoC（RPO/RTO）NC、报价超预算。

Technical Scoring Rubric技术打分细则

FC / PC / NC / EX / BE五档量化
Level等级Score分数Meaning含义
FC1.0Fully Compliant — full coverage + solution + evidence + owner完全合规 — 全覆盖，附方案 + 证据 + 责任人
PC0.5Partially Compliant — meets core with stated limits部分合规 — 主体满足，附带限制条件
NC0.0Non-Compliant — vague wording ("TBD" / "case-by-case") counts as NC不合规 — 任何"待确认/视情况"等模糊表述一律按 NC
EX+0.1~0.3Exceeded — above-requirement (e.g. ≥2× SLA, dual-AZ DR)超出要求 — 加分项（如 ≥2× SLA、双 AZ 灾备）
BEclarify待澄清Bid Exception — deviation needing 24h supplement偏离条款需 24h 内补充应答

Professional Consulting Firms' Hard Boundaries专业咨询公司的硬性要求

International top-tier consulting firms (e.g. McKinsey, Accenture) act as independent bid advisors, drawing three hard boundaries — compliance, methodology and scoring. Miss any single one and you are out. 国际头部咨询公司作为独立招标顾问，为投标方划定「合规 / 方法 / 评分」三类硬性边界——任一不满足即出局。

Qualification & Compliance资质与合规
  • Local registered entity & local legal representative本地注册实体与本地法人代表
  • Data sovereignty — data residency inside Indonesia数据主权：数据不出印尼（data residency）
  • Security & license certification (ISO 27001 / local data center)安全与牌照认证（ISO 27001 / 本地数据中心）
  • Similar track record & customer reference cases同类业绩与客户案例证明
Response Methodology应答方法论
  • Unified template & format; line-by-line RFP / SoC response统一模板与格式，逐条响应 RFP / SoC
  • Rigid time window — late / missing = instant deduction时间窗刚性：迟交 / 漏项直接扣分
  • No vague wording — "TBD" / "case-by-case" counts as NC禁止模糊表述（「待确认」「视情况」= NC）
  • Multi-round clarification (Q&A workbook)多轮澄清答疑（Q&A 工作簿）
Scoring Rules评分规则
  • Three-tier quantification: FC / PC / NCFC / PC / NC 三档量化
  • Pass line: single item ≥ 0.5 & board ≥ 70%合格线：单项 ≥ 0.5 且板块 ≥ 70%
  • Veto items (data sovereignty / key NC / over-budget)一票否决项（数据主权 / 关键 NC / 超预算）
  • Technical + commercial dual weighting技术 + 商务双线加权
Placeholder · PPT Screenshot
📄
RFP Submission Format (Chapter IV)RFP 招标文件 · 提交格式（第 IV 章）
Insert the client's original RFP "PROPOSAL SUBMISSION FORMAT" — 10-item proposal outline (Exec Summary / Requirements / Migration Methodology / Architecture / Joint Ops / FinOps / Resources / Plan / SoC / References).插入客户原始 RFP 标书大纲截图——10 项标书大纲（执行摘要/需求理解/迁移方法论/架构/联合运营/FinOps/资源/计划/SoC/案例）。
Placeholder · PPT Screenshot
✅
SoC Response Sample (D.31–D.36)SoC 应答样板（D.31–D.36）
Insert a real Technical SoC excerpt — client requirement → line-by-line response + evidence link + score (FC/PC/NC).插入真实 Technical SoC 节选截图——客户需求 → 逐条应答 + 证据链 + 评分。
Topic 1 · 1.5–1.6主题一 · 1.5–1.6

Four Reusable Strategies四类可复用打法

The four plays below are case-independent — reusable for any large deal that pushes beyond your standard service boundary.以下四类打法与项目本身无关，可复用到任何超出标准服务边界的大标。

1

PoC AnchoringPoC 锚定法

For: non-incumbent vendors with established client preference适用：非现网供应商、客户已有技术偏好

Design the PoC around the client's real workload, shifting the baseline from "vendor claims" to "reproducible measurement". The client's tech team must participate end-to-end so results enter the scoring basis.以客户真实业务负载设计 PoC，把评估基准从"厂商宣称"改为"可复现实测"。关键是让客户技术团队全程参与，测试结论方能进入评标口径。

2

Industrialized SoC ResponseSoC 产线化应答

For: >200 items across multiple workbooks/domains适用：应答条目 >200 条、跨多份工作簿与能力域

Item-level responsibility matrix + mandatory evidence chain + unified terminology + zero non-FC. The architect must act as total integrator — otherwise cross-volume contradictions are inevitable.责任矩阵到条 + 证据链强制 + 术语统一 + 非 FC 项归零。术语统一必须由架构师总集成，否则跨册矛盾必然出现。

3

Scope-for-Commitment Negotiation范围换承诺谈判框架

For: scope continually expanded by competitors适用：招标范围被友商引导持续扩大

Scope expansion is a filter, not a threat. If you can cover full-stack while competitors cannot, take the whole scope and exchange it for long-term strategic supplier positioning.范围新增不是威胁而是筛选器。若我方能全栈覆盖而对手不能，则主动接住全部范围，并兑换长期战略供应商定位。

4

PaaS/SaaS Compatibility MapPaaS/SaaS 兼容映射表

For: cross-cloud migration with proprietary-service risk适用：跨云迁移、客户担忧专有服务替换风险

Line-by-line Origin → Target mapping with regional availability and compatibility level (FC/PC/NC/NA), turning vague migration risk into a list with plans.逐条给出 Origin → Target 映射、区域可用性与兼容等级（FC/PC/NC/NA），把模糊的迁移风险转化为有方案的清单。

Five Keys to a Winning Technical Proposal技术标书制作五关键

How to design the technical volume so evaluators see professionalism at a glance.如何设计技术标，让评委一眼看到专业度。

01

Master the scoring rules吃透评标规则

Lock the criteria, pass line & veto items first; design responses backward from score points.先锁定评分标准、合格线与否决项，按得分点反向设计应答。

02

Point-to-point response点对点应答

Every RFI/RFP/SoC item mapped: requirement → solution → evidence.RFI/RFP/SoC 每条要求逐项响应："要求 → 方案 → 证据"一一对应。

03

Template-grade delivery样板级呈现

Reusable architecture diagrams, migration paths, milestones, acceptance criteria.架构图、迁移路径、里程碑、验收标准做成可复用样板。

04

Quantified & verifiable量化 + 可验收

All key metrics digital; commitments tied to verifiable standards & milestones.关键指标全部数字化，承诺落到可验证标准与里程碑。

05

Differentiate + manage risk差异化 + 风险防控

Surface hard advantages; proactively expose and manage risk.突出硬优势，同时主动暴露并管理风险。

Topic 2主题二

Let's walk through the XLSmart caseXLSmart 案例走读

An Indonesian telecom operator's cloud-migration bid whose scope was rewritten three times by competitors — how a full-stack team turned scope inflation into a barrier to entry, and won the technical evaluation from start to finish. 一个被友商三次改写范围的印尼电信云迁移大标——全栈团队如何把范围膨胀转化为竞争壁垒，并从头到尾守住技术评标第一。

2.1 Case & Timeline2.1 案例与时间线Scale, four-party landscape, RFP → award量级、四方格局、RFP → 中标
2.2 Scope Expansion2.2 范围扩大36 → 1,400+ items across three rounds三轮从 36 条到 1,400+ 条
2.3 Service Boundary2.3 服务边界延伸From cloud resources to turnkey delivery从云资源到交钥匙工程
2.4 PoC & Competition2.4 PoC 与竞争博弈Measured baseline, 7 differentiators, 3 tactics countered实测基准、七大差异化、三类手法反制
2.5 Architecture & Team2.5 架构与团队AS-IS → TO-BE and three team structures现网到目标架构与三类团队结构
2.6 Deliverables & Lessons2.6 交付物与复盘Proposal + 4 SoC workbooks; 4 rights, 4 improvements标书 + 四份 SoC；做对四件事、改进四件事
Award中标: 2025.12.17 Technical score技术评标: #1 through to the end全程第一 Sections板块: Case · PoC · Architecture · Library · Lessons
Topic 2 · 2.1–2.3主题二 · 2.1–2.3

Let's Walk Through the XLSmart CaseXLSmart 案例走读

An Indonesian telecom operator's cloud-migration bid — a full-stack deal whose scope was rewritten three times by competitors, and how the architect team turned scope inflation into a barrier to entry.印尼电信运营商云迁移招标——一个被友商三次改写范围的海外全栈大标，架构师团队如何把范围膨胀转化为竞争壁垒。

Case Overview案例简介

Scenario场景

MergeCo IT consolidation合并实体 IT 整合

Two operators merged; must unify infra, cut TCO, remove vendor lock-in.两家运营商合并后需统一基础设施、降低 TCO、消除厂商锁定。

Need需求

Turnkey full-stack delivery交钥匙式全栈承接

Migration + rework + testing + hypercare + PM + O&M, plus a cross-cloud FinOps platform.迁移+改造+测试+Hypercare+PM+运维售后一体交付，另需跨云 FinOps 平台。

Strategy策略

Anchor · Respond · Trade锚定 · 应答 · 换承诺

PoC baseline; industrialized SoC; scope expansion traded for long-term partnership.PoC 建客观基准；SoC 工程化；范围扩张换长期战略合作。

Actions动作

Detect · Escalate · Cover甄别 · 升级 · 全栈应答

Twice detected competitor steering; 4 SoC / 40 volumes / 1,400+ items responded.两次识别友商引导；4 份 SoC / 40 分册 / 1,400+ 条应答。

Result成果

Technical #1 through the end技术分领先到最后

Won the bid and became long-term strategic cloud supplier; dual migration underway.技术评标保持第一并中标，成为长期战略云供应商。

Project Scale at a Glance项目关键量级

69
applications个应用
3,344
TB of data migratedTB 数据迁移量
1,400+
SoC requirements条 SoC 要求
1,200+
microservices个微服务
5+
heterogeneous clouds & data platforms异构云环境 / 数据平台

Key Timeline — From RFP to Award关键时间线 — 从 RFP 到中标

2025.07

First RFI releasedRFI 首版发布

Scope limited to application & infrastructure migration.范围仅为应用与基础设施迁移。

2025.08

Turning point — PoC (4 weeks)转折点 — PoC 验证（4 周）

Team proactively won the PoC, validated five domains on two real apps, and secured technical #1 before the RFP was finalized.团队主动争取立项，以两个真实业务应用完成五大域验证；赶在 RFP 定稿前拿下技术评标第一。

2025.09

Scope finalized — RFP & SoC response范围定型 — 标书与 SoC 应答

Four SoCs issued; 97-page technical proposal + 40 volumes, 1,400+ items answered line-by-line.四份 SoC 陆续下发；97 页技术标 + 40 分册 1,400+ 条逐条应答。

2025.09–10

Presentation & clarification述标与澄清答疑

Pitch team formed and rehearsed; PaaS replacement, capability handover, delivery resources clarified.述标团队组建与多轮演练；PaaS 替换、能力移交、交付资源等议题澄清。

2025.10

Disrupted — competitor steering begins被搅局 — 友商开始引导

Competitor leveraged its BigQuery migration experience to push scope expansion.友商以其 BigQuery 迁移经验为攻击优势项，推动客户扩大范围。

2025.11

Counterattack — Judo scope added, defended反超 — 客户新增 Judo 范围 · 我方防守

Big data + AI/ML added; team detected it early and pulled product architects to meet the client, retaking the technical lead.大数据与 AI&ML 纳入范围；及时甄别并拉产品架构师面访客户，技术分反超。

2025.12.17

Award — notice of award received中标 — 收到中标通知函

Became cloud service provider and migration lead, establishing long-term strategic supplier position.成为云服务商与迁移主导方，确立长期战略供应商定位。

The Bid Landscape: Four Parties招标格局：客户、我方、项目、友商四方

Four things you must assess before bidding.投标前需要判断清楚的四个方面。

The Client客户情况

XLSmart (MergeCo)XLSmart · 合并运营商

  • Merger of two operators into a major Indonesian telecom carrier由两家运营商合并形成的印尼主要电信运营商
  • Production runs on public cloud: touchpoint apps, middleware, big data, AI/ML现网主体运行于公有云：触点应用、中间件、大数据平台、AI/ML
  • Strategic asks: better cost/performance, operational elasticity, regional advantage战略诉求：更优成本性能、运营弹性、区域优势
  • Explicitly requires portability-first architecture, minimizing proprietary-service dependence明确要求架构以可移植性为设计前提，弱化专有服务依赖
Our Side我方情况

Tencent Cloud腾讯云

  • Strength: Jakarta 3-AZ self-built DC, cross-AZ latency <5ms; cost-effective IaaS base优势：雅加达 3 可用区自建 DC，跨 AZ 时延 <5ms；IaaS 性价比硬底座
  • Strength: full-stack self-developed IaaS + big data + AI + security + FinOps优势：IaaS + 大数据 + AI + 安全 + FinOps 全栈自研可交付
  • Weakness: non-incumbent — no requirement-definition rights or historical data劣势：非现网供应商，缺 incumbent 的需求定义权与历史数据
  • Strategy: replace incumbent inertia with measured results + compliance evidence chain策略：以实测与合规证据链替代客情惯性
The Project项目情况

Scope & Delivery范围与交付

  • Fustal: 69 apps, 4 batches; Judo: 3 domains, 5 heterogeneous stacksFustal：69 应用 4 Batch；Judo：三域五种异构栈
  • Goal: long-term savings, zero major business impact, self-operation目标：长期降本、零重大业务影响迁移、内部自主运营
  • Delivery: turnkey cloud service & migration, supplier-led交付形态：交钥匙（Turnkey）云服务与迁移方案
  • Follow-on: 12-month joint operation + phased handover + exit plan后续承诺：12 个月联合运营 + 分阶段移交 + 退出计划
Competitors友商情况

Incumbent & Rivals现网供应商与友商

  • The incumbent has a natural advantage: familiar architecture & usage data现网供应商具备天然 incumbent 优势：熟悉存量架构与用量数据
  • Play: define technical standards by their own service boundary, raising the bar打法：以自身服务能力边界定义技术标准，抬高门槛
  • Play: push big data, AI, ETL proprietary stacks into scope打法：推动大数据、AI、ETL 等专有服务栈纳入范围
  • Intent: "single-vendor full coverage" to suppress multi-vendor split意图：以「单一供应商可完整覆盖」压制多供应商拆分

Three Rounds of Scope Expansion范围扩大的三轮

From 36 items to 1,400+ — and the response was never to resist scope, but to "cover fully + prove line-by-line".从 36 条到 1,400+ 条——应对方式不是抗辩范围，而是"完整覆盖 + 逐条举证"。

ROUND 1

RFP v1.0RFP v1.0

Fustal · 36 itemsFustal 单主线 · 36 条

App migration + infrastructure · volumes A–C.应用迁移 + 基础设施 · A–C 分册。

NEW新增
ROUND 2

Operations & Governance运维与治理

Security 107 · FinOps 79 · Privacy 43安全 107 · FinOps 79 · 隐私 43

PaaS services mapped one-by-one · volumes D–H.PaaS 服务逐一映射 · D–H 分册。

NEW新增
ROUND 3

Big Data Stack大数据栈

Governance 68 · DW 50 · Processing 70 · Viz 8治理 68 · 数仓 50 · 处理 70 · 可视化 8

Volumes I–L.I–L 分册。

NEW新增
ROUND 4

AI Platform + BOT O&MAI 平台 + BOT 运维

AI/ML 14 + BOT 570+AI/ML 14 + BOT 570+

End-to-end data stack · M + BOT 22 volumes.端到端打通数据栈 · M + BOT 22 分册。

🎯

Core insight核心洞察

Facing scope escalation driven by competitors, the right move is not passive re-scoping, but actively converting scope inflation into a competitive barrier — the larger the scope, the fewer suppliers can self-prove full-stack capability.面对友商引导下的范围失控，正确解法不是被动扩标，而是主动把范围膨胀转化为竞争壁垒——范围越大，能全栈自证的供应商越少。

Service Boundary Extension: From Cloud Resources to Turnkey服务边界延伸：从云资源到交钥匙工程

The client asks the CSP to take on far more than the standard service boundary — a dual extension of the technical chain and delivery responsibility.客户要求云服务商承接的，远超 CSP 标准服务边界——技术链条与交付责任的双重延伸。

The full service chain the CSP must own end-to-end客户要求由云服务商一体承接的完整服务链条

01
Infra Migration基础设施迁移

Landing Zone, network, dedicated interconnectLanding Zone、网络、专线互联

02
App Rework应用改造

Refactor, code changes, environment adaptation重构、代码修改、环境适配

03
Deploy & Cutover部署与割接

IaC provisioning, CI/CD, blue-green/canaryIaC provisioning、CI/CD、蓝绿/灰度切换

04
Five Test Types五类测试

Unit, integration, system, regression, UAT单元、集成、系统、回归、UAT

05
HypercareHypercare

Post-cutover stabilization & tuning切换后稳定期陪跑与性能调优

06
Project Management项目管理

PMO, RACI, milestones & risk managementPMO、RACI、里程碑与风险管理

07
O&M & After-sales运维与售后

L0–L3 full-tier support for 1 yearL0–L3 全层级支持，为期 1 年

Four clearly out-of-bound requirements (all mandatory SoC clauses)四类明显越界的要求（均为 SoC 强制条款）

1
Cross-cloud FinOps platform跨云 FinOps 成本治理平台

Not just our own billing tool, but a unified multi-cloud cost platform: merged view, per-cloud drill-down, unified tagging, FOCUS-compliant.要求的不是自家账单工具，而是统一纳管多个云厂商的成本平台：多云合并视图、各云成本下钻、跨云标签口径统一，并符合 FinOps.org FOCUS 规范。
Difficulty: unify heterogeneous cloud billing data models难点：需打通异构云的计费数据模型

2
Absorb AWS Marketplace products原 AWS Marketplace 产品承接

COTS software must be reinstalled, reconfigured and re-licensed by coordinating vendors & ISVs — not our products, yet we guarantee availability.COTS 类软件需由新 CSP 协调原厂与 ISV，完成重装、重配、License 重新校验与支持激活——这些软件并非我方产品，却须由我方保证其可用。
Difficulty: relies on third-party vendor cooperation难点：依赖第三方原厂配合，不可控

3
Embed into the client team架构师与开发全程嵌入客户团队

Architects, engineers and developers embedded end-to-end: design, dev, test, regression, cutover planning, traffic migration, stabilization.架构师、工程师、开发须嵌入客户项目团队，覆盖架构设计、开发、测试、回归、割接规划、流量迁移与切换后稳定期全过程。
Difficulty: long-term overseas on-site, capability + staffing难点：长期海外驻场，能力与人力双重考验

4
1-year L0–L3 full managed service一年 L0–L3 全层级托管

Each migrated app gets 1-year managed service: L0 monitoring, L1 service desk, L2 diagnosis & recovery, L3 vendor engineering & defect fix.切换后须为每个迁移应用提供 1 年托管：L0 监控、L1 服务台与事件分派、L2 问题定位与业务恢复、L3 原厂工程与缺陷修复。
Difficulty: app-layer O&M, beyond pure IaaS难点：需具备应用层运维能力，非纯 IaaS 职责

Four resulting technical & delivery difficulties由此带来的四类技术与交付难度

1
Zero-interruption cutover零中断割接

Drill, blue-green/canary deployment, and align cutover windows with business.须完成演练、蓝绿/灰度部署，并与业务方对齐切换窗口。

2
Full-SDLC migration全 SDLC 环境迁移

Dev / Staging / UAT / Production and their data migrated together.Dev / Staging / UAT / Production 及其数据一并迁移。

3
Five test types, full coverage五类测试全覆盖

Unit, integration, system, regression, UAT — defects closed-loop and re-tested.单元、集成、系统、回归、UAT，缺陷须闭环复测。

4
Deep dependency decoupling深层依赖解耦

1,000+ microservice call relationships mapped before cutover.1,000+ 微服务的调用关系须在割接前梳理清楚。

⚖️

The pre-sales architect's judgment售前架构师在此处的判断

This is no longer buying cloud resources — it is buying an end-to-end delivery responsibility owner. The real test: the capability chain must stretch from IaaS all the way to app rework, testing, app-layer O&M and third-party software coordination. Any missing link leaves an NC item on the SoC.这已不是采购云资源，而是采购一个端到端交付责任主体。对我方的真正考验在于：能力链条必须从 IaaS 一直延伸到应用改造、测试、应用层运维与第三方软件协调——任何一环缺失，都会在 SoC 上留下 NC 项。

Final Scope: Fustal 60% + Judo 40% Dual Mainline最终范围：Fustal 应用 60% + Judo 数据 40% 双主线

Applications and data migrate in parallel — the right-side 40% data mainline was added later, a result of scope escalation, and also our barrier.应用与数据两条主线并行迁移——右侧 40% 数据侧为后续新增，是范围失控的结果，也是我方壁垒。

FustalFustal

60% · App mainline60% · 应用主线
Infrastructure & application migration mainline · 4 batches · source (DO / on-prem) → Tencent Cloud基础设施与应用迁移主线 · 4 batch · 源环境（DO / On-prem）→ 腾讯云
Batch 1Batch 1
Internal apps内部应用 17
Batch 2Batch 2
2A Backend后端 52B Customer Web客户 Web 152B Internal Web内部 Web 4
Batch 3Batch 3
3A 33B 63C 63D 6
Batch 4Batch 4
4A 44B 74C 6
Batch 1–3: 9 groups, 62 apps. Batch 4: three cutover windows (4A/4B/4C), 17 apps. Scope includes 1,000+ estimated microservices.Batch 1–3 共 9 个分组 62 个应用；Batch 4 分 4A/4B/4C 三个切换窗口 17 个应用。范围含 1000+ 预估微服务。

JudoJudo

40% · Data mainline40% · 数据主线
Data & AI platform migration mainline · 3 batches · current environment (GCP BigQuery / Abinitio ETL)数据与 AI 平台迁移主线 · 3 batch · 现网环境（GCP BigQuery / Abinitio ETL）
GenAIGenAI
Generative AI platform & apps生成式 AI 平台与应用
Classic AIClassic AI
Traditional ML & modeling传统机器学习与建模
Big Data大数据
DW / ETL / governance / viz数仓 / ETL / 治理 / 可视化
Current status: 3 batches migrating, 8 workflows in total (see Chapter 4).当前状态：3 个 batch 迁移进行中，共 8 个工作流（详见第四章）。
Topic 2 · 2.4主题二 · 2.4

PoC Evidence, Competition & TeamPoC 实证、竞争博弈与团队

The measured results that anchored the technical narrative, the competitor playbook we countered, and the team that made it happen.锚定技术话语权的实测数据、被反制的友商打法，以及落地这一切的团队。

PoC Results — Performance & Cost BaselinePoC 实测结果 — 性能与成本基准

Benchmarked against the client's current same-spec instances under identical load conditions. Method: SPEC CPU2017 / STREAM / k6 (450 VUs, 2 min, 3 rounds).对比对象：客户现网同规格实例、相同压测条件。方法：SPEC CPU2017 / STREAM / k6（450 虚拟用户 / 2 分钟 / 三轮取均值）。

Category类别Product / App产品 / 应用Condition对比条件Advantage vs. current cloud相对现网优势
Compute计算CVM SA5-32C/64Gsimilar performance相近性能List price 20% lower刊例价低 20%
Database数据库PostgreSQLsame QPS/USD相同 QPS/USDthroughput +94%~125%, cost efficiency +113%~147%吞吐 +94%~125%，成本效率 +113%~147%
Database数据库MySQLsame resource baseline相同资源基线throughput +63%~72%, cost efficiency +25%~33%吞吐 +63%~72%，成本效率 +25%~33%
Database数据库MongoDB4C8G vs 4C32G小规格 vs 大规格cost efficiency +116%~235%成本效率 +116%~235%
Database数据库Redis24G vs 26G24G vs 26G 内存cost efficiency +51%~73%成本效率 +51%~73%
Application应用Throughput吞吐能力450 VUs / 2 min450 VUs / 2 分钟RPS 216.8 vs 214.0RPS 216.8 vs 214.0
Application应用Latency响应时延same load相同压测条件37.1ms vs 174.6ms (−79%)37.1ms vs 174.6ms（低 79%）
Application应用Stability稳定性same RPS相同 RPSfailure 0.04% vs 0.87%失败率 0.04% vs 0.87%
Placeholder · PPT Chart
📊
PoC Performance Comparison ChartsPoC 性能对比图表
Insert the four highlight stat cards (+94%~125% PostgreSQL, +63%~72% MySQL, 20% CVM lower, 37ms vs 175ms latency) and the full PoC comparison detail table screenshot.插入四个亮点数据卡（PostgreSQL +94%~125%、MySQL +63%~72%、CVM 低 20%、时延 37ms vs 175ms）及 PoC 对比明细表截图。

Requirement Scenarios & Solution Matching需求场景分析与方案匹配

Scenario × our product match × competitor challenge — a three-column comparison.需求场景 × 我方产品匹配 × 友商挑战 三栏对照。

Scenario需求场景Core ask客户核心诉求Our product / solution我方产品 / 方案匹配Competitor challenge友商挑战
Infra migration基础设施迁移Cut TCO, keep performance & availability降低 TCO，保持性能与可用性不下降CVM / TKE / CBS + Jakarta 3-AZ; PoC-measured cost advantageCVM/TKE/CBS + 雅加达 3 AZ；PoC 实测性价比优势Incumbent's familiarity; uses migration cost/risk to keep client put存量架构熟悉度高，可用迁移成本与风险说服客户不动
Architecture portability架构可移植性Avoid lock-in, adopt open standards避免厂商锁定，采用开放标准K8s + Terraform + open-compatible stack; 102-item PaaS mapK8s + Terraform + 开源兼容技术栈；102 条 PaaS 服务映射表Proprietary PaaS stickiness; client deeply dependent on managed services专有 PaaS 服务粘性强，客户已深度依赖其托管能力
Data platform rework数据平台重构Unify multi-source heterogeneous data stacks多源异构数据栈统一治理DW / processing / governance / viz full-stack; Technical 196 items covered数仓 / 数据处理 / 治理 / 可视化全栈自研，Technical 196 条全覆盖Raises the bar with Snowflake / BigQuery / Abinitio ecosystem以既有 Snowflake、BigQuery、Abinitio 生态提高替换门槛
AI/ML platformAI/ML 平台Land GenAI & classic AI capabilityGenAI 与传统 AI 能力落地TI platform + LLM knowledge engine + HCC compute; 190-item AI/ML SoCTI 平台 + LLM 知识引擎 + HCC 算力；AI/ML SoC 190 条应答Complete AI portfolio but tightly bound to its data stack, deepening lock-inAI 服务组合完整但与数据栈强绑定，加剧锁定风险
O&M & FinOps运维与 FinOpsCross-team cost visibility, allocation, prediction多团队成本可见、可分摊、可预测79-item FinOps toolchain; FOCUS-compliant + multi-cloud unified viewFinOps 工具链 79 条全覆盖，支持 FOCUS 规范与多云统一视图Limited multi-cloud cost governance; cross-cloud tagging hard to unify多云成本纳管能力有限，跨云口径难以统一
Joint ops & handover联合运营与移交Self-operation after 12-month joint ops12 个月联合运营后自主运营Embedded support + SLA + runbook & knowledge transfer + exit plan嵌入式支持团队 + SLA 保障 + 运行手册与知识转移 + 退出计划Replaces capability handover with long-term managed stickiness, limiting autonomy以长期托管黏性替代能力移交，客户自主性受限
Matching principle: every scenario must find a "we can prove, they must compromise" fulcrum — never compete on the rival's strengths; drag the battlefield to cross-cloud unified governance, portability and capability handover. 匹配原则：每一个场景都必须找到「我方能自证、友商需妥协」的支点——不与友商比拼其强项，而是把战场牵引到跨云统一治理、可移植性与能力移交上。

Seven Differentiators方案的七项差异化能力

Each differentiator aligned to a client scenario and a competitor gap.七大差异化逐条对齐客户场景需求与友商短板。

1
Solid IDC & IaaS base坚实的 IDC 与 IaaS 底座
Jakarta 3 availability zones, cross-AZ latency <5ms; PoC-measured compute & database cost advantage across the board.雅加达 3 可用区，跨 AZ 时延 <5ms；PoC 实测计算与数据库性价比全面领先。
Why it works: hits the cost-reduction ask, backed by measurement not claims.为何有效：切中降本诉求，且由实测而非宣称支撑。
2
Multi-industry migration track record多行业迁移实战经验
Large-scale migration delivered for GoTo (Indonesia's largest digital ecosystem), CP Group (Thailand's largest business group), etc.GoTo（印尼最大数字生态）、CP Group（泰国最大商业集团）等大规模迁移交付。
Why it works: answers delivery-risk doubts with same-region, same-scale references.为何有效：以同区域、同量级案例回应交付风险质疑。
3
End-to-end full-stack observability端到端全栈可观测
Managed Prometheus + Grafana + CLS centralized logs, covering infra through application.托管 Prometheus + Grafana + CLS 集中日志，覆盖基础设施到应用全链路。
Why it works: unifies multi-cloud observation, closing cross-cloud governance blind spots.为何有效：统一多云观测口径，弥补跨云治理盲区。
4
No vendor lock-in无厂商锁定
K8s + Terraform + open-compatible stack; 102-item PaaS map with per-item compatibility level.K8s + Terraform + 开源兼容栈；102 条 PaaS 服务映射逐条给出兼容等级。
Why it works: directly answers the portability goal the RFP explicitly set.为何有效：直接回应 RFP 明确提出的可移植性目标。
5
Telecom-grade reliability电信级可靠性
Carrier-grade SLA and status transparency, with public service-health dashboards.面向运营商级 SLA 与状态透明度，公开服务健康看板。
Why it works: meets telecom's high bar for availability and transparency.为何有效：满足电信行业对可用性与透明度的高要求。
6
Compliance & data sovereignty合规与数据主权
Global & regional compliance certifications in place, local data residency, 43 privacy items covered.全球与区域合规认证齐备，本地数据驻留，隐私保护 43 条全覆盖。
Why it works: resolves data-sovereignty and audit requirements in regulated industries.为何有效：解决监管行业的数据主权与审计要求。
7
AI-ready full-stack capabilityAI Ready 全栈能力
TI platform, LLM knowledge engine, HCC high-performance compute, AI-in-Box integrated delivery.TI 平台、LLM 知识引擎、HCC 高性能算力，AI-in-Box 一体化交付。
Why it works: underpins the Judo mainline's GenAI & Classic AI landing.为何有效：支撑 Judo 主线 GenAI 与 Classic AI 落地。

Competitor Formations & Our Counter友商投标阵型与我方反制

Huawei relies on a professional bid support unit; Alibaba on local ecosystem depth. We countered with "ecosystem gap-filling + FinOps partners + one-stop cloud-native monitoring".华为靠专业投标支持组、阿里靠本地生态深耕——我方以"生态补位 + FinOps 伙伴 + 一站式云原生监控平台"反制。

Huawei Cloud华为云
Bid support unit · iron triangle专业投标支持组 · 铁三角
Their strength友商优势
  • Iron triangle: AR + SR + FR, jointly accountable铁三角：客户经理 + 方案 + 交付，共同负责
  • Five-platform support; ATI gate (<60 = abandon)五大平台支撑；ATI 立项评审（<60 弃标）
  • Deep pre-bid steering, raising the bar深度标前引导，抬高门槛
Our counter我方打法
  • Turn "standard battle" into "measured battle" via PoC把"标准之争"转为"实测之争"
  • Local large migration references印尼本土大型迁移项目经验
Alibaba Cloud阿里云
Years of local ecosystem多年深耕 · 本地生态
Their strength友商优势
  • Early market entry, mature local partners/channels进入印尼早，本地伙伴/渠道成熟
  • Deep relationships & strong reference cases客户关系深，标杆案例多
Our counter我方打法
  • Turn "experience battle" into "checklist battle" — 102-item map quantifies friction把"经验之争"转为"清单之争"——102 条映射量化摩擦
  • Quickly fill local partners快速补齐本地伙伴
Winner中标方
Tencent Cloud腾讯云
Ecosystem + FinOps + observability生态补位 + FinOps + 可观测
Our gaps我方短板
  • Few local partners in Indonesia印尼本地伙伴缺少
  • Marketplace ecosystem thinnermarketplace 生态不如友商
Our counter反制打法
  • Ecosystem team secured official support letters (Solace)生态组拿到关键西方厂商技术支持函（Solace）
  • FinOps partners: tried 3 until satisfiedFinOps 伙伴：试 3 家直到满意
  • TCOP observability replaces Datadog, cutting costTCOP 可观测平台平替 Datadog，降本上手快

Three Steering Tactics & Two Comebacks竞争应对与评分攻防：三类引导手法、两次反超

Three competitor steering tactics → three counter-moves → from briefly trailing to retaking and holding #1.友商三类引导手法 → 三种反制动作 → 评分从一度落后反超到守住第一。

1
Define technical standards by their own capability boundary手法一：以自身能力边界定义技术标准
Their move:手法： Push the client to write SoC items around their service matrix, so non-incumbent vendors naturally score PC/NC.推动客户按其服务矩阵撰写 SoC 条目，使非现网供应商天然出现 PC/NC 项。
Our counter — turn "standard battle" into "measured battle":反制——把标准之争转为实测之争： Rebuild the comparison baseline with PoC measured data, putting performance & cost back on verifiable objective ground; give product names and evidence chains item by item, eliminating any "cannot map" judgment space.以 PoC 实测数据重建对标口径，让性能与成本回到可验证的客观基准；同时逐条给出产品名与证据链，消除「无法对应」的判断空间。
2
Manufacture migration friction with proprietary PaaS手法二：以专有 PaaS 服务制造迁移摩擦
Their move:手法： Emphasize the replacement cost of proprietary managed services, hinting migration causes capability downgrade and secondary rework.强调专有托管服务的替换成本，暗示迁移将导致能力降级与二次改造。
Our counter — quantify friction into a checklist:反制——以映射表把摩擦量化为可控清单： Deliver a 102-item Origin → Target service map, each marked with Jakarta availability and compatibility level (FC/PC/NC/NA), turning "uncertain risk" into "a list with plans".交付 102 条 Origin→Target 服务映射，逐条标注雅加达可用性与兼容等级（FC/PC/NC/NA），把「不确定的风险」变成「有方案的清单」。
3
Use regional experience to push new big data + AI scope手法三：以自身区域经验为支点，推动新增大数据与 AI
Their move:手法： Judo's big data and AI were not originally scheduled to migrate together; the rival leveraged its Indonesia-region BigQuery migration experience as the attack angle, steering the client to add big data first, then AI&ML, raising the full-stack response bar.Judo 的大数据与 AI 原本未决策一起迁移；友商以其印尼区域 BigQuery 迁移经验为攻击优势项，引导客户先增大数据、再增 AI&ML，提高全栈应答门槛。
Our counter — detect early + pull product architects to meet the client:反制——及时甄别 + 拉产品架构师面访客户： After recognizing it as steering rather than a genuine client need, immediately pulled the big-data and AI product architects to present to the client's key contacts; Technical data & AI five volumes (210 items) + AI/ML SoC (190 items) all answered, closing the coverage gap.识别为引导而非客户自发需求后，立即拉大数据与 AI 产品架构师面访客户关键接口人讲解方案；Technical 数据与 AI 五册 210 条 + AI/ML SoC 190 条全部应答，补齐该域覆盖。
🥇

Scoring trajectory: lead → briefly trailing → comeback → hold #1评标位次：领先 → 一度落后 → 反超 → 守住第一

Why the client chose us: 602 items 100% Full Comply + PoC-measured performance/cost advantage + capability handover instead of lock-in. The takeaway: scope expansion is not just more work — it is a scoring reset. Whether you can make the newly-added domain provable in short order decides whether you hold the score.客户选择我方核心原因：602 条 100% Full Comply + PoC 实证性能成本优势 + 能力移交而非锁定。拉锯总结：范围新增不只是工作量，更是一次评分重置——能否短时间把新增域也做到可举证，决定评分能否守住。

High-Level Game & AI + Migration Factory技术投标轮：高层博弈与 AI + 迁移工厂

High-level relationships cannot break the tie — the winning move sinks to the architect team. Tencent Cloud used "AI + Migration Factory" to let the IT team complete the migration "comfortably".高层关系拉不开差距，胜负手下沉到架构师团队——腾讯云以「AI + 迁移工厂」让 IT 团队「舒服地」完成迁移。

1
Engage at the top高屋建瓴 · 高举高打

Engage the client's senior leadership and build trust; elevate the project to a strategic partnership rather than a one-off purchase.engage 客户高层，建立信任关系；把项目抬升为战略合作，而非单次采购。

2
Both sides went all-in双方底牌尽出

The client's leadership visited China; Alibaba introduced its CEO, Tencent Cloud introduced its CEO — matched high-level investment, no one conceded.客户高层访华，阿里云引荐 CEO、腾讯云引荐 CEO——高层资源对等投入，互不相让。

3
Conclusion: no edge gained结论：拉不开差距

High-level relationships could not become the winning move — the battlefield sank to the "working-member layer".高层关系无法成为胜负手——战场下沉到「工作成员层」。

4
Key insight关键洞察

The cooperation of working members (key architect teams) becomes the unstable factor — any large IT migration is painful. The real winning move: how to let IT architects / DevOps / O&M / app developers complete the migration "comfortably"?工作成员（关键架构师团队）的配合反而成为不稳定因素——任何大型 IT 企业迁云都极其痛苦。真正的胜负手：如何让 IT 架构师 / DevOps / 运维 / App 开发「舒服地」完成迁移？

Tencent Cloud's answer: AI + Migration Factory腾讯云解法：AI + 迁移工厂

①

Point AI tooling单点 AI 工具提效

AI tools for each migration step迁移各环节的 AI 工具

②

Full-stack methodology全栈迁移方法论

Standardized process & best practices标准化迁移流程与最佳实践

③

AI migration toolingAI 迁移工具

Auto inventory / conversion / validation自动盘点 / 转换 / 验证

④

Senior migration architects资深迁移架构师

End-to-end guidance & key decisions全程护航与关键决策

⑤

Senior PM team资深项目管理团队

Cadence, risk & expectation control节奏、风险与客户预期管控

🛠️

Conclusion结论

AI + Migration Factory + a senior project-management team turn the "pain of cloud migration" into a "controllable, predictable delivery experience", completely dispelling the client's doubts.AI + 迁移工厂 + 资深项目管理团队，把「迁云痛苦」转化为「可控、可预期的交付体验」，彻底打消客户疑虑。

Turnkey Delivery: Do Every Piece to the Extreme交钥匙工程：既然要干，就把每一项做到极致

The client wanted turnkey — parse every turnkey detail, discuss each partner in depth, and lock it into the technical proposal.客户要交钥匙（Turnkey）——充分解析交钥匙细节，每一家伙伴都深入讨论并落实到技术 proposal。

01
Subcontractors分包商

Migration / app rework / testing staffing & hours confirmed one by one迁移实施 / 应用改造 / 测试的人力与工时逐一确认

02
Service providers服务商

Local L0–L1 O&M, on-site response & response SLAs本地 L0–L1 运维、驻场响应与响应时限

03
COTSCOTS

Vendor / ISV reinstall & reconfig, license validation, official support letter原厂 / ISV 重装重配、License 校验、官方技术支持信

04
App migration partnersApp 迁移伙伴

App refactor / environment adaptation / regression closed loop应用重构 / 环境适配 / 回归测试闭环

05
O&M partners运维伙伴

L2–L3 diagnosis & recovery, telecom-grade SLA backstopL2–L3 定位恢复、电信级 SLA 兜底

06
Marketplace partnersMarketplace 伙伴

Cross-cloud FinOps platform, third-party tool governance跨云 FinOps 平台、第三方工具纳管

Four steps into the technical proposal落实到技术 proposal 的四步

1
Deep-dive each partner逐一深入讨论

Every partner's responsibility boundary, deliverables, SLA commitments.每家伙伴的职责边界、交付物、SLA 承诺。

2
Get verifiable evidence拿到可核验依据

Official support letters, authorization, license migration paths.原厂技术支持信、授权、License 迁移路径。

3
Lock into the proposal落实到技术 proposal

Freeze each into the corresponding chapter one by one.对应章节逐一固化。

4
End-to-end ownership端到端交付责任主体

Turnkey integrated delivery, single responsible owner.交钥匙一体化承接。

🔐

Conclusion结论

Since we decided to do it, do every piece to the extreme — turnkey is not shifting risk to partners, but locking the certainty of every link into the technical proposal in advance.既然决定要干，就把每一项做到极致——交钥匙不是把风险转嫁给伙伴，而是把每一个环节的确定性提前锁定在技术 proposal 里。

Team Composition — Who's on the Field团队组建 — 谁在场上

Two front lines — bid team (response & commitment) and PoC team (validation & evidence) — with the solution architect standing at their intersection.两条战线——投标组（应答与承诺）与 PoC 组（验证与举证），架构师站在交汇点上。

Bid Working Group投标工作组

Proposal · SoC response · pitch · delivery handover标书 · SoC 应答 · 述标 · 交付资源承接
Sales Lead销售 Solution Architect解决方案架构师 Project Manager项目经理 Bid Manager投标经理 Product Architects产品架构师 Ecosystem (COTS/ISV)生态中心 FinOps VendorFinOps 厂商 Local Ops Partner本地运维伙伴

PoC Working GroupPoC 工作组

Measurement · evidence production实测验证 · 证据产出
Project Manager项目经理 Migration Architect迁移架构师 Product Architects产品架构师 Industry Architect行业架构师
👥

The same people run the PoC and the delivery上场的人就是交付的人

PoC members became key delivery members — so technical trust converted directly into delivery trust. The solution architect's seven duties: resource mobilization, RFP decomposition, proposal writing, SoC response, pitch team, PoC steering, and technical support.PoC 成员即后续交付关键成员——技术信任直接转为交付信任。售前架构师七项职责：资源整备、RFP 拆解、标书制作、SoC 应答、述标团队、PoC 引导、技术支持。

Topic 2 · 2.5主题二 · 2.5

Architecture & Team Design架构设计与团队组建

Four diagrams that carried the bid — the migration path from the current cloud to the target architecture, and the three team structures that organized the whole effort: the delivery organization, the PoC unit, and the bid unit.支撑整个投标的四张图——从现网到目标架构的迁移路径，以及组织整个交付的三类团队结构：交付组织、PoC 团队与应标团队。

01Migration Architecture — AS-IS to TO-BE迁移架构设计 — 从现网到目标架构

The current workloads run on a public cloud (touchpoint apps, middleware, big data, AI/ML). We migrated them over a Landing Zone — 3 AZs, CCN / site-to-site VPN, full IaC via Terraform — in 4 batches, split into the Fustal application mainline (60%) and the Judo data mainline (40%).现网负载运行于公有云（触点应用、中间件、大数据、AI/ML）。我们通过 Landing Zone——3 个可用区、CCN/专线互联、Terraform 全量 IaC——分 4 个批次迁移，分为 Fustal 应用主线（60%）与 Judo 数据主线（40%）。

AS-IS · Current Cloud现网 · 公有云
AWS, running the merged operators' workloadsAWS，承载合并运营商负载
Touchpoint apps触点应用myXL · Axisnet · mySFmyXL · Axisnet · mySF
Middleware中间件Solace · Kafka · cacheSolace · Kafka · 缓存
Big Data platform大数据平台DW · processing · governance数仓 · 处理 · 治理
AI / MLAI / MLtraining · serving训练 · 推理
→
Landing Zone · 3 AZLanding Zone · 3 可用区
CCN + Site-to-Site VPNCCN + 专线 VPN
Terraform full IaCTerraform 全量 IaC
4 batches4 个批次
Fustal 60% + Judo 40%Fustal 60% + Judo 40%
TO-BE · Tencent Cloud Jakarta目标 · 腾讯云雅加达
Portable, unified, cost-optimized可移植、统一、成本优化
Touchpoint apps触点应用CVM SA5 · TKECVM SA5 · TKE
Middleware中间件TDMQ · CKafka · RedisTDMQ · CKafka · Redis
Big Data大数据EMR · TCHouseEMR · TCHouse
AI / MLAI / MLTI platformTI 平台
FinOps + TCOP observabilityFinOps + TCOP 可观测

02Project Team — Three-Layer Delivery Organization项目组组建 — 三层交付组织

A capability gap is never filled by a single team. The internal capability pool, ecosystem OEMs, and local partners each cover a segment — an assembly method that can be reused laterally across large bids.能力缺口不是靠一个团队填的——内部能力池、生态原厂、本地伙伴各补一段，组局方法可横向复用到大标。

Layer 1第一层Tencent Internal Capability Pool腾讯内部能力池solves "solution–delivery consistency"解决「方案与交付一致性」
TCI Technical ServicesTCI 技术服务组solution design · architecture validation · technical backstop方案设计 · 架构验证 · 技术兜底
CPT Delivery TeamCPT 交付组migration execution · effort & scheduling迁移实施 · 工时与节奏确认
Ecosystem Services生态服务部COTS OEM · ISV engagementCOTS 原厂 · ISV 对接
Product / Industry Teams产品 / 行业团队product capability · industry scenarios产品能力 · 行业场景
Subcontracting Center分包中心overseas vendor screening · qualification海外服务商摸排 · 资质合规
After-Sales Services售后服务中心O&M boundary · local service运维边界 · 本地服务引入
Layer 2第二层Ecosystem & OEMs生态与原厂solves "availability of non-Tencent products"解决「非我方产品的可用性」
COTS OEM (e.g. Solace)COTS 原厂（如 Solace）new-platform compatibility + support letter新平台兼容性 + 技术支持信
ISV / OEM AuthorizationISV / 原厂授权license migration path + support activationLicense 迁移路径 + 支持激活
Overseas FinOps Vendor海外 FinOps 服务商cross-cloud cost platform (FOCUS-compliant)跨云成本平台（符合 FOCUS 规范）
Layer 3第三层Local & Regional Partners本地与区域伙伴solves "on-the-ground staffing & localization"解决「落地人力与本地化」
Strong teams from incumbent vendors现网服务商中的优质团队already familiar with the app architecture已熟悉应用架构，学习曲线最短
Local O&M Partner本地运维伙伴L0–L1 on-site response承接 L0–L1 现场响应

03PoC Team — Measurement & EvidencePOC 团队组建 — 实测验证与证据产出

A lean, delivery-grade unit (not a demo) that validated five domains on two real applications — 37 functional cases all passed, and the results were reused directly in the proposal.一支以生产标准（而非演示）组建的精干团队，在两大真实应用上完成五大验证域——37 个功能用例全部通过，结果被直接复用进标书。

PoC Working GroupPoC 工作组

Measurement · evidence production实测验证 · 证据产出
  • PMPM
    Project Manager项目经理validation plan & progress验证计划与进度
  • MAMA
    Migration Architect迁移架构师environment setup & migration validation环境搭建与迁移验证
  • PAPA
    Product Architects产品架构师per-product capability testing各产品能力实测
  • IAIA
    Industry Architect行业架构师telecom scenario alignment电信业务场景对齐

Five Validation Domains五大验证域

37 functional cases · all passed37 个功能用例 · 全部通过
  • NET网络
    Network网络independent VPC · 3 subnets · CCN · S2S VPN独立 VPC · 三类子网 · CCN · S2S VPN
  • IaCIaC
    TerraformTerraformCAM, VPC/subnet/NAT, TKE — full IaCCAM、VPC/子网/NAT、TKE 全量 IaC
  • OBS监控
    Monitoring & Logs监控日志Prometheus + Grafana · CLS central logsPrometheus + Grafana · CLS 集中日志
  • APP应用
    Application应用dual entry parallel · nginx-ingress dual control双业务入口并行 · nginx-ingress 双控
  • DB数据库
    Database Migration数据库迁移MySQL/PG, DocumentDB → Tencent CloudMySQL/PG、DocumentDB → 腾讯云

04Bid Team — Who's on the Field应标团队组建 — 谁在场上

Centered on sales and the solution architect, the team split into two front lines — the bid working group (response & commitment) and the PoC working group (validation & evidence) — with external partners plugged in on the edges.以销售与解决方案架构师为核心，按「投标」与「PoC」两条战线分别组队——投标组承接应答与承诺，PoC 组承接验证与举证，外围接入第三方伙伴。

Dual Core双核心

the two leads who anchor the bid锚定投标的两位牵头人
Sales Lead销售 Solution Architect解决方案架构师
  • S销
    Sales Lead销售client relationship · commercial rhythm · decision chain客户关系 · 商务节奏 · 决策链推进
  • SA架
    Solution Architect解决方案架构师technical owner · cross-team resource mobilization技术方案总负责 · 跨团队资源整备

    • Bid Working Group投标工作组

    proposal · SoC response · pitch · delivery handover标书 · SoC 应答 · 述标 · 交付资源承接
    • PMPM
      Project Manager项目经理rhythm & deliverable control节奏与交付物管控
    • BMBM
      Bid Manager投标经理commercial compliance & process商务合规与投标流程
    • PAPA
      Product Architects产品架构师per-domain solution & endorsement各产品域方案与背书
    • ECO生
      Ecosystem Services生态服务中心COTS OEM & ISV coordinationCOTS 原厂与 ISV 协调
    • AFS售
      After-Sales Services售后服务中心O&M boundary & local service运维边界与本地服务
    3rd-party FinOps Vendor第三方 FinOps 厂商 Local O&M Vendor本地运维服务商 Local Migration Partner本地迁移合作伙伴
    🧭

    The Solution Architect's Seven Duties售前解决方案架构师的七项职责

    Resource mobilization · RFP decomposition · proposal writing · SoC response · pitch team · PoC steering · technical support. The architect stands at the intersection of both front lines — pulling internal and external resources together while keeping the two teams' outputs perfectly consistent.资源整备 · RFP 拆解 · 标书制作 · SoC 应答 · 述标团队 · PoC 引导 · 技术支持。架构师站在两条战线的交汇点，既要把内外部资源拉齐，也要保证两条战线产出完全一致。

    Topic 2 · 2.6主题二 · 2.6

    Proposal & SoC Library招投标方案展示

    The full technical proposal and all six Statement-of-Compliance (SoC) workbooks submitted during the XLSmart bid — browse the summary cards, then open any item to read the complete original content. 投标阶段提交的完整技术标书与全部六份 SoC 合规应答工作簿——先浏览概要卡片，再点开任意方案查看完整原始内容。

    SoC Panorama: 1,400+ Requirements · 40 Volumes四份 SoC 应答全景：1,400+ 条要求构成

    A total-integration project spanning 6 major capability domains — the response was engineered as an industrialized production line, not written ad hoc.1,400+ 条要求 · 40 个应答分册 · 跨 6 大能力域的总集成工程。

    SoC workbookSoC 工作簿Volumes分册Items条目Capability domains covered覆盖能力域Response difficulty应答难点
    Technical SoCTechnical SoC（技术标）13602IaaS / security / FinOps / data privacy / PaaS compatibility / governance / DW / processing / viz / AI platformIaaS / 安全 / FinOps / 数据隐私 / PaaS 兼容 / 数据治理 / 数仓 / 数据处理 / 可视化 / AI 平台Unify terminology across 13 domains; map 102 PaaS services item-by-item跨 13 域术语与口径统一；102 条 PaaS 服务逐条映射兼容等级
    Migration SoCMigration SoC（迁移服务）436 + 7211 migration method classes + 11 RACI function domains + 69-app list + 6 resource roles迁移方法论 11 类 + RACI 11 职能域 + 69 应用清单 + 6 类资源角色Commit end-to-end ownership; RACI defines three-party responsibility boundaries需承诺端到端 ownership；RACI 需逐项界定三方责任边界
    AI/ML SoCAI/ML SoC（AI 平台）1190AI/ML 32 · AIOps 77 · Analytics 24 · MLOps 21 · Agentic AI 15 · Storage 14 · Notebook 7AI/ML 32 · AIOps 77 · Analytics 24 · MLOps 21 · Agentic AI 15 · Storage 14 · Notebook 7AIOps & Agentic AI are emerging domains needing product-grade evidence per itemAIOps 与 Agentic AI 为新兴域，需逐条给出产品级证据
    BOT SoCBOT SoC（运维托管）22570+Regulatory compliance / O&M 11 modules / tool ecosystem 13 classes / transition / priority matrix / 14 SLA-KPI classes监管合规 / O&M 11 模块 / 工具生态 13 类 / 转入转出 / 优先级矩阵 / 14 类 SLA-KPITelecom-grade SLA & P0–P4 incident tiers; BOT must commit post-handover self-operation电信级 SLA 与 P0–P4 事件分级；BOT 模式需承诺移交后自主运营
    Total合计401,400+6 capability domains, end-to-end6 大能力域端到端全覆盖Unified integration by the pre-sales architect, zero cross-volume contradiction由售前架构师统一总集成，保证跨册零矛盾
    ✅

    The three elements of a full-score (FC) responseSoC 应答样板：FC 满分三要素

    ① Answer every item FC without dodging  ·  ② Attach "solution + evidence + owner" to every item  ·  ③ Any vague wording is treated as NC. Real Technical SoC excerpt (D.31–D.36): client requirement → line-by-line response + evidence link + score.① 逐条 FC，不回避  ·  ② 每条附「方案 + 证据 + 责任人」 ·  ③ 任何模糊表述一律按 NC。真实 Technical SoC 节选（D.31–D.36）：客户原始需求 → 逐条应答 + 证据链链接 + 评分。

    Technical SoC: 602 Items IndustrializedTechnical SoC：602 条的产线化应答

    13 volumes · zero PC / zero NC · 100% Full Comply — the largest of the four workbooks.13 个分册 · 零 PC / 零 NC · 100% Full Comply（四份 SoC 中体量最大的一份）。

    13
    volumes个分册
    602
    items条目
    100%
    Full Comply完全合规
    0
    PC / NC零 PC / 零 NC
    Volume分册Items条目Compliance合规Responsible capability domain主责能力域
    A General总体支撑19100%General support & training总体支撑与培训
    B Operations运维35100%Availability & connectivity可用性与连通性
    C DevOpsDevOps7100%IaC & observabilityIaC 与可观测
    D Cloud Security云安全107100%Security & protection安全与防护体系
    E FinOpsFinOps79100%Cost governance toolchain成本治理工具链
    F Data Privacy数据隐私43100%Privacy & third-party risk隐私与第三方风险
    G PaaS CompatibilityPaaS 兼容102100%Service mapping & compatibility服务映射与兼容
    I Data Governance数据治理68100%Data governance数据治理
    J Data Warehouse数仓50100%Warehouse & analytics数仓与分析
    K Data Processing数据处理70100%Processing & ETL数据处理与 ETL
    L Data Visualization可视化8100%Visualization可视化
    M AI/ML PlatformAI/ML 平台14100%AI platformAI 平台
    Total合计602100%13 volumes, full coverage13 个分册全覆盖

    Four guarantee mechanisms四项保障机制

    1
    Responsibility matrix to the item责任矩阵到条

    Each item bound to a single responsible expert + reviewer, avoiding gaps at volume boundaries; unified scheduling closes every item in the submission window.每一条要求绑定唯一主责专家与复核人，避免分册交界处漏答；统一排期保证提交窗口内闭环。

    2
    Mandatory evidence chain证据链强制

    Every response must name the product/service and give verifiable basis (doc link, whitepaper, certification, PoC report) — no vague wording.每条应答必须给出产品名/服务名与可核验依据（文档链接、白皮书、认证、PoC 报告），杜绝模糊表述。

    3
    Unified terminology & calibration术语与口径统一

    The architect acts as total integrator, unifying product naming, metric calibration and templates across 13 volumes to avoid self-contradiction.架构师做总集成，统一产品命名、指标口径与表述模板，确保 13 册跨域一致，避免自相矛盾。

    4
    PC/NC zeroing mechanismPC / NC 归零机制

    Any non-FC item enters special attack: either add a capability solution or give an equivalent alternative path, until it can be honestly marked Full Comply.任何非 FC 项进入专项攻坚：或补能力方案，或给等效替代路径，直至可诚实标注 Full Comply。

    Hard RFP constraints: vague wording like "Future Comply" / "Noted" is treated as Not Comply; a verifiable product name/code must be given, and the compliance percentage stated. RFP 的硬性约束：「Future Comply」「Noted」等模糊表述一律按 Not Comply 处理；必须给出产品名/代码用于验证，且需说明合规百分比。

    Scope Added: AI/ML 190 Items + BOT 22 Volumes范围新增：AI/ML 190 条与 BOT 运维托管 22 分册

    Two new SoCs: AI/ML spans 7 capability domains; BOT extends into long-term Build-Operate-Transfer managed service.两大新增 SoC：AI/ML 覆盖 7 大能力域，BOT 延伸到 Build-Operate-Transfer 长期托管。

    190
    items条要求
    189
    Full Comply条 Full Comply
    7
    capability domains个能力域
    185
    mandatory items条为强制项

    AI/ML — 7 capability domainsAI/ML 七大能力域

    190 items条
    AIOps77Monitoring / alerting / anomaly / observability监控 / 告警 / 异常检测 / 可观测
    AI/ML32GPU training / distributed training / LLM hostingGPU 训练 / 分布式训练 / LLM 托管
    Analytics24BI / reporting / geospatial analysisBI / 报表 / 地理空间分析
    MLOps21Model lifecycle / drift detection / deployment模型生命周期 / 漂移检测 / 部署
    Agentic AI15LLM operations / agent orchestrationLLM Operations / 智能体编排
    Storage14AI data persistence & metadataAI 数据持久化与元数据
    Notebook7Serverless notebook / output persistenceServerless Notebook / 输出持久化

    BOT — 22 volumesBOT 运维托管 22 分册

    570+ items条
    Compliance & governance合规与治理8Indonesia regulation / audit / QHSSaEM印尼监管 / 审计 / QHSSaEM
    O&M运维维护 O&M8211 modules — AI ops / zero-touch / 3PP governance11 模块 — AI 运维 / 零接触 / 3PP 纳管
    Tool ecosystem工具生态6613 classes — FMT / AMaPMT / CMT / IMS13 类 — FMT / AMaPMT / CMT / IMS
    Transition in/out转入与转出20Transition team / knowledge transfer过渡团队 / 知识转移
    SLA & KPISLA 与 KPI14Exhibits — availability tiers / P0–P4 / 98% fix rate14 类 Exhibit — 可用性分级 / P0–P4 / 修复率 98%
    Apps & priority应用与优先级87Row list — complexity / revenue-transaction impact87 行清单 — 复杂度 / 收入交易影响定级
    Difficulty: AI/ML's only PC item (Serverless Notebook scale-to-zero) was honestly labeled with an alternative path rather than fudged as FC; BOT must simultaneously commit telecom-grade SLA, Indonesia local compliance, a complete toolchain and capability handover — the hardest for pure-IaaS vendors. 两大 SoC 的应答难点：AI/ML 唯一 1 条 PC（Serverless Notebook 缩容至零）如实标注并给替代路径，而非含糊标 FC；BOT 需同时承诺电信级 SLA、印尼本地合规、完整工具链与能力移交——纯 IaaS 供应商最难覆盖。
    Proposal & SoC方案展示 / …
    Topic 2 · 2.6 Lessons主题二 · 2.6 复盘

    Honest Retrospective诚实复盘

    A candid review has more reuse value than a success story.诚实复盘比成功叙事更有复用价值。

    ✓Four things done right做对了的四件事

    1. Proactively fought for PoC — same team, delivery-ready一线主动争取 PoC，且上场即交付团队

    Opportunity created by the frontline; PoC members became key delivery members.机会由一线自己争取；PoC 成员与交付关键成员一致。

    2. Detected steering early and escalated immediately及时甄别引导意图，并立刻升级资源

    Two scope expansions recognized as competitor steering; pulled product architects to meet the client, turning scoring reset into a comeback.两次范围新增被识别为友商引导，第一时间拉产品架构师面访，把评分重置转为反超。

    3. Insisted on evidence chains and honest labeling坚持证据链与如实标注

    The one PC item in AI/ML SoC was labeled honestly with an alternative path — strengthening credibility.AI/ML SoC 唯一 1 条 PC 如实标注并给替代路径——反而强化专业可信度。

    4. Verified delivery feasibility during the bid在投标期就核算交付可行性

    14 on-site in Indonesia, 8,970 person-days, SLA penalty model — all validated pre-award.14 人常驻印尼、8,970 人天、SLA 罚则模型均在投标阶段完成论证。

    !Four things to improve若重来会改进的四件事

    1. Detect scope-inflation signals earlier更早识别范围膨胀的信号

    The three rounds happened gradually; earlier cross-domain experts would reduce late crunch.三轮新增逐步发生；更早启动跨域专家进场可减少后期赶工。

    2. Build a standardized SoC asset library up front提前建立 SoC 应答标准化资产库

    Much of 1,400+ items is common Q&A; a pre-built item/evidence library frees people for differentiators.1,400+ 条中大量为通用问答；有条目库与证据库可把人力集中到差异化条目。

    3. Set the agenda more proactively in clarification在澄清阶段更主动地设置议题

    Mostly passive replies; proactively raising favorable topics (e.g. portability validation) could steer the baseline further.澄清多为被动答复；主动提出有利技术议题可进一步牵引评估口径。

    4. Align the delivery resource model earlier交付资源模型应更早与交付团队对齐

    Person-day & on-site estimates were pre-sales-led; earlier delivery-side involvement raises granularity.人天与驻场估算由售前主导；交付侧更早介入可提高颗粒度与可执行性。

    Placeholder · PPT Material
    🖼️
    XLSmart Technical Proposal — Table of ContentsXLSmart 技术标书目录
    Insert the actual 97-page technical proposal TOC screenshot (company intro / requirements / architecture / differentiators / O&M / FinOps / PM / enablement / after-sales / references). Also optional: the submitted material screenshots and team org diagram.插入 97 页技术标书目录截图（公司介绍/需求理解/架构/方案优势/运维/成本治理/项目管理/赋能/售后/案例）。可选：交标材料截图与团队架构图。
    AI × Bid LifecycleAI × 招投标全流程

    Where AI Helps at Every StageAI 在招投标各阶段的切入点

    AI augments — never replaces — the bid team. Below, concrete AI tasks are mapped to the six stages of the tendering & bidding workflow, each with its expected value and implementation notes. AI 增强而非替代投标团队。以下将具体 AI 任务映射到招投标全流程的六个阶段，并逐项给出预期价值与落地建议。

    1
    Initiation & Requirements立项与需求分析
    2
    Tender Document招标文件编制
    3
    Notice Publication招标公告发布
    4
    Bid Review投标文件评审
    5
    Evaluation & Award评标定标
    6
    Contract & Delivery合同签订与履约
    1

    Project Initiation & Requirements Analysis项目立项与需求分析

    Phase阶段 · Lead qualification & scoping商机研判与范围界定
    🧠
    Intelligent requirement extraction智能需求提取与结构化

    Extract and de-duplicate requirement points from project briefs, meeting notes and call transcripts, then auto-structure them into a prioritized list.从立项文档、会议纪要与访谈录音中自动抽取并去重需求要点，结构化生成带优先级的清单。

    🎯
    Opportunity scanning & matching商机扫描与匹配

    Monitor tender platforms and procurement intents, match them against capability tags, and rank high-value opportunities for proactive pursuit.监控招标平台与采购意向，按公司能力标签自动匹配打分，推送高价值商机。

    👤
    Customer 360 & procurement history客户画像与采购历史分析

    Aggregate a customer's procurement history, decision chain and preferences into a profile to judge bid feasibility and entry strategy.聚合客户历史采购数据、决策链与偏好，生成画像以判断投标可行性与切入策略。

    📊
    Scope & risk pre-assessment项目规模与风险评估

    Forecast effort, duration and margin from comparable past projects, and flag top risks before committing resources.基于历史同类项目预测工作量、周期与利润，并在投入资源前标注主要风险。

    Expected value预期价值Shorter qualification cycle, fuller opportunity coverage, more accurate and consistent requirement understanding.缩短立项周期、商机识别更全、需求理解更准且口径统一。
    Implementation落地建议Data: tender/notice feeds, CRM, historical project base, meeting notes. Key points: NLP extraction + vector retrieval (RAG) + knowledge graph + rule-based scoring.数据来源：招标公告库、CRM、历史项目库、会议纪要；技术要点：NLP 信息抽取 + 向量检索（RAG）+ 知识图谱 + 规则打分。
    2

    Tender Document Preparation招标文件编制

    Phase阶段 · RFP / SoC authoringRFP / SoC 编写
    📝
    Auto-generate draft tender document招标文件初稿自动生成

    Generate a first draft (technical spec, commercial terms, scoring rubric) from the requirement list and standard templates for human review.基于需求清单与标准模板自动生成招标文件初稿（技术规格/商务条款/评分标准），交由人工审校。

    ⚖️
    Scoring rubric assistance评分标准辅助设计

    Propose technical/commercial scoring rules, pass lines and veto items by referencing comparable projects and compliance requirements.参考同类项目与合规要求，辅助设计技术/商务评分细则、合格线与否决项。

    🛡️
    Clause compliance & risk scan条款合规与风险扫描

    Check clauses against regulations and internal policies, flagging gaps, conflicts and high-risk terms with annotations.对照法规与内部制度逐条检查，标注缺失、冲突与高风险条款。

    🔎
    Similar tender document reuse相似项目招标文件复用

    Retrieve historical tender documents and scoring methods on similar projects as a reference baseline.检索历史同类项目的招标文件与评标办法，作为编制参考基准。

    Expected value预期价值Greatly faster authoring, more standardized clauses, risks surfaced earlier.编制效率大幅提升、条款更规范、风险前置暴露。
    Implementation落地建议Data: tender template library, regulation base, historical tender documents. Key points: LLM generation + RAG retrieval + rule-engine validation.数据来源：招标文件模板库、法规库、历史招标文件；技术要点：LLM 生成 + RAG 检索 + 规则引擎校验。
    3

    Tender Notice Publication招标公告发布

    Phase阶段 · Outreach & reach发布与触达
    📣
    Auto-draft & multilingual notice公告自动撰写与多语言生成

    Generate the tender notice from structured data in the required format, and produce localized language versions.按格式规范从结构化数据自动生成公告，并生成本地化多语言版本。

    🧭
    Channel matching & scheduling发布渠道智能匹配与定时

    Match the best publishing platforms and time windows by project type to maximize effective reach.根据项目类型匹配最佳发布平台与时间窗口，提升有效触达。

    ✅
    Format compliance validation公告格式合规校验

    Validate completeness of mandatory fields (project, budget, qualification, timeline, venue) before going live.校验公告要素完整性（项目/预算/资质/时间/地点），避免漏项发布。

    📈
    Bidder attention forecasting响应方关注度预测

    Predict registration volume and competition intensity from historical announcement data to set expectations.基于历史公告数据预测报名量与竞争烈度，提前管理预期。

    Expected value预期价值Timely, wide-reaching and compliant publication with more precise targeting.发布及时、覆盖广、格式合规、触达更精准。
    Implementation落地建议Data: publishing platform APIs, notice templates, historical publication data. Key points: template engine + multilingual model + rule validation.数据来源：发布平台接口、公告模板、历史发布数据；技术要点：模板引擎 + 多语言模型 + 规则校验。
    4

    Bid Document Review & Screening投标文件评审

    Phase阶段 · Bid preparation & self-check投标编制与自审
    🪪
    Qualification & track-record screening资质与业绩智能筛查

    Verify bidder qualifications, licenses, references and financial data, flagging missing or mismatched items.自动核验资质、证照、业绩与财务数据，标记缺失与不符项。

    📚
    Similar case retrieval & benchmarking相似案例检索与对标

    Retrieve comparable past bids and evaluation outcomes to inform the current response.检索历史同类项目投标文件与评标结果，辅助当前应答。

    🔍
    Duplicate-check & compliance detection投标文件查重与合规性检测

    Detect cross-bidder similarity, abnormal consistency and format non-compliance to surface collusion or irregularity clues.检测投标文件雷同、异常一致性与格式不合规，识别围标串标线索。

    🔗
    Completeness & consistency validation应答完整性与一致性校验

    Verify every RFP/SoC item is answered and catch contradictions or vague wording (e.g. "TBD") that score as NC.逐条核对应答覆盖全部 RFP/SoC，检测前后矛盾与「TBD」等按 NC 计的模糊表述。

    Expected value预期价值More objective and complete review, compliance risks caught early, fewer gaps and contradictions.评审更客观全面、合规风险前置、减少漏项与矛盾。
    Implementation落地建议Data: qualification base, RFP/SoC, historical bid documents. Key points: text comparison + semantic retrieval + rule validation + anomaly detection.数据来源：资质库、RFP/SoC、历史投标文件；技术要点：文本比对 + 语义检索 + 规则校验 + 异常检测。
    5

    Evaluation & Award评标定标

    Phase阶段 · Scoring & decision评分与决策
    🧮
    Scoring assistance & anomaly detection评分辅助与异常识别

    Pre-score and aggregate bids against the rubric, flagging outlier judge scores or suspiciously uniform scoring.按评分办法自动预打分与汇总，识别偏离过大的评委分与异常一致分。

    📑
    Technical proposal extraction & comparison技术标要点抽取与对比

    Extract key technical points from each bidder's proposal and build a side-by-side comparison matrix.自动抽取各家技术方案要点，生成横向对比矩阵。

    🚩
    Deviation & risk clause flagging偏离与风险条款自动标注

    Auto-flag deviation clauses, non-compliant (NC) items and risky commitments across bid documents.自动标注投标文件中的偏离条款、NC 项与风险承诺。

    📄
    Auto-generate evaluation report评标报告自动生成

    Generate a draft evaluation report from scores and comparison results for reviewer sign-off.基于评分与对比结果自动生成评标报告初稿，供评委审签。

    Expected value预期价值Higher evaluation efficiency and fairness, traceable anomalies, standardized reports.评标效率与公正性提升、异常可追溯、报告更规范。
    Implementation落地建议Data: scoring rubric, bid documents, evaluation data. Key points: scoring rule engine + anomaly detection + LLM summarization.数据来源：评分办法、投标文件、评分数据；技术要点：打分规则引擎 + 异常检测 + LLM 摘要生成。
    6

    Contract Signing & Performance合同签订与履约

    Phase阶段 · Delivery & governance交付与治理
    ⚠️
    Contract clause risk warning合同条款风险预警

    Compare the signed contract against bid commitments and standard terms, flagging high-risk clauses, liability gaps and delivery risks.对照中标承诺与标准合同，识别高风险条款、责任缺口与履约风险。

    📅
    Delivery progress & milestone monitoring履约进度与里程碑监控

    Track milestones, deliverables and SLA attainment from project data, raising early warnings on delays.从项目数据自动跟踪里程碑、交付物与 SLA 达成情况，预警延期。

    🔄
    Change & claim identification变更与索赔智能识别

    Automatically identify scope changes, variation orders and claim leads, and archive them for auditability.自动识别范围变更、签证与索赔线索并归档，保证可追溯。

    🗂️
    Delivery data archiving & knowledge distillation履约数据归档与知识沉淀

    Archive delivery data and distill it into a reusable asset and case library that feeds the next bid.自动归档履约数据，沉淀为可复用资产库与案例库，反哺后续投标。

    Expected value预期价值Delivery risks surfaced early, changes traceable, knowledge assets reinvested into future bids.履约风险前置、变更可追溯、知识资产反哺后续投标。
    Implementation落地建议Data: contract text, project-management system, delivery data. Key points: contract NLP + rule engine + knowledge base + time-series analysis.数据来源：合同文本、项目管理系统、交付数据；技术要点：合同 NLP + 规则引擎 + 知识库 + 时序分析。