背景
A 保險公司是一家壽險公司，每月有近20萬份保單要處理，促銷期，每月超過40萬份保單。除了實體印製的保單提供給保戶外，尚須要提供 PDF 格式的電子保單，供存底及查詢。未來，希望進一步提供互動式電子保單，提高客戶的滿意度。 除保單外，超過160款的各式信函模版，每天不定時的電子發送及列印寄發。
面臨的痛點
模版開發工具為專屬語言
原服務廠商，因為業務策略調整，將中止後續保單模版開發業務服務
既有保單及信函模版，均為原廠商專屬模版開發工具，非標準開源工具。學習門檻高，開發人員難覓，維護不易。
渲染速度太慢
保單及信函 PDF 文件生成速度已經遠遠無法滿足目前業務服務的時效要求。
在尖峰時期，每天的 PDF 生成時間，往往超過24小時，無法滿足時效。
目前採用的保單生成架構是 Client-Server 架構，在促銷期間，需要大量保單生成時，服務器無法即時擴容提高生產處理能力。
缺乏需求及開發間的協作平台
需求異動頻繁，缺乏每一個需求的落實追蹤。
既有的保單模版使用多年，其中的邏輯因開發人員異動已經無法一一找出脈絡。若重新翻寫，牽一髮動全身，沒人敢隨意更動。
模版開發與審核之間，往往透過郵件形式來溝通，難以達到有效率的溝通。
缺乏版本管控機制
模版更改頻率高，舊版本不會即時中止使用，甚至有時還交替使用。由於缺乏良好的版本管控機制，很容易衍生問題，複雜度高。
改 A 錯 B 的問題
各個模板間，有共用的組件。缺乏模版組件管理的機制，常會出現改了 A 模板後，反而在不知不覺下，導致 B 模版出了問題，難以察覺。
驗單工具不夠友善
保單及信函 PDF 要正式發布前需要作驗單，以確保每一份保單及信函正確無誤。但是，保單數量龐大，人工驗單耗時耗力，成本極高。
模版設計缺乏統一樣式
模版樣式不統一，舉凡字型、行距，字距、版面編排⋯⋯等，缺乏統一，重覆設計明顯，維護也不易。
除了 PDF 文件格式外，無法生成其他格式
越來越多的業務單位提出，除了 PDF 外的互動文件形式要求。但是，目前架構無法實現，必須採用其他平台另外開發。
當時的保單生成僅單純考慮 PDF 輸出，未考慮網際網路的多元展現。現在要接軌，有重複開發的問題。
未來模版重新翻寫，如何與舊模版順利轉移？
模版作轉換時，新模板如何確保與舊模版所產生的 PDF 一致？因為，模版款式很多，若無法快速驗證比對，單靠人工肉眼比對，將導致轉換工程嚴重延宕。
解決的目標
採用標準與開放的模版開發工具，以取代廠商專屬開發工具。
採用雲端架構，以滿足網際網路多元的業務需求。
遵循 “Single Source Of Truth” 開發準則，以簡化日後管理的複雜度。
採用微服務架構，易於未來功能上的擴充，及處理能力的瞬間平行擴容。
建立 Design System，以建立企業的統一形象。
模版零件化，以提高模版開發品質及效率。
建立一個線上協作平台，實現線上需求管理及版本管理。
提高 PDF 生成速度，要求速度最少需達到50,000頁 A4 /小時（含高解析圖片）。
驗單智能化，以提高效能及準確性。
建立回歸測試機制，以避免「改 A 錯 B」的現象。
PDF 文件生成，須能同時處理批次 (batch) 及線上 (On-line) 單筆的需求。
建立Design Sytem及模版零件化
當我們在梳理原有的模版時，發現各個模板所使用的 Logo、字型、頁首、頁尾、頁面的編排⋯⋯等都不統一。因此，在與客戶協同努力下，建立一套模版開發適用的 Design System，同時也將模版零件化。Design System 的概念類似企業識別體系 (CIS)。有這個 Design System 作為依據，模版開發就有所依據，不會因為不同人開發，而有不同的展現樣式，可以確保企業統一形象及模版的開發品質。 模版零件化則可以簡化模版的開發，讓元件可以在不同模版中使用，大大提高模版的交付速度及品質。
保單模版的開發與管理
採用符合 W3C 標準的 HTML+CSS3+JavaScript 作為模版開發語言，重新翻寫保單及信函模版。
HTML+CSS3+JavaScript 完全是網際網路原生的語言，最適合於網際網路的應用。除了靜態PDF文件外，當然也可以在同一個 PDF 模版基礎上，開發互動的 HTML 文件格式，實現「同源多元的輸出」。
採用 Git CI/CD 開發模式，建立需求管理及版本管理的機制
每一個需求都建立 Issue 管理起來，過程中的討論及狀態都可以隨時追蹤，確保每一個需求都能夠準確無誤地交付。
採用 CI/CD 模式，將開發與生產部署自動化。
提供日後模版修改需求及各版本管控全記錄。
保單及信函的生成（文件渲染）
採用SSMO Central（On Premise）平台
加掛：
DocGear 渲染引擎
DocLens 智能驗單
根據客戶對文件生成時效的要求，在多核心處理服務器，提供 DocGear 多個授權。允許在高峰值時，瞬間平行擴充處理能力。由原來的舊系統18小時處理時間，縮短到2個小時。
驗單
DocLens 大幅提高驗單校驗的效率。
由原來採用人工 PDF 肉眼逐筆比對，提升為智能比對。將可能的錯誤，儘量由軟體來判別，並篩選出不合理的頁面。
在舊模版與新模板切換的過程中，採用智能驗單，將舊模版生成的 PDF 作為參考樣本，與新模版生成的 PDF 直接作自動化比對，將差異直接挑出，大幅縮短模版上線的時程。
文件處理流程
同一筆保單資料可能需要作紙本的列印、PDF 電子查詢、發送 email 通知⋯⋯等。中間可能還需要插入不同的頁面文件，譬如封皮、簽章、客製化圖片⋯⋯等；
針對列印輸出，有時也需要考慮紙張大小。譬如：將 A4 的 PDF 落版在 A3 的紙面上。
每一個輸出渠道都會有不同的處理要求，未來滿足這些多樣的需求，就必須考慮處理流程機制的彈性。
DocGear 內建流程設置的機制，可以在渲染文件後，針對不同的文件，再進一步進行加工處理。
發佈渠道管理
紙本列印、PDF 電子查詢、發送 email ⋯⋯等，都是一種發佈渠道的類型。我們需要掌握各個渠道的狀態、歷史紀錄、負載能力⋯⋯等，並作實時的監控確保系統的穩定。
結論
整個轉移過程中，最耗人力的部份，當屬模版的翻寫了。在缺乏完整模版規格情況下，靠反向工程直接翻寫所有保單模版及160幾款信函模版。
另一個技術挑戰，則是與其他系統的介接。舉凡數據庫、核心業務系統、email 服務、各種應用及各種通信協定的介接，都需要廣泛的技術基礎，才能在最短時程完成。
在動員12位工程師，歷時三個月的時間，我們就已經開始進入整合測試。
<待續>