在复杂性与持续改进之间取得平衡—汽车行业案例研究

>>>>背景

如今汽车行业面临着巨大挑战。近 30-40 年来&＃xff0c;汽车制造商不仅面临着激烈的市场竞争&＃xff0c;还承受着生产创新型节能汽车、同时降低制造成本的压力。

同时&＃xff0c;当前的技术进步正在拓展汽车行业的发展空间&＃xff0c;更多先进、复杂的技术将应用到汽车中。数字化不仅影响了汽车系统的运转方式&＃xff0c;还推动了制造流程和汽车制造商的业务运营方式的改革。现在技术几乎已经影响到汽车业务的方方面&＃xff0c;汽车制造商的 IT 环境逐渐成为一个在企业内外运行的互连系统网络。

此外&＃xff0c;随着计算系统在车辆运行系统中变得更加不可或缺&＃xff0c;传统 IT 功能与汽车内部 IT 功能之间的界限开始模糊。如今&＃xff0c;大数据与分析、 物联网 以及 The Open Group 开放平台 3.0™ 等新兴技术不断涌现&＃xff0c;持续增强汽车、制造商、经销商和所有者的互联程度。在这一趋势下&＃xff0c;汽车公司的 IT 部门不得不以前所未有的方式投入到产品开发和维护等业务领域中。

在经济因素和技术变革的夹击下&＃xff0c;汽车制造商与当今的许多企业一样面临着巨大的不确定性&＃xff0c;迫切需要进行重大转型&＃xff0c;以便应对前所未有的业务复杂性。

>>>>公司

本案例研究中的汽车公司就面临着这些严峻挑战。除了一般的经济和技术变革之外&＃xff0c;该公司还进行了一系列转型&＃xff0c;因此面临更多的基础设施问题。该公司在近 20 年里被三番收购&＃xff0c;增添了两名所有者和新技术系统。在公司原有传统 IT 系统和收购方引进的系统的共同作用下&＃xff0c;公司的 IT 环境变得极为复杂。此外&＃xff0c;在蓬勃发展的中国市场&＃xff0c;该公司正在扩大业务规模&＃xff0c;而要想从中国日益增长的财富中分得一杯羹并提高销量&＃xff0c;就必须加大基础设施投资。

面临着仍在运转的现有系统、亟待拓展的新兴市场及日益数字化的公司结构和产品&＃xff0c;该公司迫切需要重塑整体架构。

>>>>问题

虽然该公司在很早便开始利用 IT 来尽量确保整个公司价值链中信息流的有效性&＃xff0c;但随着所有者的更换&＃xff0c;当前 IT 环境已变得有些臃肿。为应对日益数字化的业务环境&＃xff0c;公司不仅需要解决不断增加的系统复杂性问题&＃xff0c;还要设计面向未来的可扩展系统。

之前该公司便开始考虑使用 企业架构 方法来解决这一难题。虽然公司员工中不乏解决方案架构师&＃xff0c;但他们很快意识到需要一种可覆盖整个企业的更全面方法&＃xff0c;而不是东拼西凑地构建 IT 环境。

在上市时间为王的行业中&＃xff0c;平衡短期解决方案与战略投资是一个永恒的话题。因此&＃xff0c;该公司开始投资建立企业架构&＃xff0c;以更好地了解并解决内部复杂性问题。由于 The Open Group 标准TOGAF® 是名副其实的企业架构行业标准&＃xff0c;因此自然便成为了该公司创建架构框架的首选。公司的大部分员工和企业架构师都接受了 TOGAF 9 培训&＃xff0c;并获得相关认证。之后公司的 IT 部门架构社区将 TOGAF 投入了实践。

TOGAF 为 IT 部门提供了一种探讨 IT 问题的平台&＃xff0c;同时为企业架构库奠定了基础。但是 IT 部门主要将其视为 IT 架构&＃xff0c;而不是转型的框架。企业架构团队决定&＃xff0c;为真正从 TOGAF 中获益&＃xff0c;并解决企业结构庞杂的问题&＃xff0c;他们需要证明 TOGAF 能够为整个企业创造更高价值&＃xff0c;并且能够推动 IT 环境变革&＃xff0c;同时证明结构化方法对解决内部问题的价值。

为证明 TOGAF 能够帮助公司实现整体转型&＃xff0c;该团队决定在不同的业务领域内实施几个试点项目&＃xff0c;以展示结构化方法对变革的促进作用。公司采购产品组件的方式需要改善&＃xff0c;采购流程又被普遍认为是最复杂的业务领域之一&＃xff0c;因此该团队决定先为其试验 TOGAF 方法。

>>>>全新采购平台

初期试点项目的目标是对公司的采购环境进行现代化改造。虽然通常采购是一个非常简单的流程&＃xff0c;但在汽车业&＃xff0c;产品结构内部的错综复杂性和多样性加之控制物流成本和物料流的需求为该公司带来了重大挑战。简言之&＃xff0c;为节省成本&＃xff0c;公司只希望恰到好处地采购汽车制造流程中实际用到的物料。

多年以来&＃xff0c;支持公司采购流程的 IT 因投资各种单点解决方案和不同的长期合作伙伴关系而变得非常分散。此外&＃xff0c;系统中的某些部分已经关闭&＃xff0c;这进一步加大了确定信息流&＃xff08;包括一直以来所有的系统集成&＃xff09;的难度。采购流程中的 IT 支持也存在一些重大缺口&＃xff0c;严重限制了流程的透明性和完整性。

>>>>解决方案

该团队以 TOGAF 作为架构框架和方法&＃xff0c;使用 The Open Group 标准ArchiMate® 进行符号建模&＃xff0c;并使用 Sparx Enterprise Architect (EA) 作为建模工具&＃xff0c;开始为实施新采购平台建立路线图。TOGAF 架构开发方法 (ADM) 用于建立架构愿景&＃xff0c;架构开发阶段已经完成&＃xff0c;勾勒了目标架构和后续路线图。ADM 没有进行重大调整&＃xff0c;但是为了确保顺利实施&＃xff0c;团队同步运行了平台寻源流程&＃xff0c;需要使用迭代方法。 作为路线图的一部

作为路线图的一部分&＃xff0c;团队开发了以下 ArchiMate 视图&＃xff1a;

• 动机视图
• 信息结构视图
• 基准和目标业务流程视图
• 基准和目标业务功能视图
• 基准和目标应用功能视图
• 基准和目标应用环境视图
• 基准和目标应用使用视图
• 基准和目标基础设施环境视图
• 基准和目标基础设施使用视图

所有视图均使用经过配置的 Sparx EA 创建&＃xff0c;后者能够推进 ADM 流程&＃xff0c;并用作架构库。

TOGAF ADM 提供了一种开发路线图的结构化方法&＃xff0c;其中相关成效可以追溯到最初的愿景。定义清晰的方法以及明确的交付成果和构件元模型有助于找到工作重点&＃xff0c;TOGAF 和 ArchiMate 也相对容易找到切入点。

项目面临的问题主要集中在一个领域&＃xff0c;即协调架构开发与 IT 解决方案寻源流程。由于公司希望尽早确定寻源解决方案以评估成本和发起谈判&＃xff0c;这迫使项目很早就进入了确立构成模块的解决方案阶段。大部分情况下&＃xff0c;ADM 流程的输出成果可直接投入到商业解决方案寻源中&＃xff1b;但是在该案例中&＃xff0c;寻源很快就优先于架构开发流程了。通常从 ADM 阶段 A 到 E 只需几个月就可完成&＃xff0c;但事实证明&＃xff0c;该公司内的解决方案评估与筹资更加困难和耗时。

>>>>成效

在制定全新采购流程路线图以后&＃xff0c;该公司现在开始使用 ADM 与新供应商接洽和获取信息邀请书 (RFI)。此外&＃xff0c;使用 TOGAF 和 ArchiMate 有助于解构曾被认为极为复杂的采购流程和制定基础设施路线图。该项目能够帮助 IT 团队发现流程中真正的复杂性所在&＃xff0c;其中有很多是位于组件层面而不是系统内部。此外&＃xff0c;公司还能够在开始实施流程时确定优先领域。

>>>>结论

最初该公司将 TOGAF 视作一剂良药&＃xff0c;但它必须要认识到&＃xff0c;虽然 TOGAF 代表着最佳实践&＃xff0c;但任何组织内部都需要技能娴熟、知识丰富和获得充足支持的企业架构师。

在项目中 TOGAF 带来了以下优势&＃xff1a;

• 提供分析结构
• 确保涵括所有域的全面视角
• 让团队专注于成效、定义和路线图等
• 提供有关路线图当前和未来数据的良好视图
• 提供业经验证的分析可信度

ArchiMate 通过提供定义明确的视角带来了更多支持&＃xff1b;Sparx EA 是一种经济高效的建模工具和架构库&＃xff0c;计划中的所有利益相关方均可轻松部署。

但是在这一特定的组织内仍然有许多亟待解决的问题&＃xff0c;其中有很多会阻碍 TOGAF 的应用&＃xff0c;这些挑战包括&＃xff1a;

• 相互矛盾的流程、方法和功能
• 过于注重解决方案设计而非架构
• 过于注重项目交付而非管理计划与成效
• 侧重于对解决方案而非架构的治理

实践证明&＃xff0c;该公司内部采用 Archimate 是一种更简单的方法&＃xff0c;因为它能够用于解决即时的建模需求&＃xff0c;而无需协调方法与管理。

在此类案例中&＃xff0c;最好将 TOGAF 和 Archimate 作为通用解决方案销售给业务组织&＃xff0c;而非特定的技术架构方法。即便如此&＃xff0c;我们也不会像过去一样过分推销技术解决方案&＃xff0c;而是着重介绍流程的业务优势。

>>>>未来计划

目前该公司已经进入路线图的实施阶段&＃xff0c;所有员工也经常使用 ArchiMate 对公司内不同的业务领域建模。此外&＃xff0c;TOGAF 工具和概念也已经在多个计划中成功投入实践。但是由于目前该公司着重于发布新车型&＃xff0c;在公司其他部门正式实施更全面的企业架构框架的进度放慢。对该公司而言&＃xff0c;这只是周期性现象&＃xff0c;一旦对交付产品的直接关注削弱&＃xff0c;整合和简化需求又会成为重中之重。

与大部分公司一样&＃xff0c;成功实施企业架构功能的关键归根结底还在于在 IT 部门及其支持的业务部门之间建立更加有效的合作关系。因此&＃xff0c;对此类项目来说&＃xff0c;IT 部门尽早参与业务计划是关键。IT 部门不仅要将自身定位为技术支持部门&＃xff0c;还应该成为能够提供投资建议的业务合作伙伴&＃xff0c;并通过改善流程和推进基于技术的业务转型帮助最大限度地降低业务风险&＃xff08;如同 TOGAF 和 ArchiMate 等方法有这方面的要求&＃xff09;。这就要求 IT 支持符合公司使命及其业务目标。项目经理、业务分析员和企业架构师必须对如何实现业务成功达成共识。如果企业上下无法达成一致&＃xff0c;这些工具将只能支持单个员工的工作&＃xff0c;而无法实现其真正的潜力。