IT4IT™ 标准模拟演练

在 The Open Group 阿姆斯特丹大会上,与会者以游戏的形式体验了The Open Group 的一项标准 — IT4IT™ 参考架构。GamingWorks BV 的共同所有人 Jan Schilt 扮演 UBanQ 银行的首席执行官。作为首席执行官,Jan 要求几个团队证明他们能够在竞争激烈、瞬息万变的数字世界中让 UBanQ 成为客户的首选银行。

首席执行官解释说:“UBanQ 在字面上既可表示“你的银行”,又可表示“你-银行”,反映了人与人之间的联系。”

这些团队使用 IT4IT™ 模拟 UbanQ 业务。为了使 UbanQ 成为客户的首选银行,他们需要在模拟过程中购置新产品和服务,并使用 IT4IT 标准中的概念来降低成本、提高速度和改善质量。

三个团队围绕网点的运营业绩和愿景实现程度展开了激烈的竞争。首席执行官要求创建一个显示各网点业绩的仪表盘,以展示收入和利润的增长、成本的削减、行业领先的客户满意度、市场份额的拓展以及客户数量的增长情况。

困难是前进道路上的垫脚石,而不是绊脚石。

模拟一开始,团队就遇到了客户投诉、产品缺陷、新客户要求以及由于结构性问题、支持性冗余产品/服务以及平衡技术债务而导致的效率低下等一系列问题。由于各个独立的计划、构建和运行单元需要作为一个价值链来运行,他们不得不左右同时开弓,一边计划和执行工作,一边计划和执行改进。

结果如何?第一轮模拟结束后,团队就最终结果进行了反思,更重要的是,对这种结果所反映的日常工作中的问题进行了总结。这些问题包括:

  • 难以组织端到端的团队和流程。无法确定各项任务的负责人、各类信息的归属方和需求方、各项任务的交接流程
  • 各个孤岛之间沟通不畅(无论是在团队的沟通和协作技能方面,还是数据和信息的准确性、完整性、及时性和相关性方面)
  • 各个孤岛的数据和信息缺乏可视性,例如哪些服务属于哪些应用和配置项、哪些服务应该变得冗余。支持“计划、构建和运行”需求的信息不匹配和缺失,浪费了时间、精力和成本并导致出现错误
  • 不清楚任务优先级,不了解共同目标和期望值

首席执行官展示了两个团队的仪表盘,仪表盘显示客户满意度显著下降、成本浪费和收入流失,令人唏嘘。

构建“适应未来”的能力

随后各个团队引入了 IT4IT 标准的构建模块。团队现在可以选择其中任意模块,体验哪些模块可以帮助应对挑战或重塑组织结构,从而打造客户心中首选的数字银行。构建模块是 IT4IT 标准概念的“升级版”,团队中的每个孤岛都可以提出建议,例如集成数据库、自动化测试、投资组合计划或战略计划。

不同的 UBanQ 团队通常会选择不同的构建模块开始着手。架构师通常选择 CMDB(端到端骨干网),商业产品所有者选择支持投资组合计划的模块,DevOps 利益相关者可能会选择自动部署模块。问题是,谁负责端到端地协调这些构建模块、管理它们之间的依赖关系,进而优化价值链?

理论 – 说起来容易做起来难!

参加模拟的团队都选择了不同的构建模块。他们都意识到,改进不只是部署新工具和新流程那么简单。改变行为并整合端到端功能才是关键。他们的工作成果如何?

  • 付出的努力双双白费(不一致,缺少端到端 CMDB),生产力未得到充分利用(待办事项和进行中的工作缺乏可视性)
  • 尽管购买了一个综合数据库,但似乎并没什么用。尚不清楚它能带来什么好处
  • 已经安装了综合数据库,但并不是每个人都知道如何使用它或如何将其集成到他们的工作实践中
  • 任务孤岛过多,各自为营、各行其是,没有确立端到端目标和交付价值的优先级
  • 无人负责协调和集成整个价值链中的构建模块

既有流,也有链,但就是看不见价值。

首席执行官经常在团队回顾总结时提问: “……有人知道目标和期望值吗?”各团队的回答让他颇为失望。他指出:“采用新方法和购买新技术固然很好,但是如果我们没有明确的价值目标,也无法将这一目标贯穿端到端价值链中,那么它就会变成阻碍进步的枷锁……”

团队再次就新构建模块的改进和使用达成了一致,确保将重点放在端到端功能上。尽管如此,他们仍然难以将改进的新成果融入到工作方式中。要让 IT4IT 标准交付端到端价值,行为改变、指导、所有权、领导力等都是必须要关注的隐形因素和技能。

发现

“收入略有增加,客户满意度下降。”

对于 IT4IT 构建模块的重要性和具体落实方法,团队有哪些重要发现?

显然,这是一个漫长而艰难的过程,需要在反复改进的过程中改变思维模式和行为方式,并构建端到端的价值链功能。

  • 重要的是,他们应该确保端到端数据和信息流的可集成性、一致性和可用性(人们知道如何使用它来支持和赋能端到端价值流活动和决策)
  • 随着工作的累积,人们往往将重点放在如何满足新业务需求和避免业务中断上,却没有考虑清除壁垒、化繁为简。划分资源优先级和预留出持续改进的时间非常关键
  • 效率并非效用。一个团队可能会获得“自动化”效率,但如果客户满意度较低,则代表其缺乏效用。持续学习和改进应该找对方向

最后一点恰好应验了 Charlie Betz 和 Myles Suer 在“数字管理专家日”当天一早发表的“数字运营模式”演讲中的一个论点,即“效率不等同于效用”。无法交付价值的敏捷性都是空谈。

“制定 IT4IT 标准的初衷是让多厂商的 IT 环境协同运行。只有实现接口和数据架构标准化,用户才不会花集成工具的冤枉钱。”

“……我们需要的是‘全工具链数据流自动化’,以便为 DevOps 工具管道提供支持……”

“…孤岛之间的信息流通常不确定且不一致……”

转:The Open Group https://mp.weixin.qq.com/s/EcmX0nnnq2mkyBvRBXTpqQ

更多文章