3.7.資訊管理與系統分析

　資訊管理和系統分析的孽緣可深了，所謂的MIS，如果走的是軟體開發人員的路線，系統分析師是其中必經的一個歷練過程。這個職務怎麼樣？專業啊，蓋高尚？這可是個問題很大的角色，扮演對最後成果有絕大影響的關鍵的角色，而一堆狗屁倒灶的系統開發工作都是這角色搞出來的爛攤子。就讓我們繼續往下聊吧。

3.7.1.必須以使命目標為基礎(如何設計好的管理指標,一個方向需要多個指標)

　一個很簡單的問題，知識工作或是管理資訊系統的使命目標是什麼？現代社會有大量的辦公室工作，錢多錢少的都有，但不管怎樣，這類工作總是和文書處理糾纏不清，和資訊系統剪不斷、裡還亂。有這種工作經驗的人不少吧？感覺怎樣？是很專業，很有效率，很有成效，很受到重視的感覺，還是依然很專業，但沒什麼效率，成效不知道在哪裡，又嚴重缺乏存在感的感覺？

　使命目標好像是理所當然的，本來就應該有的，像神主牌一般不容質疑與侵犯的吧？這是很常見的一種誤解。沒有絕對正確的目標，也沒有恆久不變的使命，沒有經過深沉的思索與自省，是很難得到真正有效的好目標的。這是需要持續不懈努力的。很多組織的使命目標只是領導者的自我感覺良好，別無其他。於是很多知識型工作，其中的情境都特別的悲劇，累得要死，又不知道是在累什麼的。這是很難笑的。

　那資訊系統的使命目標呢？這可以分成三種等級。

　第一種是先有方向目標，謀定而後動的。方向目標在哪裡？在第一線客戶情報的掌握，在針對未來市場變化預測的領先投資。這是一種風險投資，是在下賭注。不過既然想清楚了才去做，目標方向自然品質有保障，在執行上總是比較容易到位。特別是當這個賭注下得好，這個對未來的許諾能激發眾人的想像的時候，常常能夠產生戰略性的壓倒性優勢。不過這個等級的案例算是相對少數的，很難遇到。要遇到一個雄才大略的老闆是不容易的，而曾經成功過的領導人也很容易勝而驕，腐化而變得平庸。就現況來說，這真的只是理想中的工作環境，可遇而不可求。

　第二種是一窩蜂的從眾行為。別人在弄ERP，我們也跟跟吧，別人在導六標準差，也叫下面幾個學歷高點的提個企劃案來試試看吧。原則是什麼？這些都是好的東西啊

，要多嘗試，要有創新與嘗試的精神啊，以上這種意識形態，都是老闆自我敷衍的道德藉口。其實根本就沒有清楚的使命目標在，只是做看看這種態度，自然很難有什麼成效。上行下效，這種優雅的道德口號思維傳遞是非常快速確實的，很快整個組織就變得高度官僚了。在人力銀行搜尋工作，上頭的職缺大多數都是屬於此類的，所以，可以看到某個職務找人找了好幾年，一成不變，職務說明看起來都差不多。怎麼，如果真的是好工作怎麼會一直找不到人呢？這類工作多半都很雞肋，不好不壞。好在穩定，待遇可能也算不錯，而壞就壞在明眼人一看就知道沒搞頭，而且還要為這種註定不會有成效工作焚膏繼晷，這樣才能給上級好印象啊！這種環境下，任你才能智識再出眾，也很難有所發揮，唯一可以經營的，大概就是辦公室政治，想辦法討好上級，爬上去當個小有面子的主管吧。這也算是一種個人的成效吧？只不過在組織發展與競爭力的培養上，這些個專業知識工作者，基本上是被邊緣化了，像個演員，不像一個思考者。這類的工作機會，目前非常的多，但是多半都有一定的資格條件，缺工，但也對減少失業率沒幫助。而且，雖然這種使命目標的本質就是漫無目的的從眾，但是表面上的裝飾只會更多，一點也不會少，這些表面功夫比起真的做事，其困難度沒減低多少，要是輕易招募新人進來，生產力是負的機率比正的機率還大！徹底認命的醬菜一族很能適應這種環境。不過這種環境雖然現在是主流，但終究會慢慢萎縮的。畢竟這樣的組織一定會陷於長期的競爭力衰退，隨著市場的變化演進，而遭到淘汰。抱著醬缸想安穩過一輩子，那還需要相當程度的運氣才行唷！

　最後一種就是最原始而蠻荒的情況。領導人對知識工作，對資訊管理根本沒有多大興趣，他只是專注在眼前能賺錢的事情上而已。被打了才應變，如果日子好過，可能也就沒什麼野心而追求一點面子，但是長期投資，分析與計畫顯然還不在思考範圍之內。剛起步的事業大多是這樣的。如果一開始就搞官僚，大概還沒發展起來就死了。這種環境的工作機會相對較少，而因為較少受到不當的資訊化的腐化，這些組織可能在年輕的時候還能有相當的效率。這樣的組織也會有IT人員，但是多半都要校長兼撞鐘，得要打很多雜，錢少事多。這當然不是好工作。這種情況其實是一種災難，但也可能是一種機會。缺乏長期的發展計畫與投資，組織的發展會受到很大的侷限性，也一樣很容易被淘汰。而IT工作的效率雖然通常不高，但是有IT的基礎架構在，還是有一定的效用在的。很多情況下，一定程度的IT投資是不得不為的基礎建設，只要控制得當，初期的投資報酬率其實還不賴。但被鞭一下才動一下的這種使命目標風格－也就是除了眼前的錢什麼都看不到，除了進化成為第二種情境之外，也存在很大的風險。其實這倒是一種機會，資訊化做的好對競爭力能有根本性的支持，在草創時期就能夠走對方向的話，這樣的組織有機會少走大量歪路，而有爆發性的進展。還沒爛的環境可能性比較大，等每個位置都被醬菜人緊緊佔據之後，就難有作為了。要在這種環境下發揮並成長，需要的條件和第二類相反，所需的素質比第一類嚴苛。需要口才，需要能了解上級意圖的能力，還要有能發現機會的觀察分析的，嗯，習慣。

　哈，這是廢話。我們來說一個管理資訊系統，以及一個管理資訊系統的發展專案，其使命目標為何吧。是為了某個目標，為了達成某個效果吧？系統分析師到底是在做什麼的？是做出交付任務給他的人可以滿意的分析文件嗎？那專案經理要怎樣才會對系統分析師的文件感到滿意？如果SA的目標是滿足PM，那PM的目標是滿足誰？一個滿足一個，組織的使命就能達成了嗎？有斷層。就像一群人，一個接著一個傳話的遊戲一樣，到後面會失真的很可笑，只以滿足上一級期待的方式來管理的資訊化，層層傳遞之後的成果就只會很難笑而已。每個人都不一樣，有的人還特別難搞，人和人之間還要看磁場的，不是特別對頭的長官與下屬，對任務目標的傳遞會有可怕的落差。每個人都不一樣啊，所以怎樣才算對，沒有通則可以遵行。互相猜測，進而互相敷衍，最後就只剩下搞政治，而不存在實質目標了。這當然不是必然的悲劇。一個整體性的使命方向有這麼難嗎？難得一見是真的，但這檔事本身並不是什麼高技術含量的高深技術活。只要想清楚，認清現實，抓住一個大的機會，賭下去就對了，難不是難在專業能力，難是難在人格上的修養哩。

　有一個整體性的方向，讓多方的努力有一個集中靠攏的依歸，這不是什麼高深的技巧。但是這很實用。杜拉克的管理，對於大型集團企業的組織原則，也就是這個集團必須有一個內聚的核心在，這樣的集團組織才有綜效，才不是為大而大的不當組織。這和系統分析的一項設計原則有異曲同工之妙。那又是內聚。系統要有高內聚性，與低藕合度。模組內的各部組件要高度相關，否則不應該把它們湊在一起送作堆。而模組與模組之間的關聯要越低越好，一但模組之間互相依賴干擾，這就不再能稱得上模組，而是一大坨屎。一個系統功能模組有其定位與責任，這就是它的使命與目標。這個模組內的所有零件都應該與此有關聯，否則就只是冗贅了。對比一下，一個組織裡面，如果有許多活動，和核心經營活動的關聯很低，甚至可有可無，那這部分的功能和人力是否合宜與必須？而設計不當的組織，就是功能的定位與責任不明確，相互依賴又缺乏內聚，這種情況下，系統開發費時，維護艱辛，但成效卻和付出一點也不成比例，這其實是很正常的。

　這個原則對PM，對SA，對SD，對PG都是適用的。掌握這個原則，對設計工作的品質會有很大的提升，能讓開發與維護成本大幅降低。其實這種原則性的東西，誰都知道，在其他知識工作領域也都有派上用場之處，只不過，真的看到應用的好的，如程式設計師的工作，比例似乎是很偏低的。很弔詭嗎？其實不會。因為這個原則會產生另一個效果，那就是工作的透明度提高了。這樣的工作，只需要兩個人就能做得很好了，幹嘛要養一整個團隊來做些耍花槍的麻煩事？工作的透明度越低，就越能在專業的外衣之下做自己想做的事，為自己的目標使用組織的資源。這是利益衝突的問題。這問題當然存在，普遍存在，也會影響到簡單有效的設計原則的正常發揮。但事情就是這個樣子，不認清楚，就只能自己矇著自己的眼睛做事了。

　你真的清楚你所知道的系統是在幹啥的嗎？你熟悉的系統其職責是什麼？存在的價值有多少？真的清楚嗎？想清楚，看清楚，這能帶給你很多不容易看見的小契機。不要輕易浪費掉囉！

［數據結構的設計是誰的事？］

　每一項職責總有一個擔當的角色。數據結構的設計是那個角色的工作？實務上這沒有一個明確的答案。比較合適的角色，會是對整體資訊化有全局管理責任總需求規劃者。通常沒有這樣的職位。資料庫管理師常常只是負責技術上的數據庫設計與管理，對需求面不具備相應職權。而大PM主要的精神則通常是放在人事與資源分配的協調上，而不會管到數據結構的細節設計。系統分析師則通常是有一個責任的範圍在，整體與全局不在其職權範圍之內。那技術上的整體架構師呢？這樣的角色常是忙於技術上的問題，對於整體需求規劃的數據結構缺乏興趣。實際上在數據結構上，是需要一個集中控管的角色，來確保整體協作與溝通的品質，但卻沒有很清楚的角色執行這個任務。讓SD與PG直接設計需要使用的數據結構是常見的事，而這兩種角色壓根不適合這個整體控管的任務。於是乎，數據結構規劃設計的工作品質，常常是不怎麼樣的。

　這要先釐清好，到底對這個數據結構整體規劃職責的需求為何，再設計要哪個角色負責承擔這項任務。角色可以被創造出來，也可以調整現有角色的部分職能來因應，重點是，需求有多高？而職能的責任是否明確？該角色是否有足夠的職權來做好這項工作？在很小的系統需求上，或許直覺上是不需要大費周章來設定這個角色，但隨著系統規模與擔當任務擴張，當有此需求產生的時候，可能已經是在一個很慘的狀況了。這還是在一個被動的角度來看。如果系統要主動配合業務的發展，展開有靈活度的策略性功能，沒有了解經營核心領域議題的整體規劃者在掌控的話，系統設計的結構很容易就和需求面脫節。需求方想要的功能，和開發方想做的設計，常常不能搭配，甚至同床異夢。如果不從源頭，至少在數據結構的整體規劃確保一個雙方一致的認知與充分溝通了解，資訊化能發揮的成效不如預期，也是自然而然的現實而已。

　［數據結構的正規化與反正規化］

　技術人員對於數據結構的設計，直覺就是數據的分析設計要做到正規化。至少也要做到第三正規化吧？這畢竟是一個明確的技術議題，方法也很明確，所以常被設計的菜鳥當成工作指導上的一個圭臬。這是萬靈丹嗎？

　正規化是對的。排除不必要的重複數據可以提升效能，排除不必要的重複數據也可以減少錯誤與數據的矛盾衝突。可以說這麼做是有效益的。但是所謂的分析設計，也摻雜了許多人為的判斷。沒有絕對應該怎麼設計這回事，觀點不同，可以做出不同設計，而不同設計產生的效果也不相同。我們永遠無法保證，我們現在做的設計已經提供需求最大最好的滿足了。需求本身都可以重新解釋，而找到不同做法可以創造不同的價值。死守正規化的理論，正規化做得更正確一點，可能在成本的管控與錯誤的防治上增加了一點點正面的成效，但是可能也會讓系統的複雜度有了大幅度的提升。以成本效益來看未必然划算。而更複雜的系統，在因應需求變化的彈性上，也可能會受到很大的限制。正規化做到極致時的邊際效益和邊際成本是不成比例的。而這還要看我們如何看待資訊化追求的目標是什麼。

　要一邊確保數據結構的簡單和數據結構正規化這兩頭的平衡。保持設計上簡單永遠是最好的指導原則。要避免新手，還不清楚分析設計在幹什麼的資優設計師為了表現自己而做出的偉大豐富的設計。這絕對是一個大災難。只有對目標有良好掌握才能做出適當的設計，這個通常不是名校出身成績優異就能馬上做好的，把這個職責當成是個簡單的只要技術就能搞好的任務，可能只會讓你提早折損未來的潛力人才。聰明人急於表現自己，對於管理資訊系統這種軟體開發工作來說，是最危險的一件事。因為如果對目標沒有良好的掌握，很容易就會設計出過於複雜，充滿累贅的不當設計，這這個代價不是馬上能看到的，通常發現問題時，已經來不及導正了。

　數據結構設計的原則會是，要盡量保持簡單與業務核心活動的密切配合，並盡可能保持改變的靈活彈性。正規化只是其中的一項技巧而已。因應目標，有可能從業務觀點來看，需要的彈性正好和正規化是相反的方向。反正規化不是什麼特殊的技巧，那是只有透徹了解目標的時候，自然而然因應成本效應分析做出來的適當決策而已。不要被表象所迷惑，系統分析設計的目標永遠是針對需求的滿足，管理與成本也只是需求的其中一環而已。

　所以，設計數據結構時，技術上設計得好是一回事，與設計得有價值是兩碼事。看起來很專業的數據結構會是系統分析師在工作上的一個危險誘惑。為了看起來專業，就必須要刻意設計得複雜，否則連自己都騙不過。而為了要騙過眾人，就不得不固守專業立場，而與需求方站在對立的立場。技術上的正確被當成一種專業的正義，這種畸形是相當常見的。這樣的工作勢必產生不了什麼成效，只會製造成本而已。永遠不要忘記目標是什麼。

［時間維度的數據結構設計］

　設計數據結構的時候，時間永遠是一個值得考慮的維度。數據的狀態會變化，隨著時間變化，只看某一個時間點，例如當下，不能夠得到全貌。這是需要注意的，但也必須謹慎以待。儲存更多數據成本現在是算不上什麼成本的，硬體上的成本幾乎可以無視。但是多出來的數據如果誘發了管理者的熱情，而過度專注於不重要的細節上面，就有可能會得不償失。

　從時間的角度是認識與了解數據結構的一個好方法。從系統數據的生命週期著手，數據如何從建立到被結案封存，通常都能對整個系統流程有快速而通盤的了解。如果數據結構設計的乾淨簡潔，這會比乖乖看系統文件要有效率的多。

　這個說來空泛啊，其實簡單說就是，有沒有什麼重要的資訊是在隨著時間的經過而成為漏網之魚？數據是這樣的，如果沒有保存起來，沒了就沒了。邏輯上存在的數據不代表系統就有，就能運用。有時候設計就是要做抉擇，要留什麼捨什麼，什麼都要和什麼都沒留下一樣是畸形而糟糕的。原則還是要看重要性的。

　［空間維度的數據結構設計］

　衡量數據的重要性，這個超級簡單的原則常常被忽略了，掩埋在技術與政治議題之下。到底什麼才是重要的？不同角色的人認知是不同的。特別是工程師和管理業務這兩個陣營之間，甚至可能有個鴻溝在。不警覺點，會不知不覺的失控。

　決定數據之間的關聯，其實也是決定數據重要性的一種形式。為什麼有這個關聯？是針對現實的描述，還是有業務目的的存在？這通常是兩難的決策，怎麼設計都行，但是頭洗下去，要回頭就很難了。如果不小心的形成共識的話，通常技術與業務兩端，會導向其中的一邊，然後那一邊玩的很爽，另一邊做的很幹。這是一種腐敗的現象，不過也是很常見的狀況。

　重要性的關聯，其實更重要的一個要點是，不要忽視聯想的重要性。分析數據的關聯，是一個思考的練習。到底關聯是什麼？可以從現實的直觀解釋，也可以從目標導向的層面來思索。想想吧，其實問題常常比自己以為的更複雜，然而，一旦想清楚，最後的答案與抉擇會出乎意料的簡單。

　這個說來就更空泛了？是啊，是很空泛的。這需要實際去分析思考過才會有感受的。然而這種機會其實很多，也是知識工作提高效率的一個好途徑，只不過，因為專業的外衣，常常沒得到足夠的重視。高階主管關注的是政治與積極的管理把戲，工程師想的是技術的玩意兒，業務單位眼中只有當下的業績，關注什麼是重要的，與這些素材之間的關聯與重要性這檔事，常常像孤兒一樣得不到足夠的關注。這樣真的明智嗎？當討論怎麼做比做的是什麼還要重要與熱烈的時候，路就開始走歪了吧？

　［一對一的精確對應設計原則］

　說到數據結構的分析，一對一的精確對應設計原則，是值得拿出來討論的。作帳，常常會有所謂的月底關帳，每日結帳這樣的管理流程。好像也是一種專業，是一種管理吧？其實這是錯誤的做法。帳應該要及時而精確，總帳與明細應該要永遠都能對得上，這才是正確的做法。這是道德原則，而非設計的技巧或技術的議題。帳能做清楚，為什麼要糊在一起，再來對帳、查帳與調帳？

　一對一的即時對應，會面對開發成本的考量。將就一下可以降低成本，讓功能早點通過驗收，讓系統早點上線運作，留下的模糊地帶也讓系統在處理複雜問題的時候有後門可以繞。就短期的角度來看，這樣做實在是太有效率、太英明了，馬上就能創造績效了。但是這個是短暫的成效。糊在一起，就是留下作弊的空間，也留下更大的人為錯誤的可能性，而後續產生的問題處理成本，絕對足以抵銷早期貪步得來的好處。製造模糊是一種腐敗的習慣，同樣都有做不完的事，走模糊路線的和走明確路線的，做的事會漸行漸遠。前者會越來越傾向胡弄自己與胡弄別人，而後者才是真的找有價值有意義的事在做。當看到數據結構中存在許多糊糊的數據，月結日結每次系統作帳就要花很多時間的，大事不妙了喔。路遙知馬力，這是永遠不錯的。

3.7.2.2.商業邏輯(明確流程)

　［系統要做什麼比技術本身重要］

　系統是做什麼的？是為了滿足管理上的意圖吧？那又是什麼意圖，想要做到什麼？系統是什麼，這個問題其實不是那麼容易回答的。眼前就是一座山的時候，我們看到的不是這座山，我們看到的只是一幅平面的圖畫而已。山是什麼，如果不走進去觀察，是無法了解的。通常每個人只能看到其中一角，這是很平常的狀況。

　借用杜拉克的一個觀念來用。對企業來說，只有行銷與創新才能創造價值與產生績效，其他活動都只是必要的成本而已。那管理資訊系統的價值在哪裡？它是如何創造績效，對組織發揮出不可取代的重要功能，而不是可有可無？其實有些系統就是可有可無的，甚至成本大於效果，就這些系統來說，沒有答案。這個答案不容易界定，恐怕也沒有標準答案。不過我們可以依樣畫葫蘆。假定企業最重要的任務就是行銷與創新，那麼管理資訊系統也可以把任務放在輔助行銷與創新。於是關於顧客與市場的內部資訊與外部資訊需要平衡的取得，並以輔助高階主管的戰略性決策作為最終的目標吧！當然內部檢核與管控，控制成本也是很重要的，但是這種管理要小心上癮而做過頭。過度管理與軟體開發的過度設計一樣是得不償失的，拿寶貴資源換面子而已。

　其實資訊系統對很多行業已經是必要的重要機能。像零售業，如果不能即時清楚庫存和成本，帳都弄不清楚，是賺是賠都只能靠感覺，要把事業做大是不太可能的。要舉辦促銷還是活動，都需要強大的資訊支援能力，不然不是動彈不得，就是與資訊系統脫節，回歸到和沒系統差不多的狀態。活動和促銷當然還是可以辦，只是如果是一個縝密的行銷計畫，有戰略性的目標在的話，沒有資訊系統的支援，既缺乏對市場與客戶的資訊，活動辦完的成效也缺乏清楚回饋的分析，怎麼玩？人工做資料啊，還是能玩啊，只是成本與作業品質表現不會好的。可重要的是什麼？不同的角度，看到的可能不一樣。對一個技術出身的工程師來說，他可能毫不關心那些行銷還是業務面的需要，他只關心他能碰到多少新技術，能累積多少個人的技術工作資歷而已。

　商業邏輯，Business Rule，這東西可能會被設計成系統架構的一個底層，這玩意兒是誰在主導？很可能是工程師。畢竟這也看起來像是很酷炫的設計啊！所以工程師很容易過度設計，反而偏離了主要的商業流程需求，鑽到技術牛角尖去了。專業管理人員也是，可能在小領域過度鑽研管理細節，把商業邏輯弄得太複雜，而搞偏方向。

　什麼是商業邏輯？把做生意賺錢想清楚才是商業流程。可有可無的複雜細節不值得拉出來當作商業邏輯。好的商業邏輯其實是對企業經營模式深度分析之後的結晶，也是經驗的累積。更重要的是，它提供了系統發展的一個重要基礎。因為對現有的重要流程都已經做好了整理，要開發新功能的時候，這個商業邏輯設計的成果就是便利的現有資源，不但能降低開發成本，對系統複雜度的管控也有很大幫助。這可以說是數據結構之外的另一個改善設計的切入點。

　［商業邏輯需要組織與條理］

　商業邏輯不是有就好。弄個商業邏輯庫不代表能產生什麼成效。可以增加重用性是肯定的，只不過，如果單純是為了重用而設計，應搞出來的商業邏輯庫，也可以是一個把系統弄得無謂麻煩的亂源。

　必須要有整體性的規劃。否則把商業邏輯層獨立出來管理不會有效果，這是可想而知的。必須用心分析，把商業流程想得清楚，並採納各方的需求，才有可能做出有整體效益的商業邏輯設計。是的，或許最終目的可以說是為了增加重用的效益，但是在思維上反而要避免這樣想。應該要想成，把可用的資源整理好，使其處在一個靈活可以方便被使用的狀態。要創造更多的資源，更發揮資源的潛在價值，這個思維和為了重用而重用有些微但奧妙的不同之處，這需要好好體會。

　［防止錯誤與減少風險的邏輯］

　透過良好的規劃，商業邏輯層可以起到一個整體性規範的效果。有些重要，又很容易不小心會犯的錯誤是應該要極力避免的。但是新人怎麼會知道？錯誤會重複，直到學到教訓為止，人員流動，問題又重複發生了。這可以靠內部教育訓練來改善，但是如果作業流程已經高度資訊化的話，在系統設計上就可以根絕這種已經被發現的重要錯誤。當然這也需要節制，這種工作是做不完的，需要取適當的成本效益平衡點。太過不足都不好。

　避免錯誤之外，風險的管理也是系統設計時可以支援的一環。當然這還是要先思考業務流程與商業需求，找出風險之所在。這當然需要前置的分析思考。但是，資訊系統的設計，常常有機會提供很多好的風險管制點。用特定的規則就能產生適當的風險警報，只要有基礎數據，然後基礎數據品質沒問題，這不難實現。真正的瓶頸點不在技術上，而在釐清哪些是需要管理的風險。如果管錯對象，反會給自己找來麻煩。

　商業邏輯層既然是一個整體的機制，把減少錯誤與風險控管設計成具一致性機制的一部分，通常會有不錯的成本效益。當然，需要先想清楚，還是前提。

　［發掘機會的邏輯，客戶需求］

　其實還是要回歸根本。管理資訊系統的目標還是要創造價值的。滿足客戶，也就是系統的使用者的需求，才是根本。商業邏輯的設計與管理也不能脫離這個根本原則。

　客戶想要什麼和客戶真正需要什麼未必一致。客戶想要什麼就盡可能給他們想要的，未必會有好的結果。當客戶沒有想清楚需求時，一味牽就客戶的需求，只會讓商業邏輯充滿矛盾與混亂，開發累得要死，使用者還是照樣嫌棄到不行－明明這就是當初他們自己提出的需求呢。只有使用者得到系統輔助的真正好處的時候，他們才會感激系統開發者的辛勞，才會覺得這系統有點用。但當使用者主導系統發展的需求的時候，他們卻未必有能力掌握好需求的方向，很有可能不是心甘情願的做，這樣的需求他們也不會滿意，然後會怪到開發者頭上，在細節上挑三揀四的。這也是人之常情。另一種情境是使用者心思太雜，想了很多花招，純粹是喜歡搞一些視覺上的不一樣的設計，而從中獲得成就感。這樣的客戶是不會為大局的成敗負責任的，開發好他們夢想中的功能操作時他們會很興奮，但這些讓人興奮的設計對於整體目標來說是微不足道的小事，而且還會占用大量的寶貴資源。當業務整體狀況不佳的時候，系統自然就會不好用而承受批評了，而很有可能，此時系統因為被一些次要的花招需求搞得太複雜，真的需要它幹點事的時候，反而改不太動了。

　如果可以了解客戶的業務運作，而且也知道什麼需求才是重要的，那麼做客戶未來會需要的設計，可以事半功倍而卓有成效。但這不容易，對能力與經驗的要求高，還需要和業務人員有相當緊密的配合和良好的溝通，這通常是不可求的。

　所以說，在分析設計商業邏輯的時候，最好的策略還是一樣，和設計數據結構差不多，盡可能用簡單直覺的角度，把資訊化的對象當成資源一般的管理。保持資源的靈活彈性，並盡可能發揮其使用效益，在這樣的態度下盡量以簡約的風格來做整體的規劃，會比較好一點。反正就是一堆資源，要怎麼用都行，使用者想到的時候，兜一兜就能上菜了。如果我們不是客戶肚仔裡的蛔蟲，還是不要幫客戶想他的需求細節，讓他自己決定就好了。系統分析師要做的事就是力挽狂瀾，別讓一些花俏而不成熟的想法把系統架構與商業邏輯變得過於複雜。世事本來就複雜，而複雜是層層疊加的，這裡那裡一點點的小小不必要複雜，累積起來的成本驚人。甚至是系統判生與判死的差距。好的設計能讓系統分析師與開發團隊都得到足夠的重視，並產生實際績效，而不好的設計除了滿足少數人心裡那一點點的虛榮之外，只會做得更累，而全無成效，充滿痛苦與不滿。其中差距不是用幾個百分點可以體現，實質生產力的差距是好幾倍的，甚至因為比較的分母績效太低，可能會除出個無限大的倍數。真的差很多的。

　［堅持方向不要三心二意］

　設計獨立的商業邏輯層是一個管理思維的進展。這表示對於管理資訊系統的發展與維護，已經開始有了點想法。這是好的出發點。但是要小心的就是，系統設計的最高原則就是沒必要性與足夠性價比的設計複雜度要千萬避免，盡量讓系統以一個資源角度的彈性結構進行發展。只要維持這個原則，那管理資訊系統是什麼，核心商業邏輯是什麼，答案就是這些靈活彈性的數據資源。用資源的角度，會比一堆邏輯要好了解得多了！

　這也是對人性的試煉。我們人總是會想太多，有時候忍不住想多表現自己一點，想證明自己的能力，想得到別人的讚賞，而且需要的時間點總是馬上需要！這就會引誘我們做一些複雜花俏的設計，只要這些複雜度悄悄溜進了系統的根本，如數據結構或商業邏輯層，這個危害就會很難止血。大勢已去也。如果認定了要讓管理資訊系統發揮成效的道路方向，就要堅持簡單原則，不可三心二意，被政治需求所左右而動搖，這是一種長期投資，只有堅持到底才會有最大的報酬。

　嗯，對於多數環境，已經走上死路的環境來說，那又該怎麼辦？要堅持的原則是一樣的，如果現有的架構已經難救，也只能慢慢的轉移，反正這種環境下系統的成效被詬病，也一定有新的需求產生。重新規劃一個架構，再慢慢把東西搬過去吧。只要用心分析與設計，你會發現其實系統根本不需要設計得那麼複雜，沒有想像中那麼麻煩與痛苦的，也有很多機會是可以被利用的。都是觀念問題啊。

(以下11/3更新)

3.7.2.3.使用者互動介面

　管理資訊系統的本質是數據和邏輯。但如果沒有和人產生互動的介面，那就什麼也不是，只是空想而已。反正是想像中的系統，要說它有多強大都行，反正也看不到！

　［鍵鼠與螢幕］

　鍵盤滑鼠和螢幕是最傳統的使用者互動介面。個人電腦就是一台主機，接上鍵盤滑鼠螢幕就是了，筆記型電腦也是幾乎一樣的。如果硬要把會用電腦和不會用電腦做一個分水嶺，鍵盤打字和滑鼠操作的熟練度是一個指標。很少用電腦的人，滑鼠點擊操作那是慢動作的，打字是一指神功非常龜，就算去上電腦課也沒幫助。不常用就是會很生分，效率很低。至於常用電腦玩動作遊戲與線上聊天的，那鍵盤滑鼠的熟練度就可以是神乎其技，有夠快的。懂電腦的基本，其實不是懂電腦被設計出來的原理，而是熟練使用這些常見的使用者操作介面。

　早些年，還在DOS時代，那個時候滑鼠都還是新發明，視窗畫面也是新東西，那時候懂電腦是要懂一些系統指令。要使用一個應用程式，要先下指令切換到那個目錄，找到執行檔，再執行它！應用程式，如遊戲，需要的輸出輸入介面，如鍵盤滑鼠甚至遊戲搖桿，可能都還需要找到驅動程式再下指令去驅動，程式才能跑得起來。即使是現在，像Unix/Linux等作業系統，也是要熟悉許多系統指令才能玩得動。和視窗作業系統是一樣的，人需要一定的手段才能夠讓機器做事，這一點是不變的，不管是用鍵盤下指令，用滑鼠點擊操作，還是用觸控螢幕操作，目的是一樣的，結果也可以是一樣的，只是手段不同而已。

　這也是系統的一個限制。沒有辦法弄到輸出裝置的東西，就不能發生實際的影響力。至少也要看得到吧？若連看都看不到，那是什麼鬼？系統不管設計得再神，也要有驅動好的輸出入的設備的互動操作性，那才有用。因此了解一個系統，除了從邏輯面與整體設計概念著手，從實際的操作畫面去看去了解，也算是一種腳踏實地的基本功。先別說些不容易懂得東西，先從這個系統實際上能被怎麼使用，怎麼親手去操作，怎麼親眼見到成果，這是使用系統的第一步。如果使用者根本沒照設計者的想法在使用系統，那這個系統自然無法發揮出設計者預想的成果。這是廢話啊！或許是吧。不過呢，在資訊工作的領域，設計程式的人不使用自己設計的程式，分析系統需求的系統分析師和他分析工作產生的實際成果沒啥利害關係，這也不是什麼罕見的情況。一旦連最根本的使用方式都摸不上邊時，會出現什麼荒唐的設計，也請不要意外喔！管理資訊系統是什麼，還是有必要從頭了解起。方法就是去操作它，再找出操作與自己切身事務之間的關聯。不這麼開始，又要怎麼了解系統需求？

　［智慧型手機］

　就我們知道，鍵盤滑鼠的個人電腦操作，已經是落伍的方式了。現在流行的是能上網，攜帶便利的小型數位資訊設備。智慧型手機、平板電腦，是很熱門的產品。沒錯，只要能做事，又何必一定要一台配備鍵盤滑鼠螢幕的個人電腦呢？在某些情境下，只要能上網，有個顯示螢幕，能操作的畫面，就能滿足需要了，而隨身攜帶的便利性價值更大。沒有連線到網路的性能超強個人電腦，對一般人的用途未必比一支能上網的智慧型手機高多少。

　智慧型手機是一種流行，更輕便多功能的數位設備會是未來的演進趨勢。這都沒錯。但這是一種時尚，是風潮，也可能帶著點不理性的成分。好像手機程式設計就比個人電腦用的程式設計更高明點，更優越點？程式本身就是邏輯，看是為了哪些輸出入設備而設計的，用起來可能不同。但是就為了使用的目的去設計，並達成目的，使用什麼裝置都只是其中一種手段而已。該採用哪個方案，要依目標需求以及成本效益分析來決定，而不是只要跟流行就好。

　良好的分析設計，能讓與輸出入裝置的介面被獨立出來，而與邏輯脫離。今天如果要換一套嶄新的硬體設備，設計做到極致的話，只要把與操作介面相關的程式做調整就能安心使用。當然這幾乎是不可能的事。要換不同的操作方式，如把滑鼠操作全換成觸控(這影響倒是有限)，然後把鍵盤換成觸控方式輸入或語音辨識輸入，現有系統的使用肯定會增加很多工作，而會焦頭爛額的。

　啊，那這又有什麼值得注意的事呢？以手機來說，這東西其實很久以前就開始發展了。能上網能收電郵的手機很早以前就有了，早期操作性雖不是很理想，但是行動優勢還是讓很多企業心動。把架在企業內網的管理資訊先是搬到網路瀏覽器上，然後又再移植到手機與PDA上，幹得風風火火的也是有一些啊。實際上的成效多半是成為高階主管的玩具，玩一下而已的玩具吧。如果有哪個企業把資訊系統都建構在稍早期的手機上頭，如果又沒有把商業邏輯與操作介面設計得夠獨立，現在的處境一定會很慘。越是流行的東西，演進與升級的速度也越快，投資反而可能更不容易回收。為了利用行動裝置的便利性，如果把組織內寶貴的資訊資源都壓在嶄新系統上頭，要是運氣不好押錯寶，可能心血會整個燒掉。整個燒掉不是最慘的，最慘的是被過時而不再具備未來性的技術與系統綁架了，企業的流程大量都整合在上頭了，而不得不遷就花了大資本打造的寶貴資產！

　這其實是很傷腦筋的一件事。新潮的東西做了有面子，就個人來說對求職競爭力也很有幫助，但是對組織的整體效益來說卻是兩面刃。在管理沒個樣子的環境，有可能會養一群技術狂人，焚膏繼晷的日夜加班開發軟體，但什麼成果也做不出來。是啊，新技術是好的，但是要到能發揮產值需要一定時間的耕耘，而新技術的進展與競爭可能過度熱烈了，前一個流行還沒成熟就有了新的更受矚目的替代競爭對手冒出頭。整天玩新技術就好了，可以不用做事了？這就是傷腦筋的地方。到底目標是什麼，如果沒有搞清楚，方向堅定，很可能會悲劇。

　總而言之，行動裝置的普及是趨勢。但是資訊系統與行動裝置的整合到底是不是大力推行的時候？現在有各種介面可以開發一些行動裝置上面使用的軟體，是拋棄舊的技術與介面投資新的趨勢的時機了嗎？可能還不是好時候。如果語音的操作可行而成熟可靠，那觸控介面可能相對優勢就降低許多。如果哪一天人的意識波能直接和系統有效整合在一起，那麼現在的這些鍵盤滑鼠觸控聲控就通通是垃圾了！這不見得是天方夜譚啊。這是難題。但是這也更突顯出，簡單獨立的設計，把資源當成資源的簡單原則的重要性與優點。對資訊系統來說，或許彈性才是最大的優勢。把這個根本顧好的話，或許對於輸出入介面的升級進化這個問題的應對就不需要那麼苦惱了，根本做好，進可攻退可守，賭一把的風險決策做下去，就算輸了也不會脫褲子啊。話說回來，保持理性，不要脫離目標與成本效益的評估，才是面對風險決策的關鍵吧？

(以下11/4更新)

　［下指令控制機器］

　操作系統的介面雖然基本而重要，但也不要把眼光都放在鍵盤滑鼠與智慧手機上頭了。其實資訊系統還有很多的可能性，不是只有直接看得到的和摸得到才算數。資訊系統可以實現我們的意志，做我們想要做的事，只要我們清楚到底要它怎麼實現。指令不只是遊戲或是單調的管理系統的操作而已，指令可以是指令，是指揮命令，只要把整個運作的系統給建構完成，指令是可以動的。

　最單純的構想大概就是遙控家電吧。可以透過設定排程，讓系統幫我們錄下想看的節目，自動煮飯燒水洗衣服，這都是可能做的到的事。只有成本多高，效益多大的考量而已。或許更實用的是像玩遊戲的輔助程式一樣，代替人手眼的辛勞，呆板但踏實的持續打怪升級。像這類工作電腦就比人腦有優勢多了。如果只要安排行動計畫，放著讓系統幫我們執行，那生活或許會更輕鬆與有趣？重複機械的制式動作，讓機器代勞總是未來趨勢的。

　可以再發揮更大的想像力。像三國志之類的戰略遊戲，也就是下指令的方式在進行的。為什麼執行開墾的指令，領地的收成就會提高？為什麼指令可以產生效果？命令能夠執行需要的是指揮系統，像軍隊運作那樣，要有情報與命令傳達的系統，資訊要能回饋，監督要能落實，命令才不會是笑話。其實在很多方面上，都適合建立指揮體系，來落實我們的意志，特別是管理的工作。要讓系統單獨完成一個完整的行動指揮體系是太苛求了，要能動，能確實執行，會有嚇死人的成本。但是搭配人力呢？把人當成系統的一部分，一起建立好這個行動指揮體系，可行性就大大提高。專門執行某些有需求的指令，或許也可以是某種組織的經營生存方式？其實說回來呢，這也就是很一般的企業組織設計管理資訊系統在做的事吧？如果不是為了趕流行或為了資訊化而資訊化，這本來就應該是資訊化的基本思考出發點之一，但是有多少組織的資訊化是僵化而變成怪東西的呢？人也可以是系統的介面之一，也應該是管理資訊系統運作的一部分，本來就該這麼思考吧？

　［設計的親和與易用］

　不論輸出入介面設計得多酷，還是得要站在操作者的角度去設想，方便易用，使用起來才會順暢。設計者沒站在實際使用者的角度在規劃與設計系統的功能其實是常見的事，看起來很好看，用起來卡到不行的系統，增加的使用成本，或許看不到，但卻是驚人的。使用更費時與容易出錯是一種成本，對系統的使用產生抗拒心理則是另一種看不見的代價，而使用者因此在提需求時喪失理性則是終極的災難。要小心這種惡性循環。其實在一開始就從使用者的需求與使用的適切性作為基本的需求，彎路可以少走很多的。

3.7.2.4.系統整合介面

　系統總是由一些比較具體的概念構成。除了最根本的數據結構與商業邏輯之外，還有一些常見的基本介面。

　［表單］

　網站買東西的購物車是一種表單。把紙本的請假單與採購單這樣的單據電子化，設計成電子表單，這也是表單。基本的系統操作，都可以說是表單，表單可以說是介面中最基本的。那表單的概念是什麼？主要是數據的增刪修查，以及操作與命令的互動介面。

　設計表單的時候，要先分析這表單的用途與關聯影響的數據是什麼，再思考這個表單的商業邏輯需求有哪些。完成這兩件事，應該就能夠理清一個問題：這個表單的用途與定位到底是什麼了。這是很重要的基本工作。這其實就是系統分析文件的精神了。接著就是構思表單的操作流程與互動設計方式，把自己當成使用者來設想，剩下來的就是把設計作周全了。嗯，這個思考的過程如果可以寫下來，對理清自己的思路有幫助，先想清楚再去執行，對工作效率的提升也有正面幫助。這就是系統設計文件應該的寫法了。很多人寧願把程式寫得再精鍊一點，多用上點技巧，也不肯把需求文件的需求，設計文件的思路寫下來，於是系統因此難以維護，那真的是人為的災難啊。

　［報表］

　報表主要就是用來看的。看數據，分析數據吧與使用數據，就這樣？

　報表常常會有執行效能的問題。那是SD的設計與數據結構的不良導致的。人的肉眼能力有限，一眼不可能看海量數據，也不可能用飛快的速度瀏覽海量的數據。一眼所見，一時所觀的報表數據是有限的，只要系統沒有因為設計結構有問題而無法有效使用數據查詢的索引，或是做了太多多餘的動作，沒有慢的理由。要執行半小時的報表是荒唐的，不過實務上這並不是罕見的情況！當然，有些報表需要特別彈性的查詢條件，在效能優化上需要更多的工，如果投資報酬率不划算，讓不重要的報表慢一點不是什麼大不了的問題。不過呢，如果是一眼能看完的報表要等上半小時，那還是太誇張啦。

　報表的另一個角色就是，它能讓人對其有錯誤的解讀。太過樂觀的人最喜歡設計報表了，特別是能支持他樂觀預期的報表結果。這是一種本末倒置，不過也是不難見到的一種常態。許多人特別重視某個報表，只因為那個報表的數據與個人利害高度關聯，於是，他們甚至會試圖去扭曲報表的定義呢！玩過頭，報表就沒有其原本設定的功能效果了，只是一堆狗屎而已啦。

　［轉檔程式］

　系統系統，總是一堆系統，一堆不太相容的系統。一個企業可能就有許多個資訊系統，有的是內部開發的，有的是外包開發的，有的是套裝軟體。唯一確定的是，這些系統之間彼此都不是很友善，你的是你的，我的是我的，如果沒有管理好，甚至相同的事務物件在不同系統都存在，定義卻不同！因為系統沒有一個整體的規劃，於是，明明一件很單純的事，就得要在多個系統之間小心處理，才能不出錯！這是浪費很資源的事。

　分久必合，四處散落的數據，終歸要整合成一致，不然實在太痛苦了吧？不同系統的數據如果能夠互通，能做好多本來不能做的事啊。於是就產生了一大堆轉檔與數據整合的程式。甚至有專門寫這種程式的工程師呢！

　終歸只是轉檔而已。這種工作不是做越多越好的，會有一堆轉檔工作要做，很可能是整體的規劃沒做得很好。這只是減少本來就可以避免的浪費而已。如果數據結構的整體規劃與管理有做好，如果設計有秉持彈性靈活的發揮資源價值的簡單原則，內部系統整合與轉檔的需求應該是有限的。

　相同的，如果數據結構設計得好，和外部，也就是其他組織的外部系統的整合工作需求，可能還是很高，但是困難與痛苦不會在自己身上，而是在數據結構設計不良的那一邊。畢竟設計良好的數據結構本來就是利於整合與應用的，不管是用最土的文字檔交換數據，還是流行一點的網頁專用的數據結構做數據交換，本質都沒多大差別的。那只是最末的手段不同而已，反正選擇很多，這條路不通換一條即可，影響還是有限的。有的組織在轉檔與數據交換上抱持著很大的期待，但業務邏輯本身沒釐清，數據結構的分析設計也還處在混亂，卻只在技術選用的細節上想頭很多，這樣的狀況只會越轉越昏而已囉！

　［自動化］

　前面提到，人可以是系統的一部分。而系統也可以做人做的事。人做的事，如果是明確而重複的，又不需要思考，只要勤勞與腳踏實地就能做好的，其實再適合系統處理不過了。只要從事的工作有足夠的價值，讓機器代勞，成本可以更低，工作品質可以大幅提高，因為這本來就是適合機器做的事。

　讓機器做更多人做的事現在是很敏感的話題，政治話題。搶