商業分析真的沒那麼難，只要你在對的時間找到對的人(2/7)
人多嘴雜，但有時候人不多，反而你的心念就會開始越來越雜。
話說將近 20 年前，當我第一次為客戶做商業分析的時候，說實話，那時候哪懂得什麼叫做商業分析？其實就是開個會議室，找齊公司的主要幹部來講一講他們要什麼而已，把大家的想法彙整之後，再提取出各自部門的需求，最後統整成一份簡潔扼要的功能(?)需求書交給客戶，他點點頭，問了功能開發的價格，然後再問了財務部門的頭頭，隔沒幾天，一份簽了字、蓋了章的開發合約書就這樣寄來了。
於是，就這樣，在年輕不懂事的時期，居然也很狗屎運地度過了 5 個年頭。直到有一天，終於踢到了鐵板。
記得當時終於是網際網路已經開始逐漸風行，而各家企業也逐漸認知到官方網站的重要性，所以一些比較具有前瞻性想法的二代當家，開始逐步在公司內部建立起網路行銷部門，當然啦，那時候哪有什麼網路行銷，甚至是連風潮都還算不上，那樣的部門或稱作小組，就是找一個設計師搭配一個工程師來建立和維護網站而已，而有的時候設計師還是外包給廣告公司來畫畫圖而已。
當時，我從客戶那裡接到一件他供應商的網站規劃案，說想找工程師來幫他們設計網站，雖然當時我被其他案子和考試的事情搞得焦頭爛額，但為了維護客戶關係，還是硬著頭皮、撥出時間去聊聊看。
一到了對方的公司才發現，這是間金屬鋁片加工廠，而我們開會的地點是在工廠內的辦公室，說實話，這樣的環境對我來說還滿習慣的，畢竟台灣是以中小企業為主的環境，而當時一些中大型的企業其實已經有自己的小部門在處理網站的事情，根本不會來找小工作室來幫忙做。
接待我的是他們的業務主管，人笑咪咪的，年紀大概和我爸差不多，相對於工廠不時傳出的切割機雜聲，辦公室內部倒是安安靜靜的，因為人都出門去了，只剩獨立隔間裡的總經理和接待我的業務主管，總經理約莫30~40歲左右，桌上擺著全辦公室唯一一台電腦，也是二代接班，所以想大展身手，於是他想先從資訊系統開始著手。
在小辦公室隔間裡一陣寒喧、互相介紹之後，開始進入主題，這時候我才知道，他們想做一套管理產品進出的內部網站，概念類似於現在的 ERP。嗯，其實當時我有點嚇到，因為一直以來我都盡量找簡單、容易做的對外公司網站為主，頂多就是複製貼上一些簡易會員和留言板功能而已，反而比較少去做較為複雜、牽扯較深的內部系統網站。
不過，好吧，既來之則安之，反正都大老遠地跑了一趟，總不能空手而歸吧？就先聽聽他們想要做什麼。講到這時候，業務主管不知什麼時候，搬了一堆業務報表、倉儲資料表、財務報表等資料到辦公室裡來。這時候，其實我已經有點傻眼了。心裡開始哀嚎著：「要怎麼跟他們說明現在的情況？他們根本還不適合發展內部網站啊。」
講到這裡，是否有些看官了解我心裡的哀號是如何淒慘了嗎？我不在這裡賣關子，畢竟關子也值不了多少錢。因為，公司的企業文化仍然停留在紙本作業上，而全公司唯一一台電腦是總經理接收客戶的 e-mail 用途而已。他是因為去上了課，瞭解資訊系統對公司有多大的幫助，所以想一口氣建立起企業內部系統，而又因為公司屬於重資本的產業，所以想從強化成本管理下手，於是才要做一套綜合性的管理系統。
聽起來願景很好、很棒，但我已經看到前途渺茫、前景灰暗，這條天堂路萬萬走不得。原因講起來有太多故事，但以那個當下我在公司內看到的原因只有一個：「願意使用系統的人絕對不多。」
這怎麼說呢？因為他們公司內除了工廠的工班以外，其他幾乎都屬於對外的業務人員，倉庫也是由業務主管兼任，總經理的角色介於管理、財務、客戶關係維護和大型業務上。
也就是說，到時候這套系統在開發的初期，能夠詢問的使用者就幾乎只有總經理一個人，偶爾加上業務主管半個人。有些人會說，使用者這麼少不是很好嗎？事情就簡單啦。如果你會這樣想，那真的代表你沒做過規劃，讓我實在會忍不住想吐槽你…但我絕對不會這樣做，因為我相信正在看這篇文章的你，一定是有著豐富實戰經驗、經歷過槍林彈雨後生存下來的王者。
我想，講到這裡你應該知道我在想什麼了。當使用者這麼少的時候，在需求訪談、進行分析工作的同時，你能夠顧及的面向也跟著少得可憐，最後的結果就是在實作的過程中，不斷地因為其他因素而翻盤翻盤再翻盤。
所以，這文章一開頭講了個這麼長(?)的一篇故事，其實只是想告訴你，在訪談需求、進行商業分析規劃的時候，一定要盡量再多找一些對的人，不用太多，就找真正到最後會實際操作系統的人，這裡講的系統不一定是什麼資訊系統(像是網站、程式等等)，而是實際上會直接使用到整套解決方案的人，而且這樣的人要盡量涵蓋到初階、中階與高階人員。
在這個故事裡，如果要做這樣一套 ERP，那不只總經理和業務主管要參與，底下的業務、工班、倉管(目前業務主管兼任)、財務、公司客戶都要進來，並且除了使用者(客戶)端所有使用者的角色都必須參與之外，開發系統的團隊參與人員也會影響整個分析規劃的行程安排，這也就是談到了我們在 BA 分析中的第二階段所要做的事以及參與的人(Stakeholder)：
Part 2：規劃分析計畫(Planning Business Analysis)
在這個階段除了客戶端的使用者之外，開發團隊則要找到這些人來參與：
- 最高主管(執行長/總裁/部門主管)Master Manager： 毫無殘念地，Master Manager 在這個時候仍然要參與，但現在扮演的角色則逐漸退居幕後，成為這個專案的背後支持與關注力量，雖然說是往後退，但千萬不能退得太後面，畢竟 Master Manager 的關注仍然會是一股足以「鎮壓」大家共同往目標邁進的「動力」。 這個角色分為開發端與客戶端，兩端的最高主管都必須肩負起 Push 大家往前進的責任，唯有持續參與，事務的推動才會有往前的動力。
- 專案經理/Project Manager： 負責控管產品開發時程、進度及產品團隊內的各成員間的溝通與協調。 許多公司對於專案經理和產品經理兩個角色會將之混雜在一起，為求將這兩角色的職權明確地分開，可以將產品經理視為產品團隊的對外溝通協調窗口或是產品決策者及領導人，專案經理是對內團隊的溝通協調負責人及時程控管的角色。 通常這兩個職位的人要能夠互相協調並配合，有時分別扮黑臉與白臉，有時是一致對外，有時會有彼此理念的衝突，在這些時候最後的決策權是落在產品經理身上，因為產品經理要對 Master Manager和團隊外部負起此產品的成功責任，因此專案經理務必扮演起將團隊的內部訊息傳遞給產品經理的責任，當對內與外的雙方都能夠為了共同理念、願景和產品一同努力，產品才能夠有最好的發展。 這個角色同樣的也分為開發端與客戶端，因為雙方的 PMs同樣要負起彼此溝通的責任，Product 對 Product 溝通、同步該系統的功能與規格是否符合 Business Value 的責任，Project 對 Project 協調開發的進度、資源管理、執行間的問題排除等責任。
- 使用經驗設計師/UE/UX： 負責軟體產品的操作流程(包含操作方式、介面元件位置及共用性設計等等)、細節呈現及整體使用體驗。由於使用經驗設計師這個名詞在前幾年才剛出現，因此這職位所肩負的責任仍然很容易和視覺設計師(一般稱之UI)混淆。 而最佳也最正確的職責應將UX和UI完全分割開來，應讓UX負責整體產品共同呈現的元件風格、文字大小、擺放位置、操作手勢、介面轉換方式、輸入與輸出資料的流程(例如：每個介面應該輸入或輸出的資料欄位)，主要針對各介面能夠提供使用者簡便、完整與順暢的使用體驗。 UX為達成這些要素必須產品經理、專案經理、架構設計師、UI以及主程式設計師們通力合作，也由於需要同時和這麼多人合作，所以也經常把這個職責當成產品經理應負責的角色，然而產品經理為了兼顧產品團隊的整體發展，因此沒有時間和思緒可以鑽入產品的UX設計細節，提供足夠充足且考慮完整的作法，給團隊內的成員們依照UX藍圖進行設計。 因此，將 UX 的角色從 Product Manager 身上獨立出來，並尋找有工程背景但對介面規劃設計、使用動線設計、使用者經驗建構有興趣的工程師轉職，會對整體的系統設計有最大的效益。
- 視覺設計師/VD/UI： 負責軟體產品呈現給使用者的視覺效果設計，不同於UX，UI更正確(或更好)的說法應該為視覺設計，必須專注在產品呈現的色彩、圖像設計以及整體風格，甚至與其他相鄰的產品線共同擁有可供辨識的統一性，舉例來說：Microsoft 的方塊介面設計、Google 的 Material Design等等。 UI需要跟UX在不同時期肩負不同程度的責任，以80(UE)：20(UI)逐步轉換到50(UE)：50(UI)，然後是20(UE)：80(UI)，因為越到產品開發階段性的後期，UI為了呈現出更好的視覺效果，會與RD更加緊密地合作，甚至反過頭來要求UX協助思考，是否可以修改UX藍圖以配合更好的視覺效果，因此UI應該被稱為VD更加正確的原因在此。
- 技術經理/架構設計師/SA&PL： 負責整體產品的邏輯設計，通常在許多地方將此角色被稱為SA，而且通常是總工程師的另一種稱呼，他需要對軟體產品所使用的程式技術、語言特性、團隊成員能力、合作夥伴技術、市場新技術、元件重用(通用)性及產品未來發展方向等，有深刻的了解和經驗， 因為SA設計出來的架構將會因為團隊能夠掌握的技術以及架構，而影響此產品的各階段時程與未來前景是否能夠順利發展。
以上五種人是針對軟體產業在規劃分析階段時，身為一個商業分析者所必須要探詢、質問、巴結的人。當然啦，商業分析並不是給軟體產業的專利，而是放諸四海各個產業都需要的一把武器。
將上述的角色轉換成可以通用於其他產業的職位來看時：
- 最高主管：不用變，就是部門最高主管。
- 專案經理：也不用變，老闆指派的專案負責人就是專案經理。
- UX/UI/SA：掌管關鍵技術、擁有關鍵決策建議影響力的人。可能會是資深的老師傅、工班主管、業務主管、財務主管、倉庫主管，甚至是法務主管等等。這裡講的主管是在假設他們的專業技術能力夠強，是足以掌握公司在不同部門流程中的關鍵角色。如果有些是作為流程管理專業的主管，也是包含在內。
因此，在商業分析的Part 2一開頭，你一定要先找好這些人才能往下開始進行分析規劃的工作。不管是接下來要做的 BA Plan(商業分析計畫)或是 BA Work Plan(商業分析工作計畫書)，都需要這些人的參與，你才能夠準確地根據公司或客戶的內部流程，一步步地產出需求排序規則、開發追蹤工作、溝通與決策方法、驗證與確認流程、需求變更流程以及最後的結案評估流程。
而在依照內部流程而規劃出各種流程計畫之後，要有這些關鍵人物才能知道所有工作所需要的時間及資源、有誰該參與會議、誰該負責什麼產出之類的事，這也就是要根據 BA Plan 所制定的流程為參考，規劃整個專案進行的甘特圖。
總歸以上兩段話來說，其實就是要抓這些關鍵人物對我們要做的所有事情畫押，而他們就是這整個解決方案的中堅支持者，你必須跟這些人打好關係、讓他們能夠全心地支持產出的解決方案，並且作為解決方案實施時的最大推行動力，畢竟，這個解決方案中有著他們貢獻的建議、所需的實務功能，甚至是帶著他們頭像與名稱的文件名稱。
這就是商業分析第二階段，你身為 BA 所要找到的關鍵人物(Key Stakeholders)。
如果這篇文章你想用聽的，可以在這裡找得到：https://www.ears.tw/sounddetails/1756
如果你覺得這篇文章不錯，值得拍拍手，可以拍五下 Like 給我一些鼓勵：
分享至
成為作者繼續創作的動力吧！
© 2024 vocus All rights reserved.