這幾天跟一兩位朋友恰好都有聊到一些對於顧問行業的觀察，其中一位朋友提出：

我看來看去，經營得比較好的顧問，大致上還是以賣課程的居多。(編按：更有影響力形式的相對少得多。)

另一位朋友則說：

我覺得是thought leader在台灣的樣本數太少，大家搞不清楚standard process長怎樣，所以不敢冒險。

由於朋友們一一提出了台灣如何缺乏顧問典範的論點，我想這暗示了一個值得回答的問題：「什麼是顧問的典範？」

典範

最初 (五年前)，我想象中的顧問典範，大致上有三個特色：

1. 基於對客戶的成效而收費，而非基於工作時數而收費。

2. 他們通常會透過寫書、寫文章、給演講的方式，公開發表他的獨特知識，方便他的潛在客戶評估，是否這位顧問幫得上忙。

3. 他們打動客戶的主要敘事是：「 AAA 是我認知到的問題，BBB 則是我領悟到的解法。」而不是個人成功、科技焦慮、或是英雄之旅

   • 個人成功：因為我曾經擔任某企業的 OOO，所以我高人一等。

   • 科技焦慮：全世界都用 AI 了，所以你再不學就落伍了。

   • 英雄之旅：我曾經 AAA 般地失敗，被前輩一句話點醒，後來我經過了 BBB 的努力，達成了 CCC 的高度。

後來才想通的世界觀

在經營顧問公司五年之間，我陸續研究了一些問題、解決方案、正確但無法執行的作法、不算精確但是可以前進的作法，我發現，原來我有一些世界觀是之前相對隱晦的。

在我心裡，我深深相信兩件事：

1. 顧問給的意見如果要有可行性，就需要反覆在不同尺度的系統中，練習「在約束中做結構化取捨」。

2. 系統的長期品質，重點在於結構設計，而不是努力或聰明程度。

尺度、取捨與結構

這兩點信念，導向了我在執業時的逐步領悟出的四個核心實踐。我發現，IT 顧問可以至少在四個不同的系統尺度（Scope）中遊走，並在每個尺度中找到其核心的「結構取捨」，從而最大化影響力：

1. 在個人的層次，我不太相信成功學，我傾向談論如何穩定地提高自己成功的機率。 我通常透過 MBTI ，協助友人了解自身的強項，鼓勵友人選擇適合自己的機會、發揮強項。同時，我總是強調，人的決策過程、問題解決過程應該要結構化。

2. 在公司的層次，我認為商業策略的本質就是「選定一個 niche 並成為第一」。公司總是缺乏時間、金錢、人力種種的資源，而專注就是不浪費資源的最佳解法之一。

3. 在 Application Programming 層次，我推崇 FP (Functional Programming) 與 Clojure。 這不只是技術偏好，而是基於追求品質、正確性、長期價值的世界觀。當我們能採取基於對問題充分理解的設計，系統的複雜度就會呈現線性增長而非指數增長。

4. 在 IT 部門的層次， Separate Policy from Mechanism 則是一條極有用的設計原則。 當我們能將 auth、workflow 或 BI 這些「機制（Mechanism）」抽象成共通能力，組織才能真正落實專業分工，讓「政策（Policy）」層面靈活變動。這種架構上的取捨，決定了 IT 部門究竟是業務的瓶頸，還是加速器。

結語：知易行難

我想我很幸運，在開始的時候，我就鐵了心不選擇另一種世界觀：

人會因為信念而行動，不確定性可以用敘事覆蓋。

我有時候會想，上述的那種世界觀操作到極致，且沒有對應的結構化方法論，是不是算是一種洗腦？

我的作法在開始的時候確實有很多困難，說得更明白一些，我許多的解決方案並沒有順利地找到最佳客戶，但是，愈往前走有更加順利一些了。