运营管理的范围有哪些(项目管理论文之范围管理)

(摘要)

2020年1月,我参与了浙江省XX集团公司一体化管理信息系统项目的建设。并担任了建设方的项目经理,负责项目的管理工作。该项目为集团信息部献礼集团公司成立40周年的重点工作,主要是按照为集团定制开发一体化的综合信息管理系统,提供给集团旗下105家门店、3家子公司和集团总部使用。系统从数字化管理、数字化运维和数字化营销三个方面,帮助集团实现数字化转型,提高工作效率、较低成本,提升竞争力。项目总投资280万元人民币,工期12个月。项目于2021年1月,顺利通过业主方验收,获得了业务方一致好评。本文结合作者的实际经验,以该项目为例讨论信息系统项目建设过程中的范围管理,主要从规划范围管理、收集需求、范围定义、创建WBS、范围确认和范围控制这几个方面进行论述。

(正文)

2020年1月,浙江省XX集团公司委托我公司定制开发一体化管理信息系统。该系统需按照客户方的实际业务需求和工作流程,进行定制化开发,并提供给集团旗下105家门店、3家子公司和集团总部使用,系统主要实现日常业务处理的数字化、流程化,运营决策的科学化、智能化。并通过系统的建设帮助集团实现数字化转型,提高工作效率、较低成本,提升竞争力。该项目总投资280万,工期12个月。我被任命为该项目的项目经理,负责项目的管理工作,直接向项目总监汇报。

该系统采用B/S架构,使用JAVA语言开发,数据库使用oracle11g,中间件使用weblogic,操作系统使用linux,并采用nginx进行负载均衡部署。该系统主要由门店收银管理系统、日常事务管理系统、客户管理系统、仓库管理系统、财务管理系统、人事管理系统、经营管理系统、报表管理系统和智能决策分析系统等核心子系统构成。并针对门店、员工、客户和管理人员等使用群体,提供了对应的门店端(PC系统)、员工端(APP 应用)、客户端(微信小程序)和管理端(PC系统)等产品。

下面我将结合本项目从制定范围管理计划、定义范围、创建工作分解结构、核实范围、控制范围这几个方面对项目的范围管理进行介绍。

一、 规划范围管理

运营管理属于什么行业门类

作为一名合格的项目管理者,做任何事之前都应该先做好计划,好的计划,是成功实施项目的基础,有些人认为做项目范围计划花费了太多时间,不如把它们用于执行工作,项目将会更快更好的完成,我认为这是一个错误的想法,通过省略范围计划制定,虽然能短暂时间内节省一定的时间,但在长期内常常会因缺乏管理计划指导而使得范围定义不清、范围蔓延、以致无法完成项目。

因此,在该项目中,我非常重视范围计划的制定,在正式做计划之前,我先查找了公司组织过程资产,找出制定范围管理计划的模板,再结合以往项目的经验。制定出一份初步的计划,然后召集项目团队成员开会讨论,对计划进行修改和完善,在全体参与下,最终完成了一份详细的、科学的范围管理计划,用于指导项目如何定义、分解以及确认和控制范围。

二、 收集需求

为了实现项目目标,必须要充分的了解项目的需求和需要。在项目的早期阶段,我带领我的团队,到了客户现场收集需求,我组织了客户的运营部门、财务部门、IT部门以及我们的需求团队,召开需求讨论会,共同商讨项目范围。在收集需求的时候,客户有时候需求描述的不是很清楚,造成了双方对需求理解有歧义,甚至有时候客户对于其需求自己都不清楚,只有一个模糊的概念;针对这种情况,我采用原型法将收集到的需求,做成demo模型供客户参考确认,以此消除彼此的歧义,充分挖掘用户的需求,并基于团队自身的经验以及专业水平,对客户的需求进行引导、细化,将其模糊的概念形象化,粗糙的需求具体化。并将各类需求进行记录、汇总和整理形成项目需求文件。

三、 定义范围

需求收集完后,需要对各类需求进行确认,确认哪些需求包含在本项目范围内,哪些需求将排出在项目范围外。为了保证这一点,就需要在项目前期定义一个明确的项目范围。基于需求文件,我召集了项目的主要干系人进行开会讨论,同时邀请了系统的最终用户代表(包括甲方的店员,库管、客户等)对系统功能做评价,通过用户的角度,去发现和改进系统的功能,以此最终形成了完整的项目范围说明书。主要包含:1、产品范围描述(包括收银管理、客户管理、事务审批、运营管理、财务管理、人事管理等)2、产品验收标准(系统运行稳定、功能满足业务需求、相关文档齐全等)3、项目的主要可交付成果(用户文档、应用系统、源代码等)4、项目的除外责任(该项目涉及的信息系统基础实施改造,人员考勤、测评和财务报税等在该项目范围中)5、项目制约因素(项目已确定的预算、项目重要的里程碑时间等)6、项目假设条件等。

四、 创建WBS

基于项目范围说明书,我和我的团队开始对项目范围进行分解,以形成该项目的 WBS。在分解过程中,我首先召集项目团队对需要分解的内容进行分析,经过讨论,确定按照子系统的结构方式进行分解,并将各子系统分配给对应的团队小组,由小组负责进一步的分解任务。并采用表格的形式编排,自上而下分解。待各小组分解完成后,统一进行汇总,在通过研讨会,讨论各子系统分解的是否合理,对不合理的地方进行优化调整,最终形成项目组一致认可的的WBS和WBS词典。

在分解工作中,我按照以下原则进行分解:WBS必须是面向可交付成果的;WBS必须符合项目的范围;WBS的底层应该支持计划和控制;WBS中的元素必须有人负责,而且只有一个人负责;WBS分解最好控制再4-6层,且一个工作单元只能从属某个上层单位,避免交叉从属;WBS还应该包含管理工作,也要包含外包工作;各子系统的分解需要小组内所有人员参与;WBS分解的,最底层工作包应该满足8/80原则,即一个人工作1天到2周的工作量。

五、 确认范围

范围确认并不是件容易的事情,在与客户的沟通上,我们希望客户尽快确认以便尽快开展后续的开发阶段工作,而客户则可能认为自己什么也没看到,怎么确认呢?针对这种情况,我在提交文档给到客户的相关干系人后,重点对客户的IT人员进行沟通培训,详细介绍系统的设计,然后用他们的声音去向客户的业务部门做出介绍,这样既有益于专业人员之间的技术沟通,也有益于客户业务部门对系统范围的认可与信任,同时,在与客户的沟通时,我重点强调,虽然范围确认是正式的,但这并不意味着项目的范围就是铁板一块,不能再修改了,只要走标准的变更流程,且审批通过的,都是可以进行变更的。这样就消除了客户的顾虑,便于快速,高效的完成范围确认。

六、 控制范围

控制范围就是监督项目的范围状态,管理范围基础变更的过程。在此项目中,我定期组织召开项目状态审查会,审查项目的范围,通过对照范围基础,找出范围偏差,并做分析,严格杜绝一切的范围蔓延以及镀金。

例如:在一次状态审查会上,我发现项目的功能模块中,系统管理以及库存管理模块多了登陆日志以及盘库两块功能,我查了一下系统变更日志,未找到有类似的变更记录,于是我参照责任分配矩阵,分别找到这两个模块开发的负责人询问原因,A成员告诉我,他增加登陆日志这个功能,是因为客户在一次电话中,向他提过希望在系统管理模块中加一个登陆日志的功能,B成员则是因为在开发库存管理模块时,发现整个库存管理没有库存盘点的功能,他认为做库存管理,肯定需要用到盘点功能,而且这是个亮点,所以他私自增加了这一功能。针对这两种情况,我首先向这两名成员强调了范围基准、以及变更流程的重要性;其次,针对这两项多出来的功能,我要求相关人员提交正式的变更申请,走正常的变更控制流程。

从事项目管理工作的我深知,项目范围不是一经定义,就一成不变的,项目干系人出于项目利益以及各种情况考虑,总会有一些需求变更,管理这些变更,就需要在项目规划时,就制定好变更控制流程以及成立一个专门的需求变更控制委员会(CCB),因此,我和我的团队在项目早期就制定了一套标准的变更流程: 1、提出变更申请;2、对变更进行初审;3、对变更方案进行论证4、提交项目管理委员会(CCB)审查;5、审查通过的,发出变更通知并组织实施;6、对变更实施进行监控7、对变更的效果进行评估;8、判断发生变更后的项目是否已纳入正常轨道;有了这流程以及CCB 的控制,项目的需求变更得以良性发展,变更带来更多是项目利益以及效率的提升。

经过我和我们团队的不懈努力,本项目终于与2021年1月,通过了业主方组织的验收。通过系统的上线运行,替代了传统的手工模式,实现了集团业务办理的在线化和数字化。加强了内部管理,实现了事务处理的流程化、规范化,并为集团的经营决策提供了智能化、科学化的数据支撑,以数据为驱动,提高管理效率、较低成本,提升竞争力。经过半年多的运行,得到了业主的好评。

项目最终能成功完成,得益于我在项目中有效的范围管理,采用科学的范围管理方法、工具和技术,为项目的范围管理带来了事半功倍的效果。同时,在该项目的实施过程中,也出现了一些问题,本人觉得处理的不是很好,主要在于项目中的冲突管理以及项目风险识别方面还存在不足,后续我将加强这两个方面的学习与知识积累,不断提升自己的业务和管理水平,力争为我国信息化建设做出自己的努力。

您可以还会对下面的文章感兴趣

使用微信扫描二维码后

点击右上角发送给好友