网络摘选:用友U9系统的8个关键问题

网络摘选

用友U9系统的8个关键问题

以下从基础系统、业务应用及实施风险三个方面对U9进行分析。期望能为客户选型提供基本面参考。

着重否定MS的产品,包括Windows OS、MS 数据库
一、      关于系统效率

* SQL Server vs Oracle

* Windows vs 小型机 SO

* MS SQL Server语句 vs ORACLE的迁移

*  Windows平台缺少高端存储设备,导致数据库吞吐量受制,数据库吞吐量上不去,性能就无从谈起。

*  数据库无法通过机器获得性能提升:Oracle RAC的网格计算群集,可以通过多台服务器来实现性能的提升。Server 2005(包括2008)只支持故障转移群集 。

*  大量核心的包括MRP等在内的计算都采用存储过程实现,给数据库服务器带来非常大的压力,对性能造成严重影响

*  系统在数据库中建立存储过程739个、函数136个,涉及大量的计算

*  技术架构基于.Net, 应用能力受限:由于U9整体技术架构基于.Net,那么其应用服务器绑定Windows平台。虽然说应用服务器可以通过集群的方式进行低成本扩展,但Windows所支持的NLS集群能力最大只能支持8节点,应用能力受限。
二、      关于系统安全

*  Windows平台漏洞较多 :平均每个月有5-10个关键补丁,不安装这些补丁将给系统带来极大的隐患,通常关键补丁都需要重启服务器。补丁的安装带来大量的维护工作,重启又给系统带来了中断。

*  明文传送业务数据,可轻易伪造、篡改数据,加密成本极高 :U9采用http协议来进行通讯,Http是采用明文来传送数据的,这样企业的业务数据就在互联网上明文传递,可轻易截获、伪造、篡改数据。采用VPN技术只能防范外部客户,但实际上一半以上的安全威胁都来自企业内部。如果要使用https加密,将极大的增加应用服务器负担,并浪费大量网络带宽,其加密成本极高。

*  仅支持传统密码方式,缺少安全认证手段 :

*  用户名密码是目前最为不可靠的一种方式,大量客户长期使用同一密码,密码也极为简单,导致极大安全隐患。

*  U9缺少密码策略,用户可以一直使用同一密码,同样带来安全隐患

*  U9甚至提供默认密码“123456”,这样管理员新增用户通常密码都是一样的,给他人可乘之机。

*  数据库连接串中明文保存数据库密码,不安全 ;

*  用户密码在数据库中存放,且加密算法采用存储过程和函数,未加密,很容易被破解。
三、      关于SOA(定位)

U9采用微软ESOI架构,未遵循业界通用标准,难以支撑企业信息化规划的长期扩展应用,SOA所倡导的开放性和兼容性只能成为纸上谈兵;

*  U9未遵循业界标准,采用了微软的ESOI (企业级面向服务的底层设施)架构。微软在企业应用方面走得很孤独:数据库、ERP产品、应用服务器、Web服务器都自行开发,自成体系,很难想象如此封闭的体系会成为主流SOA方案。U9是目前全球唯一一个基于ESOI的ERP产品,很有可能成为最后一个采用ESOI的ERP产品。

*  U9不支持主流ESB:U9的白皮书没有标明兼容IBM ESB或SAP EOA架构,金蝶已经推出了IBM ESB Adaptor,能充分兼容IBM ESB;

*  U9不支持集成异构工作流:从目前的UBF开发工具中来分析,其工作流不能发布成为WebService,这样其流程也就无法参与ESB中的流程编排。EAS6.0开始工作流可以支持发布为WebService;

*  U9没有发布公开业务服务:目前U9未公布任何业务服务,不知道是尚未开发还是根本不能发布为WebService。EAS封装了数十个常用的业务服务,并已经在万科、南京油运等众多项目中得到实际验证;

*  U9不支持跨平台、跨数据库应用:目前U9不支持Oracle、DB2等大型数据库的应用。
四、      关于多组织架构

ERP组织模型中每一种组织类型就是一种业务能力,定义出多少种组织类型,就意味着多少种不同的业务能力是在ERP中需要管理的。多组织主要是为了区分业务能力、业务边界和组织的角色和职责,每一种组织类型就意味着一种组织角色和职责,多种组织角色是彼此分离而又互相协同的过程。

U9对于多组织模型本身以及对多组织下的业务协同理解的还很不到位,虽然产品宣传噱头十足,整体大致一看还行,但仔细研究就能发现有很多致命硬伤。下面从多组织模型的定义、组织之间的隶属关系(汇总和汇报)、组织间基础数据的共享和控制、多组织协同模型这四个方面来了解U9多组织的先天不足;

*  U9多组织模型定义不清晰,业务应用基石不牢

例证1:U9将营运组织将采购组织与销售组织混为一体,缺乏清晰的角色和职责分离,不利于企业的内部风险管控;

  例证2:U9的所有业务组织都必须是行政组织,降低了组织模型的灵活性,业务的多维展现能力下降;

*  组织间的基础数据管理粗放,无法提供精细化管理

问题1:U9的基础数据共享方式只有两种,一种是全局共享,另外一种是分配; U9 V1.5的实际验证中,发现只能基于隶属关系进行分发,也就是只能对下级分发,不能实现非隶属关系的平行分发,这个对于后续的业务协同如何进行是个难题。

  问题2: U9的基础数据的下发参数控制中只控制了下级是否可修改,其他内容则没有涉及。

*  U9多组织的隔离边界十分明显,仍是以单体产品的思路来构架整个业务协同模型的,U9这种基于单组织的功能展现让管控和多组织业务协同成为了泡影。

例证:U9的所有功能操作都没有用户界面(UI级)的组织切换,只能进行系统级的切换,跟重新登录的效果差不多,这样就会中断所有操作,用户不能在同一个UI上对其他相关组织进行操作。用户需要对多个组织进行同一个功能操作的时候,就非常困难,需要频繁进行系统级的组织切换,重新打开相关用户界面UI,非常繁琐。

  无法在一个UI中设置物料、客商等主数据在多个组织中的属性,必须不停的系统级切换组织;

  无法在一个UI中设置多个组织的参数(除了公共参数),必须挨个切换组织去设置;

  无法在一个UI中设置多个营运组织的货源清单;

  无法在一个UI中设置多个营运组织的价目表;

l  ……
五、      关于生产计划业务

n  U9没有S&OP系统,产销难以协同,基于企业高层关注的中长期计划的制定、调整和执行监控难以得到保障;

n  规划中的多工厂计划存在缺陷,无法适用复杂的企业应用场景;(协同生产)

l  U9的多工厂计划,没有为参与计算的工厂提供计算序号,当两个工厂存在单向供需关系时,如果工厂的计算排序错误,需求工厂无法向供应工厂传递需求。

l  U9的多工厂计划,根本不能支持两个工厂存在双向供需关系的业务场景。而这种场景在企业中非常常见。

l  例:深圳工厂产品A的部件A1由广州工厂供应,广州工厂产品B的部件B1由深圳工厂供应,在U9中,运行MRP时,无论深圳工厂和广州工厂如何排序,总有一个工厂的产品的部件需求无法传递到另一个工厂。

n  计划逻辑有缺陷,极易导致供需不平衡;

l  U9的MRP逻辑不严密,进行MRP运算时,U9是根据指定的需求进行供需平衡。在两次MRP运算中,如果两次指定的需求范围不一样,第一次计算指定的需求所产生的供应,可能会被用于满足第二次计算指定的需求。

l  在实际使用中,计划员如果不知道这个逻辑缺陷,就一定会错误使用指定需求范围的功能,导致计算出错。计划员即使知道这个逻辑缺陷,也难以保证每次指定的需求范围都能准确包含上次计算的需求数据。

n  计划结果难评估,无法为计划员提供辅助决策信息;

l  MRP运算会产生大量数据,计划员需要从大量数据中获取到例外信息,从而快速调整计划数据。这些例外信息包括:建议开工日期早于当前日期、建议完工日期早于当前日期、建议完工日期晚于需求日期、建议推迟开工、建议取消订单、建议提前开工等等。

l  U9对MRP运算结果没有提供有价值的例外信息,重排建议只给出“确定”或“取消”的选择,重排建议没有给出说明原因,异常信息不丰富,仅将需重排的计划订单单独列出,计划员难以根据整个计划订单的情况决策重排建议。
六、      关于财务、供应链业务

整体一看模块差不多都有,但实际应用时发现功能缺失很厉害:

n  U9业务功能不完整:U9不支持发运管理业务;U9不支持三方、四方调拨业务 ;U9不支持分销直送业务;U9不支持供应商准入管理、 U9不支持网上报销…….

n  U9产品易用性差:

l  U9单据关联和钩稽不灵活:例如无法按客户要求灵活选择多张出货单开具发票;

l  U9不支持对库存事务类型和库存类型进行定义,只能按系统既定的事务类型和库存类型进行业务处理。不能满足客户个性化的操作习惯,不适应企业业务发展的扩展应用;

l  U9不支持退换货和退补货业务 :U9不支持退换货和退补货业务,只能通过关闭现有订单再下新订单的方式进行处理,不符合国内用户的常规操作习惯;

l  ……
七、      关于集团管控业务

中国制造企业的集团化发展是企业转型和突围的重要途径之一,人、财、物的管控是制造集团企业管控的重要内容,U9虽聚焦于制造业,但缺乏完整的制造集团管控功能:

n  没有“财”的管控:U9没有不支持资金管理、预算管理等集团化应用;

n  没有“人”的管控:U9除了简单的工资,基本上不支持完整的人力资源应用,无法提供统一的人力资源政策,无法提供选育用留的全过程管理,无法提供绩效考核管理等应用;

n  “物”的管控不完整: U9重点关注生产物料的管理,但不支持对集团资产进行统一的管理。
八、      关于项目实施风险

n  U9产品不成熟,实施交付难度大:目前U9存在多组织先天不足、集团管控模块缺失、生产制造不可用、财务供应链功能粗糙等问题,产品不成熟导致实施交付难度大。

n  U9实施周期长,预期效果落差大:产品不成熟,实施本身处于摸索中,实施周期长,实施效果和预期落差大。如摩比天线,实施一年来,目前只能满足财务供应链主要应用(一些具体应用尚无法处理),成本需要手工调整,制造只上到BOM,目前所完成的工作进度还没有达到标书的50%。

n  缺乏本地化实施能力,交付成本高:目前由于U9还没有实现能力从总部向机构的转移,除了财务核算部分,用友机构基本没有U9实施能力。U9项目都由总部直接支持,长周期的项目实施导致双方的实施成本都很高。一个分公司一个U9项目,将耗完用友U9整体资源。

n  缺乏样板客户,交付风险高:缺乏同行业、同模式、同业务样板客户成功应用,交付风险高。

n  系统成熟性对软件实施的影响如下表:

序号 比较项目 成熟系统 不成熟系统 相关影响
1 系统培训 *标准化的教材;*专业的有经验的教师;

*非常少的二次培训

*采用不完整、非标准化甚至是临时编制的培训教材*采用不专业的、甚至自己还没有对产品完全掌握的培训老师,导致对关键问题的解释摸棱两可,影响培训效率及学员积极性

*产品功能的频繁修改和纠错,导致大量重复的培训

*大量的重复培训

培训成本增加一倍以上
2 应用集成 数据导入工具、接口工具、集成方案等经过大量客户验证的,几乎不会有风险。  企业一般比较关注基本功能,而忽视如数据导入工具、接口工具等,往往在这些看似不重要的环节,出问题,又没精力顾及 导致项目无限期延长,至少使事实周期延长一倍,成本增加
3 客户化开发 有大量的开发案例参考,甚至许多开发可以直接使用,节省开发费用,缩短实施周期 任何细节都可能带来二次开发,不仅需要花费大量的资金,还使实施周期延长 实施周期至少一倍,成本增加,实施效果大打折扣
4 分析和报表 有完善的分析和报表 有功能,报表少,需要开发 延长实施周期和增加成本
5 实施周期 实施项目可控,周期短 项目风险大,实施队伍无休止地工作,大量异常情况出现 内部成本和外部顾问的成本都增加很多,
6 投资回报 平均1~1.5年 漫长的ERP投资回报期,平均3年
7
8 汇总 不成熟的系统,将使实施周期增加3倍以上,实施成本增加3~4倍

 

支付宝扫一扫赞助

微信钱包扫描赞助