轉型與變革

風險管理就是管理風險，聽起來好像很直觀，但具體來說要做哪些事情呢？是對風險進行評估？是來一場審查？是進行一次稽核？或者進行某種測試？感覺聽起來沒問題，但感覺好像又漏了些什麼！ NIST AI RMF 再一次沿用了 ISO 31000:2018 對於風險管理的定義： 組織為了針對風險進行方向引導與控制，而有系統地協調各項管理活動 簡單說，風險管理並不是進行某一種單一行動，而是協調多種管理活動，讓組織在面對風險時能夠建立一致的方向、做出適當的判斷，並採取相應的控制措施。 因此，風險評估、審查、稽核或測試都可能是風險管理的一部分，但單獨進行其中任何一項，都不能代表完整的風險管理。在後續的文章中，我們會逐步地去瞭解 NIST AI RMF 在風險管理上所主張的相關活動與舉措，但在進一步了解這些方法前，最重要的是有正確的 mindset，因為這樣才能讓自己在規劃與執行風險管理時仍持續地保持謹慎並且尋求更好的做法，而建構 mindset 的最好方法，不外乎就是了解風險管理的棘手挑戰。NIST AI RMF 在這裡進一步提出了四個 AI 風險管理需要面對的重要課題： 風險衡量 組織的資源永遠都是有限的。為了能夠正確地將資源投到關鍵的風險，對風險進行衡量是相當重要的舉措。在面對尚無有效衡量方式或尚未進行衡量的風險時，很難憑藉直觀方式來判定是否需要投入資源，畢竟未能被衡量的風險，既不能假定是高風險也無法認為不能衡量就是低風險，而這也是規範裡開宗明義所指出的一個要點。

這些年，AI 的蓬勃發展和誘人的可能性，早已讓組織一股腦地投入 AI 相關應用與探索，以便提升自身的競爭力。不過隨著技術漸漸落地，應該也不難發現 AI 所帶來的不確定性。比方說，即便發送相同問題的請求，AI 也無法保證次次給出相同或預期的結果，而且這還不討論近幾年大語言模型的幻覺現象。因此，想要從 AI 獲得好處，我們需要思考的是如何管控這些不確定性，並且做出合理的權衡決策。 NIST AI RMF 便是用來協助組織管理 AI 所帶來的風險與影響，讓組織能在控制潛在危害的同時，真正取得 AI 所帶來的效益。 想要了解這個工具，首先得先來聊聊 Risk 在風險管理情境下的概念。在日常情境下，聽到 Risk 這個字多半會先想到負面的事件。不過在風險管理的角度上來看，Risk 卻有更為寬廣的定義。 ISO 31000 定義 Risk2 為不確定性對既定目標所產生的影響(effect of uncertainty on objectives)

今年有很多機會幫忙客戶處理軟體品質提升和測試執行效率的議題，每每檢閱各種資訊後總是感觸良深。 一般來說，軟體開發通常都會有測試，但多半會著眼在類驗收型的測試。這類測試通常是軟體開發的品質活動下限，畢竟你的交付對象不可能不驗貨。不過這類測試有個大家都知道的問題，那就是通常很晚期才會知道對錯，而且執行期會看起來很長，畢竟所有測試都在最後一刻統一驗收。一口氣驗出所有問題，然後解決問題，時間很難不長。如果再搭配窘迫的測試人員和資源，那問題就很驚人了。 通常想要改善這情況，有幾件事得思考： 降低最終測試案例數量。可以做的方式如只驗收影響的部分、等價類劃分、透過風險和覆蓋率因素來分散測項的執行或改良與刪除無效測項等。不過這些方式能否有效展開的前提在於對受測系統的功能與模組的掌握度和良善的測試案例管理。如果沒這兩個前提，那麼很難做好什麼減量的決策，畢竟沒有依據。 多樣的測試方式與早期測試，也就是我們常說的左移。在工程上，一個基礎的原則是 built in quality。簡單說就是在每個軟體開發階段都確保該階段交付物的品質，不讓瑕疵流到下個階段。話是這麼說，但想做好這件事卻很少有速解方案。以單元測試為例，或許會有一個單純的想法那就是從現在開始規定大家都要寫單元測試。通常很容易會觀察到兩種結果，那就是不了了之和施行效率不佳。接著就會開始常見的故事： 那麼到底是誰的錯呢？ 正解是整個開發系統的錯，或者非要說誰的錯的話，那大概就是全部參與者的錯。 為什麼是這樣的理由？如果組織在新產品或專案或團隊的一開始沒有左移測試的念頭或至少融入一些除了類驗收測試外的其他測試手段。通常亡羊補牢並不容易，因為組織內的工程人員和非工程人員早已經長期透過各種方式貼補或容忍品質議題，而這類慣性會成為引入所謂「正確」做法時的巨大阻礙。此外，從未考量類驗收型測試外測試的軟體系統要再為其撰寫其他類測試有可能是相當困難的事情，因為目前的軟體實作結構可能盤根錯節且沾黏嚴重(耦合度高)。面對這樣的軟體系統，一般做法都會從舊系統內的新實作開始落實。不過，這類施行方式會有幾個關鍵議題需要尋求所有該系統參與者的共識： 成效可能不容易立即彰顯，而且開發時間還變長了！畢竟既有系統的原有品質問題不會憑空消失，所以會產生一種雖然投資了品質活動，但怎還是有問題的現象。這類認知落差非常需要被重視和解決，否則可能加劇工程和非工程人員之間的摩擦。可能的解決方式不外乎事前溝通、對齊關注指標、或針對高度有問題的部分做一次性的改善等。 測試不只是學會工具就行。測試有時會需要軟體設計方面的知識，所以千萬別認為送人去學 xUnit 之類的工具，然後就要馬上雞犬升天。通常是會升天，但可能不是你想像的那種。因此，除了強化測試技術本身的學習之外，持續強化工程團隊在設計上的能力也是相當必要的。可能的進行方式除了培訓外，還可以考量組織內非正式研討活動和加深團隊對既有系統的理解等。 萬年不變的流程和政策造成的變革阻礙。此處的流程不只包含開發，還需要考量開發流程的上下游或分支流程。除非在意的只是有沒有某種測試技術活動，而成效次之，那麼的確還真不用想太多。若是希望這些活動能夠紮根並且持續發展和提升，那麼除了考慮工程相關流程外，最好也思考一下與該受測系統相關的業務流程或其他營運流程，同時重新審視這些流程所涉及範圍的政策，以便去除不必要的摩擦。

什麼是遺留系統？ 遺留系統指的是已經運行多時，具有一定商業價值，但隨著時間推移，逐漸面臨架構、技術、軟體版本等過時問題的系統。 為什麼需要面對遺留系統❓ 由於遺留系統在商業營運上仍然有其必要性，因此往往難以輕易汰換。隨著新的商業需求出現，系統在過時的基礎上變得越來越難以修改或擴充。在某些情況下，即使發展新的系統，甚至會因為系統間的高度耦合，使其無法如預期般的退場。 遺留系統除了面臨維護成本逐漸上升，穩定性往往也會開始下降，最終導致工程團隊疲於應對與維護。因此，我們必須誠實地面對遺留系統所帶來的風險，並尋求長遠的解決策略。 跨出改善的關鍵活動 在 CPHT 進行遺留系統評估與改善輔導案的過程中，除了探尋從過去到現在商業決策的脈絡，同時也包含了挖掘第一線工程人員的認知與想法。其中幾個關鍵的活動： 遺留系統與技術債的評估 團隊拓墣與服務邊界的梳理 日常工作流程的梳理 人員對於負責系統、職務等的掌握度與適應性 每個系統的形成與演變，必然有其歷史背景與脈絡，其中包含當時的商業需求、組織樣貌、技術趨勢等。而從商業到工程之間的分析活動也意味著推動任何的改變都必須彌合商業與工程的落差。否則，即使出發點是為了改善遺留系統，眼前所採取的方案仍可能成為潛在的技術債，並在未來反噬！ 由於輔導的企業涉及上百人團隊與上百個長達五年甚至十年以上的軟體系統，因此透過這些盤點作業來梳理現況也至關重要。在現況盤點後，我們更能針對架構發現與顯著技術債來尋求在商業需求層面、技術層面、治理層面的長遠處置策略，以及在下一階段聚焦關鍵的改善活動。值得一提的是－去年幫助企業進行遺留系統評估與改善規劃後，最近 CPHT 也和客戶一起動起來，努力把改善計畫變成實際行動！ – 如果你也正在思考如何組織內的資訊系統與流程內追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro