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

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

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

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

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

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

你在找聖杯嗎？

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

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

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

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

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

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

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