產品目錄大家并不陌生，無論是現已經近乎絕跡的郵寄產品目錄還是超市門口經常有人發送的打折商品目錄，這些都是產品目錄，由于日常生活中，我們都是各種產品目錄的轟炸對象，也就不能看出，它的一個作用是傳遞產品信息。上邊的例子都是信息由企業內部向外傳遞，但是，很多人都忽視了它的另一個方向，就是向內傳遞，這方面不僅僅是意識到的人不多，能在開發中真實去應用的更少，而能形成企業級信息傳導能力，通過產品目錄構建起“產品信息高速公路”的，就少之又少了。

產品目錄傳導信息的邏輯

上一章我們分析了通過構件模型建立輕量級架構工具的方法，通過構件與服務的關系關聯起開發信息，形成架構管理依據，可以支持快速開發的需要和提升項目管理的科學性。這是構件模型向開發上的延伸，但是既然構件模型可以用于裝配產品，那自然也可以向業務端延伸。在上一章的開頭部分有一張構件模型的抽象結構圖，左下角紅色虛線框起來的部分就描述了產品目錄的基本邏輯。產品目錄實際上可以包含很多信息，而不像那張簡圖中信息那么少，可以包含設計者、管理者、銷售方、合作方、產品特征、適用客戶群體等各類描述信息，還可以仿照互聯網產品管理方式，添加大量標簽，再通過產品銷售信息關聯起客戶，形成一個龐大的“圖譜”，一張通過產品和產品目錄連接起來的信息網，當這個網絡具備企業級規模時，它產生的信息傳導能力是驚人的。每一項產品信息都是一個產品維度，具備了高維度特征的產品信息庫才具備形成產品大數據的基本條件，大數據的價值不在數據量而在維度，維度才是描述對象特征最重要的手段，而金融機構目前缺少的也恰恰是這個。

產品目錄能夠聯通公司內外，聯通業務和技術，將市場信息、客戶信息、銷售信息、伙伴信息等各種信息通過高維數據結構組織起來，讓海量信息分門別類地流向信息需求方，成為一個高效的信息傳輸渠道，這才是企業級產品目錄真正的價值。而當有信息無法沿著產品目錄傳遞時，我們也可以發現是否缺少了與之對應的產品或者產品維度。如果能夠按照產品目錄匯集起海量、多維、完整的產品信息，就可以通過大數據和AI技術，進行更為廣泛、深入的信息挖掘，產生超過單點分析的業務效果，包括產品之間的相關性、客戶行為的相關性、內外部事件與產品的相關性等一系列綜合分析，這是需要通過產品進行串聯的分析工作。有效應用產品目錄來組織信息，可以更加貼近業務對信息的理解；經過整理的產品分析信息也可以直接推送產品開發團隊，完善項目效果反饋機制，提高設計人員了解市場信息的及時性。

以上介紹可以用下圖表示：

?

產品維度及其作用

對于產品目錄而言，形成信息歸集、整理和傳導能力最關鍵的是維度，也可以換個通俗的說法，就是標簽，標簽的含義是使用概括性詞匯或短語來描述某一內容，這些內容可以是文章、商品、視頻、圖片、歌曲、評論、聯系人等，上圖中的員工反饋、客戶反饋、市場變化等也都可以被標簽描述并關聯到產品上。一個產品能夠具有多少有效的標簽，反映了產品適用范圍的寬窄、承載信息能力的大小、對象描述能力的強弱。標簽與分類相比，更為靈活，可以無限拓展、自由添加，可以在保持單一分類的情況下，滿足各種視角的靈活展現，電商行業往往擁有海量的標簽庫。 可以參見以下標簽應用的示例：

從實現上來講，標簽數據包含標簽、產品、標簽與產品關系三個部分，標簽的產生一般包括用戶打標簽和系統打標簽兩類，前者根據用戶（包括內部用戶和外部用戶）的需要在用戶使用界面由用戶添加，后者根據預設的判斷規則由系統自動添加，比如點擊率超過某一限定次數，則判斷為熱點等，目前傳統行業此類應用較少，應該加大對標簽的研究力度，豐富標簽信息，增加標簽產生和應用方式，以便更好地建設大數據能力和AI能力。

聽過上邊的介紹，你可能會覺得給產品貼標簽、做分類是個再正常不過、也不會太難的事情，但是，在大企業中，這件事如果是部門級的，的確難度不大；如果要做企業級的，還真不太容易。多數金融企業以前還真的沒做過企業級產品目錄，都是部門級甚至是分行級的，各系統間的產品定義自然千差萬別，所以區分什么是產品、什么不是產品、該如何分類、分類的層級有多少、每個層級怎么確定，到處都是爭論，十幾個大型產品條線、上萬種具體產品，還不算分不清是不是產品的，確實夠吵上一陣子了。標簽其實是比分類更容易處理這個問題的。每一類不同的需求都可以轉化成不同的標簽集合，通過賦予產品大量的標簽，來滿足不同視角的展示和應用需要，這也就減少了部門對分類這種相對固定、又帶有一定權威象征的資源的爭奪。而從設計的角度來講，基于構件模型，設計人員主要應該關注的分類就是可售產品和裝配模板的映射關系，這個映射關系相當于產品的產地和配方標識，可以通過它找到產品的組成構件、構件的提供方等關鍵信息。這個關系如下圖所示：

可以看出這種方式比傳統的基于分類的目錄結構更有擴展性和彈性，業務和技術的不同需要可以兼顧，更有助于實現本章所提倡的通過產品目錄建設“產品信息高速公路”的設想。當然，標簽數量過多確實不易于維護和使用，除了要不斷改善技術手段外，也應當認識到，凡事有利必有弊，要獲得回報也必須要有一定付出，目前的人工智能也是先有“人工”才有“智能”。

產品是一個企業的價值載體，是為客戶服務的實例化表現形式，無論是生產類企業還是服務類企業都如此，產品將企業與客戶緊密聯系在一起，也是企業內外部信息的重要連接點，因此，應當在產品的系統化管理與實現方面多花些精力。

在此，我也聊些自己的“偏見”。現在都把“以客戶為中心”掛在嘴邊，似乎說產品就有些“以企業為中心”了，是從企業角度出發看問題，其實也不盡然。“以客戶為中心”只是改變了看產品的視角，卻并沒有真正改變產品的本質——企業的服務能力，企業的服務能力自然是企業的內部問題，哪怕企業擁有的只是資源整合能力而非真實的服務提供者，哪怕你實現了多高程度的API化，所以，無論怎樣強調“以客戶為中心”，問題還是要回到企業、回到產品上來解決，所以，多說說產品也沒什么不好。
?\t
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：為什么業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對復雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反復錘煉出標準模型
中臺之上（六）：如何為一個商業銀行設計業務架構？
中臺之上（七）：不神秘但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
中臺之上（九）：如何基于企業級業務架構管理業務需求？
中臺之上（十）：業務架構設計“笨重”，它能跟敏捷沾邊嗎？
中臺之上（十一）：企業級業務架構設計的“五難”
中臺之上（十二）：如何快速設計業務架構？
中臺之上（十三）：探討支持組裝式開發的業務架構設計方法
中臺之上（十四）：嘗試構建輕量級架構設計工具

作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關系、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公眾號：曉談巖說。

總結

以上是生活随笔為你收集整理的中台之上（十五）：被忽视的产品目录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。