企业信息系统建设前的需求分析简单思路

信息化一直是目前的趋势，企业也开始建设各种各样的信息系统，信息化的好处就不用多说了，对于企业里的需求分析人员，如何更全面的考虑需求，降低项目风险，有几个思路可以交流学习下。

（一）了解信息系统建设的目的

首先要清楚我们为什么要做这个系统，解决什么样的问题，目标是什么。并且和现存的业务系统是什么关系。不能拿到了需求就立刻开工，还是要先站在一定的高度思考一下。

在需求分析中常常遇到这种问题，系统都开发出来了，需求分析人员经常说不出用户为什么提此需求，一句经典的话就是“用户让我们做的”

（二）用户是谁

弄清楚用户有哪些人，分为哪些角色，每个角色在业务上进行哪些不同类型的工作。

1、有的项目涉及到不同的部门（财务部、企业发展部、法务部等），不同的部门，由于业务的不同，对系统的需求自然也不同，因此在需求调研的时候，要考虑到所有涉及到的部门的需求。

2、企业中一般有高层领导、中层领导与基层人员三个层级。不同层级的人对系统的要求也不同。

（1）高层领导：关心宏观层面，例如系统研发后带来的好处，能为决策带来什么便利， 推广时会不会给员工带来困惑，是否会有一些统计的数据报表等。

（2）中层领导：关心具体的效益，即系统能对信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计。

（3）基层人员：每一项业务的执行者，也是系统的具体操作者，基层人员才是要开发的系统的业务领域专家，也是调研的重点对象。另外他们也是今后系统真正的使用者，比较关注每项操作的细节。

3、不同的角色对系统的需求也是不同的。

系统的使用者也可以按角色来划分，比如有流程的发起人，流程的审批人，系统的管理员等角色，每个角色对系统的使用要求也不同。所以考虑到不同角色的业务要求也是很重要的。

（三）业务流程分析

对于将要建设的系统，需要详细了解相关的业务流程，最好将业务流程图梳理出来：

1、业务如何流转：从流程发起到结束，经历过哪些用户和角色， 每一个节点是哪些人来操作，如何操作，为什么要这样操作。

2、输入和输出：流程的输入是什么，输出是什么，例如在流程发起时要填写一些业务单据，流程结束后要输出一些文档。

3、流程电子化之后，每个操作人使用的场景：有的人对电脑操作不熟；有的人可能常年在外出差，不方便用pc端处理；有的岗位没有电脑.....对所有用户的使用场景都要有了解，不能只是强行上系统，这样也会给很多用户带来困惑。

（四）相关组织架构和岗位职责

了解系统涉及部门的组织架构和部门职责，以及参与用户的岗位职责。如果能知道每个岗位的KPI考核点就更好。

信息化只是将他们的职责应用在了系统上，所以调研这块还是很有必要。包括他们的KPI考虑，如何在系统上体现。

（五）最实用的两种分析方法：“为什么”“5W2H”

1、“为什么”

有些需求客户是没有说出来的，并不是用户不想说，而是在用户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而对于非业务人员，是不了解这些规则的。如果采用被动的方式去仅仅记录需求，毫无疑问会遗失这部分需求。

所以，多问为什么， “你们为什么这样操作？”，“你们为什么要这个功能”，“你们为什么要这么想”.....业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识，站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求。

2、“5W2H”

（1）WHAT——是什么？目的是什么？做什么工作？

（2）WHY——为什么要做？可不可以不做？有没有替代方案？

（3）WHO——谁？由谁来做？

（4）WHEN——何时？什么时间做？什么时机最适宜？

（5）WHERE——何处？在哪里做？

（6）HOW ——怎么做？如何提高效率？如何实施？方法是什么？

（7）HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？

基本通过以上几个维度思考问题，就会做到不重复不遗漏。

（六）原型图的必要性

在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。当软件上线时，他拿到了实物了，知道软件做成啥样了，一旦不满意他就开始提变更了。所以，这里就需要原型图，原型图的作用就是能在需求分析阶段做出和实物相差不多的体验。

以上就是在做需求分析时，总结的一点点经验和想法，当然只是一点思路，具体的操作细节，之后有空再深入写一下。