随着企业与数字科技融合程度的逐渐加深, 越来越多的企业在数字化转型之路上感到前所未有的焦虑. 他们相信组织已经拥有了具有经济价值的数据资源, 期望它能像其他资产那样为组织带来更多的未来利益.
诸如员工资产, 与数据一样, 员工也是企业资产的重要组成部分. 只不过相较于数据资产管理在国内企业中仍然处于早期阶段. 大部分企业在员工的选育用留上已经形成了一套标准化流程和相对成熟的管理策略. 基于此, 我们是不是应该考虑像管理员工资产那样, 以相同的方式处理数据呢? 这时, 数据策略显得尤为重要.
一, 数据策略的定义
数据策略是用于获取, 集成, 存储, 保护, 管理, 监控, 分析, 使用和操作数据的方法. 现代而全面的数据策略所涉及的不仅仅是数据, 它是定义人员, 流程和技术的路线图, 阐明了数据将如何实现和激发业务策略.
具体包括: 阐明目标愿景和实现该愿景的实用指南, 明确阐述成功标准和关键绩效指标, 这些指标可用于评估和合理化所有后续数据计划. 而不包含针对特定技术问题的详细解决方案. 随着企业目标的发展, 数据战略并非一成不变, 需要紧跟企业的技术创新和运作方式.
二, 为什么企业要建立数据策略
鉴于前面阐述的背景, 数据策略与员工的选育用留策略一样, 都是为了更科学地管理企业资产. 如果没有策略, 组织将被动应对各业务部门提出的数据要求. 从前台业务, 市场, 到中后台的财务, 供应链, 人力资源, 都会向一个部门提需求, 可能涉及到某种数据分析, 主数据管理, 商业智能, 数据治理, 数据质量计划等.
导致数据部门每天对外要理解业务数据需求的内涵, 竭力排期满足, 对内要运维所使用的陈旧工具和系统, 保证其正常运行, 每天不堪重负. 一旦出现数据质量, 元数据等问题, 就会被挑战得体无完肤, 甚至会升级到能力和信任的高度. 更为关键的是, 如果无法及时正确地支持这些计划, 很容易导致企业做出错误的商业决策.
三, 谁来制定, 推动数据策略
请不要将企业范围的数据策略仅仅交给首席信息官(CIO), 为什么? 数据不仅仅是 IT 资产, 而是一种企业资产, 数据策略在一定程度上是一种企业战略.
DataPipeline 认为, CEO 和董事会需要深刻理解快速将数据战略落地的意义和风险, 并着手构建下述组织架构, 鼓励相应的文化和创新.
CEO 相较于其他企业角色, 既要关注生存, 也要关注发展, 而数据很难做到立竿见影, 所以平衡短期收益与长期发展考验的是 CEO 的智慧. 如果 CEO 在公布决策时都是引用数据, 并对企业内部的数据创新非常熟悉, 那么数据策略已经成功了一半, 否则其他人的努力有极大概率会付诸东流.
CDO 由 CEO 领导, 直接负责公司组织内部数据发展策略落地的详细路径和整体节奏, 根据业务模式确定合规要求, 需求满足的价值, 速度, 流程, 以及自动化, 智能化技术路线的选择. 这里一定要注意满足业务需求的速度和质量, 由于数据需求的挑战较大, 太多 CDO 无法在一定时间, 一定业务范围内快速达成 CEO, 董事会, 业务部门希望看到的效果. 没有一个好的起点, 首席数据官的工作就会丧失前进的节奏, 陷于和业务部门就数据的上收, 使用等流程长期讨论和拉锯的泥潭中, 造成恶性循环, 使这个岗位变成高危职位. 据 DataPipeline 观察, 很多企业开始设立 CDO 的岗位, 并尝试通过数据带来业务增长, 客观来说, 这和其他高管职位一样, 是一个机遇与挑战并存的情况.
数据合规与标准委员会由 CEO 领导, 并由公司的业务线领导, 法务领导, 首席数据官组成, 详细制定出数据使用的边界, 自由度和数据质量标准. 负责随着业务的发展保持最高频率 (一般是一周一次) 的讨论更新, 同时使用自动化的工具将规则同步至数据系统中. 如果业务的变化无法从合规层面保持一致, 就会逐步成为限制数据使用的瓶颈. 这里的挑战在于不让规则讨论过于大而全, 要尽快在一定范围内达成共识, 逐步推动部分范围内规则地快速落地, 否则会使愿景的落地失去前进节奏.
数据部门由首席数据官领导, 包括数据工程师, 分析师和数据科学家. 数据工程师负责使用符合时代挑战的自研或者商业的工具, 确保业务用户可以自助式地完成数据全生命周期的使用和管理. 同时负责企业内外的数据源能自动高效地集成融合, 快速满足业务取数, 用数需求, 另外通过保证元数据, 主数据, 数据血缘与业务发展时刻保持一致, 让业务准确无误地理解数据语义.
他们不仅要确保大数据平台的负载均衡, 稳定性, 可以随时响应业务对数据模型的计算和查询需求. 还要遵循标准委员制定的标准, 通过手工制定规则和各种算法确保数据质量并尽可能做到前置预警. 最后, 也是非常重要的一点, 在应对业务部门的需求时, 需要有一套 "定价体系". 因为数据支持业务的发展探索是存在成本的, 但目前业务部门对此并无感知, 更核算不出 ROI. 在成本面前, 很容易筛选出真需求, 排出优先级, 并且在后续服务中理清 ROI. 这条路举步维艰, 但又势在必行, 否则数据部门的业务价值困境始终会存在. 有时数据部门在没有设立首席数据官的情况下也由 CIO 领导, 这时有一个职责划分艺术, 每个企业的情况都不同, 但 CDO 的重点职责是在合适的企业内带领数据组用数据快速产生业务价值. CIO 的职责范围更广, 但专精的领域不在该点上.
业务部门中应当拥有能深入理解业务的分析师和科学家, 自助使用数据部门提供的工具, 这时使用门槛会不断降低, 取数用数的难度和周期也会大幅下降, 技能的要求一般是 SQL 级别. 因此业务部门需要更加理解数据, 并构思数据可以应用到自身业务发展的角度, 再通过管理数据使用的全生命周期, 在实践中不断总结. 挑战在于如何能快速用数据高效地带来业务价值, 通过解耦来摆脱发展受到数据部门效率制约的现状.
四, 数据策略中的数据融合策略
1. 为什么要制定数据融合策略
企业希望在未来以数据支持数据应用和数据业务, 但前提是能够随时随心快速提取使用数据. 在此过程中存在一些壁垒, 诸如技术, 组织, 文化等. 如果没有提前思考这些难点, 在后续朝目标努力时, 会遇到很大的阻力, 甚至有可能让项目流产.
2. 制定数据融合策略时需要思考回答哪些问题
在搞清楚为什么制定数据融合策略之后, 接下来我们将从以下几方面展开:
Who: 组织中, 谁将参与数据融合? 是否有具备编程知识的 IT 专家解决所有数据融合任务? 还是需要使业务部门的员工能够自己使用数据融合工具? 一旦实施, 潜在的技术风险和实施周期是什么? 这些问题将对您选择购买的数据融合解决方案的类型产生重大影响.
What: 哪些数据可能需要集成? 在 DataPipeline 看来, 我们反对大而全, 支持企业按需制定非常灵活的数据融合策略. 企业需要反向从业务角度去思考, 从全局角度梳理清楚在未来一到三年或更长期的时间内, 有哪些业务目标希望通过数据去驱动, 这些数据包括哪些数据, 这些数据都存在于哪里, 避免重复建设.
如果只存在几个数据孤岛, 对企业来说, 最具成本效益的策略可能是选择可以满足特定需求的基本数据交换或 ETL 工具. 但是, 如果需要集成许多不同的孤岛(或者不同类型的数据), 那么最好使用功能更为全面的数据融合平台.
When: 何时进行数据融合? 企业一旦制定了数据策略, 接下来数据融合策略将会被摆在一个非常高的位置上. 因为, 如果不做数据融合, 其余事情将会举步维艰, 但从时间上要做通盘考虑, 进行一个顶层设计, 然后再按阶段逐步进行.
如果要创建数据仓库, 则数据融合可能会在分析之前进行. 如果要创建基于 Hadoop 或类似技术的数据湖, 以原始未更改的形式存储数据, 则将在运行分析工作负载之前进行一些数据融合. 目前许多企业都有数据仓库和数据湖, 选择何种体系结构将影响数据融合所需的技术类型.
Where: 数据融合将在哪里进行? 云和本地并不是一个矛盾, 因为现在有许多公司既有本地的 IDC(数据中心), 又有云上, 甚至是多云的架构. 企业需要选择一种能够支持本地部署, 云上部署, Docker, 在容器大的平台上多管齐下的数据融合工具. 另外, 该工具的现代化和智能化程度还应该适应企业当中非常复杂多变的环境.
How: 如何进行数据融合? 这个问题最为复杂, 因为它涉及到工具, 文化和流程. 关于员工, 作为企业和组织的战略性资源, 我们并非要将每个人都训练成高水平, 有经验, 训练有素的数据工程师. 而应注重培养其数据意识, 知道如何使用数据, 如何去发挥数据的价值.
同时企业应该采取灵活易用, 稳定的数据融合工具. 面对再厉害的人才, 如果没有匹配相应的工具和方法论, 在工作中也很难游刃有余. 未来企业需要多思考何种工具, 何种平台, 何种工作方式能让组织尽快释放数据效能.
3. 选择数据融合平台需要做哪些考量
公司需要结合自身的发展阶段, 信息化建设水平以及人员的素养等情况, 来选择自己的解决方案.
如果研发人员较多, 可选择的范围相对会比较广泛. 面对开源和商业的数据融合工具, 您需要根据企业的需求和对生产的要求进行选择. 开源是很好的方式, 可以先从这里尝试做起, 但是对于业务的连续性要求和有些生产级别的要求, 可能就需要商业工具.
另外, 关于一些技术考量点, 可以看这篇文章: 构建实时数据集成平台时, 在技术选型上的考量点
来源: https://www.cnblogs.com/DataPipeline2018/p/11910485.html