项目计划：

    在项目准备阶段，项目计划的编制成为甲乙双方两位项目经理的主要工作内容，将6个月的总体上线任务和工作内容细化到周甚至到日，并在统驭项目主计划的同时，进行了数据计划、项目整体培训计划、项目宣传、活动计划等内容，以确保项目计划的周密且不遗漏。

    “计划没有变化快”。由于人员投入不够，项目虽然按着计划在向前走，但总是存在着这样那样的问题，无法做到深入和完善。而最终导致系统上线推迟的最主要原因就是初期数据迟迟没有收集整理到位。

    项目组织：

    项目组织的建设也是起初脑筋动得比较多的地方，公司成立了项目管理委员会，将公司主要高层都纳入其中，由CEO亲自担任；管理委员会下设项目管理办公室和监理组；接下来是技术组、业务组、数据组和开发组。其中业务组按此次上线的模块分为五个组：销售、采购/仓储、物流、财务和生产，业务组长均由相关业务部门负责人担任，再由其抽调部门骨干进入，同时信息部也在每个业务组派出一名代表。

    起初，钟剑一再要求业务组必须有一名业务部门的骨干力量全职参与项目组，但最终由于业务部门负责人的反对，而导致目前业务组除信息部人员外全部属于兼职参与。经常一个讨论分析会都要一变再变地变更时间，尤其到后期的跨模块讨论时更难确定会议的时间。项目组没有一个统一的工作场所，顾问、业务组、信息部人员均在各自的办公室办公，只有开会时再聚到一起。由此，对项目所有工作的开展都产生了巨大的影响。

    蓝图设计和系统实现：

    由于前期准备工作比较充分，ERP项目启动前已经做过一轮业务流程的调研分析，加之ERP项目刚刚进入大家的视野，在蓝图设计中现状调研阶段，大家还是比较积极地参与，很快就完成了任务。但到了未来蓝图设计时，一是由于工作忙，二是“新婚期”已过，个别部门领导不再参与流程的讲座和分析，而由手下人参与，领导只看最终的汇报和文档，并也在蓝图流程上签字认可了，这些在当时并没有觉得问题有多大。但到了最终用户培训和单元测试时，却发现原来这些蓝图流程与老总们想的有出入，与那些部门骨干的思路也有出入，只好返工重来，还需要协调实施顾问的资源。在原本时间和人力资源比较紧张的情况下，这又浪费了不少时间，让人苦不堪言。这也是上线时间延迟、项目计划不能顺利执行的主要原因之一。

    系统实现，一方面是顾问按业务蓝图流程设计进行配置和二次开发，另外就是关键用户熟悉系统，并进行业务场景在系统中测试运行的好时机。由于人力的投入不足，导致很多地方由顾问进行相对标准的测试就草草了事。有些测试虽然由关键用户进行的，但由于系统熟练程度有限，加之大多数部门关键用户没有足够重视，把测试当成一项工作任务来完成，应付了事，没有完全重现业务运作时的多重组合的复杂的业务场景，相对简单地进行了一些业务内容的测试。这就埋下了隐患。

    数据整理和接口、报表设计：

    数据，从一开始就提到比较高的地位，专门成立了数据小组来负责，静态数据很快就进行了统一编码、重新规范等工作，动态数据的模板设计和下发也进行得相对比较顺利，但在业务部门却没有引起足够的重视，或者没有及时提交，或者提交上来的数据没有完善地按模板进行填报，有些业务人员就象征性地填了一两列数据表就上交。因此，数据的整体收集和整理工作一拖再拖。

    另外，由于公司从建立到现在有15年，历史遗留下来没有解决的问题比较多，集中反映到数据上就是：账实严重不符，日常在进行审计和核对时，大家只采用账账核对，而只有一些常用的原辅料和流动比较快的产成品在正常流转。这也是不同业务部门在上线数据不符进行调整时，争论得比较多的事情。

    虽然公司其他的信息系统并不多，但由于整体行业信息化程度比较高，上下游企业之间的数据传输还比较频繁，为了解决这个问题，在选型时即确定通过接口的开发来完成。这块由于顾问公司人力投入不足，而信息部提交的开发技术人员招聘的事情也被莫名搁置了几个月，到目前为止还没有任何信息。

    报表开发需求量也比较大，虽然已经开发好其中的一部分内容，但由于系统没有真实数据，很难对其正确与否进行评估和检查测试。

    最终用户培训：

    《最终用户操作手册》每个模块在顾问的督促下，在关键用户开始学习的时候就着手编制，只有少数没有关键用户投入的部门涉及到的操作流程未能完成。由于关键用户对于业务的熟悉程度不同、对ERP系统的熟练程度不一，操作手册的优劣差异很大。相对来说业务场景设计得比较全面，且能够详细截图、解说的《最终用户操作手册》不多，这也为最终用户的培训带来了问题。

    在最初的培训计划中，安排的是专门的多场集中式培训，但由于业务部门工作繁忙，关键用户和最终用户时间无法统一调配，使得培训的方式变得五花八门：有集中进行培训的，有单一进行培训的，还有到最终用户工作现场进行培训的。