Compare commits

..

85 Commits

Author SHA1 Message Date
Kpro 4db87280b4 删除 test2.md 2023-10-23 11:52:18 +08:00
Kpro 94f7d7d92a 删除 test0001.md 2023-10-23 11:52:12 +08:00
Kpro eadd5f2388 删除 test.md 2023-10-23 11:52:09 +08:00
Kpro 317acbbeb9 删除 b.md 2023-10-23 11:52:05 +08:00
Kpro 48fe8c80c0 删除 a.md 2023-10-23 11:52:00 +08:00
Kpro c963acb251 删除 test/testa.md 2023-10-23 11:51:53 +08:00
Kpro 4106b0be63 Merge pull request '系统提交' (#7) from 34bd5db7-83d8-40d2-8383-ec43c8f3888b/knowledge:master into master
Reviewed-on: Kpro/knowledge#7
2023-10-19 22:14:27 +08:00
yangjun 6262eacc24 系统提交 2023-10-19 22:13:29 +08:00
Kpro 87fd218fdb Merge pull request '系统提交' (#6) from 34bd5db7-83d8-40d2-8383-ec43c8f3888b/knowledge:master into master
Reviewed-on: Kpro/knowledge#6
2023-10-19 21:43:41 +08:00
yangjun b8774d59ab 系统提交 2023-10-19 21:41:50 +08:00
Kpro 2b392f6941 Merge pull request 'master' (#5) from 34bd5db7-83d8-40d2-8383-ec43c8f3888b/knowledge:master into master
Reviewed-on: Kpro/knowledge#5
2023-10-19 21:40:18 +08:00
yangjun dc4416ded4 系统提交 2023-10-19 21:37:40 +08:00
yangjun 5a1734c5c3 系统提交 2023-10-19 21:35:24 +08:00
yangjun 92fe21a3a6 系统提交 2023-10-19 21:14:58 +08:00
Kpro a90233df85 Merge pull request '系统提交' (#4) from 34bd5db7-83d8-40d2-8383-ec43c8f3888b/knowledge:master into master
Reviewed-on: Kpro/knowledge#4
2023-10-19 19:45:47 +08:00
yangjun ac6d64789b 系统提交 2023-10-19 19:43:03 +08:00
yangjun dc02fb346e 系统提交 2023-10-19 19:35:27 +08:00
yangjun 299775ee53 系统提交 2023-10-19 18:24:38 +08:00
yangjun 77527c2c6e 系统提交 2023-10-18 23:35:11 +08:00
yangjun 268b764915 系统提交 2023-10-18 22:05:22 +08:00
yangjun 851493fbaa 系统提交 2023-10-18 22:04:53 +08:00
yangjun 717c8cf5af 系统提交 2023-10-18 18:46:40 +08:00
yangjun 64a3bd45dd 系统提交 2023-10-18 18:44:52 +08:00
yangjun 73805c47da 系统提交 2023-10-18 18:42:51 +08:00
yangjun 2df5738785 系统提交 2023-10-18 18:42:16 +08:00
yangjun e0a94a5d8c 系统提交 2023-10-18 18:41:27 +08:00
yangjun d65c42245f 删除 a.md 2023-10-18 18:38:38 +08:00
yangjun d6b3da5247 删除 333.md 2023-10-18 18:38:28 +08:00
yangjun 484074848c 系统提交 2023-10-18 18:37:29 +08:00
yangjun 6f3acb73bc 系统提交 2023-10-18 18:36:29 +08:00
yangjun 7e65a3ff81 12 2023-10-18 18:10:51 +08:00
yangjun 11bab83d64 1 2023-10-18 18:06:14 +08:00
yangjun 0ee76f3eb7 删除 hah.md 2023-10-18 18:03:06 +08:00
Kpro ee25e87d37 更新 bbb.md 2023-10-18 16:06:53 +08:00
yangjun 264d6d2eef 系统提交 2023-10-18 16:06:02 +08:00
yangjun 27fa2b80ae 系统提交 2023-10-18 16:04:38 +08:00
yangjun 332979372d 系统提交 2023-10-18 12:56:34 +08:00
yangjun 64b1730f8d 系统提交 2023-10-18 11:02:14 +08:00
yangjun 3e49721dc2 系统提交 2023-10-18 10:54:03 +08:00
yangjun 7a7180fd12 系统提交 2023-10-18 10:53:01 +08:00
yangjun 61faf6534b Merge branch 'master' of http://gitea.opentekr.com:18800/Kpro/knowledge 2023-10-18 10:50:40 +08:00
yangjun b22c9ae2f8 1 2023-10-18 10:49:21 +08:00
Kpro 5d147ab66a Merge pull request '更新 test.md' (#3) from 25b3bbb8-9bb2-4925-b1bd-60d2101203d5/knowledge_test3:master into master
Reviewed-on: Kpro/knowledge#3
2023-10-17 23:06:30 +08:00
Kpro 818232a1cc 更新 test.md 2023-10-17 23:05:51 +08:00
Kpro 69b48931e0 添加 test.md 2023-10-17 23:02:41 +08:00
Kpro cd0edc34c9 添加 中国流程管理数字化的挑战和建议.md 2023-10-17 23:01:10 +08:00
Kpro b4647b6650 Merge pull request '更新 业务流程分级.md' (#2) from 1d278aff-d186-45c1-aef9-da5a3a9d8d8d/knowledge_test2:master into master
Reviewed-on: Kpro/knowledge#2
2023-10-17 22:56:54 +08:00
Kpro 66e55af9f2 更新 业务流程分级.md 2023-10-17 22:56:26 +08:00
Kpro f942429b13 更新 从业务流程分级的困惑看企业转型的组织变革治理.md 2023-10-17 22:46:43 +08:00
Kpro 2bf9c23cae 更新 从业务流程分级的困惑看企业转型的组织变革治理.md 2023-10-17 22:44:42 +08:00
Kpro 46db490400 更新 从业务流程分级的困惑看企业转型的组织变革治理.md 2023-10-17 22:42:02 +08:00
Kpro cdbb86e8d7 更新 从业务流程分级的困惑看企业转型的组织变革治理.md 2023-10-17 22:41:01 +08:00
Kpro 76201cbad2 添加 从业务流程分级的困惑看企业转型的组织变革治理.md 2023-10-17 22:40:06 +08:00
Kpro 50d08b7555 更新 业务流程分级.md 2023-10-17 22:33:03 +08:00
Kpro 1b17cf00f0 更新 纠结OKRKPI因为HR管理不规范.md 2023-10-17 22:29:10 +08:00
Kpro b3d8bfe596 更新 咨询项目的业务流程究竟怎么落地可落地的流程图该长成啥样.md 2023-10-17 22:28:56 +08:00
Kpro 610b77df9d 更新 业务流程分级.md 2023-10-17 22:26:53 +08:00
Kpro 92d17b26e3 添加 业务流程分级.md 2023-10-17 19:58:24 +08:00
Kpro 89ced2a240 添加 咨询项目的业务流程究竟怎么落地可落地的流程图该长成啥样.md 2023-10-17 19:55:38 +08:00
Kpro bc8105c46c 删除 test.md 2023-10-17 19:53:17 +08:00
Kpro b769526faf 添加 test.md 2023-10-17 19:52:56 +08:00
Kpro 4be6682807 删除 test.md 2023-10-17 19:51:53 +08:00
Kpro 83533f2e89 添加 test.md 2023-10-17 19:51:35 +08:00
Kpro c1d2381c23 删除 test.md 2023-10-17 19:43:53 +08:00
Kpro 35703df9e8 更新 test.md 2023-10-17 19:43:26 +08:00
Kpro 25834708a7 更新 test.md 2023-10-17 19:34:35 +08:00
Kpro a1dfb0a1fb 添加 test.md 2023-10-17 18:59:23 +08:00
Kpro b83ea9331a 删除 目录/test.md 2023-10-17 18:47:59 +08:00
Kpro 633fae8ae8 删除 测试.md 2023-10-17 18:47:52 +08:00
Kpro 9146685666 删除 test.md 2023-10-17 18:47:45 +08:00
Kpro 054578875b 更新 纠结OKRKPI因为HR管理不规范.md 2023-10-17 18:46:39 +08:00
Kpro 729383916f 更新 纠结OKRKPI因为HR管理不规范.md 2023-10-17 18:46:10 +08:00
Kpro 7c7e48b55e 添加 test.md 2023-10-17 18:45:27 +08:00
Kpro 5980ad5d3f 更新 纠结OKRKPI 是因为HR管理不规范.md 2023-10-17 18:44:57 +08:00
Kpro 21003488b9 更新 纠结OKR、KPI 是因为HR管理不规范.md 2023-10-17 18:44:10 +08:00
Kpro c51164a0f6 添加 纠结OKR、KPI 是因为HR管理不规范.md 2023-10-17 18:42:01 +08:00
Kpro f96c48f58a 更新 知识开源平台介绍.md 2023-10-17 18:20:40 +08:00
Kpro 0e99edfb6a 更新 知识开源平台介绍.md 2023-10-17 18:20:01 +08:00
Kpro 98afb84cc2 更新 知识开源平台介绍.md 2023-10-17 18:17:09 +08:00
Kpro d596c31de0 更新 知识开源平台介绍.md 2023-10-17 18:13:29 +08:00
Kpro 1253e1bed9 更新 知识开源平台介绍.md 2023-10-17 18:08:42 +08:00
Kpro 02de337f25 更新 测试.md 2023-10-17 18:08:30 +08:00
Kpro e322f2ed53 更新 目录/test.md 2023-10-17 18:07:25 +08:00
Kpro 518dcd9f5a 更新 测试.md 2023-10-17 17:32:38 +08:00
Kpro 8d33224c3f Merge pull request '更新 测试.md' (#1) from 03a2fc20-3185-438f-aeb5-9e6ea8547a8e/knowledge_test:master into master
Reviewed-on: Kpro/knowledge#1
2023-10-17 16:51:12 +08:00
9 changed files with 785 additions and 3 deletions

111
业务流程分级.md Normal file
View File

@ -0,0 +1,111 @@
---
title: 业务流程分级34
---
在我的管理咨询生涯里12跟客户谈“业务流程分级”咨询项目画业务流程要画到几级是个很让人困扰的话题参见《在企业现实中我从来没有看到过啥“六级流程”》《业务流程管理咨询的一片乱象》。流程究竟如何分级不同的业务流程管理方法论里使用的名词都比较混乱没有统一标准同样一个词例如活动 - activity在不同体系中表达的意思是不一样的。下表我列出了有代表性的四种分层命名方法以及各层所表示的业务颗粒度和信息颗粒度的大致对应关系
流程层级
APQC流程分类框架
SAP ASAP流程架构
SAP solution manager
SCOR供应链流程框架
<!-- more -->
1
Category
Business area
2
Process group
Process group
Level 1 Process type
3
Process
Business process
Scenario
Level 2 process configuration
4
Activity
Business process variant
Process
Level 3 process element
5
Task
Process step
Process step
Level 4 workflow
6
activity
APQC的层级命名方法相对比较普及如果我们以它为标准三级叫做“流程”的话比三级的层级高的属于商业模式设计的范畴包括了流程类别以及流程类别的构成关系比三级的层级低的属于每个流程里的具体的活动、任务或叫步骤那么当我们在工作中说“流程”或者“业务流程”的时候我们想表达的意思究竟是在说第三级这个颗粒度还是包含了一至五级甚至更细的所有内容
图片
在现实中,企业的业务管理者(总经理、商品总监)和流程工程师们(企业 IT 部门下的企业架构经理、信息系统设计者)口中的业务流程,有可能就不是一回事——前者说的只是 L3而后者可能包含了更细节的职位/岗位设计、信息系统的功能和数据设计等。
术语不统一造成的困惑也许要靠企业知识开源的推进(参见《企业知识开源(八)| 咨询公司的人工智能要靠开源模式》),然而这些困惑背后的企业变革治理才是最有挑战的地方。
业务流程管理是由商业模式驱动的运营模式和组织模式变革。让我们来具体举个例子:过去 这些年里,我曾经先后服务过多家中国服装企业,见证了这个行业的商业模式变化,在变化过程中就经历了一系列流程变革。
从 90 年代后期中国服装企业开始快速崛起,市场上出现了第一批领导性品牌,以体育品牌(李宁、安踏等)、休闲服装(美特斯邦威、森马等)为代表,这批品牌的商业模式被称为“微笑曲线”,即品牌商将产业链上控制价值比较高的环节抓在自己手里,将制造、零售等相对竞争激烈、附加值较低,或者价值创造活动分散、难以集中管理的环节交给合作伙伴去做。
1.研发和设计:在服装产业中,这包括设计新款式、开发新材料等,它为顾客创造独特和有吸引力的产品。
2.品牌与营销:建立品牌、市场推广,以及规划一季商品的具体款式和款数构成,是这个环节的主要活动,通过与知名设计师或品牌代言人合作,确定市场上独特的品牌形象。
3.零售与分销:通过招募加盟商,由加盟商自行开发门店,在订货会上集中下单订购一季商品,品牌商拿到订单后交给代工厂生产,并交付给加盟商。产品离开品牌商的手中后,通过不同的加盟分销商或零售商到达消费者手中。
4.制造和采购:品牌商开发制造商来代工,他们可能帮助制造商进行供应链上游(例如核心的面料、辅料)的协作,并且帮助制造商提高制造能力,但是具体的原料采购、生产计划、品质保证和成本控制等供应链活动由代工商管理,品牌商只享受最终结果。
图片
然而服装行业是一个时尚度非常高的行业,其特点是时尚流行趋势难以提前把握,要求对市场敏捷反应,因而传统的批发模式在时尚周期越来越短、变化越来越快的今天受到了很大挑战,那种通过高价签约的营销活动(例如知名品牌代言人、大型运动会赞助等)来打品牌,鼓励加盟商订货越多越好、只要收到了加盟商的货款、货到了加盟商手上能不能卖得出去就不管了的一次性买卖,给品牌商经营带来了风险。
2008 年奥运会可能是中国服装行业的一个转折点,开创了中国微笑曲线模式的某体育品牌大手笔赞助了这次奥运会,其创始人甚至成了开幕式的焦点人物,品牌影响力有巨大提升,其后两年该品牌得以加大了对加盟商销售的力度,然而面向消费者的终端动销情况却差强人意,加盟商在 2008 年后购进的货物积压在手上几年都没消化完,一方面是旧货赶不上时尚转换,另一方面加盟商为加强周转的打折销售,又对品牌带来负面影响,新货卖不出去,该品牌的经营一度进入到恶性循环的状态。
该品牌的主要竞争对手抓住机会对传统批发的商业模式进行了变革。他们将跟加盟商的单纯买卖关系转换为共同面向终端消费者的利益共享模式即加盟商购进的商品能否卖出去其风险由品牌商来共担。这使得品牌商和加盟商从一季产品的规划开始就必须紧密协作包括将服装货品看成是“商品”而不仅是“产品”销售渠道参与到款数和款式的规划上加盟商的货款及资金是双方共同使用的资源由一次性的商品买断变成持续小步快跑的集中订货、分批配货、渠道调配的商品运营。这种以消费者为中心品牌商和加盟商紧密协作的新模式被称为“消费者直达DTC”。
我自己很幸运在过去十来年里以咨询顾问的身份参与、见证了多家服装品牌商的DTC 模式变革。
变革过程必然伴随着业务流程的变化,那么问题来了:
在服装企业一季商品的运营体系里,究竟什么颗粒度的活动算“流程”,是指一季商品“从规划到退市”的端到端业务过程叫流程,还是“策划”环节叫流程?
还是策划环节里的不同工作变化,例如鞋子、服装、配饰等不同类别商品的策划流程各不相同,一组包含了鞋子、服装、配饰等的商品系列,要跟品牌推广活动的营销主题挂钩,那是不是不同商品类别、商品系列的策划、营销叫“流程”?
还是这些工作里更细的环节,例如,买货金额按渠道、按类别汇总,再折算成具体到款号、到色码的订货数量,叫流程?
这些问题在企业要做“业务流程”时,就是“业务流程咨询”或者“业务流程管理”要做什么事情,你做事的颗粒度到那个层面才能保证落地?给企业的信息管理部门的企业架构师以及咨询顾问带来很大的困扰,这个困扰不仅在于茴香豆的茴字有几种写法这种学究式的名词纠结,更重要的是,流程究竟该谁来负责?在企业转型中,从商业模式设计到具体的组织设计(职位描述、人员配置)以及信息系统的功能确定,必须要形成合理的企业业务流程治理机制。
图片
在中国,能够把企业变革和流程实施结合起来的企业非常少,我观察到一家公认企业转型最成功的企业,在流程和 IT 组织体系里有专门的变革管理职能这个变革组织是和企业架构工程流程工程是企业架构工程的一部分、以及IT系统工程及管理、项目管理等平行的
图片

View File

@ -0,0 +1,65 @@
---
title: 中国流程管理数字化的挑战和建议.md
tags: 流程
---
# 中国流程管理数字化的挑战和建议
这几天因为写书的原因我找了国内市面上卖得比较好的业务流程的书来看翻了十来本。感觉国内知识界对1业务流程管理的传播有三个流派按靠谱程度依次是
第一级是培训派,这类出版物数量最多,作者基本都是面向小微企业做管理培训的大师,这几年宣传主战争已经从机场书店转战到抖音和视频号上了。其观点将业务流程等同于企业管理制度,强调权限、审批一类的控制,江湖味很重,能唬住教育程度不高的企业管理者,虽然用了“业务流程管理”这个词,还常和阿米巴、股权激励一类小微企业主喜闻乐见的话题交织在一起,但是和大企业说的“流程管理”差别很大。
第二级是理论派,这类出版物数量不多但是市面上影响较大,作者研究了国外业务流程管理理论以及 APQC 等流程管理组织的实践倡导比上者对业务流程的基本概念掌握准确然而因为缺乏对ERP企业核心系统、BPM 技术实现手段的了解,而且作者大多没有对大型跨国公司流程管理的亲身体验,真正落到实践应用上,就往往流于培训派风格了。
<!--more -->
第三级是工具派和前两者缺乏对实践的了解相比这类作者大多有大企业的流程管理实践或者BPM软件的应用经验不过中国企业本来 BPM 应用基础就很差,包括某些号称数字化转型最成功的中国企业,谈不上有啥“最佳实践”,所以他们主要关注点是在文档性质的流程模型的管理上,对于智能工作流、流程挖掘以及超自动化的介绍还不深入。此外,对于业务流程跟运营优化、人力资源设计和组织变革等关系,这个流派欠缺明确的思路,可以说是“对流程的管理”,而非“用流程来做管理”。
本文暂不就业务流程管理的组织管理进行展开讨论,仅就业务流程管理的数字化实现而言,我认为中国企业在这方面需要有良好的顶层概念设计和架构规划,亦即建立符合自己企业特点的业务流程管理技术栈(我在《企业数字化基础概念 中国特色的业务流程管理技术栈》写的BPMTech Stack充分理解业务流程管理的技术复杂性和实施困难性。
图片
业务流程管理数字化必须依靠企业事务处理和用户交互的数字化基础,前者是指 ERP、CRM 等核心系统,以及对各种内外部数字化服务的利用(例如,采购订单处理的流程,可能接入物流公司 API从而跟踪供应商送货的物流状态后者则是业务流程数字化的使用者必须习惯利用数字化的工具来处理工作不论是非结构化的小组协作半结构化的业务案例处理还是全结构化的工作流
图片
企业微信、钉钉、飞书等企业协作平台目前可能是中国最普及的企业数字化工具,严格意义上说,这三个工具是数字化前端,而非系统,他们也能接入到企业级流程管理平台,不过,中国用户应该是更习惯于“微信上拉个群”这种非结构化的工作方法,而非更为严谨的半结构化或结构化流程。
这种现象的根源还是企业 ERP、CRM 等基础没有打牢,缺乏准确的、结构化的业务事务处理能力,业务流程自然跑不起来。
如下图所示,业务流程管理数字化可以分为三层:流程数据源头、流程管理核心和流程使用界面:
图片
其中处理结构化流程的业务流程管理核心系统(注意不要和 ERP、CRM 这样的“业务核心系统”混淆起来从90 年代后期的工作流管理WFM技术兴起到2010年前的企业服务总线ESB技术和 SOA 架构发展,今天,在技术上已经完全能解决符合下图这样架构规范的数字化工作流的问题:
图片
来源wfmc 参考模型
为了看起来容易,我将这个架构简化为下图,从应用角色上,涵盖了三种角色:
一是业务流程分析师,其工作职责是业务流程的架构规划、详细设计、流程建模,将流程模型的制品放到一个流程仓库里,
二是业务最终用户他们的工作界面是个人数字化工具OA 或者飞书、钉钉),也可以进入到传统的企业软件操作界面里,按照对他们个人推送的流程活动指令,开展相应的业务活动,并记录业务,
三是业务运营管理人员,通过两个仪表盘(参见《企业管理的两个仪表盘 商业智能BI 和 流程智能PI的区别》对流程和业务进行分析从而调控业务优化流程
图片
就中国企业的现实来看,一方面,某种程度上说,近年来的数字化、中台等带有互联网特性的企业数字化理念体现了非结构化工作协作的特点,是“反流程”的,另一方面,近年来业务流程管理数字化相关的关键技术, 包括 RPA、企业软件服务化解耦、API 集成、低代码开发、人工智能业务规则、流程挖掘等,又有很大进步,这些概念加起来就是“超自动化”,所以企业要深入推进业务流程管理数字化的话,本文开始说到的国内在业务流程管理方面的理论和舆论,已经远远不能满足中国企业的流程管理的实践需求。
最后,对致力于业务流程管理数字化的中国企业管理者,我提几个建议:
1、业务流程管理数字化不要全部铺开要从某个业务域的局部领域开始找到业务应用场景和高应用价值流程建立“超自动化”基础后逐步推广。
2、在上述建设中要形成流程规划、流程建模、流程实施和流程分析的闭环
3、根据企业实际情况建立企业级的流程管理技术栈选择合适的流程建模工具、工作流引擎、应用集成平台等
4、不要搞无所不包的流程框架体系建设全方位梳理企业流程很大概率这么干会产出一堆基本没用的废纸
5、业务流程分析是企业的一种能力建设其操作人员不论叫企业架构师还是叫流程管理专家需要建立 COE组织来培养和发展相关人才
6、少看抖音、视频号上的业务流程管理网红的视频那些人大多数不懂。

View File

@ -0,0 +1,129 @@
---
title: 从业务流程分级的困惑看企业转型的组织变革治理
tags: 组织架构
---
在我的管理咨询生涯里,跟客户谈“业务流程分级”,咨询项目画业务流程要画到几级,是个很让人困扰的话题(参见《在企业现实中,我从来没有看到过啥“六级流程”》《业务流程管理咨询的一片乱象》)。流程究竟如何分级,不同的业务流程管理方法论里使用的名词都比较混乱,没有统一标准,同样一个词(例如活动 - activity在不同体系中表达的意思是不一样的。下表我列出了有代表性的四种分层命名方法以及各层所表示的业务颗粒度和信息颗粒度的大致对应关系
# 流程层级
APQC流程分类框架
# SAP ASAP流程架构
SAP solution manager
# SCOR供应链流程框架
<!-- more -->
1
Category
Business area
<p align="center">
<img src='https://gitee.com/TDuckApp/tduck-platform/badge/star.svg?theme=dark' alt='star'></img>
<img src='https://gitee.com/TDuckApp/tduck-platform/badge/fork.svg?theme=dark' alt='fork'></img>
<img src='https://img.shields.io/github/stars/tduckcloud/tduck-platform?style=social' alt='star'></img>
<img src='https://img.shields.io/github/forks/tduckcloud/tduck-platform?style=social' alt='fork'></img>
<br />
<br />
<a href="https://www.tduckcloud.com/" target="_blank">官方网站</a>&nbsp;
<a href="https://doc.tduckcloud.com" target="_blank" >部署文档</a>&nbsp;
<a href="https://pro.tduckcloud.com/s/QUiDSKq8" target="_blank">用户社区</a>&nbsp;
<a href="https://space.bilibili.com/409825300" target="_blank">bilibili频道</a>
</p>
2
Process group
Process group
Level 1 Process type
3
Process
Business process
Scenario
Level 2 process configuration
4
Activity
Business process variant
Process
Level 3 process element
5
Task
Process step
Process step
Level 4 workflow
6
activity
APQC的层级命名方法相对比较普及如果我们以它为标准三级叫做“流程”的话比三级的层级高的属于商业模式设计的范畴包括了流程类别以及流程类别的构成关系比三级的层级低的属于每个流程里的具体的活动、任务或叫步骤那么当我们在工作中说“流程”或者“业务流程”的时候我们想表达的意思究竟是在说第三级这个颗粒度还是包含了一至五级甚至更细的所有内容
图片
在现实中,企业的业务管理者(总经理、商品总监)和流程工程师们(企业 IT 部门下的企业架构经理、信息系统设计者)口中的业务流程,有可能就不是一回事——前者说的只是 L3而后者可能包含了更细节的职位/岗位设计、信息系统的功能和数据设计等。
术语不统一造成的困惑也许要靠企业知识开源的推进(参见《企业知识开源(八)| 咨询公司的人工智能要靠开源模式》),然而这些困惑背后的企业变革治理才是最有挑战的地方。
业务流程管理是由商业模式驱动的运营模式和组织模式变革。让我们来具体举个例子:过去 这些年里,我曾经先后服务过多家中国服装企业,见证了这个行业的商业模式变化,在变化过程中就经历了一系列流程变革。
从 90 年代后期中国服装企业开始快速崛起,市场上出现了第一批领导性品牌,以体育品牌(李宁、安踏等)、休闲服装(美特斯邦威、森马等)为代表,这批品牌的商业模式被称为“微笑曲线”,即品牌商将产业链上控制价值比较高的环节抓在自己手里,将制造、零售等相对竞争激烈、附加值较低,或者价值创造活动分散、难以集中管理的环节交给合作伙伴去做。
1.研发和设计:在服装产业中,这包括设计新款式、开发新材料等,它为顾客创造独特和有吸引力的产品。
2.品牌与营销:建立品牌、市场推广,以及规划一季商品的具体款式和款数构成,是这个环节的主要活动,通过与知名设计师或品牌代言人合作,确定市场上独特的品牌形象。
3.零售与分销:通过招募加盟商,由加盟商自行开发门店,在订货会上集中下单订购一季商品,品牌商拿到订单后交给代工厂生产,并交付给加盟商。产品离开品牌商的手中后,通过不同的加盟分销商或零售商到达消费者手中。
4.制造和采购:品牌商开发制造商来代工,他们可能帮助制造商进行供应链上游(例如核心的面料、辅料)的协作,并且帮助制造商提高制造能力,但是具体的原料采购、生产计划、品质保证和成本控制等供应链活动由代工商管理,品牌商只享受最终结果。
图片
然而服装行业是一个时尚度非常高的行业,其特点是时尚流行趋势难以提前把握,要求对市场敏捷反应,因而传统的批发模式在时尚周期越来越短、变化越来越快的今天受到了很大挑战,那种通过高价签约的营销活动(例如知名品牌代言人、大型运动会赞助等)来打品牌,鼓励加盟商订货越多越好、只要收到了加盟商的货款、货到了加盟商手上能不能卖得出去就不管了的一次性买卖,给品牌商经营带来了风险。
2008 年奥运会可能是中国服装行业的一个转折点,开创了中国微笑曲线模式的某体育品牌大手笔赞助了这次奥运会,其创始人甚至成了开幕式的焦点人物,品牌影响力有巨大提升,其后两年该品牌得以加大了对加盟商销售的力度,然而面向消费者的终端动销情况却差强人意,加盟商在 2008 年后购进的货物积压在手上几年都没消化完,一方面是旧货赶不上时尚转换,另一方面加盟商为加强周转的打折销售,又对品牌带来负面影响,新货卖不出去,该品牌的经营一度进入到恶性循环的状态。
该品牌的主要竞争对手抓住机会对传统批发的商业模式进行了变革。他们将跟加盟商的单纯买卖关系转换为共同面向终端消费者的利益共享模式即加盟商购进的商品能否卖出去其风险由品牌商来共担。这使得品牌商和加盟商从一季产品的规划开始就必须紧密协作包括将服装货品看成是“商品”而不仅是“产品”销售渠道参与到款数和款式的规划上加盟商的货款及资金是双方共同使用的资源由一次性的商品买断变成持续小步快跑的集中订货、分批配货、渠道调配的商品运营。这种以消费者为中心品牌商和加盟商紧密协作的新模式被称为“消费者直达DTC”。
我自己很幸运在过去十来年里以咨询顾问的身份参与、见证了多家服装品牌商的DTC 模式变革。
变革过程必然伴随着业务流程的变化,那么问题来了:
在服装企业一季商品的运营体系里,究竟什么颗粒度的活动算“流程”,是指一季商品“从规划到退市”的端到端业务过程叫流程,还是“策划”环节叫流程?
还是策划环节里的不同工作变化,例如鞋子、服装、配饰等不同类别商品的策划流程各不相同,一组包含了鞋子、服装、配饰等的商品系列,要跟品牌推广活动的营销主题挂钩,那是不是不同商品类别、商品系列的策划、营销叫“流程”?
还是这些工作里更细的环节,例如,买货金额按渠道、按类别汇总,再折算成具体到款号、到色码的订货数量,叫流程?
这些问题在企业要做“业务流程”时,就是“业务流程咨询”或者“业务流程管理”要做什么事情,你做事的颗粒度到那个层面才能保证落地?给企业的信息管理部门的企业架构师以及咨询顾问带来很大的困扰,这个困扰不仅在于茴香豆的茴字有几种写法这种学究式的名词纠结,更重要的是,流程究竟该谁来负责?在企业转型中,从商业模式设计到具体的组织设计(职位描述、人员配置)以及信息系统的功能确定,必须要形成合理的企业业务流程治理机制。
图片
在中国,能够把企业变革和流程实施结合起来的企业非常少,我观察到一家公认企业转型最成功的企业,在流程和 IT 组织体系里有专门的变革管理职能这个变革组织是和企业架构工程流程工程是企业架构工程的一部分、以及IT系统工程及管理、项目管理等平行的

182
企业架构框架.md Normal file
View File

@ -0,0 +1,182 @@
---
title: 企业架构框架
---
早上有朋友跟我说他们在实施华为的企业架构方法,我看这个方法来自我一直很推崇的华为的这本书。
其实华为企业架构理论都不是新概念。朋友公司学习的华为业务服务化设计方法就是IBM在五十年前提出来的企业系统规划方法论——业务系统规划BSP一模一样的“V字模型”思路基本一样只是因为技术的变化有些术语的差别50 年前叫“应用”application或“功能”function今天叫“服务”service或“产品”。
<!-- more -->
![图片](https://mmbiz.qpic.cn/mmbiz_jpg/f4M8ibz2jzMqUbRX11YBv9ib0uWz66027eph7sXFCueDswGFWZOd5hHZrYllv33r2gia5CvJJRiaIolrcH3YVPq6wg/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1)
而在总体规划上衔接战略和项目华为使用了企业架构Enterprise Architecture作为方法论实际上华为自己就是企业架构标准化组织TOGAF 的委员会成员,不过华为在宣传时没有用 TOGAF 名义,而是自己起了个名字,叫 4A 架构。
我想说的是企业管理不要去搞发明,无论是 IBM BSP还是 TOGAF都是几十年前就已经早好的轮子华为实际上也是在应用。每种方法论都是有其应用环境的华为实践只适用于华为自己不是其他企业能够简单照搬最关键的是企业在学习华为或者任何“最佳实践”不是学习表象而是了解华为实践背后的基本原理。
实际上 BSP 和企业架构本身是个有争议的方法论我特别翻译了一篇独立学者Svyatoslav Kotusev撰写的批评企业架构方法论的文章。特别说明**我转发这篇文章并不代表我同意作者的观点,**只是想让大家看到任何商业性的“最佳实践”背后的潜在风险。实际上Svyatoslav Kotusev 也并不是说“企业架构”不对,他自己本人就把自己定位于企业架构专家,而且就企业架构的话题著书立说,还讲课、咨询;他是批评现在已经有的一切成名的 EA框架。
这篇文章原发于“英国计算机协会”的网站,链接是:
https://www.bcs.org/articles-opinion-and-research/enterprise-architecture-frameworks-the-fad-of-the-century/
---
**企业架构框架:世纪忽悠**
Enterprise Architecture Frameworks: The Fad of the Century
2016 年 7 月 28 日
Svyatoslav Kotusev
企业架构(EA)作为一种工具被广泛使用用于改善全球各种组织中的业务和IT一致性。然而正如我之前报道的那样成功的实际EA实践与流行的EA框架没有任何关系。此外在成功实践EA的实际组织中既没有找到最广泛讨论的EA框架所提倡的具体细节甚至也没有找到 符合 EA 总体概念的想法。
为什么最广泛认可的EA框架与EA的概念密不可分却与真正的EA实践毫无关系呢?这一切意味着什么?我对EA文献的广泛历史分析表明所有流行的EA框架包括Zachman、TOGAF和FEAF只不过是由咨询公司和大师积极推动的典型管理忽悠。它们往好里说是无用的往坏里说是有害的。
**EA框架的历史**
许多人都认为EA是在1987年Zachman框架发表之后才出现的一门学科。然而基于证据的历史回顾表明EA的思想出现得更早并且起源于IBM在20世纪60年代发起的业务系统规划(BSP)方法。BSP方法为所有当前的EA方法和框架提供了最初的基础:信息系统体系结构的概念、自顶向下的体系结构规划方法、正式的按步骤的架构规划流程,以及用于描述架构的各种图表和模型。
随后的漫长的EA历史可以大致分为三个不同的时期:前EA (BSP)早期EA和现代EA。
EA历史中的前EA时期大约持续于20世纪60年代至80年代。EA之前的方法包括IBM提供的开创性的BSP方法安达信咨询埃森哲前身提供的类似的Method/1方法以及其他咨询公司和大师提供的类似BSP的方法。
EA的早期阶段持续于20世纪80年代至90年代。在此期间:
·第一个EA框架出现了包括1986年的PRISM框架(由IBM和其他公司赞助)1987年的Zachman框架和1989年的NIST EA模型。
·术语“企业架构”开始被持续性地使用。
·新一代的EA方法论出现了包括Steven Spewak的企业架构规划(EAP它“起源于IBM的BSP)和TAFIM。
现代EA时期始于20世纪90年代并引入了当前的EA框架包括FEAF(基于EAP)和TOGAF(基于TAFIM)。所有这三代EA方法本质上都是基于BSP方法的开创性思想并提倡非常类似的基于架构、按步骤的正式信息系统规划方法。
**EA框架的问题**
研究显示在EA的漫长历史中不断证明所有三代EA方法的实际实现都存在着重大问题。例如对于第一阶段的前EA(类似bsp)时代的规划方法,发现
·规划是非常昂贵和耗时的。
·规划很难理解,非常抽象,需要进一步分析才能实施。
·规划在组织上难以实施;计划只能部分实施,甚至被搁置。
第二阶段的“早期EA”的实践经验表明
·EA开发工作需要大量的时间、金钱和人员。
·EA文档过于概念化、不灵活、难以理解和过时因此不太有用。
·EA相关的活动没有很好地集成到组织运行中EA遵从通常无法实现。
第三阶段的“现代EA”主要问题包括
·开发和维护EA文档需要大量的工作和资源。
·EA的文件质量很低不详细过于复杂而且经常过时。
·EA相关的活动发生在“象牙塔”中EA文档被忽略了。因此研究表明所有三代EA方法都需要付出洪荒之力来产出一大堆没用的文档这些文档通常被忽略或搁置EA 做了个寂寞。
不出所料在EA的漫长历史中许多学术论文作者认为推荐的前EA和EA方法是无效的。例如Goodhue 等人得出结论“这种方法太昂贵其收益太不确定并且在组织上难以实施”。Lederer和Sethi得出结论“考虑到他们巨大的费用和时间消耗(…)研究结果严重挑战了[类似bsp的]规划方法的实用性”。
“总之,信息系统战略规划者对(类似bsp的方法)不是特别满意。毕竟,这需要大量的资源……当(类似bsp的)研究完成后,在执行计划之前可能需要进一步的分析。计划的执行可能不会很广泛。” Kemp和McManus 持怀疑态度他们认为EA战略是不切实际的无法实现的即使它可以实现也是不可持续的。
Holst和Steensen得出结论:“基于大部分现有且普遍接受的机制而搞出来的EA文献很难创造出成功的EA。”Bloomberg认为“EA取得的成功令人惊讶地微不足道”。
更重要的是许多作者一致认为所有三代EA方法的问题本质上都是根本性的。例如在“前EA”的时期Goodhue 等人得出结论,“现有证据(…)强烈支持对IS规划方法进行根本性反思的必要性”。在“早期EA”阶段Hamilton得出结论“研究结果强烈表明在项目及系统组合层面上架构驱动规划的指定性方法从根本上是有缺陷的”。在“现代EA”时期Gaver12总结道:“EA通常在任何地方都不能很好地工作因为企业架构在本质上是存在问题的”。
综上所述上述证据清楚地表明所有三代EA方法:
·推荐采用实质上相同的、正式的、分步骤的、基于架构的规划方法。
·遭受同样的实践问题
·事实证明这些方法落不了地,而且从根本上有缺陷。
这些结论揭示了流行EA框架的欺骗性故事:
·所有流行的EA框架都基于50年前的BSP方法。
·从BSP开始到TOGAF结束的前EA和EA方法论整个方法论家族从根本上是有缺陷的。
·尽管它们被证明是不实用的但所有三代EA方法都被各种顾问和大师成功地推广并作为“最佳实践”出售。
·咨询顾问们没有从上一代的失败中吸取教训,也没有改进方法,而是把同样的“旧酒装进新瓶子里”重新包装和转手兜售。
·TOGAF相对于BSP的唯一基本“改进”是新的修辞技巧强调在应用方法之前需要“适应”它这实际上意味着“做其他事情”正如我之前讨论过的。
因此尽管有大量的负面反馈但在近半个世纪的时间里许多咨询公司和专家一直在以不同的名义出售同样有缺陷的前EA和EA方法并将其作为“最佳实践”通过大量的营销努力和简单的修辞技巧来赚钱。此外由于积极的推广EA 名词目前与EA框架密切相关。然而正如上面提供的分析清楚地表明的那样所有流行的EA框架及其概念性的前身都是明显的营销驱动的管理学忽悠没有成功实施的示范例子。
尽管许多营销白皮书始终将EA框架定位为“最佳实践”但基于证据的研究却始终显示出相反的结论。除了建议开发和使用一些EA文档外EA框架本质上没有内在价值。从这个角度来看最“权威”的EA框架包括Zachman、TOGAF和FEAF是如何与我之前报道过的成功EA实践无关的就变得非常清楚了。
**EA框架的危害**
坚持推广无效的“最佳实践”对组织和社会很难说是无害的。可能证明EA框架应用最引人注目的例子是联邦企业架构(FEA)项目的失败。1996年克林格-科恩法案Clinger-Cohen颁布后FEA项目于1999年启动该法案要求美国联邦政府为所有机构开发一致的架构以改进信息系统的使用。联邦企业架构框架(FEAF)被开发为FEA计划的指导性EA框架。
从一开始所有知名的EA专家和顾问都积极参与到FEA项目中。例如John Zachman和Steven Spewak作为“架构概念化和企业架构规划领域公认的两位领导者”参与了FEAF的开发。对于联邦调查局(FBI)“安达信咨询的顾问建议该局开发一个全面的EA以帮助减少孤立的、互不集成的应用程序的蔓延扩张”。
IBM也作为开发EA的承包商参与其中例如在国防部(DoD)。IBM与国防部的合同尤其有利可图:“为了开发该体系结构国防部于2002年4月与国际商业机器公司(IBM)签订了一份为期5年、价值9500万美元的合同。2004年国防部将合同金额增加到2.5亿美元。截至2004年9月国防部报告称它已为该项目承担了大约3.18亿美元的义务主要用于承包商支持。因此前面提到的最突出的前EA和EA方法的所有作者都大量参与了FEA方案的规划和实施。
FEA 项目很难说是特别成功的。根据FEA评估框架FEA项目的成熟度评估一致表明绝大多数联邦机构的成熟度没有高于阶段2(“建立EA管理基础”)而只有极少数机构成熟到阶段4(“完成EA”)几乎没有机构成熟到阶段5(“利用EA来管理变革”)。2002年提交给美国国会的关于FEA项目现状的官方报告得出结论:“目前联邦政府对EA的使用情况好坏参半但总体而言它还不够成熟无法支持充分知情的IT投资决策”。
在2003年类似的报告得出结论“联邦政府的 EA管理状态仍然不太令人满意在过去两年中几乎没有取得任何进展”。最终FEA项目基本上失败了。“大多数部门和机构报告说他们希望在未来的某个时候从各自的 EA项目中获益。这表明开发和使用 EA对联邦政府的真正价值在很大程度上仍未实现”。
克林格-科恩法案的主要作者之一Paul Brubaker评论道:“看看所有在架构理念下发起的努力,以及在这个保护伞下花费的所有资金,这些都导致了无法使用的摆在书架上的花架子软件。” 这也难怪美国联邦政府 CIO Vivek Kundra批评EA框架“比无用还要糟糕”“(企业架构师)专注于记录当前状态或未来状态应该是什么。当他们完成了他们的架构工件时,一项新技术已经杀死了他们正在做的任何事情。”
FEA项目并不便宜。例如据报道2003年“迄今为止在架构开发上花费了5.99亿美元”。2006年“各部门和机构报告说到目前为止他们在企业架构开发上总共投资了8.36亿美元”。到2010年底“联邦政府在企业架构上花费的资金已经超过10亿美元其中大部分(如果不是大部分的话)都被浪费了”。然而,政府的浪费却是承包商的利润。“各机构报告大量使用承包商支持开发各自的架构”,“(花费的资金中)1.889亿美元进了承包商的腰包”。
后一份报告总结说“各部门和机构分摊的与承建商有关的费用为6.21亿元而架构开发活动占大部分费用约为5.94亿元”。因此虽然美国联邦政府浪费了大量纳税人的钱但各种咨询公司和专家们仅仅创造了大量的EA文件而不是提供任何切实的结果从而获得了巨大的利润。“我不断催促(项目负责人),‘我们得到了什么,我们得到了什么,我们得到了什么?”Vivek Kundra解释道:“最终它变成了这本书。”
在所有的美国联邦政府机构中国防部提供了在EA上投入时间和金钱的最引人注目的例子但却得到了同样令人不满意的结果:“经过三年的努力和花费超过2.03亿美元国防部的架构仍然没有充分定义而且该部门做出业务系统投资决策的方式基本上没有改变”“尽管花费了近四年时间和大约3.18亿美元,国防部没有一个有效的架构规划”, “尽管国防部在其业务 EA上花费了10多年时间和至少3.79亿美元它仍然没有能力使用架构来指导和约束IT投资”。
2015年有报告称“架构在限制系统投资或使国防部为决策目的提供可靠和及时的信息方面无效”“该架构产生的价值有限”“架构在实现其预期结果方面通常无效其在实现经济收益方面的用处有限例如减少应用程序的数量”。“业务 EA未能有效地满足其预期结果”“国防部业务 EA在实现各种潜在利益方面的有用性是有限的”以及“架构不能使国防部为决策目的提供可靠和及时的信息”。在国防部EA的具体问题中提到了以下两个问题
·“对架构的审查是一边倒性的,并且没有与全年其余时间内发生的其他活动相结合。”
·架构是一项独立的工作,不会通过各种国防部部门来推动全面的系统组合和业务的管理。
因此2015年国防部的经验完全支持所有在20世纪80年代末最初报告的研究结果然后所有后续研究都一致支持前EA和EA方法是不切实际的因为它们需要不合理的努力来产生一大堆没用的文档而这些文档通常以束之高阁告终。由于FEAF最初是基于与之前所有有缺陷的前EA和EA方法相同的想法因此它自然也被证明是不成功的。
正如阿尔伯特·爱因斯坦的名言:“疯狂就是做同样的事情却期待不同的结果。”那些推崇50年前毁掉FEA项目的观点的人疯了吗?绝对不是。各种各样的顾问和大师都在出售任何可以能卖出去的东西来赚钱而不管它是否有效。例如EA 之父John Zachman他在IBM长达26年的营销生涯中曾推广过有缺陷的BSP方法最近他收购了联邦企业架构认证(FEAC)机构现在正在积极销售FEAF的认证和培训EA框架却要为投资到FEA项目中、浪费了纳税人10亿美元负主要责任。
FEAC机构成员们仍然推广同样的EA框架的认证项目这些框架代表着有缺陷的“最佳实践”。这里的疯狂之处在于EA社区通常仍然不承认EA框架是另一种管理忽悠许多EA从业者仍然渴望获得这些EA框架中的某些认证。几十年来顾问们能够以“最佳实践”的名义出售同样的最糟糕的实践即使真实的信息是公开的这清楚地表明了无休止的营销承诺的无限力量和基于证据的常识的完全无能。这种情况生动地说明了另一句臭名昭著的谚语:“谎言重复一千遍就成了真理”。
综上所述,上述证据清楚地表明:
·FEAF基于EAP (EAP基于BSP)因此代表了第三代EA方法。
·整个EA方法家族被证明是不切实际的不出所料基于FEAF的FEA项目也失败了。
·FEAF的问题与整个EA方法家族的众所周知的问题相同包括高成本、不可用的文档和规划活动的闭门造车。
这些结论揭示了FEA项目的可怕故事:
1. ```
FEA项目本质上是由EA顾问和大师启发、计划和实施的他们推动了广受关注的EA和EA方法包括IBM (BSP的作者)、安达信咨询(Method/1的作者)、John Zachman (EA之父)和Steven Spewak (EAP的作者)。
```
2. ```
正是这些EA顾问和大师启发了FEA随后他们作为这个失败项目的承包商赚了6亿多美元。
```
3. ```
前EA (类BSP)方法的无效性在20世纪80年代末已经得到了实证证明即在 FEA项目开始前10年即FEA从一开始就注定要失败它的失败早在项目开始前就被研究预测到了。
```
4. ```
研究人员在25年前报告的同样问题现在在提交给美国国会的官方报告中重复出现因为EA总共浪费了10亿美元的投资。
```
5. ```
尽管存在这么多争议结果却是EA原则中没有任何内容发生改变EA社区没有从FEA的失败中吸取教训同样的大师们继续将同样有缺陷的EA方法作为“最佳实践”来推广。
```
6. ```
关于EA框架失败的公开信息通常被忽略而EA认证专家的数量却在不断增长。
```
当相同的有缺陷的EA方法在几十年里以不同的名义不断推广为“最佳实践”时尽管有大量的经验证据反对它们因此整个EA方法三代史就是个公然的骗局和明显的营销操纵的历史。EA框架的历史提供了一个令人震惊的例子不负责任的销售行为对每个人都有害除了销售人员(可能安达信在安然丑闻后解散是一个公平的补偿)。如果单是FEA项目就浪费了超过10亿美元那么为了实现EA框架中描述的“最佳实践”全世界总共浪费了多少钱?这个问题的答案是未知的,但一定是令人印象深刻的。
**这对EA 原则意味着什么?**
本文中讨论的证据清楚地表明从BSP到TOGAF的整个前EA和EA方法家族从根本上是有缺陷的。这对EA原则意味着什么?这是否意味着EA不起作用?一点也不它只意味着EA框架不起作用并且成功的EA实践与我之前报道的EA框架无关。
这个结论并不新鲜。例如1993年的Periasamy报告说BSP引入的架构概念被认为是有用的但与BSP的原始处方有很大的偏差。Ross等人在2006年报告说业务导向的架构非常有用而由前EA和EA方法推荐的详细技术架构“也就比门挡有用点儿”。Holst和Steensen在2011年报告说成功的EA实践是有机的不像EA框架所代表的机械思想。
John Zachman曾说过EA是一个世纪问题。考虑到在尝试实现EA框架时浪费的金钱总数公平地说虽然EA可能仍然是世纪问题但EA框架(包括Zachman框架)可能只是“世纪忽悠”——可能是管理忽悠历史上最有害的忽悠“高管可卡因”。因此我认为EA社区应该承认整个EA框架家族与成功的EA实践没有关系只是一种有害的管理忽悠。

View File

@ -0,0 +1,122 @@
---
title: BPMN 2.0 咨询项目的业务流程究竟怎么落地?可落地的流程图该长成啥样?
---
原创 GEORGE陈果 陈果George 2023-10-15 13:17 发表于上海
我做了这么多年咨询顾问,如果被客户要求进行业务流程设计,最让人困惑的情况就是客户要求你:“你们设计的流程要能落地,越细越好,至少要画到五级流程,有必要的业务场景,要细到六级、七级流程,这样我们公司的程序员拿着你们设计的流程图,就能直接开发软件系统了。”
可是客户要的“可落地的流程”究竟该长得什么样?
我相信这是咨询公司和购买咨询的甲方所共同关心的问题。站在甲方的角度,说白了就是不想自己的咨询费白花,顾问们不要在前面忽悠完,后面拍拍屁股就走了,顾问做出来的流程不是“在天上飘”的,确实在业务中能够用起来;而站在咨询方的角度,一个咨询项目的资源是有限的,既能够让甲方满意,又能让公司满意,“可落地”要做成啥样,对每个项目经理都是挑战!
“流程”本来就到了企业的操作层面,我认为“可落地”有三个含义:
<!-- more -->
图片
一是业务方案合理,体现了行业知识和经验,这主要是咨询方的责任;
二是组织能力到位,企业自身的组织、人员和变革意识要能支持未来流程,这主要企业方的责任,咨询公司配合;
三是技术可实现,需要数字化的流程活动,能找到现成的套装软件解决方案、或者借用企业现有系统功能(或略加修改),或者开发出合适的数字化工具,做到这点双方都有责任。
咨询项目的销售阶段或者项目执行阶段的现实情况是,对“流程可落地”最大的争议、困惑、纠结就在于:咨询顾问画出来的流程图(包括描述流程图的文字)究竟应该长得啥样子、有多细的颗粒度?
因为流程图毕竟是对业务活动或者信息系统的图形化描述,在没有投入运行前,或者没有系统前,甲方和咨询方都心里没底,这个画的图究竟够不够细,能不能用起来。
业务流程管理的闭环包括了识别、建模、部署、执行、运维的业务流程全生命周期,企业要建立自身的流程管理能力;如果企业自己没有流程管理能力,其实是玩不转流程的。
而管理咨询项目通常是用业务流程管理的方法, 在企业全局(一般来说全局性从头到脚流程搞一遍的咨询项目是不多的,我个人也很反对“煮大海”式的流程体系建设,不过现实中确实也有很多企业领导有这个期望值)或者某个具体业务领域里(例如产销衔接、产品研发等),帮助客户做该领域的流程管理的前面两个环节,流程识别和流程建模,即:
1、在这个业务领域里究竟有哪些流程通常交付的是“流程清单”这个清单也称为“流程架构”
2、这些流程每个究竟长得什么样子用“流程图”这种图形化的方式展示出来辅以文字说明。
图片
这里就谈到了过去我常说的问题,“画流程究竟要细到几级?”(参见《在企业现实中,我从来没有看到过啥“六级流程”》《业务流程管理咨询的一片乱象》),对这个问题的纠结,从我对中国咨询行业的行业经验看,除了因为咨询公司因为市场竞争而相互卷,无底线承诺客户外——你说流程做三级,我就跟客户说我能做到四级,你说要做到四级,我就跟客户拍胸脯,我派十个顾问做到你们办公室来,把你们的五级流程都画出来……
主要原因还是中国咨询行业以及企业管理者对传统业务流程建模方法论 (例如 ARIS以及APQC EPC流程分类框架的有意无意的误导或者一知半解。
业务流程管理BPM的鼻祖上世纪90 年代在德国产生的ARIS 方法论,早年进入中国,对中国管理界影响巨大,而市面上主流管理咨询公司早些年的业务流程方法论,如果追本溯源,几乎也可以跟 ARIS 搭上关系都分成一级、二级、三级、四级流程啥的。早年ARIS 的流程模型确实是分成价值链、流程链、流程、子流程、活动、任务等从粗到细到很细的5-6 个层级,不过按照 ARIS 理论也只有3-4 两级叫“流程”,其他层级都不叫流程,也不用“流程图”这种形式表现。
另外一个广泛存在的误会是对全球最有影响的流程框架跨企业流程标准化组织美国生产和质量协会APQC倡导的“ PCF 流程分类框架”PCF 的确把流程分成五级:
图片
细节是这样的:
图片
很多人就拍脑袋认为 APQC 有所谓四级流程、五级流程几年前我就见过一家营收不到百亿的制造业有个IT 规划和流程管理的咨询项目,在招标要求书里声明他们公司的业务流程有六级,要求咨询公司把每级都要画出来——我就直接拒绝了参与,最后还真有一家高大上咨询公司去做了。
实际上 APQC 的这个“流程分类框架”只是一个流程清单而已APQC 制定这个清单的初衷是为希望进行业务流程最佳实践学习和跨企业流程绩效对标的企业提供一个参照系,大家用统一的流程代号,例如 10103就能知道大家都在说“开发销售策略”这一件事——不过我个人觉得这应该就是大多数行业协会和标准化组织的一厢情愿而已。
APQC PCF并没有提供任何流程实践的标准内容也没有任何流程图、流程地图等可视化流程模型这个清单是用来做模型创建的参考这在 PCF 的官方文档讲得很清楚:
图片
实际上,今天主流的业务流程建模和标记的标准是 BPMN 2.0这个标准已经是业务流程管理行业的事实性标准。ARIS 经过若干年的发展,已经向 BMPN 2.0 靠拢,虽然其自身的流程建模方法论仍然保留,但是和 BPMN 2.0 也建立了转换关系。
BPMN2.0一点都不纠结流程究竟有几级的问题。
今天,跟业务流程管理还有一个相关的概念是“企业架构”,这两个概念有很大部分是重叠的,都涉及到组织建模、流程建模、应用建模和数据建模,只是 EA 的差异点,一是架构面更广一些,在这些内容之外,还涉及到商业模式、业务能力、基础设施等内容,二是更强调架构的治理,而 BPM 的差异点是流程方面做得更深强调流程全生命周期管理以及流程实施技术方案即工作流系统WfMS和各种流程自动化技术。
图片
如果说要画流程图的话,就是两个工具流派,一是 BPM 软件二是企业架构软件这两类软件都提供了流程建模模块今天这两类软件正在相互融合甚至已经是区别不大了。这类软件全都采用了流程建模的事实标准BPMN 2.0,不用就不是主流,以代表性产品 SAP PowerDesigner 为例,其他市面上的企业架构软件和 BPM 软件的流程建模工具都大同小异。
PowerDesigner主要包括三个架构企业架构、业务流程架构和数据架构三者可以互相关联。我们可以看见企业架构包括了组织架构、业务架构、应用架构、基础设施架构以及 IT 建设的项目和目标,业务流程和价值流等内容。
图片
而在业务流程架构中最宏观层级就是“流程地图”process map如果说这个就对应到 APQC 流程分级的一级和二级,有毛好纠结一级流程和二级流程的,就是一张图,十几个框框的事儿:
图片
这个流程地图上每一块称为“流程组”process group例如需求到现金demand to cash采购到支付procure to pay在流程组下就挂着若干流程图了。
PowerDesigner 里符合BPMN 2.0 规范的流程图没有分级流程就是流程。BPMN 2.0是一套标准化的用于业务流程建模的图形符号,旨在促进必须记录其流程的非技术业务用户,与使用计算机程序语言来实现流程的技术开发人员之间的沟通。
我觉得传统 ARIS 建模最大的问题就是过于复杂,就我十多年前在中国干 ARIS 实施的经验企业领导们对业务流程管理这个企业管理神器说起来浑身是劲做起来纷纷逃跑简直就是业务好龙——业务流程管理就是那条龙ARIS 这类 BPM 工具在企业实际实施效果不好(参见《为什么业务流程建模听起来很好,大多数企业却根本用不起来》《业务流程建模和企业架构应用于企业管理的误区》)。
图片
BPMN 2.0为了解决这个问题, 提供了两种变式:
-BPMN 2.0 Descriptive 描述式 BPMN 2.0,简单说这就是个“业务精简版”,它包含一个适用于业务流程设计和分析的 BPMN 2.0 对象子集,其目标用户为业务用户以及流程负责人(流程所有者)。
-BPMN 2.0 Executable 可执行式BPMN 2.0 Executable简单说这就是个“专业全面版”它包括所有标准 BPMN 2.0 对象,其目标用户为流程实现者的工程师们,包括技术建模人员,以及从 其他BPM 软件中执行反向工程的人员。
大家来感受一下这两种变式的流程图长得啥样的,这是“描述式”的流程图,业务人员描述业务用的:
图片
这是“专业式”的流程图,是工程师用的:
图片
我认为在咨询项目中,流程要画到几级是个毫无意义的讨论!今天既然 BPMN 2.0 已经成为事实性标准了,企业方和咨询方如果希望面向实施来做流程建模,更应该达成共识的是如何采用符合行业规范的流程工程标准?采用什么流程建模规范,是不是该用 BPMN 2.0?咨询项目产出的 BPMN 模型究竟是描述式的,还是执行式的?这才是保证技术落地的根本。
最后问题来了:
GEORGE陈果
3 人喜欢
个人观点,仅供参考
阅读 4597
陈果George
写下你的留言
精选留言
神经蛙
上海置顶
为什么你们说的东西我一个985大三本科生看不懂一点每个行业都要懂这个东西

View File

@ -1 +0,0 @@
# 1233456789

View File

@ -1 +0,0 @@
# test

View File

@ -1,5 +1,10 @@
---
title: 知识开源平台
---
# 知识开源平台介绍
- 知识星系
- 知识星球
- 知识库
- 知识块
- 知识块
- 创建知识

View File

@ -0,0 +1,170 @@
---
title: 纠结OKR、KPI 是因为HR管理不规范 职位序列和知识开源
---
原创 GEORGE陈果 陈果George 2023-10-16 18:50 发表于上海
很多公司的HR管理体系中的绩效管理一会儿搞OKR一会儿又换成KPI。企业界普遍认为二者区别是前者的绩效考核没有固定指标而是在相对短的周期内例如三个月一次不断变换业务目标设定并考核目标达成值而后者则是固定的指标在相对长周期内通常是一年一次设定并考核指标的达成值。
<!-- more -->
我们且不讨论 OKR 和 KPI 究竟区别是什么(参见《回归基本 祝贺OKR升级为PBC》就算是二者区别如大家的普遍认识实际上一个企业里的绩效考核方式并不应该一刀切one size fits all所有干部和员工采用一种模式在中大型企业运营中小步快跑的工作和按部就班的工作是同时存在的所以 HR 体系里应该多种模式并存企业的绩效考核应该是既有OKR又有 KPI。
如果企业纠结 OKR还是KPI 真正原因可能是这个企业没有形成兼容多样化的职业模型career model的 HR 管理体系,即不同序列、不同职级的人员采取差异化的 HR管理模式包括招聘、培训、薪酬、职业发展等。多职业模型的 HR 管理模式在成熟企业里已经是普遍实践了,就算是传统中国组织管理的思想里,也是这么做的——直管干部、知识分子、普通群众等等也是采用区别管理的政策,大型国企的 HR 管理体系都分干部处、人事处,说不定还有个“落实知识分子政策办公室”啥的。
十多年前我在IBM GBS工作时这个组织的专业人员不包括后台管理人员的职位序列体系叫“四座高峰”4 peaks即销售、咨询、交付和技术
图片
- 销售: 最终通向解决方案式销售的高管,能卖东西、搞定客户的大销售;
- 咨询:咨询业务的实务操作者,在咨询公司的商业模式中保持均衡的技能和经验,合伙人是咨询这个职业路径的最高级别;
- 交付:强调在大型、复杂的项目和合同中,具有指挥和协调能力,掌控风险、质量和成本;
- 技术:特定技术领域中的专精能力,做到高管就是杰出工程师。
当时IBM GBS 全球有十多万人号称全球最大的专业服务组织所有专业人员都要在这四个职业路径career path上找到自己的定位。公司高管之下的职级分为五级——从 06 级到 10 级,其中,当你从 08 级升到 09 级,可以选择路径转换,例如,如果你是 08 级咨询,可以申请转为 09 级销售,那么你的提级申请将按照 09 级销售的标准来评估。不同职业路径的薪酬结构和水平、绩效考核标准、能力素质构成等都不太一样。
这个四峰模型实际上是 IBM 收购普华永道咨询业务时,从普华永道咨询业务的 HR 体系继承过来的。大约是2012 年后IBM全球进行了一次 HR 管理体系整合,就把这个四峰模型整合进了 IBM 的总体职位序列里当时叫职业框架Career FrameworkGBS 就不存在单独的职业模型了。
写到这里读者是不是觉得术语有点混乱职业模型career model、职业路径career path、职业框架career framework、职位序列job family等等名词大家可能听晕了吧不要纠结字面的区别。当年果总也搞不明白这些乱七八糟的术语直到做人力资源咨询后搞清楚了基本原理才弄明白这些词儿说的其实就是一回事。
我今天在琢磨当年 GBS这四个峰划分的底层逻辑。
企业的职位的性质或者人才的特性可以从两个维度来区分:
- 创造性:工作绩效主要是依赖于员工的创意还是经验?前者更加取决于这个人的先天智商,而后者则取决于过去相关工作的经验积累。
- 控制性:工作的性质是比较结构化,既可以考查结果,也需要控制过程——我们姑且叫“控制“,还是工作的结构化程度化低,很难预料过程,结果具有不确定性,我们姑且叫“灵活”。
从这两个维度,我们可以把企业的人才或者职位分为四类:
- 管理者
- 商务者
- 工程师
- 创造者
图片
管理者
商务者
工程师
创造者
招聘
学历要求中,自行培养为主
学历和经验均无太高要求,看情商和业绩
没有太高学历要求,主要看相关技能经验
智力要求高,通过学历来衡量
培训
方案制度培训
软技能培训
在工作中培训
软技能培训
绩效
以工作中展现的能力评定适用KPI
以业绩评定适用KPI
以工作中展现的能力评定适用OKR
高淘汰率来鼓励竞争适用OKR
薪酬
市场平均水平,浮动比例低
浮动比例高,跟业绩挂钩
市场平均水平,浮动比例低
市场较高分位值水平,高淘汰率
这个划分适用于任何行业、任何企业,可以将每个企业的一些具体职位按照这四个职位族群来归类:
图片
如果我们把 IBM GBS 的四峰模型对应过来,有很明确的对应关系:
-销售:商务者
-咨询:创造者
-交付:管理者
-技术:工程师
这就是 IBM GBS 的职业路径要做成四峰的底层逻辑。如果考虑到职业发展的层级这个四峰模型实际上是个四棱锥模型Z 轴是职级维度:一般来说职级较低时,强调在在自己的跑道里跑好,而越到组织高层,则越强调综合能力,强调在四种能力模型中的均衡:
图片
无论是咨询顾问,还是企业管理者,批判性思维、第一性思维太重要了(参见《【果总咨询观】 咨询是批判性思维的服务》。过去做HR咨询上来就划分职位序列但是很少人会有反复问 为什么要划分序列?划分的原则是什么?
好的咨询是要让企业理解为什么要这么做,而不是怎么做? 市面上的“学华为派”咨询的最大问题就是让企业生搬硬套华为的实践例如服装企业搞IPD、医药企业搞铁三角而没有理解那些华为实践的原理是什么如果要学华为的话怎样结合企业自身实际情况。
这也是我做企业知识开源的初心: 让中国企业和企业服务机构在开展管理实践时,对于企业知识的底层逻辑、基础概念达成共识。
GEORGE陈果
1 人喜欢
个人观点,仅供参考
阅读 3366
陈果George
喜欢此内容的人还喜欢
流程管理和流程数字化 活动成本法
1个朋友分享
陈果George
不喜欢
企业架构是CIO方法论 人力资源信息系统里管领电脑吗
1个朋友分享
陈果George
不喜欢
写下你的留言
精选留言
加兴@场略公司
四川
有家公司应聘流程包括智力测试12分钟100道题进公司起智商序列就很清楚了所以大项目谁做绝不可能出现“大家都能做恰好你做了”的偶然事件。不过高智商搞砸的项目也多因为追求高难度解决方案。🤣洞见性、预见性恰恰在IQ中测不出来。[偷笑]
2条回复
陈果George
(作者)
只就招聘测评而言现在领先的咨询公司招聘测评至少有四五项测评包括reasoning, personality, motivation 等, 洞见性可以用Hogan等方式。
绩效与执行力教练
浙江
新概念只是别有它图的人割韭菜的新瓶旧酒如果你境界不够理解不到绩效的本质和目的是由八十分提高到九十分而不是打完八十分就结束了境界无形中会成为你的底层逻辑和价值判断标准这个标准会让你排他其次无论什么理论都需要管理的基础突破人才测评、根因分析、解决问题、PBL培训等基础突破不解决什么理论都不能落地这就像华为5G之所以成为国际标准在于其香农定理的通信理论突破名医之所以治好病在于对各类药材的精通掌握和灵活组合这个基础突破
1条回复
F-Bai🌸🐟🌷
陕西
最近在思考团队人员管理的问题,果总这篇解答了我的一些疑惑[强]
Balhae
福建
OK R就是个笑话
已无更多数据
人划线