这个题目为近日所思,一直没有落笔。今天是端午假日,得空卸货。
标准化是精益实施的三个基础之一,在我们的项目实践中没有须臾忘记。在此我们不再赘述标准化为啥这么重要,更多来分享如何标准化。
在项目实施的各阶段中,“系统切换”是我个人一直以来的一个心病。所谓心病,就是真的会“提心吊胆”,如履薄冰,如临深渊。害怕出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