目录
1.需求提出
需求提出的几个原则:
- 需求的提出必须满足对于业务的发展适用的原则,量化需求价值目标,围绕提质降本增效推算出具体的价值金额(按照1年计算)
- 因业务整体需求而需建设新的信息系统,需要纳入年度预算,预算外须发起项目立项申请。
- 提出的需求必须符合现有在执行的流程或制度,因业务需要确需调整,须先进行流程的优化或制度的修订,依据新的流程及制度提交IT需求;
- 提出的需求需切合实际,逻辑清晰并描述清楚、具体,禁止提报不明确的IT需求。
- 用户在使用现有系统时,发生的导致业务无法正常开展、系统/功能无法正常应用、或数据出现错误的故障不属于需求,须提报IT问题反馈/服务请求处理流程。
2.需求评估
需求管理人员在接收到业务部门的需求后需要对需求进行了解,需求了解采用访谈、文档、会议等形式收集基础信息。了解完需求后需要对需求进行初步评估,以此决定下一步处理方式,主要评估原则及处理方式如下:
- 评估是问题还是需求,如果是问题则驳回申请并告知需求提出人提交IT问题反馈流程;
- 评估需求合理性,是否与当前运行的制度流程冲突,若冲突驳回申请并告知理由;
- 评估投入产出比,预估投入成本,成本按照如下公式计算:成本=消耗人天*人天单价,其中消耗人天=沟通周期+开发周期+测试周期,自主实现人天单价=人员月标准工资/当月标勤,外包实现人天单价通过第三方询价获取,如果投入成本高于收益价值,则驳回申请并告知理由;
- 若需求合理,则预估需求实现周期,并与需求提出人员沟通确认期望解决日期;
- 指派需求处理人员,优先指派负责相应IT系统或硬件的负责人,若无相应责任人则采取需求认领或上级指派方式;
- 评估需求类型,按是否属于年度预算范畴分为预算内和预算外;按需求难易程度分为简单需求和复杂需求;按需求服务对象分为决策类需求、管理类需求及操作简化类需求。划分原则如下:
| 需求类型 | 具体分类 | 划分原则 |
| 按预算区分 | 预算内 | 属于集团及各事业部预算内的需求 |
| 预算外 | 不属于集团及各事业部预算内的需求 | |
| 按复杂度区分 | 简单型 | 可通过自主配置实现并且实现周期在2天内 |
| 复杂型 | 通过自主开发实现周期2天以上或自主开发无法实现 |
3.需求审批
需求须经过审批后方可实施,具体审批流程与分类如下:
- 预算内:预算内需求已在各单位每年度的预算汇报评审中通过,无须单独审批。
- 预算外(简单需求):申请人提出—申请部门负责人审核—需求管理员评估—信息部门负责人审核
- 预算外(复杂需求):
- 集团总部:申请人提出—申请部门负责人审核—需求管理员评估—中心负责人审批—集团信息部门负责人确认。
- 各事业部:申请人提出—申请部门负责人审核—需求管理员评估—单位负责人审批—本单位信息部门负责人确认。
4.需求落地
需求处理人员接收到审批通过的需求之后,需要确定需求的优先级,优先级以价值创造为原则按照以下公式计算排序,即需求优先级=需求价值/成本。
按照不同的需求实现方式制定实现计划:
- 对于可自主开发实现类需求,按照优先级列入部门月度工作计划;
- 对于需要建设新信息系统或在原有系统基础上进行二次开发的需求按照项目管理规定开展项目立项等相关工作;
根据制定的实施计划,需求负责人开始针对需求制定具体的解决方案,并与提出部门沟通确认。若需求涉及到多个业务部门,须需求提出部门组织相关部门对需求解决方案进行评审,主要评审需求的目标、收益以及需要相关部门配合的工作内容等。如果需求评审通过,则进入需求实现阶段,评审不通过,则此需求撤销或终止。对于不可行的需求进行撤退或终结,对于可行的需求及时开展后续工作。
5.需求验收
信息部门须对需求实现成果进行验收与总结,在需求上线运行一个月后进行需求验收,业务部门对需求实现的运行状态及效果进行描述及评价并进行用户满意度评估,发现问题通过需求的持续迭代进行改进,以此实现需求的闭环管理。
6.需求变更
需求应尽量避免变更,确实因业务或技术环境等原因发生需求重大变化的,须重新发起申请流程并审批通过,原需求关闭。
7.需求持续迭代
跟踪需求实现的运行效果、用户反馈并通过《需求跟踪表》记录,收集和主动挖掘改进需求,根据业务需求持续改进,提升用户体验。
对于已经满足的需求,特别是共性需求,由信息部门安排计划进行必要的共享、推广。
本文详细阐述了企业中IT需求的管理流程,包括需求提出、评估、审批、落地、验收、变更和持续迭代。需求提出需遵循业务适用原则,评估涉及合理性、投入产出比,审批分为预算内外并涉及不同层级,需求落地依据优先级制定计划,验收确保需求效果,变更需重新申请,而持续迭代关注需求优化与用户体验提升。
698

被折叠的 条评论
为什么被折叠?



