最近...在想一件事。ERP。企業資源規劃。
聽起來很硬，但以前不是這樣的。以前搞 ERP 的人，很強。真的。他們不是只會寫 code 的工程師，也不是只會看報表的財務。他們是混合體。
大概...六成懂技術，四成懂生意。或是反過來。這種人，一個人就能打。他們直接跟用的人開會，聽需求，然後...很重要的一點是，他們會挑戰你。「你確定真的要做這個功能嗎？沒必要吧？」-p>
然後，文件寫一寫，給老闆簽個名，東西就做出來了。一個職位搞定全部，叫做「ERP 程式設計分析師」。很精實，沒廢話。
重點一句話
我們把簡單的事情搞複雜了。塞了一堆「中間人」進來，開了一堆沒意義的會，結果就是...大家都痛苦，事情還做不出來。
現在是怎樣？一場災難
快轉到今天。嗯...情況完全失控。
以前一個「程式設計分析師」能做完的事，現在被切成好幾個角色。產品經理、專案經理、商業分析師、QA、解決方案架構師、企業架構師...等等，還有什麼組織變革大使咧，天啊。
每個人都有自己的小山頭，自己的審批流程。結果呢？解決問題了嗎？沒有。只是把事情搞得更複雜。一個簡單的功能，以前可能幾週，現在要幾個月。跑不完的簽核，開不完的會。
就像那個...[The Goal] 這本書的作者 Eliyahu Goldratt 說的，任何不能讓公司更接近目標的行動，都是純粹的浪費。我們現在的 ERP 團隊，根本是浪費的藝術大師。
中間人、會議、還有無止盡的痛苦
我看到一個很有趣的現象。現在的專案，特別是跟 ERP 有關的，問題不在技術，在「人」。太多人了。
想像一個場景：一個使用者提了個小小的修改需求。
在過去，那個全能的分析師會直接跟他聊，可能半小時就搞懂了，然後評估一下，下週就給你。
現在呢？商業分析師（BA）先去訪談，寫一份文件。然後產品經理（PM）拿這份文件去跟專案經理（PjM）開會，排進時程。專案經理再去找架構師（Architect）開會，確認技術可行性。架構師說可以，然後這件事才終於能寫成一個「user story」，丟進待辦清單...這還沒開始寫 code 喔。
這中間只要有一個人理解錯了，或是有自己的想法，整件事就歪掉了。
這還沒算上外包。如果再加上 offshore 團隊，那更是災難。內部先開好幾次會，喬好一份「完美」的規格文件（FDD），然後丟到海外。海外的開發者，可能同時做好幾個案子，對你的業務根本不熟。他們就照著文件做，一個字都不敢改。
這就像小時候玩的遊戲「傳話遊戲」。一句簡單的話，傳到最後，變得面目全非。一開始的需求是「我想要一個按鈕能匯出報表」，最後做出來的可能是「一個會發 email 通知所有人的巨大紅色按鈕」。然後就是無止盡的修改、開會、爭執。所謂省下來的成本？早就被這些鳥事給耗光了。
這狀況只有台灣這樣嗎？不，全球都差不多
說真的，我本來以為這是不是台灣企業特別愛搞階級、愛開會的文化造成的。後來去看了些國外的資料，像是 Gartner 的一些報告或是一些資深顧問的文章，才發現...不，這是個全球性的瘟疫。
國外的企業，特別是大的那種，分工更細，角色更多。他們把這套稱之為「專業分工」或「敏捷規模化框架」。聽起來很厲害，但骨子裡的問題一樣。不過呢，有個地方有點不一樣。在北美或歐洲，他們對於「架構師」或「產品負責人 (Product Owner)」的權力界定非常清楚，這個人說了算，其他人比較像是支援部隊。
但在台灣，我自己是覺得，常常變成「人人都是老闆」。專案經理有意見，部門主管有想法，連使用者自己都可能今天說 A 明天說 B。結果就是 PM 跟 BA 變成夾心餅乾，整天在「喬事情」，而不是在「做事情」。我們好像更在意「關係」，而不是「規則」。這沒有絕對好壞，但在這種複雜的專案裡，真的會把事情拖垮。
一張表看懂今昔差異
講了這麼多，直接列表格比較清楚。以前跟現在的 ERP 專案到底差在哪。
| 項目 | 過去的黃金年代 | 現在的官僚地獄 |
|---|---|---|
| 核心角色 | 一個「程式設計分析師」。懂生意也懂技術，超強。 | 一整個軍隊。PM, BA, QA, Architect...還有一堆叫不出名字的。 |
| 溝通方式 | 直接跟使用者聊。面對面，有問題馬上解決。 | 開會、寫文件、再開會。用 Email 和 Jira 傳話，常常傳錯。 |
| 決策速度 | 很快。分析師自己就能判斷，頂多跟主管報備一下。 | 慢到哭。要經過 N 層簽核，每個「中間人」都要刷存在感。 |
| 產出時間 | 一個小功能可能一兩週。 | 幾個月起跳吧。光是「溝通」就佔掉一半時間。 |
| 最終結果 | 通常很貼近使用者需求，因為就是他做的。 | 做出來的東西...嗯，常常跟當初想的不一樣。是個四不像。 |
| 團隊心情 | 有成就感。事情做得快，有幫到人。 | 很無力。覺得自己每天都在做些沒意義的鳥事...就是 [Bullshit Jobs] 講的那樣。 |
風險與應變...還有救嗎？
所以，沒救了嗎？整個環境都這樣了。我自己覺得，還是有希望的，但要看公司高層的決心。
最大的風險，其實是「習慣」。大家習慣了這種做事方法，覺得「本來就該這樣」。很多主管的權力，就建立在「審批」跟「開會」上。你要他放手，等於要他的命。
David Graeber 在他的書 [Bullshit Jobs: A Theory] 裡講得超對：「很大一部分人，終其一生都在做他們私底下覺得根本沒必要做的工作。」ERP 專案的臃腫，就是這種現象的極致展現。
那怎麼辦？
我覺得，只能從小地方開始「反叛」。如果你是團隊成員，試著繞過流程。能不能直接找那個使用者喝杯咖啡，把事情問清楚？能不能跟開發者直接拉個 5 分鐘短會，而不是等一週後的正式會議？
如果你是主管，試著授權。能不能讓你的團隊自己決定一些小事？能不能砍掉一些沒必要的會議？Jason Fried 在 [Rework] 這本書裡說，「會議是毒藥」。它們傳遞的資訊量極低，卻耗掉大量時間。真的，少開一點會吧。
核心思想就是：回歸基本。找回那種懂生意、懂技術、能直接解決問題的人，給他權力，讓他去做。把那些只會傳話、製造文件的「中間人」拿掉。
建立一個小而精悍的團隊，可能只有三四個人，但每個人都是戰將。他們自己討論、自己設計、自己開發、自己測試。效率絕對比一個三十人的官僚大軍高得多。
常見錯誤與誤解釐清
- 誤解一：「人多好辦事，分工越細越專業。」
錯。在軟體開發，特別是需求會變來變去的商業系統裡，溝通成本是隱形殺手。每增加一個人，溝通的路徑就指數級增長。最後大家都在溝通，沒人做事。 - 誤解二：「外包 offshore 一定比較省錢。」
大錯特錯。這只計算了開發者的小時薪資，卻忽略了溝通成本、管理成本、重工成本，還有文化與時區差異造成的延誤。算總帳下來，常常更貴。 - 誤解三：「流程完整，文件齊全，就能保證品質。」
流程和文件是必要的，但它們只是工具，不是目標。過度的流程反而會扼殺應變能力和常識。最好的品質保證，是讓有能力的人直接負責。
說到底，ERP 的初衷是提升企業效率的骨幹。現在卻常常變成...拖垮效率的贅肉。我們 traded 效率 for 政治， traded 結果 for 流程。這真的很諷刺。
是時候想想了，我們到底是在解決問題，還是在製造更多問題？
在你公司，一個簡單的系統功能修改，從提出到上線，大概要跑多久？你覺得哪個環節最浪費時間？在下面留言分享一下吧。
