随着全民健身上升为国家战略，测量评估自身运动强度及效果的运动计量App也应运而生。
“要运动，用咕咚！”作为以计步器为主概念的“咕咚”运动软件用户规模堪当翘楚。“咕咚”会在云端为用户保存各类数据：运动时长、距离、轨迹、卡路里消耗。当用户以个人形式注册使用时没有任何疑义，但当企业内部全员推行健步走活动时，组织架构、人员姓名、通信方式以及日常生活轨迹就一览无遗地暴露在第三方软件面前了，以第三方软件为载体开展全员健步走的策划只能暂缓。
那么问题就来了，引领型的信息运营商居然连一个小小的应用软件自主开发都受制于人，那么以引领通信、存储、位置、支付、社交等4G业务应用为己任的宏图又从何谈起呢？
继续说这个计步器软件，遍历各运营商，几年前还真有某省公司自主开发了一套计步器软件，这下应该不存在企业内部信息泄露的问题，也不存在各省软件定制开发的合同费用了。于是周边几个省公司都做了免费的应用移植部署，并放心地在公司内部注册推广了。
开发这款产品的公司，确实具备了轻量级应用开发的土壤。简单来讲，该公司在信息系统部下设了一个ICT开发中心，中心以具备较强开发经验的内部员工为支撑，长期签订外包开发人员为梯队，形成了一只可控的小体量软件产品的开发团队，既可以满足内部信息化的敏捷型开发需求，也可以迭代的方式满足集团客户、个人客户的定制化或标准化开发需求。在短短的几年时间里，该团队在缩短开发周期、把控开发质量等方面也带来了一些亮点，很可惜因为不会带来公司主营业务收入的大幅度提升，也不会提升KPI，最终随着机构的整合而夭折了。
再看看其所在部门，一方面团队尝试在移动客户端做一些源程序开发工作，在SAAS的“一网多包”项目做了部分模块的自主开发工作；另一方面看到集团客户产品仍依赖专线等哑通道等方式创收的尴尬情形，也尝试将公司内部信息化产品包装推广。反观身边，IT人员缺少进入通道，纷纷以转型业务主管为自豪，导致IT人员越来越少。考虑架构的少了，研究代码的少了，由于话语权的不足常常为业务部门想当然的姑且称之为需求的东东疲于奔命，又不得不在业务主管的签字权前不敢主张。反映在结果上，IT系统软件被绑架的情形屡屡发生：上至未来3~5年的投资规划，下至具体实施项目的工作量及上线时间，无不充斥着合作伙伴的影响力。
举个简单的例子吧。信息化软件遵循相似的业务管理流程，因此在软件设计方面有很多的相似性。为了保护甲方的知识产权，合同条款上虽然明确了“由受托方提供给委托方的各种软件产品，委托方拥有其全部权利，且委托方拥有基于前述软件和文档、数据模型、类库等进行软件再开发的权利”或“受托方提供给委托方的各种软件产品，委托方与受托方共有知识产权”等条款，但此类知识产权保护条款形同虚设。在兄弟省份希望引入类似功能软件时，由于不能掌握设计开发的主导权，在合同签订时不得不再次以定制化软件的工作量进行定价；开发商在将软件改头换面以后再以定制化软件或标准化产品进行市场推广，享受“一菜多吃”的待遇。
再举一个例子，“平安通”之类的视频监控软件以license等方式向购买方出售许可权，在其他省份早已实现的平台功能沽出高价，使运营商处于欲罢不能的尴尬境地：继续升级则被深度捆绑，推倒重来费时费钱。
这类案例不胜枚举。
痛定思痛，再反思我们运营商的IT部门。在注重3G、4G网络建设的同时，信息化实现能力及转化能力被大大地忽略了。集团公司在进行SAAS模式推广和集中化探索几年后，莫名其妙地撤销了管理信息化部门，以上两个方向的探索也被搁浅。而各省公司也不断将信息化部门边缘化，IT自主能力逐步削弱，IT部门没有话语权，IT业务的实现较多地具有了外部依赖性。在此同时，业务的增值模式由单纯的CT模式渐渐向ICT及IT方式转变，集团及各省公司逐渐壮大的IDC及互联网业务种类就是佐证，但主要依靠松散型外包的模式究竟能不能挽救运营商的疲软，答案不言而喻。
在互联网业务的世界，竞争的残酷性与业务替代的速度，契约模式不是理想的手段甚至只能徒劳无功。对于产品的快速响应和目标一致是必须的胜利法则。因此，需要运营商上下做好几大能力储备，才能正确对待“咕咚”等的挑战。
运营商总部应加强信息化部门的配置，加强内外部信息系统的规划，加快SAAS业务的市场转化能力。一方面汲取“一网多包”类业务的经验教训，选择市场需求较广泛的业务，并尽可能与已大规模成熟应用的系统相冲突；另一方面缩短业务的开发和推广周期，保持市场的热度。
运营商总部应合理规划总部、省两级开发模式，避免重复开发问题。在接口平台、数据总线、ERP等基础业务及标准化较高的信息化系统统一建设；各类应用系统及个性化模块尽早放开各省建设的自主权，形成统建+自主的合理开发模式。
各省应加强IT人员的资源配置，并保持合理的自主开发能力，在内外部系统的开发上具备足够的话语权。一方面在具备架构设计、规划治理的能力，另一方面能够快速实现零星开发需求及具备开发商议价的能力。
各省可以建立一支复用的开发队伍，既能实现内部信息化的需求，又能满足外部客户的IT整合需求，同时还能将内外部信息化产品进行合理的转化，使公司资源能够合理的利用。
也许，“咕咚来了”不是件坏事，“咕咚”软件的案例客观上可以倒逼运营商发现自身的问题，加强自身的IT实现和交付能力，从而思考在信息化转型方向上应具备的自身能力，在人员培养和职责分配上给予IT人员足够的空间。