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

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Microsoft Azure Blog
Microsoft Azure Blog
Cloudbric
Cloudbric
I
InfoQ
V
V2EX
博客园_首页
The Register - Security
The Register - Security
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
S
Secure Thoughts
Vercel News
Vercel News
Forbes - Security
Forbes - Security
云风的 BLOG
云风的 BLOG
PCI Perspectives
PCI Perspectives
L
LINUX DO - 最新话题
D
DataBreaches.Net
H
Hacker News: Front Page
Application and Cybersecurity Blog
Application and Cybersecurity Blog
B
Blog RSS Feed
A
About on SuperTechFans
N
News and Events Feed by Topic
Apple Machine Learning Research
Apple Machine Learning Research
Help Net Security
Help Net Security
Attack and Defense Labs
Attack and Defense Labs
N
Netflix TechBlog - Medium
Spread Privacy
Spread Privacy
F
Full Disclosure
Recorded Future
Recorded Future
AWS News Blog
AWS News Blog
博客园 - 【当耐特】
The Cloudflare Blog
T
Threatpost
T
Tor Project blog
Google DeepMind News
Google DeepMind News
C
CXSECURITY Database RSS Feed - CXSecurity.com
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Recent Announcements
Recent Announcements
M
MIT News - Artificial intelligence
A
Arctic Wolf
C
Check Point Blog
Stack Overflow Blog
Stack Overflow Blog
T
Threat Research - Cisco Blogs
Security Archives - TechRepublic
Security Archives - TechRepublic
Hacker News - Newest:
Hacker News - Newest: "LLM"
WordPress大学
WordPress大学
Cyberwarzone
Cyberwarzone
小众软件
小众软件
C
Cyber Attacks, Cyber Crime and Cyber Security
P
Proofpoint News Feed
Security Latest
Security Latest
The Last Watchdog
The Last Watchdog

人人都是产品经理

为什么你的产品找不到差异化?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混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
制造业信息化平台的演进之路
PM小刘 · 2024-09-12 · via 人人都是产品经理

当前国内政策和市场都在推荐生产、制造业向数字化、智能化和信息化转型,而汽车制造业则是其中较为先进和典型的代表。本文讨论了信息化制造平台在制造业等其他同类型行业中的应用,供大家参考。

2015年5月8日,国务院印发《中国制造2025》,是我国实施制造强国战略第一个十年蓝图。

2024年4月30日,《南华早报》独家发布文章《中国制造2025:中国实现了大部分制造计划目标,证明美国关税和制裁无效》。

文章提到:根据十年前出版的官方书籍和其他权威来源,《华盛顿邮报》整理了此前根据该计划提出的260多个目标。这些目标涵盖10个关键领域,并且已经实现了超过86%,其他一些目标可能在今年晚些时候或明年完成。同时,电动汽车和可再生能源生产等一些目标已经远远超出预期。

新能源汽车的发展这几年有目共睹,本文主要想谈谈关于笔者眼中的汽车制造业务信息化平台演进之路。

随着汽车业务的发展以及信息技术水平的日益提升,为了进一步地提高经济效益和发展质量,制造业企业需要引入一些新兴技术。

新兴技术的使用方向主要有两类:一是信息化制造平台,用于内部的工作提质和管理提效;二是高端设备制造,提高生产运作效率。

本文主要讨论信息化制造平台在制造业等其他同类型行业中的应用。

一、平台萌芽期

平台萌芽期,也就是信息化初期,企业主要的目标是完成无纸化的转变。

无纸化的转变,包括但不限于大幅度的降低纸张的使用和存储,提高数据采集和使用准确性,提高企业信息的安全性以及提高组织和个人的工作效率。

平台萌芽期的建设,通常会采用两种方式:外部采购和自主研发。

信息化建设前期阶段,如何选择引进方式,是企业的一大难题。笔者认为,要从多个方面看待这个难题。

首先,要看企业的规模。如果是中型企业,建议是采用外采,因为外采成熟度高、使用门槛不高,企业不需要投入大量的人力、财力和物力,可以把精力更多地放在业务上面。同时,因为中小型企业在信息化方面的经验不高,采用成熟的平台可以帮助业务使用部门拓宽视野,提升信息化意识,也有助于内部学习借鉴平台的建设思路,为后面平台的改造或者重构积累经验。另外,对于小型企业来说,如果没有部署资源或者希望进一步的减少运营成本,可以考虑外采SaaS软件,根据实际情况选择版本及购买增值服务。

其次,要看企业的业务。如果企业的业务不算复杂,且通用性比较高、业务稳定的情况下,根据投入产出比(ROI)来决定是否外采;相反,如果企业的业务复杂、特殊,并且市场上没有非常成熟且能落地的方案,可以考虑自研。

最后,要看企业的场景。对于大型企业来说,虽然有自己的研发资源,但资源是有限的,企业需要考虑如何让有限的资源发挥出最大的价值,即人效最大化。因此,对于系统采用自研的企业来说,应该把资源侧重于核心业务系统的建设上面,特别是和企业核心数据及核心流程有关的系统。

以德邦为例,在潘程的《变现之中,冲破数字化转型的囚笼|对话德邦CTO殷皓》文章中,关于自研还是采购,德邦快递高级副总裁、CTO殷皓提到:

“在自研还是采购的选择上,德邦的原则是除了核心的业务系统,其他的都采购。这个核心业务,就是掌握着公司核心数据的各类体系和工具。例如中转管理体系、运力调度体系、快递员调度中心等等。这些核心业务操作系统买不到,也确实是德邦的数据核心。而像财务系统、人力系统、营销系统等则没有必要自研。很多企业需要想清楚一个点,自研技术投入那么多资金,是否真的帮企业建立了壁垒?”

笔者认为,虽然自研能够为企业带来高度定制化,切实符合企业当下的业务发展,但也存在一个缺陷:很容易成为企业信息化转型的包袱。

因为自研的质量和发展很依赖于研发团队的规划能力,如果研发团队过度地专注于眼前的业务和问题,加上过长的研发周期及企业未来发展研判的意识缺乏,会导致整个系统的建设严重偏离企业发展轨道,最后成为企业的一个负担,只能选择重构升级或者废弃系统。

二、平台成长期

无论是自研还是外采,平台经历萌芽期建设后,企业能够看到平台所带来的直接或间接价值,也会给企业带来一些信心。

当然,随着企业业务及信息技术的进一步发展,平台进入到成长期。

在这个阶段,企业会遇到各式的决策难题:如何解决各系统之间的离散化,如何打通系统之间的集成关系,如何更好地稳定运行和升级系统等等。

对于平台成长期来说,重点要关注两个方向:一个是信息化建设的统一性,另一个是平台自身的稳定性。

1. 构建统一性,建立基础

虽然企业内部各组织和各业务都或多或少建设有信息系统,但是各组织和各业务自成一体,孤岛现象严重,缺乏统一性。

以美的为例,美的集团董事长兼总裁方洪波在访谈中提到:

在2012年之前,美的已经是一个高度分权的组织,每一个事业部自成一体,以至于所有的信息系统高度离散化,缺乏一致性。所有信息都是孤岛,不能集成,更不可能自动分享。

对于美的来说,2012年数字化转型的契机是集团上市,由原来较为分散的二级产业集团统一为一个集团。统一为一个集团后,美的面临了诸多挑战:流程不统一、管理方式不统一和数据不统一。对于家电领域来说,光IT系统就有100多套,大家也不统一,就没法组成一个集团,没法统一往前跑。

在这种情况下,美的集团的战略就是:一个美的,一个体系,一个标准。

基于这个战略,美的重构了所有的流程、IT系统,统一数据的标准,这也是美的数字化转型的基础,整个工作到2015年上半年才全部完成。

因此,笔者认为,制造业企业正式数字化转型前需要进行整体性地评估:一是评估企业业务的发展能力和趋势,即转型必要性;二是评估企业的资源能否足够支撑数字化转型的变革即:转型可行性;三是评估企业内部关键领导的转型决心,即转型重要性。

如何构建数字化转型的统一性?

一是意识的统一。意识优先于行动,企业既然决定信息化迈向数字化的转型之路,那么领导班子就要做好长期主义的打算,由上而下表达企业转型的决心,要不断主动地去决策和推动。

在此,引入美的董事长方洪波访谈中提出的关于数字化转型的真正内涵:数字化技术不再是单纯意义上的技术,技术背后驱动的是整个企业的方方面面,是对全价值链的重构。

同时,他还提到:作为掌舵者面临的挑战与压力,数字化的推动一定是一把手工程,如果一把手不推,永远推不动。一把手想推,再大的困难也会解决。有时候这个过程当中就是一口气,一口气突破了、顶住了,可能就是一片新的天地。有时候没有憋过去,又回到起点。

二是标准的统一。标准是稳定的基础,标准代表着一种秩序,而数字化的转型,需要这种秩序。

业务的标准化,重点是要把企业内部已有的文件、制度以及约定习俗的程序进行整合和梳理,定义好各环节的关键信息和关键事件,这个是业务信息化的一大基础;系统的标准化,重点是要把系统中关键核心的业务数据定义好标准(如命名约定、类型、值域等),这个是系统建设的一大基础。

值得一提的是,制定标准并不代表固化标准,随着数字化转型的不断深入和理解,标准也需要不断地迭代和更新,甚至需要衍变(通用标准和专业标准)。

三是建设的统一。重复造轮子是早期建设的时候不可避免的一个问题,而建设通用服务平台,是解决这个问题的关键。所谓通用,主要是指和企业业务无直接或者明显关系的系统和功能,通过一个通用的综合性中心共享服务,即服务基座。

该服务基座,包含但不限于身份认证管理平台、低代码开发平台、能力开放平台、基础服务平台(如:文件服务,日志服务,网关服务,运维服务,流程服务,定时服务等)、共享交换平台、大数据平台、知识管理平台、项目管理平台、安全管理平台(如:漏洞管理,代码审计等)。

2. 构建稳定性,做好保障

一个系统能否稳定地运行使用,会极大影响业务及用户,进而影响数字化转型的进度。

系统离不开用户,而用户良好的反馈能够加强系统的升级迭代效果。因此,为系统用户提供简单易懂的操作和稳定的使用体验,就是数字化转型的基础。

系统的稳定性,主要是指系统在使用运行的过程中遇到各种预期或不可预期的事件时能否持续提供稳定可靠的能力。

构建稳定性,主要有两个方面:技术和人员。

1)技术方面,一个是系统的架构设计要能够灵活地面对不同场景下的风险,如容灾策略、故障策略以及负载策略,都需要在系统建设的时候有所体现;二个是系统的变更过程要能够应对失败的风险,如灰度发布、版本回滚等;三个是系统的故障要能够及时的响应,这个需要工具或者平台来支撑,比如监控告警平台、风险预测平台等。

2)人员方面,无论是个人还是团队,都会多多少少出现一定的不可控因素。对于人为因素的防控,主要通过规范、机制和预案来避免。

  • 规范,从整个产品的生命周期来看,包含但不限于项目的管理规范、需求的设计规范、代码的编写规范、功能的测试规范、产品的上线规划以及运营规范等。
  • 机制,主要是指明确事故的责任以及响应流程,能够确保事件出现时,相应的责任人能够知晓自身的职责以及需要执行的操作。
  • 预案,通常会被忽视,而且也比较麻烦,因为它需要各团队之间的配合和协调,不过它很重要,特别是对于比较核心的业务系统来说,一个良好的紧急预案能够极大地提高故障的排查效率,降低故障影响的程度和范围。

三、平台发展期

平台通过成长阶段的沉淀,已经有了很好的发展基础,企业也将迎来全面数字化的进程。

关于全面数字化,此处引用美的集团副总裁张小懿访谈中提到的话:“到了2016年以后,我们业务发生了一个重大的变革,从以前层层分销的模式,以产定销的模式变成以销定产。从原来的大订单供应模式,变成了碎片化的订单模式。面对不确定性,对交付的柔性与效率提出了很大的要求。那时候我们做了数字化2.0的转变,支撑业务的转型。同时我们也做了一个事情,用IT的术语来讲,就是由结果管理型的系统,变成了过程支撑型的系统。因为只有过程支持型才能够把数据的效益给它放出来,用数据来驱动运营。”

笔者认为,柔性与效率是平台发展期最为需要关注的能力。对于一个平台来说,如何把结果信息的系统转变成过程信息的系统是一个不小的难题。

下面,笔者将从单个平台出发,分别从技术、产品、运营、管理以及安全五个方面聊聊平台在发展期的规划。

1. 技术

对于一个大型制造业企业来说,不同地方不同部门的业务并不是完全相通的,存在差异化。因此,对于业务系统来说,如何为必要的差异化提供服务是第一个难题。

笔者认为,可以参考市面上B端SaaS化的策略,把系统拆分为标准版和定制版,标准版企业全方位通用,仅保留最为核心、基础的功能和服务,关于需要定制或者非核心、基础的功能,采用模块配置化的方式实现。

无论是上述的哪个版本,都需要考虑部署和后续的优化。

关于部署,标准版和定制版需要分离,支持独立部署(服务器委托管理和本地部署),同时支持微服务的架构设计,进一步细分系统版本,拆分业务服务和基础服务,支持服务之间的相互调用和升级。

以唯品会的微服务整体架构为例(从上到下):

  • 前端应用:唯品会、云品仓、唯品仓、唯礼小程序、线下店导购、外部应用;
  • 中间层:移动适配、PC适配、多APP适配、选购线、下单线、用户线、开放平台;
  • 电商平台:用户中心、商品中心、店铺中心、营销中心、下单&订单中心、交易中心;
  • 供应链平台:供应商系统、中央库存系统、仓储系统、物流系统、海淘系统;
  • 财物系统:财务系统、发票系统;
  • 基础服务:地址服务、风控服务、品牌服务、类目服务、商品搜索、推荐服务、消息推送。

(原文参考:《唯品会微服务架构演进之路》)

关于优化,如果是核心、基础的功能优化,直接迭代标准版,定制版根据实际情况选择升级;如果是完全定制化的功能优化,建设在定制版的基础上开发新模块,独立代码和服务,维护和调用不受其他模块影响。

其次,依赖于平台成长期中建设的通用服务平台,适当衍生适用系统及业务的个性支撑应用。以日志为例,通过日志服务定义系统重各模块的关键操作链路,结合可视化工具为系统管理者提供查询和统计服务;以数据为例,通过大数据平台根据数据使用的频率、热度等因素分离冷热数据,不仅可以提升数据的使用性能,还可以降低存储成本;以报表为例,结合BI工具和大数据平台建立一条从数据采集到数据应用的大数据分析全链路,为领导管理决策提供支撑。

最后,企业如果后续有海外的业务,还需要考虑系统的国际化配置。国内版和国际版最主要的区别就是语言,不仅仅是语言的翻译,还有语言的样式以及本地化的内容(如时间、货币、常用语等)。从技术角度来看,国际化配置的实现主要依赖于将系统所显示的文本内容从固定的代码中分离出来,作为独立的国际化资源存储,根据实际的用户使用场景来动态加载显示的内容。系统的国际化主要分为前端国际化和后端国际化,无论是前端还是后端,都需要做好代码的编码规范和指导手册,明确各角色的职责分工(开发、翻译等)。

2. 产品

系统是否能够健康有序地发展,产品设计是关键的一环。

系统拆分为标准版和定制版后,作为管理需要特别重视需求地管理。

  • 对于标准版,设置一名统一的需求管理人员,该人员需要有全局意识,理解并熟悉系统全业务,对于标准版的需求新增或业务调整都需要组织专门的评审会议,经会议综合评估后决策需求的可实行性。
  • 对于定制版,如果是业务范围较大,建议专人专版管理,独立负责需求的收集和分析,对于需求的决策需要知会统一的需求管理人员,如果是业务范围不大,可以合并专人管理。

为了能够满足业务的高效运转和使用,系统需要满足产品化的设计。产品化设计的核心是复用,但不是传统意义上的完全照搬使用,是指能够通过配置实现的功能复用。

产品化的难点在于如何识别和抽象共性需求,再结合配置、插件、二次开发等方式来满足功能的复用,这是一个阶段性的设计思路,是产品经过一定的考验之后得到的结果。

市面上复用最可行且成熟的例子就是流程配置化,通过通用的功能设计面板来实现不同业务场景流程。

冗余,是系统发展期的普遍性问题。随着产品设计人员对业务理解的不断深入,消除冗余归类模块就成为了产品设计人员的必经之路。

消除的思路有很多种,常见的是根据系统的角色来划分,比如划分系统配置类模块提供给系统管理角色,部分适合下放的系统管理模块提供给业务管理角色,系统通用无权限的功能模块提供给基础角色,专业业务模块提供给业务管理角色等。

除了产品化设计,人性化设计对于产品的体验来说会更上一层楼。对于制造业系统来说,大部分都是传统的后台管理设计,那么除了被动式的提示弹出之外,还可以考虑加入主动式的提示设计,结合算法模型,加入AI助理的概念,根据当前用户的画像主动为用户推荐业务的使用或者办理提醒 。

最后,引入高级的组件也是一种不错的选择,例如高级表格(支持列显示定制、列过滤、列排序、数据复制)和高级表单(支持不同场景下的信息填写)。

3. 运营

随着版本和环境的增多,系统的运维部署和运维监控也需要考虑实现自动化。

部署自动化,不仅仅是需要为运维人员考虑,同时也要兼顾开发和测试人员的需求,要保证系统能够持续部署,自动化地完成构建、测试、验证等操作。

传统的手动运维监控方式,运维人员不仅要面对大量且繁琐的重复性工作,还要被动地去应对不同的运维事件,效率不高,无法适应业务的快速交付模式。

因此,为了能够及时预防或者解决系统的故障性问题,运维自动化监控就有了它的必要性。自动化运维,主要的管理范围包括但不限于容量使用管理、平台性能管理、资产使用管理、资源使用管理、用户使用体验监控、日志监控告警、安全合规管理等。

除了系统本身的运营需要考虑之外,系统的用户运营也很重要。一套成熟的实施运营机制,需要综合考虑新上线、新优化以及使用中的不同实施场景。

  • 针对新上线的版本,除了进行充分的测试验证之外,还需要试运行一段时间,如果还涉及新旧的替换,可以加入试点机制,双线运行,快速响应和解决问题,等版本问题后再准备全范围推广,包含启动会议、用户初始化的准备、系统培训等。
  • 针对新优化的版本,需要做好用户的知会工作,多方式(系统消息推送、短信/邮件发送、群通知等)让用户知晓新优化的内容,并为其提供相应的操作视频或文档。
  • 针对使用中的版本,根据实施资源和实施规模制定相应的机制。若实施资源有限,定义好统一的需求和问题反馈渠道(如系统反馈功能、微信反馈群等),由统一的接口人收集需求和问题,分级、分类及分发至相应的责任人,定时整理和统计实施处理台账;若实施资源充足,根据业务类型建设不同的反馈渠道,专人专项,建立时效机制。最后,要有意识地复盘实施运营内容,整合常用的问题答疑及处理脚本,提高实施效率。

4. 管理

传统硬件制造业的管理模式,更多的是层级式的管理模式,该模式强调管理秩序,控制是核心。

该模式下,不同层级的管理者都拥有属于自己的信息和资源,通过标准和制度来控制自己的员工,自己的团队不出错就是管理的要领,每个员工仅需要专注于自己的分工和职责。

这种层级式的管理模式,如果运用于数字化转型上面,那么组织之间的协作会不流畅,部门与部门之间、个人与个人之间会存在沟通墙,决策流程冗余且繁琐,最终会大大降低团队的效率、工作质量和创新能力,让整个组织变得木讷。

为何互联网会出现扁平化的管理模式?根本原因就在于互联网面对的是快速变化的市场和不断发展的技术环境,该环境要求企业及其员工不仅要能够快速地适应和调整,还要有长远发展的意识。

制造业企业的数字化转型之路,并不要求完全照搬扁平化的管理模式,模式只是参考,本质是借鉴扁平化的管理思维,结合内部的实际情况,逐步完善属于企业本身的管理模式,加强企业内部之间的协同力和共享力。

对于平台来说,可以从技术、团队、版本、资源这四个方面考虑管理模式,打破传统管理模式的束缚,提升平台及团队的竞争力。

  1. 关于技术,一是完善技术开发规范,包括编码规范、域名规范、命名规范、脚本规范、分支规范、发布规范等,不仅能够提升个人的技术开发质量,还可以提高团队的协作力;二是建立技术审查机制,技术人员之间互相审查代码架构设计,不合理之处及时纠正,优秀的代码设计给予奖励,纳入优秀开发典例,增加绩效。
  2. 关于团队,平台的知识管理和利用是关键。对于平台来说,人员是流动的,知识是积累的,数字化转型过程中沉淀的知识是一项宝贵的资产。建设平台知识库,包括产品知识库(原型组件、业务知识、设计方案、需求文档、需求调研等)、产品技术库、产品运营库(常见问题、操作手册等)、产品项目库(规格书、会议纪要等)。
  3. 关于版本,需要制定专门的版本发布流程,控制版本的发布质量和风险。完善的版本发布流程,包含需求管理(提出,评审,交付)→开发管理(开发,自测,提测)→测试管理(功能验证,产品验收,测试报告)→发布管理(预验证,申请,评审,执行)→验证管理(验收,通知),对应使用的版本环境包含开发环境、测试环境、预生产环境和生产环境,其中预生产环境(UAT)不仅用于上线前的版本部署工作准备,还可用于系统培训、功能试运行以及大版本上线前的验证使用。
  4. 关于资源,重点是人才资源的培养。数字化转型,要求企业的员工要具备多元化的产品思维,不仅要重视员工自身的工作能力,还要重视员工的思维培养,支持员工横向发展,多接触和沟通不同方向的内容,多倾听一线员工的反馈和建议,建设员工的能力资源池,适当地下放决策权。

5. 安全

安全非小事,数字化转型企业需要制定信息安全机制,建立信息安全准则,保障平台知识的传输安全和核心数据的使用安全,定期召开安全培训会议,宣导安全知识。

四、平台发展期

“我有时候心里也在问,你往前走,到底往前走会怎么样?它也是未知,这就是最大的焦虑。焦虑就是未知。”这是美的集团董事长兼总裁方洪波关于整个数字化转型过程中的焦虑点。

杨国安先生问:“作为复盘的话,在整个转型过程里面,你做过最艰难的决策是什么?最焦虑的是什么?”

方洪波总裁复:“现在最艰难、焦虑的决策,是转型数字化的投入,当年搞632投20亿,数字化每年都要投几十亿。每到这个时候,这种抉择,很迷茫。2017年之前我投一个东西,我知道投下去肯定没错,我投20亿下去。以前根本就不会做工厂,我肯定不错,这个工厂摆在那,土地厂房都在那。研发中心也没有错,以前搞632信息系统也没有错,就是看得见的痛点,明显要解决的问题,非常清楚它一定有回报。但在2017年的时候,我不知道这个投资对不对,因为看不见。数字化都是隐形的东西,看不见。但事实上也是能看得见的。但是无法以肉眼去判断,以经验去判断,甚至有时候你不知道这个方向在哪里,这是目前最大的困难。”

“价值体现在哪里?”,是企业领导及数字化转型部门一定会面临的问题。

数字化转型发展的难题,首先就是认知。

一是对发展形态的认知,数字化转型并不仅仅只是信息部门的事情,它需要管理部门、业务部门以及信息部门的协同作战,技术只是一种手段,业务与技术的融合才是核心;二是对长期意识的认知,数字化转型并不能一步登天,不能妄想短时间能够解决所以业务问题,无序的建设只会降低企业领导层的转型信心。

数字化转型发展的难题,其次就是改变。

抗拒改变,是人的天性。对于一线用户来说,除了固定的工作量之外,还要接受并学习新的知识,具有一定的抗拒性。因为对于他们来说,不仅仅是要承担改变带来的风险性,还要担心改变带来的工作变化。平台建设的时候,专注于用户的核心痛点,做好平台的用户体验,能够很好地解决这一难题。当然,适当地领导压力或者激励也是必不可少的。

数字化转型发展的难题,最后就是人才。

在此,引用腾讯高级管理顾问杨国安在美的集团访谈中的总结:

“美的的数字化转型,核心就是有愿景与梦想,但关键在于,团队能不能实现转型。我个人认为在组织能力配套里,核心还是关键人才。

很多是领导人才,从方洪波开始,他在2012年接管集团的董事长,自己要看到未来的机遇跟挑战,如何影响高管团队,不断学习,往前推进。

我也知道他的执委会很多都是新的,以前老的那些换了,全部都是最近几年上来的年轻领导者带领公司的转型、发展。

核心人才在转型过程里面很关键,既要懂业务、产品、技术的人,又要懂数字化的科技人才,这种桥梁性的人才,且综合性的人才是最难发现的。

美的在内部是靠在做中学,在业务转型里深入了解业务的痛点,以及思考如何用科技赋能业务。一方面是内部培养人才,另一方面将硬变成软,更加数字化。

为了吸引人才,他们愿意为人才设点。美的内部的激励文化工作氛围,就是我们所谓的一国两制,不是用传统硬件制造业的模式或者文化激励来管理。

整个组织能力最核心的改变是,关键人才跟领导人才的升级和配套。”

综上,笔者认为,传统企业的数字化转型是有必要的,但不具备统一性,它的发展需要根据企业的资源和发展等多方面因素考虑。在转型的过程中,特别是针对中小型企业,找到业务关键的痛点,是转型路上的一大阶梯。也就是说,回归产品的本质,以价值为核心,切忌打肿脸充胖子,什么都想做。

引用说明:本文中关于美的集团董事长的访谈内容引自文章《数字化转型八年,智造如何重估美的?》。

作者:PM小刘,公众号:PM小刘

本文由 @PM小刘 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

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