IT实施过程中如何管理业务需求

目前,大多数企业IT建设与管理都滞后于业务变革,更谈不上引领企业发展了。对于这些企业而言,IT对企业业务的支撑或者说推动,是由业务需求到了一定程度来决定的。总的来说,企业的IT发展将取决于业务需求,而不是IT投资。

企业的常规做法是比较典型的交钥匙工程,业务部门提需求,IT部门就去张罗方案论证并组织实施,业务部门最后验收评价和使用,IT部门负责系统维护和更新。这样做的结果往往是系统不好用,不适用,或者跟不上业务的发展,业务部门不愿意用,最终成为摆设,浪费了投资,而带来的唯一好处可能是给企业相关人员上了一堂生动现实的用户培训课,花钱买了经验教训。

一般地,在IT项目上线前后,都会做需求调研,并要求业务相关方签字进行需求确认。而在后续的项目推进过程中,一般都会冻结业务需求不做变更响应。这样会造成系统上线后与业务需求匹配存在偏差,需求实现程度又直接关系到项目效果,业务用户要求更改,这又增加系统正式上线时间,影响项目如期验收,IT部门将被诟病。如果项目比较复杂,IT部门害怕出错,前期需求调研时间都比较长,应用推出的周期相应增加,业务部门等待时间过长,满意度也会降低。

因此,为了推进企业IT建设,适应业务管理需要,必须让业务部门深度参与IT建设,充分激活业务人员的主观能动性。如果企业以前没有采用这种模式,可以选择一两个业务部门,试点推行一些节省人力、改善效率的系统,业务部门很快感受到技术的好处,就会带动其他部门逐渐形成主动提出各种需求的习惯。

在IT系统建设和完善过程中,企业都需要积极地管理业务用户的需求,并根据情形对系统进行优化完善。为此,IT部门具有IT项目建设管理、系统维护职能,需要在系统全生命周期中对业务需求进行有效地管理,便显得尤为重要。

一是尝试逐步建立需求量化管理模式,可以从使用角度对需求管理、IT实现程度、业务期望值等方面进行量化,考量项目是否满足业务的期望。以需求管理为例,在开始建立IT系统时,可同步建立用户的使用日志,让管理层、业务层的每一个使用者都可随时了解企业整体系统的使用情况,哪些系统使用的频率更高,哪些功能用的多,哪些功能用的少等。通过这样不断的积累,在企业内部形成这样一种新观念:一个系统用得好不好,首先源于业务部门的需求提得好不好,业务部门应该对这些需求负责。如果业务部门提出一项需求,但实际上并不使用这些功能,说明当初的需求提得并不好。

随着来自业务的需求越来越多,可以进一步引入看板管理,将需求进行分级分类。需求分为功能需求、界面需求、使用需求等,主要的、重要的需求会被写到看板上,让所有人都可以看到哪些需求正在排队,哪些需求正在解决中,哪些需求已经解决完毕,尽量做到公开、透明,能够获得相关部门和人员的理解、支持与配合。

二是IT部门要帮助业务部门更好地提出需求。通过建立良好的沟通模式,IT部门和业务部门共同研究业务变化、需求变更,并深入探讨需求的合理性。IT部门在接到一项需求后,并不马上就投入需求实现的工作中,而是先对需求进行初始化,探究需求背后的动机,了解业务部门的真正想法、管理者的想法、技术人员的想法,各方达成一致。在确定需求的内容合理之后,才会开始进行规划和执行阶段。

对于IT部门和乙方而言,平时最头疼的并非项目型需求,而是来自用户平时的零散需求,或者根本说不清需求,只有一个大概的需求框架。先说前者,零散需求往往来自对现有某一项功能的改进,或者临时需要对一部分数据进行处理等。面对这些零散需求,一般企业的IT部门会采取拖延战术,尽可能不做响应,其实更好的做法则是拥抱需求,拥抱变更。一个好的系统是设计出来的,一个好的系统也是用出来的。一个系统在用户的使用中,必然因为用户的习惯和业务变化,产生各种需求,而IT部门通过小修小补的多次改变,才能逐渐让系统变得友好易用。反之,如果一个系统不做任何变更,用户逐渐便不愿意使用,系统也就荒废了。

至于后者,在业务需求不清晰的情况下,可以暂缓执行需求,应和业务部门继续研究完善。当然,如果有能力,可以先搭建一些原型系统,引导业务部门思考,不断参与系统试用,进一步明确、完善需求。

三是要加强IT部门自身的团队建设。在项目建设过程中,IT团队最好能够相对固定,并且要随着业务发展进行转型。企业IT部门在进行项目管理时,在乙方人员进场后,不能只当“包工头”监督乙方的工作进度,还要领会业务的IT需求和实施方案,进行需求的匹配分析。系统一旦上线,IT团队还是不知道内部的设计细节。基于此,IT团队需要具备更高的技术技能,包括把控需求、设计主要的技术路径,从长远来看更有利于IT团队能力和价值的塑造。

根据个人经验,IT系统建设都是不断的折衷,IT部门、业务部门和承建方三方相互妥协。系统越复杂越是这样,企业要抓大放小,实现主要的功能需求、使用需求和界面需求,一些未尽需求只要不影响大局也可以留待后续升级更新中去实现。从这点来看,IT系统项目建设和新房装修其实差不多,业主方的能力强、考虑问题全面,留的遗憾就会少一些,或者无关痛痒,总体上来说就算是比较成功的了。

时间: 2024-07-30 06:39:10

IT实施过程中如何管理业务需求的相关文章

BI实施过程中的工具与服务

成功的BI项目,不仅仅是应用了BI工具软件,还要具备完善的BI服务体系,才能称之为真正成功的商业智能bi项目. 现在的BI(商业智能)比起几年前的ERP一样,成为CIO们关注的焦点.在ERP等基础信息系统部署完之后,企业能够对其业务数据进行更为有效的管理,如何利用这些数据创造价值成为企业下一步思考的问题.在这一背景下,BI被提上日程.与操作型系统ERP不同,BI是分析型系统,利用BI分析的结果给企业带来商业价值才是BI系统实施成功的重要标志. 2008年,某著名品牌饮料公司宣布其以应用分析系统建

RPA实施过程中可能会遇到的14个坑

RPA的实施过程并非如我们所想的那样,总是一帆风顺.碰坑,在所难免.但也不必为此过于惊慌,因为,我们已经帮你把RPA实施之路上的坑找了出来.RPA实施过程中,将会遇到哪些坑? [不看全文大纲版]●组织层面:1-缺乏当地团队的时间承诺2-缺乏领导力支持3-缺乏IT支持4-缺乏分析/数据功能的支持5-缺乏人力资源支持6-责任划分不明确●流程层面:7-选择了对业务影响微不足道的流程8-选择了涉及更高层次认知任务的流程9-选择了一个子流程很简单但流程本身很复杂的流程10-选择了存在更好自定义解决方案的流

如何在项目设计与实施过程中改变老板?

与其说习惯是最难改变的,还不如说人是最难改变的.人们多年养成的习惯,谁会轻易改变?对于一个相对成功的企业老板而言,企业规模日益扩大.员工数量不断增加.荣誉等身,更关键的是市场征战多年一路走来多以胜利告终,奉迎吹捧的人环绕身边,自信自负理所当然.想要改变老板在多数员工看来都是一句话:"难!,我看难!"对于习惯了靠个人能力管理企业的老板,要改变他真的很难.但是,如果不改变老板单打独斗的习惯.不改变老板"一言堂"的作风.不改变老板"事无巨细亲力亲为"的

记录LNMP多主机架构Wordpress博客实施过程中的一些坑

**首先来介绍一下LNMP** LNMP就是:Linux系统下Nginx+MySQL+PHP网站服务器架构 Nginx是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP代理服务器. Mysql是一个小型关系型数据库管理系统. PHP是一种在服务器端执行的嵌入HTML文档的脚本语言. lnmp都是免费开源软件,组合到一起,就是一个免费.高效.扩展性强的网站服务系统. **整个框架我们可以部署的方式有以下几种**: 使用rpm包逐个主机进行安装及部署: 使用编译源代码的方式

作为项目管理者如何避免项目的延期与执行过程中的加班问题

作为一个项目管理者,最担心的事情就是项目的不能够如期完成:作为一个项目实施者,最担心的是无休无止的加班.项目的不能够如期完成直接导致的是用户或者甲方对公司信誉.能力等各个方面的怀疑与否定,项目实施过程中的无休无止的加班导致的则是员工上班积极性.员工思维等哥哥方面的问题.可以说,这两个方面直接决定着该项目的成败,那么,作为一个项目管理者,应该如何去避免该类的事情发生或者尽可能的减少该事情的发生呢?下面我们分析一下. 1.计划不清 作为一个项目的管理者,项目执行时最怕的就是对该项目没有一个较好的规划

研发环境容器化实施过程(docker + docker-compose + jenkins)

目录 背景介绍 改造思路 容器构建 基础准备 中间件容器 外部依赖容器 业务应用容器 容器整合 自动构建容器 Maven相关 非Maven项目 总结 背景介绍 目前公司内部系统(代号GMS)研发团队,项目整体微服务规模大概是4+9+3的规模,4个内部业务微服务,9个是外部平台或者基础服务(文件资源/用户中心/网关/加密等),3个中间件服务(数据库/Redis/Nacos). 分为2个组,迭代周期为2周.需求和排期都是会有交叉,会保证每周都有迭代内容交付,另外技术部门也在进行性能优化以及代码规约的

第九篇 ERP实施项目中需求分析及方案设计的通用思路

顾问实施ERP就好想医生给患者看病抓药,不但具有类似的过程,而且具有其通用的思路. --详见http://bbs.erp100.com/thread-272856-1-1.html 顾问实施ERP就好想医生给患者看病抓药,不但具有类似的过程(见我的另一篇文章,<顾问实施ERP与医生看病过程类比>,链接:http://bbs.ERP100.com/thread-268545-1-1.html,第二篇),而且具有其通用的思路. 那么,ERP实施过程中,需求分析和方案设计的通用思路是什么呢? 首先,

APP store 上架过程中碰到的那些坑&amp;被拒的各种奇葩原因整理&amp;审核指南中文版

苹果官方发布的十大常见被拒原因 1.崩溃次数和Bug数量.苹果要求开发者在将应用提交给App Store之前彻查自己的应用,以尽量避免Bug的存在. 2.链或错误的链接.应用中所有的链接必须是真实且有效的. 3.占位符内容.有占位符内容的应用将无法审核通过. 4.提交的信息不完整.苹果要求开发者提供所有必须在iTunes Connect的应用审查信息区(App Review Information Section)中提交审查时所需要用到的所有完整信息.这是应用审核未通过最常见的原因,占到了14%

减少过程中的浪费(1/2)

精益生产(Lean Production),简称"精益",是衍生自丰田生产方式的一种管理哲学,商管教育如EMBA.MBA等均对精益生产有所介绍.精益生产在日本近代文化中起到了极其重要的作用,日本政府甚至一度要求凡是企业中层领导,必须进修精益生产. 减少流程中的浪费属于精益生产的范畴,有人把精益生产与六西格玛相结合,成为精益六西格玛. 精益六西格玛 传统六西格玛项目主要解决与变异有关的复杂问题,例如控制一个过程的产品一次通过率.精益六西格玛项目解决的问题不仅包括传统六西格玛要解决的所有问