把这些转变为软件中的功能、权限、报表也一气呵成。组织结构和岗位职责决定了功能点和功能权限、工作流程决定了软件流程、工作流程中使用的纸张信息、EXCEL信息、软件信息就是数据输入，报表就是数据输出。这就是一个企业管理软件的四大块：组织权限、输入、处理流程、输出。

　　所以说，企业管理软件的开发是有方法和规律的，比较容易，就连最难的调研和需求管理也有方法。所以企业管理软件的开发，现在主要集中在大规模开发团队的组织、任务调度、人员培训（大规模的开发，必然需要的是一般素质的人员，而非高级人才，否则不可能有那么多资金来实现大规模开发）、大规模开发团队的质量和进度（人多了，各个层次各个水平的人都有，理解都不同，如何保证质量和进度是很关键的，否则很容易项目预算失控。一般素质的人多了，对于管理的要求是很高的，很容易成为乌合之众，只消耗不产出）。我特羡慕KFC，不管我们在大江南北哪里，迟到的KFC是一样的口味和品质，享受的服务和环境也差不多，这很难。那么多店，而且都是授权店而非自主经营店，那么多一般员工，而且员工流失和临时员工也非常多，居然能保证一样，管理水平实在了得。所以我经常学习KFC和丰田，如何使一般员工大规模配合工作。

　　对于企业管理软件开发过程中的文档，我们一般有需求分析说明书，其编写格式和思路，和我们的需求调研方法一致，也就是说，我们的需求调研的结果，落实到纸面，就有需求分析说明书，另外还有一份需求调研报告，是偏向于项目过程叙述的。

　　需求分析说明书回来，研发部内部会进行大家一起学习理解，然后讨论。

　　讨论主要由：需求调研人、业务组组长、测试组组长来参加。一个个的过流程。因为在需求调研期间，去的只是调研人，可能有想不全的地方。如果这样就直接进行开发，无疑会有很多漏洞。这样给开发、测试，都带来了返工修改，给项目管理也带来了项目进度、任务分配的调整，计划的打乱也间接影响了质量管理。

　　根据大家讨论补充后的需求分析说明书，就比较容易得到我们下面环节的文档。

　　首先我们会出功能点文档。

　　我们会把需求分析说明书中的业务功能都列出来清单，属于组织结构建立、组织角色、权限分配、登陆验证、基础数据维护之类的都归类到系统功能中。系统管理，各个企业管理软件差不多，我们又有公共的系统管理模块，就不需要重新发明轮子了。所以，我们主要重点是分析业务功能。

　　根据需求分析说明书中的每个流程，都先提出来成为一个功能点。然后针对现在整理出来的功能点，再一个个对照流程，如果这个流程复杂，就拆分，把这个功能点拆成几个复杂性和预估工作量差不多的功能点。经过这样的拆分，就形成了最终的功能点文档。

　　而功能点之间，根据上述方法的拆分，就形成了功能群。

　　功能点就成为功能权限控制的最小单位。功能群就成了软件菜单中的一项。几个相关联的功能群就成为了一个业务子系统。