前沿观点
管理层与数据分析

科学管理、严格执行、数据支撑,商业分析才能起作用

作者:Brady  来源:数海时代  发布时间:2013-1-3 12:12:04  点击数:2560

   前一阵完成了一个经营分析系统的咨询项目,客户是一个电子商务公司,在系统开发前期规划需要在业务系统上,建设一个经营分析系统。项目曲折,期间客户的管理层负责项目的人员换了一茬,技术开发人员也换了一茬,系统最后连滚带爬出来了一个“初级阶段”的系统,现在正在小流量的初期运行。虽然参与项目的成员都有进步,但我对项目的总结经验,还是要多想伤疤不忘疼,多记成功经验所需要的前后条件,因此总结的经验不管是成功点还是失败点,都是我和客户需要铭记记取的。

一、管理层需要了解数据分析
   在现在的技术条件下,开发一个流量不很大产品也不很多的垂直电子商务网站系统,也已经是一个难度不很大的挑战。现在总结起来,客户遇到的真正挑战基本都在管理环节。由于历史原因,客户的管理层多是销售和业务出身,对数据分析的理解是有所欠缺的。前期沟通时客户就一直询问我“能否把你手头的销售管理和分析系统的‘干货'给一些?”,我简要介绍了一些不涉及具体客户的成熟的营销管理方案思路,演示了未来经营分析系统可能达到的效果。客户中层管理人员仔细听后,再和我讨论时我总感觉有些出入。好在客户和我对接项目的人头脑清楚,详细解释后基本能够理解,并能努力协调开发前后相关人员落实。但是后来在开发过程中,客户的中层管理人员调整了一次,此后每过一段时间,客户管理人员阶段总结项目进展时,随着经营分析系统对数据指标的要求细节逐步提出,客户对开发方向的调整使我感觉对数据分析的作用理解出入有些大,而客户的接口人和项目组其他人的沟通,也开始日益艰难。
   例如,经营分析系统中有一个小模块,需要给出针对每个具体的用户对某产品在售前售中售后三环节的服务水平对总的客户体验满意的贡献度,我们一起研讨用了简单的类似Y=AX+BY+CZ这样的函数模型。这在实际业务上遇到需要处理大量的客户存在缺失Y或Z的处理情况,可行的处理方法并不复杂,也有多种选择,但均需要具体考虑不同用户的体验场景,有些地方需要人为设定并在日后的运营中具体微调。但客户的中层管理人员,提出一定要在缺失的情况下也能算出Y来。我解释说,如果是对群体做分析,这样的Y相当于平均值,不难。但对差异很大的个体而言,硬算出个平均值,就可能和统计局公布CPI和房价一样,多数人听了都不会满意。客户坚持说,你一定能算出来,我很无奈,这真不是能否计算出的问题,而是计算结果是否对未来真实业务有益的问题。


二、管理方案需要稳定
   经营分析系统,无论设计得再灵活智能,最终都需要支持客户的管理方案,因此客户的管理方案是否稳定,既体现客户运营管理思路的清晰,也体现了团队的成熟。这个项目中,有一个模块需要分析不同来源的用户在网站不同页面对不同产品和内容的反应和转化,除了需要日后运营中的AB测试外,经营分析系统是需要把数据关联起来做交叉分析的。项目组在这个需求上反复修改,修改原因是多方面的,都是管理和运营方案不确定,反复调整导致一直稳定不下来这个需求。开发人员在敏捷开发的压力下,后来索性精简得数据没有关联,因此这个功能没有实现。现在这个系统在运营上,就遇到了缺乏这种转化分析的数据支持,业务运营人员一直凭直觉BD。


三、项目目标和模块功能定位需要明确
   任何一个商业智能系统应用模块的提出,都是围绕一个业务的管理主题而提出的。所以,首先需要回答的是——是要解决一个管理方案的数据支撑问题,还是要改善数据的展现方式和交互形式?在实际项目中,经营分析体系所包含的业务主题非常宽泛,这些管理主题的每一个业务模块又可以分解为大量的关键业务指标。很显然,这些管理模块中的每一项关键指标几乎都是常规业务系统所无法提供的,而必须由一个个专用模块计算完成的,这些专用模块不仅需要大量基础数据的支持,同时,包含了复杂的业务逻辑维护和复杂中间计算过程。由于前面的管理方案不稳定,最后面的BI工具本身是不能也不会去参与这种数据的加工和业务逻辑处理的。
   因此,带有经营分析功能的数据挖掘系统,如果要实现带有促销响应、客户关系管理等应用模块功能,系统的关键并非“数据分析”,而是“数据加工”。也就是说,这些项目成败的关键在于业务逻辑和功能模块的明确和处理,而不在于数据的存储和展现手段。

四、需要事先客观分析基础数据环境
   经营分析系统,是将营销过程产生的相关数据,转化为知识和营销决策支持的数据加工和分析展现系统,如果前端系统开发的功能不完善,存在数据不一致和逻辑不合理,再加上边设计边开发边修改,重要产品没BD落实就没开发,后来一说可能可以就匆忙上马,上马后又说不行了再下马...。冷静下来就很明白,对于没有实际运营过经营分析系统的用户,特别是业务系统也如此,初期最好人工分析一段时间,有了固定的经营分析模式后,再逐步开发可能更好。当然这样的不足之处,是会对客户的分析团队和运维团队产生很大的压力。
   实现经营分析主题,需要很高的业务分析能力和基础数据整合能力。项目开发过程中,需要系统开发者提前对已有的基础数据进行了充分的采集和规范化整理,对数据源的质量提出系统的运营管理规范,这些都直接影响到系统最终业务目标的实现。如果没有这些专业的基础数据整合方案和数据模型,如果没有从整体高度赋予数据一个“活的灵魂”,再怎么完工的系统都是单薄或没有生命力的一堆代码。
   所以对于商业分析咨询顾问而言,对客观数据环境的分析和基于客户团队管理和未来业务运营的准确评价,以及对未来数据管理规范的制订,是成功与否的关键步骤之一。

五、在开发中,避免脱离用户和隔靴搔痒的需求
   人的想象力总还是比能做到的要多,当中层管理人员人事变动时,需求只是交给基层人员凭空猜测,虽然会让人觉得无穷尽,但是带来的可能是脱离用户的需求,或需求被多次修改到隔靴搔痒。由于开发团队也换了一茬,中间过渡期间开发人员根据实际进度压力频繁修改项目需求,最终导致业务人员往往仿佛一开始就是等着验收软件,不再多想参与详细需求的制定和坚持,开发细节的大部分都是靠开发人员的猜想,而猜想往往和实际有差距。经过无数次的往返交流,业务需求人员在繁琐中失去耐心,开发人员索性天马行空猜测一番了事,双方都互相不愿意再去麻烦对方。好在相关模块还没有规划开发,但这种危险倾向是已经潜在存在的。

   所以,我们必须清醒地看到:上述这些问题和经验未必概括全面,也未必导致这个项目马上会遇到极大的困难。但若继续忽视而不改进,后面继续更大规模的开发,就会导致系统存在更大的缺陷。
   总之,经营分析系统的核心是“经营分析”,而不是软件工具或技术;管理的核心是规则、流程和模型,而不是空洞的概念和光鲜的展现图表。商业智能的基础包括了业务数据、业务定位、商业策略和管理思维,商业智能系统只是其中的一个管理手段、一个管理工具而已。没有数据和业务体系加以支撑,“智能化功能”是无法得以实现的。在有效的数据整合和数据规范基础上,合理地应用数据仓库和商业分析技术,构建完整的经营分析数据模型和专业的营销管理模型,才是有效实施商业分析系统的关键所在。

 
分享到:
  • 上一篇:没有了
  • 下一篇:没有了