Compare commits

...

47 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
3 changed files with 253 additions and 11 deletions

View File

@ -1,8 +1,8 @@
---
title: 业务流程分级3
title: 业务流程分级34
---
在我的管理咨询生涯里,跟客户谈“业务流程分级”,咨询项目画业务流程要画到几级,是个很让人困扰的话题(参见《在企业现实中,我从来没有看到过啥“六级流程”》《业务流程管理咨询的一片乱象》)。流程究竟如何分级,不同的业务流程管理方法论里使用的名词都比较混乱,没有统一标准,同样一个词(例如活动 - activity在不同体系中表达的意思是不一样的。下表我列出了有代表性的四种分层命名方法以及各层所表示的业务颗粒度和信息颗粒度的大致对应关系
在我的管理咨询生涯里12,跟客户谈“业务流程分级”,咨询项目画业务流程要画到几级,是个很让人困扰的话题(参见《在企业现实中,我从来没有看到过啥“六级流程”》《业务流程管理咨询的一片乱象》)。流程究竟如何分级,不同的业务流程管理方法论里使用的名词都比较混乱,没有统一标准,同样一个词(例如活动 - activity在不同体系中表达的意思是不一样的。下表我列出了有代表性的四种分层命名方法以及各层所表示的业务颗粒度和信息颗粒度的大致对应关系
流程层级
@ -13,22 +13,21 @@ SAP ASAP流程架构
SAP solution manager
SCOR供应链流程框架
<!-- more -->
1
Category
Business area
2
Process group
Process group
Level 1 Process type
3
@ -63,13 +62,8 @@ Level 4 workflow
6
activity
APQC的层级命名方法相对比较普及如果我们以它为标准三级叫做“流程”的话比三级的层级高的属于商业模式设计的范畴包括了流程类别以及流程类别的构成关系比三级的层级低的属于每个流程里的具体的活动、任务或叫步骤那么当我们在工作中说“流程”或者“业务流程”的时候我们想表达的意思究竟是在说第三级这个颗粒度还是包含了一至五级甚至更细的所有内容
图片
@ -114,3 +108,4 @@ APQC的层级命名方法相对比较普及如果我们以它为标准
在中国,能够把企业变革和流程实施结合起来的企业非常少,我观察到一家公认企业转型最成功的企业,在流程和 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、少看抖音、视频号上的业务流程管理网红的视频那些人大多数不懂。

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实践没有关系只是一种有害的管理忽悠。