从设计的角度看待物流软件-转自http://hi.baidu.com/maimouse/blog/item/a59501a7e22e0396d14358b6.html

从设计的角度看待物流软件

从设计的角度看待物流软件是我们讨论物流软件不得不面对的问题，这在软件当中称之为边界划定，任何服务于第三方的物流软件，都离不开软件分析、软件设计和软件实施。当前物流软件的形势不容乐观，到目前位置，我们目睹了一批又一批的物流软件公司的倒闭和物流软件的失败。如何让软件企业和用户走出这样的困境？是我们今天讨论的重点。 物流软件的发展态势 　　问题开始之前，我们首先回顾一下大的物流行业的大背景， 2000年时物流公司都是传统性的，那时候货贷、仓储、配送叫物资部门或叫仓储部门，从那年开始有很多物流公司，以前是货贷公司，改成物流公司，但是经过这么多年的发展，我觉得物流本身没有大的变化，只是换了一个名称，里面的本质还是传统的仓储。 　　从我接触物流的时候，就谈信息化和物流的整合，直到现在软件企业也一直在这么做，但我认为，目前的物流信息化大部分只是为了迎合物流企业，企业为了上软件而上软件，而不是为了整个的资源和供应链，而物流软件的功能也都只是为了解决业务操作问题。 　　另一个需要回顾的是物流软件的大背景。目前的物流软件尚处在一个尴尬的局面，目前是很多物流公司，物流软件起来之后倒闭得很快，转行得也很多，整个行业似乎存活的比较很艰难。 　　究其原因我认为，第一个原因就是软件的开发成本很高，很多物流公司把软件当成项目做，导致很多软件公司为迎合物流企业的需求，特别开发一套软件出来，给这个物流公司用。而在面对另外客户的时候，软件公司将这套系统包装一下，换一个页面便成了一套物流软件产品。可是这个并不一定对每一家物流公司适合，因为他是根据某一个客户来定做的。 　　我们知道虽然说中国的劳动力工资很低，但是相互于来说，在软件行业的成本，对其他行业的成本还要高，所以说软件公司的成本是比较高昂的，而另一方面物流公司的成本就没那么高了，物流公司是属于劳动密集型企业，它没有那么多血液供这个物流软件公司完成项目，所以这两方面产生矛盾，一旦软件公司没有物流公司供的话，又找不到其他的物流公司，那么他只能做其他的，比如说做OA，做ERP，它为了生存就做得不专了，物流软件公司的倒闭也就在所难免。 　　刚才说了，因为对一个产品来说，可以降低开发成本，比如说以前开发成本20万块钱，如果用四五家的话，可能一家就5万块钱，如果10家的话，那么一家只拿5000块钱就可以了，这样可以给软件公司带来血液，最后可以成活起来，像一些大公司，他们开始也做项目，但是开始是兼职，慢慢的对软件完善，最后到应用，所以可以带动起来，本身也是集中这一个行业的解决方案，另外对产品的完善，在细节这个地方，可以决定产品的存活和存在。 　　因为这个产品可以存活，因为这个团队可以存在，所以当这个物流公司应用软件的时候，那么它的售后服务，它的客服都可以提供完善的支持，这对于物流公司也是双赢的方案。产品开发的两种模式，一个是以项目带产品，因为以项目带产品，这是最实际，最实用的，因为中国的开发模式。 变项目为产品，物流信息化的最优解 　　为什么中国的软件公司，很少有产品做好的，除了用友跟金蝶在财务方面做得很漂亮，但是其他的在产品方面，做得都做不了很长久。这是我目前没有想清楚的问题，也是很困惑的一个问题。 　　但是以项目带产品的模式，我认为是一种伪产品的开发模式，因为从我们看到的事实和情况看，我们很多软件公司给物流公司做产品的时候，只是因为要做这个，我给你设计这个，所以只是从项目的开发，最后形成不了产品的设计模式。这里面的原因就是说，一个项目设计的一个基础，和这一个架构，因为软件我们强调一个架构，为什么强调这个问题呢，它的目的就是说在建一个房子的时候，首先把房子整个一个模式，和架构撑起来，但是你要的是卧室，还是办公间还是什么东西，那是内部模块做的，但是对项目设计来说，因为你开始的时候，比如说我要的是一个住宅区，那么在做项目的时候，开始模块和架构，就设计成一个住宅，那么另外一个公司可能要的是商用房，那么如果把住宅房的结构用到商用房做的话，肯定不适合的，第二个原因就是说，如果这个项目要转换过来，把以前的结构全部推翻掉，再设计一个商用的一个模块，这样的话肯定他俩之间的理念和模式的转换，肯定是有冲突的，以前的设计人员很难做，这样的话，这个项目最后会做得比较失败。 　　另外一种，以产品带项目，当然这个问题我要强调一点，可能这里面大家可能会问一个东西，就是说一个鸡蛋的问题，是有鸡还是先有蛋，是先有产品，还是先有项目，按我的想法来说，是先有项目，因为软件是新生事物，在多个项目上提取精髓，做出一个产品出来，但是我觉得目前作为物流软件的开发来说，我们可以跃过这个阶段，因为软件很多是通用的开发模式，软件有很多积累，从60年代的时候，国外开始软件做库存，在中国从八十年代，九十年代就开始做这个，现在来说，应该有做这种做产品的能力和架构。 　　所以说我觉得可以用产品这种方式，来做物流的项目。而这个就是说，我们先做好一个，就像建楼一个，我们先做好一个公用的结构，再在此基础上再做，这就是我们产品的骨干和架构，通过各种模块，适应特性的东西。 　　我套用一句古话，就是说，由产品入项目易，由项目入产品难。开发产品属于一个开发观点的问题，我觉得这个问题要分析一个共性的问题，现在我觉得整个社会上，比较急功近利，比较浮躁，很多东西要讲爆发，想拿到一个东西的时候，马上就把这个东西给开发完事了，开发完了之后就收钱，收钱之后就不管了，很多软件公司都是这样，不管是为了生存也好，还是什么也好，但是很难保证软件的长久性。我跟曲攀也探讨过这个问题，一个短期的现金流跟长期的利益发生冲突怎么解决，他的回答就是认真，持久，不能为了短期的利益，去抹煞整个的长远的规划，我觉得很多软件公司，为了顺应客户这么一个东西，顺应客户的需求，也不顾自己产品的规划，立马开发东西出来，找了那么四五个比较有开发经验的工程师，一个项目不管架构，不管什么东西，也不管需求，不管产品延伸，两三个月全部搞定，还设计得很漂亮，觉得是定制的东西，但是这样的话只是为客户而做，但是不能抽取行业的共性。 业务+ 软件发展流程式物流软件 　　人才问题，因为设计任何一个产品来说，软件现在虽然说发展成为一种体力劳动，但是总的来说，相对其他的工作，它应该还是脑力性的劳动，它的智力密集型还是比较多的，当然在软件公司人的密度是最高的，从某种程度来说，也是劳动密集型的。 　　对于人才来说，我觉得这是跨两个领域的，因为作为行业的产品来说，必须要抽取这两个领域的共性，对于物流来说，要精通物流的业务，对于软件来说，要精通软件的设计和模块的区分，但是这两类人才，我觉得还是很获缺的，我本人来说，我对两个领域都是一知半解，甚至说物流只知道1/10，软件只知道1/5这样的，这两个是乘法的关系，所以两个加起来也只知道1/50。人才市场上有很多这样的人才，因为现在就业压力很大，所以软件公司觉得在市场上做IT的，到处都是，其实这种人才，真正符合行业的人才还是很少的。因为这个产品对他来说，这么一个项目，四五个就可以做，但是他只有两个最差的做开发维护就可以，其他的做关键岗位的，分析人，主要的程序开发人员都会被开掉。只留一个水平很差的人，一个月开一千多块钱，做维护。 　　用产品带项目这种可行性在什么位置，首先我觉得物流业务的本质是相同的，我这里面插了一个物流的概念，就是物流是物质资料从供给者到需求者的物理性运动，主要是创造时间价值和场所价值，有时也创造一定加工价值的活动，我在软件公司做需求分析的时候，我对物流的总结是这样的，物流要解决的问题，就是说在什么地方，有一批货物，是什么人委托的，在什么时间取，送到什么地方去，由什么人接收，大概这么一个情况，这是委派给第三方物流的，一个业务性的指令，我觉得无论是配送，还是其他的认证方式，对于总结来说，这种业务模式，我觉得都可以这样抽取，什么人在什么时间，送什么东西。大概要费多长时间，围绕这个业务完成的一系列工作，不论是配送还是仓储的东西，都会这么共性的抽取，当然这个模型对不对，还有待于各位对这个物流很精通的专家做验证和分析。 　　从软件技术来讲，现在软件技术应该说很强的，以前在开发工具来说，比如说最开除接触的是C语言，C这种程序语言是面向过程的开发语言，这种语言对写应用软件是不适合的，后来微软提出了一个，是面向数据库检索的，我们上学的时候，这个语言是风行的，后来还有微软的VB，这种东西涉及CS结构的东西是可以很快上手的，后来就是微软推出他的（荡来特）架构，之后还有其他公司推出的架构。我说的这些有点太专业了。 　　这个架构就是说，比如说设计一个楼，把整个的架子，骨架的东西放好了，你下面的工作在骨架上完成就可以了，这样就把每一块东西切割得很明确，从复杂到简单的模式就符合思路，把这个东西设计完善出来，这种架构就能够支持整个物流软件产品的开发，另外再提的，就是SOA的架构，这可能是最近比较流行的一个理念，SOA在软件上是一个开发的思路和理念，很多大的技术解决方案公司都在推这个解决方案模式，IBM明年好象要力推SOA架构上的物流解决方案。不知道这是真的还是假的。 　　另外就是工作流技术，为什么我要单独提呢，因为物流来说，整个流程是很复杂的流程，虽然说我刚才那么抽象的说，从什么地方，到什么地方，什么时间由什么人取，最后收货方是谁，如果加上异地的配货，在配送这块，要从一个地方取，通过一个线，放到异地，从异地再同城分发，这么一个定单的流程，可以说中间是很浩大的流程，所以说我在这儿要提一个软件技术上的公众流技术，作为OA审批，把这个流程审批作为技术上的集成，这样就可以作为整个定单的流转和处理。 　　最后我想给物流企业一点一点小建议，虽然很多公司说定制怎么样怎么样，在推销软件方案的时候，说我的软件就给是你定制的，很适合你，但是其实定制不一定合适你，为什么呢，首先定制不代表贴身，为什么呢，因为软件在应用到你实体当中，会对你本身的业务流程产生一个变化，如果你在这个开发软件之前，不去想这一个软件应用之后，会对你目前的业务流程，产生的变更，而对你软件做出调整的话，那么你的软件，应用到实际业务当中，就不一定适合你了。在这个位置的话，我当时在想这个问题的时候，有用到了一个系统的一个反馈的概念，就是说你的业务流程，开始的时候，在没有运用这个软件的业务流程是A，但是当你运用了之后就变成了B，你的业务进行了重组，就是你变成了B的结构，可是你设计项目的时候，你的软件还是按照A这种模式设计的，所以说这样的话，在设计这个软件的时候，那么你就应该考虑到，你应用这个软件的时候，会对你这个业务流程，产生什么样的变化，而再根据这个变化设计一个调整思路，这样的话可能更贴身。 　　所以我觉得定制并不代表贴身，而反而开发成本很高，因为我的软件只给你用，所以我所有的开发成本都摊在你身上。然后就是定制带来的风险很大，很多项目是人走茶凉，他给你开发完了，走了之后，这个项目没有人维护，当你有什么变更的话，你就找不到原来开发这项目的公司，如果这个公司的话，也找不到这个人，而代码的话，如果你想改掉某一批东西的话，做开发代码的人知道，读别人的东西是很恶心的一件事儿，所以大家在做的时候一定要谨慎。花了几十万块钱一定要谨慎。 　　选择一项产品的时候，你大的业务流程，还有管理思想，必须要跟你的物流公司的这一个运作的流程是基本一致的，因为只有这样的话，才不会对产品做伤筋动骨的改变，再就是整个细节方面，很多时候就是细节决定成败，因为很多公司设计的时候，因为物流的共性在这儿放着，如果他在这一个地方，设计得不完善，因为底下的操作人员，一旦拿到这个东西的时候，就会觉得很别扭，然后就会抵制产品的实施。