从上海地铁撞车事件看“业务建模”的不可或缺性

最新推荐文章于 2025-06-03 00:15:00 发布

转载最新推荐文章于 2025-06-03 00:15:00 发布 · 180 阅读

本文回顾了一次关于地铁应急处理的业务建模培训经历，并指出若能充分运用业务建模方法，可有效应对类似上海地铁一号线撞车事故等突发事件。文中强调了业务建模的重要性，并列举了一些具体的业务流程改进措施。

近日听闻上海地铁一号线发生撞车事故，笔者在庆幸没有出现人员伤亡的同时，也为事件所造成的重大混乱后果唏嘘不已。笔者之所以比较关注此事件，是因为笔者曾经在2007年11月份给申通地铁的相关研发团队做过一次培训，并在培训中恰好谈论过地铁事故的应急处理等问题。

那次培训的内容以嵌入式软件架构设计为主，但在培训中，为了展示嵌入式软件的需求来源，专门讲述了业务建模business modeling（用模型来描述业务，同时也包括用模型来设计全新的业务）的方法。于是便有了与学员一道探讨地铁发生事故等异常事件，整个运营系统如何支持应急预案执行等问题的经历。在讨论过程中，笔者应用业务建模的方法分析了地铁事故应急预案的一些基本内容。提到了如何在地铁站显示屏上显示事故信息、引导乘客尽快离开等；并提到自动售票机在应急预案启动后，应当在屏幕上用亮色标识出被暂停运营的路段（售票机的需求规格中常常会漏掉这一功能需求），或者暂停售票功能（售票机的状态有正常售票、电子客票空、找零不够、钱币存储箱满、机器故障中，于是这里还应加上紧急暂停售票状态）等；而相关地铁站的进口闸机应临时关闭，或转换成出口闸机；另外，出口闸机可能需要暂停验票功能，从而开放给乘客快速离场等；最后，无论售票机、进出口闸机等都应通过网络与中心运营控制系统相连接。

不过很遗憾，一次不起眼的培训并不可能引起申通地铁高层的足够重视，地铁事故应急预案以及相关应用系统的业务集成自然也没有被落实。事后上海《东方早报》载文质疑“申通”相关部门：“为何公共显示屏无任何提示信息?”“为何不增设指示牌引导乘客换乘?”“为何不通过电信群发短信提醒?”等。有人可能以相关部门缺乏经验来加以申辩，但这些问题大部分恰恰都在2007年那次培训的业务建模讨论中被提及过。实际上，只要真正掌握了业务建模的方法，那么在事先为未来才可能发生的异常事件做好处理准备，是完全可以做到的。

设想一下，如果申通地铁能够组织业务部门与研发团队一道，就上海地铁业务进行一次彻底的业务建模（涵盖所有业务范畴，包括事故或异常事件的应急处理等），设计好每个业务处理的具体流程；并依据这些业务来重新梳理相关应用软件和硬件设备的需求规格；然后升级整个运营系统，以实现新业务的集成。那么此次撞车事件很可能就不会造成如此巨大的群体性影响。

“业务建模”是上世纪九十年代便在欧美IT界开始流行的一种面向业务的分析与设计方法。在Rational 公司（现被IBM并购）主推的软件开发过程（RUP统一软件过程）中，业务建模属于在需求开发之前便开始的核心过程域。也就是说，在软件项目中，最开始的核心工作不是需求开发，而是业务建模。不幸的是，国内的开发团队对“业务建模”的重视程度还比较低，在项目中成功实施“业务建模”的就更为少见。

对于业务简单的应用而言，业务建模的作用可能有限，但对于那些较大规模或流程复杂的业务系统，缺少业务建模的环节是难以想象的。实际上，国内的开发团队通常都会为那些复杂的业务，绘制一些业务流程图，这些其实就是业务建模中的一部分内容。但是，不能系统地去进行业务建模，往往最终会造成开发团队对业务的梳理和理解产生遗漏、偏差，甚至是错误。申通地铁在设计其业务运营系统的时候，肯定也做了全面的业务规划与设计，但是因为缺乏业务建模的经验，至少在业务异常处理方面出现了重大遗漏。

随着国内开发团队的不断成长，“业务建模”目前也在一些国内软件企业中被推行，并在不少项目中取得重大成功。例如，深圳市财政局在开发新一代业务软件系统之前，专门委托大连华信梳理和设计其新的业务方案，此间便成功地应用了业务建模的方法（笔者有幸为其提供过咨询和培训服务）。笔者在2004年为海南航空集团做软件教练项目时，在开发资产管理系统的过程中，指导其团队应用业务建模技术完善了其横跨集团的资产管理业务流程。另外，笔者近几年参与的项目中，还涉及人事管理、保险业务、电力运营业务等相关领域，并均有业务建模的成功案例。

为了让有兴趣的读者了解业务建模，笔者准备在后续的系列文章中详细阐述其相关知识，并围绕申通地铁业务的实际案例（2007年培训时做了部分模型，准备在此基础上进一步加以精化）来展开。笔者相信申通地铁的研发人员可能也在规划新的地铁事故应急预案业务方案，那么，笔者在此展示的申通地铁业务模型，应当能够起到抛砖引玉的作用。

笔者在将要后续的系列文章中阐述的业务建模内容包括：