人气 22559

4PL的发展 我们还要等到哪天? _ 工业工程网 [复制链接]

IE深圳人 2010-10-3 01:26:54
针对运输和供应链技术的所有模式提供高级物流知识、交易处理能力的第四方物流正浮出水面。外包不再是新的想法。垂直一体化整合制造商的想法在很多年前也已经不再流行了。但是,在企业流程委外(business process outsourcing,即bpo)的大旗下,今天的公司正将那些在几年前他们想都不会想外包的业务部分地进行外包。在物流管理的案例中,货运代理和三方物流公司在很多年前就已经遍地都是了,并且他们是早期物流外包服务的提供者。这些服务提供者基本上都把注意力集中在公司物流需求的某个子集上,例如仓储或者出口物流等。但是,在今天,第四方物流可以为运输和供应链技术的所有模式提供高级物流知识以及交易处理能力,这些能力加起来就是一个全方位的物流外包解决方案。
  第四方物流的切入点是为想使用**供应链软件技术的公司提供一个新的选择。一开始,能够使用供应链软件的唯一途径是取得软件公司的许可并且将软件安装到公司自己的服务器上。然后,托管软件、应用服务提供商(asp)模式变得流行——至少变得流行谈论他们了。对于大多数的情况,托管软件模式在供应链软件领域还没有被广泛地采用。但是,现在,一种新的模式正浮出水面,那就是使用供应链软件提供的功能将高度集成的物流功能进行外包,这无论是在物流领域还是信息技术领域都是最好的选择。
  在现有软件的基础上进行开发
  应用供应链软件的能经得起时间考验的模式是从软件提供商那里获得使用许可。但不断上涨的费用以及实施的成本大都非常高昂,对于大公司至少一百万美元,并且通常甚至是这个数字的几倍。公司必须购买价值数万的硬件。维护的成本也是非常高的。每年的软件维护费用是原来软件使用许可费用的百分之十五到百分之二十。对软件进行改进以便重新进行生产支持的成本以及基本数据管理以保证复杂的供应链软件运行的成本(大都要付费的)可能也是很高的。
  大多数公司发现为了跟上他们被授权使用的供应链软件的版本可能存在很大的挑战。他们在一开始投入巨额的资源进行实施并且希望能够不再继续投入资源就能够取得收益。这也是可以理解的。但是这意味着这要使用有很多小错误和缺点的软件,而软件提供商可能在最近发布的版本里将这些错误都改正了。并且到了最后,可能公司正在使用的软件再也得不到软件供应商的支持。
  许多公司所要面对的一个相关的问题是需要定制的软件才能更好地适应业务的需求。软件定制化的程度越高,它就越难和软件供应商的软件升级版本保持同步。面向服务架构(service oriented architectures即soa)承诺使得客户化更容易并能使升级不再困难,但是它仍然处在起步阶段,而且大多数软件供应商还没达到这个程度。而且,顾问们经常对过去实施和客户化的软件比较熟悉,一旦他们更换工作,他们将会留下很大的知识空洞。组织里经常会缺少对实施足够熟悉能够帮助升级的人。结果是停滞不前的实施不能继续发展以满足不断变化的业务的需求。
  托管模式
  粗浅地想想,租赁供应链软件并且从internet上进行管理的概念看起来非常具有吸引力,因为这可以减少不断上涨的成本并且能够使得供应链的信息技术能力能够跟得上时代得步伐。但是,除了一些相对简单,没有复杂任务的业务流程不需要与别的公司系统进行复杂集成的公司采用之外,托管软件模式没有迅速火热,这种尴尬的处境和销售力自动化系统(sales force automation即sfa)如出一辙。
  为什么会发生这样的情况?专门设计的托管软件的解决方案只是一个应景的软件,它的解决方案太基础了,根本无法解决复杂公司的需求。这些系统只能提供一些比传统的授权软件系统更简单的功能。
  但是,一些成功的为中层市场提供的供应链执行解决方案也正开始出现。这些系统结合目前普遍存在的internet连接已经打破了供应链软件的成本对于大多数小型及中型公司太高的障碍,并且正开始为这些公司提供真正的帮助。在一些案例中,即使一些有着简单供应链的大公司(例如,大多数运输是使用集装箱卡车的外向运输)也能够使用这种供应链系统。但是,这些解决方案中的大部分还不能应用到具有更复杂的全球供应链的更大的组织中。他们还是没有具备所要求的所有的功能。
  一个正在兴起的解决方案
  雇佣第四方物流公司为那些想拥有前沿供应链技术的公司提供了一个选择。第四方物流公司是外包型的公司,它能够对一个制造商或者分销商的所有的供应链活动进行全面的协调。第四方物流公司由专家组成,这些专家同意在现有基础上提出解决方案,即使以前有一定的供应链管理的实践也可以。本质上讲,供应链应用软件是外包交易的一部分。
  这个解决方案不但为供应链技术的实施提供了较低的成本,还可以让公司接触到了服务管理优秀的一流的供应链技术。和信息技术外包的交易不同的是,信息技术外包是目前公司现存的系统不动,仅仅是转向使用信息技术外包商的系统,而第四方物流则提供他们自己的标准供应链软件套装,这个套装里有专门的技术蕴含其中。就像在托管模式里,第四方物流负责保持供应链软件有规律地随着软件的发布进行更新,并且解决可能发生的任何日常问题。最好的第四方物流也具有在公司所在行业进行垂直一体化实施复杂的遍及整个企业的供应链所需要的知识。
  劳动力的分工
  有任何理由让第四方物流的顾客需要接触复杂的让他们输入物流合同费率的用户界面吗?或者顾客需要改变过去的运输线路的业务规则吗?或者顾客需要调整优化算法的执行吗?
  第四方物流吸引人的地方就在于上述的所有的这些情况都更适合让第四方物流的员工解决。相比之下,托管软件的供应商需要提供所有这些复杂的功能(可能更多)给最终用户。这是对软件供应商的一个挑战,但更重要的是,在现实中,最终用户想要从这些功能里获得收益是非常困难的。复杂的功能需要大多数公司还没用有的不可想象的专业技术。
  在第四方物流模式里,软件会被训练过的专家实施、配置、维护及使用。第四方物流考虑了这些专门技术的核心技巧以及一系列相关的技巧。相比起来,对制造商来讲,它会发现当内部的专家被提升、换岗或者离开了公司,他们的职位是很难被替代的。
  寻找什么?——一套完整的解决方案
  要寻找一个适合的解决方案需要很多不同的元素。寻找一个外包的供应链技术解决方案要考虑的问题包括一下几点:
  是不是使用了标准的技术套件?许多第四方物流是来自于传统的三方物流,它们是通过并购来成长起来的。而且,他们也愿意接受处理顾客的资产、信息系统以及{词语被屏蔽}所有的东西(例如,仓库以及仓库的管理系统或者说wms)。这导致了许多不同系统七拼八凑,而且第四方物流要保持运作并且维护这些不同的系统所需要的专门技能是一项很困难的事情。一些第三方物流公司已经报告说,他们已经有超过了100家的运输管理系统和仓库管理系统,但是,第三方物流行业中的并购是非常普遍的。大多数第三方物流公司已经获得了很多小的公司。如果一家第四方物流公司有太多完全不一样的系统,它就很难掌握所有这些系统的不同的专业知识,并且服务提供者想要保持他们的信息技术平台以很快的步伐进行创新也是很困难的。
  垂直一体化行业的需求能被系统支持吗?大企业的供应链是非常复杂的。运输、为了节约和优化的分销策略每个行业都不同。举例来说,汽车工业的供应链和零售企业的供应链就非常地不同,而零售企业的供应链与化学工业的供应链也很不相同。在不同行业供应链软件的改造是非常不一样的,而且这种能力对于第四方物流是非常重要的,因为它需要在每一个不同的垂直化的市场满足相应的需求。
  系统能提供一个被证明行之有效的集成化的模式吗?传统的供应链软件的集成方法假定系统是“在防火墙后面的‘,这在第四方物流的环境下是行不通的,尤其是当第四方物流在它自己的防火墙后运行标准的底层技术架构的时候。第四方物流需要一个行之有效的基于消息的集成方法,这样才能很有希望转向采用面向服务的架构。
  他们能提供完全的可见性吗?当放弃了供应链的执行的管理权而由第四方物流来执行,所有交易的可见性就变得尤其重要。虽然每个第四方物流都说他们提供某种形式的可见性,但几乎没有公司说能对所有模式的运输都提供实时的可见性也不能查看第四方物流内部的执行流程。拥有在网络上写日志的能力以及不必联系第四方物流就可以发现某个具体运输批次详细的信息的能力不再仅仅是“最好具有‘,而是“必须具备‘。
  第四方物流证明了对记录的跟踪有创新了吗?很明显,公司外包的一个原因是费用的节省,另一个就是创新。第四方物流能够培养并且迫使有创新的新理念的实施,而这有助于改进公司的供应链。这些新的理念最终会在第四方物流的系统中得到证明。所以非常有理由这样问:“第四方物流能够证明他们可以建立一个节约成本或者提高服务水平的新方式吗?在他们的系统中你能看到这种革新吗?‘
  第四方物流对于制造商来说是运用供应链技术的一个新的选择。要与外包模式融合在一起,要从同一个供应商获得物流的专门知识以及供应链技术,需要在这两方面都做到最好。现在,第四方物流与传统的软件厂商相比能够以更低的成本提供更好的供应链技术专门技能和功能,能够只需要一个供应商就能提供一整套的服务和技术。
老狼的胸 2019-5-18 15:39:33
小白一个 顶一下
回复

使用道具 举报

@Xizi_P8dStzbT 2019-6-5 22:37:26 来自手机
大人,此事必有蹊跷!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

QQ|手机版|精益人 ( 沪ICP备19004111号-1 )

GMT+8, 2024-5-3 18:36 , Processed in 0.192146 second(s), 18 queries .

Powered by Lean.ren X3.4 Licensed  © 2001-2030 LEAN.REN