在大数据概念迅速普及、产业快速发展的今天，运营商仍以传统的通信思维看待大数据业务的发展，导致其在发展中陷入了某些误区。
误区1：大数据项目应当“做成产品”
最容易形成这种误区的就是运营商的政企服务机构。在他们的工作中，有一大部分的时间是用来联合设备厂商或服务支撑方满足客户各种需求，尤其是在一些ICT项目中，“运营商+服务方”联合投标的模式屡见不鲜。
在这种背景下，运营商习惯于打包提供“整体解决方案”的模式。这里面一个非常核心的点是：运营商要在摸清客户需求的情况下，协同服务支撑方事先提供一套产品/服务方案，这套方案的顶层设计、解决方案、落地服务都是由运营商或者服务商单方面提供，客户主要负责定方向以及政策指导。而在这种思维模式下，运营商更愿意将项目做成“产品”提供给客户。
然而在大数据合作项目中，笔者更愿意称之为“服务”。一个巨大的差异点在于：客户需要全程参与项目设计，在模型训练及数据验证的过程中要进行实战演练，在一些关键模型、核心参数的设定上要有明确的意见。而在此过程中有一个心态和理念上的重大区别，如果说在政企的ICT项目上，运营商扮演的是“包工头”角色大包大揽，那么在大数据项目中，运营商更多应该充当“开放平台”，将数据作为能力开放出来，数据应用的事交给更专业的行业用户。这样既可以为运营商提供广阔的思路、积攒宝贵的经验，又可以在合作过程中探索和实践出一套互信机制。
误区2：大数据项目应当“做大做强”
在运营商发展大数据的过程中，一个比较突出的现象是做大数据项目，往往都是“大”项目。一方面，大项目的影响力更大，更容易出彩；另一方面，运营商政企机构“对等服务”的设置也在某种程度上决定了高层级政企机构只愿意做高层级客户，无论从职责还是意愿上，他们都不太可能去找低层级客户。
基于此，对于高层级客户肯定要“高大上”，功能越多、越全、越高级越好，界面越酷、越炫、越缤纷越好，对于重要客户，“面子”是一定要给足的，至于报价，通常都是“鉴于双方深厚的合作基础或一定要着眼未来，不要太在意短期收益，适当收点费就可以了。”
但这样做最有可能导致的后果就是快速透支新型业务的价值，有可能导致这个业务线迅速进入枯水期。事实上，运营商的流量经营就是让流量快速贬值，从而迅速见顶。
所以笔者认为，运营商的大数据项目应该做小、做精、做深、做透、做实，真正在客户的实战场景中发挥作用。让客户用了就说好、用了就离不开。如此，才能真正深入用户，让功能变成服务、再让服务变成收入。
误区3：大数据项目应当“由内向外”
有一种观点认为，运营商的大数据项目就应该“从内到外”，也就是说主要服务内部，然后再逐步考虑外部应用。理由也非常简单，如果连自己的稀饭都“吹不冷”，又怎么能做好外部的事情？更何况，还有一把“用户隐私”的“达摩克利斯之剑”高高悬在头顶。
事实上，这种逻辑未必成立。在笔者看来，大数据项目真正成功的关键往往是部门与部门之间、行业与行业之间打破数据壁垒，产生融通价值。让人感到遗憾的是，尽管运营商拥有海量数据，但这些数据多是散落在M/B/O三域当中，经过多年的发展，不同的IT系统像是一个个高高的烟囱，随之而起的还有部门之间越来越厚重的“部门墙”。
相比之下，外部则有所不同。对于其他行业来说，通信数据是一个完全陌生的领域。从概率上来说，这种“结构洞”式的机会往往会带来“跨界交叉的意外惊喜”。两个完全不同的行业数据碰撞得出有趣结论的可能性的确会更高一些。更何况，通信数据本身就蕴含着十分丰富的内涵。
因此，只要找到合适、可靠的行业，将两者的数据打通、解构、清洗、再结构化并进行交叉分析，有很大的机会可以做出某个特定场景下的“神奇功能”。当然，这里的场景一定是基于行业用户的自身实际应用，绝非是那些“面子工程”。
误区4：大数据项目应当“自上而下”
按照运营商拓展政企市场的思路，通常更习惯于“自上而下”的策略，即与垂直行业的上级管理机构签订战略框架合作协议，再由运营商各级分公司与属地机构签订业务协议。
其实，“自上而下”部署项目是一把双刃剑。好处在于，一旦项目签约成功，可在相对较短的时间内完成某个行业的全面部署；坏处在于，客户需求不易收敛，项目极有可能失控，同时，通过行政命令强压下级机构执行时，下级单位处于被动接受的状态，或许会出现“消极怠工”的现象。
所以，笔者更倾向于“自下而上”去推动大数据的发展，原因非常简单：基层单位往往更接地气，可以在一些特定的场景、特定的行业以及特定的区域中形成收敛的需求，容易形成单点突破和饱和度攻击，最终直接产生“实战”效果。更加深层次的原因在于，基层单位主动创新提出的项目，往往在落地执行过程中更具主动性，一旦项目具备规模推广的可能性，无疑将为基层单位在上级管理机构那里变成加分项。
本文转自d1net（转载）
