零售企业软件外包后的开发管理

发布时间：2005年02月05日点击数： 作者：ITGov 来源：本站原创

【字体：小 大】 【收藏】 【打印文章】 【查看评论( 0 )】

摘要:

零售企业软件外包后的开发管理

一、      IT部门的烦恼

一直以来，IT部门总是被动的接受和处理用户提出来的业务需求，IT部门经常抱怨说业务部门提出需求时总是不分轻重缓急，让IT部门无法合理安排需求处理时间；而业务部门也经常投诉IT部门处理需求的速度太慢，导致平白无故的损失了很多商业机会。在国内，即使是专业的应用软件供应商，他们对新技术的痴迷程度也远远超过对潜在商业需求的研究，也许这就是国内商业软件供应商与国际竞争对手的差距。

国内很多企业的需求管理工作做得不是很理想，关键因素是不重视，不仅仅是企业领导不重视，IT部门自身也不重视，业务部门就更不用指望了。很多企业的IT部门都是坐在办公室等待着用户上门来“提出需求”，IT工作人员接到用户需求后也是坐在办公室用“闭门造车”的方式研究解决方法，有的甚至就直接扔给了软件承包商。可想而知，这样开发出来的系统的可行性、可扩展性等肯定是比较差的。

    当前，在中国零售行业特别是连锁零售企业，绝大部分都已经启用了POS系统、MIS和财务管理等零售应用软件。而此中大部分企业的POS和MIS系统都采用外包开发的方式，基本的步骤如下：

1.         公司IT部门与业务部门一起完成业务建模。

2.         公司IT部门与外包商共同完成系统建模和概要设计。

3.         外包商进行数据库设计、代码开发。

4.         外包商负责单元测试和集成测试。

5.         公司IT部门与业务部门一起进行验收测试。

6.         公司IT部门负责新系统/模块的发布更新

这是一个常规的软件开发过程。从用户需求的萌芽到成熟可能经历过一段很长的时间，IT部门了解并掌握需求的精髓也需要一定的时间，需求的维护、管理以及系统的开发测试都需要一定的时间。从用户正式提出需求到新系统发布的时间长短，决定了用户部门对IT部门的满意度！

大部分零售企业的业务涉及的地域、业态都很广，一直以来也没有形成以地域或者业态为主线的管理模式。中国零售市场和供应链的区域特征太强，导致了不同的业态、不同的区域都有不同的业务需求，这在客观上增加需求管理的难度。企业为了应付层出不穷的用户需求，难于采用定期更新系统的方式，不得不用“救火队”的方式（即用户提一个需求就处理一个需求，这种方式对系统的稳定性和安全性的威胁很大），这更助长了用户部门对实现需求的“迫切性”，而IT部门为了救火采取的措施和分配的资源无形中会影响到新系统的质量问题。随着时间的推移，需求缺陷、系统缺陷、系统功能与需求的不匹配等问题交叠在一起，系统的运行质量越来越低，用户对IT部门的服务越来越不满意……

二、      探索解除烦恼的方法

    按照软件生命周期的定义，结合零售业管理软件的开发过程，我们可以把软件系统的生命周期划分成4个阶段：

    第一个阶段是业务模型开发阶段，构建业务架构，定义业务模型和商业用例；

    第二个阶段是系统模型开发阶段，构建应用架构，定义数据模型和功能模型；

    第三个阶段是系统开发阶段，完成数据库设计、模块设计、编码、测试、发布等传统的系统开发工作。

    第四个阶段是持续优化阶段，完成业务功能提升及优化、系统性能扩展及优化等，直到系统的生命周期结束。这一阶段的开发工作不可小视，而且管理难度更大。

    这四个阶段是有严格的逻辑关系的。传统的软件外包业务，第一个阶段是由企业用户完成的，第二阶段和第三阶段都由承包商完成（最后的发布应该是用户与承包商共同完成）。如果企业自己有较强的IT职能部门，那么第二阶段将由企业自己的IT部门完成，承包商可在本阶段后期介入。事实上，通过总结ERP或BPR的实施经验，我们可以发现单独由用户部门完成第一个阶段的工作是不可能的，IT部门必须以较强的资源参与进去，这样才可以定义出较完整的可实现的业务模型。在开发一个完整的系统时基本上是由IT部门配合用户部门完成的，IT部门的工作重点是构建系统的技术架构和应用架构。

但是，随着业务的发展和市场竞争的加剧，用户的需求会不断的涌现，原来构建的系统不可能持续提供完整的支持，改造系统是必然的！这就是前面所说的第四个阶段，这个阶段其实是前面三个阶段的若干次小循环，但每一次小循环之间都可能存在一些关联关系而让这一阶段的需求管理工作变得异常复杂。系统改造工作中存在一些矛盾：需求的不确定性与系统的严谨性；用户对实现需求的时间要求与IT实现需求的时间要求等等。笔者认为解决这些矛盾的有效的方法就是完善需求管理制度并制订科学的系统升级计划。而要制订出科学的系统升级计划，要求IT部门必须对用户的潜在需求很强的敏感度和深入的探索，必须能够捕捉到业务发展方向，捕捉到大部分潜在的关键需求并预测可能的应用时间。否则，原来制订的升级计划将被越来越多越来越迫切的用户需求打乱，重新回到“救火”时代。

三、      两个关键环节

软件外包后，企业在软件开发管理中有两个至关重要的环节，一是需求的导入，二是程序发布管理。

需求的导入是开发过程中的第一个环节。我们常常说“需求管理”，这让用户听起来很难接受，好像管理需求就是控制需求。那么，我们换一个说法，叫“需求导入”。经过多年的实践与探索，笔者认为IT部门只有主动出击“发现需求”，才能够将需求工作变被动为主动，有效改善日趋下降的用户满意度。“发现需求”不但可以让IT人员了解实际业务的运作，也拉近了IT人员与用户之间的距离；同时，发现需求也让IT人员更快更早的掌握用户需求的目的和动向。

新系统的发布是开发管理中的最后一个环节。要管理好整个企业的开发工作，制定并坚持定期发布新程序的制度是必须的，只有基于明确的发布日期，IT部门才能够制定出合理的开发计划、测试计划和发布更新计划。定期发布制度允许IT部门有比较充分的时间来整合需求并能够做到比较充分全面的测试，同时也给了用户比较充分的时间验证需求的合理性和可行性，甚至允许用户在新系统发布前反悔。只有这样做，才是真正意义上的持续优化信息系统。

现代社会中的“服务”强调的是以客户为中心，以客户需求为导向，IT服务也不能例外。“发现需求”要求IT部门应该深入一线作业现场，争取在用户尚未形成定型的“需求”之前发现并实现之，而不是坐在办公室里等待着用户来向我们提出需求。这对传统的IT职能和IT人员的能力提出了挑战！他们需要调整思维方法和工作方式，不断扩充自己的知识领域。

四、      三个要素

笔者认为，成功的开发管理必须具备三个要素：环境、人和方法。

1.         环境

“环境”包括四个层面，一是企业对IT的定位，二是IT对自己的定位，三是组织，四是工具。企业对IT的定位其实就是企业的IT战略和对IT的授权，说到点就是IT在需求管理工作中的权威性和执行权力。发现需求要求企业有比较完整的IT战略规划，同时IT部门有比较高的地位。战略、定位以及组织的设置问题，涉及面比较广，笔者将另外行文详细讨论。工具是执行需求管理的支撑环境，工欲善其事必先利于器，要想真正把需求管理工作做好，一个好的IT内部管理平台是必须的，如IBM的Rational就是一套比较完善的IT管理平台。

这里着重谈谈IT对自己的定位问题。IT对自己的定位主要是指IT部门基于企业IT战略基础上制订的执行计划，落实到需求管理就是对需求管理工作重要性的认识和执行思路。这有这样，IT部门才能真正控制住并执行好预先制订的系统升级计划，才能够合理安排资源深入生产一线发现需求，而又不影响业务的正常发展。在软件外包业务中，企业的IT部门不仅要构建一套“好用”的系统，还要帮助企业各部门“用好”这套系统，因此他们扮演着双重角色：在面对企业内部用户时，IT部门相是一个软件开发者，除了尽可能满足业务需求之外，还必须从系统的角度去保护系统。对系统负责，其实也就是对用户负责，虽然用户是至上的，但如果不分辨用户需求的可行性而一概接收导致系统新出现这样那样的问题，就是对用户不负责任，对企业不负责任。在面对承包商时，IT部门是一个标准的用户，必须尽最大可能保证用户需求正确及时实现。这两个角色本身是一对矛盾，企业的IT部门集这对矛盾于一身，为IT部门的决策和定位带来了巨大的挑战。IT部门的决策者必须将定位贯彻到部门的每一个员工，并要找到有效弱化矛盾的指导方法。

2.         人

对于“人”，关键是观念或者认识的问题，然后才是人的能力问题。在社会分工越来越专业化的情况下，笔者是赞同软件外包方式，但软件外包的优势不在本文的讨论范围之内。很多软件外包的企业都认为自己应该具备一定的或者较强的研发职能，但大多数都错误地认为找一帮编程高手就能建立起研发队伍。笔者的观点是，对于软件外包的企业，研发的重点是业务模型开发、系统模型开发和持续优化三个阶段的工作，而不是源代码的开发，这里的核心问题是需求，我们必须确保需求的准确性、完整性、合理性和及时性，这或许要求我们付出很高的代价，但也是值得的。要完成这样的研发职能，对研发组织的要求是：较深的行业背景、对企业文化的高度理解和认同、专业的IT架构设计等知识，以及持续深入跟进一线的运作情况。这些知识，并不是外聘的编程高手或者业务专家所完全具备的，更重要的是企业自身必须有一套健全的内部培养机制，从基层开始发掘、培养出符合这些要求的复合型人才。

3.         方法

    “方法”问题也很复杂，各行各业甚至是相同行业不同的企业都有不同的方法，关键是要适合企业自身的发展需求。笔者在这里谈谈自己在实践中总结出来的经验。

首先要弄清楚需求管理与流程管理的关系。流程，当然由专门的流程管理部门负责制订、监督和优化。发现需求，并不是要求IT部门去主导流程管理工作，而是要求IT部门应该先于流程管理部门找到流程变化的趋势，有计划、有针对性的扩充系统功能和提升系统性能。扩充后的系统不是要把原有的功能砍掉，而是要包容原有的功能并能在一定程度上支持可预见的流程变化。因此，系统功能的每一次扩充，不仅仅是简单的功能堆叠，更重要的是开发出更强大的可配置特性，让系统能适应多种不同的管理需求。

要做到真正意义上的发现需求，将被动式的需求管理变为主动，要求需求管理员必须深入基层，掌握一线业务的运作情况，发现用户潜在的需求点。这些需求点应该是分布很广泛的，不仅仅局限于系统，在系统方面也不仅仅局限于系统的功能，还有性能、安全性，以及新技术、新的行业解决方案的引进等。例如：哪些手工操作有可能用系统来取代？是否可通过提升系统功能来提高收货速度？系统的性能是否已经逐渐成为降低工作效率的主要因素？是否可通过改善系统的权限管理功能来增强系统的安全性？可以引进哪些新的技术来解决当前的业务瓶颈？

五、      在需求工作中的实践与扩展

在日常工作中，笔者采用了4步自我提问的方式来指导日常的需求工作，并将这个方式传授给员工，自我感觉良好：

1.         （可以）怎样做？对于新员工，首先应该弄明白每一个与系统相关的事务是怎样完成的；或者老员工面对新的事务时，应该我们构思可以怎样去完成这个事务。

2.         为什么这样做？当知道怎样做以后，我们还应该知其所以然，搞清楚为什么这样做。

3.         这样做是否合理？鉴于企业的实际运作情况，很多事务涉及到多个不同的责任部门或人的权责关系，最终的执行流程是这些部门协商后的结果，极有可能存在某些不合理的地方。

4.         有没有更好的方法？合理的并不一定是最优的，我们应该努力的寻找出更好的解决方法。

这4个问题前后连贯，层层深入，可以帮助我们挖掘出每一个事务的本质特征。不管笔者在实际工作中扮演的角色是需求管理还是职能管理，始终坚持用这种思路去审视每一个业务需求，较好的保证了大部分需求的质量和前瞻性。

在实际工作中，我们可以将以上所提的“需求”延伸到整个开发过程乃至整个IT服务领域，即对公司IT服务功能所提出的需求，可以大大提高IT部门的服务水平。