游為建 項建英

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

基于IBM BPM的上汽大眾技術(shù)更改管理平臺的設(shè)計和實現(xiàn)

游為建 項建英

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

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

技術(shù)更改 零件 遞歸流程 IBM BPM 郵箱

0 引 言

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

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

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

1 需求現(xiàn)狀

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

1.1 技術(shù)更改主數(shù)據(jù)現(xiàn)狀

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

(1) 車型零部件范圍：單個技術(shù)更改涉及多個車型多個零部件，有的單子涉及幾百個零部件的更改,每個更改均需得到相關(guān)部門相關(guān)工程師的所有表態(tài)，并得到相應(yīng)部門領(lǐng)導(dǎo)的審批認(rèn)可。

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

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

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

1.2 各部門技術(shù)更改流程需求

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

1) 沖壓規(guī)劃科技術(shù)更改流程現(xiàn)狀

沖壓規(guī)劃科是負(fù)責(zé)公司所有車型自制件的規(guī)劃、設(shè)計，沖壓生產(chǎn)線及設(shè)備的規(guī)劃管理的一個科室。其流程分四級，規(guī)劃部負(fù)責(zé)人分發(fā)到?jīng)_壓規(guī)劃科負(fù)責(zé)人，再根據(jù)車型選擇分發(fā)給不同的車型負(fù)責(zé)人，最后分發(fā)到工程師進(jìn)行表態(tài)。工程師表態(tài)后交由自己的股長進(jìn)行審批，最后匯總到?jīng)_壓規(guī)劃科負(fù)責(zé)人，匯總表態(tài)后交由科長審批，審批通過后自動提交到規(guī)劃部，分發(fā)和審批均涉及退回、轉(zhuǎn)派、補分發(fā)等操作。具體流程見圖1所示。

圖1 沖壓規(guī)劃科技術(shù)更改流程現(xiàn)狀

2) 電器工程科技術(shù)更改流程現(xiàn)狀

電器工程科是分管所有車型電器零部件及測試的大型開發(fā)部門，其人員眾多，部門龐大，涉及的技術(shù)更改數(shù)量也多。電器工程科的流程是由負(fù)責(zé)人根據(jù)零部件號碼規(guī)則直接分發(fā)到FOP，F(xiàn)OP表態(tài)后提交股長、項目協(xié)調(diào)、項目經(jīng)理和外方經(jīng)理進(jìn)行多級審批后匯總回電器工程科負(fù)責(zé)人處，由其向公司統(tǒng)一匯總部門內(nèi)部意見。具體流程見圖2所示。

圖2 電器工程科技術(shù)更改流程圖

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

1.3 跨部門數(shù)據(jù)統(tǒng)計需求

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

(1) 各部門流程詳細(xì)明細(xì)圖：涉及流程實際流經(jīng)的每個人，包括收到日期，應(yīng)答復(fù)日期和實際答復(fù)日期，以及相關(guān)答復(fù)意見。

(2) 各部門按人員統(tǒng)計任務(wù)準(zhǔn)時完成率圖：包括時間段內(nèi)應(yīng)答復(fù)任務(wù)數(shù)，超期答復(fù)任務(wù)數(shù)，準(zhǔn)時答復(fù)任務(wù)數(shù)，超期未答復(fù)任務(wù)數(shù)等。對部門內(nèi)部考核有至關(guān)重要的作用。

(3) 多部門任務(wù)準(zhǔn)時完成率圖：按部門統(tǒng)計任務(wù)的各個狀態(tài)的數(shù)量，便于部門間比較，針對瓶頸部門進(jìn)行流程改進(jìn)。

2 平臺軟件結(jié)構(gòu)

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

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

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

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

3 平臺方案設(shè)計和關(guān)鍵方法實現(xiàn)

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

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

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

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

圖4 基于IBM BPM的遞歸多層嵌套技術(shù)更改流程實現(xiàn)

如圖4示，每級流程角色分為當(dāng)前部門和下級部門，有分發(fā)、表態(tài)和審批三個階段。每級流程從分發(fā)節(jié)點開始，分發(fā)可選，根據(jù)當(dāng)前部門是否有下級進(jìn)行選擇是繼續(xù)進(jìn)入下一級遞歸子流程還是直接進(jìn)入工程師表態(tài)階段；表態(tài)結(jié)束或遞歸子流程結(jié)束后進(jìn)入審批階段，審批階段包括四個可選項：股長審批、匯總、經(jīng)理審批和匯總表態(tài)，分別對應(yīng)不同部門流程中的特定需求。其中股長審批就是當(dāng)前股的股長進(jìn)行審批；匯總、審批和匯總表態(tài)，是考慮有的部門需要管理員先匯總?cè)缓笤偬峤豢崎L審批，有的部門則是科長先審批再由管理員匯總表態(tài)。圖5演繹了沖壓規(guī)劃科流程在遞歸模式下的實際數(shù)據(jù)流向。

圖5 沖壓規(guī)劃科技術(shù)更改流程推演

3.2 部門的郵箱化管理模式的設(shè)計和實現(xiàn)

傳統(tǒng)的流程系統(tǒng)將流程綁定在固有部門上，并基于部門的組織結(jié)構(gòu)設(shè)計相應(yīng)的流程走向；所有任務(wù)都處于每個任務(wù)人的個人任務(wù)郵箱中。這類方法有幾個缺點，一個是企業(yè)部門組織機(jī)構(gòu)變更快，需要及時調(diào)整人員和規(guī)則；二是所有任務(wù)都在每個人的個人待辦/已辦任務(wù)里，一旦發(fā)生人員變動，需要有專職人員及時處理相關(guān)遺留任務(wù)；三是針對各個專業(yè)部門，不能對本部門相關(guān)專業(yè)數(shù)據(jù)做統(tǒng)計和管理。

本平臺采用的解決方案是設(shè)計部門管理節(jié)點，即部門郵箱，基于遞歸的嵌套子流程實現(xiàn)基于郵箱。郵箱的說法源于個人email賬戶，相比email郵箱的個人任務(wù)集合，部門郵箱是一個關(guān)于部門所有功能和任務(wù)的集合，是多人共享的一個操作平臺，其囊括組織機(jī)構(gòu)管理，郵箱任務(wù)管理，郵箱報表統(tǒng)計以及郵箱自配置等功能。

1) 組織機(jī)構(gòu)管理模式

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

圖6 郵箱組織機(jī)構(gòu)維護(hù)

2) 部門郵箱配置模式

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

圖7 電器工程科技術(shù)更改流程推演

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

表1 部門配置表

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

//創(chuàng)建部門并初始化部門配置參數(shù)

public int createDepart(Map createParams) {

//獲取部門名稱

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

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

//獲取當(dāng)前創(chuàng)建部門的父部門

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

//初始化部門參數(shù)，完成表1的部門參數(shù)初始化

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 };

//更新數(shù)據(jù)庫信息

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

}

3) 郵箱任務(wù)管理和統(tǒng)計模式

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

圖8 部門任務(wù)報表示意圖

綜上，部門郵箱與個人任務(wù)相結(jié)合的模式，各部門職責(zé)分明，任務(wù)一目了然，數(shù)據(jù)實時統(tǒng)計快捷。通過實際流轉(zhuǎn)證明，能大大提升技術(shù)更改單的流轉(zhuǎn)效率。

3.3 部門級權(quán)限控制模式

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

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

圖9 角色資源列表

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

實現(xiàn)部門權(quán)限一鍵配置的核心代碼如下：

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

public int createDepartRole(Map createRoleParams) {

//為部門創(chuàng)建并初始化角色

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

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

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

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

Long roleId;

//獲取部門角色I(xiàn)D

roleId = this.iRolemanagedao.getRoleIdByDeptId(ID);

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

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

return successFlag;

}

3.4 關(guān)鍵方法實現(xiàn)

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

任務(wù)分發(fā)過程見圖10描述，分發(fā)過程在TCM中分五步：

(1) distributeTasks()：分發(fā)任務(wù)啟動，初始化數(shù)據(jù)；

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

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

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

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

(6) updateReviewStatus()：TCM更新數(shù)據(jù)庫中的部門任務(wù)和個人任務(wù)狀態(tài)。

至此，分發(fā)任務(wù)完成，表態(tài)和審批的處理過程類似分發(fā)，這里不再進(jìn)行贅述。

圖10 任務(wù)分發(fā)過程示意圖

4 結(jié) 語

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

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

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

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

[3] 王娟.航天產(chǎn)品技術(shù)狀態(tài)更改管理應(yīng)用[J].上海質(zhì)量,2013(3):63-65.

[4] 高明.REST架構(gòu)視角下面向內(nèi)容協(xié)同的BPM引擎設(shè)計與實現(xiàn)[J].電腦編程技巧與維護(hù),2010(18):19-23.

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

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

[7]IBM中國開發(fā)中心BPM團(tuán)隊.IBMBPM實戰(zhàn)指南[M].北京希望電子出版社,2014:140-144.

[8] 游為建.基于BOM和矩陣管理模式的上海大眾零件俱樂部管理系統(tǒng)的設(shè)計和實現(xiàn)[J].計算機(jī)應(yīng)用與軟件,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。游為建，工程師，主研領(lǐng)域：汽車開發(fā)領(lǐng)域應(yīng)用系統(tǒng)。項建英，工程師。

TP315

A

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