企业简介
广州瘦吧网络科技有限公司(下简称“瘦吧科技”）以数字化赋能健康管理为核心，着力打造集生物技术研发、产品生产销售服务，软件开发及大数据应用为一体的专业数字健康管理平台，业务范围主要涉及体重管理、肠胃管理、睡眠管理、血糖控制四大板块，仅体重管理已累计服务近300万用户，业务遍及国内385个城市，74个国家。
自成立以来，瘦吧科技坚持以科研提升核心竞争力，与美国哈佛大学、中国兰州大学、华南农业大学等科研机构达成产学研合作；同时邀请2013年诺贝尔化学奖得主Michael Levitt参与公司的健康产业新项目，以专业能力构筑技术、研发壁垒，瘦吧科技及其关联公司已连续承办四届“健康中国2030高峰论坛”，2021年9月，承办中国贸促会和广东省人民政府主办的“中国（广东）21世纪海上丝绸之路国际博览会健康丝绸之路国际合作论坛”。
业务需求
数据部做为独立部门，承担公司层面的数据统一管理、数据赋能业务等职能。在业务层面，数据部致力于给各部门快速提供数据报表及看板，满足业务部门看数据、分析数据的需求。在管理层面，数据部在团队小、需求多、数据杂的情况下，怎么保障在数据权限隔离的前提下，高效运转满足需求也成为我们的工作重点。
在完成数据仓库的初步建设后，公司内部已实现业务数据源打通，常规指标、报表实现T+1自动更新。此时，需要使用数据看板来做为数据承载，满足各部门对于数据查看以及分析的需求。故我们开始使用阿里云Quick BI来搭建数据看板，但在设计及搭建过程中，我们发现Quick BI作为一个SaaS产品，在应对复杂的企业业务场景、多样化的业务需求时，不管是功能还是性能方面，都无法完全满足业务需求。
例如，我们在做销售驾驶舱时，需要对销售指标进行多维度交叉分析，同时多层下钻至底层数据，每位客户经理的权限只能看到其负责的客户名单，Quick BI具体局限性如下：
1）不支持数据多层级上卷和下钻；
2）在数据量达到十万级别时，看板需要两分钟左右的时间才能打开；
3）数据展示图表种类较少，不支持动态图表展示；
4）数据存储在云服务器中，数据安全得不到保障；
5）权限管理单一，仅能设置看板权限及列权限。
在经过调研以及多家供应商对比后，我们选择帆软作为供应商,采购FineBI及FineReport软件。
与此同时，在需求越来越多的情况下，会出现需求处理流程无法闭环，同一时间处理多个需求导致需求漏处理，历史需求回溯难，团队成员需求处理情况管控难等情况，此时我们也通过公众号了解到了数知鸟这个产品，瞬间击中了我们的痛点，故开始引用该产品。
解决方案
思路
实现业务运营线上化、流程化、系统化、自助化，推动企业数字化思维建设
方法
采取采购或自研的方式，搭建数据应用平台及产品，实现线上化、流程化、系统化的目的；将数据产品推广至各业务部门，通过培训，达到自助化取数、分析的目的；将数据辅助决策的理念从管理层全面推进到一线业务层，最终实现公司的数字化转型的目的，从数据中来，到业务中去。
数据架构
推进过程
1.0阶段（Kettle + Excel报表 +Superset）2020.8-2021.1
这个时间段是数据部成立的初期，同样也是数据部引入数据应用平台的第一阶段。在历史以往的过程中，上到管理层，下到一线业务层，获取数据的来源均来自技术部门在开发软件的过程中产出的副产品——系统管理后台。数据部成立以后，数据部承接了数据质量管理、数据需求处理、数据统计口径管理到数据分析报告产出等职能。
业务部门对数据部的期望甚高，热情高涨，同时数据需求也井喷式增长。在这个阶段，数据部通过邮件承接数据需求，以报表形式交付需求，同时引入开源BI产品Superset，搭建可视化看板，解决部分日报、月报等固定需求。
在多业务系统的情况下，通过kettle关联多业务系统数据库，进行敏捷开发，快速满足业务需求。
本次数据产品更替解决的问题：
（1）流程缩短：从技术部进行系统后台开发的2周时长缩短至3天；
（2）提高效率：固定需求的通过邮件定时发送或可视化看板呈现，无需重复处理。
遗留痛点：
（1）BI产品数据安全性低：Superset是开源产品，配置的业务数据处于一个安全性低的环境；
（2）BI产品配置复杂：Superset需要基于Python的虚拟环境安装或Docker容器安装；
（3）BI产品查询卡顿：Superset支持轻量级的数据查询和可视化方案，随着公司业务的高速发展，数据量级呈现几何倍增长，出现看板加载时间过长的问题。
2.0阶段（数仓 + Quick BI）2021.2-2021.5
在长达数月的敏捷开发中，数据部对业务有了一个更整体更全面的了解，同时解决数据孤岛的问题也迫在眉睫，因此购入阿里云的MaxCompute和Dataworks产品，搭建离线数仓。同时，为了更便于可视化看板的开发，让BI在当前的数据量级下仍能舒畅使用，一并购入同样是阿里云产品的QuickBI。
在这个阶段，公司在办公软件上已经引入OA系统，数据部从邮件承接需求转为通过oa申请承接需求。数据应用平台升级的同时，数据团队人员也在壮大，内部需求管理辗转过多个管理平台，如企微文档、石墨文档等在线文档进行工作分配。
本次数据产品更替解决的问题：
（1）BI产品配置：直接在同一个平台阿里云即可完成从数仓开发到数据查询、可视化看板搭建的完整流程。
遗留痛点：
（1）BI产品数据安全性低：QuickBI是saas软件，saas环境数据安全性低；
（2）BI产品可视化功能不足：图表固化，无法满足更高需求的联动、下钻等功能；
（3）BI产品登录渠道：不能集成企微中，需要通过阿里云登录；
（4）需求管理产品无法闭环：无法及时获知每个团队成员的完成情况、平均工时等，偶尔出现需求疏漏的情况。
3.0阶段（数仓 + Fine BI + FR + 数知鸟）2021.5-2021.11
在公司的整体规划中，数据安全成为一个越来越重要的议题，为了配合公司的规划，数据部开始对市面上的BI供应商进行了解，甄选了多个供应商来公司进行产品演示，最后引入帆软的BI+FR产品，进行本地化部署，并开始基于帆软产品重新开始进行可视化看板搭建。
同时，引入数知鸟产品，集成到企微、BI中，进行内部需求管理，并且实现团队内工作安排推送至企微，完成后及时通知需求提出人。
本次数据产品更替解决的问题：
（1）BI产品数据安全性低：通过本地化部署，提高数据安全性；
（2）BI产品可视化功能不足：通过大屏+看板提供视角更广、粒度更细、功能更丰富的可视化看板到决策层、管理层及一线业务层；
（3）BI产品登录渠道：通过企微即可打开；
（4）需求管理产品无法闭环：实现从需求提出到需求完成的闭环链路。
遗留痛点：
（1）数据灵活性难：业务方对于数据分析的即时性、临时性增强，无法满足灵活多变且即时性要求高的分析需求。
3.1阶段（数仓 + Fine BI + FR + 数知鸟 + 自助分析）2021.12至今
在3.0阶段以后，企业对于数据依赖越来越强。随着数据源越来越多，业务场景也越来越复杂多变，业务部门对数据有了更多的要求，除了固定报表展示的需求外，他们更希望能够自己处理和分析数据，减少数据建设到决策分析的时间，因此引入自助分析，定期对公司内部开展线上或线下的培训课程，制作对应的自助分析数据包，按权限分配到各业务部门中。
本次数据产品更替解决的问题：
（1）数据灵活性难：数据部不再是以固定报表的形式交付到业务手中，而是提供数据包由业务自行进行，保证业务人员的数据主动性，业务通过拖拉拽就可以轻松高效进行可视化分析。
业务应用场景
场景一：内外兼顾——让管理驾驶舱与移动分析平台相得益彰
痛点
（1）管理层既要企业级实时大屏对外展现，又要满足移动端的企业经营决策
（2）业务层既要面向业务线进行监控分析，又要明细事实数据粒度自助分析
（3）公司对数据安全极为重视，行列级别较细粒度的权限管控
解决方案
（1）通过 FineReport 设计了 “管理驾驶舱大屏” 和“移动端分析平台”来解决大屏对外展示和移动端看数的问题
（2）大屏将关键信息通过大屏共享的方式可方便团队讨论和决策为企业提供直接呈现结果，让业务人员和企业决策者直观面对数据背后的信息。
（3）设计移动端的分析平台，起源于公司KA和高层常年在外奔波，很难有固定场景使用PC查看业务数据。所以通过移动端分析平台来解决非固定场景下的看数需求，提高看数用数的便捷性和灵活度，降低了看数用数和成本。
大屏
移动端
通过 Finebi 基于业务线设计看板，推动自助分析来解决
（1）通过业务关键看板进行，进行业务的整体概览，沉淀了业务场景的关键分析模型，包括指标公式拆解和关键维度下钻
（2）如销售场景下，为业务制作了销售管理驾驶舱，可以根据【城市】，【团队】，【具体销售人员】，【用户等级】，【商品】等维度，针对【业绩】进行下钻，进行异动维度归因，快速定位业务异常，及时做出运营动作进行调整
（3）瘦吧用户旅程场景下，涉及路径转化与效率分析看板，针对站内用户在app内的关键旅程进行分析，包括“激活>>注册>>咨询>>被回复>>下单”等关键路径。
（4）看板上线后观察到到“咨询>>被回复”环节中虽然转化率近60%，时间分布来看，有超过20%以上用户被回复的时长在2h以上，极大程度影响用户体验，同时这部分时长几乎无下单动作。
（5）基于该场景及时上线了回复超时惩戒机制和未被回复客户回流公海策略，将被回复时长均值从10min降低至2min，同时被回复的时长2h以上的用户缩减至1%以下，被回复>>下单环节转化提升了12%。
（6）开放自助分析，通过业务线划分数据包和数据集来实现需求中心化的管控，让具备分析能力的业务同学，能够以更细粒度，更灵活的方式进行深度的业务痛点挖掘和分析
（7）如人群洞察场景下，已经为业务制作了多业务场景的人群标签宽表，以及业务场景明细表，用户可以通过人群标签宽表创建指定人群的自助数据集，应用于具体业务场景的分析，譬如查看【近7天有活跃，但未上秤用户】的用户行为特征，制定对应的运营策略和计划进行关键行为促活
落地效果与价值
平台活跃度
- 月活跃率：70+%；月活跃用户数 100+：
- 周活跃率：50+%；周活跃用户数 80+：超过半数用户每周至少登录BI平台一次
有效用户数：目前在职且登录过BI用户155人
月活跃率 = 月活跃用户数 / 有效用户数
周活跃率 = 周活跃用户数 / 有效用户数
自助分析活跃度
- 平均业务部门至少有1个自助分析活跃用户 （ 每周至少用过1次及以上）
- 看板数量
- 现有看板60+，周活跃看板40+
需求数量
- 临时查询类需求从 50+/月 下降至 10+/月 ，减少了80%的临时查询类需求
场景二：“以数运数”——实现数据需求与指标管理的降本增效
痛点
（1）需求量级和复杂度逐渐膨胀，包括：需求出入口多收集成本高，不同需求类型内部有不同的工作流，需求数量多容易漏需求，需求复杂度高导致需求处理耗时较长，容易丢漏需求…
（2）同时数据团队建立时间较短，过去主要面向业务的敏捷开发形式来应对需求，需求处理流程较为灵活所导致的：内部需求流程不清晰，责任人不明确，处理和交付时间模糊，需求交付无通知，人员管理难度大，需求复盘成本高 等现象
（3）指标口径查询路径长，检索困难业务方对指标不能理解所带来的沟通和答疑成本；
（4）指标字典维护滞后 由于指标的开发和指标字典的维护是割裂的，导致常常BI开发同学在看板开发后较长时间未维护，通常是业务问起再进行维护，滞后性较长，业务使用体验较差
解决方案
（1）通过数知鸟进行流程管理，建立不同的工作流，进行需求分发和需求管理，人效管理和需求复盘，提高需求管理效率
（2）通过不同的工作流定制化的设置，满足了部门内个性化的流程流转诉求
（3）基于该场景，团队将数知鸟集成到了企业微信中
（4）一旦需求分发或需求状态发生变化时，会即时推送给对应的处理人和参与人，告知相关人员需求变化和需求进度，大大提高了需求分发和变更场景下的信息触达效率。
（5）减少由于需求进度不透明，变更未及时同步导致的时效性问题。
（6）通过甘特图来把控每位同学当前手上有哪些需求，进度如何，来协助判断新需求应该分发给到具体哪些同学，避免需求分配不合理导致的”旱涝不均
（7）根据不同维度，包括：需求来源部门，需求类型 等进行分析，针对需求处理时效性，通用类型需求分布来辅助团队优化需求处理流程以及数仓中的公共主题建设
（8）把指标字典更新和指标与看板的映射嵌入到了开发流程中，把指标挂载到看板上，让用户能够在看板中涉及的指标有个概览，同时减少用户检索指标时所需的路径
落地效果与价值
（1）将需求分发和变更时的触达效率变为实时
（2）根据每位同学处理中的需求梳理灵活分配新需求，保障需求分配的合理性和公平性，将需求排队处理耗时从 12小时/个，降低至 8小时/个,减少平均需求排队处理耗时 4小时 /个（前后对比值）
（3）需求复盘所需的时间成本 从6小时 / 月，降低至 2小时 / 月，减少 4小时 / 月
（4）减少指标口径答疑上的人力资源，从 1.5天 人/周 降低至 0.5天 人/周， 减少约 1天人/周
总结与展望
通过FineBI+FineReport+数知鸟的产品矩阵，公司实现了业务部门自主取数，多维分析以及常规报表随时查看，数据部也实现了需求高效流转，闭环管理，大幅提升了人效和产能，让小型团队通过敏捷开发，快速满足复杂业务逻辑，多条业务线的需求。
目前BI已成为公司员工每天上班必须打开的系统，大家也对数据的热情越来越高涨，在做每个决策前，在与客户沟通前，都会去了解数据，做到万事有数可依。数据部也在5人小团队的规模下，用一年不到的时间完成整体的数据报表和看板体系的搭建和完善。
这既离不开FineBI和FineReport强大的产品功能和性能，也离不开数知鸟对于数据工作的深度理解，让我们能通过流程和工具提升人效。
在未来的工作中，我们也会加强数据分析的投入，基于FineBI和FineReport搭建数据分析型看板，引导业务部门从看数据走到深入分析数据，让业务用起来、让人人都是数据分析师、让数据产生更大的价值！
川公网安备51015602000223号
