前幾天上「資訊系統管理」這門課時，老師提到個觀念，挺有意思的

前幾天上「資訊系統管理」這門課時，老師提到個觀念，挺有意思的，恰巧從過去土法煉鋼至今，還真沒有刻意去思考用如此組織與結構化的方式來看待企業的資訊系統發展。談老師的觀念之前，先說說過去怎麼土法煉鋼過來。

拿個實際案例來看或許會比較簡單。過去效力過公司屬於專案性質，主要從事網站、系統與行銷活動等各類專案，服務客戶有大有小，但多數為中小企業。公司人數規模約莫40人以內，屬一般編制，有行政、業務、行銷、企劃、PM、設計與技術人員。一個系統專案的配置約莫四人，有PM、企劃、設計與技術。一組人一個月內同時最多會承接三個專案，其大小不一。

最多，公司一個月內可能會有30個大大小小專案同時進行，各不同專案裡的人，又會各別跨到其他專案，因此公司內部溝通交流頻率極高，一個專案的起始會議可能最少就得要兩次，後面各項討論，還有進度回報等，各式各樣的工作堆疊起來，也讓專案管理再到專案執行成了門藝術。一個閃失或不留神，好比一封溝通信件對象寄錯人，都可能造成公司重大損失。

起先，公司對於建置內部管理系統沒有太多主動想法。

從2016年的現在去看過去營業模式，沒有管理系統似乎很不可思議。但，台灣真的有很多中小企業，可以為客戶開發專案或系統，就是沒有時間跟精力替自己做些好用的工具來操作。當時，Open Source還未普及，大家還是比較習慣「硬刻」系統，然後在伺服器端測試各種服務，因此造成許多彼此「檔案覆蓋」的問題。甚至，那個年代也沒有特別區分「前端」或「後端」工程師。一個工程師就可以搞定一個網站或系統。

專案多，工作量大，我們土法煉鋼的方式就是走「書面形式」的「工作單」與「專案單」。現在光是想起軟體專案公司靠著這類東西在運作，很不可思議。在早期我剛進公司時，連書面形式都沒有，大家習慣記錄在自己的Excel表裡面。每個人的大腦就像個超級記憶機一樣，似乎每項工作都能弄得清清楚楚。不過事實上，這全是幻覺，因為過程中每個專案都各自犯下不同大大小小的錯誤。

工作單還沒什麼，業務回來的需求混亂不清，更是常常造成PM與企劃崩潰。一般來說，業務能把案子攬下來，都會盡量迎合客戶需求。可現實存在障礙來自於多數業務不一定具有執行背景或經驗。所以，業務聽客戶講得很模糊，自己整理起來好抽象，到了執行單位要開始做RFP(需求提案)時，所有人都像進入了吸食大麻的瘋狂狀態。因為，大家在會議室裡猜測業務講的是什麼，業務明明講的是中文，可大家卻以為在聽法文，沒有交集搞得所有人都很焦慮，業務也成為執行單位最頭痛的對象。

透過文件溝通，我們依舊處於土法煉鋼階段，只不過比起原始人鑽木取火，多向前跨進一步。我為業務設計了張「需求建議分析表」，裡面提供約莫50項公司各大專案曾經執行過的項目，採用選擇題的方式，再以執行流程順序的方法，讓業務可以照著表列上的內容去詢問客戶。同時藉由「需求建議分析表」引導客戶，試圖讓業務可以按圖索驥，進而拿回一些「可能」有用的資料給執行單位。

到這，公司能運作有賺錢，現在看來根本是奇蹟。

後來，大家實在受不了案子越來越多，加班熬夜已經不是人們討論的重點，而是太多重複犯下的錯誤，造成人與人之間的不信任，令各單位之間劍拔弩張。後來老闆眼看情勢失控，即將毀滅之際，把所有人找來，連續開了五天會議，做各式各樣Workshop，將每個人的問題全部列出來，整理歸納，好好靜下心思考到底所有的問題出在哪邊。我們在辦公室裡不知道幾天沒回去，整間會議室裡被A4紙滿滿，上面羅列每位同事門在工作上遇到的問題與抱怨還有困難。

最後歸納出幾個主要問題：

1. 專案進度彼此互相不透明，不了解有多少資源能用
2. 談過資訊有人不承認，沒有紀錄記載詳細討論內容
3. 資訊共用環境太過混亂，沒有規矩造成檔案亂存放
4. 重複造輪的現象太嚴重，很多東西以前做過又重做
5. 新進人員上手時程太久，要搞懂運作流程常嚇跑人
6. 執行流程沒有制度化，每個人都有一套運作的方法
7. 各上傳檔案的版本控制沒弄好，有人亂改沒人承認
8. 承諾好的進度沒有被執行，藉口都是臨時插件太多
9. 客戶需求往來內容不夠透明，過多的人為說明想像
10. 專案時程延誤影響下個專案，卻沒有人提早拉警報

所以，我們一步一步的解決問題。

A. 導入專案管理系統
要求每個PM開啟專案時，至少要先將需求、時程、預估人力、期望配置先設定好，然後第一場會議時間訂出來，要求相關人在該會議中出席，聆聽該專案的執行輪廓。專案管理系統提供所有每個人不同權限，去查詢自己各別在哪些專案裡，現在專案裡的工作又各自進行到哪個程度，自己身上被掛上多少張Ticket。

B. 導入版本管理系統
大家至少停工一週，因為檔案彼此覆蓋的問題太嚴重，所以要求每個人不再用FTP的方式上傳檔案，而是透過版本管理系統給每個人不同權限，讓他們各自上傳自己的檔案，並且檢視自己現在更新的檔案是不是剛好別人也在做，如果有，兩個人就得坐下來好好談談怎麼合併，同時在這系統裡有每個人上傳的所有紀錄，有人要不承認或很刻意的亂搞，都可以看得一清二楚。

C. 導入內部溝通系統
現在有Slcak這種方便的協作溝通工具，但以前大家比較習慣自己開MSN群組，但問題就是有的人會用，有的人不愛用。而MSN上大家又比較屬於私人性質不想跟公司混用，因此，公司只好導入內部溝通系統。採取不同的專案，將不同的人群組起來，讓該群組裡的人所有溝通與討論全都匯聚在同個地方，也把討論當下的檔案上傳上去，至少給予每個人在討論時能夠回頭看看自己曾講過什麼的紀錄。

D. 導入內部資訊平台
公司裡有各種大大小小的雜事或鳥事，有時一些事情用信件發了公告，總會有人不看，但我們最常聽到的是「我沒有收到，可能漏信了。」於是，建立內部資訊平台，設計一個公司最新專案的Dsahboard，讓每個人每天一早開電腦，瀏覽器打開來在首頁，一眼就能得知最新公司消息，還有各項未讀資訊與前日、當日專案工作項目。以及，一些尚在醞釀中還不確定的專案，由業務來更新可能會近來的專案型態與規模。

E. 導入知識管理平台
新進人員，或是可重複利用的模組，甚至是曾經開發過的專案裡，有哪些模組能被共同使用，全部揭露於平台上。像是會員模組，幾乎每個專案都會用到，大家每次在做，有些工可以不用重新開始，但因為要人們回頭去讀文件又嫌麻煩，所以將一些準則跟重點放在平台上，讓同事們知道自己可以用到多少，或是用不到多少，減少不必要的重新思考與想像時間。新進人員則是有一本各系統操作指南，以及認識每個職務的工作任務及職責。

F. 導入資訊管理系統
為了不讓各執行單位共用同一個開發環境，公司買了幾台伺服器（當時還沒有什麼雲端概念），因應客戶專案屬性的不同，例如使用語法、資料庫、作業系統等差異，建立大小規模不一的環境。環境又細分下去切割成自用測試環境、整合測試環境、上線測試環境（完全模擬符合客戶端狀態）、再到正式上線環境。雖然環境切開來會造成不少工作冒出來，但直接把客戶線上系統弄垮掉的機率瞬間降成零，也算一樁好事。

G. 導入內部簽核系統
不管是工作單、專案單、業務需求建議單、報價單、請假單、採購單、請款單、開發票單等，各式各樣單據全部線上作業，讓同事們可以直接依照個人需求，透過瀏覽器將各式符合自身需求的表單找出來，而每個表單又有相應簽核順序的權限在背後，只要把資料填一填，送出申請後，就會透過Email或是內部資訊平台通知相關人等，將各類單據簽一簽，讓大家知道每一段的資訊走到哪裡，以及個別又是什麼程度。

H. 導入錯誤回報系統
每個專案都會有無數個問題或Bug，有的是設計端沒做好，有的是企劃端沒想清楚，有各式各樣的問題短時間內無法解決，但當沒有人提出來，很容就會忘記。可是如果又只在內部交流溝通的紀錄裡，又無法好好回頭追蹤每一個問題是不是有被處理掉。有人曾想過在專案進度項目裡放置問題，可這又會造成管理專案的資料量肥大不容易控管，於是各種錯誤回報全放到一個平台去，由誰發現問題，指名由誰要來去檢視，一清二楚，也可以知道到底各專案還有多少問題待解、待修，或是我們這個月快速解決多少個問題等。

導入各項系統的過程，很痛苦。每個人，都強迫自己要改變工作習慣，包含業務、企畫或設計，尤其這三者都不是那種可以被結構化的工作者。因為，以前部門主管講個話，工作發落過來就自己展開後續工作。導入之後，每個人每天定期都得到系統上去看各式各樣狀態，起先同事們配合度超低，每個系統的使用率都不高，可是老闆一聲令下，不配合的人就別幹了。慢慢大概經過一季強痛期，再來是半年陣痛期，最後莫名的每個人不靠系統也不大會做事了。

到這，呼應「資訊系統管理」課程老師所提到的資訊策略、資訊管理、資訊科技這三個面相導入至企業中，又能為企業怎麼帶來價值。回頭看看那段過往，公司每個時期、每個階段會遇到的問題都不同，但如果能用組織性的方式去思考整體營運架構該怎麼做，或許我們土法煉鋼的過程，造成公司損耗的每一分效益可以降低一些，甚至能藉此為公司評估分析出哪些專案賺的利潤高，哪種配置會是公司最有效的競爭策略等。