U9系统的8个关键问题.doc

用友U9系统的8个关键问题 以下从基础系统、业务应用及实施风险三个方面对U9进行分析。期望能为客户选型提供基本面参考。 关于系统效率 数据库只支持SQL Server，数据库能力受限 SQL Server的数据库引擎能力远低于Oracle是业界共识 由于SQL Server只能运行在Windows平台，因此U9数据库服务器只能使用x86系列服务器，微型计算机的CPU的处理能力不如小型机这是必然 。 系统采用大量只支持MS SQL Server的语句，包括大量的存储过程、函数，长期考虑不可能支持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将营运组织将采购组织与销售组织混为一体，缺乏清晰的角色和职责分离，不利