「把新文章發出去。」
自動發文系統開始上班。先看原稿清單，再看審查結果、翻譯進度、待發布項目。整理紀錄、存檔，接著檢查每張表是不是一致。
大約23分鐘過去了，真正處理文章的階段卻還沒開始。
這是一次匿名執行紀錄的結果：準備整體狀態花了約8分鐘，儲存結果又花了約15分鐘，最後程式被強制終止。這不是所有系統的平均時間。
就像全體員工打卡、開早會、核對出勤表，然後連一件產品都沒做就下班。最好笑的是，這間工廠根本不用人上班。
進度表還需要自己的進度表
記錄進度當然有用。知道哪篇文章完成了、哪篇通過必要檢查、哪篇還沒上線，就能避免重複處理。
但是表越生越多：原稿清單、審查清單、翻譯待辦、發文待辦，還有各組工作紀錄。兩張表的數字不同，又得派人來對帳。
「文章呢？」 「正在更新進度表。」 「好了嗎？」 「正在核對進度表的更新紀錄。」
會計部門成功研發機器人，機器人的志願也是當會計。
為了保護表格，乾脆先停止發文
有些系統把進度紀錄的變動，也當成整批發布資料改變。只改一筆資料，就可能重新產生頁面。產生到一半，其他表又更新，只好再做一次。
為了避免無限重做，甚至可能規定：發文期間，其他工作先不要寫入紀錄。
幫忙發文的表格，反過來讓文章發不出去。
就像超商收銀台為了重新數排隊人數，決定先暫停結帳。客人只想買個飯糰啊。
真正分工，不是每人輪流改總表
寫稿的人存好原稿；發布的人檢查那篇原稿並讓讀者看見；監測的人確認網頁真的能開。工作做到這裡，各自交棒就好。
如果大家都要先修改同一份超大的總表，總表一停，其他人全卡住。員工再多，唯一的蓋章窗口也不會變快。
那把台帳全刪了？
重複的進度表可以拿掉，但最基本的紀錄不能隨便丟。
系統還是得知道哪篇文章的哪個版本已經上線，以及中途失敗後從哪裡繼續。否則可能重複刊登，或讓舊稿蓋過新稿。
如果已上線的網頁和既有資料就能證明這些事，何必再抄進五張表？
有新稿就檢查那篇；沒變的結果不用重算；統計慢一點沒關係，別讓合格文章陪著等。
真正該看的成績是讀者今天多看得到幾篇文章，不是更新了多少次進度表。
「今日成果：台帳一致性100分。新文章0篇。」
這不是發文工廠，是超豪華文書中心。
