U9系统的8个关键问题文档格式.docx

资源描述

U9系统的8个关键问题文档格式.docx

《U9系统的8个关键问题文档格式.docx》由会员分享，可在线阅读，更多相关《U9系统的8个关键问题文档格式.docx（10页珍藏版）》请在冰豆网上搜索。

U9系统的8个关键问题文档格式.docx

仅支持传统密码方式，缺少安全认证手段：

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

U9缺少密码策略，用户可以一直使用同一密码，同样带来安全隐患U9甚至提供默认密码“123456”，这样管理员新增用户通常密码都是一样的，给他人可乘之机。

数据库连接串中明文保存数据库密码，不安全；

用户密码在数据库中存放，且加密算法采用存储过程和函数，未加密，很容易被破解。

三、关于SOA

U9采用微软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整体资源。

缺乏样板客户，交付风险高：

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

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

序

号

比较项目

成熟系统

不成熟系统