纸上谈兵
项目实施过程中的手册编写是比较重要的一个环节，直接影响到项目的实施进度与质量。那么在项目中手册编写需要注意哪些方面呢？在这里基于并不多的项目经历，总结了几点，在此与大家分享，抛砖引玉，欢迎大家指点：
手册的价值
作为项目实施工作的可展示的文档，直接体现了项目交付的质量。
在培训前，编写通俗易通，图文并茂的手册，有利于提高培训效果。
时间上的分类
1）一般如果项目较大，待培训人员较多的话，需要提前就着手进行培训工作。在搭建测试核心流程后，能够确定初版蓝图的时候，就可以进行培训、操作手册的编写了。基于通用操作流程的手册，基本与正式交付后变动也不会存在太大差距。此时编写的手册可能会因后续蓝图的调整（涉及业务流程、单据的增减），而需要及时更新。
2）蓝图经过汇报、调整、确认后，进行培训。到了这个阶段，因为基本蓝图确认后，手册的内容也不会有太大的变动。 此时进行集中培训、专项培训时，可以结合培训计划，分模块、岗位职能分工，编写各自的简明易懂的手册。
3）项目实施接近验收环节，此时接近离场，为了确保离场后客户的ERP系统能够顺利使用，确保客户的实习人员（新员工）的顺利上手，且作为项目的最终交付物，此时需要对手册仔细打磨，丰富完善细节，从总体上进行优化调整等等。
操作手册应该包含哪些内容
1）总体流程图、分项流程图
我认为操作手册的编写，关于流程图方面不需要只拘泥于标准规范云云之类，眼中只有流程图必须要用VISO、这个单据应该用哪个图形，那个流程应该用哪个图形，判断条件必须怎样，流程图列名称与行名称必须按部门、职能布局等等只看形式的牛角尖。当然我个人是非常反感“你这个单据用这个图标显得非常不专业云云”之类的看法。
因为我理解的操作手册编写的最根本的目的，是需要让读者能够通俗易懂，看完这个手册，就基本对这个系统运行的大致流程逻辑做到熟悉，再结合一些单据录入就基本掌握，能够做基本的操作，将流程走得通。
就算你的手册编的再规范漂亮，客户看不懂这手册写了些什么东西，看了反而更迷糊，更对这个系统产生望而生畏的感觉，那这种手册就毫无价值，反而有害。
所以我认为操作手册的流程图，需要“因企而异”，结合客户的实际情况，编写恰当的手册。建议手册做一些通俗易懂的整体流程图，让所有操作人员对系统整体有一定的了解，而不仅仅是只对自己负责的那一部分了然于胸。
2）手册编写需要对0基础人员友好一些
必要时可结合实际场景。如仓管人员今日接到供应商送货消息，在经入场抽检合格后，需要先在系统中录入采购入库单（假定不录检验单、收货通知单），然后将系统中的入库单打印后，将三联交于送货人员做出门凭证等等。系统采购入库单录入方式：功能路径-系统所有功能-供应链-采购管理-采购入库单（配图），再将操作中弹出的所有界面截图标注。
3）关于特性
基本所有项目都有一些自有的特性，在手册编写时一定要做详细记录，最好是添加体现在操作手册中。后续如果该客户做二期项目，恰好需要对一期的内容重新再次梳理实施时，这个时候就可以避免不必要的重复调研工作。也便于后续的其他同事做售后技术支持。
4）常见问题及处理
针对项目上线后做上线指导时遇到的一些常见、多发问题，及预想到的客户很容易录错的单据、字段，如确实无法通过系统做校验，就只能加强培训，同时将这些常见问题基础方法、后续如何规避等等资料，维护至操作手册中。其他诸如客户端安装、清除操作冲突、打印样式调整打印机等等操作方式建议进行添加。
操作手册的复用及潜在价值
基于常规单据的操作手册，可以按单据进行预先截图编写，用于项目交付手册编写手册的素材，可以相应的提高项目实施中手册的编写进度。同时随着新功能发布、版本的更新实时更新标准操作手册。
可以通过乙方公司内部的多部门（不同视角、关注点）共同编写、评审手册，来发现总结星空系统的特点，做到有效的连接有一定高度的方案，与实实在在的落地交付之间的鸿沟。来总结发掘公司的内部资料库（沉淀）。
纸上谈兵
操作手册这个环节，可能是很容易忽略的环节。毕竟产品中按F1有帮助手册，还有通版的操作手册。但是如果投入一定时间做好一份有温度的操作手册，将功夫、服务真正做到细致入微，而不仅仅以交付验收为目的，我相信这样的服务更加容易得到客户的肯定。
另外参与项目时编写操作手册，也是快速熟悉产品的一个好的学习方法，很多时候看视频、动手实操等常规学习方法，与直接动手编写给客户的交付手册，这样也是一种很不错的学习方法。毕竟当你自己需要编写操作手册时，需要考虑的方面就跟多了。
欢迎大佬留言讨论指导，不胜感激。
END
推荐阅读