本文来自微信公众号“与数据同行”，作者：傅一平

数据管理工作充满曲折和挑战，今天就来聊聊我当前面临的八大困境，分别是：大模型瓶颈、责权利不对等、组织架构缺陷、达摩克利斯之剑、扁平化悖论、数据不owner、完美的“坑”、冲动是魔鬼。同时也给出了我的一些思考，与大家共勉。

1、大模型瓶颈

从去年以来，我们团队陆续开发了智典、智能核稿、智乎、ChatOA、ChatBI、代码解释器等大模型应用，其中智典和智能核稿算是初战告捷。但ChatOA和ChatBI这类大模型的准确率始终达不到实际使用的标准，只能静待更强大的开源基础大模型的推出。

最近，Llama 3的开源让业界欢呼雀跃，我们团队也感到非常激动，急于进行测试。但这也让人感到些许悲哀，毕竟我们不能总是依赖外部因素。我们决定转向聚焦用户需求，寻找更实际的解决方案。

实际上，在ChatOA中我们自创的智能办公场景，如帮助业务人员撰写摘要、发送邮件等，并不常见。考虑到大多数企业员工可能一年都不需要写一次摘要，这就引发了一个问题：为什么我们要开发这类大模型产品?对于ChatBI情况也类似。

OpenAI和大厂的使用场景，并不代表所有企业的实际需求。这些需求的差异往往是由于受众和规模的不同。许多产品开发的冲动仅仅是跟风。

我们团队在内部讨论后，决定回到基础，从真实的用户需求出发，探索大模型的应用场景。例如，我们找到了一个高频的通讯录使用场景，这大大降低了大模型应用的构建难度，同时也便于结合现有的结构化知识图谱。

我们改变了大模型应用的策略，不再贸然尝试去开发像ChatOA这样试图改变商业模式的庞大产品。我们更倾向于在现有流程中嵌入大模型服务，为业务人员带来小惊喜。AI+是我们的愿景，但首先我们需要做好‘+AI’。

我们也在积极推广‘小而美’的大模型功能，毕竟这些由IT部门开发的初期产品并没有太多的资金支持，需要借助企业内部的结算机制维持运转，否则这些产品可能会很快被遗忘。

2、责权利不对等

数据团队会抱怨自己的工作成绩别人看不见，嗯，也许有吧，但有没有想过，我们自认为的价值很大的事情，也许别人看不上。

那为什么别人不认可呢?

因为我们很少承担风险，做好了是我们的功劳，比如精确营销就是数据团队经常提到的成绩，但做差了呢?当公司用户增长乏力的时候呢，数据团队到哪里去了?这个时候，数据团队和业务团队可能并没有skin in the game，也就是塔勒布说的缺乏‘共担风险’，这就是责权利不对等。

今年我们一直在做跨部门的数据一致性工作，领导给了很多的支持，业务部门也表示认可，我们也非常开心。但当审计到来时，我们一下子就被推到了风口浪尖，很多解释工作需要我们代表企业去做，这个时候我才意识到，哦，原来天下没有白吃的午餐。

对于跨部门的事情，大家一般都是躲之不及的，因为存在很大的不确定性，这就是风险。为什么我们当初做大数据变现容易获得认可呢?因为我们对公司有所承诺，一旦收入没完成，就要承担这个风险。

有时候数据团队会与业务部门在贡献上的认知不一，各执一词。我想大致的原因是业务部门在熬夜制定方案的时候，数据团队可能只是在那里等着业务提需求，然后按部就班地执行。

但如果数据团队能主动提供建议，与业务同频战斗，那至少人家不会对我们的贡献产生质疑，说不定还会送个大红花呢。

3、组织架构缺陷

数据团队在增加了数据治理职能后，我自认为自己设计的数据团队架构已经非常科学了，比如数据治理组负责建章立制，数据中台组负责能力建设和运维，数据服务组负责满足前端需求。但在实际的运作过程中，当有一个重要的任务需要三个小组协同来做的时候，我就会纠结这个任务应该安排哪个组牵头?

就拿数据开放来讲吧，这个事情既涉及到建章立制，也涉及到数据开放平台建设，还涉及到数据开放运营，我有时就只能因人定事，谁能力强一点，谁最近空一点，就安排谁牵头去做，虽然这种乱点鸳鸯谱的方式好像也不妨碍事情的推进，但我隐隐觉得这种管理是很混乱的，组织架构的设置和小组的职能划分可能存在一些问题。

最近在推进数据安全相关工作时，我这种感觉越加强烈，然后我去仔细研究了公司的组织机构，才恍然大悟，原来我把规划建设的职能给漏了，也就是团队缺少大脑组织，我原来以为数据治理组是团队的大脑，但实际上这个大脑不够，因为漏了数据管理规划建设这类关键职责。

我马上进行了组织职能和人员的调整，在数据治理组增加了以下规划职责，它们是拉通各个组工作的关键所在，大家可以看下：

1、对企业数据汇聚、建模体系进行统一规划，负责相关制度建立，制定发展目标和指标，指导和监督相关工作落地。

2、对数据共享开放体系进行统一规划，负责相关制度建立，制定发展目标和指标，指导和监督数据共享开放工作落地。

3、对数据管理体系(含数据资源管理、数据开发管理、数据运维管理、数据质量管理、元数据管理、主数据管理)进行统一规划，负责相关制度建立，制定发展目标和指标，指导和监督数据管理工作落地。

4、对数据应用体系进行统一规划，负责相关制度制定，制定发展目标和指标，指导和监督数据应用工作落地。

5、对数据安全管理进行统一规划，制定发展目标和指标，指导和监督数据安全工作落地。

通过这些调整，数据治理组不仅建章立制，还负责数据管理工作的总体规划。数据中台组和数据服务组则按此规划执行，这样就能清晰地界定各组职责，避免职能交叉和模糊，我也不再纠结于谁应当牵头某个任务。

这种"规划-执行"的运作模式其实与公司整体的运营管理十分类似。或许有经验丰富的管理者会觉得这些道理理所当然，但对我这样的技术管理者来说，确实是一次难得的领悟。

4、达摩克利斯之剑

以前我一直是以数据驱动业务为使命，因此会拼命的向业务兜售自己的数据能力和产品，比如我们打造了数据资源、数据资产和数据服务三本数据字典、对数据进行了分类分级、优化了数据开放流程、打通了各部门的数据壁垒，实现了数据的一键入湖，通过运营，我们把端到端数据开放时长大幅缩短了，我们的数据变现也到了一定规模。

但在数据共享开放的同时，也会带来数据安全的隐患，把数据要素流通的效率提升到一定水平固然不易，但在高效开放的同时确保数据安全可控更加考验管理者的智慧。很多企业数据共享开放水平不高，主要还是因为担心数据安全不可控。

近年来，随着国家对数据相关法律的陆续出台，各行各业也相继建立了数据合规性制度。作为一个数据的运营者，我也不得不开始关注这些变化，不禁会问：为什么会有这么多人要使用数据?这个场景下要不要共享这个数据?是不是不合理?

你看，当年屠龙的少年，也开始变得保守了。

不作为，当然可以不出错，但这就背离了做数据的初心，作为了，就要承担风险，而且可能代价很大。要想两者兼顾，唯一的方式就是改变数据服务的供给模式，而这条变革之路，需要自己趟出来。

首先，做数据安全，时机是第一位的，否则很难有资源和组织的支持，正好公司最近有些组织上的优化。

其次,数据安全意识也是非常重要,我们要能在脑中同时容纳"高效开放"和"安全可控"两种看似对立的观点,找到平衡点,协同推进,这样数据安全问题就解决了一半。

第三、数据安全的理论和制度也需要系统学习，比如虽然企业有数据安全的管理办法，但这些办法往往都是原则性的，需要根据这些原则制定出具体的操作细则，确保这些制度能够落到实处。例如，如何解决涉敏数据的人员集中管理问题，如何分工明确“谁主管谁负责、谁运营谁负责、谁使用谁负责、谁接入谁负责”的职责，以及如何设计一个“权限明确、职责分离、最小特权”的账号权限体系。

第四、“工欲善其事，必先利其器”，数据安全的相关方法和技术这些课也需要补，比如数据的分类分级方法、数据的安全传输、数据加密存储、数据的脱敏访问、4A的管控和金库模式等等。

最后，需要根据企业的实际情况给出一个可行的落地方案，将这些能力整合到相关流程和系统中。最大的挑战其实是如何处理既有的包袱，包括如何改进现有流程和系统，以及如何确保用户的数据使用体验不受影响。

前几年我们通过企业级数据治理，终于把数据共享开放的体系建立起来了，现在需要再演进。

5、扁平化悖论

数据工作很多具有创新性，特别是我做大数据变现的前几年，那个时候非常讲究扁平化，随便一个员工就可以直接找我直接讨论问题，我也有灵活的时间去应对这些事情。那个时候虽然也有主管和组长的层级之分，但基本上只是个头衔，除了处理一些统筹的事务外，并没有实质性的层层汇报的关系。

我一直以此种架构为荣，认为我们终于跟上了互联网的节奏，在大数据变现相当长的时间内，这种扁平化的汇报关系也是相当有效的。

然而，当我因工作变动，重新回到数据治理、数据仓库、报表和取数等内部工作后，我开始感觉到扁平化的组织架构并不完全适应这种环境。

公司总体上还是靠机制和流程驱动的，比如我会增加很多外部的会议，这样我的时间变得不自由，员工要找我其实也并不容易，有限的时间逼迫我减少探索性的交流，追求更高质量的沟通，我能“浪”的时间其实变少了，我更希望组长和主管想清楚了跟我进行言简意赅的交流，而不是大家促膝长谈，追求灵感爆发。

我们以前做大数据对外产品，自己既是业务部门，也是支撑部门，只要找对了客户和市场，就能直接开干，干了就能自己卖，公司给予了极大的自主权。但一旦对内，我回到了支撑者的角色，客户是内部的各个业务部门，渠道也是各个业务部门管理的，而业务部门有自己的机制和流程，节奏基本就掌握在了业务部门手里。在沟通上，也需要遵循中层对中层，主管对主管的对等原则，大家需要对等谈话才能推进工作。

应该说，没有哪种组织架构更好，只能说都是适应了生产力发展的结果，大数据变现追求更快固然是很好，但做大了必然要有甄选决策的流程，规模越大，风险越大，流程就越复杂。

现在，我还是倾向于回归传统，恢复组长、主管的管理职能，他们需要承上启下，不仅要干好自己的专业工作，也需要为组员的工作负责，这不以个人的意志为转移。当然在个别创新性较强或需要快速响应的事情上，我还是可以采用扁平化的方式。

6、数据不owner

作为一个IT部门的数据工作人员，如果有审计部门来问你，你为什么要开放这个数据，有没有遵循最小必要原则，你怎么回答?

我以前是没想清楚的，想着似乎这是自己的责任，比如我开放一个自己加工完的融合模型出去，当然我要为这个融合模型的开放合理性负责，但我又觉得这对我似乎不公平，但说不出个所以然，感觉没有法理依据。

最近几天我才把这个逻辑想清楚了，说到底，还是顶层设计的问题，IT部门有时有点冤，做的越多，背负的越多，这是责权利不对等。

我们首先可以去看下国家的“数据二十条”的设计，除了第一条的指导思想和第二条工作原则，最实质性的内容，就是从第三到第七条的数据产权制度开始的，即首先要进行数据确权：

“探索建立数据产权制度，推动数据产权结构性分置和有序流通，结合数据要素特性强化高质量数据要素供给;在国家数据分类分级保护制度下，推进数据分类分级确权授权使用和市场化流通交易，健全数据要素权益保护制度，逐步形成具有中国特色的数据产权制度体系。”

回到企业内部，华为公司给出了一个数据确权落地的解决办法，即数据owner制度，我觉得这是企业内解决数据共享和数据安全的最核心的抓手，谁负责业务，谁负责业务数据，谁就要负责保护业务数据，这个责任矩阵一旦落实，很多问题迎刃而解。

那么，数据团队是否该为融合模型表的开放负管理责任呢?

我的答案是，数据团队不应该擅自开放这张表出去，如果业务部门需要，需要由业务部门作为数据Owner发起数据上架流程，这个时候，这张表的owner就应该变成了相关业务部门，业务部门需要在充分理解这张表的业务逻辑基础上，明确开放表的目标范围，确保最小必要原则，这才是真正的责权利对等。

业务部门不能只享受了从数据中获取价值的利益，但不承担数据共享可能产生的风险，羊毛出在猪身上，这是不合理的，IT团队则应主要为数据共享平台的技术安全性负责。

这种数据owner制有个风险就是，谁都不愿意进行跨部门的数据共享，这个时候就需要企业的数据管理部门出来建章立制，明确规则，在必要时推动业务部门履行数据共享职责，实现责任共担。

这可能是今年我最大的领悟之一。

7、完美的“坑”

我进入职场以后，在前10年基本以数据仓库建设为主，然后做过一段时间的数据分析师。成为主管后，文字工作就开始变多了，因为需要代表科室写月报，写总结。大数据起来后，我曾经写了一年的技术材料。再后来，大数据变现出现，一方面我们如火如荼的搞产品，另一方面不停的写对外商业模式的材料。自己还兼职做过部门的文书，写了很长时间的部门材料。

最近2年，我一直在负责企业数据治理体系的建设，同时也在主导企业数据治理的材料编写，企业数据治理的道路，不夸张的讲，那也是用材料铺成的，材料代表了我们的思想结晶，一定程度也代表了生产力。

我以前也讲过，鉴于数据工作的特殊性，任何数据团队都需要一名外交部长，会写材料是数据团队体现自身价值的有效方式。

然而，随着管理职责的加深，我发现自己在追求材料的质量上有些过于执着，每次汇报都希望体现自己想像中的完美水平，这导致了资源和精力的过度消耗。其实，材料做到70分，能把事情说清楚就行了，但我总是会不自觉地去追求那个90分。一旦没达到，还经常自己上手，在一定程度上剥夺了团队成员独立思考和锻炼的机会。

应该说,一个管理者的主要工作就应该是决策,我多花点时间思考,多了解实际情况，做出更科学的决策，整个团队就可以少走一些弯路，这才是真正提升生产力的方式。而对材料尽善尽美的要求实际是对生产力的一种侵蚀。

我后来反思，觉得这是由自己怕失败的心态决定的，自己总是在追求某种确定性，可能我们这代人，生存忧患意识太强了吧，希望自己能摆脱这个心魔。

8、冲动是魔鬼

最近发生的两件事让我深刻意识到自己决策时的傲慢和不科学。

第一个事情是部门开决策会，讨论进行账号收敛的问题，然后问数据团队的XX账号能收敛到多少?我心中一盘算，觉得Y个账号就够了，然后直接跟部门拍胸脯。

两周后科室开周会，组长在介绍ZZ项目的时候，说要延期2-3周，我仔细看了周报上的文字，里面写了原因：由于账号不够原因导致项目进度受阻。我感觉很诧异，然后项目经理解释原因，说项目组的账号都被回收了，重新开通很花时间。

我问主管为什么当初决策会上不补充说明，主管说当时也很难判断具体要多少，只能凭经验定，而且当时既然我拍板了，就不好说什么，后来发现把项目组的账号数量给忘了，我问为什么不反馈到我这边，又不是不能改，大家开始沉默......

第二个事情是有一次我去替一位同事参加公司会议，会上各部门代表要对某个议题发表意见，我不太了解实际情况，因此找了一位相关的同事咨询，然后就去参会了。在各部门发表意见环节，我按照自己的理解进行了慷慨陈词，然后老板说我们要克服困难解决问题......

回来的路上，我重新找了原来做过这个事情的相关领导和同事了解了情况，才发现的确是自己片面理解了，我自己所谓的逻辑推理完全是错误的。根本原因还在于我并没有掌握完整的背景信息，加上自己不了解这个专业领域，做了很多主观的臆想。

在一个严肃的会上由一个不专业的人发表未经过多方审核的观点，的确是非常不专业的做法。

万维钢讲，科学决策的要点之一就是要多征询别人的意见和建议，然后综合起来自己拿主意，我感觉自己离这个要求很远，姑且不说我在自己的熟悉的领域也会犯错，更别提在一个自己不熟悉的领域。

我知道果断决绝有时候很有用，但尺度并不容易掌握，考虑到大多时候我们做事情没到那个紧急程度，因此更要放下身段，多听听别人尤其是一线人员和相关专业人士的意见，特别是在面对一个自己不熟悉的领域的时候，多shut up，少show time。

八个领悟讲完了，其实以上的反思都集中在了古人说的两个字上，即“中庸”，你也可以认为这就是马克思的矛盾的对立统一。做事之道，就在于恰到好处，没有什么事情是非黑即白的，人生这堂课，还真不容易学明白。