“之前有一个问题我一直没想明白，你说都是一个单位的，我在招聘模块填过的个人简历，评职称的时候，为啥还得填一遍？”
要回答引言的问题：首先我们要知道一个组织的系统是如何构建起来的
一个组织会构建非常多的业务系统，越是庞大的组织，业务系统越丰富
但是，我们要深刻认识到这些业务系统并不会一次性全都建完。一般来说呢，这些业务系统的建设路径是：
所以每个需求模块或许都是独立的应用，由不同厂商承建、有不同的业务字段、有需求特定的业务流程
然后我们回到引言的问题：招聘模块填过的个人简历，评职称的时候，为啥还得填一遍？
经过前面内容的铺垫，我们甚至可以大胆猜测一下招聘模块可能是A厂商提供的saas系统，职称评价模块可能是上级单位的定开系统，那么我们就可以解释引言的问题了，数据归属都不在同一个系统，填报内容有断层，好像可以理解了
懂点背景的人可能会说，这不就是缺个数据中台吗
起初我在咨询的时候也这么认为，下意识的会问一句：咱们组织有数据中台吗
然而回答往往是：我们有数据中台
（图源：《数据中台-让数据用起来》）
所以问题出在哪里呢？我接着问，既然数据中台建好了，下游系统直接从中台中获取数据不就万事大吉了。这话不问还好，一问需求部门就一肚子苦水可以到，故事要从很久很久以前说起，之前的系统是由另一个需求单位建设的，然后呢，就出现业务场景下同一对象的不同表述
在招聘模块中，要多了解人选，需要有500字的自我介绍
在职称评价模块中，主要看职员的成绩，100字的自我介绍就够了
招聘的数据确实在数据中台里，但是，数据中台获取过来的数据职称评价模块并不能直接用
既然我们找到症结了，解决方案是啥？
方案一：辛苦用户在不同业务系统多填一遍
优势：系统自有功能可以自闭环
劣势：用户操作麻烦，不停填写对应内容
方案二：后面建的业务系统直接获取数据中台的500字自我介绍
优势：用户不需要额外多填
劣势：委屈后建系统的业务部门，要迎合系统调整业务需求
方案三： 后面建的业务系统先从中台获取自我介绍，提示用户删减到100字
优势：对用户而言填的内容少一点
劣势：后面建的业务系统功能对之前建设业务系统产生依赖
所以，如果你是这个系统的业务方，你会如何选方案呢？
如果你是这个系统的产品经理，你又会如何设计产品呢？
本文由 @是湘湘呀 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。