大多數小型承包公司的排程系統，其實就是一個人的腦袋，外加群組聊天和工坊裡的白板當備份。
這套系統管用。這一點值得先承認：在大約兩個工班以內，它真的管用。老闆知道每個人在哪裡，有變動就傳訊息重新調度，整套系統靠的是彼此都清楚的那些背景資訊——寫下來要花一小時，用講的十秒就講完。
接著它就不管用了，而且是突然不管用。常見的導火線是第三個工班上線、老闆請假一週，或是某個運氣不好的星期二，一通取消電話引發連鎖反應。兩組人跑到同一個工地，另一個工地卻沒人去。三週前就約好的客戶，前一晚才接到電話說要改期。
到底是哪裡出了問題？
把失靈的地方講清楚很重要，因為表面的診斷（「我們需要一套排程軟體」）往往會讓人買到一個治不了病的東西。
班表存在不只一個地方。 白板寫的是一回事，群組聊天最後四十則訊息又是另一回事，而老闆腦袋裡的版本才是真正正確的。沒有人知道哪個才算數，所以每個人都得去問老闆，老闆也就成了每個問題的瓶頸。
變動傳不出去。 晚上九點在群組裡宣布改期，只有當下剛好在看手機的人會看到。正在開車的工班成員，要等到隔天早上七點開到錯的地址，才會知道。
沒有人看得到明天。 工班知道今天要做什麼，是因為早上有人告訴他們。沒辦法自己規劃，沒辦法對客戶說「我們星期四會回來」，也沒辦法在星期四之前就先發現星期四有問題。
對客戶的承諾是隱形的。 班表追蹤的是工班跑去哪裡，不是對客戶答應了什麼。所以一個月前電話裡說的那句「我們會在 14 號那週開始做你家廚房」，根本沒有記在任何地方，一直到 15 號客戶打電話來發火，才浮出檯面。
每份工作的開車成本計算機可以算出往返工地的通勤成本，無論是單件工程還是一整年的累積數字。
一份班表，人人都看得到
解法一點都不複雜。就是一份唯一的班表，是所有資訊的最終依據，每個工班成員都能在自己的手機上看到，而且一有變動，每個人立刻同步更新。
這真的就是全部的概念，而它的價值幾乎完全來自「唯一」和「每個人」這兩個詞。排程工具做得再漂亮，只有老闆自己在看，也只是把原本的問題換上更好看的畫面而已。
三個特質，比任何功能都重要：
必須能在車道上、用手機看，而且大概三秒鐘就看懂。 我在哪裡、我在做什麼、還有誰在那裡、地址是什麼。如果工班成員得自己摸索操作，他們就會改傳訊息問老闆，你又回到原點。
變動必須自動可見，不需要另外宣布。 工程一改期，班表就要跟著變。沒有人應該還要再發一則訊息，因為總有一天你會忘記發，結果就是有人開車開到錯的地方。
必須包含對客戶的承諾，而不只是工班的人員指派。 班表裡要記著：這件工程答應客戶 14 號那週開工。這樣當你把別的工作排進那一週時，才看得到自己排擠掉了什麼。
每日看板與未來一週
實際上，小工班需要兩張不同的表，而把兩者混為一談，是很常見的錯誤。
每日看板是工班的工作文件。今天、誰在哪裡、依什麼順序，附上地址和進場注意事項。它必須簡單到不需要解讀，早上六點四十五分掃一眼就懂。
未來一週則是老闆的規劃畫面，呈現的是產能：哪個工班還有空檔、什麼還沒排人、什麼有風險。這是你回答「這件工程接不接得下」的地方，也是讓你不再過度承諾的關鍵。
工班不應該需要看規劃畫面才找得到自己的一天，老闆也不應該得從七張每日看板裡拼湊出產能。Zeus 刻意把這兩者分開：一個每日看板給工班用，一個規劃表用來把工作分配到一整週，兩者都讀取同一份班表，所以不可能互相矛盾。
刻意留一點餘裕
小型承包業最常見的排程錯誤，不是缺乏組織，而是把產能排到 100% 滿載。
如果每個工班每天都排得滿滿的，那麼一次工期超支、一次請病假，或是一次查驗延遲，就沒有任何緩衝空間。骨牌就這樣倒下去，三個客戶的行程跟著往後推，而這三個客戶你都得一一打電話說明。一天不順，就變成兩週不順。
刻意留空檔，感覺上很浪費，實際上不是。每個工班每週留半天沒排工作，幾乎能吸收所有正常的變動。那週要是一切順利，這半天就拿來處理回修、收尾清單、報價，或是一直被拖著的維護工作——反正這些事本來也沒被排進去做。
還有一個相關的習慣：前置作業不在你掌控之中的工程，就不要太早敲定具體的開工日。「14 號那週」是你守得住的承諾。提前一個月就敲定「14 號星期二早上八點」，等於要四件事都順利才兌現得了，而這會把一次小小的延誤，變成一個真正跳票的承諾。
分包商也是班表的一部分
小工班排程中一個反覆出現的漏洞，是分包商活在系統之外。輕隔間師傅用簡訊約，電工師傅用電話約，兩邊都不會出現在那份用來規劃其他工作的班表上。
這會造成一個特定又昂貴的失誤：你的工班星期三就把粗配做完了，電工師傅卻約在下星期一，中間空了四天，沒有人注意到，一直到星期三下午才發現。
分包商不需要使用你的軟體。但他們確定的日期，必須出現在你的班表上，和你自己的工班並排顯示，否則你看不到真正決定工程何時完工的那一連串前後依賴關係。
該從哪裡開始？
如果你目前靠白板和群組聊天在撐，而且已經開始吃力，下面這個順序管用：
- 把每一項已確定的工程都放進同一個地方，包括那些模糊的客戶承諾。這一步會不太舒服，因為你會發現自己接得太多了。現在發現，總比之後發現好。
- 讓每個工班成員在手機上都有唯讀權限。 光是這一步，在任何流程改變之前，就能消除大部分「我在哪裡」的日常詢問。
- 不要再另外宣布變動。 直接改班表，讓大家自己看。這一步只有在完成第二步之後才有用，而這也是真正讓群組聊天退休、不再當作正式紀錄系統的關鍵。
- 把分包商的日期加進去。
- 每個工班每週留半天餘裕，並堅持守住它。
第一步和第二步就做完了大部分的工作，剩下的只是微調。
常見問題
我們只有兩個人，這樣做會不會小題大作？
兩個人的話，腦袋加傳訊息這套做法確實很有效率，太早正式化反而只會增加負擔，卻沒有好處。判斷該不該改變的訊號，不是人數多寡，而是你開始得回頭拼湊「當初到底答應了什麼」，或是有人跑錯地方不只一次。
應該提前多久排班？
大約一到兩週內的排程要確定；再往後一到兩個月，則以確定的「週」為單位，而不是確定的「日」。提前三個月就排定具體日期，只會產生假的精確感，而你會花掉這中間所有的時間去重新調整。
中斷後又重新開始的工程該怎麼處理？
工程每施作一次，就要在班表上出現一次，而不是當成一個區塊只寫一次。一間廚房如果分五個不連續的日子施作，就該有五筆紀錄。當成一個連續區塊來處理，會把中間的空檔蓋掉，而產能真正流失的地方，就在那些空檔裡。
該讓客戶看到班表嗎？
通常不該：內部班表有其他客戶的資訊，而且一直在變，公開等於是請客戶來跟你討價還價，爭工班要先派給誰。告訴客戶已經確定的時間窗，有變動時再通知一聲就好。
ZEUS