运输的生态(一)

所属行业
客户规模
核心需求

运输,这个几乎和餐饮一样古老的行业,这里说的运输,特指是快递、快运之外的公路整车和零担运输,最大的市场、最散的结构、很多的从业者,这个领域里面,包括第三方物流,运输公司、专线公司、信息中介、个体司机等等,所谓“江湖”是也。

寒冬已至,最适合温一点酒(茶也好),聊一点江湖,说一说运输。你若也有兴致,就一起来吧。

运输的完整生态是这样的,一票订单,流经:货主-3PL-分包商-司机-收货人。再延伸一下,复杂点儿:货主-3PL-分包商1-分包商2-分包商3—司机-收货人;简单点儿:货主-运输公司-司机-收货人。当然在现实世界中,复杂的多,简单的少。

其实,现在整个运输行业大家都卯着劲儿地做各种创新尝试,大都是在有意或无意的向着建立生态的方向奔去。在此简单做如下划分,一家之言,未必准确:

1. 关注局部生态:在这样一个完整的生态中,也可以划出来若干小生态,比如现在很多各式各样的APP、配货网、以及一些平台等,针对的很多都是运输公司-司机的底层生态。

2. 重塑生态,变成:货主-司机。这种是打算建个平台,干掉中间的运输公司,直接就货主-司机对接了。

3. 也是重塑生态,用创新方式建成线上运输软件社区,连接货主到司机以及中间无限层级的运输公司,做成:货主-oTMS-司机的模式(呵呵,此处真的不是广告,而是我们实在做得是一件特别的事情,自成一类了)

详细地说来,我们建立的是一个完整的业务生态:货主-3PL-分包商们(如果有)-司机-收货人,打通全链条的信息流通,但不去干涉实际运营、不干掉任何一方,而是服务于所有各方,帮助上游更好地管控下游,也帮助下游为上游提供更好的服务。让各方都从中受益,产物就是现如今的oTMS。

对于方式1,保守地看好,但是有一种可能性,局部随时随地可能变成全局,就是1向3的演化,永远存在下游逆袭的可能性,至于做得如何,那要看产品、看执行。

个人不看好方式2,基本无望。有人会说,少即是多(less is more),这是又一句被炒翻天的神句,仅次于互联网思维。可是亲们,少即是多,来源于设计师,其后延伸到互联网产品设计,但不代表放之四海而皆准的地步。作为物流行业耕耘者,在我们热情的拥抱互联网的同时,不能忘了物流行业的商业特点,这可是“忘本”。

至于方式3,非常有可能做起来,这实际是用一个更大的运输公司去替代现有的若干小运输公司,我相信在中国,会有集约化的大车队、运输公司出现,本质上,这更是一个类似第三方的内部生态。但是,具体能走多远、做多大,看产品、看执行、看博弈。

相关信息:TMStms系统物流运输管理系统物流管理软件物流管理系统物流运输系统运输管理系统物流管理信息系统物流公司管理系统运输公司管理系统

微信 vs 运输信息化:新瓶装旧酒

所属行业
客户规模
核心需求

微信,移动互联网时代最强应用,携6亿用户席卷天下,在称雄C端(consumer,消费者个人应用)的同时,众多敏锐的企业也借助微信公共号,向各自的客户提供更好的服务体验,而且,最近江湖传言,微信计划7月发布微信企业号,进军企业级市场,一时间,众多企业级软件供应商“人心惶惶”。

公路运输,信息化最弱的传统行业之一,当然快递和快运除外,快递应当是信息化武装到牙齿才对,当然目前在中国,快递信息化程度很高,但是远未武装到牙齿,但怎么说也应该是穿上了衣服。快运信息化程度应该次之,但也一样,虽不尽如人意但是也算可以蔽体。

我这里说的运输,是快递、快运之外的公路整车和零担运输,最大的市场、最散的结构、很多的从业者,这个领域里面,包括第三方物流,运输公司、专线公司、信息中介、个体司机等等,所谓“江湖”是也。在这个领域,当然也有信息化程度相对还过得去的公司,但是个体的出色掩盖不住整体的孱弱,基本我们可以把这个领域的信息化列入“裸奔”或者说-光膀子的行列。

但是这个行业/领域正在奋起追赶的前夜,正如我们一贯的观点,触底反弹、否极泰来,大家都在酝酿改变,不论是哪种模式,无不把信息系统放在很关键的位置。而微信作为时下最普及的应用,已经被一些敏锐的行内企业利用起来,向客户提供基于微信的货物追踪,客户关注企业公共微信号,输入订单号码,或者其他相关信息,便可以收到对应的回复,有的还可以下单等等。

趋势是好的,但是不赞成一些行业内人士过分夸大微信作用的观点,我觉得不能用光鲜的前端应用,掩盖孱弱的后台能力。所以,才忍不住就这个话题专门写点儿东西:

  • 方向偏了的 - 请自动纠偏
  • 方向不清的 - 希望能帮你整理思路
  • 方向正确的 - 一路狂奔吧

首先,我们从微信的角度来看(这里不谈微信营销)。对于传统行业来讲,微信可以有两个角色:

  1. 做功能应用:就是自己开发相关功能;
  2. 做开放接入:就是开放接口,接入第三方应用,比如接入传统企业管理软件

微信的角色,将取决于面对什么类型的企业级软件,个人认为大致如下,一家之言,欢迎拍砖

类型 业务复杂程度 微信作用
综合管理型ERP 非常复杂 替代没戏,可作接入
一般管理系统:CRM/HRM 复杂、但通用性高 替代没戏,可作接入
业务系统:WMS/TMS 复杂、业务个性化 替代没戏,可作接入
企业OA 简单,但个性化 影响比较大,可作应用,也可作接入,看微信怎么想
企业协同工具 简单、相对标准 影响很大,可作应用,可作接入,甚至可以替代,看微信脸色吧

对于运输这样的传统行业,开发任何一套应用,都需要有深厚的行业知识和对行业趋势的把握。明显微信是不可能杀进来做个TMS或者其他类型的运输相关管理应用的,这种东西对微信而言,是个重的要死的东西,而且我相信微信也无意于自己操刀来做每件事,作为明白的平台公司,微 信大可以开放接口,打开门来做生意,接入大量的第三方应用,把第三方应用传递来的数据、信息,通过微信这个接口,呈现给客户。

所以,对于传统运输行业而言,微信的角色是做接入,意味着微信是个渠道,是一个客户获取信息的介质,在这个意义上,微信和短信、邮件、电话是同等作用,那么关键就在于你得看企业这个微信介质的背后是什么?是发达的、整合的信息系统?那么太棒了,这个加上微信是如虎添翼, 对消费者是锦上添花。但是,如果背后依然是人工、电话、Excel呢?那么我们只能称之为新瓶装旧酒,治标不治本。

针对这一点,我们再深入展开分析一下:

领域 客户类型 和微信结合
快递 B+C 自身信息系统健全

增加微信作为一种新的前端服务窗口

快运 B为主 自身信息系统健全

增加微信作为一种新的前端服务窗口

公路整车/零担 B 自身信息系统落后

使用微信=新瓶装旧酒

观点如上,大家应该一眼就能看明白:

  1. 快递领域:非常好的探索,给用户,尤其是个人消费者更多、可能也更方便的下单、查询的选择;
  2. 快运领域:同上
  3. 公路整车/零担:也是很好的尝试,毕竟给客户多一个选择,而且某种程度上可能会有其方便的地方,比如对于终端收货人可以关注某个物流公司的公共号,输入订单号码,查询订单状态,但是我总觉得这是一个典型的新瓶装旧酒的事儿,我不否认微信的便捷性和普及性,但是不代表具有普适性,尤其在B2B中的业务流程有关的方面。那么让我们一起透过现象看看背后的玄机:

a)微信入口的背后:如前所述,抛开微信的光环,把微信当作和短信、邮件、电话同等性质的介质或入口来看,你就能淡定的去问:1、你从微信查到的信息是哪里来的?很大程度上微信是一个入口,背后对接的是企业的内部IT系统,用纯手工的方式来支持微信入口,绝对属于出力不讨好;那么2、企业内部IT系统的信息是哪里来的?我想这个地方的回答和以前的应该没什么变化,大部分是根据承运商的excel反馈,然后自己录入的;如果有人说还开放了端口给承运商,那么请再多问一句,那么承运商还有下家,直至司机,这些还是老套路,并无区别:手工的流程+微信的查询界面。

不可否认这仍然是一种进步,起码给用户多了一个选择,更多的去考虑终端用户服务体验,但是并未带来实质性的改变,真正的改变应该来自于合作企业之间的协同和连接。

b)货主:如果作为货主方,你会使用微信来查询和管理订单吗?微信入口更适合于作为用户界面,而不是作为管理界面。

c)收货人:如果是收货人,你会使用吗?我估计很多人会回答是的,但是经过我们的实践验证(非微信,其他方式),这是需要区分场景的:1、如果是经常性的稳定收货人,比如你一个月要配送给他几十票、上百票订单这种,有可能会用。如果是偶发性收货人,难度比较大,一个月订机票货,还得去关注一个物流公司的微信号,还得每次想起来去查询,这是一件想起来容易做起来难的事儿,大家看看自己的微信里面已经关注了多少公共号?;2.收货人主动查询还是推送给收货人:如 果是前者,效果要差很多,如果是后者,则会好很多。我的忠告是不要高估人们在工作方面的积极主动性,除非他很热爱工作,或者万不得已要出事儿的时候。

好的衣服,不但得有漂亮的“面子”,也得有牢靠的“里子”。

好的运输信息化,不但得有便捷的前端应用,更得有强大的后台体系。

与君共勉。

相关信息:TMStms系统物流运输管理系统物流管理软件物流管理系统物流运输系统运输管理系统物流管理信息系统物流公司管理系统运输公司管理系统

什么样的TMS是可以信赖的?

所属行业
客户规模
核心需求

前言:

这是2012年11月7日发表在物流沙龙的一篇文章,是对一篇国外的文章《什么是可以信赖的TMS》的简单翻译和分析,写在我创业之初。昨天又重新看到了英文原文,所以顺带把当时这篇评论也找出来,发现经历创业1年多之后,有了更深的认识和更多的体会,重新整理一下,和各位分享。

另外,顺带着还打算回炉重炒另一篇2012年11月28日在沙龙发表过的文章《信息技术+互联网:走向中国公路运输的美丽新世界》。

之所以回炉这两篇,共同原因都是:1、我个人以为这两篇文章的主题仍然是正确的、代表未来、值得坚持和分享的;2、有些原来的分析比较片面或肤浅,把这1年多来的相关感悟放进去,会更加客观和深刻。

文艺一点儿的说法是:不变初心,方得始终。

文学一点儿的说法是:温故而知新,可以为师矣

物流一点儿的说法是:行业进化,人人有责

欢迎拍砖。

英文原文的出处:

题目:What type of TMS solution is best? (翻译成中文:什么是可以信赖的运输管理软件)

发表:ARC Insight

作者:Steve Banker (ARC顾问集团供应链和物流方面负责人,福布斯的供应链和物流专栏作者,在美国的供应链和物流领域有相当的江湖地位和权威性)

如果对原文有兴趣,可以在微信留下您的邮箱,我们统一发送,或者您可以到物流沙龙去下载。

以下内容,蓝色部分是简单翻译原文的意思,其他是我个人的分析和观点。

1、以欧美市场为背景,作者提出现在市场上主要的两种类型的TMS

  • 传统TMS——类似所有传统软件, 单用户模式(single tenant),软件、数据库安装在用户自己的本地服务器或托管的服务器,软件的核心是企业自身,供自己内部使用,软件系统内的数据不和其他合作伙伴共享;
  • 社区型/平台型TMS——多用户模式(multi tenants),SaaS模式,用户不需要安装任何软硬件,直接登录网页即可使用软件。用户除了得到TMS的基本功能,同时也是加入一个“社区”,里面有你现在的合作伙伴,也有其他成百上千个新的公司,大家共享一些标准的流程、共享共同的数据、进行数据传输和业务管理。在这种环境下,不但有利于和现有的合作伙伴的更好的协同(因为数据共享),而且有发现更多新的业务或者新的承运商资源的机会。
  • 列出了在国外主要的两种TMS的供应商:

个人评论:

  1. 这是2012年的文章,表单里面不乏我们耳熟能详的名字,其中JDA和RP发生了并购,不知道是否SAP TM可以递补上来;在社区型TMS的名单里面,有C.H. Robinson,这是在当下中国运输行业被推崇备至的一个名字,大把大把中国的物流公司都标榜自己要做中国的C.H. Robinson,愿景是美好的,目标是远大的,路途是漫长的,但是相信总会有公司摸索出来中国特色的C.H. Robinson的。(有心研究C.H. Robinson的同学们可以直接去他们网站下载很多资料,C.H. Robinson在这一点上做的特别好,把很多资料公开分享,尤其是对于中国大部分公司现在趋之若鹜的Managed TMS服务模式,有很多详细的资料可以借鉴,而不必成天听一些“专家”在那边灌输一些二手资料)
  2. 传统TMS软件的指导思想来源于传统的生产制造企业,把运输等同于企业内部活动,所以关注的是企业的内部流程管控和优化、数据分析等等;社区型TMS软件的核心思想侧重于连接,把不同企业连接起来,进行更好的协同、合作。
  3. 但是就运输的特点来看,不论美国还是中国,大部分是通过外包来完成,只不过外包的层级和每层的玩儿家不一样,比如美国更整合一些,中国更分散。那么对于运输,显然不同于生产、财务等以内部为核心的ERP思维方式,运输的绩效和成败更多的取决于和合作伙伴之间的协同。
  4. 介于两者之间,还有一类脱胎于传统TMS的进化版,由某个大型的货主或3PL企业开发,以该企业为主,让所有的承运商使用这个软件,可以下载订单,追踪反馈,回单上传,生成帐单等等。这种方式有其进步的地方,但是长远来看,缺点很明显:1、这种软件是属于某个龙头企业的,所有的数据是在他的服务器上,利益是单方面的,承运商一定不会把自己的数据(比如成本、分包商、司机)放到这个软件中来,无法实现提升自己管理的目的;2、因为第1点,这种连接关系只能止于第一层,无法打通全链条;3、因为第1点,对于物流公司,这等同于他们操作这个企业的运输业务的额外成本,如果这个物流公司操作5个这样的客户,那么他得操作5个不同的系统。

2.两者现在优势、劣势比较

作者在对两者优劣比较的时候,观点很客观,传统TMS依然在一些重要方面占据优势,比如战略采购、功能全面性、规模化、优化功能等,同时社区型/平台型TMS在则一些执行层面更有优势,比如过程透明性,数据实时反馈,数据真实性,数据传输等。具体内容,大家可以看下面的表:

 

  • 作者也坦言,虽然社区型/平台型的TMS在很多方面占据优势,但是目前总体来说还是传统型TMS市场份额更大,因为传统TMS在战略采购和优化方面做得更好,当然另外一个重要原因是大型的跨国公司更加青睐传统TMS。

个人评论:

  1. 特别说明一下什么是基于管理的服务(managed service):看似不起眼,但为什么特别解释呢?就是因为大家推崇备至的C.H.Robinso的核心服务模式之一就叫做managed TMS,理解为运输管理外包,或者4PL,第四方物流,一个人人都知道怎么叫,但是没多少人知道怎么做的模式。
  2. 就各自优缺点来看,传统TMS更适合于高度集中的运输市场,一些大货主、大公司主导运输市场,各自有自己的TMS,管理自己内部的复杂流程,同时,彼此之间,也可以通过EDI实现数据交互;社区型的TMS更适合于分散的、完全市场化竞争的运输市场。
  3. 社区型TMS更接近日常执行层面,传统TMS的优点更侧重大公司的战略层面,比如说优化功能,其实如果你是个货量不大的企业,那么这个功能基本就和你无关了,优化更多针对是一个企业,有足够多的货量、使用足够大的网络才会有意义。
  4. 个人认为,在中国的市场环境中,优化功能的应用属实有限。比如,优化的基本前提是有好的数据,那么以中国运输市场来看,数据基本来自手工,准确性、可信度、可用性很低,垃圾的数据做出来的只有垃圾的结果。
  5. 另外,优化功能的应用有其适用领域,比如长途干线运输、外包运输等理论上可以优化,但是变量太多,影响优化结果。有的比如使用货源集中、车源稳定的市内密集配送、或者业务相对固定的milk-run等,则有相当的优化空间。
  6. 另外一个很重要的因素,价格。传统TMS的价格一般都是比较贵的,而且是一次性支出购买软件证书+后续每年的维护费用,一次性投入比较大。而社区型TMS因为其SaaS模式的特点,按需付费,随时退出,成本低,风险也低。

3. TMS的未来

对于这个话题,作者的观点是:现在,传统的TMS做的更好,但是TMS的未来,属于社区型/平台型TMS。原因有两个:

  • 后者正在日渐努力缩小与传统TMS在功能全面性和优化能力方面的差距;
  • 这个是最关键的原因,目前尚未利用的但是最大的可能降低运输成本的因素是降低车辆在路上的空驶,而这一点,只有社区型/平台型才有可能做到。作者引用美国交通部(US department of Transportation)的数据为证,美国有25%的车辆在路上处于空驶状态。而中国,据统计可能超过50%。

个人评论:

这一点我个人绝对认同,就降低成本而言,对于甲方也好,第三方物流,运输公司,甚至专线公司,都是永恒的主题。就内部深挖,提高自身等方面降低成本,我想很多公司已经做的够多了,而中国过去10年的运输市场也反映了这一点,价格一直在降,成本一直在涨,生意还是一样在做,所以近2年,我们才会越来越多谈公路运输困境,生存空间缩小,变革之年。。。。也出现了很多创新的思路和模式,比如快运进一步提速,各种联盟、平台等等。而社区型TMS,则是从更广的角度去看整个运输产业链,连接货主-3PL-大中小运输公司-司机-收货人,有几个关键点(这里我们只谈思路,不谈产品,不做广告):

  • 连接是核心:1、必须是多层连接,不仅仅是上下两层;2、连接关系种,数据可以流动、信息可以共享,但是企业身份需要保密,要尊重实际业务逻辑;3、这种连接没有从属关系,而是平等的,每个人可以做自己的生意。
  • 提炼流程,标准化,了解细节但不沉溺于细节而不自拔 — 谁都知道也会说“中国运输市场很复杂,需求都不一样”“市场太不成熟了,不适合我们的软件/系统”,但是这些都不足以成为阻碍创新的借口,反而该是动力,市场如果很好很成熟,创新何来?正所谓:技术应该顺应市场需求,而不是等待市场“成熟”.
  • 注重用户体验,关注终端客户:在B2C的运输(快递)体验面前,B2B被比的一塌糊涂,在大家都在想怎么差异化竞争的时代,其实,最能差异化你竞争优势的就是想方设法给你的客户包括终端客户,提供越来越好的运输服务体验。
  • 低成本、低风险的SaaS模式:我个人认为,未来不是所有软件还能舒服的靠着现有的卖证书+维护费+定制费生存了,从一些较为通用的软件领域已经可以初见端倪,比如客户关系管理(CRM)领域的salesforce,或人力资源(HRM)的workday。软件业的趋势,未来可能主要就3种:大型综合管理软件在结合移动端应用和开发一些轻应用后,依然生命力旺盛:比如SAP, Oracle;流程更复杂、客制化程度高的领域,还是传统软件,比如WMS;更标准化的领域,转向SaaS,比如CRM,HRM,OA,也包括运作执行层面的TMS等。

最后,再回到我们的题目,什么样的TMS才是可以信赖的?

看完这篇文章,可能很多同志们会说,是社区型TMS,出发点是产品。

下面,是另一种更加形而上的答案,出发点不是产品,是客户,因为不论什么样的产品,他是一个工具,用的好坏取决于使用的人。

我的一个朋友,他在一家大型3PL中负责市场&销售,他们公司在选择TMS,当他老板问他对于选择TMS的期待是什么的时候,他回答是:我希望我们公司花在TMS上的每一分钱都能让我们的客户直接感受到,而不只是一个仅仅关注公司内部的系统,更不只是一个存在于销售ppt上面的系统。

当公司花钱购买一套系统的时候,买的应当是价值,而不是软件本身。

Pay for value, not for software!

相关链接:TMStms系统物流运输管理系统物流管理软件物流管理系统物流运输系统运输管理系统物流管理信息系统物流公司管理系统运输公司管理系统