Warning: file_get_contents(http://ip-api.com/json/77.88.5.199): failed to open stream: Connection timed out in /var/www/wp-content/plugins/aa-counter/aacounter.php on line 76

Notice: Trying to get property of non-object in /var/www/wp-content/plugins/aa-counter/aacounter.php on line 81

Warning: mysqli_query(): MySQL server has gone away in /var/www/wp-includes/wp-db.php on line 2030

Warning: mysqli_query(): Error reading result set's header in /var/www/wp-includes/wp-db.php on line 2030
May « 2019 « Supplier Lifecycle Management供应商全周期管理

Home » 2019 » May

Monthly Archives: May 2019

事态升级管理Escalation Process

前些日子家里两个小朋友发烧了, 时而低烧,时而高烧,尤其是半夜突然烧到39度,笔者更是急得团团转,不知如何是好,总想着是不是要尽快送到医院处理,平时带的少,没有经验。但是太太就很不一样了,泰然处之,时而用各种方法测量体温,确保测量读数一致,时而准备好退烧药给宝宝们服用。

其实在此之前笔者一直有阅读各种儿童发烧的处理方法的,但是实践才能出真知,否则临阵就慌乱。在这之后,笔者又重新查阅了儿童发烧的标准处理步骤,思路就是一种升级处理的手法。

一测:如果额温、耳温、肛温≥38度,口温、腋温≥37.5度时,宝宝就发烧了。

二看:一般超过38.5度需要吃退烧药,但是!如果娃的精神状态还不错,能吃能玩能睡,即便超过这个度数,也可以继续观察。

三换衣:适当的增减衣物,让娃舒服点。当体温上升时,宝宝会觉得冷,可以打开空调,适当穿衣穿袜。当体温下降时,宝宝会觉得热,可以适当脱几件衣服,增加散热。

四用药:当宝宝体温超过38.5度,就要考虑给娃用药了。当然这不是硬指标,如果宝宝精神状态不佳,即便没过38.5度也可以用药。

五送医院:但是如果发烧时伴随着呕吐不停,或是因发烧引起抽筋的情况时,就要赶快送医检查与治疗了!

你看最后到关键时刻才是送医院,并不是第一时间送医院,相反,第一时间送医院可能会因为交叉感染,等待时间过长等其它原因延误病情。

所举的这个例子就是一个事态升级的案例,仔细琢磨,其实生活中类似的事态升级还有不少。大家去看我们的各类安全生产法律条例,其中就会提到损失范围在多少该在多长时间内向谁进行通报,不同的损失程度就会有不同的处理要求;各位公司的员工手册也会有类似的说明,针对不同的违规定义的有从警告到开除不同等级的处罚;气象灾害预警里会有暴雨预警,台风预警,大雾预警等各种按严重程度分级的警告及对应的流程。

为什么需要有这样的事态升级的机制,笔者认为是出于规范沟通,高效沟通的目的。第一可以明确职责,减少推诿,第二可以规范信息的流通,确保信息在第一时间传递到正确的需求方。

升级,英文单词Escalation, 多年前接触时就琢磨这个词用得好,它不是Lift (直行电梯),而是Escalator(扶手电梯),多形象,不能跳跃,也就不能直接越级,而是要一级一级有步骤的来,就像在组织里,有什么问题要先找直接领导沟通,再找更高级领导,不能越级汇报一样,同理,更高级领导也不便直接找低级下属,就像大家没见过主席经常微服私访吧。在ISO9001 里并没有提到事态升级的概念,但是在IATF 16949 里明确提到了“升级”,并在“术语和定义”里定义升级过程 – “用于在组织内部强调或触发特定问题的过程,以便适当人员可对这些情况作出响应并监控其解决。” 具体包含有

“4.4.1.2 产品安全 。。。。。。组织应有形成文件的过程,用于与产品安全有关的产品和制造过程管理;形成文件的过程应包括但不限于(在适用 情况下): 。。。。。。h)包括最高管理者在内的,明确的职责,升级过程和信息流的定义,以及顾客通知; 。。。。。。

5.1.1.1 公司责任。。。。。。组织应明确并实施公司责任方针,至少包括反贿赂方针、员工行为准则以及道德准则升级政策(“举报政策”)。

9.1.1.1 制造过程的监视和 制造过程的监视和 制造过程的监视和 制造过程的监视和测量。。。。。。e)当不满足接收准则时的反应计划和升级过程。。。。。。“

在VDA 6.3 中也有P2 项目管理,P5 供应商管理,P7 客户服务提到升级管理,可见升级管理的重要性,但是在实践中却时常发现供应商的升级管理存在各种的缺失。究其原因,不外乎三个“不”:

  1. 不知道

不知道如果要升级,升级的流程到底是什么,这种通常是没有明文的程序或规定,有时流程有,可是不一定可用于当下的情形,因为世事变了,或者某些岗位的工作内容变了,又或者指定的那个岗位空缺,没有人在职;不知道升级的切入点是什么,也不知道当前的状态究竟是怎么样的,什么条件下可以升级,或者可以降级;不知道向谁升级,渠道不清晰。就像所有公共场合写着“不准吸烟”,可是当你发现有人就在你身边吸烟时,你却不知道找谁来处理。

  1. 不授权

文件规定的很好,也批准发行了,可到了该领导授权的时候,却发现要不到资源,执行不下去。

  1. 不执行

你按流程升级到某个人那里,各种原因的卡,没资源,没时间,没配合,就是不执行或者延缓执行,一副拖着耗着,大事化小,小事化无的心态。到了该降级的时候,对方就是不接收,认为事态还没有恢复或缓解到可以接受的地步。

要避免这些问题,在VDA Product Manufacturing and Delivery – Robust Manufacturing Process 里给出了一些升级和降级的小技巧,比如以下,事先定义清楚升级的等级,升级的临界值,升级的计划以及升级的决定者,反应计划,降级的条件,所需要通知的相关方,以及负责记录的人。

并举了一个供应商绩效提升的模板例子来进行说明,见以下,当然实际应用中可以做一些优化。

在实践中,有些公司在内部推行各类各层级的快速反应小组(Quick Response Quality Control), 让影响项目,运营的问题点能第一时间得到有效解决,其实也是一种升级管理,关于如何运作快速反应小组,这将在以后的文章中另作分享。