EAZYBI建模-建立矩阵组织模型
最小的矩阵模型需要包括以下维度
- 职能部门金字塔型结构，例如部门，小组
- 项目维度：项目、模块、版本
需要在JIRA上配置齐全，才可能有比较好的EAZYBI模型，以下配置都在JIRA上进行。
矩阵组织模型
一般公司采用矩阵组织结构，如下图
- 项目归PMO(Project Management Office)一般称为项目管理办公室管理，当在JIRA上创建了一个项目，EAZYBI需要的Project维度就自然创建起来了。
- 职能部门在JIRA上对应的是Group因此需要按照真实的组织结构来创建Group，而下级部门展开时，为了保证报表展示时排序，需要进行编号。
- 例如创建SW、HW、ID等大组
- 在SW（软件部门）下再创建平级的SW1、SW2……等等，继续展开为SW1-1、SW1-2……
- 硬件HW和ID用同样的方式编号
- 类似，例如同一平台的项目貌似也需要类似命名规范。
创建职能部门群组
群组命名需要反映组织架构并且编号，否则生成EAZYBI图表会有大量人工排序工作。
用管理员登录，在“管理界面”的“用户管理”标签-“群组”-“新增群组”，增加经过编号的群组名。
项目配置
模块和版本是出报表必要的维度，大领导经常关注故障按版本收敛情况，或者问题主要集中在哪些模块。而配置这两个要素，往往繁琐并且需要经常修改，因此，需要督促软件经理或者该项目的管理员进行配置。
配置模块的必要性
项目的模块和职能部门下的小组并非一一对应关系，模块Leader往往是职能部门的接口人。如果选择Default Assignee为Component Leader，该模块的故障默认指派给该模块负责人。
如果一个项目只有一个软件经理，但是有多个模块负责人，故障就不会堆积在软件经理处，由多个模块负责人快速分配下去。如果不配置模块，而其他模块的人并不知道具体模块的负责人是谁，故障流转效率会低，当旧的软件提供该功能，很多人将会拒绝使用jira。
配置版本的必要性
配置版本主要是配置版本的开始和结束时间，对于生成报表，至关重要，同时，可以把故障拉入具体版本，要求修复。
思考
- 按在职能部门配置，项目的安全性怎么考虑？并非每个职能部门的成员都在具体的一个项目里面。
- 当员工离职，入职，或者大的组织架构调整，JIRA怎么可以和其他ERP软件保持一致？
- 版本计划变更，是否需要同步修改JIRA上的版本计划，还是只在项目管理软件上修改？
- 以上这些脏活累活，谁来干？
- EazyBI数据建模是否是一个独立项目，需要有自己的版本计划？假设没有和其他ERP软件联动时，当组织架构变化时，有没有比较大的工作量？