这个题目为近日所思，一直没有落笔。今天是端午假日，得空卸货。
标准化是精益实施的三个基础之一，在我们的项目实践中没有须臾忘记。在此我们不再赘述标准化为啥这么重要，更多来分享如何标准化。
在项目实施的各阶段中，“系统切换”是我个人一直以来的一个心病。所谓心病，就是真的会“提心吊胆”，如履薄冰，如临深渊。害怕出Bug，害怕出现未知问题。媳妇给我说，当我们面对未知而害怕时，最好的办法就是凝视它，给它贴标签。焦虑感就会大大降低。
在近期的两次项目上线中，我们有意识的解决这个问题。有些心得，标记如下。
借鉴FMEA
切换工作本质上是将沙盒中的配置、定制、数据迁移到正式环境，同时保证用户能够按照预定流程在正式系统进行业务操作。我们所要做的工作是将环境切换的影响降为0，不让在沙盒中完成UAT的“可用”系统失效。只是由于随着项目规模的扩大，配置、定制、数据复杂度出现了几何级的跃迁，理论上，这必然导致切换失败概率的提升，这就是墨菲定律嘛。
因为较长一段职业生涯我是在制造业信息化领域，在这一领域的很多工具和手法，完全可以有效作用于专业服务领域。正如我们倡导的“精益实施”就是“精益生产”在ERP实施、服务领域的实例化。在制造业质量管理领域中的众多工具，都可以帮助我们解决相似的管理挑战。其中，失效模式及影响分析（Failure Mode and Effects Analysis，FMEA）就是其中的一种。
FMEA是一种系统的、前瞻性的质量管理工具，能够帮助识别和评估潜在的失效模式及其影响，并制定相应的预防和缓解措施。我们可以利用这个质量管理工具，用于项目系统切换过程的潜在失败分析、预案制订，能够让项目管理者较为从容的面对可能的失效事件。
主要办法是由项目经理、实施顾问和开发顾问一起，列举清单，展示沙盒与正式系统的差别，包括：
- 系统配置参数
- 代码清单
- 自定义记录类型
- 工作流
- 自定义工作中心及目录
- Workbook
基于上述内容，列举可能由于环境变化而出错的地方：
- 沙盒与正式环境的URL差别
- 引用Internal ID导致的环境变迁失效
- 引用关联记录导致的环境变迁失效
通过全量列示，形成迁移计划中的任务清单。
所谓，预则立，不预则废。这种前瞻性办法能够最大限度的降低迁移失效风险。
强调上线后的场景测试
基于正式系统的功能测试，是将系统正式开放给用户前的关键工作。在我们的系统定制工作中，可能10个技术定制点才能对应一个用户能够“感知”到功能点。如果10个技术定制点中的一个出了迁移错误，就会导致这一个用户感知功能点的失效。所以，在FMEA“穷举”了潜在失效“技术定制点”后，以用户角度看“功能”，是一个更有效的排错办法。
用UAT脚本，在功能、数据迁移完毕后，在目标系统中跑一遍，是不能逾越的必要过程。需要提醒的是，根据项目复杂程度的不同，有两种上线测试模式：
切换标准作业
从实践中来，书斋枯坐，最后再回到工作中去，提升实践水平，精益求精。截止到目前，我们切换阶段标准作业原则如下。
最后，我用一本书来结束今天的总结。
奥美的创始人，大卫.奥格威提到他早年在巴黎的饭店（美琪）当厨师的经历。他说在这家全法最好的厨房里，有很多的工作原则和标准，这影响了20岁的他。也成为了创建奥美时的工作原则的来源。
如果有任何关于NetSuite的问题，欢迎来谈。邮箱：service@truston.group
