webMethods Modeler 中 Join Type 的設定

為什麼我建置的 Model 沒辦法被起動？
記得我剛開始在開發 RosettaNet 的時候，時常發生一個問題，就是當我收到一份 Document 的時候，我的 Model 卻沒有跑，然後，我檢查 Lo g的時候，看到 Log 的訊息是 “*** MODEL IS INACTIVE ***” “cannot create new instance of P54FJNQEBNZJ”，當時我第一個想法就是我的 Model 可能設錯了，於是我將原有的 Model 給刪除，然後再重新 Create 一個新的，但仍無法解決我的問題，還是一樣發生同樣的事情，其實後來才發現這個問題不難解決，只是一個簡單的設定而已。
那麼為什麼會發生上面的訊息呢？你可以進你的 Developer 的環境去執行 “wm.prt.debug:getModelIndex” 你就會發現到，你有部份的 Model 是重覆，但是狀態卻是 “INACTIVE” ，這個原因並不是一個 “Error” ，只代表你這一個 Model 被你從 Monitor Delete 而已。但當你接收到一份 Documents 的時候，原本被你刪除的 Model 剛好附合被趨動的條件，但這一個 Model 卻是被 Inactive ，所以才會出現 “*** MODEL IS INACTIVE ***” 的訊息。至於我真正要被趨動的 Model 為什麼沒有被趨動呢？其設定更改如下就可以了！
當你會發生這個原因，大部份是你的 Model 附合以下的條件：
　　1. 你的 RN 是屬於 Receiver 端，所以你等待的是一份外部的 Document 。
　　2. 這一個 Model 是拿原始的 Model 來更改的
　　3. 你在 TN Console 中的 Transaction 看得到此筆 Transaction ( Document )
若你附合以上的條件，那麼請您就做以下的操作：
　　1. 打開你的 Model ，並且打開第一個Step（Wait for……）的 Properties 。
　　　　
　　2. 在 Properties 中會看到 “Join Type” 的內容是 “Complex” ，請你把該選項下拉後，再選一次。
　　
　　3. 你會看到類似下面的畫面，在 “Transition/Subscriptions” 重新選擇你所要 Wait 的 Document。
　　

　　
　　
　 4. 存檔後，重新產生即可。
就依據上面的幾個動作就可以囉！

我不希望我Filepolling使用Multiple Threads

在敘述問題前，先感謝Calista, Rich, Sandra, Ls 等人的協助，希望下次有機會能再到你們公司拜訪囉^^

有個 webMethods 的朋友，前幾天問我一個 Filepolling 的問題，說實在的，雖然我 Filepolling 已經用了一段時間，但還沒有遇到跟他類似的需求，所以我想了一下，想出了一個爛的解決方法，不過此方法卻沒有解決他的問題，我先把他的需求簡單的描述一下。

“……在所 Filepolling 的 Folder ，要他以一筆一筆的方式來處理該檔案，此檔案是，當該檔案還沒有處理完畢時，不能處理下一筆檔案，但 webMethods 是 Multiple Thread 的方式，雖然他可以依順序來處理檔案，但若第一筆的資料比較多，第二筆的資料比較少的時候，有可能發生第二筆處理完畢後，第一筆才處理完，但我希望的是第一筆處理完，再處理第二筆……”

雖然我沒遇到這個 Case ，不過我想這應該不難吧，弄一個 Q DB 就可以搞定這一個 Case 才是，所以我就決定下面的做法：

流程序述：
1. 產生的檔案的檔名請依時間命名
2. Fillpolling 取得到檔案時，將檔名存放於DB中，內容暫不處理
3. 每三十秒執行一次Schedule Seriver, 此Service是去Q DB取得第一筆Record，此記錄應該為最舊尚未處理的檔案，當處理完畢後，將此Record刪除，所排定的Schedule請勾選Repeat from end of invocation 選項，可避免後來先處理的情形。

過沒多久對方跟我說，並沒有解決他們目前的問題， “……因為在這一個Case 裡,我們除了要讓 wM 依照順序丟出 Data 給 ERP 後端程式外,還希望控制到等ERP 後端程式處理完後再丟出 Data 給 ERP ……” 。顯然地，我的解決方法並沒有未他們解決這一個問題，不過他們卻跟我說有一個設定可以解決這一個問題， “……後來我們發現 wM 的 FilePooing 的機制設定中,有個 Maximum Number of Invocation Threads 這個設定 (設定為1)可以解除我們目前遇到問題……”。

我後來查了一下文件，這一個設定是可以允許你這一個 Filepolling 一次可以有多少個 Threads ，他的範圍從 1 ~ 10 ，因為我平常都不做這一個設定，所以也沒去注意到，而他的 Default 是 10 ，所以當你不去做設定時，他就是以 Multiple Threads 的方式來處理。

後記~~我想解決問題的方法，應該是先找有沒有相關的文件或案例，若找不到相關的資料再進行天馬行空會比較好，免得臭大了。

WCM Overview (1)

　　今天開始學習新的工具 WCM (Web Content Management)，這是一套由 IBM 所提供的網頁上下稿工具，之後我會將這些學習筆記，記錄在此。

　　什麼是 WCM 呢，用一個簡單的方式來說明，就是我現在用的 MSN Space 就是一個簡單的WCM。有了MSN Space 及 Blogger 之後，我們寫網頁就簡單多了，只要把我們想要寫的東西寫在網頁上，然後再將一些圖片給上傳，包括了字體、字型及文字大小，都可以利用簡單的 tool bar 來達成，只不過今天 IBM 的 WCM 還多了很多的 Feature 以及多國語言的支援，還有簡單的流程管理，還有呀，還可以跟Dreamweaver 結合哦！

　　今天讀的不多，不過我就將今天讀的東西做一個簡單的整理。
　　WCM 提供了幾個工具可以讓你來管理你網頁的建立、簽核以及發佈。

1. Authoring Templates
   嗯～～這個工具我不太清楚怎麼用，不過它是寫說，他可以跟一個叫做 "Presentation Templates" 的工具一起合用，可讓你的網頁風格一至性
2. Workflow and Security
   你的每一個網頁都可以藉用一個簡易的簽核流程來決定你這一頁面是否可以創建。例如一些新聞稿在發佈前，必需經由公關經理及總經理的核准才可發佈。
3. Scheduled Publishing and Expiring
   你的網頁還可以設定日期，在該日期區間此網頁才會呈現。例如我們可以做一個產品促銷的網頁，在產品促銷期間讓它呈現出來，過了產品促銷期之後，讓此網頁"自動"關閉。
4. Authoring Environments
   可以結合 Dreamweaver ，讓網頁開發人員開發完網頁後，就可以自動發佈在 WCM 上，只要在你的 Dreamweaver 上安裝一個 Plug-In 就可以了
   
   
   

Processing Rules實作（一）

案例
　　我有一台webMethods Server上面運行EDI也有一段時間了，我當時也購買了五個 webMethods Partner 的License ，想說可以給我的 Partner 使用，不過最近我其它在國外的子公司也想導入，但我的 Partner License 只能連總公司，那我要怎麼做比較好。
　　在不久前我有聽過有”類似”這一方面的需求，雖然我不知道這是不是大部份的公司所面臨到的問題，不過 webMethods 的 Processing Rules 應該可以符合這個需求，實作起來還蠻簡單的，以下我就舉一個案例來做簡單的步驟說明，若有不當的，還請多指教囉！
　　情境：
　　我的公司名稱為 Julian Company ，另有有二間子公司各為 Julian UB1 及 Julian UB2 ，他們的客戶 Customer1 在以前傳送 Invoice 都是經由傳真的方式給我的子公司，但現在想利用 EDI 的方式來傳送，選擇的標準為 EDIFACT 版本為 96B ，訊息名稱是 INVOIC ，所以我將以 Julian Company 做為公司的 Hub ，然後依據資料內容傳送給不同的子公司 UB1 或 UB2 。
　　方法：
　　1. Install TN Document Type
　　　　進到 http://localhost:5555/WmEDI/ 的畫面，然後到 Doc Exchange 的 Install TN Document type ，在右側處選擇 Standard 為UN/EDIFACT 、 Version 為 96B 、 Transaction Set 為 INVOIC ，

　　　　選完後，請按 "Add Document Type Definition to Trading Network" 。這個時候就能在 TN Console 中 Document Type 看到 UNEDIFACT 96B 的 Document 。

　　2. 撰寫 Route EDI 的 service
　　　　 當我們收到 EDI 資料時，分辨出他的 Receiver 後，接下來就是轉傳給他的真正的 Receiver 而不是 HUB ，所以我們必需要寫一個簡單的 service 來做一個轉傳的動作。除此之外，在我們收到 EDI 當時， TN Console 上的 Transaction 中的 User Status 會顯示為 "IGNORED" ，在這一個 case 裡，我希望當他轉傳成功能，能變為 "DONE" ，這一個 server 的簡易寫法如下：

（可 下載 此service範例）

　　3. 訂定 Route EDI 的 Processing Rule
　　　　 訂定這一個 Processing Rule 的目的是為了將收到的 EDI 交由我們剛剛所設定的 Service 處理，此設定如下：
　　　　i. 打開 TN Console 並到 Processing Rules ，選擇 Last Tab 並按 "Above" ， Processing Rule 的 Name 設定為 "EDI Processing Rule" 。

　　　　ii. 在 Criteria Tab 中設定 Sender Name 為 "Customer1" ， Document Type 為 "UNEDIFACT Envelop" ，於 Action Tab 中設定 Execute a service ，並選擇我們剛剛所撰寫的 Service 。

此 Processing Rule 就算是設定完成。（此 Processing Rule 可 下載 ）

　　4. 進行測試
　　　　 將我們要測試的EDI資料透由http://server:port/WmEDI 傳到 http://server:port/invoke/wm.tn/receive 即可。
　　　　 注意：請用二台機器做對傳，若僅有一台機器 Processing Rules 會出現 Loop 狀況。

EDI Modeler Design實例運用（一）

前言

大部份的人除了公司有拿 webMethods 來做 EAI 的事項外，其餘的應該很少有用到 Modeler 功能，我以一個目前實際的例子來引導出 Modeler Implementation 的概念，不過， Modeler 的用法跟目的，是見人見智啦，在這邊只是用一個簡單的例子來說明而已，所以不要太介意或太在乎我的做法，畢竟每個人的想法不一樣，所以做出來的東西也不一樣，就像寫程式一樣，一個九九乘法表的程式，每個人寫出來的，也不盡相同。
範例：一個 Inbound EDI 的流程，當我收到一個 EDI 的檔案時，進行資料驗證後，將資料傳送到資料庫中，若其中的過程有問題，則必需要做 Error Handle ，並且發生 Email 通知相關人員。
這個範例，其實也可以經驗 Processing Rules 來完成，反而簡單又快速，不過，我以 Modeler 的方式，是為了能運用 Modeler 用法，並且能使用 Monitor ，來方便管理及監控我的 Process 。其步驟如下：
　　1. 繪製 EDI Inbound Process

注意到，左右這二塊是跟中間這一塊的顏色不一樣，而且連接的線，是以虛線來表示，跟其它的實線不一樣，其原因在於左右這二塊是屬於External Group，External Group中的Step不會程生於程式當中，純粹只是流程的表示而已，最重要的是我們中間白色的這一塊，這是webMethods實際運作流程。
注意：藍色跟紅色線的差別是在於Step處理的結果，若此Step處理失敗則會走紅色路線，若成功則走藍色路線，只要設定Line的Properties即可。

　　２. 當有 Join Step 的時候，必需要設定 Join 的條件

流程中的 Handle Error Step ，有三條 Line 都指定此 Step ，此時我們必需設定 Join Type ，否則在 Process Validate 的時候，會發生無法驗證的錯誤。

　　3. 設定 Folder 以及 Package 的位置

雖然當我們的流程產生出來後， Modeler 會自動幫我們產生 Folder 以及 Package ，但為了管理方便，我們也可以自行指定我們要產生的 Package Name 以及 Folder Name ，只需要在 Properties 中設定即可。

　　4. 定義被啟動的文件及條件
　　幾乎每一個 Modeler 都是被一個 Document 所啟動的，也就是說，若我們所畫的 Modeler ，是要被啟動的一個 Process ，那們我們就得設定他所等待的 Document ，以及此文件所等待的條件，在此範例中，我的條件是設定此份的 EDI 的 User Status 及 Sender ，當符合我所設定的條件時，就會啟動此流程。

　　5. 選擇要Invoke的Service

在開發這一個 Modeler 之前，我已經開發完所相對應的 Service 了，所以接下來，我只需要指定我所開發出來的 Service 即可。不過有的人是習慣先畫完流程再寫 Service ，我想這應該沒有一定的規則吧，應該是看每個人的開發邏輯跟方式而定。







　　6. 驗證、產生、上傳流程
整個Modeler算是開發完畢，接下來只需要幾個按紐即可搞定，這其中包括：
Validate Business Process：驗證一下我畫出來的圖是否正確，如果有不對的，他會有Error Message產生，再依照所指定的錯誤去更改就好了。
Generate Business Process：產生你的 Business Process ，產生完畢後，你可以用 Developer 去看看有沒有什麼變化，這時，你應該會看到會產生一個 Package 出來，而這個 Package 的名稱，應該是你之前所指定的名稱。
Update Model for Monitoring：當你完成後，你就會在你的 Monitor 的管理畫面看到這一個 Model 的名字啦， Monitor 的管理畫面在哪呢？打開你的瀏灠器，並在網址列打上 webMethods 的位置及 Port Number 後面再加上 /WmMonitor/ 即可。
最後別忘了，把這一個 Model 給 Enable ，即可使用啦。

我們提供 B2Bi & EAI 解決方案

在多變的競爭環境，整合企業內部系統以達到跨部門跨組織並整合上下游供應商，組成完整的供應鏈，已是企業已不可獲缺。讓企業提昇競爭力及客戶服務，使企業提高獲利速度。

企業目前所面臨 IT 平台整合的困境

繁亂無章的系統要進行整合

今天企業內部面臨龐大企業整合的壓力，各系統之 間不僅僅只是做單純的資料交換而已，更需要有整 合的統一標準、細緻的流程控管並且更有彈性的變 化來因應各種不同的需求及變更。
一個看似簡單的 系統整合，卻要橫跨三個以上不同 的系統，以傳統的做法，可能是以資料庫整合的模 式，來整合各個不同的系統，但此種模式並非合適 的方式，那我們遇到整合性的問題，該如何來解決？在此webMethods提供一個良好的整合解決方案。

webMethods (NASDAQ: WEBM)

webMethods為美國一間上市公司，所提供的Solution為解決公司內部系統整合及外部B2B整合的解決方案供應商，其Solution名稱與公司稱webMethods同名，所服務的客戶含蓋全球，包括知名的AT&T、SONY、Panasnic、3M、台積電、聯電等等世界名大廠，其Solution能輕易且快速的整合企業各種不同平台系統及經由RosettaNet、ebXML或是EDI的方式整合企業供應商系統，以達到水平及垂直性的供鏈管理。（其公司網站為http://www.webMethods.com）

webMethods 所提供的整合機制

webMethods提供一整合性服務平台來整合個各系統
企業內部，擁有不同的應用系統、不同的應用系統上又有不同的Function，以及外部不同的Partner，webMethods以服務為導向，將整合層次往上提昇，不只做資料庫的整合，更做功能性的整合，整合各個不同應用軟體上的功能，以達到真正的EAI。
webMethods所提供的Adapter
若企業今天要做B2Bi，webMethods有：RosettaNet Adapter、EDI Adapter、ebXML Adapter
若企業今天要連接不同的資料庫，webMethods可支援：Oracle、IBM DB2、Sybase、Informix、Microsoft SQL Server
若企業今天要整合不同的ERP，webMethods提供了：SAP Adapter、Oracle Applications Adapter、Broadvision
若企業內部有CRM系統需要連接，webMethods有：Siebel Adapter、Peoplesoft Adapter
webMethods提供商業流程管理介面來建置企業的商業流程

利用 webMethods 的 BPM（Business Process Management），經由簡單的托、拉、放的方式，

及簡易的設定，即可設計一個複雜的商業

流程。而當一個流程被啟動時，webMethods的BAM（Business Activity Monitoring），可及時知道目前此流程的狀態，並且即時產生動態報表。

webMethods提供多種應用管理媒介

企業可以利用PDA、電腦以及手機方式來操作你的webMethods整合系統。

安捷達提供整合的經驗

各種不同平台的開發經驗

企業內部所要整合的系統不僅複雜，並且各系統的開發方式不盡相同，但安捷達不管是在Portal Management 、On-line Applicatoin 以及Application Integration等等，都擁有許多的系統開發經驗。


充份的技術資源
安捷達著力於亞洲的IT市場，擁有豐富的IT資源，各分據點不僅相互支援並且緊密的合作，不管是在香港、上海或是新加坡，我們都有充份的IT經驗，是可以值得信賴的顧問公司。


台灣安捷達更擁有C + M + T的能力
　　　C : Creative
　　　M : Marketing
　　　T : Technology安捷達除了提供Technology外，並且提供了Creative能力，由這次第六屆金手獎，安捷達更是獲得許多專家的肯定，安捷達在這次盛會中，共入圍了二十二項，並獲得了三銀二銅三佳作的獎項。然而有了美化的網頁，並不足稱上一個好的網站，因此在Marketing部份，安捷達更是提供了許多良好的企劃來協助網站及企業的經營，安捷達能將C + M + T的能力緊密的結合並且提供給客戶。
Julian Chou 周金龍
http://www.agenda-asia.com
Technical Consultant of eSolutoin
Division AGENDA Taiwan
WORK: +886-2-2396-7773
FAX : +886-2-2396-7926
MAIL: Julian.Chou@AGENDA-asia.com
GSM : +886-922-639894
MSN : julianchou71@hotmail.com

供應鏈管理的第一本書--重點摘要

　　哈哈！各位，好久不見了！原本計畫每週都有介紹一本書給各位，可是咧！我實在是太懶了，果然是一位沒有恆心跟毅立的傢夥~~

　　話雖然此，不過總還是不能太懶唄，最近買了一本書，叫做「供應鏈管理的第一本書」，作者是盧舜年跟鄒坤霖，據書本描述，一位是在i2待過一陣子，不過，最近i2在台灣好像也沒有風聲了，而另一位咧，是培基數碼股份有限公司的產品經理。而我為什麼要買這本書的原因，是因為我預測年底開始四年內，會有一波供應鏈系統的導入的風潮，明年年底應該會有一波高峰，我說到這邊，一定會有人開始質疑我了是吧，覺得我怎麼可能會預測的出來，其實這也不是我說的，是我前幾天到行天宮拜拜的時候，神明跟我說的，尤於我這個人還蠻迷信的，所以，我相信神的旨意。

　　所以囉！為了應付未來的需求，我總得開始準備，研究一下供應鏈的整個流程的整合，跟概念，於是乎，翻了幾本書之後，我決定買這一本，而我為什麼不要選別本呢，這個原因很簡單，因為他書的名字取得太好了，即然是"第一本書"所以我當然是先買這一本，看完之後，再買下一本囉！不過，我在這邊不做這本書的導讀跟評論，畢竟在供應鏈的領域裡，我還是一位菜到不行的鳥，所以我只做一些隨手的筆記，會摘錄一些重點出來，預計每天摘錄一章，那麼我應該可以把這本書完完整整的開完才是，以下就是我的重點摘要，在寫每一章的摘要前，我會記錄我下筆的日期，以便掌握我偷懶的進度。

第一章：從企業核心競爭優勢說起　　2005/5/1（星期日勞動節，但明天不補休，真是雪特～～）
　　第一章實在太長了，我分二天報告好了。
　　5/1：因為科技的進步，及管理的革新，而造今組織現在面臨許多的挑戰，「組織 + 科技 + 管理」使得公司的組織、策略及流程有所改變。而網際網路及電子商務的出現，更使得企業受到不小的衝擊，如何應用資訊科技來增加公司競爭優勢，已是目前及未來企業的重點。
　　產品客製化、全球化競爭、縮短產品上市時間等等課題，是目前的重點。本章把產品設計到售後服務分為六個環節，從研發設計、採購、製造、運交、銷售到服務，各環節中都可利用資訊科技達到提昇品質、增進效率的效果。
　　我覺得這章節當中有一句話講的很有道理「e化不是企業目標，持續成長與獲利才是。要視e化為手段與過程，……」也就是說，很多公司為了e化而e化，確不知e化能帶給公司什麼樣的成長跟效益，就像業務為了業績而亂賣東西一樣，賣了一個不適合客戶的產品給客戶，就像裡面說的「企業是要購置可以使用兩年以上的設備，但並不需要在今天就購置兩年後才會用到的設備。」，所以企業要導入e化的解決方案的同時，必需好好評估其需要性及功能性。
　　這章還有提到的就是企業的e化藍圖，也就是企業內部各軟硬體以其功能性及特性化分成三個部份，我做一個非～～常簡短的說明：

1. 資訊科技基礎架構平台：屬於硬體部份，像是網路設備、系統、伺服器等等，或一些較基礎的軟體，像是資料庫、作業系統等等。
2. 商業規劃及協同作業：是以供應鏈管理為主軸而向外部組織擴張，其主要服務對像除了公內部人員外，還有供應商及客戶，像是PLM,PDM系統，以及Order Management, Service Planning等系統。
3. 商務營運及管理：屬於日常性作業系統，是以「會計及財務報表」的資料收集為主軸而向內擴張，像是Shop Flow, Km, EIP等等皆是。

　　好了，今天就先醬吧，明天再繼續講第一張囉！

那年秋天, 我與阿姆斯特丹相遇 [一]

前言
這個是我朋友所寫的一篇文章，她目前在瑞士居住，嫁給了一個老外，他們的相識非常的有緣，二個人居住在地球的不同端，但卻在紐約相識、相愛，到現在二個人結了婚，目前是正在懷孕中，應該很快就會有小寶寶寶了吧。算算日子，她過去瑞士也有四年了吧，五年前，我剛才軍中退伍，退伍後參加了基隆一個區域性的劇坊，因此認識。

我從他的新聞台拮取一些文章出來，當作我的電子報的內容，當然我是有徵求她本人的同意才發送的。或許從她一個嫁到外國人的台灣人，來看台灣與瑞士，以及華人文化對其它區域的影響，或許文章不夠深入，但細細品味，我是覺得有不同的感覺，今天我用她與阿姆斯特丹的故事，做為我blog以及電子報的內容吧！

她的新聞台 裘安外傳


那年秋天, 我與阿姆斯特丹相遇 [一]
德語學了五年多, 雖然一直生活在德語區, 說得是高級德文(標準德文), 然而一旦身處德國境內, 感覺卻很陌生.

跟德國人打交道也只限於幾年前於語言學校學習德文時所認識的任教老師及日後參加活動時所認識的朋友,當我探問她們來自德國何處時, 總是有聽沒有'懂', 因為德國這個唯一使用高級德文的國家, 對我而言, 是一個非常陌生的國度. 即使德國境內極具知名的國際城市的名字如:法蘭克福(Frankfurt)及柏林(Berlin)常常在我耳邊打轉(日前有法蘭克福書展; 歐洲航空公司Easyjet不久前在Basel租飛機場地, 提供直飛班機到Berlin及London,價格從SFR99元起跳, 約台幣2'600) 但在我腦海中,這些城市名字始終沒有屬於她們應有的影像...當然也因為簽證方面的關係, 她們曾是如此的遙不可及

目前我人正在德國快速火車ICE(Inter City Express)上, 火車已駛離了Freiburg i. B.. 終於, 我越過了德國邊境卡規定的50公里境內的距離. 於是, 我跨過了這條虛有的界線.

曾經在一本阿富汗人文旅遊攝影本裡讀到旅遊探險家對疆界(界線)下了這麼一個定義: "界線之所以存在, 是等著被人跨越."

終於, 今天, 我跨越了這條界線...但心中多的是五味雜陳...

跨越了這條界線, 火車也陸續駛經法蘭克福及科隆等城, 然而, 我也只能止於驚嘆, 止於癡想, 止於無知...因為這些城市對我毫無意義可言, 最多只是一堆符號的串聯,然後再次被我收納於記憶的抽屜裡, 塵封...

火車一次次地拋開身旁曇花一現的鄉村, 平原, 丘陵及不該屬於德國這個工業這麼先進國家的老舊的鄉鎮火車站...當然也無情地拋開了童話故事中的黑森林, 一路奔向現實的所在

我無情的雙眼, 就如火車拋開身邊景緻的無情一般, 嗅到了瑞士與德國兄弟間生理上的差異:

瑞士是小弟, 對德國大哥帶有複雜的感情

瑞士與德國同父異母, 雖留著同樣的血液, 但因受不同母親後天的調教, 思想上存在著些微的出入

瑞士地小, 天然資源有限, 但事事求真, 求完美; 而德國地大物博, 無法事事兼顧

雙眼直瞪著火車站火車行駛的出口及入口的鐵軌間, 在瑞士, 鐵軌間雜草沒有機會叢生, 而在德國...鐵軌間的雜草生得好不熱鬧!

一架風車倏忽間收入眼簾, 即知我們已進入了荷蘭, 就像一葉知秋如此的靈敏, 如此的必然

好是興奮...看到了田間一道道的水渠, 想到日前於中國時報閱讀到的一篇關於荷蘭用水態度的文章. 想著想著, 我們的火車已駛進了阿姆斯特丹

哇, 這就是阿姆斯特丹!


* 關於旅遊攝影集, 請連至 http://home.kimo.com.tw/joannelee24/

我的電子報的創刊號要出爐了

　　呵呵，蘊釀了好久，終於要發行電子報的創刊號，其實之前已經發過一次了，但是沒發送成功，PCHome的電子報系統還得再改進才行，預期發送功能完全的失效，真是給他圈圈叉叉。

　　好吧，我的創刊號，就是要介紹一下，我電子報的內容要放哪些東西，阿是不是定期發放，還是想到就發，我原本的想法是，隨我高興，想發就發，後來想想，好像不太恰當，如果是醬，我怎麼對得起我廣～～～～大的閱讀者跟粉絲呢！於是乎，我打算最少每週發一次，那書主題呢～～跟書籍有關，好吧，我就簡單介紹一下，我未來電子報的發送內容跟時間。

每週發送「好書大家看」
　　為了強迫自已每週最少閱讀一本書，所以我決定了，我每一週的星期日或是星期一，晚一點可能是星期二，不小心，托到星期三發行的「好書大家看」的主題。放的東西，會有以下幾個咚！ 　

1. 書本導讀

說"導讀"可能有點沉重，只是把閱讀的書籍做一個簡單的介紹，我是怎麼閱讀這一本書的，不過，如果對於我的評論有任何的評論的話，請歡迎留言，批評指教，還是說，各位有閱讀到跟此本書相關主題的習籍的話，也請各位介紹介紹呀。
　
2. 讀後感想

看完書嘛～～一定會有讀後感想，不過感想一定是每個人不一樣的啦，這個部份呢，我會盡量以條理式的方式，以幾個原則：清析、條理、表格、比較等方式來發表我的心得感想，不過，如果真的以這幾個原則來寫的話，不知道會不會讀的很痛苦，沒辦法，我不夠性感，無法寫出感性的文字，所以多多包含囉！
　
3. 精選文句

每本書裡面，都有幾句我認為還不錯的話，會把他給摘錄出來，然後寫一寫一些評論或是評語，把這幾句放在我的經典例句中，把它背起來，看能不能搞得跟胡忠信一樣，動不動就出去杜拉克或是星雲法師的話，我覺得醬超屌的。

IT 生活日誌
　　此專欄是屬於不停時發送，因為我是在IT 工作嘛，所以一定會寫一些跟IT 有關的東西，我有個機車朋友，盡然在我的面前直接說，我寫的東西很基本，阿是怎麼樣，基本就基本，是不能寫哦，要不是看跟他的交情還不錯，不然就砍掉他的一隻手一隻腳了。阿也別醬，如果對我的東西有什麼意見，就請各位大大補充補充，讓我有學習的機會咩，不要直接說我的東西不好，就算醬覺得，放在心裡就好，說出來讓我聽到，我可能會受不了剌激做出傷害你的事情，你也不想發生意外，是吧！所以～～有什麼意見，就說出來聽聽囉！我一定會虛心，或是假裝虛心領教的。

每週財金三件事
　　應該是每週四會發送吧！會有這個構想，是因為每天早上開車上班時，都會聽蔡詩評的廣播，他有一個小小的單元，就是每日財金三件事，我覺得這個主題超棒，因為我沒什麼時間看報紙（其實是很懶），所以聽他每天醬說，我都覺得受益頗多，所以，我也希望每週選三個財會話題來說，這些話題是會跟我們的生活比較相近的，像是哪個百貨在特價，哪邊在做跳樓大拍賣，或者是說一些對換卷等等，如果可以的話，我再加上一些現在跟時勢及生活較為貼近的財金話題。

推薦朋友電子報及文章
　　我有一些朋友，也有自已的新聞台、電子報及網站，我會徵求他們的同意，會把一些精選的文章發送出來，我會醬想，是因為有時候我可能會懶的寫，用別人的來轉寄，一方面，可以將好東西分享給各位，一方面，我的電子報也不會中斷發送，怎樣，這個主意不錯吧。

生活雜記
　　好聽一點是叫做"生活雜記"，其實是隨便亂寫，想到什麼寫什麼，看到什麼寫什麼，有可能一個月會出一篇，或是一年出一篇。說不一定，我會寫一寫，我看龍捲風的感想。

　　嗯～～大概就醬吧，不知道也沒有時間來搞這些，反正就是盡量啦，不然自已實在太懶散了，看醬能不能逼自已稍微勤勞一點，讓自已多讀一點東西才行

IT部門到底在搞什麼？

　　今天跟以前的同事閒聊，請他喝了杯咖啡，聊到他現在待在User Site的感覺如何，接著呢～又去拜訪以前的客戶，順道瞭解他們公司目前的IT需求，聽一聽之後，乎然有所感想，對方講了一堆，可惜我當時沒有帶筆，無法記錄下來，或是偷偷弄個錄音筆，來搞側錄，每次跟他們聊天，都可以得到蠻多東西的。

IT部門重要嗎？
這個問題，我可是想了很久，雖然我只在User Site待了六個月左右的時間，雖然時間不長，但也能感覺到，IT 部門，有時也是挺為難的。

我個人覺得，不管是站我的立場，或是站在企業的立場，「IT 在未來將會主宰企業未來的競爭優勢」，怎樣，這句話，聽起來很嚇人吧，身為 IT 人員的你，有沒有覺得乎然叫阿（驕傲）起來了呢？不過，這句話，也有點語病，他是主宰企業未來的競爭優勢是沒錯，但現在呢？是嗎？
是與否，是取決於公司在它所屬產業的特質，以及對資料或資訊的倚賴程度，我個人用下面幾點來判斷 IT 部門的等級（前提：公司有 IT 部份）：

• 等級一：重要

1. 無需 Real-Time 的資料流。
2. 只需內部簡易網路連線。
3. 擁有進銷存系統。

• 等級二：很重要

1. 資訊系統無需對外連接。
2. 大部份資料是由公司內部提供。
3. 無需即時反應產品生產狀態或是活動狀態。
4. 重要資料或資訊，是由各部門所匯集。

• 等級三：非常重要

1. 資訊系統需要對外連接（透由 CRM、SCM 等資訊系統）。
2. 大部份資料或資訊，是由外部公司所提供。
3. 需要即時的生產狀態或貨品狀態。
4. 客戶大多屬於電子消費族群。

• 等級四：重要的不得了

1. 公司屬跨國性或是屬跟區域性產業。
2. 針對外在環境或是競爭對手策略，需即時反應。
3. 敏感性高的產業。
4. 產品變化性高的產業族群。
5. 金融業。

• 等級五：無敵重要

1. 未完待續……

　　看完以上五個等級就知道， IT（MIS） 部門在公司有多麼滴重要了吧，不過捏～～可惜的是，大部份的 End User 擁遠也搞不懂IT（MIS） 部門在搞什麼，我常聽到的：「我們 IT 部門養了一堆的人，但我從來不知道他們在搞什麼，電腦有問題，要搞個老半天，害我不能工作，網路又常段線，收個Mail也收不到，網路速度又是無敵慢的……」。所以，你看，在IT（MIS） 部門真的很吃力不討好，做的要死要活的，也被人嫌得要死要活的。

IT部門不受重視
　　IT 部門在大多的企業，是不受重視的，因為在大部份的經營著眼中， IT 部門是一個花錢的部份，它不從事生產，但是又少不了它，它每年跟老闆要好多的錢，賺錢的時候，就給它多點錢花，沒有賺錢的時候，就不給錢用，還要從裡面 lay off 一些人。你看 IT 部門好可憐呀，老是要看老闆的眼色，有些系統要外包，老問就會問，你們是不是能力不夠，沒辦法做，聽到這種話，我第一個心裡的念頭就是：「哇咧看咧！你不知道現在資訊科技變化很快哦，每次都要求那麼多，要做這功能做那功能，那麼多的功能，我只有一個人，每個月就領你那些死薪水，什麼都不懂，話還那麼多」，不過想歸想，還是得硬著頭皮幹，不會，就問朋友吧，不然，能怎麼辦？這個就是 IT 部門的窘境，「要錢沒錢，要人沒人，要技術沒技術，要上課沒課上，有改不完的系統，有做不完的事情」，真是（嗶！）的（本台為高尚的網站，髒字一律消音，以嗶！帶過）。

跟 IT 部門要個東西，搞了好久，我開始懷疑我們 IT 部門的技術能力
　　User 擁遠很難達到”滿足”的程度，其實在我個人認為，對 IT 部門來說，我覺得這並不是一壞事，反而是一個能讓 IT 人員有一個表現的機會，也可以顯示出 IT 部門對公司的重要性，但是！大部份的 User 都覺得他們提出來的需久都很簡單，很容易做，像我就聽過 User 說：「你就弄個跟某某系統一樣就好啦，醬不是很快就弄好了，幹嘛要搞那麼久，我看你大部份的時間都嘛是在 MSN　……」「吼～這是什麼態度，不然你自已來寫，真是（嗶！）的」，我們提的 Schedule 永遠不能 Meet ，現在我要說的是，我們 IT 人員要硬起來，不能每天 User 欺壓了。但是！在做反抗的同時，也要站在 User 的立場想一想，如果我是 User ，我是不是，也會醬要求呢？所以，我覺得身為 IT 部門的一員，除了懂得拒絕過份的要求外，也應幫 User 想一想，若這個方法行不通，我是不是可以用另一個方法或方式來解決 User 的問題；與其答應 User 所提的 Schedule 外，是不是真的要評量，你真正能達到的時程，而且”誠實”的跟 User 說「你要的時程我達不到，如果要達到你所要的功能，可能需要花 xx 天，但是，我們可以切成幾個階段來完成，你要的日期，我可以完成第一個階段，第一個階段的功能，我可以做到xxxx……」，我想，醬雙方面應該可以比較和平相處吧。

做的比 User 要求的，多做一點點
　　這個方法，我是屢試不爽，當然，我指的不只是系統的功能，其中也包含上線的時間，能提早一點點，專案一開始，是「報憂不報喜」，把最糟的狀況跟 User 或是客戶說，但是除了”說”，還得說出，解決的方法，但不一定要我們去解決，尤其是對客戶，不是我們要推工作，而是應該讓熟悉的人去做熟悉的事。專案”可能”在第五天可以完成，但是能百分之百能完成的時間是第十五天，那麼，我們就得跟User (客戶)說，我們要完成些專案，是第十五天，一旦專案提前完成，在這段時間中，也可以幫 User (客戶)多做一些小小的功能，讓對方覺得，我們是有在幫他想一些事情。

IT部門定位的類型
　　有些書籍把 IT 部門定位幾種角色以階段，但詳細的內容，我忘了，我就以我的經驗跟記憶，劃分以下幾種角色跟階段：

1. 系統維護者

公司的系統到達一定的成度（可以用，經營者認為不需要增加），這個時候，IT 部門的主要目的，就是讓系統穩定的運作，不要當機，以及一些網路或是使用者帳號的維護，當部門為些種角色時，部門內的人員，無法顯示其價值及能力，且容易與外部技能脫節，若要轉換跑道，會變成較為吃力，不過，若有心的話，是可以多學習一些 Domain 上的知識，但是在技術能力上，較難提昇。

2. 服務使用者需求

若真的能服務使用者需求，我覺得也是個好事，至少公司的 User 會希望資訊人員來幫他做一些事情，能夠讓他們能更好作業，通常這種 User 會有一點點知道 IT 能為他們做什麼，不過此時的 IT 部門是處於一種被動的狀態，是被使用者要求，而不是主動來為使用者設想，其實，這個有時候跟企業文化有關，並非 IT 人員不願意幫使用者或是說不願意幫公司 E 化，有可能是經營者沒有此種共識，有心想弄，但不給予適當的空間，只有當使用者（可能是擁有權力的人）提出需求，IT 部門才有辦法去做，但是通常使用者所提的系統，所願意付出的成本，與真正取得的成本，有極大的落差，所以公司的想法是，與其花大錢找外援，不如自用現在的人力來開發新系統。

3. 創造使用者及企業需求

在我的觀念中，若公司存在的是這一類型的 IT 部門，這可說是公司之福呀，不過要有這種 IT 部門一定要有幾個前提，第一，公司完全信任 CTO（技術長）的決定；第二， CTO 必需有足夠的能力正確的來領導公司未來的 IT 走向及定位；第三，公司能接受新的觀念（未必是新技術，有可能是新的趨勢）；第四，CTO 擁有整合、溝通及協調能力。若能具備以上能力，能夠以 IT 來提昇公司的競爭力、創造副加價值，更能夠顯示出 IT 部門的重要性。

4. 成為立潤中心

我想，若 IT 部門能成為利潤中心，這對身在 IT 部門當中的我們，可說是非常之好，怎麼說呢～～IT 部門在公司來說，實際上是可以計算出生產力的，此專案為了公司省了多少錢，付了多少成本，或是創造了多少價值，都應該將其量化，而 IT 部門不只做公司內部專案，甚至可以擴展至外部，利用產業的 Domain knowledge 再加上配合的 IT 技能，以協助其它公司導入 e 化，雖然這很困難（因為背後還有許多的考量，資料安全性的問題），不過，至少我當時在 User Site 的想法是如此。已目前業界的情況來說，精業就是一個例子，它本身就是從永豐餘分割出去的一間公司，且不論目前的好、壞，若是從正面的角度來看，這未嘗不是見好事，不僅僅能提昇公司 e 化的腳步，更能為公司帶來利潤。

EAI vs. BPM 初次感觀（不是鋼管）

在工作這些年當中，B2Bi的案子做了不少，不過，EAI的案子，這回我可是第一次做。這篇文章，不是在發表學術論文，也不是發表個人大做，更不是在說明自已多瞭解 EAI 以及 BPM ，只是就我所瞭解以及認識，再加上一點點的個人解釋及看法，來說一下 EAI 及 BPM 。

在解釋的過程中，必需有需要觀念上以及實務上的錯誤，或是跟其它人的觀念上的不同。若看了這篇文章之後，能夠引發各位對 EAI、BPM 有不同的想法，或是說，能夠來糾正我的錯誤，我是非常的感激不盡。以下，我就針對我所認知的EAI及BPM來解釋。

什麼是EAI？
EAI全名為Enterprise Application Integration ，中文應翻成「企業應用系統整合」，白話一點講，就是整合公司內部所有的應用系統。為什麼要做整合？做了整合之後，會得到什麼樣的效益？以下我就此做簡單的看法。
為什麼要做整合？
公司內部有許多不同的系統，尤其公司越大，系統就變得非常得多、非常的龐大。在過去，我們一談到整合，為什麼要做整合，第一個直覺就是…「嗯~~做整合的最大的原因，就是各系統之間資料的重複性，非常的多，以及，存在不同得資料庫，會發生相同的資料無法同步更新……」，沒錯！這個就是我們要做整合的原因。
我將為什麼要整合的原因，就我個人觀點，舉下列幾點（若有想到新的，再補充啦~~）：

1. 資料散落各處，無法統一管理。
2. 資料無法同步更新。
3. 有些資料必需有其它應用系統提供。
4. 資料的來源過於廣泛，並不是只有單一應用系統提供。
5. 資料即使已更新，但卻無法即時，讓使用者看到較早的資料。
6. 各應用系統散落各處，系統之間無法相互溝通，而造成需花費更多的人力及物力去做「重工」的事情，尤其是對全球性的公司，更是如此（在我做B2Bi的經驗來看，只要經由"人"來處理資料，資料發生的機率更造成的後果，則更為嚴重。）。
7. （想到再補充）

　　因此，我們就開始動功做整合了，嗯~~~~先弄個資料庫好了，這個資料庫，是可以把我們的資料集中起來，或是搞個Data warehouse吧。我想想哦……公司有十多個應用系統，如果一次整合的話，我想可能會發生問題，乾切我先切成幾個Phase好了，第一個試做，先整合二個系統好了。因此，我把二個套系統的資料庫，先整合一個，嗯~~~~先做個正規劃~~~~之後，我做了系統分析、設計、規劃、開發，最後，終於把整二個系統的應用系統整合在一起了~~~。好！接下來，我要做這二個系統跟其它系統的整合~~哇！問題來了，看樣子，我又得重新做一切正規劃了~~~~再重分析、設計、規劃……感覺掉入一個旋渦裡。看到這裡，你或許會覺得，我這種做法很笨，為什麼不買個工具，專門做整合的工具就好了，還要把自已搞得那麼累 ，若你有這種想法，看樣子，就講到重點了。許多的 IT 部門，寧願花更多的時間來做一些沒有效率，或是沒有結果的事情，這是目前台灣 IT 部門所面臨到的問題－IT部門沒有足夠的經費。

　　對於一個企業來說，企業的經營者，或是決策者，一定要有個認知「IT 部門的強弱，未來將會是決定公司在產業中的競爭力」，或許你不認同，但我卻對此深信不移，我會在另一篇文章會提到此趨勢，最重要的原因是，如果你或是老闆不認同，敝人在下我，可能很快就沒飯吃了。

　　這一個小段落我不是要說「怎麼做 EAI」，好像扯太遠了，不過，想知道怎麼做 EAI 的，咱們私底下聯絡嘿～～這個文章，不從事任何的商業行為。

什麼是BPM？
　　講了 EAI 就要來講 BPM 了， BPM 的全名為 Business Process Management，中文翻做「商業流程整合」，其實，我對這個還蠻有興趣的，不過，還沒有真正實做過就是了。
　　我把 BPM 視為一個資料的流進及流出，而在這流進及流出的過程中，會經過一些資料的處理，或是說一些「應用系統」的處理。我醬說，可能說的很糢糊，我從一個製造流程談起好了，有間公司進了一批零組件，一進來之後呢先把它放到倉庫中（倉儲系統），接下來，工廠要開始生產啦，從倉庫中取了貨，並且放到產線上，進行生產（Shopfloor、EMS）生產完了呢，變成了成品，變成公司的貨啦，就把它們擺在成品倉中（ERP），請了進出口人員訂了一條船，要把東西送出去，要經過海關的報關（報關系統）等等，一出家門口，我還得看看貨到了哪邊，免得在路上掉了貨（E-Tracking），經過一連串的波折，終於到了發貨倉了～～結束了嗎？當然還沒，你以為簡簡單單就結束了哦，其實並沒有，還沒到客戶的手上咧！就算到了客戶的手上，整個流程也還沒結束，為什麼？因為貨品有可能會壞掉，又流回來了咩。知道整個商業流程的複雜度了吧，這個，我就叫做為「BPM」了，不管你認不認同，但至少我是醬認為啦！

EAI vs. BPM
　　看了上述的二個說明，不知道能不能接受我的想法跟看法。這個時候，可能會開始覺得，BPM 跟 EAI 好像有點像耶～～是錯，也是沒錯，是像，又好像不太像，我用個角度來比較好了。

1. 資料 vs. 資訊：EAI所傳遞的是資料，而BPM所傳遞的是資訊，資訊對User 來說，才有意義。
2. 有進有出 vs. 有進未必有出：EAI中的資料，是做一個交換，有可能從資料庫 A 轉到資料庫 B；然而對 BPM來說，每個資訊必有他的起始跟結束，只是時間早晚的問題。
3. 系統角度 vs. 使用者角度：EAI 是單純系統及資料的角度；BPM是從使用者的角度。
4. （嗯～～目前尚未想到）

　　或許在這，可能會覺得，我好像有點故意找麻煩，明明就是一樣，為什麼還是不一樣，嗯～～我只能說，這個是觀點上的問題，所以我只是發表我的觀點啦。
　　所以囉！市面上有很多的 Tool 都說，他們能做 BPM ，但是實事上，真的能做嗎？我會再發表一個審視 BPM 工具的要點（我現在還沒想到要怎麼寫）。請”四”目以待（請戴上您的眼鏡）。

用簡單的方式來說BPM
　　我覺得BPM，在我認為最貼切的比喻就是「吃飯跟大便」（可能很多人覺得不文雅，但在下才疏學淺，只能想到這個例子），食物從我們的嘴巴進去，在嘴巴裡面做了第一道的處理，再經由食道、胃的消化、大腸、小腸的吸收及分解，有的到了尿道，而有的呢，到了大腸等待大便，看似簡單的過程，其實，若是在這中間的階段停留過久，或是出不來了，我想，這個人不是便秘，就是哪一個器觀出了問題；比造我們的商業流程，何嘗不是如此，若在這過程中，有一小段阻塞了，或是不知跑哪去了，那麼，這個企業在整個流程上，必定出了問題，需要好好的健診一下了，不知道這個比喻似否適當呢？

　　希望各位能對我這一小篇的文章，多多批評，讓我有進步的空間呀，謝謝！謝謝！肛溫嘿（感恩）！