在一个企业里,企业的类型决定了IT的地位

没有苦就没有乐 2020-08-12 05:27:16

企业IT治理是个古老的话题,也是个比较大的话题,聊起来难免空洞,老哈尽量从方向性的角度对随着时代变化,目前多数头部企业对于IT治理的规划方向,方法讲清楚,希望给到一些准备做这块工作的同仁们一些帮助。


在一个企业里,企业的类型决定了IT的地位。通常分四类企业:


->传统企业,IT是为了实现功能,线下转线上,一定程度的提高协同效率。IT地位较低。如传统制造企业。


->传统转型企业,IT成为企业竞争力之一,能够帮助企业运营提高产出。IT有一定的地位,需要思考IT策略。如新零售,金融等。


->互联网企业,IT是盈利手段之一,IT的好坏直接影响企业运营,需要系统化的将企业战略和IT战略结合。如京东,淘宝等。


->云企业,IT是主要盈利手段,IT就是企业的核心竞争力。如亚马逊云,阿里云等。


企业类型的不同,决定了IT的地位和策略。三,四型企业多半都经历过IT治理阶段,在IT架构,服务化转型,数据治理方面已经领先于行业标准。通常我们谈IT治理多半是针对一,二型企业。


那么IT治理该从哪里下手呢?应该按照什么步骤推进呢?


本质上,IT还是要为业务服务的,为企业的运营成功服务的。IT治理首先要想清楚我们要通过治理解决哪些运营上,管理上,业务场景上的问题呢?这是我们IT治理的目标。目标决定了后续的行为,定目标是IT治理的第一步工作。


定目标


通常老哈会按照下面的步骤来调研:自动化->信息化->数字化->智能化


1 自动化


是否有可以提高效率的工具可以导入?是否有可以替代人工的场景可以IT化


2 信息化


是否有线下操作可以通过线上固化?是否有信息断点需要补强?


3 数字化


部门间的协同数据共享是否顺畅?数据标准,数据源,数据owner是否清晰?数据在企业全生命周期是否可以无断点流动?现有数据是否可以作为资产被模型利用,并支撑运营决策。


4 智能化


是否具备充分的行为数据,过程数据的抓取能力?


是否有能力对全量数据进行清洗和梳理?


是否可以自动寻找特征值预测性建模?


是否可以主动的给到运营决策者建议,有效的影响运营决策的正确性。


目标定好,下一步就是如何实现目标,更多的是战术层面的操作了。从上面的目标我们不难看出,所有的探讨在IT层面聚焦在两个大的点上,一个是IT系统规划,一个是数据如何治理并被高效利用。下面就这两大焦点,老哈跟大家探讨下如何落地实施。


IT系统规划


标准套路


通常按照Togaf的4A从业务架构向信息架构推动。老实说,能这样做的企业在国内屈指可数,实操性不强。历史负担重,投入大是标准套路很难在国内企业落地的原因。


中台,服务化套路


这两年随着苏宁,阿里这类互联网企业的高速发展,他们的中台策略正在被传统转型企业学习。用户体验,快速响应需求变化,企业级数据打通,跨部门协同提高效率是中台,服务化套路的收益。老哈曾给一家车企做过如下的规划,这类规划大同小异,可以参考:


技术中台容易理解,易于管理,其实即便没有中台的概念,技术能力也会以服务或者组件的方式被管理和消费。数据中台我们放在后面数据治理来论,这里重点谈谈业务中台(应用中台)。


业务中台有着非常明显的行业标签。比如你在高科技电子行业做的业务中台规划和在JG行业会有明显的差异。这也是互联网企业没法直接复制赋能传统制造业的原因。这里需要甲方公司和IT服务商共同探讨解决。


如上面分析,对于一,二型企业,互联网式的服务化是没价值的,而且劳民伤财。本着保护既有投资的原则,我们可以将业务能力分为稳态(很少变化),和敏态(经常变化)两种。对于稳态的业务能力就由原OA,MES等软件系统承载,不建议重复建设。对于敏态的业务能力抽到业务中台以低耦合,服务化编排的方式对外提供服务。新老系统并存是长期存在的。这样既保证了不会重复造轮子,又保证了可以快速响应市场,响应业务的需求变化。


这里有两个经验分享:


1  服务分层


为了更好的重用,即便在业务中台也建议采用服务分层的方式设计。底层服务尽量具备通用性和可重用性。上层服务更多的跟业务场景契合,采用服务编排调用的方式被前台消费。尽量不要采用扁平式的服务设计方式。


2  自下而上和自上而下相结合


通常我们的IT治理是在飞行中换发动机。大刀阔斧的变革是高投入,高风险的。老哈建议可以自上而下的给出规划思想和规则,实际操作的时候按照项目导入的方式,自下而上的按照规划进行切分和合并。服务的切分本质是业务边界的切分,不是一个IT的话题,是个业务的话题。在充分理解业务关联性的前提下基于DDD的方法论进行服务设计。

在一个企业里,企业的类型决定了IT的地位

数据治理(数据管理)


标准套路


在Togaf的数据架构里有对数据梳理进行明确的定义。可以参考下图:


数据架构是起着上承业务架构,下接应用架构的作用。从图中可以看到,数据资产目录,数据模型关系,数据标准,数据分布,通过这些数据使我们清晰的知道数据从哪来,到哪去。然而现实是残酷的,企业的IT建设往往经历了部门独立采购,IT主要实现业务功能的时代。不会从一开始就从企业级对数据全生命周期,跨部门的流动做好定义和跟踪,反向的梳理个别公司在做,需要时间,需要投入大量的资源,对于偏离规则的数据为了保证现有系统的稳定性,即便发现了问题,也最多做出标记,很难进行根本性的修正。标准套路是从根本上解决数据作为资产来管理,并被消费的方法,非常好,但是实操性不强。


主数据治理


有人一提数据治理就提主数据治理。貌似主数据治理就是数据治理的全部。老哈也难免俗套,主数据作为跨系统的数据存在确实对数据治理的效果立竿见影。主数据的治理方法其实也跑不出上面所说的标准套路中的四个象限。为了缩小工作范围,优先对诸如客户,员工,物流,财务等数据进行梳理和修正。市面上主数据治理的产品很多,多以数据总线的方式进行集中处理,在去中心化的时代,只要标准统一,有相应的组织和流程保障,数据语言统一了,分散在各个业务系统内管理,再进行数据集成也未尝不可。

在一个企业里,企业的类型决定了IT的地位

需求驱动的数据治理


1 数仓


现代化企业,为了更理性,更有依据的决策,通常我们使用BI的方式基于事先定义好格式和含义的数仓数据进行分析,输出报表,驱动企业决策。


此类方法我们可以认为是“拉动法”的数据治理。从报表要求的,数据模型要求的特征值出发,寻找需要的数据组合。来自于各个系统的原始数据通过数据清洗进入事先定义好的数仓中等待被消费。拉动型的数据治理方法适用于常规的,管理能力成熟的企业,主动性的拉动数据进行消费。


2 数据集成


大家经常说数据孤岛。本质上就是数据架构没做好,部门间的数据语言不一致。无论是点对点的集成还是数据总线,从根本上都是要解决如何统一数据语言的问题。从业务的角度部门间(反应在it上就是系统间)需要传递哪些数据,需要按照什么格式来传递,我们常说的接口设计。往往对于易修改的,可以在设计接口的同时完成数据源,数据格式的修改。对于不易修改(系统影响大,变更大)的,建立mapping关系或者通过etl进行数据转换,最终保证数据顺畅的流动,被下游系统消费。

在一个企业里,企业的类型决定了IT的地位

全量数据分析驱动的数据治理


随着计算机运算能力的提升,大数据算法的成熟,以及我们IOT技术的长足发展,使得抓取过程数据,清洗,建模,实时(准实时)的分析成为可能。跟数仓的处理方式不同,对于全量数据,结构化非结构化的数据混合,我们很难全面精准的建立数据模型和提前指定特征值。深度学习算法通过训练数据的共性可以帮我们选取特征值,再经过甲方和IT公司共同探讨建模,可以为运营决策提供更多维度的智能推荐和数据依据。在这个过程中,非结构化数据的结构化转换,标签化是我们数据治理的重要工作。


数据中台


数据中台可以理解为数据管理的组织级能力体现。这里将从数据抓取,数据清洗,数据存储,数据建模,分析算法,报表呈现等以服务的方式被消费,方便应用或者数据分析的工程师易于使用,并不会重复建设。


数据治理本质上是对数据标准,流程,组织,管理方法的治理,并通过IT手段固化下来。短期见效可通过转换,匹配的方式(翻译)对接使用,中长期要逐步形成数据管理的有法可依,有法必依。历史脏数据清洗转换,新数据干干净净。


综上所述,企业IT治理是个长期迭代优化的工程。要依据企业类型,IT价值制定治理策略。短期收益和中长期规划相结合,表象是IT在变,本质是企业管理能力,运营能力的成熟度提升。



来源: 老哈说

注:文章内的所有配图皆为网络转载图片,侵权即删!

免责声明

我来说几句

不吐不快,我来说两句
最新评论

还没有人评论哦,抢沙发吧~

为您推荐