基于IBM BPM的上汽大众技术更改管理平台的设计和实现
2017-04-14游为建项建英
游为建 项建英
(上汽大众汽车有限公司 上海 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
//获取部门名称
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
//为部门创建并初始化角色
successFlag = this.iRolemanagedao. createDeptRole(ID, SHORTNAME, SHORTNAME);
//给部门管理员添加部门角色信息
final String ISADMINUSERS = (String) createRoleParams.get("staffIdUserName");
final List
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
