订单拆成多个零件，不同员工分别完成。
MANUFACTURING ORDER & PIECEWORK WORKFLOW
制造企业订单与
计件协同工作流
客户最开始要的是“记账软件”。两轮业务沟通后，我把问题重新定义为：如何让订单、零件、员工工作量与老板确认形成一条完整业务链。
真实企业需求验证原型，包含老板端/员工端、订单拆分、任务领取、完成确认、员工结算与订单级财务核算。
在线体验原型 ↗当前为需求验证原型 · 非生产系统
REAL PROTOTYPE · 老板端经营总览
01
PROBLEM REFRAMING
客户说“想要记账软件”，
但真正的问题不是记账。
进一步梳理业务后，我发现老板真正花时间的地方，是一个订单被拆成多个零件、多人计件完成后，需要重新汇总工作量、核对金额，并且很难快速看清订单成本和利润。
员工按零件 / 图纸计件，月底需要重新汇总。
老板需要逐项判断员工填写金额是否合理。
工作量、计件成本与订单利润缺乏稳定关联。
问题从“怎么做一个记账软件”，变成了“怎么让订单、零件、员工工作量和老板确认形成完整业务链”。
02
BEFORE / AFTER
先把现有流程画出来，
再决定软件应该出现在哪里。
第一步不是列功能，而是把真实信息流和责任流拆出来。旧流程依赖总表、个人表和月底人工汇总；新流程把“谁负责什么、什么时候算完成、谁确认”变成显式状态。
订单→总表→个人表→人工填写→月底汇总→老板核对
数据分散、重复录入、对账成本高，订单利润难追踪。
创建订单→添加零件→领取 / 分配→提交完成→老板确认→成本 / 对账
同一零件沿状态链流转，老板和员工共享业务事实，但看到不同工作界面。
03
TWO SIDES OF ONE WORKFLOW
不是做两个页面，
而是让两个角色围绕同一业务对象协作。
老板和员工关注的内容完全不同，但他们操作的是同一批订单、零件与状态。产品需要保证“各看各的界面，共享同一事实”。
老板需要
- 创建订单与零件
- 分配或开放领取
- 查看待确认
- 确认计件金额
- 查看订单成本与利润
OWNER WORKSPACE待确认3
张三 · LJ-E-001 · 已提交
李四 · LJ-A-004 · 进行中
王五 · LJ-C-007 · 待领取
员工需要
- 只看到自己的任务
- 快速领取 / 查看零件
- 明确计件金额
- 完成后提交
- 查看历史工作记录
MY WORKLJ-E-001¥ —
状态：进行中
订单：ORD-2026-08
动作：提交完成
同一套业务数据，对不同角色应该呈现完全不同的工作界面。
04
STATE TRANSITION
真正需要设计的，
是零件如何在角色之间发生状态变化。
以一个零件任务为例，产品价值不在于“员工端有按钮、老板端有列表”，而在于每一次动作都能让下一角色看到正确状态。
01待领取任务进入工作池
→02进行中员工领取 / 被分配
→03已提交员工提交完工
→04待确认老板审核完成情况
→05已确认进入对账与成本
示例链路：张三点击 LJ-E-001「提交完成」→ 老板账号立即出现对应待确认项。
05
PROTOTYPE
原型的目标不是“像成品”，
而是尽快验证真实工作流。
第一轮重点只覆盖老板创建订单、添加零件、员工领取 / 查看、提交完成和老板确认，保证一次完整业务流可以被实际演示和讨论。
原型目前仍在与企业老板持续对接，用来验证流程、角色和核算逻辑是否足够贴合真实使用。
在线体验原型 ↗06
ITERATION
Bug 暴露的不是按钮问题，
而是链路问题。
原型迭代中出现过“员工提交完成无法点击”，修复后又需要验证老板端能否接收到正确状态；后续修改还曾影响原有创建订单能力。这让我开始把测试对象从“单个页面”改成“完整业务链”。
创建订单→添加零件→员工领取→提交完成→老板确认
工作流产品的复杂度来自状态之间的联动，而不是单个页面。
07
MVP / SCOPE
第一阶段只验证核心协作闭环。
我没有把它扩成完整 ERP、财务或薪酬系统。当前最重要的是验证员工是否愿意使用这条流程，以及它能否真正降低老板的对账成本。
FIRST
- 订单创建与零件拆分
- 分配 / 领取任务
- 员工查看计件金额
- 完工提交
- 老板确认
- 订单成本与对账入口
NOT NOW
- 完整财务系统
- 自动薪资
- ERP 深度集成
- 复杂审批流
- 自动利润分摊算法
- 企业微信深度集成
08
CURRENT STATUS
现在仍是原型与需求验证，
还不是生产系统。
已完成多轮业务沟通，重新定义核心问题与主要角色。
已形成老板端 / 员工端可交互原型，并持续修正业务链路。
尚未进入正式企业生产环境，当前重点仍是需求与流程验证。
09
WHAT I LEARNED
这个项目让我更确定：
产品不是把客户说的话做出来。
需求要被重新定义。
客户提出的是解决方案，产品要继续追问背后的工作、成本和约束。
业务对象和状态比页面更重要。
老板端和员工端只是入口，真正决定产品是否成立的是状态如何可靠流转。
先验证闭环，再扩功能。
在20人企业场景里，减少对账成本比做一个“功能很多的管理平台”更重要。
从“帮企业做一个软件”，
到“先理解企业到底在为什么付出成本”。