最新文章

流程系列五之 專案流程的重點在管理而非方法

之前寫到專案性質的工作應該分三種流程來看待 1. 專案管理的流程 (要怎麼管) 2. 管理支援之流程 (特殊事件怎麼處理) 3. 產品導向之流程 (要怎麼做) 前兩者是可以標準化,也是提升組織管理成熟度一開始該做的部分。 但產品導向之流程,也就是案子的實際施作方法,則會因為每次案子的需求與差異,可能有極大的變動。 若想一下子標準化常是不切實際的,所以並不需要勉強在這部分打轉想做成SOP。 但雖然不需要勉強把施作方法建立成SOP,可不表示施作過程不需要被描繪。 反而就是因為專案變化多端的特性,反而應當在「每次專案開始前」做一次完整的構想,並把我們接下

流程系列四之 如何撰寫真正有用的SOP

上周提到,在製作標準化的流程時(也就是SOP),我個人建議把握下列幾個原則: 1. 架構應由粗到細,由上而下 2. 清楚易讀 3. 每一步驟的介面切割清楚,定義明白 4. 日後好管理 5. 防呆設計 而上周談了第一項,也就是SOP制定及思考時,我們應從抽象的架構開始,然後逐漸往下展細。 這意思是說,不需要勉強把所有的細節、判定、負責人員、甚至說明都要在一張圖上表達。 畢竟都放在一張圖上雖然很完整,但是相對東西多時將很嚇人,對於溝通或是概念傳遞這目的而言,反而未必有幫助。 很可能會讓第一次接觸的人在面對眼花撩亂的資訊時整個傻眼,更別說還能理解到底實際該

流程系列三之 撰寫SOP的原則

前兩周提到,我們談到流程規劃時可以大略的分成「一般性的產業」,或是「專案導向的產業」來做思考。 因為在面對這兩類產業中,我們對於流程的定義很可能會有些不同。 在前者,我們應定義「產品導向的流程」(怎麼做)以及「管理支援流程」(碰到特殊事件該怎麼辦);而對於後者,我們則增加了「專案管理的流程」(專案進行中我們怎麼管,以及可能會動用到哪些流程)。 那在接下來的兩周,我們或許先來談談一般性流程的製作原則;這議題談完後,則再來談談專案性質產業流程的製作與管理。 一般性的商業活動,大多重複性高。 也因為重複性高,才有制定成標準作業程序(SOP, standar

你在找聖杯嗎?

隨著組織的擴張,通常組織中既有專案會加速增加其複雜度。 不單同時執行的案件增多、每一案件的範疇可能增加、客戶在技術或品質的要求會越來越嚴苛,但很遺憾的是案子執行的時間與成本卻未必會對應上升。 而有趣的事情是,組織對於專案管理上的成熟度,幾乎都不會跟隨著複雜度的增加而自動同步提升。 甚至很多時候,組織會被複雜專案牽扯而變得越來越混亂。 這是因為大部分的組織,當面對複雜的專案環境時,並沒有從基礎來檢視如何改進專案的做法,多是以疊床架屋(如,當狀況複雜時,就多加個一兩個職位,或特別成立一個部門或小組;但這些職位與小組常沒有從全面來做思考,它們跟原本的架構

流程系列二之 讓團隊自由的基礎

兩周前,我們談到了流程的標準化對於商業行為的長期運作的重要性。 甚至只是間小吃店也是一樣,因為若缺乏這東西的話,混亂、錯誤、衝突、與失敗就很可能出現在日常工作中。 但若回到以專案為主體的工作環境,相同的概念卻好像並不那麼容易可以帶入?  

三個打破穀倉、突破專案困境的方法

幾十年來台灣的經濟支柱多以製造業為主,大部分公司常是以功能性的部門(Functional Departments)做為其基本的組織架構。 比方說公司內可能會有業務部、設計部、工程部、生產部、會計部、或行銷部這樣的單位。 專長類似的人被聚集在相同的部門中,部門中每天則大多做著重覆度很高的工作。 比方說生產部每天忙著加工產品、業務部的人則每天跟客戶聯絡、拿著型錄拉攏生意、試圖談妥訂單等。 但是,隨著商業活動複雜度越來越高,服務、研發、創意、或是需為客戶量身打造的東西越來越多下,工作變得難以獨立切割。 產出物的流程也不再只是部門內自己的事務,而是必須走出

流程系列一之 只是好吃還不夠

之前我上班的附近有間小吃店,店裡賣的是魯肉飯、炒麵、炒飯、豬肝湯那類菜色。 說起來其實並不多特別,但是因為那附近很少小吃店,他的一盤炒飯又大約僅是60元上下的價位,加上份量適中口味又還不差,也因此與當時的同事中午常去那邊吃。 那家店東西雖然不錯,我們也從來沒吃到不新鮮的餐點或異物,但這店卻有個問題。 因為中午生意很好客人非常多,幾乎每五次有兩次會有誰點的東西漏掉沒做、不然就是看著送菜的小姐一桌一桌問著:「鳳梨炒飯是你們點的嗎?」、再不然就是明明鳳梨炒飯吃完了,不知道為何卻又做了一份送來。 幾次下來我就好奇,到底這家店發生了甚麼事? 人多雖然是助長混亂的