今天在某罈子裡看到有某位做it經理的兄弟發貼，問：「各位有沒有打官司的經驗？我們公司上了賊船了，買了一套erp的軟體，軟體**商之前說的n漂亮，說他們的系統是個優秀的平台，可以根據我們公司的業務進行靈活定製開發，滿足我們公司的個性化業務需求。可是專案做到現在，已經嚴重超期了，已經影響到我們公司的業務了，現在我不想跟他們玩了，想想看怎麼能告他們呢。現在他們以為我們上了賊船，就沒有辦法治他們了，一拖再拖，再也不忍了。」
看到這裡，想來又是erp專案過度開發惹的禍。這個專案如此看下去，估計也是凶多吉少了，但這個軟體開發商是否會找這個客戶一起「沉船陪葬」呢？照此情形來看，這是大有可能的。畢竟現在有許多的軟體廠商，其實自己根本沒有一套成形的軟體產品， 就只是乙個能夠拿出來忽悠的demo原型，就敢說自己掌握了高階技術，開發了乙個靈活可架構的erp平台，可以根據客戶的需要進行靈活配置，滿足客戶的個性化需求，並可以實現專案實施的低價、短週期，總之，專案管理因素中各個要互：質量、成本、進度、範圍都被他們給忽悠全了，無所不能。
真是這樣的嗎？其實仔細一分析，這就是乙個大忽悠了，成熟erp平台的構建比乙個成熟的erp產品難度要大的多，可以說國內還沒有幾家能夠有乙個成熟的erp平台出現，即便有的話，也還是基於自己的軟體產品來構建的，基本上不會開放給客戶進行開發。放眼世界上，倒是有成功的例子，但也得看看，那是誰呀？sap是個例子，ibm也算是，都是行業內的巨人。再想想他們的平台的複雜性，複雜到乙個高階顧問能說精通的就只是乙個模組而已。來到我們的國內的這些廠商，卻將自己的平台包裝的無所不能了。
再說說如果有相對成熟的軟體產品，如果面對了大量的二次開發，這還能叫產品嗎？試想一下，你建好了乙個大樓之後，你卻說我想把大樓的造型再改改，看看是不是動動框架，把樓的造型再拉的漂亮點？你肯定說人家「腦子進水了」，可是在erp領域，卻是有很多需求基本上是要求顛覆erp框架與模型的開發，我們的一些軟體廠商卻是點頭說是：ok，沒問題，我們改！結果改來改去，功能是不是實現倒不說，客戶發現系統越改，問題越多，原來好好的功能也用不了了，而自己想要的功能卻一直沒有見到。這個時候再扯皮，就扯成了如何處理這些問題上來了，大家對於最早提的需求是什麼，想達到什麼目的已經不關心了。這種專案的實施，也是離大限不遠了，如果大家這種合作的關係破裂了之後，自然就要法庭上見了。
所以，不只只是對客戶來說，過度的二次開發，等於是上了軟體廠商的「賊船」，其實軟體廠商也是一樣，如果用乙個成熟的產品再去做顛覆性的開發，最終的結果就只是導致與客戶「同歸於盡」的下場。所以，從這個角度來說，不妨在專案的前期跟客戶說清楚，哪些能做，哪些不能做；哪些可以開發，哪些不能做開發。有所為，有所不為。這才是一家健康的erp軟體企業的生存之道！
ERP專案教訓
上年底接到乙個小公司的企業管理軟體專案，在做的過程中產生了種種的問題。1.輕視了erp軟體的製作，在缺乏財務知識的情況下，接下了這個需要很多財務知識的專案，導致在做需求分析時出現了一些預料之外的困難，最後做出的需求分析也不專業。這也帶出了乙個問題，計算機要應用到其它行業時，程式設計師並不熟悉相關行業...
ERP專案管理
erp二次開發專案 img 我們的客戶每一家都不一樣，都有各自的特點，如果遇到有專業it部還好些，如果沒有那麼效果會差些。有專業it部，客戶就會知道標準軟體開發的具體過程，初步知道個難易程度，會為開發人員著想。沒有專業it部的客戶，只有不停的讓你趕進度，他看具體結果，管你用啥方式方法。一般的erp專...
小型ERP開發
做了幾個小型erp系統，雖然已經被幾十家小型企業所用，但自我感覺仍然很差。所以決計把原有系統遷到mysql apache python django 的同時重新設計。這篇文章就當是記錄設計思路的點滴吧。一 概要 基於web的小型erp系統，支援多公司運營。二 軟體使用者 1 系統管理員，管理n個公司...