close

流程合理性

資訊服務是一種企業資源,它需要投入成本、人力、時間、,可以想見的是如果是與企業營運無關聯的需求,一般都不太可能被資訊部門接受。所以資訊部門接到服務需求時,首要工作即是要確認該需求與營運之關聯性。

 

接下來,就是資訊部門的人員展現專業的時候,需求者提出之服務需求最低限度是必須符合企業營運對合法性之要求,也就是資訊部門的人員必須要有能力對該服務需求是否符合公司利益以及合乎法令規範有一定的認識,如果有違這兩項要求,就必須作出暫停執行之決定,並找適當的人員確認需求的合理性。例如:採購單位提出修改公司表單簽核流程變更,將原先超過NT 1,000,000之採購案由原先總經理核可變更為部門主管核可,此為違反原先營運規範的需求,此時,資訊部門承辦人員應有警覺心,要求需求者必須提出該項變更已獲得權責主管核可之證據,或是該項變更需求需經相關權責主管同意後才可以執行。有讀者會質疑,既然有授權流程,何必還要注意這麼多,這就牽涉到有些企業的使用者,對服務需求往往是以一通電話或電子郵件就算提出求,而較無經驗或無制度的資訊部門員工有時為了維繫與使用者之間的良好關係,即會私底下滿足使用者的服務需求,這就略過了後面章節所提及之服務變更授權機制之監督。所以,無論服務需求是由何種方式被提出,承辦之資訊人員都應有足夠能力去辨識該需求是否合理、合法。

 

另一個值得注意的是,某些需求雖是對企業有利,卻是有違法令規範,例如某些高階主管有時會要求非法存取某些特定人士之資料,也許他們認為這些特定人士可能作出有害組織之行為,但私自檢視員工的資料,不但有違憲法對隱私權之保護,也可能觸及個人資料保護法的底線。為避免此類的爭議需求,資訊部門可先擬定一取得決策者同意以及不違法的的授權流程,要求所有人員必須遵守此規定後才能提供此類具爭議性之資訊。

 

 

預估投入資源

在確認服務需求是合理後,下一步驟就是得找出需投入多少的企業資源,這包括現有的組織人力(資訊部門的執行人力以及其他單位協助討論、驗證之人力)、時間、需要向外尋求資源之成本、等。在這個階段完成後,必須讓需求者以及相關主管確認是否要進行該項需求之投資,畢竟有些服務需求的投資效益過低,可能只是滿足個人的喜好或利益,此時即便資訊部門願意提供此類服務,也建議將此類需求的執行優先權降低,轉而優先滿足對營運有實質效益之服務需求。

 

下表為一個分析的範例:

人力

專案經理 x 1

系統分析設計師 x 1

Programmer x 5

測試人員 x 2

時間

100個工作天

硬體

應用系統伺服器 x 2

資料庫空間:每天100MB成長量

軟體

XXX軟體 x 3

後續維護所需資源

Programmer x 1

儲存空間 3GB/

 

xxx 資訊服務建置預估投入資源表

 

前面提過,資訊部門常為每年必須編列之維護預算傷腦筋,上表的『後續維護所需資源』即是強有力的證據。

 

 

建置成本評估

據筆者經驗,大部分的企業在評估建置成本時,皆聚焦在『採購』這一件事上,實務上,即便是沒有採購行為,仍是有人員參與等等的成本,只是因為沒有以此服務為名之實質支出,所以建議有志成為更專業資訊人員的讀者,可以參考專案管理方面的書籍,皆會詳述該如何為專案配置必要之資源以及計算所需之成本。

 

 

建置方式評估

第四章已提到企業如何取得所需之服務。企業應就前面幾項因素以及使用者要求之時程進行綜合評估,以決定哪一種服務取得方式最能為企業帶來綜效。

 

為時較長之需求,建議應以一個專案進行完整的進度管控,除了可以讓進度透明化,所有的資源運用都可以清楚展現給需求者了解,即便有任何執行上之困難,也可透過專案定期的進度報告在專案會議上獲得解決。

 

 

預估執行時程

完成服務需求所需時間是受資訊部門有多少資源的限制,常發生的情況是人力不足導致完成需求所需之時間超出使用者的期待。

 

嚴格說來,每個資訊服務需求單位都會認為自己的需求最為重要,應該優先執行,尤其影響財報產出、出貨、生產等的需求一般都會被列為最高優先等級。但讀者有碰到一種情況嗎:你手邊滿是上述這些被列為最高等級的需求,但忽然間你的老闆或是總經理要求你產出一份用過一次就丟的報表,你該優先滿足誰的需求?很難抉擇吧!你問我有沒有答案?沒有(前提是人力並不足以同時滿足這些需求)!因為這必須看讀者所待的組織文化是哪一類型,如果組織是有紀律的,也許你可以把需求區分為重要但不緊急‚緊急但不重要ƒ重要且緊急„不重要也不緊急四類,優先執行重要且緊急以及緊急但不重要的那些;但如果組織文化並未如此有制度,讀者可以先與自己主管商量以確定需求緊急度,至於總經理的需求,筆者認為無論如何都應該是優先被滿足的一群,不單是因為總經理操持讀者的生殺大權,還因為總經理的需求一般而言是影響公司重大營運的,所以這類不循體制運作的需求可歸前兩類。

 

雖然不同企業有不同作法,但有一種建議作法,也許可以在預估服務製作流程所需時間時,提供明確的支撐點:將整個資訊部的每一個人員都設計一個『資源日曆』,以及每個人可以提供最大之服務量;每確認一個需要執行的需求,且與需求者達成完工日期的確認時,即將所佔用的日期標示到該日曆上,日後在與使用者安排新服務需求之執行時間時,可以拿出這份資料以取得使用者之諒解,但如果使用者仍不接受,此時,危機反倒是轉機,透過使用者的力量,也許反而可以讓資訊部門爭取更多的資源,例如。暫緩其他資訊人員手邊不緊急的需求、委外代為執行,甚至可能可以換得擴編資訊部門規模之機會。

 

 

可行性結論

完成上述這些項目的評估,使用者提出之資訊服務需求是否可行就呼之欲出,但有一點很重要:不論是否可行,結論都應該是需求供需雙方已達成之共識,資訊部門的人員必須儘量避免以自我為中心,認為既然人力不足無法完成,又何必與使用者有什麼樣的共識,需知道資訊部門提供服務並非只開門營業一天,日後都還是會持續與各單位使用者接觸,能多為需求者想一步,就是為自己留下更寬廣的後路。最後,不要忘記讓雙方都在可行性結論上簽名畫押,以保障雙方的權益。

arrow
arrow
    文章標籤
    企業IT經營實務
    全站熱搜

    個人資料保護顧問 發表在 痞客邦 留言(0) 人氣()