編輯導語：在BI系統(tǒng)里，經(jīng)常會遇到風險告警的場景，在這一類場景中需要更加重視業(yè)務的管理以及產(chǎn)品流程，及時解決問題；對于這種數(shù)據(jù)決策類產(chǎn)品設計，我們應該怎么做？本文作者分享了關于BI系統(tǒng)里的數(shù)據(jù)賦能與業(yè)務決策，我們一起來了解一下。

01?什么是風險告警？

風險告警是一個我們在使用數(shù)據(jù)過程中會遇到的比較常見的場景。我們今天詳細說說這類場景如何進行數(shù)據(jù)決策產(chǎn)品設計。

1. 業(yè)務風險管理角度

從業(yè)務風險管理的角度上，一般將風險管理分為事前管理、事中管理、事后管理。

• 事前管理，目的是預防事情的發(fā)生；
• 事中管理，目的是及時介入，避免事情變得更糟糕；
• 事后管理，目的是縮小已發(fā)生的問題造成的影響面、降低影響程度。

從業(yè)務風險的角度，我們能夠理解風險告警的目的。

2. 產(chǎn)品角度

從產(chǎn)品角度上看在日常業(yè)務場景中，一般可以分為流程類風險、總量類風險。

• 流程類風險，是流程監(jiān)控中常見的，比如事情應該做而沒有做、延遲做了、出現(xiàn)了不應該出現(xiàn)的事情（流程節(jié)點）。
• 總量類風險，是水平監(jiān)控、質(zhì)量監(jiān)控中常見的，比如今天應該完成多少，沒有完成；平時正常水平多少，現(xiàn)在監(jiān)控指標超過了正常水平相當比例。

從產(chǎn)品角度，我們能夠區(qū)分出我們遇到需求的是哪一類問題。

02 風險告警解決方案

知道了這兩種分類，能夠幫助我們在需求分析階段，很快的鎖定住我們的目標和大致的解決方案。

1. 一個例子

一家車聯(lián)網(wǎng)公司，最近想做一個用戶疲勞駕駛的風險告警，業(yè)務方設想的場景是，如果超過了交通法規(guī)規(guī)定的時間，就通過車聯(lián)網(wǎng)APP給用戶發(fā)出告警。

從風險管理的角度看，這個需求屬于是事后管理，因為業(yè)務希望是已經(jīng)發(fā)生疲勞駕駛，發(fā)出提醒。

從產(chǎn)品角度看，這個需求屬于總量類風險（水平監(jiān)控），當數(shù)據(jù)積累到一定值，發(fā)出告警，這個一定值，是交通法規(guī)規(guī)定的，所以是一個固定值。

弄清楚這兩點，我們的解決方案也大概有了個輪廓，采取策略方法，通過監(jiān)控持續(xù)駕駛時長這個數(shù)據(jù)指標，當數(shù)據(jù)指標到達閾值時，觸發(fā)告警。那么，我們產(chǎn)品方案的核心就是要弄清楚持續(xù)駕駛時長這個數(shù)據(jù)指標的計算邏輯，這個和車聯(lián)網(wǎng)采集上來的數(shù)據(jù)是什么樣高度相關，數(shù)據(jù)指標邏輯選取是另一個話題，我們這里不展開了。

用這個例子向大家說明，一個數(shù)據(jù)相關的風險告警場景的需求分析大致是怎么做的。

表面上看，這個例子不太像BI系統(tǒng)干的活，更像是一個車聯(lián)網(wǎng)的應用場景。事實上，如果要在一個BI看板里面進行業(yè)務決策支持的應用，他要面對的需求場景和解決方案都會更復雜一些。

之前的文章里我們提過，BI系統(tǒng)做數(shù)據(jù)決策之所以是一個比較難的問題，是因為現(xiàn)實世界存在復雜性。

復雜性決定了在做數(shù)據(jù)賦能和業(yè)務決策相關的數(shù)據(jù)產(chǎn)品設計時，要避免『一刀切』的想法，避免『畢其功于一役』，避免設想自己的設計能夠『一次成功』，這是一個不斷調(diào)優(yōu)的過程（如果是一名策略產(chǎn)品經(jīng)理或者算法產(chǎn)品經(jīng)理，應該能很好理解），調(diào)整好心態(tài)，我們開始吧。

2. 背景數(shù)據(jù)做風險告警的幾種方案

用數(shù)據(jù)來做風險告警，大概有這么幾種方案：

• 數(shù)據(jù)+策略/規(guī)則
• 數(shù)據(jù)+數(shù)據(jù)挖掘/機器學習
• 數(shù)據(jù)+知識圖譜

本文從產(chǎn)品角度，給大家介紹需求場景如何與這些解決方案相結合。

03 風險告警實例

下面來看一個數(shù)據(jù)安全審計的例子。

1. 背景

現(xiàn)在，平臺已經(jīng)有了敏感字段管理，對于用戶的導出權限一般來說不做限制，但是會去監(jiān)控用戶的導出操作與導出量行為，如果操作行為上看用戶的導出超過了正常業(yè)務需要，就屬于疑似異常導出，平臺要能識別這種異常并且發(fā)出風險告警。

這是一個我們通常會遇到的需求描述。表面上看，需求很明確，但仔細一琢磨，就會發(fā)現(xiàn)這個描述有很多模糊的地方。

這里面最大的需要明確的點，就是如何定義疑似異常導出的行為，即風險識別。

那么根據(jù)不同層次的需求，我們的解決辦法有相應的不同：

業(yè)務側說，我們有很明確需要監(jiān)控的重點表，根據(jù)之前的業(yè)務case，當發(fā)生這些行為的時候（同一天內(nèi)多次導出不同查詢條件的同一個表的數(shù)據(jù)；同一天內(nèi)導出總數(shù)據(jù)量超過xxx條數(shù)）就是疑似異常導出。只要先識別出這些行為推送給我們，通過一些日志去判斷是否真的是異常就可以。

2. 明確需求

首先判斷，這是一個事后風險管控+總量類風險（水平監(jiān)控）的需求，因為導出行為已經(jīng)發(fā)生了；其次，我們判斷數(shù)據(jù)決策的要求水平，業(yè)務方對告警的精度要求不高，他們已經(jīng)有了明確的通過實際案例積累下來的規(guī)則，

數(shù)據(jù)要做的是什么呢？幫助業(yè)務方在進行風險識別的時候提升效率、也就是篩選一個大面積的數(shù)據(jù)集，然后推送給業(yè)務人員進一步識別。

3. 設計解決方案

1）確定初步方案

需求到這個程度大致明確了，我們可以使用數(shù)據(jù)+策略的產(chǎn)品解決方案。即統(tǒng)計每個用戶對監(jiān)控的表的單日導出次數(shù)，和每個用戶對監(jiān)控的表的當日單出總量，兩者有一項超出閾值（或者同時發(fā)生時），將用戶信息及操作日志推送給指定的管理員用戶。

2）迭代

現(xiàn)在，來看一下迭代需求。

對接人反饋，第一期上線后，確實解決了大海撈針的問題，但是現(xiàn)在公司規(guī)模擴大了，數(shù)據(jù)量和數(shù)據(jù)分析人員增加，現(xiàn)在推送的疑似異常也多了很多，用戶已經(jīng)分析審核不過來了，能不能把風險比較高的給我們，低風險的那些就先給這些用戶做一些告警提示。

業(yè)務對接人還提出來一些想法，比如按照導出次數(shù)大小或者按照數(shù)據(jù)量大小去分這個風險高低，低風險可以等審核人員有空的時候進行抽查。

首先通過判斷，這是一個迭代需求，需求還是事后風險管控+水平監(jiān)控。

然后通過分析，這些新增的內(nèi)容，是對于告警的精度要求提升了，說白了，就是要降燥。

業(yè)務方給的解決方案是：通過對識別出的異常進行分級，不同的級別對應不同的處理辦法。怎么判斷我們能不能按照業(yè)務提出這個解決方案去做呢？

我們從產(chǎn)品發(fā)展的角度分析一下：

這個解決方案進行了風險分級處理，不同級別風險，告警方式不同。這個思路肯定沒有問題。

3）分級的問題

在再進一步看，如何分級，用什么原則去分級呢？我們發(fā)現(xiàn)業(yè)務提供的這個分級的策略比較剛性，如果用一個固定的數(shù)據(jù)指標值，可能會有兩個問題：

• 導出數(shù)據(jù)量和次數(shù)與風險閾值的關系，是和表本身存儲的內(nèi)容和數(shù)據(jù)量有關，也許不同的表閾值是不同的（意味著有巨大的維護規(guī)則的工作）。
• 隨著業(yè)務規(guī)模發(fā)展，存儲的數(shù)據(jù)量規(guī)模也會變化，即使同一個表，風險告警閾值很容易就會需要變更。

那么這個規(guī)則從擴展性來說，閾值不適合使用一個固定的值了，而是一個受到一些影響因素會發(fā)生變化的數(shù)。

經(jīng)過一番需求分析，發(fā)現(xiàn)業(yè)務對接人提供的解決方案思路是ok的，但是細節(jié)還需要進一步去設計；那么這次產(chǎn)品迭代的目標是就是需要在數(shù)據(jù)監(jiān)控的基礎上，動態(tài)的去進行風險分級。

有些小伙伴會說，這個時候該算法工程師上啦！應該讓算法同學出解決方案了。

我要說，這個時候其實產(chǎn)品的核心邏輯還沒思考清楚，算法同學接到需求，只會丟給你一個白眼好嘛！

4）梳理核心邏輯

怎么去梳理這個核心邏輯呢？

我的答案是，要去思考這件事情的本質(zhì)是什么，抽象出來。我們要理解的事情是—風險告警推送給審核人員，他們到底在審核什么？

帶著這個問題和業(yè)務人員交流，溝通后發(fā)現(xiàn)，審核要找出用戶是不是真的出于不好的目的（比如盜取數(shù)據(jù)）導出數(shù)據(jù)。那么，我們風險識別，就是去能夠識別用戶行為的惡意程度，而風險的分級，就是惡意程度的分級。

現(xiàn)在，需求轉(zhuǎn)化成為了一個相對定量的，評估用戶在平臺進行數(shù)據(jù)導出或者查詢等一系列行為的惡意程度。惡意程度，如何量化？可以從結果去推導，用戶操作得到的數(shù)據(jù)結果整合后，如果這些內(nèi)容流出，對公司造成損失程度。

把惡意程度和損失程度做了一個對等變換，如何看損失程度呢？通過和業(yè)務方調(diào)研了解到泄露出去的數(shù)據(jù)，包含的內(nèi)容以及內(nèi)容的組合，如果會推算出一些不公開的數(shù)據(jù)，或者通過單元數(shù)據(jù)加工可得到一些財務數(shù)據(jù)，這種就屬于損失比較高的了。

原來如此，不同損失程度其實和疑似泄露的數(shù)據(jù)集的特征有關系。這個數(shù)據(jù)集不一定是從有一個表導出的，也有可能是好幾個表數(shù)據(jù)組合的。和數(shù)據(jù)量明細也許不一定高相關（不同特征的權重是不一樣的）。

到了這一步，核心邏輯就整理出一個大概輪廓了：找到某個用戶一系列操作行為組合出的數(shù)據(jù)集的特征，與我們的目標值（損失程度較高的數(shù)據(jù)集）特征，他們的相似程度，相似度越高，風險越高。

5）明確詳細方案

現(xiàn)在，產(chǎn)品思路理清楚了，我們可以去和算法同學討論，使用什么樣數(shù)據(jù)挖掘/機器學習的算法能夠達成需求目標。當然，還會遇到算法同學提出的一些別的問題，需要共同討論再進一步得出更詳細的解決方案。

好了，這個例子對于需求分析說的比較詳細，通過對需求不斷抽絲剝繭，一步一步深入，最后得到一個解決方案。

未來會繼續(xù)對數(shù)據(jù)決策相關做探討。

作者用了一個虛擬的案例，或者說一個思想實驗，與實際上數(shù)據(jù)安全審計的類似場景會有不同的地方，但是解決問題的思路很值得學習和思考。

#專欄作家#

大鵬，公眾號：一個數(shù)據(jù)人的自留地。人人都是產(chǎn)品經(jīng)理專欄作家，《數(shù)據(jù)產(chǎn)品經(jīng)理修煉手冊》作者。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。