1. 概述编辑
1.1 背景
项目应该被计划管理，因此项目计划是项目能否高效稳定执行的重要条件。
尽管在成立 BI 项目初期，由于初期的调研较少，且由于我们还不了解公司数据质量、员工数据素养等等各个方面，因此我们没有办法估计出详细的工作量，但可以根据已有的信息，制定出当前阶段的计划。
计划是用来改的，后续随着我们对项目的了解越来越深刻，可以不断的修正计划，让其更合理。
1.2 实现思路
想要制定好的项目计划，需要按如下步骤操作：
考虑影响项目计划制定的因素。
拆任务，这里我们推荐按照自助分析项目的生命周期来拆解工作。
排计划，以时间表形式展示计划。
估算风险，对项目可能存在的风险进行定期监控。
2. 影响项目计划制定的因素编辑
在制定项目初步计划前，首先需要考虑影响我们计划的各种因素。
2.1 数据质量
当前公司数据质量包括数据来源、数据情况、数据补录、数据合并、人员组织、数据仓库等。
需要根据企业当前已有数据的实际情况对整体方案设计进行时自己建数据完善间延长和把控，
例如可以先让各部门自己将数据完善后再开始项目，或者调整为优先推动数据相对完善的部门实行自助分析。
2.2 项目配合度
在进行计划排期时，需要考虑当前项目在公司中的配合程度，如果配合程度高，意愿强，那么就可以将计划排的紧凑一些，否则可能需要将时间后延2周-1月以上时间左右，方便与领导沟通/举办宣讲会议等；对人员想法进行拉通，另外需要在计划中增加价值宣讲会。
配合度的影响因素包括：
高层领导支撑：是否有高层领导支撑，是CIO、业务部门领导、还是集团的高层领导？
IT 部门配合：是资料对接？还是专人辅助开发？若有专人，专人的人数+角色+技能？
业务用户配合：对 BI 工具的态度、是否愿意主动参与学习？
2.3 推广范围
在制定计划前，要了解客户公司计划推广的范围和深度：
推广范围：预期推广哪几个业务部门，业务部门的规模，总人数多少？
推广深度：预期每个部门大概有多少人需要做分析？多少人会查看就可以了？
例如需要在企业内部进行 BI 的前 3 个部门推广，来确认 BI 真正能够带来使用价值；当将前几个试点部门推广成功后，其他部门可直接套用推广过程进行赋能学习即可；
2.4 业务用户基础能力
业务对数据越了解，接受新产品的能力越强，整体推进的时间越短；
企业中业务员工的年龄较大，或者本身企业属性不太愿意接受新事物，就需要额外多做一些培训/引导的活动；整体时间在增加1月左右；并需要企业领导进行行政手段等协助。
因此在制定计划前，需要了解：
用户了解数据程度：用户对自己的业务数据有了解吗？比如知道数据结构，知道具体每一张表的业务含义？
数据分析能力：平时是否做数据分析？怎么做数据分析？是否用过类BI产品？Excel 熟练程度？是否会 sql？
学习能力：学历+学习习惯+新事物接受能力
3. 拆分任务编辑
按照自助分析的四个阶段生命周期，我们可以将任务拆解。
对任务进行拆分时，需要注意以下几点：
任务需要相互独立、不重复也不遗漏
独立责任，单个工作应该只有一个责任人
单个工作的工作完成时间应该合理，不能太长
下面给出示例脑图：
4. 排计划编辑
4.1 项目计划书
在工作任务拆分完成后，即可根据任务内容做出项目的计划排期。
示例计划书如下图所示：
4.2 工作任务拆分
| BI建设事务大类 | 具体事务 | 事务详情 | 建议角色 |
|---|---|---|---|
| 服务器管理 | 服务器基本操作 | 下载和上传文件、操作服务器资源等 | IT运维 |
| BI系统巡检 | 定期对BI系统进行检查 | IT运维 | |
| 系统级异常维护 | 包括日志报错监控、宕机分析与内存监控等 | IT运维+系统管理员 | |
| 系统配置优化 | 内存、磁盘、各种参数等 | IT运维+系统管理员 | |
| 版本升级 | 大小版本升级 | IT运维+系统管理员 | |
| 系统运营 | 资源交接 | 针对离职和转岗用户，将其名下的数据集和仪表板资源进行核实，转交给合适的交接人 | 系统管理员 |
| 资源迁移 | 测试环境到正式环境的发版操作 | 系统管理员 | |
| 插件安装和升级 | 插件的功能确认，然后在测试环境验证，无误后在正式环境升级 | 系统管理员 | |
| 性能优化 | 针对系统的卡顿、加载慢等问题，进行日常的监控和管控，形成通用的方案 | 产品数据经理 | |
| 日常管理配置 | “管理系统”下面所有的配置 | 系统管理员 | |
| 制定标准规范 | 指定开发管理、发版规范、准入考核等，并持续执行 | 产品数据经理 | |
| 搭建运营指标体系 | 包括但不局限于用户量、报表访问情况、用户满意度、违规情况等，最终形成可视化运营大屏 | 产品数据经理+各级次管 | |
| 数据与权限 | 权限分配方案编写及落地、权限审计 | 权限方案设计和实施，日常进行权限审计，确保数据不泄密 | 产品数据经理 |
| 仪表板目录和数据集目录管理 | 构建具有一定规则、方便易读的仪表板目录和数据集目录体系，日常进行审计和维护 | 产品数据经理+各级次管 | |
| 数据集建设 | 主要指指标含义计算公式及口径、公共的基础数据集添加、自助数据集开发，包括撰写取数来源和指标计算说明 | 各级次管+数据处理用户 | |
| 数据更新配置 | 确保数据更新机制是符合性能要求和业务诉求的 | 系统管理员 | |
| 用户赋能培训 | 产品功能宣传 | 将产品功能和一些更新及时地通知用户 | 产品数据经理 |
| 用户问题支持 | 包括用户支持、开发问题指导、满意度调研、用户使用问题记录、解决方法总结与培训 | 产品数据经理 | |
| 各种业务的分析思路整理、组织交流、培训 | 目的是提升数据化转型思维能力 | 产品数据经理 | |
| 组织BI能力提升培训，辅助进行职业认证支持 | 目的是提升和验证业务人员的使用能力 | 产品数据经理 | |
| 各种提升数据氛围的活动组织 | 例如内外部的数据分析比赛、积分活动等 | 产品数据经理 | |
| 数据分析落地 | 分析思路扩展 | 给业务提供分析思路，通过数据率先发现问题，向上汇报分析结果辅助决策，向下优化分析报表提供各人工作参考依据。同时为部门内其他分析用户提供分析思路指导 | 数据分析师(可由数据处理用户兼任) |
5. 估算风险编辑
在项目执行中，由于第二章中的因素，都可能会影响我们实际实施中的进度，因此需要将风险一一列出，并定期监控。
| 编号 | 风险名称与描述 （什么风险？风险发生的影响） | 可能性 （高-中-低） | 影响 （高-中-低） | 优先级 （高-中-低） | 状态 （重点-跟进-挂起-关闭） | 处理策略 （规避-转移-减轻-接受） | 风险应对措施 （如何降低风险发生的影响） | 下一次风险评估时间 | 责任人 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 业务用户的基础能力太薄弱，无法实际上手 | 中 | 高 | 高 | 减轻 | 减轻 |
| ||
| 2 | .... | ||||||||
问题&场景 有奖反馈：
恭喜您已看完整篇文档，现诚邀您参与BI建设方案共建，反馈 方案问题或企业实际场景 都有机会获得丰厚奖励哦~