推 ai8051: 沒辦法,你把系統流程表現的太簡單太明確,反而看起來不夠 10/21 12:59
→ ai8051: 厲害,沒經驗的常幹這種事,明明就不適合的單據或功能應要套 10/21 13:01
→ ai8051: 只因為顧問認為這樣才符合標準,理解顧問有他的立場,但身為 10/21 13:03
→ ai8051: 公司導入人員卻隨之起舞就死了,到最後成本一樣滾不起來 10/21 13:05
→ ai8051: 連倉管都帳料不符,他們最後都只看自製的EXCEL表 10/21 13:08
這一段心有戚戚焉，當時請一堆人來做整頓多年爛帳
結果庫存加權平均移動平均怎麼管理這些人討論得很開心，最後沒一個做出來
財會還給錯帳(自製 Excel, 期初期末都異常)
東西數量都不對了有甚麼好平均的
正本清源其實就是當下進出做好，有問題慢慢回追(要下苦功)
最後乾脆自己撩下去做系統管理，進出庫存帳當年度被抽盤就100%正確
→ ai8051: 這當中的問題除了一開始說的,導入人員前置作業跟流程外 10/21 13:09
→ ai8051: 中間到後續MIS人員的支援蠻重要的,我先前就是遇到一堆直接 10/21 13:09
→ ai8051: 人員不會打單,也覺得麻煩問不到人就擺爛,最後是我留分機 10/21 13:10
→ ai8051: 從辦公室到現場都直接找我,才一個個解決,問題不一定都很大 10/21 13:11
→ ai8051: 只是多餘的作業流程卡住,但原先的主管堅持(還是我去跟顧問 10/21 13:12
→ ai8051: 問清楚做與不做的差異才簡化掉)最後才有運作,但花很多時間 10/21 13:13
→ ai8051: 就是,很多中小企業都這樣,自以為的主管,跟沒空理人的MIS 10/21 13:14
→ ai8051: 要理下去,從銷售金額到製造,庫存對帳，我就是覺得被操翻了 10/21 13:16
各功能一定要訓練種子學員出來
當下多花工、日後很輕鬆
系統操作流暢度其實就是影響日後這些作業複雜度，所以才要仔細評估系統
ERP / 系統明明是要來解決問題的，但很多最後都只是 E 化把資料顯示在螢幕上
問題還是一直都在，最後隨便找個資訊人員負責任
推 esla: 編碼有可讀性是好事，但要分類再加流水碼吧 10/23 11:03
→ esla: 連自動編碼都沒有，全手動編出錯的機會更高吧 10/23 11:03
→ esla: 人為編碼，一編錯不就失去編碼可讀性的意義了 10/23 11:04
分類+流水號大多系統基本款
原本舊系統也是一碼數字 + 一碼英文字分類 + 可辨識資訊 + 流水號
所以光分類就起碼有260種組合分類，硬要變成可讀
光兩碼就變成十碼不夠 再蠢蠢地把color size breakdown 放進去料號就爆表了
不是第一次看到會這樣編碼的邏輯，累的都是前端作業的人
換言之，客人每下一次單，幾乎都得建一次料號
→ esla: 限定倉儲批跟智能化倉儲管理的關係在那? 10/23 11:05
智慧化倉儲簡單就是系統告訴操作人員，東西該擺哪比較適合未來取出
譬如 以出庫效率為主 (未來省時)
還是 以入庫效率為主 (當下省時)
或是 集貨作業讓倉儲最大化運用 (省倉儲空間)
可以想成同樣是入/出庫，如何用最少時間跟人力完成
東西找不到進而限制東西只能擺在哪，算沒經驗又沒常識吧
推 esla: 個人覺得導ERP就2個目的1.降低工作量2.增加資料正確/可讀性 10/23 11:16
→ esla: 有時二個目的可能會互相衝突，這點就要看公司的判斷了 10/23 11:16
→ esla: 最蠢的是二個目的都達不到，加了一堆流程，資料還是錯的 10/23 11:17
這兩個目的都要達到，就是第三方人力(外援)要介入了
最簡單的
很多系統轉換不包含資料部份，也許寫個sql script測試完資料就拋過去了
但系統商不幫忙移轉 ($$$ + 風險)
就會要人工打單，系統用越深就越慘，打完單系統最後沒上線的大有人在
推 esla: 沒啦，轉換時期很難不增加工作量的，我是指上線之後的目的 10/24 12:00
→ esla: 那怕直接從db導，也是得花不少時間整理資料的 10/24 12:00
→ esla: 我這個月都在搞這個，光料號、bom跟製程就夠讓人頭痛了 10/24 12:01
TIPTOP 拿出資料的確是比較麻煩, 尤其是有被客製過的
有時看到資料在第10個欄位
後來才發現255也有一樣的資料才是對的，就變成一定要從頭看到尾
→ esla: 新的t100轉移資料相對人性化很多了，甚至不用從db導 10/25 09:37
→ esla: 只是還是得花很多時間去整理，尤其是bom架構有變動的情況下 10/25 09:37
TIPTOP 這五年我也沒接觸到這類要捨棄 轉新ERP的客戶
會寫 script 一方面也是要配合目的地資料庫，方便調整
另一角度 有相同客戶的話也是有機會省下轉資料時間
推 minami74: 感覺用流水號之後，當產品種類越來越多，總有一天會被 10/28 14:20
→ minami74: 檢討 10/28 14:20
所以不要為料號而料號
流水號只是一個數字, bigint 總夠用了
如何 快速 正確 取得想要的料 對應的系統設計才是重點
※ 編輯: konkonchou (220.137.46.214), 11/10/2018 00:46:12