一個資料導向的小型專案的流程和難易度是不是就只是這樣?

database devops developement 需求分析

something 2018-10-27 21:27:16 ‧ 1528 瀏覽

分享至

若全球銷貨系統內有個運輸費用的價目表。該表過去僅用縣市做為運輸費用的區別，而未來將以郵遞區號做為區別，此運輸費用計算的變更流程和簡易度是不是就只有如下呢?

商業分析 (5星 - 很難) - 尤其在跨國事業來說，怎麼讓每個國家的使用者同意使用統一的價目表格式是需要耐心溝通與協調的。
資料取得 (3星 - 不簡單) - 以運輸費用來說還算簡單，總是有參考的依據。假若今天是極為國家間個別性的政策設定，那就可能還要將合約或章程轉換為應輸入之數據，這是極為耗時的。(我認為這也是AI的導入點，尤其當政策反映在交易資料中，而機器又可以在交易資料中學習到政策的轉變。不知這個觀點大家是否也認同?)
開發 (3星 - 不簡單) - 銷售表加一個郵遞區號欄位、價目表家郵遞區號欄位、更改運輸費用計算邏輯，最怕就是上下游的dependency被破壞。
有感公告與無感上線 (5星 - 很難) - 發布一個群組信件就好，還是得開會佈達。做好完整的上線準備需要大量的規劃與準備，Misoperation後的拯救在在是難關。

stephen3342 iT邦新手 2 級 ‧ 2018-10-29 10:03:04 檢舉

郵遞區號 : 台灣的郵遞區號還是全球的郵遞區號
全球銷貨系統 : 出貨地是全球各地還是只由台灣出貨?
商業模式: 是 B2B 還是 B2C ...?
上下游 : 是賣原料還是賣成品給分銷點
每個國家的使用者同意使用統一的價目表 : 各國使用者使用同一系統, 這些使用者是分屬不同公司的人? 還是同一公司的人? 如是同一公司, 公司要調整運費計算方式, 使用者有什麼立場反對?
極為國家間個別性的政策設定，那就可能還要將合約或章程 : 看起來像是多國貿易, 很難理解運費為何可以用郵遞區號? 海運/空運/快遞/陸運都可能會隨淡旺季調整運費, 還是這只是為了預估一個參考運費?
3.開發 (3星 - 不簡單) -銷售表加一個郵遞區號欄位、價目表家郵遞區號欄位、更改運輸費用計算邏輯，最怕就是上下游的dependency被破壞: 這行看起來又像是商品放經銷商

登入發表討論