討論區快速選單
知識庫快速選單
軟體開發過程中有哪些資安漏洞? 網路投保旅行平安險 網路投保旅行平安險
[ 回上頁 ] [ 討論區發言規則 ]
ERP 軟體產業似乎來到寒冬季節
更改我的閱讀文章字型大小
作者 : mydick(ㄉ一ˊㄎㄜˋ) SQL Language優秀好手貼文超過200則
[ 貼文 223 | 人氣 6296 | 評價 2890 | 評價/貼文 12.96 | 送出評價 34 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/10/6 下午 01:59:01
最近陸續聽到之前服務公司的情況, 感覺ERP 軟體產業似乎來到寒冬季節:
1. 產品換版頻率頗高, 且會衍生其他問題, 業務人員必須花費大量時間處理客戶抱怨!
2. 研發主管及主要程式師至客戶處道歉!
3. 軟體銷售先提供數個月導入試用期, 試用滿意後再收數個月的支票!
4. 產品預測銷售金額僅微幅調整(投入研發兩三年且已行銷一年的產品在明年僅預計幾十套), 逐年延後目標市場!
5. 全公司主管減薪, 研發部門裁員!
6. 主要競爭對手狀況也不盡理想, 市場仍處於不景氣!
除了市場景氣的問題外, 我認為產品品質是造成這些問題的主要因素!

軟體公司的根在於品質良好的產品, 品質要良好則需要建立並落實軟體工程的觀念, 讓軟體開發能像工業產品一樣,
在每個可預期且控制的步驟下用一致的方式產出, 這樣才能在微利時代避免陷入高成本低收益的營運風險!

因為不重視軟體工程, 缺乏品質觀念, 造成資源的浪費, 且產品無法有效獲利, 眼看著微利被奈米化, 不知舊同事如何調整心態去適應, 而當初購買的股票也不知何日得以翻身!
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/10/8 下午 06:55:00
ERP最大的問題在於系統能否及時反應客戶的業務需求,有效提高ERP使用者的企業競爭力。之前,很多ERP業者很得意他們的套裝ERP賣得不錯,但是套裝ERP能涵蓋一切嗎?套裝ERP能與業主的企業活動完全契合嗎?不必多久客戶就會發現他們被騙了,結果很多ERP廠商都收不到尾款,客戶的要求已經到了無法以修改程式來因應的地步,很多ERP本身的結構也不能被大幅修改,所以ERP的大夢就此結束。
好在敝人公司的ERP系統是反其道而行,以快速量身訂做,合宜系統分析,快速反應客戶需求為系統開發工具設計理念,客戶只要同意我們的ERP本質是永續服務,我們的系統永遠是變形蟲,客戶無法挑大毛病,又用得不錯,大概我們的出頭天快到了!
作者 : whisper(whisper)
[ 貼文 6 | 人氣 418 | 評價 20 | 評價/貼文 3.33 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/10/13 下午 10:06:10
是ㄚ..只是不曉得在你手下作事的程式員有多倒楣..每天所面對的都是前人留下來的爛攤子..
如果願意的話..可否說說貴公司的ERP產品是那套..我玩過Oracle ERP..我都不覺得Oracle ERP有比你的產品彈性ㄟ..
作者 : whisper(whisper)
[ 貼文 6 | 人氣 418 | 評價 20 | 評價/貼文 3.33 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/10/20 上午 12:06:34
->在沒加入我們公司團隊之前,我也接觸過很多ERP系統(SAP, Oracle,鼎新)
嗯..對於此句話,我覺得我們之間的見解有所不同,我說過
->我玩過Oracle ERP
代表的是我曾參與過Oracle ERP系統導入與客製化專案服務(SA,SD,Coding)..So..我說我玩過
Oracle ERP,也看得出來這不是一個人玩得起的..畢竟這是國外廠商集多少人才的心血結晶..

不知你所說的
-> 接觸過很多ERP系統(SAP, Oracle,鼎新)...
代表的意義為何?
 

作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/10/20 下午 03:21:31

>不知你所說的
>-> 接觸過很多ERP系統(SAP, Oracle,鼎新)...
>代表的意義為何?
以前我服務的公司是一家如聯合國般的業務代理公司,每一家我們代理的廠商會有他們的ERP系統進駐,經常有機會看到他們的員工操作相關的ERP系統,其中以SAP為主,也有BAAN,我是公司資訊專案主管,難免會與代理廠商的MIS人員交涉,談網路規劃與資源合用的問題,所以也曾經到過歐洲與相關人員一起講習SAP。最後因為反對公司導入我認為不合用的ERP系統而離開,至於鼎新的系統則是評估公司ERP系統時,曾與鼎新接觸過一陣子。
好在離開原先的公司;否則我不會有機會接觸到現在的伙伴團隊,讓我大開眼界,重拾信心。


>
>
>
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/28 下午 08:53:46
跟一家對電腦沒有sense,然後又覺得電腦萬能的客戶
真的能夠[滿足]對方的需求嗎?
=====================
這種客戶只有比爾蓋茲才有辦法服務,還是打退堂鼓吧!


所以小弟想看看您的[成功案例],方便透漏嗎?
mail給我也行喔....
================================
我們是小公司,錢賺得不多,但是不會賺得很辛苦,
「成功案例」的定義是什麼?
例如:連續每月付我們五萬元長達八年,從幾人的小公司做到要上市,
目前還繼續與我們簽約改每月八萬元(從COBOL換Windows 版),算不算是?
我們每週拜訪這客戶半天,大家都Happy。

套裝ERP,賣了就要跑,沒法長久,不只是冬天要來,恐怕是冰河時代降臨。








作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/28 下午 10:03:17
有考慮開闢一系列主題談軟體工程嗎? 相信很多高手都翹首以待,畢竟成功模式難尋!
==================
抱歉!個人並非系統的原創者,雖然日積月累,從團隊中多少吸收了這個系統的一些軟體工程理念,如無公司許可,仍不便將很多技術細節公開。

只能說這個系統的觀念也不是一成不變,比如說第一代用COBOL,
第二代用 Delphi ,第三代 目前是先用 Java ,但可能也把 C# 併入

其中有很多經驗的累積,也有苦工。但是以工程方式確保軟體品質,我們算是小有成就。
我們的應用程式幾乎不Debug,運作平台穩若磐石。

所以,很特別的,我們公司同仁可以同時維護COBOL與 Delphi 的版本,駕輕就熟。
未來的Java/C# 版本可以與 Delphi 的共存 是我們努力的目標。目前看來蠻樂觀的。
作者 : bjc4100(林口之虎) 人氣指數超過10000點
[ 貼文 141 | 人氣 18695 | 評價 450 | 評價/貼文 3.19 | 送出評價 22 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/29 上午 12:52:54
在技術資料方面不便透漏,這是人之常情,
不過對於您這麼優秀的團隊,希望能有幸得知貴公司的寶號,
如果哪一天我們的客戶或朋友有 ERP 的需求,而我們又吃不下來的時候,
就交給貴公司處理,做的好的話你們賺錢、我們臉上也多少沾一點光啊!
作者 : jawa560(Snaking) Java Script優秀好手貼文超過1000則人氣指數超過30000點
[ 貼文 1154 | 人氣 32593 | 評價 4630 | 評價/貼文 4.01 | 送出評價 168 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/29 上午 01:55:22
那∼那∼不如 steve兄跟你們公司大大說,『好多人都好崇拜您喔,要不要考慮開個座談會,以彰顯武林至尊的風采呢?』 ^^ (癡人妄想中) :D
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/29 上午 08:44:16
在技術資料方面不便透漏,這是人之常情,
不過對於您這麼優秀的團隊,希望能有幸得知貴公司的寶號,
如果哪一天我們的客戶或朋友有 ERP 的需求,而我們又吃不下來的時候,
就交給貴公司處理,做的好的話你們賺錢、我們臉上也多少沾一點光啊!
==============================================
基於對本網站的尊重,我們不考慮在此公布我們公司的網址。以免落入
打廣告之嫌。而且我們的網站內容也不怎樣好看。想要看我們簡介資料的朋友,可以留下e-mail
我們寄給你。至於熱心幫我們推薦客戶的朋友,我們自然不會也不敢讓他丟臉。




那∼那∼不如 steve兄跟你們公司大大說,『好多人都好崇拜您喔,要不要考慮開個座談會,以彰顯武林至尊的風采呢?』 ^^ (癡人妄想中) :D
============================================
是的,我們都很佩服他,因為他的軟體工程規劃的如此好,才會讓我們的系統有生命
能永續運作,永續改善。
公司上下大家都有角色扮演,在不同系統層級安排下,各人寫各人部分的程式,
一合起來,一定Work。不會互相指責,忙著debug

我們規劃的Java版底層,在經歷近兩年的構思,目前結構大致清楚了,等到
應用層也起來後,經過客戶驗證,開座談會的時機就會成熟,所以不是不可能。





作者 : darkdummy2003(darkdummy2003)
[ 貼文 24 | 人氣 805 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/29 上午 09:04:00

>跟一家對電腦沒有sense,然後又覺得電腦萬能的客戶
>真的能夠[滿足]對方的需求嗎?
>=====================
>這種客戶只有比爾蓋茲才有辦法服務,還是打退堂鼓吧!
^^^^
客戶真的能選擇嗎?
能只選擇好做的客戶嗎?
跟您簽約的是主管,也許主管好搞
但是有些公司裡面的使用者會搞死妳
你搞的過那些使用者嗎?有些已經成精了ㄟ......

想問你的成功案例,是想知道究竟是哪幾家
要打廣告也請給點資訊來證明吧!!
如果真如您所講的那樣,小弟可以為自己不當的言行道歉


>所以小弟想看看您的[成功案例],方便透漏嗎?
>mail給我也行喔....
>================================
>我們是小公司,錢賺得不多,但是不會賺得很辛苦,
>「成功案例」的定義是什麼?
>例如:連續每月付我們五萬元長達八年,從幾人的小公司做到要上市,
>目前還繼續與我們簽約改每月八萬元(從COBOL換Windows 版),算不算是?
>我們每週拜訪這客戶半天,大家都Happy。
^^^
所謂成功案例。就是系統做完後沒有被冰到該家公司的櫥櫃。
這樣的定義夠直接吧,沒有曖昧的空間...
長時間的working,我們也有成功案例,合約結案後繼續
跟我們簽訂維護合約5年(沒你們的8年強),其中當然也有update,
不過需另行計價

>套裝ERP,賣了就要跑,沒法長久,不只是冬天要來,恐怕是冰河時代降臨。
^^^
敝公司套裝和專案各有Team負責
兩種都有做
各有利弊
套裝真的完全不好嗎?未必?
看需求,看規模

作者 : darkdummy2003(darkdummy2003)
[ 貼文 24 | 人氣 805 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/29 上午 09:04:27

>跟一家對電腦沒有sense,然後又覺得電腦萬能的客戶
>真的能夠[滿足]對方的需求嗎?
>=====================
>這種客戶只有比爾蓋茲才有辦法服務,還是打退堂鼓吧!
^^^^
客戶真的能選擇嗎?
能只選擇好做的客戶嗎?
跟您簽約的是主管,也許主管好搞
但是有些公司裡面的使用者會搞死妳
你搞的過那些使用者嗎?有些已經成精了ㄟ......

想問你的成功案例,是想知道究竟是哪幾家
要打廣告也請給點資訊來證明吧!!
如果真如您所講的那樣,小弟可以為自己不當的言行道歉


>所以小弟想看看您的[成功案例],方便透漏嗎?
>mail給我也行喔....
>================================
>我們是小公司,錢賺得不多,但是不會賺得很辛苦,
>「成功案例」的定義是什麼?
>例如:連續每月付我們五萬元長達八年,從幾人的小公司做到要上市,
>目前還繼續與我們簽約改每月八萬元(從COBOL換Windows 版),算不算是?
>我們每週拜訪這客戶半天,大家都Happy。
^^^
所謂成功案例。就是系統做完後沒有被冰到該家公司的櫥櫃。
這樣的定義夠直接吧,沒有曖昧的空間...
長時間的working,我們也有成功案例,合約結案後繼續
跟我們簽訂維護合約5年(沒你們的8年強),其中當然也有update,
不過需另行計價

>套裝ERP,賣了就要跑,沒法長久,不只是冬天要來,恐怕是冰河時代降臨。
^^^
敝公司套裝和專案各有Team負責
兩種都有做
各有利弊
套裝真的完全不好嗎?未必?
看需求,看規模

作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/5/29 上午 11:33:52
想問你的成功案例,是想知道究竟是哪幾家
要打廣告也請給點資訊來證明吧!!
=============================
To DarkDummy 大大,

你要的資料已經寄給你了,裡面也有我們部分客戶名單,所以沒必要在這裡打廣告吧?

本來生意就是兩相情願,我們的政策是要挑客戶,會糟蹋我們同仁工作成果的客戶,寧願不要。沒有互信基礎的生意,對兩方都是傷害。

貴公司的政策要分兩個Teams,如果客戶滿意,我們沒有置喙餘地。
我們公司的理念,認為ERP不應該是套裝軟體,如果「冰河時代」的說法
太過尖酸,請原諒我的失言。

你所謂成精的User,大概是指那些認為操作介面不理想的人,一天到晚抱怨系統難用的本位主義者。對付這種人只有用他的上司與同儕壓力,不必自己出面,更犯不上與他吵嘴。
我們系統導入時,如大推土機一般,只要業主支持,幾個月之內,雜音就會減少,一年之後
只有討論如何改善的聲音。

我們都是軟體工作者,有職業的尊嚴與豪氣,這是我們追求的,不是嗎?

作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/18 下午 01:56:51
>最近陸續聽到之前服務公司的情況, 感覺ERP 軟體產業似乎來到寒冬季節:

Compiere ERP & CRM 的出現,帶令 ERP 軟體產業進入「明天過後」的盛況。

開放原始碼商用軟體輩出
http://taiwan.cnet.com/news/software/0,2000064574,20078201,00.htm


作者 : magicdream(Frank)
[ 貼文 6 | 人氣 219 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/18 下午 02:24:02
Hi Steve:

     我也想了解貴公司的產品,可否寄些資料給我做個參考!!
我有朋友他們總經理最近也想導入ERP,最近在評估中,就麻煩你可以的話,能盡快提供給我,謝謝囉!!



作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/28 下午 06:10:02
Frank,

請告知e-mail address
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/30 下午 06:53:28
Compiere ERP & CRM 的出現,帶令 ERP 軟體產業進入「明天過後」的盛況。
===============================================

這沒有什麼稀奇,我們公司也對客戶開放原始碼,做為對客戶利益的一種保障。
但是除非客戶找來的程式設計師有我們的功力、分工方式與技術理念,才有能力維護我們的原始碼。


重點就是ERP是管理的工具,管理是會變化的,所以ERP也要跟著變,
如何讓ERP能夠跟著變,才是重點,才是技術所在。所以我們才提出ERP是服務,不是套裝的經營理念。

很多軟體業朋友對ERP這塊領域充滿恐懼,因為很難做得好。
我們小有心得,所以敢向客戶打包票,只要接受我們服務的模式,保證一定成功。

至於Compiere ERP是否會成功,也在於它的結構是否經得起改,是否有一個完整的
運作理論。還有Compiere 是用Java 開發的, Java 可不是簡單東西。
還有,開始是免費的,不見得最便宜。 Linux 就是最好的例子。

冰河時代是造就另外一種成功物種的契機。




作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/31 下午 05:02:43
>Compiere ERP & CRM 的出現,帶令 ERP 軟體產業進入「明天過後」的盛況。
>===============================================
>
>這沒有什麼稀奇,我們公司也對客戶開放原始碼,做為對客戶利益的一種保障。


原來如此,聽聞最近微軟也想來分一杯羹:

微軟商用軟體延後推出
http://taiwan.cnet.com/news/software/0,2000064574,20090741,00.htm

不過我猜它不會開放原始碼,對客戶應該沒有什麼保障的。


>但是除非客戶找來的程式設計師有我們的功力、分工方式與技術理念,才有能力維護我們的原始碼。

不知可否設計成這樣:就算沒有什麼功力的人,也有能力維護原始碼呢?
我猜開放原始碼帶來的保障是:就算原作者不再提供支援,也可以找到第三者去支援。


>重點就是ERP是管理的工具,管理是會變化的,所以ERP也要跟著變,
>如何讓ERP能夠跟著變,才是重點,才是技術所在。
>所以我們才提出ERP是服務,不是套裝的經營理念。


這裡的變化是否指「客製化」呢?


>很多軟體業朋友對ERP這塊領域充滿恐懼,因為很難做得好。
>我們小有心得,所以敢向客戶打包票,只要接受我們服務的模式,保證一定成功。

我先在此祝 貴公司能夠成功,讓我們的企業享受到 ERP 帶來的好處,
提高企業的競爭力。


>至於Compiere ERP是否會成功,也在於它的結構是否經得起改,是否有一個完整的

我覺得它是否成功就在於能否找到它的市場,
因為有些企業是會變的,也有些企業不太會變的。


>運作理論。還有Compiere 是用Java 開發的, Java 可不是簡單東西。

我也覺得不簡單的,連 Oracle 也要自己出個 JVM 來跑它的 ERP。

>還有,開始是免費的,不見得最便宜。 Linux 就是最好的例子。

贊成,就好像賣打印機是蝕錢的,賣墨水才是賺錢的。


>冰河時代是造就另外一種成功物種的契機。

因為冰河時代帶來了石油 ^^"
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/31 下午 08:29:47
>不知可否設計成這樣:就算沒有什麼功力的人,也有能力維護原始碼呢?
其實,我們可以這樣看:ERP是資料管理的「作業系統」,依我們的經驗,光要開發穩定的作業平台與開發工具就要兩三年時間,這還不包括為客戶分析系統、開發應用程式與導入(當然,客戶的部分因為有之前的建構基礎,是相較容易也快多了)。
過去COBOL如此, 現在Delphi如此, 不久未來Java與C#還是一樣
沒有一定功力的人,老實說,要接手維護我們如此龐大的系統,很難

>我猜開放原始碼帶來的保障是:就算原作者不再提供支援,也可以找到第三者去支援。
開放原始碼的真正意義是在於方便與你有同等(或更高)功力的人,可以方便接手你的工作。因為現在太多軟體捶手可得,所以在心理上多數人沒注意軟體是多麼大的工程,需要很多智力與心力的專注投入。要接手他人以團隊方式開發出來的軟體,你得有鋼鐵般的心智與毅力。
不信,你可以試試接手任何一個開放原始碼的軟體計畫, 最簡單的,把Compiere ERP 的Database 由 Oracle 移植到 MySQL / PostgreSQL 就夠嗆了
(這也是我對Compiere有懷疑之處,因為我們的ERP設計絕對把Database介面交代清楚,所以可以使用任何符合SQL標準的資料庫)

>這裡的變化是否指「客製化」呢?

ERP本來就是要客製化,外加永續修改,永續改善而且絕不崩潰。
要不然,就如本欄開欄先進所說的,準備向客戶道歉,最後走入寒冬



作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/31 下午 10:01:31
>>我猜開放原始碼帶來的保障是:就算原作者不再提供支援,也可以找到第三者去支援。

>開放原始碼的真正意義是在於方便與你有同等(或更高)功力的人,可以方便接手你的工作。因為現在太多軟體捶手可得,所以在心理上多數人沒注意軟體是多麼大的工程,需要很多智力與心力的專注投入。要接手他人以團隊方式開發出來的軟體,你得有鋼鐵般的心智與毅力。


我有一個想法,就是如果有多些第三者來提供服務,
應該可以提高客戶的信心,即是類似以下的第三者:

http://www.compiere.org/support/index.html

例如,一個客戶在使用軟件時突然遇到程式的 Bug,業務受阻,
假設在他受阻期間,每日的損失是 50 萬,那麼他可能願意拿出 50 萬,
要求有人在廿四小時內解決這個問題(有點像殺手服務似的)。

當然,如果程式是設計得好的話,應該可以減少這類情況發生,
或者如果不會遇到那麼急的客戶,也不太需要提供這類的 24x7 的服務。


>不信,你可以試試接手任何一個開放原始碼的軟體計畫, 最簡單的,把Compiere ERP 的Database 由 Oracle 移植到 MySQL / PostgreSQL 就夠嗆了
>(這也是我對Compiere有懷疑之處,因為我們的ERP設計絕對把Database介面交代清楚,所以可以使用任何符合SQL標準的資料庫)


是啊,各個資料庫的設計都有這麼大的分別,單是轉 SQL 也要不少功夫,
除非它只用一些簡單的資料庫功能。

Compiere 首先支援 Oracle ,放棄跨資料庫的設計,
大概是因為開發者本身也是從事 Oracle ERP 的工作,
而且他似乎覺得 Oracle 的資料庫也不太貴,只是 ERP 未能滿足他的要求。


>>這裡的變化是否指「客製化」呢?
>
>ERP本來就是要客製化,外加永續修改,永續改善而且絕不崩潰。
>要不然,就如本欄開欄先進所說的,準備向客戶道歉,最後走入寒冬


希望將來在香港也能見識到 貴公司的作品,讓我們減少依賴外國的軟件。
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/31 下午 11:21:40
>是啊,各個資料庫的設計都有這麼大的分別,單是轉 SQL 也要不少功夫,
>除非它只用一些簡單的資料庫功能。

對了!這個就是重點!因為太多人把資料庫的複雜度與ERP系統功能搞混了。
以為要用到資料庫的強大複雜功能,ERP系統才算入流。這觀念是很有問題的。
我們過去使用COBOL為客戶建構一個非常複雜的MRP系統,其中根本沒有用到
任何SQL資料庫,而這個系統完全符合客戶需要,而且非常穩定。
所以,資料庫只要用到與COBOL檔案系統相當的程度就可以解決很多問題,
尤其是現在硬體非常便宜可靠,多層分散式運算已經是主流,我們認為ERP系統
最後要自成體系,與OS及Database脫勾才是正途!


>Compiere 首先支援 Oracle ,放棄跨資料庫的設計,
>大概是因為開發者本身也是從事 Oracle ERP 的工作,
>而且他似乎覺得 Oracle 的資料庫也不太貴,只是 ERP 未能滿足他的要求。

跨資料庫設計其實不是太難,因為Delphi 很多年以前就用BDE的方式解決了大部分問題,
尤其是利用物件導向的觀念來設計資料庫介面,取其同,避其異;就其簡,避其繁。
拿定主意,知道你的系統需要的是哪些,就可以了。
你要是用到某家資料庫的「強大功能」來設計你的系統,那麼掉入「技術泥沼」的困境的可能性
極大,嚴重的話,你的系統會垮掉。Compiere是否與Oracle「攪在一起」,我不清楚;不過要是不幸如此,那是設計上的大缺陷。


>希望將來在香港也能見識到 貴公司的作品,讓我們減少依賴外國的軟件。
我們公司可以跨過網路來服務,有興趣嗎?


作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/8/3 上午 12:48:13
>>是啊,各個資料庫的設計都有這麼大的分別,單是轉 SQL 也要不少功夫,
>>除非它只用一些簡單的資料庫功能。
>
>對了!這個就是重點!因為太多人把資料庫的複雜度與ERP系統功能搞混了。
>以為要用到資料庫的強大複雜功能,ERP系統才算入流。這觀念是很有問題的。


一言驚醒夢中人,我竟然從來沒想過 ERP 是否真的需要使用資料庫的「特異功能」,
總是認為一個 ERP 最緊要的就是穩定,而穩定就需要特異功能。


>所以,資料庫只要用到與COBOL檔案系統相當的程度就可以解決很多問題,
>尤其是現在硬體非常便宜可靠,多層分散式運算已經是主流,我們認為ERP系統
>最後要自成體系,與OS及Database脫勾才是正途!


贊成!我曾經聽到一句話是這樣的:電腦科學發展了 40 多年,就是研究如何把各個部份分離,
同時讓它們容易「接駁」或「隨插即用」。

我想 Oracle 是很想與 OS 脫勾的,只是它最不想與 Database 脫勾,
好像打印機生產商會製造獨家出品的墨水一樣。


>跨資料庫設計其實不是太難,因為Delphi 很多年以前就用BDE的方式解決了大部分問題,

Borland 真是功不可沒。


>Compiere是否與Oracle「攪在一起」,我不清楚;不過要是不幸如此,那是設計上的大缺陷。

可能因為他要縮短 Market Time 吧。


>>希望將來在香港也能見識到 貴公司的作品,讓我們減少依賴外國的軟件。
>我們公司可以跨過網路來服務,有興趣嗎?


其實我只是個職位低微的上班一族而已,不能作出任何商業決定,不過還是很感激 Steve
不吝賜教。我想既然有這麼好的軟體理念,應該把它發揚光大,令軟體大廠也汗顏一下 ^^
作者 : iiicswa02(iiicswa02)
[ 貼文 16 | 人氣 347 | 評價 40 | 評價/貼文 2.5 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/8/7 上午 12:36:30
(我只是新手)
呃,雖然這串討論被業務人員混淆了原來的主題.
但是如果真的如第一篇所描述的,
現在的環境變成大家都在賣package,
那,任何剛入行的pg及sa,
應該都要變得非常的謹慎.
因為,這代表這兩個職位的數量,
可能會巨幅的縮減.
導入package可能只需要業務和顧問.
那,未來IT產業值錢的會是什麼人呢?
由會計師或生管轉入IT的顧問???
作者 : s8370017(成吉斯汗) 貼文超過200則
[ 貼文 225 | 人氣 3907 | 評價 160 | 評價/貼文 0.71 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/6 下午 04:08:03
<(我只是新手)
<呃,雖然這串討論被業務人員混淆了原來的主題.
<但是如果真的如第一篇所描述的,
<現在的環境變成大家都在賣package,
<那,任何剛入行的pg及sa,
<應該都要變得非常的謹慎.
<因為,這代表這兩個職位的數量,
<可能會巨幅的縮減.

恩,心有戚戚焉,我剛進SAP領域一年多一點,我發覺台灣的導入CASE量越來越少,
有能力導SAP的大廠大多已經導過SAP,剩下的CASE憎多粥少.

<導入package可能只需要業務和顧問.
<那,未來IT產業值錢的會是什麼人呢?
<由會計師或生管轉入IT的顧問???

我是不可能有機會當顧問的,如果我撐下去的結果是SAP的大環境進入冰河期
,那我啟不是會失業,我已經決定要走 OPEN 的環境,這個產業實在太小也太競爭了.

作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/7 上午 09:10:45
<呃,雖然這串討論被業務人員混淆了原來的主題.

這裡應該沒有「業務人員」參與討論,我們(至少我個人)是ERP系統的開發者,我現在仍然參與程式開發工作。只是開欄先進提出「寒冬論」後,個人覺得ERP系統的原貌被扭曲,以致於走到今天的蕭瑟景象。實際上,ERP是與公司管理者常相左右的重要工具,公司管理方式日日新月月新,但很多ERP系統導入後十年不變,難道一個軟體系統可以做到不變應萬便?這其間一定有問題!一定有還沒有完全解決的理論基礎與實踐手段,這表示我們還有耕耘的空間。

ERP在軟體工業中屬於頂級難度,做不好的CASE比比皆是,但是當事者絕不承認(人性問題)。
尤其是軟體語言技術複雜化之後,迷路的人就更多了。
我們公司現在正陷入長考,是否要將我們的理論基礎,實踐手段與軟體技術公開,以開創一個新的局面,但是,事情總有利弊,難!
作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/7 下午 01:31:08
>這裡應該沒有「業務人員」參與討論,我們(至少我個人)是ERP系統的開發者,我現在仍然參與程式開發工作。>只是開欄先進提出「寒冬論」後,個人覺得ERP系統的原貌被扭曲,以致於走到今天的蕭瑟景象。


Steve 大大對 ERP 的理念也真的很有見地,雖然「只賣產品」是可行的,
但不代表「賣服務」一定不行,始終不同公司規模、不同產業也有不同的需要。


>實際上,ERP是與公司管理者常相左右的重要工具,公司管理方式日日新月月新,
>但很多ERP系統導入後十年不變,難道一個軟體系統可以做到不變應萬便?這其間一定有問題!
>一定有還沒有完全解決的理論基礎與實踐手段,這表示我們還有耕耘的空間。


我個人只是接觸過 Oracle 而已,而且對它認識不多,不過它可以做到一套軟件就適用於
不同國家、不同產業,如果遇到某些公司有很特殊的需求的話,也可以透過第三者去提供服務。

可否請教一下 Steve 大大,您的理念與 Oracle 的是否有些不同之處呢?
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/7 下午 04:16:48
>可否請教一下 Steve 大大,您的理念與 Oracle 的是否有些不同之處呢?
個人對Oracle接觸不多,僅止於看過示範,而且是多年以前。

Oracle 的ERP 如果設計到非常有彈性,那一定有相當的理論基礎,才能達到。
一般而言,我們喜歡提出一個採購作業模擬模式,以來測試任何一家的ERP系統,看看它是否能自圓其說。這個測試提出一系列情景,看看這個系統如何因應:
以下是一例

1. 某件採購案採購 A 品 10 件, 現在已到貨 5 件, 5件尚未交貨
2. 公司上層決定 A 品未到貨部分 改 為 A1 品 3 件, A 品減為 2 件
   (因為公司相信 A1 可以取代 A,而且 A1有現貨,可以應急)

請問您的ERP系統如何處理這個問題?

接著來的:

後來發現A1有問題不能完全取代A,於是上層又決定,以後訂單更改為替代品時,必須先有查詢
預先建立的對照資料表,對照資料表公司由品管部門維護鍵入ERP系統,更改訂單內容時程式必須只能接受有對照的部分,沒經過品管部門認可的,不得任意替換。

請問您的ERP系統如何處理這個問題?




作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/7 下午 06:45:18
>一般而言,我們喜歡提出一個採購作業模擬模式,以來測試任何一家的ERP系統,
>看看它是否能自圓其說。這個測試提出一系列情景,看看這個系統如何因應:
>以下是一例
>
>1. 某件採購案採購 A 品 10 件, 現在已到貨 5 件, 5件尚未交貨
>2. 公司上層決定 A 品未到貨部分 改 為 A1 品 3 件, A 品減為 2 件
> (因為公司相信 A1 可以取代 A,而且 A1有現貨,可以應急)


這個例子很不錯,不過我以前都是做報表的工作(設計越有彈性,做報表越辛苦 >_<)
只是到最近才開始研究 Oracle 的設計。採購方面我完全沒接觸過,待我趼究一下這方面
再看看可否解決這個問題。

我接觸比較多的是訂單管理:

http://www.hkln.net/doc/oracle_eb/ont.htm
(只是前幾天開始接觸而已)

感謝 Steve 大大提供寶貴實例。
作者 : swwei(Steve) 貼文超過200則
[ 貼文 230 | 人氣 1250 | 評價 580 | 評價/貼文 2.52 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/7 下午 09:05:59
>.....,不過我以前都是做報表的工作(設計越有彈性,做報表越辛苦 >_<)
啊! 這就是關鍵所在! 如果你需要Join 兩個以上的 Tables 來產生報表, 就表示這個系統設計有問題了。如果你要花很多時間去瞭解你要的資料分佈在哪些地方,這個系統不算有彈性,只能算是複雜,而複雜就是出錯的根源。


>我接觸比較多的是訂單管理:
「訂單交貨」與「採購收貨」以資料處理模式來看,幾乎一樣,只是Table名稱不一樣,欄位名稱不一樣。所以,設計基礎系統的第一步,不要被實務名詞所惑,先看出抽象的相同運作之處,才能設計出堅如磐石的底層運作核心,務求Once works, it works everywhere! 這是要訣。
 如果訂單歸訂單,採購歸採購,程式各寫各的,那麼整個系統就會沒有生命,毫無章法,甚至失控。連電腦作業系統如此複雜,都有規則架構可循,才會穩定執行,ERP也應該如是。


>感謝 Steve 大大提供寶貴實例。
謬讚了!我這是野人獻曝
作者 : hkln(HKLN.net) Perl卓越專家Oracle卓越專家資訊類作業求救優秀好手一般優秀好手程式設計甘苦談優秀好手C#卓越專家貼文超過2000則人氣指數超過100000點
[ 貼文 2135 | 人氣 122272 | 評價 14600 | 評價/貼文 6.84 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/7 下午 10:35:56
>>.....,不過我以前都是做報表的工作(設計越有彈性,做報表越辛苦 >_<)
>啊! 這就是關鍵所在! 如果你需要Join 兩個以上的 Tables 來產生報表,


我遇過的 Oracle 報表之中,印象中最複雜的一個 SQL ,
是連接了十多二十個 Tables,加上 6 個 UNION,和數之不盡的預存程序。
而我自己寫的 SQL ,一般都需要連接 2 至 6 個 Tables,
不過如果改用 View 的話可以少一些。


>就表示這個系統設計有問題了。如果你要花很多時間去瞭解你要的資料分佈在哪些地方


不過我覺得 Oracle 的文件倒也足夠我去瞭解資料放到哪一個 Table,
可能因為我的需要比較簡單吧。


>,這個系統不算有彈性,只能算是複雜,而複雜就是出錯的根源。


可能我對「彈性」一詞的意思有點不同看法,個人覺得有彈性是指
它能夠滿足不同的需要,無論是簡單的還是複雜的需要,
都能夠用一個報表來滿足,所以 Oracle 的報表是會比較複雜的。


>>我接觸比較多的是訂單管理:
>「訂單交貨」與「採購收貨」以資料處理模式來看,幾乎一樣,
>只是Table名稱不一樣,欄位名稱不一樣。所以,設計基礎系統的第一步,


是,好像要表示「父」和「子」的關係,Oracle 會用 HEADERS 和 LINES
(好像一般常見的 Order 和 OrderDetails),所以不論是那個模組,
如應收帳、應付帳、訂單、採購,都會見到 HEADERS 和 LINES 的 Table 名稱。

而訂單和採購的欄位都應該會差不多,例如大家都會有日期、數量、單價、行總額等。


>不要被實務名詞所惑,先看出抽象的相同運作之處,才能設計出堅如磐石
>的底層運作核心,務求Once works, it works everywhere! 這是要訣。


我就是想學您所說的抽象化設計,做到只要設計一次,就能滿足所有的需要,
例如一個處理會計的程式,也能用來處理庫存。


> 如果訂單歸訂單,採購歸採購,程式各寫各的,那麼整個系統就會沒有生命,
>毫無章法,甚至失控。連電腦作業系統如此複雜,都有規則架構可循,
>才會穩定執行,ERP也應該如是。

是,這樣就減少了 Reuse ,而且程式多了一倍,維護工夫也多一倍了。


>>感謝 Steve 大大提供寶貴實例。
>謬讚了!我這是野人獻曝


哈!不管是野人還是猿人,能設計出有生命的程式就是好人 ^.^
作者 : bonnie0209(bonnie)
[ 貼文 6 | 人氣 3179 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/21 下午 06:06:58
各位先進.看以上先進高手過招真是精采.對於s
>
作者 : bonnie0209(bonnie)
[ 貼文 6 | 人氣 3179 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/21 下午 06:09:49
前一篇文章還沒打完...怎麼刪啊?
作者 : smgrj(jj)
[ 貼文 24 | 人氣 228 | 評價 130 | 評價/貼文 5.42 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/7/7 下午 03:44:54
請問你們開發ERP一個月薪水多少啊?
 板主 : 徵求中
 > 資訊軟體 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - 資訊軟體 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
資訊軟體
1 ozzy 300 
2 fortran 220 
3 monkey 160 
4 SweetWo 130 
5 judas 120 
6 openmind 110 
7 Jasper 100 
8 好說 100 
9 Hsu-春源 90 
10 Steve 90 
資訊軟體
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2019 程式設計俱樂部 http://www.programmer-club.com.tw/
0.140625