當客戶說『我們和微軟關係超好』時,其實是在掩飾什麼問題?
「我們和微軟的合作關係一直很好。」這句話在導入Microsoft Dynamics 365 Finance and Operations(簡稱D365FO)當主力ERP的企業裡,聽到的次數恐怕得累積到七十多次都不止。有時候這種說法就像某些人在聚會上輕描淡寫地說「只是朋友」一樣,不知怎麼地,過不了多久總會冒出點什麼小插曲。這類正面表態背後,其實常常藏著一種無奈——好像每隔一段時間就會出現效能卡住、臨時想辦法繞過去的小技巧,還有那種對平庸狀況默默忍耐的氛圍,有時讓人覺得連最有耐性的同事也開始懷疑人生選擇。
其實只要接觸過不少家用D365FO的企業,就能發現那種很會講「我們和微軟關係不錯」話術的團隊,性格或組織氛圍上往往有幾個相似地方。哪怕不是全部,也至少佔了將近一半。例如,負責管控D365FO的人,大多是主管或中階經理,通常不是技術底子出身,而且在公司內部遇到事情要挑戰微軟這個大供應商時,好像也比較謹慎保守;這種現象不見得是壞事,但在推動複雜專案碰到困難時,有時候反而容易讓進度卡住。
記憶裡偶爾還會聯想到,有些情境下大家對問題選擇睜一隻眼閉一隻眼,就是因為覺得「大廠一定有道理」,或者單純沒意願去深究細節。不過話說回來,每家公司情況不同,只是從外部觀察來看,那些常掛在嘴邊誇獎合作無間的團隊,好像真的蠻容易掉進某種類型的舒適圈,而這可能只是冰山一角。
其實只要接觸過不少家用D365FO的企業,就能發現那種很會講「我們和微軟關係不錯」話術的團隊,性格或組織氛圍上往往有幾個相似地方。哪怕不是全部,也至少佔了將近一半。例如,負責管控D365FO的人,大多是主管或中階經理,通常不是技術底子出身,而且在公司內部遇到事情要挑戰微軟這個大供應商時,好像也比較謹慎保守;這種現象不見得是壞事,但在推動複雜專案碰到困難時,有時候反而容易讓進度卡住。
記憶裡偶爾還會聯想到,有些情境下大家對問題選擇睜一隻眼閉一隻眼,就是因為覺得「大廠一定有道理」,或者單純沒意願去深究細節。不過話說回來,每家公司情況不同,只是從外部觀察來看,那些常掛在嘴邊誇獎合作無間的團隊,好像真的蠻容易掉進某種類型的舒適圈,而這可能只是冰山一角。
那些不敢對微軟說不的經理人,正在用妥協換取系統災難
有時候,當微軟那邊某個設計決策或是「最佳實踐」落到現場,好像濕毛巾一樣壓住整個運作空間,其實也不是什麼太新鮮的事情。奇怪的是,不少管理者看見這種情況,大多數都只是點點頭,期待下次升級會自動解決——但大家應該都知道,這種事通常不太會發生。這種「聽天由命」的反應,好像不只是個人風格問題,更像是某種系統性的現象。有些人或許沒有足夠的技術敏感度去察覺那些隱藏的漏洞,也有人就算發現了,也很少直接對微軟提出質疑。久而久之,他們組織內部慢慢陷入一種循環:臨時修補、各式客製化東拼西湊、然後只能無奈接受現狀。換句話說,有點像把一台高價跑車交給還沒學會開手排的人,結果每次換檔總是卡卡的——到底是哪裡出錯好像也說不清。
另外有個狀況,最近似乎越來越常見,就是在 D365FO 團隊人才上精打細算(或者說保守)到有點奇特。有些公司號稱和合作廠商關係很好,但卻選擇不自己留住懂行的人才,反而全部仰賴外面的系統整合顧問。這類型外包經驗其實已經流傳不少年了,有些SI公司確實願意站在客戶角度思考,可還是有不少顧問團隊,看起來更專注於讓自己更難被替換掉,把服務綁得更緊密一些。有時候聽前輩聊起來,彷彿就是這麼回事。不過具體成效怎樣,每家公司碰上的情境好像都有差異,也不是三言兩語能蓋棺論定。
另外有個狀況,最近似乎越來越常見,就是在 D365FO 團隊人才上精打細算(或者說保守)到有點奇特。有些公司號稱和合作廠商關係很好,但卻選擇不自己留住懂行的人才,反而全部仰賴外面的系統整合顧問。這類型外包經驗其實已經流傳不少年了,有些SI公司確實願意站在客戶角度思考,可還是有不少顧問團隊,看起來更專注於讓自己更難被替換掉,把服務綁得更緊密一些。有時候聽前輩聊起來,彷彿就是這麼回事。不過具體成效怎樣,每家公司碰上的情境好像都有差異,也不是三言兩語能蓋棺論定。
Comparison Table:
結論 | 具體內容 |
---|---|
雙向寫入的問題 | 資料重複存儲導致雜亂,效能下降。 |
Power Platform的限制 | 功能受限,授權費用高於預期,導致使用者困擾。 |
ERP系統選擇 | 選擇合適的ERP平台需考量企業需求與平台特性,以避免未來改造困難。 |
性能瓶頸影響 | 隨著業務增長,系統性能可能變慢,需提前規劃以減少影響。 |
自主掌控的重要性 | 企業應該發展內部技術能力,以避免過度依賴外部供應商造成風險。 |

為什麼省下內部專家的錢反而讓你掉進系統整合商的陷阱?
有時候,顧問們會拋出一些看似無關緊要的問題,好像只是為了讓自己的工時多一點,或者偶爾會把比較資淺的人當成專家來收費。修補問題的方式也常常留著尾巴,下次還能再被叫回來,彷彿某些水電師傅總是把水龍頭弄得半好不壞,好保證過幾個月又有機會上門。大概不少公司遇到這種情況時,如果缺乏內部懂行的人去監督,就容易陷入那種花出去的錢和實際收到的成果明顯對不上號的困境。其實說到底,只要企業規模大到需要用到那些等級蠻高的ERP系統,差不多就已經有理由自己養一批技術人員了——比起老是仰賴外部團隊,有自家的人才可能更能信得過。
而至於那些海外低價方案,也不是沒討論空間。有聽說不少組織為了省成本,不只把基礎工作交給海外團隊,有時候還連整體架構設計都一起外包。這樣做到底效果怎麼樣,好像各界評價分歧,有人認為短期內可以節省下不少支出,但長遠來看是不是划算,就很難說得太絕對啦。有些案例裡,離岸團隊確實能應付日常瑣事,可是一旦牽涉到全盤規劃,那種細節、默契或許就沒那麼容易達成一致。不過這類現象在業界倒也不是少見,或許反映出大家在資源調配上的不同考量吧。
而至於那些海外低價方案,也不是沒討論空間。有聽說不少組織為了省成本,不只把基礎工作交給海外團隊,有時候還連整體架構設計都一起外包。這樣做到底效果怎麼樣,好像各界評價分歧,有人認為短期內可以節省下不少支出,但長遠來看是不是划算,就很難說得太絕對啦。有些案例裡,離岸團隊確實能應付日常瑣事,可是一旦牽涉到全盤規劃,那種細節、默契或許就沒那麼容易達成一致。不過這類現象在業界倒也不是少見,或許反映出大家在資源調配上的不同考量吧。
把核心架構交給海外團隊就像讓學徒設計米其林菜單
這種情況有點像,廚房裡副主廚被叫去設計整本菜單,然後真正的主廚卻不知道為什麼閒在一旁,說不上來哪裡怪。其實,合理的工作拆分結構應該要讓全職員工把關大方向,把那些細碎又瑣事的開發流程交給遠端團隊處理。可是,一旦那個比例失衡,就可能會出現設計看起來東拼西湊、好像跟擴展性也搭不太上邊的結果。有時候內部成員——也許是某位平常主要負責會計或軟體的小夥伴——就得自己想辦法把這一切理清楚。亂象就像這樣慢慢堆起來,其實不少組織還挺習慣這種狀態。
說到 Dataverse 的問題和雙重同步帶來的困擾,如果管理沒有好好盯著,事情就會像度假回來後信箱塞爆那樣,不知不覺累積成山。有些問題原本以為只是小瑕疵,到後來經常變得難收拾。
說到 Dataverse 的問題和雙重同步帶來的困擾,如果管理沒有好好盯著,事情就會像度假回來後信箱塞爆那樣,不知不覺累積成山。有些問題原本以為只是小瑕疵,到後來經常變得難收拾。

Dataverse雙向同步如何讓你的數據倉庫變成垃圾場
像微軟那個Dataverse,還有它的雙向同步功能,有些企業會蠻倚重這種結構——資料在Dynamics CE或者Field Service跟D365FO之間來來回回地同步,好像就很方便。不過,大家常常碰到一件事,就是用著用著,存儲費用不知怎麼一下子變得貴得有點誇張。大致上,等到帳單出現的時候,公司內部才開始討論:「咦?這到底為什麼會花這麼多?」有人說是資料量大幅增加,也有聽說過某些企業光是存資料這一塊開銷就比原本預期高了數十倍。當然,每家公司狀況都不完全一樣,有人感覺負擔還好,有人就覺得壓力很大。到底值不值得?可能也只能看各自實際需求和預算分配吧。有的人甚至會懷疑,是不是哪裡設錯或是流程沒調整好,不然怎會這樣。
當Power Platform的授權陷阱比它的開發速度還快
有時候,當大家還在思考到底要不要同時把資料放進兩個系統時,就會有人提到這種做法其實有點像是網路上那些囤積症患者——明明一份東西卻得留好幾份,結果哪裡都是重複的檔案,看起來挺雜亂。然後,這套叫做「雙向寫入」的設計,好像又沒辦法做到那種讓人放心的非同步同步,所以一但操作起來,效能就容易被拖慢。有些用戶大概已經等到快打瞌睡了。
再說,有一些地方設計上也不算很理想。例如公司之間如果不能互通資料,下游那邊的資料倉儲可能就會出現將近一半以上類似資訊,但每家公司各自分家、各自有不同版本,長遠下來主數據變得七零八落,也不是沒發生過。偶爾會碰到比較懂技術的主管,他們可能會問一句,「這種雙向寫入真的適合我們這麼大的規模嗎?」然後順帶質疑一下Dataverse是不是太受限——畢竟市面上也還有其他沒那麼封閉、彈性高一些的CRM可以選。
只是這些問題通常不是常常有人提出來。有時候,那位應該負責盯細節的管理者壓根不在現場;或許他們人在,但心思早就飄去盤算自己的小勝利了,只留下一陣煙塵。
再說,有一些地方設計上也不算很理想。例如公司之間如果不能互通資料,下游那邊的資料倉儲可能就會出現將近一半以上類似資訊,但每家公司各自分家、各自有不同版本,長遠下來主數據變得七零八落,也不是沒發生過。偶爾會碰到比較懂技術的主管,他們可能會問一句,「這種雙向寫入真的適合我們這麼大的規模嗎?」然後順帶質疑一下Dataverse是不是太受限——畢竟市面上也還有其他沒那麼封閉、彈性高一些的CRM可以選。
只是這些問題通常不是常常有人提出來。有時候,那位應該負責盯細節的管理者壓根不在現場;或許他們人在,但心思早就飄去盤算自己的小勝利了,只留下一陣煙塵。

低代碼開發真的能撐起企業級應用嗎?看看這些爆掉的案例
Power Platform 最近好像很常被提起,微軟自己也挺積極推廣,讓不少企業一頭熱地往這個生態圈裡鑽。只是,有些人可能沒注意到,一開始那環境其實就像被綁了手腳,有點像被限制在某種沙盒裡,很多功能卡卡的。有聽過 PowerApps 嗎?這工具剛推出時有些人以為能省下大把開發時間,但實際上,好幾家用戶後來才發現授權費用比想像中高出不少——而且那些價格,大約在他們預期的幾倍上下浮動,不是那麼容易算清楚。
有趣的是,號稱「不用寫程式」的設計搞著搞著常變成一堆繞來繞去的流程圖,看起來簡單,其實遇到資料量稍多或要加新功能時,就容易出現各種問題。有朋友曾經描述過,他們做了一個系統,本來還行,但隨著需求增加、用戶多了之後,那些小問題就慢慢跑出來:速度明顯變慢,新功能一加就怪怪的——這情形,在不同公司好像都偶爾會見到。
性能受限,也許不是每個人都會立刻察覺,可等你真的需要它快一點時,就會感覺像買了台看起來很拉風的新車,結果開出去最快也只能勉強跟得上市區交通。外表亮麗,但要拿去參賽,好像還差點什麼。
說到底,這類狀況——不管是效能上的瓶頸、額外付出的成本、或總覺得「是不是哪裡還可以更好」——似乎都和自主掌控程度不夠有關。如果沒有辦法真正主導自己的技術路線,到底該繼續駕馭這台車呢?還是乾脆選擇別條路走,其實也不是誰說得準,每家公司考量可能都略有不同吧。
有趣的是,號稱「不用寫程式」的設計搞著搞著常變成一堆繞來繞去的流程圖,看起來簡單,其實遇到資料量稍多或要加新功能時,就容易出現各種問題。有朋友曾經描述過,他們做了一個系統,本來還行,但隨著需求增加、用戶多了之後,那些小問題就慢慢跑出來:速度明顯變慢,新功能一加就怪怪的——這情形,在不同公司好像都偶爾會見到。
性能受限,也許不是每個人都會立刻察覺,可等你真的需要它快一點時,就會感覺像買了台看起來很拉風的新車,結果開出去最快也只能勉強跟得上市區交通。外表亮麗,但要拿去參賽,好像還差點什麼。
說到底,這類狀況——不管是效能上的瓶頸、額外付出的成本、或總覺得「是不是哪裡還可以更好」——似乎都和自主掌控程度不夠有關。如果沒有辦法真正主導自己的技術路線,到底該繼續駕馭這台車呢?還是乾脆選擇別條路走,其實也不是誰說得準,每家公司考量可能都略有不同吧。
微軟D365FO是法拉利,但你的團隊真的會開手排檔嗎?
Microsoft Dynamics 365 Finance and Operations,這套系統怎麼說呢,大概可以被形容成一款功能不算單薄的平台,操作起來有些地方還蠻靈活的。有人覺得它對於那種規模大一點、流程複雜的企業來說,好像頗能發揮作用,尤其整合性還不錯,也有不少擴充空間。不過話又說回來,每個 ERP 都各有長短——SAP、Oracle 什麼的也差不多是這種情況,很難找到哪一個完全沒毛病。
但現實上,有些小問題一直都在,比如 dual-write 的那些小狀況,有時候 Power Platform 的限制也會讓人摸不著頭緒。這些細節如果處理不好,或許就會影響運作,不過感覺只要事前多花點功夫規劃,還是能把影響降到最低。有的人總期待微軟自己會幫忙補足所有缺口,但其實靠外部支援太多、自家懂行的人又太少時,出狀況機率可能就比想像中高。
突然想到以前看電影《烈火悍將》(Heat),裡面主角 Neil McCauley 說過一句話:「別讓自己對任何東西產生依戀,如果你感受到危險,就要三十秒內轉身離開。」這句話拿來放在企業選擇系統策略上,好像也不是全無道理——如果企業光靠廠商好心,自家卻沒有一點底氣,到最後反而容易陷入困境。到底該怎麼權衡自己的需求和平台本身的特性,其實每家公司都得慢慢摸索;畢竟市場上經驗談也是七零八落,不見得哪套就是萬靈丹。
所以到頭來,是不是只要把優勢放大、弱點管控住,一切就能水到渠成?可能還得再觀察吧。有時候,就連資深顧問都講不出標準答案,只能建議大家別掉以輕心,多留幾手備案比較穩妥。
但現實上,有些小問題一直都在,比如 dual-write 的那些小狀況,有時候 Power Platform 的限制也會讓人摸不著頭緒。這些細節如果處理不好,或許就會影響運作,不過感覺只要事前多花點功夫規劃,還是能把影響降到最低。有的人總期待微軟自己會幫忙補足所有缺口,但其實靠外部支援太多、自家懂行的人又太少時,出狀況機率可能就比想像中高。
突然想到以前看電影《烈火悍將》(Heat),裡面主角 Neil McCauley 說過一句話:「別讓自己對任何東西產生依戀,如果你感受到危險,就要三十秒內轉身離開。」這句話拿來放在企業選擇系統策略上,好像也不是全無道理——如果企業光靠廠商好心,自家卻沒有一點底氣,到最後反而容易陷入困境。到底該怎麼權衡自己的需求和平台本身的特性,其實每家公司都得慢慢摸索;畢竟市場上經驗談也是七零八落,不見得哪套就是萬靈丹。
所以到頭來,是不是只要把優勢放大、弱點管控住,一切就能水到渠成?可能還得再觀察吧。有時候,就連資深顧問都講不出標準答案,只能建議大家別掉以輕心,多留幾手備案比較穩妥。

從電影《烈火悍將》學到的ERP管理哲學:30秒逃命原則
尼爾·麥考利在那部差不多三十年前的電影《烈火悍將》裡有段話,大致意思是:「如果你察覺麻煩即將找上門,自己得能在不到半分鐘內放下任何牽絆。」這種帶點灰色地帶的思維,有時好像跟ERP規劃還真有幾分契合——畢竟,變通跟實際一向比較重要。說穿了,沒什麼所謂「最佳慣例」真的一定適用每個情境。很多人會對工具或流程產生依賴感,可是不太有人能確保那東西永遠吻合真正經過驗證的架構原則。
其實ERP這玩意兒,就像企業的骨架,有的人說它應該像量身打造的機器,哪怕多花點心思調校,也比直接拿現成品湊合來得穩妥。不少公司曾經因為選擇了現成解決方案,後面發現要改就很棘手。有些朋友私下聊起來,好像也遇到類似情況:局勢稍有風吹草動時,如果系統本身限制太多,要轉型往往不是說走就走。
當壓力來臨、環境變動時,若能夠針對Dynamics 365 FO之類的平台彈性調整方向,大概才比較有可能掌握一些新機會。如果綁死在某些看似「完美」卻其實未必長久稱心如意的關係上,到頭來可能只剩下想解套卻不得法子的煩惱。
最後,如果你看到這裡,其實滿感謝你的耐心。有空…可以隨便按個讚或追蹤一下作者吧——但也沒什麼非做不可啦。
其實ERP這玩意兒,就像企業的骨架,有的人說它應該像量身打造的機器,哪怕多花點心思調校,也比直接拿現成品湊合來得穩妥。不少公司曾經因為選擇了現成解決方案,後面發現要改就很棘手。有些朋友私下聊起來,好像也遇到類似情況:局勢稍有風吹草動時,如果系統本身限制太多,要轉型往往不是說走就走。
當壓力來臨、環境變動時,若能夠針對Dynamics 365 FO之類的平台彈性調整方向,大概才比較有可能掌握一些新機會。如果綁死在某些看似「完美」卻其實未必長久稱心如意的關係上,到頭來可能只剩下想解套卻不得法子的煩惱。
最後,如果你看到這裡,其實滿感謝你的耐心。有空…可以隨便按個讚或追蹤一下作者吧——但也沒什麼非做不可啦。
與其迷信『最佳實踐』,不如打造屬於你的特製化ERP戰車
有些人會習慣在社群平台上逛逛,這幾年其實也多了不少選擇。大概像是 Twitter(有人現在叫它 X)、BlueSky、Truth Social,那個 Substack 還有 LinkedIn──這幾個名字,說熟也不是人人都熟。不過,如果想要接收訊息或追蹤一點什麼,好像不少人會建議到這些地方去看看。到底是不是每個平台都有用?可能還得靠你自己試過才知道。有時候聽朋友說,他們大約在其中某兩三個比較常混,也不一定每一樣都追蹤得很勤快。至於哪裡資訊比較及時,或許有人覺得 Twitter 上消息跑得快,不過其他平台偶爾也能看到不同的討論風向。總之,如果真的有興趣,不妨隨手瀏覽一下——搞不好會發現一些先前沒注意到的新東西。
