06 | 玩转业架:怎么设计业务架构?
怎么设计业务架构?
1. 战略设计
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何设计业务架构,以及业务架构如何连接业务和技术,推动业务和技术的持续融合。作者认为,持续推动业技融合,就是通过业务架构让业务人员和技术人员采用相同的认知方式去认识企业和业务,形成类似共同语言的沟通基础,从而更高效地商量如何用技术手段解决业务问题。业务架构设计包含战略设计、组织设计、业务设计和组件设计四个环节。战略设计是企业对自身发展的长期考虑,组织设计是明确企业的内部组织结构与分工,业务设计则是梳理企业的业务流程和涉及的数据规范。文章强调了业务架构设计的重要性,以及在数字化转型中的应用。 在组件设计环节,业务组件被定义为业务能力的分组,包括数据和流程两部分。通过业务架构设计,企业能够更好地了解业务能力的分布情况,为数字化转型提供支持。文章还强调了业务架构如何连接业务和技术,通过建立共同语言,帮助业务人员和技术人员深入沟通,减少误解,促进业务和技术的融合。最后,文章提出了持续推动业技融合的方法,包括培养足够的业务架构师、推动企业架构项目、开展业务架构培训等方式,以及业务架构师在业务部门的工作轮换,形成良好的工作链条。 总的来说,本文强调了业务架构设计在数字化转型中的重要性,以及如何通过业务架构设计促进业务和技术的深度融合,为读者提供了一套完整的业务架构设计方法和推动业技融合的实践建议。
《说透数字化转型》,新⼈⾸单¥59
全部留言(18)
- 最新
- 精选
- 术子米德🤔☕️🤔☕️🤔 流程最大的价值,就是不要重复犯低级错误 流程最大的缺陷,就是容易把主动性锁死在牢笼里,本来可能遇到的问题,没机会遇到也就没机会锻炼,更没机会主动思考是否有更好的解决方案,缺乏锻炼、缺乏主动的代价,就是新问题来了的第一反应,找现有流程是否满足,要么构建新的流程,可是经验和能力,都还没有积累培养起来,这样就跟容易出现流程的死局 系统架构师和分析师,他们是否要在流程外面,这样才能保留解决新问题的火种呢?
作者回复: 您的思考很深入👍流程的价值不仅在于不重犯低级错误,更在于重现成功。流程的缺陷也不是容易把主动性锁死,这是人的缺陷,不是流程的,流程是人设置的,自然也是该由人去改进它,是人怕犯错而不像改进,所以,是人锁死了流程,而不是反过来。没机会遇到并不是没机会锻炼,有些事情可以多想,很多积极思考数字化转型的人,思考企业架构的人,也不是都有机会操刀一个企业的架构设计和转型实践,但是不妨碍自己把悟到的道理用来改进眼前的工作,扩大自己的视野和思考深度,逐渐从身边的点滴做起积累能力,毕竟现用现学,往往来不及。找现有流程或者构建新流程都是解决问题的合适方法,没经验不会成为死局,人都是一张白纸开始人生的,不动手才是死局,做,总有办法,是做培养了人,不能等着有人再做,这才是死局。至于最后这个问题,如果从进入流程的角度讲,他们大部分能跟岗看看就不错了,由于责任的问题,确实进不到流程里边,但是他们做设计是不能在流程外面的,因为谁也不能脱离设计对象去搞设计,他们在流程外面,往往是为了获得更大的视野,以获得更好的解决方案。您想的非常深入,非常好👍
2021-04-2425 - ing (泰来)我觉得业务架构的核心应该是业务,所以顺序上业务分析应该是第一位的,用一句通俗的话讲就是:看菜吃饭。 只有基于数字化的思维和方法,从新定义业务、分析业务,才能在未来知道如何定战略、建组织、做组件。这一切都是为了促使业务能够落地。否则,脱离实际的战略就是好高骛远、脱离实际的组织就会内卷内耗、脱离实际场景的组件就会形同虚设。
作者回复: 您好,感谢您的提问!看菜吃饭是吃今天的饭,战略更关注怎么吃明天的饭,到了明天现找饭吃是大家都不愿意看到的。所以,业务执行是为了落地企业战略,而不是反过来,为了执行业务设计战略,业务执行属于战术问题。战略不是好高骛远,而是合理前瞻,这个比好高骛远难得多。其实您描述的基于数字化思维重新定义业务,这个已经是战略范畴了,它需要确定引进什么样的技术,如何利用技术,涉及什么样的人才,用多长时间改变业务,这期间新旧业务什么关系,怎么处理客户稳定迁移等等,是吃明天的饭。另外,您提出的问题都很好,这些恰恰是做战略时要重点考虑的问题,更是我为什么推荐用业务架构方式落地企业战略的原因,因为业务架构是对战略方向的具体分解,是保证战略本身可行的,无论是用画布的简单分析,还是用业务架构的完整设计,目的都是为了让战略不空,战略问题我在后边有一节课是专门讲的🙂
2021-04-278 - 王俊把业务架构和数据架构放在一起设计是构建业务和技术沟通桥梁的好方法。而我作为业务人员对数据架构这块感觉有点陌生,有没有一些适合的数据建模或数据架构这块的书籍可以推荐阅读?
作者回复: 《数据建模经典教程(第2版)》,《华为数据之道》,这两个挺好,一个是通俗易懂的数据建模,一个是大型企业完整的数据治理和数据架构
2021-04-254 - hbwl有没有关于业务架构的案例展示呀,目前听起来还是云里雾里的
作者回复: 您好,业务架构初次听确实容易这样,但是案例展示的话,完整的业务架构至少包括企业战略,价值链,业务领域,业务应用,业务组件,活动,任务,数据主题域,数据实体,数据属性等内容,而且不是一张图可以完整展示的。如果不看到完整的业务架构设计成果,不大容易领略全貌,感兴趣的话,可以到我的公众号,晓谈岩说,去看中台之上系列,共16篇,专门讲业务架构的。
2021-04-253 - Jxin如果是站软件架构视角,我们梳理的往往不只是具体的某个流程。而是相近的多个流程交织再抽象的宏流程,是流程的模版。从依赖人,到依赖流程,最后到依赖工具。将流程工具化本身有利于加强企业或组织真正的核心能力。对宏流程的思考有利于在多个行业复现成功。但事有两面,有利必有弊,流程化可能导致组织模式和思考方式的僵化,在每个流程节点追求kpi,调整现有业务模式以适应现有流程(抛弃了可能出现的新创新)。所以梳理流程沉淀工具的同时,还要在内部构建热于思考,不迷信权威,敢于直言不讳的文化结构,以保证流程能在跌跌撞撞🀄️持续演进,不致于逐步僵化。 甚至更激进点,我觉得可以先差异化发展,等需要时在合并流程工具,用冗余保留创新的可能。
作者回复: 整体理念非常好👍
2021-09-151 - 必得非常赞成聊天是重要的沟通手段这一点,可惜很多技术人员不看重这一点。
作者回复: 嗯,这是非常遗憾的,聊天能解决很多问题,也能发现很多问题,还能学到很多东西,现在人们有点儿太忙了
2021-07-191 - X_F核心的要找对人 数字化转型要业务出身的人牵头才会成功 IT牵头那是信息化
作者回复: 您说的非常好,其实就算是信息化,在大多数传统企业中,如果过于强调让it牵头也是做不好的,因为即便是信息化,到了深度时,也需要处理组织结构等非技术类问题,数字化就更是这样。其实多是要企业领导牵头,业务和技术之间则是要深入合作,互相推动,如人的双腿,协同前进🙂
2021-07-041 - Geek_95d25e我对文章中提到的战略设计、组织设计、业务设计、组件设计观点是认同的。我眼前就参与了一家企业中台系统改造,上层关注的是战略,中层关注的是业务,下层关注的是组件,每个关注点都做了设计,不过层层之间反馈很少,信息损失严重。系统改造一定是有价值提升的,毕竟做事的人还是奔着减少人工成本,比如操作失误成本,重复劳动成本,同质化成本。但少了一项设计(细心的朋友能够看出是少哪个),让新思想,新系统去适配旧结构,最终价值就显而易见了。
作者回复: 您的分享非常好,您的经验也非常宝贵,这两年做中台的企业不少,但是大家在回答中台里边放什么这个问题上都很困难,这其实是个繁琐的业务梳理过程,不然,中台里边放什么确实很不好回答。数据架构在我自己的新企业架构方法论中是被整合了,没有单独的数据架构。
2021-06-061 - jumpfox深有同感,进行信息化建设、数字化转型过程中,往往最缺架构设计这块,容易业务有痛点就直奔功能需求、原型设计、开发计划而去,结果可能只解决了部分操作问题,而没有解决好why问题。
作者回复: 是的,您说的太对了,我第一本书的读者经常跟我反馈这个感受,所以现在大家又开始重新考虑企业架构的价值。
2021-04-301 - 何鹏业务架构和DDD怎么能有效衔接
作者回复: 我个人是不建议直接衔接,毕竟二者可以达到相类似的效果。如果一定要衔接,那么业务架构负责处理宏观问题,包括战略拆解、业务领域定义、业务组件定义、业务活动定义等,到了更细一级的限界上下文,具体的实体和行为定义,走ddd
2023-04-04归属地:广东