IT論述常談到所謂「桌面生命周期」（desktop lifecycle），接著以各種方式定義這種周期。但很少人提到，在我們朝落實這種模型邁進之時，可能落入一種很常見、卻又不易察覺的陷阱：倚賴專案（project）而非過程（process）。所幸我們能運用一些簡單的技巧，來避免掉入陷阱。這麼做讓我們收到生命周期管理的成果，同時亦可避免一些令人洩氣的枝節問題。
評估問題：專案 vs.過程
有個故事很有名，大多數IT人員都講過，只是版本大同小異，那就是：「一間五人辦公室的移植工程（migration），比架設企業骨幹網路還費事」。這類故事背後的成因（如領域性、自我控制的需要、政治運作等），若講給氣味相投的聽眾聽，必定引起哄堂大笑。然而，如同其他雋永的寓言，這些故事也蘊含意義深長的真理：準備工夫其實差不多。所遭遇的問題，也多多少少與更大型專案面臨的問題一樣。何以致此?要回答這個問題，我們必須先釐清專案與過程的差別。
專案是一項具體任務，依循一套既定目標產生獨一無二的成品。過程則是一套相關的程序，具有明確的衡量機制，可一再產生同樣的結果。真正的差別在於預期結果不同：專案會有獨一無二的產物，而過程則用來管理穩定的工作流程（workflow）。
依照上述定義，部署新作業系統需要的是專案，安裝桌面硬體則不會產生獨一無二的產物。新硬體和舊硬體在功能上未必有所不同，只不過比較新、技術問題比較少罷了。事實上，就多年來我服務過的公司而言，硬體更新次數大多遠比實際需要來得頻繁，只是為了升級作業系統的緣故。
我們從這一番語義解析練習得到什麼？桌面汰舊換新是專案或過程，有必要分得那麼清楚嗎?
如果桌面替換是一項專案，就需要搭配種種輔助專案的活動，像是規劃、成立特別小組、發展處理獨特挑戰的新方法等等。換句話說，每當我們全面更換桌面硬體，就有一大堆事等著我們去做，對其他工作形成大量干擾。
但另一方面，若桌面替換是已知的、規劃好的過程，所需的工作即可分散到更長的一段時期逐步執行。溝通、後勤支援、乃至於下一輪替換的預先規劃，都會變成IT組織日常活動的一部分。這麼一來，IT團隊便能把注意力集中於具體的專案，例如規劃下一次的災變營運延續（business continuance）測試。
決定點
一旦決定把一次性的專案轉變成持續性的過程，我們就能決定下列要素：
- 替換周期（replacement cycle）
- 循序漸進的替換步驟（replacement phase-in）
- 後勤與存放（logistics and storage）
- 專案附屬事項（project attachments）
- 管理衡量機制（management metrics）
對一些公司來說，替換周期是最棘手的問題。在採購桌面硬體上，我的許多客戶沒什麼控制權。他們的用戶端（clients），也就是實際的商業用戶，只買他們覺得有需要的設備。別的時候，由於欠缺資產和合約的管理程序，害我們陷入進退兩難的困境。
假設我們能夠在替換周期方面發揮一些影響力，成功的計畫通常不外乎下列三大類型：
- 三年替換周期：除非被安裝新版作業系統或企業資源規劃（ERP）軟體的速度超越，否則大多數桌面硬體用個三、五年不成問題。這樣的替換周期可把對職場造成的干擾降到最低，但也免不了遭遇大量「資產遷移」的問題。設備和人員遷移時，資產管理紀錄未必都能隨著更新妥當，這會導致替換周期接近尾聲時，必須頻頻尋覓資產的去向。
- 三比二替換周期：這一類計畫是，IT小組每三年全面替換桌上型電腦，每兩年替換筆記型電腦。採取這種周期，勢必造成桌上型和筆記型電腦替換周期不協調，但可顧及行動使用者的配備耗損速度較快的問題。一如前述比較單純的三年一換周期，這類周期在接近尾聲之時，也需要投入大量的資產管理人力。
- 一年期替換周期：這種所費不貲的周期通常只有新創公司和小公司採用。他們和供應商簽一年的租約，刻意規劃在12個月之內更換設備。這麼做可降低替換過程末了必須大費周章清點資產的管理工夫，只是花費不輕，而且會給工作環境帶來變動不穩的感覺。
選擇周期的依據，應視IT組織本身管理資產的能力、對預算穩定的需求度，以及從送修單歸納出硬體趨勢的分析能力而定。
後者尤其重要。一般而言，硬體安裝後狀況會相對維持穩定，直到使用到某個故障點為止。通常這個轉折點介於三到五年之間。到那時，硬體送修單會開始增加，帶給支援人員額外的苦差事。IT組織若能憑過往經驗正確拿捏轉折點，即可預先把桌面替換時間點訂在料定下一波硬體故障潮湧現之前。
Shannon T. Kalvar撰．唐慧文譯 2004/07/26
轉載自: 升級是過程，不是專案
