本來我已經不想寫這些文章了，因為這些文章我已經在過去的十多年裡寫了n多，都是老生常談的問題和答案，但是總有一代一代的人掉坑里，連一點長進也沒有，連一點傳承也沒有。正好今早有人討論這些問題，我也多嘴了幾句，所以把這些多嘴再放上來。
一、企業應用軟體分類
我們是做企業應用類軟體的，在我們角度來看，我們把企業應用類軟體分為四類：
1、業務操作類：如收銀/支付/結算收費/核算、倉儲物流配送客服。這些工具都是為了高效準確的完成手頭的業務
2、mis類：就是資訊記錄下來，為了方便事後追溯查詢或者匯**計
3、管理類：這類軟體一般是以pdca為主線，計畫牽頭，審批在中間，注重把多部門串聯在一起
4、分析類
大家往往喜歡把企業應用類軟體一股腦都叫做erp軟體，什麼需求都往裡放，這往往會出現一些常見問題：如定製難度大，如架構不支撐，如效能不佳。就是因為乙個軟體種類都有它的特性優缺點，你非要拿乙個東西做所有東西，當然不倫不類了。很多企業cio、很多小軟體公司，並未弄清楚這是根源。所以我一開頭就把這個小分類先擺上。
二、所謂的實施失敗
這些問題都是我們十多年掰飭了n多次得出來的，大家不用再每次掰飭了。世界上本就有路，是你見識少所以以為沒有路。
實施失敗，一般三個常見現象：
1、由於重大分歧而終止專案。這個發生可能性小，軟體企業都是為了賺錢，不會輕易堅持什麼原則，能做的基本都答應了。一般重大分歧大多是籤了單以後方向360大調整，專案不划算了。為啥會方向360度大調整，一般常見的根源就是：上頭換人了。就這麼簡單而可笑，但別笑，這就是常見原因。
2、上線了，但過了一段時間後，用的人越來越少，用的模組越來越少，錄入的資料越來越少。一般都是it部門、業務部門、高管和老闆，都對資訊化報無所謂態度，業務部門也不推著用，老闆也強要求著用，it部門也不著急。有人說，那買軟體當初是為啥。唉，老闆也是人啊，他只不過是創業了，你沒創業，就這點區別。人就有七情六慾，買軟體和買其他東西都是一樣的。企業是由七情六慾的人組成的，你指望它客觀理性？
3、使用了，但立項前討論的目標問題並未解決。這一般是立項時的目標問題就不清晰。我們經常會看到立項目標呈現兩極分化，一級是太高，什麼用it資訊化提高企業管理水平、提高效率、提高質量這類大空話，一級就是太低，都是很具體的點上的小需求。
你還見過哪些常見的企業應用軟體實施失敗的現象呢？
何為erp實施失敗呢？
三、我們到底在定製什麼
企業應用軟體定製多，這是業界常態。但仔細掰開揉碎，就那麼幾類：
1、報表類：增加或修改各種查詢清單格式、統計報表
2、整合類：需要和企業現有上線使用的各類應用打通介面呼叫或資料。中國很多地方上的民營企業一開始購買的是本地小it公司開發的小軟體，都沒啥標準或api，現在要整合，就生生接唄
3、流程類：一種是複雜配置，另一種就是複雜配置都配置不來了，流程太奇葩了，需要定製開發了。為啥流程太奇葩？因為在中國，人情和山頭大於制度，我是老臣我是權臣，我就這樣辦。企業老闆創始人也是投鼠忌器，到處平衡企業內部勢力，小車不倒儘管推
4、資料類：過去系統的資料匯入、補全、校驗、修正。異常資料的檢查、修補。這是最耗時間的
5、遷移類：系統拆分、合併。這不亞於把血管先斷開再接上的複雜
我們的定製開發需求時長就主要消耗在這些地方了
四、需求定製是怎麼回事
我們再來看看定製需求一般怎麼發生，我們常見的發生週期是：
1、上線前。因為軟體沒有人使用，只是在it部門部署好，it部門的人內測，也邀請一些業務部門骨幹錄入一些資料，證明業務過程能跑通，資料能對得上。在這個內測過程中，每個人都會提出一些需求。這還是非常好非常務實的需求。
最爛的上線前需求是，企業it部門要求企業實施軟體人員給業務部門對著軟體講操作講業務流程，邊講，底下人你一嘴我一嘴隨便提問提需求，你都得記下來，然後企業it部門往往會派乙個忠心耿耿、pdca特別緊的小姑娘跟進，讓你必須承諾兌現修改。
2、上線後。一上線一使用，發現過去搞了那麼多需求和定製，都是一小撮人意淫，真正的一線操作人員的操作需求根本沒注意到，這時一操作發現問題了。趕快改吧。說明啥，說明上線前的需求和定製都白費了，都意淫了。我們總是在實施前就和客戶說起這個常見現象，但大多數客戶還是掉進這個坑。人啊，控制欲太強，這是根源
3、驗收前。聽說我們試點實施完了、要驗收了、要撤場了。企業it部門著急了，怕軟體公司一旦撤場了自己背鍋，所以要把能想到的問題都徹底解決了。所以又會有一大波需求襲來。
五、所謂需求
我是理想派中的務實派，也是務實派中的理想派。
我既研究管理，又作為高管在實踐管理，又設計管理軟體，又帶領團隊實現管理軟體，還力求用管理軟體來管理自己的團隊，這些我都經歷過。
我也待過官辦國企、創業型民企、成長型民企、大型民企，我既擔任過小兵，也擔任過中間層，也擔任過高管cxo，也親自和老闆一同創過業打過江山，背過銷售業績，也頭疼過給員工發工資斷糧的問題。
對於我這樣既做過網際網路電子商務，又算創過業，又做過企業應用，管理上做到cxo，技術深度上做到cto的人來說，對需求的理解，一般都回歸樸實了。
我個人觀點，大部分企業的問題，都是可解決可不解決的。解決了，企業也不會明顯增加收入，不解決，企業也不會明顯減少收入。
我也親身經歷了，管理好，企業也沒有業績一飛沖天，後來行業遇到低谷了，企業正好也內憂外患時，管理的再好，發現也出了許多么蛾子事件，企業並沒有因為過去管理精細井井有條而保底。這就是現實。所以別太迷信管理。
有限的精力多去掙掙錢，增值永遠比在內部折騰內部人有價值的多。
有問題解決問題，小車不倒儘管推。心態穩，永續性強，別認為這事不幹就會死。企業離了老闆都不會死（我正好經歷過這檔子事），何況這些毛毛雨。
一切都是手段，不要太意味想到用軟體解決問題，別鑽牛角尖，手段可以百無禁忌守正出奇，目的最重要，目的最重要。賺錢就是目的，所有的企業都繞不開這個問題，最終還是會回到這個原點。
簡化erp，先簡化思維。複雜問題簡單化，才是好帶頭人。
（我是不是管理軟體的克星？做管理軟體的一幫老朋友會不會恨死我？嘿嘿嘿。我早就告訴你們了，要切交易、要切交易、要關注產業鏈、要關注產業鏈）
關於管理軟體市場的再論一
一 管理軟體的研發週期與市場週期相對較長 這是與網際網路產品相比而言。1 研發週期取決於獲得使用者真正需求的速度，網際網路產品的特徵決定了其產品迭代週期非常短，甚至是以小時論，管理軟體的產品應用，其週期至少是幾個月，產品迭代也應以月為單位，更多是以年為單位，v1.0 v2.0.v10等等，諸如此類，...
我的CVS配置管理軟體
cvs 由於都是windows開發，所以採用cvsnt和tcvs或者wincvs，不過感覺tcvs更加方便。試驗過vss，不過我覺得它的目錄很亂，不像cvs一樣有條理，想刪除之類的都比較方便。更改配置也方便。而且還要先訪問遠端的ini檔案。subv，據說比cvs更好，不過我安裝之後，發現使用實在比較...
說給做管理軟體的同行 學會職業規劃
今年以來,一直都比較少與人交流了.以前做顧問哪會兒,因為走動的關係,交流還是比較多.可能身在企業裡了,不一樣了.最近出去bbs和qq群轉轉,發現挺多人對從事管理軟體工作這個職業還是比較迷茫的.尤其是一些剛做管理軟體時間不是太長的人.其實,做管理軟體即所謂的顧問 consultant 還真的跟其它的職...