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

推荐订阅源

Spread Privacy
Spread Privacy
P
Palo Alto Networks Blog
P
Proofpoint News Feed
AI
AI
Help Net Security
Help Net Security
S
Securelist
T
Troy Hunt's Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
C
Cisco Blogs
Scott Helme
Scott Helme
Hacker News - Newest:
Hacker News - Newest: "LLM"
Vercel News
Vercel News
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
B
Blog
GbyAI
GbyAI
Recent Commits to openclaw:main
Recent Commits to openclaw:main
D
Darknet – Hacking Tools, Hacker News & Cyber Security
P
Proofpoint News Feed
S
Security Affairs
Cisco Talos Blog
Cisco Talos Blog
AWS News Blog
AWS News Blog
T
Tenable Blog
H
Help Net Security
NISL@THU
NISL@THU
F
Fortinet All Blogs
博客园_首页
G
GRAHAM CLULEY
L
LINUX DO - 最新话题
P
Privacy International News Feed
G
Google Developers Blog
博客园 - Franky
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Security Archives - TechRepublic
Security Archives - TechRepublic
The Register - Security
The Register - Security
L
LangChain Blog
aimingoo的专栏
aimingoo的专栏
T
Tor Project blog
P
Privacy & Cybersecurity Law Blog
量子位
C
Cyber Attacks, Cyber Crime and Cyber Security
Forbes - Security
Forbes - Security
S
Secure Thoughts
Simon Willison's Weblog
Simon Willison's Weblog
D
Docker
Recorded Future
Recorded Future
博客园 - 三生石上(FineUI控件)
L
Lohrmann on Cybersecurity
T
Tailwind CSS Blog

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
道生一:资源架构设计
道家软件 · 2025-08-16 · via 人人都是产品经理

资源架构不是从“有”开始,而是从“无”开始。本文以“道生一”为隐喻,提出一种从本源出发的架构设计思路,帮助产品人在复杂系统中构建更清晰、更可控的资源逻辑。

数字化,数字化,就是要先有数字,才能计算和转化,我们的数字是怎么来的呢,就是从我们的道生一来,即一代表的是资源和数字。资源是整个道家管理体系中唯一的对象,因为在后面的一生二的组织架构中,我们是把组织构架拆分为一个个的仓库容器,这些仓库容器也是由单个或多个资源组成的而已,所以组织结构的仓库也可以叫做资源组或资源库,仓库也是我们企业对资源的管理主体,其组成还是资源。资源在资源库里加减出入就是三,三代表所有业务。所以资源是整个道家体系中唯一的对象,这也符合奥卡姆剃刀原理,即如无必要,勿增实体。

企业资源我们可以分为原有和附带两种,原有就是企业进和出的,进的就是企业买的人机料等,而出的就是企业卖的产品和服务等,进和出的我们都统称为资源。我们对资源的划分是依据约定俗成来的,比如人机料产品服务等,但为什么会区分他们呢,主要就是它们的计量方式不同,比如服务是计次的,产品是计量的,人工是计时的等,有了计量我们才能计算。附带的是什么呢,附带的就是文件和表单等,比如有的产品有说明书,就是一个文档,有的产品有参数表,就是一个表单,有的服务需要按次计时间,那时间也是伴生和附带的。

为了说清楚这个资源的属性,我们需要从三个维度来说,就是这个一和一二三零分别的对应关系来讲,一对一就是资源和资源的关系,例如我们的BOM表,一对二就是资源对仓库的关系,例如我们零件只能进设备,人员只能进出岗位,资金只能进出账户等限制关系,一对三就是资源对加减的关系,例如产品出库做的减法,既可以是销售、也可以是借用、或者是测试,所以一个资源会对应多种加减法,我们只要定义好加减所具体指定的业务,就可以对这些分类进行统计了,一对零就是资源的计价管理。

根据以上的描述,那么企业资源管理员在后台的三大功能菜单就是:

(1)资源的目录,

(2)资源的加减,

(3)资源的剩余。

简单理解就是资源先有数字、然后进行加减、最后加减后看剩余多少。

章节一、资源的目录

资源管理员是管资源的,首先就需要知道资源的目录里有哪些资源,没有的资源需要先创建再使用,创建任何一个资源,都需要说明这个资源的内在属性和外在关系两方面的内容。1、内在的属性:就是资源的类别、分类、来源、名称、编码、计量以及伴生的资源以及附带的信息等,2、外在的关系:就是资源和其他资源,资源和所有仓库,资源和任务以及资源和财务的相互关系。

1. 内在的属性

需要提前说明的是,资源属性按我们的学科分法有:语文类、数学类、地理类、物理类、化学类等,我们目前先就语文类进行分析,目前我们先解决语文类即我们常说的人机料产品服务类的资源。后面的几类以后也会有应用的,例如存储数据类的设备物联网、存储地理坐标类的地图、存储参数类的物理属性量、以及存储化学类的分子量等,这些不是企业常见应用,我们先实现基础应用,高级的以后再说。

1、资源类别:资源类别是按我们日常的使用习惯进行资源的划分:买的有3类、卖的有3类,附的有3类:买的3类就是人、机、料,卖的3类就是产品、服务和虚拟(如游戏装备)等,附的3类就是企业的文档、表单、时间等,这其中时间资源需要解释下,例如员工的月工资、包房的时间、电影票的时间,球馆的时间,都算作资源,但时间也必须附在其他资源对象上,因此也是附带的。这样的分法基于约定俗成,易于大家理解。

2、资源分类:资源分类简单来说就是规格型号等,跟淘宝的分类是一样的,可以将企业内部的物料进行分类和标签设置,分类有分类、名称、标签、选项,企业根据实际情况来确定,如果需要的话,就需求提前在后台设置好,前台才能使用。当然不设标签选项等,就只有分类,一般的应用是足够的,但比如有了手机有颜色、内存和运存几个标签属性,就需要提前设置了。

3、资源来源:资源的来源需要说明这个资源是引用的还是创建的,产品是可以凭空创建的,这个配置字段说明这个资源是外来还是自己创建的。需要强调的还有些资源是由库转变而来的,例如一个手机首先是一个资源,接到订单后,在生产中把手机转为一个仓库,把手机零件都装到手机里了,我们就封库贴上封条,然后把这个库转成资源即可以交付的手机了,所以资源的来源有创建和引入两种。

4、资源名称:这个可以自定义,当然也可以依据一定的规则生成,例如按时间、按空间,按序列或自定义等。因为名称这个字段可以有两个规则,分别是无序和有序,甚至进一步规定中英文和字符,这个组合是一个无限枚举。设置名称后我们还可以设置别名或者简称,这样符合用户习惯。

5、资源编码:这个也可以进行设置,编码有一定的生成规则,这个需要符合企业的既有编码规则,比如有拼音字母打头的,也有英文缩写打头的,有的需要行业编码规则,还有日期编码加序号的等等,编码就是唯一性搜索比较方便。这个功能个别企业用户是刚需的功能,当然用户也可以不启用。

6、资源单位:资源的计量一个庞大的体系,我们的9种常规资源会各自有各自的计量单位,常用计量无非是物理计量、时间计量或者空间计量三种,目前我们只讨论了刚体,对于流体的计量的留到以后去说。计量单位也同时存在换算关系,除了常用的面积,重量等单位换算,还有一些是企业自行设定的换算,例如一包和一箱商品各是多少个,这就是数字单位的换算关系。

在资源大类型中,一般产品按数量,服务按次数,人工按计时等,这些计量是和现实相符合的,注意时间是一个通用函数,适用于所有对象,比如设备有买的,算的是入库时间,还有租赁的,那么租赁其实就是算的在库时间,其实所有的对象都是算的在库时间,因为一个商品如果不和仓库发生关系,那么他的时间是产生不了的,换句话说也就是资源和库发生关系,才会产生时间。

7、资源计价:资源计价按道家架构应该放在外部对财务的关系中去,一般企业没那么复杂,也可以纳入内在属性进行设置,价格就是资源对财务的设置,就是说要驱动这个资源加减或者出入任何一个仓库,需要花多少钱的意思。计价也是比较庞大的体系,原理上,每种资源,在每个仓库,对应的每种操作,甚至每个时间段,费用都会不一致的,如果不事先计价,那么每次加减出入时,都要去输入价格并计算费用就比较麻烦,所以价格一般需要提前设置。

但设置价格就需要确定仓库和加减,而仓库和加减在后面才会讲到,那么可以先简单的设置,资源先对总库的加减分别是多少钱,后面仓库加了子库,加减做了分类后,还可以继续设置更细的价格。另外促销也是常用的功能设置:促销则是个更大范围的排列组合,即资源、仓库、以及任务任何一项变动,都可以产生一个函数去驱动另一个或一组对象变动,这个比较复杂,但原理是一致的,先把整体体系用起来没问题了,再去做这个动态函数的功能。

8、伴生资源:例如一个产品,会有表单、附件或者时间限制等,这些都是属于这个产品伴生出来的其他资源,伴生出来的资源是没法独立存在的,是需要依附于这个产品才能存在,所以也叫附加资源,他们都是这些资源的附带的属性。比如企业生产的产品需要附带产品说明书,就做一个表单或者附件都可以,那么这个设置好后,你上传产品选择了分类标签后,这时候系统就提醒您还需要上传它的说明书。还比如员工入职后,员工的时间就是资源,这个资源是可以计价的,不同岗位的时间价格是不一样的。

9、资源状态:资源的状态就是这个资源是否启用,还是处于停用状态,比如企业产品已经停售了,这个产品你是买不到的。但并不是说你买不到就不存在,只要这个资源产生了业务记录,那么是可以查询历史数据的。

2. 外在的关系

资源外在的关系,是1分别对1230的对应关系,即资源对资源的BOM清单,资源对仓库的库容设置,资源对加减的业务限制,资源对财务的单价预设。

1、资源对资源

资源对资源,就相当于是制造型企业的BOM表功能,例如一个手机包含了几百个零部件,就等于是产品对物料的比例关系,手机其实就是一个库,手机里的零件才是实体资源,这些零件组合在一起就是手机了,所以这个手机其实就是一个资源组或者是一个资源包。用户购买的其实是这几百个零件,我们只是生产组装好而已。这个BOM表你设置以后,如果客户下单100个手机,那么其实也就包含100套零部件物料,你需要把这些物料都装到手机里,才算给客户完成了生产和交付。

还比如你美团上买了一桌菜,就是几个菜的打包组合,这个团购的商品是多个实体的菜品组成的,因为这几个菜才是实际的实物资源,所以团购也相当于一桌菜的菜品目录,所以这个资源对资源的关系我们可以用BOM功能来解决。

2、资源对仓库:

资源对仓库有两种关系,首先是资源可在哪些仓库存储的对应关系,然后是资源绑定了哪些仓库的绑定关系。

(1)对应关系

对应关系就是那种资源可以在哪些仓库里存储。由于在设置资源时,仓库还没有开始设置,所以最开始的资源肯定是都可以在公司的总库下存储的,但是总库会不断增加部门车间等子库,所以资源自然就需要设置可以在哪些子库存储。这个对应关系是双向操作的,即可以在资源这边设置可以对哪些仓库,也可以在仓库那边选可存储哪些资源。在一边设置后,在另一边也会有相应的显示。规定某些资源只能在某些库中加减,这样做的目的是为了防止出错,因此这个设置可以实现对业务规则的操作限制。

(2)绑定关系

我们知道资源可以计价,但仓库不能计价,为了让仓库可以计价,我们就需要把资源和仓库绑定关联起来。就拿前面的团购举例,就是比如团购后还要定一个包房,那么就绑定一个包房,这样这个团购就和仓库绑定起来了,如果商家还要收包房费,也可以在这里很方便的设置入库即收费。再比如一账电影票,你绑定的是哪个影厅和哪一排哪个座位,再绑定的哪个时间,这个时间内你只要进出电影厅了,就等于实现了卖电影票的功能。

(3)权限设置

资源的权限管理,就是给资源目录设置分管人员,分管人员的权限就是管理分类目录下的资源所有的业务。

(3.1)统一授权资管

一般情况下会由公司统一在后台分配权限,分配方式则是按类别和分类,直接设置分管人员,这样该人员就获得了该类别分类下资源的管理权限。比如公司直接设置产品下,哪些销售员负责销售哪些规格的产品,或者哪些采购员负责采购那些型号的材料。

(3.2)逐级授权模式

当组织规模比较大时,后台授权就比较繁琐了,这样就需要只把产品大类给销售总监,材料大类给采购部长,然后他们自己再将小类去分配不同的销售员和采购员,这样就比较省事,而且后台也可以看到他们的分配记录。

3、资源对加减:

(1)对应关系

和前面的仓库一样,我们的资源可以在哪些仓库进行加减,是可以提前设置好的,例如员工只能在岗位中出入,资金只能在账户中出入,查看资源的加减,就会列出这个资源允许在哪些仓库加,允许在哪些仓库减,甚至还有时间限制等。

(2)绑定关系

加减同样是不能计价的,所以我们还是需要用资源和加减建立起关联关系,就实现了服务的计价。因为有些服务本身就是商品,我们就需要建立一个服务的商品,来绑定对应的任务,例如医疗服务、维修服务,这些服务的计费是以任务为主的,但我们的系统只有资源才是唯一实体对象且才能计价,所以我们需要用资源绑定服务的方式来进行计费处理,下面继续来举例说明。

例如这个手机价格还包括一个1年的保修服务,这个服务也是资源,手机过1年到期才算真正交付完成。那么就需要先绑定维修类的任务,这个任务客户报修就可以启动,保修期内客户没有报修,那么这个任务就不会启动,如果发生了在保修期内,所以不能算钱。

还比如说物业管理中报事报修服务,这个服务是业主发起的,发起后由物业接单后上门完成维修任务后,才能结束任务,因为这个服务就需要绑定一个任务,用任务的完成状态来确定这个服务的交付状态是否完成。客户买的也不是实体商品,买的是一个任务,所以我们平常就称之为买单。

4、资源对财务:

资源对财务就是产品服务和人机料的价格,但是资源单独不能对费用,资源必须要进行加减才能兑换成费用,而且这里设置的价格就费用的单价预设模版,并不是真实的费用。例如我们设置产品价格是100元,但是实际销售的时候,如果是大客户,肯定就降点价90元,所以资源在这里设置的也只是一个参照价格而已,只有在进行真实加减的时候,才是真实的费用。资源的加减对应的就是财务的原始凭证,这个我们后面再说财务的时候再详细介绍。

上面我们说了资源的目录,主要功能就是完成了资源的创建,创建了资源才能计数,计数才能加减。接下来我们就可以进行资源的加减了,也就是企业的业务体系。

章节二、资源的加减

从道家数字化的架构中,我们知道资源只有加减两个基本计算,且这个加减必须通过一个可以存储的仓库来承载实现,顶级的资源库就是公司本身,而公司下面又会有很多例如部门或车间产线设备工位等不同的子库,资源在企业组织结构的这些子库中加减减减,出出入入,就构成了企业的全部业务。资源管理员需要知道所管辖的资源,将会正在和已经发生了哪些加减,下面我们以未开始、进行中、已完成三种状态来说明。

在说明加减的这三大状态之前,我们先说下加减的流程和项目。资源加减是对业务的抽象,是一个最小的可执行单位即任务,加减本身是一个操作或者动作,多个加减串起来就是流程,一个加减也可以分解为很多小的加减就是项目,即我们说的加减同时包含任务、流程和项目这三种,这个我们会在后面的二生三加减中详细介绍。

在道家构架中,流程的节点和项目的子任务,都是用分库来对应解决的。比如买菜就是拿菜、上称、称重三步,对应的就是申请、发起和执行三步,分别是申请加减,发起加减和执行加减三个阶段,就可以分三个子库。我们一般企业都有售前售中售后三个阶段,那么就对应的分为销售、生产、售后三个部门是一个道理,然后生产又要分很多工序,也是分库来完成对应步骤的。

上图的意思就是任何业务流程的节点和任何项目子任务,都有资源的进出,且都有自己发生的地点,这个地点其实就代表了仓库。所以流程节点功能其实就是仓库子库的功能。项目分解也是对仓库子库的继续分解。那么企业的每个业务行为,就是一个最小的加减任务,这些任务左右连接就是企业的流程,上下组合就是企业项目。就都有前中后即未开始、进行中和已完成三种基本状态,我们下面先来分析未开始的加减。

1. 未开始的加减

所有未开始的加减都要从发起开始,发起由资源管理员自己发起,也可以由群众通过预先做好的表单发起。加减的确认权限一般在资管哪里,当我们可以设置这些表单并且在前台发生了申请后,后台就需要人工来审核,也可以设置自动通过。而后台下达后,也可以设置前台是自动接收还是可以拒绝等,这些设置如果需要,就可以配置成加减的模版,就是我们常见的各种单据,然后规定这个单子发给谁谁就可以填。

1、加减模版

业务模版就是公司后台提前设好的业务单子,这些单子会发给有对应业务需求的人员,例如请假单发给所有人,销售单发给销售员,领料单发给生产工人等,业务模版有三个元素可以设置,资源可以设置允许资源的种类及其数量限制,仓库可以设置允许哪些子库,加减就是设置其业务的动作名称,每个公司都有很多业务限制,例如每月领一次办公用品,病假一个月只能请三次;销售1万元送一个赠品,特定时间前100名半价等等。模版详细的我们会在二生三的加减中详细介绍,这里只起一个开头。

2、加减申请

当这些模版发给有对应业务员工后,员工就可以填写单子并提交业务申请了,填写的内容也是资源仓库和加减的内容,填写完成就提交即可,需要说明的是,即使公司后台一个模版都不设置,员工也是可以提交申请的,因为系统有最基本的加减两个单子,你选择后可以自定义资源和仓库,公司同意后,自然就在后台同步添加了这些资源和仓库,所以企业管理是可以从零开始慢慢搭建起来的。

注意加减既可以是增量加减,也可以是存量加减。增量加减就是企业发生的实际业务如订单、请假、报销等;存量加减就是库内剩余的数量进行盘存。加减可以限制在仓库或其子库内进行,加减因为是在库里进行,所以可以在加减上做函数计算,你可以把仓库就看成一个单元格,我们加减的时候同样可以支持EXCEL的计算公式。

3、加减审核

一般在前台提交加减的申请后,后台三个分管都会收到消息,即管资源的,管仓库的,管加减的,因为任何申请都有这三个要素。一般三个分管都必须同意才能走到下一步,当然也可以在后台模板中设置只需要部分分管确认或者自动同意。分管各自确认什么呢?比如一个销售员提交了一个客户订单。资管即销售总监确定到底是要卖什么样的产品或者服务,以及产品的货期和价格等。库管即生产部长需要确定资源够不,车间的产能是否跟得上,这单到底能不能做,因为仓库是一个容器,这个容器的话它是有库容限制的,如果产能跟不上,那么他就会拒绝这个订单。

而事管确定什么呢?事管是需要确定完成这个订单任务需要用什么工艺来保证客户的质量要求,现有的设备能不能满足客户的参数要求等。还有负责财务的主管也要算下这单能赚钱不,拿出物料清单大致核下价,看会不会亏本。那么以上几个角色都确认这个申请可行以后,这个申请就处于了待发起的状态。

审核我们在一生二中会详细说明,这里只说下审核的设置是仓库的功能,上级库可以设置下级库的哪些业务我需要审,哪些可以不审自动通过,具体的设置在后篇中会详解。

4、加减分合

也许有人会说直接执行就行了,为什么还有一个待发起状态呢?那是因为在我们的实际生产中当中,销售和生产一般都是两个部门。销售订单交付给生产部门的时候一般会合并或者分解。就比如我十个销售人员,每天多个销售订单需要合并以后一起转给生产部门。或者是有客户有一个大单,那么销售部门他也是按月计划或者按周按天来做一个交付的计划,并把这个计划发送给生产部门。所以在申请和执行当中有一个分单和合单的过程,这个过程是子库到父库自动汇总或者手动选择性汇总得到的,而这个过程我们就叫发起。

5、加减发起

分单合单后的发起和最开始提交的发起,是总和分的关系,这个新的发起同样需要三个分管角色一块儿确认。发起的时候谁都可以发起。也可以设置为固定角色发起。比如一般公司是由销售发给生产部门,那就是由资管来进行发起。但是有的公司产能是固定的,所以生产部门会发一个固定的单给到销售部门。就是说我每天只有这么多的产能,客户给你下的订单的多或少,我都产这么多。也有的公司是由技术部门来进行生产订单的发起和安排。因为技术部门同时要兼顾销售部门的订单以及生产部门的产能状况来做合理的安排。

这个发起功能就是我们的执行前的计划。而这个计划也有的公司叫排程系统,也就是我们的生产排程。生产排程会调动公司所有的资源和仓库进行合理的组合安排。计划做得再好,由于所有的资源和仓库都在处于变化当中。所以生产实际过程当中的计划变更是经常常见的现象。而每一次计划变更又是依赖于所有仓库和资源的变动。所以会造成非常多的排列组合。因此排程系统也称为工业ERP上的明珠。我们在后面第五章中再详解介绍。

6、加减调配

加减接下来的操作是调配,也就是划库操作。调配就是我们说的就是企业的调度,也就是资源从一个库到另一个库,这样不断的延伸就形成企业的流程。调度后我们知道事管可以把一个库的资源加减分解为多个资源的加减,例如制造加一个产品就会消耗减一些原材料。调度资源分为库内和库外,一般认为库内就不需要调配了,其实这是一种误解。举例来讲就是比如说一个车间生产了100件商品。但这100个是为2个订单合并起来生产的。那么这100件商品如何分配到这2个订单上呢?就是资管要做的工作。

当然资管可以设置一个公式,比如说每生产一件是平均分配,还是说先A后B呢?调配划库如果没有加减,只有出入,那么就是进销存。如果划库涉及库内的加减,那么就是生产和加工。加减的调配一般也是资管来做,申请根据业务需要谁发起都可以,资管审核通过后就可以提交这个要求,然后其他两个角色库管和事管来进行确认,确认完了后,资管就可以进行调配了,注意调配是一个功能权限,系统默认是三个管理角色都需要确认,当然也可以事先把权限划定给一个人,就不用三方都确认那么麻烦了。

7、加减计划

加减的下步就是加减计划的确认。我们已经讲了,调配及调度的工作已经完成。但是这个调度的执行需要分多少次完成,这就是调度计划了,调度同样需要另外两个角色来确认。调度计划做好以后,剩下的就是执行。计划不是必须做的,因为只要你调配资源,那么就存在两个库管之间的资源转入和转出了,但是如果数量大,时间长,需要分很多次完成,是每个周期数量一样呢,还是周期性的数量波动呢,还是每次都是临时确定数量呢,这些都是可以通过配置计划的方式完成。配置计划就是企业的资源计划,资源计划设计的环节和变量都非常多,和火车票的原理一致,一个节点变化会影响到后续所有环节的变化,所以排程系统才称为工业领域的明珠。

加减计划其实就是把一个加减用另一个后一组加减来平衡的过程,就是任务的输出生成了任务的输入,这是两个不同的加减,但是在同一个库里发生的操作,一旦生成了另一个加减,那么就开始了循环,即新增的这个加减例如生成一个产品是输出,原料需求是输入,一旦生成了这个新的加减,系统会自动到最初的流程去,即申请流程,所以计划就像一颗石子投入到了水中,会衍生到很多其他的子库泛起水波,而这个路径是可查的,因为是可以溯源到的。

以上我们已经将未开始的加减说完了,看起来有点复杂,其实很多小企业,没那么多功能需求的,所以有的环节就不会存在,直接申请就会跳到下步执行,没有那么多弯弯绕绕的。接下来就要开始执行这个加减了,执行的人员就是这个加减所在仓库的库管。

二、进行中的加减

进行中的加减我们分为三个步骤来说,分别是准备、执行和确认三个环节,其中准备是执行的前提,而确认是对执行结果的检查。

1、准备加减

加减的计划发出来后,库管的事情就来的了,因为库管要执行这个加减,但我们知道你要生产一个产品,肯定需要原料,这些原来没准备好之前,是生产不了的,所以有一个准备的环节,什么是准备好呢,就是当物料全部都入库了,然后生产工人就可以用设备生产出产品来,这时候减物料加产品才是真正的加减。当然加减的准备不仅仅是物料,还有工人师傅、生产设备、水电气等等,这些都是准备加减的范畴。准备有待准备,准备中,已完成三种状态,分别可以查询哪些任务处于那种状态。

2、执行加减

执行加减一般也有未开始、执行中、已完成的三种状态,未开始的可以点击开始或者取消任务,进行中的可以点完成,也可以返回未开始状态,已完成可以提交确认,或者发现没做完也可以返回进行中自己再补下。这些操作都是库管操作和完成的,也有可能库管有多人一起完成的,都是可以的。有的任务执行过程相当短,就只有未开始和已完成的状态,都是可以自行在后台对任务状态进行提前设定的。

3、确认加减

库管执行完成会自动会通知资管和事管。因为你不仅要符合工艺质量要求,而且要得到资管的交付数量的确认,如果这个任务是群众发起的任务,那么群众还需要进一步的确认,例如报事报修你说业主的水龙头修好了,一般是需要业主确认的才能收费的。只有所有人都确认完成,那么这个任务才算完成。当然为了管理方便我们可以在模板的设置当中可以设置部分的角色确认即可。

加减最后的操作就是加减的确认。执行加减,每次库管执行完加减后,按默认规则来说都是需要得到资管和事管的确认的,当然也可以提前设置不需要确认。如果发起人是群众,那么还需要群众的确认。确认完以后,也等于任务的完成。一旦完成加减,那么库存的数据也随之改变。同时会记录到已经加减的数据记录当中去。这样和库存的查询就进行一一对应了。

4、处理盈余

但凡执行了加减,就有可能和最初申请数量不一致,例如销售说客户订100个,结果你应为某种原因生产了102个,或者只生产了98个,那么这个就和预期值不符了,这些多出来的,或者不足的怎么办呢,这就需要资管和客户沟通后,来决定补、加、退等操作,这是输出部分的盈亏。那么输入部分也有盈亏的,例如我们的原料剩下了一些,这时候怎么办呢,那就是退给公司呗,但有的服务性的工作例如装修等,退回供应商或公司都不太可能,很多时候就是在不同的项目中互相调用,因此当原料剩余时,资管可能会查看临近的项目装修情况,就会把原料调配到新的装修项目,或其他的本地临时存放点,这些都是资管做的事情。即有了盈余,就调配盈余,然后库管再执行出入库,最后实现一个什么呢,那就是资源是从0开始的,最后也必须回到清零的状态,才算这个任务整体的完成。

这样我们就跑完了一个完整的工作任务。这是从数据层面说的,我们怎么配合业务完成,在设置层面你可以定义为这个任务的加减代表的是销售还是采购,还是维修,还是退货,还是测试或者借用等等都可以。事后对这些分类进行统计的话,我们就可以得到某种业务的全部数据。

以上的站在资管的角度我们跑完了一个完整的资源加减任务,虽然过程很冗杂,但原理其实很简单,因为整个道家管理体系中,就只有资源一个对象,而且加减也只有一个平衡法则,那就是有输出必定有输入,输出输入必须平衡,平衡则代表任务完成。

三、已完成的加减

统计前面的执行完成并得到了确认后,就转为已完成的加减任务了,这些加减任务,对这些已经完成的任务,都是企业业务的真实记录,这些记录会转到财务去核算企业的成本和利润等,也可以通过大数据结合AI的分析,找到业务的变化规律,从而改进业务。

所以已完成的加减不要以为就没有价值了,这些加减记录是企业经营活动的唯一凭证,具体的作用有以下三个方面:1是财务核算的唯一依据,2是业务统计的唯一源头,3是人工智能的唯一粮食。下面我们分别来讨论下。

1、财务的核算依据

后面的介绍万归道篇中,我们会介绍所有的加减都会自动归入财务,作为原始的业务凭证记录,财务会根据价格来计算这个加减任务的发生的费用是多少,并作为科目进行记账处理,而记完账后才能合并和财务的报表,才知道到底亏还是赚。所以任务的完成并不是业务终点,业务的终点是财务的试算平衡。

所有已完成的任务,可以看到哪些已经推给了财务做原始凭证,哪些财务审核例如报账有问题被退回要修改的,企业要实现业财一体化,就需要定义这些加减任务,哪些可以自动转到凭证,自动计算金额,自动转为科目,自动试算平衡,不仅减小财务的手算工作压力。最主要的功能是这样设置了自动化后,就可以反向从财务设置一些比如利润成本指标之类的,来反向控制业务的发生了,一旦财务端设置控制参数后,业务端在发起的时候,会自动比对财务的金额限制,从而达成企业控制利润成本的目的。

2、业务的统计源头

后面的二生三加减中,会涉及大量配置企业的何种业务规则,但这些业务规则设置得到底合不合理,是需要从这些已完成的数据中来统计分析对对比检验的,如果企业的实际运行下来发现利润不达标、质量不过关等问题,就需要调整这些业务规则,这是一个持续性的过程。而要实现这一持续优化的目的,就需要统计已完成的这些实例数据,统计的方法还是以资源、仓库和加减做取并集或交集的分析和统计。

3、AI 的训练基础

我们知道一般的业务是通过输入控制输出,而AI则是通过输出反向求输入,所以企业的AI训练需要大量的业务数据来支撑,这部分我们也留到后面的三生万业务的篇中去分析。

章节三、资源的查询

资源加减后的查询就很简单了,那就是资源经过加减后还剩下多少,就是查询库存的意思,查询库存是实时的查询,因为业务在不停的发生,所以库存也在不停的变动,那么一般我们需要查询哪些数据呢,首先我们必须选择一个仓库,然后再选择一种资源进行查询。

一、业务资源的查询

1、共有多少:共有多少就是还剩多少,也就是累加总和减去累减总和,就是剩余的数量,也就是库存的数量。这些累加和累减是可以点击查询具体的历史记录的,每条记录都记录了这次的加减的过程记录,包括谁申请的,谁发起的,谁执行的等等。

2、能用多少:库存数量并不是你能用的数量,因为有的库存可能正在执行加减,这些占用的数量,你是不能调用的,因此能用多少就是你剩余多少减去你待减数量后多少后剩余的数量。这些才是你可用的数量,同样也可以点击查询占用数量的合计,再进一步查询分别是哪些任务正在占用着资源的。

3、将有多少:就是这些能用的数量,由于库外的还会不断的入库,库内也可能是因为加工在不断的增加,这样在未来你就会共有多少。同样也是可以点击查询的,并且也支持查询这些待加数量隶属于哪些任务的。这个查询是固定的数据项,任何一个加减操作,都会引发这些数据的变动,而且会随着仓库一层一层向上自动做统计,因为任何时候查询都是实时数据。

二、固定资产的查询

1、资产的清单:我们会在一生二仓库篇中说明资源是怎么构成仓库的,例如一台生产设备买进来是资源,安装后就是仓库了,因为它要承担零件的进出和制造,但是这台资源的设备就被占用了,直到最后拆除。所以占用着的资源就可以看做是固定的资产,我们把全部的占用着的资源拉个列表出来,就是我们的固定资产的清单。

2、资产的折旧:这个清单拉出来后,因为都是买进来或者租进来的,所以都有价格,但是其中部分设备是随着时间要逐渐折旧的,那么算上折旧,就要用当时买的价格减去折旧的价格,就是剩余的价值。

3、资产的残值:那么把全部资产的残值加起来,就是企业的固定资产价值,所以仓库里是有两种资源的,一种是占用的固定资产资源。另一种是就是前面的业务资源,这两种资源的计算方式是不一样的。

以上的查询公式看起来很简单,不要以为统计就很简单,因为仓库是一个树形结构,一般的企业有几百上千个还好说,有的建筑企业和制造型企业多达几万甚至几百万个仓库节点,数据一级一级向上汇总,这就会实时统计带来很大的压力,而且子库太多也给企业带来更高的管理成本,这个我们也留到后面的一生二仓库篇中去讨论。

以上就是我们从资管管理者的角度,实现的三大业务管理功能,即资源的目录,资源的加减,资源的剩余,完成我们对一这个资源的分析和梳理后,下一章我们将和小后半一起推演这个一资源是怎么变成二仓库的,以及仓库具备哪些功能,又是怎么来实现企业的日常管理的。

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

题图来自Unsplash,基于CC0协议