國內從事 “企業(Enterprise)” 軟體的獨立開發廠商(ISV)，大致可以分為三種營利的模式：
- Project (專案)。
- Package (套件)。
- Product (產品)。
算起來，應該約有 80% 以上的開發廠商是以專案開發為主的(Project-based)。專案，顧名思義，會偏以滿足單一任務的工作性質，服務的對象也偏以單一的客戶為主，目的就在於能達成客戶對資訊系統的期望，而這些期望，也就是系統所提供的服務與功能—軟體開發廠商所負責承諾來實現，並換取實質的回饋報酬。
我們都知道，最為難的就是如何能滿足客戶的期望，因為，客戶的期望一直在變；又，競爭的因素，專案性質的資訊系統開發總是被要求在最短的時間，以最少的成本來完成，自然，種種不合理的要求，品質當然也就不佳。
請記得，開發端與客戶端是要能達成一種實質交易上的平衡，而開發端投入許多的心力與人力，來服務單一的客戶，卻換取開發端認為不合理的報酬，當然這種交易的結果也就無法讓雙方都能協調滿意的了。
只賣給一家客戶，即使開發 ERP 系統拿到 200 萬元，開發端都還認為是慘賠，因為人月的實質負擔實在不敷成本。一般專案性質的軟體開發總是存在一個根本問題：無法達成軟體的大量複製！
專案的規模除非夠 “肥”、專業領域夠 “精”，否則，對開發與客戶端都很難取得實質交易的平衡。我還記得，閱讀 XP (Extreme Programming) 的書籍，Kent beck，軟體業界的大師，所涉及參與的專案，諸如航空班機的控管系統，開發預算都是高達數千萬、數億美金以上，開發的週期要高達好幾年以上 …。我覺得，若要開發專案，作這種才有機會有實質的回饋、人生也會活得比較有成就感吧？
ERP 系統可否大量複製呢？ 嗯，我們在世貿軟體展，可以看到國內許多的軟體廠商展出 ERP 系統的產品，可真便宜，數千至數萬就可以買到了。站在該軟體廠商的角度，活用軟體的大量複製，方向是對的，如此才有可能將成本壓低，才能服務眾多需要的客戶，售價自然也就可以大幅降低了。只可惜，這些 ERP 系統實在不能稱為產品(Product)，最多最多，只能稱為套件(Package)而已。
套件與產品如何區別？ 每一次我到軟體展時，遇到漂亮的展售小姐解說 ERP 功能時，我只會問一個問題：可不可以將 SQL Server 換成 MySQL？ 幾乎一致的回答是不行。我還只是問實體平台的變更而已喔，還沒有問到，若我要求某一個 ERP 系統所沒有的功能或需要變更業務流程時，該如何客製化(Customize)呢？這問題我連問根本也不想問，因為可想而知，作不到！
套件的特性是，它提供了預先定義好的功能(pre-defined)給客戶，然後利用 “參數(parameters)”，讓客戶來自行 “微調” 系統功能；若是客戶單位要求的是套件沒有的功能、企業規則或企業流程的話，當然就要找原開發廠商，然後回到 “專案” 的型態來開發新的功能。
專案要作的是滿足客戶的需求，但期望客戶的需求變動不要太頻繁；套件則是提供預先定義好的需求給客戶，但其假設點是客戶的要求不多、規模不大(這也就是國內的 ERP 廠商的客戶鎖定在中小企業的原因)。兩者的根本問題是：彈性度不足，無法提供 Enterprise 層級的資訊系統，有效的客製化與變動性管理！
那麼，該具備什麼樣的特性才 “夠格” 稱之為 “產品(Product)” 呢？ 答案就是理出專案與套件的共同問題：讓系統更有彈性！
為什麼客戶端需要更換資料庫系統與應用伺服平台？ 因為成本、效能、穩定性等考量。
為什麼客戶端需要客製化？ 因為需求就是一直持續性地變動。
即使有領域專家的協助、即使有超炫的使用者介面、即使提供的是更棒更完善的功能，這些仍是沒有用的，因為，客戶永遠都會有第 101 個意想不到的需求！
既然如此，就乾脆讓客戶端可以自行開發他們的需求，未嘗不可！ 學學 MS 的 .NET Framework、Java 陣營的 J2EE Framework，以上兩者提供的是作業系統層級的框架(System-level frameworks)，而開發如 ERP 產品，就是提供企業層級的框架(Business-level frameworks)，讓開發者視需求的變動與要求，而在既有的基礎建設(Infrastructure)上，加工快速建置新的功能。
企業層級的 Framework，除了提供共用的資料庫、共用的企業流程，還要能提供白箱的 Open-APIs 與原始碼，以及黑箱的 “企業元件(Business Components)”，來供其客製化客戶單位的功能。難不難？ 非常地困難！ Business Framework 的設計與開發，需要能結合領域專家、軟體專家、與平台面的 IT 專家，共同合力協助，才有可能完成的。這也是為什麼國外頂級的 PDM((Product Data Management)產品與國內某些軟體公司所開發號稱的 PDM 產品，價格為何能差到數百萬元之多吧。
對了，Open-source 的許多企業層級的專案，可否稱之為產品？ 個人是不以為然，還是無法到這樣的層次。但，Open-source 卻靠兩種方式，來達成如同產品的性質：
- 頻繁的改版。
- 提供原始程式碼(Source-codes)。
這是一種非常有意思與另類的作法，此時，軟體廠商反而不是賣產品，而改以提供 “服務(services)” 的方式來計價收費了。
Hi Patrick:
您所提最後一段所述，正是國內諸多 PM 的走向。 🙂
可以說，從業務的角度看使用者 “要什麼”，這本就是理所當然。但是，兩個潛在的 issue，能不能引導客戶更多的需求、能不能快速順應客戶的需求變動，這正是軟體設計者的核心所在了。
我是從軟體的角度，期能調和業務與技術的 Gap。往往，老闆與PM 正是因為太重視業務與需求，卻看不到軟體的結構根本，走短線的需求導向，卻使得產品(系統)不容易達成上述我所提的兩個潛在 issue。
I think it is depending on what system you are designing for. For example, if you are designing a system for a back office department, you aim may be focus on automation, simplify business process and hence, the reduce business cost. A new system mean to business does not always in “making profit”. Well, in another sense, reduce cost is increasing in profit margin as long as marketing department remain steady sales figure.
From business point of view, a value of PM is to deliver what business really “wanted”. Whether the system is good to use or not, it’s stakeholder’s judgement call.
Hello 曾經是：
感謝您留言的分享，也提供了您的觀點。
個人幾個想法… 我是沒有像您比較悲觀的。當然，大環境似乎不佳，但，好像我也不會想那麼多。
產品 OO 化？ 這個… 我是很懷疑啦，因為呢，好像 OO 與產品或工具實在不會有太大太大的關連，若要論最佳所謂 OO 產品的話，那麼，.NET or Java，絕對是更 OO 了，但，用的人就不是那麼一回事，反而是變成 QOO 啦～
有點不瞭解您所謂 PM 的重要？ 是否是 Sales 的重要還是 PM？ 聽您的敘述，比較像是 Sales 所應具備的能力。
至於彈性… 這，我們是不會向客戶去解釋這種太過虛無飄渺的理想，基本上，我們是覺得從行動中，比較能證明這些的。
亞洲的軟體業環境應該是全球最惡劣的地方.
case多數不大, 小弟所謂不大就是金額不夠大, scope倒是挺大.
在亞洲作product的導入, 能夠損益兩平已經不容易了, 想要真正的賺錢, 以現在的環境來說是非常不容易的.
case能否賺錢在亞洲來說, 往往最終會是取決於PM的能耐, 對於產品架構而言反而次要.
小弟曾經幹過外商PLM顧問, 公司產品非常有彈性, 也有基本的component甚至service可以使用, 非常OO, 不但資料庫都OO, 連開發都OO, 甚至有時候覺得系統太偏OO, 而忽略了其他的view. 但, Kenming所列的product特性與彈性也都是有的.
在亞洲, 尤其是台灣, 往往只能做到損益兩平. 彈性帶來的, 是客戶近乎無理且無限制的要求, 因為沒有做不到的, 而彈性也讓客戶也能夠自己客製化, 但在台灣來說, 願意這樣投資IT部門的公司並不多, 而且往往朝不保夕, 本來維護的人就少, 只要公司營運上一有個風吹草動, 砍人毫不手軟.
產品好, 但PM更重要, 市場上多的是產品比我們差的, 但一樣在賣, 保留客製化彈性或者是以parameter來config產品, 本來就各有市場, 再怎麼樣有彈性的系統, 也一定會有limitation, 以導入的project來說, 都會盡量希望能夠限制客戶在product的框框下走.
PM的功力在此就可以展現.
也不是沒有盡量想要為客戶客製出適合的function, 並兜出好的process, 但在國內, 這樣的project往往因為金額不夠, 不賺錢甚至賠錢, 客戶大多作OEM慣了, cost-down與討價還價本來就是他們的生存法寶, 這時後彈性往往成為專案殺手, 因為辦得到, 客戶也知道我們辦得到, 但就是不給錢, 那還不如一開始就說不行來的好吧.
問題多半不在技術，大部分是在於團隊與管理上沒有應有之修煉…
我並不認同以上的說法，當OO思維愈深入，您愈會發現OO設計的理念與東方的哲學思維是相通的。
把OO看成是技術，當然辛苦；因為技術是死的，肯花錢就絕對買得到，用錢買得到的東西您覺得價值有多少？我寧願把時間放在活化思維上，OO的思維不是單靠花錢就可以得到的，但正因為如此，OO的思維更顯得彌足珍貴。
Hello 疑惑者 您好：
我大概講過不下 100 此以上了，物件導向，並非是從純技術的角度來看待的。 會讓您有如此印象，個人認為是國內業界的一種迷思，把物件導向降至 OOP 層級來看待；又若從所謂 OOA/OOD 角度來看，因無法貼近現實或有所謂效能等問題，就認為物件導向有問題，這些都太過偏頗了。
或者，您也可以將物件導向也當作一種 “手段”，它也只是在實現軟體設計人員的設計思維罷了，所以，重點不在物件導向，而是在軟體設計的整體思考能力的提升。
問題在哪裡？ 環節太多囉，業務導向、重視短線、太偏重 IT 平台技術、很少去思考 … 這些都是問題。
您的問題，我大概都有思考過(但同樣地，我也有很多茫點)，不過並不容易以文字表達，牽涉的環節太多了，您可以透過貴公司單位找我們過去作些說明，面對面，甚至直接面對貴公司的 IT 單位，會清楚很多。
Kenming您好，您在業界推廣物件導向概念多年，也極力推廣UML作為實現此概念的手段，我能認同這樣的概念，但是個人時常苦思一個問題，物件導向的概念是否真的適用於台灣呢?畢竟這個技術是源於歐美，而軟體算是將人類抽象的思維轉換成具像的一種技術，東方人與西方人在思考的邏輯本身就差異很大，因此才有這樣的想法，而且從下面的觀點來看，我依然對這項技術有些疑問
以軟工的技術面來看，物件導向的概念確實能有系統地來描述一個複雜系統，幫助軟體系統開發人員能從巨觀的角度來看待一個系統，而這樣的一個系統也確實可以做到，系統有”彈性”，可以以”不變”應”萬變”，個人可以深切體會這概念在技術面中所帶來的好處
以企業經營或是行銷的角度來看，私人的公司存在的價值就是獲利，公司必須要有獲利的利基點才能在競爭的環境下存在，但是對於軟體公司的客戶來說，他的需求只有一個，只要系統可以運作，就算是完成專案，他並不會理會，軟體架構的好壞，也因此很多業務掛帥的小型工作室(10人以下)，完全以所謂瀑布型開發手法，二層式架構來開發系統，反而這類的公司有辦法賺些蠅頭小利，而一些較具規模的大公司，用了很多軟工的概念，花了很多時間規劃出漂亮的架構，但是始終不能有好的獲利空間，也因為看不到那盞獲利的曙光，企業主也裹足不前，不敢大手筆的投資
以結果論來看，多年來台灣的軟體業界始終無法有像台灣半導體工業一般的表現，工程師超時工作，流動率很高，公司為節省人力成本，開始西進外移，但是卻不能跟半導體產業一樣擁有傲人的成就，而軟體產業也苦苦吶喊，為何徵不到好人才
綜合以上看來，物件導向的概念，除了在技術面能符合這個技術所提出的院景外，在其他方面似乎都與願景背道而馳，是否這樣的概念並不適用於台灣呢? 問題出在哪邊呢?
系統維護費的確是最好賺的，不過IBM等公司也賣顧問的，當然顧問是以該公司的產品為主，不過如果對方的公司太大，有要求要用特定的軟硬體，也會配合的。
而且，顧問服務賺的很多僅次於系統維護費。
456指的應該是管理顧問公司吧，例如勤業或生產力中心之類的公司。以資訊產業的特性，及台灣的公司不尊重智慧財產的心態，提供單純人力資源的服務的公司似乎不多。
以IBM及HP而言，雖然每個專案會以技術人員或專案經理，以所謂系統整合或企業改造的名義進入，但是在提供解決方案上，都是以自家的產品為主，這些可能是伺服器，可能是作業平台，可能是合作廠商的軟體。賣人是第一步，賣設備軟體才是重要的第二步。要不然，如何經由系統的「綁標」去賺後續更好賺的「系統維護費」？
456應該是很可愛的社會新鮮人吧。
Hi 456:
怪怪的，賣人力駐廠似乎不能成為 Business Model ? 我也不知道～ ~^^
我們是顧問團隊，的確是要走另外的路，但應該也不太算是賣人力？
其實還有一種 P — 雖然，比較少公司是這種型態。就是『賣人』（People）的顧問啦！克明兄不就是如此型態的小而美軟體公司嗎？其它像是 HP、IBM、Microsoft、Sun…等，也都兼做一些出人力賺顧問費的方式。