kingdeeway交付方法论v7.0.pptx

1、编制部门：总部PMO,Kingdee Way项目交付方法论7.0,Kingdee Way交付方法论V7.0特性简介 Kingdee Way交付方法论V7.0内容简介 交付方法论框架体系 交付过程 项目管理 Kingdee Way交付方法论V7.0初步推广计划,提纲,金蝶交付方法论的发展历程,新的实施方法论，如何进行优化和改进？,2014,交付方法论，不仅要成为项目经理和顾问的工作指南，还要成为PMO项目监控的标准，更要成为销售人员的有力工具和武器。,交付方法论的定位和优化改进方向,顾问的工作指南,公司盈利,客户增值,顾问成长,将原来的实施方法论内涵进行了外延，在核心内容（实施过程、项目管理、知

2、识库和IT支撑平台）之外，前端延伸到客户价值和实施产品销售、后端延伸到顾问能力素质模型和顾问成长。,交付方法论V7.0优化之处（一）,未来具体的项目交付，将会以实施方法论及其工具模板为基础，结合领域和行业应用特点，形成个性化应用指南，以满足不同行业、领域、项目大小的裁剪需求，形成“1+X”的具体项目实施交付工作。,交付方法论V7.0优化之处（二）,1个主体,X个行业、领域应用指南 如EAS集团财务、EAS供应链、K/3Cloud、房地产，等,将原来的实施方法论和客户化开发方法论整合为统一的交付方法论。解决了一个合同多个项目经理，互相扯皮，内耗严重的问题。,交付方法论V7.0优化之处（三）,整合

3、,对四个阶段的工作包内容，进行了改进和优化。由原来的4个阶段，20个工作包，调整为26个工作包，工作包的名称和内容进行了优化、调整，重点强化了项目调研、蓝图设计、系统测试、上线准备、实施总结等工作内容。,交付方法论V7.0优化之处（四）,交付方法论,工作包：将20个实施工作包和6个客户化开发工作包融合成26个交付工作包； 工作活动：将26个工作包分解为82个具体交付工作活动； 文件模板：每个交付物提供文件模板，主要交付物提供分业务领域的文件模板，包括：培训课件，培训考试题，调研问卷，业务流程，用户手册，标准格式初始化数据，初始化数据检查表,合计396个文件模板。,4个实施阶段,26个交付包,8

4、2项活动,396个文件模板,新的方法论，不仅明确了要做什么内容，更加了很多如何开展工作的相关指导和说明，使顾问更加容易理解和掌握。,交付方法论V7.0优化之处（五）,作事原则,做什么 What 怎么做 How 何时做 When 谁来做 Who,工具方法,项目实施过程,共享知识库,软件工具 使用手册 培训 项目案例,交付方法论,要求顾问知道在作任何一件事都必须知道此原则,即做什么、怎么做、何时做以及谁来做,项目实施团队,交付方法论,项目实施团队根据实际情况，结合共享知识库案例以及方法论，在项目过程中进行裁剪，以达到工作效率与项目质量的平衡。,新的交付方法论的主要价值,顾问可快速学习大量可利用的实

5、施工具 顾问不仅知道应该做什么，而且了解了如何去做 快速了解行业知识，向行业管理专家转型,规范交付过程，提高交付质量和客户满意度 降低交付成本，提高项目收益 持续提高客户满意度，建立良好市场口碑,有利于实现客户价值主张，满足客户实际需求 有利于借鉴行业优秀的管理知识和经验，提升管理效率和质量,对顾问,对公司,对客户,Kingdee Way交付方法论V7.0特性简介 Kingdee Way交付方法论V7.0内容简介 交付方法论框架体系 交付过程 项目管理 Kingdee Way交付方法论V7.0初步推广计划,提纲,实 施,项目定义,Kingdee Way交付方法论7.0框架体系简介,蓝图设计,系

6、统实现,上线支持,2,3,4,项目立项,项目筹备,制定项目管理计划,项目启动,软件安装与部署,关键用户产品培训,项目调研(AS-IS),核心流程分析及模拟,编写新业务蓝图（TO-BE）,新业务蓝图确认,客户化开发编码/单元测试,客户化开发程序发布,客户化开发系统设计,系统测试,上线准备,系统上线确认,编写总结报告,召开总结大会,项目收尾,开 发,1,上线辅导,需求编写,编码/单元测试,系统测试,实施转服务交接,客户化开发项目立项,客户化开发需求编写,客户化开发需求确认,编写用户手册,最终用户培训,开发立项,系统设计,程序发布,需求编写,系统设计,编码/单元测试,程序发布,系统测试,系统上线,K

7、ingdee Way交付方法论V7.0特性简介 Kingdee Way交付方法论V7.0内容简介 交付方法论框架体系 交付过程 项目定义 蓝图设计 系统实现 上线支持 项目管理 Kingdee Way交付方法论V7.0初步推广计划,提纲,销售交接阶段-项目交接立项,1.项目定义,1.2 项目筹备,1.3 编制项目管理方案与实施计划,1.4 项目启动大会,1.5 软件安装与部署,1.1 项目立项,项目立项-理想状态的EAS实施团队,系统研发 二次开发 第三方承包商,决策领导,管理员 技术支持,裁决项目范围 审批实施方法 审批项目计划 阶段性质量监控 ,建议项目范围 制订并执行实施方法 制订并控制

8、实施计划 制定总体业务蓝图 签署项目的交付成果 项目预算与奖惩控制 ,协助制订实施方法 系统培训与考核 制订业务流程方案与测试 制订岗位操作说明书 基础数据的统筹管理 系统初始化统筹管理 ,网络与硬件资源协调 系统的安装与部署 系统数据安全控制 用户权限分配与管理 系统维护与补丁包管理 ,协订业务流程方案与测试 基础数据的收集与整理 协订岗位操作说明书 岗位业务的操作应用 ,系统功能的完善 系统集成的构建与测试 二次开发的培训与考核 开发代码包的统筹管理 元数据的统筹管理 ,操作用户,项目经理,关键用户 实施顾问,大多数项目，为方便省事，销售端向交付端作交接时只有文档交接，导致实施项目团队一进

9、场时又要重新建立客户关系。如何让销售已经经营好的客户关系稳定住至关重要！,项目交接需要强调平滑过渡,多数机构售前文档不齐全，同时又受制于各种条件，机构提交的售前文档内容质量不高，更多情况下是为了应付各个审批环节； 客户经理通常情况下是通过邮件方式将售前文档转给项目经理，即使召开会议作售前文档正式交接，最多也就一二个小时，交接效果不好，而且很多销售口头承诺无法体现在文档中。,项目交接作为销售向实施两个重要阶段的转移环节，需要作到平滑过渡,高质量的售前文档可以让交付团队尽快了解项目的范围，了解客户启动该项目的背景及复杂性，可以尽早进入状态； 由于项目的相关资料不可能在客户公司内部广泛传阅，因此项目

10、经理在交接过程中首先要对客户方重要干系人进行访谈，以了解他们对项目的态度和看法； 前期客户经理 已经经营的客户关系，需要有人来承接，因此交付项目经理需要尽早在客户那里建立他的专业性以及可信任性。,现场交接基本没有,多数情况下，客户经理带项目经理第一次出现在客户现场是在启动会议上，在这之前项目经理基本上没有与客户重要干系人进行过沟通，项目经理很难了解到客户关键干系人对项目的态度及各自的处事风格； 客户经理可能有意识到要帮助项目经理建立客户关系，但往往不知道建立客户关系的最好时机就是在刚开始进行交接并在启动会议之前。,好的开始是成功的一半。如何帮助交付团队进入客户现场时就树立专业形象及客户关系是交

11、接过程的重要目标。,售前文档交接流于形式,项目立项-项目基线确定,时间(Time, Schedule),范围（Scope）,质量 （Quality),风险,在预算内按时提交满足要求的产品、服务或成果。,成本(Cost, Budget),说明: 在项目立项时，必须明确指定项目基线，包括范围基线、进度基线以及成本基线。,项目基线确定,项目三重制约,范围基线包括实施主体、产品模块、业务范围、报表范围、客户化开发、接口及培训范围。,成本基线包括实施人天、人天成本、差旅费及其他相关费用。,进度基线包括计划开始日期、计划完成日期、里程碑以及检查点等。,销售交接阶段-项目筹备,1.项目定义,1.2 项目筹备

12、,1.3 编制项目管理方案与实施计划,1.4 项目启动大会,1.5 软件安装与部署,1.1 项目立项,了解客户高层的行事决策方式、既定的偏好，他们对项目的态度，并通过分析高层价值主张，介绍项目章程及实施方法论，最终确立项目基调。与高层沟通极其重要，这是体现专业性和取得客户信任的重要过程。,高层访谈如何进行,设定目标,组织内容,选择交流形式,明确信息 安排会见与会议； 讲述我们的工作方法(项目章程及实施法论); 在这一个特定阶段对客户的“答案”是什么？ 分析听众 客户多大程度上准备倾听我们的讯息？包括兴趣、对项目了解程度、顾虑是什么、有什么偏好、可能的反应是什么。 成果 我们对客户的言行有什么明

13、确要求？ 我们的目标是否反应了客户的利益?我们对成功的评价？,预期交流过程中 发生的变化,为一次成功的交流作准备,准备交流 提前3个工作日打印项目章程及电子档提交高层； 约好会议时间及地点，明确参与人数； 准备好交流用PPT。 现场交流 黑板架 讨论大纲 现场展示/幻灯片 交流后 备忘录 项目章程（修改后） 邮件知会,规划角色 清楚自己扮演的角色并且明白自己要演示哪一部分材料，这样你就不会被问题和议论打断，使计划好的进程被打乱。在其他人讲演时，最好对客户提出的问题、建议和决定作记录。 规划角色 通过考虑客户的观点，你就能预计他或她可能会提出什么问题； 书面交流中把答案同问题一起放入全文结构中；

14、 口头交流中可以在问题被提出时就回答，或者简短地拖延一下后面的内容。,情节线索 通过结构化的语言使内容更容听懂，都要以最重要的信息开头使读者或听众对后面的论述内容有所了解。 提供支持 提供论据支持观点。对于重要和有争议的论点提供完备的支持，而对那些已经被广泛理解和接受了的观点的支持一笔带过就行了。 奠定基调 在陈述方案建议时注意尽量明确； 除非有充分的理由,否则避免用消极的语气。,如何进行项目筹备,项目筹备的主要目的是确保项目团队一进场就可以正常开展工作，项目经理在此阶段必须协助客户方组建项目团队、办公环境准备以及共同草拟项目章程。,项目筹备过程中经常犯的错误,项目团队总是一大堆人先进场，进场

15、后很多顾问都不能正常开展工作。 项目未进行充分准备，草草启动项目。 项目团队进场前不进行充分沟通，总是想借用“启动会议”解决所有问题； 多数情况下甲方项目团队安排的成员并不是真正懂自己业务的人，项目经理也不干涉； 项目章程总是直接采用标准模板，没有客户方人员参与制订； 项目章程准备过程中，未充分利用客户重要干系人等资源。,应对方法,协助甲方组建团队,办公环境准备,草拟项目管理计划,约见甲方关键负责人，提供办公室需配置清单，提出完成要求及标准； 办公环境检查合格后才可让团队成员进场； 办公环境5S规定及值日安排。,约见甲方关键负责人，明确甲方项目经理人选，并成立筹备小组； 指导甲方项目经理制订人

16、力资源计划，要求关键用户是那些有潜力提升的公司精英； 通过甲方关键负责人明确关键用户名单，包括业务、财务及IT部门相关人员； 与甲方团队成员建立联系，乙方项目组成员可以陆续进场。,先访谈甲方关键负责人，征询看法及意见； 再内部讨论，提出项目章程的建议稿； 双方召开讨论会，建立理解、一致与必要的约束条件，最终达成共同目标。,销售交接阶段-实施计划编制,1.项目定义,1.2 项目筹备,1.3 编制项目管理方案与实施计划,1.4 项目启动大会,1.5 软件安装与部署,1.1 项目立项,项目管理制度-沟通交流机制,建立完善项目管理制度,1,2,3,4,周例会,月度高层例会,里程碑或阶段目标完成成果汇报

17、,重大变更或突发事件,建立例行沟通管理机制,并使其制度化； 每周召开项目例会，使各级人员能够及时、准确、全面了解项目全貌，并参与提供支持。,为加强与项目领导委员会沟通，每月都将与高层汇报项目全貌，让其了解项目信息； 如有问题或难处，项目经理在会上提出申请并请求双方高层提供相关支持。,当项目出现重大变更或重大问题时，可不定期召集高层及相关干系人参与会议。,在项目关键节点或里程碑点完成将邀请高层参与并作成果汇报。,实施计划编制-项目实施计划表完成步骤,项目计划概要 需求整理 制订WBS 活动序列 工作量估算 计算初步进度表 阶段财务目标分解 确定完工标准 资源分配,资源约束,计划,详细计划开发模型

18、,需求管理,第一步 制订WBS,第二步 活动排序,第四步 计算初步进度表,第五步 阶段财务目标分解,网络图,关键路径、关键事件,第三步 工作量估算,第七步 资源分配,项目整体计划 干系人管理计划 风险管理计划,现实的进度表 资源预测,无员工成本,所有项目任务,项目规则,范围和交付成果,期间估算,员工技能的估算,第六步 确定完工标准,预算,质量目标,在原有TSM的解决方案的基础上继续展开,形成项目整体计划,实施计划编制-需要掌握的方法,EXCEL？ WBS 问题分类、优先顺序 5W2H,例,PDCA,作业：DCA,销售交接阶段-项目启动大会,1.项目定义,1.2 项目筹备,1.3 编制项目管理方

19、案与实施计划,1.4 项目启动大会,1.5 软件安装与部署,1.1 项目立项,项目启动大会,中高层领导培训,销售交接阶段-软件安装与部署,1.项目定义,1.2 项目筹备,1.3 实施计划编制,1.4 项目启动大会,1.5 软件安装与部署,1.1 项目立项,项目定义阶段-软件安装与部署,检查客户的硬体安装,每一套ERP系统软件的功能各有不同，但其相关的硬件架构却是大同小异，主要有以下几项:,软件安装,软件安装与部署实际上包含硬件安装检查以及软件安装，此环节是重要收款节点，需特别注意与小心。,服务器: 运算功能应该视公司所选择的套装软件以及系统使用人数而定 ; 稳定性 指令周期 可升级性,客户端:

20、 需满足系统要求的最低配置；,局域网络: 所要架设的网络包括因特网(internet)与公司内部网络(corporate intranet),进行软件安装的时候，应该逐一的安装、测试，而不是一次安装完所有软件才进行测试。,操作系统: 检查原订给客户部署方案的服务器操作系统以及客户端操作系统。EAS系统支持各种主流硬件平台。,数据库: Oracle DB2 MS SQLServer,ERP软件: 金蝶各产品线，包括EAS， K/3 Cloud及K/3等。,Kingdee Way交付方法论V7.0特性简介 Kingdee Way交付方法论V7.0内容简介 交付方法论框架体系 交付过程 项目定义 蓝

21、图设计 系统实现 上线支持 项目管理 Kingdee Way交付方法论V7.0初步推广计划,提纲,蓝图设计阶段-关键用户产品培训,2.蓝图设计,2.1 项目现状调研,2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,关键用户产品培训-不同的培训方式比较,培训方式 效果（回忆率） 形式 成功要素,解释 举例 实践 通过教来学,70% 72% 85% 100%,10% 32% 65% 100%,讲课 讲义 录像 讨论 实例展示 扮演 模拟 游戏 练习 案例 作业 互

22、动 向第三者解释、演示和辅导,短于20分钟 运用例子分析 短于15分钟 不同视频好的演讲， 而用鲜活的例子 有目的的问题 允许团队去回答问题 有目标的直接的反馈 -具体 -相关 -有深度 -有依据 -实用,关键用户产品培训-关键用户需达到的技能水平,我能在任何情况下运用 “授人与鱼不如授人与渔”,我能在特定场合使用 -知其然，但未必知其所以然,我能理解,1.意识水平,1小时到半天已足够 有限的前期时间投入，大部分是即时的材料,2.基本水平,至少半天到一天以上 需花些时间作前期准备,3.掌控水平,完整的培训项目：指导、实习 长时间内反复练习 大量的前期准备（26个月）,特别提示 关键用户如果成长

23、快，对于越大的项目，其在上线阶段帮助越大，完全可以作为一个顾问来看； 项目组必须要求关键用户得达到第3种掌控水平,而不是目前大多数情况只带着一张嘴来作关键用户,最终上线阶段完全起不到作用； 对于关键用户，乙方项目经理必须对其有考核权。,蓝图设计阶段-项目业务流程梳理(AS-IS),2.蓝图设计,2.2 项目现状调研,2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,项目业务流程梳理-制定业务调研分析子计划,1、就计划与客户确认 2、客户与业务部门确认,1、编制详

24、尽的调研进度安排 2、编制调研问卷、提纲等,1、调研开展的沟通 2、客户准备工作 3、调研计划思路沟通,1、计划编制的准备 2、顾问调研的准备,项目业务流程梳理-调研技巧,关于访谈,充分准备 访谈目的、要点、对象、预约时间、地点 访谈记录、结束后报告 根据谈话方的性格、心情，甚至对方的谈话口气来选择合适的方式和语句 始终对被访者表示尊重和善意 打破砂锅问到底,项目业务流程梳理-进行有效的业务调研,收集到的各类表单、制度、流程,素材类,完善后的调研问卷、提纲、经验总结,组织资产类,调研笔记、问题,过程文件,业务现状报告,交付物,蓝图设计阶段-核心流程分析和模拟,2、蓝图设计,2.2 项目现状调研

25、,2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,流程模拟与差异分析是一个非常复杂且重要的过程，此过程关键是要验证产品功能与业务需求的匹配程度，此步骤业务蓝图是否可以落地的关键环节。,流程模拟与差异分析,差异分析 顾问必须要在原型系统中进行模拟测试，匹配上的部分继续完成业务蓝图，而存在差异的部分，则需要编写需求规格说明书，交给开发作客户化开发； 测试必须严谨深入，尤其是数据的控制逻辑必须测试。,蓝图设计阶段-编写新业务蓝图,2.蓝图设计,2.2 项目现状调研,

26、2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,业务分析及流程优化-业务流程优化原则,找出流程本身存在的问题,缺少关键步骤 重复劳动 (一个流程内或是跨部门) 不必要的文书工作 不完全或冗余的审查过程 不必要的延误 与其它流程、部门、顾客或供应商的接口不够清晰,理解现有系统的限制(比如:数据格式不兼容,硬件容量限制,关键系统间缺乏集成) 确认应用新技术的潜在收益 (比如:提高作业自动化程度, 增加信息的共享程度等.),速效方案主要针对企业需要立即处理的问题,旨

27、在加强风险防范、增加盈利能力或降低成本 速效方案的特点是低投入、短期见效快,业务流程优化原则,通过找出流程本身存在的问题,通过信息系统的应用提升流程效率,制订速效方案解决当务之急.,通过信息系统提升流程效率,制定速效方案解决当务之急,在流程绘制过程中,我们不仅应该理解现有的流程, 更要识别流程改进的机会, 建议的步骤如下:,业务分析及流程优化-流程优化工具清单,技能,怎样利用多重技能来消减各门的界限,提高工作范围与效率?,相关概念: 职能扩大,灵活以及授权,第一时间,怎样保证数据在事件发生的源头录入,并保证其质量?,相关概念: 重复工作,校验,检查全面 质量管理,新业务蓝图设计(TO-BE)-

28、流程设计过程,与核心流程人员协同工作 将流程细化 完成流程的定义 产品功能匹配分析 定义需求和系统功能的差距 开发解决方案 采用流程优化方法论,Level,1,Level 2,Level 3,Level 4,Level 5,流程分解,系统需求定义和确认,核心流程设计,“会议室原型测试”,流程文档,To-be流程文档,业务流程不断细化并融入信息系统实施方案中,流程模拟与差异分析,整个业务蓝图设(To-be)的流程设计过程与后一个工作包流程模拟与差异分析是一个循环过程，不断优化改进，其中存在差异的部分需要作客户化开发需求分析。,流程模拟与差异分析在后面的工作包中详细介绍,新业务蓝图设计(TO-BE

29、)-从功能到流程转化的观点,成功的业务流程重组需要树立从功能到流程转化的概念,功能驱动运营,第一阶段,第三阶段,关键流程驱动运营,电力工程建设,采购,设备维护,客户,采购申请到付款,资产管理,电力项目管理,传统的管理注重职能层级机制,流程概念打破职能层级体制的界限,直达客户,流程得以承认，但功能处于主导,电力工程建设,采购,设备维护,第二阶段,新业务蓝图设计(TO-BE)-业务流程层次分类方法(1),Level 2,1,Level 3,Level 4,1.1.1,1.1.2,1.1.3,1.1.3.1,1.1.3.2,1.1.3.3,1.1,Level 1,流程等级 逐步细化,1层,2层,3层

30、,4层,业务/企业 企业整体的价值链和所有支持流程领域 1级流程图展示了公司运营概况。每个流程框代表了一个业务流程链/价值链。而一个业务流程链/价值链由一系列的相关流程组成产出最终结果,业务的基本流程框架 2级流程图表示了1级流程中的某个业务流程链（价值链）的分解流程。2级流程图中的每个流程框代表了该业务流程链中的一个具体流程,子流程 3级流程通常是在企业的一个部门内部完成的一组流程，3级流程图表示了2级流程中的某个业务流程链（流程框）的分解流程。3级流程图中的每个流程框代表了2级业务流程链中的某一特定流程下的具体工作,子流程中的具体工作 子流程中的具体工作，叙述了具体的程序。记述怎样完成子流

31、程具体工作的步骤,Level 5,5层,工作/步骤 记录了如何完成具体工作和步骤的详细信息。每个步骤都有明确的动作或程序,企业价值链,服务开通,业务受理,开户,系统输入 用户信息,新业务蓝图设计(TO-BE)-业务流程层次分类方法(2),新业务蓝图设计(TO-BE)-流程绘制应注意的要点,不能 按照自己的想象绘制流程 不能 把流程图局限在自己的部门 不能 闭门造车，在真空中工作 不能 在流程范围无法确认的前提下绘制流程 不能 在流程中注入太多的细节,需要 按实际情况绘制流程 需要 在整个组织内思考流程 需要 与流程牵涉的人员交流 需要 在开始前确认流程的起点和结束 需要 有高度、层次感的流程图

32、,需要遵循的原则,需要注意的原则,新业务蓝图设计(TO-BE)-三级流程示例,流程图的组成 流程图标题 涉及部门 部门分隔线 标识符 连线,1,2,标题 宋体 14号 加粗 中间对齐,部门 宋体 12号 加粗 中间对齐,3,连线尽量避免交叉、有时可以适当合并以求简单,框体内的字 宋体 10号 普通不加粗 中间对齐,5,4,不同的选项在连线上标明，与框内字体要求一致,三级流程图示例,新业务蓝图设计(TO-BE)-四级流程示例,流程图的组成 流程图标题 涉及部门 部门分隔线 标识符 连线,1,2,标题 宋体 14号 加粗 中间对齐,部门 宋体 12号 加粗 中间对齐,3,连线尽量避免交叉、有时可以

33、适当合并以求简单,框体内的字 宋体 10号 普通不加粗 中间对齐,5,4,不同的选项在连线上标明，与框内字体要求一致,四级流程图示例,除了流程图，TO-BE还应该包括什么内容？还有很多!,新业务蓝图设计(TO-BE)-展现内容,业务蓝图总卷,业务蓝图分卷,项目模块概述 业务组织架构、业务组织架构列表 模块系统涉及角色表 模块业务应用蓝图 业务流程 目的 适应范围 术语解释 流程图 流程说明 应用价值 系统配置规划 组织单元设置 用户及角色权限 系统参数设置 单据转换规则（BOTP、DAP） 单据套打 审批节点（工作流） 客户化开发报表 报表清单 报表格式及取数规则,只说明需要作什么，具体设置的

34、内容在系统配置文档中,蓝图设计阶段-编制客户化开发概要需求,2.蓝图设计,2.2 项目现状调研,2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,客户化开发需求分析,业务需求,业务需求范围文档,用户需求,用例文档,系统需求,功能需求,业务规则,质量属性,非功能需求,约束条件,软件需求规格说明书(SRS),需求的三个层次及关系,功能需求,非功能需求,外部接口,客户层面,顾问层面,开发SA层面,蓝图设计阶段-编制客户化开发详细需求,2.蓝图设计,2.2 项目现状调研

35、,2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,客户化开发详细需求说明书 的结构与内容,详细需求说明书,引言 目的 文档范围 读者对象 参考资料 术语与缩写 产品说明 产品目标 产品面向的用户群体 产品应当遵循的标准或规范 产品范围 产品中的角色 运行环境,3. XXX系统详细需求 3.1业务报表需求（示例） 3.2通版产品二次开发需求（示例） WBS号 任务名称 菜单名称 参考界面 需求概述 功能需求 3.3第三方接口需求（示例） 3.4全新模块需求（示例

36、） WBS号 任务名称 模块名称 模块功能菜单 E-R图(数据实体关系图) 参考界面 数据需求 功能需求 系统登录方式 权限需求 功能权限 数据权限 安装要求 性能需求 测试用例,详细需求说明书,需求规格说明书的作用？ 需求规格说明书文档可以成为各方人员之间有关软件系统的协议基准。开发者和用户可以使用它作为合同协议的重要部分，涉众也可以利用它在相互间达成一致。 需求规格说明书文档可以成为项目开发活动的一个重要依据。它可以成为软件估算和项目进度安排的基础，也可以成为开发人员判断设计、测试等工作的进行是否正确的依据。 在需求规格说明书文档的编写过程中，可以尽早发现和减少可能存在的需求错误，从而减少

37、项目返工，降低项目的工作量。 需求规格说明书文档可以成为有效的智慧资产。该智利资产可以帮助新加入的团队成员快速融入项目，可以帮助更好地将软件产品移交给新客户，也可以帮助开发者更好地进行其他类似项目或者后续增强项目的开发。,软件需求规格说明书(SRS)的作用,蓝图设计阶段-客户化开发需求确认,2.蓝图设计,2.2 项目现状调研,2.3 核心流程分析与模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,蓝图设计阶段-新业务蓝图确认,2.蓝图设计,2.2 项目现状调研,2.3 核心流程分析与

38、模拟,2.4 编写新业务蓝图,2.5 客户化开发计划制定,2.1 关键用户培训,2.6 编制客户化开发详细需求,2.7 客户化开发需求确认,2.8 业务蓝图确认,新业务蓝图确认业务蓝图评审汇报内容,3,4,2,业务蓝图流程清单及综述,未来系统上线的风险以及风险应对措施(即系统运作需补充的管理制度),1,业务蓝图组织结构,5,未来管理层可获得的管理信息,业务蓝图方案主要改进方向及内容,6,未来系统持续改进点,Kingdee Way交付方法论V7.0特性简介 Kingdee Way交付方法论V7.0内容简介 交付方法论框架体系 交付过程 项目定义 蓝图设计 系统实现 上线支持 项目管理 Kingd

39、ee Way交付方法论V7.0初步推广计划,提纲,系统实现阶段-客户化开发系统设计,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.4 系统测试,3.5 编写用户手册,3.1 客户化开发系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,系统实现阶段-客户化开发,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.4 系统测试,3.5 编写用户手册,3.1 客户化开发系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,系统实现阶段-客户化开发程序发布,3.系统实现,3.2 客户化开发编码/单元测试,3.

40、3 客户化开发程序发布,3.4 系统测试,3.5 编写用户手册,3.1 客户化系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,系统实现阶段-系统测试,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.4 系统测试,3.5 编写用户手册,3.1 客户化系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,什么是测试用例？为什么要编写测试用例？,ERP实施测试用例是根据业务蓝图的流程来进行设计的，必须包含未来在系统实现过程中可能涉及到的所有的场景。设计测试用例，减少测试的不完整性，减少上线的风险； 按照系统测试用例进行测试，可以令系统

41、测试的实施重点突出、目的明确，避免盲目测试并提高测试效率； 根据测试用例的多少和执行难度，可以估算测试工作量，即测试项时间和资源管理； 实施顾问进行的系统测试，可以根据测试用例的执行等级，实施不同级别的测试，目前系统测试主要是流程测试及用户场景测试。,测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例。测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。,测试用例定义,为什么要有测试用例？,测试用例设计方法,可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺

42、陷的表现可以清楚的判定 测试用例包含期望的正确的结果 待查的输出结果必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织,系统测试用例的设计方法,黑盒测试,测试用例组成元素及范例,好的测试用例的特征,至少包含以下几个方面： 测试用例编号ID 测试用例标题 测试的内容 业务流程在系统中实现 基本功能(新增，审核等) 单据转换规则 工作流、套打 角色权限等 测试输入条件 期望的输出结果 其它说明,系统实施的测试是有组织性、步骤性和计划性的，为了能将系统测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例。 测试用例的通用化和复用化则会使软件测试易于开展，并随着测

43、试用例的不断细化其效率也不断攀升。,根据已知程序的功能和性能(而不是内部细节)，通过测试检验每个功能和性能是否正常。,运行测试-测试计划的制订,系统测试是一个典型的团队协作的测试活动。越是规模大的项目，就越需要进行严密的组织及策划，以确保达到较为理想的效果。,Why 系统测试的目的，为什么要作？ What确定要测试哪些内容？ ho谁来做？明确责任者及协助者？ here在哪里进行测试？ When什么时候完成？ ow to明确如何进行及进行的顺序步骤,测试计划制订原则5WH,测试项目简介 测试环境准备（软件、硬件、网络） 测试流程及清单 测试者的分工任务、联系方式与培训 测试进度计划（完成及结束时

44、间） 测试的方法 （测试人员、测试工具、测试流程） 测试开始条件和结束条件 测试提交的结果与格式 测试进度与跟踪方式 测试风险与解决方式 本测试计划的审批与变更方式,运行测试的执行与后续跟踪,根据系统测试计划，将具体任务落实到各部门和有关人员，按规定的数量、质量和时间等规定要求，认真贯彻执行。 根据测试用例的操作步骤以及和Checklist，认真执行好每一步测试，并作好详细记录。,具体执行测试计划,系统测试需要重点关注的问题点,各功能模块间衔接的数据是否会丢失，尤其是数据反写及逻辑关系 一个模块的功能是否会对另一个模块的功能产生不利影响 实现子功能的模块组合起来是否能够达到预期的总体功能（影响

45、到结账） 全局数据结构的测试 共享资源访问的测试 二次开发的功能模块是否与标准功能数据的交互是否正常等,根据测试执行结果，可以方便地书写系统测试报告，跟踪后续问题！,多组织架构系统下的用户权限、参数设置、初始化数据的设置可能不完全一致。因此在测试环境刚建立时就需要编制系统配置方案，不断更新验证，最终保证系统正式环境的系统配置不出现问题。,系统配置说明事项,测试环境,基础数据编码规则 用户权限 系统参数 BOTP(单据转换规则) DAP(动态会计规则) 套打 工作流 .,2,1,系统配置,系统实现阶段-编写用户手册,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.

46、4 系统测试,3.5 编写用户手册,3.1 客户化系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,如何编写SOP,SOPSTDANDARD OPERATION PROCEDURE,SOP是-分角色的操作手册,SOPVS 蓝图,SOP作用,系统实现阶段-最终用户培训,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.4 系统测试,3.5 编写用户手册,3.1 客户化系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,比较合适的最终用户培训方式,最终用户培训相对来说对培训效果要求不是特别高，只要求最终用户能够在特定场合完成具体的工作

47、。但是最终用户培训可能受到的最大挑战是用户数众多以及可能分散在不同的地域。,呼叫中心的模式也是最终培训的一种辅助手段，适用于培训完的事后补充练习答疑用的一种方式。,用户数集中，人数相对较少； 现场教学能较快反映学习成效。,最终用户人数众多，不好集中的一种辅助手段； 需要配合SOP等一起，事后反复练习，效果才好。,WHY培训的目的 WHAT培训的内容（流程及具体操作） WHO关键用户作为培训讲师 WHERE培训地点 WHEN培训时间的安排 HOW TO采取什么培训方式，如何作,培训方案及计划制订,场地布置（教室、桌椅、饮水机等） 培训材料准备 签到表、课程评估表 学员手册（SOP）等书面材料 培

48、训道具、白板纸、白板笔、铅笔、橡皮等 设备检查（电脑、网络、视听器材、投影、灯光、空调等） 自我检查（培训内容是否熟悉等）,培训方式,现场集中培训,培训前准备,在线+视频,呼叫中心模式,系统实现阶段-上线准备,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.4 系统测试,3.5 编写用户手册,3.1 客户化系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,制定切换方案,业务和数据切换策略和方式,切换范围和任务,数据切换策略,切换步骤,业务对策,并行方案,上线支持,组织范围,功能范围,任务安排,数据准备,导入逻辑,静态、动态,数据文件服务器,文件

49、夹命名规则,文件命名规则,上线检查,执行,总体对策,关键数据,关键任务,相关业务,并行时间,并行业务,切换支持,上线后支持,问题预案,基础数据管理规范,基础数据管理规范： 明确需要维护主数据及辅助属性种类 明确需要维护的各模块基础数据种类 定义新旧系统基础数据转换规则 讨论及制订各基础资料各字段属性定义维护规范,制订成手册,明确何种场景使用哪种属性 基础数据管理流程及制度： 基础数据的准确性是系统上线是否成功的关键要素，制订基础资料维护的流程及管理制度，确保数据的准确性 明确各业务组织下的基础资料管理组织及权限，明确提出数据所有者的概念，确保主数据录入是唯一来源 明确各基础资料处理的时限，规定

50、完成时间，以便后续业务可正常开展,系统内组织架构及组织属性设置 各组织权责体系设计 系统角色及相关权限设计 业务流程图基于以上设计才能落地,一（求唯一） 类（分类别） 有（勿有意） 变（避变化） 数（数字好） 短（力求短） 长（长统一） 跳（用跳号）,基础数据管理规范及流程制度确定,主数据规划,基础数据编码规则,基础数据准备要点,常言道：”三分产品，七分实施，十二分数据“。但是在ERP实施上线过程中，由于基础数据不准或管理不完善而造成的问题是占相当比重的。主要原因是由于它数量大且技术性不强，一直以来并没有引起实施人员特别的关注。,企业管理层对企业内部的”数据质量”给予高度重视,严肃对待; 建立

51、数据管理岗位责任制,专人负责; 及时将所制定的标准,以企业公文的形式发布 培训员工,使每个人对数据的重要性有充分的认识,对所经手的数据负责 定期清理数据,调整相关业务流程和操作规范,清除失效数据 采取相应管理措施,对易出问题的数据给予特别的保证,对企业内部数据进行规范化管理与正确检验，保证原始数据与关键数据的准确性,系统上线前,对系统运行过程进行持续监控，及时发现与矫正错误的数据保证系统正常运行,系统上线后,实施中数据质量具体管理措施,基础数据质量的要求 及时性 准确性 一致性 完整性,系统上线,3.系统实现,3.2 客户化开发编码/单元测试,3.3 客户化开发程序发布,3.4 系统测试,3.

52、5 编写用户手册,3.1 客户化系统设计,3.6 最终用户培训,3.7 上线准备,3.8 系统上线,系统初始化的完成意味着系统实现阶段的正式完成，但并不意味着上线成功。初始化过程中最重要的期初数据的处理与检查工作，项目规模越大，数据量也就越大，极具挑战性。,系统初始化,上线动员大会召开,初始化数据检查,初始化（静态与动态数据）,客户”一把手“要参与，鼓舞上线士气,坚定上线决心,作好艰苦作战的心理准备 上线工作安排,明确数据责任者,责任到人 公布上线后的运作体制,初始化完成确认,初始化前作最后一次环境检查,确保初始化可以正常进行 各项静态数据与动态数据指定数据录入的负责人，并按照上线切换计划正式

53、完成初始化工作，如是导入数据需签字确认 按照初始化指南，一步一步指导用户完成初始化,在系统中点击完成各模块初始化之前，需要各负责人进入系统确认数据的正确性,本阶段实施阶段最重要的工作就是完成初始化完成确认单的签署，正式表示进入了上线支持的阶段； 初始化完成后，如有必要，需要将为了初始化工作顺利开展而开放的相关权限（如反初始化等）收回，权限集中管理； 项目组可以考虑逐渐将顾问资源撤离现场，上线支持不需要太多顾问。,Kingdee Way交付方法论V7.0特性简介 Kingdee Way交付方法论V7.0内容简介 交付方法论框架体系 交付过程 项目定义 蓝图设计 系统实现 上线支持 项目管理 Ki

54、ngdee Way交付方法论V7.0初步推广计划,提纲,上线支持阶段-上线辅导,4.上线辅导,4.2 编写总结报告,4.3 召开总结大会,4.4 项目收尾,4.5 实施准服务交接,4.1 上线辅导,什么才能叫作系统上线成功？,系统上线成功是指新系统满足预定目标，即最初SOW规定的能够正常满足流程、业务数据处理需求。通常情况下规模较大的项目在初始化完成后，一定会经过单据补录、系统切换以及正式运转三个阶段，完成后才能称之为正式上线。,第一阶段：单据补录阶段,常见问题,原因分析,应对措施,补录工作量大，会出可能两套账并行的状况，补录数据质量不高 补录期间可能系统流程未能像蓝图设定的业务流程运作,第二

55、阶段：系统切换,第三阶段：正式运转,客户旧系统结账有滞后期，且两套系统基础数据规则设定不一样,会导致单据数量不可能一致 蓝图设定的流程最完整，复杂，客户不愿意补录大数据量的工作,补录单据期间最好集中办公，处理问题周期短，充分利用顾问资源 视频呼叫中心等方式联合使用，及时处理问题,客户不愿意放弃原有系统,还是以原系统为主 系统刚切换时，短时期会出现大量数据质量问题 用户喜欢比较系统的易用性,操作习惯,不适应新系统,用户对新系统不信任，仍然习惯于依赖旧有系统,惯性思维 客户一旦不会操作或出现问题,就会怪罪新系统有问题,行政命令停止原有系统,迫使其在新系统中作业 关键用户需要顶上,消除最终用户的怨气

56、,系统性能在作复杂计算时运行速度缓慢 用户输入数据经常存在错误，但当时发现不出业 用户情绪容易再一次爆发,不容易控制,许多单据作业过程中需要注意的地方客户录入错误 基础数据存在质量问题 结账期间存在大量并发,从源头找出问题,证明系统逻辑性不存在问题,增强其信心 提前准备各种问题的处理对策,让用户知道如何处理 系统部署介入,系统性能优化,系统业务流程及周期性数据已经能正式运转，并且根据不同产品线有不同标志。如财务业务一体化时，会以月底结账作为标识。,问题定义已经发生的风险 问题管理的重点解决问题并防止问题恶化 问题处理程序 问题发现 问题识别 拒绝 推迟 接受 排序 分析解决 问题跟踪 模版 问

57、题纪录单 问题处理跟踪表,上线辅导-系统问题处理跟踪,上线支持阶段-编写总结报告,4.上线辅导,4.2 编写总结报告,4.3 召开总结大会,4.4 项目收尾,4.5 实施准服务交接,4.1 上线辅导,编写总结报告-向客户进行的项目完工汇报,收集汇报信息,目的,具体汇报内容,满意度调查,评估客户满意度 获取将来对客户开展业务联系有帮助的反馈信息 确定项目是否为客户带来了预期的收益 了解是否存在项目二次销售的机会,项目产出、交付物 工作范围，质量 实施的评价 合同和协议的履行表现 客户关系 团队关系 与客户沟通情况 识别问题和解决问题 对未来项目的建议 ,客户反馈会议,方向：感知服务预期服务,上线

58、支持阶段-召开总结大会,4.上线支持,4.2 编写总结报告,4.3 召开总结大会,4.4 项目收尾,4.5 实施准服务交接,4.1 上线辅导,项目实施完成确认的原则,根据SOW约定的范围，所有的项目交付物和资料已经提交给客户后，如项目文档无质量问题，甲方在规定的5个工作日内给予明确答复，如逾期未答复，视同确认本阶段实施工作已完成。当所有阶段工作完成确认单签署完毕且项目具备以下几个条件时，即可视为本项目实施工作结束。,项目实施完成确认的条件,上线支持阶段-项目收尾,4.上线辅导,4.2 编写总结报告,4.3 召开总结大会,4.4 项目收尾,4.5 实施准服务交接,4.1 上线辅导,上线支持阶段-项目内部移交,4.上线辅导,4.2 编写总结报告,4.3 召开总结大会,4.4 项目收尾,4.5 实施准服务交接,4.1 上线辅导,通过对规模较大项目增加实施转服务的规范性检查环节，