這段時間做項目，美工設(shè)計的界面輸入框都是圓角的，確實很好看，研究了一下，實現(xiàn)起來真還有些麻煩

firefox，safri，chrome這些瀏覽器基本都一定程度支持新的CSS3標(biāo)準(zhǔn)，可以用CSS來搞定圓角：

  1: border-radius: 5px; /* css 3標(biāo)準(zhǔn) */
  2: -moz-border-radius: 5px; /* mozilla */
  3: -webkit-border-radius: 5px; /* webkit */

可是M$的IE就麻煩了， 直道IE9 還沒完整支持CSS3，就只能用背景圖片法，前后補(bǔ)圖法等等，來模擬圓角效果了

上網(wǎng)查了一些資料，摸索著用Flex寫了一個 文件上傳的工具。沒做太多修飾，主要代碼貼出來，免得以后忘了

   1:  <!-- filename :flashuploader.mxml -->

   2:  <?xml version="1.0" encoding="utf-8"?>

   3:  <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

   4:                  xmlns:c="component.*"

   5:                  width="450" height="450" minWidth="460" minHeight="400" initialize="application1_initializeHandler(event)" layout="absolute">

   6:      <mx:Style source="css/main.css"/>

   7:      <mx:states>

   8:          <mx:State name="TEST">

   9:              <mx:AddChild position="lastChild" relativeTo="{filelist}">

  10:                  <c:uploadFile currentState="UploadError">

  11:                  </c:uploadFile>

  12:              </mx:AddChild>

  13:          </mx:State>

  14:      </mx:states>

  15:      <mx:LinkButton id="selectbutton" x="5" y="5" label="{selectlabel}" click="button1_clickHandler(event)"/>

  16:      <c:CountingVBox id="filelist" x="5" y="36" height="100%" maxCount="{max}"/>

  17:      <mx:Script>

  18:          <![CDATA[

  19:              import component.uploadFile;

  20:              import mx.events.FlexEvent;

  21:              private var filter:Array;

  22:              private var single:Boolean;

  23:              

  24:              private var fileRefs:FileReferenceList;

  25:              

  26:              private var fileRef:FileReference;

  27:              [Bindable]

  28:              private var max:int=10;

  29:              [Bindable]

  30:              private var selectlabel:String="文件上傳";

  31:              

  32:              

  33:              

  34:              private function button1_clickHandler(event:MouseEvent):void

  35:              {

  36:                  if (single){

  37:                      fileRef = new FileReference();

  38:                      fileRef.addEventListener(Event.SELECT,singleSelectHandle);

  39:                      fileRef.browse(filter);

  40:                  }else{

  41:                      fileRefs = new FileReferenceList();

  42:                      fileRefs.addEventListener(Event.SELECT,multiSelectHandle);

  43:                      fileRefs.browse(filter);

  44:                  }

  45:              }

  46:              

  47:              private function singleSelectHandle(event:Event):void

  48:              {

  49:                  var file:uploadFile = new uploadFile();

  50:                  file.parentContainer=filelist;

  51:                  //                file.fileRef = FileReference(event.currentTarget);

  52:                  file.fileRef = fileRef;

  53:                  filelist.addChild(file);

  54:                  

  55:              }

  56:              

  57:              private function application1_initializeHandler(event:FlexEvent):void

  58:              {

  59:                  if( parameters.labelselect !=null) selectlabel = parameters.labelselect;

  60:                  if( parameters.ext != null)

  61:                      if ( parameters.type!=null)

  62:                          filter=[new FileFilter(parameters.type,parameters.ext)];

  63:                      else

  64:                          filter = [new FileFilter("Select Files"+parameters.ext, parameters.ext)];

  65:                  

  66:                  

  67:                  if (parameters.single!=null && "true" == parameters.single.toLowerCase()){

  68:                      single = true;

  69:                      max = 1;

  70:                  }else{

  71:                      if (parameters.max !=null )

  72:                          max = parameters.max ;

  73:                      if (isNaN(max)||max<=0 ) max=int.MAX_VALUE;

  74:                  }

  75:                  filelist.addEventListener("EMPTY",restoreSelectButton);

  76:                  filelist.addEventListener("FULL",disableSelectButton); 

  77:                  var prefix:String="http://localhost/fileupload";

  78:                  filelist.urlRequest = new URLRequest(prefix+"/upload.php");

  79:              }

  80:              

  81:              private function multiSelectHandle(event:Event):void

  82:              {    

  83:                  var fileList:Array=fileRefs.fileList;

  84:                  for(var i:int =0;i<fileList.length;i++){

  85:                      

  86:                      var file:uploadFile = new uploadFile();

  87:                      file.parentContainer=filelist;

  88:                      file.fileRef = fileList[i];

  89:                      filelist.addChild(file);

  90:                  }

  91:              }

  92:              

  93:              private function restoreSelectButton(event:Event):void

  94:              {

  95:                  selectbutton.visible=true;                

  96:              }

  97:              

  98:              private function disableSelectButton(event:Event):void

  99:              {

 100:                  selectbutton.visible=false;                

 101:                  

 102:              }

 103:              

 104:          ]]>

 105:      </mx:Script>    

 106:  </mx:Application>

   1:  <!-- filename: component/uploadFile.mxml -->

   2:  <?xml version="1.0" encoding="utf-8"?>

   3:  <mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"

   4:             xmlns:c="component.*"

   5:             height="20" width="440" initialize="canvas1_initializeHandler(event)" >

   6:      <mx:states>

   7:          <mx:State name="UploadError" >

   8:              <mx:SetProperty name="label" target="{progressbar1}" value="{errorInfo}"/>

   9:              <mx:SetProperty name="styleName" value="error"/>

  10:          </mx:State>

  11:          <mx:State basedOn="UploadError" name="FileError">

  12:              <mx:SetProperty name="x" target="{image1}" value="317"/>

  13:              <mx:RemoveChild target="{progressbar1}"/>

  14:              <mx:SetStyle name="styleName" target="{label1}" value="error1"/>

  15:              <mx:SetProperty name="toolTip" target="{label1}" value="{errorInfo}"/>

  16:          </mx:State>

  17:      </mx:states>

  18:      <mx:Image x="5" width="16" height="16" source="{fileicon}" verticalCenter="-1" />

  19:      <c:FilenameLabel x="23"  width="160" text="{filename}" truncSize="10" verticalCenter="-1"/>

  20:      <mx:Label x="185" width="64" text="{extname}" verticalCenter="-1"/>

  21:      <mx:Label id="label1" x="251" width="64" text="{filesize}" textAlign="right" verticalCenter="-1"/>

  22:      <mx:ProgressBar id="progressbar1" x="317" width="100" height="16" label="%3%%" labelPlacement="center" maximum="100" source="{_fileRef}"

  23:                      verticalCenter="-1"/>

  24:      <mx:Image id="image1" x="419" width="16" height="16" click="cancle_clickHandler(event)" source="@Embed('icons/cancel.png')" verticalCenter="-1"/>

  25:      <mx:Script>

  26:          <![CDATA[

  27:              import flash.events.MouseEvent;

  28:              import flash.events.ProgressEvent;

  29:              

  30:              import mx.controls.Alert;

  31:              import mx.events.FlexEvent;

  32:              import mx.states.Transition;

  33:              

  34:              private static var MAX_FILE_SIZE:uint =int.MAX_VALUE;

  35:              

  36:              private var _parent:CountingVBox;

  37:              [Bindable]

  38:              private var _fileRef:FileReference ;

  39:              [Bindable]

  40:              private var errorInfo:String="";

  41:              [Bindable]

  42:              private var fileicon:Class;

  43:              [Bindable]

  44:              private var extname:String;

  45:              [Bindable]

  46:              private var filesize:String;

  47:              [Bindable]

  48:              private var filename:String;

  49:              

  50:              

  51:              

  52:              

  53:              public function set fileRef(value:FileReference):void

  54:              {

  55:                  _fileRef = value;

  56:                  filename=_fileRef.name.substring(0,_fileRef.name.indexOf(_fileRef.type));

  57:                  extname=_fileRef.type;

  58:                  var size:uint=_fileRef.size;

  59:                  var unit:String="B";

  60:                  if(size>10240){

  61:                      size/=1024;

  62:                      unit="KB";

  63:                  }

  64:                  if(size>10240){

  65:                      size/=1024;

  66:                      unit="MB";

  67:                  }

  68:                  if(size>10240){

  69:                      size/=1024;

  70:                      unit="GB";

  71:                  }

  72:                  

  73:                  filesize=size.toFixed(0)+unit;

  74:                  fileicon=getFileIconClass();

  75:                  if (checkFilesize()){

  76:                      _fileRef.upload(_parent.urlRequest);

  77:                      _fileRef.addEventListener(DataEvent.UPLOAD_COMPLETE_DATA,upload_complete); 

  78:                }

  79:              }

  80:              

  81:              public function set parentContainer(p:CountingVBox):void

  82:              {

  83:                  _parent = p;

  84:              }

  85:              

  86:              

  87:              private function getFileIconClass():Class

  88:              {

  89:                  [Embed("icons/Unknown.png")] 

  90:                  var unknown:Class;

  91:                  

  92:                  [Embed("icons/doc.png")]

  93:                  var doc:Class;

  94:                                  

  95:                 //其他文件類型

  96:                  

  97:                  if (_fileRef.type == null){

  98:                      return unknown;

  99:                  }

 100:                  

 101:                  var type:String=_fileRef.type.toLowerCase();

 102:                  if (type == ".doc") return doc;

 103:                  if (type == ".docx") return doc;

 104:                  //其他文件類型

 105:                  

 106:                  return unknown;                

 107:              }

 108:              

 109:              private function cancle_clickHandler(event:MouseEvent):void

 110:              {

 111:                  _fileRef.cancel();

 112:                  _parent.removeUploadedFile(_fileRef);

 113:                  _parent.removeChild(this);

 114:                  if (_parent.count<1){

 115:                      _parent.dispatchEvent(new Event("EMPTY"));

 116:                  }

 117:              }  

 118:              

 119:              protected function upload_complete(event:DataEvent):void

 120:              {

 121:                  _parent.addUploadedFile(_fileRef); 

 122:              }

 123:              

 124:              protected function upload_IO_error(event:IOErrorEvent):void

 125:              {

 126:                  errorInfo="UploadError";

 127:                currentState = "UploadError";

 128:                   

 129:              }

 130:              

 131:              private function checkFilesize():Boolean

 132:              {

 133:                  if (_fileRef.size>MAX_FILE_SIZE){

 134:                      errorInfo = "File too Big";

 135:                      currentState = "FileError";

 136:                      return false;

 137:                  }

 138:                  return true;

 139:              }

 140:              

 141:          ]]>

 142:      </mx:Script>

 143:  </mx:Canvas>

 144:   

你是否有過復(fù)查程序時發(fā)現(xiàn)有些注釋毫無用處？程序注釋是為了提高代碼的可讀性，為了讓原作者以外的其他開發(fā)人員更容易理解這段程序。

我把這些讓人郁悶的注釋方式歸為了五類，同時把寫出這些注釋的程序員也歸為了五類。我希望讀了這篇文章后你感覺自己不屬于其中的任何一種類型。如果你有興趣的話可以讀一下另外一篇文章 五種程序員(英文)，和這篇講到的五種程序員對比一下。

1. 高傲的程序員

public class Program

{

static void Main(string[] args)

{

string message = “Hello World!”; // 07/24/2010 Bob

 Console.WriteLine(message); // 07/24/2010 Bob

 message = “I am so proud of this code!”; // 07/24/2010 Bob

 Console.WriteLine(message); // 07/24/2010 Bob

 }

}

這種程序員是如此的欣賞自己的程序，以至于不得不在每行代碼上都署上自己的大名。應(yīng)該讓版本控制系統(tǒng)來提供程序變更的信息，他這樣做一眼看去并不能說明誰對這行代碼負(fù)責(zé)。

2. 過時的程序員

public class Program

{

static void Main(string[] args)

{

/* 這段程序已經(jīng)不再有用

* 因為我們發(fā)現(xiàn)千年蟲問題只是一場虛驚

* 我們的系統(tǒng)不會恢復(fù)到1/1/1900 */

//DateTime today = DateTime.Today;

//if (today == new DateTime(1900, 1, 1))

//{

// today = today.AddYears(100);

// string message = “The date has been fixed for Y2K.”;

// Console.WriteLine(message);

//}

 }

}

如果一段程序不再有用（比如廢棄了），那就刪了它吧——不要被幾行沒用的注釋搞的程序混亂不堪。即使你可能以后重用這段代碼，你也可以使用版本控制系統(tǒng)，用它把你的程序恢復(fù)到以前的樣子。

3. 天真的程序員

public class Program

{

static void Main(string[] args)

{

/* 這個程序是用來在屏幕上

* 循環(huán)打印1百萬次”I Rule!”

* 每次輸出一行。循環(huán)計數(shù)

* 從0開始，每次加1。

* 當(dāng)計數(shù)器等于1百萬時，

* 循環(huán)就會停止運(yùn)行*/

for (int i = 0; i < 1000000; i++)

{

Console.WriteLine(“I Rule!”);

}

}

}

基本的編程語法規(guī)則我們大家都知道——我們不需要“編程入門”。你不需要浪費(fèi)時間來解釋一個顯而易見的東西，我們更希望知道的是你的程序功能——那是浪費(fèi)空間了。

4. 傳奇的程序員

public class Program

{

static void Main(string[] args)

{

/* 有一天我在大街上的一家星巴克里

* 和銷售部的Jim討論問題，他告訴我

* 銷售代表是依據(jù)以下的比例提取傭金的。

* 周五: 25%

* 周三: 15%

* 其它日期: 5%

* 我是否告訴你過我點了一個卡拉梅

* 鐵咖啡和兩份的Espresso?

*/

double price = 5.00;

double commissionRate;

double commission;

if (DateTime.Today.DayOfWeek == DayOfWeek.Friday)

{

commissionRate = .25;

}

else if (DateTime.Today.DayOfWeek == DayOfWeek.Wednesday)

{

commissionRate = .15;

}

else

{

commissionRate = .05;

}

commission = price * commissionRate;

}

}

如果你不得不在注釋里寫明需求，那也不要提到人名。銷售員Jim很可能在公司里不再是銷售。而且大多數(shù)讀到這段注釋的程序員未必都知道Jim是誰。你描述的是實際情況但跟我們的內(nèi)容不相干，所以就省掉吧。

5. 未來程序員

public class Program

{

static void Main(string[] args)

{

//TODO: 將來我會修復(fù)這個問題 – 07/24/1995 Bob

 /* 我知道這個問題很難解決而且

* 我現(xiàn)在依賴于這個Contains函數(shù)，但

* 我以后會用一種更有意義，更

* 優(yōu)雅的方式打印這段代碼。

* 我只是現(xiàn)在沒時間。

*/

string message = “An error has occurred”;

if(message.Contains(“error”))

{

throw new Exception(message);

}

}

}

這種注釋是一種集大成者，它包含了上面所說的注釋的所有問題。TODO注釋在一個項目最初的開發(fā)階段是非常有用的，但這個注釋看起來是在好幾年前的產(chǎn)品程序里的——它證明了程序有問題。如果程序有問題需要解決，馬上解決，不要拖到日后再解決。

如果你寫過這樣的注釋，或者是你正在尋找一種最好的注釋方案，我推薦你讀一讀Steve McConnell寫的《Code Complete》這本書。這是我推薦給所有程序員必讀的六本書中的一種。或者你可以學(xué)學(xué)如何停止注釋你的程序(英文)。

你是否在你的程序里還見到過其它種沒有意義的或討厭的注釋？歡迎共享。

英文原文：5 Types of Comments to Avoid Making in Your Code

　　開發(fā)框架的選擇，始終是個仁者見仁、智者見智的事情。尤其是Web層的開發(fā)框架，數(shù)量非常多，而且各有特色，如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。

　　下面先來看看為什么要使用Web開發(fā)框架

　　一：使用框架的必然性

　　框架，即framework。其實就是某種應(yīng)用的半成品，把不同應(yīng)用程序中有共性的一些東西抽取出來，做成一個半成品程序，這樣的半成品就是所謂的程序框架。

　　軟件系統(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別是服務(wù)器端軟件，涉及到的知識，內(nèi)容，問題太多。在某些方面使用別人成熟的框架，就相當(dāng)于讓別人幫你完成一些基礎(chǔ)工作，你只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計。這樣每次開發(fā)就不用白手起家，而是可以在這個基礎(chǔ)上開始搭建。

　　使用框架的最大好處：減少重復(fù)開發(fā)工作量、縮短開發(fā)時間、降低開發(fā)成本。同時還有其它的好處，如：使程序設(shè)計更合理、程序運(yùn)行更穩(wěn)定等。基于這些原因，基本上現(xiàn)在在開發(fā)中，都會選用某些合適的開發(fā)框架，來幫助快速高效的開發(fā)應(yīng)用系統(tǒng)。

　　了解了使用框架的必然性，下面來看看如何選擇，當(dāng)然我們的話題集中在Web層的開發(fā)框架。在談這個問題之前，先來看看我們在Web開發(fā)中究竟需要做些什么工作：

　　二：Web層開發(fā)的工作

　　在J2EE開發(fā)中，分層是基本的思想，3層架構(gòu)或者多層架構(gòu)早已深入人心，在這里我們就把目光集中到Web層，看看到底Web層開發(fā)做了那些工作：

　　1：數(shù)據(jù)展示

　　Web層需要從邏輯層獲取需要展示的數(shù)據(jù)，然后以合理的方式在頁面進(jìn)行展示

　　2：人機(jī)交互

　　用戶需要從界面上輸入數(shù)據(jù)，在界面上進(jìn)行按鈕點擊，進(jìn)而觸發(fā)事件，標(biāo)準(zhǔn)的事件驅(qū)動模型，然后跟后臺進(jìn)行數(shù)據(jù)交換，出現(xiàn)新的界面。

　　3：收集數(shù)據(jù)，調(diào)用邏輯層接口

　　Web層收到用戶的事件請求，需要調(diào)用相應(yīng)的邏輯層接口來進(jìn)行處理，Web層是不會有任何邏輯處理的。調(diào)用邏輯層接口，需要傳遞參數(shù)，這時需要收集用戶在界面上輸入的數(shù)據(jù)，然后進(jìn)行組織，組織成為邏輯層接口需要的數(shù)據(jù)封裝形式(通常都是ValueObject)。

　　4：根據(jù)邏輯層的數(shù)據(jù)來重新展示頁面

　　邏輯層處理完了，需要返回數(shù)據(jù)或信息到界面上。這個時候Web層需要根據(jù)返回的值選擇合適的頁面，然后展示這些數(shù)據(jù)或者信息。

　　從上面可以看出，Web層開發(fā)的主要工作集中在展示上，也就是圖形用戶界面。這一部分是用戶直觀感受應(yīng)用程序的窗口，也是用戶要求最多的地方，其表現(xiàn)形式也是最豐富的。

　　三：Web層開發(fā)的步驟

　　下面再來總結(jié)一下Web層開發(fā)的大致步驟(也就是需要開發(fā)人員做的工作)：

　　注意：這里討論的Web層開發(fā)，是不使用任何開發(fā)框架時候的開發(fā)。

　　1：寫頁面Html，到底有哪些數(shù)據(jù)需要在界面上表現(xiàn)

　　2：每個數(shù)據(jù)的具體表現(xiàn)形式，如：有的需要表現(xiàn)成為下拉列表，有的需要表現(xiàn)成為單選按鈕等。

　　3：界面表現(xiàn)形式的邏輯布局，所謂邏輯布局是指某些數(shù)據(jù)的表現(xiàn)形式應(yīng)該放在前面，某些應(yīng)該放在后面;某些放在上面，某些放在下面。如：某個請假
申請的業(yè)務(wù)，有請假開始時間和結(jié)束時間，很明顯開始時間的表現(xiàn)就應(yīng)該排在結(jié)束時間的前面。而美工是負(fù)責(zé)最后頁面的美觀，一般美工不能動界面的邏輯布局。

　　好了，確定了值的來源，開發(fā)人員就要寫代碼來獲取這些值，然后把這些值賦值到對應(yīng)的表現(xiàn)形式里面。

　　5：還有一些比較特殊，也就是真實操作的是一類值，但是在界面上顯示的是另一類值，比如：數(shù)據(jù)庫中有用戶編號，到了界面上就得顯示用戶姓名，但
是所有的操作都是要操作用戶編號的。我們把這種情況分做：真實值和表現(xiàn)值，他們有一定的內(nèi)在聯(lián)系。這些都是要開發(fā)人員去轉(zhuǎn)化和維護(hù)的。

　　6：接下來就應(yīng)該開發(fā)功能性的事件響應(yīng)了。用戶點擊了某個按鈕或者觸發(fā)了某個事件，首先是客戶端：數(shù)據(jù)檢測、客戶端事件處理;然后提交到服務(wù)端，服務(wù)端要獲取到客戶端提交的數(shù)據(jù)，然后調(diào)用相應(yīng)的邏輯層接口來響應(yīng)。當(dāng)然如何寫邏輯層的實現(xiàn)這里就不去談?wù)摿恕?/p>

　　7：邏輯層執(zhí)行完過后，返回數(shù)據(jù)和信息到Web層，開發(fā)人員還需要寫代碼去處理，選擇哪個頁面來顯示，如何顯示這些數(shù)據(jù)和信息等。

　　8：在整個交互的過程中，還必須考慮到如何控制權(quán)限，如：某些數(shù)據(jù)不能顯示，某些數(shù)據(jù)不能編輯等等;同樣還需要考慮到消息的配置和國際化等等。這些功能起源于邏輯層，但是實際的控制要到Web層，這些都需要開發(fā)人員來控制。

　　9：完成了上面的開發(fā)步驟，頁面基本的功能開發(fā)就告一段落，接下來開發(fā)人員需要考慮頁面美觀的問題了。大家可能會說：“不是有美工嗎，還需要開
發(fā)人員干什么?”。事實上美工多半只能出一個靜態(tài)頁面的美化模版，美工對于一推Java代碼和Html的混雜物，多半是沒有辦法的，更不要說還有一些內(nèi)容
是動態(tài)生成的，美工就更不可能搞定了。還是得開發(fā)人員上陣，按照美工給的模版，開始添加Css：class、id、style……

　　10：完成上面的開發(fā)，基本頁面的開發(fā)工作就完成了，最后的一個步驟就是把各個頁面有機(jī)的組織起來，開發(fā)應(yīng)用程序的整體應(yīng)用導(dǎo)航框架，通常就是菜單，然后把各個功能頁面跟菜單結(jié)合起來，形成一個完整的應(yīng)用。

　　在這里我們省略了開發(fā)期反復(fù)的調(diào)試過程，僅總結(jié)開發(fā)的步驟。

　　四：選擇Web開發(fā)框架的目的

　　了解了如果沒有框架，我們需要做的工作，這對選擇框架有非常大的幫助。

　　框架，直白點說，就是一個半成品，能夠幫我們做一些事情的半成品。

　　框架的選擇，就是看哪個框架最合適，從而減少開發(fā)的工作量，提高開發(fā)的效率和質(zhì)量，并有效減少維護(hù)的工作量，最終達(dá)到節(jié)約綜合開發(fā)成本，獲取更多的收益。

　　五：選擇Web開發(fā)框架的標(biāo)準(zhǔn)

　　聲明：這里所談的選擇Web開發(fā)框架的標(biāo)準(zhǔn)，只是我們的總結(jié)和一家之言，并不是放之四海而皆準(zhǔn)的真理，請根據(jù)您的體會客觀的看待我們的總結(jié)。

　　另外：我們這里更多的討論業(yè)務(wù)功能性應(yīng)用程序的Web開發(fā)框架。

　　1：選擇能夠?qū)ξ覀兊拈_發(fā)過程提供更多、更好幫助的Web開發(fā)框架

　　2：Web開發(fā)框架的學(xué)習(xí)一定要簡單，上手一定要快，沒有什么比使用能得到更深的體會。那些動不動就需要半個月或者一個月學(xué)習(xí)周期的框架，實在是有些恐怖。

　　3：一定要能得到很好的技術(shù)支持，在應(yīng)用的過程中，或多或少都會出現(xiàn)這樣或者那樣的問題，如果不能很快很好的解決，會對整個項目開發(fā)帶來影響。一定要考慮綜合成本，其實這是目前應(yīng)用開源軟件最大的問題，碰到問題除了死肯文檔就是查閱源代碼，或者是網(wǎng)上搜尋解決的辦法，通常一個問題就會導(dǎo)致1-2天的開發(fā)停頓，嚴(yán)重的甚至需要一個星期或者更長，一個項目有上這么幾次，項目整體的開發(fā)成本嗖嗖的就上去了。

　　4：Web開發(fā)框架結(jié)合其他技術(shù)的能力一定要強(qiáng)，比如：在邏輯層要使用Spring或者Ejb3，那么Web開發(fā)框架一定要能很容易，很方便的與它們進(jìn)行結(jié)合。

　　5：Web開發(fā)框架的擴(kuò)展能力一定要強(qiáng)。在好的框架都有力所不及的地方，這就要求能很容易的擴(kuò)展Web開發(fā)框架的功能，以滿足新的業(yè)務(wù)需要。同時要注意擴(kuò)展的簡單性，如果擴(kuò)展框架的功能代價非常大，還不如不用呢。

　　6：Web開發(fā)框架最好能提供可視化的開發(fā)和配置，可視化開發(fā)對開發(fā)效率的提高，已經(jīng)得到業(yè)界公認(rèn)。

　　7：Web開發(fā)框架的設(shè)計結(jié)構(gòu)一定要合理，應(yīng)用程序會基于這個框架，框架設(shè)計的不合理會大大影響到整個應(yīng)用的可擴(kuò)展性。

　　8：Web開發(fā)框架一定要是運(yùn)行穩(wěn)定的，運(yùn)行效率高的。框架的穩(wěn)定性和運(yùn)行效率直接影響到整個系統(tǒng)的穩(wěn)定性和效率。

　　9：Web開發(fā)框架一定要能很好的結(jié)合目前公司的積累。在多年的開發(fā)中已有了很多積累，不能因為使用Web開發(fā)框架就不能再使用了，那未免有些得不償失。

　　10：選擇開發(fā)框架另外要注意的一點就是：任何開發(fā)框架都不可能是十全十美的，也不可能是適應(yīng)所有的應(yīng)用場景的，也就是說任何開發(fā)框架都有它適用的范圍。所以選擇的時候要注意判斷應(yīng)用的場景和開發(fā)框架的適用性。

　　XSS攻擊，跨站腳本攻擊是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計算機(jī)安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。XSS攻擊將對用戶的web安全構(gòu)成巨大的威脅。

　　XSS攻擊：跨站腳本攻擊(Cross Site Scripting)，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆。故將跨站腳本攻擊縮寫為XSS。XSS是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計算機(jī)安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。比如這些代碼包括HTML代碼和客戶端腳本。攻擊者利用XSS漏洞旁路掉訪問控制——例如同源策略(same origin policy)。這種類型的漏洞由于被駭客用來編寫危害性更大的phishing攻擊而變得廣為人知。對于跨站腳本攻擊，黑客界共識是：跨站腳本攻擊是新型的“緩沖區(qū)溢出攻擊“，而JavaScript是新型的“ShellCode”。

　　數(shù)據(jù)來源：2007 OWASP Top 10的MITRE數(shù)據(jù)

　　注：OWASP是世界上最知名的Web安全與數(shù)據(jù)庫安全研究組織

　　從這張圖中我們看到，在2007年OWASP所統(tǒng)計的所有安全威脅中，跨站腳本攻擊占到了22%，高居所有Web威脅之首。

　　XSS攻擊的危害包括

　　1、盜取各類用戶帳號，如機(jī)器登錄帳號、用戶網(wǎng)銀帳號、各類管理員帳號

　　2、控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力

　　3、盜竊企業(yè)重要的具有商業(yè)價值的資料

　　4、非法轉(zhuǎn)賬

　　5、強(qiáng)制發(fā)送電子郵件

　　6、網(wǎng)站掛馬

　　7、控制受害者機(jī)器向其它網(wǎng)站發(fā)起攻擊

　　XSS漏洞的分類

　　XSS漏洞按照攻擊利用手法的不同，有以下三種類型：

　　類型A，本地利用漏洞，這種漏洞存在于頁面中客戶端腳本自身。其攻擊過程如下所示：

　　Alice給Bob發(fā)送一個惡意構(gòu)造了Web的URL。

　　Bob點擊并查看了這個URL。

　　惡意頁面中的JavaScript打開一個具有漏洞的HTML頁面并將其安裝在Bob電腦上。

　　具有漏洞的HTML頁面包含了在Bob電腦本地域執(zhí)行的JavaScript。

　　Alice的惡意腳本可以在Bob的電腦上執(zhí)行Bob所持有的權(quán)限下的命令。

　　類型B，反射式漏洞，這種漏洞和類型A有些類似，不同的是Web客戶端使用Server端腳本生成頁面為用戶提供數(shù)據(jù)時，如果未經(jīng)驗證的用戶數(shù)據(jù)被包含在頁面中而未經(jīng)HTML實體編碼，客戶端代碼便能夠注入到動態(tài)頁面中。其攻擊過程如下：

　　Alice經(jīng)常瀏覽某個網(wǎng)站，此網(wǎng)站為Bob所擁有。Bob的站點運(yùn)行Alice使用用戶名/密碼進(jìn)行登錄，并存儲敏感信息(比如銀行帳戶信息)。

　　Charly發(fā)現(xiàn)Bob的站點包含反射性的XSS漏洞。

　　Charly編寫一個利用漏洞的URL，并將其冒充為來自Bob的郵件發(fā)送給Alice。

　　Alice在登錄到Bob的站點后，瀏覽Charly提供的URL。

　　嵌入到URL中的惡意腳本在Alice的瀏覽器中執(zhí)行，就像它直接來自Bob的服務(wù)器一樣。此腳本盜竊敏感信息(授權(quán)、信用卡、帳號信息等)然后在Alice完全不知情的情況下將這些信息發(fā)送到Charly的Web站點。

　　類型C，存儲式漏洞，該類型是應(yīng)用最為廣泛而且有可能影響到Web服務(wù)器自身安全的漏洞，駭客將攻擊腳本上傳到Web服務(wù)器上，使得所有訪問該頁面的用戶都面臨信息泄漏的可能，其中也包括了Web服務(wù)器的管理員。其攻擊過程如下：

　　Bob擁有一個Web站點，該站點允許用戶發(fā)布信息/瀏覽已發(fā)布的信息。

　　Charly注意到Bob的站點具有類型C的XXS漏洞。

　　Charly發(fā)布一個熱點信息，吸引其它用戶紛紛閱讀。

　　Bob或者是任何的其他人如Alice瀏覽該信息，其會話cookies或者其它信息將被Charly盜走。

　　類型A直接威脅用戶個體，而類型B和類型C所威脅的對象都是企業(yè)級Web應(yīng)用，目前天清入侵防御產(chǎn)品所能防范的XSS攻擊包括類型B和類型C。

　2、XSS攻擊防御

　　基于特征的防御

　　XSS漏洞和著名的SQL注入漏洞一樣，都是利用了Web頁面的編寫不完善，所以每一個漏洞所利用和針對的弱點都不盡相同。這就給XSS漏洞防御帶來了困難：不可能以單一特征來概括所有XSS攻擊。

　　傳統(tǒng)XSS防御多采用特征匹配方式，在所有提交的信息中都進(jìn)行匹配檢查。如， 對于這種類型的XSS攻擊，采用的模式匹配方法一般會需要對“javascript”這個關(guān)鍵字進(jìn)行檢索，一旦發(fā)現(xiàn)提交信息中包含 “javascript”，就認(rèn)定為XSS攻擊。這種檢測方法的缺陷顯而易見：駭客可以通過插入字符或完全編碼的方式躲避檢測：

　　躲避方法1)在javascript中加入多個tab鍵，得到    

　　躲避方法2) 在javascript中加入&#x09編碼字符，得到 

　　躲避方法3) 在javascript中加入字符，得到    

　　躲避方法4)在javascript中的每個字符間加入回車換行符，得到

   躲避方法5)對"javascript:alert('XSS')"采用完全編碼，得到

<IMGSRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

　　上述方法都可以很容易的躲避基于特征的檢測。而除了會有大量的漏報外，基于特征的還存在大量的誤報可能：在上面的例子中，對"http://www.xxx.com/javascript/kkk.asp?id=2345"這樣一個URL，由于包含了關(guān)鍵字“javascript”，也將會觸發(fā)報警。

　　基于代碼修改的防御

　　和SQL注入防御一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應(yīng)用開發(fā)的角度來避免：

　　步驟1、對所有用戶提交內(nèi)容進(jìn)行可靠的輸入驗證，包括對URL、查詢關(guān)鍵字、HTTP頭、POST數(shù)據(jù)等，僅接受指定長度范圍內(nèi)、采用適當(dāng)格式、采用所預(yù)期的字符的內(nèi)容提交，對其他的一律過濾。

　　步驟2、實現(xiàn)Session標(biāo)記(session tokens)、CAPTCHA系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網(wǎng)站所執(zhí)行。

　　步驟3、確認(rèn)接收的的內(nèi)容被妥善的規(guī)范化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠(yuǎn)程內(nèi)容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。

　　當(dāng)然，如上操作將會降低Web業(yè)務(wù)系統(tǒng)的可用性，用戶僅能輸入少量的制定字符，人與系統(tǒng)間的交互被降到極致，僅適用于信息發(fā)布型站點。并且考慮到很少有Web編碼人員受過正規(guī)的安全培訓(xùn)，很難做到完全避免頁面中的XSS漏洞。

　　正是由于傳統(tǒng)檢測方法存在諸多缺陷，國內(nèi)廠商(如啟明星辰天清入侵防御系統(tǒng))并未采用這一方法，而是采用了基于攻擊手法的行為檢測方法。　　

　　首先對各種場景下的XSS攻擊樣本庫進(jìn)行整理和分類，并建立起XSS攻擊行為特征庫，在實時攻擊檢測階段，對所有可能實現(xiàn)XSS攻擊的數(shù)據(jù)來 源，如HTTP-Refere、URL、COOKIE、表單數(shù)據(jù)等，進(jìn)行數(shù)據(jù)收集和初步分析，存在注入腳本的用戶提交信息才進(jìn)入下一步的XSS攻擊判斷。

　　這種分析方法有以下幾點優(yōu)勢：

　　A：采用行為特征庫而非數(shù)據(jù)特征庫方式，可以避免由于檢測固定特征導(dǎo)致的誤報可能。

　　B：內(nèi)置數(shù)據(jù)預(yù)處理過程，可以對所有可能包含XSS攻擊的數(shù)據(jù)進(jìn)行預(yù)處理，放行大部分正常HTTP請求，僅對少量疑似事件進(jìn)行深入分析，提升分析速度，降低資源開銷。

　　C：XSS攻擊行為特征庫維護(hù)由啟明星辰公司AD-LAB(積極防御實驗室)和博士后工作站負(fù)責(zé)，AD-LAB擁有大批漏洞發(fā)掘和分析人 員，2007年發(fā)現(xiàn)并獲得CVE編號的漏洞數(shù)量多達(dá)26個，是國內(nèi)獨立發(fā)掘CVE漏洞數(shù)量最多的團(tuán)隊。啟明星辰博士后工作站是業(yè)內(nèi)第一家駐企業(yè)的信息安全 博士后工作站，為產(chǎn)品算法實現(xiàn)、研究技術(shù)轉(zhuǎn)化提供有力保障。

　　3、綜論

　　XSS攻擊作為Web業(yè)務(wù)的最大威脅之一，不僅危害Web業(yè)務(wù)本身，對訪問Web業(yè)務(wù)的用戶也會帶來直接的影響，如何防范和阻止XSS攻擊，保障Web站點的業(yè)務(wù)安全，是定位于業(yè)務(wù)威脅防御的入侵防御產(chǎn)品的本職工作。只有結(jié)合對XSS攻擊的分析，才能能準(zhǔn)確的發(fā)現(xiàn)和防御各類XSS攻擊行為，保障Web業(yè)務(wù)的正常運(yùn)營。

Tags: XSS, Web, Web安全, 攻擊, 網(wǎng)頁掛馬, 防御

Tags: 產(chǎn)品經(jīng)理, 項目經(jīng)理, BUG, 需求

　　ERP實施顧問在推進(jìn)項目的過程中，應(yīng)該注意項目團(tuán)隊中各成員之間的相互激勵。如果激勵制度設(shè)置的不當(dāng)，可能項目小組成員不僅不會創(chuàng)造貢獻(xiàn)，還很有可能發(fā)生內(nèi)部戰(zhàn)爭，產(chǎn)生一些比必要的內(nèi)耗。

　　ERP實施顧問在推進(jìn)項目的過程中，應(yīng)該注意項目團(tuán)隊中各成員之間的相互激勵。如果激勵制度設(shè)置的不當(dāng)，可能項目小組成員不僅不會創(chuàng)造貢獻(xiàn)，還很有可能發(fā)生內(nèi)部戰(zhàn)爭，產(chǎn)生一些比必要的內(nèi)耗。為此，實施顧問必須建立有效的只針對個人而不是成員之間的激勵制度。換句話說，即將現(xiàn)有的個體之間的競爭，人與人之間的比較，轉(zhuǎn)化為自己和自己的競爭。如果錯誤的將所有的項目小組成員都趕到一條獨木橋上，讓他們?nèi)Z取隔岸的那一顆唯一的勝利果實，那么合作將不可能形成，相互激烈就會被相互泄氣所代替。

　　原則一：不要在團(tuán)隊內(nèi)部締造英雄。

　　在國際上，有一個著名的足球教練，他說過一句非常有哲理的話，我是記憶猶深。他說，我們足球隊沒有英雄，個個都是英雄。確實，在足球場上贏得勝利，不是前鋒一個人的功勞，而是后衛(wèi)、中鋒、門衛(wèi)一起的功勞。若在足球場上過度的強(qiáng)調(diào)進(jìn)球人的貢獻(xiàn)的話，則難免會在團(tuán)隊中形成隔閡。所有的光環(huán)都在射球人身上的話，那誰以后還去當(dāng)這幕后的英雄呢?

　　所以，筆者認(rèn)為，在ERP項目的團(tuán)隊中，不要塑造個人英雄。ERP項目實施小組中，沒有英雄。只要項目取得成功，那么個個都是英雄，每個人都應(yīng)該得到嘉獎。

　　若我們在激勵員工的時候，以個人為單位進(jìn)行嘉獎，會產(chǎn)生什么情況呢?則難免就會形成員工個人與個人之間的競爭。俗話說，人比人，氣死人。這真是團(tuán)隊管理的禁忌。筆者認(rèn)為，ERP項目要取得成功，不是靠個人之力，而是團(tuán)隊相互協(xié)作的結(jié)果。所以，不要在團(tuán)隊內(nèi)部之間形成相互賽跑的局面，而應(yīng)該努力培養(yǎng)一個自我提升的氛圍。

　　2、要設(shè)置盡量多的勝利帽子，而不要造成眾人搶過獨木橋的現(xiàn)象。在足球賽場上，會按不同的位置設(shè)置不同的獎項。如最佳守門員、最佳前鋒、最佳后衛(wèi)等等。如此的話，每個位置的人就會堅守自己的崗位，努力做的更好。他們就不會三心二意，覺得自己所負(fù)責(zé)的位置沒有出風(fēng)頭的機(jī)會，一心就想著去射門、去做前鋒等等。如此的團(tuán)隊，其協(xié)作型又怎么會好呢?其實，在ERP項目中也有類似的問題。若我們在設(shè)置項目激勵制度的時候，只設(shè)置了一個獎項，如把項目獎金的80%獎勵給項目實施過程中有杰出貢獻(xiàn)之人，而這人也就只有一個。那會產(chǎn)生什么樣的情況呢?項目小組成員個個都是企業(yè)的皇子，他們就會為了爭奪這個太子的位置，相互扯后腿，相互攻擊。企業(yè)這是人為的造了一條獨木橋。如此的話，ERP項目小組的各個成員之間，就會拉小幫派，就不會有勁往一處使了。筆者是非常反對這種做法的。筆者現(xiàn)在的處理方式是，以部門為單位，進(jìn)行選拔。也就是說，我們ERP項目有五個部門參與的話，則把80%的獎金分為5份，每個部門一份。讓每個部門自己選擇一個杰出貢獻(xiàn)人員。如此的話，就可以有效的避免部門之間的競爭，同時，又能夠起到激勵的作用。

Tags: 項目管理, ERP, 軟件工程

　　Sun的官員日前表示MySQL 5.1開源數(shù)據(jù)庫的正式版將在未來的幾周內(nèi)公開發(fā)布（generally available）。Sun原定于2008年更早的時候公開發(fā)布該版數(shù)據(jù)庫，但為了讓開發(fā)人員修復(fù)軟件漏洞而不得不推遲發(fā)布時間。

　　Sun日前已經(jīng)確認(rèn)最新版的MySQL 5.1的所有重大漏洞已經(jīng)被修復(fù)，一切都準(zhǔn)備就緒，翹首以盼的開源用戶可以期待它能夠在未來的幾周之內(nèi)公開發(fā)布。Sun公司的數(shù)據(jù)庫產(chǎn)品部門副主席Zack Urlocker表示，Sun的開發(fā)人員已經(jīng)在很多方面對MySQL 5.1進(jìn)行了反復(fù)檢查和測試，確保公開發(fā)行的正式版毫無問題。

　　Sun的官員早在四月份的MySQL大會上就曾經(jīng)放出消息說，這個新版的MySQL數(shù)據(jù)庫會在會議結(jié)束的幾周之內(nèi)與大家見面。不過，為了找出 MySQL 5.1的重大漏洞并將其修復(fù)所花費(fèi)的時間遠(yuǎn)遠(yuǎn)超出了Sun的預(yù)算，所以MySQL 5.1正式版的公開發(fā)布時間不得不一拖再拖。

　　市場調(diào)查機(jī)構(gòu)451集團(tuán)的分析師Matt Aslett表示，數(shù)周前MySQL的創(chuàng)始人Monty Widenius邀請MySQL的開發(fā)人員幫助公司決定是否該公開發(fā)布MySQL 5.1。很顯然，該公司對之前5.0的公開發(fā)布以及5.1候選版發(fā)布時因為不夠?qū)徤魉赶碌腻e誤仍然心有余悸，以至于現(xiàn)在很擔(dān)心會不會第三次犯錯。 MySQL認(rèn)為有必要公開咨詢發(fā)布事宜的事實表明，公司對于漏洞報告過程信心不足，不然就是過于謹(jǐn)慎了。

　　Urlocker稱，Sun承諾，在給該產(chǎn)品貼上公開發(fā)行的標(biāo)簽并正式推薦客戶將其用在生產(chǎn)環(huán)境前，必須確保產(chǎn)品是真的沒有問題可以投放市場才 行。這也是Sun為什么在產(chǎn)品發(fā)布候選版(RC)階段找人來幫忙的原因。同時，Urlocker也表示，在開發(fā)人員的努力下，目前已經(jīng)把客戶曾經(jīng)上報沒有 修復(fù)的優(yōu)先級為一和二的已知漏洞都修復(fù)了。

　　Forrester市場調(diào)查機(jī)構(gòu)的分析師Noel Yuhanna則認(rèn)為，如果MySQL要擴(kuò)展其現(xiàn)有功能，以便為高性能的企業(yè)級環(huán)境提供支持，那么在這條提升的道路上必定會遇到困難，而Sun的延遲發(fā)布 就是最有力的證明。MySQL 5.1的研發(fā)大概耗時了三年時間，Sun對MySQL的項目一直都雄心勃勃，為此增加了大量企業(yè)級功能，以改善性能，例如基于行的復(fù)制等特性。這個功能可 以在主服務(wù)器和從服務(wù)器之間復(fù)制數(shù)據(jù)的變化，而不是實際的SQL語句。為了提高靈活性，MySQL團(tuán)隊還添加了混合復(fù)制功能，可以根據(jù)單個的SQL操作來 選擇使用語句復(fù)制或行復(fù)制。其他的增強(qiáng)功能還包括支持五種不同的數(shù)據(jù)分區(qū)形式——hash分區(qū)、list分區(qū)、key分區(qū)、range分區(qū)和sub-partitioning分區(qū)，據(jù)稱這項功能可以幫助客戶處理超大型的數(shù)據(jù)集。考慮到這些功能都非常復(fù)雜，確實需要在研發(fā)和測試過程中投入相當(dāng)大的力度，特別是如果想讓這款軟件能夠支持大型復(fù)雜的生產(chǎn)環(huán)境的話。

Tags: Mysql, 產(chǎn)品發(fā)布, Sun

在電子信息時代，是否充分利用電子商務(wù)成為中小企業(yè)成敗的關(guān)鍵。但在中小企業(yè)運(yùn)用電子商務(wù)的過程中，會遇到一些問題，影響到中小企業(yè)的電子商務(wù)的實施。

在電子信息時代，是否充分利用電子商務(wù)成為中小企業(yè)成敗的關(guān)鍵。“沒有電子商務(wù)，企業(yè)就只能等待死亡!”或許有些偏激，但確實是企業(yè)發(fā)展壯大的基本。但在中小企業(yè)運(yùn)用電子商務(wù)的過程中，會遇到一些問題，影響到中小企業(yè)的電子商務(wù)的實施。

首先，對電子商務(wù)認(rèn)識不足的問題

許多中小企業(yè)管理基礎(chǔ)落后，領(lǐng)導(dǎo)信息化意識不強(qiáng)，也沒有充分認(rèn)識到知識經(jīng)濟(jì)時代搶占信息市場的重要性。或者對如何開展電子商務(wù)理解比較片面，如 認(rèn)為電子商務(wù)就是上網(wǎng)，或簡單地建一個網(wǎng)站，而相關(guān)的管理基礎(chǔ)卻沒有跟上，企業(yè)的電子商務(wù)僅停留在表面的網(wǎng)站建設(shè)上。因此中小企業(yè)不但在觀念上要重視電子 商務(wù)，而且要了解電子商務(wù)的實質(zhì)，不宜盲目跟風(fēng)。

此外，電子商務(wù)不單是一個企業(yè)的事情。中小企業(yè)供應(yīng)鏈的管理能力欠缺，如何和供應(yīng)鏈的核心企業(yè)合作，借助其平臺或第三方共享交易平臺開展業(yè)務(wù)也是中小企業(yè)開展電子商務(wù)的重要話題。

其次，設(shè)施落后的問題

中小企業(yè)使用互聯(lián)網(wǎng)和參與電子商務(wù)的程度參差不齊。據(jù)統(tǒng)計，目前參與電子商務(wù)的企業(yè)僅為22.3%，在眾多的行業(yè)用戶中，汽車行業(yè)、電子行業(yè)和 貿(mào)易行業(yè)等信息化建設(shè)水平較高。但在這些領(lǐng)先的行業(yè)，電子商務(wù)的應(yīng)用也極不平衡，很多網(wǎng)站都不成熟，如網(wǎng)站建設(shè)目的不明確，不知道目標(biāo)用戶是誰，不能反映 出企業(yè)的形象，網(wǎng)站功能簡陋，用戶找不到自己需要的信息，用戶的咨詢也常常得不到回復(fù)等。有些企業(yè)雖然建立了網(wǎng)站，但過于關(guān)注于傳統(tǒng)業(yè)務(wù)，網(wǎng)站利用率極 低，甚至成為一個空殼。

由于資源有限，許多中小企業(yè)需要把主要精力集中放在業(yè)務(wù)上，難以投入足夠的資源進(jìn)行信息化建設(shè)。但中小企業(yè)普遍對采購、生產(chǎn)、庫存、銷售、財務(wù) 和人事等方面的應(yīng)用有一定需求，應(yīng)用服務(wù)提供商模式ASP就成為中小型企業(yè)開展電子商務(wù)的選擇。就目前ASP的發(fā)展情況而言，由于觀念、安全等方面的因素 影響，ASP在國內(nèi)的發(fā)展并不讓人滿意。

再次，執(zhí)行不力的問題

由于中小型企業(yè)管理者還未充分認(rèn)識到電子商務(wù)給企業(yè)發(fā)展，營銷手段帶來的革命性變化，因此對人才的培養(yǎng)沒有足夠的重視，導(dǎo)致電子商務(wù)人才的匱 乏。中小型企業(yè)開展電子商務(wù)既要技術(shù)又要人才，但這方面的人才在大企業(yè)也不是很充裕。專業(yè)人員的不足，電子商務(wù)模式缺乏創(chuàng)新，導(dǎo)致中小型企業(yè)缺乏網(wǎng)絡(luò)經(jīng)營 的經(jīng)驗，電子商務(wù)的優(yōu)越性表現(xiàn)不出來，許多中小型企業(yè)涉足電子商務(wù)心有余力不足。

資金短缺是中小企業(yè)的普遍困難。在有限資金的合理使用方面，許多中小企業(yè)尚處于摸索階段。很多中小企業(yè)對硬件的投資占到整個信息化投資80%以上，而配套軟件和IT服務(wù)等方面投入相對滯后，對軟件的選型不恰當(dāng)，咨詢合作伙伴協(xié)調(diào)不力，最終會使企業(yè)的投資回報率低，難以獲得持久的發(fā)展動力。

第四、缺乏規(guī)劃的問題

中小型企業(yè)開展電子商務(wù)往往缺乏長遠(yuǎn)規(guī)劃，比較注意短期效益。電子商務(wù)涉及業(yè)務(wù)轉(zhuǎn)型，不同企業(yè)發(fā)展電子商務(wù)的方式也是不同的。從利用互聯(lián)網(wǎng)瀏 覽、收集、發(fā)布信息，到建立企業(yè)網(wǎng)站，建立信息平臺，實施網(wǎng)上采購，再到建立行業(yè)聯(lián)合采購平臺，完善自己的供應(yīng)鏈管理系統(tǒng)等，中小型企業(yè)電子商務(wù)的實施要 逐步到位，長遠(yuǎn)規(guī)劃，分步實施。

電子商務(wù)在我國的發(fā)展時間不長短，中小企業(yè)對實施電子商務(wù)發(fā)展戰(zhàn)略方面還缺乏深刻的認(rèn)識，但是，“機(jī)不可失，時不我待”，在不以我們的意志為轉(zhuǎn)移的、勢不可擋的電子商務(wù)發(fā)展大潮面前，中小企業(yè)除了盡早實施電子商務(wù)以外，別無選擇。否則，遲早要被電子商務(wù)潮流所淘汰。

最后，全球化不足的問題

當(dāng)今，全球電子商務(wù)的發(fā)展是不可逆轉(zhuǎn)的態(tài)勢。電子商務(wù)是世界經(jīng)濟(jì)全球化和科技發(fā)展的必然產(chǎn)物，其發(fā)展勢頭不可阻擋，目前電子商務(wù)在技術(shù)上已初步 具備實施條件，在美國的推動下，國際組織和發(fā)達(dá)國家政府相繼發(fā)表電子商務(wù)文件，而且從多邊貿(mào)易自由化發(fā)展的趨勢來看，不久將會有這方面的國際協(xié)議和規(guī)則出 臺。而目前的電子商務(wù)國際談判主要集中在少數(shù)發(fā)達(dá)國家之間，發(fā)展中國家若不及時參與到對話中來，不利于形成電子商務(wù)的國際框架。

對于中小企業(yè)來說，要致力于產(chǎn)品技術(shù)含量的提高、附加值的增加，最重要的是要增強(qiáng)企業(yè)的全球意識。全球電子商務(wù)專家中國諾網(wǎng)認(rèn)為，企業(yè)要真正地 實施全球化戰(zhàn)略，最緊迫的是提高企業(yè)的信息化程度。在融入國際市場后，已經(jīng)有相當(dāng)多的中小企業(yè)認(rèn)識到，網(wǎng)站的建設(shè)尤其是直接針對客戶的英文網(wǎng)站的建設(shè)，將 成為企業(yè)業(yè)務(wù)增長的一個關(guān)鍵因素;同時也是企業(yè)區(qū)別于其他同行，建立自身品牌的重要平臺。而中小企業(yè)從網(wǎng)站的建立到托管再到維護(hù)這之間花費(fèi)的金錢，與在信息化程度提高、客戶來源更廣、品牌價值提升后獲得的利潤相比，根本不值一提。正是意識到了網(wǎng)絡(luò)的重要性，中小企業(yè)的英文網(wǎng)站紛紛地建了起來。

品牌化、信息化、全球化，中小為外貿(mào)企業(yè)重新迎接更大商機(jī)的必經(jīng)之路。全球電子商務(wù)專家中國諾網(wǎng)作為國內(nèi)首家成熟的全球電子商務(wù)平臺，為國內(nèi)中 小企業(yè)精心準(zhǔn)備了高質(zhì)量的海外空間，讓國內(nèi)外貿(mào)企業(yè)的網(wǎng)站在海外高速、穩(wěn)定的運(yùn)行。讓全世界都能快速訪問你的網(wǎng)站，讓你的網(wǎng)站為你帶來更多的定單!使中國 企業(yè)的全球互聯(lián)夢想不再遙遠(yuǎn)。

Tags: 中小企業(yè), SMB, 電子商務(wù)

　　從根本上說，這一現(xiàn)象的真正原因是出自組織體系。如果公司具備一套明確的體系，并得到管理高層的高度支持，那就可以借助相應(yīng)的軟件來順利展開工作。如果本末倒置，舍體系而求軟件，那恐怕世上任何一款軟件都難以從本質(zhì)上解決問題。

　　從管理角度來看，人們通常將問題劃分為三大類：即技術(shù)與技能、價值與行為，還有組織體系。

　　一套成熟的體系并不一定要基于軟件(盡管軟件能起到很大的作用)。它如同一本員工手冊，明確指導(dǎo)每位員工該做什么，何時做，以及如何去做，同時提供績效測量和責(zé)任分配的方式。

　　體系是公司的縮影

　　從本質(zhì)上說，公司就是一種體系。不同的體系造就了不同的公司特色。一套精良的體系是往往都會受到公司管理層的大力支持。公司中每個人都應(yīng)參與、了解，并從中得到幫助。體系是一種收集智能、獲取反饋的形式。

　　比如在CRM方面，我們就曾發(fā)現(xiàn)許多軟件實施其實都踏入了誤區(qū)。主要表現(xiàn)為：首先，幾乎沒有人去真正使用這一系統(tǒng)；其次，公司管理人員也忽略了這一現(xiàn)象。

　　從根本上說，這一現(xiàn)象的真正原因是出自組織體系。如果公司具備一套明確的體系，并得到管理高層的高度支持，那就可以借助相應(yīng)的軟件來順利展開工 作。如果本末倒置，舍體系而求軟件，那恐怕世上任何一款軟件都難以從本質(zhì)上解決問題。有不少公司一套接一套地實施各種軟件，斥資數(shù)百萬，但卻忽略了體系的 重要意義。

　　大道至簡

　　每一家成功的企業(yè)都有成熟完善的員工手冊。這種手冊是一種活文件，它會定期更新，并用來培訓(xùn)指導(dǎo)新晉員工。

　　制定公司體系不是研究航天科學(xué)，所以越簡單越好。然而，有不少企業(yè)往往匱乏這一體系來與員工進(jìn)行雙向溝通，并測量他們的績效。我們認(rèn)為，體系是提高效率最簡單的方式。

　　比如有一家專業(yè)服務(wù)公司就部署了CRM軟件，并將它集成到銷售與市場體系中，從而為該公司帶來了顯著的投資回報。這家公司所謂的“秘訣”就是設(shè) 計一套體系來達(dá)成既定目標(biāo)，明確與每個責(zé)任人溝通，然后測量工作績效。CRM軟件中所獲取的數(shù)據(jù)會在董事會中進(jìn)行回顧檢驗，從中查看該公司創(chuàng)建了多少潛在 客戶，制定了哪些流程。在這家公司中，從來沒有人討論“我們該如何讓員工使用CRM”之類的問題，因為使用CRM早已被定義成工作的一部分。

　　善于借鑒

　　借鑒優(yōu)秀公司在這方面的經(jīng)驗?zāi)軒椭行∑髽I(yè)做的更好。很多公司都十分勤快地向CRM中錄入各種聯(lián)系人資料，但CRM卻沒有帶給他們什么成長。而 一旦你制定了一套明確的體系，你的員工就知道何時該跟進(jìn)案例，如何根據(jù)服務(wù)等級協(xié)議(SLA)測量績效。CRM還是原來的CRM，但員工卻有了更為明確的 工作目標(biāo)與方向。

　　有些公司或許喜歡聘請外部顧問來分析自己的商業(yè)流程，但歸根到底，只有你自己才最了解你的企業(yè)，也只有你自己才能量體而裁，設(shè)計出合適的體系。

　　在一個體系里，軟件只是一種頗具價值的催化劑，而不是替代品。

Tags: SMB, 中小企業(yè)信息化, SaaS

　　廠商們或許總是在考慮用戶需要什么產(chǎn)品功能或什么解決方案，那么，現(xiàn)在，是否可以換個角度想一下用戶不需要哪些產(chǎn)品功能或者哪些解決方案?

　　“相比我們總在關(guān)心用戶需要什么而言，或許我們很少去關(guān)注用戶不需要什么，而這一點卻同樣值得我們?nèi)リP(guān)注與重視。”酷愛繪畫藝術(shù)的Trend Micro(趨勢科技)全球CEO近日指出。

　　的確，對于熟悉了企業(yè)商業(yè)運(yùn)作流程的IT供貨商來說，滿足用戶需求一直被解讀為對用戶需要什么的回答，然而從數(shù)學(xué)的角度看，這顯然不是一個充分 且必要的等式。相應(yīng)地，需要在回答用戶需要什么的基礎(chǔ)上追加用戶不需要什么。當(dāng)然，這樣的追加并非只適用于Trend Micro這一家或者這一類安全類的供應(yīng)商，諸如軟件及其升級功能、硬件設(shè)備、系統(tǒng)解決方案中各子模塊功能等統(tǒng)統(tǒng)都應(yīng)在追加之列。

　　隨便環(huán)顧一下我們身處的網(wǎng)絡(luò)環(huán)境，或者再稍試遙想一下網(wǎng)絡(luò)建設(shè)之初的當(dāng)年，不算完善的網(wǎng)絡(luò)環(huán)境發(fā)展至今雖然明顯有七拼八湊的嫌疑，但至少在上線 的當(dāng)時，各個零散的軟件或者硬件都的的確確曾經(jīng)發(fā)揮過各自獨有的功效。大概分析一下也不難理解，網(wǎng)絡(luò)環(huán)境從不成形到成熟顯然會經(jīng)歷需求在前、供應(yīng)在后的階 段，相應(yīng)的產(chǎn)品也自然都是跟著需求一步一步建設(shè)起來的。但是到今天，相信70%以上的企業(yè)用戶都深切感受到網(wǎng)絡(luò)環(huán)境錯綜復(fù)雜的痛楚。這就說明人們不再一味 地需要“疊加式”的供應(yīng)模式了，用戶需求也已經(jīng)進(jìn)入需求與供應(yīng)的磨合期。

　　對此，或許廠商們依然會辯駁“我們一直在挖掘和滿足用戶的需求，用戶希望磨合的話那就磨合好了”，或者對于一些大型供應(yīng)商還會拿出很多整合型的 系統(tǒng)解決方案……凡此種種，其實我們不難發(fā)現(xiàn)很多時候或很多情況下，用戶的聲音都被淹沒了，供應(yīng)商總會用方案或者產(chǎn)品引導(dǎo)用戶，使得原本用戶比較清晰的需 求意向演變?yōu)樽罱K上線后的落差，久而久之，錯綜復(fù)雜的痛楚也將繼續(xù)上演……

　　面對相似功能的產(chǎn)品如何選擇，甚至面對不同叫法卻相似功能的產(chǎn)品又該如何選擇，對于既要滿足當(dāng)前網(wǎng)絡(luò)承載的需求又須考慮未來可擴(kuò)展的用戶們，這些都正在成為他們所頭疼的問題。

　　那么，用戶到底希望怎么做呢?

　　從需求來看的話很簡單，無非是“做減法”——簡捷而奏效，在現(xiàn)有的IT資源上用最有性價比的投入同時獲得原有資產(chǎn)的充分利用和IT設(shè)施的可持續(xù) 發(fā)展。或許從實現(xiàn)的角度，供應(yīng)商甚至?xí)謶诌@樣的需求，但無論如何，現(xiàn)在用戶市場出現(xiàn)的產(chǎn)品功能重疊、難以協(xié)同、采購量與功效比嚴(yán)重脫節(jié)等現(xiàn)象實在不容忽 視。

Tags: 企業(yè)信息化, 需求,

　　在未來的三至五年里，隨著五個主要的消費(fèi)者和商業(yè)趨勢的加速發(fā)展，云計算將不斷發(fā)展并且獲得更廣泛的應(yīng)用。

　　云計算基本上是用于一個由大量的連接在一起的計算機(jī)系統(tǒng)組成的共享的IT基礎(chǔ)設(shè)施的一種方法。由于它訪問“虛擬”資源，云計算不受本地和遠(yuǎn)程計 算機(jī)的功率和能力的限制。云計算是下一代企業(yè)數(shù)據(jù)中心，能夠像互聯(lián)網(wǎng)一樣操作，向連接到網(wǎng)絡(luò)的用戶提供極大的規(guī)模和快速的訪問能力。

　　云計算為需要時的使用、降低成本和能源的使用提供一種簡化的、集中的平臺。與網(wǎng)格計算不同，網(wǎng)格計算是為一項具體的任務(wù)分布IT資源，云計算是在整個活動范圍內(nèi)使用的。受到媒體最多關(guān)注的這種平臺是外部托管的服務(wù)，但是，有些是在企業(yè)內(nèi)部使用的，特別是在全球運(yùn)營的企業(yè)中使用。

　　在未來的三至五年里，隨著五個主要的消費(fèi)者和商業(yè)趨勢的加速發(fā)展，云計算將不斷發(fā)展并且獲得更廣泛的應(yīng)用。

　　1.網(wǎng)絡(luò)成為一種全球共享的通信媒介

　　目前，網(wǎng)絡(luò)用于交換、發(fā)布和操作信息。網(wǎng)絡(luò)內(nèi)容不再像早些年那樣是靜態(tài)的，全球用戶每一天都在改變網(wǎng)絡(luò)內(nèi)容。維基百科、Facebook和 YouTube等網(wǎng)站就是突出的例子。不過，這些網(wǎng)站只是冰山的一角。社交網(wǎng)絡(luò)、流音頻和視頻和其它協(xié)作工具正在企業(yè)內(nèi)部網(wǎng)的防火墻后面快速發(fā)展。知識工 人，特別是那些搞研發(fā)的知識工人，使用網(wǎng)絡(luò)應(yīng)用程序在全球范圍內(nèi)協(xié)作研究項目。

　　中國電信和歐洲專業(yè)服務(wù)公司Sogeti使用內(nèi)部云計算平臺在員工之間進(jìn)行在線的、實時的集思廣益的討論。這個高性能的平臺能夠搜集Sogeti公司1.8萬員工的意見并且對這些意見進(jìn)行分類和分析以便應(yīng)用到業(yè)務(wù)中。

　　互動、實時的通訊也稱作Web 2.0，是云計算的主要推動因素。云計算能夠使用現(xiàn)有的基礎(chǔ)設(shè)施在極短的時間內(nèi)處理大量的信息以滿足動態(tài)網(wǎng)絡(luò)的高性能的需求。

　　2.使用較少的能源的需求

　　由于擔(dān)心成本問題和增加碳排放量，減少IT部門使用能源的目標(biāo)正在日益受到關(guān)注。云計算更有效地使用能源，減少了運(yùn)行數(shù)據(jù)中心所需要的耗電量。 過剩的計算能力會得到利用，不是打開電源，使用能源，而是保持待機(jī)狀態(tài)。據(jù)研究機(jī)構(gòu)Info-Tech Research Group稱，大多數(shù)計算機(jī)服務(wù)器都是一直在運(yùn)行的，但是，僅有10%至20%的工作負(fù)荷得到了利用。通過整合資源，云計算平臺能夠升級或者降級，節(jié)省能 源和運(yùn)行成本。

　　3.急切需要的技術(shù)創(chuàng)新

　　在全球經(jīng)濟(jì)中，尋求更多的技術(shù)創(chuàng)新、把新思想更快地應(yīng)用到市場和實用技術(shù)加快實現(xiàn)結(jié)果是推動云計算的主要動力。云計算能夠隨時隨地在需要時以較低的成本提供強(qiáng)大的計算能力。

　　在中國無錫的一個工業(yè)園區(qū)，大多數(shù)新興的軟件企業(yè)都能夠讓員工把計算機(jī)插入網(wǎng)絡(luò)接口訪問整個公司的IT基礎(chǔ)設(shè)施。這個工業(yè)園區(qū)與IBM合 作創(chuàng)建了一個云計算中心為園區(qū)內(nèi)的租戶提供托管的服務(wù)。IT是這個工業(yè)園區(qū)的基礎(chǔ)設(shè)施的一部分，同取暖、照明和水一樣。對于軟件新型企業(yè)來說，這就意味著 降低了開發(fā)產(chǎn)品的成本。他們不用購買和操作自己的服務(wù)器、應(yīng)用程序和工具，只需要為自己實際使用的IT服務(wù)付費(fèi)。越南國家大學(xué)最新建立了一個云計算平臺以 便更快地培養(yǎng)員工隊伍的IT技能。

　4.尋求簡單化

　　雖然技術(shù)的發(fā)展越來越高級，但是，用戶希望技術(shù)仍然像以前一樣容易使用。以服務(wù)的方式在互聯(lián)網(wǎng)上提供軟件取得的市場成功就是向簡單化發(fā)展的一個 例子。軟件服務(wù)也是云計算的一個先驅(qū)。通過購買一項服務(wù)，而不是直接購買軟件產(chǎn)品，企業(yè)能夠直接使用最新的軟件，沒有復(fù)雜性和管理成本，也不需要進(jìn)行升 級。

　　云計算能夠給整個IT范圍帶來同樣的簡單性。有些云計算平臺是由外部托管的并且是作為一項服務(wù)購買的。這對于那些缺乏技術(shù)人員的小企業(yè)是有吸引力的。然而，許多企業(yè)，特別是大企業(yè)，可能會選擇內(nèi)部的平臺，特別是在存在安全和隱私問題的金融等行業(yè)。

　　5.消除混亂建立結(jié)構(gòu)

　　網(wǎng)絡(luò)實現(xiàn)了快速訪問大量的信息。但是，分類這些信息是一個挑戰(zhàn)。谷歌等搜索技術(shù)的成功就在于滿足了次序和分類的需求，因為信息的快速擴(kuò)張超出了人類大腦能夠處理的速度。谷歌在美國的搜索網(wǎng)站每個月的訪問人次達(dá)到1.41億。

　　每一天大量的互聯(lián)網(wǎng)用戶都要向全球的網(wǎng)站貢獻(xiàn)數(shù)據(jù)、照片、音頻和博客。沒有快速和準(zhǔn)確地找到用戶需要的信息的能力，網(wǎng)絡(luò)作為一種生產(chǎn)率工具的價值就會開始消失。

　　云計算是專門為消除混亂建立次序量身定做的技術(shù)。云計算提供了把各種不同種類的信息集成在一起的能力。為處理大量的數(shù)據(jù)提供了更多的計算能力，提供更簡單的基礎(chǔ)設(shè)施管理復(fù)雜性。

　　作為一種新興的技術(shù)，云計算將隨著時間的發(fā)展而變化。云計算的真正價值是能夠?qū)χ饕纳虡I(yè)和市場趨勢做出反應(yīng)。這些趨勢未來幾年將仍然存在于我們的技術(shù)環(huán)境中。

Tags: 云計算, 技術(shù)趨勢, web2.0

　　此外，方便地設(shè)置和配置的虛擬機(jī)能夠讓數(shù)據(jù)中心更靈活和更動態(tài)化，對變化的應(yīng)用程序工作量迅速做出反應(yīng)。一個增加的優(yōu)勢是虛擬機(jī)管理程序提供的操作系統(tǒng)分區(qū)非常適合當(dāng)前的N層的、以Web為中心的應(yīng)用程序架構(gòu)。

　　盡管有這些大量的好處，虛擬化對于數(shù)據(jù)中心管理員并不是一個真正的祝福。虛擬化的薄弱方面(也稱作虛擬蔓延)能夠很快侵蝕掉從物理向虛擬化過渡 節(jié)省的硬件和人員開支。蔓延還是一個粘糊糊的詞匯。一個人的蔓延也許是另一個的適應(yīng)性。但是，Embotics公司產(chǎn)品營銷經(jīng)理Anthony Mar對于這個詞匯提出了這樣的定義：虛擬蔓延可以定義為虛擬機(jī)沒有適當(dāng)?shù)腎T控制的擴(kuò)散。他補(bǔ)充說，這不是關(guān)于虛擬機(jī)的實際數(shù)量的問題。這主要是關(guān)于虛 擬環(huán)境如何構(gòu)造和控制的問題。

　　FastScale公司負(fù)責(zé)工程的副總裁Richard Offer說，鼓勵這種行為被認(rèn)為是零成本創(chuàng)建虛擬機(jī)。他指出，虛擬機(jī)是很容易創(chuàng)建和存儲的，特別是與物理服務(wù)器相比更是如此。用戶沒有認(rèn)識到存在著極度浪費(fèi)的累積成本。

　　創(chuàng)建虛擬機(jī)的容易和方便性是造成蔓延的主要因素。但是，根本的原因是圍繞虛擬機(jī)管理缺少管理控制和流程。Info-Tech分析師John Sloan指出，即使一家公司擁有一個除非例外全部采用虛擬化的政策，這家公司仍然需要正式的部署流程，甚至要像對待物理服務(wù)器那樣對待虛擬服務(wù)器。

　　獨立質(zhì)詢顧問Anil Desai在Embotics公司贊助的白皮書中稱，虛擬機(jī)蔓延最常見的根源是沒有計劃和沒有協(xié)調(diào)的部署、非生產(chǎn)的虛擬機(jī)和虛擬設(shè)備。

　　虛擬機(jī)蔓延成本增加

　　虛擬蔓延不僅是管理方面令人討厭的問題，它還是有昂貴代價的。Mar指出，虛擬機(jī)的四類成本包括基礎(chǔ)設(shè)施、管理系統(tǒng)、服務(wù)器軟件和管理。在虛擬機(jī)基礎(chǔ)設(shè)施中，雖然機(jī)器也許是虛擬的，但是，它們消費(fèi)的資源是真實的。

　　Mar指出，應(yīng)用程序需要處理、內(nèi)存、存儲和網(wǎng)絡(luò)，無論它是否包含在虛擬機(jī)中。你擁有的虛擬機(jī)數(shù)量越多，你需要的資源就越多，它的成本就越多。

　　CiRBA公司共同創(chuàng)始人和首席技術(shù)官Andrew Hillier指出，他稱作“朽木”的利用率不足的虛擬機(jī)或者孤兒式的虛擬機(jī)的成本會非常高，因為一個真運(yùn)行而不做任何有用的工作的鏡像仍然在消耗系統(tǒng)的內(nèi)存。所有的虛擬機(jī)都要占用有價值的硬盤空間，每個ISO鏡像通常占用幾GB空間。

　　Mar指出，蔓延還會增加數(shù)據(jù)中心管理系統(tǒng)的成本，因為許多管理系統(tǒng)的許可證都是根據(jù)管理的節(jié)點或者客戶端代理收費(fèi)的。這意味著你擁有的每一臺 虛擬機(jī)都有累計的許可證費(fèi)用。Mar還謹(jǐn)慎地指出，雖然虛擬機(jī)很容易創(chuàng)建和部署，但是，配置、監(jiān)視、升級和使用補(bǔ)丁等標(biāo)準(zhǔn)的系統(tǒng)管理活動是有管理成本的。

　　Info-Tech公司的Sloan贊成這個觀點。他指出，許多服務(wù)器管理任務(wù)，如升級補(bǔ)丁、都把服務(wù)器當(dāng)作運(yùn)行的操作系統(tǒng)和應(yīng)用程序?qū)嵗幚怼Ｔ谶@方面，100個虛擬服務(wù)器仍是100個管理實例，而不管下面的物理服務(wù)器的數(shù)量是多少。

　　由于包含各種變量，預(yù)測蔓延的財務(wù)成本是有問題的。這些變量包括沒有使用的多余的機(jī)器、IT管理員逐步增加的開銷、需要的新的軟件許可證的數(shù)量、硬盤空間的成本和存儲管理等。

　　據(jù)Embotics公司進(jìn)行的調(diào)查，大多數(shù)客戶認(rèn)為他們公司的大約30%的虛擬機(jī)很可能是冗余的。實際的物理服務(wù)器審計證實了這個數(shù)字。這個審計指出，有些客戶把冗余量定在50%以上。Embotics的客戶預(yù)計他們運(yùn)行一臺普通服務(wù)器的成本大約是1000至3000美元。這些成本包括操作系統(tǒng)、應(yīng)用程序、工具和相關(guān)的管理系統(tǒng)代理程序等軟件許可證。Mar稱，一個150個虛擬機(jī)的環(huán)境平均有5萬至15萬美元的費(fèi)用與冗余的虛擬機(jī)有關(guān)。

　　由于虛擬機(jī)的設(shè)置不當(dāng)，蔓延還增加了軟成本，如增加的安全風(fēng)險或者遵守法規(guī)的問題。

　　如何減小或者防止蔓延

　　減小蔓延的兩個主要方法是恢復(fù)對虛擬機(jī)的生命周期管理控制和根據(jù)可用的物理資源優(yōu)化虛擬機(jī)和相關(guān)應(yīng)用程序的使用。Sloan說，改善虛擬機(jī)管理對于虛擬機(jī)廠商來說是一個積極開發(fā)和差異化的領(lǐng)域，因為虛擬機(jī)管理程序?qū)⒑芸毂恍薷摹５谌杰浖_發(fā)商也進(jìn)入了這個領(lǐng)域，推出一些新的基于政策的虛擬化管理產(chǎn)品，特別是針對管理虛擬化環(huán)境獨特難題的產(chǎn)品。

　　優(yōu)化軟件旨在通過描繪虛擬化應(yīng)用程序工作量的特點并且把它們映射到數(shù)據(jù)中心的服務(wù)器池和存儲中來改善可用資源的利用。比較新的方法許諾通過創(chuàng)建 FastScale公司所說的“動態(tài)應(yīng)用程序捆綁”來顯著減少虛擬機(jī)占用的資源。“動態(tài)應(yīng)用程序捆綁”是一個小的、功能齊全的軟件環(huán)境(一個虛擬機(jī)鏡像使 用大約1%的內(nèi)存)，僅需要一個應(yīng)用程序需要的準(zhǔn)備的軟件組件。

　　虛擬化是一個強(qiáng)大的工具，允許IT部 門快速建立和部署新的系統(tǒng)環(huán)境，同時增加使用不足的硬件的利用率。遺憾的是虛擬機(jī)創(chuàng)建的簡單性和方便性能夠?qū)е虏惶玫氖虑椋绱罅咳哂嗟摹⒑苌偈褂玫幕?者孤兒式的虛擬鏡像。如果部發(fā)現(xiàn)這個問題，這種虛擬蔓延將迫使企業(yè)付出巨大的成本。不過，新的管理工具和優(yōu)化軟件現(xiàn)在能夠讓數(shù)據(jù)中心管理員控制虛擬機(jī)環(huán) 境，更有效地把虛擬的應(yīng)用程序映射到他們的物理服務(wù)器。

Tags: 虛擬化, 虛擬機(jī), 成本.IT, 架構(gòu)

　　對于小型 項目，首先，必須有文檔要求，否則后期的修改、維護(hù)、升級都會變得異常困難;其次，對文檔的要求應(yīng)該“適度”，即夠用即可。一切以便于后續(xù)工作為目標(biāo)，不 做過于繁瑣的要求，不應(yīng)把大量精力投入進(jìn)過于繁瑣的文檔編寫。此外，還應(yīng)注意文檔的版本控制，保證文檔和代碼的一致性。

　　小型軟件項目，通常是指工作量在3-12人月之間的項目，在小型軟件開發(fā)企業(yè)中，這類項目一般是放任自流，少有管理。在這類項目中，項目經(jīng)理的 角色常常由公司老總或部門老總親自充當(dāng)， 項目往往具有投資少、人員少、時間緊、需求不明確等特點。由于針對小型項目，缺乏科學(xué)有效的管理方式，或企業(yè)難以負(fù)擔(dān)類似于大型軟件開發(fā)的管理成本，這類 項目的開發(fā)過程往往會產(chǎn)生諸如項目進(jìn)度難以控制、產(chǎn)品缺陷多、后期維護(hù)工作量大、客戶滿意度低、文檔缺乏等諸多問題。一項調(diào)查表明，大約有70%的小型軟 件開發(fā)項目超出了預(yù)期時間，90%以上的項目費(fèi)用超出預(yù)算。因此，小型項目迫切需要引入適度的開發(fā)管理。本文將針對小型軟件項目開發(fā)過程中的核心管理問題 給出一些行之有效的解決方案。

　　一、需求管理

　　對于任何類型的軟件項目，需求階段都是最重要的階段，需求管理是整個軟件項目管理的重中之重。需求管理通常包括兩個大方面的問題：需求收集分析與需求變更管理。

　　首先，對于需求收集與分析，核心風(fēng)險來自于需求不明確。由于客戶和軟件開發(fā)團(tuán)隊的背景不同，對同一問題的理解自然存在差異。這些差異如果不能在 需求的最初階段盡量彌合，那么必然導(dǎo)致需求增加與需求更改。因此，在需求分析階段，要求需求分析人員具有豐富的客戶溝通經(jīng)驗，必須多花一些時間，充分了解 用戶的目標(biāo)與工作過程，站在客戶立場上，設(shè)身處地考慮問題，幫助用戶將模糊的需求清晰化，將簡略的需求明細(xì)化、完善化，將混亂的需求邏輯化、條理化。

　　其次，任何項目都無法承受頻繁的需求變更與需求增加。因此，除了在需求收集階段需要盡可能將需求細(xì)化外，還需要在適當(dāng)階段盡量凍結(jié)需求。公司的 銷售人員往往傾向于接受用戶模糊的要求，并暗示用戶“什么都好商量”。這往往給項目后期甚至項目完成后又頻繁更改需求，甚至導(dǎo)致項目嚴(yán)重拖延、開支嚴(yán)重超 出預(yù)算埋下禍根。因此，在需求細(xì)化的后期階段，必須“拉下臉來”，就需求凍結(jié)和后期需求增加的費(fèi)用支付方式和客戶達(dá)成共識。

　　二、關(guān)注項目設(shè)計的靈活性

　　對于中小型項目，在設(shè)計過程中，必須關(guān)注設(shè)計的靈活性。在實際的項目中，即使在需求階段花再多的經(jīng)歷，也沒法完全避免開發(fā)階段的需求變更。因此，在架構(gòu)設(shè)計中，盡可能采用靈活的設(shè)計就至關(guān)重要。對于項目設(shè)計人員，可以借鑒RUP(Rational Unified Process)中基于組建的體系結(jié)構(gòu)思想，利用基于獨立的、可替換的、模塊化組件的體系結(jié)構(gòu)管理復(fù)雜性，提高重用率，構(gòu)建有彈性的、能適應(yīng)變化的、易于理解的、有助于重用的體系結(jié)構(gòu)。

　　三、開發(fā)進(jìn)度管理

　　開發(fā)進(jìn)度管理，主要需要關(guān)注如下幾個方面：

　　1. 任務(wù)分配、人力資源分配、時間分配要和工程進(jìn)度協(xié)調(diào);

　　2. 任務(wù)分解要合理，并且盡量并行化;

　　3. 對項目進(jìn)度控制要盡量細(xì)致，并且在實際執(zhí)行過程中審查要嚴(yán)格;

　　4. 針對項目中不容易控制的部分，譬如技術(shù)難點、來自于客戶的時間拖延要做好充分的準(zhǔn)備;

　　5. 要為測試、缺陷修正和預(yù)期的需求變更預(yù)留足夠的時間;

　　如有必要，還應(yīng)采用適當(dāng)?shù)膮f(xié)同進(jìn)度管理工具。

　　四、開發(fā)團(tuán)隊管理

　　對于開發(fā)團(tuán)隊管理，要做到分工明確、因人施用。根據(jù)水平的高低，合理分配工作量。并且關(guān)注團(tuán)隊內(nèi)部的交流溝通結(jié)構(gòu)，避免“互相等”和“誤解”。盡量讓每個人的工作量飽和化。在項目開始以后，要盡可能保持團(tuán)隊穩(wěn)定，避免人員變更給團(tuán)隊帶來的協(xié)作混亂。

　　五、配置管理和SQA

　　軟件配置管理(SCM)的主要作用是標(biāo)識、控制、和狀態(tài)統(tǒng)計。

　　這些功能的意圖是維護(hù)和跟蹤功能、配置、產(chǎn)品、產(chǎn)品基線、需求規(guī)約和其他文檔的變更，軟件版本的描述;跟蹤變更申請，問題報告和解決記錄，提供配置控件委員會(CCB)會議紀(jì)要等。

　　軟件開發(fā)之后的變更需要從多個側(cè)面加以注意:

　　1. 任何返工都是有代價的

　　2. 將資源用于返工則無法開展新項目

　　3. 如果變更不能精確的標(biāo)識和控制，那么軟件的版本就會因為未知和沒有記錄的修改而無法跟蹤

　　4. 如果變更沒有考慮到所有的副作用，那么對于一個變更所引起的連鎖反應(yīng)的跟蹤是非常費(fèi)時間的

　　5. 變更次數(shù)的增加會使系統(tǒng)面目全非

　　當(dāng)項目經(jīng)常變更時候，SQA是非常重要的。SQA應(yīng)該進(jìn)行Pareto分析和趨勢分析以確定引起變更的根本原因。SQA同時要保證系統(tǒng)的影響是可跟蹤、可測試和可驗證的。SQA的一個主要目標(biāo)是在開發(fā)的早期發(fā)現(xiàn)問題，避免其進(jìn)入下游開發(fā)中。

　　六、文檔管理

　　對于小型項目，首先，必須有文檔要求，否則后期的修改、維護(hù)、升級都會變得異常困難;其次，對文檔的要求應(yīng)該“適度”，即夠用即可。一切以便于 后續(xù)工作為目標(biāo)，不做過于繁瑣的要求，不應(yīng)把大量精力投入進(jìn)過于繁瑣的文檔編寫。此外，還應(yīng)注意文檔的版本控制，保證文檔和代碼的一致性。

Tags: SQA, 項目管理, 軟件工程

Tags: QQ, Linux,

     MySQL Server將永遠(yuǎn)保留完整的功能和開放源代碼，MySQL數(shù)據(jù)庫驅(qū)動和新的存儲引擎都將如此。此外MySQL 6.0即將加入的備份功能，MyISAM driver，加密和壓縮備份功能都會繼續(xù)開源。

    此舉顯示Sun仍然遵守開源的承諾。

Tags: Mysql, 開源, 數(shù)據(jù)庫, 博客

　　在國內(nèi)，作為“甲方”的電信和一些大型國企已經(jīng)開始探索在IT外包應(yīng)用中引入ITIL，規(guī)范管理IT外包商;作為“乙方”的IT服務(wù)商也開始探索建立符合ITIL的服務(wù)管理體系，提升服務(wù)水平。

　　從企業(yè)內(nèi)部來說，國內(nèi)有一個很龐大的外包群體，尤其是國資企業(yè)，他們一般采取誰開發(fā)、誰運(yùn)維的外包模式，把相當(dāng)一部 分維護(hù)工作外包給應(yīng)用開發(fā)商，這是國內(nèi)最普遍的外包形態(tài)。但是，他們在外包方面存在諸多困惑，主要困惑是不知道怎么去管理這些外包服務(wù)商，也不知道怎么去 量化這些服務(wù)，到底什么是好的服務(wù)，什么是不好的服務(wù)，服務(wù)要做到什么程度才算好的等。

　　從企業(yè)外部環(huán)境來看，目前市場上的IT外包服務(wù)商的服務(wù)水平還有待進(jìn)一步提高。大多數(shù)外包商只是針對他自己開發(fā)的軟硬件來提供外包服務(wù)，缺乏全 面服務(wù)能力，無法支持企業(yè)的整體IT外包需求。大多數(shù)外包商還缺乏可量化、規(guī)范的IT外包服務(wù)管理體系，這種不明朗的服務(wù)狀態(tài)，讓服務(wù)商和用戶單位都面臨 著很大的挑戰(zhàn)：用戶單位對服務(wù)質(zhì)量感到不滿意，而服務(wù)單位不一定能得到合理服務(wù)費(fèi)用，往往只能通過持續(xù)不斷的項目形式來得到回報。總之，以上兩個方面的問 題都不同程度制約著IT外包應(yīng)用的進(jìn)一步發(fā)展。

　　從IT外包發(fā)展趨勢來看，企業(yè)越來越重視IT外包服務(wù)品質(zhì)，希望IT外包服務(wù)商具備規(guī)范的服務(wù)體系、較高的服務(wù)水平，哪怕價格相對高一點。

　　面臨這樣的挑戰(zhàn)，IT外包雙方都不得不突破原有管理模式，尋找新的發(fā)展方向。在國外，ITIL是指導(dǎo)企業(yè)IT外包應(yīng)用的最佳實踐方法，尤其在 ITILv3.0版本中增加了對外包服務(wù)管理的內(nèi)容。在國內(nèi)，作為“甲方”的電信和一些大型國企已經(jīng)開始探索在IT外包應(yīng)用中引入ITIL，規(guī)范管理IT 外包商;作為“乙方”的IT服務(wù)商也開始探索建立符合ITIL的服務(wù)管理體系，提升服務(wù)水平。

　　“甲方”關(guān)注質(zhì)量監(jiān)控和考核

　　對于IT外包雙方來說，ITIL的價值各有不同。通過實施ITIL，作為“甲方”的用戶可以更加明確IT外包雙方的職責(zé)、日常要做的工作內(nèi)容等，從而創(chuàng)建一個如何規(guī)范外包商的服務(wù)管理體系。

　　目前，大多數(shù)企業(yè)的IT外包合同內(nèi)容非常簡單，只簡單說明一下針對哪些系統(tǒng)提供維護(hù)服務(wù)，全年花多少錢，派多少人常駐等。很多企業(yè)IT外包方面 的負(fù)責(zé)人所面臨的挑戰(zhàn)是：需要IT外包商提供什么樣的服務(wù)水平，才能讓企業(yè)業(yè)務(wù)部門滿意?如果業(yè)務(wù)部門不滿意，該怎么驅(qū)動IT外包商改善服務(wù)?到目前為 止，大多數(shù)IT外包合同對以上內(nèi)容沒有非常明確的定義。

　　另外，外包的IT設(shè)施會有一些增減變化，服務(wù)的用戶數(shù)量也可能發(fā)生變化，如果在原來合同里沒有明確說明改怎么辦?由于缺乏一種相應(yīng)的管理機(jī)制， 比如針對這些變化該如何進(jìn)行協(xié)調(diào)等,那么最終就是客戶吃虧或者IT外包商吃虧。通過部署ITIL的服務(wù)目錄和服務(wù)水平協(xié)議，用戶可以把整個外包內(nèi)容細(xì)致 化、量化，明確提出IT外包商該做些什么，并把這些服務(wù)項目放進(jìn)服務(wù)合同中，改變以往粗放式的合同。

　　舉例來說，原來沒有明確說明外包商該怎么做后臺的維護(hù)工作，詳細(xì)化之后，用戶可以明確要求IT外包商把日常巡查管理做起來，代理廠商、代理服務(wù) 商每天要巡檢幾次、要巡檢哪些內(nèi)容;而且系統(tǒng)會自動檢查是否做過巡檢，如果兩小時內(nèi)沒有巡檢，系統(tǒng)就會向用戶主管人員發(fā)一個短信，通知他們外包商沒有做巡 檢。對用戶來說，這確確實實提供了一種非常便利的管理手段;對于外包商來說，通過這種規(guī)范性管理，從而幫助他們提升外包服務(wù)的管理水平。

　　通過實施ITIL，用戶還可以對外包商進(jìn)行量化考核。以前很多IT外包合同沒有明確的考核指標(biāo)，不管是對外包商還是用戶，都是不公平的。舉例來 說，現(xiàn)在用戶可以對服務(wù)滿意度進(jìn)行量化，分為滿意、不滿意、比較滿意等幾個等級。如果70%客戶滿意那么就是比較滿意;低于50%的客戶滿意，就是不滿意 等。隨后把這些量化的滿意度指標(biāo)放進(jìn)合同中，明確提出今年的滿意度是多少，明年要提升多少等，如果外包商達(dá)不到，就要接收懲罰。這樣，考核就比較細(xì)化了。

　　總之，用戶可以在外包過程中更有效地承擔(dān)起質(zhì)量監(jiān)控和服務(wù)考核的角色。

　　“乙方”重點規(guī)范服務(wù)流程

　　通過實施ITIL，作為“乙方”的外包商可以搭建一個可量化、可視化、可控的服務(wù)管理體系，提升服務(wù)能力、服務(wù)水平、服務(wù)架構(gòu)。目前，大多數(shù) IT外包商的服務(wù)能力比較薄弱，通過部署以ITIL為基礎(chǔ)的管理流程，外包商能夠以更科學(xué)的方法學(xué)會怎么做服務(wù)、怎樣配備人員、設(shè)置什么樣的服務(wù)職能以及 制訂日常服務(wù)規(guī)范等，從而提升了管理能力、服務(wù)能力，并進(jìn)而跟蹤服務(wù)成本的組成，幫助服務(wù)單位為優(yōu)化和降低成本打下基礎(chǔ)。

　　在組織體系設(shè)計上，ITIL打散以往按技術(shù)劃分部門的組織體系，提供層級化的組織架構(gòu)，把服務(wù)人員按照一線、二線、三線來劃分。一線人員記錄服 務(wù)的呼叫，并處理簡單故障;二線人員處理一線解決不了的問題;三線人員解決難度較大的問題。另外，ITIL還針對不同流程設(shè)置相應(yīng)的流程經(jīng)理，去推動和優(yōu) 化每個流程的實現(xiàn)。這種對服務(wù)資源進(jìn)行重新整合的服務(wù)架構(gòu)，把服務(wù)提供的日常職能和崗位劃分清晰，不僅可以提高處理故障的效率，還使相同數(shù)量人員的服務(wù)能 力極大提高。

　　ITIL的核心是流程管理，包括故障處理流程、變更流程等十大流程。通過實施ITIL，外包商能夠把日常操作全部流程化，并通過自動化工具對流程執(zhí)行情況進(jìn)行及時追蹤。 在這個基礎(chǔ)上，可以對各個流程的執(zhí)行效果、服務(wù)質(zhì)量進(jìn)行量化考核和統(tǒng)計分析。

　　簡單來說，乙方只要按照服務(wù)水平協(xié)議，做好外包的過程控制，就可以了。

　不同的實施關(guān)鍵點

　　對于IT外包雙方來說，由于角色不同，因此導(dǎo)致二者在ITIL實施方面具有明顯不同的特點。

　　IT外包商的服務(wù)管理體系設(shè)計與一般數(shù)據(jù)中心的相似，不同的是在開始就要規(guī)劃好服務(wù)容量。因為數(shù)據(jù)中心的服務(wù)內(nèi)容變化是緩慢的、漸進(jìn)的，但是 IT外包商的服務(wù)內(nèi)容變化的劇烈程度遠(yuǎn)遠(yuǎn)高于數(shù)據(jù)中心，這是最大的差別。因此，IT外包商的服務(wù)管理體系需要能夠適應(yīng)這樣一種動態(tài)變化的環(huán)境，需要具備一 定彈性。比如，IT外包商當(dāng)前為兩個企業(yè)提供外包服務(wù)，如果第三個企業(yè)的服務(wù)合同進(jìn)來時，這種服務(wù)管理體系是否能夠容納。

　　為了保持彈性，IT外包商需要重點關(guān)注人力資源的能力規(guī)劃，比如多少人接多少個呼叫是合理的，邊際效應(yīng)是什么樣，最大承受能力應(yīng)該有一個范圍，也就是說，一個人接多少個呼叫是不會虧本的，而且一個人最多能夠承受多少個呼叫才不會使得服務(wù)質(zhì)量明顯下降。

　　相比IT外包商，用戶不是那么關(guān)注IT外包商提供服務(wù)的細(xì)節(jié)，通常是讓他的外包商來參與這些細(xì)節(jié)。只要看到外包商是按照IT服務(wù)流程和規(guī)范在運(yùn) 作，就可以了。用戶比較關(guān)注的是控制點，比如服務(wù)目錄、服務(wù)水平協(xié)議的內(nèi)容，服務(wù)質(zhì)量、量化的考核指標(biāo)，對故障的定義也非常關(guān)注，要求在多長時間內(nèi)必須解 決故障，什么等級的故障多長時間之內(nèi)不能處理，就必須升級等，這些問題是用戶必須花精力來做的事情。

　　總之，ITIL可以使IT外包雙方之間的溝通更快捷、高效，提高IT外包的應(yīng)用效果，為IT外包應(yīng)用的進(jìn)一步發(fā)展提供有力支持。

Tags: ITIL, IT外包, 信息化, SaaS

　　對于許多小型企業(yè)來說，SaaS是采用先進(jìn)技術(shù)的最好途徑，它消除了企業(yè)購買、構(gòu)建和維護(hù)基礎(chǔ)設(shè)施和應(yīng)用程序的需要，近年來，SaaS的興起已經(jīng)給傳統(tǒng)套裝軟件廠商帶來真實的壓力。

　　SaaS是Software-as-a-service(軟件即服務(wù))的簡稱，它是一種通過Internet提 供軟件的模式，用戶不用再購買軟件，而改用向提供商租用基于Web的軟件，來管理企業(yè)經(jīng)營活動，且無需對軟件進(jìn)行維護(hù)，服務(wù)提供商會全權(quán)管理和維護(hù)軟件， 對于許多小型企業(yè)來說，SaaS是采用先進(jìn)技術(shù)的最好途徑，它消除了企業(yè)購買、構(gòu)建和維護(hù)基礎(chǔ)設(shè)施和應(yīng)用程序的需要，近年來，SaaS的興起已經(jīng)給傳統(tǒng)套 裝軟件廠商帶來真實的壓力。

　　SaaS服務(wù)提供模式

　　SaaS服務(wù)提供商為中小企業(yè)搭建信息化所需要的所有網(wǎng)絡(luò)基礎(chǔ)設(shè)施及軟件、硬件運(yùn)作平臺，并負(fù)責(zé)所有前期的實施、后期的維護(hù)等一系列服務(wù)，企業(yè)無需購買軟硬件、建設(shè)機(jī)房、招聘IT人 員，只需前期支付一次性的項目實施費(fèi)和定期的軟件租賃服務(wù)費(fèi)，即可通過互聯(lián)網(wǎng)享用信息系統(tǒng)。服務(wù)提供商通過有效的技術(shù)措施，可以保證每家企業(yè)數(shù)據(jù)的安全性 和保密性。企業(yè)采用SaaS服務(wù)模式在效果上與企業(yè)自建信息系統(tǒng)基本沒有區(qū)別，但節(jié)省了大量用于購買IT產(chǎn)品、技術(shù)和維護(hù)運(yùn)行的資金，且像打開自來水龍頭 就能用水一樣，方便地利用信息化系統(tǒng)，從而大幅度降低了中小企業(yè)信息化的門檻與風(fēng)險。

　　SaaS服務(wù)的優(yōu)勢

　　對企業(yè)來說，SaaS的優(yōu)點在于：

　　⒈ 從技術(shù)方面來看：企業(yè)無需再配備IT方面的專業(yè)技術(shù)人員，同時又能得到最新的技術(shù)應(yīng)用，滿足企業(yè)對信息管理的需求。

　　⒉ 從投資方面來看：企業(yè)只以相對低廉的“月費(fèi)”方式投資，不用一次性投資到位，不占用過多的營運(yùn)資金，從而緩解企業(yè)資金不足的壓力;不用考慮成本折舊問題，并能及時獲得最新硬件平臺及最佳解決方案。

　　⒊ 從維護(hù)和管理方面來看：由于企業(yè)采取租用的方式來進(jìn)行物流業(yè)務(wù)管理，不需要專門的維護(hù)和管理人員，也不需要為維護(hù)和管理人員支付額外費(fèi)用。很大程度上緩解企業(yè)在人力、財力上的壓力，使其能夠集中資金對核心業(yè)務(wù)進(jìn)行有效的運(yùn)營。

Tags: SaaS, 中小企業(yè)，IT外包

標(biāo)簽: 中小企業(yè), email營銷, 用戶體驗, 設(shè)計

美國負(fù)責(zé)貿(mào)易的副國務(wù)卿Christopher Padilla近日對媒體表示，如果中國堅持建立自己的技術(shù)標(biāo)準(zhǔn)而不是遵循世界的標(biāo)準(zhǔn)，中國將有被“技術(shù)隔離”的危險。

他表示，中國建立自己的技術(shù)標(biāo)準(zhǔn)其實只是為了阻止外國公司進(jìn)入這個世界上最大的市場而已。

Padilla說，中國正在面臨日本80年代同樣的問題：他們覺得自己已經(jīng)夠強(qiáng)大了，開始制定其標(biāo)準(zhǔn)而要求世界遵從起來。美國的公司已經(jīng)發(fā)現(xiàn)在中國做生意越來越難，因為信息技術(shù)的安全標(biāo)準(zhǔn)大不相同，他們需要付出額外的代價。

他認(rèn)為，現(xiàn)在看來中國的這種努力并沒有取得成效，反而使得中國成為了一個“被隔絕的技術(shù)孤島”。中國現(xiàn)在正在開發(fā)自家的3G標(biāo)準(zhǔn)，雖然這可能會讓中國在短期內(nèi)更有競爭力，但是長期以來會限制產(chǎn)品的研發(fā)，減少用戶的選擇范圍，從而最終阻礙中國的增長。

標(biāo)簽: 技術(shù)標(biāo)準(zhǔn), 3G

了解 Eclipse 插件如何使用 OSGi

Eclipse 和 OSGi 的關(guān)系，從 plugin.xml 到 manifest.mf

級別： 中級 原帖地址：http://www.ibm.com/developerworks/cn/opensource/os-ecl-osgi/index.html

Scott Delap (scott@clientjava.com), Desktop/Enterprise Java 顧問

Eclipse 集成開發(fā)環(huán)境（IDE）和 Eclipse Rich Client Platform（RCP）應(yīng)用程序的核心由 Open Services Gateway Initiative（OSGi）規(guī)范的實現(xiàn)驅(qū)動。本文通過描述對 Eclipse 平臺而言插件是什么，并跟蹤從 Eclipse V2.1 到今天基于 OSGi 的實現(xiàn)中插件的發(fā)展，闡明了 Eclipse 與 OSGi 的關(guān)系。還解釋了 OSGi manifest.mf 文件選項以及通過 Eclipse 提供的添加項。

大多數(shù) Java? 編程語言開發(fā)人員通過作為 IDE 的功能認(rèn)識了 Eclipse。Eclipse IDE 實際上由叫做插件 的交互式組件的集合組成。這些插件組成了 IDE 的基礎(chǔ)，它們還可用于創(chuàng)建其他桌面應(yīng)用程序。創(chuàng)建基于 Eclipse 的應(yīng)用程序所需的最小插件集稱為 Eclipse Rich Client Platform（RCP）。但是，插件本身不能啟動。它們需要在一個環(huán)境中啟動和操作。Eclipse 使用 OSGi R4 規(guī)范的實現(xiàn)提供了該環(huán)境。

因為 Eclipse 在本質(zhì)上是由 OSGi 驅(qū)動的，因此必須了解 Eclipse 插件的概念與 OSGi 框架有什么關(guān)系。在本文中，我將通過描述對 Eclipse 平臺而言插件是什么來詳細(xì)解釋這種關(guān)系。然后，將描述在 Eclipse V2.1 平臺到今天基于 OSGi 的實現(xiàn)中插件的發(fā)展。最后，將詳細(xì)介紹應(yīng)用于 Eclipse 插件的 OSGi 提供的 manifest.mf 選項。

插件是什么？

Eclipse 聯(lián)機(jī)幫助將插件定義為：

“插件是為系統(tǒng)提供功能的代碼和/或數(shù)據(jù)的結(jié)構(gòu)化包。可以以代碼庫（帶有公共 [應(yīng)用程序接口] API 的 Java 類）、平臺擴(kuò)展甚至文檔的形式來提供功能。插件可以定義擴(kuò)展點、定義良好的位置，其他插件可以在這些位置添加功能。”

要注意的一個重點是插件以結(jié)構(gòu)化方式提供功能。它們可以提供服務(wù)（比如日志）或可用于用戶界面（UI）的功能，比如編輯器。不管什么功能，所有插件都以相同的結(jié)構(gòu)化方式來定義。

到 OSGi 的發(fā)展

如前所述，Eclipse 使用 OSGi 作為插件系統(tǒng)的基礎(chǔ)。但并非總是如此。早期版本的 Eclipse 也設(shè)計為插件集合，而且 Eclipse 包括自己專用的插件系統(tǒng)來管理交互。但是，隨著 Eclipse IDE 要求的增長，必須需要一個更強(qiáng)壯的解決方案。這個新系統(tǒng)的基本要求包括動態(tài)添加新插件和停止現(xiàn)有插件的能力。經(jīng)過大量研究之后，Eclipse 創(chuàng)建者決定通過實現(xiàn) OSGi 框架規(guī)范替換專用的插件框架。

OSGi 是服務(wù)平臺的規(guī)范。Eclipse 提供了該規(guī)范的許多可用實現(xiàn)之一，并用作最新 OSGi R4 規(guī)范的參考實現(xiàn)。OSGi 是基于 Java 的框架，旨在用于需要長運(yùn)行時間、動態(tài)更新和對運(yùn)行環(huán)境破壞最小的系統(tǒng)。起初，OSGi 旨在用于家庭自動化和家庭網(wǎng)關(guān)設(shè)備。最近，從手機(jī)到汽車都發(fā)現(xiàn)了它的蹤跡。

在核心，OSGi 是一個組件和服務(wù)模型，如圖 1 所示。OSGi 規(guī)范定義了一個叫做綁定包 的模塊化單位。（在下文中，除非特別指明，Eclipse 術(shù)語插件 和 OSGi 術(shù)語綁定包 可交換使用，因為所有 Eclipse 插件現(xiàn)在都是 OSGi 綁定包。）OSGi 還提供了 Java Virtual Machine（JVM）級別的服務(wù)注冊，該綁定包可用于發(fā)布、發(fā)現(xiàn)和綁定至服務(wù)。

OSGi 規(guī)范定義了綁定包生命周期的基礎(chǔ)架構(gòu)和綁定包的交互方式。這些規(guī)則通過使用特殊 Java 類加載器來強(qiáng)制執(zhí)行。在一般 Java 應(yīng)用程序中，CLASSPATH 中的所有類都對所有其他類可見。相反，OSGi 類加載器基于 OSGi 規(guī)范和每個綁定包的 manifest.mf 文件中指定的選項（稍后將詳細(xì)介紹）來限制類交互。

Eclipse IDE 使用圍繞模塊化和綁定包生命周期的一個 OSGi 子集。但是，它最低限度地使用了 OSGi 提供的服務(wù)支持。相反，Eclipse 提供自己的擴(kuò)展點系統(tǒng)來啟用綁定包交互。綁定包將功能暴露給其他擴(kuò)展。綁定包還定義自己的擴(kuò)展點，允許其他綁定包向其貢獻(xiàn)功能。使用 Eclipse 中擴(kuò)展點的一個示例是 Preferences 窗口。核心 Eclipse 插件提供中央窗口，并暴露擴(kuò)展點以允許其他首選項頁面的貢獻(xiàn)。當(dāng)插件添加到 Eclipse 中時，它們可以貢獻(xiàn)它們自己的頁面。Eclipse 中擴(kuò)展點的模型不同于基本的 OSGi 服務(wù)。綁定包擴(kuò)展點由定義綁定包擁有；其他綁定包只對這些點做貢獻(xiàn)。相反，任何綁定包可以實現(xiàn)和使用 OSGi 服務(wù)。

使用 OSGi 實現(xiàn) Eclipse

在 3.1 之前版本的 Eclipse 中，在每個插件的 plugin.xml 文件中定義插件依賴關(guān)系以及擴(kuò)展和擴(kuò)展點。在使用 OSGi 的新版本 Eclipse 中，依賴關(guān)系信息被分解到 manifest.mf 文件中，而 plugin.xml 文件只包含擴(kuò)展和擴(kuò)展點的 XML 定義。看一個演示該發(fā)展的生動的工作示例十分有用。清單 1 展示了 Eclipse V3.0 中 org.eclipse.pde.ui 插件的代碼段。

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
   id="org.eclipse.pde.ui"
   name="%name"
   version="3.0.2"
   provider-name="%provider-name"
   class="org.eclipse.pde.internal.ui.PDEPlugin">

   <runtime>
      <library name="pdeui.jar">
         <export name="*"/>
      </library>

   </runtime>
   <requires>
      <import plugin="org.eclipse.core.runtime.compatibility"/>
      <import plugin="org.eclipse.ui.ide"/>
      <import plugin="org.eclipse.ui.views"/>
      <import plugin="org.eclipse.jface.text"/>

      <import plugin="org.eclipse.ui.workbench.texteditor"/>
      <import plugin="org.eclipse.ui.editors"/>
      <import plugin="org.eclipse.ant.core"/>
      <import plugin="org.eclipse.core.resources"/>
      <import plugin="org.eclipse.debug.core"/>
      <import plugin="org.eclipse.debug.ui"/>

      <import plugin="org.eclipse.help.base"/>
      <import plugin="org.eclipse.jdt.core"/>
      <import plugin="org.eclipse.jdt.debug.ui"/>
      <import plugin="org.eclipse.jdt.launching"/>
      <import plugin="org.eclipse.jdt.ui"/>
      <import plugin="org.eclipse.pde"/>

      <import plugin="org.eclipse.pde.build"/>
      <import plugin="org.eclipse.search"/>
      <import plugin="org.eclipse.team.core"/>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.update.core"/>
      <import plugin="org.eclipse.ui.forms"/>

      <import plugin="org.eclipse.ant.ui"/>
      <import plugin="org.eclipse.jdt.junit"/>
      <import plugin="org.eclipse.ui.intro"/>
      <import plugin="org.eclipse.ui.cheatsheets"/>
   </requires>


<!-- Extension points -->
   <extension-point id="pluginContent" 
   name="%expoint.pluginContent.name" 
   schema="schema/pluginContent.exsd"/>
   <extension-point id="newExtension" 
   name="%expoint.newExtension.name" 
   schema="schema/newExtension.exsd"/>
<extension-point id="templates" 
name="%expoint.templates.name" 
schema="schema/templates.exsd"/>
<extension-point id="samples" 
name="%expoint.samples.name" 
schema="schema/samples.exsd"/>

<!-- Extensions -->
   <extension
         point="org.eclipse.ui.perspectives">

      <perspective
            name="%perspective.name"
            icon="icons/eview16/plugins.gif"
            class="org.eclipse.pde.internal.ui.PDEPerspective"
            id="org.eclipse.pde.ui.PDEPerspective">
      </perspective>
   </extension>

<export name="*"/> 聲明暴露了插件中的所有包以供其他插件使用。插件依賴關(guān)系導(dǎo)入部分列出了 org.eclipse.pde.ui 插件需要的必備插件。

接下來兩部分定義了 org.eclipse.pde.ui 可用于其他插件的擴(kuò)展點以及它對其他插件的貢獻(xiàn)。在本例中，可以看到自定義 Eclipse Plug-in Development Environment（PDE）視圖的定義。

下面來看 Eclipse V3.1 中的同一插件定義。清單 2 展示了 plugin.xml 文件。

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>

    
<!-- Extension points -->
   <extension-point id="pluginContent" 
   name="%expoint.pluginContent.name" 
   schema="schema/pluginContent.exsd"/>

   <extension-point id="newExtension" 
   name="%expoint.newExtension.name" 
   schema="schema/newExtension.exsd"/>
   <extension-point id="templates" 
   name="%expoint.templates.name" 
   schema="schema/templates.exsd"/>
   <extension-point id="samples" 
   name="%expoint.samples.name" 
   schema="schema/samples.exsd"/>

<!-- Extensions -->
   <extension
         point="org.eclipse.ui.perspectives">
      <perspective
            name="%perspective.name"
            icon="icons/eview16/plugins.gif"
            class="org.eclipse.pde.internal.ui.PDEPerspective"
            id="org.eclipse.pde.ui.PDEPerspective">

      </perspective>

注意，導(dǎo)出和導(dǎo)入信息不見了。該信息現(xiàn)在位于清單 3 所示的 manifest.mf 文件中。

Manifest-Version: 1.0
Bundle-Name: %name
Bundle-SymbolicName: org.eclipse.pde.ui; singleton:=true
Bundle-Version: 3.1.0
Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jar
Bundle-Activator: org.eclipse.pde.internal.ui.PDEPlugin
Bundle-Vendor: %provider-name
Bundle-Localization: plugin
Require-Bundle: org.eclipse.core.runtime,
 org.eclipse.ui.ide,
 org.eclipse.ui.views,
 org.eclipse.jface.text,
 org.eclipse.ui.workbench.texteditor,
 org.eclipse.ui.editors,
 org.eclipse.ant.core,
 org.eclipse.core.resources,
 org.eclipse.debug.core,
 org.eclipse.debug.ui,
 org.eclipse.jdt.core,
 org.eclipse.jdt.debug.ui,
 org.eclipse.jdt.launching,
 org.eclipse.jdt.ui,
 org.eclipse.pde,
 org.eclipse.pde.build,
 org.eclipse.search,
 org.eclipse.team.core,
 org.eclipse.ui,
 org.eclipse.update.core,
 org.eclipse.ui.forms,
 org.eclipse.ant.ui,
 org.eclipse.jdt.junit,
 org.eclipse.ui.intro,
 org.eclipse.ui.cheatsheets,
 org.eclipse.update.configurator,
 org.eclipse.help.base
Bundle-ManifestVersion: 2
Eclipse-AutoStart: true
Export-Package: org.eclipse.pde.internal.ui;x-internal:=true,
 org.eclipse.pde.internal.ui.build;x-internal:=true,

 . . .

 org.eclipse.pde.ui,
 org.eclipse.pde.ui.internal.samples;x-internal:=true,
 org.eclipse.pde.ui.templates

各種插件導(dǎo)入現(xiàn)在被指定為必需的綁定包，* 包導(dǎo)出已經(jīng)替換為顯式導(dǎo)出的包列表。

插件級的依賴關(guān)系改為需要顯式導(dǎo)出和導(dǎo)入包的依賴關(guān)系，當(dāng) Eclipse 宣布這個消息時，曾引起大量騷動。主要抱怨的是缺乏已經(jīng)存在于 Eclipse 早期版本中的 <export name="*"/> 的替代物。但是，該省略有許多原因。最重要的原因是從顯式導(dǎo)入和導(dǎo)出中獲得的速度收益。早期版本的 Eclipse 必須打開并瀏覽每個插件 jar 文件以確定它包含哪些類。不包括 * 導(dǎo)出還提供了一級保護(hù)來避免插件暴露不必要的類。插件開發(fā)人員必須進(jìn)行專門選擇來使插件中的功能可供外部使用。該限制允許內(nèi)部包保留在內(nèi)部。

OSGi 清單選項

OSGi R4 框架核心目前的規(guī)范草案幾乎有 PDF 格式的 300 頁。介紹該規(guī)范的每個部分超出了本文范圍，但我將討論 Eclipse 插件開發(fā)人員特別感興趣的 OSGi manifest.mf 選項：

Bundle-Activator

該類用于啟動和停止綁定包。在上面的示例插件中，指定了 org.eclipse.pde.internal.ui.PDEPlugin 類。該類擴(kuò)展 org.eclipse.core.runtime.Plugin，實現(xiàn)了 BundleActivator 接口。

Bundle-ClassPath

該屬性指定要用于綁定包的 CLASSPATH。該屬性可以包含對綁定包 jar 文件中目錄或 jar 文件的引用。可以使用句點指明綁定包的根。在示例 Eclipse PDE 綁定包中，指定了綁定包 jar 文件中的 org.eclipse.pde.ui_3.1.0.jar。如果將插件的源版本導(dǎo)入工作區(qū)中，導(dǎo)入過程將更改綁定包 CLASSPATH 以顯示為 Bundle-ClassPath:，這允許插件的開發(fā)版本挑選已編譯的綁定包類。

Bundle-Version

該屬性指定綁定包的版本號。包導(dǎo)入和必需的綁定包規(guī)范可以包括綁定包版本號。

Export-Package

該屬性指定要公共暴露給其他插件的所有包。

Import-Package

該屬性指定要從必需插件中顯式導(dǎo)入的所有包。默認(rèn)情況下，必須為要啟動的綁定包解析所有包。還可以將包導(dǎo)入指定為可選項，以支持包不存在的情況。顯式導(dǎo)入的類在 Require-Bundle 插件中的包之前解析。

Require-Bundle

該屬性指定要在給定綁定包中導(dǎo)入使用的綁定包及其已導(dǎo)出的包。指定的綁定包在顯式包導(dǎo)入之后解析。

Eclipse 提供的其他清單選項

伙伴類加載器選項 首先為 Hibernate 創(chuàng)建插件。然后創(chuàng)建一個插件，其中包含與 Hibernate 有依賴關(guān)系的特定于域的類。將下列行添加到 Hibernate 插件清單中：Eclipse-BuddyPolicy: registered。 將下列清單屬性添加到包含特定于域的類或資源的插件清單中： Eclipse-RegisterBuddy: hibernate。 該行允許插件通過聲明將自己暴露給 Hibernate 插件，而它預(yù)先并不知道這些插件。現(xiàn)在，Hibernate 插件可以看到需要的類，雖然它并沒有專門導(dǎo)入它們。

OSGi 規(guī)范包括的 manifest.mf 配置選項不提供 Eclipse 平臺需要的所有功能。因此，Eclipse 創(chuàng)建者添加了多個擴(kuò)展（還建議將它們包括在未來版本的 OSGi 規(guī)范中）：

Export-Package 頭擴(kuò)展

Eclipse 具有兩個 OSGi 解析器方法 —— default 和 strict，可以使用 osgi.resolver 屬性指定它們。Eclipse 還包括對 Export-Package 屬性的兩個擴(kuò)展 —— x-internal 和 x-friends，啟用 Strict 模式時，會強(qiáng)制執(zhí)行這兩個擴(kuò)展。

x-internal

該屬性的默認(rèn)值是 false。當(dāng)使用該選項將內(nèi)部包指定為 true 時，Eclipse PDE 禁止其使用。

x-friends

該選項類似于 x-internal，但允許特定綁定包使用具有該選項的已導(dǎo)出包。其他綁定包被禁止。x-internal 選項優(yōu)先于 x-friends。

Eclipse-AutoStart

默認(rèn)情況下，Eclipse 根據(jù)需要加載綁定包。因此，當(dāng)導(dǎo)入綁定包包含的第一個類的綁定包需要這個類時，就會加載這些綁定包。將該值指定為 ?? 會導(dǎo)致 Eclipse 在啟動時加載綁定包。還可以指定例外情況列表，它們是無需啟動包含它們的綁定包就可以加載的類和資源。

Eclipse-PlatformFilter

該屬性允許為要啟動的綁定包指定必須等于 true 的條件。可以將下列信息包括在指定的表達(dá)式中：

• osgi.nl，表示語言
• osgi.os，表示操作系統(tǒng)
• osgi.arch，表示架構(gòu)
• osgi.ws，表示窗口系統(tǒng)

展示如何使用該屬性的一個示例是，在啟動使用 SWT_AWT 橋的插件之前驗證操作系統(tǒng)是否是 Mac OS X。（Standard Widget Toolkit（SWT）的 Mac OS X 實現(xiàn)當(dāng)前不支持該功能。）

Eclipse-BuddyPolicy

該選項指定加載綁定包策略的類。通常，綁定包只在其內(nèi)部類和從依賴綁定包中導(dǎo)入的內(nèi)部類中具有可見性。在 Eclipse 新聞組中用來解釋伙伴類加載的流行示例是 Hibernate。Hibernate 框架必須查看用戶創(chuàng)建的而非 Hibernate 本身一部分的類和資源。這樣的一種情況是當(dāng)使用項目動態(tài)填充來自 Hibernate Query Language（HQL）查詢的類時。默認(rèn)情況下，Hibernate 將無法查看位于包含 Hibernate jar 文件的插件外部的類，而需要修改 Hibernate 插件以創(chuàng)建包含 Hibernate 地圖不可接受的類的每個插件。幸運(yùn)的是，伙伴類加載器選項 一節(jié)中介紹的伙伴類加載器選項解決了這個問題。

Eclipse 和 OSGi 的未來趨勢

Eclipse 已經(jīng)從使用 OSGi 中大大受益，獲得了以動態(tài)方式管理組件生命周期的一個健壯的系統(tǒng)。新的使用方法每天都在被發(fā)掘，比如服務(wù)器層特征 servlet、JavaServer Pages 以及 Eclipse 樣式插件中的其他 HTTP 資源。

Eclipse Foundation 已經(jīng)決定在驅(qū)動 OSGi 規(guī)范向前發(fā)展的過程中扮演關(guān)鍵角色，以便于自己和其他人利用 OSGi。在從專用 Eclipse 插件框架轉(zhuǎn)換到 OSGi 的過程中，對 OSGi 規(guī)范進(jìn)行了許多添加，這些添加成了 OSGi R4 規(guī)范發(fā)行版的一部分。因此，Eclipse Equinox 項目已經(jīng)成為不斷發(fā)展的 OSGi 參考實現(xiàn)。該實現(xiàn)以及用于管理發(fā)展 OSGi 的 Java Specification Request（JSR） 291 的創(chuàng)建，保證了 Eclipse/OSGi 合作伙伴關(guān)系將在未來幾年里不斷取得成功。

標(biāo)簽: OSGI, 技術(shù)趨勢, SOA, 組件化, JAVA, ECLIPSE

　 　對于中國數(shù)量眾多的中小企業(yè)而言，在ERP系統(tǒng)應(yīng)用方面需要進(jìn)一步加深對信息化應(yīng)用的理解，需要更多地深入應(yīng)用而非停滯于徘徊中，尤其是已經(jīng)進(jìn)入應(yīng)用階 段的企業(yè)，更需要在長期的實際應(yīng)用中去挖掘系統(tǒng)的價值。此外，在ERP系統(tǒng)的選擇過程中，應(yīng)該多學(xué)習(xí)國際經(jīng)驗，建立科學(xué)的產(chǎn)品選擇觀。

　　【IT專 家網(wǎng)獨家】中小企業(yè)是我國國民經(jīng)濟(jì)中最具活力、并且是推動經(jīng)濟(jì)發(fā)展的重要力量。對于我國的中小企業(yè)而言，他們面臨資金少、規(guī)模小、業(yè)務(wù)單一、員工素質(zhì)不 高，管理體系不規(guī)范等亟待解決的問題。面對復(fù)雜多變的經(jīng)營環(huán)境，越來越多的中小企業(yè)開始尋求信息化手段來幫助自己增強(qiáng)市場競爭力，希望借助先進(jìn)的管理軟件 來理順生產(chǎn)資源和提高管理水平和效率。

　　中小企業(yè)進(jìn)入成長期后，原有的管理模式將不再適應(yīng)企業(yè)內(nèi)外環(huán)境的變化，企業(yè)迫切需要借助信息化手段進(jìn)行規(guī)范的管理，ERP的實施自然是其中不可缺少的一環(huán)。但是，中小企業(yè)從誕生之日起就有著自身的頑癥和特點，如何針對這些頑癥和特點來實施ERP，少走冤枉路，少花冤枉錢，提高成功率是每個中小企業(yè)主所關(guān)心的問題。

　　ERP應(yīng)用是一項系統(tǒng)的綜合工程，它包括前期論證、選型、系統(tǒng)實施、系統(tǒng)驗收、二次開發(fā)等階段，其中，ERP選型即是開始也是難點。選型決定了 整個ERP項目的方向，選型過程就如同遠(yuǎn)航船舶的舵手，如果舵手指錯了方向，那么開足馬力的行駛只能是偏離正確的方向越來越遠(yuǎn)。如何選型，成為擺在中小企 業(yè)面前的一道難題。

　　“只選對的，不選貴的”，這是中小企業(yè)選擇的準(zhǔn)則。“以信息化帶動工業(yè)化，以工業(yè)化促進(jìn)信息化”，國家明了走新型工業(yè)化道路的戰(zhàn)略，中小企業(yè)信 息化得到前所未有的重視。然而，中小企業(yè)信息化的實踐表明，數(shù)以億計的信息化投資似乎并沒有帶來人們預(yù)期的收益。在中小企業(yè)信息化過程中還存在一些誤區(qū)， “信息化黑洞”、“上信息化項目是找死，不上是等死”等問題的出現(xiàn)，始終困擾著中小企業(yè)信息化的成功實施。為此，筆者總結(jié)了在中小企業(yè)選擇ERP的時候， 可以將以下內(nèi)容作為參考依據(jù)：

　　一、中小企業(yè)選擇ERP依據(jù)分析

　　依據(jù)一：ERP實施企業(yè)必須有準(zhǔn)確定位。ERP項目本質(zhì)上是一個管理項目，而不是純粹的IT項目，它的導(dǎo)入 和實施會涉及到企業(yè)管理的方方面面，需要對企業(yè)現(xiàn)有的管理模式、業(yè)務(wù)流程、作業(yè)方式和作業(yè)習(xí)慣進(jìn)行系統(tǒng)整合，以提高企業(yè)的管理水平和效率為不斷完善的主 線。因此，在ERP項目選型之前，企業(yè)一定要對ERP項目作一個明確和準(zhǔn)確的定位。一個正確的定位對項目選型乃至實施工作都可以起到極強(qiáng)的指導(dǎo)作用，直接 影響ERP項目的效果。

　　依據(jù)二：ERP上線時間必須明確。在選型之初，企業(yè)要對自身現(xiàn)狀進(jìn)行調(diào)查，了解企業(yè)的規(guī)模、人員素質(zhì)、管理 模式、信息化基礎(chǔ)等方面的情況，以明確信息化需求。中小企業(yè)具有一些共性，例如，管理基礎(chǔ)薄弱，業(yè)務(wù)流程和組織結(jié)構(gòu)都還需要不斷完善，企業(yè)的發(fā)展策略可能 會隨著市場的變化而不斷地調(diào)整;資金投入有限，可融入資金的渠道相對較少;沒有相對規(guī)范的業(yè)務(wù)流程;信息化基礎(chǔ)薄弱，在信息化建設(shè)方面投入的資金較少，有 經(jīng)驗的信息化建設(shè)人才更少。除此之外，不同企業(yè)有著各自不同的特點，在分析現(xiàn)狀時必須明確這些特點，挖掘自身不同于他人的需求，將這些作為確定ERP項目 是否上馬和確定系統(tǒng)類別及使用年限的重要依據(jù)。

　　依據(jù)三：將企業(yè)自身的發(fā)展規(guī)劃作為選型的依據(jù)。中小企業(yè)一般比較關(guān)注企業(yè)的當(dāng)前需求，比如一些急需改善的問 題、急需提高的效率等。這本身是沒有問題的，但是，相當(dāng)多數(shù)的企業(yè)忽略了企業(yè)長期的需求、今后可能出現(xiàn)的問題等，也就是說，對自身的信息化建設(shè)沒有一個通 盤的考慮，哪里有洞哪里補(bǔ)。這樣做可能很快就見到了效益，而且只付出了比較小的成本，但是卻為以后的信息化建設(shè)留下了隱患。今后隨之而來的，可能是企業(yè)使 用的系統(tǒng)越來越多，越來越雜，造成數(shù)據(jù)無法整體共享、系統(tǒng)重復(fù)建設(shè)等問題。

　　依據(jù)四：服務(wù)提供商的選擇。選擇專注于某個行業(yè)的中小服務(wù)提供商，實際看重的是其背后的專業(yè)化服務(wù)團(tuán)隊，在 這個團(tuán)隊中，包括了行業(yè)的管理咨詢專家、軟硬件工程技術(shù)人員等，他們能從專業(yè)的角度幫助用戶選型、分析、實施，乃至二次開發(fā)。因此，選擇有行業(yè)背景的中小 服務(wù)提供商即可以滿足企業(yè)的實際業(yè)務(wù)需求又可以節(jié)省ERP項目成本。

　　依據(jù)五：ERP項目實施預(yù)算是按時完成的關(guān)鍵。確定預(yù)算范圍是決定選型廣度的基礎(chǔ)。由于中小企業(yè)可融入資金 的渠道相對較少，因此，要注意根據(jù)自身財務(wù)狀況及ERP系統(tǒng)使用年限預(yù)期確定ERP項目預(yù)算框架，以保證項目順利進(jìn)行。ERP項目除了實際購買軟件和支付 實施顧問企業(yè)的費(fèi)用外，還需要考慮到很多的人力資源相關(guān)成本，如用戶保證項目參與時間引起的加人情況、項目加班等一系列費(fèi)用，這些都會對企業(yè)正常運(yùn)營情況 下的整體預(yù)算成本造成很大的壓力，因此，這些機(jī)動費(fèi)用必須考慮在項目預(yù)算中。充足的預(yù)算是保證ERP項目按時完成的關(guān)鍵。

　　依據(jù)六：企業(yè)內(nèi)部各部門的溝通必須充分。在選型前必須在企業(yè)中高層范圍內(nèi)進(jìn)行討論、確認(rèn)。溝通是非常重要 的，對于中小企業(yè)來說，大多中高層都是一個家族的成員，對于大項投資的金額、時間、回報率都是非常關(guān)注的，沒有大家的共識與參與，很容易導(dǎo)致選型成了單一 的選價格，那就失去了投資ERP項目的意義。選型溝通的另一個重點要選擇ERP產(chǎn)品和企業(yè)適用性一定要有良好的對接，ERP產(chǎn)品要在企業(yè)中應(yīng)用必須適合企 業(yè)的管理流程、管理需求，相當(dāng)一部分現(xiàn)有的軟件是不適合中小企業(yè)需求的，這就需要進(jìn)行流程再造，對于哪些管理流程需要調(diào)整和再造，也需要在選型前和管理層 進(jìn)行充分的溝通，取得一致意見，然后和服務(wù)提供商進(jìn)行商榷，進(jìn)行產(chǎn)品的升級或二次開發(fā)。

　　依據(jù)七：評價標(biāo)準(zhǔn)的設(shè)立是必要的。軟件產(chǎn)品的功能，即產(chǎn)品是否能滿足企業(yè)的實際業(yè)務(wù)的需求、滿足到那種程度，對于部分特殊的需求，是否有針對性的解決方案。大體上而言針對軟件產(chǎn)品有三個評價指標(biāo)：

　　第一、軟件產(chǎn)品的成熟度分析和了解。對于軟件產(chǎn)品的成熟度可以從供應(yīng)商的發(fā)展歷史、在行業(yè)內(nèi)擁有的客戶數(shù)量和客戶類型來考察。最好用公司的現(xiàn)有 業(yè)務(wù)數(shù)據(jù)對供應(yīng)商提供的演示版進(jìn)行數(shù)據(jù)測試，并且去供應(yīng)商以前客戶實地考察一下，了解其實施的背景、基礎(chǔ)、過程、遇到的問題以及目前的運(yùn)行狀況、適用性及 穩(wěn)定性等情況。將這些資料綜合作為考察產(chǎn)品成熟度的標(biāo)準(zhǔn)。

　第二、軟件產(chǎn)品的人性化程度分析和了解。軟件產(chǎn)品的人性化程序主要指界面的友好性，可操作性。如視窗操作，圖形化的功能界面(圖形化的業(yè)務(wù)流程、 查詢系統(tǒng)等)，與桌面主要應(yīng)用系統(tǒng)的集成(如：與Office系統(tǒng)的集成等)，簡便的界面和菜單功能設(shè)計，界面操作直觀、簡單，符合現(xiàn)有的系統(tǒng)操作習(xí)慣， 不需要額外增加軟件學(xué)習(xí)成本。

　　第三、軟件產(chǎn)品的擴(kuò)展性分析和了解。軟件產(chǎn)品的擴(kuò)展性主要體現(xiàn)在兩個方面：第一,與其他軟件系統(tǒng)的集成，在采用現(xiàn)有解決方案的基礎(chǔ)上，企業(yè)可很 容易的擴(kuò)展到電子商務(wù)、辦公自動化、客戶關(guān)系管理、供應(yīng)鏈管理等系統(tǒng)，并且所有這些解決方案都是無縫集成的。第二,系統(tǒng)的二次開發(fā)，在項目實施和運(yùn)行的過 程中，可以對現(xiàn)有的系統(tǒng)進(jìn)行功能完善，能否提供穩(wěn)定可靠的二次開發(fā)能力是軟件產(chǎn)品是否成熟的關(guān)鍵因素之一。

　　依據(jù)八：對ERP提供商技術(shù)實力和服務(wù)水平設(shè)立評價標(biāo)準(zhǔn)。服務(wù)提供商的技術(shù)實力和服務(wù)水平也會影響到ERP項目的成功與否。服務(wù)提供商能夠為企業(yè)提供什么樣的技術(shù)保障，是否有完善的售后服務(wù)體系等。大體上而言針對服務(wù)提供商有以下三個評價指標(biāo)：

　　第一、服務(wù)提供商的行業(yè)經(jīng)驗。供應(yīng)商目前實施的客戶中與本公司生產(chǎn)和業(yè)務(wù)管理以及實施基礎(chǔ)等方面是否有相似的類型，這可以為企業(yè)ERP項目導(dǎo)入上的成功提供強(qiáng)有力的支持。

　　第二、服務(wù)提供商的實施力量。作一個管理項目，實施顧問的管理背景和合理的知識結(jié)構(gòu)、豐富的項目經(jīng)驗非常重要。企業(yè)實施顧問應(yīng)具備企業(yè)一線管理 的經(jīng)驗，對企業(yè)的業(yè)務(wù)和管理運(yùn)作非常熟悉，有過在類似公司的任職的經(jīng)歷以及多年的ERP項目實施經(jīng)驗等。而不能是以IT背景人員作為實施的主要力量。

　　第三、ERP軟件系統(tǒng)的實施方法及文檔管理規(guī)范。服務(wù)提供商是否能夠提供完整的實施方法論體系，作為雙方項目導(dǎo)入和實施工作的指導(dǎo)。好的系統(tǒng)必須要在科學(xué)的方法論體系的指導(dǎo)下實施才有可能取得真正的成功。

　　系統(tǒng)的文檔建立和保存是整個項目成功的保障。通過科學(xué)嚴(yán)密的文檔控制系統(tǒng)，不僅可以很好保證實施效果，而且即使公司出現(xiàn)人員調(diào)整，通過有關(guān)實施 文檔紀(jì)錄，新員工也可很快熟悉有關(guān)業(yè)務(wù)操作流程，降低人員培訓(xùn)成本和系統(tǒng)運(yùn)行的風(fēng)險。在項目實施的過程中，供應(yīng)商是否有能力協(xié)助企業(yè)編制產(chǎn)品編碼系統(tǒng)、業(yè) 務(wù)科目技術(shù)文檔，以及各種嚴(yán)密的實施過程控制文檔(如細(xì)化的項目實施計劃、實施服務(wù)意見反饋調(diào)查表、階段性的實施服務(wù)報告等)，細(xì)化的崗位業(yè)務(wù)操作流程、 業(yè)務(wù)改進(jìn)報告等。

　　以下將列舉一些在中小企業(yè)選型過程中普遍存在的誤區(qū)，希望引起實施企業(yè)的注意：

　　首先、制定ERP項目的目標(biāo)時，目標(biāo)過高，ERP實施范圍的范圍過大，脫離企業(yè)的實際業(yè)務(wù)情況和現(xiàn)有資源。對企業(yè)內(nèi)部的現(xiàn)有資源缺乏客觀的評價，盲目上馬。

　　其次、整個選型過程由IT技術(shù)部門負(fù)責(zé)，以計算機(jī)技術(shù)人員為主導(dǎo)，業(yè)務(wù)部門不參與選型。在實際環(huán)境中，各個部門的業(yè)務(wù)都很繁雜，ERP的應(yīng)用本 身就是與各個部門密切相關(guān)的工作，別人不了解你的業(yè)務(wù)，也無法替你發(fā)表意見，只有親自參加選型過程，才能充分理解所要選擇的ERP系統(tǒng)，使本部門的業(yè)務(wù)需 求得到滿足。

　　第三、迷信國外的服務(wù)提供商產(chǎn)品，造成產(chǎn)品的水土不服。不對軟件產(chǎn)品進(jìn)行功能性測試，只相信典型用戶的參觀效果。在一個公司成功的ERP軟件，拿到另一個公司未必成功，在一個企業(yè)失敗的ERP系統(tǒng)，換另一個企業(yè)則可能成功。

　　第四、過于相信供應(yīng)商的承諾，決不能把承諾作為系統(tǒng)建設(shè)的一部分，也就是說不能把系統(tǒng)建立在任何承諾之上，謹(jǐn)慎的做法，就是把承諾當(dāng)作不存在來進(jìn)行系統(tǒng)的選型和實施。

　　最后、過于追求新技術(shù)，ERP是基于軟件技術(shù)的商品，但它的目標(biāo)是進(jìn)行業(yè)務(wù)管理，不是為了實現(xiàn)某項技術(shù)。有的企業(yè)在選型的時候過分注重ERP軟件的技術(shù)基礎(chǔ)，要求必須采用B/S方式、必須跨平臺等等，這犯了本末倒置的錯誤。

　　總而言之，ERP項目成功的關(guān)鍵在于企業(yè)要有較為明確的實施目標(biāo)以及遠(yuǎn)景規(guī)劃，從管理的角度來組織，而不是簡單的軟件采購行為。對于國內(nèi)大多數(shù) 中小型民營企業(yè)來說，由于資源、經(jīng)驗?zāi)酥琳J(rèn)識的不足，要做到一步到位絕非易事，因此必須從企業(yè)高層給予足夠的重視與支持，這是ERP項目成功實施的關(guān)鍵。

　　二、中小企業(yè)選擇ERP注意事項分析

　　第一、分析和規(guī)劃自身企業(yè)信息化建設(shè)的需求。在選擇ERP軟件之前，企業(yè)必須首先明確自己的需求，也就是企業(yè)實現(xiàn)信息化要解決什么問題。當(dāng)前， 很多企業(yè)還是處在傳統(tǒng)的手工管理模式，還處在由計劃經(jīng)濟(jì)向市場經(jīng)濟(jì)轉(zhuǎn)換的過渡階段，企業(yè)管理有很多不足和缺陷。解決這些問題，正是引進(jìn)ERP系統(tǒng)的主要目 的。因此，企業(yè)在購買ERP軟件之前，必須對自身的管理進(jìn)行診斷和冷靜的思考。在對現(xiàn)狀進(jìn)行認(rèn)真分析的基礎(chǔ)上，做好企業(yè)信息化建設(shè)的規(guī)劃，在規(guī)劃中確定管 理信息系統(tǒng)建設(shè)的目標(biāo)，系統(tǒng)涉及的范圍，要解決的關(guān)鍵問題，系統(tǒng)建設(shè)的階段劃分和進(jìn)度要求，并對企業(yè)在現(xiàn)行條件下可投入的人力、物力、財力進(jìn)行可行性分 析。

　在此基礎(chǔ)上提出ERP軟件選型的需`求任務(wù)書，提供給ERP服務(wù)提供商，作為軟件選型的依據(jù)。這種信息化建設(shè)的前期規(guī)劃是非常重要的，它將成為企 業(yè)信息化建設(shè)全過程的指導(dǎo)性文件，是各階段實施工作的依據(jù)。“規(guī)劃”的正確性是非常重要的。“規(guī)劃”既要保持一定的先進(jìn)性，又要具有實用性。因此，“規(guī) 劃”的編制是一件非常重要和嚴(yán)肅的事。企業(yè)決策層要領(lǐng)導(dǎo)和參與此事，并抽調(diào)各部門的領(lǐng)導(dǎo)和業(yè)務(wù)骨干及信息化技術(shù)人員組成專門小組。如果企業(yè)缺乏對ERP了 解的人員，可以聘請社會上專業(yè)的IT咨詢專家參與此項工作。

　　第二、功能是否滿足企業(yè)自身的需求。在明確了企業(yè)的需求以后，使軟件的選擇有了依據(jù)。選擇的ERP軟件的功能與企業(yè)的需求相符合，是ERP軟件 實施成功的關(guān)鍵因素。當(dāng)前，在國內(nèi)ERP軟件市場上，ERP商品化軟件種類繁多，令人眼花繚亂。有些大型ERP軟件(特別是一些國外著明的ERP軟件公 司)，具有強(qiáng)大的功能，能較好地適合各類企業(yè)的需求。但是由于種種原因，不是所有的企業(yè)都能購買這些大型ERP軟件。

　　特別是占企業(yè)總數(shù)中絕大多數(shù)的中小企業(yè)，由于規(guī)模小、財力有限等原因，只能在國內(nèi)ERP市場上選擇那些中小型ERP軟件。這些軟件雖然都冠以 ERP的牌號，但由于軟件開發(fā)商的歷史、技術(shù)背景、應(yīng)用的程度、投入的力度等的差別很大，軟件功能和性能上的差異也很大。因此，企業(yè)在選擇這些軟件時，不 能僅僅停留在表面上，被口頭上的宣傳所迷惑，要對軟件的功能結(jié)構(gòu)進(jìn)行認(rèn)真地研究和考查。

　　例如對制造業(yè)企業(yè)來說，首先要考慮軟件是否適合自己企業(yè)的生產(chǎn)類型。大家都知道，制造業(yè)的生產(chǎn)類型可分兩大類：離散制造業(yè)和流程制造業(yè)。在離散 制造生產(chǎn)類型中，又可分為三種類型：多品種小批量生產(chǎn)、大批量流水生產(chǎn)、單件小批生產(chǎn)。這些不同的生產(chǎn)類型有著完全不同的生產(chǎn)模式(不同的生產(chǎn)流程、生產(chǎn) 計劃方式、生產(chǎn)組織和控制方式等)。

　　對應(yīng)不同生產(chǎn)類型，ERP軟件將提供不同的生產(chǎn)管理解決方案相適應(yīng)。多品種小批量生產(chǎn)類型適用MRPII/ERP傳統(tǒng)的生產(chǎn)計劃與控制功能，既 由主生產(chǎn)計劃(MPS)—物料需求計劃(MRP)—車間任務(wù)與作業(yè)管理組成的三級管理體系，生產(chǎn)管理系統(tǒng)的核心是物料需求計劃模塊，它將按零件提前期和相 適應(yīng)的批量準(zhǔn)則，組織零部件的生產(chǎn)和采購。因此，這類生產(chǎn)類型的企業(yè)在購買ERP軟件時，要仔細(xì)考察軟件是否具備以上提出的功能。特別是第三級計劃—車間 生產(chǎn)作業(yè)(工序級)計劃的功能，由于其數(shù)學(xué)模型比較復(fù)雜，實施難度比較大。

　　有些軟件此模塊的功能比較弱，甚至有些軟件根本就沒有此功能;對于大批量流水生產(chǎn)類型，在ERP軟件系統(tǒng)中，最適合的生產(chǎn)管理解決方案是MRP/JIT混 合生產(chǎn)管理模式。在此方案中，零部件的生產(chǎn)準(zhǔn)備計劃和原材料的采購計劃是由MPS—MRP系統(tǒng)去解決，而車間生產(chǎn)管理則采用按訂單拉動的準(zhǔn)時生產(chǎn) (JIT)管理系統(tǒng)來完成。JIT準(zhǔn)時生產(chǎn)管理系統(tǒng)遵循市場和訂單拉動機(jī)制，真正做到按需生產(chǎn)。JIT的計劃模式是按節(jié)拍生產(chǎn)的流水線生產(chǎn)計劃。

　　在當(dāng)前市場上的一些中小型ERP軟件，JIT功能很弱，甚至缺乏此功能;對于單件和小批量生產(chǎn)類型的企業(yè)，一般是按客戶訂單來組織生產(chǎn)，按訂單 的要求制造或裝配，甚至是按客戶的要求進(jìn)行重新設(shè)計或改動產(chǎn)品。這種生產(chǎn)類型的關(guān)鍵是如何快速地按客戶的個性化需求生產(chǎn)出客戶需要的產(chǎn)品。為做到這一點， 要求ERP系統(tǒng)具有快速將客戶對產(chǎn)品的技術(shù)要求轉(zhuǎn)化為基礎(chǔ)制造數(shù)據(jù)的功能，自動生成針對客戶訂單個性化要求的制造數(shù)據(jù)，如訂單產(chǎn)品結(jié)購數(shù)據(jù)(OBOM)和 訂單工藝路線數(shù)據(jù)等。在ERP商品化軟件中，這些功能通常是由配置控制模塊完成的。也可采用與ERP緊密集成PDM軟件來完成。因此，這類企業(yè)在購買ERP軟件前，要很好地研究著些瓶頸問題的解決方案，有針對性地考察ERP軟件。

　　綜上所述，要避免ERP軟件選擇方面的風(fēng)險，企業(yè)必須做好需求分析，找到自己的特點和關(guān)鍵問題，做到心中有數(shù)。這樣才能有針對性地考察軟件，選準(zhǔn)軟件，減少由于軟件與企業(yè)不匹配而造系統(tǒng)實施的失敗。

　　第三、考察并評估ERP的成熟度。ERP軟件包是一個大型的、復(fù)雜的軟件，程序中的關(guān)聯(lián)錯綜復(fù)雜。任何一個軟件包都不可避免地存在著缺陷和錯 誤，只是程度的不同。企業(yè)應(yīng)用ERP能否順利地取得成功，與ERP軟件的質(zhì)量和軟件的可靠性有很大的關(guān)系。因此，企業(yè)在選擇ERP軟件的時侯，要認(rèn)真考慮 該軟件是否成熟可靠，這是企業(yè)選擇ERP軟件的一個重要標(biāo)準(zhǔn)。

　　ERP是一個管理應(yīng)用軟件，它的成熟度自然與它在企業(yè)實際應(yīng)用的程度有關(guān)。ERP軟件在開發(fā)成功以后，除了要經(jīng)過嚴(yán)格的試驗室測試以外，更重要 的是要經(jīng)過在企業(yè)中的反復(fù)應(yīng)用的過程中進(jìn)行不斷的磨練，通過對錯誤和缺陷的不斷修改和補(bǔ)充，使軟件的可靠性和成熟度不斷得到提高。試驗室測試通是常通過人 為設(shè)計的程序和模擬數(shù)據(jù)進(jìn)行的，具有一定的局限定性。而在企業(yè)現(xiàn)場中的實際應(yīng)用，軟件會經(jīng)受到大量的實際數(shù)據(jù)和復(fù)雜的業(yè)務(wù)流程的考驗，這是試驗室條件不能 比擬的。所以，企業(yè)在選擇ERP軟件時，必需考查該軟件公司的歷史和經(jīng)歷，考查該軟件包的形成和發(fā)展過程，以及應(yīng)用的客戶數(shù)和應(yīng)用效果的評價，并且考查該 軟件商軟件版本維護(hù)的機(jī)制。一般來講，通過大量客戶工程化考驗軟件的質(zhì)量和可靠性要高一些，企業(yè)要盡量避免成為不成熟產(chǎn)品的試驗場。

　　第四、考察服務(wù)提供商的實施經(jīng)驗和能力。企業(yè)要想成功實施ERP系統(tǒng)，在選擇ERP服務(wù)提供商時除了要認(rèn)真考察該公司提供的ERP軟件產(chǎn)品，還 要重視對該公司實施ERP能力和經(jīng)驗的考察。由于ERP系統(tǒng)的復(fù)雜性，在實施的過程中牽涉面大，要比其它的應(yīng)用軟件實施起來困難得多。

　　同時，ERP系統(tǒng)涉及的新知識和新技術(shù)較多，特別對我國企業(yè)來說，ERP屬于新生事物，企業(yè)中缺乏ERP的專業(yè)人才。因此，在實施過程中需要 ERP提供商在技術(shù)上的大力支持，特別是對ERP項目的組織和實施技術(shù)更為重要。為做到這一點，大型的ERP供應(yīng)商(特別是國外公司)，一般都有若干專業(yè) 的咨詢公司為該軟件做專門的咨詢和實施服務(wù)，但對我國大多數(shù)的中小型ERP軟件公司來說當(dāng)前還做不到這一點。因此，要求這些公司不但提供ERP軟件產(chǎn)品還 必須具有ERP咨詢和實施服務(wù)的能力。企業(yè)在尋找ERP建設(shè)的合作伙伴時，不但要求其軟件好，要更關(guān)注該公司是否具備較強(qiáng)的咨詢和實施力量，還要考查該公 司咨詢實施的經(jīng)歷和業(yè)績。

　　ERP系統(tǒng)的實施也可以說是一種藝術(shù)，管理咨詢和實施服務(wù)人員對ERP系統(tǒng)的經(jīng)驗和對企業(yè)現(xiàn)場管理的理解程度，對ERP實施有著重要的影響。 ERP是一個巨大的知識寶庫，如何把這些豐富的功能，結(jié)合企業(yè)管理現(xiàn)場的實際充分地加以運(yùn)用起來，就會取得可喜的效果。這正如醫(yī)生看病一樣，一個優(yōu)秀的醫(yī) 生如果只有醫(yī)學(xué)理論知識是不夠的，還要有大量的臨床經(jīng)驗。醫(yī)生的經(jīng)驗越多，他為病人的診斷就越準(zhǔn)確，治療方就案就越有針對性，治療效果就越好。同樣的道 理，在ERP系統(tǒng)實施的過程中，只有具有豐富咨詢和實施經(jīng)驗的專家，才能為企業(yè)現(xiàn)行管理做出確切而中肯的診斷，才能提出優(yōu)秀的解決方案，才能成功地進(jìn)行系 統(tǒng)實施。

　　因此，企業(yè)在選擇ERP合作伙伴時，要特別重視對實施經(jīng)驗和效果的考查，要走訪該公司的成功和失敗的客戶，多聽聽客戶的反映，吸取其成功的經(jīng)驗和總結(jié)失敗的教訓(xùn)，保證ERP實施成功。

　　第五、ERP的選型就是選擇其實際功能。由于我國ERP的開發(fā)與應(yīng)用還在初級階段，國內(nèi)市場上銷售的ERP軟件產(chǎn)品在功能上和各功能解決問題的深度上都有很大差別。一般來看，MRPII系統(tǒng)的傳統(tǒng)功能，如進(jìn)銷存、財務(wù)、生產(chǎn)等各軟件都比較完整。

　　但在新發(fā)展起來的一些ERP功能，如JIT、CRM、SCM、DSS 等，或者缺乏，或者功能不完善。這可能是由于某些軟件商的開發(fā)歷史較短，應(yīng)用的經(jīng)驗不足;同時，也由于ERP的這些新功能目前還缺乏通用的標(biāo)準(zhǔn)，這樣必然 引起ERP軟件商在定義這些新功能時的混亂。因此，為企業(yè)選擇這些功能時造成很大困難。在選擇這些功能時，不要只看表面，要看該模塊實際上能解決什么問 題，特別是能否解決企業(yè)需要解決的問題。例如，決策支持是ERP系統(tǒng)“能動性”功能之一。在傳統(tǒng)MRPII的決策是面向結(jié)構(gòu)化問題的決策，它所解決問題的 決策過程的環(huán)境和原則是能用明確的語言描述的。而在ERP中決策支持功能增加了新內(nèi)容，它要求對企業(yè)經(jīng)營管理中大量的非結(jié)構(gòu)化和半結(jié)構(gòu)化的決策問題提供解 決方案。如新產(chǎn)品開發(fā)、投資決策、企業(yè)并購等決策。

　　為此，企業(yè)在選擇和評價ERP軟件的決策功能時，不能只從該功能的表面上看，而首先要確認(rèn)企業(yè)所需決策問題的框架，進(jìn)而檢查軟件提供的決策功能能否解決這些問題。其它的功能如JIT、CRM、SCM等 在各ERP軟件提供的功能也存在很大差異，企業(yè)同樣要給予注意。但是，更重要的一點，企業(yè)在考查這些軟件功能的時侯，千萬不要忽視該軟件商實施這些軟件的 經(jīng)驗和這些模塊應(yīng)用的效果。有些服務(wù)提供商在功能清單上雖然也列出了這些模塊的介紹，但并沒有在客戶現(xiàn)場中應(yīng)用，技術(shù)服務(wù)人員對這些模塊的理解還局限在概 念上，對這些新興功能在企業(yè)現(xiàn)場應(yīng)用缺乏實踐經(jīng)驗。這對該系統(tǒng)成功實施造成一定困難。

　　總結(jié)

　　因此，對于中國數(shù)量眾多的中小企業(yè)而言，在ERP系統(tǒng)應(yīng)用方面需要進(jìn)一步加深對信息化應(yīng)用的理解，需要更多地深入應(yīng)用而非停滯于徘徊中，尤其是 已經(jīng)進(jìn)入應(yīng)用階段的企業(yè)，更需要在長期的實際應(yīng)用中去挖掘系統(tǒng)的價值。此外，在ERP系統(tǒng)的選擇過程中，應(yīng)該多學(xué)習(xí)國際經(jīng)驗，建立科學(xué)的產(chǎn)品選擇觀。

　　在實施ERP系統(tǒng)的選型的階段應(yīng)該運(yùn)用SWOT的分析方法進(jìn)行對企業(yè)自身的優(yōu)劣勢、面對外界的機(jī)遇挑戰(zhàn)進(jìn)行分析，通過對自身人員、制度、技術(shù)、 資金、文化、實施前景等方面的詳盡的分析，形成科學(xué)的預(yù)測分析。這樣，才能夠盡可能多地避免面對以后企業(yè)實施ERP的過程中出現(xiàn)的各種困難，保證ERP的 順利實施。

標(biāo)簽: ERP, 信息化, 中小企業(yè), 技術(shù)趨勢