貼合團隊實際工作方式的內部工具。

當試算表已到達極限

• 多人編輯,卻沒有人肯定哪個版本才是最新。
• 不同人需要不同視圖 — 而有人要靠手工維護。
• 重要規則只存在於某個人的腦海,而不在檔案內。
• 您需要知道誰在何時更改了什麼。
• 同事以副本繞道,令「真正」的資料散落各處。

試算表很適合探索問題。但一旦別人要依賴答案,資料周圍的結構便比資料本身更重要。

通常合理的工具類型

• 請求及工作追蹤 — 誰要求什麼、誰負責、處於什麼狀態。
• 批核流程 — 採購、請假或內容簽核,並留有清晰記錄。
• 庫存及設備登記 — 擁有什麼、在哪裡、由誰持有。
• 入職及檢查清單 — 不能遺漏步驟的重複流程。
• 營運儀表板 — 經理每朝需要的少數數字,取自真實資料。

令工具被真正使用的設計原則

• 為重複使用者而設。人們整天都在使用,因此速度、搜尋、篩選及合理預設值,比初次使用的吸引力更重要。
• 貼合現實的角色。提出者、執行者及管理者,需要同一份記錄的不同視圖。
• 預設保留歷史。每項更改都記錄由誰在何時作出,無需像偵探般追查便能回答疑問。
• 小步前進。先取代舊流程中最糟糕的部分,再逐步擴展。

如何在不影響運作下脫離試算表

1. 描述現行流程的真實運作情況,包括各種繞道做法。
2. 整理並匯入您想保留的資料。預計會發現重複及缺漏。
3. 在議定的短期內並行運作,避免任何事情依賴未經測試的系統。
4. 在明確日期切換並停用舊檔案,避免影子副本重新出現。

最常見的失敗並非技術問題:舊試算表繼續存在,只因為沒有人被要求停止使用。請議定由誰宣布切換。

情境說明:由散落的請求變成單一隊列

試想一間小型活動策劃公司。設備需求、場地更改及供應商訂單,分別經 WhatsApp、電郵及走廊閒談而來。一位協調員維護一份試算表;她不在時,沒有人知道還有什麼未完成。(這只是說明用的假設情境,並非客戶個案。)

首個內部工具只需做三件事:為每項請求建立附有負責人及狀態的記錄;讓提出者無需詢問便能看到自己的請求進度;並讓協調員看到一份列出所有逾期事項的清單。報表、系統整合及批核流程,待這份清單獲得信任後才處理。

這就是大多數成功的首個版本的樣子:一份清單、每項有一位負責人、只有一處需要查看。