业务调研注意事项.doc

业务调研注意事项
调研步骤
n 需求调研准备: 制订具体业务和管理需求调研计划, 准备调研提要和问卷, 准备调研场地或安排调研培训等;
n 需求调研: 按计划完成调研, 编写和汇总需求调研汇报或调研日志;
n 需求分析: 双方共同分析确定需求, 关键分析业务步骤和问题, 提出初步处理思绪和优化方案, 提交需求分析汇报;
n 步骤设计: 对关键业务步骤进行优化设计、 大项目可单独提交步骤设计方案;
n 业务处理方案设计: 双方依据需求分析和步骤设计等, 共同编写业务处理方案初稿, 并让双方组员充足了解;
n 用户化开发设计: 依据需求分析和业务处理方案, 确定用户化开发需求, 并和开发人员共同确定用户化开发具体设计（功效、 步骤、 界面、 算法、 数据库设计等）, 并和用户确定用户化开发需求部分（功效、 步骤、 界面、 算法）。
需求调研
对于不一样类型被调查对象, 怎样引导被调查对象思绪, 问出你关心问题, 取得很好效果, 就看顾问经验和专业能力了。调研总体思绪是由粗到细, 先整体后局部, 先集团后部门。
1、 总体调研:
总体调研关键是指企业整体运行情况调研和高层管理需求调研, 如企业未来几年战略计划、 企业组织与机构布署、 IT建设计划、 集团管控需求、 高层管理者需求等内容。
2、 具体业务需求和管理需求调研:
a) 具体业务步骤调研: 能够按业务步骤次序, 对企业各个业务部门参考调研提要或调研问卷内容进行业务步骤调研, 共同绘出完整跨部门业务步骤图（包含数据、 加工、 单据等）, 并描述每个步骤节点所包含处理和数据规范。并描述各部门对业务改善提议和管理需求目标等。
b) 每个部门调研完成以后, 都应该让该部门相关人员针对调研内容进行确定, 看是否存在误解和遗漏。
c) 需求调研我们是经过顾问与用户访谈、 用户填写调查问卷及步骤图等形式来进行。经过与项目小组或单位业务人员会谈, 顾问应从多种角度取得企业业务管理思想和业务处理现实状况。
3、 需求调研汇报讨论与确定
全部需求调研结束后, 顾问要将需求调研日志进行汇总, 从粗到细, 从总体到业务进行归纳和整理, 形成整体需求调研汇报;
需求调研汇报要具体向用户方项目组进行汇报、 讨论和确定, 确定后才能开始需求分析和编写实施方案。
调研时应注意以下几点:
1. 调研要适合项目范围与用户行业特点, 不能使用通用调研提要, 顾问一定要依据标准提要进行剪辑, 提前准备, 不了解行业需求可提前查询知识库或咨询相关顾问, 不然会失去信任;
2. 售前、 商务文件中已调研或已知需求不要反复调研, 能够和用户作一个最终确定;
3. 不管进行什么调研都要求顾问在整个调研活动中占据主动地位, 能够控制整个活动进展, 注意用户反应, 确保得到我们想要知道东西。
4. 调研过程有一个总体把握, 也就是说实施人员不能仅仅局限于具体业务处理中, 而应该从总体业务步骤上进行分析, 把各个部门业务连贯起来。只有这么才能从宏观角度来把握调研、 分析进程, 确保此阶段顺利完成。
5. 调研和提要都应有层次和连贯性, 按业务步骤次序进行梳理和调研, 调研时不要仅限于协议中产品模块范围（比如应收应付需求和方案可能和销售和采购业务管理需求相关）, 也不要按产品模块次序进行调研, 讨论议题也不要有大跳跃, 要从粗到细, 逐步分解和连贯;
6. 要尽可能结合标准产品功效在调研过程进行引导, 但调研时不能和用户讨论产品功效, 只讨论业务需求, 产品功效只是在脑海中进行对比, 这么, 当调研结束时, 基于对产品了解, 脑子里就基础上有了处理方案。产品中无法实现不合理需求尽可能经过变通方法处理, 按变通方案进行引导。
7. 顾问在调研中要有引导用户技巧, 调研时要把握总体范围, 不要偏题和跑题, 引导时要从分析业务步骤和实际业务角度去引导, 不能完全从产品是否满足需求角度去引导。
n 调研中在双方讨论业务步骤时, 可将业务步骤在白板上画出, 用相机拍下来再安排时间整理成文档, 顾问立刻整理出当日调研关键内容, 然后交用户方项目小组阅读, 看顾问了解是否正确。
n 也能够调研前请被调查业务部门先写业务现实状况汇报（包含业务步骤描述）, 也能够让业务部门先描述业务步骤现实状况。要求在业务现实状况汇报中要反应以下问题: ①该业务部门组织结构, 岗位设置和职责; ②关键业务和业务步骤; ③列出现在存在关键问题。再基于业务现实状况做调研和讨论, 调研进程会大大加紧。
需求分析
需求分析关键工作包含:
n 在具体业务调研基础上帮助企业分析业务步骤和业务管理中存在优点、 问题、 不足和处理思绪, 并确定各领域管理模式。
n 建立新管理模式和集团管控方法;
n 双方共同设计和优化企业目标业务步骤, 形成新业务步骤规范;
n 建立新管理模式, 如以及定义相关数据规范和管理制度等;
n 将需求分析过程和意见整理成需求分析汇报, 并具体汇报给用户方项目组, 最终书面确定。

需求分析基础方法:
1) 形成产品匹配性初步分析, 顾问要尽可能从业务步骤和管理模式角度说服用户放弃不合理需求;
2) 当全部用户需求整理出来以后, 再进行分类:
u 一类是软件能够处理, 而且能带来关键效益, 放在首位;
u 第二类是软件能够处理, 用户方领导非常关注需求, 放在第二位;
u 第三类则是软件能够处理, 用户方一般操作者关注需求;
u 另一类是软件极难甚至无法处理: 首先关注用户方领导关注问题, 这一类问题通常比很好处理, 比较轻易经过“沟通”来说服; 而另一类是用户方一般操作者关注, 这往往是影响实施成功关键所在。
3) 最终需求分析汇报要分析用户方需求和业务步骤优劣, 提议、 目标步骤定义（步骤图）和差异分析、 数据规则改变、 管控需求实现方法和对数据、 步骤要求, 对系统对组织职责、 配套制度要求等。需求分析汇报中还要明确每个业务步骤未来哪些是要在系统内运行, 哪些是不在系统内运行。
4) 需求分析汇报初稿完成后, 要向双方项目组进行具体讲解和汇报, 并逐项讨论, 修改后形成需求分析汇报终稿, 确定后作为确定系统处理方案依据。
在最终形成和审核需求分析汇报时应注意以下几点:
a) 对各管理步骤和业务步骤现实状况所做描述是否清楚;
b) 对各管理步骤和业务步骤现实状况所做分析是否正确;
c) 业务步骤和管理改善提议是否合理;
d) 对用户现有业务步骤和管理需求清楚掌握是编写业务处理方案前提;
e) 在设计和优化业务步骤时, 要充足考虑业务步骤可实施性, 或行业普遍性, 可参考优异企业做法;
f) 在需求调研和分析期间, 一定要用户方项目组组员全程参与。切不可单方面确定需求分析结果。
步骤设计
需求分析时要讨论并确定目标业务步骤（财务核实和简单供给链类项目除外）, 作为制订业务处理方案依据, 业务比较复杂项目, 提议依据业务步骤设计方案, 在上线前, 先对关键用户和最终用户进行步骤培训;
常见业务步骤图有二种: 标准业务步骤图和泳道图。
标准步骤图由步骤起点、 结束点、 数据、 加工、 流向、 岗位等原因组成, 每个加工后必需有一个新单据, 不能有反复加工和反复单据, 以下图所表示:

申请单
采购员: 制作申请单
步骤开始
经理: 审批申请单
审批后申请单
步骤结束

泳道图用泳道表示岗位, 其她和标准步骤图类似, 以下图所表示:
采购员　　　　采购经理　　　仓库管理员

制单
采购订单

审批

业务处理方案设计
基于需求分析结果, 制订整体业务处理方案和用户化开发方案, 包含全部在系统中实现步骤、 操作步骤、 数据、 参数等, 系统布署步骤等。
假如是分阶段上线项目, 应统一制订出整体方案, 再分阶段细化上线。以预防各阶段衔接不连贯风险。
方案中如有用户化开发, 应整体考虑, 不能把用户化开发部分独立开来制订方案, 用户化开发部分设计受整体方案影响, 比如接口开发方案受整个系统数据和步骤、 管理要求决定。通常来说, 用户化开发部分需求由顾问负责, 可由开发需求分析人员帮助, 设计方案由开发设计人员负责;
用户化开发需求应包含需求、 开发环境、 操作人员、 数据步骤, 业务步骤描述、 功效需求和界面模拟、 报表及查询、 算法描述等, 而且需要用户方进行确定。
实施方案设计基础标准与方法:
1) 我们在设计实施方案时尽可能考虑现有产品能够实现功效, 对于我们产品功效不能满足地方我们应该合理回避, 采取变通方案（在不降低项目质量和效果前提下）, 降低因为产品功效原因造成方案不能够实施性。
2) 很多项目需求变更是因为需求不够具体和考虑不周引发, 所以方案设计时要考虑步骤、 操作性、 数据、 参数和报表分析等各方面;
3) 顾问在引导和讨论蓝图设计时, 对系统功效、 步骤、 参数、 数据等不确定地方, 可先在测试环境下少许测试数据进行测试确定;
4) 顾问要引导用户需求趋向合理化, 对于不合理需求需要说服用户尽可能放弃或暂缓, 相关用户合理需求要尽可能满足, 不能满足需求能够使用变通方法或用户化开发方法给予处理。用户化开发部分假如不在协议范围内要和用户商议一下商务变更。