用好技术有效管理软件

　　5年对于一套运行的信息系统而言是漫长的，尽管我们可以乐观地说“不长”，但是现实已经击碎了这种乐观，击碎它的不是技术的变革，而是在竞争的压力下，企业的规则、流程、组织、战略的一系列的变化，会将“信息系统”的不变特征击得粉碎。如果有人仍不相信5年的周期极限，可以去那些已经使用了较长时间信息化系统的企业中去了解，所有的使用者一定在抱怨它们的系统已经无法适应现在的需要，已经成为必须替代的软件产品;同样也会发现，企业的战略、企业的规则、企业的组织都已经有或多或少的变化，那种一成不变的企业在现在的经济社会中，已经少之又少。

　　既然建造一个能够支撑5年的信息系统非常之难，那么，如何保证一个信息系统能够支撑5年呢?这个问题的另外一种说法就是：如何选择适合企业信息化的技术路线呢?

　　平台体系的选择

　　在软件选择中，企业必须坚持大众化、广普化的开放性原则，选择那些技术路线相对成熟，而且适合于企业当前管理需要的基础软件开发平台，无论这种平台是否是面向供应链体系，还是人力资源，还是财务管理，它必须坚持要选择那些适应于这种软件长期使用的体系。否则的话，不到5年，系统将成为历史。

　　主流的基础软件体系，它会在一定的时期内保持稳定，所以认真选择基础软件的技术路线是非常必要的，它是系统稳定的重要因素。就目前而言，如果企业希望构筑连接企业内外的供应链体系，那么与互联网技术相关的基础系统软件产品，就成为了软件开发平台的主流选择。今天互联网络公司所经常使用的JAVA、ASP、.NET，已经成为解决供应链应用体系的应用软件系统开发的核心平台。

　　从现在的角度来看那些成功的信息系统，如“海菱”、“伊利”分销(DRP)系统的基础软件体系的选择，都是正确的，它的正确就是因为它已经选择了一条为解决企业广域化的供应链管理(销售链管理)而全面采用了基于互联网应用的体系。

　　1. 广普原则下操作系统的选择

　　对于操作系统的选择，从中小型企业、中大型企业而言，只有两种考虑，一种选择WINDOWS系统、一种选择UNIX系统。微软所开发的系统最大的特点是使用群体庞大，可维护人员众多，而且人力成本相对较低，比较适合于中小型企业的信息化应用。而UNIX系统安全性较高，系统比较稳定，但由于它的普及率远没有微软系统高，所以使用人群相对较小，系统维护人员缺乏，造成人力成本相对偏高，这种系统比较适合对于安全性要求较高、对于系统的稳定性要求较强的大型企业集团。

　　2. 硬件体系选择方针

　　如何选择系统设备?这一问题实际上依赖于所选择的软件路线，如果选择的是基于微软体系之下，那么建议采用PC服务器系统，当然，这个选择会面临服务器性能太弱的问题，为解决这一问题，微软在其所提供的WIN2000专业的服务器操作系统中提供了面向多台主机的“动态平衡”机制，确保了多台服务器同时并行工作，保证了数据处理功能的需要。

　　如果在软件技术路线的选择中，采用了java技术，那么建议选择 UNIX服务器，它同样可以为企业提供很好的服务，当然所花费的成本会高些，如果企业能够承受，这种花费并不算太大，但是必须要考虑使用这种开发环境的人员总数量，这个人员群体与熟悉微软系统的人员群体相差极大，作为企业很难留住这种系统的维护与开发人员，即便能够留住，还同样面临着未来接班人员的培养问题。

　　忠告——

　　总而言之，一定要记住：

　　企业只能够使用成熟技术体系下的软件，并非常认真考察软件是建立在哪种技术体系下，在确定软件的技术路线之后，再去确定其他设施的技术路线。有几点也必须提醒，在选择时应当学会平衡：

　　* 技术路线的选择过程，请坚决忘记个人的技术偏好;

　　* 安全与不安全都是相对的，在安全体系上的投资价值如何?

　　* 任何选择，在技术上都是成立的，但请从成本、人员角度考虑;

　　* 不要偏废基于WEB开发技术与基于C/S开发技术的任何一种;

　　* 多考虑未来的维护，少考虑目前的成本;

　　* 数据库技术已经很完美，无论选谁性能上也许相差无几，但维护人员来自何处?

　　应用体系的选择

　　上面所提到的技术路线的选择只是一个方面，另外一个选择是建立在这个基础路线选择之上的信息系统结构的选择，这种结构的好坏同样影响系统较长期的有效性。当企业把信息系统生命周期定为5年的时候，这一有效性的作用明显会体现出来。信息系统建设过程中必需坚持“实用性原则、易用性原则、适用性原则、灵活性原则”，当然还会包括“安全性、系统的扩展性”原则等诸如此类，那么这些原则在说明些何种问题呢?它的中心目标是在确定一个系统的优良与低劣的标准。

　　1. 易用性

　　“易用性”所要表达的是易于使用，这种易于使用不是纸上功夫，它要求软件去掉一切繁琐的、不必要的内容，而直面用户的使用方便，它要求处理一个事件如果只存在3个步骤和4种算法，那么必须要清晰地告诉使用者每个步骤的处理结论与错误提示，而不是不清不白，让使用者不知所云;它同时必须提供一系列的使用引导和帮助，能够让使用者非常容易记住流程，记住运作规则，它必须保证在系统中需要用户填写的内容必须填写，不需要的内容绝对不能够填写，它同样必须保证系统中所提供的操作功能具有非常好的辨识性，等等诸如此类，事实上任何优秀的软件必须做到这一点，而不能够把一个简单和清晰的流程变得复杂化。

　　2. 适用性

　　“适用性”要表达的是，一个信息系统必须能够解决一个行业或一类企业的现实问题，它必须要有很强的针对性。在制药领域的应用中，它就必须支持国家管理部门所推动的GMP、GSP规则;在服装和鞋帽领域的应用中，它就必须支持专卖店管理;在食品和奶制品领域，它就必须支持保质期和生产批号的管理，它就必须支持城市内的当天生产、当天配送的业务。因此说每个行业的不同，它所面对的应用的特殊性是不同的，这就要求信息系统一定是为解决某类问题、某类特殊性所建设的系统，而不是一个貌似全面，实际上没有任何特点的系统，那么这样的系统是不具备行业的“适用性”，它只能够被称作一个没有行业特点的通用化系统，在解决实际具体问题时，它的一切弱点都暴露无遗。

　　3. 实用性

　　“实用性”在告诫每一个从事信息化的工作者，软件的实用性是信息系统的生命源泉，如果我们不太在意对于信息系统实用性的思考和辨识，那么企业将会面临灾难，这种灾难不仅仅是实施时间的延长，而是系统实施的失败，是信息系统的整体性失败。在今天，有种非常自欺欺人的说法——“一个系统，如果有部分子系统应用起来就算是系统成功”，在这种言论或者思维的笼罩下，可以看到弥漫在国内众多成功实施信息系统的企业的报道中，其“成功”的不准确性。

　　这些年，国内曾经报道过许多成功的信息化案例，大概总数应当有200-300多家，为了了解这些案例的实际应用状况，笔者曾经虔诚地向20多家的企业打了电话，寻问他们的应用情况，但是非常遗憾，真正完全让系统全面运作的企业居然只有2-3家，剩下的企业通常只是使用了所购买软件的一个部分或者是几个部分，那么为何有些子系统无法实施?企业的人员回答得非常简单，“这些子系统无法在我们的企业应用，因为它的流程和规则与我们的实际情况相差太大”。

　　上面提到的情况，告诫企业在选择信息系统的过程中应当如何去看待系统的实用性原则，无论软件公司有多大，无论软件的知名度有多大，无论产品的包装和宣传多么地吸引民众，你都必须认真地对照企业的实际去判断软件的实用性。

　　其实软件的实用性判断是艰难的，它有太多因素的制约，一个是企业的现有业务流程与规则的制约，一个是企业业务流程调整的制约，一个是企业的管理者的管理思维的制约，一个是企业管理者对于流程调整决心的制约，一个是信息系统软件流程与规则适应企业的制约，一个是软件实施人员能力的制约，一个是企业信息系统推动小组的主管的综合能力与知识的制约，等等。这些制约的因素已经让许多企业信息系统主持人的大脑变得一片空白，几乎让他们对于实用性的选择进入了迷茫状态。在这种情况下，建议企业的管理者尝试用一种排他性的思维去思考：

　　你需要开展流程变革吗?

　　如果回答是，

　　那么，就要研究软件与企业变革后的流程运作的可行性;

　　如果回答不是，

　　那么，继续问，你们企业可以开展一些适应性的流程调整吗?

　　如果回答是，

　　那么，就要研究软件与有限的调整后的流程运作的可行性;

　　如果回答不是，

　　那么，不用研究，尽快抛弃与现有流程不相适应的所有软件产品。

　　尽管，这看起来似乎是一项简单游戏，但它确实是一种非常有效的方法，这种方法的运用，对于企业根据自身的需求选择软件，提供了一个非常简单的思维武器。

　　4. 灵活性

　　“灵活性”原则的真实意义就在于并不仅仅强调现在，而更加强调整个信息系统生命期内的软件的适应性要求。企业在长达5年的信息系统生命期中一定会存在流程的调整、规则的调整，甚至是组织方面的调整，那么如何去保证这些调整之后信息系统能依然适用呢，这本身就是一个非常难以预料的事情，几乎所有的软件商都不敢有足够的勇气打下保票。但是，透过信息系统的构造方式还是能够看到软件是否能够可以在有限的空间之中作出些许调整的能力，那么这种能力的强弱已经与软件的构造水平有很大的关系。一般来说，一个优秀的软件构造存在两种不同的形式，分别可以称其为“基于系统维护的构造体系”、“基于系统组件的构造体系”(这里的组件不是指编程时的组件，而是指信息系统功能的组件化)，这两种构造体系都是可以支撑一定的系统灵活性需求。

　　“基于系统组件的构造体系”的设计是一项分常艰辛和认真的工作，它与维护体系之间存在一个最大的设计区别，就是维护体系并不需要在设计阶段开展流程的最小功能的划分，而组件的方式，它必须在设计之初对于所有的业务流程实行最小模块的拆分，这种拆分的优劣实际上就决定了系统的灵活性的优劣。这种“搭积木”的方法，尽管具有非常强的灵活性，可以适应几乎所有的变化(如果不能适应的情况下，也可以追加新的积木)，但是由于它所需要的功能模块的拆分、数据的拆分、数据表的拆分(数据库中的一种数据实体的组合方式)，必然引发运行效率的降低，尽管现有的机器系统已经提供了非常庞大的运算能力，但是由于这类系统的复杂性，它同样会面临系统效率的低下，这种低下可能在互联网络体系下表现得更加突出，而如果这种系统只是在一个工厂、一个总部这类本地化运行的状态中，可能并不被明显感觉得到。

　　最后必须明确的是，信息系统的技术路线，不仅仅是针对硬件体系、网络体系、基础软件体系、数据库体系，同时也是针对信息系统的构造体系而言，如果我们偏颇了任何一种，那么企业在技术路线的选择方面都会犯严重的错误，至少会使企业的信息化过程变得并不顺畅。