积累是CIO成功第一要素

　　笔者一直坚信积累是CIO成功的第一要素。不仅仅笔者这么认为，周围的很多CIO都跟笔者有相同的认识。故为什么积累是CIO成功的第一要素笔者在这里不做过多阐述。笔者在这里项说的是CIO该如何做好积累，为自己的成功打下坚实的基础。

　　一、翔实的做好项目文档。

　　笔者在平时的工作中很重视知识的积累，如通过项目文档来积累知识。因为笔者有自知之明，知道自己精力有限，无法精通项目实施过程中的所有内容。而且好记性不如烂笔头，为此笔者在项目实施过程中的每一个环节，都会翔实地做好相关的项目文档。如在ERP项目中，需要重新制定或者调整物料编码。这项工作完成后笔者记录了如下的内容。

　　一是原有的方案有哪些不足之处。笔者企业在上ERP之前，为了管理的方便，已经有一套物料编码。具体的编码规则为“大类+小类+客户或者供应商简称+分隔符+流水号”，总共12码。但是实施顾问看了这个编码原则后，就马上否定了这个方案。他一针见血的说出了这个方案的弊端。一是把客户或者供应商的简称放在物料编码里面，很容易导致物料的重复。如某个物料有两个供应商提供，那么就需要编制两个品号信息。这对于后续物料清单建立、物料需求计划运算等等都会造成很大的困扰。二是企业原材料种类繁多，现在只把物料分为大类、小类则后续物料编码的扩充性并不是很好。根据企业现在的物料种类，流水号4位都快用完了。虽然扩充流水号可以增加物料编码的种类，但是还不如对物料进行细分对于后续操作更加方便。专家不愧为专家，一看就可以把困扰企业多年的弊端找出来。不错这两个问题，特别是第一个物料编码重复的问题，已经困扰企业好久了。这种经验性的东西笔者当然要记录下来，免得后续大家又犯类似的错误。

　　二是根据企业的实际情况，实施顾问给我们做了一些建议。一是可以把物料分为大中小类，并且利用英文字符来区分大中小类。如是刻供品的原材料，可以利用GU或者CL表示。如此在后续查询的时候，直接输入材料的前缀即可以实现模糊查询。另外这个种类编码最好是英文单词或者拼音字母的简称，这方便员工记忆。不过最好使用英文单词，因为英文单词不容易重复；而拼音字母简写的话则重复的几率会搞许多。二是对物料进行大中小类分类之后，企业要预计以下物料的多少。现在流水号长达4位，有一点长。如果企业物料编码能够保证够用的话，这个流水号最好能够控制在3位。否则的话物料编码太长，不容易输入、维护、记忆。最后企业就是按照实施顾问的这些建议设计了新的物料编码。为了后续能够追踪为什么要这样制定物料编码，笔者把实施顾问的这些建议也都一一作了记录。这份记录到后来还真起到了作用。一年后有员工提出来这个种类的编码能否设置为拼音的简写，因为他们英语不好，不知道英文单词。反而拼音对他们可能更加直观。笔者接到他们的需求后，觉得也比较有道理。不过笔者当时也忘记了那时候为什么要这么处理。为此找出了这份文档，一看才知道之所以不用拼音是怕担心种类编码重复的问题。为此笔者按现有的物料种类利用拼音简写进行编码。完成后确实发现有很多种类如果利用拼音简写都是重复的。后来经过各个部门权衡利弊之后，还是决定采用英文单词简写编码，而放弃使用了拼音。

　　从这个物料编码的工作就可以看出，项目文档的重要性。当CIO通过项目文档来积累自己的经验时，笔者认为不仅需要把现有的方案记录下来，而且还需要把为什么要这么做的考虑也记录下来。也许一年或者几年后有员工会对现有的方案提出疑义，而CIO又记不清当时为什么要这么设计时，则可以通过项目文档来寻找答案。就好像笔者遇到的那个拼音与英文单词的问题。有了这方面的记录，可以帮助CIO避免犯错误。另外，如果企业以前已经有了一些解决方案，但是新项目无法使用时，最好也能够把旧解决方案的弊端记录下来。因为每个人都有一种怀旧的思想。说不定哪一天员工会认为以前的解决方案好。此时CIO就可以利用这个项目文档来反驳员工的想法。其实很多情况并不是说员工真的认为是以前的解决方案好，他们只是通过这个方式来反对这个项目而已。

　　笔者强烈建议各位CIO的朋友们要做好项目文档。他是CIO积累经验的一个很好的手段。有时候，自己编写的项目文档比所谓专家编写的教科书要好得多。

　　二、测试记录也不可少。

　　CIO在负责信息化项目的时候，软件测试是必不可少的。在软件选型时需要对软件进行测试；二次开发完成后也需要对二次开发的功能进行测试。对于这个测试的内容CIO也最好做详细的记录，否则的话，以后可能会重复性的工作。

　　如笔者以前就犯过这愚蠢的错误。那时笔者在企业中负责一个ERP系统的日常维护工作。在软件选型测试的时候，碰到过一个问题。销售订单这个窗口，在后台数据库中是对应着两张数据库表，分别为订单头与订单明细。他们之间通过订单ID来进行联系。也就是说在销售订单明细这个表中存储有订单ID。不过为了直观显示，在订单明细中向用户显示的是订单单号而不是系统自动生成的订单ID。但是这里系统有一个漏洞。如果事后对销售订单调整过，若在销售订单行中通过应用字典向这个页签中添加了一个字段，那么此时在销售订单明细页签中订单号码处显示的是订单ID，而不是订单单号。需要在应用字典中进行调整后才会显示正常。

　　半年之后笔者因为用户的需要对销售订单页签进行了调整，主要是调整了显示的顺序。可是调整完成之后，这个订单编号又不见了。显示的是员工看不懂的订单ID。笔者知道这是因为订单明细调整所引起的，只需要在应用字典中进行相应的调整即可。可是笔者记不起来在哪里调整了。觉得好像系统中有一个批处理作业，运行一下这个问题就可以解决了。但是笔者找来找去，就是找不到。最好搞弄了大半天，才给我找到这个批处理作业。

　　如果笔者在当初测试的时候，就可以把这个问题的解决方案记录下来。那么在以后遇到类似的问题时，即使忘记了该如何处理，也可以查询相关的项目文档来寻找答案。好记性不如烂笔头。有时候CIO动动手也是蛮不错的。

　　故笔者建议，CIO在做软件测试的时候，如果发现问题要马上通过书面的形式记录下来。并且如果有解决方案的话也需要一一进行记录。而不要太过于相信自己的脑袋。要知道CIO平时的信息摄取量已经大大超过常人了。但是人的记忆力毕竟有限，故其忘却的程度也可能要比常人要快。为此在测试过程中发现的任何可疑点以及相关的解决方案最好都能够以文字形式记录下来。如此的话，不仅以后遇到类似问题可以轻松的解决；而且这也是后续评价软件供应商的一个重要指标。CIO也可以凭借这份文档督促软件公司进行修改程序。所以说软件测试报告也是CIO少不了的一项内容。

　　而且各个类似软件具有相通的地方。如果CIO在第一次接触软件的时候能够把这个软件的测试过程一一记录下来，那么当以后跳槽后再次遇到类似的软件时，则凭借以前的测试文档在对新软件进行评估时就方便许多了。不需要再从头开始进行测试，而只需要针对以前项目文档中的一些重点内容进行测试即可。这给了CIO一个走向成功的捷径。笔者现在手头的软件测试报告已经积累了厚厚的一大叠了。基本上现在企业常用软件的测试报告笔者都有。如此笔者现在工作就轻松许多了。如企业要新上一个项目，笔者会首先查询以前的测试报告，看看需要测试的重点。然后再有针对性的对新项目软件进行选型与测试。如果运气好的话，遇到的是相同的软件，那么更好了。可见这可以大大节省CIO的工作量，助CIO更快的取得成功。