手机软件MMI的自动化测试需要手机终端和计算机进行通讯，所以通讯方式可以选择串口或者蓝牙，鉴于稳定性和易用性，设计简单程度，串口通讯是非常简单的很容易实现的。

然后自动化测试工具选择脚本语言的问题，我们可以选择VBScript，Perl，Python，比较一下，Python比较强大，Nokia的一些工具就是python做脚本的。

两者之间的通信机制：可以使用ATcommand进行通信，出了GSM标准支持的ATC，还要有手机专门自己的命令来支持远程终端操控手机。比如键盘控制，长按短按等。

手机需要暴露一些接口，比如截图，文字识别，返回图像，文字等。这样可以做自动化验证，做到无人值守。这些均需要手机来支持。比如设计手机要有这样的接口 BOOL GetPicture(int top, int bottom, int right, int left, BITMAP & bitmap); 这样通过ATC发过来命令然后手机解析一下，得到top，bottom等信息，然后得到bitmap返回。文字识别需要python来完成，char* GetStringFromPic(Point pt, const Bitmap* bitmap); 我就用C++来表示了。这样在脚本里面就可以进行比较文字了。

更进一步，支持录制脚本功能，比如按下某个键，串口信息，监听串口信息，这样脚本解析按下的键，然后判断在转译成脚本语言。Key（）；

关于手机只需要支持识别ATC参数，然后传回要的结果，我想主要是通过图片来返回，因为这是模拟人工测试的原理，我按下某个键，就会出现什么结果，这样需要返回图片即可，然后脚本客户端需要对图片进行处理，要么进行比较图片内容，要么进行文字识别进行文字对比，这样可以实现测试自动化。

前文已经把大致的手机需要提供的接口说了一下，再次总结一下：

1.需要手机支持GSM07.07中规定（Optional）的键盘控制的命令at+ckpd
2.需要手机支持一些特殊的ATC，比如传回手机当前图片，以便作比较。
3.自动化测试的目的：能够替代人工实现大量手工难以完成的工作，重复性较强的工作，比如一些压力测试，存五百条通讯录等，删除等，考验手机内存释放时是否有内存泄露等等。二是能够完成大量的回归测试，易于维护等特点。

思路：

选择脚本语言：由于python使用很灵活而且具有强大的文本处理能力，且易于学习等特点，可以选用python作为脚本语言和实现语言。

方式：

比如定义def CCKEY（）来完成发送CCKEY，也可以通过一个map文件来实现CCKEY--at+ckpd="c"这种方式，然后用户这边只是用譬如以下的命令：

CenterKey()
Key("#", 2)
LongPress("#")
PressKey("0")
LSK()
RSK()
NaviUp()
NaviDown()

　　再加上python的控制流程，异常处理等，可以编出强大的易于维护的脚本来。

　　手机方面的接口可以是GetImage（），然后通过脚本进行处理，这个可能需要很大的工作量，因为要么重新研究图像识别对比，文字识别等技术，要么购买组件等，即验证这一关也很难实现。

　　在初期可以考虑人工来验证一些结果，比如图片对比结果，可以使用一些技术，比如蒙板等，得到一些异状图片，用户自己审阅一下，加入明显的由异样，就Fail，这样就不能自动，可以说是半自动化了。 

一、 lost+found目录简介
在软件配置管理工具 Rational ClearCase中，当你创建一个VOB库后，将自动产生一个目录：lost+found,这个目录主要存放不再包含在VOB中任何一个目录版本中的元素（在ClearCase中，元素包括文件和目录），这句话听起来有些拗口，呵呵。简单来说，lost+found目录类似于Windows的回收站，所不同的是：在windows中进行删除操作后，文件将被放入回收站；而在ClearCase中，当一个元素在VOB中与其他元素的依赖关系被全部删除时，它才会被放入lost+found目录。

二、什么情况下 ClearCase的元素会被放入lost+found目录
当你做如下操作的时候， VOB中的元素将被放入lost+found目录：

1. 使用 rmname删除一个元素与其他元素的最后一个依赖关系

Rename命令不会删除VOB中的元素，只会把该元素与父文件夹之间的关系删除。如果一个元素与其他元素的关系全部被renamed,没有路径能访问到该元素，这时这个元素将被自动放入lost+found目录中。如果这个元素是目录时，那么 它里面包含的子目录与文件都会被放入 lost+found目录。

2. 使用 rmver、 rmbranch 或rmelem删除一个目录版本最后一个依赖关系

在 Rational ClearCase 中，目录也做为配置项管理，如果你把目录删除了，其下的子目录与文件就会没有正确的链接，这时这些子目录与文件会放到 lost+found 中。如果你确实不需要，可以在 lost+found 目录对它们进行彻底清除。反之可以恢复，以避免误操作带来的损失。

3. 当一个目录处于 checkout状态时，如果在该目录中创建新元素，然后又将处于checkout状态的这个目录进行了 undo checkout操作，这种情况下你新建的那个元素将被放入lost+found目录，因为它已经找不到对应关系了。

三、 lost+found中元素的命名规则
当一个元素被放入 lost+found目录后，我们会看到它的名字很长，好像很乱，其实ClearCase对它有一套统一的命名规则。当元素被放入lost+found目录后，名字将增加一个OID(Objedct ID)，格式为：element_leaf_name.id_number。

举个例子：

文件放入 lost+found前的名称：build.log；

文件放入 lost+found后的名称：build.log.3e105a5cad674d0db12ad477fd11026c；

它的 element_leaf_name为build.log，3e105a5cad674d0db12ad477fd11026c是id_number。
四、 lost+found目录的特点
lost+found目录有几个独有的特性：

1. lost+found目录本身不能进行checkout操作。

2. 该目录里面的内容可以进行修改，即进行检入、检出操作。

3. 在 lost+found目录上无法创建分支，但是目录里面的内容可以创建。

五、 lost+found中元素的处理方法
一个有经验的配置管理人员不应该把文件移到 lost+found中，而应定期把文件归回原位或者清除lost+found文件夹中不再使用的文件。

为了节约空间，定期清理 lost+found目录的方法是必要的，方法如下：

1. 如果 lost+found目录中的内容仍然有用，可以将其移出并恢复：

• 将 lost+found中的内容移动到本VOB库中，使用命令：cleartool mv；

• 将 lost+found中的内容移动到其他VOB库中，使用命令：cleartool relocate;

误删除了元素后，不要着急，看看能否在 lost+found目录中找到并恢复它。如果被彻底删除，再通过备份的VOB库来恢复也不迟。

2. 使用 cleartool rmelem 命令将不再使用的元素删除；

如果 lost+found中的内容确实不再需要，可以使用rmelem彻底清除，以节约VOB的空间，就像你经常整理Windows的回收站一样。 需要强调的是，使用 rmelem 命令前一定要慎重，因为该命令将永久删除元素。

六、总结
平时大家在工作中可能不太关注 lost+found目录，其实它在文件恢复、节约工作空间方面都有不少的价值，希望本文能对你有所启示和帮助。 

用一个账户可以在两个域都能登陆，具体实现：

目的：用AGDLP来实现访问其它域的文件服务器。

AGDLP意思是:A( 帐户)，加入G（全局组），再加到对方域的DL（域本地组），分配P（权限）。
存在3台机器，一台DC(a.com)，一台DC(b.com)，一台加入域的客户端(bb.b.com)。
即能用b.com的用户访问a.com的共享文件。

1、先在各自域建立组和用户：
在a.com建立DL组；
在b.com建立G组及c用户。

2、把用户c加入全局组G，即实现了AG！

3、用于分配P（权限）。那先在a.com上建立服务器，并为DL组赋与访问权，实现了DLP！

4、为了验证结果，还在share里面建立了一文本，b.com上的用户c能过来访问，即实现了AGDLP！

5、AG做了，DLP也做了。还有最重要的一步没做，就是把b.com上的全局组G加入到a.com上的域本地组DL，这也是最重要的一步。要在一个域里加其它域里的对象，那么域之间必须存在信任关系。
下面就实现如何在两域之间建立信任关系，建立信任关系前提，必须能相互解释，那么在DNS上设置转发器即可。

6、确定相互解释成功；
接差下来就是提升域和林的功能级别，以实现2003上更多的功能；
下面终于可以建立信任关系啦；
设置信任类型，信任方向。做的是双向，说明两个域之间的资源都可相互访问；
身份验证；
信任密码，用于确认信任关系；
信任完毕；
是否传出信任，传入信任。我这里没有设置，等建立完后再验证；
信任完毕，b.com做同样操作；
建完信任关系后，可手工验证信任关系。

7、现在可以实现把b.com的全局组G加到nwtrader的域本地组DL，那么AGDLP的全过程就实现了。下面看如何把b.com的全局组G加到a.com的域本地组DL。由于成功的信任关系存在，所以在a.com这个域能看到b.com。

8、以上，AGDLP for服务器的实现操作结束。

回顾一下，我们做了在b.com上把用户c加到全局组，再把b.com的全局组加到a.com的域本地组，再为域本地组分配权限。
剩下的就是验证结果。
在b.com上设置了NAT，只是为了验证一下客户端能否访问服务器。
在bb.b.com上用c登录。 

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

☆ 软件未达到客户需求的功能和性能；

☆ 软件超出客户需求的范围；

☆ 软件出现客户需求不能容忍的错误；

☆ 软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

☆ 测试是不完全的（测试不完全）

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

☆ 测试具有免疫性（软件缺陷免疫性）

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

☆ 测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

☆ 80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

☆ 为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

☆ 缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

☆ 软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

☆ 软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：
软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。 

目前大部分的系统，在功能的结构设计上都是采用三层架构。ClearQue三t也不例外，它就是按照标准的三层结构设计的：数据层、业务层和表示层。我们具体可以从这三个层来理解：

 

一、数据层

我们无法否认数据在一套系统中的重要性，而ClearQuest的根本所在也是在于数据，它将所有的数据都存储在数据库中（SQL Server、DB2、Oracle等）。

在使用以上数据库的时候，需要特别注意的是数据库管理员和使用者的权限设定，因此在做CQ系统之前，就必须建立相对应的数据库，并建立相对应的角色。

CQ的数据库分为两种，一种是通过Maintenance Tool中Schema Repository使用的数据库（我称之为主数据库master)；另外一种是Desiger中Schema使用的数据库（我称之为产品库product和测试库test）。

1、主数据库

如果原先没有master，在Maintenance Tool中通过Create建立Schema Repository和主数据库的连接，Schema Repository内容储存在主数据库中。

如果原先存在master，在Maintenance Tool中通过New Connection建立Schema Repository和原有主数据库的联系，原有主数据库内容不变。

这个master存储了Schema Repository的信息以及User Adminitrator中的Group和User信息。

只要我不删除master，就可以通过New Connectio连接回来到Maintenance Tool。

2、产品库和测试库

这两个库包含了相关的Schema的对应信息，包括Schema本身的各种信息、用户通过客户端录入的变更信息（Defect、Email_Rule、Project等）、操作此Schema的Groups和Users信息。

 

二、功能层

在CQ系统中，所有的功能都是在底层实现的。主要通过Maintenance Tool和Designer以及一个附属可扩展配置的Web服务器来实现。

1、Desinger

Desinger（安装目录中的cqdesign.exe）是设计Schema使用的。

在进入Desinger的时候，如果Maintenance Tool中有多个Schema Repository，必须选择一个Schema Repository才能进入Desinger，此时在Desinger中设计的所有Schema都附属于此登陆的Schema Repository，并且所有Schema信息都储存于对应的主数据库中。

Designer中的Schema是可以独立存在的，不一定非要连接产品库和测试库，因为Schema的信息存储在主数据库中。不过如果想在客户端或Web端使用Schema及其相关内容，则必须建立和Schema相对应的产品库和测试库。

Schema连接的数据库分为两种:Production Database和Test Database。

Production Database是实际使用的数据库。只有存在Production Database的时候，才可以在实际使用客户端访问的过程中看到相应的Schema。

Test Database是为Schema设计的时候使用的，设计好后，如果建立了Schema对应的Test Database，则可以选择菜单中的File->Test Work调用客户端查看Schema设计的结果，此过程可以反复进行，相当于调试的过程。

 

2、Web服务器

如果想在Web端使用CQ，就必须配置Web服务器。

 

三、表示层

CQ可以使用两种方式访问：客户端访问或者通过Web端browser访问。

1、客户端访问

客户端（安装目录中clearquest.exe）是实际进行变更流程操作的CQ访问程序。在客户端，可以建立Query、Chart、Report查看提交的记录。而在使用Report的时候，必须有相对应的水晶报表来实现。

2、Web端访问

如果想Web端访问，则必须配置Web服务器。目前公司所使用的CQ版本是2003.06.15，支持的浏览器是IE5.01—6.0和Netscape4.72—4.77，因此不建议使用IE7或其他独立的浏览器。

 

四、后台数据库

从CQ的三层体系，我们可以认为它之所以那么强大就在于其提供的快速二次开发能力。从表单设计，到基于状态转换的流程机制，到数据项的分角色和用户组授权，到灵活的自定义查询和自定义报表，同时支持多数据库等。整一个设计良好的快速开发平台，虽然没有很好的体现了面向对象的一些特征，但绝对是一个可以快速上手的一个平台。要更好地开发应用CQ就必须弄清楚它的数据库设计（以下内容建立在SQL Server之上）。

通过Maintenance Tool创建一个Schema Repository。这个就是后期CQ设计和正式使用要用到的数据库，创建完成后后会自动生成很多数据库表。从大的类型分为数据对象相关，状态相关，权限相关，查询相关几大类表。后续的表单设计完全以数据实体对象为基础的。例如表m_formdef一般会关联到表m_entitydef。

状态转换矩阵是CQ系统的一个重点内容，主要实现了系统表单的流程处理和权限控制，这个CQ设计的相当简单而且易用。首先是表m_statedef定义一个数据实体对象可以有哪些状态，每个状态的名称和缺省触发的活动。另外一个重点就是状态转换矩阵，状态转换矩阵的重点就在当前的某一个状态下执行某个活动可以转到另一个什么样的目标状态，因此这里面包括了源状态，执行活动，目标状态三个重要内容。这里的数据处理为：

1、定义一个数据对象状态：存储到m_statedef表；

2、定义一个数据对象活动：存储到m_actiondef表；

3、定义一个状态下可以执行哪些Action，存储到m_state_legal_action；

4、配置状态转换矩阵：存储到m_actiondef表。

 

有了这个数据后，后续动作根据以上数据进行分析处理：

1、到了某个状态后我能够执行哪些Action(m_state_legal_action)；

2、我执行Action后转到哪个状态(m_actiondef)；

3、当前状态下每个字段的可用情况(m_field_status_def)；

4、当前活动权限控制(m_actiondef_usergroups)。

常规的快速开发平台对象建模中提交到过对象和对象之间既可以是关联关系，也可以是依赖和引用关系。通过关联多个子对象可以形成一个完整的主对象，如订单对象和定单明细对象间应该是关联关系，共同构成完整的订单对象。这点在CQ中暂时没有发现体现的地方，也许是我没有找到。另外状态转换机制虽然易用，但于标准的工作流功能相比仍然欠缺很多内容。

 

五、总结

本文只是基本分析清楚了CQ系统所建立平台的一些内容，从它的层次结构、数据库建立和流程管理进行了阐述。当然，仅仅以上所描述的，并不能很好地扩展和完善对CQ平台的理解和认识，也无法对这样类似的快速开发平台又完整而清晰的处理思路。因此还要对表单建立、业务建立和权限建立进行深入了解。 

   ERP这个已不新鲜的词汇，无疑已经成为中国企业、尤其是制造企业信息化的焦点。但到底ERP为企业带来了什么？企业中不同角色的员工又因ERP而得到哪些收获？笔者做了总结，与同仁一同分享。

ERP为企业老板带来什么？
　　1. 随时可以由系统中的资料掌握公司的营运状况；
　　2. 建立公司的管理体系及运作规范，由系统管理公司运作；
　　3. 建立公司营运的数据库，累积公司的管理经验知识，不会因人员异动而流失；
　　4. 由系统信息的整合，可以提升公司的反应速度，不需由人力统计，可减少错误，节省人力；
　　5. 由系统提供的大量运算功能，可以加强公司的生产弹性，提高接单能力；
　　6. 系统可以整合各单位的资料，可以随时结算，了解公司目前营运成本；
　　7. 系统符合财税法规，可能达成内稽内控的目标；
　　8. 系统符合上市上柜的规范，可以协助公司上市上柜作业；
　　9. 系统可以反映各项异常状况，且提供相关资料，方便解决问题；
　　10. 系统可以提供电子签核及工作流程之功能，可达成无纸化目标；
　　11. 系统可以远程联线操作查询，方便跨国管理，不受地区限制；
　　12. 系统可以作资金的管理，提高资金运作的效益。

ERP为部门经理带来什么？
　　1. 随时查询公司所有原物料采购单价波动情况，并依据市场行情做出应对；
　　2. 可对供货商在某个时段的采购总金额进行分析，根据有效的数字金额同大宗原物料供货商协商折扣事宜；
　　3. 销售部分，可按照一定时间内的销售金额，对客户进行划分. 确定A级客户.；
　　4. 对客户订单进行分析，针对出货商品的订单量做出趋势图。可重点管控，对其成本分析，并尽可能降低其销货成本，从而增加利润.并可对商品销售作出预测；
　　5. 对库存异常及存货呆料情况进行分析，制定相应处理规划，并将信息反馈至各相关部门. 从而使库存最优化；
　　6. 对项目部分可做到项目稽控，对其项目损益做出分析，评估其可行性；
　　7. 对全年费用部分可进行预算，并与实际发生相比较，对差异部分进行分析，制定相应策略；
　　8. 可对采购单价进行电子签核管控，使采购人员在下采购订单时必须使用主管签核的采购单价；
　　9. 针对应收帐款部分，系统以帐龄的长短体现，可实时迅速了解应收帐款的情况，进行追踪；
　　10. 对业务人员的销售业绩进行统计分析，制定相应奖惩机制。更大限度的调动员工积极性，为公司创造更大的效益；
　　11 对生产过程中发生的报废情况及时了解，对报废出现异常的工单进行分析，制定相应策略；
　　12. 对经营能力，财务结构，获利能力进行分析，针对各个异常系数部分分析；
　　13. 在运用工作流消息管理过程中，及时迅速了解采购订单延迟，销货订单延迟情况，对异常部分作出相应调整。

ERP为物料控制﹑生产主管带来了什么？
　　1. 可及时掌握销售订单订购量﹑出货量﹑未交量及客户需求日期；
　　2. 可随时掌控材料的采购到货状况；
　　3. 可随时掌握材料产品库存状况﹑及时作出生产，出货安排；
　　4. 对客户需求进行交期预测分析和用料分析，从而确定产能﹑材料能否达成客户的需求﹑快速反馈信息给业务；
　　5. 通过产品主计划，可一次将成品﹑半成品工令开单，减少工作量；
　　6. 物料需求可将生产当前产品所需材料的库存﹑已分配﹑在途数量及预计库存﹑缺料数一一列出，由物控查核，并可直接将其转入采购系统，产生采购订单；
　　7. 开立制令单的同时，可知晓每种材料的库存﹑已分配及可领料数量；
　　8. 可设定派工单完工计划，并可通过“订单生产排程”查询计划完状况，从而进行生产调控；
　　9. 加工中心生产排程，可随时掌控各种资源的超短荷情况，从而做出相应的调配；
　　10. 加工中心绩效分析，可了解加工中心的实际耗用工时及生产效率﹑良品率﹑不良品率等；
　　11. 产品主计划进度追踪表，可按销售订单查询到生产安排情况﹑已领料套数﹑未领料套数及入库数量；
　　12. 制令单进度和订单进度随时反映；
　　13. 生产线在制品移转管制及每站投入﹑产出﹑在制分析；
　　14. 移转入库超量控制及入库时间管制；
　　15. 逾期未完工制令单资料追踪表，可及时对逾期制令单作出处理；
　　16. 超领料限制及补料程序管制。

ERP为品管带来什么？
　　1. 使用品管作业使整个运作流程，更合理化﹑完整化；
　　2. 对于进料方面的记录更加完整化，便于追溯﹑分析及后续的改善；
　　3. 能够对于整个生产过程进行详细的记录，以便于后续的分析及改善；
　　4. 能够统一分析供货商为我们提供料件的好与坏，以便于作业相应的调整；
　　5. 能够集中分析公司内部所生产的产品需要进行解决的环节；
　　6. 能够取消大量的手工检验报告，提高效率，减少不必要的人为错误；
　　7. 多个环节的品管作业，能够对产品进行多重认证，减少后续不必要的重复作业。

ERP为会计带来什么？
　　1. 每月的各项财务报表及时结出：如财务人员每月提供的资产负债表﹑月损益表等。系统作业财务人员不必再为了借贷不平而去费力检查；
　　2. 往来明细帐管理一目了然:作为工厂不管多少往来客户均可由系统管理，随时都能掌握其应收未收﹑应付未付的金额。财务人员也不必为了总帐和明细帐不平而烦恼；
　　3. 在资金流的掌握及调配：能及时查询工厂资金占用﹑结余情况，并进行资金预测，提供给领导资金运作的合理方案；
　　4. 各部门在系统作业上环环相扣，最终的单据由财务人员审核记帐，方便工厂内部管理的内部监督﹑内部控制；
　　5. 成本结算轻松完成。每月系统交易正常，单据完整，成本计算轻松结出；
　　6. 财务人员结帐时有个特点：前松后紧，即月初时没事，月末没有时间。而系统作业注重于日常作业的及时录入和单据正确性的检查，只要平时资料入正确，月末由系统计算各项报表资料，有利于企业人力资源的合理使用；
　　7. 系统作业不光是提供当月的报表资料，更能提供不同月份之间资料的比较，以利于各项财务资料分析；
　　8. 预算功能的使用，提供预算和实际之间的分析；
　　9. 提供多角度的分析统计的功能：如销售额(采购额)按客户统计﹑按客户分类统计﹑按业务员统计﹑按存货统计﹑按存货分类统计等；
　　10. 对于两岸三地的作业工厂来说，数据库之间的资料互转，业务之间的往来﹑财务帐合并等需求本系统提供了最方便快捷的方法。

ERP为市场业务人员带来了什么？
　　1. 提供完整的客户基本资料文件，记录客户的各种详细信息及与客户的相关交易条件，方便日后的资料查询；
　　2. 可以方便快捷的录入销售订单，掌控客人的受订量，随时提供接单日报表；
　　3. 已出货部分系统自动扣帐，实时提供未交订单明细，方便与客人核对P/O残；
　　4. 提供订单在线生产状况分析，可以准确了解当前的生产状况，快速回复客人交期；
　　5. 提供核准单价管理，提供交易历史单价查询，可以了解单价的异动状况；
　　6. 提供订单预测用量分析表，可以对客人的Forecast部分进行物料需求的运算，提前备料；
　　7. 可以随时提供已出货部分的出货对帐明细表，方便与客人对帐；
　　8. 提供受信额度管控，可以保证资金回笼的及时性，减少公司呆帐的发生，降低公司的经营风险；
　　9. 提供本公司料号与客人料号的对照表，可以直接以客人料号进行订单处理﹑出货单打印﹑查询管理等，大大提高了作业效率；
　　10. 提供订单版本控管，可以根据版次的变更追溯客人的订单修改内容及原始订单信息；
　　11. 可按期间﹑存货﹑客户提供销售趋势分析报表，了解销售趋势﹑市场走向，为未来的生产﹑销售计划提供第一手资料；
　　12. 对于外销部分可以根据出货单自动提供Invoice和Packing list，能够满足外销客户之需求，而不需重复作业；
　　13. 真正做到了资源共享，只要有权限，进入系统一查，客户的订﹑出货所有相关信息一目了然，不会因负责某一客户的业员人员不在而其它人便不了解状况，无法及时回复﹑处理客户问题。

ERP为生产工艺带来了什么？
　　1. 可以对同一产品设计多个BOM版本；
　　2. 可以用产品结构相近的BOM直接进行复制，减少输入；
　　3. 通过BOM结构树可以清晰打印产品的多阶关系；
　　4. 可以进行不同产品之间的BOM结构比较；
　　5. 可以维护材料的替代关系；
　　6. 可以一次进行多个产品BOM的变更；
　　7. 可以维护主产品的联副产品资料；
　　8. 同一产品可以维护多条加工工艺；
　　9. 可以对各类资源及个别资源进行维护；
　　10. 可以随时进行各类资源的生产能力调整。

ERP为仓库管理带来了什么？
　　1. 快速查询到仓库库存及相关料况如该材料的在途，已分配，已请购等数量更为全面；
　　2. 库存查询方式灵活便利，如可查历史某时点库存，可查某类或某个仓库存货的库存，可只查当天有交易发生的存货库存；
　　3. 可快捷查询常用存货的安全库存状况，及时了解到材料是否该采买，以确保生产所需；
　　4. 可迅速查询仓库呆滞料状况，以便及时处理，减少库存积压对资金的占用，提高资金营运力；
　　5. 仓管做帐简单，轻松，及时，准确。仓库资料可据领导需要以多种格式产生，美观大方，快捷灵活；
　　6. 每月盘点资料产生快捷方便，系统自动统计出仓库帐及会计帐的盘盈亏数字；
　　7. 仓库所做单据可由系统自动传递到财务等相关部门，及时准确；
　　8. 仓库资料可与其它部门实时共亨，不用一天到晚总是接到替人查库存的电话；
　　9. 库存异常存货有专门报表统计，以便仓库作业人员有针对性的查核；
　　10. 为配合财务所需，对月底收到暂无发票之存货有单独接口可做存货暂估。

ERP为材料采购带来了什么？
　　1. 资源整合，采购系统资源与企业其它人、财、物资源整合在一个数据库中，有利于企业资源的共享；
　　2. 信息上传，采购单据一经输入，系统会自动发送短信通知主管审核；
　　3. 指令下达，采购指令会自动流转到仓库部门，便于物品验收与入库；
　　4. 财务记账，采购入库单据会自动拋转到帐务系统，便于财务人员对帐与记帐；
　　5. 可直接按营业部门所接客户订单安排采购；
　　6. 系统会根据生管部门下达的生产制令展算原物料需求，并可自动转成采购订单。
　　7. 可维护上下游厂商之供应链管理(SCM)；
　　8. 统一管理供货商及其报价，便于考核评估供货商，比较分析采购价格；
　　9. 可根据实际需要按不同采购人员划分采购物品范围；
　　10. 采购订单输入时，系统自动将供货商之核准价格带入，方便输单作业；
　　11. 在请购作业中记录各部门原物料的请购情况，并可自动转成采购订单采购；
　　12. 供货商送货过来，暂收资料直接与品管关联，检验合格则入库，否则退回；
　　13. 提供各类查询窗体，以便随时掌握采购下单、采购单价、厂商交货、仓库验收、采购跟催、进货对账、应付账款等信息；
　　14. 提供相关统计窗体，以便高阶主管分析、决策。

ERP为MIS人员带来了什么？
　　1. ERP系统软件 软件具有安装上的简易性，业务上的专业性，作业上的实用性，和使用上的人性化，这些优点使MIS人员学习和维护ERP系统容易上手，以利于提高品质，提高效率；
　　2. ERP有益于MIS人员对本公司(工厂)内的计算器硬件及网络架构有更深入的了解，以便于MIS人员更好的维护和管理；
　　3. 通过ERP实施和导入使MIS人员对计算器安全和网络安全有更深入的了解，可以增强他们的计算器专业知识；
　　4. 通过ERP的学习和使用，使MIS人员可以对SQL数据库的自动备份和还原数据库功能有更深的理解；
　　5. 通过ERP的学习和使用，使MIS人员学到关于远程遥控联机的新的知识；
　　6. 通过ERP的导入过程.使MIS人员从一个计算器操作者逐步成为一个具有计算器专业知识的系统管理员；
　　7. ERP有益于MIS人员对Windows系列操作平台系统有更深入，更专业，更系统的学习和使用；
　　8. 在ERP实施过程中一定会遇到一些困难和问题，这些问题的处理和解决对增强MIS人员的实务经验有很大的帮助；
　　9. 通过ERP的导入实施，给MIS人员提供了多学习一些专业知识和技能的机会，为MIS人员工作经验值加重法码；
　　10. ERP有很强的逻辑性和系统流程条理性，MIS人员深入的学习和了解后如果变通的把条理性的工作模式，方法带入到更多工作当中也会提高他的工作品质和效率；
　　11. 有益于MIS人员对工厂的作业流程有更深入，细致的了解；
　　12. 促进MIS人员与公司(工厂)内部各个部门之间的配合及协调，从而加强团队意识；
　　13. 通过对ERP系统的了解，学习，使用，维护和管理.对MIS人员素质也是一个很大的提高。 

　　本文总结了EPG成员在从事软件过程改进时，常犯的10个错误，为EPG有效地开展过程改进活动，提供了一个简洁实用的指南。
关键词 模型 沟通 循序渐进 裁剪 持续培训

1、 对模型研究不够深入
　　模型是多年软件工程经验的总结，里面的每一句话，每个例子都不是随便写上去的，都有其内在的含义在里面，需要仔细琢磨，仔细体会。作为EPG的成员，在遇到问题时，首先要做的事情是要去读模型，在模型中查找答案。市面上所有翻译的中文资料都不准确，所以要去读模型原文，以免以讹传讹。在读不懂的地方应该去读SW-CMM与SE-CMM，从那里获取类似的描述，如果还读不懂，可以去网络上搜索资料，与朋友交流。
　　当然，不能唯模型论，模型不会解决所有的问题，模型也只是描述了做什么，怎么做在模型里并没有详细描述，要解决怎么做的问题需要和有实践经验的专家进行沟通。只有真正理解了模型才能不唯模型论，才能根据实际进行裁剪。

2、 不善于与项目组沟通
　　规范的管理是着眼于未来的，可以降低犯错的概率，其效益可能在当前并不明显，规范的管理会改变开发人员的工作习惯，在他们的眼中可能认为规范是一种累赘，因此对规范的抵制是一种很自然的反应。
EPG是公司研发管理大法的制订组织者，是体系推广者，项目组是体系的执行者，而EPG不是项目组的领导，在和项目组打交道时，不能以居高临下的姿态和项目组沟通，否则很容易引起项目组的反感，给体系的推广设置人为的障碍。
　　项目组里最有影响力的是项目经理，项目经理就是EPG的重点沟通对象。

3、 不善于利用企业高层管理人员
　　过程改进也是一把手工程，尤其是在基础薄弱的组织中。如果缺少了企业高层的支持，体系的推广是寸步难行的。
　　EPG不是项目组的直接领导，不可以直接对项目下命令，因此在推广的过程要善于利用企业的领导，经常和领导沟通，和领导一起加深对研发管理的认识，从领导那里获得反馈，并借助领导的影响力促进体系在项目中的推广。
　　与领导的沟通是有技巧的，要根据领导的风格区别对待。有的领导喜欢直来直去，有的领导喜欢迂回曲折，有的领导喜欢独断专行，有的领导则比较民主。要将你的思想转换为领导的思想，就要采取一定的技巧，对症下药。

4、 不善于利用一切改进机会
　　为了推广体系，需要充分抓住一切在组织内教育员工、教育领导的机会。最典型的有4个机会：
　　（1）质量事故。一旦发生了质量事故就要刨根问底，追根溯源，以充分引起大家对质量的重视。
　　（2）成功案例。如果有个项目做的很成功，同样也要抓住机会，仔细深入地分析项目成功的原因，利用典型的成功案例教育大家。
　　（3）外部咨询。中国有句俗话：“外来的和尚会念经”，当有外部的咨询师或者评估师到企业时，也要充分利用这个机会，对员工和领导进行教育。
　　（4）内部调研。在企业里进行对管理现状的调查，是一种自底向上反应大家对组织规范管理需求的有效手段。管理永远是需要改进的，改进的动力来自于商务需要，也来自于群众的呼声，群众的呼声可以转换为商务需要。

5、 EPG本身作业不规范
　　EPG要以身作则，自己也要按规范办事，不能表现的很随意。比如：
　　EPG自己生产的文档不符合公司定义的各种的规范；
　　EPG自己的文档没有纳入配置管理；
　　体系文件的变更不遵守公司的变更流程；
　　EPG的工作缺乏计划性
　　对EPG的工作没有执行PPQA等等。
　　已身不正，何以正人？

6、 违背了循序渐进的思想
　　“以人为本，以过程为核心，以度量为基础，循序渐进”是当前各种管理模型的核心思想。管理的改进是文化的变革，要改良而非革命，不能拔苗助长，要冷水煮青蛙。一些软件开发中的基本实践看似简单，在企业里推行时却会困难重重，比如：需求文档化、设计文档化、计划文档化、同行评审、专职的测试等等。往往迫于商业目标的压力，在过程改进时，EPG会定义不切实际的改进目标，试图短期内见效，这样就要求项目组一次改进的地方太多，而这么做，很可能事与愿违，导致项目组比较抵触，即使短期内能够通过评估，一旦拿到证书，反弹也会比较大。

7、 忽略了裁剪指南
　　裁剪指南比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的，要保持体系的灵活与敏捷，就必须定义详细的、实际的裁剪指南，并在实践中逐步完善。EPG的成员往往试图包罗万象，将体系定义的相当完备，在过程定义、模板定义上花费了大量的时间，而忽略了裁剪指南是体系的更重要的部分。这样导致在实际推广中，体系可以裁剪的选择余地很少，针对具体的项目组，往往会让项目组多做一些无法产生价值的活动，这样项目组就会产生一些抵触情绪。

8、 忽略了持续培训
　　在过程改进的初期会做CMMI的 introduction培训、过程域培训、管理技术的专题培训，在体系定义完成后，会做体系的培训。那些培训要么是集中在一段时间完成了，培训的密度比较高，效果并不好，要么间隔的时间比较长，培训后面时忘记了前面的内容。因此，需要在体系的推进过程中再将已经做过的培训的要点换个角度进行强化，使一些观念、一些做法深深的刻在每个人的脑子里，这样才能成为习惯，才能让执行者能够知其然，知其所以然，持之以恒地坚持下去。

9、 缺乏足够的软件工程经验
　　这一条实际上是在选择EPG成员时犯的错误。以CMMI模型的博大精深，要想充分理解其内涵，理解其精神，没有足够的软件工程背景是比较困难的。而很多企业的EPG成员恰恰就缺乏足够的软件工程经验，有经验的员工都去生产一线做项目经理、做部门经理，去直接创造商业价值了，间接创造商业价值或者会带来长期效益的管理活动便让一些缺少经验的人来做了，这实际上一种“脑体倒挂”。缺少经验的人需要到一线去工作，去锻炼，去提高，那些有经验的员工则需要充分贡献出其经验，充分发挥他们在企业里的正面影响力，而不是成为过程改进的阻力，这才是他们的价值的体现。

10、过分依赖咨询公司
　　EPG成员在建立公司内部过程体系的初期，往往会过分依赖外部咨询公司，要求咨询公司提供已成型的过程体系文档。每个组织都有其自身的特点，产品方向可能不同、组织结构可能不同、企业文化可能不同、人员结构可能不同、外部的商务环境也可能不同，因此企业的作业流程、文档格式等都可能不同。如果机械的照搬，那么势必会造成EPG建立的标准过程并不适合本组织，从而使过程改进见效缓慢，甚至夭折。

 

　　作者简介：任甲林，软件研发能力高级咨询顾问，10多年软件工程经验，曾任多家公司的研发总监。参与或主管了近50多个项目，在工作中积累了大量的研发管理经验，对CMMI、软件项目管理、软件公司管理、软件复用技术有较深的理解。