惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
V
V2EX
WordPress大学
WordPress大学
U
Unit 42
I
InfoQ
A
About on SuperTechFans
宝玉的分享
宝玉的分享
J
Java Code Geeks
博客园 - 司徒正美
爱范儿
爱范儿
Engineering at Meta
Engineering at Meta
G
Google Developers Blog
人人都是产品经理
人人都是产品经理
小众软件
小众软件
Microsoft Security Blog
Microsoft Security Blog
L
LangChain Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Hugging Face - Blog
Hugging Face - Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
aimingoo的专栏
aimingoo的专栏
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Last Week in AI
Last Week in AI
腾讯CDC
Recent Announcements
Recent Announcements

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
业务方案对比:制造转单在哪一个环节确认产品来源
人鱼 · 2025-04-07 · via 人人都是产品经理

在制造业的数字化转型过程中,如何高效地确认产品来源是一个关键的业务问题。本文通过对比两种不同的业务方案,探讨了在制造转单过程中确认产品来源的最佳环节。

简要的背景介绍:我司目前为各种中小型离散制造的工厂企业做数字化转型服务,以SaaS化的轻MES模式推广。在不断的推广客户,拓展使用的场景后,我们锚定的客户规模也有所提升,客户工厂的产品也愈发标准化,逐渐从完全的离散制造转为离散选型装配制造的模式,在这种模式中,在业务上遇到的第一个差异点就是在哪一个环节来确认产品来源。

简要的业务上下游介绍:某工厂是一家精密模具的制造工厂,也是A、B、C等大型流程工厂的供应商,有时A、B、C的工厂在制造时会有一些新的开模需求,他们会考虑让某工厂来制造,减轻自己的成本。当某工厂接到需求(往往是收到某零件本身,要求某工厂提供能够制造此零件的模具)以后,会由自己的设计员来进行模具设计,将这个模具拆分为某些子部件或者某些子步骤,车间的工人分步来进行加工,最终造出此模具。制造的子部件也不常常都由车间工人自己完成,会有一些采购而来的标准件,会有一些车间仓库里本身有存放的库存件,还有自己的工厂无法完成而需要外协的工厂帮忙完成的外协件。自制、采购、库存、外协,这就是在制造过程中常见的四个来源。

再回顾一下我们的问题:我们要在哪一个环节确认产品来源?

为什么要知道在哪一个环节确认呢?

第一,因为从这一点开始订单开始 有了不同的分支走向;

第二,因为这涉及到业务流程上的职责划分(我想这一点做SaaS的产品会有所共鸣,因为我们都在试图标准化出一个企业的最佳实践,用这份系统中的操作流程来指引公司运营上的业务流程);

第三,则是因为这一个点越早的出现,越早完成分歧固化,就能越早将串联的工作流转为并联,极大地提高工作效率。

当然,这个环节不能一味地取早,过早的话极易引发频繁的变更,变更的处理要比正向流程更加繁琐,因此,要在尽早和确定之间取一个平衡值。

方案1:在订单转单阶段确认产品来源,并且结合库存数量进行对应下料扣减,直接生成各个去向的单据。录入订单时一并录入物料,在物料下可以直接标记明细是否需要设计、从仓库从取现货、采购还是转向生产。

这个方案是原始的产品设计流程,已经应用到许多离散制造、装配、机加工厂中,契合业务。在业务上,更适合规模不大,管理扁平,物料品种简单易判断的工厂,在订单阶段往往具备判断条件,一切分支前置,流程简单易控。

方案2:在设计以后先初步判断产品来源,主要判断标准采购、库取还是自制,在自制的分支下进行具体判断,采购、自制还是外协。

这个方案则是最新接触到的工厂生产流程,在订单阶段商务无法判断物料的来源,只负责记录订单范围到底要交付几个什么样的成品,成本在传到设计后,设计进行分解和绘图,并将分解的技术要求传递下去,此时设计可以提供一定的意见参考,如制造此类成品需要哪些标准件可以进行采购,哪些部分可以自制。在从设计转向采购或者生产时,系统需要依据当前工厂所有的此产品需求和产品库存、产品订单进行判断,下单结合总需求判断,但不对库存进行占用,但进行实质性判断的需要由制造部的工艺部门完成,工艺部门判断自己生产部门的产能是否能完成这项任务,是否有完成这项任务的技术和时间,并依此进行外协、生产、采购的判断。

此工厂产品特殊,为按单设计,所有的订单都需要设计,因此在设计的环节上出现第一次的去向判断,但在生产部门才进行实质性的去向判断,这种方案更适合业务复杂,按单设计的工厂。

另外:

在这个问题下可以窥见到另一个新人误区:即此类需要设计、生产的工厂流程,订单中的物料产品清单往往与最终的入库、发货出库的物料清单不同。一方面,这来自于物料的层级关系,在订单阶段未进行设计往往只记录了产品的最初一级BOM,而在进行了设计以后,进行具体的BOM拆解,就会出现每一层级下分化出多层级的BOM的情况,而最终的最小级的BOM清单才是出入库的参考清单。另一方面,则是要考虑设计变更的问题,在订单传递到设计以后,我们往往不会再随时从设计同步回订单BOM清单,而设计过程有时候会出现变更,出现变更以后出现的增、删、改物料也不会同步回订单。

本文由 @人鱼 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务