《大中型企业（集团）业绩报告系统的实现》由会员分享，可在线阅读，更多相关《大中型企业（集团）业绩报告系统的实现（14页珍藏版）》请在金锄头文库上搜索。
1、1题目：大中型企业（集团）业务报告系统的实现单位：青岛海尔软件有限公司姓名：许刚2题目：大中型企业（集团）业务报告系统的实现内容提要：企业业务报告系统，从归属上可视为企业业绩评价体系的一部分。业绩评价体系一般包括关键绩效指标库子系统、实际业绩计量子系统、预算（或标准）与实际差异的分析和报告子系统（即本文将描述的业务报告系统） 。在理想情况下，企业还可通过业务报告系统与企业内计酬系统、战略地图系统、基础业务系统进行的各种集成或连接，实现自动取数、自动汇总、自动计酬，并形成对企业各级管理者和员工的各期目标的考核。而在具体的系统实现过程中，如何有效的将“理想情况”有效落地，形成对企业发展真实有效的软
2、件系统，需要考虑很多具体情况并规避一些常见的风险。笔者通过在多个实际项目研发中的体会，整理并论述了其中的一些策略。主题词：业务报告、绩效考核系统、报表系统3正文部分目录1 系统的规划.31.1 系统定位.31.2 范围控制.41.3 部署策略.52 系统的设计.62.1 软件生命周期模型的选择.62.2 报告逻辑设计.82.3 报告展示设计.92.4 数据准备相关.103 风险及规避措施.123.1 数据准确性控制.123.2 需求变更的控制.131 系统的规划系统的规划1.11.1 系统定位系统定位企业业务报告系统是用于管理决策使用的统计分析软件系统。它随着企业的规模、企业信息化情况和企业的
3、领导者风格的不同，实现的形式也为多种多样。不过虽然变体4很多，但能真正在企业内推广实施的业务报告系统，总体来讲都具备以下特征： 不涉及具体的基础业务结果类数据采集过程，而多关注于相关的数据整合、标准化等工作； 有针对特定指标的统计分析； 包含大量的经营管理报表群； 和企业的预算体系、绩效考核体系和战略评价体系拥有直接和间接的连接；1.21.2 范围控制范围控制业务报告系统的范围包括 2 个方面：用户范围和系统开发范围。以下分别做分析： 用户范围狭义上的业务报告系统的用户应定位为企业的中高级管理者，而广义上的业务报告系统的用户则可扩展到企业的基层员工。笔者认为，这就像软件工程领域的TSP（群组软
4、件过程）和 PSP（个体软件过程）一样，不同的管理者、员工关注的对象是不同的，高层用户主要关心企业战略决策的执行结果，中层用户多关注于企业战略决策的执行过程，而基层管理者（员工）则多关注于各类战术的实现，不同层面的用户都可以通过业务报告系统获得所需的信息；5 开发范围企业业务报告系统的开发一般不包含基础数据的采集。以制造业企业为例，车间的产品下线扫描数据、发货扫描数据等基础业务记录是不会出现在企业业务报告系统中的。但也有一个例外，就是各类预算数据，特别是针对不稳定的、临时性的考核分析指标，系统用户经常会以行业平均、或者通过加权平均的方式生成一些预算值，希望能和系统中的实际数据进行对比，此时就会
5、需要开发一些预算数据的导入、维护界面了。此外，为提高用户数据分析的灵活性，业务报告系统往往被设计为可将报告数据进行导出（以文本或 Excel格式） ，供有对应技术分析能力的用户、或提供给外部的专有分析工具进行有效的利用。1.31.3 部署策略部署策略笔者所见的多个零售业企业、制造业企业和物流行业企业成功所实施的业务报告系统，其部署策略都遵从了“由上至下”的方针进行推进，并将系统的实施过程分为多个阶段实现。在第一阶段，多数系统都选择先给企业核心管理者进行服务，得到反馈意见并完善后，再逐级下推到各级管理者。当然，笔者认为“由下至上”的推广部署策略也可在以6下 2 种情况中使用： 高层用户没有精力做
6、先行者，而希望委以某个下级部门主导进行系统的研发； 系统用户担心系统推广失败，希望能够在小范围内进行测试性研发试点，成功后再进行较大范围的推广。2 系统的设计系统的设计2.12.1 软件生命周期模型的选择软件生命周期模型的选择多数企业业务报告系统项目都具备以下特点： 需求不确定多数企业没有现成的关键绩效指标库，因此需要“报告”哪些内容，往往不能通过几次需求调研整理出来，而需要一个较长的设计、完善和演化过程，故此业务报告类系统项目往往执行时间都会超过 6 个月，多数需要 1 年左右的时间； 需求更新频繁对于多数企业来讲，唯一不变的就是经营战术不断变化本身。因此业务报告项目需求难以控制也就不足为怪
7、。但也有特例，就是政府部门的业务报告系统需求相对来讲较为稳定。鉴于上述特性，相较与传统瀑布模型、螺旋模型和快速7原型法等软件生命周期模型，笔者认为增量模型是最为适合此类系统开发过程的。增量模型是瀑布模型的一种变化模型。这种方式是首先建立概要设计，然后设计的实现是通过一系列小的、相互交错的子项目，每个子项目完成一个独特的功能。第一个增量往往是核心的产品，即实现了基本的要求，但很多补充的特性还没有开发。核心产品交用户使用的结果是下一个增量的开发计划。该计划包括对核心产品的修改，也包括新增的特点和功能。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。具体开发过程如下图所示：图表 1 增量开
8、发模型增量模型中的各阶段任务的定义如下表所示：No阶段入口标准任务出口标准1增量项目任务书已经由进行第一阶段的详第一阶段81高层经理签字，并进行了总体的需求分析及概要设计。细设计、编码、测试及发布。产品完成。2增量2增量 1 产品已经完成并完善了本阶段的需求分析及概要设计。进行第二阶段的详细设计、编码、测试及发布。第二阶段产品完成。3增量3增量 2 产品已经完成并完善了本阶段的需求分析及概要设计。进行第三阶段的详细设计、编码、测试及发布。第三阶段产品完成。各阶段中包含的详细阶段，可参考传统瀑布模型定义。2.22.2 报告逻辑设计报告逻辑设计笔者认为在系统逻辑设计方面应遵从以下原则： 在系统中规
9、划和集成特定分析流程多数具备一定实力的企业在实施企业级商业职能系统或 ERP 系统前，都会先以 BPM 系统来规划、完善企业的现有业务流程。但很少有企业能够在后续系统实现时，在系统中集成数据分析建议流程，而仅仅由用户的自身能力来解读报告，进而引申到发现特定的问题。这不得9不说是一个不小的遗憾； 报告应明确标杆、瓶颈内容，并可定位细节问题很多报表系统的实现模式就是“罗列数据” ，殊不知对于用户来讲，数据越多不会帮助他们更加明白其中隐含的内容，反而会使其无所适从。故此，笔者建议此类系统设计时，应能让用户通过报告很快了解其中的标杆、瓶颈指标项，并可方便的通过连接、自动提示等形式，查询到其对应的明细数
10、据以定位问题所在； 建议增加互动性的功能设计制定业务报告的最终目的是为了纠正业务操作中的问题。从这个意义上讲，如果业务报告系统仅仅实现了“报告” ，而没有实现解决问题的辅助方法，始终不能称为完整的解决方案。 2.32.3 报告展示设计报告展示设计业务报告系统的数据展示形式有很多种，但无非是通过各类报表、图形进行相应的分析。笔者认为在界面设计方面应遵从以下原则： 简单与复杂性原则企业业务报告系统的很多用户，年龄都在 45 岁以上。此类人群的特点是不喜欢花花绿绿的图形展示方式，而钟爱传统的中国式报表。同时，他们多数希望报表中显10示的数据尽可能少，而图形中包含的数据尽可能多； 清晰性原则对于多数企
11、业业务报告系统的用户来讲，最大的问题就是每天需要看的数据太多，而不是太少。因此，如何使用哪类颜色，标注报表中的最好、最差项，以及标注的最好、最差项数量以多少为最合适，恐怕需要根据用户的具体喜好来设定了；同时，为了避免用户在一张报表中需要看到过多的数据内容，如何有效的利用计算机屏幕的分辨率以减少屏幕的左、右、上、下 4 个方向的滚动条，以及如何将大型报表分类、分级进行显示，也是每个企业业务报告系统需要重点研究的问题； 总结性原则笔者看到很多企业自行开发、甚至某些产品厂商开发的通用化产品的报表，在展示数据时仅仅强调了数据的可查询性，而忽略了数据的可分析性。诸如各类报表间的关系（融合业务的分析流程）
12、应如何定义，报表中的数据能够得出什么分析结论却没有具体的功能实现。 2.42.4 数据准备相关数据准备相关业务报告系统涉及技术和业务的各个层面。整个系统应以为解决业务需求为主，兼顾实现企业信息化日后的数据11需求，实现企业级业务报告的实现。从技术层面分析，它的总体目标为以下 2 个方面： 结合业务报告所需，建立一个 ODS，抽取并存放所需各业务系统数据。通常情况下，企业级报表的出具需要以下 3 个步骤： 从各相关系统中进行数据抽取、清洗、转换与整合； 将数据存储并进行必要的管理； 在适当的时候，以适当的形式将数据进行前端展现。考虑到多数企业内部的数据和业务都相当复杂，如果数据从各业务系统中抽取
13、出后，直接进行清洗、转换和整合加载，则由于中间处理过程过于复杂，会严重影响到各业务系统的正常运转。因此，需要在源数据系统和前端系统间增加操作数据集中存储区（即，ODS） ，将原有的 ETL 过程分为集中和处理转换两个独立过程，源系统的数据首先抽取并集中到（ODS）中，然后再在 ODS 的基础上进行各种数据质量检测，业务规则转换等，将复杂的 ETL 过程与源系统分割开来，从而最大程度上降低对原有业务系统的影响； 在 ODS 的基础上，开发业务报告的前台展示界面有关前台展示界面的需求，需在项目实施的具体过程12中，结合项目开发模型的特点分期、分步确认。可以先以当前企业手工统计报表的需求作为系统的初期需求。3 风险及规避措施风险及规避措施3.13.1 数据准确性控制数据准确性控制业务报告系统最常见的问题就是数据准确性问题。在通常情况下，数据差异来源于以下几方面的原因： 统计方法或编码的不统一比如某套报告的一级表采用的是新组织结构的部门划分，而二级表采用的是原有组织结构，报表间的可比性就会出现问题；再如外销收入统计表按报关时间为准记为收入时间，而内销收入表按客户付款到帐为收入时间，则企业的内、外销收入合计表中时间又应以哪个为准呢？ 取数时间的逻辑差异比如系统取数逻辑是，销售部的系统每日 23 时将最新的客户信息更新入业务报告系统的后台数据库，而客户开票的数据要等
