请上传宽度大于 1200px,高度大于 164px 的封面图片
    调整图片尺寸与位置
    滚轮可以放大缩小图片尺寸,按住图片拖动可调整位置,多余的会自动被裁剪掉
取消
zwenli(uid:201491)
职业资格认证:尚未取得认证
集群异常宕机始终未解决,帆软运维平台FineOps无效果。
  说好的通过运维平台解决问题,从安装后,从而没有异常报过警。   今天又发现宕机吧。一台服务器3月24日后,就无日志,系统无邮件报警。   另一台,日志里面连续错误,但也没有邮件报警。   更不要提自动重起应用,恢复系统使用。    
再论帆软用户同步功能,再次吐槽
使用帆软系统几年了,针用户同步功能,真是无以言表,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一致。而角色不一样,角色为本系统中的角色,不应更新。 帆软应高度重视这种系统基本功能,连这都做不对,还指望其它功能?
帆软集群方案严重投诉
帆软真的应该重视自己的集群方案了,这么严重的问题长期不解决,如何跟客户交待? 今天服务器集群又down机了,这是使用帆软系统以来第5次大的down,这对于客户是致命的问题。 集群的意义是什么? 1、增加并发访问能力; 2、任何一台服务器出问题,都不影响其它服务器的使用,不影响服务。 但帆软不行,5次down机,只有1次保证的服务可用,其它4次服务均不可用。 软件系统安全性的三个指标:完整性、安全性、可用性。可用性这一大项,帆软都解决不好,情何以堪? 所谓的集团应用支持,名可符实? 可怜的一线服务人员还在排查问题,可怜的我还在陪着加班。
关于服务器数据集增加分类管理和排序的需求
目前服务器数据集无法进行分类管理,由于服务器数据集可能数量比较多,无法分类管理,导致管理效率低下。 原设计中服务器数据集由于无法进行迁移(研发、测试、生产环境),导致数据集大量都使用模板数据集。但模板数据集有个重大缺乏,即复用性比较差,开发中存在多个模板使用相同数据集的情况,如需要改动,需要多个模板同时改动,这极大增加了维护工作量。 多个模板可能使用相关的数据集,如使用服务器数据集,在改动时,只要改动一次,所有模板数据集即可完成改动。如果大量使用服务器数据集,则服务器数据集中表定义数量比较大,如无法分类管理,则管理效率低下,难以识别和管理。 需要实现 1、对服务器数据集可进行分类管理(多级分类) 2、服务数据集可进行排序 3、现在的模板数据集可转化为服务器数据集,同时也可将同名的服务器数据集更换掉模板数据集中的同名模板数据集,以便多模板能使用相同的数据集。 4、数据集迁移明,可按服务器数据集分类进行部分迁移 5、可识别出某数据集被哪些模板引用,以便评估修改该数据集的影响范围,并进行验证。 6、服务器数据集上可定义参数,模板选用该数据集时,该参数作为模板上的参数,以便对参数进行更新。 7、现有选用的服务器数据集,在导出带数据的模板时,无法同步导出,如大量模板更换为服务器数据集,刚调试时可能出现问题。    
关于插件环境不一致功能的改进意见
仅示服务器插件版本,未显示本地插件版本。未提供插件单独同步功能。 原则上本地插件版本低,升级本地; 服务器插件版本低,升级服务器。 单前无法选择。如选择错误,需要重新下载插件升级。   希望:发现本地插件版本低,升级本地;服务器插件版本低,升级服务器。可单独同步某插件。 另外,是否可远程升级服务器插件?
关于条件设置、链接设置、事件跨单元格、控件进行复制,提高研发效率
代码编写过程存在编码复制,在复制基础上进行修改的情况,可极大减少开发工作量。报表、填报设计过程中同样存在该大量应用。但目前设计严重影响研发效率。 目前:条件设置、链接设置、事件设计无法跨单元格、控件和模板进行单独复制,模块web属性事件同样无法复制调整事件顺序,极大的影响开发效率。 如下图条件,仅能本处复制: 如下图链接,仅能本处复制: 如下图事件,仅能本处复制: 如下图事件不能复制、不能命名、不能调整顺序。 如下图填报属性,不能跨模板复制: 以下是建议复制模式支持: 1、公式可跨模板进行复制、粘贴 公式、事件支持调整顺序、命名、复制和粘贴、启用禁用。
关于数据分析软件应具备的特性
已经使用帆软report、BI产品很长时间,帆软简道云也深度试用。经过这段时间使用,发现这些产品没有很好的统一起来,同时,与实现应用还有一定差距。 本文给帆软提一些有效建议。 注:本人原来做审计软件研发,对于数据分析软件有深入研究。 首先,report、BI产品 报表产品主要解决数据展示,形成图形、图表分析结果。BI产品,虽希望提供给普通分析人员进行数据分析,但实际应用模式,还是在定义仪表盘,说白了还是在定义输出给管理层的图形、图表。整个软件,在数据处理过程比较弱、或难以支撑普通分析人员的分析过程。 这从软件产品最初没有提供ETL工具,可见一斑。但,即使提供ETL工作,也不代表提供使用普通数据分析人员使用的工具。 其次,简道云 简道云,原行业定义为网表软件,目标为建立基于网络的快速收集数据工具。同时,也可以称为零代码、低代码软件。这一名称,近几年比较火。可以实现简单应用的过速定义。是报表和BI产品,在应用缺乏ERP等前端数据时,向前端扩展方法。 从整体使用上,简道云、report、BI产品三套产品,底层框架差异很大,没有很好的统一起来,举例如下: 1、report的数据集与BI的数据集管理没有统一起来,这两个数据集管理需要分别定义和重复定义。      注:report的服务器数据集最初没有迁移功能,这导致为了方便不同环境中模板迁移,只能大量将数据集定义在模板中,在报表开发时增加了同一实质相同的数据集的修改工作量,在本人建议下才增加了这一功能。 2、简道云模板定义,实际底层也需要形成数据集,与report、BI也未形成统一。这导致这三套产品,看起来没有太多关联。 如更好的适应用户使用,需要从业务人员角度重新梳理整体流程,这需要还原数据分析原始流程。 基于数据分析的软件,国外产品做得比较好的产品有两家可参考,分别是ACL、IDEA。以下是IDEA的手册User Guide.pdf (5.98 M) 数据分析过程如下: 1、引入数据      引入数据的过程包括:ETL、链接当前数据、导入数据等。这不进一步说明。      这里需要说的是,数据引入往往需要与后续的分析过程、报表输出、预警输出重复使用。即在输出报表时,往往需要引入数据、数据处理,最后形成报表,必须引入数据、并数据处理后,才能保证报表的正确性。目前,这一定时调度并没有综合考虑,也未考虑这一过程中的容易处理。 2、数据管理     拿到数据后,首先要对数据进行管理。数据管理,需要对数据进行分类,对数据概况进行了解,对数据的来源去向进行管理。        数据的概况,是数据分析的基础。      (1)由于英文或简称等,需要对数据进行标识,以便对数据更好识别。               BI已增加该功能。实际上report数据集管理也存在该需求。SQL语句研发时间过长后,可读性降低,对字段必要的标识势在必须。               而简道云中对于模板的定义,实际也是数据集管理。这三个产品本可统一。      (2)概览数据类型,如下图            (3)概览数据范围            如不重复值、最大值、最小值等。以便在此基础上进一步对数据进行加工。                   (4)数据管理时,明确数据的来源和去向          数据上可以看出是在某项数据上进行了某些加工形成的数据,发抽样、加字段、查询部分数据。目前,产品中此功能比较弱。          此功能,对于数据分析人员很关键,某些数据时间比较长后,不清楚是怎么处来而来。对于数据形成过程极为关键。                     每个数据记录和明确该数据是如何处理来的。                        3、数据分析过程     数据分析过程,是在当前数据的基础上,直接利用工具栏,对数据进行标识、关联、抽样、查询、分层、转置、透视等操作。     这种处理习惯与当前的BI处理习惯不同,当前BI处理过程为面向报表开发过程。而实际分析过程是需要大量试算、大量处理。此项,BI需要进行改进。           如对EXCEL比较熟悉的,这一块比较好理解。如标识重复数据、去重复数据、数据条件显示、数据筛选、数据比对等。这一块帮助用户对数据进行有效识别和分析。      当前report中数据处理过程比较欠缺,主要还是根据数据表,形成报表。 4、报表生成      在数据分析的基础上,进一步形成相关报表、仪表盘。BI中的当前功能主要仅为数据结果展示。实际缺乏对数据的解读功能。对同一数据,如不经过必要解读,不同的人可能理解不同。甚至一些人看不懂数据。     BI目前实际应用中,仅用于数据展示。而普通管理人员大量使用的为report,主要用report解决日报、周报、月报这种重复工作量较大工作,在形成报表后导出成WORD,再进行加工形成自己经解读过的日报、周报、月报。     这里要重复提的是,本人使用任务调度时,生成word报表,在使用中必须调度缺少与数据引入、数据处理过程一条线联动,这导致最终报表的正确性可能难以保障。例如,数据引入过程异常,而本次报表输出使用的为历史数据。 5、数据预警     数据预警是数据分析日常工作中的重要事项。数据预警,可能形成一个报表、一个数据表。但这仅为数据生成过程。数据预警需要对数据进行验证、跟踪处理。目前这一块的功能相对比较弱。产品的重点仍停留在数据的结果报表展示层次。  
关于插件管理的吐槽
Report中大量使用插件,并提供了插件市场。插件的设计方法,为软件进行扩展提供了无限可能,但如管理不善会适得其反。这里就日常使用过程中发现当前插件的一些问题进行吐槽。 目前帆软已经有数量庞大的插件,对于用户来说: 1、插件的选用和安装需要耗费大量的时间。      用户在使用系统时,对不需要增加的功能,需要大量查询和查阅插件,才能找到增强方案。对于用户产生较大负担。 2、升级需要耗费大量的时间和工作量。      插件需要定期升级。而实际开发管理过程中,存在多个环境,包括:生产环境、准生产环境、测试环境,不同开发和设计人员环境。这些环境的升级,无形中需要耗费大量工作量。      特别是,当公司规模比较大时,采用内网部署,其工作量更是巨大。不同环境插件不一致的冲突,需要大量时间处理。      升级插件成员用户的一大负担。 3、系统启动时间变长。      由于插件的安装,在系统启动时,需要大量的时间加载插件,执行插件中的升级逻辑等。这导致加载时间长,插件时有报错等情况。 4、外部插件缺泛验证,错误和BUG较大     在本人使用日历、文件预览等外部收费插件时,发现大量BUG,有些BUG甚至为阻断性BUG。这无形中极大的增加了用户的工作量。花费大量时间试用,最终发现不可用。  5、插件缺少统一标准,使用时间不统一    举例来说,网页框、日历、内置控件的链接不一致 插件对用户不便,同样对帆软造成不利影响: 1、需要耗费大量的时间维护管理插件; 2、需要在软件中解决插件冲突; 3、外部插件缺乏验证和管理,最终不良结果需要由帆软承担。 因此,建议: 1、对于免费插件,适当的降减插件数量,合并进工程归。以减少该类插件的管理量、单独升级量、以及系统加载对该类插件的处理量。 2、加强标准的制订,统一插件的设计规范,减少插件的学习成本。
入坑零代码、低代码、APaas系统,你需要了解系统支持业务线和业务数量是否与本团队...
原贴位置:https://www.zhihu.com/question/487214224 本文为系列原创文 当前零代码、低代码、APaas系统话题热度不断提高,随之其是否能实现复杂业务一直是业内争吵的焦点。很多公司准备入坑,但不知道这坑到底有多深,本人根据切身经验加以探讨。 整体上从对数据量和业务量的支撑能力,将能力划分为:适合小团队使用;适合公司级团队使用;集团化公司使用。这三类团队特点: (1)小团队:组织比较扁平,成员之间关系平等;数据组织比较随意、业务相对简单、数据量不是太大。 (2)公司级团队:公司具有多部门组织,成员之间上下极关系明确;有一些基本管理规范,对于数据规范性有一定要求;业务涉及环节比较多,业务数据量比较大; (3)集团化公司:公司体系比较完善,需对多级公司进行管理,有典型体线化管理;对于管理规范性要求比较高,对于数据规范性要求高;业务多元化、多态化;业务数量极大。 一、组织机构 公司组织机构是企业业务重要管控单位,在管理过程中是重要管理主体,具要重要管理意义。组织机构在企业管理中不仅仅只是一个树形结构,其体建了企业的治理结构。从组织机构功能设计,我们可以识别出,该软件对于使用团队规模支撑能力。先以集团公司为例,说明其重要性: (1)公司机构中:办公室、人力资源部、财务部等机构设置体现了企业权力制衡、相互监督、相互制约结构设计,从一定层面体现企业管理能力。公司组织机构根据企业业务、战略布局进行规划设计。最终要体现出定编、定员、定岗管理要求。 (2)组织机构对于集团公司管理相对比较复杂。组织机构上涉及集团、公司、事业部、部门、小组等属性。同时,组织机构在实际使用时,存在根据选择部门找所在公司的需求、或所在集团的需求。组织机构上的公司,并不完全是该公司管理小的所有公司,主要原因为公司部门化管理、或仅用于融资等操作,在实际企业管理中,并不实际作为一级组织机构进行管理。 (3)对于集团公司,实行条线化管理,如人力资源、财务、风控等体系,因此,每个公司下都可能会有人力资源部、财务部、风控部等部门。集团公司同名部门需要区分所在集团、公司、事业部等。 (4)组织机构会定义调整,可能新设、变更、撤消。涉及历史管理要求。 (5)归入组织机构员工,在后续使用中,选择人员后,需要根据人员获取所在部门、所在事业部、所在公司、所在集团等信息。以便减少信息录入,以及对人员进行区分(大公司同名人员众多)。 从以上说明,组织承载了大量管控要求,属于系统基本功能。 目前,市场上涉及组织机构大体有三种类型: 1、软件中没有预置组织机构维护类 市场上部分软件没有预置组织机构维据,或者没有通自定义模板表实现组织机构功能(需要支持树形控件)。 此类软件由于缺乏大量组织机构特性,更无法实现复杂权限管理,很难适用于企业级应用、集团级应用。 2、提供简单组织机构维护和使用类 此类软件一般提供简单部门名称和上下级关系维护,没有提供组织推展信息。由于没有定义组织机构编码,无法对同名组织机构进行区分。这决定义其很难适用集团公司使用。 分析该功能,需要分别从定义和使用进行分析。 (1)定义 典型定义见下图: (图1、某1软件组织机构定义) (图2、某2软件组织机构及岗位定义) 本图定义,对于大组织机构定义,如数千组织机构,可能出现崩溃的情况。 (图3、某3软件组织机构定义) (图4、某4软件添加组织机构定义) (图5、某5软件添加组织机构定义) 本图定义,难区分同名组织机构。难承载组织机构更多信息。 注:总结,一般将组织机构、人员定义为通讯录的,往往仅适用于小规模公司。 (2)组织机构和人员选择 组织机构使用,往往与人员相关。 (图6、某软件选择人员) (图7,某软件选择人员) 上图选择人员,未对人员进行分类选择,在人员数量比较多时,如数千、数万,则加载速度会比较慢。网络传输数据量比较大。 (图8,某软件选择人员) 上图选择人员,按组织机构分类筛选人员,将组织机构和人员加载在一棵树控件件。这一界面设计,如果组织机构数千、人员数千和数万,则加载效率比较低下,同时,网络传输数据量比较大。相对来说图9相对合理。 (图9,某软件按组织机权分类选择人员) (3)组织机构和人员在数据上展示 对于小组织团队组织机构或人员重名概念比较低,但对于较大团队组织机构、人员为普遍现象。对于单公司,致少应支持同名人员区分。目前,大多数软件设计界面暂无法进行此类数据区分。如下图: (图10,某软件部门选择结果) (图11,某软件部门选择结果) 以类设计缺陷是,部门与人员单独选择录入,无法根据选择人员自动补录人员所在部门信息,输入工作量比较大。对于集团公司,需要同时录入所在集团、公司、事业部等信息时,输出工作量更大。因此,此类设计仅适用于单公司使用。 (3)权限分配时 模板表权限分配时,同上。主要区分是否支持多用户量权限分配,以及人员是否能区分公司、部门、员工编号(或员工账户)。这里不再重复。 3、提供可扩展组织机构类 提供可扩展织机构类系统,一般在组织机构上提供字段扩展能力,或者,在表模板中提供更新组织机构表能力设计(即通过自定义模板扩展组织机构信息,将组织机构定义同步更新的系统组织机构表)。目前市场上此类软件较少。 另外,在组织机构等信息选择时,支持将人员、组织机构信息多列一次性返回表列表。相关界面例示如下: (图12,某软件选择部门、人员等返回多列信息) 通过以上论述,可明确,组织机构信息可扩展,可同时返回多列信息是集团类团队业务所必备功能。否则开发工作量将比较大。 二、业务量支持能力 业务量支持主要从两个角色进行评估:模板表支持数量、数据加载方式。 1、模板表 模板表从零代码、低代码、APaas系统来看,决定了支持多大数量的业务。重点考察模板表的排列显示方式,是否能对模板表进行分类管理。 从市场上来看,模板表管理分为两类: (1)以项端多页签形式管理模板表 此类软件主要模仿Airtable软件样式,如下图: (图13,Airtable模板页签管理) (图14、某软件模板页签管理界面) (图15、某软件模板页签管理界面) 以上模板表管理缺陷是,业务表数量比较多时,页签平铺展开,可支持页签数量受到限制;无法对模板表进行分类管理。 (2)提供左边功能分类栏进行管理 对模板表进行分类管理,有利于对模板表进行有效组织。通过折叠分类树,可以增加对模板表数量的管理能力。 (图16、某软件功能分类管理界面) (图17、某软件功能分类管理界面) 综上所述,项端页签模板表管理形式,仅适用于业务流程和功能简单业务。对于业务环节众多业务不适应。 2、数据加载方式 EXCEL数据量最大支持65万条,数据库应用无此限制,但系统通过网络实现数据加载,因此,需要重点考察是否有进行分类加载处理、以及减少默认加载数量设计。 此类设计主要从默认过滤查询条件和左栏分类管理树解决。 (1)默认查询条件 默认查询条件,可以缺少数据加载数量。如下图: (图18、默认筛选体件参数界面) (2)在栏分类管理树 在数据左边提供组织机构树控件,对右边数据进行快速过滤。如下图,通过点先组织机构对数据进行快速筛选。 (图19、默认筛选体件参数界面) 注:组织机构使用下拉树控件时,操作步骤过多(每次切换必须点击下选,并且重新打开组织机构树),不利于简化操作步聚。 (图20、下拉选择组织机构界面) 注:部分软件对于树形分类控件支持不足,从而弱化了对数据的分类管理能力。这意味着,如果想要对多级仓库、销售大区等管理时,很难直观显示层次结构。 (图21,摘取3个主流软件无树形字段) 三、数据规范化管理 数据规范化对于企业管理是重中之重,曾有经历多个部门拿来的数据对不上,并且不知道哪个数据是正确数据。而数据夫范化对不同规模企业重要小相差比较大,对于小团队要求相对弱,团队越大、跨部分越多,要求越高。 数据规范化中一个重要的概念和功能是数据字典。存传统ERP中,数据字典为系统必备公司,其主要解决相同类型的字段,引用相同字典,在系统修改时,通过修改字典一次性修改所有功能模块。同时,对于字典进行权限控制,避免数据字典被任意修改,导致数据差异情况出现。 数据字典示例如下图: (图22,数据字典图) 目前,市场上软件大多数系统数据字典概念比较弱。分为:仅仅提供单表单定义、跨表单引用、集中提供数据字典三大类。 1、单表单定义 单表单定义,仅支持在一个表单中定义,可以任意修改。如下图: (图23,airbable字段下选定义) (图24、某软件下选定义) (图25、某软件下选定义) 以上定义主要缺点是,对规范输入没有权限控制,任何人员、随时可以修改。因此,该类软件仅适用于小团队、对规范化要求不高团队。 2、本表单定义、跨表单引用 此类软件支持在本表单上定义选择项、以及从其它表单引用项。 (图26、某软件自定义和跨表引用下选) 该类定义无法支持对关联表数据进行权限限制。 3、本表单定义、跨表单引用并支持权限控制 除以上一条具备功能位,提供权限控制功能。即根据权限提供供选择内容。 (图27、某软件弹出定义) (图28、某软件定义权限控制和过滤条件) 4、数据字典功能 少数软件单独提供数据字典功能。如图22。 从功能上建议选用支持权限控制、可提供集中数据字典管理(避免多处修改,可能出现遗漏)、支持跨表单具筛选功能数据字典。 综上所述,结合本团队规模、业务特性,针对性选择与本团队和业务数量和规模相适应用软,避免入坑适应较小团队能,可有效减小项目失败风险。 适用团队规模 团队特点 功能特点 备注 小团队 组织比较扁平,成员之间关系平等;数据组织比较随意、业务相对简单、数据量不是太大表格未分类 无组织机构定义;人员未实现分类选择;模板表以页面顶端页签展示;默认数据全量加裁;无数据字典功能;   公司级团队使用 公司具有多部门组织,成员之间上下极关系明确;有一些基本管理规范,对于数据规范性有一定要求;业务涉及环节比较多,业务数据量比较大; 有简单组织机构定义,未对组织机构信息进行扩展;模板表提供分类管理;默认数据按筛选条件加裁;弱数据字典,可实现跨表引用; 目前方案中对于树形分类控制支持均不足。 集团化公司使用 公司体系比较完善,需对多级公司进行管理,有典型体线化管理;对于管理规范性要求比较高,对于数据规范性要求高;业务多元化、多态化;业务数量极大。 提供可扩展组织机构信息管理;对人员进行分类选择;模板表提供分类管理;默认数据按筛选条件加裁;可实现数据更多层次分类;提供数据字典功能,规范数据管理;提供跨表引用;数据字典、跨表引用支持权限控制。 集团化公司使用需提供更精细管理;要求更严格权限控制
入坑零代码、低代码、APaas系统,你需要了解权限控制上有哪些坑?
原文地址:https://www.zhihu.com/question/485463474 当前零代码、低代码、APaas系统话题热度不断提高,随之其是否能实现复杂业务一直是业内争吵的焦点。很多公司准备入坑,但不知道这坑到底有多深,本人根据切身经验加以探讨。 整体上从对权限的支撑能力,将权限支撑能力划分为:仅适合权限要求弱小团体使用;仅适合单部门体系使用;能适用于公司网状或矩阵化权限管理使用;能适用于集团型公司复杂权限使用。 相对于EXCEL,权限控制解决EXCEL文件权限控制不足问题。如多人收集汇总数据、多级部门汇总数据,避免人员看到、维护大于本人员权限数据。权限控制之重要性,是系统选型核心重点。 当前零代码、低代码、APaas系统大都从表格入手,多从模仿Salesforce、Airtable这些软件开始。表格网络化之后,第一要解决问题是权限问题,权限问题解决不好,表格网络化基本没有存在市场价值。 由于沿用Salesforce、Airtable概念,这导致目前市场上软件大多数权限基于单表控制;或者由于基于表的概念,对于数据量较大、使用部门较多的情况考虑欠缺,这整体导致权限控制能力相对比较弱,限制了对复杂业务、多部门协作的支持。 从目前市场上软件还看,基本都可以实现对表记录新增、修改、删除、导入、导控制,对视图权限控制,对字段权限控制,但在行权限控制上比较薄弱。对于行权限控制分为以下三种情况: (1)无法对行记录权限进行控制; (2)仅对部门条线化管理权限可以控制,如本人看本人、领导看本人、上级领导看下线领导、上级部门看下线部门,即存在隶属关系权限控制。 (3)矩阵化部门权限管理(或监督型权限管理),如质量保障部、财务部、风险控制部,可以查看销售部门、采购部门、项目相关数据,而这些部门与销售部门、采购部门等没有隶属关系。 (4)项目权限控制,成员加入项目后,项目成员可编辑查看该记录信息。 对于权限控制,可参考本人《零代码、低代码、APaaS系统设计(之四)权限设计推荐》一文 领悟杂谈:零代码、低代码、APaaS系统设计(之四)权限设计推荐3 赞同 · 1 评论文章 一、无法对行记录权限进行控制 此类权限控制,没有提供数据权限、行权限功能。严格说,此类软件仅适于很小的团队应用,相关团队对于数据权限没有太高要求,没有本人只能看本人数据权限要求。此类软件一般适用于权限要求弱、小团体使用。 如下图: (图1、某1软件权限设计界面) (图2、某2软件权限设计界面) 二、仅对部门条线化管理权限可以控制 此类权限一般在模板表定义时,定义一个成员字段,通过成员字段设置作为成员、作为记录拥有者、仅用于记录人员数据,在权限处设置本人和下属,即具有相关的记录权限。此类软件仅适合单部门体系使用。 此类权限局限性为: (1)、对于部门设定某普通员工作为业务管理员,代为管理某业务数据的(如合同管理员、案件管理员等)不能很好支持。 (2)、矩阵化部门权限管理(或监督型权限管理)不能很好支持。如财务部门要监管销售合同数据。 (3)、如果员工岗位调到其他部门,而数据上又没有将该员工在原部门数据成员、数据拥有者记录取消,则可能出现新部门领导看到其他部门数据情况。 注:一般通过表字段上定义部门、公司字段,通过该字段控制部门数据查看范围相对比安全。 (4)该设计由于仅显示名称,对于公司存在人员重名,无法区分;对于集团公司,存在不同公司下有相同部门时,无法区分部门。一般对于较大公司对于信息管理,需要通过集团、公司、事业部、部门等字段共同区分人员和部门。 从以上我们可以看到,条线化管理应用局限性也比较大,如涉及要跨财务、质量管理、风控、法务等体系管理,则很难支持该业务。 如下图: (图3、某3软件模板表增加成员字段) (图4、某3软件权限配置) (图5、某4软件行权限配置) (图6、某4字段条件匹配当前人员权限配置) 三、矩阵化部门权限管理(或监督型权限管理) 1、逐个表定义权限,按部成、成员字段区配权限 矩阵化部门(或监督型)权限管理,目前一般是在表上通过增加部门字段、成员字段,然后,在权限设置时,将成员字段设置当人员人或指定人员匹配,校验是否本人或指定我人有权记录;将部门字段与指定部门匹配(如当前用户所在部门、当前部门所在部门及下级部门、指定的部门),即可以实现条线化权限管理,同时,也可以实现财务等部门管理其他部门数据的业务要求。此类软件能适用于公司网状或矩阵化权限管理使用,人员用户数量不适过多。 以上权限控制的缺陷是: (1)逐个表配置,权限配置工作量巨大。 (2)不支持大集团分级数据授权模式。 如下图: (图7、某4软件成员匹配设置) (图8、某4软件部门匹配设置) 2、模板表中定义筛选公司或部门字段in操作人员部门权限表 此类权限是定义组织机构,并定义角色或人员所具有的组织机构权限(如图7),然后,在表单中定义公司、部门字段找当前人员有权限的公司和部门记录。 该方式的优点是, (1)、权限条件统一定义,人员或角色定义组织机构权限仅需权一次,权限定义工作量相比较小。 (2)、权限可通过in 语句多层嵌套,可以实现较为复杂权限。如“五”中所述权限。 (图9、某5软件人员部门权限设置) (图10、某5软件通过SQL条件嵌套过滤数据) 上图权限满足:按角色过滤数据、按项目组过滤数据、按主责人员和最后修改人员过滤数据、按组织机构和组织机构权限表过滤数据复合权限控制。 注:本种权限控制,在零代码、低代码、APaas系统中非常少。 四、项目权限控制 此类权限一般在模板表定义时,定义一个成员字段,通过成员字段设置多选成员,并通过权限处设置成员为加入的、拥有的,来界定多个成员有权限。参见图3、图4。 该设计局限性: (1)、一般成立项目组,成员可能由多个公司、部门、人员组成,项目组中需要区分以上信息;人员在项目中担任不同角色,需要区分;人员有不同的加入项目时间和离开项目时间,需要进行区分。目前设计无法加以区分。 (2)、项目权限控制时,还涉及项目中子任务、内容权限控制,一般项目控制为,项目经理对项目中所有子任务有调整权、检查权;项目中可能分成数个项目小组,小组长对本人负责范围内的子任务有调整权、检查权。目前,试用软件范围内,尚未看到有软件支持子任务权限控制。 注:项目权限控制是日常管理中运用非常普遍权限控制,建议重点支持。 五、考虑不足权限控制 1、通过子表公司、部门授权控制主表行记录: 工作任务、事故、案件等,在企业管理中一般指定主责公司、主责部门、主责人员(不同部门可能各设一名)。同时,同一项任务由多部门共同承担、一事故涉及多公司和部门、一案件当事人涉及集团内多公司,在管理时存在两个角度管理:A、主责公司部门统筹管理;B、涉事公司统计本公司涉及的任务、事故、案件等。实际上业务办理虽然工作主责管理单位跟进,但该工作对本单位有紧密关联关系,相关部门负责人、相关公司负责人要纳入本公司和部门跟踪范围。因此,根据子表所列公司、部门控制权限,也是权限的一种主要形式。 2、多种组织机构权限控制 企业管理由于管理需要,不仅要按统一固定组织机构管理数据,还需要按多种不同组织机构管理数据。例如:按销售大区管理、按管理体系管理(如人力资源、财务体系、风控体系、采购体系、办公室体系等)、党组织等。 销售管理中,大区管理(东部区、西部区等,该大区在组织机构上不一定存在,仅仅在总部指定人员分别负责不同区域分公司和代理商的销售管理)。 集团公司一般进行体系化管理,如人力资源体系、财务体系、风控体系,各公司财务、人力资源、风控服务本公司管理,同时,要服从本体系管理。 多组织体系授权控制支持,是复杂权限授权支持要件,也是集团化权限管理要件。 3、集团分级行数据授权 集团公司人数众多,如人员权限全归集团总部授权,其工作量巨大,相关系统管理员无力承担该工作量。一般情况下,由集团总部授权子集团管理本集团范围内公司和部门,子集团再授权给下级公司管理本级公司下部门人权授权。目前,分级数据授权在零代码、低代码、APaas领域暂未发现该类授权。只有分级授权,才能适应大型企业权限应用,能适用于集团型公司复杂权限使用 注:从成员选择未考虑同名人员、多部门、多公司区分,以及实现复杂权限管理的供应商比例非常大,目前市场上对于大型企业的典型客户不足,或涉及业务尚不复杂。供应商应重点解决权限问题,以满足复杂业务需要。降低公众中,无法实现复杂业务印象不利影响。 综上所述:从以上分析,部分软件仅适合小团体使用;部分软件仅适合单体系部门使用;部分软件可适用矩阵化管理模式,但其权限分配工作量巨大,仍有待进一步优化;而对于复杂权限支持,目前市场上软件均存在不同程度不足。软件企业采购,根据适用范围慎重选型。 适用团队规模 功能特点 备注 小团队使用 无法对数据行权限进行控制   单部门条线团队使用 定义岗位和员工上下级关系;定义编辑、查看本人创建数据。定义上级编辑、查看本人,及下属、下级单位数据; 人员调动时,可能出现权限漏洞。 网状矩阵化(监督型)团队使用 支持部门条线化权限授权。模式1:基于表单,通过表单上字段条件定义人员、角色,设置可管理部门组织机构权限。模式2:基于组织机构等维护,定义人员、角色部门组织机构权限;基于表单,定义表上字段与某部门组织机构权限过滤筛选关系。 适用协同人力资源、财务、风控、办公室等多部门联合使用。使用小规模公司管理 集团化团队使用 支持网状矩阵化(监督型)权限分配;支持分级授权;支持分组织机构授权;支持通过涉及组织,多层反查约束授权。 重点支持5000人以上权限分配;大型组织,需重点考察部门和人员选择界面(部门多、人员多),是否分层显示部门、分部门过滤人员,一次性加载部门和人员说明未经历大团队项目考验。分级授权重点考察组织机构控件是否可部分加载有权限部门;多分、子公司管理 项目团队管理 定义行记录(项目)团队,以及行记录主责人员(项目经理);定义团队小组长,及可编辑、查看资源(如任务、任务下文件等);实现仅本团队成员可编辑、查看本记录数据。非本团队成员无权查看和维护。 涉及项目管理需考察
零代码、低代码、APaaS系统应从哪些指标考察选型?
该原来地址:https://www.zhihu.com/question/477427067   软件选型对企业影响很大,初步拟定以下指标供参考。后续进一步更新。 零代码、低代码、aPaas系统选型不同于传统软件选型,区别如下: 1、传统软件选型 (1)更注重软件业务支撑能力,支撑业务的在熟度;业务标准化程度相对比较高; (2)供应商的服务能力。如果软件有部分业务不支持,供应商的二次开发能力作为重点考核点。 (3)公司有足够软件投入;   2、零代码、低代码、aPaas系统选型 (1)一般现有市场没成熟系统,或者系统集成性不好,或者某些功能市场上产品没有实现,或者需求变化太快,或者需求还没整理清楚;业务标准化程度不高; (2)本公司开发能力不足,如专业开发人员不多,或者不具备研发管理能力支持;开发能力足,则自行定制化开发(原因参考此文); 低代码开发平台提供源码有什么意义?1 赞同 · 2 评论回答 (3)公司软件投入相对不同足; 总结起来就是业务标准化相对高的一般传传统软件,比如标准化比较高业务财务系统,就选用友、金蝶等,选低代码一定不是明智之举。而非准系统,因为没有,因此重点考查一些重要特性指标,这些特性决定是否能支持未来自己系统功能实现。 以下指标中有几个关键指标重点考查: (1)权限:灵活快速的权限设置。目前大多数软件仅有实现条线化权限控制,即本人有权护本人创建记录,本人上级能维护查看本人创建记录、上上级能查看下级记录。参见 领悟杂谈:零代码、低代码、APaaS系统设计(之四)权限设计推荐3 赞同 · 1 评论文章 (2)跨表的处理逻辑:只有能对基它表和字段进行跨表新增、修改、删除、计算等,才能实现复z杂业务逻辑和功能。参见 领悟杂谈:零代码、低代码、APaaS系统设计(之五)跨表处理逻辑设计3 赞同 · 0 评论文章 (3)集团功能:业务数量大,且涉及本企业多家公司管理时,需要重点考查。参见 领悟杂谈:零代码、低代码、APaaS系统设计(之六)集团公司需求设计0 赞同 · 0 评论文章 (4)选择零代码还是低代码,除以上关键指标,重点考查公司是否有研发人员。两种研发文式优劣势,参见: 零代码和低代码平台这两个平台那个对公司后期的发展好?0 赞同 · 0 评论回答  
关于网表软件、零代码、低代码软件设计模式中严重误区
文章发表于知呼  https://zhuanlan.zhihu.com/p/357144455 目前,大多网表软件、零代码、低代码在设计时严重忽视终端用户实际部署和使用问题,这问题涉及生产环境、准生产环境、研发测试环境的应用。目前,大多数软件没有提供这多系统之间的切换功能。 首先,无论是网表软件、零代码、低代码软件,软件功能都需要不断的叠代、扩展,有些复杂的功能不可能一次、一天修改完成,而如果只有一个系统环境,则会严重影响前端用户的使用,严重的情况会出现系统中断、数据错误等问题。这就需要区分生产环境、准生产环境、研发测试环境等环境。 生产环境:前端用户正式使用的环境,这一环境需要确保系统相对稳定,功能逻辑在一定时间期限内、或一定业务范围内应保持完整、连续、有效。只有经过测试、验证的程序逻辑才能在生产环境中使用 准生产环境:其环境配置与生产环境保持近似,其部分数据来源于生产环境,其环境主要为在开发的功能在式应用于生产环境前,对相关功能进行最终确认,以降低、减少功能迁移到生产环境后,系统出现中断、BUG等严重影响前端用户使用的问题。 研发测试环境:即使于定义新功能、新逻逻辑,对现有功能进行修改完善的环境。网表软件、零代码、低代码软件并不能改变功能定义这一过程(仅是没有编写代码,或将代码编写改变为功能配置),因此,也无法改变需要提供研发测试环境这种客户需求。 因此,网表软件、零代码、低代码软件设计模式中必须致少支持两个环境,即生产环境和研发测试环境,如果软件无法区分这两个环境,则会严重影响客户实际使用。 仅仅区分生产环境、准生产环境、研发测试环境还不够,软件真正要做到的是对新功能的打包、迁移。重点关注以下几方面: 1、功能模块打包迁移,确保相关功能能整体迁移到正式生产环境中。最好具备一定的版本控制功能,能对功能模块的升级进行标识区分,能明确功能变更情况。 2、数据库连接迁移,涉及应用必须涉及数据库,数据库连接信息的迁移为功能迁移最低要求。 3、数据打包迁移,应开发功能中涉及数据字典等数据,用于支撑新功能和变更功能,如功能迁移完成,而不迁移数据则会导致变更功能无法使用。因此,功能打包迁移,必然涉及数据打包迁移。 综上所述:考查网表软件、零代码、低代码软件时,一定要注意验证平台是否支持生产环境、准生产环境、研发测试环境多环境应用,以及在不同环境中进行功能迁移,如不具备相关功能,应避免选择。
关于国内网表软件、零代码、低代码、APaas软件等快速开发软件选型
相关文章发表于知呼 https://zhuanlan.zhihu.com/p/356015370 随着经济的快速发展,当前市场上对于快速开发软件需求和呼声很高。其目标是,由业务人员(非技术人员)快速完成软件的定义,快速上线、快速应用,以便适应需求的快速变化。笔者在选型相关软件时,涉及网表软件、零代码软件、低代码软件等、耗费了大量时间,为减少有相关需求的人员走弯路,特整理本文档,供参考。 一、快速开发软件的引入 传统的软件开发模式存在天然的缺陷,相关缺陷如下: 1、研发周期长,失败概率大 传统软件研发一般采用爆布工、敏捷式的开发模式,需要经历可行性研究、需求、设计、编码、测试、上线试运营和正式运营等生命周期的管理,软件从需求到上线一般需要致少6个月的周期,而大多数软件这一过程在8个月以上。 这一长周期,与当前经营发展不相适应,当前企业经营情况以月为单位发生变化,在2到3个月周期间,需要对业务进行调整,这导致原有需求发生变化;同时,企业组织机构调整周期约为11到12个月,企业组织机构的调整也导致需求变化。实际上意味着软件开发过程中,需求已经变动;或者软件投产不久,需求已经变化,也就意味着软件马上需要重构。传统软件研发过程,不能适应当前企业经营发展速度。 2、需要专业技术人员,需求转化存在障碍 传统软件研发需要专业的产品经理、需求分析师、程序员、测试工程师等大量专业的人员,这些人员一般专业能力偏计算机软件技术,对于企业的经营管理了解往往不深入,因此,在业务需求转化为软件产品时,存在天然的障碍,最终软件产品成品往往偏离于企业业务人员需求。其表现结果为,业务人员认为软件不好用、不可用,软件增加工作负担等。 3、软件投入成本大,软件调整受限,软件失败概率大 传统软件大多为定制性开发,需专业人员投入,其成本往往很高,一套软件往往达到150万元以上,而受限于需求变更,可能引起研发成本的大幅变更,软件供应商一般不欢迎变更需求,甚至在合同中约定变更需求工作量。而这与实际企业业务需求的获取过程形成矛盾。企业经营管理人员往往不具有软件技术经验,很难将自己需求整理准确、充足,这导致往往软件产品在上线使用后,还需要进行大量的调整,而在当前研发模式,软件研发公司不可能接受这种调整,而不调整又影响使用效果,这导致软件失败概率比较大。 同时,定制化开发软件,也导致后续软件升级难度高,企业要付出高昂的代价。 以上传统软件研发的缺陷,导致传统软件越来越无法适应企业经营管理,市场需要由业务人员(非技术人员)快速完成软件的定义,快速上线、快速应用,以便实应需求的快速变化快速开发软件,这也引出了快速开发软件。 二、快速开发软件分类 1、按代码量分类 快速开发软件是一统称,快速开发软件实现方式有很多种。大致可分为:代码生成类软件、少代码软件、零代码功能配置类软件。 (1)、代码生成类软件,一般为在相关系统上完成功能配置后,由系统自动生成相关的代码,再经过编译成为最终的软件产品。客观讲,这一类产品属于程序员级的产品,即只有程序员才能使用的产品。这类产品的优点是,相对比较灵活,能实现相对复杂的界面和功能;但缺点也明显,即对使用人员要求高,实际上很难适应需求的快速响应。 (2)少代码软件,这类软件一般大部分功能可通过配置完成,复杂的功能要求通地VB Scrip、JAVA Scrip、SQL去实现。这类产品相较于代码生成类软件适应性更强,但对研发人员的要求还是比较高,客观讲还是影响了这类软件的实际应用,试想多少企业业务人员具有较高的计算机软件技术能力 (3)零代码功能配置类,这类软件体产品功能均由系统功能配置完成,完成不需要代码人员参与,主要由业务人员、产品人员、需求人员参与,软件能适应业务的快速变化。其缺陷是软件界面转化程度不高,界面美观性受到一定程度影响。客观讲此类软件是真正市场所需的快速开发软件。 2、按市场名称分类 目前快速开发软件市场上的名称有很多,包括:网表软件、低代码零代码软件、aPaaS、BPM PaaS等。 (1)网表软件包括:快表、伙伴云、云表、魔方网表、简道云、勤哲、活字格等;这类软件目标是将大多数线下EXCEL表格都能转到线上,供多用户进行分权限填报,并输出图形、图表统计分析展示。 (2)零代码低代码包括:明道云、牛刀云、氚云、轻流、宜搭、JePaaS、天纵软件、力软、云捷配等;这类软件一般定位于,快速实现简单企业应用。 (3)BPM PAAS包括:炎黄盈动等。其主要实现线上工作流、自定义表单,快速适应企业各种业务工作流流转。 (4)致于aPaaS则以上很多软件也宣称自己也是aPaas系统(在aPaaS模式下,非技术人员可以直接在云端完成应用程序的搭建、部署、使用、更新和管理)。 客观讲,以上名称分类与实际功能应用可能相差比较大,仅作为宣传参考吧。 3、部署方式分类 快速开发软件按部署方式分类纯云部署、混合部署、纯私有部署。 (1)纯云部署,由服务商仅提供云服务,由企业通过服务商云服务配置系统,所有的数据都在服务商服务器上。这类系统如:明道云、氚云、轻流、宜搭、伙伴云等。这类部署方式个人认为并不适合市场需求。数据对于企业经营发展越来越重要,小微企业相对容易接受这种方式,对于中、大型企业则不大能接受这种模式。而矛盾的是,无论快速应用软件如何宣传,其对于业务人员的软件技术能力还是有一定要求,太小企业的人员并不具备这种能力。笔者,并不看好此类部署发现的市场前景。 (2)混合部署,此类部署即支持使用服务商的云服务,如企业有需求,也支持企业私有化部署。这类系统如:云表、炎黄盈动等。相对来讲,这种模式更有利于企业更广泛的选择,在企业规模小时,使用服务商的云服务,企业发展壮大后,再转为私有化部署。笔者认为,此部署方式更有利于服务器和企业发展需要。 (3)纯私有部署,即服务器并不提供云服务的模式,仅提供在企业本地私有部署。此类软件一般费用比较高,属于相于传统的企业软件提供方式。此模式限制了跨企业的数据共享,不利于提供更高级的软件应用服务,例如知识库共享等。 三、软件成熟情况分析和选择 快速开发软件当前大多数还不成熟,主要原因为,快速开发软件对于研发人员技术能力储备提出更高要求,同时,要求研发人员具有较高的企业业务应用能力,即最好具体一定程度的企业经营管理经验。特别是后者,没有相关企业经营管理经验,很难抽象出能定义出符合企业经营管理运营需求的快速开发平台。而单纯从技术人员角度提出的解决方案,天然很难适应普通业务人员使用需求。因此,软件在选型时,需要综合考虑本企业情况、本业务情况,选择相近的系统。 1、当前快速开发平台的选择需要从两个方向考虑: (1)本企业的人员情况 本企业技术人员比例高,可选择偏技术方向的快速开发平台,即要求具有一定编程能力的平台。本人原来从事过软件编程工作,建议选择低代码和零代码方向的平台。 (2)业务情况 在选型软件时,需要根据自身的业务应用方向,业务的复杂度进行综合考虑。毕竟适合自己的才是最佳选择。业务应用比较复杂,一个快速开发平台的配置相对会更复杂、界面要求更复杂,对可编程代码要求更高一些。 2、软件平台选择关键功能确认要点 快速开发软件在选型时,应重点从以下功能处进行确认,以便选择更适合自己的系统。 (1)组织机构和人员管理功能 组织机构和人员管理功能是信息系统的关键基础功能。软件选型需要首先确认这一基本功能。对该功能的确认需要参考两个变量:使用系统组织机构规模、使用组织机构人员数量。 目前,部分软件并未提供组织机构的维护功能、人员信息维护功能,这些功能需要通过软件进行再定义。这类软件,一般仅适用于少量人员使用,一般不超过50人,织织上适用于小组型团队使用,不大适用于大规模使用。 一般3个部门以上,50人以上的企业应用,建议选择已经具备组织机构维护、人员信息维护功能的系统。另外,还需要考虑,是否具体现有组织机构导入、现有人员信息导入功能。如涉及与当前已有系统的集团,还需要考虑相关功能是否具备单点登入集成的能力。一般纯云端部署的系统,不具备单点登录信息的能力。 (2)权限功能 权限功能是快速开发软件选型时,应核心考查的功能。对快速开发软件权限功能支持的权限模式,将影响该产品可应用的功能范围。 权限一般分为:功能菜单权限、列权限、行记录权限。功能菜单权限一般大多数软件都能支持,即可以按功能模块、按菜单、按钮(如新增、修改、删除、导入、导出、审核等)对软件进行授权;列权限,主要指哪些列可以指定人员查看和修改;行记录权限,主要涉及每条记录查询、查看、修改、审核权限,例如,查看不同销售大区的销售线索、不同人员查看不同合同、项目组成员可查看项目相关信息等。而行记录权限是权限重点考查关键重点项。 行记录权限一般致少支持以下权限模式: (A)条线化权限管理模式:本人管理本人记录、部门负责人管理本部门记录、上级部门管理本级及下级部门记录。 (B)监督权限管理模式:一条为质量管理部门、财务管理部门、风险管理部门、法务管理部等可以管理其它部门数据。 (C)项目级管理权限:合同、项目等,只有项目组成员可维护(新增、修改、删除)、查询相关合同、项目信息。 (D)按指定的字段分配授权模式:如按销售大区分配授权、按文件保密级别分配授权等。 行记录权限比较自身需求,致少从以上维度进行考查,尽量选择权限具备可多表关联灵活配置权限、条件可进行组合设置的软件平台。 权限另一外特别关注的功能是,在进行查询、报表设置等后续使用于,在表上配置的权限是否可沿用。该功能将决定后续报表设置的工作量,如果权限不能沿用,报表设计将面临大量工作量。 (3)功能界面快速自定义 功能界面快速经定义,将决定软件开发的效率。目前市面上的软件分为几种类型: (A)仅支持逐个字段定义:此类软件效率最低。 (B)通过导入现有EXCEL台账,快速定义字段:此类软件从当前EXCEL中,自动识别表列(即字段)、列表类型(文件、数值、日期等),再有管理人员快速调整列表类型、选择范围等,此类软件效率相较“逐个字段定义”类软件效率更高。 (C)通过将现有的模板(合同、申请单等)复制入系统,快速定义字段和界面:即可以将系统当前正在使用的合同模板复制给系统中,再由系统自动识别成表列、列表类型,再有管理人员快速调整列表类型、选择范围,设置完成后,软件即形成与线下模板近似的录入界面。此类软件效率和体验均高于前两种类型。 功能定义另一项考查的重要内容是,定义完成的表单,是否可再次进行组合,形成新的管理界面;主表、子表,是否可以相互独立、又可以再组合成新的管理界面。如果支持这一功能,相关数据具有更高的再利用能力,支持更复杂的应用。 界面的查询功能是否可经过简单配置形成快速查询功能;是否支持复杂的可进行与、或、括号条件组合的高级查询;是否可将查询条件保存成查询方案,方便后续再次使用。此项可减少查询功能的定义。 主子表录入,业务中主子表的情况比较大,比如入库单和入库明细、出库单出库明细、合同基本信息和合同约定产品明细;因此,支持主表信息可与多个不同明细信息的界面组合,在界面定义时,需要重点考查。 (4)数据字典支持 数据字段指,在录入时供选择的内容,该内容用于规范内容的输入,避免不同人员录入数据、不同功能模块相同列(字段)录入不一致问题。 数据字典功能,决定后续数据的规范性和工作量,举例来说:合同类型,如涉及在多个表中分别使用,如果能统一引用一个地方,在需求变化后,一次性可将全系统中涉及合同类型全部修正,则可以极大的提高效率,避免多处修改可能引起数据不一致的问题。因此,在建议选择有可一次性配置数据字典功能的系统。 数据字典功能在系统中一般表现为下拉单选、下拉多选、弹出界面选择(单位、多选、树列表选择、左树右列表选择)、下拉树(单选、多选)等。在数据选择时,建设考虑支持权限沿用能力的系统。 (5)跨业务和表单数据操作能力 跨业务和表单数据操作主要指:一个业务或表单的确认结果,驱动其它业务或表单的数据变化。举例来讲,产品入库单审核通过来,需要调整库存信息;产品出库后,也需求调整库存信息;采购需求审核通过后,需要生成采购计划;订单明细变更后,订单总额需要变更。 从以下来看,跨业务和表单数据操作能力是快速开发系统的核心能力之一,如果不能跨业务和报单更新其它业务和报单,则系统仅能管理非常简单的业务。 (6)审批和工作流功能 涉及业务,必然会涉及复核、审批,工作流功能是必然要考虑的功能。审批最简单的功能为提供审核按钮,第二人审核即可;复杂的业务涉及多人串行审核、并行审核等审核流程。如仅作为数据采集、收集,对工作流要求相对比较低。但涉及复杂审核、审批过程,则需求考虑复杂的流程。 在考查工作流时,需要同时考查“跨业务和表单数据操作能力”,即审批完成后,需要根据审批如果过表其它表结果数据。 (7)导入导出功能支持 导入导出功能将决定是否能快速接手现有业务。即如果已经有了台账数据(销售、出入库、合同、客户等)导入系统,能快速基于现有业务数据开展业务。毕竟从头开始录入数据,其工作量是任何公司不大可能接受的。同时,系统的内数据也可以导出来,用于企业其它应用。 导入功能重点要考虑是否支持增量导入、新增导入、更新导入、删除导入,以及指定导入关键字。支持对数据进行必须的有效性的验证,如特殊字符(空格、回车等)、主子表关联、父子级(如组织机构主下线)关联等关联关系。特别是否支持子表的导入。 (8)报表功能 报表功能往往决定系统实施的成败,这主要有两方面原因: (A)报表主要提供给领导使用,只有领导能看到的功能才是有价格的功能。如果领导看不到系统效果,即无法驱动普通员工使用系统。 (B)报表功能另一主要使用者为相关的业务、台账管理员,报表工作是他们日常最重要的工作,是他们最关心的工作,而系统的使用可能给普通员工带来更大的工作量,只有管理员的大力推动,才能引导普通员工日常化使用系统。 最理想的状态是,数据导入体系统后,经过简单配置,管理员和领导就可以看到原来类WORD报告、各种图形、图表。 根据已经了解现有市面上的系统报表功能有以下几种情况: (A)不支持报表输出,需要其它报表产品支持; (B)支持报表输出,但仅用于报表展示,不支持从报表穿透到明细表、再透穿查看详细信息。 (C)支持报表的展示和数据的穿透,即报表à明细列表à查看单项详细信息。具备这类能力的系统目前比较少。 (9)导出为WORD、PDF、EXCEL能力 日常应用中,数据、报表的交换大量使用WORD、PDF、EXCEL格式的数据,因此,顺畅使用系统,需要考虑这些系统是否支持将现有系统中的数据、界面、结果导出为WORD、PDF、EXCEL格式文件。目前大多数系统不支持该功能。 (10)文件附件功能 业务处理过程中,大量涉步及文件附件,如合同附件、原始出库单、原始入库单等,需处理业务里,需要收集和审核这些原始的证据,因此,系统需要提供文件附件上传、以及动附件文件进行整体管理功能。可涉及合同等应用,建议对相关功能进行考查。 (11)数据集成功能 数据集成功能是指,是否可通地数据库或web Service功能与现有系统集成,接替原有系统或与现有公司系统集成,进行数据共享、数据交互。这些集成包括: (A)与现有系统人力资源系统的单点登录集成。 (B)可通过数据库连接,对现有业务系统的数据进行操作,从而从其它系统获取数据,并将本系统数据提交给其它系统。 (C)通过企业数据总线ESB(一般为web Service接口),从而从其它系统获取数据,并将本系统数据提交给其它系统。 最理想的系统,应该可能通过简单配置,完成对接有系统的接管。 (12)定时调度任务 信息系统之所以能提供生产效率,一项重要的指定是否能自动进行数据的更新和生成。例如,员工年龄和工龄,应该每天晚上计划一次;报表可以定时自动重新生成。目前定时调度任务支持的系统相对比较少。 (13)预警提醒功能 信息系统避免人员遗忘工作,或者对数据存在的问题进行提醒,可以避免相关的业务风险,优秀的系统需要提供预警功能。预警包括:预警内容、预警条件、预警目标人员、预警方式(系统内消息、短信、邮件微信等),以及预警处理过程(验证、处置)等。 (14)日志功能 日志功能有利于追踪业务操作人员,避免操作风险。因些,选择系统时,尽快选择具备日志记录功能的系统。这些日志包括:系统日志、登录日志、业务操作日志等。系统日志包括:系统的启动、停止、报错;登录日志包括:登录人员、登录时间、错误信息(登录失败信息)、IP地址;业务操作日志包括:操作功能模块、操作时间、操作内容、错误信息、IP地址。 目前部分软件可以提供业务更新内容记录,例如:合同修改了合同开始和结束时间等。 (15)其它辅助功能 以上功能为主要考查的功能点,市场上软件还提供了其它功能,例如:身份证验证接口等,个人认为这些功能非常有价值,但目前大多数软件还未考虑到这个云面。 四、总结 根据本人试用和选型过程,个人认为当前市面上的快速开发软件还处于初级阶段,市面上软件供应商对于该类软件认识还不足,对企业应用需求认识严重不足,很难面对市场竞争。目前,个别软件具备开发复杂软件的能力,但仍存在不小缺陷。因此,选型时建议依据本人业务适当降低要求,解决过度问题,相对比较好选型一点。
关于帆软云上功能和本地化功能平衡考虑的建议
帆软系统中部分功能均要求使用云环境,这与报表软件和BI软件用户特性和市场特性相背离,建议慎种平衡考虑。 对于报表软件、BI软件实,相关功能集成了企业的大量数据,且为安全性等级要求非常高的数据和管理层决策信息,实际上这一产品已经成为企业信息安全极为关键的节点,风险集中节点,即一旦该节点暴发安全风险,将为企业带来严重影响。因此,一般该类系统均要求私有化部署,与外网进行隔离,如需访问需通过VPN或更严格的二次验证策略控制安全风险。 目前,帆软系统提供了性能分析工具、数知鸟、短信、插件在线升级等功能,均需要依赖云环境,这造成以下困境: 1、私有化部署,相关功能无法正常使用,或使用起来流程不畅。 2、如通过安全策略,允许应用服务器直接访问帆软服务器,内部安全要求不允许。 因此,建议帆软应慎设计纯基于云的功能,多站在企业安全角度定义产品,避免相关功能在企业中实际无法使用。
关于实现界面上下、左右多页页组合界面
当前界面组织比较单一,主要提供单页面,多页签面视图。决策报表中多页签显示效率低下。 在数据展示是,往往需要将多个数据界面组合进行使用。上主下多页签,左主右多页签;上主下多IFRAM,左主右多FRAM平铺的情况。 提供上主下多页签,左主右多页签;上主下多IFRAM,左主右多FRAM平铺的框加。 如下图: 通过选择上部某条,可在下面有多面签显示相关内容。同时,哪个页签激活,对应刷新哪个页签下页面。 下图为左主右多页签或多框架,即围绕主信息,可多页签显示相关信息,或从上往上平铺多个IFRAM框。
组织机构和员工设计和同步功能不支持扩展,以及不符合通常设计
用户信息中,员工编号所有企业管理中的关键信息,在帆软件没有该字段。同时,在数据同步时,无法按员工编号进行同步,导致出现脏数据,以及同步逻辑难实现。 同时,同步时,必须要求员工和组织机构建成一张表,是在强人所难。 希望达到: 1、企业组织机构和员工信息希望能扩展,自定义其它信息; 2、企业机构和员工可以分开同步,在同步过程中增加大量容错处理,如员工无组织机构,组织机构重复、员工重复等转换过程中通用错误处理。 3、员工信息中增加员工编号,可通过员工编号进行数据同步。 4、组织机构同步完成后,能检查出组织机构改名、组织机构注销、组织机构新增、组织机构改变上下级等情况。 5、员工信息同步后,能检查出员工离职、换岗等信息。 以上信息变化将引起统计、报表等业务变动为关键信息。
个人成就
内容被浏览83,182
加入社区5年353天
返回顶部