提升自信控制壓力的十個祕訣

Fred Wang譯

1.想想看在你離開人世時希望留給別人怎樣記憶,這決定你是怎樣的一個人,銘記在心,做你想要變成的那種人

2.每日給自己一個激勵的話幫助自己養成正面思考的習慣

3.將您過去的成功事例列表記在筆記本上,時常檢視及更新

4.避開消極的思想與消極的人

5.脫離你的舒適(或懶惰)領域,大膽去做些你害怕做的事情

6.不管任何狀況盡你的可能做好, 但不要騙自己認為自己是最完美的

7.原諒自己所曾經犯過的錯誤, 感謝自己努力所得的成就, 把自己當成自己最親密的朋友

8.信賴自己的判斷並在自己的能力範圍內做好的決策

9.學習對將耗盡你的時間與能量的要求說不

10.成就是做出來的不是夢想出來的, 積極的努力成為你希望變成的那種人

下一波程式設計的挑戰-multithreading 讀後感

看過另一篇文章"程式設計師的保鮮期只有十年", 恰巧Java誕生至今剛好十年, 不過Java的熱度未退, 如同Pascal, Fortran, COBOL 沒有什麼語言,什麼技術是永遠的主流的, 程式設計的思維從結構化到物件導向, 從單機處理,Client-Server,到Multi-Tier, 隨著硬體發展而重新被提起的平行處理/多執行緒的應用.
不要讓自己成為"過期"的IT人員, 只有持續的學習, 保持謙卑與彈性來面對改變!
-- Fred Wang

下面文章是冼鏡光老師(資訊科系的學生應該很熟悉吧!)在程式設計師俱樂部發表的文章, 這裡還有許多的討論
http://www.programmer-club.com/pc2020v5/forum/showsametitleN.asp?board_pc2020=general&id=3499

下一波程式設計的挑戰:multithreading
作者 : shene(冼鏡光)

也許說平行處理太曲高和寡，因為沒多少人買得起，談起來總是相當遙遠。但是我們的桌上型電腦的速度卻也愈來愈快，想當年有一台8mhz的PC就可以引以自豪，再比一比目前3.4ghz的PC，兩者的差別何止千里！問題是，CPU的速度不可能無止境地加快，終有到達瓶頸的一天；沒有人知道這一天何時到來，但若目前的瓶頸無法突破（事實上也很難突破），我們寫程式的人終究有一天會覺得CPU不夠快，我們有對策嗎？我們的知識與技術足以克服這個障礙嗎？
在硬體方面，Intel與其它廠家已經加上了hyperthreading的功能，但效能的增加在最好的狀況也不過是10%到15%而已。所謂的 hyperthreading，指的就是CPU中會把待執行的指令分成幾條執行線(thread)，讓CPU可以在一條線無法繼續時（譬如等待cache 來的資料，或是等待另一條線完成某項工作），能夠執行另一條線的工作。但是運算單元與邏輯單元在CPU中都只有一個，所有執行線都搶著用，於是瓶頸就出現了。
今年，各廠家可能會推出multicore的CPU，把兩個或更多個CPU的功能放在固一個CPU中，因此CPU中的執行線就至少有兩組運算單元與兩組邏輯單元可以使用，這樣hyperthreading的效能又可以再度提高。聽說Intel會把兩個Xeon合併在一個CPU中，並且在今年上市；AMD據說也有類似計劃，當然PowerPC與SPARC也不會落後太遠。
如果這些新一代硬體出現，一般的程式設計技術就不太夠用了，用為我們從頭開始所學的都是「序列式」(serial)的思考方式，所以寫成的程式很可能使hyperthreading與multicore 的架構無用武之地。然而，複線作業(multithreaded programming)的觀念在1960年代末遂漸成型，從IBM PL/I F，全錄(Xerox)的Star，到Modula 3、Ada與Java，這些語言本身都具有複線作業的能力。另外，Unix在1980年代中期也引進了複線作業的能力，後來ANSI的POSIX加上 Pthread標準，以及OS/2、Windows與Sun Solaris都有此等能力。
為什麼複線作業那麼重要？很簡單，如果一個程式有個分身來做額外的事，程式的效率與CPU的使用率就都會提高。好比說，當一條執行線正在等輸出輸入完成時，我們可以起動另一條線進行計算的工作，於是 CPU就不會閒置，從而CPU使用率就會比較高，程式也執行得比較快。這些觀念在您的OS課程中應該學過，正因為如此，我很想請教各位一個很嚴肅的問題：
您準備好迎接下一波程式設計的挑戰了嗎？
過年放假不少天，在吃喝玩樂之餘，我們得真心想一想這個問題的答案。
後記：不知道什麼人始作俑者，把thread譯成「執行緒」而不是上面用的「執行線」。這個「執行緒」譯名的確有點滑稽，程式或系統中何「緒」之有？

"Java天生麗質亂人眼"讀後感

全文 : http://blog.clubbenq.com.cn/904569/archive/2005/09/05/17625.aspx

最後一段, 最有哲理!
"一種語言都有它閃光的地方，都有它迷人的特徵，每一個人在學習電腦的時候，要根據自己的實際情況選擇一門讓自己能夠提高最快的語言來學習。學習語言本身就是學習電腦的末流，是附屬。程式思想才是一個程式師要掌握的核心。
很多問題，用各種語言都可以描述，語言本身沒有貴賤之分，倒是人們刻意的去尋找這種貴賤區別，迷惑了自己，也迷惑了別人。
C 的程式師們可以放下顧慮，認真地學習Java，這就表明了很多C程式師的博大，也許這些高手已經參透了電腦的本質，學習語言只是因爲學了它可以偷懶而 以。那麽就請很多Java程式師不要在做井底之蛙，來嘲笑一個C語言程式師了。要知道，一個C的高手學Java，只是須臾之事，根本花不了太多的精力和時 間。
我們學Java，只是爲了工作的更好，並不是因爲不會Java，我們就無所適從。任何一門語言消失了，世界都依舊存在，依舊美好。"

感想 :
本文真是太好了! 給一些擁抱一種技術就以為是全世界的人當頭棒喝!

從74年開始學Basic, 後陸續學過Fortran, Pascal, Forth, COBOL, RPGII, dBase3/Clipper, C, Assembly Lang., Prolog, Lisp, HTML, Javascript, Java, ABAP/4, 不論是用到多少, 我從來不認為哪種程式語言是最完美的! 重點是 "程式思想才是一個程式師要掌握的核心" 使用電腦語言, APIs, Programming Library, Tools, IDE等, 都是為了讓工作更好, 創造價值, 因此只要能創造最大效益的就是最好的.

Lotus Quickplace的問題與答覆

問題 :
我是某大學教授的助理
幫忙教授管理還有製作工作區

能否麻煩請教一些有關quickplace的問題
目前我在自訂佈景主題那邊有一些問題
就是在版面配置的問題

我想讓TOC的table能往下移一點
那個是要在清單資料夾配置的htm檔裡面去設定嗎?

另外我幾乎不會什麼程式或java
我之前是先用IBM的REDBOOK的相關檔案下載
IBM做為範例的檔案
但裡面並沒有清單資料夾配置的htm檔(Listfolder.htm)

當然平台也可以自動幫我產生那個檔
可是就沒有辦法配合我想要的樣子

請問一下有沒有什麼辦法
把平台自動產生的那個檔捉下來
我才能參考
另外請問一下除了IBM的那個REDBOOK
還有沒有什麼資源可以讓我參考
怎麼自製QUICKPLACE的佈景主題

關於版面配置
我幾乎都不會
不知道要怎麼去設定

- Holisi

答覆 :
問題一: 更改TOC要改哪些檔案?
答:
要更改TOC table的位置, 要同時到資料夾清單(list folder)及Page theme file(html)中更改, 若您有使用slide or headline 形態的folder, 也要到其他兩個theme file修改, 否則在顯示單一網頁內容會與顯示資料夾清單會有不同的TOC, 除非您有特殊需要, 要讓兩者有所不同.

問題二.請問一下有沒有什麼辦法,把平台自動產生的那個檔捉下來?
答:
Quickplace系統只提供一個標準的template給你下載, 其他的template則無法下載, 可以做的是用Dreamware or frontpage做這些Theme files(html)再逐一將Quickplace Component tags加入這些Themes, 然後上傳到您的Quickplace site

這種方式, 不需要懂Java, 但是設計的好不好, 則與美學設計有關了, 當然熟HTML是基本的, 另外Quickplace Customizing 手冊中第四章介紹的Theme and Quickplace components也要熟悉

-- Fred Wang 2005/02/25

2300萬個工作狂比不上5800萬個哲學家

台灣的工作時數是世界最多，經濟表現幾乎是敬陪末座的第四十名； 法國的工作時數是世界最少，經濟表現卻是世界第八名。 這樣的結果讓人困惑，為什麼2,300萬個工作狂，卻比不上5,800萬個哲學家？ (From 2002年11月 CHEERS雜誌)

世界不斷創造出各式各樣的商品, 科技產品推陳出新, 價格也越趨低廉, 而多數人的生活卻越來越趨忙碌而失去生活品質, 您有意識到您的努力有讓世界變的更好,讓生活品質變的更好, 讓自己變的更好嗎? 如果沒有, 重新思考您要走的路與重新規劃您的生活吧! -- Fred Wang

名言 :
「不要追求成功，試著追求生命的意義！」～愛因斯坦

新成立的公司資訊系統建構的順序 - 製造業為例

Fred Wang (2002/05/02)

一般公司建立到申請上櫃,需八大內部控管循環:

. 銷售及收款循環
. 採購及付款循環
. 固定資產循環
. 融資循環
. 薪工循環
. 生產循環
. 投資循環
. 資訊管理循環

1. 其中財務主體有三項, 與財務相關有三項
2. 而協助制度的建立為首要, 其次才是自動化系統的建立
3. 若是製造業則以生產系統為必要建立的系統
4. 營運系統(ERP) 則以財務第一, 人事其次, 然後倉/物管及生管最後才是採購及接單
5. 至於CRM, 電子商務, 資料倉儲, EIS等, 則是建立在這些基礎之上

因此優先順序:

制度建立--基礎建設(Infrastructure)--生產系統--營運系統(財務--人事--倉/物管/生管--接單/採購)--CRM/eBusiness/EIS/DW

當然系統尚未建構前, 例如接單系統較晚建立, 則須透過書面文件的方式作業.

實作ERP系統時料號編碼策略問題探討

在導入物料管理系統時，往往會有料號編碼原則的問題，要將料號賦予意義的編碼原則還是用系統自動產生沒有意義的編碼? 下面是一個CPIM專家的回答 :

實作ERP系統時料號編碼策略問題 :
. What part numbering strategies have other companies employed during implementation of an ERP system?
. Why was this strategy chosen?
. What problems arose during implementation because of this decision?
. If you were to do this all over again, would you make the same decision?

顧問解答如下 :
This issue comes up in most ERP implementations. I have had this discussion with almost every company that I have been involved with. My recommendation would be the same as your SAP consultants. No matter how much or little intelligence you put in your part numbers you will run out of numbers some time. Or your business will change enough that your part numbers don't mean as much as they used to. SAP has a good solution to this problem. Let SAP auto-generate your part numbers and use Classification to classify the numbers into the groups that you want. You can then build reports or search queries to find the part number or groups of part numbers that you want. SAP also has "material groups" that you can assign to a group of part numbers. This would be like a commodity code.
By using classification you also help eliminate the possibility of having two part numbers for the same physical part because you could not find the part number and just created a new one.
During implementation the problem is that you have to retrain people to not rely on the part number and that they should rely on the description to identify the physical part. Descriptions have to be very specific using Noun, Adjective, Adjective, etc.
Another thing that I have seen is that in the storeroom or warehouse people try to put the inventory in part number order. This might be of some help when trying to find a part number but it is very inefficient for storage space. You should use a part locator to store material and not the part number sequence.
Would I do it again?? Without a doubt I would use system generated part numbers.
這個問題發生在大多數ERP導入過程。我幾乎跟每一個參與導入的公司有過這樣的討論。我的建議跟一般SAP顧問一樣。無論您把公司的料號編碼加入多少智慧(意義)，執行一段時間，號碼就會用完。或者是因為業務的改變，造成料號編碼的原則已經不敷使用。
 SAP對這個問題具有很好地解決方法。讓SAP自動產生料號並使用Classification來進行分類分群。您可以建立報表或透過搜尋，找到需要的料號或料號群組。 SAP還有“material groups(物料群組)”，你將它指定給料號。就像一個商品代碼，藉由分類可以避免相同實體料件，建立了兩個不同的料號。

在導入過程中的問題是，你必須訓練同仁，不要再依賴於料號編碼，讓他們依靠的料號的描述，了解物料的實體特性。這個描述必須要非常具體的使用名詞，形容詞，形容詞等。

我曾看過在儲藏室或倉庫的人試圖把庫存以料號來排序。這可能有助於找到一個物料，但對這種方式對存儲空間是非常沒有效率的。而應該使用"料號定位碼"(part locator)，來存放物料，而不是料號的順序。

毫無疑問，我會用系統來自動產生料號。

Steve Blair CPIM
Quality Systems Consulting

感想 :
料號採系統自動編碼機制? 也就是無意義的料號編碼! 但是在實際的生產及倉儲人員卻無法透過無意義的編號進行溝通, 因此生產及倉儲人員透過另一種方式描述料號, 但是必須有良好的管理方式及嚴格的轉換機制, 否則容易造成錯誤. - Fred Wang

SAP是甚麼的縮寫-Joke

Stupid And Pay
Shutup and Pay
Send Another Payment
Stop All Processes
Suffer After Purchase
Slow and Painful
Slow And Problematic
Submit And Pray
Stress, Anxiety, Panic

Reference : "What does SAP stand for?" From http://www.experts-exchange.com

如同微軟, 最大的公司往往目標也最明顯, 最容易成為眾矢之的.

ps. 正確解答是 "System Analysis and Programming"(早期) 或 "System, Application and Product in the data processing"的縮寫

SAP - Stops All Production ?

在J-Walk Blog中看到兩個對SAP的評論 :
(1)
We have SAP in our large corporation, and, what used to take one person to do in a half day, now take three people three days.
The standing joke is that SAP stands for "Stops All Production".
It is a horrible control system that tries to be all things to anybody who makes anything.
Is the screw you ordered the wrong thread? Good luck. It will take half a dozen people to correct the situation, IF they are authorized to do so, and probably they are not.
(I hate SAP, in case you wondered...)
SAP a great system to buy, for your competitor.

-- By Jim Arnett . Comment posted 28-Apr-2005

(2)
All I know is the guy in the next office over, on a daily basis, is on the phone talking Oracle and SAP, and we use SAP for equipment and services rendered cost codes. You have to look in a 3" thick book to find the SAP cost code. Then when we are done with drilling a well, someone in town adds up all the SAP costs and starts b******g about the million dollars spent to drill the well. To confusing for me. I'm far enough up the ladder right now, that it's gonna hurt like heck if I take a fall.
-- By Rance . Comment posted 28-Apr-2005

http://j-walkblog.com/index.php?/weblog/comments/sap_and_erp/

SAP是功能齊備的豪華轎車, 不是所有企業玩得起的, 不過近年已提出中小企業的解決方案,
企業仍因其企業規模,需求,投資等審慎評估再決定是否採用.

當您想要的太多, 往往也忽略失去了什麼

商業周刊 "裁員一半，蘭奇卻衝出宏碁美國四倍價值" 文中提到宏碁電腦總經理蔣凡可．蘭奇（Gianfranco Lanci）的致勝之道不是加法，而是「減法」，他的心法是：「搞清楚不必做什麼事，比學會該做什麼事還要困難。」

我想人生也是如此, 簡單而專注, 才能成就一項事業

蘭奇說到:「每一小時，太陽都會朝地球散發數以億計千瓦的能量，戴頂帽子，加上一些遮陽裝備，可以在大太陽底下，享受好幾小時的日光浴；但只凝聚數千瓦而形成的雷射光，卻能夠鑿穿鋼板，或消滅癌細胞。」這就是專注與聚焦的力量

因此,
當您的思想過於複雜, 將無法進行更深層的人生體會與思考
當您的夢想過多, 將無法專注在任何一個夢想的實現
當您的交友過多, 將無法真正的找到知心的對象
當您學習過於廣泛, 將無法成為特定領域的專家
當您想要的太多, 往往也忽略失去了什麼

Fred Wang 2005/09/16 商業周刊讀後感

SAP工廠維護模組(PM)主要物件名詞解釋

SAP工廠維護模組(PM)主要物件名詞解釋
Fred Wang 2005/09/11 (http://fredwang.blogspot.com)

第一部份 Functional Locations
Functional Locations
功能位置(Functional Locations)為技術結構的組成元素，例如: 工廠的功能性子單元; 功能位置以階層式方式建立， 可以根據下面條件來建立其結構
1.功能
2.流程導向
3.空間
一個功能位置代表一個執行維護工作的場所。
需定義的欄位有 :
 -Structure Indicator
 -Functional Location
 -Functional Location Category
 -Object Type
 -Maintenance Plant
 -Plant Section
 -Cost Center
 -Planning Plant
 -Planner Group
 -Main Work Center
 -Catalog Profile
主要欄位描述如下 :

Structure Indicator
決定功能位置的結構建立時階層編號方式(edit mask)
欄位 :
-Structure Indicator
-Description
-Edit mask

Object Type
定義技術物件的型態。用來將技術物件分組以區分主檔資料或維護資料。
欄位 :
-Object Type
-Description

Maintenance Plant
維修工廠(maintenance plants)是一個可以管理技術元件(technical objects)和負責執行工作的工作中心(work centers)的工廠

Plant Section
從生產的角度將維護工廠區分成一些工廠區域。負責這個工廠區域的人就是協調生產與工廠維護的聯絡人。
欄位 :
 -Plant
 -Plant Section
 -Person Responsible
 -Telephone

Maintenance Planning Plant
定義維修工作清單，在工作清單中以BOMs基礎執行物料規劃和執行維修工令，管理及安排維修時程，為相關的維修工廠輸入維修通知和處理維修工令的工廠。
欄位 :
 -Planning Plant
 -Name

Planner Group
定義計劃工廠相關的計劃小組(Planner Group)
欄位 :
 -Planning Plant
 -Planner Group
 -Name
 -Telephone

Maintenance BOM


第二部份 Equipment
Equipment
設備只一個獨立的維護單元，每一個設備可以個別管理。因此可以 :
-從維護的角度管理個別的資料
-產生個別的工廠維護行動
-紀錄每一個工廠維護工作
-蒐集並評估跨一段長時間的技術資料
設備可以在功能位置(Functional Location)安裝及採解。每個設備在功能位置的作業時間可以按照時間先後被紀錄下來。

欄位 :
 -Equipment Category – 設備類別，ex: Q: Test/Measurement Equipment
 -Description
 -Type of Technical Object – 設備類型
 -Vendor Number – 供應商
 -Manufacturer – 製造商
 -Manufacturer model number
 -Manufacturer serial number -製造商設備序號
 -Plant - 維護工廠
 -Company Code
 -Planning Plant
 -Planner Group
 -Main Work Center
 -Material
 -Serial Number

Material with Serial Number Profile
這種物料指定給設備(在設備主檔的serialization view)用來建立及管理設備的維護紀錄，這類的物料不會使用在別種作業上。
欄位 :
 -Industry sector
 -Material type
 -Plant
 -Storage Location
 -Description
 -Base unit of measure
 -Material Group
 -Purchasing Group
 -Serial no. profile

第三部份 Maintenance Plan
General Maintenance Task List
一般維護工作清單記錄所有需要的維護工作。維護計劃建立時會指定一般維護工作清單。清單中的作業(operations)此時會轉入維護計劃內，後來將轉到維護工令內。
欄位 :
 -Description
 -Planning Plant
 -Work Center
 -Usage : 4 (Plant Maintenance)
 -Planner Group
 -Task List Status : 4 (Released)
 -Inspection points
Operations
 -Operation
 -Control Key
 -Operation Description
 -Work : 維護工作時間
 -Unit : “H” for hours維護工作時間單位
 -Number of Person

Maintenance Plan

欄位 :
 -Maintenance Plan Category
Single Cycle Plan View
 -Description
 -Cycle - 維護週期的長度
 -Unit - 維護週期的單位, ex: “MON” (month)
 -Offset - 從維護計劃開始到啟動工令的時間
 -Equipment – 要維護的設備
 -Planning Plant
 -Order type – PM02 (Maintenance Order)
 -Main Work Center
建立後自動給一個Maintenance Plan Number

-Planner Group
 -Maintenance Activity Type - 002 (Preventive Maintenance)
 -Type - Task List Category
 -Task List Group
 -Group Counter
Maintenance plan scheduling parameters
 -Shift Factor Late Completion
 -Tolerance (+)
 -Shift Factor Early Completion
 -Tolerance (-)
 -Cycle Modification Factor
 -Call horizon
 -Scheduling period
 -Completion Requirement – Order operations是否需要確認(confirmation)
 -Cycle start

在維護計劃可以使用前，必須進行排程(Scheduling)並啟動的程序，排程就是依據上面的排程參數來進行。

第四部份 Maintenance Order
Maintenance Notification
當技術物件不能正確或正常運作或產生較差的結果, 此時員工必須開立維護通知，如果使用解決方案資料庫(solution database), 則可以根據問題搜尋可能的解決方案。維護通知可以描述詳細的技術異常狀態，並藉此提出維護需求。
欄位 :
 -Notification Type : 分為兩種 : 故障報告(M1)及故障需求(M2)
 -Equipment
 -Assembly
 -Description
 -Subject Long Text
 -Reported by
 -Object part
 -Damage
 -Text
 -Cause Code
 -Cause Text
System availability and System Condition
 -Functional Location affected
 -Availability before malfunction - 故障發生前的可用程度
 -Availability after malfunction - 故障發生前的可用程度
 -System availability after task -維修後系統的可用程度
 -Condition before malfunction – 故障發生前的情況
 -Condition after malfunction – 故障發生後的情況
 -Condition after task – 維修後的情況
Breakdown
 -Malfunction start - 故障開始的時間
 -Malfunction end -故障修好的時間
 -Breakdown – 是否已經完全修好
 -Breakdown duration – 故障總時間 (自動計算)

Maintenance Order
維護工令用來規劃更細的維護工作，例如決定維護工作要內部處理或外部處理，需要那些原件(物料)，另外也可以用來搜集維護工作的成本
欄位 :
 -Order Type
 -Priority
 -Functional Location
 -Equipment
 -Assembly
 -Maintenance planning plant
Assembly Structure List :
 -Order short text
 -PM Activity type : ex: 003 (Repair)
 -System condition
 -Basic start
 -Basic finish
 -Operation text
 -Work duration
 -Number
Operations
 -Operation Number
 -Operations Short text
 -Control key : ex: PM02 (external processing)
If Control key is “external processing”, select “External” (輸入採購資訊)
 -Operation quantity
 -Price
 -Purchasing group
 -Purchasing organization
 -Recipient
 -Unloading point
 -Vendor number
Explanation for Including Components (Spare Parts)
 -Description
 -Item category
 -Unit of measure
 -Quantity or requirement
 -Operation Number
 -Component (material number)
 -Material type
 -Material description

SAP R/3 與外部系統整合設計概述

Fred Wang(20050906) http://fredwang.blogspot.com

整合設計常出現的現象如下 :
1.多數的時間與成本花在定義與實作跨系統的流程與介面
2.不好的介面設計造成效能,資料一致性及管理上的問題

除了跨系統間的介面設計外還有許多問題需要思考的, 下面將整合設計粗分為三階段:

初部設計階段
產出 :
. 商業流程圖與描述
. 限制因素
. 資料物件 :
必須詳細瞭解交換的物件及物件在兩個系統間的差異, 除了意義上的差別, 在資料內容上也可能不同,必須考慮其轉換的方法
. 實作策略

問題 :
1.介面應建立在商業流程的那個地方?
2.有那些限制因素, 如non-SAP系統環境, 用到的SAP功能, 實作策略等
3.必須在那個時間點交換那些資料物件

細部設計階段
產出 :
1. 資料物件的輸入與輸出
2. 取得一些樣本資料
3. Coding或客製化 (SAP and External System)

問題
1.有資料交換的標準解決方案? 如ALE, RFC and other middleware
2.評估使用的技術考量 : 資料量, Online or Batch, 同步或非同步, Monitoring/Recovery機制等
3.有沒有Sample Codes?

實作階段

產出 :
1. 介面程式設計
2. Test Scenarios
3. Test Reports

問題
1. 有否建立測試環境(含SAP, non-SAP)?
2. 那些流程要測試, 有那些Test Scenario?
3. 有足夠的測試資料以進行測試?
4. 任何錯誤的狀況應如何用文件加以記錄?

結論 :

因此, 整合設計應確認下面事項:
1. 定義經常且必須的介面Scenario
2. 找出管理上的限制
3. 找出技術上的限制
4. 列出Scenario上的資料物件
5. 描述每個物件的輸入輸出
6. 找出可能的替代方案
7. 找到每個替代方案與物件的sample codes

整合設計時除了商業流程整合之外, 還要考慮下面幾點:
1. 資料的一致性
2. 錯誤處理
3. 管理成本 (介面的管理是否容易)
4. 安全性