分類彙整: 管理分享

網站速度恢復正常了…

時逢夏季,一則天氣炎熱,二則電費漲價,所以我就把網站移到小的機器上跑了

就讓IBM伺服器好好休息一下,等到冬天再重出江湖

剛轉移時,沒有仔細注意跑的速度如何? 這兩天才發現似乎奇慢

原因出在我中間曾更換IP,某個外掛的設定卻死守在原舊的IP上,才造成系統出現等待的狀態

今天重做外掛安裝,晚點再找備份把當初的檔案(該外掛為檔案管理使用)倒回去,不然有些文章的圖或影片,可能受影響

IT 需求管理

11/10/2015 9:09:55 PM

IT 管理工作, 最困難的是如何平衡人力與預算,以及如何判斷優先順序??

IT 平日負責維運工作,同時,會因應各單位突如其來的需求,有時,IT因為不在決策圈內,同時公司可能將IT視為後勤單位,所以經常會有狀況外的情況出現,比 如神秘的產品突然上市,市場行銷部門會急如星火的要求官網的上線支援,緊急調派所有線上的資源也要符合;這個時候,IT有再多的流程管理要求,可能都在一 句話下,被打槍,比如說,這是CEO要求的,IT就只能嘴巴閉上去做事了.

是的,即便如此,是不是IT就能以此為藉口而不進行量化的管理?

個 人後來的管理理念,都偏向導入服務管理的流程觀!! 建立維運所需的服務客服系統,這可以反映IT人力資源在各種技術支援所耗費的管理成本,接著再依公司戰略策略需求下,進行IT項目/專案的管理流程; 所有專案一旦准予成立,專案本身也有專案辦公室負責專案的流程管理,而所有工作包的人力準備及規劃,也應置入服務系統一併進行IT資源管理.

我有幸在前一東家實行了這一連串的過程,我會在管理分享的單元,分享個人的經驗及想法.

以 下分享一份個人之前導入的IT需求管理流程!! 當時,我甫就任的IT,即便立項,也可能碰到使用者突然說,不用了,結果IT耗費了大量人力,卻做了白工的情形,這樣的狀況還不是一兩件而已,所以推出需 求管理的流程,是試圖在IT及業務單位的高層,建立起一致的管理流程理念及想法,這樣才能在吃緊的IT管理中,由業務及IT單位一併做好決策管理,並使 IT的人力及預算用在最佳化的狀態

IT需求登記及审查說明簡报

IT報告探討

之前初到前一東家時,IT內部各團隊報告格式都流於流水帳的形式

但都很認真,一張EXCEL表,羅列了所有IT正在進行的項目或維護 事項,可謂天書表矣,在報告時,聽者暈頭轉向,為何? 因為跳來跳去,一下看第一項,突然又跳後面第十幾項,然後就看MOUSE滿天飛舞,這樣的情況,我大概經受了兩三個星期; 而且所有的報告,都無法呈現量化的數據,只有AP可以跟你說他多少人工天,但當時AP又卡在系統分析在一個組,開發在另一個組,分析與開發團隊的頭是死對 頭,在會議上你來我往,搞得大家摸不清誰對誰錯?

一開始,高層一直希望我告知到底誰對誰錯?不過,我個人內心是在想,問題其實就在高層,因為是我們允許他們這麼做的,基層的人,基本上都想把事做好,但規則沒有訂定好,尤其是報告的效率及格式都有問題,如何建置一個可以被追蹤的IT報告管理模式,也是我當初在思考的點!!

所以在導入IT服務流程及IT服務系統OTRS時,我也制作了一些IT報告應著重的重點,分享給IT的同仁們,尤其希望大家能把服務的流程觀建立起來,內部不能只有對立,而沒有對話!!而如何建立起可供對話而又允許建設性衝突的平台,這有賴高層的領導能力.

以下分享一份我當初制作的一份文檔, 密碼: urcloud1688

IT报告格式探讨.protected

IT PMO

11/12/2015 08:48:06

IT PMO, 全文為IT Project Management Office,即IT專案管理辦公室,IT PMO的角色定位為CIO的幕僚單位,為IT專案管理的管理單位,初期是一個虛擬組織,實際上,當我初到那公司提出此建議時,也只有我一個人在PMO. 話說,這也不是我自己無端提出,而是在就職前三天,我接到該公司執行董事的電話,他是IT的實際負責人,他要求我必須兼管IT項目(即IT專案).

當 我初就職時,首先我發現,IT單位就任務及專案的界線也不清楚,有些支援性工作,該單位也說是項目,項目基本上,被實際實体的行政組織單一劃分,這也造成 一種危險,只要有跨部門的溝通或配合事項,就牽涉許多組織內部文化的問題.最後呈現的結果,便是在會議中互相的較勁,我姑且不說是交互指責吧.

當下幾個比較嚴重的狀況,我發現到的是:

(1) 以支援的定位看待項目,許多時候,項目的優先順序取決於發起的時間

(2) 項目缺乏立項前的決策機制,通常是由該單位主管自行決定,又因為以支援的角度設想,因此一般也難以拒絕

(3) 項目立項後,許多跨部門溝通,卡住了項目往前順利進行的步伐

(4) 項目決束後,也缺乏績效追蹤的機制

(5) 項目的發起者,包括業務單位,缺乏戰略思維,有些是某一基層主管突然發起的,缺乏戰略思維,亦即該公司也缺乏年度策略規劃的展開

(6) 項目缺乏分級機制,所有項目不分大小,重要性都一樣,亦即IT資源運用陷入極度不足,而業務單位對IT也相當不滿

許 多人都說,IT的角色必須由被動的支援單位,改變而為能夠配合公司戰略規劃,主動配合的單位,因此,首先我也建議需進行IT 3-5年的策略規劃,以此配合公司業務需求的戰略,再發展各年度IT應進行的項目,這樣所有的項目決策才能清晰,更能align with business.

成立IT PMO後,我做了簡單的項目管理的教學,同時包括OPPM的教學,並開始在就任後第三個月導入立項程序,所有項目的決策機制拉到IT PMO,各單位必須將需求送至PMO審查後,通過立項程序,在立項前,所有工作包的討論,必須得到各單位主管及項目參與者的簽名,使大家知悉在何時需預備 投入什麼資源,而工作包間的WBS,也由PMO來界定是否合理?每一工作包以週為單位做為進度報告及規劃的依據.每周周報時,僅需報告當周進度的狀 況,OPPM上需顯示是已完成或進行中或未開始,個別以綠底實心代表如期完成,黃底實心代表有點落後完成,紅底虛心代表落後卻未開始,因此管理階層要投入 會議討論的當然是黃底及紅底未完成或未開始的部分,尤其是當周應完成卻落後的工作包.

也因此,後來周會也能更加順利的進行,IT PMO這裡,則開立所有項目的管控表,也因此未來會有每一個IT成員在項目投入的貢獻指標,雖則目前沒有系統,但即便透過EXCEL,也能快速的統計.

作為PM的人員,也不是任何人都可以擔任,至少需由主管提報,再由PMO確立可行,同時PM也可做為未來的儲備主管來培養,所以也建議高管,必須將這些列入績效考核的範圍,否則只給鞭子不給糖,那是不行的

結案後一個月,或視需要延後,PM需報告實際項目執行後,有無達成立項時在CHARTER上顯示的預期效益目標,此亦由PMO負責審閱.

在我離開前,PMO只再多增加一位行政助理而已,主要幫忙我統計資料,所有審查及溝通,全落在我個人身上,可見工作負荷之大,而這竟是當初工作中未談及的部分,所以我也算是善良的人吧

IT PMO 五月上線後,在七月份的統計,已有廿六項項目在手,可見該公司的欣欣向榮!!

唯 一值得欣慰的是,幾位IT經理或一些資深的工程師們,都向我反應,現在項目的進程順利多了,最後執行董事,在年底的高階主管策略會議上(這是該公司第一次 以年度策略規劃名義召開此會,一般皆是年度REVIEW會議),向全公司高管說,IT進步很大,抱怨也變少了.我想這個時候,我或許也該有一點成就感!

OPPM

2015-11-11 2:54:33 PM

OPPM 英文全名為One Page for Project Management, 中譯為一頁式專案管理,在大陸都叫項目管理.

我第一次接觸這個OPPM,倒不是在我工作最久的老東家,而是離開之後,在一家美商公司的CIO那裡聽到的,當時他想要導入這樣的管理模式,在與我面試時就一再詢問我的意見,不過我當時主要的管理系統是使用微軟的專案管理系統.

後來CIO還每人發了一本原文書,有關OPPM FOR IT PROJECT的,我在這本書上學習到了原來可以更簡單的管理IT專案.不過,比較可惜的是,缺乏系統,只能使用EXCEL.不過,後來我在中國,也確實導入了這個管理流程.

IT 專案的管理最需要的是一個綜覽的視野,到底在目前的時間點,有多少項目,又有多少工作包應該要被執行,每週的週會工作會報,到底應該把管理的重點放在那 裡? 而不是讓底下的經理,帶著你在他的流水帳式的EXCEL檔裡進行MOUSE迷航,同時,各分工單位的基層主管也應了解其底下的組織成員有多少工作包的承諾 需要進行.

所以OPPM是很適合這樣的一個需求而存在著!! 所謂的一頁,它長得就像這樣,如圖.

MWSnap020 2015-11-11, 14_53_45

OPPM TEMPLATE

在進入OPPM的介紹前,我想這只是一個工具,如何使組織能夠運用它,實際上還需要一些行政管理及組織流程上的配合及調整.有關這個部份,屆時再介紹IT PMO的角色的建立及執行流程的經驗.

就OPPM的基礎介紹,請參考以下文件, 密碼為urcloud16888

Introduction of OPPM.protected

IT服務

許多年前,在我任職最久的老東家,台湾最大的主機板廠,IT的服務是這樣的

使用者會拿到一張IT人員負責領域的清單,上面會告知,網 路問題找誰,ERP問題找誰,每一個IT系統皆有負責人,這樣子的優點是IT人員各盡其職,有時外交能力好的,沒有客訴的話,坦白說,大老闆也不知有沒有 什麼基礎問題的隱患需要放到未來的規劃裡,同時,使用者因為忌諱得罪人,怕未來得不到優先的服務,所以除非逼急了,否則也不會客訴; 我稱此為恐佈平衡, 基本上,這樣子的IT服務不是透明的,是在一個黑箱子裡的

我大約在2005年,就在我就讀EMBA時,接觸到ITIL,也就是後來ISO 20000標準, 如果站在企業最高決策者的高度看整個IT,我想勢必有許多問題想問的,比如說

  1. IT經常說人力不足,到底人力及需求的配置如何?決定服務優先順序的決策基礎是什麼?
  2. IT專案總是DELAY,如何決定專案的優先順序及輕重緩急?預算的執行與專案的成果如何確保??

在 IT內部REVIEW會議時,也經常會出現某種場景,A部門某A工程師說,判定此事為網路問題,已轉交B部門某B工程師,此時或許B工程師會否認轉交的時 間,或者他也判定此事與網路無關,此時老大只好兩邊訓戒一下,要求彼此要關照一下,但其實IT本身除了維護的事要做,專案又滿手,經常有掉棒的現象, CIO也就陷入不時在救火的角色,甚至有時電話打來就某副總要求,所以很顯然地,最後就比誰背景或後台最硬,因此,也許真正對公司重要的,但對方可能官不 夠大,長此以往,工程師也學會了看風向做事,因為如果太白目,極可能因為得罪了某位副總或大頭,自己辛苦一年的獎金就泡湯了…

大約在2007年,我開始在自己的組織內導入IT服務流程,此流程在後來的2009年也順利在整個IT上線,不過歷程是艱辛的,因為這牽涉到組織的變革管理,所有人都不喜歡變動,甚至我一位老長官還曾明講,這麼透明,好嗎??

去年我在另一製造業裡就職,初上任,就好像看見七年前的前老東家的影子,甚至其狀況更慘烈,因為連監看系統都沒有,我根本無從得知一個系統本身的可用度有多少?同時IT下的各單位,開會時也多半是吵成一團,互相指責的多,也很難追蹤到底誰對誰錯?

於是乎,我在最短的時間內導入了IT服務系統,以及IT系統的自動監看系統,因為缺乏預算,只好使用OPEN SOURCE,但對一個中小型的製造業來講,也足夠了,先有個量化有基準的平台,才能使所有事情的討論回到管理基本面

對於一位CIO來說,導入IT服務流程及量化管理的平台,有幾大好處

1.了解服務事件與人員配置比率是否合理

2.教育IT人員,自己只是整個IT服務的一環,比如說ERP異常,是整個IT的考核指標之一,如果一年不能當超過30分鐘, 那當案件轉發在某人身上時,它的處理時間及反應時間都在一定的規範內,且必須註明在系統內,再來計算個人績效

3. CIO將擁有屬於IT運作的大數據分析基礎,以此做為未來不管是管理或技術上策略的考量基礎,或者做為來年新的KPI的規劃基礎

4. 確切將維護及專案的人員的個別能力取得最大的發揮,過去IT未明確分開一二線的人員,經常有領有高薪也確有規劃專長的人,在忙一些沒有什麼技術性的工作, 所以對於專案進度也能有更多的掌控及在必要時做調整的決策基礎,因為所有的工作數據都能清楚,不過在專案的管理上,我後來是另外成立PMO來管控專案的立 項及後續控管等動作,此後續有機會再談.

有關一份組織變革的思考文件,分享如下,密碼為urcloud168,我去除了一些敏感性文字資 料,只提供方向性的思考在裡面,在進行變革前,最重要的是思想的溝通及再造,這部分我之前花了很多時間去說服大家,包括管理階層.也很慶幸後來得到大家的 支持!!許多經理人員,後來都對整個IT服務,表示進步及滿意.

IT未來策略与组织規画DRAFT.protected