1 背景

按燈機制來源于豐田-生產(chǎn)模式，基于其“建立立即暫停制度以解決問題，從一開始就重視品質(zhì)管理的文化”的生產(chǎn)原則。在豐田生產(chǎn)線上，一線操作工人一旦發(fā)現(xiàn)任何異常，有權(quán)按下按鈕，直接停止整個流水線，讓問題暴露出來，馬上解決。

2012年，美國電商巨頭亞馬遜將豐田的按燈機制引入到客服系統(tǒng)中。為了解決客戶投訴問題，一旦有超過兩名客戶投訴同一產(chǎn)品或者營銷規(guī)則的同一個問題時，無論產(chǎn)品、營銷規(guī)則多么火爆，客服專員都可以直接按下紅燈鍵，下架產(chǎn)品或者營銷規(guī)則，直到問題解決才會重新上架。

2022年，轉(zhuǎn)轉(zhuǎn)為進(jìn)一步提升品質(zhì)管理，在公司組織內(nèi)落地一套用戶反向驅(qū)動的機制即按燈機制，前期聚焦在如何把用戶的聲音（尤其是客訴）穿透到公司業(yè)務(wù)方做針對性改善，最終實現(xiàn)公司組織具備實現(xiàn)用戶第一的機制保障。

2 系統(tǒng)設(shè)計

轉(zhuǎn)轉(zhuǎn)引入按燈機制的交互流程圖如下：

從流程上看，按燈相關(guān)流程放在業(yè)務(wù)系統(tǒng)中也可以實現(xiàn)。

2.1 為什么要單獨開發(fā)按燈系統(tǒng)？

轉(zhuǎn)轉(zhuǎn)體系內(nèi)存在多個與品質(zhì)有關(guān)系的直接系統(tǒng)，如果各業(yè)務(wù)系統(tǒng)都自主實現(xiàn)按燈邏輯的話，主要的弊端有：

1. 資源浪費；
2. 業(yè)務(wù)系統(tǒng)與按燈相關(guān)其他業(yè)務(wù)系統(tǒng)耦合；
3. 按燈數(shù)據(jù)格式無法保證一致，數(shù)據(jù)分析起來較困難；

根據(jù)以上問題，將業(yè)務(wù)系統(tǒng)相關(guān)按燈動作抽象出來，由按燈系統(tǒng)統(tǒng)一收攏，按燈系統(tǒng)的主要功能如下：

1. 發(fā)起按燈；
2. 按燈單據(jù)的處理；
3. 同步申訴信息；
4. 發(fā)送執(zhí)行命令；
5. 跟蹤按燈結(jié)果；

2.2 系統(tǒng)邊界如何劃分？

按燈系統(tǒng)既是承接上游發(fā)起按燈又是對下游系統(tǒng)發(fā)送執(zhí)行命令的載體，那么按燈系統(tǒng)與上下游系統(tǒng)的邊界劃分則是系統(tǒng)設(shè)計的關(guān)鍵因素。

將整個流程相關(guān)系統(tǒng)分為四大模塊，如圖：

問題

為什么申訴、執(zhí)行模塊沒有放在按燈模塊中？

答案

申訴信息的展示需要依托業(yè)務(wù)系統(tǒng)推送給用戶。例如：商戶查看按燈信息需要通過商戶管理平臺。不同的業(yè)務(wù)會有不同的申訴場景，所以申訴模塊由業(yè)務(wù)系統(tǒng)自身實現(xiàn)即可，按燈只需提供申訴的數(shù)據(jù)。

執(zhí)行模塊如：質(zhì)檢系統(tǒng)、商戶管理系統(tǒng)等。這些系統(tǒng)本來就控制商戶的質(zhì)檢能力和供貨能力，按燈系統(tǒng)無需重復(fù)實現(xiàn)限制邏輯，只需要給對應(yīng)系統(tǒng)發(fā)送命令，執(zhí)行系統(tǒng)識別命令后執(zhí)行相應(yīng)限制邏輯即可。

3 系統(tǒng)實現(xiàn)

3.1 流程實現(xiàn)技術(shù)選型

根據(jù)第二部分系統(tǒng)設(shè)計，按燈系統(tǒng)主流程即為按燈單據(jù)的流轉(zhuǎn)，流程實現(xiàn)技術(shù)選型是系統(tǒng)實現(xiàn)技術(shù)方案的重中之重，它決定了系統(tǒng)的復(fù)雜度、系統(tǒng)運行性能以及后續(xù)的維護(hù)成本。

常見的流程邏輯實現(xiàn)主要有狀態(tài)機和責(zé)任鏈兩種處理方式，兩種處理方式對比如下表格：

兩種模式雖然都是處理鏈?zhǔn)秸埱螅煌氖牵籂顟B(tài)機是通過狀態(tài)切換促使不同的狀態(tài)處理類去處理請求，而責(zé)任鏈模式是在動作執(zhí)行完成后直接傳遞給下一個處理類繼續(xù)執(zhí)行。

按燈系統(tǒng)劃分為流程節(jié)點如下圖：

在按燈的場景中，按燈單也有多個狀態(tài)，但實際執(zhí)行并不復(fù)雜，按燈整體鏈路長度適中，結(jié)合當(dāng)前的場景和后續(xù)規(guī)劃，最終選擇了更輕便的責(zé)任鏈模式來實現(xiàn)按燈單據(jù)的流轉(zhuǎn)。

3.2 按燈流程實現(xiàn)

流程執(zhí)行器抽象類：

• next() : 設(shè)置下一個執(zhí)行器；
• execute(): 當(dāng)前執(zhí)行器處理邏輯；
• doNext(): 觸發(fā)下一個執(zhí)行器；

public abstract class AbstractAndonTicketProcessService {


    protected AbstractAndonTicketProcessService next;


    protected abstract void next();


    protected AndonProcessResult doNext(String logStr, AndonProcessContext context) {
        if (Objects.isNull(this.next)) {
            return AndonProcessResult.buildSuccess("執(zhí)行成功");
        }
        return this.next.execute(logStr,context);
    }

    public abstract AndonProcessResult execute(String logStr, AndonProcessContext context);

}

流程器的觸發(fā)有四個場景：

1. 創(chuàng)建按燈單；
2. 申訴結(jié)果回傳；
3. 處罰指令執(zhí)行結(jié)果回傳；
4. 恢復(fù)指令執(zhí)行結(jié)果回傳；

將流程器按功能模塊區(qū)分開，基于場景需求，選擇不同的模塊作為起點直接觸發(fā)，使代碼復(fù)用性更高。

3.3 按燈策略實現(xiàn)

按燈策略：對按燈源場景配置一組要執(zhí)行的按燈指令以及按燈指令下發(fā)的時機。每一個按燈源有且只有一個按燈策略，不同的業(yè)務(wù)可以根據(jù)指令和時機的不同組合，實現(xiàn)按燈流程。

• 按燈源：觸發(fā)按燈的場景
• 按燈對象：被按燈的對象
• 申訴能力：是否需要申訴
• 按燈指令：執(zhí)行處罰措施的類型

• 罰款指令
• 學(xué)習(xí)指令：指定按燈對象去學(xué)習(xí)系統(tǒng)學(xué)習(xí)對應(yīng)課程
• 限制商戶能力指令：不允許商戶上架、質(zhì)檢商品等

• 下發(fā)時機：指令下發(fā)執(zhí)行系統(tǒng)的時機
• 立即下發(fā)：創(chuàng)建按燈單時立即觸發(fā)
• 申訴失敗：等待申訴結(jié)果且失敗時觸發(fā)
• 到達(dá)整改期限：指定指令在期限內(nèi)沒有完成，則觸發(fā)

問題

創(chuàng)建按燈單據(jù)時是怎樣匹配按燈策略的？

按燈策略的更新對單據(jù)邏輯影響是怎樣的？

答案

查詢該按燈場景下配置的按燈策略，根據(jù)按燈策略配置的按燈指令類型及下發(fā)時機生成對應(yīng)按燈單和按燈指令。

更新策略采用模板方式，更新后會產(chǎn)生新的模板。待此按燈源下個按燈單據(jù)匹配時，會取最新版本進(jìn)行關(guān)聯(lián)。

4 應(yīng)用場景

在轉(zhuǎn)轉(zhuǎn)平臺，商戶服務(wù)評級是通過平臺多維度考核商家服務(wù)能力，以平臺機制和平臺運營策略正向引導(dǎo)商家的服務(wù)能力、質(zhì)檢能力和履約能力的提升。對于商家在商品、訂單、售后等服務(wù)上存在的問題，比如商品質(zhì)量不達(dá)標(biāo)、超時發(fā)貨、售后時效不達(dá)標(biāo)等其他問題都可以作為按燈的數(shù)據(jù)來源，各業(yè)務(wù)按照自己業(yè)務(wù)規(guī)則靈活配置，超過閾值觸發(fā)按燈系統(tǒng)創(chuàng)建按燈單，執(zhí)行在按燈系統(tǒng)配置的流程。下圖為商戶服務(wù)評級按燈流程：

5 總結(jié)

按燈系統(tǒng)是轉(zhuǎn)轉(zhuǎn)落地一套用戶反向驅(qū)動的機制，會為平臺建立一個正向循環(huán)體系，提升平臺購物體驗，讓更多的用戶喜歡轉(zhuǎn)轉(zhuǎn)。