研发管理

新品研发最常见的状态是：配方改来改去，这次开裂、下次塌陷、再下次口感不对，试了十几次仍然说不清问题出在哪一步。原因往往不在技术，而在记录——这次加了多少黄油、醒发多久、温度调了几度，全靠脑子记和本子记，过两天就乱了。研发管理把每个产品的试作过程留成履历，成功与失败的参数都沉淀下来，让下一次试作从「重新猜」变成「在上次的基础上改」。

一、功能说明

能力	说明
产品研发履历	按产品独立建档，同一产品的多次试作记录归在一起，不与其他产品混
研发失败登记	把未达预期的配方标记为研发失败，填写失败原因并上传照片或文件
失败归档查询	失败记录自动归档并汇总到研发失败查询报表，可按产品、日期回看
修改历史	记录配方的变更情况，微调前后的差异可以对照
配方复用	成熟配方可整份复制到另一个物料，作为新品研发的起点

研发失败查询报表的列表包含研发失败日期、物料类型、物料分类、产品编号、产品名称等列，选中记录后可在图文编辑区查看当时的照片与说明。具体入口与字段以实际版本为准。

二、适用场景

同一产品反复试作。 一款吐司试了八次，第七次最接近目标，但当时的配方参数已经找不到。有研发履历之后，每次试作的配方、工艺参数、结论都留着，回看就能定位「哪一次做对了、那一次和现在差在哪」。反过来，验证成熟的配方整份复制给新品，只改差异行，上新周期会比从空白开始短很多。

多条产品线并行。 吐司、蛋糕、点心三条线同时在上新品，参数互相串味是常事。按产品分类建档，每条线的试作记录各归各位，不会出现「这个温度是蛋糕的还是面包的」这种问题。

失败原因沉淀。 开裂、塌陷、组织粗糙、口感发干，这些问题的原因分布往往有规律，比如集中在某款面粉批次或某个搅拌阶段。把失败原因分类登记并配上照片，累积一段时间后就能看出规律，而不是每次从零排查。

三、使用要点

1. 每次试作都留一条记录。 记录内容包括日期、配方版本、关键工艺参数（搅拌、发酵、烘烤）和试作结论。只记成功的那几次没有意义，失败的记录才是排除法的依据。
2. 一次只改一个变量。 同时调配方比例、发酵时间和烘烤温度，做出来不对也无法判断是哪个因素导致的。按变量逐个试，每次的结论才可信。
3. 失败也要写原因、配照片。 文字描述容易失真，「塌陷」到底是出炉塌还是冷却后塌，照片比一句话清楚。失败原因按类别登记，后续统计才有意义。
4. 定稿要确认，确认后才是准配方。 试作阶段的配方是草稿，排产与配料只读已确认的配方。研发成功意味着这份配方被确认，而不是「最后一版文件存在某个文件夹里」。
5. 研发配方要控权限。 研发阶段的配方往往是企业最敏感的资料，谁可以看、谁可以改、谁可以导出，要按岗位区分。配方外泄的损失通常远大于研发本身投入。

四、与其他功能的关系

环节	对应功能
配方主档（网页端）	工艺配方
配方窗口（客户端）	工艺配方
失败查询发布说明	功能分享2026年4月第2期
工序与参数	生产工序定义
操作说明沉淀	作业指导
配方保密与分权	烘焙配方保密与权限落地方案
上市后的毛利	销售毛利环比分析

五、验收清单

检查项	通过标准
建档完整	每个在研产品都有独立履历，试作次数与记录条数一致
参数可查	任意一次试作都能查到当时的配方、工艺参数与结论
失败留痕	失败记录带原因分类与照片，能在失败查询报表中检索到
成功可复现	按成功记录的参数重做一次，成品表现与记录一致
版本清晰	定稿配方处于已确认状态，草稿版本不会被排产读取
权限到位	只有授权岗位能查看、修改或导出研发配方，操作有记录

六、常见问题

研发失败记录和删除配方有什么区别？ 删除是把这份配方去掉，历史也跟着没了；标为研发失败是把这次尝试归档，配方本身退回未确认状态，失败的原因、照片、参数都留在失败查询里。失败记录的价值恰恰在于它还在，所以不要用删除代替归档。

失败原因怎么分类才有效？ 按可控环节分，而不是按现象分。「塌陷」是现象，原因可能出在配方比例、搅拌过度、发酵不足、烘烤温度或原料批次。分类时把这些环节列成选项，再配合照片与批次信息，积累之后才能定位高频问题。

研发期的配方要不要确认？ 试作期间不必确认，草稿状态即可，方便反复修改。试作成功、参数稳定后要及时确认，确认之后才能被排产和配料读取，也才能按正式配方核算成本。

功能发布：功能分享2026年4月第2期