制造业市场背景
从21世纪开始，各类新兴技术不断发展，数字化、自动化、智能化技术蓬勃发展，企业、用户的需求越发精确，原有的大宗通用型设备制造越来越难以满足市场需求，聚焦实际需求场景的“小型”制造愈发成为制造业关注重点。 在聚焦核心场景的过程中，如何更好地服务于客户，更好更快地完成产品交付，控制研发生产成本，保持企业资源平衡成为企业管理的重中之重。 面相此类场景我们一般存在两种主要管理模型：
-
LTC模型：实际交付的不仅仅是产品，是面向场景实现、场景交付为主的完整方案交付时，企业聚焦方案的评估，方案变更调整的影响变化跟进，确保业务实时转化为项目可用资金，以达到长周期或复杂方案项目可交付的管理模式，不严格设定项目上限，追求收益成本同比增减，下面将主要围绕该方案模型展开；
-
OTD模型：在产品工艺过程相对稳定，有一定成型标准，或者研发定制设计过程可控的研发到生产模式下，企业更聚焦业务的协同，明确跟进各环节进度，控制制造放量，把控变更与进度风险时推荐使用此模型，本方案不涉及此模型；
什么是LTC
- Leads To Cash——“是从线索到现金的企业运营管理思想”，企业定义“从「接触客户」到「收到客户回款」的整个流程”
- 常规企业定义中LTC往往聚焦于线索、商机、立项、投标、签约，对后续的交付持续运营管理模型并没有很好的兼容，这也是本文提供企业管理改善的重点。
LTC流程完整框架
文本所描述的LTC整体场景相对庞大，会涉及较复杂的管理模式与团队定义，若中小型项目管理模式可裁剪后使用
LTC管理目标价值
| 💡价值A | 💡价值B | 💡价值C | 💡价值D |
|---|---|---|---|
| 全面场景跟进业务 | 概预核决四算机制 | 需求变动实时反应 | 跟进执行改善复盘 |
| 明确识别、记录客户需求背景 | 前期可单独进行费用预算构成申请 | 对客信息实时变化，需求调整责任清晰，及时报价调整预算 | 明确项目成员分工 |
| 方案入手实现，确保客户对可实现性和企业运营价值的认可 | 线索正式立项后明确概算准则要求 | 需求发生不分阶段，需求主线跟踪执行进展 | 明确项目关键步骤信息，各阶段可分别安排阶段负责人跟进 |
| 整体产品、技术、实施、服务流程管理一体化，全面管理各业务 | 正式签约，明确职责，内部澄清，概预转换 | 项目周期关联需求，各阶段需求精准统计，记录执行变动风险 | 形成项目复盘模型，逐渐改善方案、设计、研发、交付环节SOP提高企业整体效能 |
| 分段核算，最终确认，决算定版，项目复盘 |
企业面临管理痛点
| 😭痛点A | 😭痛点B | 😭痛点 | 😭痛点D |
|---|---|---|---|
| 项目复杂跟进失真 | 预算混沌最终亏损 | 需求增减周期紊乱 | 营收价值难以盖全 |
| 偏工程型或大型项目中客户的需求结构复杂，业务类型繁多，难以以一套完整体系管理 | 没有合理的拆解跟进预算，项目盈亏不明确 | 没有同客户制定长周期的交付定义，项目过程不明确 | 缺乏全面复盘模型，对项目实际成本影响较大的问题点不明确 |
| 变更影响多发，处理过程复杂难以跟进记录 | 前期交底内容失真，后续变动大项目交付出现混乱，难以控制成本 | 紧急需求任意插队，验收标准难以平衡 | 非标行为频发没有跟进管控机制，缺乏预警控制与小团队管理意识 |
| 关联方众多，协同成本高，信息同步困难 | 方案评估与预算构成无明确对应关系，单边预算问题严重 | 需求变更问题跟进执行不清晰，责任不明确 | 项目缺乏复盘机制，核心团队忙于一线交付 |
LTC实现设计思路
主要解决场景线路
全景的LTC业务链条相对庞大，视项目的不同级别与不同方案内容，会存在一定的过程内容存在裁剪等情况，以及企业会根据一些管理要求弱化环节中的一些控制逻辑，这些都需要根据企业实际背景进行细微的调整，基于此模板场景可实现的管理过程链路大致有以下几种——
-
LTC体系外事项：客户主档信息建立，填写客户/企业基本情况，补充企业关系人、关键用户信息。即可直接使用也是预留便于同其他业务系统打通接口。
-
完整流程线路：线索建立→线索日常跟进→线索阶段明确初步需求与初步解决方案→确认客户立项+内部正式立项→初版概算编制→投标准备标书制定→投标执行反馈结果→拟定合同→确认终版概算→合同签订→内部权责转移→项目周期拆分+项目预算分解→项目各阶段执行（产品研发+产品生产+技术方案支持+服务支持+产品采购→各阶段验收→各阶段核算→全阶段核算确认→最终决算匹配与财务汇报。
-
直接立项：已明确客户已立项已招标的情况下，跳过线索阶段直接新建合同项目开始执行，确认客户立项+内部正式立项→初版概算编制→......
-
内定中标线路：已明确确认中标，或项目无招标过程等场景，跳过投标相关步骤，视情况可保留投标过程节点便于记录相关文件内容
-
提前开工流程：面向战略项目，特殊项目情况，允许在合同确认前即开展项目阶段执行步骤，此时允许项目经理提前拆分项目首个周期，安排一些先行事项，例如部分试产研发，提前服务支持等。
-
多段批量生产：项目执行计划排期后，可以开启多批生产交付流程，以满足多产品试产生产要求，可支持长周期项目按月度、季度、年度生产的场景。 项目管理神器，点击申请，立即体验飞书项目→
核心痛点解决方案
复杂项目拆解执行**：流程化繁为简**，落实阶段权责，整合业务逻辑
在复杂的工程方案交接过程中，往往项目面临多种需求内容、多方协同协作、多段分布上线等业务逻辑，如何来准确的描述与定义大项目下复杂场景的管理标准与管理预期会显得尤为重要，要能准确地划分阶段职责，分解定义不同业务，协同关键事项，保持项目一体可读。 划分职责的建议：根据企业各团队管理标准与作业准则为基础，将项目拆解为各个过程阶段，匹配对应的主要负责角色，可参考本文模型——
线索阶段——市场、业务
- 由于事项尚未明确，还处于客户建联或老客户新需求初步了解的时期，以销售职能团队跟进为主。针对高优客户场景，可申请解决方案（售前）支持协作，主责不变化；
- 此阶段一般只允许申请前置营销相关费用。
立项阶段——市场、业务、解决方案
-
此阶段是实质上的企业投入开始，也是明确项目真正规模、确认客户实际意向到真正出具企业概算的时机。
-
对于线索转化为真正商机立项的原则，可企业自行扩展，往往会有一下几种因素：
-
客户内部已正式立项；
-
客户已有相关项目事务启动，例如国标通过、商业往来达成；
-
跟进了解实际情况后，业务主管与市场判断需重点投入跟进。
-
- 正式立项后原则上解决方案会正式介入，视项目特殊性（提前开工或客户要求）可能会提前安排项目经理进入项目团队跟进。
- 同时各核心业务团队进行概算拆解，明确前期各需求转化拆分为可执行需求：
-
在需求的定义上，本方案将直接产品交付、功能方案交付部分定义为“产品/技术需求”的模型相对复杂，过程更长链，一般会结合企业内部的具体产品或方案资产进行确认；
-
将施工实施、部署协作等轻量化事项定义为“客户服务需求”，逻辑上此类需求偏向具体实施工作量，相对交付定义更聚焦到客户实际要求，会结合企业可提供的支持服务进行报价与确认。
-
- 当概算初稿完成，内部评审通过后，视为立项工作结束，概算收入明细构成亦是企业项目的初版报价体系，进一步进行投标、签约活动。
投标阶段——业务、市场、解决方案
-
从投标阶段开始实质上主责从市场转移到业务侧，具体的营销业务人员需要全程跟进项目具体执行情况，确认范围与标注，同客户进行长期联系，确保项目主要边界、合同边界、项目款项、关键风险等事项。
-
各行业内投标细则不同，本文不做很明确投标标准指引。
-
实际投标过程中面向投标准备视标准情况内部各类方案标书会存在企业定制和客户定制两种主要模式，主要体现在标书文件的形式内容中，文本暂不涉及。
- 其中方案部分的团队分属模板流程中定义是五个主要方向分别执行，整体方案制定统一参考，形成完整标书的模式，可根据企业需要完善调整此阶段实际过程。
- 常规投标结论根据会在投标执行后确认，针对未中标与弃标，原则上流程关闭不再跟进；流标与停标时业务主管根据实际情况判断项目执行可行性与下一步动作。
签约阶段——业务、市场、解决方案
-
此部分是企业同客户正式确认双方法律合作效益的关键阶段，后续的合同变更、项目范围变更等事项都会依据此阶段签署的合同进行变更与调整。
-
在进行合同报价最终定稿时会要求关键负责人最终明确报价、成本的概算拆解情况，作为项目后续风险评估的一个重要依据，作为项目最终利润评估的起点。
- 当客户签约意向基本明确后，部分长周期采购活动可以先行，此类情况往往是制作周期较长或批量较高单成本较低以及可多项目复用类的物料允许执行；由采购主管进行判定。
项目执行阶段——项目经理、业务团队
-
项目执行阶段也是正式从前端业务售前转向后端项目交付团队的权责切换点，核心项目产出执行都是项目经理为主进行推进。
-
实际执行中，此阶段由于项目的规模大小与项目投入安排，客户时间周期等因素可能是所有阶段中时间最长部分。
-
本位设计的项目周期较长会存在拆分阶段的场景，亦允许不同项目周期有不同的子项目经理负责。
- 项目经理要根据合同拆解项目周期，明确项目具体计划，并将前期需求对齐到具体项目周期中，主要是以需求的启动周期为主：
-
本文是基于旗舰版构建模板，无法实现WBS的自定义拆解，故实施执行是一个相对标准的流程
-
对于产品需求的执行，支持项目经理与生管、产品经理对齐，安排相关试产、量产（子工作项流程）
-
 |  |
|---|
- 同步根据终版执行情况完善或继续分解项目，此时系统会完成概算到预算的版本切换，项目经理主控预算阶段编制事项。
- 若拆分预算实际是需求补充，不涉及收入分解可独立完成，若涉及收入分解变化需触发合同变更，业务参与落实客户变更进展。
项目核算、决算阶段——项目经理、财务
-
此部分作为项目的尾声，整体核算决算需要项目经理明确执行结论，项目验收情况，协同业务确认回款执行情况；
-
同时财务基于业务信息结合各类核算控制系统（此处模型预计同ERP、OA等存在明细费用成本核算的系统集成获取对应核算数据）确认项目最终执行情况，落实项目实际营收、费用、利润情况；
-
项目经理、财务等高权限人员可实时查看项目预算进展情况。
复盘阶段——项目经理、各业务主管
-
在项目结项前进行文档、问题、历史风险、执行情况、团队评价等项目复盘过程；
-
此阶段实质上与项目本身无直接关系，用于企业进行长期流程、制度改进与项目评价奖金发放等场景。
[CTA:百亿Token限时放送，抢先体验AI能力→](https://www.feishu.cn/landing/feishu_future_base_ai_bonus) ### 管理需求实现阶段**：控制项目成本**，分段落地部署，减少交付混乱
往往在中长期项目交付过程中，客户需求相对庞大，很多项目不做明确的实现阶段部署或实际执行中没有合理的跟进体系流程与管理系统，那么可以考虑通过飞书项目管理不同阶段的需求范围与交付标准。
项目拆解定义
- 明确各阶段核心目标制定整体项目周期计划，往往概念拆分的信息在前期解决方案与项目经理会提前沟通给整体项目进行大的规划与安排；
明确需求阶段
- 根据需求场景与交付可行性定义需求大致阶段划分，允许项目经理或相关主管进行需求时间阶段的调整，建议与客户建联保持双方标准一致。
分段定义验收标准
- 各需求验收标准在需求跟进过程中明确，控制大的边界不超出合同条款约定范畴。
-
产品技术需求往往其验收标准更加复杂。
-
- 服务需求的定义常规根据企业服务标准提供，实际中服务标准更加人性化，有时难以形成准确的标准，此时也建议实时同步客户的感受与服务过程意见。
最终回归阶段验收
- 各阶段验收标准往往作为项目回款的标志性里程碑阶段（非强制，模板中不设限）。
营收价值评估，完善项目管理**：项目风险识别**，实时跟进信息，整体项目复盘
无论我们如何进行项目的预估预判、流程优化、执行监控，都难免在项目过程中出现各类问题，并且随着市场变化很多模式要求都要不断改进，那么定期收集关键信息，形成指标牵引，驱动管理优化，形成复盘机制是项目管理体系外但又密不可分的关键一环。
项目风险溯源跟进
- 随着项目复杂度的提升，风险的产生场景，产生原因，管理措施都在不断变化，我们首先需要能够清晰有源地记录风险的发生与原因再进行持续跟进改善。
- 模板案例中基于合同、交付阶段、产品/技术需求、服务需求、生产交付过程都可进行风险提起，并且向上一级结构汇集，整体项目可总览。
 |  |
|---|
从线索开始持续跟进项目进展
- 项目链路越长，项目信息也会随时间增长越多，导致信息沟通和获取不及时的情况，那么可以考虑将项目跟进过程形成我们作业的制度，对于营销体系可能会更强制的要求形成周报或更明细级别的跟进记录模型。
- 本文模板案例中，支持线索开始的项目跟进记录，会自动关联到后续的合同项目中，允许在项目中持续进行跟进，方便各类项目成员维护和明确项目与客户的跟进过程，提供项目分析用资产。
设定项目复盘评分模型，核心参与成员评估留痕
-
最直接也是最高效的手段，就是根据我们的不同管理要素进行打分评估，飞书项目支持进行分级分类的匿名、实名投票打分。
-
本案例流程中未在合同或交付阶段中扩展复盘评分的模型，下图是示例参考。
 |  |
|---|
建立项目相关直接数据报表、图表等度量数据，便于复盘整体考量
此外，根据项目执行的偏差延期、投入评估、耗用评估进行单项目间的对比，整体资源使用情况的分析，也是企业有效利用数据资产改善企业管理的有效途径。
- 研发情况统计、生产情况统计等都是关联相关数据直接统计（具体模型可以随时自定义扩展，例如查看不同类型的研发统计等）。
- 各类型任务资源投入统计与平均值观察。
-
企业可综合设计对项目、对产品、对生产交付等不同模型多种多样的复盘机制，数据标准，便于优化项目管理达成企业流程的不断进化，促进大家高效运转提升价值！
