好看的小说君子以泽,遮天辰东小说笔趣阁

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

按燈系統(tǒng)在轉轉的實踐

1 背景

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

創(chuàng)新互聯(lián)主營普蘭網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,成都app開發(fā),普蘭h5小程序制作搭建,普蘭網(wǎng)站營銷推廣歡迎普蘭等地區(qū)企業(yè)咨詢

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

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

2 系統(tǒng)設計

轉轉引入按燈機制的交互流程圖如下：

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

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

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

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

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

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

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

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

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

模塊	職責
業(yè)務模塊	過濾或匯總業(yè)務數(shù)據(jù)；
按燈模塊	核心實現(xiàn)按燈單據(jù)的流轉；
申訴模塊	提供申訴能力，回傳申訴結果；
執(zhí)行模塊	執(zhí)行按燈命令，回傳執(zhí)行結果；

問題

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

答案

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

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

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

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

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

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

技術選型	優(yōu)點	缺點
狀態(tài)機	狀態(tài)驅動運轉，易擴展	邏輯重，配置理解成本高
責任鏈	代碼類配置鏈路，清晰易懂	鏈路長的話，性能會低

兩種模式雖然都是處理鏈式請求，但不同的是：狀態(tài)機是通過狀態(tài)切換促使不同的狀態(tài)處理類去處理請求，而責任鏈模式是在動作執(zhí)行完成后直接傳遞給下一個處理類繼續(xù)執(zhí)行。

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

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

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

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

next() : 設置下一個執(zhí)行器；
execute(): 當前執(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ā)有四個場景：

創(chuàng)建按燈單；
申訴結果回傳；
處罰指令執(zhí)行結果回傳；
恢復指令執(zhí)行結果回傳；

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

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

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

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

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

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

問題

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

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

答案

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

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

4 應用場景

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

5 總結

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

當前標題：按燈系統(tǒng)在轉轉的實踐
文章地址：http://m.fisionsoft.com.cn/article/coicich.html