业务流程初步收集指南v2.docx

业务流程收集初步指南 第一版 作者：张辉  引言 传统应用系统建设上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯等。 作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 由于不同流程的特殊性与个性化要求，以及需求分析的高风险性，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 用户说也不清楚业务流程需求例如总部各部门及各地的财务报销制度，和员工招聘制度存在差异，但是又缺少一个能对所有组织管理制度都精通的业务人员，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 流程需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 另外流程建设需求有其自身的需求梳理特点，不完全和传统需求方法论一致，因为传统需求方法更多适用于为职能部门开发的业务系统，业务领域更多关注在相对独立的业务体系内，如考勤管理，销售管理等系统，而流程需求分析则需要从更高层面进行抽象建模，如企业内控制度，岗位权限，财务制度等。 流程需求方法论 需求规划：调研结构规划 静态调研报告结构 业务调研结束后，需要收集到的原始文件盒调研记录进行整理，形成规范而有价值的业务调研报告。目标是到业务调研报告不需要与客户再次沟通就能通过业务调研中抽象出的系统需求和一起需要的信息。我们把业务调研报告分为静态业务和动态业务两类 上图的组织架构是比较典型的静态结构模型，在静态业务抽象时，彩雀逐层细化的过程。可以这样推理，一个公司至少包含一个或多个部门，一个部门可能包含一个或多个岗位。一个岗位可能要处理多个表单或数据。 对部门职责描述，应该采取表格形式最晚有效和准确， 如下部门职责描述模板： 部门编号“按照企业要求编写”部门名称不为空直接上级“填写主管部门名称”部门性质部门级别编制人数数值下属部门下属部门是指部门领导的下级部门部门职能职能1[详细描述]，尽可能描述本部门的职能，已经与之较好的上下游部门 职能2[详细描述] 具备条件 《部门职责描述模板》 职位编号单位人事编号职位名称组织架构图对应所属部门组织架构对应部门职位类型上级职位根据人事部门提供填写编制日期需要就每个岗位所承担的职责详细描述，通过岗位职责描述，全面了解岗位所承担的责任和具体工作细节，便于通过岗位职责挖掘用户需求。需下图模板： 序号工作职责（按照重要程度排序）时间比例关键指标1工作职责详细描述时间比例占考核指标币种2其它工作职责时间比例占考核指标币种 《具体工作职责描述》 另外，原始资料整理，本阶段的主要职责是每个岗位中的工作人员需要的原始资料进行整理和分析，分门别类的处理，原始资料是业务系统分析的静态结构的主要数据。也可以使通过原始资料整理，获取业务运行的业务规则，如下图： 《业务表单模板整理》 表单编号表单名称岗位职责中用到的名称表单类型编制单位所在部门使用部门列出使用此表单的所有业务部门是否自产生是/否岗位名称表单拥者岗位处理周期时间 《数据集1》 数据项目编号数据项名称标示符数据类型长度初始值范围项目组约定项目组约定.NET数据类型