n8n 自動化團隊轉型：告別服務台模式，賦能各部門自主建構

n8n 內部 AI 與自動化主管 Romina da Costa 分享了她的團隊所採用的四項原則，旨在協助每個團隊都能自行建構並掌握其自動化流程。

在「n8n 談 n8n」系列文章的首篇中，我們的內部 AI 與自動化主管 Romina da Costa 解釋了服務台模式的局限性。她也分享了團隊目前遵循的四項原則，以協助 n8n 的每個團隊都能自行建構並掌握其自動化流程。對於一個自動化團隊而言，成功的定義是什麼？是完成的工作流程、結案的工單，還是清空的待辦事項？簡而言之，這些都不是真正讓自動化團隊成功的關鍵。

每個集中式的自動化團隊都解決了實際的業務問題，例如自動化例行性任務、釋放時間，以及承擔不需要人工判斷的工作。然而，正是因為做得太好，導致組織其他部門會持續依賴你來解決問題，而非將這種能力內建到組織的運作方式中。你並沒有解決瓶頸，只是將它轉移到下游。

這並非 n8n 獨有的錯誤，我認為這根本不是錯誤。大多數組織，特別是企業級別的，最終都會意識到這一點。你建立了一個集中式的自動化團隊，清空了待辦事項，讓員工擺脫了例行性工作。這一切在一段時間內確實有效。然而，隨之而來的卻是一個無人預算到的問題：誰來維護你所建構的一切？以及解決了第一個問題的團隊，能否無限期地承擔第二個問題。

在此之下，還有一個更大的轉變正在發生。建構工作流程、代理程式和內部工具，對於非工程師而言變得越來越容易。你可能會認為這使得中央自動化團隊變得不那麼必要。但我認為這讓這份工作變得更重要，只是職責不同了。稀缺的技能不再是「你能不能建構這個」，而是「這個該不該建構、你如何知道它有效、哪種工具最適合，以及當它出問題時誰來負責」。建構的便利性提高了判斷力的重要性，並未消除對判斷力的需求。

因此，這是我對自動化團隊職責的實際看法，也是我來到這裡的最初幾個月，致力於改變團隊成功定義的原因。自動化團隊一直運作良好，但其模式已達到極限。

在我到任之前，自動化團隊的建立是為了解決一個實際問題。n8n 的各團隊被手動工作淹沒，且組織內部沒有足夠的協調來系統性地解決問題。因此，公司聘請了工程師來建構工作流程，連結工具、消除重複性任務，並讓員工投入更高價值的工作。這在當時是正確的決策，團隊也確實出色地完成了任務。

今年稍早我加入並領導這個職能時，發現這個團隊的成功與公司的成長，默默地揭示了其所依賴模式的局限性。我們擁有超過 12,000 個內部工作流程，無論多麼優秀的團隊，都無法建構並維護所有這些流程。如果「建構更多自動化」仍然是職責描述，那麼我將會成為阻礙公司達成我受聘來加速實現的成果。

這就是我會提醒任何擔任我這種職位的人的陷阱。這並非前一個團隊或模式的失敗，而是這個職能若任其自然發展，最終會走向的結果。這沒關係，甚至是可以預期的。然而，在某個時刻，領導 AI 和自動化的人就必須介入，刻意地打斷這種趨勢，以免為時過晚。如果你真正想建立的是一個高度自動化、AI 優先，並準備好應對工作變化的組織，這一點尤其重要。

重新定義：從建構自動化到建構自動化文化。我一直在思考的問題不是「我們如何建構更多自動化？」，而是「我如何建立一個讓每個團隊都能像自動化工程師一樣思考和行動的公司？」。這兩個問題聽起來相似，但對於我們處理工作的方式以及工作的實際樣貌，卻有著截然不同的影響。

在第一個問題下，成功看起來像是產出量。而在第二個問題下，成功則像是究竟有多少團隊不再需要我們。我花費了最初幾個月的時間，試圖讓第二個答案成為現實。這意味著要弄清楚如何才能實現這一目標：不僅要改變我的團隊工作方式，還要改變我們被看待的方式，以及其他團隊最初選擇與我們互動的方式。這在紙上看起來只是一個小小的轉變，但它幾乎改變了我們每週的工作內容。

實踐中，這轉化為四項原則。1. 培養建構者，而不僅僅是建構成果。我的團隊所做的最高槓桿工作，並非本週交付的工作流程。而是賦能，這意味著當下次出現類似情況時，團隊就不再需要我們。這發生在幾個不同的層面。

在個人層面，這看起來像是我的一位工程師本季度沒有為利害關係人編寫自動化，而是與她坐在一起，協助她調試自己的自動化流程：審查失敗原因，並向她展示如何更改以及為何更改。無論哪種方式，工作流程都得到了修復。不同之處在於，她下次就不再需要我們了。

在團隊或部門層面，這包括培訓課程、其他團隊可以從中開始的重複使用工作流程（而非盲目建構）、人們帶著實際問題前來，我們與他們一同建構的辦公時間，以及技術擁護者網絡：每個部門有一位成員，他們充分了解團隊的流程並能清楚描述，同時負責該團隊日常使用的工具。他們不一定是工程師，但必須是能告訴你流程運作方式的人，而這往往是更難找到的技能。

每個部門擁有一位擁護者是一個真正的起點，而非終點。它在賦能之外還有其他用處：當一個部門還沒有明顯的擁護者時，這會告訴我們一些事情，包括接下來應該將重點放在哪裡，以及我們實際應該招聘什麼樣的人。坦白說，我們的目標不僅僅是每個團隊一人。在理想情況下，大多數人都能為自己的職能擔任擁護者。我們還沒達到那個境界，但必須從某處開始，而每個部門一位明確的負責人是一個合理的起點。

在公司層面，這看起來像是我們正在建立的 AI 素養框架：關於負責任地使用 AI 的共享標準和共同判斷基準，這些都不依賴於任何單一團隊來維持。從外部看，為某人建構和與他們一同建構可能看起來一模一樣，特別是如果你只計算交付的工作流程。然而，它們是完全不同的工作。讓我的團隊和我們的利害關係人真正理解這種差異，是我最初幾個月大部分的工作。

2. 在建構之前要求建立基準。這源於我親眼目睹的一個錯誤。我們的一個 AI 代理在一個月內產生了令人印象深刻的成果：六位數的銷售管道。這看起來像是一個明顯的勝利，直到我問了一個真正重要的問題：與什麼相比？

並非我們沒有可比較的對象。我們有關於人類 SDR（銷售開發代表）產出的實際數據。複雜之處在於，比較本身並不清晰。該代理程式全天候運作，從不休息，而當時我們的人類 SDR 主要處理代理程式已經篩選掉的更困難、更複雜的工作。將代理程式的原始銷售管道數字與人類 SDR 的數字進行比較，實際上並非同類比較，而要弄清楚公平的比較方式，需要付出真正的努力。

從那以後，我對我的團隊設定了一個嚴格的要求。在任何新的自動化專案開始之前，我們會詢問提出請求的團隊，目前的情況究竟如何：工作發生的頻率、所需時間、涉及多少人、目前產生了什麼，以及什麼才算是真正有意義的改進，即使答案只是猜測。猜測仍然比什麼都沒有更有用，而提出這個問題往往是人們第一次思考這些事情。

3. 針對問題選擇工具，而非選擇你習慣的工具。一旦你真正了解要改進什麼，下一個問題就更容易回答：什麼是適合的工具？我們不為建構而建構，而且通常會推動購買決策，而非自行建構。鑑於我們是 n8n，這一點讓人感到驚訝。一般來說，如果市場上存在一個經過驗證、特定的工具一年或更長時間，通常購買會比內部建構更好，其原因不僅僅是哪種選項現在效果更好。

自行建構意味著無限期地承擔維護負擔和安全風險，而專門的供應商團隊會持續按照他們的路線圖發布更新，而我們的 V1 版本則會停止跟進。SaaS 工具會產生持續成本；自行建構只是將其換成另一種較不明顯的成本：我們團隊的時間，用於維護、保養和改進，只要該事物存在。

真正的問題不僅僅是哪種選項現在效果更好，而是我們實際上希望在未來幾年內負責維護和改進什麼。

同樣的原則也適用於代理程式與工作流程的選擇。並非每個流程都需要大型語言模型（LLM）的參與。我曾看到團隊收到的自動化請求，其實際任務功能上只是「將這封電子郵件轉發給 James」，卻被包裝成一個代理程式，然而一個簡單的電子郵件篩選器就能毫無錯誤地完成這項工作。這種原則並非避免使用代理程式，而是當一個更簡單、更可預測的工具已經解決問題時，拒絕出於便利或炒作而選擇使用代理程式。

4. 確保我們建構的成果具有韌性。我的團隊交付的每個工作流程都是一項承諾，而非一次性幫忙。它需要一個負責人、文件、錯誤處理，以及當建構者轉去做其他事情時的應變計畫，因為這最終會發生。一個六個月後無人理解的巧妙自動化，將成為一種負擔。

這部分仍是我們努力的目標。我們尚未擁有全團隊遵循的單一文件標準，因此一位工程師的筆記與另一位截然不同，當有人必須接手不屬於自己的工作時，這會造成實際的成本。我們現在正在制定一個共享的文件範本，每個工作流程都將以此為衡量標準，並目標在未來幾週內實施。最困難的部分不會是撰寫標準，而是實際執行它，確保每個工作流程都達到相同的記錄標準，而不僅僅是那些有人碰巧有時間處理的。

轉變我們的模式以轉變組織。我不想讓我的團隊成為一個服務台，一個接收請求並按需交付產出的團隊。我希望我們能以正確的方式解決正確的問題。有時這意味著建構一些東西，有時則意味著教導一個團隊自行建構。有時甚至意味著告訴利害關係人，他們所描述的還不是一個自動化問題。

這就是我們的意圖。我們還沒有完全達成目標。實際上，我的團隊仍然比我希望的更常像服務台一樣運作，而原因並非真正關乎流程。這是因為文化轉變緩慢，而且對於一家快速發展的公司中的員工來說，要找到時間學習如何自行建構和掌握自動化，確實很困難。我的團隊更頻繁地拒絕請求，並不能單獨解決這個問題。

這需要領導層和其他職能部門的真正支持：將 AI 素養納入員工評估的一部分，設定具體目標，說明每個職能如何使用 AI 和自動化，以及建構