为什么周期长
轻量、中量、重量项目混在一起卖;签约后才发现服务器、网络、国产化、设备型号、接口和甲方责任问题。
围绕赵野刚提出的三件事:为什么交付周期长、哪些经验要沉淀复用、报价前必须确认什么。目标是把 6 月规划、交付策略、控标参数和售前工具合成一套周会可评审的管理动作。
轻量、中量、重量项目混在一起卖;签约后才发现服务器、网络、国产化、设备型号、接口和甲方责任问题。
沉淀企业/机关标准包、设备白名单、控标参数库、售前轻量工具、甲方责任矩阵和交付资产包。
P0 门禁未过,不给确定报价、确定周期、确定交付承诺;只能写假设、风险和可选项。
| 问题 | 周会回答 | 需要拍板的动作 |
|---|---|---|
| 为什么交付周期长? | 轻量、中量、重量项目混在一起卖;现场服务器、网络、浏览器、国产化、证书、设备型号、接口、供应商责任和甲方协同责任没有在报价前确认。 | 建立项目分层和报价前门禁。重型项目必须先冻结需求、环境、接口、设备和验收。 |
| 哪些经验要沉淀复用? | 把金斯瑞、国信、江西 206、重庆环卫、控标参数库和营养售前工具中反复出现的经验沉淀为可复用资产。 | 项目结束必须留下截图、手册、视频、设备联调记录、验收清单、问题闭环和可复用参数。 |
| 报价前必须确认什么? | 客户场景、餐线点位、支付/补贴/对账规则、服务器网络、数据库国产化、硬件型号、接口、甲方责任人、验收口径、不可做事项和额外报价项。 | 报价前形成一张门禁表。P0 缺口未闭环时,报价只能写假设和风险。 |
| 根因 | 典型表现 | 管理动作 |
|---|---|---|
| 项目没有分层 | 轻量演示、中量配置、重型软硬件集成都按同一种方式报价。 | 定义轻量 / 中量 / 重量项目的报价速度、方案深度和审批门槛。 |
| 标准包不足 | 销售按客户临时需求组织方案,产品和交付难以复用。 | 企业 / 机关标准包作为第一突破线,形成固定配置和可删减模块。 |
| 现场环境后置 | 服务器、内外网、浏览器、证书、国产化、数据库到交付阶段暴露。 | 报价前完成现场环境确认表,未确认项进入风险假设。 |
| 设备与接口边界不清 | 售卖柜、称重台、一体机、电子菜牌、摄像头等依赖供应商和联调条件。 | 建立设备白名单,要求型号、协议/SDK、规格书、联调记录和售后边界。 |
| 甲方协同责任不清 | 网络、安全、财务、设备、供应商、验收分别找谁不清楚。 | 报价前建立甲方责任矩阵,写入会议纪要或合同附件。 |
| 验收证据不标准 | 截图、手册、视频、问题闭环和客户确认分散。 | 每个项目形成交付资产包,作为下一个项目的售前和交付输入。 |
定位6 月优先突破线。先把当前最接近成交和复制的能力组合成标准报价边界,不追求一次覆盖所有智慧食堂想象。
| 标准模块 | 标准内容 | 报价边界 |
|---|---|---|
| 前厅运营结算 | 报餐、订餐、档口、小碗菜、称重计量、扫码 / 刷卡 / 人脸 / 补贴 / 计次。 | 标准支付和补贴规则纳入标准包;银行、财务、OA 深度对接单独评估。 |
| 营养展示与员工体验 | 菜品热量、营养成分、健康提示、电子菜牌、营养周报样例。 | 已有截图 / Demo 可进入演示;健康设备真实对接需补协议和授权。 |
| 食安与运营看板 | 留样、晨检、消毒、农残、视频巡查、经营看板、报表分析。 | 客户特殊监管口径、区域平台接口另行报价。 |
| 硬件设备包 | 消费机、称重餐台、电子菜牌、取餐柜、摄像头、一体机、打印设备等白名单。 | 白名单内可报价;非白名单型号必须先确认规格、协议和供应商售后。 |
| 部署与安全 | 本地化部署、服务器、数据库、浏览器、证书、内外网、权限审计。 | 国产化、等保、客户专网和安全测评按专项报价。 |
| 交付资产包 | 实施计划、验收清单、操作手册、截图证据、培训材料、问题闭环表。 | 标准交付物;客户追加定制培训、驻场、二次开发单独评估。 |
门禁原则P0 项未确认:不能给确定报价、确定周期、确定交付承诺。P1 项未确认:可以报价,但必须写入报价假设、风险备注或可选项。
| 门禁项 | 报价前必须确认 | 缺口处理 |
|---|---|---|
| 客户场景 | 客户类型、餐厅数量、餐线、就餐人数、支付方式、补贴规则、对账规则。 | 缺客户规模 / 财务规则时,先按估算报价并标注假设。 |
| 产品范围 | 标准模块、可选模块、定制模块、不可做事项、验收场景。 | 范围不清时先做需求冻结,不进入确定周期。 |
| 现场环境 | 服务器、操作系统、数据库、中间件、浏览器、证书、内外网、国产化要求。 | 未确认环境按风险项处理,国产化 / 等保专项报价。 |
| 设备硬件 | 设备型号、数量、厂家、协议/SDK、固件、安装条件、供应商售后。 | 非白名单设备先联调验证,再报价或承诺。 |
| 第三方接口 | OA、银行、支付、财务、补贴、监管平台、主数据来源、测试账号。 | 缺接口文档 / 测试账号时,只能写对接假设。 |
| 数据与合规 | 个人健康数据、刷脸、人脸、手环/体脂秤数据、权限审计、数据留存。 | 涉隐私和健康数据必须确认授权与非医疗化边界。 |
| 甲方责任 | 网络、安全、财务、设备、供应商、验收部门和具体责任人。 | 未给责任人时,不承诺进场和上线日期。 |
| 交付验收 | 验收清单、试运行周期、培训对象、问题响应、付款节点。 | 验收口径不清时,报价写明验收前提和变更规则。 |
| 决策项 | 建议结论 | 未决风险 |
|---|---|---|
| 第一突破线 | 6 月优先把企业 / 机关 / 国企标准包做成销售主线。 | 销售继续按单项目临时组织方案,无法沉淀复用。 |
| 报价前门禁 | 新项目报价前必须走门禁表,P0 缺口必须有责任人和假设边界。 | 交付阶段继续被环境、设备、接口和甲方协同拖慢。 |
| 控标资料口径 | 控标参数库由产品端牵头,销售/商务/研发/交付共同复核。 | 销售临时写参数,带来履约和验收风险。 |
| 交付资产标准 | 每个项目完结必须留下交付资产包,作为下一项目复用输入。 | 项目上线了,但经验不可复制,周期仍降不下来。 |
| 经营指标 | 后续周报跟踪标准包复用率、报价前 P0 缺口闭环率、交付周期、验收周期、回款和交付工时。 | 只能看项目数量和销售额,看不到真实利润、现金流和复用能力。 |
| 缺口 | 为什么重要 | 建议补证 |
|---|---|---|
| 真实交付周期和交付工时 | 目前周期长的判断主要来自项目复盘和管理归纳。 | 交付端按项目补开始、进场、联调、试运行、验收、回款节点。 |
| 标准包报价模型 | 标准包边界已清楚,但标准报价项、可选项、专项报价项仍需商务确认。 | 商务输出标准报价结构和专项报价规则。 |
| 设备白名单证据 | 硬件是周期拖慢和控标的重要变量。 | 补型号、规格书、协议/SDK、测试记录、供应商售后边界。 |
| 控标参数证据等级 | 部分参数仍是 B/D 级,不能直接进正式标书。 | 为 P0 参数补截图、证书、合同、验收、接口或设备证明。 |
| 甲方责任矩阵模板 | 责任不清会直接拖慢交付协调。 | 产品/交付/销售共同形成模板,并在国信等重型项目试用。 |
来源索引见同目录 source-index.csv。本页为内部周会评审材料,不替代正式报价、合同、标书或客户承诺。