项目的性质：过去和现在
IT 业内早期的项目比较直接，简单。大部分是把企业内部的运作进行自动化，例如薪资管理系统，库存管理系统等。这些项目的范围可以从功能部门的工作内容，和雇员的工作说明，按人工运作流程等方面搜集功能需求，进而建立项目的范围。
到了今天，大部分的项目是从概念进而立项，成为项目。例如一些网站的建设，或客户关系管理（ CRM ）系统等，这些项目都是跨部门的需求，而且没有任何模式可以依从。在客户来说，功能需求也只是一个很模糊的概念，当我们接收一个类似的项目开始进行交付的时候，最感觉头痛的问题便是如何建立整个项目的明确范围，建立项目的功能需求。不但合约的服务内容常常含糊不清，或者只有一个服务框架的说明，让很多技术人员发觉合约签订后所建立的『范围』内包括的工作和交付物，绝对不能按合约签订时的服务价格和指定的工期内可以『成功』地把项目完成。
建立项目的范围
上世纪 80 年代中期，一些编程工具开始提供系统快速示范模板建立的功能，利用『快速应用开发』（ Rapid Applications Development 简称 RAD ）模式进行系统开发，利用工具建立一个示范程序，让客户可以看到一些结果，从而启发客户对系统的功能需求，一些技术人员认为只有采用这模式才能够建立初步项目范围，可惜这是一个错误的观念。
任何一个客户在决定投资系统开发的时候，肯定已经很明确的知道这系统所能够带来的商业效益，不然客户绝对不会花费这笔系统开发的费用，签订有关的合约。纵然是内部的系统开发，要没有一个商业效益，企业绝对不会投资在系统的开发项目。
当我开始负责加拿大满地可银行的客户关系管理（ CRM ）系统建设的时候，银行对这项目的目标和最终效益有一个明确的指示：了解客户对银行的服务要求，提供客户所需的高效、优质服务，为银行建立准确的客户财务信息，提升客户对银行的满意度，提供客户财务投资机会和建立客户的财务记录，包括个人帐户，跟个人有关的企业帐户，信用卡、贷款、投资、按揭等信息。
从表明上看，我们可以从不同的现有数据库内有关客户的记录进行汇总，建立有关的客户数据库，让银行能够得到有关信息来管理客户的关系，但客户信息管理只是项目的一部分要求，如何才能够了解客户对银行服务的要求，如何提升客户对银行的服务满意度，如何为客户提供所需的高效优质服务呢？这些都是整个项目的最终效益要求，如何才能够达到这些要求呢？
为效益建立定义
首先我们为这些效益建立个别的定义。我们组合了十数名跟银行关系密切的客户，包括企业客户和个人客户，共同进行效益定义的探讨，同时在不同的分行内为客户进行调查，以服务范围和服务态度等方面从中了解客户对服务的要求和满意度。我们从实际客户口中和客户小组的研讨过程中建立有关的效益定义，了解客户对银行服务的实际需求和期盼，也了解客户所希望达到的服务水平和质量要求。
从客户的服务需求中我们明确地知道客户希望银行能够为客户进行全面的理财服务，而且希望能够让客户在实际的服务需求前有足够的时间进行分析和决定，同时能够为客户提供财务的状态分析，让客户能够全面掌握本身的财务管理信息。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
