我在招聘模块填过的个人简历，评职称的时候，为啥还得填一遍？
01 了解B端产品建设背景
要回答引言的问题：首先我们要知道一个组织的系统是如何构建起来的
一个组织会构建非常多的业务系统，越是庞大的组织，业务系统越丰富
但是，我们要深刻认识到这些业务系统并不会一次性全都建完。一般来说呢，这些业务系统的建设路径是：
- 具体使用部门提出需求
- 厂商提供解决方案
- 交付实施建设完成
所以每个需求模块或许都是独立的应用，由不同厂商承建、有不同的业务字段、有需求特定的业务流程
02 产生问题的原因分析
然后我们回到引言的问题：招聘模块填过的个人简历，评职称的时候，为啥还得填一遍？
经过前面内容的铺垫，我们甚至可以大胆猜测一下招聘模块可能是A厂商提供的saas系统，职称评价模块可能是上级单位的定开系统，那么我们就可以解释引言的问题了，数据归属都不在同一个系统，填报内容有断层，好像可以理解了
03 是因为没有数据中台吗
懂点背景的人可能会说，这不就是缺个数据中台吗
起初我在咨询的时候也这么认为，下意识的会问一句：咱们组织有数据中台吗
然而回答往往是：我们有数据中台
（图源：《数据中台-让数据用起来》）
04 数据中台失效的原因
所以问题出在哪里呢？我接着问，既然数据中台建好了，下游系统直接从中台中获取数据不就万事大吉了。这话不问还好，一问需求部门就一肚子苦水可以到，故事要从很久很久以前说起，之前的系统是由另一个需求单位建设的，然后呢，就出现业务场景下同一对象的不同表述
在招聘模块中，要多了解人选，需要有500字的自我介绍
在职称评价模块中，主要看职员的成绩，100字的自我介绍就够了
招聘的数据确实在数据中台里，但是，数据中台获取过来的数据职称评价模块并不能直接用
05 如何在用户侧选择解决方案
既然我们找到症结了，解决方案是啥？
方案一：辛苦用户在不同业务系统多填一遍
优势：系统自有功能可以自闭环
劣势：用户操作麻烦，不停填写对应内容
方案二：后面建的业务系统直接获取数据中台的500字自我介绍
优势：用户不需要额外多填
劣势：委屈后建系统的业务部门，要迎合系统调整业务需求
方案三： 后面建的业务系统先从中台获取自我介绍，提示用户删减到100字
优势：对用户而言填的内容少一点
劣势：后面建的业务系统功能对之前建设业务系统产生依赖
所以，如果你是这个系统的业务方，你会如何选方案呢？
如果你是这个系统的产品经理，你又会如何设计产品呢？
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！