經多年執行資訊系統開發建置與維護等專案的經驗顯示，推動資訊系統相關專案時最耗費精力的時間不在於系統建置階段，真正的挑戰是在系統建置完成後上線運作才正式開始。當系統正式運作後也表示該系統同時間進入維護階段，因此使用者對於系統中斷時間的忍受程度依據不同使用需求均有所不同，然而目前資訊系統的使用管理單位對於系統委外維護合約中系統服務水準之標準如何訂定，尚未依循一定之作法。常見的狀況是透過使用者的個人感覺與經驗制定，更多的情形是直接參考其他專案合約的規定辦理，不論何種方式，這些不精準且不科學的方法，對於後續專案執行過程中將有可能產生爭議發生的風險，因此如何避免因為不明確的系統維護服務水準造成資訊系統停擺後延伸更大的困擾，故針對”如何研擬合理的服務水準”，與後續”如何記錄確實的服務績效”為本文所要探討之主要課題。
資訊系統服務水準(SLA)的主題，目前在產官學界均多有相關作法與規定，包括行政院國發會(原行政院研考會)有制定政府資訊委外服務水準訂定說明與台灣科技化服務協會亦曾訂定服務水準管理參考指引等，甚至系統服務供應商如Google 公司亦針對Google Apps提出Google Apps服務水準協議，從這些相關案例來看，都是要讓使用者瞭解到資訊系統其實與我們日常使用的設備一樣，是有可能發生故障的。資訊系統並不是開機後永遠不會停止服務，各單位透過服務水準標準擬訂後明確定義出，當系統停止服務後在多久時間內重新提供正常服務是可以被接受的，當然這些的服務水準的標準擬定也需取決於使用者對於系統的使用需求程度與所投資之相關軟硬體設備之搭配情形而定，而非依據個人經驗或是參考其他案件方式辦理了。
針對研擬相關合理服務水準的做法，目前均有許多文件與資料可以參考使用(在網路搜尋引擎下達服務水準或SLA之關鍵字等)，甚至也有許多教育訓練課程提供學習參考，以下內容僅就筆者個人多年執行多項資訊系統專案相關經驗彙整後，提供一項可透過簡單程序就可建立合理化服務水準與後續執行評估的方案供讀者參考：
1.確認使用者對於系統停止或發生錯誤後之可忍受時間：可利用問卷調查方式收集”重度”使用者在”必須使用”系統時的平均可忍受停機或錯誤修復時間(需同時了解到系統無法使用時的忍受程度)，作為參考依據，接下來評估系統可停擺時間是否符合維護單位的維修所需時間，若系統一刻不得停止，建議系統必須投資建立備援方案，當系統停擺後立即由備援系統接手服務，反之則利用使用者合理的忍受時間做為服務水準要求。
2.建立問題反映處理流程：將使用者於系統停止服務或發生錯誤後，如何回報問題並針對問題處理需經過哪些審核程序，交付至維護單位處理以及處理單位之回覆方式，透過會議方式由管理單位、維護單位與使用單位共同協調將處理程序標準化，並定案發佈週知，除可讓使用者瞭解到系統維護程序也可以供管理單位掌握後續處理情形。
3.建立資訊化管理系統協助管理：針對前述標準流程明定後，建議可以透過資訊化方式協助問題管理，針對問題處理流程較為單純，建議可以委由資訊管理廠商或部門使用市面上既有免費系統(如Mantis、BugZilla、trac、RT(Request Tracker等)安裝後導入問題管理使用，反之若涉及複雜程序則可尋求更專業之管理系統或是自行建置開發問題反映管理系統，相關功能至少包括通報管道、流程審查、工作分派、處理回報、進度查詢與統計分析等功能。
透過前述相關程序除了可以簡單的合理評估維護資訊系統所要求之服務水準外，亦對系統問題處理建立出標準處理程序，不論管理單位、使用單位與維護單位均有一致標準依循，當人員交接異動時亦不致發生認知差異，甚至當有爭議發生時，也可釐清處理權責，減少溝通協調時間。此外，配合問題管理系統導入支援，至少可以有效紀錄各項維護工作類型與處理時限，讓管理單位可以透過歷史紀錄之資料分析，瞭解到系統維護過程之重點問題，針對後續維護亦可掌握重點改善項目，其次，系統的維護預算應該如何合理編列，均可以透過數字來說話了。
希望透過以上簡單的工作經驗分享，提供資訊系統相關管理單位一個可操作的解決方案，能夠對於未來的系統維護委外規範定義上可以藉由較為科學化之方式進行研擬，以改善過往透過憑感覺或是憑經驗的評估模式。