1 前言

今年年初，劉潤老師在他的一個短視頻號上發布了一段視頻：《錢越來越難賺了，怎么辦》，在他看來錢越來越難賺了的原因主要有五個：效率被技術推動、行業稀缺性流動、消費者需求變化、組織內部熵增、經濟形勢不好；他認為的最佳應對策略是：卷與熬，鞏固基礎、修煉內功，讓自己別死掉，直到春天來臨。

這段視頻在企業內部激起了不小的討論，在當前的這個錢越來越難賺的行業背景下，數禾應該如何卷和熬成為了數禾人必須思考的問題， 聚焦到技術團隊內部，呼應公司層的決策，也采取了一系列舉措：建立BizDevops流程體系、引入DDD指導應用架構實踐、建立研發效能度量體系；然而這些舉措還是無法清晰回答“研發投入和系統完備度之間的關系”，例如：信貸核心系統做了這么久，為什么還是需要投入這么多研發資源 ？

2 如何解產研這道題？

我們雖然有研發效能度量，但是這套度量指標主要是針對BizDevops流程的多、快、好、省而制定的指標，能夠反饋出來我們的研發資源投入情況，但是很難回答為什么需要投入這些研發資源；而要回答這個問題，就需要結合系統建設情況做關聯分析。

在結合系統建設情況做關聯分析的時候，我們又遇到了新的問題，我們每天都在說“應用、系統、領域、產品”，這些詞到底是不是同一個意思？再基礎性的概念問題都沒有說清楚的時候，我們更加無法回答，資源投到哪里去了？

為了解決這一系列產研的問題，我們經過無數次的探討，總結了一套思路，我們稱之為“產品化體系建設”，本文主要是介紹產品化體系建設的三步主要是怎么做的，并且在文末給出了一個詳細的產品梳理的案例。

產品化體系建設三步走

3 基于企業架構做要素拆解

3.1 什么是企業架構

企業架構是定義企業各個組成部分如何構建，企業各個組成部分之間的關系以及企業各個組成部分演變的原則和規定，主要包括：業務架構、數據架構、應用架構、技術架構。

企業架構是戰略和數字化項目的橋梁，向上銜接戰略規劃，向下連接項目實施。“協調”與“對齊”是企業架構的重要特性和作用之一，縱向協調戰略、規劃、實施、運營各層級一致性。橫向對齊業務、數據、應用與技術。

企業架構在企業中的位置

3.2 數禾企業架構框架（SEAF）

數禾企業架構框架（SEAF）：是一個符合數禾的企業現狀的，參考了TOGAF和華為企業架構而形成的一套輕量化、可落地的企業架構方法。框架本身需要遵循下面的四條原則：

1. 戰略和業務價值驅動：一切從業務出發，以價值驅動，是架構設計的重要的原則和基礎
2. 符合數禾現狀可落地：企業架構框架和產研流程緊密融合，讓所有企業架構框架中的要素都在產研中被嚴格遵從
3. 輕量化：概念簡化，只保留工作中需要的要素，去除不必要的要素
4. 產品化：以產品為中心打造4A架構體系，流程通過產品實現線上化、應用實現產品功能并歸屬于產品，產研流程以產品化開發模式，通過組合各個產品功能， 交付符合業務期望的解決方案。

3.3 數禾企業架構模型

企業架構模型：是對于架構核心概念要素的精確定義和描述，元模型構成了架構設計的“基本語言要素”，通過元模型及其關系的表達，就可以通過結構化的方式對于架構進行描述和展現，元模型是企業級架構框架的核心，是對于架構描述的“統一語言”。

3.3.1 數禾企業架構元模型

數禾企業架構元模型

3.3.2 數禾企業架構核心要素解釋

企業架構核心要素

3.4 產出企業的產品地圖

對公司已有的產品資產進行梳理，形成一個產品全景圖基線，并且建立完善的產品生命周期管理體系，以提高產品成熟度為過程目標，最終實現三大目標：減少產研投入人力、提高產研質量、沉淀科技能力。

每一個產品的梳理都應該做到：梳理業務流程，識別業務對象、業務過程和使用的業務規則。首先實現對象、過程的系統化管理，記錄業務對象的全量、全生命周期數據，記錄業務活動的執行或操作軌跡，實現業務規則的結構化、配置化管理。然后進一步向業務流程自動化、業務決策智能化的方向發展。

金融科技企業產品地圖

4 產品標準

產品標準是通過經驗積累，將一個產品必備的能力組合形成一套用于指導產品如何變好的標準。但是并不是符合產品標準就一定是一個好產品， 產品標準是用于提高產品下限的，要做好產品，還需要產品經理不斷探索，把產品做精做透。

產品標準框架

5 產品化運營體系

1. 對標阿里的 “BIzDevops”方法，整理數禾的產研流程，和產品的生命周期匹配。
2. 建立產品/應用架構資產庫，沉淀架構資產，提高產研流程的運行效率。
3. 建立以產品為中心的運營團隊， 技術委員會為牽頭組織， 每個產品任命對應的產品負責人和技術負責人。
4. 建立產品標準和度量體系，指導產品建設，提高產品的成熟度。

產品運營體系

6 應用架構實踐案例

本案例是以貸后催收業務為背景，從催收業務流程觸發，逐步分析最后產出一套基于企業公共能力、滿足催收業務場景的解決方案。

6.1 基于業務流程總結功能模塊

1. 從業務流程中識別業務活動和業務對象

2. 基于業務活動和業務對象劃分業務功能模塊

核心業務功能模塊

業務功能模塊類型

• 核心模塊：由主業務流程中的業務活動形成，如“催收數據處理”、“規則碼分案”
• 支撐模塊：支撐核心模塊的對象管理模塊，如用于支撐“坐席分案”的“坐席管理”，支撐非主業務流程的模塊，如“賬務處理”、“質檢管理”
• 通用模塊：各業務線都需要的功能模塊，通常有比較標準的實現方案，如“系統管理”、“數據大盤”

6.2 梳理業務功能矩陣

從業務功能模塊進一步分解到業務功能，可以參考以下方法：對于基于業務活動劃分的功能模塊，通常可以按照業務場景來劃分功能點，如“分案”業務模塊按照業務場景可以分為“規則碼分案”、“坐席分案”等 對于基于業務對象劃分的功能模塊，通常包括一組相關對象的生命周期管理，如“通知管理”包括“短信模板配置”、“AI提醒模板配置”等。

業務功能矩陣

6.3 劃分產品

將上一步梳理出來的業務功能各類到各個產品中。

產品業務功能矩陣

6.4 產出產品架構

產品架構由產品功能模塊和產品功能組成。 面向特定業務領域的產品往往只出現在單一解決方案中，其產品架構形態也與業務功能矩陣比較類似。

產品架構

6.5 產品功能拆分到應用

產品架構中的每個產品功能都應該有明確的應用來承載。從產品架構到應用架構只是將產品功能劃分到對應的應用。基于應用架構設計原則，結合技術架構標準，進一步拆分應用，形成最終版本的應用清單，輸出最后的應用架構圖。

應用架構

6.6 形成面向業務領域的解決方案

解決方案由產品+實施組成。 一套解決方案通常包含N個產品，在此基礎上完成產品配置和集成的實施工作，從而實現特定領域內的業務能力。 產品所屬領域劃分：

• 核心域：實現核心業務功能，承載核心業務流程處理 支撐域：支撐核心業務功能，增強業務處理能力
• 通用域：業務屬性較弱，在多個業務領域都可能需要通用能力，往往有比較標準的實現方式
• 數據域：業務實現數字化、智能化必不可少的功能領域

解決方案架構

7總結

架構管理是一個復雜的系統工程，只靠一套方法論和少數運動式的項目是無法達成目標的；要達到期望的目標既需要企業架構這樣的方法論，從頂層做好規劃，也需要敏捷開發這樣的實踐方法，創建MVP而不是追求完美，在實踐過程中快速迭代。我們的應用架構管理實踐之路才剛剛開始，路漫漫其修遠兮，在實踐的過程中自我迭代也是非常重要的， 只有自我認知跟得上，才是實踐成功的最大保障。