“之前有一个问题我一直没想明白，你说都是一个单位的，我在招聘模块填过的个人简历，评职称的时候，为啥还得填一遍？”

01 了解B端产品建设背景

要回答引言的问题：首先我们要知道一个组织的系统是如何构建起来的

一个组织会构建非常多的业务系统，越是庞大的组织，业务系统越丰富

但是，我们要深刻认识到这些业务系统并不会一次性全都建完。一般来说呢，这些业务系统的建设路径是：

1. 具体使用部门提出需求
2. 厂商提供解决方案
3. 交付实施建设完成

所以每个需求模块或许都是独立的应用，由不同厂商承建、有不同的业务字段、有需求特定的业务流程

02 产生问题的原因分析

然后我们回到引言的问题：招聘模块填过的个人简历，评职称的时候，为啥还得填一遍？

经过前面内容的铺垫，我们甚至可以大胆猜测一下招聘模块可能是A厂商提供的saas系统，职称评价模块可能是上级单位的定开系统，那么我们就可以解释引言的问题了，数据归属都不在同一个系统，填报内容有断层，好像可以理解了

03 是因为没有数据中台吗

懂点背景的人可能会说，这不就是缺个数据中台吗

起初我在咨询的时候也这么认为，下意识的会问一句：咱们组织有数据中台吗

然而回答往往是：我们有数据中台

（图源：《数据中台-让数据用起来》）

04 数据中台失效的原因

所以问题出在哪里呢？我接着问，既然数据中台建好了，下游系统直接从中台中获取数据不就万事大吉了。这话不问还好，一问需求部门就一肚子苦水可以到，故事要从很久很久以前说起，之前的系统是由另一个需求单位建设的，然后呢，就出现业务场景下同一对象的不同表述

在招聘模块中，要多了解人选，需要有500字的自我介绍

在职称评价模块中，主要看职员的成绩，100字的自我介绍就够了

招聘的数据确实在数据中台里，但是，数据中台获取过来的数据职称评价模块并不能直接用

05 如何在用户侧选择解决方案

既然我们找到症结了，解决方案是啥？

方案一：辛苦用户在不同业务系统多填一遍

优势：系统自有功能可以自闭环

劣势：用户操作麻烦，不停填写对应内容

方案二：后面建的业务系统直接获取数据中台的500字自我介绍

优势：用户不需要额外多填

劣势：委屈后建系统的业务部门，要迎合系统调整业务需求

方案三： 后面建的业务系统先从中台获取自我介绍，提示用户删减到100字

优势：对用户而言填的内容少一点

劣势：后面建的业务系统功能对之前建设业务系统产生依赖

所以，如果你是这个系统的业务方，你会如何选方案呢？

如果你是这个系统的产品经理，你又会如何设计产品呢？