Fans Or Not » Uncategorized

用友U8印象记

Zeeno — Tue, 05 Apr 2011 08:01:31 +0000

其实关于用友对ERP用户带来的影响，几个月前就想说一说了，但是一则篇幅很容易拉大，二则也缺少适合聊这一话题的对象和环境。我一直关注的领域是Oracle和SAP，对于国内的一线产品确实缺乏足够的关注，但是随着时间的流逝和国内产商（尤其是用友）经验和实力的增长，你已经无法忽视这一支曾经还只是口头上的“生力军”。现在的中国，如果你靠产品吃饭，那么你可以不必理会，但如果你同时对整个ERP行业保持兴趣，那就不得不把视线分一部分在用友上面。

曾几何时，当人们谈论某某公司准备实施ERP，但是软件选型为用友的时候，往往便有会心一笑的人。一直以来，用友给人的印象就是小，小到只有小企业才能使用。事实上，三年前的用友ERP确实如此，但是当U8第10版本推出的时候，这个局面将会被有利扭转。尤其当你同时发现用友的NC和U9两个产品线已经开始蚕食原本属于两大国际一线ERP厂商的阵地时，这个趋势已经更加明朗了。

对用友的印象通常是在U8上面，而对U8的印象则主要集中在以下几个方面：
1，账套。这个词几乎可以代表了U8的出身，也正是这个词导致其与Oracle/SAP等保持了足够让人移出视线范围的距离。对于重度U8用户，这个概念的个性化理解让任何ERP实施人员感到头疼。在很多场所，我发现一些人把账套当作了一堵墙，一个可以随意隔离的孤岛。
2，非常低的技术门槛和系统维护成本。老实说，如果你愿意，可以让任何人在任何场所使用U8，不需要一个专职的DBA，甚至可以不需要专职的系统管理员，如果愿意，一个账套主管可以搞定所有User和Administrator级别的问题。对于用户而言，唯一的操作就是处理各类单据，不需要考虑事务、并发、归档等问题。
3，廉价的客户支持。在接触到U8后，我才知道原来业务部门的使用者可以直接给用友支持提Ticket，甚至可以直接安排工程师上门服务，甚至，据说有的企业直接将数据库文件打包发给用户，让对方处理好数据后再发回来。这些情况，在任何使用Oracle或SAP的企业都是难以想象的。我的第一反应不是赞叹用友的支持效率之高，而是惊叹其服务成本之低。
4，归档。用友U8在第10版本之前都有一种非常有趣的方式来处理历史数据，那就是“年结”。U8的年结是任何其他产品所无法类比的，也是我所见过的最麻烦的年结。U8的一个账套对应于一个SQL Server中的Database，年结时需要将新数据复制到新创建的Database中。想想Outerbay等商业ILM解决方案吧，完全不在一个量级。我在这里不把Database翻译成数据库，因为每次我建议采用这个翻译的时候，总会有一些人出来教我数据库是什么，这或许也是SQL Server世界和Oracle世界的一个隔阂所在吧~

正如开端所言，关于用友可以说很多东西，但是在亲身感触过一段时间后，却发现没必要每样都说出来，对于很多东西，已经淡然了。比如数据集成、二次开发等，这些在U8的第9版本之前都非常糟糕。

我经常挂在口头的一句话是：如果一个企业未经历过大型信息系统的实施，那么这个企业的用户成熟度就非常低。大型信息系统指的是ERP系统，如果用友开始重视实施——而不仅仅是卖出产品——那么它也就真正培养起来了自己的用户，它自身也走向了成熟。ERP的趋势将是技术管理简单化，这一点SAP做的非常出色，Oracle则非常差劲，如果你读过《SAP德国造》，那么对这两个产品的差异就非常清楚了。

也许有一天，中国的ERP市场将成为用友和SAP的逐鹿之地，有可能吗？

关于Table API

Zeeno — Fri, 15 Oct 2010 01:13:19 +0000

在Oracle ERP二次开发领域，有一个非常重要的开发规范就是关于Table表数据操作的。一般而言，技术团队都会规定避免将数据操作sql直接写到逻辑层代码中，至少将具体的底表操作语句独立放到一个package里。EBS的开发规范中称之为Table Handler，就是在需要直接操作数据表的地方调用该Table Hander来执行DML动作。不管项目有多大，都应该遵循这个规范。

此次SQL Developer升级到3.0后，也增加了一个名为Table API的自动生成功能。

自动生成RECORD和Insert/Update/Delete Procedure：

PACKAGE test_tapi IS
  TYPE test_tapi_rec IS RECORD(
    content     test.content%TYPE,
    id          test.id%TYPE,
    upload_time test.upload_time%TYPE);
  TYPE test_tapi_tab IS TABLE OF test_tapi_rec;
  -- insert
  PROCEDURE ins(p_content     IN test.content%TYPE DEFAULT NULL,
                p_id          IN test.id%TYPE,
                p_upload_time IN test.upload_time%TYPE DEFAULT NULL);
  -- update
  PROCEDURE upd(p_content     IN test.content%TYPE DEFAULT NULL,
                p_id          IN test.id%TYPE,
                p_upload_time IN test.upload_time%TYPE DEFAULT NULL);
  -- delete
  PROCEDURE del(p_id IN test.id%TYPE);
END test_tapi;

这个自动生成的代码在二次开发时无法直接拿来用，缺少了异常处理(比如Update时没有对应的行时通常需要抛出NO_DATA_FOUND异常以供后续处理)和LOCK机制(这是由EBS应用程序开发框架所决定的)。

对于SQL Developer这种非专属IDE而言，增加这个功能或许会对很多新入行的人起到不小的指示和帮助作用。

迎接变化

Zeeno — Sun, 01 Aug 2010 11:18:03 +0000

最近工作和生活都发生了些变化，参加新的团队，实施新的项目，也可能要投入新的ERP阵营。在企业信息化的工作经历中，我乐意了解并接触不同的产品。就像博客，保持独立性是重要的，不要把人生绑在一张船票上，也不要把企业绑在一个软件厂商上。

由于目前还处于ERP系统选型阶段，所以一切未知，一切也不便多说，但是一些通用的，依旧存在于那里。在工作变换的简短假期中有所憧憬，也有所忧虑，对之前走过的路和将来要走的路都有一些不算深入的思考。一些经验和体会零零碎碎的，整理出了下面几点：

对待变化不忧虑，迎接它。
面对现实，不逃避。
预估风险，面对风险，承担风险。
质量往往和时间成正比。
关键部分坦然面对。
不捣浆糊，有帐迟早要还的。
学好一门语言，其他的，可以在用到时再学——你不是程序员。
了解一些技术，有助于深入吃透功能本身。
愿意花一部分工作时间在其他需要你的地方，尽管它不属于本职工作。
多读官方文档。
沉得下去，浮得上来。

纯属个人体会和感触，不具有任何其他意义。一旦选型结束，将重新投入到实施和技术分享中来，自然会忙，会觉得辛苦，但值得。

面对变化，迎接变化。

为什么Oracle 11g R2最低内存要求是1G?

Zeeno — Thu, 08 Apr 2010 11:50:37 +0000

Oracle公司最近采取了一些措施来保证只有真正的专家才能使用Oracle，这些措施包括：

Oracle 11g R2 的所需内存至少1G
磁盘空间至少要达到10G
一些额外的特性，比如ASM和Oracle Restart需要额外的1G内存

很多名不副实的所谓Oracle专家，他们的知识可能仅仅来源于个人电脑上的单用户的Oracle系统，很多人甚至没有接触过真正的上规模的企业环境。Oracle将会继续贯彻这种政策来减少越来越多的半吊子和没有资格认证的外行人士，以避免行业陷于低水平境地。

我的看法是，今后所有企业版所需内存至少2G，ASM之类则需要额外的1G内存，这样效果会更好一些。 Joke

(注：本消息可信度自行判断 )

寒碜的会议

Zeeno — Wed, 31 Mar 2010 01:58:09 +0000

昨日赴上海Oracle公司参加了一次所谓的“Oracle商务智能应用推广体验活动”，主题是亲身试用Oracle BI产品。我参加过多次Oracle主办的各类会议，比如OOW，但是这次的体验真当是首次。

会议9:15分开始，我从杭州出发，坐了最早一班的动车，大概9:30左右到达会议地点。这种时间安排本身，就带着一点点的莫名其妙，因为这貌似不欢迎上海以外的客户。然后有了如下一些体验：

会议室很小，或者说人数太多，竟然没有足够的位子。
于是去外面找椅子，是自己动身去找了并推过来的。
坐下来后，发现主持人没用话筒，声音很轻。
体验时，网速超慢，打开首页要4、5分钟。
所谓的午餐，就是盒饭，没有位子的人需要自己找地方，不过地方不够。

因为体验不佳，所以我直接走人。

印象中，所有Oracle相关会议都是在五星级饭店举行的，即便不是如此，至少也有足够的位子；如果要体验，至少有足够的网速；如果要吃饭，至少不用手捧着盒饭吃。这次的组织者，显然没有上心。不过这是不是也说明，其他的会议都是交给专门的公司安排的，这是专业性的体现啊。

当然，最主要的问题还是在于自己，没事瞎凑热闹。

UPK 3.6.1 更新

Zeeno — Tue, 23 Mar 2010 01:42:17 +0000

记得最初用UPK时，那时连安装都是件麻烦事，需要自行下载firebird，而且还是官方已经不再提供下载的旧版本。自3.5.x版本之后，UPK在功能上虽然变化不大，但是安装就比较轻松方便了。现在，UPK 3.6.1 已经可以提供下载了，这是UPK 3.6系列的最新版本，大的功能更新没有，但是对于UI设计上有了许多人性化的调整，也比较符合当前主流的操作习惯：

在新Tab中编辑主题
旧版本中，必须新开窗口打开主题编辑器，这种改进开始向主流靠近了。这令我想起GIMP，动不动就开N的窗口出来，整个布局看上去非常混乱。
新的音频编辑器
在主题中关闭bubble
bubble 是现在最流行的UI元素，就是那种吸引用户注意的泡泡一般的提示框。
可以发布为PowerPoint格式
自动保存和恢复
Package 编辑器加强
包中的文件双击后可以直接调用关联程序打开，也可以通过Open with… 菜单项打开。
See It! 窗口加强
现在可以在非全屏窗口中执行See It!模式了。
Firefox 加强
Firefox 中也可以正常使用Do It!模式和音频播放了。
支持 Safari
保持文档为 checked out 状态
在check in后，文档可以依旧保持checked out状态。
Tab页中的关闭按钮
这种细节应当已经是主流了，当初firefox 3.6官方提供该特性时，当即就卸载了一个tab addon。
Outline 编辑器加强

关于版本选择上，UPK有一个普通版和一个专业版。edelivery网站上下载时会看见一个Oracle User Productivity Kit 3.6.1 Development Tool for Microsoft Windows和Oracle User Productivity Kit Professional 6.3 for Microsoft Windows，这里不要被6.3这个版本号混淆，其实就是3.6.1专业版。

说实在话，从工具本身的使用体验来看，其实是很糟糕的，这种设计风格落后了不止一代。不过对EBS的支持倒是极佳，是视频教材录制的首选工具。

Ref: http://blogs.oracle.com/UPK/2010/03/upk_361.html

iTunes 上的Oracle Podcasts

Zeeno — Mon, 15 Mar 2010 00:43:04 +0000

如果你有iPhone，那就可以在手机上随时收看Oracle的学习视频。如果你没有iPhone，也可以通过iTunes在电脑上收看，或者在其他支持MP4的移动设备上收看。

iTunes 上有很多免费学习资料(视频广播)，有大学课程，有电视节目，很多公司都提供了自己录制的视频材料，比如Oracle。目前，Oracle 提供的podcasts包括以下内容：

Oracle Author Podcasts 一些技术专家的观点
Oracle Buzz 各类新闻、趋势和话题
Oracle Database PodCasts Oracle 数据库学习
Oracle Fusion Middleware Radio 中间件产品
Oracle Green Enterprise 帮助客户更好了解Oracle产品
Oracle Intellicasts 商务智能之类的企业管理优化话题
Oracle Keynotes 企业新闻，产品和服务升级等
Oracle Magazine Oracle 杂志的编辑、作者等的会话节目
Oracle Technology Network TechCasts 了解Oracle最近的技术研发相关信息
Oracle’s AppCast 了解客户如何使用Oracle应用产品，以及最新的产品特性
~~Oracle@Work~~ 三年不更新了，不看也罢

更多有用信息可以访问 http://blogs.oracle.com/databaseinsider/

用Mockups绘制原型图

Zeeno — Sat, 13 Mar 2010 08:38:09 +0000

每次项目实施时都会有大量的客户化功能，自然也有很多功能设计出炉。我一直认为合格的实施顾问是懂一点技术的，应当会用最趁手的工具来表达自己的意图。在功能设计中，如果已经有了特定的界面构思，则需要将界面示之于开发人员。

有些人喜欢在功能设计文档中描述功能主要逻辑，界面则另行以黑板或白纸绘画，和开发人员当面细述。此类顾问多数初出茅庐，往往在开发过程中乃至上线后，提供许多修改需求，甚至有些时候界面由开发人员根据功能意图自行设计。也有一些人会使用Visio等工具绘制界面，但是需要耗费较多时间，所以如果开发过程中需要调整界面时，文档通常就懒得更新了。待得数月后回头来对应功能和文档，已经面目全非了。

对于原型图，在经历中我也曾尝试过多种方式，最初是用Word自带图形工具，简单方便，但是没有控件模板，全部手绘。后来尝试Visio，界面倒是可以很精致了，有现成控件，但是颇费功夫，一旦绘制后调整起来比较麻烦。去年也尝试过用Excel来画界面，由于Form界面往往有棱有角，所以在表格中涂抹些颜色倒也似模似样。

我眼中的绘图工具应当具备以下几个特点：

适合推广，不能只是一个人用。
能够准确描述心中所想，有现成控件可用，如果什么都自己画，显然影响效率。
能够方便的调整界面。虽然只是原型图，但是有些时候，开发过程中针对特定界面快速调整结构也是有需求的。
上手容易。如果需要一个礼拜甚至一个月才能上手的工具，这适合专业工作者，不是用来打草稿的。
工具本身要足够轻便。
价格低，最好免费。

花了一段时间对比各种软件，针对工作特点，最后找到了Balsamiq Mockups。关于Mockups的介绍有很多，我最中意的一点是可以和Confluence、JIRA集成，并且画图非常迅捷，基本上两三分钟内就可以完整画出整幅图了。

国内的ERP实施顾问比不得国外，半路出家的多，技术功底不够扎实，所以很多新潮的工具，并不会推而广之。但是从团队建设角度而言，有一款大家都用的趁手工具还是很能提高协作效率的。当工作时间达到一定程度后，就会对各种工作中所需要的小工具有了更高的要求，比如文档模板、流程图、原型图、课件工具等。Mockups花费10分钟即可上手，将来有更好的工具时，放弃它也不会有什么遗憾。

之前我很少谈及Oracle之外的产品，今后或许会涉及一些，毕竟，这也是用于Oracle相关工作中，不是吗？

Ref: 10 Excellent Tools for Creating Web Design Wireframes

关于招聘ERP顾问

Zeeno — Fri, 05 Mar 2010 00:44:14 +0000

我其实并不喜欢这活儿，看看事儿还可以，看人就差远了。但是有时候却不得不看，尤其是你的团队需要增加人手的时候。

在Oracle ERP实施领域，我们习惯将人员分为两种，一种是提供软件或者实施服务的所谓“乙方”，一种是上ERP项目的所谓“甲方”。相对而言，甲方的实施顾问更像是培训专员和客服，甲方的技术顾问更像是乙方致仕还乡的小官儿，只在小地儿谈论小道。在整体平均薪资上来讲，甲方要逊上一筹，但也稳定轻松了些许，不需要整年里出差漂流外乡。

在招聘人手时，往往面临几个困境：

如果从乙方招聘，则薪资可能难以谈拢，但是水平有保证。当然，这也不是绝对的，我就见过很多例外。
如果从甲方招聘，则薪资或可谈拢，但是水平多数都是高估的。由于环境的因素，很多人往往得过且过，所以工作多年，却并不见得水平渐长的，多数人干的活只值2000块。
如果招聘新手，看着用功成本不高，但是培训也是件烦事儿，而且无法保证学成后跳往他方。

虽然自己就处在“甲方”，我却对甲方有点偏见。他们做开发却不懂数据库，设计功能却不了解系统功能和技术实现，全是些忽悠之辈。但是换个角度来讲，这却是在甲方的工作内容之一，尤其是在实业企业，技术是次要的，精通业务才是首要的，所以基础薄弱了些倒也无可厚非。

定位问题有时候是一个非常重要的问题。信息化绝对是一项与时俱进的工作，软件的升级换代非常迅速，如果因循固守，即便在企业里稳坐不动，但是对于个人而言，其知识也趋于淘汰之列。但是若过度跟进时势，却往往力有不逮，任何工作都是需要人力物力投入的，在一个注重投资回报率的时代里，企业不可能轻率地做出变更。这也是个人知识更新和企业信息化平稳升级的矛盾之一。基于这个考虑下，很多有心上进的人，便不乐意到这边来死守一方。

几年前注册orafans这个域名时，还有点念想，期望中国也能出现个地域性的Oracle ERP实施顾问的小圈子。后来渐渐发现，该圈子人员极少，而且从业人员往往半路出家专业功底不深，在现有的杭州地区从业人员来看，对技术兴趣缺乏，上进心极弱，这种大环境下，很难形成一种party似的氛围。

我觉得Oracle ERP从业人员至少应当具备以下几点：

了解系统技术架构，最好了解数据库和应用基本知识。不要求能自己做二次开发、性能调优，但是至少要知道想要的功能能够通过哪些方式去实现。
深入了解标准功能本身，不要一知半解。至少，要通读过所负责模块的官方文档。
有持续跟进、学习的兴趣，保持升级的冲动。随着ERP的推进，不论从规模上看，还是从功能上看，肯定会出现平台扩展和升级的需求。

在这个行业，找一可聊之人，难哪！也只在此牢骚几句而已。

不应因习惯而麻木

Zeeno — Thu, 25 Feb 2010 02:28:22 +0000

案例：ERP系统中项目数量非常多，在项目管理模块，有个WEB界面是用于调整任务信息的。克隆环境后，用户发现该功能的访问速度和正式环境有明显差异。经询问各方面人员（包括用户和实施顾问），都说没有做过任何特殊变动。

任何一名实施顾问，首要的经验就是要学会明确自己和普通用户的不同。一种业务，或者一个功能，绝对不能完全站在用户的立场来看待问题。如果用户说没有做过更改，那是从功能使用角度来讲的，作为系统和功能之间起到桥梁作用的ERP实施人员，还应当关注系统本身的变化。首先，克隆本身就是一种变化，比如硬件平台的变化、文件路径的变化、访问方式的变化，甚至系统参数（数据库或应用）也可能变化。任何一种变化，都可能导致用户体验的不同。一个新克隆的系统，第一次访问就发现速度变慢（或者变快），实施顾问应当事先就预料到各种可能的情况。从我的经验来看，没有做过变动的可能性非常小，那就通过一些简单的技术手段来找到这种变化。

先对该功能启用诊断后发现，有一段执行任务列表查询的SQL存在明显的性能问题。

克隆环境检查该SQL的执行计划：

SQL> set linesize 1000
SQL> set pagesize 1000
SQL> explain plan for SELECT *
  2    FROM (SELECT * FROM pa_task_progress_v) qrslt
  3   WHERE (task_manager_person_id = 126)
  4   ORDER BY project_name ASC,
  5            task_name    ASC
  6  ;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
| Id  | Operation                                    |  Name                         | Rows  | Bytes | Cost  |
----------------------------------------------------------------------------------------------------
……
|* 14 |               HASH JOIN                      |                               |     1 |   239 |  5274 |
|* 15 |                TABLE ACCESS BY INDEX ROWID   | PA_PROJ_ELEMENT_VERSIONS      |     2 |    86 |     3 |
|  16 |                 NESTED LOOPS                 |                               |   381 | 84201 |  5253 |
|* 17 |                  HASH JOIN                   |                               |   252 | 44856 |  4497 |
|* 18 |                   TABLE ACCESS BY INDEX ROWID| PA_PROJ_ELEMENTS              |   445 | 65860 |  4492 |
|* 19 |                    INDEX RANGE SCAN          | PA_PROJ_ELEMENTS_N1           | 81751 |       |   357 |
|* 20 |                   TABLE ACCESS FULL          | PA_TASK_TYPES                 |     9 |   270 |     4 |
|* 21 |                  INDEX RANGE SCAN            | PA_PROJ_ELEMENT_VERSIONS_N1   |     2 |       |     2 |
|* 22 |                TABLE ACCESS FULL             | PA_PROJ_ELEM_VER_STRUCTURE    |  1732 | 31176 |    20 |
|* 23 |               TABLE ACCESS BY INDEX ROWID    | PA_PROJ_ELEM_VER_SCHEDULE     |     1 |    34 |     2 |
|* 24 |                INDEX UNIQUE SCAN             | PA_PROJ_ELEM_VER_SCHEDULE_U2  |     1 |       |     1 |
……
----------------------------------------------------------------------------------------------------

再在正式环境中检查同一句SQL的执行计划：

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
| Id  | Operation                                 |  Name                         | Rows  | Bytes | Cost  |
----------------------------------------------------------------------------------------------------
……
|* 14 |               HASH JOIN                   |                               |     1 |   239 |  3793 |
|* 15 |                TABLE ACCESS BY INDEX ROWID| PA_PROJ_ELEMENT_VERSIONS      |     2 |    86 |     3 |
|  16 |                 NESTED LOOPS              |                               |   393 | 86853 |  3787 |
|* 17 |                  HASH JOIN                |                               |   253 | 45034 |  3028 |
|* 18 |                   TABLE ACCESS FULL       | PA_PROJ_ELEMENTS              |   446 | 66008 |  3025 |
|* 19 |                   TABLE ACCESS FULL       | PA_TASK_TYPES                 |     9 |   270 |     2 |
|* 20 |                  INDEX RANGE SCAN         | PA_PROJ_ELEMENT_VERSIONS_N1   |     2 |       |     2 |
|* 21 |                TABLE ACCESS FULL          | PA_PROJ_ELEM_VER_STRUCTURE    |  1883 | 33894 |     5 |
|* 22 |               TABLE ACCESS BY INDEX ROWID | PA_PROJ_ELEM_VER_SCHEDULE     |     1 |    35 |     2 |
|* 23 |                INDEX UNIQUE SCAN          | PA_PROJ_ELEM_VER_SCHEDULE_U2  |     1 |       |     1 |
……
----------------------------------------------------------------------------------------------------

从两者对比上看，可以发现正式环境中该SQL并没有用到PA_PROJ_ELEMENTS的索引，基本上可以确定两个环境同一个功能访问速度不同的原因。同样的语句，在克隆环境和正式环境中的执行计划不一样。两个环境分别重新收集统计信息后，依旧如此。

从用户角度看，问题出在系统方面；从实施顾问角度看，此类系统问题应当寻求技术人员尤其是DBA的帮助，为什么会出现这种差异。经过进一步的诊断，发现正式环境中 db_file_multiblock_read_count 参数被设置为100，而克隆环境中该参数被设置为8。在克隆环境中尝试调整该值，可以确定正是该参数导致了执行计划的不同。

这里不对db_file_multiblock_read_count做探讨，这应该交给专业的性能调优人员去分析。回到开始，我们在发现问题后询问各方人员，为什么都回答没有做任何特殊变动呢？这其实是个非常有趣的话题，我想，最大的问题还是出在“习惯”二字上面。做了几十上百次同样的操作，当某一天发现这种方式出现问题时，我们条件反射的把这种习惯性操作排除在外，而把问题原因归咎于某些未知的可能性上面。

一个有经验的实施人员，和一个没有经验的实施人员，其生产力差别可见一斑。