需求调研是信息部门使用信息化工程技术对业务部门常规工作进行重构工作。简单的说：就是用信息技术语言翻译业务流程。需求调研，从行动阶段来说，主要分为：调研前的准备，调研中的探讨与挖掘，调研后的整理与归纳。
针对某业务部门进行业务调研前，事先了解下大背景是必须的。
业务背景知识调查：业务部门按服务对象来分，主要有对外运营的部门，例如：销售，采购，市场等部门。对内支持的，有例如：人事、财务、后勤、信息部等。生产型企业还有生产组、仓储等部门。不同的业务部门对应不同的业务角色和功能，而业务调研就是基于部门的业务角色和功能的调研。在你对企业某部门进行调研前，你可以先用互联网搜索工具，在网络上寻找对应部门常见的角色和功能，处理什么样的数据，怎么处理这些数据。总之，背景知识的调查可以让你做到：事先有谱，遇事不慌。
业务问题提问计划：整理出一个列表，根据5W+1H，事先对可能想到的问题整理出来。这个部门有多少人？每个人的角色是什么？他们平时处理什么业务？他们怎么处理这些业务？这些业务从哪里开始，哪里结束？这些业务哪些是重点？是否有什么阻碍、瓶颈？通常会用一个通用的列表来挖掘信息，以销售部为列，从以下切入点来分析部门的基础信息，其他部门以此类推。
以下是一个简单的提问模板：
部门名称：XX电气-销售部
部门规模：8人，包含1个总经理
业务模块：销售计划，销售订单，销售开单，委托代销，发出商品，销售开单等功能模块；
业务流程：按模块划分，业务处理流程图，偏业务行为，例如：客户打电话/发Email，下订单；
数据流程：按模块划分，业务数据流程图，偏数据流，订单数据走向，财务数据走向
主要文档：业务处理过程中需要的文档，尽量电子化
应用系统：是否已经使用的应用系统，如果有，请列出：
业务瓶颈：（偏运营管理、IT支持方面）：
在与业务部门进行面对面的沟通时，先要做个安静的聆听着，又要做个爱提问题的三好学生，但最重要的，在关键时刻，要成为一个合格的引导着。
聆听者：如果被调研的业务部门对业务了然于胸，且善于表达，可以让其自由发挥，做好笔记；反之，可以把事先准备好的提问稿给对方，让他一一解答。
学生：事先准备的提问大纲一定要在调研中的得到答案。细节问题、核心问题必须要有所解答；
导师：很多时候，会碰到那些对自己业务很了解，但不善于表达的业务员，这个时候，要循序渐进，本着5W1H的精神，慢慢找出答案；
在业务部门表述需求的时候，往往会碰到各种不同的问题。以偏概全、业务知识难以理解、无确定需求、难以实现的需求等是常见的几种现象。
无确定需求：业务部门自己都不十分清楚想要的功能
很多时候，业务部门对新应用开发的时候，往往只有一个概念，看到人家已经有的，很想拿来用。这个时候，干脆就以市场上流行的这方面的成熟系统做原型讨论，先“拿来主义”，再“修正主义”是在这个时候是最合适的；
以偏概全：比方说财务中做的报表有些基础报表被遗漏了
由于长时间的业务沉淀，很多不标准的业务方式在现实中使用着。由于种种原因，造成企业未按标准的方式遵循，这个时候，有必要重新设计业务流程，尽可能的实现企业信息标准化；
业务知识难以理解：比方说财务报表中的复杂算式
术业有专攻，每一行都有自己的特定的知识储备，暂时一些难以理解的业务知识是可以后期学习和弥补的。这个只能花点时间多去业务部门学习，甚至现场实习1，2周；
难以实现的需求：技术上由于种种原因难以在有限的资源、时间内实现
很多业务人员由于对信息化技术的不了解，有时候会提出些天马行空的需求，或者有些是能实现，但是，很费人力、财力的时候，需要耐心的解释，甚至有必要请出专业IT技术人员来协同解答；
在与业务部门进行多次沟通后，手上必定拿了很多一手资料，现在就要以软件工程方法学来翻译这些需求，即：业务系统建模，或者叫业务模型化（数据标准化，流程可视化，注：此处的建模是业务，非实现技术）然后，找到对应的信息化解决方案，最终给业务部门敲章定稿。
资料整理与归纳：
文档记录与归档，即以电子文档的方式记录业务上的各种资料。
纸质文档一般以图像照片记录的方式拍摄下来，现场的特殊场景、布景等也以电子化的方式记录。然后，按照所属业务模块分类保存在不同的文件夹中，供信息化部门搜索、建模使用；（数据记录一定要做到原始数据记录跟业务处理流程记录，这是建模的基础）
业务建模，即用模型化的方式对业务进行重构，以期用文字+图标+图示来实现业务流程重现。
以业务部门能快速理解的角度看，组织结构图，功能模块图，业务流程图，数据流程图，系统部署图是常见的客户浏览图。（注：标准建模，参考UML，Unified Modeling Language，统一建模语言，偏信息技术建模，有功能图、对象图、动态图）
跟业务部门的反馈：
会议反馈：
每次跟业务部门开完会议后，会议纪要是必不可少的，一方面可以记录项目的跟进程度，另一方面可以反馈给业务，看是否有遗漏或者理解上的疏漏；
业务模型定稿反馈：
当业务资料积累到一定程度后，使用多种不同的图示来构建业务模型，需要进一步跟业务组进行业务确认，以防止有遗漏，或者理解上的疏漏；
解决方案反馈：
当信息化调研到达一定程度后，总体上对应的解决方案也应该有了雏形，这时候，就需要针对客户能理解的做解决方案，持续与客户交流意见；
最终定稿反馈：
当信息化调研快要结束的时候，一定要以正式的邮件/书面的形式向被调研的部门确认最终解决方案以定稿，以防止日后跟业务部门有需求上的纠结；
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。