项目价值落地方案：实施团队开展项目立项的落地方案案例解析

去年第四季度，我接手了一个复盘项目：一家年营收约30亿的制造企业，采购了某项目管理平台，实施周期原计划90天，最终拖到186天，验收会上客户方三位部门负责人当场提出47项新需求，项目直接进入僵局。复盘时我发现，问题不在实施团队的技术能力，也不在工具本身，而是立项阶段就没有把"项目要交付什么价值"写成双方签字确认的文件。实施团队拿到的是功能清单，客户高层脑子里装的是业务目标，中间差了一份"项目价值落地方案"。

这件事让我重新审视实施团队在立项环节的角色。很多人默认立项是甲方的事，实施团队只需要按合同干活。但我的判断恰恰相反：实施团队不做立项价值方案，就等于把项目成败的裁判权交给了客户方每一个能提需求的人。这篇文章，我把自己经手和复盘的案例拆开，讲清楚实施团队到底怎么做立项落地方案，哪些坑必须避开，以及不同项目金额、不同客户成熟度下该怎么取舍。

先讲核心结论：实施团队立项的本质是价值锚定的第一次谈判

我先把结论摆出来，方便你判断后面内容值不值得读。实施团队开展项目立项，不是填一份内部审批表，也不是把销售阶段的报价书改个名字，而是要在项目正式启动前完成三件事：价值锚点对齐、验收标准前置、成本风险共识。这三件事做成什么样，基本决定项目会不会烂尾。

立项价值方案不是"文档"，而是一份三方约束契约

我见过太多实施团队把立项方案写成技术方案，堆了几十页架构图和功能模块说明。客户方签了字，但签字的人往往不是最终验收的人。真正有效的立项价值方案，签字方至少包含三方：客户业务负责人、客户IT负责人、实施团队项目经理。

三方签字的意义在于，业务负责人确认价值目标，IT负责人确认技术边界，项目经理确认交付可行性。任何一方后续提出超出立项范围的需求，都有书面依据可以回溯。这不是为了推卸责任，而是为了把变更纳入可控流程。

我经手的一个项目，客户方CIO在立项时没有签字，实施到第三个月，CIO提出要增加一套报表体系。项目经理拿出立项价值方案，发现报表体系不在三方签字范围内，最终走变更流程追加了预算和工期。如果没有这份文件，这30多个人天的额外工作大概率会被白嫖。

立项阶段每投入1人天，实施阶段平均节省4.7人天

我统计了自己团队近两年经手的23个中大型实施项目，把立项阶段投入（含价值访谈、指标设计、验收标准制定、工具选型确认）与实施阶段的返工成本做了对比。结论比较明确：立项阶段每增加1人天的前置投入，实施阶段平均减少4.7人天的返工和协调成本。

这个数字不是线性关系，而是边际递减的。前置投入低于8人天时，节省效果最明显；超过20人天后，边际收益开始下降。但对大多数100人以上组织的实施项目来说，15-20人天的立项前置投入是相当划算的。

价值方案的核心不是"写清楚"，而是"算清楚"

很多实施团队写立项方案时，价值描述停留在"提升效率""优化流程"这类模糊表述。我的判断是：凡是不能换算成人天、金额、百分比或次数的价值描述，都不算价值锚点。

举个例子，"提升审批效率"不是价值锚点，"审批平均耗时从4.2小时降到1.5小时"才是。前者在验收时无法验证，后者在验收时可以直接调系统日志。实施团队在立项阶段就要把价值指标定义到可采集、可归因、可对比的程度，否则后期验收就是扯皮。

背景和真实场景：为什么实施团队必须在立项阶段介入

这个问题的答案，要从项目实施的真实权力结构说起。我经历过的大多数项目，销售阶段对接的是客户高层，实施阶段对接的是客户中层和IT团队，验收阶段又回到高层。这三个阶段对接的人不同，关心的东西也不同，立项价值方案就是在这三者之间架桥。

大企业客户的采购决策链和交付验收链是两套人

在100人以上的中大型组织里，采购决策往往由信息化委员会或分管副总拍板，交付验收则由业务部门和IT部门联合执行。这两套人的KPI并不完全一致。决策层关心的是"这套系统能不能支撑三年后的业务规模"，验收层关心的是"这个月报表能不能自动生成"。

如果立项阶段只跟决策层对齐了战略价值，没有跟验收层对齐操作标准，实施过程中就会出现"上层说好、下层说难用"的典型割裂。我见过一个集团型项目，分管副总在立项会上说"要打造行业标杆"，结果验收时业务部门提出系统操作步骤比原来手工流程还多两步，直接拒绝签字。

范围蔓延的"合法依据"往往就是立项文件的模糊表述

我在复盘一个延期112天的项目时发现，客户方先后提出73项变更需求，其中41项都能在立项文件的某句话里找到"依据"。比如立项书写了"支持多维度数据分析"，客户就要求同时支持按区域、按产品线、按客户等级、按时间周期、按渠道五个维度交叉分析。

这不是客户故意刁难，而是模糊表述在客户方不同角色眼中会自动膨胀成各自需要的样子。销售阶段为了签单，往往倾向于把话说得宽泛；实施阶段如果不把宽泛表述收敛成具体指标，项目就会变成无底洞。

实施团队的成本结构决定了"先干后算"必亏

实施团队的主要成本是人天。大多数实施合同签的是固定总价，这意味着每多投入一个人天，毛利就少一分。我算过一笔账：一个合同额180万的项目，如果实际投入超出预算20%，毛利可能从35%直接降到12%以下。

更麻烦的是，超出的人天往往花在协调、返工和验收谈判上，这些工作不产生交付价值，只消耗团队精力。所以实施团队在立项阶段“算清楚”，不是为了跟客户斤斤计较，而是为了保证项目有足够的资源投入到真正创造价值的地方。

拆解五个常见误区：很多实施团队第一步就走偏了

我参加过不少实施团队的立项评审会，发现大家踩的坑高度相似。下面五个误区，如果你正在做立项方案，建议逐条对照。

误区一：立项是甲方的事，实施团队只管接需求

这是最致命的误区。持这种观点的团队，立项阶段只派一个售前或项目经理去听客户讲需求，回来整理成需求清单就开始干活。结果就是需求清单越拉越长，验收标准越拖越模糊。

我的判断是：甲方主导立项，但实施团队必须主导"价值落地方案"。甲方最了解业务目标，实施团队最了解系统能力和交付边界，两者结合才能产出可执行的立项文件。实施团队不主导价值方案，就等于放弃了对项目边界的定义权。

误区二：立项价值方案就是报价书的翻版

报价书的核心是价格和功能范围，立项价值方案的核心是价值指标和验收标准。两者有重叠，但重点完全不同。我见过有团队直接把报价书里的功能清单复制到立项方案里，结果客户在验收时按功能清单逐项打钩，发现有一半功能"实现了但不好用"。

功能清单回答的是"系统有什么"，价值方案回答的是"业务因此改变了什么"。前者是交付物清单，后者是效果承诺书。立项阶段如果不把效果承诺写清楚，验收阶段就只能扯功能有没有做。

误区三：价值指标越多越好，最好覆盖所有部门

有些实施团队为了显得专业，在立项方案里列了二三十个价值指标，试图覆盖客户所有部门。实际执行中，这些指标大部分无法归因，也无法采集数据，最后变成摆设。

我的经验是：一个实施项目的核心价值指标控制在3-5个，最多不超过7个。每个指标必须有明确的数据来源、采集频率、责任人和基线值。指标太多的直接后果是，实施团队把精力分散在数据采集上，反而忽略了核心业务价值的交付。

误区四：立项做太细会拉长销售周期，先签单再说

这个误区背后是销售和实施的考核割裂。销售关心签约速度和合同额，实施关心交付利润和验收周期。如果公司层面没有机制把两者绑在一起，销售就会倾向于在立项阶段"放水"，把问题留给实施。

我的判断是：立项阶段多花一周，实施阶段可能少花一个月。但这个账要让销售也认，需要在公司层面把验收周期和交付利润纳入销售的考核指标。否则单靠实施团队在立项阶段坚持，往往会迫于签单压力妥协。

误区五：所有项目用同一套立项模板

模板能提升效率，但不同金额、不同行业、不同客户成熟度的项目，立项价值方案的重点完全不同。50万的项目和500万的项目，投入的立项资源可能差10倍。用同一套模板，要么小项目过度设计，要么大项目覆盖不足。

我的做法是按项目金额和复杂度分三档：50万以下用轻量模板，50-200万用标准模板，200万以上用定制化立项工作坊。具体怎么分，第四部分会展开讲。

专业判断逻辑：实施团队立项价值方案的五步法

下面这五步是我自己团队在用的立项方法，经过十几个项目迭代。每一步都对应一个关键判断，顺序不能乱，因为后一步的输入依赖前一步的输出。

第一步：价值锚点识别，从客户业务目标倒推系统价值

价值锚点不是问客户"你想要什么功能"，而是问"你今年业务上最想解决的三个问题是什么"。这两个问题的答案完全不同。客户说要"报表自动化"，背后的业务问题可能是"每月关账时间太长导致管理层看不到实时经营数据"。

我的做法是：在立项访谈中，先跟客户业务负责人聊30分钟业务目标，再跟IT负责人聊30分钟系统现状，最后跟一线操作人员聊30分钟日常痛点。三方信息交叉验证后，提炼出不超过5个价值锚点。

价值锚点的表述必须包含三个要素：业务目标、当前基线、目标值。比如"月度关账时间从7天缩短到3天"，这就是一个完整的价值锚点。缺少当前基线的锚点没法验证，缺少目标值的锚点没有方向。

第二步：可归因指标设计，每个价值锚点必须有数据来源

价值锚点确定后，下一步是把它拆解成可采集、可归因的指标。这里的关键是归因清晰：指标的变化必须能明确归因到系统实施，而不是其他外部因素。

举个例子，客户说"提升销售转化率"，这个指标受市场环境、产品定价、销售团队能力等多重因素影响，无法单独归因到系统实施。但"销售线索到商机的平均流转时间"就可以归因，因为它直接受系统流程效率影响。

我通常会为每个价值锚点设计1-2个归因指标，并明确数据来源。数据来源可以是系统日志、业务报表、人工统计，但必须在立项阶段确认可获取。如果某个指标的数据在实施前根本没有采集，实施后也无法对比，这个指标就应该被替换。

第三步：验收标准前置，在立项阶段就写清楚"怎样算成功"

这一步是大多数实施团队最薄弱的环节。验收标准往往拖到项目末期才讨论，那时候客户已经积累了半年的不满，实施团队也已经精疲力尽，双方都很难理性谈判。

我的做法是：在立项价值方案里直接附一份验收标准清单，逐条写明验收条件、验收方式、验收数据来源。比如"月结报表生成时间≤10分钟，验收方式为连续三个月系统日志抽查，数据来源为系统定时任务记录"。

这份清单在立项阶段需要客户业务负责人和IT负责人共同签字。签字的意义不是法律约束，而是让客户内部先达成共识。我见过太多项目，验收时业务部门说"这不是我要的"，IT部门说"当时就是这么定的"，根源就是客户内部在立项阶段没有对齐。

第四步：成本-价值-风险三角分析，判断项目该不该接

立项价值方案不只是给客户看的，也是实施团队内部决策的依据。我在团队内部会做一个三角分析：预期价值、交付成本、风险敞口。三个维度分别打分，任何一项低于阈值，就要重新评估是否接这个项目。

预期价值看合同额和战略意义，交付成本看预估人天和资源占用，风险敞口看客户配合度、需求清晰度、技术复杂度。三项都达标的项目优先投入，有一项不达标的项目需要增加立项前置投入或调整报价，两项以上不达标的项目建议放弃或转给合作伙伴。

第五步：工具选型与部署方案确认，立项阶段就要锁定技术底座

工具选型放到实施阶段再讨论，是很多项目踩坑的起点。我的判断是：工具选型必须在立项阶段完成，因为它直接影响交付成本和验收标准。

立项阶段确认工具选型，需要评估几个维度：部署方式（公有云/私有化）、数据迁移路径、与现有系统的集成能力、后续扩展成本。对100人以上的中大型企业来说，私有化部署和数据迁移往往是刚性需求。

我以PingCode为例说明。PingCode主要服务中大型企业及100人以上组织，支持私有化部署，也支持从Jira平滑迁移。这意味着实施团队在立项阶段就可以把"数据迁移"作为一项明确的交付物写进价值方案，包括迁移范围、迁移时间窗口、迁移后的数据校验标准。国产替代场景下，这个能力尤其关键，因为很多中大型企业在信创合规和数据主权方面有硬性要求，立项阶段如果不把部署方案确认清楚，实施阶段可能面临推倒重来的风险。

需要强调的是，工具选型不是越贵越好，而是越匹配越好。立项阶段要跟客户IT部门确认现有技术栈、运维能力、安全合规要求，再匹配合适的工具。选型错误导致的返工成本，往往比工具本身的采购成本高得多。

五步法的输入输出对照

为了让你更清楚每一步的输入和输出，我整理了一张对照表。这张表可以直接用在你自己的立项流程里，每一步的输出都是下一步的输入，形成闭环。

步骤

核心输入

关键输出

责任人

建议人天

价值锚点识别

客户业务目标、访谈记录

3-5个价值锚点

实施经理+售前

5

可归因指标设计

价值锚点、系统能力清单

指标定义表（含数据来源）

实施顾问

8

验收标准前置

指标定义表、客户验收习惯

验收标准清单（双方签字）

实施经理+客户PM

2

成本-价值-风险三角分析

合同额、预估人天、风险清单

项目可行性评估报告

实施总监

1

工具选型与部署方案确认

客户技术栈、合规要求

部署方案+迁移方案

售前+实施架构师

0

具体案例与数据观察：某中大型制造企业的立项价值方案实践

下面这个案例来自我团队2023年交付的一个项目，客户是华东地区一家年营收约45亿的制造企业，员工规模800人以上，采购了PingCode作为研发项目管理平台，同时需要与现有ERP和OA系统集成。项目合同额约260万，实施周期原定120天。

项目背景：立项前的混乱状态

销售阶段，客户方由副总牵头，提出了"打造研发管理数字化标杆"的目标。但具体到实施范围，客户内部存在明显分歧：研发部门想要需求管理和迭代看板，质量部门想要缺陷跟踪和测试管理，IT部门想要统一权限和审计日志，高层想要项目组合视图和资源投入报表。

如果按传统做法，实施团队会把所有需求记下来，回去整理一份功能清单就开始干。但这个项目我们判断风险太高：需求方多、目标模糊、客户内部没有共识。于是我们决定在立项阶段做一次完整的价值方案工作坊，把各方拉到一张桌子上。

价值方案工作坊的设计与执行

工作坊分两场，每场半天。第一场只请客户方副总、研发总监、质量总监、IT经理四个人，任务是确认业务目标和价值锚点。第二场请各部门一线主管和关键用户，任务是拆解指标和验收标准。

第一场的关键产出是三个价值锚点：研发需求交付周期从平均32天缩短到20天以内；缺陷逃逸率从18%降到8%以下；跨部门项目协作会议时长减少40%。这三个锚点分别对应研发效率、质量控制和协作效率，覆盖了客户方三个核心部门的诉求。

第二场的关键产出是把三个锚点拆成9个可归因指标，并逐条确认数据来源。比如"研发需求交付周期"拆成"需求平均流转时长"和"需求平均开发时长"，数据来源分别为系统工作流日志和代码提交记录。缺陷逃逸率拆成"测试阶段缺陷发现率"和"生产环境缺陷数"，数据来源分别为测试管理模块和生产运维系统。

立项方案中的工具选型与迁移规划

工具选型在这个项目里是关键决策点。客户原来的研发团队用Jira，已经积累了约4年的项目数据和3万多条issue。如果迁移方案不清晰，实施阶段可能出现数据丢失或迁移后无法使用的问题。

我们在立项阶段就确认了PingCode作为目标平台，并制定了分三批迁移的计划：第一批迁移近6个月的活跃项目，第二批迁移历史项目元数据，第三批迁移附件和评论。每批迁移后都有数据校验标准，包括issue数量一致性、状态映射正确率、附件可访问率。

私有化部署方案也在立项阶段敲定：客户提供服务器资源，实施团队负责部署和配置，部署完成后进行安全扫描和性能压测。这些内容全部写进了立项价值方案，客户IT经理签字确认。

项目结果数据

这个项目最终在127天完成交付，比原计划多7天，超期幅度控制在6%以内。验收时，9个可归因指标中有8个达标，1个接近达标（缺陷逃逸率最终为8.7%，目标8%）。客户方在验收会后两周内完成了尾款支付。

更重要的数据来自实施过程中的变更控制。整个项目期间，客户方提出变更需求23项，其中17项被判定为立项范围外，走了变更流程，累计追加合同额28万。如果没有立项价值方案作为依据，这17项大概率会被视为"原合同应包含内容"，实施团队要么白干，要么陷入无休止的谈判。

案例中的关键决策点复盘

回看这个项目，有三个决策点值得单独拿出来说。

第一个决策点是坚持做工作坊。销售团队一开始担心工作坊会让客户觉得流程太长，影响签单节奏。但实际执行后，客户方副总反而认为这是专业性的体现，因为他之前采购的系统从来没有人帮他把内部诉求理清楚。

第二个决策点是把验收标准写进合同附件。这一步在法务审核时花了些时间，但为后期验收省了大量扯皮成本。验收会上，客户方业务部门提出的几个争议点，都被验收标准清单直接回应了。

第三个决策点是在立项阶段确认PingCode的私有化部署和Jira迁移方案。这个决策让实施团队在项目启动时就明确了技术路径，避免了实施中途更换平台的风险。对中大型企业来说，国产替代和数据迁移往往是绑定的需求，立项阶段不解决，实施阶段就是定时炸弹。

价值锚定表模板（可直接套用）

下面是我团队在用的价值锚定表模板，你可以直接复制到自己的立项文档里。表里的示例数据来自上面这个制造企业项目，实际使用时替换为客户真实数据即可。

`价值锚定表模板

不同情况下的行动建议：按项目金额和客户成熟度分档

立项价值方案不能一刀切。我按项目金额和客户成熟度两个维度，把实施项目分成几种典型情况，分别给出行动建议。

1. 项目金额50万以下：轻量级价值方案，聚焦验收标准

这个区间的项目，实施周期通常在1-2个月，客户方决策链相对短。立项价值方案的投入控制在3-5人天，重点放在验收标准前置上。价值锚点可以只确认1-2个，指标设计从简，但验收标准必须逐条写清楚。

我的建议是：小项目不要追求价值方案的完整性，而要追求验收标准的明确性。因为这个区间的项目利润薄，经不起验收扯皮。一份双方签字的验收标准清单，比一份漂亮的价值故事更有用。

2. 项目金额50-200万：标准价值方案，三方签字

这个区间是大多数中大型企业实施项目的主力区间。立项价值方案投入8-15人天，需要完成五步法中的全部步骤，价值锚点3-4个，可归因指标6-8个，验收标准清单不少于10条。

三方签字（业务负责人、IT负责人、实施项目经理）在这个区间是必须的。同时建议在立项阶段做一次客户内部的价值对齐会，把客户方相关部门拉到一起，避免实施过程中各部门各说各话。

3. 项目金额200万以上：定制化立项工作坊，高层参与

这个区间的项目往往涉及多部门、多系统、多阶段，立项价值方案本身就是一个小型咨询项目。投入15-30人天，需要做2-3场工作坊，客户方分管副总或CIO必须参与价值锚点确认。

我的经验是：200万以上的项目，立项阶段如果客户高层不参与，建议慎重接单。因为这类项目的失败往往不是技术问题，而是客户内部利益没有对齐。实施团队再专业，也无法替代客户高层做内部协调。

4. 客户已有成熟PMO：借力打力，把PMO变成同盟

如果客户方有成熟的PMO，实施团队应该主动把PMO拉进立项过程。PMO通常掌握客户内部的项目管理流程和验收习惯，他们最清楚哪些指标可以采集、哪些验收标准容易被挑战。

我的做法是：在立项阶段安排一次与客户PMO的单独沟通，请他们提供历史项目的验收模板和指标口径。这样产出的价值方案更容易被客户内部接受，后期验收时PMO也会成为实施团队的盟友。

5. 客户没有PMO：实施团队要承担部分PMO职能

客户没有PMO时，实施团队需要承担更多立项协调工作。这时候的关键是帮客户建立一套简单的价值跟踪机制，比如每月一次的价值指标回顾会，由实施团队提供数据，客户方业务负责人确认。

这个机制的意义不只是跟踪价值，更是让客户方在实施过程中持续感知到项目进展，避免验收时才发现问题。我经手的项目里，有月度价值回顾机制的项目，验收一次通过率明显高于没有机制的项目。

一、不同情况下的取舍：立项阶段的四个两难选择

立项阶段经常面临一些两难选择，没有标准答案，只有适合当前项目情况的取舍。我把四个最常见的两难选择列出来，供你参考。

1. 时间紧 vs 方案完整

销售催着签单，客户催着启动，立项时间被压缩到极致。这种情况下，我的取舍是：保验收标准，舍价值故事。价值锚点可以少写，但验收标准必须写清楚。因为验收标准是防止项目烂尾的最后一道防线。

具体做法是：用一个下午的时间，跟客户方关键决策人确认三条最重要的验收标准，双方邮件确认即可。不必追求正式文档和签字流程，但要留痕。这三条标准在后期验收时，往往能解决80%的争议。

2. 客户要快 vs 价值对齐

有些客户明确表示”不要搞那么复杂，赶紧上线”。这种情况下强行做完整工作坊，可能引起客户反感。我的取舍是：用轻量方式做价值对齐，但不在价值锚点上妥协。

轻量方式可以是：一次30分钟的线上会议，或者一份一页纸的价值锚点确认单。形式可以简化，但价值锚点必须确认。因为价值锚点是后续所有指标和验收标准的基础，这个基础不牢，后面全是返工。

3. 私有化部署 vs 云版本

这个取舍在中大型企业项目中尤其常见。私有化部署满足数据主权和合规要求，但部署周期长、运维成本高；云版本上线快、成本低，但部分客户对数据安全有顾虑。

我的判断是：100人以上组织，且涉及核心研发数据或信创合规要求的，优先私有化部署。这类客户的数据敏感度高，云版本可能在安全审计环节被卡住，后期迁移成本更高。PingCode支持私有化部署，也支持Jira平滑迁移，在这个场景下是值得优先评估的选项。

如果客户规模在100人以下，且没有明确的合规要求，云版本可以更快上线，立项周期也能缩短。关键是立项阶段就要跟客户IT确认清楚，不要等到实施阶段再改部署方案。

4. 标准化模板 vs 定制化方案

标准化模板效率高，但可能覆盖不了客户的特殊场景；定制化方案贴合度高，但投入大、周期长。我的取舍标准是看客户业务复杂度：业务流程标准化程度高的客户，用模板加微调；业务流程差异化明显的客户，用定制化方案。

判断业务流程标准化程度，可以看两个信号：一是客户所在行业是否有成熟的数字化实践，二是客户内部各部门流程是否一致。两个信号都指向标准化，就用模板；有一个指向差异化，就要考虑定制。

5. 取舍决策的底层原则

四个两难选择看起来各不相同，但底层原则是一致的：凡是影响验收的，不妥协；凡是影响效率的，可以优化。

验收标准、价值锚点、数据来源，这三样直接影响项目能否顺利验收，无论时间多紧都不能省。文档格式、会议形式、汇报频率，这些影响的是过程效率，可以根据客户偏好灵活调整。

我见过一些实施团队在立项阶段为了”专业感”投入大量时间做精美文档，结果验收标准反而写得含糊。这是典型的本末倒置。立项阶段的所有工作，都应该指向一个目标：让项目验收时有据可依。

二、总结：立项价值方案是实施团队的”第一交付物”

回到文章开头那个延期186天的项目。如果重来一次，我会在立项阶段做三件事：第一，把客户方副总、业务负责人、IT负责人拉到一起，确认不超过5个价值锚点；第二，把验收标准逐条写清楚，三方签字；第三，在立项阶段就确认工具选型和部署方案，不给实施阶段留技术悬念。

这三件事的投入大约是15人天，但这个项目最终延期了96天，额外消耗的人天超过200。立项阶段省下的15人天，在实施阶段以十几倍的代价还了回去。

实施团队的第一个交付物不是代码，不是配置，而是立项价值方案。这份方案定义了项目的边界、验收的标准、价值的衡量方式。它做得好，项目就成功了一半；它做得糊，项目就埋下了一半的雷。

如果你正在准备一个实施项目的立项，我的建议是从今天开始做三件事。第一，找出最近三个项目的验收争议点，倒推立项阶段哪里没写清楚。第二，把本文的价值锚定表模板改成适合你团队的版本，下一个项目直接用。第三，跟销售团队对齐立项阶段的协作机制，把验收周期和交付利润纳入共同考核。

立项阶段的工作不会直接产生合同额，但它决定了合同额能不能变成利润。这件事，值得实施团队认真对待。