再论帆软用户同步功能,再次吐槽

楼主
我是社区第201491位番薯,欢迎点我头像关注我哦~

使用帆软系统几年了,针用户同步功能,真是无以言表,2022年2月25日发过一个贴子吐槽这一功能,今天再次吐槽。

组织机构和员工设计和同步功能不支持扩展,以及不符合通常设计

帆软系统做了这么多年了,用户同步的逻辑都没有理清楚。更要命的是实施非常不规范,前端实际工程师没有标准化的处理过程。给用户造成大量困扰。

首先,用户同步要考虑几种场景:

1、用户已经试用系统,或者前期少部分部门使用系统,因此,存在手工添加用户的情况,在后续工作中,正式上线或用户扩大化,以及满足内控上新入职员工加账户,离职员工禁账户或减账户需求,需要自动化同步用户信息;

2、存在一些外部工作人员,需要保留一部分手工添加的用户。

解决这一问题,最佳的做法是在添加用户时,增加一个手工维护用户和系统同步用户的选项(系统同步用户,除能变更选项,其它一切都不能调整)。后续只要将用户更改为同步用户,即需要系统更新信息,如果是手工维护用户则不更新信息。

其次,同步用户的目标没搞清楚

1、首要目标是,同步过后保证原已经设置权限的用户权限不能改变,一旦清空用户和权限,最终用户配置权限的工作量是海量的,可以视为一次安全事故。

2、用户同步可能存在一异列的异常,包括不限于,原始数据异常、同步功能设计异常、同步时通讯异常等,此时要增加大量的异常处理,但无论如何异常,最基本要保障用户信息同步更新过来,人员信息是全量的,一旦人员信息不全则可能出现无法为新用户授权的异常情况。

3、慎用删除用户功能,因为一旦删除,要想重新配权限,则还会出现海量工作量的情况。因此,在做功能时,一般都应选使用禁用用户功能,即如发现用户不存在时,应先将该用户设为禁用。再通过单独接口,对于删除人员进行单除验证和处理。

4、从企业内部控制要求上,离职人员,必须禁用账户,此功能主要防止离职人员再次访问系统的安全风险事件。

5、在确保人员正确的基础上,进一步同步校验组织机构、岗位等管理特性,在校验时,应确保组织机构上下级关系完整性。而岗位并非必须。同样,考虑异常的情况,在确保现存数据基础上,更新数据,要处理有人员无组织机构、组织机构无上级机构、组织机构名称异常等情况。

以上核心目标均是要保证现存系统的可用性,要保证能同步尽量同步数据,将异常和未同步的情况集中输出给客户,供客户进一步处理。

再次,帆软系统的设计败笔较多

1、设计时未考虑原始数据存在多种异常、同步工具存在异常、通讯异常等异常情况,作为BI软件处理原始数据异常这一基本要求未得到重视,未考虑到整个软件设计过程中。理想的认为原始数据正常,导致同涉过程中大量中断无法继续,实际难以完成同步,不是以能同步多少同步多少,后续再不断修改的思想,给客户造成困扰。

2、强制要求将客户的组织机构表、员工表关联才能导入。这是最反人类的设计,试问帆软自己会将这两张表设计在一张表中吗?实际企业中大量人员是挂在最下级组织,中间组织并不一定有员工。

3、在导入过程中以组织机构名、岗位名称进行唯一性校验。实际企业中大量以组织机构ID为唯一识别字段,组织机构名称校验并无实际太大意义,如有错误,通知客户处理即可,在系统中用不同颜色显示。而岗位名称,实际企业HR系统中,可能有一个基础岗位表,岗位分配到具体部门后,可能还允许具体公司和部门自行调节,这时会出现人员信息中同一岗位ID有多个不同岗位名称或者同一岗位名称有多个不同ID,这是原始系统的问题,但到帆软系统中则变成不可导入的情况。这实际阻断了后面的工作。这实际也是帆软不考虑容错,不考虑先正常使用再逐步修正的处理思想。

4、用户同步时,用用户ID匹配,不符合安全性设计思想。用户ID,主要保证自己系统权限逻辑的正常。如破坏用户ID,可能导致历史权限分配失控。因此,一般不允许外部数据更新该数据。如要更新,一般以员工编号、员工账号、员工身份证号为准进行更新。而当前系统中未提供员工编号字段,很多开发人员直接将员工编号与用户ID匹配,从而可能出现权限分配失控风险。

5、保留、清空这两个选项欠缺考虑,没有系统化的设计,缺乏人工交互。

(1)实际管理中相关业务操作复杂,由系统自己识别是手工录入,还是系统同步,缺乏应对管理多样化的实际需求,也缺乏人工交互的特性,缺乏应对管理灵活性能力。对于系统,实际在添加用户界面和修改用户界面,提供选择手工维护和自动同步的选项,实际灵活性更强;

(2)保留用户的核心是保证当前系统权限功能的完整性,因此,在保证权限不变的情况下,任何信息均可改变。如以员工编号为唯一关键字,更新用户账号、邮箱等(实际企业中有领导级员工要求使用某账户,而要求员工改账号的情况),因此,功能应是更新、新增,即对于现存用户,以唯一关键字为准进行更新,对于新增用户,增加员工信息,对于离职员工,将账号设为禁用或者删除账户(后者慎用)。可以增加配置项,不存在用户删除或不存在用户禁用等。

(3)对于密码,从安全上密码实际不允许出系统,出系统则意味着密码泄露。因此,密码处理可选项不多,即使用统一单点登录,或者生成随机密码,后续下发给用户邮箱,由用户首次登录自行更改。

  因此,保留这一功能,不存在某些情况下组织机构、岗位不变的问题,只要纳入同步范围,就是要保证与HR一致。而角色不一样,角色为本系统中的角色,不应更新。

帆软应高度重视这种系统基本功能,连这都做不对,还指望其它功能?

分享扩散:

沙发
发表于 2023-12-28 17:11:17
另外,帆软件组织机构居然没有排序功能,数据库中没有排度字段,这导致同步的组织机构与原系统组织机构存在显示差异。
SELECT  [id]
      ,[creationType]
      ,[description]
      ,[enable]
      ,[fullPath]
      ,[lastOperationType]
      ,[name]
      ,[parentId]
      ,[alias]
      ,[tenantId]
  FROM [fineDB].[dbo].[fine_department]
板凳
发表于 2024-1-5 23:35:55 发布于APP客户端
最开始也遇到了同样的问题。最后不得已废掉了帆软的用户体系,自建了一套,效果还不错,部门、角色、岗位、用户,一对多等等关系,几乎满足所有情况,最重要的是每个模块都可以授权一个模块管理员,该模块下的用户都由他去建,用户修改密码,锁定,删除,调整等我只需要开发新业务就可以了,灵活方便。只用了user表,dep表和enum表。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

返回顶部 返回列表