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

游為建 項(xiàng)建英

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

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

游為建 項(xiàng)建英

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

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

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

0 引 言

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

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

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

1 需求現(xiàn)狀

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

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

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

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

(2) 表態(tài)時(shí)間要求：?jiǎn)蝹€(gè)技術(shù)更改一般需要在2周內(nèi)完成所有部門(mén)的表態(tài)意見(jiàn)收集。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 平臺(tái)方案設(shè)計(jì)和關(guān)鍵方法實(shí)現(xiàn)

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

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

需求分析后看出，各部門(mén)流程相對(duì)獨(dú)立，由于職能不一，無(wú)法實(shí)現(xiàn)技術(shù)更改流程統(tǒng)一模式進(jìn)行。但是為各部門(mén)設(shè)計(jì)各異的流程一方面工作量非常大，因?yàn)樾枰渲昧鞒痰牟块T(mén)非常多；另一方面對(duì)于以后需要隨時(shí)追加部門(mén)進(jìn)行流轉(zhuǎn)的需求無(wú)法滿足，因?yàn)樾枰獮槠渑渲米约旱牧鞒?，變更代價(jià)大。

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

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

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

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

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

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

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

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

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

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

2) 部門(mén)郵箱配置模式

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

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

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

表1 部門(mén)配置表

完成部門(mén)配置的核心代碼如下：

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

public int createDepart(Map createParams) {

//獲取部門(mén)名稱

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

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

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

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

//初始化部門(mén)參數(shù)，完成表1的部門(mén)參數(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ù)庫(kù)信息

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

}

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

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

圖8 部門(mén)任務(wù)報(bào)表示意圖

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

3.3 部門(mén)級(jí)權(quán)限控制模式

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

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

圖9 角色資源列表

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

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

//初始化部門(mén)角色清單，同時(shí)配置部門(mén)管理員角色

public int createDepartRole(Map createRoleParams) {

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

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

//給部門(mén)管理員添加部門(mén)角色信息

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

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

Long roleId;

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

roleId = this.iRolemanagedao.getRoleIdByDeptId(ID);

//給管理員配置部門(mén)角色

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

return successFlag;

}

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

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

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

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

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

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

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

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

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

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

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

4 結(jié) 語(yǔ)

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

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

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

[2] 范菲雅,馬登哲.CIMS環(huán)境下工程更改的管理與實(shí)現(xiàn)[J].機(jī)械設(shè)計(jì)與研究,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è)計(jì)與實(shí)現(xiàn)[J].電腦編程技巧與維護(hù),2010(18):19-23.

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

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

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

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

TP315

A

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