【正文】 觀圖形方式顯示的訂單行流程狀態(tài)。需要指出的是，并非所有業(yè)務流程類表單都要采用類似銷售訂單的“工作流”處理方式，例如“采購訂單”的處理等。系統(tǒng)應用模塊是否使用、如何使用“工作流”技術(shù)，與具體的業(yè)務實踐以及采用之的優(yōu)缺點取舍有很大關(guān)系，不能一概而論。從系統(tǒng)開發(fā)設(shè)計的角度來看，盡管“工作流”于技術(shù)層面并不難掌握，但要與業(yè)務實踐實現(xiàn)很好的結(jié)合則并非易事。目前國內(nèi)主流產(chǎn)品基本都宣稱具有“工作流”技術(shù)，但真正在系統(tǒng)核心業(yè)務流程中用得比較好的并不多見，大多只是在“單據(jù)審批”或非核心的事務處理型業(yè)務諸如“費用報銷”等領(lǐng)域中有所應用。此外，在EBS中有關(guān)“單據(jù)審批”的工作流應用只是“單據(jù)審批”的系統(tǒng)實現(xiàn)方式之一。為滿足企業(yè)的復雜業(yè)務環(huán)境的需要，結(jié)合工作流技術(shù)，系統(tǒng)還專門提供了一個審批功能更為強大且相對獨立的引擎模塊“審批管理”（AME）作為“外圍產(chǎn)品”供企業(yè)選擇使用。(待續(xù))十一、預警（Alert） 今天在企業(yè)的辦公場所或酒店的房間等很多地方，我們都可以見到天花板上裝有“煙感報警器”以及“自動噴淋器”，國家對建筑物的消防安全有明確的法律法規(guī)，因此這些“報警或滅火”裝置幾乎已成了建筑物的標準配置。與之類似，預警平臺對于今天的ERP系統(tǒng)來說也幾乎是一個標準裝備，無論是從系統(tǒng)實現(xiàn)角度還是從業(yè)務應用角度來看，它都不是很復雜，比較容易掌握。 ORACLE 的系統(tǒng)預警分兩種方式，一是“事件預警”，二是“周期預警”。兩者的基本工作方式均是使用SQL Select語句基于對數(shù)據(jù)庫中的相關(guān)值作出條件判定，以決定是否執(zhí)行某種活動（發(fā)出信息，執(zhí)行并發(fā)程序、執(zhí)行操作系統(tǒng)程序、執(zhí)行SQL語句）。更進一步，對于“發(fā)出信息”類預警，系統(tǒng)在收到對此信息的符合規(guī)定格式的“回復”后，還可以據(jù)此自動執(zhí)行相關(guān)活動并完成相關(guān)事務處理。所謂“事件預警”，即當用戶在相關(guān)數(shù)據(jù)表中“插入”或“更新”某些值時，系統(tǒng)自動啟動已定義的“SQL Select語句”的檢查，已確定是否需要發(fā)出預警信息或執(zhí)行某種活動，如下圖33所示的一個事件預警定義：在采購管理系統(tǒng)模塊中，當出現(xiàn)一個巨大數(shù)量的申請行數(shù)量被輸入時，系統(tǒng)需要向相關(guān)責任人發(fā)出預警通知（以提醒諸如做好資源準備等）。 所謂“周期預警”，即系統(tǒng)按照事先定義好的周期間隔或頻率，自動啟動已定義的“SQL Select語句”針對數(shù)據(jù)庫中表的某些值作檢查，已確定是否需要發(fā)出預警信息或執(zhí)行某種活動，如下圖34所示的一個周期預警定義：在采購管理系統(tǒng)模塊中，系統(tǒng)按每兩個工作日的間隔頻率對所有“一攬子采購協(xié)議BPA”的到期情況進行檢查，并將需要關(guān)注的檢查結(jié)果（例如某些BPA將在一周之類過期）通知到相關(guān)責任人。十二、應用開放接口（Open Interface and API） 任何ERP系統(tǒng)都無法做到在任何情況下都能滿足企業(yè)實際使用的各種要求，企業(yè)有時可能需要從其它來源向系統(tǒng)中批量輸入數(shù)據(jù)，如從物料的Excel電子數(shù)據(jù)表格向EBS的INV系統(tǒng)導入Item信息等等，或者需要與其它第三方應用系統(tǒng)建立業(yè)務數(shù)據(jù)的交換機制，如從專用的“費用報銷或發(fā)票申付”管理系統(tǒng)向EBS的AP系統(tǒng)導入事務處理數(shù)據(jù)并將事務處理執(zhí)行結(jié)果反饋回來源系統(tǒng)等等。理論上，使用相關(guān)數(shù)據(jù)庫工具可以向數(shù)據(jù)庫的數(shù)據(jù)表中直接批量寫入數(shù)據(jù)，但這樣做無法對寫入的數(shù)據(jù)進行正確性、合規(guī)性校驗，無法保證寫入數(shù)據(jù)的質(zhì)量以及對存在問題進行有效管理。為此，ORACLE提供了接口表Interface Table作為“中間表”過渡，并在此基礎(chǔ)上，根據(jù)某些業(yè)務需要提供業(yè)務視圖Business View，以便對導入的數(shù)據(jù)進行修改、更正、重新導入等等管理。如下圖35所示“Open Interface Diagram”：更進一步，ORACLE將某些數(shù)據(jù)的導入導出功能進行封裝，成為一個應用程序可以調(diào)用的接口（API），以實現(xiàn)在各模塊之間以及內(nèi)部模塊與外部系統(tǒng)之間的數(shù)據(jù)與流程集成。如下圖36所示“Open Application Programmatic Interface（API）Diagram”：開放接口（API）的基本工作模式分為兩個階段：一是先將來源數(shù)據(jù)裝入（Load）接口表。如果是在兩個應用系統(tǒng)之間，這通常是由專用的裝入程序完成，例如EBS內(nèi)部采購申請要轉(zhuǎn)成內(nèi)部銷售訂單，需先運行“創(chuàng)建內(nèi)部銷售訂單流程”，以便將內(nèi)部采購申請發(fā)送并插入訂單管理系統(tǒng)的接口表。如果是從某些電子表格如EXCEL等導入，則需要先使用專門的SQL*Load工具將數(shù)據(jù)格式轉(zhuǎn)換后直接插入相關(guān)接口表，例如要通過物料的EXCEL數(shù)據(jù)表直接批量裝入Item數(shù)據(jù)，必須先通過SQL*Load工具如DataLoad等將來源數(shù)據(jù)插入Item數(shù)據(jù)接口表。在將數(shù)據(jù)插入接口表的過程中是否對數(shù)據(jù)進行校驗（或是在將接口表數(shù)據(jù)導入正是表時再校驗），取決于系統(tǒng)各應用模塊的不同設(shè)計；二是系統(tǒng)將存在于接口表中的數(shù)據(jù)導入正式的業(yè)務數(shù)據(jù)表，如EBS訂單管理模塊的“訂單導入”，庫存管理模塊的“導入Item”等等。在從接口表導入“正式表” 或數(shù)據(jù)裝入“接口表”過程中因數(shù)據(jù)校驗而產(chǎn)生的錯誤或失敗信息，如系統(tǒng)提供專門的業(yè)務管理視圖，則可以在其中進行查看、更正、重新提交，如EBS的“訂單導入更正”窗口等。如系統(tǒng)未提供管理視圖，則可以在并發(fā)程序請求的“輸出”文件中查看結(jié)果。下圖37所示“應付款管理模塊費用報表類發(fā)票導入流程圖”是一個典型的應用過程示例：十三、結(jié)語我們經(jīng)常見到有些國內(nèi)產(chǎn)品在宣傳中，總是喜歡嘲諷國外產(chǎn)品如SAP已經(jīng)是“老古董”，刻意強調(diào)自己的技術(shù)是如何先進、平臺是如何創(chuàng)新等等這些于企業(yè)應用實踐其實相距甚遠、華而不實的東西，而在產(chǎn)品研發(fā)過程中，卻忽略了于企業(yè)信息化實踐更為重要的基本元素與應用基礎(chǔ)的研究。這就好比賣房子的開發(fā)商總是賣弄自己造房子的鋼筋質(zhì)量是如何好、水泥標號是如何高、施工所用的機械設(shè)備都是進口的等等，問題是這些與買房人真正所關(guān)心、所需要的“戶型結(jié)構(gòu)、空間適用以及小區(qū)配套”等又有多大關(guān)系呢？技術(shù)的進步無疑會對企業(yè)管理實踐中的組織形態(tài)、業(yè)務模式等諸多方面產(chǎn)生重大影響，管理作為一門“科學”而誕生的這近一百年來，企業(yè)管理實踐從早期的“職能管理”到現(xiàn)代的“流程管理”，從早期主要內(nèi)向關(guān)注“生產(chǎn)效率”到現(xiàn)代重點外向關(guān)注“客戶需求”，技術(shù)的進步尤其是近二十年來信息技術(shù)的飛速發(fā)展起到了重要的推動作用。但管理科學畢竟是屬于“形而上”的范疇，相較于“形而下”的器物層面，技術(shù)進步的作用與影響方式總是承前繼后、繼往開來而非顛覆性的?；仡橲AP R3或ORACLE EBS過往十多年的發(fā)展歷史與演化進程，我們可以發(fā)現(xiàn)，系統(tǒng)開發(fā)設(shè)計人員于早期階段就融入軟件的那些于企業(yè)核心業(yè)務運作所至關(guān)重要的管理思想、業(yè)務模式等核心內(nèi)容并未過時，它們今天依然是支撐企業(yè)高效運作的核心與基礎(chǔ)，并且它們也在隨著時代的發(fā)展而與時俱進、不斷得到充實與完善。管理軟件從三十年前的主機時代，到二十年前C/S架構(gòu)的客戶機/服務器時代，再到十年前開啟的B/S架構(gòu)的互聯(lián)網(wǎng)時代，軟件具體技術(shù)的發(fā)展較之于信息技術(shù)整體進步對企業(yè)管理實踐的影響，總的來說還是局部的、非決定性的。今天大概不會再有人相信“管理軟件從C/S架構(gòu)進化到B/S架構(gòu)是企業(yè)管理實踐的一場革命”這樣的夸大其辭，、Java平臺、私有的ABAP平臺等等這些純技術(shù)領(lǐng)域的開發(fā)工具對于管理軟件中所蘊含的管理思想、業(yè)務流程模式能有多大影響。喜歡看美劇的人或許經(jīng)常可以在片中看到美國紐約于上世紀三十年代初期所建造的兩座美輪美奐的標志性大廈：克萊斯勒大廈（77層）和帝國大廈（102層）。八十年前的技術(shù)條件與工具手段和今天簡直沒法比，但我們今天能說它們已經(jīng)落后、不是“現(xiàn)代化”的大廈嗎？有誰知道克萊斯勒大廈還是世界現(xiàn)存最高的“磚體”建筑呢！ 人類的認識總是從已知的東西逐步推展到未知的領(lǐng)域。如果我們暫且拋開系統(tǒng)具體的業(yè)務流程、功能應用以及操作細節(jié)不談，僅針對前述ORACLE EBS系統(tǒng)的11個基本組成元素，從實踐來源與系統(tǒng)實現(xiàn)兩方面，作并非詳細深入但比較直觀概要的探討，我們也許就能獲得這樣一個總體上的認識，即無論多么龐大、復雜的一個軟件應用產(chǎn)品體系，它仍然是由一些使用比較簡單、理解并不深奧的基本構(gòu)件所組成。這些基本構(gòu)件來源于業(yè)務實踐或與日常工作息息相關(guān)，我們其實并不陌生，它們是“從業(yè)務到技術(shù)，再從技術(shù)回到業(yè)務”兩者高度融合的結(jié)晶體，也是神妙莫測、不可捉摸的代碼空間通往紛繁復雜、多姿多彩的真實世界的橋梁。大多數(shù)情況下，對于普通的EBS系統(tǒng)用戶而言，結(jié)合自身的業(yè)務，掌握了上述十多個基本元素中前幾個，例如表單、查詢、事務處理、文件夾以及報表類并發(fā)請求等，就足以可應付一般的日常工作；而對于系統(tǒng)實施、維護人員來說，相對而言后幾個技術(shù)味較濃的基本元素，諸如并發(fā)處理、彈性域、配置文件、工作流等則可能是工作的重點與難點。但需指出的是，本篇有關(guān)系統(tǒng)基本組成元素的介紹，只是起到一個幫助初學者打破神秘、入門引路的作用，進一步深入掌握系統(tǒng)還必需結(jié)合ORACLE EBS的具體測試環(huán)境，對照單調(diào)抽象、枯燥乏味的海量應用幫助文檔，進行大量的、艱苦的、耐心細致的學習研究，絕非一朝一夕之功。關(guān)于EBS系統(tǒng)的具體測試環(huán)境，對于今天即使普通配置的計算機來說，安裝與使用也基本不是問題，網(wǎng)上有大量圖文并茂、詳盡細致的安裝幫助文檔可供參考。而ORACLE系統(tǒng)官方的應用幫助文檔，針對每個模塊則主要有三種：Implementation Guide（實施指南），User Guide（用戶指南）以及online help（在線幫助）。這三種文檔基本上也是顧問、實施人員需經(jīng)常用到的工具書。碼字到這里，突然想起一位資深ORACLE 顧問喜歡在其文章封面中引用的亙古勵志名言，這里且搬來與大家共識、共勉：