新版U9系统的8个关键问题

用友U9系统的8个关键问题以下从根底系统、业务应用及实施风险三个方面对U9进行分析。期望能为客户选型提供根本面参考。关于系统效率数据库只支持SQLServer，数据库能力受限SQLServer的数据库引擎能力远低于Oracle是业界共识由于SQLServer只能运行在Windows平台，因此U9数据库效劳器只能使用x86系列效劳器，微型计算机的CPU的处理能力不如小型机这是必然。系统采用大量只支持MSSQLServer的语句，包括大量的存储过程、函数，长期考虑不可能支持ORACLE数据库Windows平台缺少高端存储设备，导致数据库吞吐量受制，数据库吞吐量上不去，性能就无从谈起。数据库无法通过机器获得性能提升：OracleRAC的网格计算群集，可以通过多台效劳器来实现性能的提升。Server2023〔包括2023〕只支持故障转移群集。大量核心的包括MRP等在内的计算都采用存储过程实现，给数据库效劳器带来非常大的压力，对性能造成严重影响系统在数据库中建立存储过程739个，涉及大量的计算系统在数据库中建立函数136个，涉及大量的计算技术架构基于.Net，应用能力受限：由于U9整体技术架构基于.Net，那么其应用效劳器绑定Windows平台。虽然说应用效劳器可以通过集群的方式进行低本钱扩展，但Windows所支持的NLS集群能力最大只能支持8节点，应用能力受限。关于系统平安Windows平台漏洞较多：平均每个月有5-10个关键补丁，不安装这些补丁将给系统带来极大的隐患，通常关键补丁都需要重启效劳器。补丁的安装带来大量的维护工作，重启又给系统带来了中断。明文传送业务数据，可轻易伪造、篡改数据，加密本钱极高：U9采用http协议来进行通讯，Http是采用明文来传送数据的，这样企业的业务数据就在互联网上明文传递，可轻易截获、伪造、篡改数据。采用VPN技术只能防范外部客户，但实际上一半以上的平安威胁都来自企业内部。如果要使用https加密，将极大的增加应用效劳器负担，并浪费大量网络带宽，其加密本钱极高。仅支持传统密码方式，缺少平安认证手段：用户名密码是目前最为不可靠的一种方式，大量客户长期使用同一密码，密码也极为简单，导致极大平安隐患。U9缺少密码策略，用户可以一直使用同一密码，同样带来平安隐患U9甚至提供默认密码“123456〞，这样管理员新增用户通常密码都是一样的，给他人可乘之机。数据库连接串中明文保存数据库密码，不平安；用户密码在数据库中存放，且加密算法采用存储过程和函数，未加密，很容易被破解。关于SOAU9采用微软ESOI架构，未遵循业界通用标准，难以支撑企业信息化规划的长期扩展应用，SOA所倡导的开放性和兼容性只能成为纸上谈兵；U9未遵循业界标准，采用了微软的ESOI〔企业级面向效劳的底层设施〕架构。微软在企业应用方面走得很孤独：数据库、ERP产品、应用效劳器、Web效劳器都自行开发，自成体系，很难想象如此封闭的体系会成为主流SOA方案。U9是目前全球唯一一个基于ESOI的ERP产品，很有可能成为最后一个采用ESOI的ERP产品。U9不支持主流ESB：U9的白皮书没有标明兼容IBMESB或SAPEOA架构，金蝶已经推出了IBMESBAdaptor，能充分兼容IBMESB；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的根底数据共享方式只有两种，一种是全局共享，另外一种是分配；U9V1.5的实际验证中，发现只能基于隶属关系进行分发，也就是只能对下级分发，不能实现非隶属关系的平行分发，这个对于后续的业务协同如何进行是个难题。问题2：U9的根底数据的下发参数控制中只控制了下级是否可修改，其他内容那么没有涉及。U9多组织的隔离边界十清楚显，仍是以单体产品的思路来构架整个业务协同模型的，U9这种基于单组织的功能展现让管控和多组织业务协同成为了泡影。例证：U9的所有功能操作都没有用户界面〔UI级〕的组织切换，只能进行系统级的切换，跟重新登录的效果差不多，这样就会中断所有操作，用户不能在同一个UI上对其他相关组织进行操作。用户需要对多个组织进行同一个功能操作的时候，就非常困难，需要频繁进行系统级的组织切换，重新翻开相关用户界面UI，非常繁琐。无法在一个UI中设置物料、客商等主数据在多个组织中的属性，必须不停的系统级切换组织；无法在一个UI中设置多个组织的参数〔除了公共参数〕，必须挨个切换组织去设置；无法在一个UI中设置多个营运组织的货源清单；无法在一个UI中设置多个营运组织的价目表；……关于生产方案业务U9没有S&OP系统,产销难以协同，基于企业高层关注的中长期方案的制定、调整和执行监控难以得到保障；规划中的多工厂方案存在缺陷，无法适用复杂的企业应用场景；U9的多工厂方案，没有为参与计算的工厂提供计算序号，当两个工厂存在单向供需关系时，如果工厂的计算排序错误，需求工厂无法向供给工厂传递需求。U9的多工厂方案，根本不能支持两个工厂存在双向供需关系的业务场景。而这种场景在企业中非常常见。例：深圳工厂产品A的部件A1由广州工厂供给，广州工厂产品B的部件B1由深圳工厂供给，在U9中，运行MRP时，无论深圳工厂和广州工厂如何排序，总有一个工厂的产品的部件需求无法传递到另一个工厂。方案逻辑有缺陷，极易导致供需不平衡；U9的MRP逻辑不严密，进行MRP运算时，U9是根据指定的需求进行供需平衡。在两次MRP运算中，如果两次指定的需求范围不一样，第一次计算指定的需求所产生的供给，可能会被用于满足第二次计算指定的需求。在实际使用中，方案员如果不知道这个逻辑缺陷，就一定会错误使用指定需求范围的功能，导致计算出错。方案员即使知道这个逻辑缺陷，也难以保证每次指定的需求范围都能准确包含上次计算的需求数据。方案结果难评估，无法为方案员提供辅助决策信息；MRP运算会产生大量数据，方案员需要从大量数据中获取到例外信息，从而快速调整方案数据。这些例外信息包括：建议开工日期早于当前日期、建议完工日期早于当前日期、建议完工日期晚于需求日期、建议推迟开工、建议取消订单、建议提前开工等等。U9对MRP运算结果没有提供有价值的例外信息，重排建议只给出“确定〞或“取消〞的选择，重排建议没有给出说明原因，异常信息不丰富，仅将需重排的方案订单单独列出，方案员难以根据整个方案订单的情况决策重排建议。关于财务、供给链业务整体一看模块差不多都有，但实际应用时发现功能缺失很厉害：U9业务功能不完整：U9不支持发运管理业务；U9不支持三方、四方调拨业务；U9不支持分销直送业务；U9不支持供给商准入管理、U9不支持网上报销…….U9产品易用性差：U9单据关联和钩稽不灵巧：例如无法按客户要求灵巧选择多张出货单开具发票；U9不支持对库存事务类型和库存类型进行定义，只能按系统既定的事务类型和库存类型进行业务处理。不能满足客户个性化的操作习惯，不适应企业业务开展的扩展应用；U9不支持退换货和退补货业务：U9不支持退换货和退补货业务，只能通过关闭现有订单再下新订单的方式进行处理，不符合国内用户的常规操作习惯；……关于集团管控业务中国制造企业的集团化开展是企业转型和突围的重要途径之一，人、财、物的管控是制造集团企业管控的重要内容，U9虽聚焦于制造业，但缺乏完整的制造集团管控功能：没有“财〞的管控：U9没有不支持资金管理、预算管理等集团化应用；没有“人〞的管控：U9除了简单的工资，根本上不支持完整的人力资源应用，无法提供统一的人力资源政策，无法提供选育用留的全过程管理，无法提供绩效考核管理等应用；“物〞的管控不完整：U9重点关注生产物料的管理，但不支持对集团资产进行统一的管理。关于工程实施风险U9产品不成熟，实施交付难度大：目前U9存在多组织先天缺乏、集团管控模块缺失、生产制造不可用、财务供给链功能粗糙等问题，产品不成熟导致实施交付难度大。U9实施周期长，预期效果落差大：产品不成熟，实施本身处于摸索中，实施周期长，实施效果和预期落差大。如摩比天线，实施一年来，目前只能满足财务供给链主要应用〔一些具体应用尚无法处理〕，本钱需要手工调整，制造只上到BOM，目前所完成的工作进度还没有到达标书的50%。缺乏本地化实施能力，交付本钱高：目前由于U9还没有实现能力从总部向机构的转移，除了财务核算局部，用友机构根本没有U9实施能力。U9工程都由总部直接支持，长周期的工程实施导致双方的实施本钱都很高。一个分公司一个U9工程，将耗完用友U9整体资源。缺乏样板客户，交付风险高：缺乏同行业、同模式、同业务样板客户成功应用，交付风险高。系统成熟性对软件实施的影响如下表：序号比拟工程成熟系统不成熟系统相关影响1系统培训*标准化的教材；*专业的有经验的教师；*非常少的二次培训*采用不完整、非标准化甚至是临时编制的培训教材*采用不专业的、甚至自己还没有对产品完全掌握的培训老师，导致对关键问题的解释摸棱两可，影响培训效率及学员积极性*产品功能的频繁修改和纠错，导致大量重复的培训*大量的重复培训培训本钱增加一倍以上2应用集成数据导入工具、接口工具、集成方案等经过大量客户验证的，几乎不会有风险。企业一般比拟关注根本功能，而无视如数据导入工具、接口工具等，往往在这些看似不重要的环节，出问题，又没精力顾及导致工程无限期延长，至少使事实周期延长一倍，本钱增加3客户化开发有大量的开发案例参考，甚至许多开发可以直接使用，节省开发费用，缩短实施周期任何细节都可能带来二次开发，不仅需要花费大量的资金，还使实施周期延长实施周期至少一倍，本钱增加，实施效果大打折扣4分析和报表有完善的分析和报表有功能，报表少，需要开发延长实施周期和增加本钱5实施周期实施工程可控，周期短工程风险大，实施队伍无休止地工作，大量异常情况出现内部本钱和外部参谋的本钱都增加很多，6投资回报平均1~1.5年漫长的ERP投资回报期，平均3年78汇总不成熟的系统，将使实施周期增加3倍以上，实施本钱增加3~4倍关于B/S和C/S应该说，B/S和C/S各有千秋，都是当前非常重要的计算架构。在适用Internet、维护工作量等方面，B/S比C/S要强;对于以浏览为主、录入简单的应用程序，采用B/S技术有很大的优势；但在运行速度、数据平安、人机交互等方面，B/S不如C/S，当采用SmartClient客户端时，C/S模式的维护工作量得到大幅度减少，几乎与B/S相当；因此B/S与C/S具有不同的优势与特点，它们无法相互取代。对与ERP系统，涉及财务、供给链、生产制造等对运行速度、数据平安、人机交互要求非常高、甚至要求在网络环境不佳时能够本地临时存储的功能时，采用SmartClient的C/S模式比拟好，对于如CRM、BI、工作流、OA等维护工作量少，要求对人机交互、速度要求不是很高的情况下使用B/S比拟适宜；目前8个客户的应用情况目前共有三个客户在使用，其中：广东大冶摩托技术有限公司使用非常简单，还达不到U8的范围和深度摩比天线技术(深圳)有限公司，应用多组织，没有实施起来，客户很不满意苏州京东方茶谷电子有限公司，应用多组织，问题很多，两年发现2000多个BUG，平均每天都有3~4个错误出现。目前U9宣传的客户包括：广东大冶摩托技术有限公司，苏州京东方茶谷电子有限公司，摩比天线技术(深圳)有限公司，厦门恒耀金属有限公司，北京骏马诚信机械有限公司，大连新重集团，浙江康盛股份有限公司，江苏沃得集团等。

经了解，这些UF宣传所谓的“样板客户〞，绝大部份经过了长时间(近1年)的实施仍未完成，实施进度一再延迟，且在可预计的时间内看不到结束的希望。即使个别已局部上线客户，实际应用情况并不理想，这也印证了U9产品存在缺陷，靠市场虚假宣传欺骗客户的本质。广东大冶摩托技术有限公司大冶摩托的工程合同金额约250万，却达不到以前使用U8的状态。主要使用生产订单、生产领料、生产入库流程，MRP计算仅做参考，订单还是手工下达。大冶摩托没有使用多组织，目前使用最大并发50~60个，该客户没有用到多组织苏州京东方茶谷电子有限公司使用多组织，工厂协同，跨组织的订单变更没用，跨组织领料不能实现。并发数小于100个。该工程实施两年，发现2000多个BUG，该客户多组织应用不成功。摩比天线技术(深圳)有限公司1.摩比天线只用了跨组织和财务局部；其生产方案是二次开发的还在调试中，该工程只有80万，并发数40~50个，用友投入资源少，客户很不满意。2.供给链系统易用性差,需要大量的手工调整和修正，操作层对产品的适用性与灵巧性意见较大，经常需要加班加点；3.本钱系统没有当时介绍的强大和完善，本钱计算的设置复杂，且经常出错，目前根本靠手工调整；4.MRP只上到BOM层面，无法完整运行MRPII运算；5.工程设计与变更模块BUG过多，目前根本无法使用；6.与选型之时的期望值差距甚远，目前所完成的工作进度还没有到达标书的50%；7.双方的实施本钱都很高，企业方面投入了大量人力和时间，IT部门和各业务部门的信息化负责人时常加班加点，问题解决的速度和质量