發表文章

目前顯示的是 1月, 2010的文章

如何找到AgilePoint 產品序號

圖片
找出AgilePoint 的序號可使用Registry Editor, 尋找關鍵字 www.ascentn.com ”, 再找Display Name 為所需之產品名稱, 其Production ID 就是產品序號. 執行 [開始]執行. 輸入 regedit , 點[ 確定 ] 尋找: 我的電腦\H KEY _LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\ UserData 按右鍵, 點選[尋找]. 輸入 www.ascentn.com , 點選[找下一個]. 按 F3 key 直到 Display Name 出現 "AgilePoint Server" 或 “AgilePoint Envision” 或 “AgilePoint Developer” , 其Product ID 欄就是 License Key.

AgilePoint Envision 的屬性視窗不見了?

圖片
AgilePoint 的流程設計工具Envision是MircoSoft Visio 的附加元件, 有時安裝完或執行一段時間發現屬性視窗不見了, 目前我們已知的原因有下列幾種. 1.屬性視窗被關掉了 如果envision 中左辦部之屬性視窗不見了, 但是檔案下的Validate Process,Update Server …都還在, 通常是屬性視窗被關掉了. 此時只要點選編輯—>Process Template Properties 即可開啟屬性視窗. 2.安全性設定.    因為Envision 是Visio 的附加元件, 因此若安全設定太高時, 會無法執行, 不過根據筆者測試的結果, 不論選擇何種選項, 目前的版本(4.7)會自動將其改為低. 工具-->選項-->安全性 3.Envision停用    Visio 升級以後有時會發生附加的的元件被停用的情形.   可檢查功能表 說明-->關於Mircosoft vision 下的停用項目, 若有相關停用項目, 則將其改為啟用. 4.安裝順序錯誤.    AgilePoint 的Server Pack 是包含所有產品的更新(包括AgilePoint Server , Envision, Developer ,Enterprise …),更新程式會自動依照安裝的產品, 自動更新相關元件, 又因為Agilepoint 的核心程式的組件(Assembly),在這些產品模組都是共用的,因此常見的錯誤為先安裝AgilePoint Server 再安裝Service Pack , 之後再安裝Envision , 此時更新的Envision 元件有可能會蓋過新版的元件, 造成Envision 的元件是舊的 , 但核心組件是新的. 因此正確的安裝方式應該是先安裝各項產品, 再執行Service Pack 可避免這個問題.

AgilePoint 的流程變數

圖片
一般的工作流程或電子表單的軟體, 最常用的方式是一張表單, 一個流程, 通常也會對應至一個資料表, 因此我們會看到有些Workflow的軟體, 所強調的流程整合是利用表單資料轉換的方式來進行, 請購轉換為採購單, 採購單轉換為驗收單, 驗收單再轉換為付款單, 類似此種架構, 主要是因為他們的架構上表單與資料是密不可分的緣故. AgilePoint 是採用前端輸出入介面, 流程, 資料三者分離的架構, 因此可視為三者是獨立存在. 我不將前端輸出入介面直接稱為表單, 而改稱為輸出入介面, 主要的原因是在AgilePoint 中資料與表單是分離的, 因此流程中所儲存的資料, 我們稱為Custom Attribute 我將他翻譯為流程變數, 其流程變數與表單並無絕對的關係. 流程變數是串起整個流程資料的依據, 就像是網頁程式的Session 變數, 差別在於Session變數只存在於網頁連線的期間, 流程變數是存在於整個流程, 由流程啟動一直到流程完成後都會一直保留在資料庫中. 流程變數在流程資料庫中預設是以XML 的型式儲存, 其優點為無需預先定義資料格式, 可視需要隋時增加變數與修改變數的內容. 流程變數的產生有以下幾種方式: 1.啟動流程時一併建立流程變數. 在AgilePoint要啟動一個流程可以透過CreateProcInst() 的API , 其有兩種形式直接呼叫CreateProcInst()的API 或呼叫其所提供的WebService 介面, 視呼叫單所在的位置決定. 在此API 中可傳輸一個流程變數與資料名稱的陣列, 資料型態為其內定的NameValue[] 的格式, 簡單的說就是由名稱與值所組成的陣列. 因此在表單中輸入資料或外部應用系統如ERP 中只要能呼叫WebService 並且可組成NameValue的Array , 都可以在啟動流程時, 一併將外部資料傳送至AgilePoint 中. 2.透過AgilePoint 所提供的WebControl 在AgilePoint 所提供的WebControl 都有一個BindingName 的屬性, 呼叫啟動流程的API- CreateProcInst()或呼叫完成一個工作(WorkItem)的API – CompletedWorkItem() 時係統會...

第三代AgilePoint 表單開發樣板-AresEFM

圖片
AgilePoint 的前端表單 AgilePoint Server 端是採用Web Service 架構, 因此前端表單可採用任何可以呼叫WebService API 的程式語言或工具, 在國外大部份的客戶皆採用InfoPath 作為表單, 不過因為以InfoPath 作表單,一方面需配合MOSS(Mircosoft Office SharePoint Server )及Form Server , 另一方面要作到彈性很高的表單, 較為困難, 所以在國內大部份的客戶皆採用Asp.net 作為前端表單. 以Asp.net 作表單最大的優點是表單的彈性很高, 所有Mircosoft 所提供的表單元件, 甚至是ThirdParty 所開發的元件皆可使用, 再加上Asp.net 是一個標準的程式語言, 因此並無學習上的門坎與障礙, 因此是一個很好的表單前端工具, 但缺點是要作到具有基本功能的表單也需要花一些的功夫, 這也是我們希望剋服的問題. AgilePoint 與Asp.net 表單發展歷程 第一代表單元件—基本元件 AgilePoint 最原始的表單開發元件有兩種類型, 一種是AgilePoint 預設提供的表單基本元件(如TextBox、DropDownList、Checkbox…)其繼承自Microsoft 所提供的元件, 但加上一個BindingName的屬性, 可自動將元件的內容存入指定的流程變數, 並於顯示時可自動由流程變數取得相關的值,另一種方式是直接採用 Microsoft 或ThirdParty 提供的元件, 此時可呼叫AgilePoint 提供的儲存流程變數的API – setCustomAttr()或以getCustomAttr()取得變數值, 另外要觸發流程事件如發單/同意/退回/加簽/轉派…皆需自行呼叫相關的API , 並處理後續網頁的行為, 此時所作的工作與一般網頁的應用程式開發無異, 但已能享受到AgilePoint流程模型驅動的優點. 第二代表單元件—整合元件 第二代的表單開發元件是我們針對使用者常用的功能, 提功一組較完整的元件, 如發單的按鍵可提供確認是否要執行的訊息, 並自動呼叫啟動流程API, 顯示完成的訊息, 完成後網頁可導向指定的位置.又如簽核意見的輸入, 分別提供輸入欄位、顯示的Grid 等獨立的...

如何達成作業Pool, 一份工作同時指派多人, 但只要部份的人簽核?

圖片
在AgilePoint 中一個步驟可以同時指派給多人, 但真正需要執行的人數, 可由流程元件Manual Activity控制之屬性[最大參與者數](Max Participants)設定, 指派的人數小於[最大參與者數] 則表示所有被指派者都需簽核, 如設定為 1則表示被指派者只有一個人需簽核. 指派多個參與者的方法常用的有下列幾種: 1. 單一流程變數- 指定多人 如$O2U_AssignedUser_USER (使用者存放於流程變數AssignedUser中,人員間以分號區隔, 若需指定部門, 可以UserName 後加逗號.) 2. 單一流程變數-指定多部門 如$O2D_AssignedDept_USER (使用者存放於流程變數AssignedDept中,部門間以分號區隔.) 3. 指定多個流程變數, 流程變數間以分號區隔. 4. 使用組織變數 如$O2_DeptID_ALL( 註:DeptID為特定部門代號) 5. 其它任何可一此設定多人的方法皆可使用. 除了原有的流程變數外, 我們在新一個版本另外增加一個功能是指定部門主管層級範圍與人數 (此視窗為新版AFAgileWork 之ParticipantsUser 的設定部門視窗) 例如在一個組織中 L6-組長 L5-科長 L4-經理 L3-協理 L2-副總 L1-總經理, L0-董事長 若申請者送出表單後, 可由 L6 至 L3 任一人核可, 之後再由上一階主管逐一簽核至 L1的總經理. 則可以設定為MANAGERGROUP , 並指定最多幾個Manager , 且範圍為L6 至 L3 , 則 L6 至 L3 的主管每人都會收到一個New 的Task , 其中一人簽核後, 可在配合逐級簽核至指定層級. 上述設定UserRank 由L6 至 L3 , 會依使用者所在部門, 尋找上階部門只要部門主管層級是在L6至L3 之簽則會加入指派名單, 若L4 之經理發單, 則上階部門只會取得L3(協理). 必要時利用這種設定方式可加快企業流程之進行.

如何作到一個步驟有多個參與者與批次簽核?

圖片
在AgilePoint 中要作到批次簽核的功能是一件很容易, 因為AgilePoint 是採用webService的架構, 因此要完成一個步驟只要有工作代號(WorkItemID), 逐筆呼叫api.CompletedWorkItem(WorkItemId) 就可以了. 但是要作一個通用的批次簽核要考慮的問題就比較多了, 原因是AgilePoint 沒有絕對的核準或退回, 其核准或退回只是一個流程變數等於True或False, 而變數麼名稱是可以自定的. 因此若要作到批次簽核, 首先變數名稱一定要先統一, 另外AgilePoint 支援同一個步驟可以有多個參與者, 此時核准或退回就不能單純改變流程變數, (如上圖流程變數 IsApprove, 如果每個參與者點選同意或退回都去改變他的值, 則其最後的值會由最後一個人決定).因此我們在點選同意或退回的後, 表單中可呼叫SetClientDataVerifyResult(VERIFY_RESULT VerifyResult) 其參數有 VERIFY_RESULT.Approve: 同意 VERIFY_RESULT.Reject: 不同意 VERIFY_RESULT.NoComment: 沒意見(不常用) 這些資料將會寫入每一個WorkItem 的私有的參數欄(Clientdata) 同時在流程元件設定投票的優先順序VotingPriority. 此元件設定為Approve_First 或Reject_First 會讀取 相關的WorkItem 的Clientdata 所存放的核決結果, 判斷出一個惟一的值, 並將其寫入指定的變數. 可設定的判斷有兩種: Voting Priority: 設定符合條件              Approve_First - 當符合條件時將ApproveRejectResult的變數設為True。              Reject_First -當符合條件時將ApproveRejec...

如何將Envision 改為英文界面

圖片
有些人覺得AgilePoint Envision 原來的屬性視窗使用英文介面比較容易設定, 4.0 以後採用多國語言的作法, 用起來很不習慣, 其實是可以改回英文介面的, 要將Envision 的屬性視窗 由中文改為英文, 可用Regedit修改 JKEY_LOCAL_MACHINE\SOFTWARE\Ascentn\Envision下的licd , 由十進制的1028(繁體中文) 改為 1033(英文), 則會改成英文介面.

AgilePoint 流程管理常用SQL

1. 如何清除測試機的所有資料 delete WF_EVENTS delete WF_AUTO_WORKITEMS delete WF_MANUAL_WORKITEMS delete WF_ACTIVITY_INSTS delete WF_CUSTOM_ATTRS delete WF_PROC_TRACKINGS delete WF_LARGE_TEXTS where TEXT_ID in ( select PROC_INST_ID from WF_PROC_INSTS ) delete WF_PROC_INSTS delete WF_MAIL_DELIVERABLES 2.取得指定流程資訊 select WK.WORK_ITEM_ID,WAI.NAME,WK.SESSION_, WK.STATUS,        WK.ORIGINAL_USER_ID,O_WRU.FULL_NAME,        WK.USER_ID,WRU.FULL_NAME,        WK.ASSIGNED_DATE,WK.COMPLETED_DATE,WK.RESTRICTION_TYPE,WK.CLIENT_DATA from dbo.WF_PROC_INSTS PIS,      dbo.WF_ACTIVITY_INSTS WAI,      dbo.WF_MANUAL_WORKITEMS WK  LEFT JOIN WF_REG_USERS WRU                                ...

找出系統效能問題的第一步—資料庫的效能

圖片
AgilePoint 的系統架構是IIS 上的一個Application, 因此通常其效能問題的發生的原因通常與一般網頁的應用程式相同, 因此在追查系統效能上, 最常發生的問題是發生在資料庫存取的問題上. 通常資料庫的效能問題, 常出現的問題在於SQL 的執行計劃(Execution Plan), 目前不論Oracle 或SQL Server 都是採用Cost-Base , 也就是依照資料的筆數與分佈的情形計算各種執行計劃的cost, 來決定用那一鍵值或那一種方式讀取效率最高. 因此在處理資料庫效能問題上, 通常程序如下: 1. 以SQL Profiler 找出使用IO量最大的SQL: 2. 先點選檔案新增追蹤 3. 無特殊目的可採用預設的選項, 並設定存放的目錄檔案名稱 4. 點選執行後系統會開始搜集系統的效能數據, 可特別注意兩個欄位CPU 與Reads, CPU 表示執行這段SQL 所耗費的時間, Reads 表示讀取冊數, 如果Reads 的次數很高, 通常需要分析這段SQL 是否有問題. 進一步的分析, 一個簡單的方法是將這段SQL 拿到SQL Server Management Studio , 可將此SQL 開啟一個新的執行視窗, 貼上SQL 後, 可點選顯示估計執行計劃, 則SQL 下方會顯示其評估的結果. 可將執行計劃儲存為檔案交由資料庫的專家分析. 或可點選執行計劃之單一節點, 觀察其採用的執行計畫, 特別注意其估計的資料列數目與認知中應有的實際數是否有極大差異, 我們曾遇過設定正確, 可是統計確是錯誤的狀況, 原因不明,因此即使設定正確, 亦要根據執行計劃的估計比數判斷是否有問題. 若有較大的差異可能是資料庫經過大量資料異動後, 資料庫的統計值不正確所導致, 可檢查自動更新統計資料是否設定為True. 並且注意這個自動統計參數的設定可分為資料庫層級, 資料表層級 亦可點選單一Table 的統計資料, 檢查其上次更新時間,若上次更新後有大量刪除或轉檔則可能是造成統計值的錯誤. 若要快速更新統計值, 可執行 USE 指定資料庫 EXEC sp_updatestats

如何動態決定下一個步驟的逾期時間?

圖片
在流程中有時需要動態決定下一個步驟的時間, 常見情境如案件可分一般件, 急件,特殊件…每種案件逾期的時間都不一樣, 又如工作交辦, 需於特定日期前完成, 超過則為逾期,目前預設的時間限制, 可設定時間長度及單位, 同時長度部份可以是一個變數, 對於第一種情境可以在表單上依案件類別找出對應的時間長度, 將其指定至流程變數, 下一個步直接指定時間長度的變數.但對於第二種的情境則無法以這個方法解決. 且這種作法並無法達到較好的元件化的概念 因此對於動態流程逾期的時間最好的作法是在AgileWork 中直接依設定逾期的時間, 配合AgileWork 參數化的設計概念, 在我們提供的AFAgileWork 中, 我們提供多種逾期時間限制的選項, 設定時可點選AdvancedTimeSpan(進階逾時控制), 預設為無作用. 1. 依案件別, 直接指定各種案件逾期的時間長度與單位. 選擇ByCondition(依條件決定逾期時間), 並依需要決定是否勾選Business hours, 以決定是否依工作曆計算. 下方列表的部份則設定各種逾期的條件, 如所列出的條件皆不符合時則採用預設的工時限制. 2.直接指定逾期時間 若逾期的時間是由前面步驟的人直接指定, 則可將其存入指定的流程變數, 於進階時間限制(Advanced TimeSpan)中直接指定存放逾期時間了流程變數. 設定限制型態為指定時間(Specify DateTime) 指定逾期時間變數,格式為dateTime 並可設定 之後或之前多久為逾期時間. 若指定的時間格式無效, 則會以預設的工時限制為逾期時間.

辦公室學不到的36件事:做管理,你準備好了嗎?

圖片
作者: 黃明耀/著 出版社: 華立文化 出版日期:2004年02月01日 ISBN:9867582071 全書分為 5大篇, 管理上司篇, 管理員工篇, 管理團隊篇, 管理自我篇,管理異術篇, 共36個短篇故事. 作者以輕鬆詼諧的筆法, 用說故事的方式來談論管理的議題. 其中我最喜歡的一篇是”等待指示的一代”, 談論的是新進員工與資深主管間認知的衝突, 其中有一段是談到如果不去花時間了解每個人的能力,性格, 而只看到它們的缺點, 又如何能期待他們能對工作有熱情呢?值得四五年級的管理者深思. 又有一篇活用下屬的短處, 談論的是一個人的特點, 很多事情如果只看到缺點的一面, 可能會認為一無是處, 但若換個方向來看可能會變成優點, 如果能發揮個人的特質, 活用短處, 最後缺點也可以變成強項, 一個小氣,對金錢斤斤計較的人, 如果用來管理財務, 可用效率會很高,一個吹毛求疵的人如果去作品管, 產品的品質可能會提高, 謹慎小心到神經質的人, 如果去管工安, 可能減少事故發生.

孫悟空是個好員工:勇闖職業生涯的28個成功箴言

圖片
作者: 成君憶/著 出版社: 臉譜 出版日期:2004年11月24日 ISBN:9867335058   本書是以管理的角度, 重新詮釋西遊記, 西遊記這個取經的過程就像是一個專案的管理, 在這個專案裡有4種不同的性格, 完美型, 力量型, 活潑型, 和平型, 這不正是一個團隊的縮影, 這個專案正如眾人所知的結案了, 但是過程中確是衝突不斷, 透過管理學的眼光來詮釋, 令人有更深刻的體會

一分鐘經理

圖片
作者: 史賓賽‧強森、肯.布蘭查/著 譯者: 李毓昭/譯 出版社: 晨星 出版日期:2004年11月25日 ISBN:957455774X 一分鐘經理的內容是以故事的方式說明一個年輕人想要尋找何謂成功的經理, 因此到處拜訪個種的經理人, 最後找到了人稱一分鐘經理的管理者, 向其學習一分鐘管理的祕訣.

位位出冠軍

圖片
  作者: 蘇國垚、劉萍/著 出版社: 天下文化 出版日期:2004年09月17日 ISBN:9864173685 這本書一開始, 我是由圖書館借來的, 由於內容值得一看再看, 因此買回來收藏. 蘇國珪是前亞都麗緻的總經理, 本書是以真實故事的方式說明服務與管理. 這本書裡我看到一個成功的人本身的執著與專注, 正如本書的標題每個位置的人, 只要認真作好份內的工作,都可以達到冠軍, 都是一種勝利.

建構BPM-Enable 的應用系統(下)以固定資產管理為例

圖片
一個企業標準作業程序(Standard Operation Procedure)可分為兩部份,作業流程及傳遞的資訊(資訊管理),傳統的資訊系統主要是在處理流程中的資訊部份,作業的流程中的每一個環節是由人來銜接,也因此產生許多不便與容易產生弊端,或許也有人稱為彈性,但對一個成熟的企業說,如何讓作業更標準化但又保留必要彈性成為一個很重要的課題。 新一代的BPM-Enable 的應用系統,建構的基本原則在於保留應用系統原本該有的功能,在加上以自動化的程序,取代原來靠人傳遞資訊的作業,因此簡單的說就是以BPM 平台來建構應用系統,為了加強讀者的理解,再此我們以新一代的BPM 平台AgilePoint來說明,何種的BPM 平台適合建構BPM-Enable的應用系統。 前面我們提到一個企業的企業標準作業程序(Standard Operation Procedure)可分為兩部份,作業流程及資訊管理,因此再建構一個BPM-Enable 的應用系統時,亦需滿足這兩方面的需求。 資訊管理: 傳統的應用系統主要的功能在於資訊管理,因此常需要呼叫或引用其它系統或廠商所提供的元件,對於一般資料處理或系統整合的能力要求較高,轉換至BPM平台上開發應用系統時,相較於一般工作流程(Workflow)所使用的電子表單更覆雜,原既有的需求必需要能夠滿足,因此在流程平台所使用的表單或元件必需要使用一般的程式語言開發如Java或.net,而非僅是單純的表單設計工具就能滿足,使用一般程式語言,一方面可保持程式開發的彈性,另一方面亦可減少企業內部同仁進入的障礙。 AgilePoint強調表單與流程引擎分離的概念,不僅是表單可使用Asp.net 開發,並且提供完整的WebService API , 因此亦可透過其它語言開發表單或其它外部系統透過Web Service API 與AgilePoint 整合. 除了表單以外,AgilePoint 亦強調元件化的整合觀念,對外部系統或內部處理的邏輯,都可以作成獨立的元件,而這些元件都可以使用.net 來開發,或透過Dot.Net 呼叫其它系統所提供的服務,因此再流程開發時亦可採用物件導向的流程開發方式。 流程管理 BPM-Enable 的應用系統除了資訊管理外,另一個重點在於流程整合的範圍,不同於一般的電子表單,只是在於單一表...

建構BPM-Enable的應用系統(中)-以固定資產管理系統為例

圖片
前言 在前一期電子報中,我們談到以BPM 平台建構應用系統與一般的應用系統的差異, 在這一期的電子報中, 我們將以固定資產管理系統為例,來說明BPM-Enable的固定資產管理系統有那些特點,以及如何將BPM的特性發揮於應用系統中。 企業流程與應用系統 一個企業資訊處理的業務,不外乎是處理的過程與處理結果的管理,以固定資產的管理業務來說,處理過程亦即簽核流程,處理的結果亦即存放在資產管理系統的資料及後續的資料處理系統。 其內容包括下列項目: l 簽核流程(資產新增、處分、調撥、增減值…等流程) l 資產管理(資產新增、處分、調撥、增減值…等結果的記錄與管理,以作為後續折舊、盤點…等作業之依據. 傳統的固定資產管理系統,著重於資產管理部分, 系統之主要使用者為財產管理人,簽核流程部分大部份企業採紙本簽核後再由財產管理人將資產相關資料登錄至資產管理系統,亦有部份企業採用電子表單簽核方式。 採用電子表單簽核與固定資產整合的方式取決於表單簽核平台的技術及固定資產管理系統所提供的應用系統整合介面(API)。 一般而言,若表單簽核平台採用開放的技術且固定資產管理系統提供足夠的API,兩者之間的整合可能會比較完整,否則仍需由人工輸入表單簽核的結果或僅能將最後的結果寫入應用系統資料庫,簽核表單上資料的來源,仍以資料輸入為主。 BPM-Enable 的固資管理 BPM-Enable的固定資產管理系統,可包含兩部份: u 資產管理的功能:此部份的功能需具備與一般程式語言(.net、Java...)開發的固定資產管理系統相同。 u 簽核流程 整合:包括資產新增、處分、調撥、增減值…等流程,簽核資料來源為固定資產的資料庫,採用選取的方式,而非自行輸入,若輸入的資料需執行業務邏輯的檢核,這些規則不論管理或簽核流程皆應來自同一個驗證的模組,以避免重複資料建檔或規則重複維護,簽核結果需回寫固定資產資料庫。 因此在一個BPM-Enable 的應用系統中,亦可採用物件導向的設計模式。 除上述兩項基本功能外,亦可運用流程平台的特性,整合主動式的資料管理作業,包括: u 資產保管人異動檢核 Ø 定時自動比對組織資料庫與資產資料庫之資產保管人員、部門差異 Ø 當資料不一致如人員已離職或調部門,可自動通知保管人或財產...

建構BPM-Enable 的應用系統(上)

一、前言 在討論BPM-Enable 的應用系統之前我們先對BPM及BPM Enable 有個初步的認識。 何謂BPM BPM就是把所有業務流程中涉及的資源包括人與應用系統都連接起來,以保證工作流程無縫執行,並更有效率。 把業務流程中的控制部分提取到業務流程層,這樣它就可以重新建模、重複使用,從而協調所有的人員、應用程式和系統元件,達成更高效率的工作。 何謂BPM-Enable的應用系統 BPM-Enabled 的應用系統簡單來說就是應用BPM平台來開發應用系統。 並將應用系統切割為一個個的服務元件,再以BPM的平台來整合或串連這些元件 以一個企業中跨應用系統來說,BPM 可應用於系統與系統間,服務或程序的整合,在單一應用系統內部,亦可用來整合內部的服務元件。 簡單的來說就是以流程平台取代原來應用系統人工銜接的工作,因此BPM Enable 的應用系統可以說是運用BPM 平台的特性,建構應用系統。 二、建構BPM Enable 的應用系統 應用系統開發通常分成線上交易與批次處理兩種模式,在大型主機的時代,線上的程式雖然使用者介面不是很豐富,但亦能滿足使用者的需求,對於批次處理的系統,因為通常大型主機都具有背景處理的機制,因此具有良好的解決方案。 主從式的架構下,前端具有完整的使用者介面,但對於批次處理的能力較為薄弱,但仍能達到某種程度的要求。 但因每一台電腦皆需安裝客戶端的程式,因此很快的就被Web 化的應用系統所取代,Web 化的應用系統具有優良又豐富的使用者界面,同是又因為只要有一個Browse 就可操作系統,可享受服務無所不在的便利性,但是對於批次的處理並無較好的解決方案。 BPM Enable 的應用系統不只對於線上交易的系統,具有良好的架構,對於批次處理的作業,將其設計成流程的元件,組合成一個自動化的流程,是一個最佳的解決方案。 傳統Workflow-enable 的應用系統,Workflow 的應用範圍大多是應用在表單傳簽或審核上,對於應用系統自動化作業如批次交易並未具有良好的解決方案,因此應用的範圍並不是很廣。 一個BPM-Enable 的應用系統不僅可以作到人工表單輸入審核的作業,並因為在一個BPM的系統中,人工作業(Manual activity)與電腦自動化的作...

企業流程管理新思維

圖片
BPM- 下一代資訊技術發展的藍圖 前言 在過去這兩、三年,我們在推廣BPM的過程中,我們感受到不論是客戶或者是友商,都極力在推廣企業流程管理(Business Process Manager,BPM)以取代傳統的工作流程(Workflow),但是到底什麼是BPM與傳統的Workflow有什麼不同則是我們常常被客戶提出的質疑,也常收到一些客戶或者是一些專業媒體的BPM功能調查表(Suvery Form),但是觀察其內容多半是傳統Workflow的功能,如能不能動態加簽、能不能跳關.....等等的功能描述,加上有沒有支援Web Service、有多少的系統整合配接器(Adaptor),這些功能當然是BPM應該要有的功能,可是難道Workflow 或傳統程式就作不到嗎? 目前市場上有幾種的迷思包括: BPMS 只不過是Workflow 廠商的舊瓶裝新酒。 WorkFlow加上系統整合的Adaptors就變成BPMS EAI廠商加上Activity Modeling的工具或者是Routing Engine重新包裝一下,也可以稱作BPMS BPM 是不是等於 Workflow+EAI 正因為這樣的迷思,某些產品宣稱,傳統的Workflow 是一張表單的流程,而只要可以整合流程中的多張表單,例如請購、採構、驗收、付款,這些表單的流程能夠串連起來,就是一個BPM的系統。 有些使用者會說程式沒有作不到的,基本上這句話是對的,因此我們可以說就功能面來看BPM 可以有的功能,Workflow 也都可以作到,但是重點在於要達成這樣的功能,需要花多少的成本、多少的時間,更何況BPM對一個企業在價值面的功能是傳統應用程式或Workflow所無法作到的。 我們也常接觸一些曾經用過Workflow 的客戶,想要找一套BPM但又怕買到一套Workflow,因此我們也試圖建立一個BPM應該具備的功能的功能查檢表,協助資訊單位的同仁,找到適合自己的解決方案,在查檢表中並非每個項目都是必備的,端看企業本身是否有此種需求。 在BPM的導入精神中,希望讓流程設計的工作讓Business User 也能參與流程的規劃,因此常常會有Business User 質疑是否可以達成,在現階段也許還無法實現,但是至少以目前BPM的開發模式可以讓IT主管人員系統析人員...