2020 年是前所未有的一年，当数据高管们反思公司所经历的技术加速发展时，他们可能会发现，在琳琅满目的技术宝库中，确定 2021 年及以后的技术优先级很有挑战。

2021 年有很多值得期待的事情。

根据 SiliconAngle 和企业技术研究 (ETR) 的数据，预计 2021 年 CIO 预算将至少增加 4%。

根据最新的大数据和人工智能高管调查，近 92% 的企业表示，在数据和 AI 方面的投资步伐将继续加快。

不过，仍有很多问题需要解决：超过 3/4 的高管承认，他们没有成功建立一个数据驱动的组织，虽然 99% 的高管对大数据和人工智能的投资仍然很高，但结果并没有那么理想。

在这篇文章中，我研究了两个可能决定 CIO 未来的问题。一个是有利的，另一个比较令人担心。

组织洗牌

在数据、人工智能和分析领域，数据团队的组织效率问题一直是一个争议点。一些公司更倾向于集中式模式，由一个团队作为“卓越中心”，协助业务部门解决分析需求。这种方法的好处是基于这样一个前提，即通过集中的资源、技术和流程，组织可以获得规模经济，出自一个团队的数据更能保持其标准和规范。

另一些企业则将数据工作分散化，部门负责人能够采购分析软件和基础设施，以及雇用直接分析师和科学家向其汇报。这种方法基于这样一个前提，即在帮助组织进一步走向数据驱动时，商业敏锐性和协调性与技术知识同样重要。

当然，也有一些公司尝试了两者的混合，他们建立了提供“数据即服务”的集中式团队，也拥有针对“特定业务”需求的业务分析人员。

无论你的公司采用何种模式，似乎还没有解决在组织里向谁报告的问题：数据、AI 和分析团队应该在“技术部门”(CIO/CTO)、“财务部门”(CFO) 还是其他业务职能部门下报告?

这个问题是最近 LinkedIn 调查的主题，结果 CFO 的优势非常微弱。如果你读过评论，你会注意到仍然没有明确的共识：许多人建议数据、AI 与分析团队应该向 CEO 办公室报告。另一些人则担心，向 CFO 报告可能会使得组织运行集中到降低成本上，而不是集中在创新上。

2021 年或许能帮助 CIO 们解决这个问题。对许多人来说，2020 年“技术加速 ”将数字化转型变成了业务的必选项。对一些人和企业来说，更是生死攸关，CIO 们和其团队首当其冲，被委以重任。

因此，在 Gartner 的 2021 年 CIO 议程调查中，Gartner 建议 CIO 们“抓住这个数字业务加速的机会”就不足为奇了。最重要的是，在 2021 年，CIO 们有机会成为“代理首席运营官”，在全公司范围内进行数据驱动的业务转型。

技术融合

人们相信，最好的突破发生在最糟糕的年份之后。

2021 年其中一个突破就是 "融合" 的概念，这种现象指的是某些技术市场相互接近，以至于它们可能会重叠并成为一个整体。

“融合”并不是一个新概念，它可以追溯到上世纪 90 年代，麻省理工学院实验室创始人尼古拉斯 - 尼葛洛庞帝，在其 1995 年出版的《Being Digital》一书中对其进行了最精彩的描述，大量技术在后来被得到验证，尼葛洛庞帝也被誉为技术预测之父。

他的思想是正确的，就是数字化加速了技术的融合，技术为我们的生活带来了便利，技术的融合使得设备的功能越来越强大，如果你不相信，可以回顾一下过去的十年：我们的手机变成了手表，也变成了我们的电视……哦，还有电话。

这种趋势在企业领域也有很多：比如很多人预测人工智能和商业智能的融合，数据仓库和数据湖将来也会融合。虽然在不同的技术之间有共同的用例比较常见，但 CIO 们需要小心 “供应商说辞 (VendorSpeak)”。

“VendorSpeak”是指当技术供应商将技术趋势描绘成被广泛接受的现实，以支持他们所构建的解决方案时所说的话。VendorSpeak 通常不是恶意的，它源于技术创始人希望将他们打造的解决方案解决更多的问题。

我在供应商已经工作了很多年，亲身经历，深有体会。不妨把 "VendorSpeak" 想象成技术专家的 “确认偏差”。

事情是这样的：技术专家为他们所熟悉的问题 (甚至有实践经验的问题) 构建了一个解决方案。他们的产品得到了广泛的市场认可：客户和合作伙伴扩大了解决方案的使用范围。当他们发现其技术被应用到许多方面时，他们会感到兴奋。他们的愿景超越了他们建立原始产品的目标，这时，技术专家们要经受考验，区分其解决方案的核心用例与角落用例之间的差异。

当“角落用例”被定位为“核心用例”时，技术专家就有可能将 CIO 引向错误的业务塑造 (有时甚至是改变职业生涯) 决策之路。

最好的补救措施是所谓的 “设计中心”。 对于 2021 年接触的每一个供应商，通过将“每个产品的最佳应用”归零来对其评估，评估一个解决方案的“设计中心”的最佳方式是将其与 “用户、数据和流程”三者关联。

以数据仓库与数据湖为例。该解决方案最适合什么数据? 结构化数据还是非结构化数据? 它针对什么用户角色进行优化? 分析师还是数据科学家? 它最适合什么类型的用例? 分析还是建模?

如果供应商告诉你，他们有一个工具可以“解决所有问题”，那就要小心了。退一步问：你的需求是否适合重叠的领域，或者所提出的“一刀切”的方法是否会使你的解决方案超出其真正的设计中心?

"角落用例"VS “核心用例”

回到我们智能手机的例子，可能更容易思考核心和角落用例的区别：智能手机之所以能够吸收这么多设备的功能，是因为那些设备只覆盖了狭窄的用例：一个时钟只能报时，一个有线电话只能打电话。

技术产品和解决方案是尺有所短寸有所长，不能太过听信供应商的一家之言，结合自身业务需求博采众长不失为上策。

比较特斯拉和吉普车。它们都是伟大的汽车。它们都可以运输货物、物资和人员。但你会带哪一辆去参加越野赛呢?

这同样适用于数据仓库和数据湖。应用解决方案时，要从其核心用例出发，而不是从角落用例出发。换句话说，避免开错车参加错误的比赛。