业务架构金三角

Paul Leinwand和Joachim Rotering在他们的文章“如何在战略和执行上都出类拔萃?”(哈佛商业评论,2017年11月)中指出,要缩小战略与执行之间的差距需要正确把握三个方面,并给了我们一些不错的反思问题:

1. 制定战略

  • 当你在应对干扰的时候,你是在用自己的优势塑造你周围的世界,还是在等待改变的发生,从而遵守别人的规则?
  • 在制定战略的过程中,您是在使用“构建战略,然后考虑执行”这一经典方法,还是在问自己“您是否具备执行战略所需的能力?”?
  • 你是否非常清楚你是如何以其他人所不具备的方式为客户增加价值,以及使你能够在价值主张上出类拔萃的具体能力?

2. 将战略转化为日常工作

  • 你是否努力贯彻你的决定?你需要非常清楚战略是什么,以及成功所需的条件,并将其进行沟通,以便组织中的每个人都明白他们应该做什么。
  • 是否有可见的计划(例如特定的新技术、新流程或培训计划)来构建您的组织在战略上取胜所需的关键能力?
  • 你是否在战略和预算过程之间建立了具体的联系,以便将资金重新分配到最重要的地方?你是否有将战略转化为个人目标和对管理者和员工的奖励的机制?

3. 执行战略

  • 你是否每天都在激励员工,了解他们所做的与你所关注的重要战略杠杆之间的联系?
  • 你是否能让员工跨组织的竖井一起工作,以应对让公司获胜的跨职能挑战?
  • 您是否不仅要跟踪自己的绩效,还要跟踪您如何构建和扩展那些使您能够以其他人无法实现的方式为客户创造价值的关键能力?
  • 您的管理团队是否参与到您如何执行战略中,而不仅仅是通过衡量结果,而是通过不断挑战组织并支持它提高其关键能力?你是否为你的团队设定了足够高的目标来完成他们需要完成的任务,以及在什么时候?
  • 我们相信公司的战略执行力是巨大的。能够同时成为远见者和经营者,并在这两种思维模式之间转换的领导者,才是能够将其组织转变为超级竞争对手的领导者。

根据《BIZBOK®指南》,“业务架构代表了以下方面的整体、多维业务视图:能力、端到端价值交付、信息和组织,以及这些业务视图和战略、产品、政策、举措和利益相关者之间的关系。” 换句话说,业务架构主要涉及战略到执行过程中事物之间的相互关系,这使其非常适合用作解决上述问题的基础。

业务架构思维和框架公开课中,我们讲到的业务架构框架的核心是业务架构金三角

它是一个基本框架,包括三个主要组成部分:

  1. 商业动机(如愿景、使命等)
    • 为什么存在?
    • 要实现什么目标?
    • 达成未来目标的路标是什么?
  2. 商业模式(如价值主张、客户群、合作伙伴等)
    • 为谁提供什么价值?
    • 如何创造、交付价值?
  3. 业务执行(如能力、流程、IT等)
    • 我们能做什么?
    • 我们怎么做?

商业动机、商业模式和业务执行不应被认为是相互独立的。相比之下,管理一个部分至少需要考虑其他部分,它们之间的关系可以用带有数字的连线表示如下:

摘自《业务架构思维和框架公开课》讲义
  1. 商业模式的当前状态,例如,包括所提供的产品和目标客户群体,为(重新)开发商业动机设定了上下文;。此外还可以分析业务执行的当前状态(业务能力级别),以确定优劣势,从而为商业动机的发展提供信息。
  2. 一旦根据输入确定了战略选项,就可以评估它们对商业模式的任何影响,进而评估它们对当前状态下的业务执行的影响。
  3. 一旦做出了战略选择,新的商业动机就会转化为to-be商业模式,而商业模式的未来状态又决定了业务执行的未来状态。
  4. 从商业模式的执行情况来看,可能无法充分地分析商业模式的执行情况。在这种情况下,可能需要确定战略来定义业务执行中的更改,以正确实现当前的商业模式,而当前商业模式本身将保持不变。此外,可能还有一些不一定会影响商业模式的进一步战略,但可能会直接影响执行水平(如控制系统、领导、激励、组织结构、提高员工满意度的变化),以优化和维持商业模式的实现。

如何创建客户旅程地图?

概述:为了帮助团队理解和满足客户需求,旅程地图结合了两种强大的工具 – 讲故事和可视化。虽然根据上下文和业务目标,地图有各种各样的形式,但是通常包含某些元素,并且有一些基本的指导方针可以帮助它们成为最成功的。

什么是客户旅程地图?

因为这个问题很常见,让我们直接从答案开始。

定义:客户旅程地图是一个人为了实现目标而经历的过程的可视化,它用于理解和解决客户需求和痛点。

在最基本的形式中,旅程地图首先将一系列用户目标和操作转化为时间线骨架。接下来,用用户的想法和情感来充实这个框架,以创造一个故事。最后,这种叙述被压缩成一个可视化的工具,用来传达设计过程的信息。

旅程地图结合了两个强大的工具:讲故事和可视化。

讲故事和可视化是旅程地图的基本方面,因为它们是以一种令人难忘、简洁的方式传递信息的有效机制,并创建了一个共享的愿景。

在为每个部门或组分配和度量KPI的组织中,碎片化的理解是长期存在的,因为许多组织从来没有从用户的角度将整个体验拼凑在一起。这种共享的愿景是旅程地图的一个关键目标,因为没有它,就如何改进客户体验达成一致将永远不会发生。

旅程地图创建了一个客户体验的整体视图,正是这个过程将不同的数据点集合在一起并可视化,从而可以吸引来自不同组的不感兴趣的利益相关者,并促进协作对话和更改。

解构客户旅程地图

虽然旅程地图根据所使用的特定上下文而变化,但它们倾向于遵循一个通用的模型,其中包括“透镜”区域、地图体验及贯穿整个过程的洞察。

请参见下面的图注释:

  • 区域A:透镜通过分配(1)一个角色(“谁”)和(2)要检查的场景和目标及期望(“什么”)来为地图提供约束。
  • 区域B:地图的核心是视觉化的体验,通常在旅途的(3)阶段,(4)用户在整个过程中的行为、(5)想法和(6)情感体验都可以通过引用或研究视频进行补充。
  • 区域C:根据地图支持的业务目标,输出应该有所不同,但是它可以描述发现的洞察和痛点,以及(7)关注未来的机会,以及(8)内部所有权。

你为什么需要旅程地图?什么时候需要?

应该始终创建旅程地图以支持已知的业务目标,不与业务目标一致的地图不会产生可应用的洞察。目标可能是一个外部问题,比如:了解一个特定角色的购买行为,或者一个内部问题,比如:解决对客户体验的某些部分缺乏所有权的问题。下面列出了一些可能的业务目标,这些业务目标可以用于地图。

  • 将公司的视角从内到外转变到由外到内。如果一个组织允许内部流程和系统驱动影响客户体验的决策,那么通过关注客户的想法、行为和情绪,一个旅行地图可以帮助改变该组织的文化。旅程地图揭示了真实的人类经验,而这些经验往往是组织所知甚少的。
  • 打破竖井,创建一个共享的、组织范围的愿景。因为旅程地图创建了整个客户旅程的愿景,它们成为创建跨部门对话和协作的工具。旅程地图可能是构建整个组织范围的行动计划,以投资于客户体验的第一步,因为它有助于回答“我们从哪里开始?”。
  • 分配关键触点的所有权给内部部门。通常,客户旅程中不一致和故障的地方存在,仅仅是因为没有内部团队承担该元素的所有权。旅程地图可以在不同阶段的部门或组之间建立清晰的一致性,或者在旅途中需要解决的关键触点。
  • 针对具体客户。旅程地图可以帮助团队专注于特定的角色或客户,无论是在多个角色的旅程中理解差异或相似之处,优先考虑高价值的角色,还是探索针对新类型客户的方法。
  • 了解定量数据。如果你通过分析或其他定量数据意识到某些特定的事情正在发生 – 也许在线销售正趋于停滞,或者在线工具被低估 – 旅程地图可以帮助你找到原因。

客户旅程地图的关键元素

虽然旅程地图可以(而且应该)采用各种形式,但一般包括某些元素:

(1)视角

首先,选择故事的参与者,这张旅程地图是关于谁的?

例如:一所大学可能会选择学生或教员,这两种选择都会导致非常不同的旅程。如果角色存在的话,“参与者”通常会与角色保持一致。作为指导方针,在创建一个基本的旅行地图时,使用每个地图的一个视角来提供一个强有力的、清晰的叙述。

(2)场景

接下来,确定要地图的具体体验。这可能是一个已经存在的旅程,地图将揭示当前体验中的积极和消极时刻,也可能是一个“未来”体验,地图设计者正在为一个尚未存在的产品或服务设计一个旅程,确保在此过程中明确用户的目标。两个词地图最适合描述一系列事件的场景,如购买行为或旅行。

(3)操作、心态和情绪

在旅程地图的叙述的核心,是用户在旅途中所做的事情、思考的事情和感受。这些数据点应该基于定性研究,如实地研究、上下文查询和日记研究,表示的粒度可以根据地图的目的而变化。目的是评估或设计一个完整的、广泛的采购周期还是一个包含的系统?

(4)触点和渠道

该地图应该将接触点(当地图中的参与者实际与公司交互时的时间)和渠道(沟通或服务交付的方法,如网站或实体店)与用户目标和操作对齐,这些元素值得特别强调,因为它们经常暴露出品牌不一致和不连贯的体验。

(5)洞察和所有权

旅程地图过程的全部要点是发现用户体验中的差距(这在全渠道旅行中尤为常见),然后采取行动优化体验,洞察和所有权是经常被忽视的关键因素,旅程地图中出现的任何见解都应该明确地列出。

可行的话,还可以为旅程地图的不同部分分配所有权,这样就可以清楚地知道谁负责客户旅程的哪些方面。没有所有权,没有人有责任或授权去改变任何事情。

即使包含了上述所有关键元素,两个旅程图看起来可能完全不同,但都非常适合它们所设计的上下文。在决定包含哪些元素时,需要在范围、焦点、广度和深度之间进行权衡。

要对这些权衡做出明智的决定,请考虑以下几点:

  • 为了讲述完整的故事,需要什么层次的细节?
  • 为了提供最真实的叙述,还需要哪些元素(比如:设备、渠道、遇到的内容)?
  • 这次旅程的目的是为了诊断当前的问题,还是设计一种新的体验?
  • 外部行为(在客户端)和内部行为(在组织端)之间的平衡是什么?
  • 谁将使用这张旅程地图?

创建成功的旅程地图的规则

成功的旅行地图不仅仅需要包含“正确的”元素。旅程地图应该是一个协作过程,由定义明确的目标指导,并从研究中构建。要使过程保持在正确的轨道上,这需要付出艰苦的努力。

以下是一些提示,以确保过程开始和保持在正确的方向:

(1)建立“为什么”和“什么”。

首先,确定路线图将支持的业务目标。在开始这个过程之前,确保这些基本的关键问题都有明确的答案:

  • 这个旅程地图支持什么业务目标?
  • 谁会使用它?
  • 它是关于谁的,是关于什么体验的?
  • 它将如何被共享?

(2)基本的事理

旅程地图应该是真实的叙述,而不是虚构的。从收集任何现有的研究开始,但还需要更多的基于旅程的研究来填补现有研究无法覆盖的空白。这是一个定性研究过程。虽然定量数据可以帮助支持或验证(或帮助说服那些可能将定性数据视为“模糊”的利益相关者),但单凭数量数据无法构建一个故事。

(3)与他人合作

旅程地图的活动(而不是输出本身)通常是过程中最有价值的部分,所以需要其他人参与。拉开帷幕,邀请来自不同团体的利益相关者参与数据的汇编和地图的构建。

(4)不要跳到可视化

创造一个美学图形或跳转到设计的诱惑,可以导致美丽但有缺陷的旅行地图。在开始创建可视化之前,请确保数据的合成是完整的、易于理解的。

(5)用最终产品吸引其他人

不要指望仅仅通过发送一个图片作为电子邮件附件,就能得到“认同”并培养你对旅行地图的兴趣。让它成为一个活生生的交互式文档,人们可以成为其中的一部分。在会议和谈话中提出你的故事,以促进别人相信并开始引用的叙述。一个想法是创建一个旅程地图展示室,在这里,任何不是直接在团队中的人都可以体验过程和产生的工件。

原文作者:Kate Kaplan

原文链接:https://www.nngroup.com/articles/customer-journey-mapping/

BIZBOK10 认证公开课

3月24日与BAGuild主席和联合创始人wmmulrich线上交流了一个小时,我计划今年底向BAGuild提交中文讲义,申请开BIZBOK认证公开课,开始在中国做业务架构BIZBOK的布道。

到时参加我们的课程,你可以获得什么?

BIZBOK10.0 电子书

上面这张封面,估计大家已经在IT帮大本营看过好几次了,但就是看不到里面的内容(大家也不用去网上搜索PDF文件了,找不到的)。到时你参加捷创成咨询的BIZBOK认证公开课,就可以拥有印有自己名字水印的英文PDF电子书了。

BIZBOK知识体系的目录如下:

  • 1. 介绍
  • 2. 业务架构蓝图
    • 业务战略地图
    • 能力地图
    • 组织地图
    • 价值地图
    • 信息地图
    • 举措地图
    • 产品地图
    • 利益相关者地图
    • 政策地图
  • 3. 业务架构实践指南
    • 通用入门方法
    • 业务架构治理
    • 业务架构和商业模式
    • 业务架构和业务流程建模与管理
    • 业务架构和案例管理
    • 业务架构和精益六西格玛
    • 业务架构和流程绩效管理
    • 业务架构和需求对齐
    • 业务架构成熟度模型
    • 业务架构师角色
    • 业务架构和战略实现
    • 业务架构和运营模型
    • 业务架构和客户体验设计
  • 4. 业务架构场景
  • 5. 业务架构基础设施管理
    • 业务架构知识库
    • 业务架构工具选项
  • 6. 业务架构和IT架构对齐
    • 业务架构和IT架构对齐概述
    • 业务架构和企业架构框架对齐
    • 业务架构和系统开发生命周期
    • 业务架构和应用组合管理
    • 业务架构和SOA对齐
    • 业务架构和数据架构对齐
    • 业务架构和解决方案架构
    • 业务架构和IT架构转型
  • 7.业务架构案例研究
  • 8.行业参考模型
    • 金融服务行业参考模型
    • 制造行业参考模型
    • 医疗保健行业参考模型
    • 基于会员的协会行业参考模型
    • 保险行业参考模型
    • 通用参考模型
    • 运输业参考模型
    • 政府行业参考模型
金融服务行业参考模型(做的一个翻译,PDF没有中文)

行业参考模型

如果你报名课程选择了附加包,你将可以获得官方已发布的所有行业参考模型。例如下图有几个行业的Excel文件:

下面这张图来自通用参考模型,你可以看到不同页签,下图中展示的是能力地图,除此之外还有价值流地图、信息地图、利益相关者地图等。

果你未报名附加包,不用问我索要这些文件。因为版权原因,如想获得报名时请选择包含课程的附加包。当然,你还有一种方式可以获得,那就是直接去官网购买这些参考模型。

Web在线研讨会视频

除此之外,还有很多来自官方的在线视频分享,这样你可以听到更多大拿的讲解了。

BAGuild会员

报名附加包,捷创成会赠送大家一年的BAGuild的会员,除了上面所说的内容之外,你还可以获得业务架构成熟度模型、业务架构工具评估等。另外还有持续的行业模型的更新、新组织的在线研讨会。

业务架构的12个常见误解

01 业务架构很复杂!

相信很多人都已经知道TOGAF,或者学习过TOGAF了,不少人觉得考证容易掌握很难。其实,要掌握TOGAF也不难,只要我们有一个正确的期望,你要知道自己当前处于哪个段位,然后逐步提升。有了这个认识之后,你会发现业务架构其实就不复杂了,当然,你也不能指望自己一学就会。就算企业经过培训,大部分还是要在外部教练的帮助下才能正确的开展工作。但您真的使用业务架构之后就会发现,您在实践中的概念其实还是我们在上一篇《这么理解业务架构就对了!》中所介绍的那些元素。

业务架构其实是一门比较简洁的学科,只需要对基础原理有基本的了解即可开始实践。在工作中,业务架构团队和业务部门更有可能因为缺乏业务主题专业知识而无法进站,而并不会因为业务架构学科的困难而受阻。随着我们后面的学习,如果您将业务架构应用于复杂的业务场景时,这个更加明显。

02 业务架构很贵!

我们习惯了从IT出发进行能力提升,因为觉得搞定业务很难。另一方面,对于组织级项目,觉得只要从业务出发就基本是大工程了。公司高层可能会觉得:没有业务架构师,招人或培养人需要钱;没有方法论,引进方法可能需要做培训请咨询,这又是一笔不小的钱;另外对新方法是否靠谱心里没数,即使有成功案例,但自己走一趟可能就全是弯路,这个代价也不小……

其实,我们算一笔账。没有业务架构,我们白花了多少钱???从投资回报率的角度来说,与其他主要学科(例如没有真正的投资组合规划下的项目管理)相比,业务架构的成本其实很低。我们大家其实都知道,有多少项目是真正成功的?

另外,如果您真的投入并定义了良好健壮的业务架构,它可以为企业服务多年,只需要不断完善即可。如果您一定要说证明了有用采取实施,我觉得这个在较短的时间内几乎不可能实现,这正如我给企业做流程管理微咨询过程中讲到的:活动级别优化价值显而易见,但业务场景和业务模式优化的价值度量可能真的只能来自于高层的自我认知。当高层决定不改就解决不了问题,或者可能带来更大问题的时候,采用这个方法其实就不需要验证就可以决定了。

03 没有通用定义的业务架构方法!

业务架构其实是企业架构的一个重要架构领域,所以说业务架构也已经存在不少时间了。我在为什么需要企业架构师?中提到,我是在2009年开始践行企业架构的,那时EA谈到比较多的是“业务与IT的融合”,所以有些愿意琢磨的企业架构师就会去想业务架构应该是怎么样的。

下图是我在BangBA(business analysis)实践公开课中给大家分享的我之前工作中的一些方法论,可以看到业务架构其实有了好几个版本。

虽然是我们自己的企业最佳实践,但我们建立这些方法也是站在巨人肩膀之上的,例如TOGAF、CBM、PCF等。而8月初我给一个企业做的一个产品架构内训,可以看做是之前版本的一个升级,其中很多新思路就是引用的BIZBOK。

但我们知道,每个企业的实践方法一般不会对外发布的,所以学习起来成本较高。但现在我们已经知道了,BIZBOK是一种通用的业务架构方法,它定义明确,并在全球众多企业和行业中使用,只是目前在国内的应用还很少,掌握这个学科的咨询师也很少。IT帮也希望在未来5年能够培养一批业务架构师。

04 可以在有限的业务投入和承诺下建立业务架构!

我们在 这么理解业务架构就对了! 中提到了业务架构来自业务,这就意味着只靠IT,或者业务只是参与的话,业务架构的结果就已成定论。

相信“中台”这个词听得不少了吧。我之前从不同角度写了两篇文章:《从企业架构角度说一下:中台》和《从技术角度杂说一下:中台》,后来就不怎么写了,因为写来写去您还是需要回过头来掌握早已存在的理论和实践。有多少冠名“中台”的部门,其实就是几个IT人员窝在自己的隔间里把框架搭建出来的,业务人员基本就是过客,这也为中台项目大部分很难满足预期期望埋下了隐患。

如果说企业架构,我在认证公开课开始都会给大家补充一张企业架构实践成熟度的图。较低级别的话,可能还真的是关注IT,这个时候您还可以争辩一下业务的投入和承诺重要性。但我们如果明确要做的就是业务架构,你需要从业务、产品甚至战略方面来谈架构,但如果缺乏与业务专家的频繁互动,出来的一定是不能反映业务的无效业务架构。这背后的很大一个演员,就是缺乏业务承诺和支持,所以我们谈到要做业务架构,就一定要有业务的投入和承诺,甚至可能是由COO来主导业务架构项目。

05 可以许可或购买业务架构!

我们可能会简单理解业务架构工作就是使用前面提到的能力、价值流等元素去描述业务模型,而现在又会有一些行业参考模型可以作为快速启动的“捷径”。但我们需要知道,对于给定的业务而言,业务架构是唯一的。参考的基本上都是共性的,而业务架构的目的是为了帮助企业战略落地,这必然是需要满足必要的差异化水平。

另外,每个企业都有自己的术语和结构,这都要求企业定制自己的业务架构来与竞争对手区分开来,只有这样才能提高客户价值交付并且持续创新脱颖而出。所以对于企业来说,您需要了解业务架构基本逻辑,掌握这个方法,知道如何一步一步的构建您的业务架构并加以利用。

06 企业不需要业务架构,因为已经了解了所有需要了解的业务!

有些业务部门会觉得不需要做架构,因为自己天天做着这些业务,不需要描述也能够一清二楚。假设这即使是真的,有没有想过当应用于跨业务部门、跨项目群或项目时,业务是否还能够清楚?应用的边界是否清晰?数据所代表的信息是否理解一致?…… 业务词汇、思维模式和利益相关者参与的视角在各个业务部门之间差异很大,并且通常是分散的。每个人都从一个角度或一个角度看待业务,这使得除了小问题之外的大的问题分析和解决都变得困难起来。这个时候我们会觉得一切好像都不透明起来。

而业务架构通过商业生态系统的整体设计,揭示了通常在给定业务部门或主管的视线中隐藏的问题,提升了业务的透明性,这给企业带来了极大的价值。

07 业务架构是一门IT学科!

业务架构代表业务,而不是数据、解决方案、应用程序或技术架构。因此,企业必须参与、理解和利用业务架构,才能利用该学科。任何将业务架构与IT架构混淆的人都需要了解其在战略对齐、计划管理和其他业务计划中的用法。

08 业务架构特定于项目群、项目或业务部门!

上图是TOGAF实践公开课的一张讲义。我首先要说的是,业务架构的确可以应用在特定项目群、项目或业务部门中。但我们需要明白,定义越狭窄,业务架构交付的价值就越低。这也就是IT帮常说的,以终为始,我们更要关注组织级的业务架构,而非项目级,这才是业务架构的应用基准,所以业务架构不应受项目或业务部门的限制。

难度是肯定比较大的,但一旦建立了业务架构基础,就可以反复利用结果,并随着该学科进入越来越多的业务领域而建立可持续的价值构建,这是值得去探寻的。

09 业务架构能力图是可交付成果!

如果不与业务架构的其他方面合并,则能力地图只是业务架构的一种交付物,其价值有限。没有价值流的能力就其价值和对业务的影响而言缺乏上下文。将整个业务架构集成到更广泛的业务实践和管理学科中,才能实现真正的价值。

10 业务架构是进行业务分析的理想名词!

业务分析通常在逐个项目的基础上定义解决特定业务问题的要求和解决方案。业务架构提供了跨项目组合的透明度,使业务分析人员可以更有效地执行并提供更好的解决方案。这两个学科是独特且截然不同的,并且业务分析师应该可以访问并利用业务架构。业务架构提供的透明性为一直努力调和不同,相互矛盾的业务观点的项目分析师带来了一套全新的、有价值的是视角。

可以看看我之前写的《业务架构师和业务分析师有什么不同?

业务架构师业务分析师

Why找出业务单元的战略需要差距,设计实现这些需要的业务架构,并发起举措来实现这些差距开发和文档举措要解决的详细业务问题知识

How分析未来战略、捕获能力、建模内外部关系,开发跨职能路标来解决差距。不捕获系统需求。访谈现有利益相关者和专家来了解流程、信息和使用的系统,之后来解决特定问题。这个活动主要结果是系统需求文档。

When周期性业务战略、周期持续触发当问题被识别后及需要解决方案需求后触发

Who熟练掌握业务职能、商业等问题的业务或IT通才,必须具有很强的能力分析和建模技能了解信息和应用、需求分析、系统开发方法的通才,必须具有很强的IT需求捕获能力和建模能力。

What商业动机模型、价值流、业务场景、能力模型、热图、风险图等业务需求、业务规则、用例和详细的业务流程描述

11 业务流程是业务架构的一部分!

业务流程和业务架构是两个独立但相关的学科。它们的形式、功能和意图不同。业务架构使企业能够实现其业务模型,而流程使企业能够实现其运营模型。

但是,可以将这两个学科联系起来,以提供有关业务影响分析,将战略转换为可实施的计划以及业务改进的更全面的观点。

12 业务架构阻碍了组织的敏捷性!

之前也写过《数字化转型两大抓手:产品敏捷+企业架构》,可见而业务架构是企业架构的一个重要组成部分,可见业务架构并不是阻碍组织敏捷性,反而是增强敏捷性。单靠敏捷开发实践并不能使组织实现端到端的企业敏捷性。实际上,这些做法可能会加速错误解决方案的创建。业务架构提供了业务的通用思维模型,确保业务在做正确的事情,构架并加速解决方案的开发,并根据业务目标衡量结果。它还可以进行动态重新计划,以应对不断变化的外部条件。

业务架构并不妨碍组织的敏捷性,实际上是成功实现组织规模化敏捷性的必要,这也是为什么在例如SAFe等方法中可以看到最高层中有EA角色的存在。

到底应该是IT人员,还是业务人员来学习业务架构?

经常有学习企业架构的同学问我,没有IT经验是否也能学TOGAF,会不会听不懂。下图是前几天的一个聊天截图

以前大家普遍认为企业架构就是IT架构,所以有上面的疑问也很正常,但是我们提到业务架构的时候,仍旧会让很多人疑惑,这到底是业务人员学习还是IT人员应该学习的?接下来我说说我的想法。

01. 布道业务架构  

2009年开始我布道企业架构,当时很少人知道EA或TOGAF,这三年来越来越多IT从业人员开始关注和学习企业架构。但企业架构所发挥出来的作用与我期待的还是有比较大的差距,主要原因是大部分企业仍旧是IT人自己在“玩”。我希望未来十年,不再只是更多IT人员参与企业架构架构中来,而是有更多业务人员、战略规划人员参与进来,共同真正的把企业架构规划好、落实好。所以,我将继续下一个十年,去布道业务架构,希望能够影响更多业务方去形成架构思维,认识业务架构,与IT从业者共同推进企业EA的建设。

然而,业务架构的布道可能更难,因为在业务人员的世界了没有“架构”这个词汇。他们会认为”架构“这个词就应该是IT人员的事情,自己只需要提出一句话需求就可以了。也许我们建设一个一个烟囱式的系统,这样还勉强可以。但从企业全局视角来看,这样的建设无异于给自己扔下很多绊脚石。

虽然有这种意识的业务领导并不多,但还是可以看见已经有人走上了这条变革之路,虽然开始有点难,但这条道路将会让自己越走越顺,我也希望能为此贡献自己的一份力量。

02. IT人员学习业务架构  

从我布道的目标来说,我是希望一开始就有很多业务领导、规划人员参与并主持业务架构工作的,但我也知道有这种洞察的业务领导和规划者并不多,所以我暂退一步,从我以前老本行讲起。

2009年开始学习TOGAF时,我在公司的职称是IT技术专家。但我发现,如果不是从业IT科学攻坚的事情,在商业的世界里,如果没有业务和商业视角,你的话语权可能会很小。即使你的建议是更正确的,也没有人听你的。所以我当时就下了决定,要跳出IT这个小圈子,然后像公司申请去做了产品负责人。然而,一个IT从业者的惯有思维对工作模式的影响还是很大的,虽然你可以通过学习掌握做单个产品的业务能力,但始终很难理解业务全局,更不用说战略意图。

如何与业务人员建立对话基准,如何让高层愿意为你留出一些交谈的时间?在我学习的众多方法之中,业务架构是最能帮助我从全局观视角去建立与战略、业务和IT对话的一个学科。正如下图所示,通过业务架构的思考和践行,我有了对组织级能力建设更整体且深入的认识。我跳出了IT人的局限视野,知道业务人员关心什么,你开始知道与他们对话谈什么,而不是总是说”系统“。

IT人员学习业务架构的作用不仅是建立对话,你甚至可以去教练业务人员。为什么IT人员还可以去教练业务人员?我一直把企业架构和业务架构都看作是一个管理学科,也就是说通过它们的学习,你并不是就懂了一些方法、一些模型,而是一种管理思维,这在很多业务领导人那里也往往是不具备的。而业务架构学科的形成是基于过去很多人的经验总结,里面其实就把企业管理的本质抽象的很好。而IT人员与生俱来的工作中形成抽象总结思维可以让我们更快的去掌握它。所以一个IT工作者,如果你能跳出自己原有的IT思维,其实是完全有可能胜任业务架构工作者。即使你仍旧专注于IT架构,你以后也能更容易理解业务架构,知道如何顺接业务去进行IT的架构和设计,这其实在很多IT人中也是欠缺的一项重要能力。

目前在我身边看到的是大部分IT人员仍旧在自己的IT局限视野中不愿走出或没时间走出,而业务人员又对此不感兴趣甚至都不知道还有这个学科可以帮助他。业务架构布道艰辛,所以我在此也希望有更多愿意有业务思维的IT人员能够领先走出来,去学习和应用业务架构,毕竟这个工作在组织角度来说是必须的,没有人做你就可以勇于挑战一下,对你来说也许是意味着职业生涯的一次转变呢。

03. 业务人员学习业务架构  

还是不得不说到业务人员,因为即使IT架构师学习业务架构,他们和我一样去企业中布道,仍旧最后还是需要业务人员采纳。

虽然我们一直说,中高层需要具备长远洞察,但可以这么说,业务人员都忙于运营,毕竟考核在那,眼前的问题一定会比几年后的事情跟容易被引起重视。但业务其实和IT是一样的道理。IT系统烟囱式的建设导致数据不能共享、应用不能复用,业务流程的非端到端的建设,同样会导致部门竖井,业务无法打通的结果。面向问题的解决办法终究只是大量小的、零散、有限影响的项目举措,这其实是一种巨大的隐性浪费。你发现业务所对应的IT系统支持越来越慢,质量也越来越差,这些技术负债其实有一大部分都是业务缺少设计而造成的。

业务架构的作用不只是业务运营,它其实可以帮助我们进行战略落地。战略规划人员可以想一下自己在战略制定到战略执行的整个过程中有哪些问题,你会发现其实也是欠缺方法的。而大部分现有的战略方法都是帮助我们如何以战略思维去思考,却没有架构思维去做结构化和落地设计。

业务人员和战略规划者通过学习业务架构可以更加透彻的了解企业的本质要素有哪些,这其中以能力建设为主,再引申出更多核心要素,通过要素就形成了一个完整的商业生态。如果我们的业务方能在IT架构建设之前梳理透彻,这对自身的业务战略和落地是有了巨大的贡献的。在此也希望看到更多业务人员和规划者能够开始接触业务架构学科,尝试着去学习它,这不只是对企业的长远发展有所帮助,也一定是你的认知升级的一次自我重塑过程。

04. 其他人员学习业务架构  

虽然标题上只列了IT和业务人员,但业务架构影响或被影响的人群还是有很多的。例如在业务架构思维和框架中我罗列了四个主要人群。

我希望未来几年能看到越来越多企业有明确的业务架构师,也希望有更多管理咨询师的学习布道,就像现在有越来越多的售前咨询师在我们捷创成咨询学习企业架构TOGAF一样。

05. 业务架构要学习什么?  

我作为一个布道者,除了自己践行之外,还在思考如何能够以更好地方式把好的理念和方法传播出去。在业务架构学习中,我大致分为了三块内容,面向与业务架构相关的各类从业者:

1. 架构思维:适合所有业务架构相关者

要想让业务架构发挥作用,我们必须打破它象牙塔的围墙 – 这座象牙塔是由一个不为大多数业务人员所理解和接受的学科建造的。业务架构需要由多个角色协作完成。为了实现这一点,需要将“架构思维”的思维方式带到业务角色和高管身上。

业务架构思维会其实可以看做是一个轻量级的内容框架,会让学员能够快速的了解组织级的业务视角应该看到什么,哪些是需要注意的,我们的现状是什么样的,未来的提升空间在哪里。

2. 架构框架:适合业务架构从业者

如果你们正在开展数字化转型、中台等组织级项目的建设,这个项目涉及到业务架构领域,而你正好是其中一员,那么你就需要了解一个完整的业务架构框架是什么?如何从战略到实现?有哪一些输出和管理过程?哪些是我们需要以往没有重视却又比较重要的?

业务架构框架其实是从不同的相关实践集成而来的,其中有商业动机模型、商业模式和业务执行三大模块,每一个模块都将有详细讲解和示例,通过学习可以让自己更快的建立全局视野。

3. 架构建模:适合业务架构建模者

如果只是使用Visio或Excel来对复杂系统进行描述,一定会让你受挫。除了维护之外,没有元模型的支持,也会让我们对业务架构的真正工作造成很大的挑战。你在前面两个板块的学习会建立整体的架构思维和管理框架,现在你要开始真正建模了,这个时候你需要知道能力、信息、价值流等核心概念的梳理有哪些具体原则?建模中有哪些指导?使用什么工具来表达?过程中如何维护这些模型?

架构建模需要建立在共同语言之上,你可以采纳任何一种达成一致的语言和工具,不过我们会优先推荐你在免费的Archi中进行建模工作。随着组织能力的提升之后,再去采购付费工具。

上面的业务架构体系能力建设是捷创成咨询给希望提升业务架构能力的企业提供的微咨询服务,如果你的企业有这方面的需求,可以微信联系我。

捷创成咨询 周金根

如果你是对上面三个主题感兴趣的个人,这个月你在北京,可以抓住机会参加4月17-18两天的业务架构思维和框架线下公开课。

06.  捷创成咨询的希望 

to 长期从事转型(愿景、战略、商业模式、企业架构、业务架构)相关学科的领导者:

  • 我们希望激励您与我们建立联系
  • 我们承诺将促进您的工作更加全面
  • 我们将在短时间内为你提供帮助

to 解决方案开发、创新相关学科的负责人、实施解决方案的人员(敏捷、业务分析师、开发人员,…):

  • 我们希望您在感到自己产生了点的解决方案之外,还能看到您对“更大整体”的贡献
  • 我们承诺将帮助您的职业取得发展
  • 我们将在短时间内为你提供帮助

to 业务高管:

  • 我们希望形成您长期思考的架构模式
  • 我们承诺将推动你的组织取得进步
  • 我们将在短时间内为你提供帮助

作者:周金根,一个自在快乐、勇于践行的布道者,致力于提升咨询师、培训师和企业高级专业人员在企业架构、产品管理、业务需求、创新、敏捷开发等领域的能力。

业务架构4.0出炉

当你要处理跨业务单元的整体业务规划和设计时,你应该掌握业务架构。业务架构不是速效救心丸,而是一门有核心概念、方法和实践的学科。

捷创成咨询首席架构师 – 周金根

能力提升需要遵循一定的路径,如果从具备需求能力的人来说,大体上说应该是从需求工程师到业务分析师,再到业务架构师的转变过程。

如果你开始需求工作,那么应该把掌握需求工程能力放在首位。关于什么是需求工程,我以前文章和内训大纲中也介绍过。需求工程帮助我们解决的是项目级别的需求,以下交付内容可做参考:

而要做业务线或公司级别的整体业务规划,你面临的最大障碍是认知和思维的进阶。当然我们通过方法论的指导是一种更为切实可行的提升路径,在做中学,学中体验,持续提升自己的综合能力。那业务架构有什么方法论呢?在我以前工作中,我们自己总结了不少的方法论,其中有业务架构和产品地图等。

这几天给中信银行培训业务架构,于是结合Glodon业务架构3.0以及Glodon产品地图2.0方法论,以及BangEA框架2.0的架构思维,再结合最新的一些业务架构最佳实践,形成了BangEA 业务架构4.0