网络摘选：用友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倍