我在招聘模块填过的个人简历,评职称的时候,为啥还得填一遍?

01 了解B端产品建设背景

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

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

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

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

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

02 产生问题的原因分析

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

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

03 是因为没有数据中台吗

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

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

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

我在招聘模块填过的个人简历,评职称的时候,为啥还得填一遍?

(图源:《数据中台-让数据用起来》)

04 数据中台失效的原因

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

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

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

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

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

既然我们找到症结了,解决方案是啥?

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

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

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

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

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

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

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

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

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

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

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

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部