關於EOM(Enterprise operating model)企業經營模型(2)
阿新 • • 發佈：2019-02-13
上一章講述了企業資訊系統的建設現狀，以及這種以企業需求來驅動，由軟體公司來開發的企業資訊系統建設模式，帶來給企業和軟體公司的問題，這些問題影響了我國軟體業的發展。
我們面對這些問題，如何去分析去解決，關鍵是我們站在什麼角度，看待這個問題。
如果我們站在程式設計師角度，我們根本看不到問題所在，或者說沒有問題存在，因為程式設計師是按照設計方案通過程式設計方法實現某一功能的解決。而這些功能設計是否合理，程式設計師並不關係。程式設計師只關心能不能把程式給編出來，編出來就是沒有問題，編不出來是才可能有問題，而這個問題只是在程式層面的。
如果我們站在專案設計者角度上，同樣我們也看不清問題。因為專案設計者只對專案需求負責，他對系統的評判標準很簡單，如果專案設計滿足了專案需求的要求，這個專案就是OK，如果不能滿足，則存在問題。而這個問題則可以通過設計來解決的。雖然有些高階專案設計師，根據自己的經驗和積累，將其他專案中優秀的設計理念和方法放到本專案設計當中，但是，一個專案優秀改變不了其他眾多專案水平平平的狀況。因為個人的能力始終是有限的。更重要的是專案設計者很難跨越需求方的要求，唯需求為是，已從根本上註定了專案設計者的侷限。
如果我們站在專案需求提出者角度，同樣我們也看不到問題的所在，因為企業的業務需求的提出，反映了業務需求的迫切性，只要能把業務需求提出來，讓開發者完成開發，這個需求就完成了。至於這個需求是否是最合理的，是否代表業界最高業務境界，是否符合企業資訊建設的整體發展，是否能被企業內部更多的使用者共享，需求方是從不考慮的。因為企業的需求方往往是由具體業務部門產生的，從各部門各地區集中需求，由企業專門部門提出需求，這種情況很少。所以需求的水平決定了系統的水平。而在中國，需求的提出往往和他們的經營方式密切相關的，大都是一些面向市場的應急的需求。這些需求，不確定因素很大，時間要求比較急，造成了需求反覆變更，開發急急匆匆，這樣的結果肯定是不會好的。
如果我們不站在以上的角度，那我們還能站在什麼角度？我們能不能站在一個企業全域性的高度來看待企業資訊建設存在問題呢？答案是可以的，許多人正是站在這個角度上，發現企業（尤其是大型企業）在企業資訊建設上，存在著各種問題。例如，資訊建設無序、需求永遠無法滿足、系統越建越多、資訊不能共享、功能交叉、維護成本越來越高、業務主導科技（科技的作用僅限於實現業務需求）等等。而面對這些問題，人們只能望問題興嘆。但是我們要說的，站在一個企業角度，即使是全域性角度他也是短視的。因為他的視野範圍僅限於這個企業。
我們能不能站在一個行業角度上，來看待行業內部各個企業的資訊建設呢？答案也是可以的。在這個層面上，許多人都在提出，為什麼A企業開發了一個系統，B也要開發?為什麼A、B甚至C、乃至全行業的企業都使用統一的系統呢？很快他們得到一個理直氣壯的回答：不行！因為每個企業都是不一樣的，所以系統就一定不樣。我們這裡先不對這個回答給與評判。我們很高興得看到，站在這個角度上，有人看到了問題所在，那就是重複開發！尤其是軟體公司看到了這一點，他們特別希望他們的軟體能夠產品化，將產品銷售到行業內每個企業。但是，軟體產品化舉步維艱，許多人都說願望是好的，做起來很難很難。我們要說的是，站在這個角度視野仍然不夠開闊，仍然關注於一個系統的產品化和共享。
那我們能不能佔在跨行業的角度上來看待這些問題？有人一聽便會說，站那麼高幹嗎？下面的問題都還沒解決呢！空談！對此，我們先不與解釋。我們只想說，站在這個角度，我們能更能看到問題的所在，我們不僅僅看到的是一個企業內部、一個行業內部問題，我們更能看到全國性的問題，也就是說，不同的行業的企業資訊建設水平極不平衡，系統差異化極大，行業之間的系統共享為零、行業之間的資訊交流幾乎是空白，等等等等。所有問題都浮現出來了，這樣我們可以把所有的問題放到一個手術檯上，進行徹底的解剖，看看病因究竟在什麼地方。而這種解剖一定是在理論層面上的，因為只有理論才能抽象於各種實際，才能應用於實際。
我們面對這些問題，如何去分析去解決，關鍵是我們站在什麼角度，看待這個問題。
如果我們站在程式設計師角度，我們根本看不到問題所在，或者說沒有問題存在，因為程式設計師是按照設計方案通過程式設計方法實現某一功能的解決。而這些功能設計是否合理，程式設計師並不關係。程式設計師只關心能不能把程式給編出來，編出來就是沒有問題，編不出來是才可能有問題，而這個問題只是在程式層面的。
如果我們站在專案設計者角度上，同樣我們也看不清問題。因為專案設計者只對專案需求負責，他對系統的評判標準很簡單，如果專案設計滿足了專案需求的要求，這個專案就是OK，如果不能滿足，則存在問題。而這個問題則可以通過設計來解決的。雖然有些高階專案設計師，根據自己的經驗和積累，將其他專案中優秀的設計理念和方法放到本專案設計當中，但是，一個專案優秀改變不了其他眾多專案水平平平的狀況。因為個人的能力始終是有限的。更重要的是專案設計者很難跨越需求方的要求，唯需求為是，已從根本上註定了專案設計者的侷限。
如果我們站在專案需求提出者角度，同樣我們也看不到問題的所在，因為企業的業務需求的提出，反映了業務需求的迫切性，只要能把業務需求提出來，讓開發者完成開發，這個需求就完成了。至於這個需求是否是最合理的，是否代表業界最高業務境界，是否符合企業資訊建設的整體發展，是否能被企業內部更多的使用者共享，需求方是從不考慮的。因為企業的需求方往往是由具體業務部門產生的，從各部門各地區集中需求，由企業專門部門提出需求，這種情況很少。所以需求的水平決定了系統的水平。而在中國，需求的提出往往和他們的經營方式密切相關的，大都是一些面向市場的應急的需求。這些需求，不確定因素很大，時間要求比較急，造成了需求反覆變更，開發急急匆匆，這樣的結果肯定是不會好的。
如果我們不站在以上的角度，那我們還能站在什麼角度？我們能不能站在一個企業全域性的高度來看待企業資訊建設存在問題呢？答案是可以的，許多人正是站在這個角度上，發現企業（尤其是大型企業）在企業資訊建設上，存在著各種問題。例如，資訊建設無序、需求永遠無法滿足、系統越建越多、資訊不能共享、功能交叉、維護成本越來越高、業務主導科技（科技的作用僅限於實現業務需求）等等。而面對這些問題，人們只能望問題興嘆。但是我們要說的，站在一個企業角度，即使是全域性角度他也是短視的。因為他的視野範圍僅限於這個企業。
我們能不能站在一個行業角度上，來看待行業內部各個企業的資訊建設呢？答案也是可以的。在這個層面上，許多人都在提出，為什麼A企業開發了一個系統，B也要開發?為什麼A、B甚至C、乃至全行業的企業都使用統一的系統呢？很快他們得到一個理直氣壯的回答：不行！因為每個企業都是不一樣的，所以系統就一定不樣。我們這裡先不對這個回答給與評判。我們很高興得看到，站在這個角度上，有人看到了問題所在，那就是重複開發！尤其是軟體公司看到了這一點，他們特別希望他們的軟體能夠產品化，將產品銷售到行業內每個企業。但是，軟體產品化舉步維艱，許多人都說願望是好的，做起來很難很難。我們要說的是，站在這個角度視野仍然不夠開闊，仍然關注於一個系統的產品化和共享。
那我們能不能佔在跨行業的角度上來看待這些問題？有人一聽便會說，站那麼高幹嗎？下面的問題都還沒解決呢！空談！對此，我們先不與解釋。我們只想說，站在這個角度，我們能更能看到問題的所在，我們不僅僅看到的是一個企業內部、一個行業內部問題，我們更能看到全國性的問題，也就是說，不同的行業的企業資訊建設水平極不平衡，系統差異化極大，行業之間的系統共享為零、行業之間的資訊交流幾乎是空白，等等等等。所有問題都浮現出來了，這樣我們可以把所有的問題放到一個手術檯上，進行徹底的解剖，看看病因究竟在什麼地方。而這種解剖一定是在理論層面上的，因為只有理論才能抽象於各種實際，才能應用於實際。