1,简介
产品名称:生产报工(原"码上制造")
愿景:为小微企业提供移动化的、可智能协同的小型生产管理系统,赋能并提升制造业小微企业数字生产力.
帮助文档 alidocs.dingtalk.com/i/p/nb9XJ1l…
如何安装
2,产品介绍
2.1 详细描述
为小微企业提供免费的、移动化的、可协同的小型生产管理系统,核心功能围绕生产过程、仓储出入库,展现企业进销存DKA数据、产能数据。
该系统同时沉淀行业化平台能力,包括制造业主数据、行业连接器,连接生态插件,满足中大企业的定制化、个性化需求。
2.2 产品核心设计理念
围绕生产订单的,高效率的移动化协同能力,加强过程管理。
通过沟通即业务和一物一码的设计理念提升生产管理效率。
功能能力差异化
- 进销存仓储能力和生产过程管理部分,是底座能力,差异不大
- 一物一码,来料、半成品、成品、仓位等统一沉淀数字身份ID,全链路管理
- 强大的连接和高度的自定义能力,包括流程表单和数据展现部分
- 接口全面开放,钉钉生态/企业可在底座能力上继续拓展能力插件
交互能力差异化
- 强化移动端能力
- 简单明确易上手的交互体验,界面功能符合40-50岁工人可操作的认知水平
协同能力差异化
- 结合钉钉的IM、群、DING消息、机器人等协同能力,拓展管理半径,管理直达一线,可以实现真正的事找人、而非人找事,用消息和待办串联起员工一整天的工作任务,明确定义每日工作SOP
2.5 核心卖点
下面只是提纲和摘要,还要大量细化;
-
表单模板多租户,客户可以自行修改,增加自定义字段;
-
因为基于OA审批表单,所以用户体验无缝衔接;
-
找到生产制造企业高频业务切口-计件报工和计件算薪;
-
生产过程统计,节约人力成本
before:
目前4个文员,专门做车间产量统计的工作。
如果用了我们的产品,这4个人力直接节约掉。
after:
班组长移动化报工,不需要单独安排文员;
节约人力成本是最直接的价值体现。
- 生产进度透明化,管理更及时
before:
excel统计,每天下班用生产流转卡记录在纸上,第二天上午文员统计成excel,有时候没提醒,仓库那边成品就忘了及时登记,耽误发货时间。
after:
当日进度当日记录,甚至一天可以录入多次,降低信息延迟,增加及时反馈。
- 工人绩效统计更便捷、减少出错,老板每天掌握薪资支出
before:
文员纸质统计,打印出来,每天或者每周,让工人每个人签字确认,耗时耗力,有些由于时间长了、记不清楚,翻旧帐找起来困难;
after:
生产过程计件数据、工时数据,可打通“计件薪资”应用,自动同步。工人可每天在手机上快速确认计件数量是否正确。
- 便于生产过程的质量追溯
before:
问题不知道出在哪个环节,事后很难复盘。
after:
(1)领料过程,依据使用物料的批次码可以溯源;
(2)生产过程,数字化记录责任班组、工序工人、生产周期;
- 发挥钉钉信息流与协同优势:事找人,而非人找事
before:
老板催销售,销售催车间,车间派人去盘点一下库存,才知道产品可以发货了;
老板问订单进度,文员要把好几张excel汇总一下,才能看明白;
after:
生产管理群,智能机器人自动提醒:及时查看生产任务、及时领料、及时报工、及时确认工资等
3,产品详细设计
产品截图
3.1 为什么做
- 当时和生态品合作,结果不理想;
- 当时强调数字资产,
- 50人一下组织,没有人愿意服务;
- 当时目标只有规模化;
国家:统计的百人以下制造业组织数量,94%的制造业是100人以下。
可持续的规模化的来源:百人以下小组织
特征:
(1)付费能力差
(2)服务商赚不到钱,不愿意服务
(3)但有生产管理精细化的需求
(4)业务数字化基本为0
3.1.1 这个品是三方做还是一方做?
要一方做
为什么?
共识:
(1)服务商做的付费品,这些企业不愿意付费也用不起,规模化起不来;
(2)就算服务商都做免费品,但系统孤岛后,没有网络和规模效应,企业和企业之间没法快速协同;
(3)服务商不愿意服务这类企业,挣不到钱,商机不多,也会逐渐流失,钉钉生态无法繁荣;
只有钉钉同时具备这几个能力:
(1)连接能力:连接人、系统、设备...
(2)平台普惠能力:免费
(3)只有钉钉可以形成平台和网络效应
(4)钉钉平台的高效率移动化协同基座:IM、移动OA
为什么做了这个品反而能给服务商引流:
现在平台上的组织规模分布和国家没差别,我们其实给不到服务商更多商机;
现在有免费品,企业可以低成本试用,试用觉得还OK,发现有更多需求,我们就导流。
这是一个长线必须做的事情:路从窄到宽
4,架构设计
4.1 和OA协作
场景
码上制造是以钉钉平台能力为底座,OA审批为承载界面来为用户提供服务的,所以用户在界面还是操作上更多的使用的是OA审批的原生能力。不过OA是通用能力,无法满足码上制造这种行业纵深领域的能力,所以需要业务系统与OA之间进行协作。
举个例子,数据同步场景:用户进行表单数据提交,在OA侧数据都是以『大json』的形式存储的(schema)。但是很多地方需要对数据进行业务化处理,所以数据需要回流到业务系统的数据库中,这个数据回流的过程就是数据同步。
5.1 表单数据的一致性
背景
在大纲4.1提到过,与OA进行协作场景里会进行数据同步,同步的就是表单的数据。
问题
数据同步过程的问题可以归纳为两大类
- 数据一致性
-
- 数据丢失(OA库有,业务库没有)
- 数据不一致(OA和业务库都有,但是业务库的数据版本不是最新)
- 数据实时性
-
- 同步耗时长,导致用户操作完立马打开详情页查看业务数据时,查询失败(数据未落库)
方案
首先我们是基于MetaQ消息的方式进行数据同步,那么基于该方式我们如何保证数据一定能落库并且数据版本是最新的(不漏更新任何一条数据),并且保证时效性?
- 记录持久化
通过落库的方式将同步记录持久化起来,只要审批表单消息能够正常投递到业务系统,就可以对数据进行状态监控,可在异常情况下进行数据回放和溯源,是后续解决方案的根本。
- 零信任(侧重实时性)
这里的零信任主要做的是"实时查询",不依赖消息body体里的快照数据"。因为极端场景下会出现并发更新的问题,那么在MQ无序消息特性里面,很有可能出现ABA的问题。所以每次进行实时查询,将这个保障机制交给OA审批,我们只要根据数据ID在审批数据库中获取最新的内容就可以低成本解决这个问题,保证了与OA审批的数据一致性,也是一个非常重要的方案。(参考RocketMQ的消息存储以及MySQL的redo log的保障机制)
- 异步校验(侧重实时性)
MQ开始进行同步前,通过EventBus(事件驱动)发送一个延时事件,在3s后会进行数据反查校验同步状态,如果同步状态为失败,则触发数据更新,并且有重试机制(3次)。目的是在最短的时间内监控到异常数据并进行补偿操作。
- 链路异步拆分(侧重实时性)
数据同步的过程中我们定义了生命周期以及拓展点,比如beforeInsert、afterInsert这种拓展点,在里面可以针对不同的模型数据进行不同的定制逻辑,但是本质是一个Thread线程,链路耗时是每个操作之和,所以操作越多耗时越长,同步性能越差。
所以核心就是将链路操作的数量降到最少,即把非核心的流程通过异步的方式执行,只保留核心同步流程。异步的方式有两种:EventBus,MQ
- 定时调度(侧重一致性)
结合SchedulerX定时调度框架,每隔1分钟都会将同步记录表中异常或失败的数据拉取出来,批量进行数据补偿,时效性比异步校验要低一点,但是安全性会更高一点,因为每分钟都会调度,直到同步成功为止。
- 按需拉取(兜底,侧重一致性)
极端场景下,接口查询的数据未同步到业务库中,此时会通过HSF接口根据数据ID进行数据补偿,将数据同步后进行后续业务操作并返回给用户侧,它的执行时机是侧重于用户需要时拉取,减少全量数据对比的性能开销。
- 数据对账(兜底,侧重一致性)
用户录入但是不常用的数据,其实丢失的情况下用户是感知不到的,这就可以通过ODPS的数据对账,每天凌晨与OA审批的数据进行全量对比,找到缺失的数据,进行数据补偿。
5.2 根据身份分层
| 身份 | 角色 | **** |
|---|---|---|
| 生产报工用户 | 钉钉管理员(去 OA 后台配置) | 只能访问本组织的数据,能够对本组织的数据做CRUD.无法访问其他组织的数据. |
| 老板权限 | ||
| 生产管理员 | ||
| 班组长 | ||
| 仓管员 | ||
| 服务商 | - | 能够访问别的客户组织的数据,但是必须有绑定关系.通过数据库表ipl_provider_custom_relat实现 |
| 平台管理员(即钉钉内部研发) | - | 只能访问任何组织的数据,能够对任何组织的数据做CRUD (当然还是有权限细分,保证数据安全性) |