提到開源軟件，很多人首先想到的是Linux。
就這樣一個由個人開發出的類似Unix的操作系統
居然能跟Win系統在服務器領域進行抗爭，
並且取得了不小的戰績，真是不容易啊。
大家可以很明顯的看到：
使用了Linux服務器以後，
公司的運營成本在降低——相對于Win系統，Linux幾乎可以說是免費的。
可在ERP行業，開源的生存空間又有多少？
開源的優勢
提到開源首先想到的就是源代碼開放，
當然這裏的源代碼開放無非是兩種情形：
1、部分源代碼開放
很多企業爲了自己的核心利益不受侵害雖然打著開源的牌子，
可實質上在系統管理方面的核心源代碼是不開放的。
比如說你購買了哪些模塊才能使用哪些模塊，
購買了多少用戶數才能使用多少用戶數，
再有一些底層的算法。
這類僞開源軟件在本文中就不再做詳盡的闡述。
2、真正的源代碼開放
所謂真正的源代碼開放是指軟件所有的功能、
程序完全提供給企業，
大家遵循一種指定的遊戲規則
（比如購買軟件源代碼的使用權，而沒有銷售盈利的權力）
在同一套産品的基礎上進行開發、改進和優化。
開源ERP能解決的問題
我把開源ERP理解爲一種商業模式，
這種商業模式能解決特定客戶的一些顧慮，
特別是供應商的服務問題
所謂的服務涵蓋的面非常廣，
有了源代碼客戶可以完成以下的工作：
1、無限用戶的擴展。
有了不受限制的源代碼，
隨著企業的擴充，
企業不需要在LICENSE方面再增加任何費用。
可以大大降低ERP使用的成本。
2、無限功能的擴展。
有了完整的源代碼，
用戶可以根據自己的期望任意的擴充功能，
不受任何限制。
想增加CRM可以增加CRM，
想增加SCM可以增加 SCM，
隨心所欲。
幾乎可以說只要購買了完整的源代碼，
企業就有了控制整個ERP項目的權力。
對開源的顧忌
這樣完美的方案似乎十分誘人，
既省成本，又能完美的控制，
那麽所有的ERP廠商都開源好了，
用戶自己來選擇嘛。
可事實並非如此。
ERP的市場被非開源的ERP廠商牢牢的控制著，
這是爲什麽呢？
因爲我們對開源的ERP還有顧慮。
一、ERP並非只是軟件。
三分軟件七分實施十二分的數據－－在這我也還是不忘把數據這個話題拿出來，
盡管在這裏並不會討論這個問題。
可從三七開這樣的比例就能看出：
軟件對于一個ERP項目的影響有多大。
事實上很多 ERP項目實施失敗，
“軟件的因素”只是個借口。
軟件只是個工具－－協助企業管理的工具，
沒有軟件企業就運行不下去了嗎？雞照飛狗照跳的。
我認爲：
上一套ERP除了能帶來軟件功能所涵蓋的便捷的統計功能以外，
更重要的是：
改善企業的管理過程。
僅僅是把企業現有的流程照搬進SAP，
那麽這樣的項目也不能稱之爲成功。
所以：
僅僅談軟件是否開源，
我覺得影響有限。
二、對産品開發的約束
1、對軟件的理解
>>
>>程序員設計軟件 ?? 死路一條,,不知所謂何事 !!
>>
對于程序員來說，
如果是自己設計自己開發一套軟件産品，
我想難度會比“在別人産品的基礎上進行修改”要容易的多。??
思路是自己的，想法也是自己的，只是如何實現罷了。
對于開源産品來說也存在同樣的問題：
程序員要去理解並掌握這套新的系統需要多長時間。
和對成品軟件的實施不同，
要掌握的不僅僅是軟件的功能，
更要掌握軟件的設計思路，
開發的技巧。
多長時間能掌握這些，
後續開發的程序是不是狗尾續貂是每個IT經理需要考慮的。
2、開發的成本
有了開源的産品，對于企業來說可以隨心所欲的進行開發，
但在這個“隨心所欲”的背後缺忽視了“開發的成本”。
開發哪怕只是一個報表也是需要成本的。
雖然在企業內部一個程序員的工資並不會很高，
但這的確還是要占有成本的。
也就是說在有限的時間內企業能夠進行開發或者改善的空間有限。
當然，
企業願意花時間去等也沒有關系，
但在這個商場如戰場的環境下，
企業等得起嗎？
3、開發的項目控制
很多在企業內做過程序開發的朋友多遇到過這樣的問題：
很多非常小的功能，
僅僅是爲了方便用戶查詢某個數據的功能，
占據了大量的開發的時間。
而真正能對企業運營産生良好幫助的模塊，
卻因爲沒有時間去進行開發。
這就是：對需求的分析、分級和控制。
作爲用戶來說，
他們很難站在全局的高度去思考一個ERP項目應該如何運作，
應該在哪些方面全盤考慮。
而ERP 項目組在國內企業內的地位又往往不是很高，
這很容易讓ERP程序員陷入這樣一個困境：
永遠有解決不完的問題，
而要解決的多是雞毛蒜皮的事情。
慢慢的程序員也在沈淪，
每日悠閑的改改報表中的字段長度，
或者增刪幾行數據。
三、對開源軟件的顧慮
1、産品升級換代的問題
在開源産品的基礎上進行開發，
勢必會影響到産品的升級。
對于同一個功能，
軟件公司有軟件公司的考慮，
企業有企業的考慮。
進行了比較的二次開發以後必然降低産品升級的可能性。
也就意味著企業要獨自承擔軟件後續的維護工作。
如何均衡利弊？
2、開源廠商持續經營的問題
既然産品可以很廉價的購買，
購買了以後也不需再受軟件商的約束－－那麽你們的利潤來源在哪？
如何保證貴企業的持續經營？
有位開源ERP廠商的朋友說可以通過提供：
技術文檔、
技術支持、
授權加盟等形式來贏取利潤。
可這種運營模式真的會成功嗎？
在這裏我就做結論了，
但我個的感覺是：
賣文檔賣一個客戶就少一個客戶，
而且客戶群僅僅是使用了這套ERP系統的客戶。
做支持就更不用說了：
人家都有源代碼了，
當客戶群足夠龐大的時候，
用戶自己都可以組織相應的討論組來解決問題。
利潤的空間有多大？
如何維持企業的運營？
開源ERP所適用的環境
談到了開源ERP的優勢，
也談到了開源ERP的軟肋或者說是我們困惑，
自然要談談我所理解的開源ERP所適合的生存空間了
1、企業內有強大的IT團隊，
能對軟件進行深入分析並擴充。
要對ERP系統進行功能上的擴充需要一些程序員。
隨著企業規模的不斷擴大，
對軟件本身功能要求不斷增加的情況下，
要麽更換ERP産品，要麽進行升級，
要麽就只能自行開發了。
企業需要有多大的開發團隊來維系軟件的運營？
這對程序員的需求可就高了。
當然，
企業也可以額外購買開源軟件商的服務，
出高價由他們來進行二次開發。
2、企業的IT團隊必須能完整的控制項目的進度。
除了對開發人員的要求以外，
IT團隊還必須有獨立的項目控制的能力。
各個部門提出的各種需求，
如何在工作上進行分配管理？
如何才能保障在規定的時間內完成。
IT經理或者項目經理的角色是必不可少的。
當然這類人員還必須得具備系統分析的能力，
能最優化的實現用戶的需求。
3、企業更需要一個CIO能從戰略的角度來設計新的模塊和功能。
除了完成用戶提出的需求以外，
CIO更要能站在企業運營的角度去考慮軟件未來發展的方向。
並規劃一些新的功能、模塊。
與IT經理或項目經理進行溝通，
制定完成工作的時間表。
啊，這樣看來，
IT部門也能獨立運作了，
或許能從一個成本（費用）中心轉變爲一個利潤中心。
開拓新的軟件市場。
>>
>> 資工來玩::ERP::必斃::
>>
10年前本人就曾在一家台資公司從事某國外ERP産品的二次開發工作，
對此深有體會。
一套經典的ERP産品在設計過程中必然融入了它對企業管理的理解。
僅僅只是做代碼的堆徹
而不考慮企業的流程、數據的運轉傳遞那還不如只用EXCEL。
而理解這些信息又需要多長的時間？
作爲程序員，
那套系統我們只能一個功能一個功能，
一個模塊一個模塊的研究，
20人的IT團隊每人分配一部分工作，
隔三五個月再交換負責的模塊從而保障系統獨立、穩定運行。
我也相信對于一套成熟的ERP系統來說大家需要話同樣多的精力來消化吸收。
從純粹技術的角度來說，程序員是很欣賞有這類産品出現的。
借鑒這些産品的經驗自己可以進行改進，
或者開發出類似的産品。
而從商業的角度來看，
我並不否認這樣一種商業模式有其生存的空間－－存在就是合理的。
可是從一個用戶的角度來看，
我更希望開源ERP的商家能考慮到作爲用戶的這些顧慮。
畢竟對于ERP廠商來說成敗不過是個案例，
但對于企業來說上一套ERP系統很可能是傷筋動骨。
(王朝網絡 wangchao.net.cn)
2010年7月12日 星期一
2010年7月4日 星期日
好好笑 IBM 你麼不湯亂找人來亂亂寫
http://www-07.ibm.com/services/bcs/tw/erp.html
IBM 全球服務部 > 全球服務項目總覽 >
業務諮詢暨整合服務
ERP 成功導入要素分析
企業經營核心戰略 - ERP 成功導入要素分析
製造業是國民經濟的發動機，是對外貿易的支柱和國家安全的保障。製造業是實現工業化的源泉，是實現現代化的原動力。近年來，由於國內外環境的變化，新世紀的製造業正在面臨著前所未有的機遇和挑戰。
在資訊時代，市場瞬息萬變，產品的研製、開發、生產、上市、服務節奏日趨加快，導致產品生命周期大幅度縮短，企業的生命周期也隨之發生變化。
針對以上變化，今時今日企業的確已經到了不使用先進的資訊技術來進行管理和商務運作就無法立足市場的地步。越來越多的企業認識到必須先改進自身的管理水平，找到一種能夠適應這種競爭環境的管理機制，為實施電子商務奠定良好的基礎。企業必須開始考慮，在新形勢下如何進行經營管理，如何整合廠房、設備、動力、人力、原料以及產品、技術等等各方面企業資源，以最低的資源消耗來生產出市場所需要的產品，從而節約成本，提高盈利。
沒有 ERP，就沒有真正的電子商務
ERP 是企業發展的基礎。只有打好這塊地基，企業向上發展的空間才會廣闊，如下圖所示， ERP 具有極為廣闊的擴充範圍。
ERP 擴充範圍
請點擊將圖放大
雖然電子商務時不我待，但沒有 ERP ，就不能進行真正的電子商務，因為 ERP 幫助企業首先練好內功，如將公司內部流程電腦化、對客戶訂單實行中央資料庫管理等等，只有後臺（ back-end ）的堅強流程支援，才能將前臺的業務迅速交到後臺，實現真正的電子商務。
ERP 結構示意圖
請點擊將圖放大
ERP 起源於製造業，並主要用於製造業。
是一種以市場和客戶需求為導向，
以實行企業內外資源優化配置，實現資訊流、物流、資金流、價值流
和業務流的有機集成和提高客戶滿意度為目標的現代企業管理思想和方法。
近年來，我國很多製造業的企業都在實施與準備實施 ERP。
ERP 由 MRP、MRPⅡ 發展而來，它繼承了 MRP、MRPⅡ 許多優點，
管理深度、廣度均超越了 MRPⅡ。ERP 融入了許多現代先進的管理思想和方法，
同時充分發揮資訊技術 (IT) 的優勢，
是先進管理思想和資訊技術對企業全面資源計劃管理的綜合體現。
世界上許多企業都有非常成功的應用。
ERP 軟體的合理運用可以幫助企業內部業務操作合理化，同時運用功能豐富的協作/合作技術 (collaborative technologies) 可以幫助企業在跨合作企業群體和貿易夥伴之間提高管理水平，擴展企業競爭空間和提高綜合能力。同時企業可以在 ERP 的基礎上，整合 CRM，SCM 等電子商務應用，將企業管理從企業內部延伸到企業外部，
把客戶需求、企業生產和供應商的資源整合在一起，
形成一條供應鏈，並對供應鏈的所有環節進行管理。
同時，ERP 不再像 MRPⅡ 那樣，
局限于幾種單一的生產方式和管理標準，
由單一型生產方式向混合型生產管理發展，
滿足企業的多角化經營需求。
ERP 還增加了對跨地區，
多工廠的集團生產經營管理的支援，
以滿足集團公司的需求。
IBM 的看法: 如何成功實施 ERP
毫無疑問，成功的 ERP 將會為製造業企業帶來巨大的競爭優勢。但是必須看到，ERP 專案是一個複雜和具有一定實施難度的專案.這是因為，一方面企業有效地應用 ERP 不僅僅是一個純粹資訊技術的專案。更重要的是它必然涉及到人們傳統管理思想的轉變、管理模式的改變、管理方法的改進、管理機制的轉換、管理基礎的加強、業務流程的重組、組織結構的調整、責權利的再分配、專案應用目標的制定、專案的可行性研究、專案管理體制和運作機制的建立、應用軟體的選擇和專案的實施方法等一系列實際問題，
從而使整個專案應用具有涉及面廣、難度大、周期長和系統複雜等特點。
特別是在具有單件小批量生產、多品種小批量生產類型，
產品結構複雜，生產周期較長的國有大中型企業這種現象就更為突出。
另一方面，ERP 系統中大量的複雜的高新水準的資訊技術，
包括多種軟體，硬體，需要專業人員來進行設計，集成和實施。
企業在實施 ERP 的過程中的最大困難在於：
ERP 既非一個純粹的管理變革，
也非一個純粹的 IT 專案，
成功的 ERP 必須把管理經驗、行業經驗和資訊技術這三者有機的結合在一起，
實現有效的整合，達到“1+1+1>3”的效果。
通常企業應該按照如下的步驟來實施 ERP 以確保整個專案的成功。
IBM 全球服務部 > 全球服務項目總覽 >
業務諮詢暨整合服務
ERP 成功導入要素分析
企業經營核心戰略 - ERP 成功導入要素分析
製造業是國民經濟的發動機，是對外貿易的支柱和國家安全的保障。製造業是實現工業化的源泉，是實現現代化的原動力。近年來，由於國內外環境的變化，新世紀的製造業正在面臨著前所未有的機遇和挑戰。
在資訊時代，市場瞬息萬變，產品的研製、開發、生產、上市、服務節奏日趨加快，導致產品生命周期大幅度縮短，企業的生命周期也隨之發生變化。
針對以上變化，今時今日企業的確已經到了不使用先進的資訊技術來進行管理和商務運作就無法立足市場的地步。越來越多的企業認識到必須先改進自身的管理水平，找到一種能夠適應這種競爭環境的管理機制，為實施電子商務奠定良好的基礎。企業必須開始考慮，在新形勢下如何進行經營管理，如何整合廠房、設備、動力、人力、原料以及產品、技術等等各方面企業資源，以最低的資源消耗來生產出市場所需要的產品，從而節約成本，提高盈利。
沒有 ERP，就沒有真正的電子商務
ERP 是企業發展的基礎。只有打好這塊地基，企業向上發展的空間才會廣闊，如下圖所示， ERP 具有極為廣闊的擴充範圍。
ERP 擴充範圍
請點擊將圖放大
雖然電子商務時不我待，但沒有 ERP ，就不能進行真正的電子商務，因為 ERP 幫助企業首先練好內功，如將公司內部流程電腦化、對客戶訂單實行中央資料庫管理等等，只有後臺（ back-end ）的堅強流程支援，才能將前臺的業務迅速交到後臺，實現真正的電子商務。
ERP 結構示意圖
請點擊將圖放大
ERP 起源於製造業，並主要用於製造業。
是一種以市場和客戶需求為導向，
以實行企業內外資源優化配置，實現資訊流、物流、資金流、價值流
和業務流的有機集成和提高客戶滿意度為目標的現代企業管理思想和方法。
近年來，我國很多製造業的企業都在實施與準備實施 ERP。
ERP 由 MRP、MRPⅡ 發展而來，它繼承了 MRP、MRPⅡ 許多優點，
管理深度、廣度均超越了 MRPⅡ。ERP 融入了許多現代先進的管理思想和方法，
同時充分發揮資訊技術 (IT) 的優勢，
是先進管理思想和資訊技術對企業全面資源計劃管理的綜合體現。
世界上許多企業都有非常成功的應用。
ERP 軟體的合理運用可以幫助企業內部業務操作合理化，同時運用功能豐富的協作/合作技術 (collaborative technologies) 可以幫助企業在跨合作企業群體和貿易夥伴之間提高管理水平，擴展企業競爭空間和提高綜合能力。同時企業可以在 ERP 的基礎上，整合 CRM，SCM 等電子商務應用，將企業管理從企業內部延伸到企業外部，
把客戶需求、企業生產和供應商的資源整合在一起，
形成一條供應鏈，並對供應鏈的所有環節進行管理。
同時，ERP 不再像 MRPⅡ 那樣，
局限于幾種單一的生產方式和管理標準，
由單一型生產方式向混合型生產管理發展，
滿足企業的多角化經營需求。
ERP 還增加了對跨地區，
多工廠的集團生產經營管理的支援，
以滿足集團公司的需求。
IBM 的看法: 如何成功實施 ERP
毫無疑問，成功的 ERP 將會為製造業企業帶來巨大的競爭優勢。但是必須看到，ERP 專案是一個複雜和具有一定實施難度的專案.這是因為，一方面企業有效地應用 ERP 不僅僅是一個純粹資訊技術的專案。更重要的是它必然涉及到人們傳統管理思想的轉變、管理模式的改變、管理方法的改進、管理機制的轉換、管理基礎的加強、業務流程的重組、組織結構的調整、責權利的再分配、專案應用目標的制定、專案的可行性研究、專案管理體制和運作機制的建立、應用軟體的選擇和專案的實施方法等一系列實際問題，
從而使整個專案應用具有涉及面廣、難度大、周期長和系統複雜等特點。
特別是在具有單件小批量生產、多品種小批量生產類型，
產品結構複雜，生產周期較長的國有大中型企業這種現象就更為突出。
另一方面，ERP 系統中大量的複雜的高新水準的資訊技術，
包括多種軟體，硬體，需要專業人員來進行設計，集成和實施。
企業在實施 ERP 的過程中的最大困難在於：
ERP 既非一個純粹的管理變革，
也非一個純粹的 IT 專案，
成功的 ERP 必須把管理經驗、行業經驗和資訊技術這三者有機的結合在一起，
實現有效的整合，達到“1+1+1>3”的效果。
通常企業應該按照如下的步驟來實施 ERP 以確保整個專案的成功。
2010年6月27日 星期日
杨天明：全球品牌知名企业之商务运筹管理
http://www.fnews.com.cn 2007-08-15 14:16:14 第一时间 已投15 票
各位好。
今天我是代表Acer，我在这里更正一下，Acer已经把制造环节切割。
我今天谈的跟前面谈的有最大的差异，我讲的策略性的规划。
因为Acer从成立到现在已经超过30多年，
在史先生的领导之下，涉及到400家公司，分分合合。我谈的是策划规划，
一个时期我们在谈供应链，我们面对的问题就是由品牌开始，
我们有很多现状，
你如何从比较中长期的规划让整个新Acer的生产线在运筹上、
在经营上是能够一步一步能够配合经营方针达到第三、甚至是第二、第一。
介绍我的经历。我在欧洲的飞利浦公司工作过，
从事标准的制造业。我也在甲骨文公司工作过，
是一家法国公司，标准的做ERP顾问服务的公司。
我目前是在Acer刚工作满六年，
是一个完完全全没有制造品牌的公司。
我分几个主题来谈：第一，和各位介绍一下Acer的演变;
第二，策略性的规划。
前面大家听很多ERP的展开、信息的部件，
那么我要谈的范围更大的一点，我要A2A的供应链，
也会谈到我们执行到现在从短期、中期的状态，最后会做一个结尾。
简单介绍最早Acer是叫“泛宏基”。
2001年三分天下，兄弟爬山各自能力。
所谓的ABW，A代表 Acer，B代表BanQ，W代表伟创。
这三家在2001年成立了新集团各有特色。
Acer只有品牌，我们专注在品牌。
伟创专门从事制造，BanQ有品牌有制造。
我目前服务于Acer。
我现在服务生产，包括笔记本、台式机，还有LCD，DV等等。
先看一看公司的经营方针和策略。
你必须有战略和商业模式，然后你再看ERP怎么套用。
我们的董事长，他的策略很简单，但是做起来比较复杂。
我们叫做“三一三多”，
三个一：一个品牌，一个全球集团、一个团队。
全球我们大概有二三十家公司，然后是一个团队。
“三多”：多产品，多通路，多供应商。
所以这就是我们从2000年开始定的很清楚的目标。
那么我们非直接经销，大家可能马上会想起戴尔，
刚好跟我们看起来是截然不同的方式—直销，
这样听起来会有一个很明显的对照。
戴尔很清楚直销是什么，直接面对消费者，中间没有推销商、没有零售商。这样话可以把库存降低到最低。
戴尔的直销事实上是在美国发迹，
所以美国已经非常习惯在互联网的情况下发展，
戴尔用的是直销+CPO。
Acer 的观点不截然是，从消费者眼光上，
如果今天你要上网看一台电脑，
然后你可能要花到超过六千块或者是七千块的人民币，
你会不会马上买呢?
我想不会。
因为那不是几块钱，这种情况，在欧洲我们也发现了。
欧洲人特性，也是要到实体店看到他想买的笔记本、台式机长的怎么样，
还习惯享受一下杀价的乐趣，
最后才会下单。
所以Acer采取这样一个模式。
当然这里放了一个戴尔的销售模式已经开始调整。
从2003年，戴尔一直是第一，到2006年下半年就一直被HP压着打，
那么HP是现在是第一，那么戴尔是第二。
所以没有永远常胜的将军。你必须跟着你经营环境做调整。
戴尔有直销加上通路，所以戴尔号称是混合式的销售。
我的看法就是第一个，戴尔、HP是以美国做市场，
然后再做到其他的市场。联想是以大陆做市场，然后延伸到德国市场。
索尼、东芝等是以日本做市场，然后延伸到德国。
所以，当你在做市场的时候，你的模式已经做了改变。
当你看到对亚洲来讲是不可能做到的，
要硬把一个不变的DELL模式，他的直销对亚洲来讲，是不可能做到的。
你要另把一个不变的BELL模式，强加一个在一个另外商业管理领域，
你注定会失败。对Acer来讲，没有一个PC的赢家会永远死守在一成不变的模式。
差别只是直销还是营销，在不同商业环境应用的程度和强度。
speed这个世界讲究速度，看到一个商机，别人也会看到商机，
你两个月把产品上架、铺货，人家要六个月，
谁赚到商机，当然是谁越快谁赚到钱。
软件还有ERP，还有谁还在家里自行开发，
你能开发出来已经享受不到利润和效益了，
为什么ERP会大放异彩，
制造业如此，所有的行业都是如此。
这是AcerE2E供应链的介绍。
第一，现在是5个Region有5套不同的ERP。
是5个长的都不一样的ERP。
getorder而是还有一套在台湾。
我们的东西南北中要帮我开拓市场，
所以Region的定位很清楚是开拓市场。
第二，到把订单回敲到总部的时候，
总部的目的是满足订单，
马上交出去，总部是降低采购总成本，
加速产品新开发的时间。
第三，fulfill。我们的合作伙伴对我们来讲是帮我们制作武器的供应商。
有了最强最新的武器，才可以卖到前线。
第五，我们的master是我们的channel，
这是我们简化的供应链的理解。
这5套ERP，QAD在中国也代卖，每套ERP都超过15岁。
Acer也有ERP，我们的策略是当全球统一销售 ERP以后，
我们的既有的ERP也有“三不”政策：不投资、不升级、成本不增加。
用到老死为止。
现状分析：必须了解Acer的现状，在2001年增加之后，
我的是8个Region变成5个Region，
我们在不同的时间、不同的环境、不同的背景下布建起来了，
这些系统不是一个人决定的，因为Acer是由很多家公司合并而成的。
系统和系统之间有一堆的界面做资料的整合。
High Dependencies，当Region系统改了一些系统，这边也要配合改。
这是看Acer现状里最大的痛。
有很多的资料，料耗阻挡，会计科目的阻挡，财务要做汇总报表的时候，
很多资料都要转过来，因为定义文件不同，所以要改。
这个现象是我们的工作环境提供给员工的不是非常有效能的环境，
在没有效能的工作环境中如何要求我们把竞争能力提高，所以我们必须做一些改变。
改变的时候我们讲过策略规划，
先从所有的高阶主管请他们用很简单的白话把他们的期望值，
对信息未来的期望值讲出来。
CEO说，我每天都要看到全球的销售量，
可不可以一个系统按一个键可以看到。每一个Region head，要重新换ERP可以，
但是不要妨碍我的工作。
这就困难了，Chairman说一个系统蓝图到底是什么，
我们必须要全公司都可以清楚的了解。
最终用户说换系统了，是不是很危险。
CIO说所有老板讲得都对，咨询部要做电脑化、信息化的建设，
都使公司更有竞争力。
finance说我们希望有一套快速的系统。
物流部说，Region要求桌面是有批判性，在全球都有价值。
答案很清楚了，我们希望有一套系统，但又不妨碍每个Region做生意，
运营不能够打断，我们的做法短期是小的但是价值很高的项目。
以前我们再逐渐的做到中长期。
还有一个指导原则，不要做一大堆的计划，让系统和系统对接。
这个方法看起来很好，系统和系统对接的任务非常不容易，
因为有不同的运行系统要做很多转换工作。
(图)PLM、ERP、SCM同时导入，因为要维持正常运转。
当一个系统运行最高指导原则很清楚之后，什么叫做一个系统。
(图)一个blueprint，包括B2B、 ERP、PLM、SCM。B2B不是应用系统。
为什么ERP排在B2B的后面，为什么ERP不是老大，
大家不是说ERP是核心吗?
有了ERP才能广泛的伸展到供应链，为什么ERP不可以一口气做。
因为人力、资源、成本都有限。
什么叫做B2B，(图)中HP、Dell、Acer、联想、东芝、苹果都是电脑。
代工有广达、富士康、伟创，是 OEM收入比较高。
下面有一大堆原材料的供应商，到供应商层有上十万家，
这叫做B2B的生态环境。
可以看到有很多材料在中间，
每一天在交换。
ERP从 Acer采购订单，
给富士康，富士康接单排到ERP当成demand，
跑出来还要缺料，还要跟下一轮的供应商跑。
再把计划性订单变成采购订单，
丢给下游的供应商。
每一天有这么多的采购订单、销售订单、出货等等，
这样一个供应链是整个生态。
最大差别是，ERP是企业内部企业资源整合，
供应链是彼此之间的协同运作，
所以ERP是企业的核心，
企业应该根据竞争力要把两手伸开，
要走供应链。
供应链的底层是B2B，每一天都在做数据信息的交换。如果今天没有ERP，
以上的内容还是要发生。
举一个例子，
高速公路可以开到120公里，
开到收费站要交钱，
那时候你的速度会降下来，让你没有办法快。
供应链就在打破这些收费站的速度，要推动速度在ERP里跑，你的过程就完成了。
跑到外面到供应链的时候，就碰到了收费站。B2B就是加速器，
B2B是ERP和supply chain必备的底层。ERP还是核心，从应用系统的角度，
对于Acer已经有五套ERP了，
我是用到不升级、不修改，不加人。
所以B2B变成了第一位。
整个B2B one system长期坚持起来，只有一个系统。
刚才看到5个Region有5个ERP，它还是一套ERP。
get coder还是1套ERP。
第一，B2B的平台在全球ERP和SCM之前准备。
第二，B2B要提供多方的数据流的接受。2002年开始，
DDI能够做的我们都做了，
我们在做马步基本功的扎实，
就像高速公路收费站的速度平均变成高速公路一样的速度。
最近两年，我们领先的技术已经做到成功，
这是我们短、中期的目标已经上线了。
未来长期我们会用一套内销，自己研发的产品，接单、过单、PLM，
不是所有信息化的专案都圆满结束。
有一个国际化的系统还是不稳，所取消掉了。
去年我们导入了Oracle Agile，最后宣布失败。
大家都谈ERP，我谈的是一个比较不一样的策略。ERP导入有那些考虑点，
互联网公司随便找几家。如果有HQ、 China、Europe、PA、AP
到底先上哪一个。如果Acer现在的欧洲的市场占有份额是第一，
那么他就是市场最优先。如果先一步，而且是中国、欧洲，
剩下的当然花在经济上，有不同的考量。
如果公司从零开始，董事长说全部动员，
那么没有问题，那么在欧洲最优先，亚太在最后，
那么最后你还是要做一个决定。
所有的企业都在追求卓越，time时间和市场是追求竞争力的不二法门。
没有核心不可能向外发展，供应使ERP两手伸出去。数据库的建设，
B2B是ERP和SCM的加速器。当想ERP信息化建设的时候，如果企业跟很多的供应商或者客户，
假如客户够大，有自己的 ERP，当数据流在交换可以变成B2B的时候，不是只有你赢，大家都赢。
在供应链里谈的是“协同”。SUB-control是一个世界潮流，富士康是世界领域，只是他们用的不一样，
而富士康是ODM，广达是CMMS。神州数码是整个大中华的第一，
我们选最强的来合作。同样的world wide发生在软件的环境里，ERP这样的东西自己在家开发绝对来不及。
IT策略永远要跟着市场的策略做调整，特别要小心并购跟合并，
你可能选了一个厂商很有名，可是它在美国，
而美国最近几年一下子会淘汰掉，所以很难掌控。
当地资源可能是一个最重要的决定关键。
我们把董事长讲的话再重复：最后的致胜的关键，
不局限在Acer internal弹性与速度，
而是需要和ODM、关键的零组建商、通路配销运筹业者等合作伙伴，
能否快速且有弹性的完美配合。
我们看Acer的供应链分享是不是只做自己，
要跟供应链里面的渠道，
我们的ODM和我们的关键供应商要利用B2B加速两边的整合。
永乐和苏宁也在谈，现在是大者恒大，联想在大陆是第一，但是不是全球市场，
要做到全球，合并和并购的策略就出来了。所以才有IBM和联想的合作，
实现在美国的扩张。透过专业的分工是world wide的精髓，透过专业分工，
你就可以快速反映市场变化的速度。
回到ERP WORLD2007年，ERP的核心我有两个，第一，ERP的核心有两个“lier”，
就是B2B的建制。如果今天能够把B2B的速度跟合作伙伴一起努力打破的话，
就比别人快一步了。第二，如果把核心再拆到更核心的时候，
所有的东西在ERP里面都是data，数据地上满街都是，
要把数据变成有用的资讯为主管做决策就是信息，这就要靠流程。当你在延伸，
把ERP做好，只不过是把企业内部的数据变成了自己的信息，
如果要跟渠道合作伙伴做更加深入的延伸加速运筹，数据比ERP更麻烦，
料耗到别的系统还是这样的料耗吗?
这样传过来是否要转换?今天要做好就要把服务做好，
我们要从ODM来，富士康有自己的料耗。
同样的东西在不同的企业里料耗分工不一样，
这就是一个大问号。ERP谈的是B2B的建制，
ERP本身就是一个供应链的核心，这是无可厚非的。
如果能把B2B 建制好，就比别人快一个脚步。
ERP真正的核心从数据来讲，是怎么把数据变成信息，
是要通过好的设计。谈到供应链把数据变成信息就更困难了，
因为料耗不一样，这是一个很困难的问题。
感谢各位听我演讲，谢谢大家。
嘉宾介绍：宏碁 杨天明处长
WORKING EXPERIENCE PER COMPANY ：
飞利浦集团台湾源讯 / ERP Consultant， Project Manager，
ERP Product mgr， Practice mgr.
飞利浦显示器事业总部 / SAP Application Manager
台湾飞利浦中坜厂 / MIS Manager
台湾 IBM / ERP Principle Manager， ERP Solution Offering mgr.
宏碁 / Auditor， Controller， Director of PLM &SCM application Div.
SPECIALISATION(专业领域)in ERP/SCM/PLM &IT dept. Management
Business Development (Sales and Marketing)
ERP / SCM / PLM / BI experience
Knowledge Transfer and Documentation Standardization
Budget Control and Rolling Forecasting
Strong manufacturing industry overall know how
Strong ERP / Global Logistics concept
Strong international EDI project management experience
IT Strategy development and management
http://www.fnews.com.cn 2007-08-15 14:16:14 第一时间 已投15 票
各位好。
今天我是代表Acer，我在这里更正一下，Acer已经把制造环节切割。
我今天谈的跟前面谈的有最大的差异，我讲的策略性的规划。
因为Acer从成立到现在已经超过30多年，
在史先生的领导之下，涉及到400家公司，分分合合。我谈的是策划规划，
一个时期我们在谈供应链，我们面对的问题就是由品牌开始，
我们有很多现状，
你如何从比较中长期的规划让整个新Acer的生产线在运筹上、
在经营上是能够一步一步能够配合经营方针达到第三、甚至是第二、第一。
介绍我的经历。我在欧洲的飞利浦公司工作过，
从事标准的制造业。我也在甲骨文公司工作过，
是一家法国公司，标准的做ERP顾问服务的公司。
我目前是在Acer刚工作满六年，
是一个完完全全没有制造品牌的公司。
我分几个主题来谈：第一，和各位介绍一下Acer的演变;
第二，策略性的规划。
前面大家听很多ERP的展开、信息的部件，
那么我要谈的范围更大的一点，我要A2A的供应链，
也会谈到我们执行到现在从短期、中期的状态，最后会做一个结尾。
简单介绍最早Acer是叫“泛宏基”。
2001年三分天下，兄弟爬山各自能力。
所谓的ABW，A代表 Acer，B代表BanQ，W代表伟创。
这三家在2001年成立了新集团各有特色。
Acer只有品牌，我们专注在品牌。
伟创专门从事制造，BanQ有品牌有制造。
我目前服务于Acer。
我现在服务生产，包括笔记本、台式机，还有LCD，DV等等。
先看一看公司的经营方针和策略。
你必须有战略和商业模式，然后你再看ERP怎么套用。
我们的董事长，他的策略很简单，但是做起来比较复杂。
我们叫做“三一三多”，
三个一：一个品牌，一个全球集团、一个团队。
全球我们大概有二三十家公司，然后是一个团队。
“三多”：多产品，多通路，多供应商。
所以这就是我们从2000年开始定的很清楚的目标。
那么我们非直接经销，大家可能马上会想起戴尔，
刚好跟我们看起来是截然不同的方式—直销，
这样听起来会有一个很明显的对照。
戴尔很清楚直销是什么，直接面对消费者，中间没有推销商、没有零售商。这样话可以把库存降低到最低。
戴尔的直销事实上是在美国发迹，
所以美国已经非常习惯在互联网的情况下发展，
戴尔用的是直销+CPO。
Acer 的观点不截然是，从消费者眼光上，
如果今天你要上网看一台电脑，
然后你可能要花到超过六千块或者是七千块的人民币，
你会不会马上买呢?
我想不会。
因为那不是几块钱，这种情况，在欧洲我们也发现了。
欧洲人特性，也是要到实体店看到他想买的笔记本、台式机长的怎么样，
还习惯享受一下杀价的乐趣，
最后才会下单。
所以Acer采取这样一个模式。
当然这里放了一个戴尔的销售模式已经开始调整。
从2003年，戴尔一直是第一，到2006年下半年就一直被HP压着打，
那么HP是现在是第一，那么戴尔是第二。
所以没有永远常胜的将军。你必须跟着你经营环境做调整。
戴尔有直销加上通路，所以戴尔号称是混合式的销售。
我的看法就是第一个，戴尔、HP是以美国做市场，
然后再做到其他的市场。联想是以大陆做市场，然后延伸到德国市场。
索尼、东芝等是以日本做市场，然后延伸到德国。
所以，当你在做市场的时候，你的模式已经做了改变。
当你看到对亚洲来讲是不可能做到的，
要硬把一个不变的DELL模式，他的直销对亚洲来讲，是不可能做到的。
你要另把一个不变的BELL模式，强加一个在一个另外商业管理领域，
你注定会失败。对Acer来讲，没有一个PC的赢家会永远死守在一成不变的模式。
差别只是直销还是营销，在不同商业环境应用的程度和强度。
speed这个世界讲究速度，看到一个商机，别人也会看到商机，
你两个月把产品上架、铺货，人家要六个月，
谁赚到商机，当然是谁越快谁赚到钱。
软件还有ERP，还有谁还在家里自行开发，
你能开发出来已经享受不到利润和效益了，
为什么ERP会大放异彩，
制造业如此，所有的行业都是如此。
这是AcerE2E供应链的介绍。
第一，现在是5个Region有5套不同的ERP。
是5个长的都不一样的ERP。
getorder而是还有一套在台湾。
我们的东西南北中要帮我开拓市场，
所以Region的定位很清楚是开拓市场。
第二，到把订单回敲到总部的时候，
总部的目的是满足订单，
马上交出去，总部是降低采购总成本，
加速产品新开发的时间。
第三，fulfill。我们的合作伙伴对我们来讲是帮我们制作武器的供应商。
有了最强最新的武器，才可以卖到前线。
第五，我们的master是我们的channel，
这是我们简化的供应链的理解。
这5套ERP，QAD在中国也代卖，每套ERP都超过15岁。
Acer也有ERP，我们的策略是当全球统一销售 ERP以后，
我们的既有的ERP也有“三不”政策：不投资、不升级、成本不增加。
用到老死为止。
现状分析：必须了解Acer的现状，在2001年增加之后，
我的是8个Region变成5个Region，
我们在不同的时间、不同的环境、不同的背景下布建起来了，
这些系统不是一个人决定的，因为Acer是由很多家公司合并而成的。
系统和系统之间有一堆的界面做资料的整合。
High Dependencies，当Region系统改了一些系统，这边也要配合改。
这是看Acer现状里最大的痛。
有很多的资料，料耗阻挡，会计科目的阻挡，财务要做汇总报表的时候，
很多资料都要转过来，因为定义文件不同，所以要改。
这个现象是我们的工作环境提供给员工的不是非常有效能的环境，
在没有效能的工作环境中如何要求我们把竞争能力提高，所以我们必须做一些改变。
改变的时候我们讲过策略规划，
先从所有的高阶主管请他们用很简单的白话把他们的期望值，
对信息未来的期望值讲出来。
CEO说，我每天都要看到全球的销售量，
可不可以一个系统按一个键可以看到。每一个Region head，要重新换ERP可以，
但是不要妨碍我的工作。
这就困难了，Chairman说一个系统蓝图到底是什么，
我们必须要全公司都可以清楚的了解。
最终用户说换系统了，是不是很危险。
CIO说所有老板讲得都对，咨询部要做电脑化、信息化的建设，
都使公司更有竞争力。
finance说我们希望有一套快速的系统。
物流部说，Region要求桌面是有批判性，在全球都有价值。
答案很清楚了，我们希望有一套系统，但又不妨碍每个Region做生意，
运营不能够打断，我们的做法短期是小的但是价值很高的项目。
以前我们再逐渐的做到中长期。
还有一个指导原则，不要做一大堆的计划，让系统和系统对接。
这个方法看起来很好，系统和系统对接的任务非常不容易，
因为有不同的运行系统要做很多转换工作。
(图)PLM、ERP、SCM同时导入，因为要维持正常运转。
当一个系统运行最高指导原则很清楚之后，什么叫做一个系统。
(图)一个blueprint，包括B2B、 ERP、PLM、SCM。B2B不是应用系统。
为什么ERP排在B2B的后面，为什么ERP不是老大，
大家不是说ERP是核心吗?
有了ERP才能广泛的伸展到供应链，为什么ERP不可以一口气做。
因为人力、资源、成本都有限。
什么叫做B2B，(图)中HP、Dell、Acer、联想、东芝、苹果都是电脑。
代工有广达、富士康、伟创，是 OEM收入比较高。
下面有一大堆原材料的供应商，到供应商层有上十万家，
这叫做B2B的生态环境。
可以看到有很多材料在中间，
每一天在交换。
ERP从 Acer采购订单，
给富士康，富士康接单排到ERP当成demand，
跑出来还要缺料，还要跟下一轮的供应商跑。
再把计划性订单变成采购订单，
丢给下游的供应商。
每一天有这么多的采购订单、销售订单、出货等等，
这样一个供应链是整个生态。
最大差别是，ERP是企业内部企业资源整合，
供应链是彼此之间的协同运作，
所以ERP是企业的核心，
企业应该根据竞争力要把两手伸开，
要走供应链。
供应链的底层是B2B，每一天都在做数据信息的交换。如果今天没有ERP，
以上的内容还是要发生。
举一个例子，
高速公路可以开到120公里，
开到收费站要交钱，
那时候你的速度会降下来，让你没有办法快。
供应链就在打破这些收费站的速度，要推动速度在ERP里跑，你的过程就完成了。
跑到外面到供应链的时候，就碰到了收费站。B2B就是加速器，
B2B是ERP和supply chain必备的底层。ERP还是核心，从应用系统的角度，
对于Acer已经有五套ERP了，
我是用到不升级、不修改，不加人。
所以B2B变成了第一位。
整个B2B one system长期坚持起来，只有一个系统。
刚才看到5个Region有5个ERP，它还是一套ERP。
get coder还是1套ERP。
第一，B2B的平台在全球ERP和SCM之前准备。
第二，B2B要提供多方的数据流的接受。2002年开始，
DDI能够做的我们都做了，
我们在做马步基本功的扎实，
就像高速公路收费站的速度平均变成高速公路一样的速度。
最近两年，我们领先的技术已经做到成功，
这是我们短、中期的目标已经上线了。
未来长期我们会用一套内销，自己研发的产品，接单、过单、PLM，
不是所有信息化的专案都圆满结束。
有一个国际化的系统还是不稳，所取消掉了。
去年我们导入了Oracle Agile，最后宣布失败。
大家都谈ERP，我谈的是一个比较不一样的策略。ERP导入有那些考虑点，
互联网公司随便找几家。如果有HQ、 China、Europe、PA、AP
到底先上哪一个。如果Acer现在的欧洲的市场占有份额是第一，
那么他就是市场最优先。如果先一步，而且是中国、欧洲，
剩下的当然花在经济上，有不同的考量。
如果公司从零开始，董事长说全部动员，
那么没有问题，那么在欧洲最优先，亚太在最后，
那么最后你还是要做一个决定。
所有的企业都在追求卓越，time时间和市场是追求竞争力的不二法门。
没有核心不可能向外发展，供应使ERP两手伸出去。数据库的建设，
B2B是ERP和SCM的加速器。当想ERP信息化建设的时候，如果企业跟很多的供应商或者客户，
假如客户够大，有自己的 ERP，当数据流在交换可以变成B2B的时候，不是只有你赢，大家都赢。
在供应链里谈的是“协同”。SUB-control是一个世界潮流，富士康是世界领域，只是他们用的不一样，
而富士康是ODM，广达是CMMS。神州数码是整个大中华的第一，
我们选最强的来合作。同样的world wide发生在软件的环境里，ERP这样的东西自己在家开发绝对来不及。
IT策略永远要跟着市场的策略做调整，特别要小心并购跟合并，
你可能选了一个厂商很有名，可是它在美国，
而美国最近几年一下子会淘汰掉，所以很难掌控。
当地资源可能是一个最重要的决定关键。
我们把董事长讲的话再重复：最后的致胜的关键，
不局限在Acer internal弹性与速度，
而是需要和ODM、关键的零组建商、通路配销运筹业者等合作伙伴，
能否快速且有弹性的完美配合。
我们看Acer的供应链分享是不是只做自己，
要跟供应链里面的渠道，
我们的ODM和我们的关键供应商要利用B2B加速两边的整合。
永乐和苏宁也在谈，现在是大者恒大，联想在大陆是第一，但是不是全球市场，
要做到全球，合并和并购的策略就出来了。所以才有IBM和联想的合作，
实现在美国的扩张。透过专业的分工是world wide的精髓，透过专业分工，
你就可以快速反映市场变化的速度。
回到ERP WORLD2007年，ERP的核心我有两个，第一，ERP的核心有两个“lier”，
就是B2B的建制。如果今天能够把B2B的速度跟合作伙伴一起努力打破的话，
就比别人快一步了。第二，如果把核心再拆到更核心的时候，
所有的东西在ERP里面都是data，数据地上满街都是，
要把数据变成有用的资讯为主管做决策就是信息，这就要靠流程。当你在延伸，
把ERP做好，只不过是把企业内部的数据变成了自己的信息，
如果要跟渠道合作伙伴做更加深入的延伸加速运筹，数据比ERP更麻烦，
料耗到别的系统还是这样的料耗吗?
这样传过来是否要转换?今天要做好就要把服务做好，
我们要从ODM来，富士康有自己的料耗。
同样的东西在不同的企业里料耗分工不一样，
这就是一个大问号。ERP谈的是B2B的建制，
ERP本身就是一个供应链的核心，这是无可厚非的。
如果能把B2B 建制好，就比别人快一个脚步。
ERP真正的核心从数据来讲，是怎么把数据变成信息，
是要通过好的设计。谈到供应链把数据变成信息就更困难了，
因为料耗不一样，这是一个很困难的问题。
感谢各位听我演讲，谢谢大家。
嘉宾介绍：宏碁 杨天明处长
WORKING EXPERIENCE PER COMPANY ：
飞利浦集团台湾源讯 / ERP Consultant， Project Manager，
ERP Product mgr， Practice mgr.
飞利浦显示器事业总部 / SAP Application Manager
台湾飞利浦中坜厂 / MIS Manager
台湾 IBM / ERP Principle Manager， ERP Solution Offering mgr.
宏碁 / Auditor， Controller， Director of PLM &SCM application Div.
SPECIALISATION(专业领域)in ERP/SCM/PLM &IT dept. Management
Business Development (Sales and Marketing)
ERP / SCM / PLM / BI experience
Knowledge Transfer and Documentation Standardization
Budget Control and Rolling Forecasting
Strong manufacturing industry overall know how
Strong ERP / Global Logistics concept
Strong international EDI project management experience
IT Strategy development and management
而自動產生料號的時間也只要10分鐘 笑死人!!!!
而自動產生料號的時間也只要10分鐘 笑死人!!!!
每分鐘要去檢查一次
每次轉入 10秒內轉換完成
有錢的公司真的很好笑 笑死人!!!!
高達90％的料號都可以自動產出，???
那部被罵死才怪!!!
有錢的公司真的很好笑 笑死人!!!!
宏碁PLM自動產生料號只要10分鐘
文/楊惠芬 (記者) 2010-01-27
宏碁採取階段式導入的做法，
PLM系統上線至今，
已經有200多個主要專案是在PLM平臺上進行，
而自動產生料號的時間也只要10分鐘
宏碁（Acer）在跨入品牌經營之後，為了加速產品推陳出新速度，
2004年首度導入產品生命周期管理（PLM），
最終卻因全面一次上線的計畫過於龐大等種種因素以失敗收場，
也讓宏碁的PLM導入專案停滯了2年之久，
直到2006年才又再度著手評估。這一次，
宏碁決定採取階段式導入的做法，
上線至今，
已經有200多個主要專案是在PLM平臺上進行，
而自動產生料號的時間也只要10分鐘。
宏碁資訊技術總處PLM／SCM應用系統處處長楊天明指出，
在導入PLM之前，
宏碁總部的資料中心編制了4名人力，
專門負責料號申請作業，
來因應全球各個區域新接訂單的料號申請需求，
PLM系統上線後，料號申請作業邁入自動化階段，
一般情況下，高達90％的料號都可以自動產出，
系統可以根據訂單組出規格並且產生料號，
而整個過程只需要10分鐘。
目前料號申請作業只需要0.25名人力來做事後查核即可，
而總部的資料中心與人力可以由低階的資料輸入工作，轉向策略性的工作，
例如：洽談使用者需求以及持續強化系統開發等。
宏碁在陸續導入物料清單與專案組合管理等功能模組後，
又延伸發展出預測規畫（Planning BOM）等應用。
文⊙楊惠芬
宏碁的PLM應用已涵蓋到行銷（Marketing BOM）與服務（Service BOM）等構面。
每分鐘要去檢查一次
每次轉入 10秒內轉換完成
有錢的公司真的很好笑 笑死人!!!!
高達90％的料號都可以自動產出，???
那部被罵死才怪!!!
有錢的公司真的很好笑 笑死人!!!!
宏碁PLM自動產生料號只要10分鐘
文/楊惠芬 (記者) 2010-01-27
宏碁採取階段式導入的做法，
PLM系統上線至今，
已經有200多個主要專案是在PLM平臺上進行，
而自動產生料號的時間也只要10分鐘
宏碁（Acer）在跨入品牌經營之後，為了加速產品推陳出新速度，
2004年首度導入產品生命周期管理（PLM），
最終卻因全面一次上線的計畫過於龐大等種種因素以失敗收場，
也讓宏碁的PLM導入專案停滯了2年之久，
直到2006年才又再度著手評估。這一次，
宏碁決定採取階段式導入的做法，
上線至今，
已經有200多個主要專案是在PLM平臺上進行，
而自動產生料號的時間也只要10分鐘。
宏碁資訊技術總處PLM／SCM應用系統處處長楊天明指出，
在導入PLM之前，
宏碁總部的資料中心編制了4名人力，
專門負責料號申請作業，
來因應全球各個區域新接訂單的料號申請需求，
PLM系統上線後，料號申請作業邁入自動化階段，
一般情況下，高達90％的料號都可以自動產出，
系統可以根據訂單組出規格並且產生料號，
而整個過程只需要10分鐘。
目前料號申請作業只需要0.25名人力來做事後查核即可，
而總部的資料中心與人力可以由低階的資料輸入工作，轉向策略性的工作，
例如：洽談使用者需求以及持續強化系統開發等。
宏碁在陸續導入物料清單與專案組合管理等功能模組後，
又延伸發展出預測規畫（Planning BOM）等應用。
文⊙楊惠芬
宏碁的PLM應用已涵蓋到行銷（Marketing BOM）與服務（Service BOM）等構面。
杨天明和Acer的缘分还真不是一个“巧”字了得
一個公司不會有 5個 ERP 系統
一個公司會有 5個以上的系統
ERP 是以能對應產出正確財報
需要調整 SAP/Oracle 會計引擎核心
你絕對不可能會有五套 ERP 系統
也就是你不可能有五套 系統可以產生正確的 財務報表!!!!
進貨銷貨單據 要能對應正確會計科目都不是一見簡單的事
你怎麼會有 五套 ERP 系統
像我智商 145 會計經驗 20年 程式經驗 20年
才可能有能力
杨天明和Acer的缘分还真不是一个“巧”字了得，
被杨天明整合的多套ERP系统，
大部分是杨天明在做销售期间卖给Acer的。
见到宏碁股份有限公司（Acer）PLM/SCM应用系统处处长杨天明
是在神州数码的中国ERP行业峰会上，
久居宝岛台湾的杨天明每次的祖国大陆之行都形色匆匆，
“我明天就要赶往上海，
后天就要返回台湾。”
忙碌的节奏下，有条不紊的高效率处理工作，
之于杨天明就成了一种必须，也成为了一种习惯。
5套同时运转的ERP
看到Acer现在的管理模式的人，是无法想象3年前的状态的。
当时Acer内部大概有5套以上的ERP同时使用。
这种状况与Acer的背景有关，2001年，
Acer分家，成为三家具有不同特性的公司。
Acer专攻品牌，不管制造；伟创专营制造加工；
Acer则是既有品牌又有制造。
2001年分家之后的新Acer，
一时间承继了很多老公司的若干个相关体制，
“所以那个时候除了我们总部之外，东南西北每个地区都有一套系统，
加起来有超过5套的 ERP同时运转。”
这种状况让Acer集团董事长施振荣头痛不已，问题频频发生。
“你会碰到两个最困难的事情，每个ERP料品主导各自为政，会计科目也是各自为政。”
杨天明认为在ERP的环境里面有两个核心，
一个是全部统一的料品主导，
在公司企业的内部全部是统一的，
第二就是一套会计科目，
对于一个公司，财务方面是最容不得差异性的，
如果一个地区和另一个地区的会计科目不一致，
无法统一核算，
对于一个公司是很危险的事。
这种情况下，整合系统就成为Acer最急切的事情。
而杨天明和Acer的缘分还真不是一个“巧”字了得，
在Acer内部运转的这多套ERP系统，
大部分是杨天明在做销售期间卖给Acer的。
对于 Acer内部的ERP构造，
目前使用的多套ERP系统的功用性能，
他都无比了解。
也正基于他对Acer内各套ERP系统的了解，
整合中他的意见被领导非常重视。
整合系统的急迫也与Acer的运营模式有关，
Acer集团董事长施振荣曾用餐饮业来形容计算机市场。
他认为，中国餐馆遍布全球，
中国菜也经济实惠，但是缺乏企业化经营，
品质良莠不齐，因此，缺乏高水准的形象。
这就如同采用宝岛台湾主机板的计算机厂商，
也是全世界到处林立，但是产品品质参差不齐，
没有品牌形象可言。而麦当劳以简单的菜单、企业化经营、统一的品牌，
成为全球性连锁速食店。
因此，Acer要取全球各地相容计算机厂商之长，
并以麦当劳的“速食店”运作模式避免其缺点。
所谓“速食店模式”，就是将原来在台湾生产计算机整机，
转变为台湾生产主机板、外壳装置、监视器等组件，
卖给其海外事业单位（即海外子公司），
在市场当地组装，向市场提供最新的计算机，
加快新产品推出与库存周转速度。
推行这种模式之后，Acer的库存周转速度加快了1倍，
不但降低了经营风险，而且也为新产品上市创造了有利条件；
新产品上市时间提前了1个月；
由于库存降低，出清存货的时间也随之缩短，推出新产品就更具时效优势。
更为重要的是，在模式改变之后，Acer的产品能够紧随消费者需求的变化而变化。
Acer一直奉行的“速食店模式”，
越发对Acer的系统统一提出了要求。
而Acer配销方面也没有一个统一的料号，对于同一个物品，
在两地同时销售，却因为料号不一样重复销售，还有在同样料号下面，却是不同的物品。
现状已经容不得Acer在拖延下去，2005年春季，
Acer与神州数码敲定了合作事项。
杨天明在选择ERP时的考量是，
第一，要有本地资源；
第二，能够满足Acer的业务需求，
此外还要简体、繁体同时具备的系统。
月结的飞跃
在加入Acer之前，杨天明在飞利浦工作，飞利浦的全球月结只需要三天，
总财务CFO就可以拿到报告，
而Acer的五套ERP，一个个结下来，
是一个月也结不完的。而时间就是金钱，
所以杨天明果断决定，
从财务系统开始整合。
在和神州数码签订合同不到一年的时间里，
Acer的分公司基本全部布置完毕，动作迅速。
“一旦开始，我们决不拖拉，时间耽误不起。”
在与神州数码沟通之后，杨天明觉得ERP是一个全方位的系统，
包含着配送、制造、财务，但是Acer的现状是财务问题最急迫，
所以先切财务系统。也有人问过杨天明，配销为什么不一起做？
“如果你的公司从零开始，你很容易跨出这一步，
如果你的公司已经有相当的规模，
全球性组织的时候，势必你的人力、资源、现行的系统，还要做一些更新，
这些都需要投入人力、成本。这样考虑下公司的运转还是要继续，
也不需要对你的生意和营运做很大冲击的时候，我们就会选择流程管理先做。
因为财务在后面，报税都是标准的秩序可以跟随的话，我们先做财务这方面的平整。”
2001年Acer的分家，把制造全部隔离出来，
所以杨天明对所有相关领导强调，
是Acer股份有限公司，
不是Acer电脑股份有限公司。
“因为以前Acer电脑是有制造的，
就产生很多ERP。
所以在这种前提下，你只能做选择性的导入，
就跟我们ERP常常讲的，如果这家公司原来没有，
我们原来讲是全面性的导入，
一口气全部上，碰到这种情况，
你的营运还得继续你公司的经营方针，
比如说我们希望2005年达到第四，
我们希望2008年冲到第三，
你在冲的过程中，这里再给你改，
那里再给你换，最重要是讲究人力比较精简。”
而杨天明的目的是把财务做到两点，
一是同一套的会计科目，二是各地能够同时做财务的汇总，
像财务报表等，全部可以同时做出来。
夫妻店&连锁店
现在回头看Acer ERP建设的选型，杨天明深感欣慰。
在选择神州数码的时候，
Acer也曾经考虑过甲骨文，
Acer的高层在瑞士与甲骨文用了一个星期的时间进行过一次彻谈，
在加加减减后算出的所需费用，
在杨天明看来是要吓死人的。
ERP选型，在杨天明看来，
和公司的规模、业务范围是紧密相关的。
杨天明把这叫做夫妻店和连锁店的分别。
如果是夫妇两人草创一家小店，
刚开始账本用手工做完全足够，
也可以叫ERP，原始状态的ERP。
当发展到一种规模，成为具有20多人规模的公司时，
原来的做法就没有实效了，
就需要一台电脑来帮助公司实施管理，
这是初级阶段的ERP。而再进一步，
公司成长为连锁经营时，ERP就真正派上用场了。
所以企业在不同的规模要慎选适合它体制的ERP。
在适当的时机、适当的成本、有限的人力，
各种条件综合考量之下，
Acer的ERP选型在杨天明看来十分清晰，
“我们希望能够不到两年时间就把各地的财务全部整合起来，
结果，我们做到了。”
无止境的IT
在问到杨天明的个人休闲计划时，他的表情有些无奈，
“其实信息化的工作是无止境的，所以永远有做不完的事，
休假也只能是忙里偷闲，很难有整块的休闲安排。”
但是，提到工作安排杨天明倒是侃侃谈来。
Acer的ERP建设是从2001年就开始规划的，
面对未来，杨天明看到的不仅是一个ERP。
Acer用ERP已经有15年的经验。ERP是企业的管理核心，
可是ERP是针对企业内部管理的，在企业内部规做完之后，加强市场竞争力，
“你要把手伸出去，你公司做得再好，售后服务、资源服务做得不好，
用户还是要放弃你，”杨天明希望的将来是
“以ERP为核心，慢慢把这些环节像珠子一样串起来，
让领导面对的界面越来越少。”
企业要朝向第一的目标进步，
有些问题就不能回避，在IT投入上，
杨天明总是用生活中的必需品来作衡量，
“年年都有物品涨价，石油更是狂涨，
今年看物价会跌下来吗？不会。
信息化建设也是如此，年年投入的价目表都在增长。
如果不整合，整个企业的痛还会继续，必须要做得，
与其晚做还不如早做，能够早一年就是节约一年。
”在这种思想下，Acer的信息化建设一步步领先发展。
一個公司會有 5個以上的系統
ERP 是以能對應產出正確財報
需要調整 SAP/Oracle 會計引擎核心
你絕對不可能會有五套 ERP 系統
也就是你不可能有五套 系統可以產生正確的 財務報表!!!!
進貨銷貨單據 要能對應正確會計科目都不是一見簡單的事
你怎麼會有 五套 ERP 系統
像我智商 145 會計經驗 20年 程式經驗 20年
才可能有能力
杨天明和Acer的缘分还真不是一个“巧”字了得，
被杨天明整合的多套ERP系统，
大部分是杨天明在做销售期间卖给Acer的。
见到宏碁股份有限公司（Acer）PLM/SCM应用系统处处长杨天明
是在神州数码的中国ERP行业峰会上，
久居宝岛台湾的杨天明每次的祖国大陆之行都形色匆匆，
“我明天就要赶往上海，
后天就要返回台湾。”
忙碌的节奏下，有条不紊的高效率处理工作，
之于杨天明就成了一种必须，也成为了一种习惯。
5套同时运转的ERP
看到Acer现在的管理模式的人，是无法想象3年前的状态的。
当时Acer内部大概有5套以上的ERP同时使用。
这种状况与Acer的背景有关，2001年，
Acer分家，成为三家具有不同特性的公司。
Acer专攻品牌，不管制造；伟创专营制造加工；
Acer则是既有品牌又有制造。
2001年分家之后的新Acer，
一时间承继了很多老公司的若干个相关体制，
“所以那个时候除了我们总部之外，东南西北每个地区都有一套系统，
加起来有超过5套的 ERP同时运转。”
这种状况让Acer集团董事长施振荣头痛不已，问题频频发生。
“你会碰到两个最困难的事情，每个ERP料品主导各自为政，会计科目也是各自为政。”
杨天明认为在ERP的环境里面有两个核心，
一个是全部统一的料品主导，
在公司企业的内部全部是统一的，
第二就是一套会计科目，
对于一个公司，财务方面是最容不得差异性的，
如果一个地区和另一个地区的会计科目不一致，
无法统一核算，
对于一个公司是很危险的事。
这种情况下，整合系统就成为Acer最急切的事情。
而杨天明和Acer的缘分还真不是一个“巧”字了得，
在Acer内部运转的这多套ERP系统，
大部分是杨天明在做销售期间卖给Acer的。
对于 Acer内部的ERP构造，
目前使用的多套ERP系统的功用性能，
他都无比了解。
也正基于他对Acer内各套ERP系统的了解，
整合中他的意见被领导非常重视。
整合系统的急迫也与Acer的运营模式有关，
Acer集团董事长施振荣曾用餐饮业来形容计算机市场。
他认为，中国餐馆遍布全球，
中国菜也经济实惠，但是缺乏企业化经营，
品质良莠不齐，因此，缺乏高水准的形象。
这就如同采用宝岛台湾主机板的计算机厂商，
也是全世界到处林立，但是产品品质参差不齐，
没有品牌形象可言。而麦当劳以简单的菜单、企业化经营、统一的品牌，
成为全球性连锁速食店。
因此，Acer要取全球各地相容计算机厂商之长，
并以麦当劳的“速食店”运作模式避免其缺点。
所谓“速食店模式”，就是将原来在台湾生产计算机整机，
转变为台湾生产主机板、外壳装置、监视器等组件，
卖给其海外事业单位（即海外子公司），
在市场当地组装，向市场提供最新的计算机，
加快新产品推出与库存周转速度。
推行这种模式之后，Acer的库存周转速度加快了1倍，
不但降低了经营风险，而且也为新产品上市创造了有利条件；
新产品上市时间提前了1个月；
由于库存降低，出清存货的时间也随之缩短，推出新产品就更具时效优势。
更为重要的是，在模式改变之后，Acer的产品能够紧随消费者需求的变化而变化。
Acer一直奉行的“速食店模式”，
越发对Acer的系统统一提出了要求。
而Acer配销方面也没有一个统一的料号，对于同一个物品，
在两地同时销售，却因为料号不一样重复销售，还有在同样料号下面，却是不同的物品。
现状已经容不得Acer在拖延下去，2005年春季，
Acer与神州数码敲定了合作事项。
杨天明在选择ERP时的考量是，
第一，要有本地资源；
第二，能够满足Acer的业务需求，
此外还要简体、繁体同时具备的系统。
月结的飞跃
在加入Acer之前，杨天明在飞利浦工作，飞利浦的全球月结只需要三天，
总财务CFO就可以拿到报告，
而Acer的五套ERP，一个个结下来，
是一个月也结不完的。而时间就是金钱，
所以杨天明果断决定，
从财务系统开始整合。
在和神州数码签订合同不到一年的时间里，
Acer的分公司基本全部布置完毕，动作迅速。
“一旦开始，我们决不拖拉，时间耽误不起。”
在与神州数码沟通之后，杨天明觉得ERP是一个全方位的系统，
包含着配送、制造、财务，但是Acer的现状是财务问题最急迫，
所以先切财务系统。也有人问过杨天明，配销为什么不一起做？
“如果你的公司从零开始，你很容易跨出这一步，
如果你的公司已经有相当的规模，
全球性组织的时候，势必你的人力、资源、现行的系统，还要做一些更新，
这些都需要投入人力、成本。这样考虑下公司的运转还是要继续，
也不需要对你的生意和营运做很大冲击的时候，我们就会选择流程管理先做。
因为财务在后面，报税都是标准的秩序可以跟随的话，我们先做财务这方面的平整。”
2001年Acer的分家，把制造全部隔离出来，
所以杨天明对所有相关领导强调，
是Acer股份有限公司，
不是Acer电脑股份有限公司。
“因为以前Acer电脑是有制造的，
就产生很多ERP。
所以在这种前提下，你只能做选择性的导入，
就跟我们ERP常常讲的，如果这家公司原来没有，
我们原来讲是全面性的导入，
一口气全部上，碰到这种情况，
你的营运还得继续你公司的经营方针，
比如说我们希望2005年达到第四，
我们希望2008年冲到第三，
你在冲的过程中，这里再给你改，
那里再给你换，最重要是讲究人力比较精简。”
而杨天明的目的是把财务做到两点，
一是同一套的会计科目，二是各地能够同时做财务的汇总，
像财务报表等，全部可以同时做出来。
夫妻店&连锁店
现在回头看Acer ERP建设的选型，杨天明深感欣慰。
在选择神州数码的时候，
Acer也曾经考虑过甲骨文，
Acer的高层在瑞士与甲骨文用了一个星期的时间进行过一次彻谈，
在加加减减后算出的所需费用，
在杨天明看来是要吓死人的。
ERP选型，在杨天明看来，
和公司的规模、业务范围是紧密相关的。
杨天明把这叫做夫妻店和连锁店的分别。
如果是夫妇两人草创一家小店，
刚开始账本用手工做完全足够，
也可以叫ERP，原始状态的ERP。
当发展到一种规模，成为具有20多人规模的公司时，
原来的做法就没有实效了，
就需要一台电脑来帮助公司实施管理，
这是初级阶段的ERP。而再进一步，
公司成长为连锁经营时，ERP就真正派上用场了。
所以企业在不同的规模要慎选适合它体制的ERP。
在适当的时机、适当的成本、有限的人力，
各种条件综合考量之下，
Acer的ERP选型在杨天明看来十分清晰，
“我们希望能够不到两年时间就把各地的财务全部整合起来，
结果，我们做到了。”
无止境的IT
在问到杨天明的个人休闲计划时，他的表情有些无奈，
“其实信息化的工作是无止境的，所以永远有做不完的事，
休假也只能是忙里偷闲，很难有整块的休闲安排。”
但是，提到工作安排杨天明倒是侃侃谈来。
Acer的ERP建设是从2001年就开始规划的，
面对未来，杨天明看到的不仅是一个ERP。
Acer用ERP已经有15年的经验。ERP是企业的管理核心，
可是ERP是针对企业内部管理的，在企业内部规做完之后，加强市场竞争力，
“你要把手伸出去，你公司做得再好，售后服务、资源服务做得不好，
用户还是要放弃你，”杨天明希望的将来是
“以ERP为核心，慢慢把这些环节像珠子一样串起来，
让领导面对的界面越来越少。”
企业要朝向第一的目标进步，
有些问题就不能回避，在IT投入上，
杨天明总是用生活中的必需品来作衡量，
“年年都有物品涨价，石油更是狂涨，
今年看物价会跌下来吗？不会。
信息化建设也是如此，年年投入的价目表都在增长。
如果不整合，整个企业的痛还会继续，必须要做得，
与其晚做还不如早做，能够早一年就是节约一年。
”在这种思想下，Acer的信息化建设一步步领先发展。
2010年4月16日 星期五
笑看 學生幫教授打成績 ERP顧問公司之評量與選擇
笑看 學生幫教授打成績 ERP顧問公司之評量與選擇
親愛的企業先進鈞鑒：
百忙之中，煩勞您撥空填寫問卷，實在感激之至！
這是一份有關碩士論文的學術研究問卷，
目的是欲了解 貴公司於選擇與評量協助ERP導入之顧問公司時，
對於各項ERP顧問公司評選指標之重視程度。
敬請您就 貴公司實際選擇與評量ERP顧問公司之情況，
對各評量指標之重要性進行評估。
由於資訊部門在ERP顧問公司之評選過程中扮演重要的角色，
故冒昧請您參與本研究之調查，
懇切希望獲得 貴公司之支持，
以使研究能順利進行分析及完成。
懇請將本問卷惠請
貴公司高階主管、ERP專案成員或資訊部門人員撥冗填答。
同時，
您於本問卷內所填之各項資料僅供論文研究之用，
並僅作整體性之分析，
絕對不會披露個別資料，
敬請您放心填答。
若有題意不清或疑問之處，
務請不吝嗇提出您的寶貴意見。
最後，再次懇請惠予協助，謹此敬致謝忱！
敬頌
崇祺
國立中央大學企業管理研究所
指導教授何應欽 博士
研究生林燕妮 敬託
中華民國九十九年四月
聯絡地址：32001桃園縣中壢市中大路300號中央大學企業管理學系林燕妮收
聯絡電話：0911-187-523
E-mail：cuteqny@gmail.com
* Required
一、問卷填寫背景說明
在ERP顧問公司之評選構面中，
包含了
專業能力、
服務品質、
合夥關係建立與維持、
經營能力、
收費標準共五個評量構面。
>> 買菜當然買最出名
>> 買菜當然買最多人買
>> 買菜當然買品質穩定
>> 買菜當然買準時供應
?? 這是賣菜的 專業能力
?? 這是賣菜的 專業能力
?? 這是賣菜的 合夥關係
但是這是餐廳要的
還是賣菜要的
??
同時，
各評量構面分別有其所屬之評量指標，
以下請您就 貴公司於評選ERP顧問公司時，
對於各評量指標的重視程度進行勾選
（
1代表該評量指標是極不重要的，
5代表該評量指標是極重要的
），
再次感謝您所提供的協助，謝謝您！ *
* 已閱讀
第一部分 ─ 專業能力構面
1.專案管理能力 * 指顧問公司於 貴公司的ERP導入專案中，控管專案進度、品質以及協調各項資源的能力。
2.企業所處產業之專業知識與導入經驗 * 指顧問公司對 貴公司所處產業之環境、實務、運作流程等相關專業知識的了解，以及在同產業中，協助其他公司導入ERP的經驗。
3.ERP系統與延伸性軟體之專業知識 * 指顧問公司對於 貴公司欲導入的ERP系統，以及可提升ERP系統性能的延伸性軟體（如：APS、CAD、SCM、CRM…等）所具備的專業知識。
4.流程再造之能力與經驗 * 指顧問公司於 貴公司導入ERP時，協助進行內部流程修改、調整的能力與經驗。
5.差異化分析能力 * 指顧問公司在協助 貴公司導入ERP時，協助釐清ERP系統功能與 貴公司需求之間的差異，並提出調整方案的能力。
6.系統客製化能力 * 指當欲導入的ERP系統在某部分無法符合 貴公司的作業流程時，顧問公司協助開發並測試客製化程式的能力。
第二部分 ─ 服務品質構面
1.顧問諮詢 * 指顧問公司提供給 貴公司的顧問諮詢，包括服務形式、時間長短、資源數量以及顧問團隊之品質。
2.導入方法論 * 指顧問公司協助 貴公司導入ERP的系統建置方法或建置程序。
3.教育訓練 * 指顧問公司提供給 貴公司的使用者教育訓練。
4.後續服務 * 指顧問公司在ERP導入專案完成後，提供給 貴公司的後續服務，包含系統日常維護、成效追蹤、系統升級等項目。
第三部分 ─ 合夥關係建立與維持構面
1.團隊溝通能力 * 指在ERP導入專案團隊中，顧問群與 貴公司參與專案的人員，彼此能有良好的溝通並且相互配合。
2.與企業有一致的專案目標 * 指顧問公司與 貴公司雙方皆對ERP導入專案的內容與目標，有明確且一致的共識。
3.與企業彼此之相互信任 * 指顧問公司能與 貴公司相互信任，對彼此抱持正面的態度與預期，並期望未來一定可以合作愉快。
4.合作夥伴關係之持續性 * 指顧問公司能與 貴公司建立良好的夥伴關係，並持續延續雙方未來的交易或合作關係。
第四部分 ─ 經營能力構面
1.顧問公司經營穩定性 * 指顧問公司經營狀況之穩健度，包括公司規模、經營方向與其財務穩固性等。
2.資源完整性 * 指顧問公司在服務項目、合作夥伴、顧問人力、支援據點等資源上的完整性。
3.創新學習 * 指顧問公司持續學習新知識與新技術，並持續改善其服務內容。
4.顧問流動率 * 指顧問公司內部的顧問人員流動率。
5.聲譽 * 指顧問公司在 貴公司所處產業中，具有高知名度與良好聲望。
第五部分 ─ 收費標準構面
1.明確且合理的收費結構 * 指顧問公司在合約中明確地列出計價事項與合理的計費標準。
2.顧問輔導費用 * 指顧問公司針對協助 貴公司建置ERP系統與進行企業流程再造所酌收之輔導費用的低廉性。
>> 不要去壓低別人的價值
>> 我們都是另給獎金紅包
>> 力求上線顧問單價 200%最大化 (另給個人100% 獎金)
>> 力求時間最小化
>> 800工天 * 2.5萬 = 2000萬 >> 200工天 * 5萬 = 1000萬
>> 最完整上線前討論規劃 再導入前先自己導入模擬出衝突點
3.程式客製化費用 * 指顧問公司針對協助 貴公司進行系統客製化程式開發與測試所酌收的費用。
4.費用回饋制度 * 指在ERP導入專案完成之後，
貴公司若再額外要求的其他服務項目，
顧問公司對老客戶在收費上的費用回饋制度（如：折扣）。
>> 導入顧問就像畫面功能設定導覽員
>> 你在導覽過程不紀錄不分析不學習
>> 還要他幫你導第二次
>> 一般顧問平均智商才 120
>> 哪你的智商是不是才 100
親愛的企業先進鈞鑒：
百忙之中，煩勞您撥空填寫問卷，實在感激之至！
這是一份有關碩士論文的學術研究問卷，
目的是欲了解 貴公司於選擇與評量協助ERP導入之顧問公司時，
對於各項ERP顧問公司評選指標之重視程度。
敬請您就 貴公司實際選擇與評量ERP顧問公司之情況，
對各評量指標之重要性進行評估。
由於資訊部門在ERP顧問公司之評選過程中扮演重要的角色，
故冒昧請您參與本研究之調查，
懇切希望獲得 貴公司之支持，
以使研究能順利進行分析及完成。
懇請將本問卷惠請
貴公司高階主管、ERP專案成員或資訊部門人員撥冗填答。
同時，
您於本問卷內所填之各項資料僅供論文研究之用，
並僅作整體性之分析，
絕對不會披露個別資料，
敬請您放心填答。
若有題意不清或疑問之處，
務請不吝嗇提出您的寶貴意見。
最後，再次懇請惠予協助，謹此敬致謝忱！
敬頌
崇祺
國立中央大學企業管理研究所
指導教授何應欽 博士
研究生林燕妮 敬託
中華民國九十九年四月
聯絡地址：32001桃園縣中壢市中大路300號中央大學企業管理學系林燕妮收
聯絡電話：0911-187-523
E-mail：cuteqny@gmail.com
* Required
一、問卷填寫背景說明
在ERP顧問公司之評選構面中，
包含了
專業能力、
服務品質、
合夥關係建立與維持、
經營能力、
收費標準共五個評量構面。
>> 買菜當然買最出名
>> 買菜當然買最多人買
>> 買菜當然買品質穩定
>> 買菜當然買準時供應
?? 這是賣菜的 專業能力
?? 這是賣菜的 專業能力
?? 這是賣菜的 合夥關係
但是這是餐廳要的
還是賣菜要的
??
同時，
各評量構面分別有其所屬之評量指標，
以下請您就 貴公司於評選ERP顧問公司時，
對於各評量指標的重視程度進行勾選
（
1代表該評量指標是極不重要的，
5代表該評量指標是極重要的
），
再次感謝您所提供的協助，謝謝您！ *
* 已閱讀
第一部分 ─ 專業能力構面
1.專案管理能力 * 指顧問公司於 貴公司的ERP導入專案中，控管專案進度、品質以及協調各項資源的能力。
2.企業所處產業之專業知識與導入經驗 * 指顧問公司對 貴公司所處產業之環境、實務、運作流程等相關專業知識的了解，以及在同產業中，協助其他公司導入ERP的經驗。
3.ERP系統與延伸性軟體之專業知識 * 指顧問公司對於 貴公司欲導入的ERP系統，以及可提升ERP系統性能的延伸性軟體（如：APS、CAD、SCM、CRM…等）所具備的專業知識。
4.流程再造之能力與經驗 * 指顧問公司於 貴公司導入ERP時，協助進行內部流程修改、調整的能力與經驗。
5.差異化分析能力 * 指顧問公司在協助 貴公司導入ERP時，協助釐清ERP系統功能與 貴公司需求之間的差異，並提出調整方案的能力。
6.系統客製化能力 * 指當欲導入的ERP系統在某部分無法符合 貴公司的作業流程時，顧問公司協助開發並測試客製化程式的能力。
第二部分 ─ 服務品質構面
1.顧問諮詢 * 指顧問公司提供給 貴公司的顧問諮詢，包括服務形式、時間長短、資源數量以及顧問團隊之品質。
2.導入方法論 * 指顧問公司協助 貴公司導入ERP的系統建置方法或建置程序。
3.教育訓練 * 指顧問公司提供給 貴公司的使用者教育訓練。
4.後續服務 * 指顧問公司在ERP導入專案完成後，提供給 貴公司的後續服務，包含系統日常維護、成效追蹤、系統升級等項目。
第三部分 ─ 合夥關係建立與維持構面
1.團隊溝通能力 * 指在ERP導入專案團隊中，顧問群與 貴公司參與專案的人員，彼此能有良好的溝通並且相互配合。
2.與企業有一致的專案目標 * 指顧問公司與 貴公司雙方皆對ERP導入專案的內容與目標，有明確且一致的共識。
3.與企業彼此之相互信任 * 指顧問公司能與 貴公司相互信任，對彼此抱持正面的態度與預期，並期望未來一定可以合作愉快。
4.合作夥伴關係之持續性 * 指顧問公司能與 貴公司建立良好的夥伴關係，並持續延續雙方未來的交易或合作關係。
第四部分 ─ 經營能力構面
1.顧問公司經營穩定性 * 指顧問公司經營狀況之穩健度，包括公司規模、經營方向與其財務穩固性等。
2.資源完整性 * 指顧問公司在服務項目、合作夥伴、顧問人力、支援據點等資源上的完整性。
3.創新學習 * 指顧問公司持續學習新知識與新技術，並持續改善其服務內容。
4.顧問流動率 * 指顧問公司內部的顧問人員流動率。
5.聲譽 * 指顧問公司在 貴公司所處產業中，具有高知名度與良好聲望。
第五部分 ─ 收費標準構面
1.明確且合理的收費結構 * 指顧問公司在合約中明確地列出計價事項與合理的計費標準。
2.顧問輔導費用 * 指顧問公司針對協助 貴公司建置ERP系統與進行企業流程再造所酌收之輔導費用的低廉性。
>> 不要去壓低別人的價值
>> 我們都是另給獎金紅包
>> 力求上線顧問單價 200%最大化 (另給個人100% 獎金)
>> 力求時間最小化
>> 800工天 * 2.5萬 = 2000萬 >> 200工天 * 5萬 = 1000萬
>> 最完整上線前討論規劃 再導入前先自己導入模擬出衝突點
3.程式客製化費用 * 指顧問公司針對協助 貴公司進行系統客製化程式開發與測試所酌收的費用。
4.費用回饋制度 * 指在ERP導入專案完成之後，
貴公司若再額外要求的其他服務項目，
顧問公司對老客戶在收費上的費用回饋制度（如：折扣）。
>> 導入顧問就像畫面功能設定導覽員
>> 你在導覽過程不紀錄不分析不學習
>> 還要他幫你導第二次
>> 一般顧問平均智商才 120
>> 哪你的智商是不是才 100
2010年4月15日 星期四
ERP 如何正確挑選合適的SAP顧問公司？
ERP 如何正確挑選合適的SAP顧問公司？
資料來源::
http://ahkuo.blog.ithome.com.tw/post/1114/18372
由 CKHiseh 發表於 [ General ]
(3391) 閱讀, (0) 引用, (4) 回應 , 推文( 0 )
一般客戶在選擇SAP系統時，
具備完整導入實務經驗的顧問公司也是其選擇的重要條件之一。
但到底市場上這麼多顧問公司，
到底哪一家的經驗跟實力才是對我最好的？
我應該要怎麼挑選才會對我是最適合的？
針對這一點，往往客戶都無所適從，
通常都是接觸的業務或其他人帶哪一家顧問公司就是那一間顧問公司。
至於其他顧問公司無從調查起，
因為網路上沒有太多資料。
多半只能透過同業間口耳相傳，
徵詢其他案例的專案經驗或依據聽到的傳奇故事來決定顧問公司的適合度。
但這樣的方式，可想而知，是非常不專業跟不嚴謹的作法。
身為從事SAP導入已經第八年的我，
我想已經夠資格提供一些意見來幫助這些新客戶做出選擇。
為了讓這個產業跟市場更健全，我想這也是我的義務。
一般客戶，在挑選顧問公司的時候，
往往會先去瞭解現在市場上有哪幾間顧問公司，
然後跟預設的顧問公司逐一比較，
有問得到資訊的就問，如果沒得問的，
那就是信任預設的那一家。
但往往業主都忘記了要先問自己到底是屬於哪一類產業？
公司的規模跟數量，
生產的型態跟接單方式等基礎資料。
為何要這樣先問自己呢？
因為顧問公司不是萬能的，
往往都有專精的領域，
而且不同的產業有不同的導入需求。
藥品業於批次、管制藥品的要求就高於其他的產業，
電子組裝業的替代料跟ECN的要求就高於其他的產業，
半導體業的物料特性值跟機台的即時性資料要求就高於其他的產業，
零售業對付款方式的要求就高於其他的產業。
所以，一開始，各位業主們應該要先確認的是，你是哪一種產業？
哪一個關鍵是你在這個產業的存活原因？
哪一些目標是我這次要導入SAP的必要項目？
接下來才是哪一類顧問跟顧問公司是我覺得可以透過SAP專案精進我的強項跟提升我的弱項。
市場上的顧問公司
有了上述的這些檢查之後，接下來就是找到正確的顧問公司跟顧問。
在SAP產業中，顧問公司們主要有分外商顧問公司
如IBM、Abeam、Atos Origin、HP、NEC、SAPC等，
本土顧問公司如東捷、英業達、主軸、泰新、台灣應用系統等跟Freelancer共三個群落。
在這些公司中，有些是如孟嘗君養士般持續培養人才，
也些是承攬專案後再找固定班底的Freelancer組成專案隊伍，
也有些是以滿足母公司集團需求為優先。
不過也有以搶Downpayment為優先，錢先進來再說的類型。
形形色色，各有風格，但無論如何，對業主來說，
重要的是，好的顧問比顧問公司重要。
大型或外商的顧問公司的強項是在於能提供的是不同產業的專業顧問人才。
根據客戶的需要建議不同的Solution，
但缺點就是不同Solution可能要靠一堆外掛漿糊黏接。
本土的顧問公司，就會以SAP為核心，
建議以在SAP中可以解決的方式來滿足客戶的需要。
但缺點可能就是良莠不齊。
因為SAP業人才流動很快，
而且各公司對於業務的要求跟人事的管理不一樣，
所以可能某個時期，某個顧問公司有一群強力的資深顧問，
但因為某個因素顧問流失之後就變弱了。
因此，多打聽是對的，但不一定是對的，
因為各位打聽的專案可能會是天寶舊事，
那些顧問都已經不知道跑到哪裡去了。但還是要多方打聽。
總是會問到這些人現在在哪裡？現在你看到的顧問過去發生什麼故事？
此外，在SAP選型過程中往往會有很多迷思，
其中一個就是品牌迷信。
不要因為某顧問公司的母公司是某大企業就迷信一定專案會有母公司的奧援，
或是有母公司的成績。
因為對不起，
母公司的SAP專案不見得就是你現在遇到的這一群人導入的。
還有一個迷思就是大公司比較好告，不怕倒。
這一點最是導入時似是而非的論點，因為大公司不見得比較好告，
對方的法務說不定比你買的License數還多。
對方處理SAP專案訴訟的經驗會比你少嗎？
確定告得贏嗎？花錢就是老大嗎？
在現下SAP專案業主規模普遍縮小的情況下，
說不定對方可以花比你更多的錢來告贏。
所以。在雙方都以合約來進行專案的時候，
我建議把時間花在研究合約跟SOW比較實際，
看清楚了才簽。
怎麼挑顧問？
既然顧問那麼重要，那我應該要怎麼挑呢？首先要弄清楚的是，
一般Pre-sale時來的顧問，往往都不會是作專案的顧問。
因為Pre-sale時的顧問都是演說家型的顧問，
他的工作就是解答客戶在選擇ERP時的疑惑，
讓客戶瞭解ERP的功能進而決定使用該系統。
至於實際的導入，他們不見得專精。
因為Pre-sale是要告訴你系統能這樣做，
但不見得一定作得到，
而專案的結果是要每一個功能都充分被測試過跟確認可以正常作動。
這兩者之間至少有半年的工作時間差，
所以，要過濾的是未來要真正實施專案的顧問。
不要搞錯了。
那顧問要如何過濾呢？一般的作法是顧問要先Interview。
顧問Interview往往會問的就是專案經歷，
每個案子的心得為何？
如果作我們家的案子會如何做等等，
透過顧問的回答來瞭解雙方是否契合。
這個作法沒什麼不對，
但也是有幾個迷思要各位避免的。
第一個是，
年紀越大的顧問越好。
很多公司往往會覺得這個派來面試的顧問年紀不小，
專案經歷豐富，
雖然面試上覺得普通，
但應該比較穩吧。
錯，這是SAP專案，不是十大傑出老年比賽。
SAP專案講究的是顧問對系統的瞭解程度跟因應客戶需求調整系統的能力。
年紀大經歷多是沒錯，但那是產業實務經驗，
不見得是SAP專案跟系統能力經驗。
實務經驗對顧問來說的用處是可以提前猜到用戶的需求跟系統的反應，
協助防堵沒有設想到的誤失，但要以SAP實務經驗來論斷。年紀大顧問不是不好，
但也不要誤會年紀輕的顧問就是經驗不足。
這個產業顧問的折損率很高，顧問缺工的比率也很高。
因此，年紀大的顧問會出現在你面前往往可能會是，
這個模組市場上全面缺人，
所以沒辦法只好找這個人上場。
年紀太輕的也是有這樣的可能。
所以，對於年齡建議還是持中立的角度。
一般市場上可以使用的顧問多半都是30~45之間，
目前評價好的顧問也多半在這個區間，
年紀以上或以下的，可能才應該是需要多問問的重點。
第二個是顧問年資越久越好。
有些公司會覺得，顧問是個經驗跟能力的行業，
所以顧問年資當然越久越好。這一點基本是沒錯，
但是顧問年資久不代表品質好，還要看專案的內容才能決定。
因此，建議以顧問年資/該顧問於該顧問公司任職的時間來論斷。
通常一個正向循環的顧問公司，顧問待的時間會越久。
一個有問題的公司，就很有可能發生顧問集體消失的事件。
因為案子做完大家不爽就全部散掉。
同樣的，一個好的顧問，
待在一個正常的公司的時間才會越久，
如果一個顧問SAP資歷很久但是每個顧問公司像走馬燈一樣的輪轉待過一遍，那就要注意了。
看起來這個顧問喜歡沾醬油，
總不會每一間顧問公司都有問題吧。
是不是這個顧問的專案常常砸鍋？
所以需要換工作？
顧問公司也是一樣，
一個老牌的顧問公司如果出來的都是一堆小朋友，
那也可能是有問題。
各位希望自己變成托兒所跟職業育成中心嗎？
所以這個KPI值得各位參考，
基本上大於1或小於1太多都不好。
趨近於1的話，
就表示這個顧問基本上是跟著這個顧問公司一起在這個產業奮鬥，
這兩者有密切的配合，
如果各模組的顧問都是這樣，那就是更好了，
表示這群人有密切的默契，做專案也會知道互相支援的部分，
更重要的是他們的專案一直成功，
所以才會繼續合作。
那這樣你的專案基本上就成功了一半。
第三個是忘記預約好的顧問。
有很多客戶，看到好的顧問出面，
不管是Pre-sale或一開始engagement的時候出現的顧問，
覺得他們真是專業豐富，經驗十足，導我家應該沒問題，
可以成功。不過，到了專案開始才發現，
怎麼來的是其他人？或是，專案過沒多久，
就有人來交接顧問的工作，換手到另外一組人。
這是因為顧問業是一個以專案為主的行業，
有專案人天才有營收，好的顧問人天價格就高。
因為他可以更快更好地處理專案的事務。
可能對於業主來說，怎麼人換來換去？
這樣我的案子要找誰做？
但如果業主本身支付的專案費用不高，
可是來的顧問素質好，即便來的次數不多，
那就認了吧。
付陽春麵的錢，已經有牛肉湯了，還要吃牛肉，就太過份了。
但如果這個專案是高單價的專案，表示各位對專案的重視程度高，
那麼理所當然可以要求自己的權益，把顧問名稱註明在專案合約中，
並且要求其到廠的人天數。
不過，相對的，Key User的名字也需要出現在合約中，
免得人也跑掉，以確保專案進行的順利。
第四個是外掛的部分漏了問。
很多顧問公司，往往報價比別家低，
或是說他們能做到比別家多的功能。
那有可能是因為他沒有把外掛那一塊估進來，
或是說用外掛的方式達成。
各位不要以為外掛那100天或200天就是free的，
或是專案價格低就是好的，
因為到時候如果顧問說要外掛才能達成，
頭都洗下去了，
你會濕淋淋換一間洗髮院重洗嗎？
基本上專案的費用、軟體跟硬體的採購費跟顧問費應該是1:1.5或1:2會比較健康。
太便宜的專案價，
不見得是佔到了便宜，
因為目前有專案分析後外掛一萬天的例子，
而且是今年的案子。
以Total Owner Cost來看，真的有佔到便宜嗎？，
真的有佔到便宜嗎？各位都是企業主管才會負責SAP的專案，
請至少要有格調，不是上菜市場買菜。
因此，如果在衡量顧問公司及顧問的時候，
請把外掛輝煌記錄評估進去。
當然不見得是該顧問公司的問題，
有可能是某個SAP專案的用戶太異想天開，
要這個要那個各類的方便功能，
所以要開發自動化的外掛來協助處理。
但是如果每一個案子都是一堆外掛，
那就要計算潛在的其他專案費用跟重新評估該顧問的經歷了。
第五個是搞不清楚顧問公司的on-going專案數跟顧問的比率。
很多IT主管在想要導入SAP專案的時候都是一開始慢慢找，
後來老闆問了，壓力來了才會急就章，
八月說12月上線啦，四個月就要上線，
馬上就要開始啦，好像市場上的顧問是無限供給的。
然後業務就幫各位找馬上可以開工的顧問公司，然後就趕趕趕，
最後就是亂亂亂。各位要想，老闆的壓力難道會是上個月才給的嗎？
SAP專案會是"馬上"就想導入嗎？
當然是會有很久的軟體Survey的過程，
那為何不早點開始Interview顧問公司呢？
挑挑挑，慢慢選的過程中，難道顧問公司不會被別家Book走嗎？
SAP產業類似於醫界，顧問也是有大小牌之分，大小牌價錢可能不會差很多，
但是專業度差非常多。
好的顧問公司，可能提前就被其他業務或客戶訂走了，
想要就要排隊。那隨時可以讓各位開工的公司呢？
可想而知了。
所以在Survey的過程中，一定要問清楚該公司目前的閒置度為何？
如果太閒，那可能是真的有原因讓他太閒。
但如果太忙呢？
一組顧問接了4個以上的案子呢？
那你覺得該公司又說馬上可以開工的意思是什麼？
這就是一件有趣的事情了。
第六個是問清楚此顧問真的是該顧問嗎？
在台灣，顧問的名字普遍都是用英文名，這不知道是誰開的慣例。
所以我的名字就是Ben。
一般來講，都會加個公司來判定，
如是XX顧問公司的Ben，這樣大家就知道這個人是誰了。
但有趣的是，往往大家都忘記這個人中文名字叫什麼。
多半是，你說那個Ben喔，不錯呀，做過什麼什麼案子，還可以。或是，
你說那個Ben喔，哈哈，嘿嘿，我什麼都沒說。
這兩者通常就代表著兩類的評價。但有趣的是，
因為英文名的關係，所以在台灣就有顧問會有好幾個名字。
三國不是有個三姓家奴呂布嗎？
差不多會換名字就是這個原因。沒事哪有人會換名字呢？
所以會換名字的顧問就是有趣的顧問。還請多打聽清楚。
這個名字之前有沒有其他的名字？
說了這麼多，希望對各位在SAP選型時能有些幫助。
最後，要回頭說說業主自己該注意的事項跟心態。
由於目前SAP的使用公司越來越不電子業化，
規模也越來越小。
傳統產業在顧問服務的判定上，
想當然而，
因為缺乏同業的資訊，
會更覺得撲朔迷離。
往往敢使用SAP的原因都是因為同業的老大已經使用了，
所以我們用應該是沒有問題。但是，有幾點要建議各位的。
就是，不要以為花錢就是老大，
說實在的，真的老大花的錢比你想像的多。
TSMC一年花在SAP的費用你知道有多少嗎？
各位現在的SAP導入費真的已經比之前便宜多了，
這當然是因為台灣的大案子都已經做得差不多的關係，
所以SAP只有往中小型企業走。
但是，
各位真的不要認為花了一千多萬所以Bargain Power就很強。
花了多少錢，還是會得到該有的價值，
絕對不會少拿，
也不要凡事都想多拿。
說實在的，
以我的角度就是拿多少錢做多少事，
大家公平。
另外，
專案上線才是重點，
專案過程中不要亂拗，
拗的意思就是不要不想花錢就要獲取不在專案範圍內的好處。
但確定的是，
拗只會讓專案進行的循環變負向，
變得更難處理。
你要拗顧問，
小拗可以，
大幅地拗到大家不爽，
顧問要讓專案產生麻煩很容易，
不告訴你就好了。
那你也會不爽，
就更想拗。
無論是資料或是額外的需求你都會想要多拿一些。
最後，
你不簽Milestone不付款，
顧問撤出專案轉進到別的案子，
倒楣的會是誰？
>>
>>你要他作顧問 :: 你是否有另一個顧問來證
>>
>>
>>
我想沒有顧問天生就是想要欺負人，特別是要整客戶，
大家也不是小氣鬼說什麼都不給，什麼都要錢。
基本上我們這個層次的顧問都是出來交朋友，
除了賺錢之外，更重要的是讓台灣的產業享受先進資訊科技帶來的競爭力。
但為何會讓顧問有不爽的感覺？
就是亂拗。買專案不是上菜市場，多一把蔥一把蒜的佔便宜。
你覺得菜販會不在別的地方動手腳嗎？我如果隨便就給你佔便宜，
那我不是也失了我的格調跟專業？那我對我其他的客戶要如何交代？
所以，不偏不倚，除了SAP方的PM要恪守之外，
業主的PM也請要特別注意。
最後，專案真的不要太趕。
坊間說四個月讓新SAP專案上線，各位相信嗎？
我只能說技術上做得到，但實務上有困難。
顧問在設定上可以超快，基本上我在系統設定只要兩天就全部設完了，完成度可以有85%。
剩下的修修改改頂多又兩天。再加上一些輔助性的Routine跟測試，頂多再兩天。
但各位的主檔資料能像我這麼快的準備好嗎？
各位用戶的使用熟練度能像我們顧問的速度這麼快提升上來嗎？
說實在的，專案的過程中，
多半都是在教育用戶、說明系統功能跟協助設計主檔等一些瑣事上。
真正的跨模組Solution Design並不用花很多時間，
大約一個月就能有顧問端完整的雛形了。
但這些瑣事，說實在的才是專案順利上線的關鍵。
顧問再簡潔跟有效的設計都比不上阿呆的用戶一句我不會。
所以，實在來說，這是一次企業轉型跟適應的過程，
套句郭董的一句話，豆芽菜發芽都要兩天了，SAP專案要馬上就成功？
好酒還是需要醞釀，好專案的目標就是要如時上線。這樣才是成功。
資料來源::
http://ahkuo.blog.ithome.com.tw/post/1114/18372
由 CKHiseh 發表於 [ General ]
(3391) 閱讀, (0) 引用, (4) 回應 , 推文( 0 )
一般客戶在選擇SAP系統時，
具備完整導入實務經驗的顧問公司也是其選擇的重要條件之一。
但到底市場上這麼多顧問公司，
到底哪一家的經驗跟實力才是對我最好的？
我應該要怎麼挑選才會對我是最適合的？
針對這一點，往往客戶都無所適從，
通常都是接觸的業務或其他人帶哪一家顧問公司就是那一間顧問公司。
至於其他顧問公司無從調查起，
因為網路上沒有太多資料。
多半只能透過同業間口耳相傳，
徵詢其他案例的專案經驗或依據聽到的傳奇故事來決定顧問公司的適合度。
但這樣的方式，可想而知，是非常不專業跟不嚴謹的作法。
身為從事SAP導入已經第八年的我，
我想已經夠資格提供一些意見來幫助這些新客戶做出選擇。
為了讓這個產業跟市場更健全，我想這也是我的義務。
一般客戶，在挑選顧問公司的時候，
往往會先去瞭解現在市場上有哪幾間顧問公司，
然後跟預設的顧問公司逐一比較，
有問得到資訊的就問，如果沒得問的，
那就是信任預設的那一家。
但往往業主都忘記了要先問自己到底是屬於哪一類產業？
公司的規模跟數量，
生產的型態跟接單方式等基礎資料。
為何要這樣先問自己呢？
因為顧問公司不是萬能的，
往往都有專精的領域，
而且不同的產業有不同的導入需求。
藥品業於批次、管制藥品的要求就高於其他的產業，
電子組裝業的替代料跟ECN的要求就高於其他的產業，
半導體業的物料特性值跟機台的即時性資料要求就高於其他的產業，
零售業對付款方式的要求就高於其他的產業。
所以，一開始，各位業主們應該要先確認的是，你是哪一種產業？
哪一個關鍵是你在這個產業的存活原因？
哪一些目標是我這次要導入SAP的必要項目？
接下來才是哪一類顧問跟顧問公司是我覺得可以透過SAP專案精進我的強項跟提升我的弱項。
市場上的顧問公司
有了上述的這些檢查之後，接下來就是找到正確的顧問公司跟顧問。
在SAP產業中，顧問公司們主要有分外商顧問公司
如IBM、Abeam、Atos Origin、HP、NEC、SAPC等，
本土顧問公司如東捷、英業達、主軸、泰新、台灣應用系統等跟Freelancer共三個群落。
在這些公司中，有些是如孟嘗君養士般持續培養人才，
也些是承攬專案後再找固定班底的Freelancer組成專案隊伍，
也有些是以滿足母公司集團需求為優先。
不過也有以搶Downpayment為優先，錢先進來再說的類型。
形形色色，各有風格，但無論如何，對業主來說，
重要的是，好的顧問比顧問公司重要。
大型或外商的顧問公司的強項是在於能提供的是不同產業的專業顧問人才。
根據客戶的需要建議不同的Solution，
但缺點就是不同Solution可能要靠一堆外掛漿糊黏接。
本土的顧問公司，就會以SAP為核心，
建議以在SAP中可以解決的方式來滿足客戶的需要。
但缺點可能就是良莠不齊。
因為SAP業人才流動很快，
而且各公司對於業務的要求跟人事的管理不一樣，
所以可能某個時期，某個顧問公司有一群強力的資深顧問，
但因為某個因素顧問流失之後就變弱了。
因此，多打聽是對的，但不一定是對的，
因為各位打聽的專案可能會是天寶舊事，
那些顧問都已經不知道跑到哪裡去了。但還是要多方打聽。
總是會問到這些人現在在哪裡？現在你看到的顧問過去發生什麼故事？
此外，在SAP選型過程中往往會有很多迷思，
其中一個就是品牌迷信。
不要因為某顧問公司的母公司是某大企業就迷信一定專案會有母公司的奧援，
或是有母公司的成績。
因為對不起，
母公司的SAP專案不見得就是你現在遇到的這一群人導入的。
還有一個迷思就是大公司比較好告，不怕倒。
這一點最是導入時似是而非的論點，因為大公司不見得比較好告，
對方的法務說不定比你買的License數還多。
對方處理SAP專案訴訟的經驗會比你少嗎？
確定告得贏嗎？花錢就是老大嗎？
在現下SAP專案業主規模普遍縮小的情況下，
說不定對方可以花比你更多的錢來告贏。
所以。在雙方都以合約來進行專案的時候，
我建議把時間花在研究合約跟SOW比較實際，
看清楚了才簽。
怎麼挑顧問？
既然顧問那麼重要，那我應該要怎麼挑呢？首先要弄清楚的是，
一般Pre-sale時來的顧問，往往都不會是作專案的顧問。
因為Pre-sale時的顧問都是演說家型的顧問，
他的工作就是解答客戶在選擇ERP時的疑惑，
讓客戶瞭解ERP的功能進而決定使用該系統。
至於實際的導入，他們不見得專精。
因為Pre-sale是要告訴你系統能這樣做，
但不見得一定作得到，
而專案的結果是要每一個功能都充分被測試過跟確認可以正常作動。
這兩者之間至少有半年的工作時間差，
所以，要過濾的是未來要真正實施專案的顧問。
不要搞錯了。
那顧問要如何過濾呢？一般的作法是顧問要先Interview。
顧問Interview往往會問的就是專案經歷，
每個案子的心得為何？
如果作我們家的案子會如何做等等，
透過顧問的回答來瞭解雙方是否契合。
這個作法沒什麼不對，
但也是有幾個迷思要各位避免的。
第一個是，
年紀越大的顧問越好。
很多公司往往會覺得這個派來面試的顧問年紀不小，
專案經歷豐富，
雖然面試上覺得普通，
但應該比較穩吧。
錯，這是SAP專案，不是十大傑出老年比賽。
SAP專案講究的是顧問對系統的瞭解程度跟因應客戶需求調整系統的能力。
年紀大經歷多是沒錯，但那是產業實務經驗，
不見得是SAP專案跟系統能力經驗。
實務經驗對顧問來說的用處是可以提前猜到用戶的需求跟系統的反應，
協助防堵沒有設想到的誤失，但要以SAP實務經驗來論斷。年紀大顧問不是不好，
但也不要誤會年紀輕的顧問就是經驗不足。
這個產業顧問的折損率很高，顧問缺工的比率也很高。
因此，年紀大的顧問會出現在你面前往往可能會是，
這個模組市場上全面缺人，
所以沒辦法只好找這個人上場。
年紀太輕的也是有這樣的可能。
所以，對於年齡建議還是持中立的角度。
一般市場上可以使用的顧問多半都是30~45之間，
目前評價好的顧問也多半在這個區間，
年紀以上或以下的，可能才應該是需要多問問的重點。
第二個是顧問年資越久越好。
有些公司會覺得，顧問是個經驗跟能力的行業，
所以顧問年資當然越久越好。這一點基本是沒錯，
但是顧問年資久不代表品質好，還要看專案的內容才能決定。
因此，建議以顧問年資/該顧問於該顧問公司任職的時間來論斷。
通常一個正向循環的顧問公司，顧問待的時間會越久。
一個有問題的公司，就很有可能發生顧問集體消失的事件。
因為案子做完大家不爽就全部散掉。
同樣的，一個好的顧問，
待在一個正常的公司的時間才會越久，
如果一個顧問SAP資歷很久但是每個顧問公司像走馬燈一樣的輪轉待過一遍，那就要注意了。
看起來這個顧問喜歡沾醬油，
總不會每一間顧問公司都有問題吧。
是不是這個顧問的專案常常砸鍋？
所以需要換工作？
顧問公司也是一樣，
一個老牌的顧問公司如果出來的都是一堆小朋友，
那也可能是有問題。
各位希望自己變成托兒所跟職業育成中心嗎？
所以這個KPI值得各位參考，
基本上大於1或小於1太多都不好。
趨近於1的話，
就表示這個顧問基本上是跟著這個顧問公司一起在這個產業奮鬥，
這兩者有密切的配合，
如果各模組的顧問都是這樣，那就是更好了，
表示這群人有密切的默契，做專案也會知道互相支援的部分，
更重要的是他們的專案一直成功，
所以才會繼續合作。
那這樣你的專案基本上就成功了一半。
第三個是忘記預約好的顧問。
有很多客戶，看到好的顧問出面，
不管是Pre-sale或一開始engagement的時候出現的顧問，
覺得他們真是專業豐富，經驗十足，導我家應該沒問題，
可以成功。不過，到了專案開始才發現，
怎麼來的是其他人？或是，專案過沒多久，
就有人來交接顧問的工作，換手到另外一組人。
這是因為顧問業是一個以專案為主的行業，
有專案人天才有營收，好的顧問人天價格就高。
因為他可以更快更好地處理專案的事務。
可能對於業主來說，怎麼人換來換去？
這樣我的案子要找誰做？
但如果業主本身支付的專案費用不高，
可是來的顧問素質好，即便來的次數不多，
那就認了吧。
付陽春麵的錢，已經有牛肉湯了，還要吃牛肉，就太過份了。
但如果這個專案是高單價的專案，表示各位對專案的重視程度高，
那麼理所當然可以要求自己的權益，把顧問名稱註明在專案合約中，
並且要求其到廠的人天數。
不過，相對的，Key User的名字也需要出現在合約中，
免得人也跑掉，以確保專案進行的順利。
第四個是外掛的部分漏了問。
很多顧問公司，往往報價比別家低，
或是說他們能做到比別家多的功能。
那有可能是因為他沒有把外掛那一塊估進來，
或是說用外掛的方式達成。
各位不要以為外掛那100天或200天就是free的，
或是專案價格低就是好的，
因為到時候如果顧問說要外掛才能達成，
頭都洗下去了，
你會濕淋淋換一間洗髮院重洗嗎？
基本上專案的費用、軟體跟硬體的採購費跟顧問費應該是1:1.5或1:2會比較健康。
太便宜的專案價，
不見得是佔到了便宜，
因為目前有專案分析後外掛一萬天的例子，
而且是今年的案子。
以Total Owner Cost來看，真的有佔到便宜嗎？，
真的有佔到便宜嗎？各位都是企業主管才會負責SAP的專案，
請至少要有格調，不是上菜市場買菜。
因此，如果在衡量顧問公司及顧問的時候，
請把外掛輝煌記錄評估進去。
當然不見得是該顧問公司的問題，
有可能是某個SAP專案的用戶太異想天開，
要這個要那個各類的方便功能，
所以要開發自動化的外掛來協助處理。
但是如果每一個案子都是一堆外掛，
那就要計算潛在的其他專案費用跟重新評估該顧問的經歷了。
第五個是搞不清楚顧問公司的on-going專案數跟顧問的比率。
很多IT主管在想要導入SAP專案的時候都是一開始慢慢找，
後來老闆問了，壓力來了才會急就章，
八月說12月上線啦，四個月就要上線，
馬上就要開始啦，好像市場上的顧問是無限供給的。
然後業務就幫各位找馬上可以開工的顧問公司，然後就趕趕趕，
最後就是亂亂亂。各位要想，老闆的壓力難道會是上個月才給的嗎？
SAP專案會是"馬上"就想導入嗎？
當然是會有很久的軟體Survey的過程，
那為何不早點開始Interview顧問公司呢？
挑挑挑，慢慢選的過程中，難道顧問公司不會被別家Book走嗎？
SAP產業類似於醫界，顧問也是有大小牌之分，大小牌價錢可能不會差很多，
但是專業度差非常多。
好的顧問公司，可能提前就被其他業務或客戶訂走了，
想要就要排隊。那隨時可以讓各位開工的公司呢？
可想而知了。
所以在Survey的過程中，一定要問清楚該公司目前的閒置度為何？
如果太閒，那可能是真的有原因讓他太閒。
但如果太忙呢？
一組顧問接了4個以上的案子呢？
那你覺得該公司又說馬上可以開工的意思是什麼？
這就是一件有趣的事情了。
第六個是問清楚此顧問真的是該顧問嗎？
在台灣，顧問的名字普遍都是用英文名，這不知道是誰開的慣例。
所以我的名字就是Ben。
一般來講，都會加個公司來判定，
如是XX顧問公司的Ben，這樣大家就知道這個人是誰了。
但有趣的是，往往大家都忘記這個人中文名字叫什麼。
多半是，你說那個Ben喔，不錯呀，做過什麼什麼案子，還可以。或是，
你說那個Ben喔，哈哈，嘿嘿，我什麼都沒說。
這兩者通常就代表著兩類的評價。但有趣的是，
因為英文名的關係，所以在台灣就有顧問會有好幾個名字。
三國不是有個三姓家奴呂布嗎？
差不多會換名字就是這個原因。沒事哪有人會換名字呢？
所以會換名字的顧問就是有趣的顧問。還請多打聽清楚。
這個名字之前有沒有其他的名字？
說了這麼多，希望對各位在SAP選型時能有些幫助。
最後，要回頭說說業主自己該注意的事項跟心態。
由於目前SAP的使用公司越來越不電子業化，
規模也越來越小。
傳統產業在顧問服務的判定上，
想當然而，
因為缺乏同業的資訊，
會更覺得撲朔迷離。
往往敢使用SAP的原因都是因為同業的老大已經使用了，
所以我們用應該是沒有問題。但是，有幾點要建議各位的。
就是，不要以為花錢就是老大，
說實在的，真的老大花的錢比你想像的多。
TSMC一年花在SAP的費用你知道有多少嗎？
各位現在的SAP導入費真的已經比之前便宜多了，
這當然是因為台灣的大案子都已經做得差不多的關係，
所以SAP只有往中小型企業走。
但是，
各位真的不要認為花了一千多萬所以Bargain Power就很強。
花了多少錢，還是會得到該有的價值，
絕對不會少拿，
也不要凡事都想多拿。
說實在的，
以我的角度就是拿多少錢做多少事，
大家公平。
另外，
專案上線才是重點，
專案過程中不要亂拗，
拗的意思就是不要不想花錢就要獲取不在專案範圍內的好處。
但確定的是，
拗只會讓專案進行的循環變負向，
變得更難處理。
你要拗顧問，
小拗可以，
大幅地拗到大家不爽，
顧問要讓專案產生麻煩很容易，
不告訴你就好了。
那你也會不爽，
就更想拗。
無論是資料或是額外的需求你都會想要多拿一些。
最後，
你不簽Milestone不付款，
顧問撤出專案轉進到別的案子，
倒楣的會是誰？
>>
>>你要他作顧問 :: 你是否有另一個顧問來證
>>
>>
>>
我想沒有顧問天生就是想要欺負人，特別是要整客戶，
大家也不是小氣鬼說什麼都不給，什麼都要錢。
基本上我們這個層次的顧問都是出來交朋友，
除了賺錢之外，更重要的是讓台灣的產業享受先進資訊科技帶來的競爭力。
但為何會讓顧問有不爽的感覺？
就是亂拗。買專案不是上菜市場，多一把蔥一把蒜的佔便宜。
你覺得菜販會不在別的地方動手腳嗎？我如果隨便就給你佔便宜，
那我不是也失了我的格調跟專業？那我對我其他的客戶要如何交代？
所以，不偏不倚，除了SAP方的PM要恪守之外，
業主的PM也請要特別注意。
最後，專案真的不要太趕。
坊間說四個月讓新SAP專案上線，各位相信嗎？
我只能說技術上做得到，但實務上有困難。
顧問在設定上可以超快，基本上我在系統設定只要兩天就全部設完了，完成度可以有85%。
剩下的修修改改頂多又兩天。再加上一些輔助性的Routine跟測試，頂多再兩天。
但各位的主檔資料能像我這麼快的準備好嗎？
各位用戶的使用熟練度能像我們顧問的速度這麼快提升上來嗎？
說實在的，專案的過程中，
多半都是在教育用戶、說明系統功能跟協助設計主檔等一些瑣事上。
真正的跨模組Solution Design並不用花很多時間，
大約一個月就能有顧問端完整的雛形了。
但這些瑣事，說實在的才是專案順利上線的關鍵。
顧問再簡潔跟有效的設計都比不上阿呆的用戶一句我不會。
所以，實在來說，這是一次企業轉型跟適應的過程，
套句郭董的一句話，豆芽菜發芽都要兩天了，SAP專案要馬上就成功？
好酒還是需要醞釀，好專案的目標就是要如時上線。這樣才是成功。
2010年4月14日 星期三
ERP 拋完領料後，不瑣住新增機制
org.compiere.process.SIGenMI，拋完領料後，不瑣住新增機制
Win-Tab.ReadOnlyLogic @IsGenMI@='Y' 要拿開
還有
GridTab.java 會依據 @Processed@ 鎖住 變成 ReadOnly
if (m_vo.TableName.startsWith("M_ProductionSI")) // && m_vo.TabNo == 0)
{ // DocStatus = "CO" / "CL"
String DocStatus = m_vo.ctx.getContext( m_vo.WindowNo, "DocStatus");
String Processed = m_vo.ctx.getContext( m_vo.WindowNo, "Processed");
String IsGenMI = m_vo.ctx.getContext( m_vo.WindowNo, "IsGenMI");
log.info("m_vo.TableName="+m_vo.TableName+" ,DocStatus="+DocStatus+" ,Processed="+Processed+" ,IsGenMI="+IsGenMI);
if (Processed.equals("Y")) // || IsGenMI.equals("Y"))
return true;;
}//boolean
Win-Tab.ReadOnlyLogic @IsGenMI@='Y' 要拿開
還有
GridTab.java 會依據 @Processed@ 鎖住 變成 ReadOnly
if (m_vo.TableName.startsWith("M_ProductionSI")) // && m_vo.TabNo == 0)
{ // DocStatus = "CO" / "CL"
String DocStatus = m_vo.ctx.getContext( m_vo.WindowNo, "DocStatus");
String Processed = m_vo.ctx.getContext( m_vo.WindowNo, "Processed");
String IsGenMI = m_vo.ctx.getContext( m_vo.WindowNo, "IsGenMI");
log.info("m_vo.TableName="+m_vo.TableName+" ,DocStatus="+DocStatus+" ,Processed="+Processed+" ,IsGenMI="+IsGenMI);
if (Processed.equals("Y")) // || IsGenMI.equals("Y"))
return true;;
}//boolean
ERP 看周先生
各位知道ERP这个词从1980年开始到现在已经经过了30年了，
这30年的确对全球的企业有很大的帮助。
这些企业通过实施ERP能够真正让它的运营和经营变得更科学、更制度化。
不过这两年看起来最热门的话题并不是绕着ERP谈的，而是叫云计算。
>>>>>>>>>>>>>>>>>>>>>
就是 browser base ERP
就是 ERP on internet
就是 鼎新頂不住的系統
>>>>>>>>>>>>>>>>>>>>>
这两年几乎各行各业都在谈云计算这件事情，从硬件公司、软件公司、网络公司、通讯公司，
甚至做收集的公司都在谈云计算。
在ERP经过30年这么成熟的发展之后，却碰到了这么一个先进的IT议题，
到底能产生什么样的新的火花呢？
鼎捷公司确实有义务也有责任，我们想分享这样一个冲突激起火花的看法。
事实上国内很多软件公司，当谈到云计算的时候，把很多事情忽略掉了，
这个也是我们今天跟各位要介绍的事情。
在介绍今天议题的开始，我想回顾一下过去计算的发展。
大家知道在计算方面实际上可以区分为两块：1.商业处理。2.科学计算。
在商业处理上主要以数据管理为主，大部分的计算几乎是以数据库为主。
科学计算就是以数学模型为主，是要解决非常复杂的数学运算为主。
所以从一开始这两条路线就不一样，一个是绕着很大的储存媒体来做，
另外一个则是以快速向量的计算方式为主。
过去的四五十年的历史它们从来都是分开来的，不过随着时间的发展，
网络越来越兴盛之后，到了80年代，
我们可以借用这些分布的各种不同的个人电脑来提升它的计算能力。
这个历史就是从集中走向分布，我们希望通过分布的方式来取得更大的资源。不过在这个过程里面我们也发现，事实上分布的做法有时候在上游产生问题，有时候在安全方面产生问题，最重要的是在管理上，管理变得非常复杂。所以随着计算资源越来越便宜，互联网络越来越成熟，有没有可能假想一些东西，把这些计算干脆再集中起来，集中在一个虚拟的环境里面，让我们的使用者可以不知道后面的计算多复杂，只要用上网络就可以用到它了。再一次从分散的概念，走上集中的概念。可是这个过程并不见得是非常成功的，事实上都是停留在概念上、学术上面的研究，真正的应用并没有非常的成功。
我们下一个课题出来了，云计算。云计算到底会走向哪个方向呢？
这也是我今天的一个议题。
各位知道从60年代开始一路下来，
事实上这个过程对企业来讲是更重要的一个过程。
到互联网成熟的电子商务，
到现在我们需要的不止是ERP，
需要更多方面的技术应用，我们把它概括起来叫ERPⅡ。
各位如果有机会到欧美的银行去看，事实上到目前为止，
欧美很多的银行系统还在用30年前IBM做的技术，没有采用新的技术。
为什么呢？因为应用本身是以需求为先。
我要满足我的需求，并不在于我要追求什么新的IT技术，
而是能动性符合现在的需求，才是更重要的一件事情。
所以对我们来看，从理性的角度来看，到底云计算的趋势对不对？我们认为云确实是未来很关键的信息技术。我们今天来看云技术，确实是有机会的，虽然它到现在还不是很成熟，但是都是有解决方向的。云技术确实是未来关键的IT技术。但我们看到国内许多的软件公司在提到“云”的时候，常常被误导了：有了“云”之后，企业变得很方便，管理上变得没有问题了，只要把东西“送上云端”之后，就没有问题了。
那么真的是这样的吗？
我们来看看一些软件公司所提到的说辞：有人说云是穷人家的超级计算机。超级计算，即所谓的科学计算，基本上它的领域是在企业里面，虽然今天云真的有可能变成穷人家的超级计算机，但是也不一定能解决我们企业所有的问题。
又有人认为：云计算就是从部署、管理和运维全都基于统一的平台，所有的软件都变成了服务。软件要变成服务绝对没有那么简单，软件是个商品，把商品变成服务绝对不是一句话就可以变过去的。我认为统一平台根本不是关键，关键是怎么样把商品变成服务，怎么样把软件变成服务才是最大的挑战。
又有人认为：从特定行业发展云的应用，将保障“云计算”的应用实践和价值发挥得到切实的推进。有没有云不重要，关键在于应用的知识。在鼎捷的台湾团队，10年前我们就有这样的概念了。
更进一步，我想再提另外一个概念，就是云有多大的好处呢？
云概念就好像自来水。有人提到，用了云技术之后，就像用自来水，不要买水了。这样是不是比较方便？当然比较方便。这是一个服务的概念。买水是产品，打开水龙头是一种服务，用了多少水我付多少水钱。这是一个很漂亮的概念。对应到软件，所谓的云计算，看起来是没有错的。一样的道理，在云计算领域，我们提到一种服务的机制-SaaS，我们都提供这样的服务，你们可以直接通过上网然后取得你要的软件服务，就感觉像水龙头一样很方便，因为你真的不用去安装或者采购这样的软件。
我想问的是下一个问题。大家知道水接下来要煮咖啡或者做饭，对应到云计算，假设这是水龙头，我能不能把这个东西像水一样接下来之后做别的事情呢？但是不幸的是现在SaaS提供的不见得是跟你家的咖啡壶是一样的，不见得就适合做成咖啡，所以这会是一个很大的问题。尽管如此，站在鼎捷的立场，云计算绝对是未来关键的IT技术。
那到底什么是云呢？
我们常常听人家说云分三种：1.SaaS。2.Paas。3.Laas。我个人认为这样的介绍是不好的，对企业来讲我认为不应该是这样的。所以我们提出来第二种概念，云应该从使用者的角度来看。
假如我今天是企业用户，我为什么要用云呢？我们把云分成三种：1.Cloud2C，针对一般终端用户的云。假如今天到北京、上海或者西安，各位知道我的 E-mail可以随时通过我的手机看到。所以我认为Cloud2c确实是云的一种应用，但并不是我们重点关注的用户。2.Cloud2B，针对企业用户的云。3.Cloud2E，针对企业终端用户的云。这个是很重要的，因为Cloud的一个特性就是在云端。
鼎捷云的策略是什么？基于刚刚的介绍，我们云计算的太阳系主要分成三圈。第一圈是属于Cloud2B的，中间的是Cloud2E的首选，第三圈再回到 Cloud2B。作为软件公司，特别是ERP厂商，我们必须进一步把产品虚拟化。所以第一圈协助我们的企业用户去做到Cloud2B这一块的云计算目标。第二层是Cloud2E，或者叫MobilCloud，长期在外跑动的企业员工，可以通过云计算来实现他们需要的计算。第三层我们会回到Cloud2B，专注S-Cloud的发展。
先来看看第一层的P-Cloud。我们有五种不同的虚拟化形式，从桌面的虚拟化一直到存储的虚拟化。鼎捷作为ERP公司，必须把我们的产品也虚拟化，而在这一块我们的研发速度也是很快的。以易飞为例，它本来有很多不同的ERP产品，但以易飞来部署就可以让他得到非常多的管理上的好处。
第二层是M-Cloud的概念。M-Cloud可以让我们企业的服务延伸到公开的云端上来。不管是在新疆还是在海南岛，只要上了云端之后，就可以使用企业快速便捷的服务。我们把这种做法叫做M-Cloud。
第三层是S-Cloud。我们认为在这里要做的一件事情除了多租户差总管理之外，还要做租户内的集成。我们必须要帮助我们的企业用户去做所谓的租户内的集成，这个问题本身是一个很大的需求。除了这个之外，我们还要考虑到租户间的协作问题，这也是目前大家都很少考虑到的。到目前为止，大家都考虑到水龙头打开倒水，却没有考虑到最后我的水必须和水壶协作才能烧水或制作咖啡。这些协作问题如果不解决的话，使用云端不见得就是全对的。所以大租户之间的协作，也变得非常重要。
因此可以看出，我们在关注和发展云技术时跟很多业界友商是有很大差异的，因为我们考虑的问题会比较多。
那么，后ERP时代难道只有云计算这个问题吗？当然不是，在后ERP时代不应该只有云，我们提出“Use- IT”架构（U-无所不在的企业、S-服务型的企业、I-集成企业、T-薄型企业）+Green ERP。云绝对是里面重要的项目，但绝对不是唯一的一项。U-无所不在的企业、S-服务型企业、I-集成智能型企业、T-薄型企业。
谈到绿色ERP，2012年起欧盟要求所有飞往欧洲的航空公司都必须很清楚地表明碳排放；再举个例子，2012年起，沃尔玛要求所有销往美国的产品，一定要贴上所谓碳足迹的标签。这已经是我们企业面临的真实挑战了，因为只要你不贴上碳标签你的产品就卖不到沃尔玛去。
我们刚刚看到的几乎都是从IT应用的角度来看对企业可能造成的影响。不过我最后想讲的是Enterprise ABC-企业应用的架构师、企业智能的烘焙师、企业服务集成的指挥家。当我们各种不同的服务串联起来之后，就一定要想办法去很好地协调。如果不能够协调一致的话，我们做出来的服务集成就会让企业内部的运行乱七八糟。依照过去的实施经验，IT技术本身虽然很重要，但是企业的Enterprise ABC这三种任务，可能会变得更重要了。
我们认为企业管理软件不能只是IT，帮助企业进化的不论是产业趋势、知识、经验或者顾问与服务等，都是更重要的议题，只有融合所有这些，才能最终帮助企业成长。
这30年的确对全球的企业有很大的帮助。
这些企业通过实施ERP能够真正让它的运营和经营变得更科学、更制度化。
不过这两年看起来最热门的话题并不是绕着ERP谈的，而是叫云计算。
>>>>>>>>>>>>>>>>>>>>>
就是 browser base ERP
就是 ERP on internet
就是 鼎新頂不住的系統
>>>>>>>>>>>>>>>>>>>>>
这两年几乎各行各业都在谈云计算这件事情，从硬件公司、软件公司、网络公司、通讯公司，
甚至做收集的公司都在谈云计算。
在ERP经过30年这么成熟的发展之后，却碰到了这么一个先进的IT议题，
到底能产生什么样的新的火花呢？
鼎捷公司确实有义务也有责任，我们想分享这样一个冲突激起火花的看法。
事实上国内很多软件公司，当谈到云计算的时候，把很多事情忽略掉了，
这个也是我们今天跟各位要介绍的事情。
在介绍今天议题的开始，我想回顾一下过去计算的发展。
大家知道在计算方面实际上可以区分为两块：1.商业处理。2.科学计算。
在商业处理上主要以数据管理为主，大部分的计算几乎是以数据库为主。
科学计算就是以数学模型为主，是要解决非常复杂的数学运算为主。
所以从一开始这两条路线就不一样，一个是绕着很大的储存媒体来做，
另外一个则是以快速向量的计算方式为主。
过去的四五十年的历史它们从来都是分开来的，不过随着时间的发展，
网络越来越兴盛之后，到了80年代，
我们可以借用这些分布的各种不同的个人电脑来提升它的计算能力。
这个历史就是从集中走向分布，我们希望通过分布的方式来取得更大的资源。不过在这个过程里面我们也发现，事实上分布的做法有时候在上游产生问题，有时候在安全方面产生问题，最重要的是在管理上，管理变得非常复杂。所以随着计算资源越来越便宜，互联网络越来越成熟，有没有可能假想一些东西，把这些计算干脆再集中起来，集中在一个虚拟的环境里面，让我们的使用者可以不知道后面的计算多复杂，只要用上网络就可以用到它了。再一次从分散的概念，走上集中的概念。可是这个过程并不见得是非常成功的，事实上都是停留在概念上、学术上面的研究，真正的应用并没有非常的成功。
我们下一个课题出来了，云计算。云计算到底会走向哪个方向呢？
这也是我今天的一个议题。
各位知道从60年代开始一路下来，
事实上这个过程对企业来讲是更重要的一个过程。
到互联网成熟的电子商务，
到现在我们需要的不止是ERP，
需要更多方面的技术应用，我们把它概括起来叫ERPⅡ。
各位如果有机会到欧美的银行去看，事实上到目前为止，
欧美很多的银行系统还在用30年前IBM做的技术，没有采用新的技术。
为什么呢？因为应用本身是以需求为先。
我要满足我的需求，并不在于我要追求什么新的IT技术，
而是能动性符合现在的需求，才是更重要的一件事情。
所以对我们来看，从理性的角度来看，到底云计算的趋势对不对？我们认为云确实是未来很关键的信息技术。我们今天来看云技术，确实是有机会的，虽然它到现在还不是很成熟，但是都是有解决方向的。云技术确实是未来关键的IT技术。但我们看到国内许多的软件公司在提到“云”的时候，常常被误导了：有了“云”之后，企业变得很方便，管理上变得没有问题了，只要把东西“送上云端”之后，就没有问题了。
那么真的是这样的吗？
我们来看看一些软件公司所提到的说辞：有人说云是穷人家的超级计算机。超级计算，即所谓的科学计算，基本上它的领域是在企业里面，虽然今天云真的有可能变成穷人家的超级计算机，但是也不一定能解决我们企业所有的问题。
又有人认为：云计算就是从部署、管理和运维全都基于统一的平台，所有的软件都变成了服务。软件要变成服务绝对没有那么简单，软件是个商品，把商品变成服务绝对不是一句话就可以变过去的。我认为统一平台根本不是关键，关键是怎么样把商品变成服务，怎么样把软件变成服务才是最大的挑战。
又有人认为：从特定行业发展云的应用，将保障“云计算”的应用实践和价值发挥得到切实的推进。有没有云不重要，关键在于应用的知识。在鼎捷的台湾团队，10年前我们就有这样的概念了。
更进一步，我想再提另外一个概念，就是云有多大的好处呢？
云概念就好像自来水。有人提到，用了云技术之后，就像用自来水，不要买水了。这样是不是比较方便？当然比较方便。这是一个服务的概念。买水是产品，打开水龙头是一种服务，用了多少水我付多少水钱。这是一个很漂亮的概念。对应到软件，所谓的云计算，看起来是没有错的。一样的道理，在云计算领域，我们提到一种服务的机制-SaaS，我们都提供这样的服务，你们可以直接通过上网然后取得你要的软件服务，就感觉像水龙头一样很方便，因为你真的不用去安装或者采购这样的软件。
我想问的是下一个问题。大家知道水接下来要煮咖啡或者做饭，对应到云计算，假设这是水龙头，我能不能把这个东西像水一样接下来之后做别的事情呢？但是不幸的是现在SaaS提供的不见得是跟你家的咖啡壶是一样的，不见得就适合做成咖啡，所以这会是一个很大的问题。尽管如此，站在鼎捷的立场，云计算绝对是未来关键的IT技术。
那到底什么是云呢？
我们常常听人家说云分三种：1.SaaS。2.Paas。3.Laas。我个人认为这样的介绍是不好的，对企业来讲我认为不应该是这样的。所以我们提出来第二种概念，云应该从使用者的角度来看。
假如我今天是企业用户，我为什么要用云呢？我们把云分成三种：1.Cloud2C，针对一般终端用户的云。假如今天到北京、上海或者西安，各位知道我的 E-mail可以随时通过我的手机看到。所以我认为Cloud2c确实是云的一种应用，但并不是我们重点关注的用户。2.Cloud2B，针对企业用户的云。3.Cloud2E，针对企业终端用户的云。这个是很重要的，因为Cloud的一个特性就是在云端。
鼎捷云的策略是什么？基于刚刚的介绍，我们云计算的太阳系主要分成三圈。第一圈是属于Cloud2B的，中间的是Cloud2E的首选，第三圈再回到 Cloud2B。作为软件公司，特别是ERP厂商，我们必须进一步把产品虚拟化。所以第一圈协助我们的企业用户去做到Cloud2B这一块的云计算目标。第二层是Cloud2E，或者叫MobilCloud，长期在外跑动的企业员工，可以通过云计算来实现他们需要的计算。第三层我们会回到Cloud2B，专注S-Cloud的发展。
先来看看第一层的P-Cloud。我们有五种不同的虚拟化形式，从桌面的虚拟化一直到存储的虚拟化。鼎捷作为ERP公司，必须把我们的产品也虚拟化，而在这一块我们的研发速度也是很快的。以易飞为例，它本来有很多不同的ERP产品，但以易飞来部署就可以让他得到非常多的管理上的好处。
第二层是M-Cloud的概念。M-Cloud可以让我们企业的服务延伸到公开的云端上来。不管是在新疆还是在海南岛，只要上了云端之后，就可以使用企业快速便捷的服务。我们把这种做法叫做M-Cloud。
第三层是S-Cloud。我们认为在这里要做的一件事情除了多租户差总管理之外，还要做租户内的集成。我们必须要帮助我们的企业用户去做所谓的租户内的集成，这个问题本身是一个很大的需求。除了这个之外，我们还要考虑到租户间的协作问题，这也是目前大家都很少考虑到的。到目前为止，大家都考虑到水龙头打开倒水，却没有考虑到最后我的水必须和水壶协作才能烧水或制作咖啡。这些协作问题如果不解决的话，使用云端不见得就是全对的。所以大租户之间的协作，也变得非常重要。
因此可以看出，我们在关注和发展云技术时跟很多业界友商是有很大差异的，因为我们考虑的问题会比较多。
那么，后ERP时代难道只有云计算这个问题吗？当然不是，在后ERP时代不应该只有云，我们提出“Use- IT”架构（U-无所不在的企业、S-服务型的企业、I-集成企业、T-薄型企业）+Green ERP。云绝对是里面重要的项目，但绝对不是唯一的一项。U-无所不在的企业、S-服务型企业、I-集成智能型企业、T-薄型企业。
谈到绿色ERP，2012年起欧盟要求所有飞往欧洲的航空公司都必须很清楚地表明碳排放；再举个例子，2012年起，沃尔玛要求所有销往美国的产品，一定要贴上所谓碳足迹的标签。这已经是我们企业面临的真实挑战了，因为只要你不贴上碳标签你的产品就卖不到沃尔玛去。
我们刚刚看到的几乎都是从IT应用的角度来看对企业可能造成的影响。不过我最后想讲的是Enterprise ABC-企业应用的架构师、企业智能的烘焙师、企业服务集成的指挥家。当我们各种不同的服务串联起来之后，就一定要想办法去很好地协调。如果不能够协调一致的话，我们做出来的服务集成就会让企业内部的运行乱七八糟。依照过去的实施经验，IT技术本身虽然很重要，但是企业的Enterprise ABC这三种任务，可能会变得更重要了。
我们认为企业管理软件不能只是IT，帮助企业进化的不论是产业趋势、知识、经验或者顾问与服务等，都是更重要的议题，只有融合所有这些，才能最终帮助企业成长。
2010年4月9日 星期五
1.
hassan84
[Avatar]
2009-10-04 09:42:13 GMT
Dear Adempiere Community,
I'm not accountant and not a programmer
but finally I'm should make a decision with which accounting package
and future accounting standard the company will use in all related operations therefore I have some comment to share and have some questions.
The past few months our team has evaluated some accounting ERP programs
(commercial and Open source) for our fast growing operation.
Currently there are three software packages in the final,
Adempiere is one of it.
Our company operation spreads around the Indian Ocean with offices in East Africa,
the Indian Sub Continent and South East Asia.
In India and Indonesia we have small production facilities.
For the base evaluation we use only Gardenworld data and
found out that Adempiere (Ver 3.4)
is quite extensive ERP solution but not very flexible in handling taxes especially withholding taxes for services which are common in many countries we operate offices. Also to add additional costs for goods on stock is not possible.
After some google search we found two solutions for withholding tax
one in Columbia localization and
a “Adempiere fork” in Thailand
(Saeree ERP – which does not provide a source code).
Thanks to Google Translate (Spanish - English)
service our team could install the Colombian localization into Gardenworld data.
Without playing too much we could get it work with the Gardenworld data.
The accounting figures are the way we need it in most countries.
But when we setup our own test client with some data
we still could not figure out how to configure it correctly.
But this is not the point yet for questioning.
I have some questions to the council / community:
1.)
Is there any reason not to include the Colombian Withholding tax solution in the trunk,
since I guess in almost every continent there will be one or more countries which has a source tax with a tax base which is not fully compatible to the document type system of Adempiere but gives Adempiere enormous flexibility?
2.)
Landed Cost does not work as in SAP and SAGE Accounting Systems standard,
which is a disadvantage mainly
when you have to export / import goods across boarders.
(cost of goods in stock = cost purchased + landed cost ((or +add monthly cost))).
Sales staff needs nowadays the accurate cost per item on stock immediately from the system therefore additional storage cost for an item must be added all time to the current cost. (Warehouse rent for 1000 tones corn, security, electricity, fumigation should be added every month to current product cost)
in these regards Adempiere is very clumsy.
Is there already a solution available for adding cost to an item on stock?
3.)Is Humanflash the commercial support arm of Adempiere or how it works since they are very predominant in Google?
Regards,
Hassan
2.
trifonntProject Admin
[Avatar]
2009-10-04 10:53:07 GMT
Dear Hassan,
i will try to answer some of your questions
> 1.) Is there any reason not to include the Colombian Withholding tax solution
> in the trunk
There is no political reason not to include Colombian Withholding functionality. As far as i know, this extension was used in Italy too.
My advice is if you could support original developer or some other CORE ADempiere developer to include it in trunk.
> 2.)Landed Cost does not work as in SAP and SAGE Accounting Systems standard,
3.4.2 is not good in Cost calculation. Only Standard costing is working in 3.4.2. new version (3.5.4a) is much better in Costing and i would recommend you to test it and report if it fits your needs.
> 3.)Is Humanflash the commercial support arm of Adempiere or how it
> works since they are very predominant
> in Google?
NO.
The best ADempiere support can be provided by ADempiere developers at this moment because ADempiere is evolving very fast and only developers truly know what is the last functionality.
Regards,
Trifon
www.catura.de
3.
globalqssSourceForge.net SubscriberProject Admin
[Avatar]
2009-10-04 18:40:18 GMT
Hi Hassan,
Good to hear you're considering Adempiere in your evaluation.
Please let me comment/ask/answer some of your post:
> "found out that Adempiere (Ver 3.4) is
> quite extensive ERP"
I'm just curious about this statement, "expensive" compared with?
I know implementing Adempiere is not free - but I'm curious to know which variables did you take into account to declare is "quite expensive". Not criticizing, just wondering.
> "a “Adempiere fork” in Thailand (Saeree
> ERP – which does not provide a source
> code)."
I didn't know about Saeree before this post, but as I see they provide - it's a must following the GPL license. ---------- > "Without playing too much we could get > it work with the Gardenworld data. The > accounting figures are the way we need > it in most countries. But when we > setup our own test client with some > data we still could not fig[code][1] - it's a must following the GPL license.
> "Without playing too much we could get
> it work with the Gardenworld data. The
> accounting figures are the way we need
> it in most countries. But when we
> setup our own test client with some
> data we still could not figure out how
> to configure it correctly"
:-) It seems I'm going to need to translate those manuals. There are lot of interest.
I know configuring LCO withholdings is really hard, and to ease the understanding of this I created a demo site with some preconfigured cases, you can play with GardenWorld+LCO [here][2]
Please excuse us if you find problems with this demo site. Until past week the demo was configured with version 3.4.2s and it was running flawlessly. This week I just migrated it to 3.5.4+patches and I'm still finding some problems and struggling to stabilize it.
> "Is there any reason not to include the
> Colombian Withholding tax solution in
> the trunk"
That's a good question :-) I made a presentation in Berlin past june, and at the end of the presentation the same question arose. The Localization Colombia is being used or considered in Ecuador, Peru, Argentina, Venezuela, Italy, Spain, and now you.
I'm really glad to hear this, and I'm trying to give support on LCO whenever asked in forums (free) or private (paid).
Look, we (GlobalQSS) wrote the LCO withholdings management as an extension with two purposes: 1 - give the extension time to mature proving that it's useful, 2 - to avoid passing initially the trunk process (that is hard to follow when you're writing localizations or some extensions). We needed to answer the needs of Colombia quickly and we could not achieve the needed speed if asking for trunk integration.
Additionally this was intended intially like a localization - and localizations must not go into trunk. The issue is that we did our localization so configurable that it has shown value for many other countries. So, maybe it's the moment to ask if it's worthy to integrate into trunk.
There is an additional thing - there was a similar development called "GTM" (Global Tax Management) that was pushed into trunk without too much discussion and it seems is somewhat incomplete (as it requires additional coding to make it work). My opinion is that both developments (LCO and GTM) are trying to solve the same need in different ways. LCO trying to make it really configurable and user-independent (via configuration rules), and GTM needing additional code to make it work, and AFAIU it needs some user interaction to choose the proper withholdings.
Pushing LCO into trunk will make probably conflict with GTM - Adempiere will have duplicate functionality - personally I don't know if anybody is using GTM. But my guess is that we need to avoid duplicated functionality in trunk. If LCO is considered for integration then we need to a) drop GTM or b) integrate LCO and GTM to use the same structures and approach (what I've tried to analyze but it costs, and I cannot support the effort at this moment)
That's one of the main reasons why I keep pushing this community to establish rules to avoid incomplete things arriving into trunk - and establish rules to encourage competence via extensions.
When an extension is proven to be useful (as it's showing LCO) then it can be voted to be in trunk. Allowing incomplete "first-flag-seeders" in trunk is discouraging competence. I'm not encouraged to code a "better-solution" for "GTM" because it's already in trunk and it's having "competitive advantage" over LCO.
> "Landed Cost does not work as in SAP
> and SAGE Accounting Systems standard"
This is something to improve - I think there are some solutions that are hard to achieve with a pure-community approach - at this moment this community is trying to find better ways to evolve and I hope in future we'll have a complete cost solution (unfortunately I cannot say how much time will take).
> "Is Humanflash the commercial support
> arm of Adempiere or how it works since
> they are very predominant in Google"
Maybe I better would not say this, but honestly I would call HumanFlash some kind of vampires - I've never seen one single contribution from them to Compiere neither Adempiere. Indeed AFAIR Jorg Janke demanded them because they abused the trademark Compiere registering the domain www.mycompiere.com (and JJ won).
They're predominant in Google **ADS** because they pay to be there, I suppose that's OK. What I don't like is the fact they don't contribute back to any of the projects they use to survive.
But please note that maybe I'm just uninformed about.
Regards,
Carlos Ruiz
[1]: http://saeree.svn.sourceforge.net/viewvc/saeree/
[2]: http://demo.globalqss.com/
4.
globalqssSourceForge.net SubscriberProject Admin
[Avatar]
2009-10-04 18:58:41 GMT
Erratum:
Trifon let me notice that I misread "expensive" when Hassan wrote "extensive".
Regards,
Carlos Ruiz
5.
sureerayaAccepting Donations
[Avatar]
2009-10-09 03:22:36 GMT
Hi All,
I'm Sureeraya. I'm fork project Saeree ERP from Adempiere for Certified with Revenue Department in Thailand. I would like to submit the extended Withholding Tax features to Adempiere too. Please create new branch for me (I can't create with my privilate) . I'm develop base on Adempiere 3.5.3a .
I've planed to retest all process and upgrade to Adempiere 3.5.4a too. Actually Saeree ERP is Adempiere Extended version customize for Thai Accounting Standard. Also included VAT Not Due (for service product in Thailand), Withholding Tax.
6.
globalqssSourceForge.net SubscriberProject Admin
[Avatar]
2009-10-10 16:19:57 GMT
Hi Sureeraya,
> "I would like to submit the extended
> Withholding Tax features to Adempiere
> too. Please create new branch for me
> (I can't create with my privilate)"
I just gave you svn permissions. You can now create your branch and contribute there.
If you want you can add a README.txt file in your branch expressing your preferred branch rules, maintainer, what's in, etc.
Thanks for contributing.
Regards,
Carlos Ruiz
7.
red1Project Admin
[Avatar]
2010-04-09 11:05:12 GMT
I cant find anything from Sureeraya. We now need to pick up on Withholding and Deferred Tax which are in use in Thailand. Carlos, can i use the Withholding Tax of Colombia?
I will ask ISEC whether Withholding Tax is basically when invoicing a vendor, payable value is deducted VAT to be paid to govt later.
hassan84
[Avatar]
2009-10-04 09:42:13 GMT
Dear Adempiere Community,
I'm not accountant and not a programmer
but finally I'm should make a decision with which accounting package
and future accounting standard the company will use in all related operations therefore I have some comment to share and have some questions.
The past few months our team has evaluated some accounting ERP programs
(commercial and Open source) for our fast growing operation.
Currently there are three software packages in the final,
Adempiere is one of it.
Our company operation spreads around the Indian Ocean with offices in East Africa,
the Indian Sub Continent and South East Asia.
In India and Indonesia we have small production facilities.
For the base evaluation we use only Gardenworld data and
found out that Adempiere (Ver 3.4)
is quite extensive ERP solution but not very flexible in handling taxes especially withholding taxes for services which are common in many countries we operate offices. Also to add additional costs for goods on stock is not possible.
After some google search we found two solutions for withholding tax
one in Columbia localization and
a “Adempiere fork” in Thailand
(Saeree ERP – which does not provide a source code).
Thanks to Google Translate (Spanish - English)
service our team could install the Colombian localization into Gardenworld data.
Without playing too much we could get it work with the Gardenworld data.
The accounting figures are the way we need it in most countries.
But when we setup our own test client with some data
we still could not figure out how to configure it correctly.
But this is not the point yet for questioning.
I have some questions to the council / community:
1.)
Is there any reason not to include the Colombian Withholding tax solution in the trunk,
since I guess in almost every continent there will be one or more countries which has a source tax with a tax base which is not fully compatible to the document type system of Adempiere but gives Adempiere enormous flexibility?
2.)
Landed Cost does not work as in SAP and SAGE Accounting Systems standard,
which is a disadvantage mainly
when you have to export / import goods across boarders.
(cost of goods in stock = cost purchased + landed cost ((or +add monthly cost))).
Sales staff needs nowadays the accurate cost per item on stock immediately from the system therefore additional storage cost for an item must be added all time to the current cost. (Warehouse rent for 1000 tones corn, security, electricity, fumigation should be added every month to current product cost)
in these regards Adempiere is very clumsy.
Is there already a solution available for adding cost to an item on stock?
3.)Is Humanflash the commercial support arm of Adempiere or how it works since they are very predominant in Google?
Regards,
Hassan
2.
trifonntProject Admin
[Avatar]
2009-10-04 10:53:07 GMT
Dear Hassan,
i will try to answer some of your questions
> 1.) Is there any reason not to include the Colombian Withholding tax solution
> in the trunk
There is no political reason not to include Colombian Withholding functionality. As far as i know, this extension was used in Italy too.
My advice is if you could support original developer or some other CORE ADempiere developer to include it in trunk.
> 2.)Landed Cost does not work as in SAP and SAGE Accounting Systems standard,
3.4.2 is not good in Cost calculation. Only Standard costing is working in 3.4.2. new version (3.5.4a) is much better in Costing and i would recommend you to test it and report if it fits your needs.
> 3.)Is Humanflash the commercial support arm of Adempiere or how it
> works since they are very predominant
> in Google?
NO.
The best ADempiere support can be provided by ADempiere developers at this moment because ADempiere is evolving very fast and only developers truly know what is the last functionality.
Regards,
Trifon
www.catura.de
3.
globalqssSourceForge.net SubscriberProject Admin
[Avatar]
2009-10-04 18:40:18 GMT
Hi Hassan,
Good to hear you're considering Adempiere in your evaluation.
Please let me comment/ask/answer some of your post:
> "found out that Adempiere (Ver 3.4) is
> quite extensive ERP"
I'm just curious about this statement, "expensive" compared with?
I know implementing Adempiere is not free - but I'm curious to know which variables did you take into account to declare is "quite expensive". Not criticizing, just wondering.
> "a “Adempiere fork” in Thailand (Saeree
> ERP – which does not provide a source
> code)."
I didn't know about Saeree before this post, but as I see they provide - it's a must following the GPL license. ---------- > "Without playing too much we could get > it work with the Gardenworld data. The > accounting figures are the way we need > it in most countries. But when we > setup our own test client with some > data we still could not fig[code][1] - it's a must following the GPL license.
> "Without playing too much we could get
> it work with the Gardenworld data. The
> accounting figures are the way we need
> it in most countries. But when we
> setup our own test client with some
> data we still could not figure out how
> to configure it correctly"
:-) It seems I'm going to need to translate those manuals. There are lot of interest.
I know configuring LCO withholdings is really hard, and to ease the understanding of this I created a demo site with some preconfigured cases, you can play with GardenWorld+LCO [here][2]
Please excuse us if you find problems with this demo site. Until past week the demo was configured with version 3.4.2s and it was running flawlessly. This week I just migrated it to 3.5.4+patches and I'm still finding some problems and struggling to stabilize it.
> "Is there any reason not to include the
> Colombian Withholding tax solution in
> the trunk"
That's a good question :-) I made a presentation in Berlin past june, and at the end of the presentation the same question arose. The Localization Colombia is being used or considered in Ecuador, Peru, Argentina, Venezuela, Italy, Spain, and now you.
I'm really glad to hear this, and I'm trying to give support on LCO whenever asked in forums (free) or private (paid).
Look, we (GlobalQSS) wrote the LCO withholdings management as an extension with two purposes: 1 - give the extension time to mature proving that it's useful, 2 - to avoid passing initially the trunk process (that is hard to follow when you're writing localizations or some extensions). We needed to answer the needs of Colombia quickly and we could not achieve the needed speed if asking for trunk integration.
Additionally this was intended intially like a localization - and localizations must not go into trunk. The issue is that we did our localization so configurable that it has shown value for many other countries. So, maybe it's the moment to ask if it's worthy to integrate into trunk.
There is an additional thing - there was a similar development called "GTM" (Global Tax Management) that was pushed into trunk without too much discussion and it seems is somewhat incomplete (as it requires additional coding to make it work). My opinion is that both developments (LCO and GTM) are trying to solve the same need in different ways. LCO trying to make it really configurable and user-independent (via configuration rules), and GTM needing additional code to make it work, and AFAIU it needs some user interaction to choose the proper withholdings.
Pushing LCO into trunk will make probably conflict with GTM - Adempiere will have duplicate functionality - personally I don't know if anybody is using GTM. But my guess is that we need to avoid duplicated functionality in trunk. If LCO is considered for integration then we need to a) drop GTM or b) integrate LCO and GTM to use the same structures and approach (what I've tried to analyze but it costs, and I cannot support the effort at this moment)
That's one of the main reasons why I keep pushing this community to establish rules to avoid incomplete things arriving into trunk - and establish rules to encourage competence via extensions.
When an extension is proven to be useful (as it's showing LCO) then it can be voted to be in trunk. Allowing incomplete "first-flag-seeders" in trunk is discouraging competence. I'm not encouraged to code a "better-solution" for "GTM" because it's already in trunk and it's having "competitive advantage" over LCO.
> "Landed Cost does not work as in SAP
> and SAGE Accounting Systems standard"
This is something to improve - I think there are some solutions that are hard to achieve with a pure-community approach - at this moment this community is trying to find better ways to evolve and I hope in future we'll have a complete cost solution (unfortunately I cannot say how much time will take).
> "Is Humanflash the commercial support
> arm of Adempiere or how it works since
> they are very predominant in Google"
Maybe I better would not say this, but honestly I would call HumanFlash some kind of vampires - I've never seen one single contribution from them to Compiere neither Adempiere. Indeed AFAIR Jorg Janke demanded them because they abused the trademark Compiere registering the domain www.mycompiere.com (and JJ won).
They're predominant in Google **ADS** because they pay to be there, I suppose that's OK. What I don't like is the fact they don't contribute back to any of the projects they use to survive.
But please note that maybe I'm just uninformed about.
Regards,
Carlos Ruiz
[1]: http://saeree.svn.sourceforge.net/viewvc/saeree/
[2]: http://demo.globalqss.com/
4.
globalqssSourceForge.net SubscriberProject Admin
[Avatar]
2009-10-04 18:58:41 GMT
Erratum:
Trifon let me notice that I misread "expensive" when Hassan wrote "extensive".
Regards,
Carlos Ruiz
5.
sureerayaAccepting Donations
[Avatar]
2009-10-09 03:22:36 GMT
Hi All,
I'm Sureeraya. I'm fork project Saeree ERP from Adempiere for Certified with Revenue Department in Thailand. I would like to submit the extended Withholding Tax features to Adempiere too. Please create new branch for me (I can't create with my privilate) . I'm develop base on Adempiere 3.5.3a .
I've planed to retest all process and upgrade to Adempiere 3.5.4a too. Actually Saeree ERP is Adempiere Extended version customize for Thai Accounting Standard. Also included VAT Not Due (for service product in Thailand), Withholding Tax.
6.
globalqssSourceForge.net SubscriberProject Admin
[Avatar]
2009-10-10 16:19:57 GMT
Hi Sureeraya,
> "I would like to submit the extended
> Withholding Tax features to Adempiere
> too. Please create new branch for me
> (I can't create with my privilate)"
I just gave you svn permissions. You can now create your branch and contribute there.
If you want you can add a README.txt file in your branch expressing your preferred branch rules, maintainer, what's in, etc.
Thanks for contributing.
Regards,
Carlos Ruiz
7.
red1Project Admin
[Avatar]
2010-04-09 11:05:12 GMT
I cant find anything from Sureeraya. We now need to pick up on Withholding and Deferred Tax which are in use in Thailand. Carlos, can i use the Withholding Tax of Colombia?
I will ask ISEC whether Withholding Tax is basically when invoicing a vendor, payable value is deducted VAT to be paid to govt later.
2010年4月6日 星期二
ERP SAP 不同人分區段授權
Create material- user authority by create material type
Postby sanzidaiub on Tue Apr 06, 2010 2:15 am
Hi Expert
I want to set authority for user to creating material by using material type. User will create only those material which they are assigned in their material type.
Please help me to solve the problem.
Postby sanzidaiub on Tue Apr 06, 2010 2:15 am
Hi Expert
I want to set authority for user to creating material by using material type. User will create only those material which they are assigned in their material type.
Please help me to solve the problem.
2010年3月29日 星期一
SAP OMS2的物料類型對應的工廠沒有打勾
SAP OMS2的物料類型對應的工廠沒有打勾
??
如果沒打勾
沒警告:: OMS2的物料類型對應的工廠沒有打勾
警告是會出現"科目類別需要被指派".....
請教一下，有人有人在SAP ERP 可以在第三地英屬維京群島的公司工廠設定下，可以設定會計科目指派類別進行收貨"入庫"，透過協力廠商模式可以 (PO : X + S) 但是要用一般工廠模式去收是會出現"科目類別需要被指派"......(IMG 有關科目精靈自動指派都對過.....不知道V.G FI/CO的部分要注意哪部分...)
終於被我測試出來了,後續再跟大家分享在vg第三地公司如何收貨入庫
已經找到, OMS2的物料類型對應的工廠沒有打勾
??
如果沒打勾
沒警告:: OMS2的物料類型對應的工廠沒有打勾
警告是會出現"科目類別需要被指派".....
請教一下，有人有人在SAP ERP 可以在第三地英屬維京群島的公司工廠設定下，可以設定會計科目指派類別進行收貨"入庫"，透過協力廠商模式可以 (PO : X + S) 但是要用一般工廠模式去收是會出現"科目類別需要被指派"......(IMG 有關科目精靈自動指派都對過.....不知道V.G FI/CO的部分要注意哪部分...)
終於被我測試出來了,後續再跟大家分享在vg第三地公司如何收貨入庫
已經找到, OMS2的物料類型對應的工廠沒有打勾
2010年3月26日 星期五
ERP 國際商管學院促進協會
國際商管學院促進協會
維基百科，自由的百科全書
國際商管學院促進協會
（英語：The Association to Advance Collegiate Schools of Business），
簡稱AACSB或AACSB International，
是一個於1916年在美國創建的、針對世界各管理學院的認證NGO；
核心任務是推動全球商管教育品質的認證，
當前已經成為國際上最為權威且知名的大學商管學院與MBA認證機構，
學術地位崇高。
AACSB的初始會員校有（依據英文首字字母排序）
哥倫比亞大學、
達特茅斯學院、
哈佛大學、
紐約大學、
西北大學、
俄亥俄州立大學、
杜蘭大學、
加州大學柏克萊分校、
芝加哥大學、
伊利諾大學厄巴納-香檳分校、
內布拉斯加大學系統、
賓州大學、
匹茲堡大學、
德州大學、
威斯康辛大學麥迪遜分校、
耶魯大學。
維基百科，自由的百科全書
國際商管學院促進協會
（英語：The Association to Advance Collegiate Schools of Business），
簡稱AACSB或AACSB International，
是一個於1916年在美國創建的、針對世界各管理學院的認證NGO；
核心任務是推動全球商管教育品質的認證，
當前已經成為國際上最為權威且知名的大學商管學院與MBA認證機構，
學術地位崇高。
AACSB的初始會員校有（依據英文首字字母排序）
哥倫比亞大學、
達特茅斯學院、
哈佛大學、
紐約大學、
西北大學、
俄亥俄州立大學、
杜蘭大學、
加州大學柏克萊分校、
芝加哥大學、
伊利諾大學厄巴納-香檳分校、
內布拉斯加大學系統、
賓州大學、
匹茲堡大學、
德州大學、
威斯康辛大學麥迪遜分校、
耶魯大學。
Automatic Account Determination
Automatic Account Determination
=================================
2010.04.13.成立
=================================
Compiere -> ADempiere -> SAPiere
=================================
This is perhaps the part that causes the most heartache for the FI Configurer.
For some reason, although it is an integration area, the FI team always ends up with responsibility for it. To do a good job you need a reasonable understanding of :
1. the business processes in the source modules
2. the FI account postings that they should be generating (what sort of account should be debited or credited etc)
3. the organisation structure and its relationships between the source modules
4. the reporting requirements that are expected from the General Ledger or Profit Centre Accounting
5. your chart of accounts
Sounds daunting doesn't it ? Here is a suggested approach ...
The IMG section under GL / business transactions / integration will take you through all the necessary account determination for the automatic postings that the system may need to post. You may not need all of these.You could maintain on an as needed basis. As the project teams test or prototype their expanding functionality, the SAP system will look for the accounts to which it should post. The error message and the SAP documentation and configuration does not always explain clearly which piece of account determination is used for which type of functionality, so it is sometimes difficult to be pro-active.
Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an understanding of what the business transaction is and therefore where it should be posting. Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).
I will be explaining each account determination area simply and clearly with posting examples
* SD to FI Account Determination (aka revenue account determination). This and MM seem to confuse people the most.
* More later - This may take a while to complete........
In the meantime, some general warnings:
* Whenever you change the field status settings for an account, ensure that you have verified that any automatic postings will be able to meet the requirements. EG: do not make business area mandatory if your system may make a posting which cannot determine and post the business area.
* Consider specifying that accounts that are posted to automatically can only be posted to automatically. This will simplify reconciliation between the source module and the GL account should you need to do this.
SD-FI Account Determination and Postings
This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc). This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.
The integration is controlled both in SD and in FI.
In SD there is a awesome area of configuration called the pricing procedures. The pricing procedure determines the final price quoted to the customer for a particular product. This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. This condition technique is used in a number of areas of SAP.
For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys). You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:
* ERF freight revenues
* ERL revenues
* ERS sales deductions
* EVV cash settlement
* MWS sales tax
Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!
So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )
We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".
The chart of accounts part is standard in all account determinations, so let us look at the rest. This access sequence allows us to specify different GL accounts for different Sales Organisations.
So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation. To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:
SD Line Item Condition type SD Amount Account Key Sales Organisation GL Account
1 Sales deduction for being such a nice guy $10 ERS 1000 800010 - Sales deductions for 1000
Sales deduction for special promotion on particular product $15 ERS
Base Revenue $200 ERL 800000 - Revenue for Sales Org 1000
Total for item 1 $175
2 Base Revenue $100 ERL 1000 800000 - Revenue for Sales Org 1000
Total for item 2 $ 100
Document Total $ 275
So the invoice that the customer gets (and that you can view in SD) will look something like:
Item (Note this is the SD Invoice line item) Amount
Item 1: $175
Item 2: $100
Total owing , 30 days terms etc: $275
The GL document posting that the system will make to FI will look something like this though:
FI Line Item Debit / Credit Account Amount
1 Debit (PK=01) Customer (AR Account) $ 275
2 Credit (PK=50) Revenue (GL Account) -$ 300
3 Debit (PK=40) Sales Deduction (GL Account) $25
Balancing to 0 as all GL documents must....
$0
Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.
Other considerations:
* Remember that if you are using business areas, then depending on your configuration there, the system may create additional FI line items if it needs to post to different business areas. This may be even more of a reason why you do not need additional GL accounts. If your Sales Organisations already map to different business areas, you could use the GL accounts for all Sales Organisations.
* Different access sequences will allow a broader variety of GL accounts (for example: by customer account) group. I strongly suggest having a good understanding of the reporting requirements expected to be supported from the General Ledger vs the SIS (Sales Information System) or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre modules before you create too many GL accounts. At the risk of repeating myself, the SD to FI account determination should only be as detailed as your statutory reporting requirements. The reporting from other tools like Profitability Analysis are so much more flexible and powerful, you may never look at the General Ledger for internal profit reporting again except to do a reconciliation check.
=================================
2010.04.13.成立
=================================
Compiere -> ADempiere -> SAPiere
=================================
This is perhaps the part that causes the most heartache for the FI Configurer.
For some reason, although it is an integration area, the FI team always ends up with responsibility for it. To do a good job you need a reasonable understanding of :
1. the business processes in the source modules
2. the FI account postings that they should be generating (what sort of account should be debited or credited etc)
3. the organisation structure and its relationships between the source modules
4. the reporting requirements that are expected from the General Ledger or Profit Centre Accounting
5. your chart of accounts
Sounds daunting doesn't it ? Here is a suggested approach ...
The IMG section under GL / business transactions / integration will take you through all the necessary account determination for the automatic postings that the system may need to post. You may not need all of these.You could maintain on an as needed basis. As the project teams test or prototype their expanding functionality, the SAP system will look for the accounts to which it should post. The error message and the SAP documentation and configuration does not always explain clearly which piece of account determination is used for which type of functionality, so it is sometimes difficult to be pro-active.
Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an understanding of what the business transaction is and therefore where it should be posting. Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).
I will be explaining each account determination area simply and clearly with posting examples
* SD to FI Account Determination (aka revenue account determination). This and MM seem to confuse people the most.
* More later - This may take a while to complete........
In the meantime, some general warnings:
* Whenever you change the field status settings for an account, ensure that you have verified that any automatic postings will be able to meet the requirements. EG: do not make business area mandatory if your system may make a posting which cannot determine and post the business area.
* Consider specifying that accounts that are posted to automatically can only be posted to automatically. This will simplify reconciliation between the source module and the GL account should you need to do this.
SD-FI Account Determination and Postings
This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc). This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.
The integration is controlled both in SD and in FI.
In SD there is a awesome area of configuration called the pricing procedures. The pricing procedure determines the final price quoted to the customer for a particular product. This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. This condition technique is used in a number of areas of SAP.
For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys). You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:
* ERF freight revenues
* ERL revenues
* ERS sales deductions
* EVV cash settlement
* MWS sales tax
Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!
So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )
We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".
The chart of accounts part is standard in all account determinations, so let us look at the rest. This access sequence allows us to specify different GL accounts for different Sales Organisations.
So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation. To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:
SD Line Item Condition type SD Amount Account Key Sales Organisation GL Account
1 Sales deduction for being such a nice guy $10 ERS 1000 800010 - Sales deductions for 1000
Sales deduction for special promotion on particular product $15 ERS
Base Revenue $200 ERL 800000 - Revenue for Sales Org 1000
Total for item 1 $175
2 Base Revenue $100 ERL 1000 800000 - Revenue for Sales Org 1000
Total for item 2 $ 100
Document Total $ 275
So the invoice that the customer gets (and that you can view in SD) will look something like:
Item (Note this is the SD Invoice line item) Amount
Item 1: $175
Item 2: $100
Total owing , 30 days terms etc: $275
The GL document posting that the system will make to FI will look something like this though:
FI Line Item Debit / Credit Account Amount
1 Debit (PK=01) Customer (AR Account) $ 275
2 Credit (PK=50) Revenue (GL Account) -$ 300
3 Debit (PK=40) Sales Deduction (GL Account) $25
Balancing to 0 as all GL documents must....
$0
Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.
Other considerations:
* Remember that if you are using business areas, then depending on your configuration there, the system may create additional FI line items if it needs to post to different business areas. This may be even more of a reason why you do not need additional GL accounts. If your Sales Organisations already map to different business areas, you could use the GL accounts for all Sales Organisations.
* Different access sequences will allow a broader variety of GL accounts (for example: by customer account) group. I strongly suggest having a good understanding of the reporting requirements expected to be supported from the General Ledger vs the SIS (Sales Information System) or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre modules before you create too many GL accounts. At the risk of repeating myself, the SD to FI account determination should only be as detailed as your statutory reporting requirements. The reporting from other tools like Profitability Analysis are so much more flexible and powerful, you may never look at the General Ledger for internal profit reporting again except to do a reconciliation check.
2010年3月25日 星期四
ERP SAP SD 配銷 會計科目
ERP SAP SD 配銷 會計科目
ERP SAP SD 配銷 會計科目
============================================
業務銷售的 出貨 作業 與 會計科目
During goods issue in the sales cycle,
the system is usually configured to update
the relevant GL accounts automatically
and to create the relevant accounting documents.
This customization in IMG is also called
material account assignment and is achieved
through a number of steps as detailed below:
=============================================
1. Determine ‘valuation level’ (Company Code or plant).
2. Activate ‘valuation grouping code’ and link it with the ‘chart of accounts’ for each ‘valuation area.’
3. Link ‘valuation class’ with ‘material type’ (FERT, HAWA, HALB, etc.) with the ‘account category reference’ (combination of valuation classes).
4. Maintain ‘account modification codes’ for ‘movement types.’
5. Link ‘account modification codes’ with ‘process keys’ (transaction/event keys).
6. Maintain a GL account for a given combination of ‘chart of accounts’+ ‘valuation grouping code ‘+’ account modification code ‘+’ valuation classes.’
The process of Automatic Account Determination is as follows:
1. Depending on the ‘plant’ entered during goods issue (GI), the ‘Company Code’ is determined by the system which in turn determines the relevant ‘Chart of Accounts.’
2. The plant thus entered in goods issue determines the ‘valuation class’ and then the ‘valuation grouping code.’
3. The ‘valuation class’ is determined from the ‘material master.’
4. Since the ‘account modification code’ is assigned to a ‘process key’ which is already linked to a ‘movement type,’ the ‘transaction key’ (DIF, GBB, AUM, BSX, etc.) determines the ‘GL account’ as posting transactions are predefined for each ‘movement type’ in ‘inventory management.’
ERP SAP SD 配銷 會計科目
============================================
業務銷售的 出貨 作業 與 會計科目
During goods issue in the sales cycle,
the system is usually configured to update
the relevant GL accounts automatically
and to create the relevant accounting documents.
This customization in IMG is also called
material account assignment and is achieved
through a number of steps as detailed below:
=============================================
1. Determine ‘valuation level’ (Company Code or plant).
2. Activate ‘valuation grouping code’ and link it with the ‘chart of accounts’ for each ‘valuation area.’
3. Link ‘valuation class’ with ‘material type’ (FERT, HAWA, HALB, etc.) with the ‘account category reference’ (combination of valuation classes).
4. Maintain ‘account modification codes’ for ‘movement types.’
5. Link ‘account modification codes’ with ‘process keys’ (transaction/event keys).
6. Maintain a GL account for a given combination of ‘chart of accounts’+ ‘valuation grouping code ‘+’ account modification code ‘+’ valuation classes.’
The process of Automatic Account Determination is as follows:
1. Depending on the ‘plant’ entered during goods issue (GI), the ‘Company Code’ is determined by the system which in turn determines the relevant ‘Chart of Accounts.’
2. The plant thus entered in goods issue determines the ‘valuation class’ and then the ‘valuation grouping code.’
3. The ‘valuation class’ is determined from the ‘material master.’
4. Since the ‘account modification code’ is assigned to a ‘process key’ which is already linked to a ‘movement type,’ the ‘transaction key’ (DIF, GBB, AUM, BSX, etc.) determines the ‘GL account’ as posting transactions are predefined for each ‘movement type’ in ‘inventory management.’
ERP專案調研報告
ERP專案調研報告
一、 引言
1. 編寫目的
通過瞭解 TSMC（以下簡稱 TSMC）現狀，分析企業業務流程及管理之重點，
為BPI企業流程、明確軟體功能需求以及評估軟體二次開發需求而撰寫本文。
本文的讀者為專案的組織實施者、專案二次開發系統分析及軟體發展人員等。
2. 文檔背景
調研時間：2009年03月2日、3日共兩個工作日
調研地點：TSMC總廠辦公室
參與人員：TSMC MIS、TSMC 專案小組各成員、TSMC 總廠各部門相關人員
調研範圍：TSMC 總廠銷售、採購、工程、生管、倉庫、等主要業務的現行流程
3. 參考資料
A. 藍道科技ERP 系統文檔書寫規範
B. 系統總體進度表
C. 各部門提供的相關表單及文檔
二、公司概況
TSMC 總廠、二廠、及制三，總廠、二廠以五金衝壓及五金模具設計製造為主
三、現行業務流程說明
1. 銷售部門
總廠業務部門負責總廠、二廠以及製造三部相關業務部門工作，擔當與客戶溝通的視窗。
客戶關係管理
1. 公司客戶目前主要為日資企業，如先鋒、日立等，另一類客戶為利盟指定的二級客戶。但隨著公司經營，客戶數將逐漸增加。
2. 目前客戶代號兩碼，有些以客戶英文名稱中的兩個英文字母表示，有些以漢字首兩個漢字的拼音字母表示，沒有統一規範，有規範統一編碼的需求。
3. 目前沒有客戶分級管理，但手工有做銷售分析，分別按產品做營業額、毛利分析，按客戶做營業額、毛利分析。按產品類別（如DVD、車載等）分析營業額及毛利。
4. 目前客戶如先鋒，其有不同的出貨地點，如香港、深圳等。出貨及開發票時都會開不同的公司抬頭，在分析報表時也需要將同一客戶不同區域匯總。（因此建議客戶編碼時，將不同區域的客戶建立成不同的客戶，在客戶編碼時，將同一客戶不同出貨區域客戶編碼，在編碼上讓其排列在相鄰區域。）
5. 目前暫不存在總公司和分公司的客戶模式，即與分公司交易，與總公司結款的模式。
6. 目前沒有做信用額度的管控，因為幾個大客戶都是很穩定的，但有部分壞帳，有管控壞帳風險的需求。
報價
1. 新產品客戶詢價時，客戶會聯繫業務要求報價。
2. 新品報價後，可能有一部分產品不會在公司生產，只是工程品，在系統內只記錄其總價。還沒有正式品號報價時，系統需要有專用於報價的料號，此料號應能設定其可以更改品名規格，在報價時更改品名規格，為沒有正式料號的產品作報價使用。（關於工程樣板的報價，一般沒有零件規格尺寸只有材質，但是需要顯示其數量，單價和縂價值。部分情況下還需要模具費的報價）
3. 沒有正式生產前，報價都沿用客戶料號，正式生產後，工程會會編立正式的料號。
4. 目前對外有統一的報價單格式，因涉及到模具開發成本及生產批量、採購批量原因，報價時會有分量計價的需求。（分量計價指：不同數量範圍，單價不同）
5. 報價時需能記錄材質、模具價格、部品價格等。
訂單核價
1. 銷售價格基本上以每次的合同價為准，若客戶需要降價，會重新報價。不同的客戶有不同的價格，需分量計價。
2. 價格的調整沒有固定的週期，要求每次的交易價格可以回寫價格資料檔。
3. 降價後，有客戶對未交完貨的訂單，要變更為新的單價交易。或出完貨後，還未結帳的客戶要求變更為新的單價結算。
Forecast
1. 客戶每月給一次後三至四個月的需求。有些客戶不會給Forecast，但會提前一個月下定單給業務，但需求變更都很大。
2. 業務部門會以銷售計畫統計表的形式統計回饋給生管，每月統計，在18號前提交生管單位。
訂單建立
1. 訂單的來源為國內、國外客戶及制三，客戶以傳真或郵件方式通知業務，即使電話口頭通知，事後也會補單。
2. 業務以銷售計畫統計表通知生管，若有變更時，會另外以郵件方式通知生管。目前計畫變更頻繁，且緊急插單情況頻繁。
3. 訂單類型：訂單通常分為三種：
1) 一種：一部分客戶不下Forecast，但會提前將訂單下出，後以交貨排程來安排生產，此類定單一般不安排生產主要用於備料；
2) 一種是客戶下Forecast後再正式訂單通知業務，Forecast可以作業備料的參考依據，因Forecast變更較大，在此基礎上會有調整，生產則以正式訂單安排生產。
3) 還有一種是樣品訂單，和正式訂單一樣，樣品訂單也納入生產計畫由車間進行生產，在接單時一般可確定樣品訂單是否收款。（樣板訂單和量產訂單的單價會有不一樣的情況）
4. 訂單評審沒有專門的會議和書面的評審資料，但業務會以電話或郵件告知生管，主要由生管和其它部門確認客戶的交期是否可以達到，評審確認後即可轉為公司的內部訂單。訂單的簽核則由業務主管，再到副總簽字。簽完字後轉生管一聯。
訂單變更
1. 目前訂單變更的頻度比較高，變更的內容主要是調整數量和變更交期。
2. 客戶訂單變更時，有些強制取消，有些取消時會與業務溝通，有些已經做好，也有可能取消，中間損失的吸收需業務與客戶協定方案。少部分客戶會有簽字蓋章的文書郵件通知業務。
3. 訂單內部變更需求時，由生管提出變更需求，業務接到通知後與客戶郵件溝通。
4. 訂單變更時，廠內不發行訂單變更通知單，只以郵件方式通知生管。
出貨管理
1. 目前有一家客戶：旭麗，在出貨時不算銷貨，在客戶倉庫屬代管，客戶在自已倉庫領出使用後，以每月領出使用的量作為結算依據。
2. 樣品出貨，在現有系統內，一部分樣品從工程單位直接出貨，不入成品倉庫，系統內也不會有樣品定單。（現在的做法：因爲樣板要從工程出，所以業務就不能用正式的送貨單給客戶，只能手工做送貨單，然後用這份送貨單製作相應的發票，所以在月底對帳的時候系統中不能直接導出，而是需要手工將這一部分追加上去。 數量較大或者交貨次數較多時容易出現錯誤。 希望做法：因爲手板零件大部分是外發製作，厰内一般不會將其輸入系統。希望此部分可以在系統中用另外一種方式完成 注：客戶會提供料號或者品名）另一部分樣品入成品倉庫，需在系統內建立樣品定單，出貨時走正常出貨流程。
3. 出貨備品處理：現有一家客戶出貨時需要1％的備品，訂單和計畫內都不體現備品數量，只是在倉庫出貨時，倉管員多給1％。
4. 銷貨流程：
1) 業務部提前兩天開出貨通知單，出貨通知單上含嘜頭資訊，列印簽核，出貨通知單一式六聯，通知生管、業務出貨組、品質、成品倉、包裝等，倉庫接到出貨通知單後，安排出貨，並開立成品裝箱單。
2) 若出海外部分，業務需另開Invoice及Packing List。倉庫開立成品裝箱單後，轉交業務部出貨組，出貨組開立送貨單。並負責成品之出貨。國內客戶送貨單會簽回。
退貨管理
1. 退貨分為兩種情況：
1) 一種是產品出現品質問題需要退貨的，則由客戶先退貨，公司再進行補貨處理，有些產品客戶不需要重新補貨，只需沖銷應收款；
2) 另一種是實物不退回，如國外客戶，只是財務沖銷應收款或重新補貨處理。
2. 退貨時有些能核對到訂單和銷貨，有些無法核對。
若無法核對訂單及銷貨單的，沖銷應收款時則以最新交易單價扣款，補貨時備註退貨單號，能核對到訂單或銷貨單的，補貨時則需備註訂單號。
所有退回品必須經品檢後入庫。
3. 客退品經品管判定後，廠內處理時有三種情況，
1) 第一種：直接報廢，
2) 另一種先入庫，
3) 第三種則開立退回加工單返回生產線重工，再直接出給客戶。
建議以後走重工流程，生管開立重工制令。
2. 採購部
供應商管理
1. 目前公司共有供應商100家左右，目前供應廠商分為三大類：原料廠商、輔材廠商、模具廠商。
2. 供應商的編碼原則為3位元－XXX，第一位表示上面的三種大類，但有廠商會供應不同的產品時，不知道將其劃為哪一類，編碼比較混亂。
3. 供應商只根據供應材料的不同進行分類管理，沒有按地區或國家進行分類，原料會按材質、製造商（高爐廠）、供應商做統計分析。
4. 目前有每月進行供應商考核，月底按供應商交期、服務、及品管提供的品質狀況進行評核。
請購管理
目前公司不走請購流程（即不填請購單，生產用料不走請購流程）。
採購單建立
公司目前鋼材的採購方式是，一部分按照客戶Forecast及訂單評估後備料，一部分按單採購，一部分為客戶通知高爐廠後，高爐廠生產完畢通知 TSMC，TSMC 視情況提前採購，其採購來源主要為生管給出的物料需求表：
1. 採購週期：國內一般4-5個工作日，國外進口料件，若廠商有備庫存，採購週期在2個月，沒有備庫存的，至少需提前三個月。
2. 原材的採購有些客戶會指定高爐廠及供應商，採購料件需能追蹤高爐廠及供應商。客戶指定高爐廠及供應商的原材，建議在料號上做區分。採購單上需能體現料件的製造商（高爐廠）及供應商。
3. 有材料認可的管理需求，未經過認可的材料或供應商不允許下採購單。
4. 採購單目前會在現有系統內建立訂購單，不含價格，簽核完後提交廠商。另外以Excel檔的形式，做一份原材料單價表。但月底時還需另外手工列印一份訂購單，和以前訂購單內容一樣，只是會帶上單價，將此資料給香港。
5. 每月25號左右下單給供應廠商，次月初時再補不足量。
6. 試樣有部分不下採購單，實物可能經過倉庫，但不入倉庫帳。
7. 包材由倉庫寫物品需求單簽核後提交採購。物料採購各單位填寫物品需求單簽核後提交採購。
8. 採購簽核時分急件與非急件，急件須簽至財管即可進行採購。
採購變更
1. 目前採購單變更沒有規則，生管提出變更需求，由採購與廠商協商。
2. 採購變更時，需另外列印採購變更單，簽核完後傳真供應廠商，但小宗交易變更時，則沒有列印採購變更單，只是在原訂單上文字說明，主管簽字後即可。
========
採購進貨
========
1.
除原材部分允許10%的超交外，其它不允許超交，
但有些因生產問題，也有超過10%也需要收貨，
此部分一般在發採購單與供應商溝通時就已知道，
會郵件聯絡各單位，
建議此情形若在下單階段就知道，須變更採購單。
>>>>>>>>>>>>>>>>>>>>>>
>>另外需要超交標準設定
>>另外專案超交標準設定
>>>>>>>>>>>>>>>>>>>>>>
2.一般允許分批交貨，而且包裝材料必須按實際生產進度需要另做交貨排程通知供應商交貨。
3. 採購進貨時，由廠商填寫 TSMC 格式的送貨單，將實物送至總廠收料中心，由收料中心、倉管收料員、品管負責收貨。其流程為：
1) 原料倉在實際材料上貼卷號條碼標籤（卷號指每卷材料或片材每包裝，為品質追溯的需求，須每卷材料都進行不同的編碼，並在保存、後繼生產、出貨等過程中進行正向和反向追溯而編此號），
2) 收料中心檢查送貨單與實物是否相符，原料倉開立原材料採購入為單。品管負責檢驗。在入庫時卷材須能記錄料號、卷號、重量、高爐廠、供應商、訂單號、進貨日期、母材、捆包號(即供應商卷號)等。
3) 片材須能記錄：料號、卷號、片數（需默認包裝片數，但允許用戶自行修改：如尾數）、重量、高爐廠、供應商、進貨日期、母材、捆包號等。
4) 後續為管控先進先出，則須按照入庫日期管控領用，按卷號做品質追溯。
4. 目前原材70%--80%料件為客戶指定高爐廠、及供應商，另一部分則不同供應商及高爐廠的同規格材料可以互相替代使用。
在料號編碼時，建議：客戶指定原材之高爐廠及供應商的，料號編碼須做區分；不同供應商及高爐廠同規格材料或以互相替代使用的，則料號編碼須編同一料號表示。
若同一高爐廠之不同供應商材料可以替代使用時，則料號編碼時只需將高爐廠作區分，不區分供應商。
採購退貨
(1). 品質有問題時，品管會驗退。
(2). 倉退時有兩種處理方式：一種是實物退回，必須有 退貨單沖銷對應的進貨單，此退貨一般需要補回；另一種是由供應商換貨，不扣貨款。
(3). 單據處理上由倉庫建立退貨單，對帳時由採購查詢單價。若需重新補貨時，則按原退貨單號補貨，不沖銷以前訂單的已送貨數量，也不另外開立新的PO。
3.倉庫管理
(1).目前總廠倉庫分為：原材倉庫、包材倉、成品倉、模具物料倉、外發虛擬倉、二廠對應原材、包材、成品倉。
(2).實際倉庫有劃分區域管理，為方便實物管理，快速存、取貨物之用。
(3).目前都是環保料件，以前有環保與非環保交替的情形出現。若以後再有此類狀況，建議在料號上作區分。
4. 批號管理：目前原料和成品都需作先進先出管理、保質期失效期管理以及後續追蹤處理。
5. 可回收包裝箱在管理時，由包裝產線開領料單至倉庫領料，接著入包裝後的成品至成品倉庫，再發貨給客戶，發貨給客戶後需要管控周轉箱的回收。倉庫人員想知道，公司現有多少可回收周轉箱，這些周轉箱都在哪些地方。因為目前沒有管控包裝產線入到成品倉的數量，所以無法知道周轉箱存放的地點。
6. 盤點管理：現在兩種盤點：月盤及年終盤點，月盤為倉庫自行盤點，
1） 月底盤點時，產線也需要清線，帳務部分做虛擬退倉，實物不做退庫。
2）年終盤點則會列印盤點卡及盤點清冊。原材料不允許出現盤差，其它有盤差時，目前沒有盤差調整申請流程。
7. 報廢流程：目前生產線自行填寫報廢單，經品管判定及相關人員簽核後，報廢至倉庫。至倉庫後倉庫需另外再重新填寫報廢單，重新走報廢流程。
8. 資材課下設委外發中心，所有托外加工部分都由外發中心管理。
9. 系統需求：目前倉庫沒有進行ABC管理、沒有做迴圈盤點管理、呆滯分析，但有做ABC管理、迴圈盤點管理、呆滯分析的需求。
4. 工程
產品工程資料：
1. 目前成品、半品、原材都以客戶料號為主。經前階段討論，未來將對材料進行重新編碼，原材編碼建議參見採購說明。成品以客戶料號編碼，半品以客戶料號加工藝識別碼識別。
2. 產品BOM並不複雜，為管控生產進度，將以BOM斷階及工藝管理結合進行管控。如下圖結構示意圖：
3. 新品報價時，業務發圖面給設計和工程，由設計課報模具、材料、設備加工費用，貼紙、鉚軸、捆包須工程課出相關圖面給採購詢價。報價階段都沒有正式的料號。
4. 下了樣品定單的都會由生管開立物品需求單，手板則由業務部開立需求單工程審核後交由採購處理。
新BOM建立流程
1. 對於新產品，業務發出圖面，設計課根據設計開立原材料需求表給工程，工程課在系統內建立料號及BOM相關資料。
2. BOM表內不會標明產品加工工藝，但在QC控制圖內會標明產品相關工藝。
3. BOM表內材料有一部分為治具，在BOM表內只作標示，其領料碼應設置為不發料，另有一些可能為客戶供給的材料，應定義為客供料。後期計算成本時，客供料雖然發料，但不計入直接材料成本。
4. BOM經簽核後發行。
ECN變更流程
1. 客戶設變後，有發行工程變更。目前有出現變更後，因現場或在庫沒有及時清理，出貨匯入舊版一起出貨。
2. 工程課反映設變後延誤通知工程，有些三次元了才通知工程，變更通知單發行比較滯後，造成流程上混亂。建議重新協定變更流程。
3. 若需變更供應商，則須採購開立原材料試樣申請單，工程再試樣。
5. 生管部門
計畫制定
1. TSMC 目前的生產模式屬於接單式生產，生產計畫基本來源於客戶正式訂單，部分材料根據銷售預測作為參考，參與人為經驗調整後進行備料。
2. 生管制定生產計畫排程以月為單位，每月23號左右排出生產計畫及備料計畫，次月初有變更時，則會以郵件方式發急件通知變更計畫。有些大訂單分批次下生產計畫（開立制令時需要能有工單拆解功能，分批次進行工單生產追蹤）
計畫發放流程
目前沒有明確開立制令，以月度生產排程為准，後繼則須開立正式製造命令單，以便追蹤生產、核算生產成本。生產計畫無法直接利用客戶Forecast及訂單作為計畫來源，變異性很大，也不完全是有訂單才生產。
計畫變更作業
計畫變更較為頻繁，變更需求主要來自客戶訂單變更，其次來自生管的變更，變更一般以郵件方式溝通，不另行發變更檔。
6. 生產部
按照生管發放的月生產計畫及急件通知安排生產。總廠生產部包含：衝壓課、加工課、包裝課。
生產領退料
1. 生產線有專人負責領料，一般架模具時領料。
2. 生管排生產計畫及急件通知都會給倉庫和生產，生產線按照排產計畫自行開立領料單至倉庫領料，倉庫按照排產備料。但無法核算工單用料，無法管控超領。在領料時，需按工藝分工作組各自領料。
3. 原材領料須按先進先出規則管控領料，領料單上須顯示與入庫單相似的資訊，即：料號、卷號、材質、母材、供應商卷號、重量等相關資訊。
4. 有些卷材無法分割按工單領料，只能整卷整卷髮料。可以使用用產線倉庫自動扣料功能，或退料模式，若採用退料模式，則須及時退庫，否則做計畫時無法知道領用未使用完，還有餘料。
5. 目前發料時，不會考慮用料的合理損耗。
6. 超耗領料：生產部自行開立原料領料單，簽核後至倉庫領料，超領時生管另外開立慮擬的制令，為超領開單使用。建議以後以制分析管控領料及超領。
7. 挪料：一些共用料件會挪料，挪料時未辦相關手續，不走單據。
8. 一部分原材領幫至產線拆裝後，長期露置在空氣中，會對產品品質有影響，也有保質期管理需求。
生產線報廢
生產線填寫報廢單，經簽核後入到倉庫，倉庫再填寫相同的報廢單，重新簽核一次才算正式報廢。在產線報廢時，量小由各生產課自行報廢，量大時，統一交由包裝部統一填寫報廢單報廢。
生產報工
1. 衝壓生產線每班填寫個人生產日報表，需登記機台編號、日期、班次、機種、料號、原材供應商、供應商卷材編碼、重量、加工數、調模報廢、料頭料尾報廢、衝壓報廢、完成良品數、時間、時數、模具裝況、及衝床時間使用狀況。
根據輸入的生產日報表產生衝壓產能統計表，作為早會開會的依據。必當日早上8：30天早會前看到昨天的生產資料。
2. 加工生產線每班填寫：個人攻牙日報及個人鉚軸生產日報，現有系統內只錄入統計攻牙工序日報表。
3. 現在生產入庫未按制令入庫，未來若需要產生成本資料，須按工單收集工時。
委外加工
1. 委外加工廠商的管理由倉庫委外中心執行，目前沒有設立供應商倉庫管理外點庫存，外發產品也沒有入到實際倉庫後發出，而是在產線暫存區域直接外發給委外廠商。
2. 委外也沒有委外加工制令，只有相應的發料及回收單。這種方式不利於委外核銷及委外用料分析。
3. 加工費用由委外中心與委外加工廠商對帳。
四、總結
以上只是對現行各個部門業務流程初步的瞭解，隨著專案的展開和深入，將會有更細緻更具體的瞭解，同時也將發現系統操作面和功能面與 TSMC 當前運作習慣的差異，因此建議在項目的實施階段，本著使用系統現有功能至最大程度為首要原則，必要時才進行適當的二次開發，保證項目能按照計畫進行並順利上線。
一、 引言
1. 編寫目的
通過瞭解 TSMC（以下簡稱 TSMC）現狀，分析企業業務流程及管理之重點，
為BPI企業流程、明確軟體功能需求以及評估軟體二次開發需求而撰寫本文。
本文的讀者為專案的組織實施者、專案二次開發系統分析及軟體發展人員等。
2. 文檔背景
調研時間：2009年03月2日、3日共兩個工作日
調研地點：TSMC總廠辦公室
參與人員：TSMC MIS、TSMC 專案小組各成員、TSMC 總廠各部門相關人員
調研範圍：TSMC 總廠銷售、採購、工程、生管、倉庫、等主要業務的現行流程
3. 參考資料
A. 藍道科技ERP 系統文檔書寫規範
B. 系統總體進度表
C. 各部門提供的相關表單及文檔
二、公司概況
TSMC 總廠、二廠、及制三，總廠、二廠以五金衝壓及五金模具設計製造為主
三、現行業務流程說明
1. 銷售部門
總廠業務部門負責總廠、二廠以及製造三部相關業務部門工作，擔當與客戶溝通的視窗。
客戶關係管理
1. 公司客戶目前主要為日資企業，如先鋒、日立等，另一類客戶為利盟指定的二級客戶。但隨著公司經營，客戶數將逐漸增加。
2. 目前客戶代號兩碼，有些以客戶英文名稱中的兩個英文字母表示，有些以漢字首兩個漢字的拼音字母表示，沒有統一規範，有規範統一編碼的需求。
3. 目前沒有客戶分級管理，但手工有做銷售分析，分別按產品做營業額、毛利分析，按客戶做營業額、毛利分析。按產品類別（如DVD、車載等）分析營業額及毛利。
4. 目前客戶如先鋒，其有不同的出貨地點，如香港、深圳等。出貨及開發票時都會開不同的公司抬頭，在分析報表時也需要將同一客戶不同區域匯總。（因此建議客戶編碼時，將不同區域的客戶建立成不同的客戶，在客戶編碼時，將同一客戶不同出貨區域客戶編碼，在編碼上讓其排列在相鄰區域。）
5. 目前暫不存在總公司和分公司的客戶模式，即與分公司交易，與總公司結款的模式。
6. 目前沒有做信用額度的管控，因為幾個大客戶都是很穩定的，但有部分壞帳，有管控壞帳風險的需求。
報價
1. 新產品客戶詢價時，客戶會聯繫業務要求報價。
2. 新品報價後，可能有一部分產品不會在公司生產，只是工程品，在系統內只記錄其總價。還沒有正式品號報價時，系統需要有專用於報價的料號，此料號應能設定其可以更改品名規格，在報價時更改品名規格，為沒有正式料號的產品作報價使用。（關於工程樣板的報價，一般沒有零件規格尺寸只有材質，但是需要顯示其數量，單價和縂價值。部分情況下還需要模具費的報價）
3. 沒有正式生產前，報價都沿用客戶料號，正式生產後，工程會會編立正式的料號。
4. 目前對外有統一的報價單格式，因涉及到模具開發成本及生產批量、採購批量原因，報價時會有分量計價的需求。（分量計價指：不同數量範圍，單價不同）
5. 報價時需能記錄材質、模具價格、部品價格等。
訂單核價
1. 銷售價格基本上以每次的合同價為准，若客戶需要降價，會重新報價。不同的客戶有不同的價格，需分量計價。
2. 價格的調整沒有固定的週期，要求每次的交易價格可以回寫價格資料檔。
3. 降價後，有客戶對未交完貨的訂單，要變更為新的單價交易。或出完貨後，還未結帳的客戶要求變更為新的單價結算。
Forecast
1. 客戶每月給一次後三至四個月的需求。有些客戶不會給Forecast，但會提前一個月下定單給業務，但需求變更都很大。
2. 業務部門會以銷售計畫統計表的形式統計回饋給生管，每月統計，在18號前提交生管單位。
訂單建立
1. 訂單的來源為國內、國外客戶及制三，客戶以傳真或郵件方式通知業務，即使電話口頭通知，事後也會補單。
2. 業務以銷售計畫統計表通知生管，若有變更時，會另外以郵件方式通知生管。目前計畫變更頻繁，且緊急插單情況頻繁。
3. 訂單類型：訂單通常分為三種：
1) 一種：一部分客戶不下Forecast，但會提前將訂單下出，後以交貨排程來安排生產，此類定單一般不安排生產主要用於備料；
2) 一種是客戶下Forecast後再正式訂單通知業務，Forecast可以作業備料的參考依據，因Forecast變更較大，在此基礎上會有調整，生產則以正式訂單安排生產。
3) 還有一種是樣品訂單，和正式訂單一樣，樣品訂單也納入生產計畫由車間進行生產，在接單時一般可確定樣品訂單是否收款。（樣板訂單和量產訂單的單價會有不一樣的情況）
4. 訂單評審沒有專門的會議和書面的評審資料，但業務會以電話或郵件告知生管，主要由生管和其它部門確認客戶的交期是否可以達到，評審確認後即可轉為公司的內部訂單。訂單的簽核則由業務主管，再到副總簽字。簽完字後轉生管一聯。
訂單變更
1. 目前訂單變更的頻度比較高，變更的內容主要是調整數量和變更交期。
2. 客戶訂單變更時，有些強制取消，有些取消時會與業務溝通，有些已經做好，也有可能取消，中間損失的吸收需業務與客戶協定方案。少部分客戶會有簽字蓋章的文書郵件通知業務。
3. 訂單內部變更需求時，由生管提出變更需求，業務接到通知後與客戶郵件溝通。
4. 訂單變更時，廠內不發行訂單變更通知單，只以郵件方式通知生管。
出貨管理
1. 目前有一家客戶：旭麗，在出貨時不算銷貨，在客戶倉庫屬代管，客戶在自已倉庫領出使用後，以每月領出使用的量作為結算依據。
2. 樣品出貨，在現有系統內，一部分樣品從工程單位直接出貨，不入成品倉庫，系統內也不會有樣品定單。（現在的做法：因爲樣板要從工程出，所以業務就不能用正式的送貨單給客戶，只能手工做送貨單，然後用這份送貨單製作相應的發票，所以在月底對帳的時候系統中不能直接導出，而是需要手工將這一部分追加上去。 數量較大或者交貨次數較多時容易出現錯誤。 希望做法：因爲手板零件大部分是外發製作，厰内一般不會將其輸入系統。希望此部分可以在系統中用另外一種方式完成 注：客戶會提供料號或者品名）另一部分樣品入成品倉庫，需在系統內建立樣品定單，出貨時走正常出貨流程。
3. 出貨備品處理：現有一家客戶出貨時需要1％的備品，訂單和計畫內都不體現備品數量，只是在倉庫出貨時，倉管員多給1％。
4. 銷貨流程：
1) 業務部提前兩天開出貨通知單，出貨通知單上含嘜頭資訊，列印簽核，出貨通知單一式六聯，通知生管、業務出貨組、品質、成品倉、包裝等，倉庫接到出貨通知單後，安排出貨，並開立成品裝箱單。
2) 若出海外部分，業務需另開Invoice及Packing List。倉庫開立成品裝箱單後，轉交業務部出貨組，出貨組開立送貨單。並負責成品之出貨。國內客戶送貨單會簽回。
退貨管理
1. 退貨分為兩種情況：
1) 一種是產品出現品質問題需要退貨的，則由客戶先退貨，公司再進行補貨處理，有些產品客戶不需要重新補貨，只需沖銷應收款；
2) 另一種是實物不退回，如國外客戶，只是財務沖銷應收款或重新補貨處理。
2. 退貨時有些能核對到訂單和銷貨，有些無法核對。
若無法核對訂單及銷貨單的，沖銷應收款時則以最新交易單價扣款，補貨時備註退貨單號，能核對到訂單或銷貨單的，補貨時則需備註訂單號。
所有退回品必須經品檢後入庫。
3. 客退品經品管判定後，廠內處理時有三種情況，
1) 第一種：直接報廢，
2) 另一種先入庫，
3) 第三種則開立退回加工單返回生產線重工，再直接出給客戶。
建議以後走重工流程，生管開立重工制令。
2. 採購部
供應商管理
1. 目前公司共有供應商100家左右，目前供應廠商分為三大類：原料廠商、輔材廠商、模具廠商。
2. 供應商的編碼原則為3位元－XXX，第一位表示上面的三種大類，但有廠商會供應不同的產品時，不知道將其劃為哪一類，編碼比較混亂。
3. 供應商只根據供應材料的不同進行分類管理，沒有按地區或國家進行分類，原料會按材質、製造商（高爐廠）、供應商做統計分析。
4. 目前有每月進行供應商考核，月底按供應商交期、服務、及品管提供的品質狀況進行評核。
請購管理
目前公司不走請購流程（即不填請購單，生產用料不走請購流程）。
採購單建立
公司目前鋼材的採購方式是，一部分按照客戶Forecast及訂單評估後備料，一部分按單採購，一部分為客戶通知高爐廠後，高爐廠生產完畢通知 TSMC，TSMC 視情況提前採購，其採購來源主要為生管給出的物料需求表：
1. 採購週期：國內一般4-5個工作日，國外進口料件，若廠商有備庫存，採購週期在2個月，沒有備庫存的，至少需提前三個月。
2. 原材的採購有些客戶會指定高爐廠及供應商，採購料件需能追蹤高爐廠及供應商。客戶指定高爐廠及供應商的原材，建議在料號上做區分。採購單上需能體現料件的製造商（高爐廠）及供應商。
3. 有材料認可的管理需求，未經過認可的材料或供應商不允許下採購單。
4. 採購單目前會在現有系統內建立訂購單，不含價格，簽核完後提交廠商。另外以Excel檔的形式，做一份原材料單價表。但月底時還需另外手工列印一份訂購單，和以前訂購單內容一樣，只是會帶上單價，將此資料給香港。
5. 每月25號左右下單給供應廠商，次月初時再補不足量。
6. 試樣有部分不下採購單，實物可能經過倉庫，但不入倉庫帳。
7. 包材由倉庫寫物品需求單簽核後提交採購。物料採購各單位填寫物品需求單簽核後提交採購。
8. 採購簽核時分急件與非急件，急件須簽至財管即可進行採購。
採購變更
1. 目前採購單變更沒有規則，生管提出變更需求，由採購與廠商協商。
2. 採購變更時，需另外列印採購變更單，簽核完後傳真供應廠商，但小宗交易變更時，則沒有列印採購變更單，只是在原訂單上文字說明，主管簽字後即可。
========
採購進貨
========
1.
除原材部分允許10%的超交外，其它不允許超交，
但有些因生產問題，也有超過10%也需要收貨，
此部分一般在發採購單與供應商溝通時就已知道，
會郵件聯絡各單位，
建議此情形若在下單階段就知道，須變更採購單。
>>>>>>>>>>>>>>>>>>>>>>
>>另外需要超交標準設定
>>另外專案超交標準設定
>>>>>>>>>>>>>>>>>>>>>>
2.一般允許分批交貨，而且包裝材料必須按實際生產進度需要另做交貨排程通知供應商交貨。
3. 採購進貨時，由廠商填寫 TSMC 格式的送貨單，將實物送至總廠收料中心，由收料中心、倉管收料員、品管負責收貨。其流程為：
1) 原料倉在實際材料上貼卷號條碼標籤（卷號指每卷材料或片材每包裝，為品質追溯的需求，須每卷材料都進行不同的編碼，並在保存、後繼生產、出貨等過程中進行正向和反向追溯而編此號），
2) 收料中心檢查送貨單與實物是否相符，原料倉開立原材料採購入為單。品管負責檢驗。在入庫時卷材須能記錄料號、卷號、重量、高爐廠、供應商、訂單號、進貨日期、母材、捆包號(即供應商卷號)等。
3) 片材須能記錄：料號、卷號、片數（需默認包裝片數，但允許用戶自行修改：如尾數）、重量、高爐廠、供應商、進貨日期、母材、捆包號等。
4) 後續為管控先進先出，則須按照入庫日期管控領用，按卷號做品質追溯。
4. 目前原材70%--80%料件為客戶指定高爐廠、及供應商，另一部分則不同供應商及高爐廠的同規格材料可以互相替代使用。
在料號編碼時，建議：客戶指定原材之高爐廠及供應商的，料號編碼須做區分；不同供應商及高爐廠同規格材料或以互相替代使用的，則料號編碼須編同一料號表示。
若同一高爐廠之不同供應商材料可以替代使用時，則料號編碼時只需將高爐廠作區分，不區分供應商。
採購退貨
(1). 品質有問題時，品管會驗退。
(2). 倉退時有兩種處理方式：一種是實物退回，必須有 退貨單沖銷對應的進貨單，此退貨一般需要補回；另一種是由供應商換貨，不扣貨款。
(3). 單據處理上由倉庫建立退貨單，對帳時由採購查詢單價。若需重新補貨時，則按原退貨單號補貨，不沖銷以前訂單的已送貨數量，也不另外開立新的PO。
3.倉庫管理
(1).目前總廠倉庫分為：原材倉庫、包材倉、成品倉、模具物料倉、外發虛擬倉、二廠對應原材、包材、成品倉。
(2).實際倉庫有劃分區域管理，為方便實物管理，快速存、取貨物之用。
(3).目前都是環保料件，以前有環保與非環保交替的情形出現。若以後再有此類狀況，建議在料號上作區分。
4. 批號管理：目前原料和成品都需作先進先出管理、保質期失效期管理以及後續追蹤處理。
5. 可回收包裝箱在管理時，由包裝產線開領料單至倉庫領料，接著入包裝後的成品至成品倉庫，再發貨給客戶，發貨給客戶後需要管控周轉箱的回收。倉庫人員想知道，公司現有多少可回收周轉箱，這些周轉箱都在哪些地方。因為目前沒有管控包裝產線入到成品倉的數量，所以無法知道周轉箱存放的地點。
6. 盤點管理：現在兩種盤點：月盤及年終盤點，月盤為倉庫自行盤點，
1） 月底盤點時，產線也需要清線，帳務部分做虛擬退倉，實物不做退庫。
2）年終盤點則會列印盤點卡及盤點清冊。原材料不允許出現盤差，其它有盤差時，目前沒有盤差調整申請流程。
7. 報廢流程：目前生產線自行填寫報廢單，經品管判定及相關人員簽核後，報廢至倉庫。至倉庫後倉庫需另外再重新填寫報廢單，重新走報廢流程。
8. 資材課下設委外發中心，所有托外加工部分都由外發中心管理。
9. 系統需求：目前倉庫沒有進行ABC管理、沒有做迴圈盤點管理、呆滯分析，但有做ABC管理、迴圈盤點管理、呆滯分析的需求。
4. 工程
產品工程資料：
1. 目前成品、半品、原材都以客戶料號為主。經前階段討論，未來將對材料進行重新編碼，原材編碼建議參見採購說明。成品以客戶料號編碼，半品以客戶料號加工藝識別碼識別。
2. 產品BOM並不複雜，為管控生產進度，將以BOM斷階及工藝管理結合進行管控。如下圖結構示意圖：
3. 新品報價時，業務發圖面給設計和工程，由設計課報模具、材料、設備加工費用，貼紙、鉚軸、捆包須工程課出相關圖面給採購詢價。報價階段都沒有正式的料號。
4. 下了樣品定單的都會由生管開立物品需求單，手板則由業務部開立需求單工程審核後交由採購處理。
新BOM建立流程
1. 對於新產品，業務發出圖面，設計課根據設計開立原材料需求表給工程，工程課在系統內建立料號及BOM相關資料。
2. BOM表內不會標明產品加工工藝，但在QC控制圖內會標明產品相關工藝。
3. BOM表內材料有一部分為治具，在BOM表內只作標示，其領料碼應設置為不發料，另有一些可能為客戶供給的材料，應定義為客供料。後期計算成本時，客供料雖然發料，但不計入直接材料成本。
4. BOM經簽核後發行。
ECN變更流程
1. 客戶設變後，有發行工程變更。目前有出現變更後，因現場或在庫沒有及時清理，出貨匯入舊版一起出貨。
2. 工程課反映設變後延誤通知工程，有些三次元了才通知工程，變更通知單發行比較滯後，造成流程上混亂。建議重新協定變更流程。
3. 若需變更供應商，則須採購開立原材料試樣申請單，工程再試樣。
5. 生管部門
計畫制定
1. TSMC 目前的生產模式屬於接單式生產，生產計畫基本來源於客戶正式訂單，部分材料根據銷售預測作為參考，參與人為經驗調整後進行備料。
2. 生管制定生產計畫排程以月為單位，每月23號左右排出生產計畫及備料計畫，次月初有變更時，則會以郵件方式發急件通知變更計畫。有些大訂單分批次下生產計畫（開立制令時需要能有工單拆解功能，分批次進行工單生產追蹤）
計畫發放流程
目前沒有明確開立制令，以月度生產排程為准，後繼則須開立正式製造命令單，以便追蹤生產、核算生產成本。生產計畫無法直接利用客戶Forecast及訂單作為計畫來源，變異性很大，也不完全是有訂單才生產。
計畫變更作業
計畫變更較為頻繁，變更需求主要來自客戶訂單變更，其次來自生管的變更，變更一般以郵件方式溝通，不另行發變更檔。
6. 生產部
按照生管發放的月生產計畫及急件通知安排生產。總廠生產部包含：衝壓課、加工課、包裝課。
生產領退料
1. 生產線有專人負責領料，一般架模具時領料。
2. 生管排生產計畫及急件通知都會給倉庫和生產，生產線按照排產計畫自行開立領料單至倉庫領料，倉庫按照排產備料。但無法核算工單用料，無法管控超領。在領料時，需按工藝分工作組各自領料。
3. 原材領料須按先進先出規則管控領料，領料單上須顯示與入庫單相似的資訊，即：料號、卷號、材質、母材、供應商卷號、重量等相關資訊。
4. 有些卷材無法分割按工單領料，只能整卷整卷髮料。可以使用用產線倉庫自動扣料功能，或退料模式，若採用退料模式，則須及時退庫，否則做計畫時無法知道領用未使用完，還有餘料。
5. 目前發料時，不會考慮用料的合理損耗。
6. 超耗領料：生產部自行開立原料領料單，簽核後至倉庫領料，超領時生管另外開立慮擬的制令，為超領開單使用。建議以後以制分析管控領料及超領。
7. 挪料：一些共用料件會挪料，挪料時未辦相關手續，不走單據。
8. 一部分原材領幫至產線拆裝後，長期露置在空氣中，會對產品品質有影響，也有保質期管理需求。
生產線報廢
生產線填寫報廢單，經簽核後入到倉庫，倉庫再填寫相同的報廢單，重新簽核一次才算正式報廢。在產線報廢時，量小由各生產課自行報廢，量大時，統一交由包裝部統一填寫報廢單報廢。
生產報工
1. 衝壓生產線每班填寫個人生產日報表，需登記機台編號、日期、班次、機種、料號、原材供應商、供應商卷材編碼、重量、加工數、調模報廢、料頭料尾報廢、衝壓報廢、完成良品數、時間、時數、模具裝況、及衝床時間使用狀況。
根據輸入的生產日報表產生衝壓產能統計表，作為早會開會的依據。必當日早上8：30天早會前看到昨天的生產資料。
2. 加工生產線每班填寫：個人攻牙日報及個人鉚軸生產日報，現有系統內只錄入統計攻牙工序日報表。
3. 現在生產入庫未按制令入庫，未來若需要產生成本資料，須按工單收集工時。
委外加工
1. 委外加工廠商的管理由倉庫委外中心執行，目前沒有設立供應商倉庫管理外點庫存，外發產品也沒有入到實際倉庫後發出，而是在產線暫存區域直接外發給委外廠商。
2. 委外也沒有委外加工制令，只有相應的發料及回收單。這種方式不利於委外核銷及委外用料分析。
3. 加工費用由委外中心與委外加工廠商對帳。
四、總結
以上只是對現行各個部門業務流程初步的瞭解，隨著專案的展開和深入，將會有更細緻更具體的瞭解，同時也將發現系統操作面和功能面與 TSMC 當前運作習慣的差異，因此建議在項目的實施階段，本著使用系統現有功能至最大程度為首要原則，必要時才進行適當的二次開發，保證項目能按照計畫進行並順利上線。
2010年3月24日 星期三
ERP 看到 Yeh 教授
ERP 看到 Yeh 教授!!
如何把ERP的導入和使用成本壓到最低？
丹尼爾一邊開車一邊想著。
>>
>>為什麼 ERP 導入要顧問
>>因為要幫你設定企業管理流程
>>因為要幫你設定對應會計科目
>>因為它無法記錄系統
>>取得會計科目的路徑
>>供使用者參考修正用
>>
>>教你管理
>>教你會計
>>教你系統
>>幫你客制化
>>你收顧問費每小時2500元
>>我收技術轉移每小時800元
>>??
ERP導入顧問費在台灣至少每小時2500元，
而中小企業彈性大，商務流程各不相同，
ERP常要客製，所以產品費、顧問費、
客製費加起來起碼要數百萬元，
中小企業負擔不起。
上線後的使用成本更高，
每年18%至22%的維護費、伺服器的費用、
以及要聘請一位或數位IT人員維持日常ERP運作，
這也是中小企業負擔不起的。
丹尼爾的學術背景使他想到，
能不能將SOA-ERP融入學校課程有系統的訓練
「學生顧問」並以「社會企業」的方式對中小企業提供服務呢？
ERP顧問需要多年的培養，怎麼可能用學生當顧問？
而且，為什麼用NEO結合學校課程而不是其他ERP系統？
如何把ERP的導入和使用成本壓到最低？
丹尼爾一邊開車一邊想著。
>>
>>為什麼 ERP 導入要顧問
>>因為要幫你設定企業管理流程
>>因為要幫你設定對應會計科目
>>因為它無法記錄系統
>>取得會計科目的路徑
>>供使用者參考修正用
>>
>>教你管理
>>教你會計
>>教你系統
>>幫你客制化
>>你收顧問費每小時2500元
>>我收技術轉移每小時800元
>>??
ERP導入顧問費在台灣至少每小時2500元，
而中小企業彈性大，商務流程各不相同，
ERP常要客製，所以產品費、顧問費、
客製費加起來起碼要數百萬元，
中小企業負擔不起。
上線後的使用成本更高，
每年18%至22%的維護費、伺服器的費用、
以及要聘請一位或數位IT人員維持日常ERP運作，
這也是中小企業負擔不起的。
丹尼爾的學術背景使他想到，
能不能將SOA-ERP融入學校課程有系統的訓練
「學生顧問」並以「社會企業」的方式對中小企業提供服務呢？
ERP顧問需要多年的培養，怎麼可能用學生當顧問？
而且，為什麼用NEO結合學校課程而不是其他ERP系統？
2010年3月19日 星期五
ERP 以前用SAP
>>這是明明需要有一個作業稱作 << 修正發票 >>
>>SAP 也不對為何要<迴轉物料>
>>現在你的系統也不對 <消退,原發票作廢,重打一張應收帳款單,
>> 自行輸入原銷貨單號,做一張出貨單,手動輸入應收帳款資料,並且載明原始出貨單,重新出發票>
>>明明就是需要一個<< 修正發票 >>作業
>>
>>SAP 也不對為何要<迴轉物料>
>>現在你的系統也不對 <消退,原發票作廢,重打一張應收帳款單,
>> 自行輸入原銷貨單號,做一張出貨單,手動輸入應收帳款資料,並且載明原始出貨單,重新出發票>
>>明明就是需要一個<< 修正發票 >>作業
>>
ERP 資通加油 不錯的軟體公司 有 ADempiere 水準
ERP 資通加油 不錯的軟體公司 有 ADempiere 水準
如果你愛台灣
400萬的台灣商用軟體
與
不用錢的 OpenSource 歐美共構
你會用哪一種!!
愛台灣請用愛心
購買台灣產品
令人愛不釋手的 ERP 底層架構
文 - 楊振源
首先還是分享一段冷笑話。
話說某日一位顧問到客戶端導入系統， MIS 問他：『 我用過4套 ERP 系統，每一套都有XX功能，為什麼你的系統沒有這個功能？ 』，該顧問回答：『 因為這是第5套。』
現在與各位分享傳說夢幻中，令 IT 人員愛不釋手的第 6 套 ArgoERP 系統的底層架構：
WEB 架構
透過 Browser ( IE / Firefox / Google … ) 就可以 RUN ArgoERP，沒有地點的限制，也沒有安裝 Client 端程式的負擔。
多語系架構
同一套程式執行碼，提供正體中文、簡體中文、英文… 等多語系架構，不會增加 IT 維護系統的額外負擔。系統 Prompt 可按需求自由設定調整，例如 “ 料號 ” 可自由調整為 “ 商品編號 ”。
多時區架構
Centralize DB 於總部統一管理，以簡化 IT 維護人力。可設定時區管理，由歐洲、美國、日本…等地連線回總部共用 DB 系統，但又各自保有該地區正確的時間。例如台灣 1 月 1 日，美國可是 12 月 31 日。
多公司架構
同一套 DB 之下的多公司架構，程式與資料庫只需要維護一套。設立一家新公司只要 30 秒鐘。跨公司基本資料彈性發佈，集團公司多角貿易資料拋轉、集團合併報表拋轉。
可依資料歸屬授權的架構
同樣有銷售訂單的執行權限，但是 A 就是看不到 B 的資料。比如 A 員管理倉庫 WH1、WH2， B 員管理倉庫 WH3、WH4，則可限定只可以看到自己所管理的倉庫資料。
可依程式欄位授權的架構
程式區塊 / 頁籤 / 欄位 / 按鈕 …等等元件，可以依照每位員工或群組授予各種權限。如此則可以免除一些不必要的程式客製。尤其對於成本 / 單價 …等等業主關心的資料安全問題。
與異質系統接口的架構
從基本資料如料件 / BOM / 客戶 / 廠商 …到開帳資料如應收 / 應付 / 傳票…再到交易資料如訂單 / 出貨單…等等，提供一系列異質系統資料介接的入口與API，有效整合或同步異質系統的資料。如 PLM 的料號或 BOM 透過介面 API 自動匯入 ArgoERP 系統，客戶的電子訂單透過介面 API 自動匯入 ArgoERP 的訂單系統。
預警功能的 ERP 架構
可以自行 SQL 設定警訊的條件 / 傳送資訊 / 收件人或群組…等等，於事件達到警示條件時，即自動發出 e-Mail 或簡訊通知相關人員。例如交期延誤一天通知課長，延誤兩天通知經理，延誤三天通知總經理…等設定。
可匯出 EXCEL 套範本的架構
凡是 ArgoERP Form 上面查詢得到的資料都可以匯出 EXCEL ，甚至匯到事先已建立好的套印範本，如 Invoice / Packing List 範本，或事先已建立的樞紐分析表範本。以增加資料彈性運用的空間。
俗話說，人對了，事情就對了。同樣的，選擇一套底層架構對的系統，你的 ERP 已經成功了一大半。根據中華企業資源規劃學會 ( CERPS ) 論文研究指出，讓使用者喜歡的 ERP 系統是確保導入成功的關鍵因素之一。
>>回電子報首頁
平均滿意度：5.00 / 總人數：3
您對這篇文章的滿意度：非常好
如果你愛台灣
400萬的台灣商用軟體
與
不用錢的 OpenSource 歐美共構
你會用哪一種!!
愛台灣請用愛心
購買台灣產品
令人愛不釋手的 ERP 底層架構
文 - 楊振源
首先還是分享一段冷笑話。
話說某日一位顧問到客戶端導入系統， MIS 問他：『 我用過4套 ERP 系統，每一套都有XX功能，為什麼你的系統沒有這個功能？ 』，該顧問回答：『 因為這是第5套。』
現在與各位分享傳說夢幻中，令 IT 人員愛不釋手的第 6 套 ArgoERP 系統的底層架構：
WEB 架構
透過 Browser ( IE / Firefox / Google … ) 就可以 RUN ArgoERP，沒有地點的限制，也沒有安裝 Client 端程式的負擔。
多語系架構
同一套程式執行碼，提供正體中文、簡體中文、英文… 等多語系架構，不會增加 IT 維護系統的額外負擔。系統 Prompt 可按需求自由設定調整，例如 “ 料號 ” 可自由調整為 “ 商品編號 ”。
多時區架構
Centralize DB 於總部統一管理，以簡化 IT 維護人力。可設定時區管理，由歐洲、美國、日本…等地連線回總部共用 DB 系統，但又各自保有該地區正確的時間。例如台灣 1 月 1 日，美國可是 12 月 31 日。
多公司架構
同一套 DB 之下的多公司架構，程式與資料庫只需要維護一套。設立一家新公司只要 30 秒鐘。跨公司基本資料彈性發佈，集團公司多角貿易資料拋轉、集團合併報表拋轉。
可依資料歸屬授權的架構
同樣有銷售訂單的執行權限，但是 A 就是看不到 B 的資料。比如 A 員管理倉庫 WH1、WH2， B 員管理倉庫 WH3、WH4，則可限定只可以看到自己所管理的倉庫資料。
可依程式欄位授權的架構
程式區塊 / 頁籤 / 欄位 / 按鈕 …等等元件，可以依照每位員工或群組授予各種權限。如此則可以免除一些不必要的程式客製。尤其對於成本 / 單價 …等等業主關心的資料安全問題。
與異質系統接口的架構
從基本資料如料件 / BOM / 客戶 / 廠商 …到開帳資料如應收 / 應付 / 傳票…再到交易資料如訂單 / 出貨單…等等，提供一系列異質系統資料介接的入口與API，有效整合或同步異質系統的資料。如 PLM 的料號或 BOM 透過介面 API 自動匯入 ArgoERP 系統，客戶的電子訂單透過介面 API 自動匯入 ArgoERP 的訂單系統。
預警功能的 ERP 架構
可以自行 SQL 設定警訊的條件 / 傳送資訊 / 收件人或群組…等等，於事件達到警示條件時，即自動發出 e-Mail 或簡訊通知相關人員。例如交期延誤一天通知課長，延誤兩天通知經理，延誤三天通知總經理…等設定。
可匯出 EXCEL 套範本的架構
凡是 ArgoERP Form 上面查詢得到的資料都可以匯出 EXCEL ，甚至匯到事先已建立好的套印範本，如 Invoice / Packing List 範本，或事先已建立的樞紐分析表範本。以增加資料彈性運用的空間。
俗話說，人對了，事情就對了。同樣的，選擇一套底層架構對的系統，你的 ERP 已經成功了一大半。根據中華企業資源規劃學會 ( CERPS ) 論文研究指出，讓使用者喜歡的 ERP 系統是確保導入成功的關鍵因素之一。
>>回電子報首頁
平均滿意度：5.00 / 總人數：3
您對這篇文章的滿意度：非常好
ERP 畫面複製 到底哪些不該複製 欄位複製設定篇
// fill data
if (copyCurrent)
{
boolean hasDocTypeTargetField = (getField("C_DocTypeTarget_ID") != null);
Object[] origData = getDataAtRow(currentRow);
for (int i = 0; i < size; i++)
{
GridField field = (GridField)m_fields.get(i);
String columnName = field.getColumnName();
if (field.isVirtualColumn())
;
else if (field.isKey()
|| columnName.equals("AD_Client_ID")
//
|| columnName.startsWith("Created") || columnName.startsWith("Updated")
|| columnName.equals("EntityType") || columnName.equals("DocumentNo")
|| columnName.equals("Processed") || columnName.equals("IsSelfService")
|| columnName.equals("DocAction") || columnName.equals("DocStatus")
|| columnName.equals("Posted") || columnName.equals("IsReconciled")
|| columnName.equals("IsApproved") // BF [ 1943682 ]
|| columnName.equals("IsGenerated") // BF [ 1943682 ]
|| columnName.startsWith("Ref_")
// Order/Invoice
|| columnName.equals("GrandTotal") || columnName.equals("TotalLines")
|| columnName.equals("C_CashLine_ID") || columnName.equals("C_Payment_ID")
|| columnName.equals("IsPaid") || columnName.equals("IsAllocated")
// Bug [ 1807947 ]
|| ( columnName.equals("C_DocType_ID") && hasDocTypeTargetField )
|| ( columnName.equals("Line") )
)
{
rowData[i] = field.getDefault();
field.setValue(rowData[i], m_inserting);
}
else
rowData[i] = origData[i];
}
}
if (copyCurrent)
{
boolean hasDocTypeTargetField = (getField("C_DocTypeTarget_ID") != null);
Object[] origData = getDataAtRow(currentRow);
for (int i = 0; i < size; i++)
{
GridField field = (GridField)m_fields.get(i);
String columnName = field.getColumnName();
if (field.isVirtualColumn())
;
else if (field.isKey()
|| columnName.equals("AD_Client_ID")
//
|| columnName.startsWith("Created") || columnName.startsWith("Updated")
|| columnName.equals("EntityType") || columnName.equals("DocumentNo")
|| columnName.equals("Processed") || columnName.equals("IsSelfService")
|| columnName.equals("DocAction") || columnName.equals("DocStatus")
|| columnName.equals("Posted") || columnName.equals("IsReconciled")
|| columnName.equals("IsApproved") // BF [ 1943682 ]
|| columnName.equals("IsGenerated") // BF [ 1943682 ]
|| columnName.startsWith("Ref_")
// Order/Invoice
|| columnName.equals("GrandTotal") || columnName.equals("TotalLines")
|| columnName.equals("C_CashLine_ID") || columnName.equals("C_Payment_ID")
|| columnName.equals("IsPaid") || columnName.equals("IsAllocated")
// Bug [ 1807947 ]
|| ( columnName.equals("C_DocType_ID") && hasDocTypeTargetField )
|| ( columnName.equals("Line") )
)
{
rowData[i] = field.getDefault();
field.setValue(rowData[i], m_inserting);
}
else
rowData[i] = origData[i];
}
}
2010年3月16日 星期二
ERP 如何大量客製化 ??
大量客製化的條件是什麼？
ERP如何大量客製化？
>>大量客製化的第1個條件，產品必須模組化。
>>也就是說，產品必須由數個模組構成，
>>而模組與模組之間必須有標準化的介面。
大量客製化本身是大問題 ??
應該是顧問可設定導向 !!
ERP如何大量客製化？
>>大量客製化的第1個條件，產品必須模組化。
>>也就是說，產品必須由數個模組構成，
>>而模組與模組之間必須有標準化的介面。
大量客製化本身是大問題 ??
應該是顧問可設定導向 !!
2010年2月13日 星期六
MDA ERP 資訊系統外購 與 部分包 與 全外包外
MDA ERP 資訊系統外購 與 部分包 與 全外包外
所謂外購::
1. 資訊系統外購:
這類公司認為資訊系統的開發不是該公司的核心業務, 公司應當集中資源於企業的核心工作上, 比如研發、生產、或銷售上面。而把資訊系統交給專業的軟件公司購買、維護。以達到最有效益的資源分配與運用。
2. 資訊系統外購+報表自行開發
這類型公司同上述類型的公司, 但是他們更注重資訊的分析與運用, 所以他們會聘雇IT人員自行開發管理用途的報表程式, 或引進BI軟件提供給資訊分析單位使用。
3. 系統底層外購+自行開發
這類型公司認為該公司的行業特殊性很高, 從外部找不到適合的軟件, 所以自外購入系統開發底層架構的東西, 然後自行量身訂做企業核心競爭力流程。
因為公司上述不同策略, 就會引進不同專長的人員,
如上第1類型的公司, 需要的不是技術人員, 而是專案管理人員,
通常會計部門主管或管理部門主管最適合擔任這個角色。
??不可以一二類混合型 也就是 僅幾支自己寫
??不可以一二類混合型 也就是 僅幾支自己調整
而第2類型的公司, 也僅僅需要會寫報表程式的技術人員即可。
而第3類則需要完整資訊公司各類型的技術人員。
??不可以一二三類混合型 也就是 僅幾支自己寫
??不可以一二三類混合型 也就是 僅幾支自己調整
而你所提到的企業內自行客製化,
我強烈強烈建議你,
不要幹這種事,
如此蠻幹只是滿足你寫程式的欲望,
卻造成你公司系統成為孤兒,
公司日後會付出很高很高的代價。
?? 真是有病 !!
難怪 鴻海改了鼎新系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
難怪 鴻海改了 SAP 系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
>> 公司日後會付出很高很高的代價 !!
就是原廠無法要你簽維護合約
就是你不想跟原廠簽維護合約
無法簽合約是很難過的事
就像結婚後離婚後又同居
沒有合約真恐怖
所謂外購::
1. 資訊系統外購:
這類公司認為資訊系統的開發不是該公司的核心業務, 公司應當集中資源於企業的核心工作上, 比如研發、生產、或銷售上面。而把資訊系統交給專業的軟件公司購買、維護。以達到最有效益的資源分配與運用。
2. 資訊系統外購+報表自行開發
這類型公司同上述類型的公司, 但是他們更注重資訊的分析與運用, 所以他們會聘雇IT人員自行開發管理用途的報表程式, 或引進BI軟件提供給資訊分析單位使用。
3. 系統底層外購+自行開發
這類型公司認為該公司的行業特殊性很高, 從外部找不到適合的軟件, 所以自外購入系統開發底層架構的東西, 然後自行量身訂做企業核心競爭力流程。
因為公司上述不同策略, 就會引進不同專長的人員,
如上第1類型的公司, 需要的不是技術人員, 而是專案管理人員,
通常會計部門主管或管理部門主管最適合擔任這個角色。
??不可以一二類混合型 也就是 僅幾支自己寫
??不可以一二類混合型 也就是 僅幾支自己調整
而第2類型的公司, 也僅僅需要會寫報表程式的技術人員即可。
而第3類則需要完整資訊公司各類型的技術人員。
??不可以一二三類混合型 也就是 僅幾支自己寫
??不可以一二三類混合型 也就是 僅幾支自己調整
而你所提到的企業內自行客製化,
我強烈強烈建議你,
不要幹這種事,
如此蠻幹只是滿足你寫程式的欲望,
卻造成你公司系統成為孤兒,
公司日後會付出很高很高的代價。
?? 真是有病 !!
難怪 鴻海改了鼎新系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
難怪 鴻海改了 SAP 系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
>> 公司日後會付出很高很高的代價 !!
就是原廠無法要你簽維護合約
就是你不想跟原廠簽維護合約
無法簽合約是很難過的事
就像結婚後離婚後又同居
沒有合約真恐怖
2010年2月6日 星期六
JANUS ERP java MDA 輸入更改取消查詢畫面 接太多了. 有人可以幫忙做嗎！！(剩7天到期)
標籤：soa mda erp 資訊義工
* [點數] 點數(20)
* [回答] 回答(0)
* [討論] 討論(0)
* [取消追蹤] 取消追蹤(1)
* 收藏(0)
* 贊助
* 轉寄
* 檢舉
JANUS ERP java MDA 畫面 接太多了. 有人可以幫忙做嗎！！
畫面包括 :: 輸入/更改/取消/查詢/拋轉/驗證
一個畫面基本價格 NTD 100元 ＋
一個欄位 NTD 10 元 +
一個欄位動態驗證 NTD 10元 +
一個欄位動態內定值 NTD 10元
這是我接的價格!! 有人要幫忙麻 !!
限國中以上畢業(彰化國中/陽明國中/彰安國中/精誠中學/彰中/彰女畢業生最好)
有 1000 個畫面經驗 ( Avg 30 fields/ 30 Callout / 30 Validation Rule)
可到大學研究所擔任 ADempiere ERP 專題實務顧問(國中畢業可)
要幫忙的可以免費幫你教到會
(限彰化人或在彰化縣讀國小/國中/高中者)
於 2010-01-30 21:42:16 補充
1. 資訊系統外購:
這類公司認為資訊系統的開發不是該公司的核心業務, 公司應當集中資源於企業的核心工作上, 比如研發、生產、或銷售上面。而把資訊系統交給專業的軟件公司購買、維護。以達到最有效益的資源分配與運用。
於 2010-02-06 19:23:53 補充
2. 資訊系統外購+報表自行開發
這類型公司同上述類型的公司, 但是他們更注重資訊的分析與運用, 所以他們會聘雇IT人員自行開發管理用途的報表程式, 或引進BI軟件提供給資訊分析單位使用。
3. 系統底層外購+自行開發
這類型公司認為該公司的行業特殊性很高, 從外部找不到適合的軟件, 所以自外購入系統開發底層架構的東西, 然後自行量身訂做企業核心競爭力流程。
因為公司上述不同策略, 就會引進不同專長的人員,
於 2010-02-06 19:24:13 補充
如上第1類型的公司, 需要的不是技術人員, 而是專案管理人員, 通常會計部門主管或管理部門主管最適合擔任這個角色。
而第2類型的公司, 也僅僅需要會寫報表程式的技術人員即可。
而第3類則需要完整資訊公司各類型的技術人員。
而你所提到的企業內自行客製化,
我強烈強烈建議你,
不要幹這種事,
如此蠻幹只是滿足你寫程式的欲望,
卻造成你公司系統成為孤兒,
公司日後會付出很高很高的代價。
?? 真是有病 !!
難怪 鴻海改了鼎新系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
難怪 鴻海改了 SAP 系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
>> 公司日後會付出很高很高的代價 !!
就是原廠無法要你簽維護合約
就是你不想跟原廠簽維護合約
無法簽合約是很難過的事
就像結婚後離婚後又同居
沒有合約真恐怖
標籤：soa mda erp 資訊義工
* [點數] 點數(20)
* [回答] 回答(0)
* [討論] 討論(0)
* [取消追蹤] 取消追蹤(1)
* 收藏(0)
* 贊助
* 轉寄
* 檢舉
JANUS ERP java MDA 畫面 接太多了. 有人可以幫忙做嗎！！
畫面包括 :: 輸入/更改/取消/查詢/拋轉/驗證
一個畫面基本價格 NTD 100元 ＋
一個欄位 NTD 10 元 +
一個欄位動態驗證 NTD 10元 +
一個欄位動態內定值 NTD 10元
這是我接的價格!! 有人要幫忙麻 !!
限國中以上畢業(彰化國中/陽明國中/彰安國中/精誠中學/彰中/彰女畢業生最好)
有 1000 個畫面經驗 ( Avg 30 fields/ 30 Callout / 30 Validation Rule)
可到大學研究所擔任 ADempiere ERP 專題實務顧問(國中畢業可)
要幫忙的可以免費幫你教到會
(限彰化人或在彰化縣讀國小/國中/高中者)
於 2010-01-30 21:42:16 補充
1. 資訊系統外購:
這類公司認為資訊系統的開發不是該公司的核心業務, 公司應當集中資源於企業的核心工作上, 比如研發、生產、或銷售上面。而把資訊系統交給專業的軟件公司購買、維護。以達到最有效益的資源分配與運用。
於 2010-02-06 19:23:53 補充
2. 資訊系統外購+報表自行開發
這類型公司同上述類型的公司, 但是他們更注重資訊的分析與運用, 所以他們會聘雇IT人員自行開發管理用途的報表程式, 或引進BI軟件提供給資訊分析單位使用。
3. 系統底層外購+自行開發
這類型公司認為該公司的行業特殊性很高, 從外部找不到適合的軟件, 所以自外購入系統開發底層架構的東西, 然後自行量身訂做企業核心競爭力流程。
因為公司上述不同策略, 就會引進不同專長的人員,
於 2010-02-06 19:24:13 補充
如上第1類型的公司, 需要的不是技術人員, 而是專案管理人員, 通常會計部門主管或管理部門主管最適合擔任這個角色。
而第2類型的公司, 也僅僅需要會寫報表程式的技術人員即可。
而第3類則需要完整資訊公司各類型的技術人員。
而你所提到的企業內自行客製化,
我強烈強烈建議你,
不要幹這種事,
如此蠻幹只是滿足你寫程式的欲望,
卻造成你公司系統成為孤兒,
公司日後會付出很高很高的代價。
?? 真是有病 !!
難怪 鴻海改了鼎新系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
難怪 鴻海改了 SAP 系統後 就成為孤兒!!
因此只好一不作二不休,完全更改成自己的系統
>> 公司日後會付出很高很高的代價 !!
就是原廠無法要你簽維護合約
就是你不想跟原廠簽維護合約
無法簽合約是很難過的事
就像結婚後離婚後又同居
沒有合約真恐怖
訂閱：
意見 (Atom)
