基于IBM BPM的上汽大眾技術更改管理平臺的設計和實現

游為建 項建英

(上汽大眾汽車有限公司 上海 201805)

基于IBM BPM的上汽大眾技術更改管理平臺的設計和實現

游為建 項建英

(上汽大眾汽車有限公司 上海 201805)

隨著汽車行業新產品更新換代周期的縮短，汽車設計和工藝等方面不斷發生變化，技術更改的頻率和范圍越來越多。以上汽大眾為例，一個復雜技術更改有可能要牽涉到數百工程師相關技術工作，傳統的管理方法面臨一系列效率和標準化管理問題。針對這些問題，創新性地提出采用基于IBM BPM的遞歸流程和郵箱管理的集分發、表態、審批于一體的多部門技術更改管理平臺。詳細介紹了該平臺的系統架構，基于遞歸流程的系統方案設計、部門郵箱及權限設計和關鍵方法的實現。上線后成功運行，大大提高了技術更改的管理效率，有力地支撐了整車零件的開發和管理。

技術更改 零件 遞歸流程 IBM BPM 郵箱

0 引 言

隨著汽車行業愈演愈烈的競爭現實，各大車企必須快速推出滿足市場需求的新車型，甚至是定制化車型以期占有更多的市場份額。車型成倍增長，開發周期極度壓縮，零部件變更異常頻繁，機構部門龐大繁雜，工程師人員眾多更迭快，是目前車企所面臨的共同問題。

零部件技術更改即技術方面的更改，是指企業在產品設計和制造等全生命周期中, 由于企業內部或外部的需要, 對產品設計或工藝、相關文檔、組件或裝配、自制件或外購件、生產過程甚至供應商等的一系列更改[1]。技術更改管理即通過建立嚴格的更改業務流程, 在手工或計算機工具支持下, 使更改活動始終處于嚴格的可控狀態, 并記錄更改涉及的所有對象的變化, 保證相關信息的一致性和完整性[2]。同時，為了達到嚴格控制技術狀態更改的目的，對于研發和批產狀態的零件技術更改，需采用不同的流程進行處理[3]。上汽大眾每年30個車型左右，單個車型涉及零部件1 000～4 000個，涉及從產品規劃、技術開發、采購、財務、質保、物流各個核心部門的數千工程師；單個零部件技術更改可涉及多個車型的多個零部件，有的更改甚至涉及幾百個零部件；單個技術更改涉及的工程師近一千，由零部件技術更改引發的制造工藝、模具設計、供應商、質量控制及物流控制均會發生相應調整。目前業內還沒有一個很好的系統化平臺來有效管理和支持零部件的技術更改。

本平臺經歷了長期的與一線員工的需求訪談，與IT技術專家的技術方案討論，最終確定了基于IBM流程引擎產品BPM實現技術更改平臺Java應用，設計了一個多層遞歸的適合所有部門對于研發和批產狀態不同流程的系統框架，通過一系列參數配置即可完成新部門的流程配置，能大大減少代碼開發量，增加程序可用性和靈活性；在傳統流程處理的“個人任務”的基礎上融入部門管理節點，這里稱之為“郵箱”的概念，將部門與“郵箱”融合，達到部門與人員更改不影響流程的目的；部門級權限控制，能合理控制各部門的數據和功能權限，部門管理員自行配置，最大地體現系統自由度。整個平臺能適應多部門各異的技術更改流轉需求，最大程度減少人為工作量，快速處理日益增長的技術更改單據，大大提升各部門的工作效率。

1 需求現狀

本平臺涉及公司八大部門29個科室的技術更改信息流轉，其各自流程各異。需求現狀主要從三方面入手，技術更改主數據，各部門流程需求和跨部門統計需求。技術更改的車型、零部件數據來源于車企的車型項目管理或者BOM(Bill of Material)管理系統，人員信息來源于企業SAP等系統，本技術方案的流轉的目標為車企內部的零部件技術更改，如下將默認這些數據已經在本平臺中。

1.1 技術更改主數據現狀

零部件技術更改包括零件的材質，尺寸，加工方式，加工地點，工藝及質量改進，成本控制等方面的變化。特點如下：

(1) 車型零部件范圍：單個技術更改涉及多個車型多個零部件，有的單子涉及幾百個零部件的更改,每個更改均需得到相關部門相關工程師的所有表態，并得到相應部門領導的審批認可。

(2) 表態時間要求：單個技術更改一般需要在2周內完成所有部門的表態意見收集。

(3) 單據數量規模：每個部門涉及的需要表態審批的技術更改單據數量不一，平均每年每部門有10 000個左右，并以20%左右每年的速度遞增。

(4) 涉及工程師數量：單個單據表態審批涉及近1 000名工程師經理參與表態審批，其表態時間要求短，人員變動大，各部門流程復雜各異導致目前的人工分發審批表態模式根本無法滿足日益增長的車型量需求。

1.2 各部門技術更改流程需求

本期平臺完成了囊括產品規劃、技術開發、質保、物流及樣板等多個核心部門技術更改流程。由于篇幅限制，無法對每個流程詳細描述，下面將挑選代表部門進行流程簡單介紹。如下流程描述中，“科長”即科室經理；“股”是 “科”下的子機構，“股長”是“股”負責人； “車型負責人”是指定科室部門某個車型的負責人； FOP即Father of Parts，零件父母官，也就是工程師，一般產品開發部門的工程師簡稱為FOP。

1) 沖壓規劃科技術更改流程現狀

沖壓規劃科是負責公司所有車型自制件的規劃、設計，沖壓生產線及設備的規劃管理的一個科室。其流程分四級，規劃部負責人分發到沖壓規劃科負責人，再根據車型選擇分發給不同的車型負責人，最后分發到工程師進行表態。工程師表態后交由自己的股長進行審批，最后匯總到沖壓規劃科負責人，匯總表態后交由科長審批，審批通過后自動提交到規劃部，分發和審批均涉及退回、轉派、補分發等操作。具體流程見圖1所示。

圖1 沖壓規劃科技術更改流程現狀

2) 電器工程科技術更改流程現狀

電器工程科是分管所有車型電器零部件及測試的大型開發部門，其人員眾多，部門龐大，涉及的技術更改數量也多。電器工程科的流程是由負責人根據零部件號碼規則直接分發到FOP，FOP表態后提交股長、項目協調、項目經理和外方經理進行多級審批后匯總回電器工程科負責人處，由其向公司統一匯總部門內部意見。具體流程見圖2所示。

圖2 電器工程科技術更改流程圖

由上述流程描述可以看出，不同科室部門由于各自職能不同，其流程也各不相同。一般都是多級分發，多級審批后匯總，存在會簽，搶單的情況，相應流程都存在補充分發，撤回，退回等操作。

1.3 跨部門數據統計需求

鑒于技術更改審批時間的緊迫性，統計跟蹤當前流程的流轉情況就變得異常重要。目前的手工模式采用email、電話的方式人為跟蹤，工作量極大，對于轉派、退回后重新分派的人員更難跟蹤。另外，公司內不同部門之間需要互相查看其他部門的表態意見以作參考。由此可見，三類統計需求顯而易見：

(1) 各部門流程詳細明細圖：涉及流程實際流經的每個人，包括收到日期，應答復日期和實際答復日期，以及相關答復意見。

(2) 各部門按人員統計任務準時完成率圖：包括時間段內應答復任務數，超期答復任務數，準時答復任務數，超期未答復任務數等。對部門內部考核有至關重要的作用。

(3) 多部門任務準時完成率圖：按部門統計任務的各個狀態的數量，便于部門間比較，針對瓶頸部門進行流程改進。

2 平臺軟件結構

本平臺基于IBM BPM上進行定制化Java開發，采用B/S架構模式設計。軟件功能結構視圖如圖3所示，邏輯上定義了Web訪問層、業務邏輯層、公共支持層、數據庫層和接口層，整體框架采用Spring MVC(模型-視圖-控制器)框架實現，各層應用功能的核心技術概述如下：

(1) Web訪問層：Web應用層提供用戶訪問平臺的界面，采用以瀏覽器( Browser， 如IE等)為基礎的瘦客戶端。頁面采用JSP+jquery作為頁面實現技術核心，通過服務總線將服務層以Web 服務和REST(REpresentational State Transfer)風格接口暴露出來，用以與外部系統進行服務于資源交互。

(2) 業務邏輯層：采用基于Spring Framework 提供的輕量級IOC 容器，結合面向方面編程技術(AOP)[4]，完成業務框架功能搭建；使用Mybatis技術提供基本數據訪問服務，MyBatis框架集合多種操作型關系數據的概念和方法，它是一個強大的數據訪問工具和解決的方法[5]。Spring MVC及MyBatis架構的整合，能將Web系統中的表示層、業務層和邏輯層有效地分開，從而有利于Web系統的整體維護和升級[6]。

(3) 公共支持層：BPM REST組件，是用 REST服務實現的API與Java的交互。IBM BPM提供了一組豐富的REST API，用于訪問業務流程、人工任務、業務類別數據等資源。這些REST API允許開發人員構建自定義的客戶端或定制門戶應用程序進行流程管理，同時REST API也使得開發BPM移動應用成為可能[7]。采用Quartz 1.6版本實現平臺在集群環境下的定時調度程序管理。Quartz 是個開源的作業調度框架，定時調度器，為Java 應用程序中進行作業調度提供了簡單卻強大的機制[8]。采用Log4j作為平臺的日志生成框架。

3 平臺方案設計和關鍵方法實現

本平臺特點如下：(1) 多部門各異的流程采用同一個遞歸式BPM流程APP進行流轉；(2) 部門管理采用“郵箱”式管理模式；(3) 權限控制模式采用部門自配置的方式進行。下面將從這幾個方面的技術進行講述，同時對于核心實現技術進行講解。

3.1 基于IBM BPM的遞歸多層嵌套流程設計

需求分析后看出，各部門流程相對獨立，由于職能不一，無法實現技術更改流程統一模式進行。但是為各部門設計各異的流程一方面工作量非常大，因為需要配置流程的部門非常多；另一方面對于以后需要隨時追加部門進行流轉的需求無法滿足，因為需要為其配置自己的流程，變更代價大。

經過多輪討論、分析，我們利用IBM BPM設計出一個遞歸的多層流程嵌套實現方式，配合機構參數自行配置，能符合如上所有部門的技術更改流程需求，且追加部門配置簡單，只需按部門要求修改一定的參數配置即可達到配置流程的目的，代碼工作量急劇減少。這樣可以以最小的工作量滿足多部門各異的多層分發，表態，同時多層審批的功能需求，具體實現見圖4所示(BPM軟件設計圖)。

圖4 基于IBM BPM的遞歸多層嵌套技術更改流程實現

如圖4示，每級流程角色分為當前部門和下級部門，有分發、表態和審批三個階段。每級流程從分發節點開始，分發可選，根據當前部門是否有下級進行選擇是繼續進入下一級遞歸子流程還是直接進入工程師表態階段；表態結束或遞歸子流程結束后進入審批階段，審批階段包括四個可選項：股長審批、匯總、經理審批和匯總表態，分別對應不同部門流程中的特定需求。其中股長審批就是當前股的股長進行審批；匯總、審批和匯總表態，是考慮有的部門需要管理員先匯總然后再提交科長審批，有的部門則是科長先審批再由管理員匯總表態。圖5演繹了沖壓規劃科流程在遞歸模式下的實際數據流向。

圖5 沖壓規劃科技術更改流程推演

3.2 部門的郵箱化管理模式的設計和實現

傳統的流程系統將流程綁定在固有部門上，并基于部門的組織結構設計相應的流程走向；所有任務都處于每個任務人的個人任務郵箱中。這類方法有幾個缺點，一個是企業部門組織機構變更快，需要及時調整人員和規則；二是所有任務都在每個人的個人待辦/已辦任務里，一旦發生人員變動，需要有專職人員及時處理相關遺留任務；三是針對各個專業部門，不能對本部門相關專業數據做統計和管理。

本平臺采用的解決方案是設計部門管理節點，即部門郵箱，基于遞歸的嵌套子流程實現基于郵箱。郵箱的說法源于個人email賬戶，相比email郵箱的個人任務集合，部門郵箱是一個關于部門所有功能和任務的集合，是多人共享的一個操作平臺，其囊括組織機構管理，郵箱任務管理，郵箱報表統計以及郵箱自配置等功能。

1) 組織機構管理模式

圖 6是郵箱內的組織機構維護界面，可以看出，所有的子機構全部由電器工程科的郵箱管理員進行操作，每級機構均可以設置自己的管理員，管理員可以配置所屬機構的下屬員工，經理。人員變動不依賴冗長的SAP流程，直接在這里配置即可開展相應工作。

圖6 郵箱組織機構維護

2) 部門郵箱配置模式

新建部門后，需要根據部門實際情況配置相應人員，還需要根據部門實際流程配置技術更改流轉參數，配置完人員和參數后，部門即可開展技術更改流程的流轉。以電器工程科為例，圖7是電器工程科遞歸流程推演圖。

圖7 電器工程科技術更改流程推演

從流程圖可以看出，電器工程科處于第一級流程，其有下級部門，需要分發任務，無需自動分發，分發時要依據技術更改單所涉及的零件號進行工程師分配，本級經理需要審批，且本級管理員需要匯總表態。這些參數均在部門配置表如表1中進行設置。其下級機構如項目經理層，股層再根據實際的流程走向設置自己級別的對應參數即可完成整個部門流程參數配置。

表1 部門配置表

完成部門配置的核心代碼如下：

//創建部門并初始化部門配置參數

public int createDepart(Map createParams) {

//獲取部門名稱

final String SHORTNAME = (String) createParams.get(Constants.SHORTNAME);

final String FULLNAME = (String) createParams.get(Constants.FULLNAME);

//獲取當前創建部門的父部門

parentId = (String) createParams.get(Constants.PARENTDEPTID);

//初始化部門參數，完成表1的部門參數初始化

final Object[] CREATEPARAMS = new Object[] { ID, SHORTNAME, FULLNAME, STATUS, 30, 15, 15, 1, 0, 1, 0,USER, new Date(), USER, new Date(), PARENTDEPTID, deptTreeId, virtualDept };

//更新數據庫信息

successFlag = this.tcmJdbcTemplate.update (this.sqlCreateDepart,CREATEPARAMS);

}

3) 郵箱任務管理和統計模式

郵箱內的任務管理模式，有“待處理”、“流轉中”和“已完成”三種模式，部門郵箱管理員對這些任務均有操作權，完成后任務記錄保留在郵箱任務管理中，匯總成部門相關的所有任務匯集。有了部門郵箱管理，部門工單及個人任務統計在這里變得異常簡便，部門管理員可以隨時查看部門內部任務的完成情況，可以精確到每個員工，如圖8所示，此為測試的示例數據。

圖8 部門任務報表示意圖

綜上，部門郵箱與個人任務相結合的模式，各部門職責分明，任務一目了然，數據實時統計快捷。通過實際流轉證明，能大大提升技術更改單的流轉效率。

3.3 部門級權限控制模式

傳統的權限管理控制在系統管理員手中，一方面系統管理員對各部門業務熟悉度不夠，容易誤開權限；另一方面申請人員眾多，管理員需花很多精力為其分配權限。作為公司的技術更改管理平臺，涉及部門、人員眾多且更改頻繁，傳統權限配置模式并不能滿足要求，必須實現彈性的菜單配置和部門功能數據靈活控制管理的功能。

本平臺中，每個部門均被設計為獨立的權限單元，包含完整獨立的技術更改流程功能模塊，對于不同的部門要求，還設置了不同的分發自動匹配規則。每個部門郵箱均包括三類權限：郵箱管理員、郵箱經理和普通用戶。創建部門時即自動為該部門創建并初始化這三個角色資源。角色對應的資源示例見圖9所示。

圖9 角色資源列表

由圖9可知，每個角色均可自由配置郵箱內部的所有功能，可以勾選自己部門需要的匹配規則還可以自定義審批頁面某些控件的展示與否，真正做到了一鍵式創建部門，一鍵式權限管理。

實現部門權限一鍵配置的核心代碼如下：

//初始化部門角色清單，同時配置部門管理員角色

public int createDepartRole(Map createRoleParams) {

//為部門創建并初始化角色

successFlag = this.iRolemanagedao. createDeptRole(ID, SHORTNAME, SHORTNAME);

//給部門管理員添加部門角色信息

final String ISADMINUSERS = (String) createRoleParams.get("staffIdUserName");

final List USERNAMES = Arrays.asList(ISADMINUSERS.split(","));

Long roleId;

//獲取部門角色ID

roleId = this.iRolemanagedao.getRoleIdByDeptId(ID);

//給管理員配置部門角色

this.iRolemanagedao.addUserRole(USERNAMES, roleId, 1L);

return successFlag;

}

3.4 關鍵方法實現

作為IBM BPM與Java結合的在上汽大眾的第一個流程類項目，BPM與Java的無縫接口實現是本平臺的一大特色，如前所述，BPM與Java之間采用REST API實現，下面將“分發”任務為例，講述一下具體的方法實現。分發任務是指將任務從上級分派到下級部門或工程師的過程，分發任務在本文中可以是上級郵箱分發到工程師，可以是分發到下級郵箱，可以是分發到下級負責人等。本文講述的技術更改管理平臺下面以簡稱TCM代替。

任務分發過程見圖10描述，分發過程在TCM中分五步：

(1) distributeTasks()：分發任務啟動，初始化數據；

(2) batchCreateTasks()：篩選分發類型，是分發到部門還是分發到工程師；

(3) startAekoProcess()：avonMsgId(技術更改單)遞歸到流程底層，piid是單個流程實例ID，ppiid是單個流程實例的父節點ID；

(4) startProcess()：遞歸為BPM中指定流程app(processAppId)的指定流程(bpdId)創建實例并啟動；

(5) BPM流程實例啟動，初始化數據，BPM調用數據庫將本次分發任務插入部門任務(TT_AEKO_DEPT_WORK)和個人任務表(TT_AEKO_STAFF_REVIEW)中；

(6) updateReviewStatus()：TCM更新數據庫中的部門任務和個人任務狀態。

至此，分發任務完成，表態和審批的處理過程類似分發，這里不再進行贅述。

圖10 任務分發過程示意圖

4 結 語

基于遞歸的多層嵌套流程能很好地滿足車企內部多部門各異的零部件技術更改流程需求，充分解放人工分發審批的繁雜勞動；部門郵箱化管理能最大實現部門內外數據實時共享，減少人員變動造成的任務耽擱；部門流程一鍵式配置能快速響應企業內部因機構變更導致的流程更改需求，實現快速開發；基于郵箱的權限配置管理模式，實現了部門權限自行管理配置，規范各部門的工作流程和工作方法。本平臺作為零部件技術更改的統一數據平臺，為各下游系統提供了最準確的零部件信息，是企業內部各系統的統一零部件更改數據源。

平臺已于2015年9月開始推廣，目前多個部門在平臺上成功運行了多個車型如NEW PASSAT, LAVIDA, TOURAN NF等車型項目的技術更改流轉，大大提升了員工的工作效率，已成為公司核心平臺。

[1] 劉曉冰,孟永勝,邢英杰,等.制造領域工程更改管理系統的技術研究[J].中國機械工程,2005,16(15):1339.

[2] 范菲雅,馬登哲.CIMS環境下工程更改的管理與實現[J].機械設計與研究,2001,17(2):31-33.

[3] 王娟.航天產品技術狀態更改管理應用[J].上海質量,2013(3):63-65.

[4] 高明.REST架構視角下面向內容協同的BPM引擎設計與實現[J].電腦編程技巧與維護,2010(18):19-23.

[5] 張宇,王映輝,張翔南.基于Spring的MVC框架設計與實現[J].計算機工程,2010,36(4):59-62.

[6]ClintonBegin,BrandonGoodin,LarryMeadors.iBatisinAction[M].Manningpublications,2007.

[7]IBM中國開發中心BPM團隊.IBMBPM實戰指南[M].北京希望電子出版社,2014:140-144.

[8] 游為建.基于BOM和矩陣管理模式的上海大眾零件俱樂部管理系統的設計和實現[J].計算機應用與軟件,2015,32(7):94-95.

DESIGN AND IMPLEMENTATION OF TECHNOLOGICAL CHANGE MANAGEMENTPLATFORM FOR SAIC VOLKSWAGEN BASED ON IBM BPM

You Weijian Xiang Jianying

(SAICVolkswagenAutomotiveCompanyLimited,Shanghai201805,China)

Due to the shorten of the products replacement cycle in auto industry, the automotive design and craft keeps changing. The technological change frequency has been raised as well as the scope has been increasingly extended. Such as in SAIC Volkswagen, hundreds of engineers may be involved in one complex technology change flow, while traditional methods of management is inefficient and not standard. Aiming at these problems, this paper puts forward an innovative technological change management platform for multiple departments, containing distribution, statement and approval, which is based on recursive IBM BPM process and mailbox management. In this paper, we give detailed introductions on the system architecture of the platform, the design of the system based on recursive process, department mailbox, permission design and the implementation of the key method. After the successful operation of the platform, the efficiency and accuracy of technological change management has been greatly improved, which supports the development and management of auto parts effectively.

Technological change Part Recursive process IBM BPM Mailbox

2016-02-04。游為建，工程師，主研領域：汽車開發領域應用系統。項建英，工程師。

TP315

A

10.3969/j.issn.1000-386x.2017.03.018