導入新工具不被罵的 7 個步驟：變革溝通 checklist

「工具都發下去了，怎麼還是沒人用？」這是很多 IT 決策者導入新系統三個月後的心聲。組織變革管理談的正是這件事：把數位轉型工具「裝進公司」很快，把它「裝進每個人的工作習慣」才是真正的難關。

問題多半不在工具好不好。Atlassian《The State of Teams 2026》調查 12,035 位知識工作者與 173 位 Fortune 1000 高管後發現，89% 的高階主管認為 AI 提升了工作速度，卻只有 6% 有把握指出全組織層級的投資回報實例。買了、也變快了，卻證明不了對整間公司的效益，這種落差通常不是技術問題，是導入方式的問題。

更早的一份經典研究把話說得更直接。波士頓顧問公司（BCG）2020 年的《Flipping the Odds of Digital Transformation Success》分析發現，只有三成的轉型真正達標並帶來可持續的改變；但只要幾項關鍵要素備齊，成功率可以從 30% 翻到 80%，而其中最關鍵的一項，正是從 CEO 到中階主管的領導投入。導入新工具會不會「被罵」，關鍵往往在溝通與節奏，而不在功能列表。以下拆成可以照著做的步驟，每一步都寫清楚該做的事，以及最容易踩到的地雷。

為什麼一紙公告通常叫不動人

一紙「即日起改用新系統」的公告，通常換來的是陽奉陰違，因為它跳過了所有讓人願意改變的前置工作。組織會讀空氣：老闆自己還在用 LINE 交辦、公告卻要大家改用新平台，這套系統就自動被歸類為「可以不用的系統」。

變革管理和單純的系統上線差在哪？系統上線是 IT 的工作，把帳號開好、把功能設定好就結束；變革管理處理的是人願不願意改變行為，這件事沒有人能「設定」出來。BCG 那份研究會把「領導投入」列為關鍵要素之一，正是因為工具再好，缺了帶頭的人與對的節奏，多數轉型還是落在失敗的那七成裡。想先避開最常見的觀念誤區，可以搭配數位轉型的迷思破解一起看：那篇談「不要做什麼」，這裡談「照什麼順序做」。

先讓所有人同意「問題出在哪」

導入前最該做的一件事，是讓各個層級都同意「我們要解決的到底是哪個問題」。變革溝通的起手式是把痛點講到大家點頭，不是急著介紹工具。找幾位不同部門、不同層級的人聊一輪，用他們自己的話把痛點寫下來：業務嫌簽核要等主管出差回來、會計每個月月底對不完那張表、主管永遠不知道專案卡在誰手上。

該做的事：先讓問題有共識，再讓工具進場。當大家都同意「進度追蹤很痛」，之後導入追蹤工具時，員工看到的就是「終於有人要解決這件事」，而不是「又要多學一套」。

常見地雷：從工具出發，而不是從痛點出發。「我看同業都在用 Lark，我們也來導入」是最容易被罵的開場，因為第一線根本沒感覺到那個痛。另一個地雷是痛點只有高層有感：老闆看到的是報表拖累決策，第一線每天做的卻是另一批瑣事，兩邊的痛沒對上，工具就落在中間變成額外負擔。選型階段的評估重點，可參考數位轉型工具清單。

挑一批帶得動風向的種子使用者

種子使用者是變革能不能擴散的槓桿，挑對人，改變會自己長出來。理想的種子使用者有三個特質：被同事信任、願意嘗試、而且散布在不同部門和層級。人數不用多，一個部門級的導入抓五到八位就夠。

該做的事：為這批人開一個試點群組，給他們早鳥權限，把他們的回饋當一回事。他們踩到的問題先修掉，等全員上線時就少了一堆坑；更重要的是，同事看到「隔壁的老王都在用而且說不錯」，比任何官方宣導都有用。

常見地雷：只挑電腦最強的人或只挑年輕人當種子。這會直接引來一句「他們當然會用，他們本來就是高手」，反而讓其他人更覺得這工具跟自己無關。另一個地雷是由上而下硬指派，被指定的人自己沒被說服，只會把抗拒帶進群組。種子要選的是意見領袖，不是技術能力排行榜。

先圈一小塊範圍跑一輪

試點的價值在於用最小的代價證明「這條路走得通」，所以範圍一定要小。挑一個團隊、一個每天都會用到的高頻場景、一個可以量測的目標，設一段固定的短窗先跑起來。場景要挑見效快的，簽核或群組公告這類每天都碰的最好，年度盤點那種一年才一次的先別碰。

該做的事：試點前先定好「怎樣算成功」。例如「請假單從送出到核准的時間」，先量現況再看導入後的變化，有對照才有說服力。試點期間把待辦用任務追蹤集中管理，誰負責什麼、卡在哪都看得到。想用迭代的節奏跑，可參考敏捷導入的在地做法；先做哪個場景，也可以對照企業協作平台選型指南提到的導入順序。

常見地雷：一次全上。七個場景同時試，每個都分不到足夠的注意力，只要一個出包就可能連累整個專案被打回票。另一個地雷是挑了低頻場景試點，跑完也養不成日常習慣；還有沒定成功指標就開跑，結束時各說各話，誰也證明不了值不值得。

把跑出來的成果變成內部故事

試點成功之後，最該做的是把成果變成一個會被傳的故事，而不是讓它安靜地結束。人記得住的是故事，不是功能清單。把結果包成「有數字、有名字」的版本：業務部小陳的請假單，從以前要等三天變成四小時就核完。

該做的事：讓種子使用者自己講這個故事，然後用群公告佈達到大家看得到的地方。同一件事由 IT 部門公告，聽起來像推銷；由隔壁同事親口說，聽起來像分享。這一步呼應 BCG 研究裡「推動更廣採用」的要素：改變要擴散，得靠看得見的成功案例把其他人帶上來。

常見地雷：宣傳功能而不是宣傳成果。「新系統有甘特圖喔」沒有人會在意，「小陳的請假不用再追著主管跑」才會。另一個地雷是根本沒有內宣：試點默默成功、默默結束，其他部門完全沒聽說，好不容易累積的動能就這樣散掉。

分批帶人上手，別想一次到位

教育訓練要分批、分場景進行，一次把全公司塞進會議室講兩小時，下週就忘光了。有效的做法是按團隊或場景排梯次，而且教的是「你每天在做的那件事現在怎麼做」，不是把功能從頭到尾巡一遍。

該做的事：在員工快要用到某個功能之前才教，學完馬上用得上，才記得住。同時準備一份看得懂的繁中速查資料，讓人卡住時查得到答案。語言的門檻常被低估：一套介面是英文、教學是簡體用語的系統，對台灣第一線就是兩道額外的坎，這也是我們把繁中知識中心做到數百篇的原因。

常見地雷：把一次性的全員大會當成唯一訓練。人數越多、內容越雜，留下的越少。另一個地雷是功能巡禮式教學，把每個按鈕都講一遍，員工反而抓不到「跟我有關的是哪幾個」。教材只有英文或簡體、或是教得太早（員工還沒有帳號、還用不到），也都會讓訓練白做。

留一段新舊並行的過渡期

新舊系統並行一段固定時間，再設一個明確的落日日期，是過渡期該有的樣子。直接硬切會引發恐慌與出錯，永遠並行則會讓人賴在舊方法上，兩種極端都會出事。

該做的事：一開始就把落日日期講清楚，例如「線上簽核跑順的一個月後，紙本單據停收」。過渡期間的重點是幫忙，不是處罰，讓還沒跟上的人有時間、也有人可以問。落日條款是這一步的關鍵：該退場的是舊流程，不是還在猶豫要不要用新系統的人。

常見地雷：沒有落日日期。新舊無限期並行，員工做兩遍工，怨氣最後全記在新系統頭上，這是最隱蔽的失敗。反過來，完全不留過渡、公告當天就要全部切換，也會因為沒人接得住而反彈。這一步和數位轉型迷思裡「舊流程不用改」那一條互為表裡，值得一起想。

讓每個里程碑都被看見

上線不是終點，讓後續的每個里程碑被看見，動能才不會在上線那天用完。首月採用率、第一張全線上核完的單據、累積到某個數量的紀錄，這些節點都值得公開標記一下，哪怕只是群組裡一句「這個月全部門都上來了」。

該做的事：用儀錶板把採用率攤開來給大家看。看得到曲線往上走，人就會覺得自己是一件正在成的事的一部分，這也對應 BCG 研究裡「對明確成果的有效監測」那項要素。追蹤的指標要挑真的，例如實際完成的單據數，而不是登入次數這種好看卻不代表有用的數字。

常見地雷：只在上線日慶祝，把上線當終點線，慶祝完專案小組就解散，三個月後使用率默默下滑。另一個地雷是慶祝虛榮指標：登入數漂亮，不代表工作真的搬上來了。從不展示採用曲線也是問題，大家感覺不到進展，就容易回頭用舊方法。

八週導入時程範本

一個部門級場景的導入，依我們協助台灣企業導入的經驗，大約可以排成八週的節奏。以下是範本，不是保證：組織規模越大、流程越複雜，每個階段都會往後拉。

這份節奏的重點不在天數，而在順序：痛點共識一定在選工具之前、內宣一定在試點之後、落日一定在培訓跟上之後。順序錯了，八週壓成四週也一樣會被罵。

同一件事，對高層和基層要有不同說法

同一個導入計畫，對高層和對基層要用兩套語言講，因為他們在意的事根本不同。高層要聽的是投資回報、風險控管、管理可視性和合規；基層要聽的是「會不會更麻煩、要多學什麼、對我有什麼好處、舊的東西還在不在」。BCG 2020 年把「從 CEO 到中階主管的領導投入」列為關鍵，中階主管的角色正是這套翻譯：把高層的策略，翻成基層聽得懂的日常。

同一套話術兩邊通用，是很多導入被罵的隱形原因：跟第一線大談 ROI，他們只覺得事不關己；跟老闆只講「員工比較方便」，他也批不了預算。

退場機制要先想好

導入之前就要想清楚退場機制：如果這條路走不通，我們怎麼收、資料怎麼帶走。先想好退路，聽起來像在觸霉頭，實際上它同時降低了兩種風險，一種是硬撐的風險，一種是不敢開始的風險。

該做的事：開始前先講好一條退場規則，例如「如果到某個時點採用率還不到一定水準、而且卡點是某個明確原因，我們就暫停調整」。同時確認資料能匯出、不會被鎖死在單一工具裡。把這件事講給團隊聽也有用：「先試，不行我們有退路」這句話，會讓願意嘗試的人多很多。

常見地雷：完全不留退場機制。一旦沉沒成本堆高，就算工具明顯不合用，也會有人為了「都已經花這麼多了」硬推下去。反過來，因為怕沒有退路而根本不敢採用，是同一個問題的另一面。還有一個地雷是太早燒掉舊資料的橋：新方法還沒證明可行，就先把舊系統資料刪掉或停用，萬一要回頭就回不去了。依我們導入輔導的經驗，管理層不帶頭的案子，多半在三個月內就退回原狀，這其實就是一種沒有規劃、卻真實發生的退場。

變革溝通 checklist：七個步驟自我盤點

把七個步驟收成一張表，導入前逐項自問，答不出來的就是還沒補好的破口。BCG 研究提醒過一件事：關鍵要素只做到三、四項的公司，最後多半還是失敗，要素得整套備齊。這張 checklist 的用法也一樣，缺一角就容易前功盡棄。

這張表可以直接帶進下一次的導入啟動會議，每一題答不出來就是風險所在。導入前當規劃檢核、上線後每季重跑一輪，答案會隨組織成長而改變。想針對貴公司的現況逐題盤一遍、或想知道第一步該挑哪個場景切入，找我們聊聊，把你們最痛的流程帶來就好；身為 Lark 台灣授權代理商，艾瑞特資訊科技手上有上百家企業的真實導入經驗可以對照。

常見問題

Q1：導入新工具，員工一定會抗拒嗎？

員工抗拒的通常不是「新」，而是「更麻煩」和「沒被問過」。多數抗拒來自要多學一套、要多登入一個系統、舊流程還得照跑，以及決策過程完全沒有第一線的聲音。對策是讓新工具比舊做法省力、先靠種子使用者建立口碑、並在導入前就把痛點問過一輪，讓員工覺得這是來解決問題的，而不是又一個由上而下的命令。

Q2：組織變革管理和專案管理有什麼不同？

組織變革管理和專案管理的差別，在於前者管人的行為改變、後者管事情的交付。專案管理把系統準時上線、把功能設定完成；組織變革管理則要讓人真的改用新方式做事，靠的是溝通節奏、種子使用者和領導帶頭。BCG 2020 年的研究把「從 CEO 到中階主管的領導投入」列為轉型成功的關鍵要素之一，講的就是這一塊：光把系統做好，補不上人願不願意改變的缺口。

Q3：種子使用者該挑誰？要找電腦最強的人嗎？

種子使用者該挑的是被同事信任的意見領袖，不必是電腦操作最強的人。技術最強的人一旦被貼上「他們本來就會」的標籤，反而說服不了其他人；真正帶得動風向的，是那些跨部門、有人望、又願意嘗試的同事。理想的種子名單會散布在不同部門和層級，人數不必多，一個部門級導入大約五到八位就足夠。

Q4：導入到一半才發現不合用，怎麼辦？

導入到一半發現工具不合用，正是「退場機制要先想好」的用意所在。因為一開始就把範圍圈小、也講好了退場規則，這時候的損失是可控的：先照當初定的規則暫停或調整，確認資料能匯出、不被鎖死，再重新評估是要換工具還是換做法。小範圍試點最大的價值，就是把「發現不合用」的成本壓在最低。

Q5：為什麼一定要設過渡期和舊流程落日？

過渡期和落日日期要成套設計，因為少了任何一半都會失敗。沒有過渡期就硬切，員工接不住會恐慌出錯；有過渡期卻沒有落日日期，新舊會無限期並行，大家賴在舊方法上、還做兩遍工，怨氣最後全算在新系統頭上。正確的節奏是新舊並行一段固定時間，同時把落日日期先公告出去，讓大家知道舊流程哪一天正式退場。

瀏覽知識中心教學