吴文钊wuwenzhao复制地址
控制面板
日历
<2008年8月>
SuMoTuWeThFrSa
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456
留言簿(9)
随笔档案


    如果CIO们强调企业需求的实现,强调系统运行的稳定,强调投资的适度,它的目标是实现系统的成功运行,那么他们一定可以发现这份合同中潜藏的风险和危机。

    这份合同存在“目标与需求、客户化管理、服务与维护、实施管理”四大漏洞。其中:服务与维护和实施管理的风险应对,在前面的章节中已经做了较为系统的介绍,在这里将不再重复。下面将就目标与需求和客户化管理在合同中存在的风险以及如何应对风险,提出相应的解决之法。

    目标与需求的风险
    让我们重温上面合同案例中的若干条目,从中可以发现目标的风险,企业需求的风险。读者可以看到,在这份合同中明确了以下几点内容。

    第一,它通过如下内容,明确了合同的范畴,在合同中写到:
     甲方确认由乙方承担销售管理信息系统软件的客户化、实施以及技术支持与服务。
     本合同所涉及的系统包括销售管理信息系统软件中的分支机构的销售管理、采购管理、费用管理、客户管理、应收应付管理等,具体功能提供以《销售管理信息系统软件功能列表》为准(见附件一)。
     本合同涵盖的范围指项目所涉及到的管理系统的客户化、实施、培训和技术支持,除此以外的其他系统以及有关硬件设备和系统软件的购买、安装、调试、售后服务等工作不属于本合同范围。

    第二,它明确了需求的来源,是以现有的标准软件功能为基准,这个功能基准是以合同附件的形式存在,在合同中写到:
    本合同所涉及的系统包括销售管理信息系统软件中的分支机构的销售管理、采购管理、费用管理、客户管理、应收应付管理等,具体功能提供以《销售管理信息系统软件功能列表》为准(见附件一)。

    第三,它明确了不属于自身工作的范畴,在合同中写到:
    本合同涵盖的范围指项目所涉及到的管理系统的客户化、实施、培训和技术支持,除此以外的其他系统以及有关硬件设备和系统软件的购买、安装、调试、售后服务等工作不属于本合同范围。

    从表面上看,在上述内容明确后,甲乙双方似乎已经看不出需要补充的内容。但是,如果仔细研究一下还是可以看出这份合同种存在的“目标”、“需求”的漏洞。

    一份有效的信息系统合同需要明确系统的目标,它是项目目的的保证,也是对信息化需求的整体性描述,是衡量信息系统能否取得预期效果的核心标尺。在国内信息化建设过程中,甲乙双方经常忽略这项内容的存在,使得没有人清楚这个系统是为何目的而存在。下面是一家图书出版企业为信息系统项目所确定的基本目标,通过目标读者不难看出它存在的价值。

    强化销售管理,加速资金回笼:出版发行部的500多家代理机构分布全国各个省市,在现有手工管理体系下,各地的分支机构,无法对每家代理机构的销售信息和应付信息无法迅速归集到总部的财务部,同时财务部也无法动态、准确地了解每家代理机构的欠款情况,这为财务部对于资金的有效管理带来了非常大的难题。

    加速库存周转,合理调配图书:由于出版发行部在全国设置了三大仓储中心、以及遍布全国的30个周转仓库。从出版发行部集中管理的角度上,需要动态了解每种图书在全国各个地区的动态库存,以及每种图书的滞销程度、畅销程度。通过对全国库存的动态监控,实现合理调配各种图书在全国的分布,加速库存的周转,实现图书在全国的库存调配。

    掌握市场动态,安排印刷出版:通过信息系统,实时了解各地区、各种类别图书的销售情况,动态实现排产,动态实现印刷材料的采购。并通过市场销售信息的反馈,和对反馈信息的有效跟踪,为选择出版内容、出版议题、图书作者提供参考。

    改造流程规则,实现精细管理:手工的管理方式无法实现渠道管理的规则统一、流程统一、方法统一,也无法实现出版选题、排产计划、采购计划的精细管理。也无法实现出版管理过程中各个环节的绩效管理。通过全面的信息系统的建设,加快企业内部的精细管理改造。

    在这一管理目标中,涉及到了信息系统建设的八大核心目的,“渠道管理、收付管理、库存管理、出版管理、印刷管理、精细管理、绩效管理”。如果在合同中没有明确这些内容,那么你所看到的需求都将是散乱和无序的内容。

    那么如何看待这份合同中对于“需求”的描述呢?将一个企业的需求置于以软件功能列表为基准的方式是否明智和准确呢?如果企业的CIO们、企业的管理者细究这个疑问的时候都会众口一词地回答“这种方式一定不能够满足我们的需求”,但在这份合同签署的时候又有谁提出了异议呢?显然没有,产生这个问题的核心原因,是企业的信息化人员与软件商或实施服务商都把这份合同当成了一份“商务合同”,这就是问题的关键。

    在本书的前面几章中都对需求存在的价值和需求的写作方法作了详细的介绍,相信读者看到这个问题,都会在未来的信息化建设中、信息系统合同的内容中关注“需求”。我们都知道,需求本身是有严格的界定的,规则是需求、表单是需求、算法是需求,战术是需求、策略是需求。如此众多的需求,不可能通过一份功能列表来解决,也不可能通过客户化的承诺来解决。

    众所周知,在未开展需求调研之前,软件商不清楚需求的复杂度、企业的人员也无法评估需求的复杂度会对软件的客户化带来多大的影响。如果难度很大,不但合同中所制定实施计划无法按时实施,工期被迫推迟,更重要的是,软件商或实施服务商可能无法承受软件需求难度的大幅度提高后,所需要增加的人员上的投入、资金上的投入。下面的情景是这种需求不明确下所产生的问题的写照。

    “当软件公司在签完合同之后(且第一笔款已付),一切的主动权似乎已经被软件公司所掌握,在软件公司的需求人员提交他们的需求报告之后,第一次双方的冲突就开始了,双方为需求报告上的不同要求和内容展开了第一次交锋,而这种交锋的结果只会得到妥协后的需求结论,这种结论确有可能会使企业的系统目标留下缺憾”。

作者:吴文钊 阅读() 评论()  编辑 发表于:2008-06-11 09:42
文章评论
发表评论

标题 *  
姓名 *  
主页
内容 *  
   验证码: *