用"好工具"整合业务与技术需求
用"好工具"整合业务与技术需求
王磊 IDS Scheer中国副总裁
业务需求描述的环节，是一个信息化项目得以顺利进行的基础。而在众多项目中，该环节往往会出现前期业务需求的描述不够明确，从而导致项目后期不断变更需求设计的情况。
在项目中，对于业务需求的描述往往是由精通业务的人员进行的，但这部分人员通常又是企业内部最为忙碌的人员。因此，在描述业务需求时由于不能有充足的时间来反复斟酌，从而使得所描述的需求比较粗糙。
另外，咨询顾问要求业务人员用来描述业务需求的工具太过专业，使得业务人员无法用这些工具来很好地表达自已的想法。
比如，传统的做法是先画流程图再填需求调研表，这种画图加填表的方式等于是将基于业务需求梳理软件开发思路的工作全部交给了业务人员，这对于以业务操作为主很少接触信息化管理系统的人员来说，确实是勉为其难的。
正是由于上述情况，所以又会经常出现在项目后期业务人员不断提出新的业务需求或不断变更业务需求的情况，从而给咨询公司顺利完成系统的开发和配置带来很大的压力。
针对上述情况，笔者认为由业务人员进行需求描述这一点应该是要坚持的一个方向。咨询顾问通过调研整理出业务需求并请业务人员进行确认的做法，其准确性和完整性被大量实践证明是很差的。
问题的关键是应该给业务人员提供一个很好的工作平台，在这个平台上业务人员能够用业务的语言比较高效地进行需求的描述。而这种用业务语言描述出来的业务需求又能自动转成IT人员所要的技术信息，以便于咨询公司进行系统的开发或配置。
那么需要给业务人员提供一个什么样的业务需求描述工具呢？笔者认为，这个工具平台应该采用业务人员的工作语言。比如，描述一个业务流程，业务人员只要讲清楚做什么事，谁来做，目前需要用到什么样的数据或表单等即可，不用涉及专业的技术术语和概念。
但为了今后能基于此导出IT人员需要的信息，因此对于这些业务要素的描述应建立统一、标准、图形化的流程描述语言、方法和标准。比如，流程的操作、执行者、输入输出等要素的表达符号、形状、视图格式、关联逻辑等都应该有一个统一的规范和标准，流程要素的定义无二义性。 总而言之，应该有一套用业务语言统一起来的业务需求描述的建模规范，这套规范起到了联系业务人员与咨询顾问的作用，使得业务人员可以用自已的语言进行需求的描述，而咨询顾问又可以基于此得到所要的技术信息。
IDS Scheer 公司的创始人希尔教授早在上世纪八十年代就提出了将业务语言与技术语言相结合的ARIS业务流程描述规则。经过20多年的发展，ARIS业务流程描述的房式结构已经成为一种业界的规范和标准，被大量的企业所采用。
那么，有了一个好的工作平台后，是不是对于业务需求描述的责任全在业务人员呢？笔者认为，以业务人员为主进行业务需求描述是需要坚持的一种做法，但这并不意味着咨询顾问只是起一个收集和分析信息的作用。在业务人员进行需求描述的过程中，咨询顾问是应该全程参与其中的，咨询顾问应该起到一个指导和共同梳理的作用。
从某种意义上来说，是双方共同完成业务需求的描述。笔者反对的是传统的由咨询顾问对业务人员进行调研，然后由咨询顾问出具需求分析并请业务人员进行确认的作业方式。这种作业方式，由于业务人员往往只是动动嘴，因此对于需求的描述肯定是不够全面和深入的，这样必然会导致后期需求的大量变更。
综上所述，在管理信息化建设过程中，对于业务需求的描述应是由业务人员为主来进行，但同时应该给业务人员提供一个很好的工作平台，而且咨询顾问也应全程参与并起到指导作用。
应该有一套用业务语言统一起来的业务需求描述的建模规范，而咨询顾问又可以基于此得到所要的技术信息。
网友评论