业务架构金三角

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主席和联合创始人William Ulrich 线上交流了一个小时,我计划今年底向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 业务架构很复杂!

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

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

02 业务架构很贵!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

业务架构师业务分析师

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

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

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

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

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

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

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

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

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

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

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

业务架构4.0出炉

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

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

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

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

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

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