只有一个模糊问题
比如“订单总是对不上”“库存不准”“门店执行看不清”。
建议从初步沟通和诊断评估开始。
Delivery Process
交付流程不只交付系统，也交付可执行的方案和机制
用分阶段交付，把项目从诊断、方案、实施到运营复盘连接起来，最终产出可能是方案、系统、数据看板、自动化规则或长期运营机制。
- 首个可用成果
- 30-90 天
- 从诊断到运营
- 6 个阶段
- 先跑通核心业务
- 1 个闭环
Entry Path
不是所有客户都从第一步开始
有的客户还在描述问题，有的客户已经有明确系统需求，也有的客户只需要一套可执行方案。我们会先判断你当前处在哪个状态，再决定从哪一步进入项目。
已有明确系统需求
比如已经知道要做小程序、后台、看板或接口集成。
可以更快进入方案共创，先确认边界和验收标准。
已有系统但不好用
比如系统上线了，但员工不用、数据不准、流程仍靠人工补位。
建议从效果评估切入，先判断问题在流程、数据还是使用方式。
01Phase 01
初步沟通
确认问题是否值得进入项目
判断切入点
先判断当前问题适不适合进入项目。
我们会一起确认业务断点、系统现状、决策目标和预算边界，避免一开始就进入大而散的需求清单。
客户需要参与
业务负责人说清楚当前最反复、最耗人、最影响经营判断的环节。
这一阶段确认
判断是否适合进入诊断，还是先收集更多现场信息。
阶段产出
- 业务痛点清单
- 当前系统与表格清单
- 首期目标假设
02Phase 02
诊断评估
把模糊问题拆成可交付范围
锁定业务闭环
把模糊问题拆成可执行、可验收的范围。
围绕流程、数据、人员、系统和现场执行方式做诊断，明确最先交付的成果形态和可衡量指标。
客户需要参与
提供现有流程、关键表格、系统账号或截图，以及一线人员的真实操作方式。
这一阶段确认
确定首期先做哪一个闭环，不把所有部门和所有功能一次性装进项目。
阶段产出
- 流程断点分析
- 数据与接口清单
- 首期交付范围
03Phase 03
方案共创
让业务和技术在同一张图上对齐
形成可执行蓝图
把业务目标、交付边界和执行节奏对齐。
根据项目目标设计方案结构、系统边界、角色权限、关键页面、数据口径和推进节奏，让客户清楚每个阶段交付什么。
客户需要参与
业务、管理和实际使用人员一起确认页面、角色、数据口径和验收优先级。
这一阶段确认
确认首期版本做什么、不做什么，以及每个功能对应的业务动作。
阶段产出
- 首期功能清单
- 页面流程图
- 里程碑计划
04Phase 04
分步实施
先交付可用成果，再扩展能力
首个成果落地
先交付能被使用、能被验证的首个成果。
交付物不一定是完整系统，也可能是诊断方案、产品原型、数据看板、自动化规则、运营机制或可运行版本。
客户需要参与
指定关键用户参与测试，及时反馈现场操作是否顺手、数据是否准确。
这一阶段确认
先让核心流程跑起来，再判断哪些能力进入下一轮迭代。
阶段产出
- 可用成果版本
- 测试问题清单
- 上线验收清单
05Phase 05
效果评估
用数据判断成果是否真正发挥作用
复盘业务指标
判断交付成果是否真的进入业务使用。
根据项目类型跟踪订单、确认耗时、库存准确率、异常响应、复购率、方案执行度等指标，判断效果和持续优化方向。
客户需要参与
反馈系统使用情况、人员阻力、流程变化和关键指标表现。
这一阶段确认
判断当前版本是否真正被使用，以及下一轮该优化流程、页面还是规则。
阶段产出
- 指标复盘报告
- 问题修正清单
- 迭代优先级表
06Phase 06
持续陪伴
把一次性交付变成长期运营能力
沉淀长期机制
让方案、系统和运营动作持续产生价值。
根据现场反馈和业务变化持续优化流程、自动化规则、页面体验、数据看板或运营机制，让交付成果长期有效。
客户需要参与
把新的业务需求、组织变化和运营目标纳入定期复盘。
这一阶段确认
决定哪些需求进入迭代，哪些需求暂缓，避免系统重新变成复杂负担。
阶段产出
- 运营复盘纪要
- 功能迭代计划
- 长期支持机制
Common Concerns
客户把项目交给我们前，通常最担心这几件事
交付流程的价值，不是把项目包装得更复杂，而是让客户知道项目如何控制范围、如何上线、如何验收，以及上线后如何继续产生价值。
项目会不会越做越大？
我们会先锁定首期闭环，明确做什么、不做什么。需求可以扩展，但不应该在首期无限膨胀。
多久能看到第一个成果？
多数项目会以 30-90 天为首个可用成果目标，成果可以是方案、原型、看板、机制或系统版本，具体取决于数据准备、接口复杂度和参与人员反馈速度。
交付的不一定是系统，可以吗？
可以。我们会根据问题判断交付物，可能是诊断方案、产品原型、系统版本、数据看板、自动化规则或运营机制。
落地后没人用怎么办？
设计阶段就会把角色、现场动作和指标放进去，交付后继续跟踪使用情况，并根据反馈调整流程、页面或运营规则。
需求变化怎么处理？
变化不可避免。我们会区分核心流程变化和附加功能变化，把迭代优先级放进复盘机制，而不是临时堆需求。
Principles
我们更关注系统上线后的真实使用
先闭环，再扩张
先让一个关键流程跑起来，再扩展到更多部门、门店、平台或产品线。
先指标，再功能
每个功能都对应一个业务指标或管理动作，避免系统变成信息堆积。
先使用，再完美
优先交付现场能用的版本，再根据真实使用反馈迭代体验和规则。
想知道你的项目应从哪一步开始？
已有明确需求，可以直接进入方案共创；如果当前流程和系统都比较混乱，诊断评估会先帮你找出最值得上线的业务闭环。