Re: [請益] 公司自行開發資訊管理軟體但需求不明確

[esla (無限解、解無限)]

※ 引述《oherman (qq)》之銘言：
: 企業發展到一定規模時，傳統的紙本或excel管理已經不敷使用，此時就必須建置有
: 系統化的資訊管理系統，但市場上買的聯宏資通的工程管理軟體導入出很多問題
: （1）流程面和公司差距大，很多要客制
: （2）客制費用高，主管不想花這些錢
: 所以找我進來寫一套工程管理軟體
: 但是問題是：主管是管理、工程出身，對資訊完全不懂，所以無法開出需求
個人覺得啦，聽到這裡為止，應該可以歸納出幾個重點
1.紙本、excel不敷使用?
  這已經是需求了啊，是那裡不敷使用?希望改成怎樣會比較好用?
2.已經買了一套，但需要客制
  這還是需求啊，都有一套系統參考了，只是流程不符合
  那換個角度想，只要改善掉這套系統需要客制的部份就ok了?
3.主管對資訊不懂，不會開需求?
  呃，對資訊不懂跟開需求無關吧，管理出身的人不會搞流程有點無言
  這個所謂的流程某種層面來看，就是一種需求了啊
  舉例來說，業務報價出去之前，要先把紙本單給主管簽核
  然後寄給客戶確認回傳，回傳無誤後，訂單方可成立
  轉給採購/生管等，再依此訂單核算需求，轉而開立採購單或製令
  當然這裡講的很簡單，細節很多需要談，但這些就是需求了啊

: 所以我建議他參考市面上其他的工程管理軟體流及介面，先從小系統開發，
: 再慢慢聯結串接資料，但是他不肯，理由是目前已經有用excel做
: 零散資料管理，要就整套開發，目前只有我1個人開發。
: 這樣對我來說很苦惱，以大型系統來說，現行已經有導入cpm系統了，只是不合用
: 要客制…
: 但是高階主管很堅持不聽建議，請問我該怎麼做比較好：
: （1）慢慢磨，等主管有想法了再說
: （2）開發其他非主要需求資訊管理軟體
: （3）快逃…
老實說，我不清楚你們到底要做什麼東西，大概沒辦法給很實際的意見
但其實大多數的管理系統嘛，重點大概就是三個
1.降低出錯率(避免資料填寫錯誤，各模組自動互相勾稽檢查等)
2.減少人員工作量(降低重覆性工作，從機台等獲得log導入等)
3.增加資料正確度/增加可獲取的資訊
  (如從大量製令獲取實際投料量，計算出正確成本等)
當然上面說的都很基本，根據不同行業別，能玩的很多

基本上你得知道你們公司導系統的理由是什麼
然後根據這樣的理由去檢討目前公司流程有問題的部份
再跟各部門訪談，要以什麼樣的方式改善或加強
再加上前一段我說的，把舊有系統導入需客制的部份
還有了解現行公司內部流程，其實這樣大概就能有個雛型出來了
只是說真的，如果你是純寫程式的人材
這樣的工作可能對你而言有點困難
但反過來想，要是你能搞定，的確是非常非常強大的經驗就是


不過比較怕的是，上頭的想法根本不是想改善流程
只是單純覺得，啊公司規模夠了，不弄套系統來玩玩好像不夠專業
那只能說，快逃啊~~~~

最近我也是剛到新公司，負責導入新的erp系統
這算是我第四次玩導入erp了
雖然不知道你們所謂的系統是要玩什麼
不過我想前置作業應該都差不多就是，有興趣可以私信聊聊
但關於寫程式那段我就完全苦手了，這點別問我，我無能為力xdd


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.217.176.70
※ 文章網址: https://www.ptt.cc/bbs/MIS/M.1523527903.A.139.html
推 downtoearth: 如果是導系統 你描述的需求夠了 但是寫程式的話
→ downtoearth: 這樣的細節 遠遠不夠 我舉個極端的例子 要寫程式
→ downtoearth: 需要的細節可能會細到 你採購單價小數點到第幾位
嗯，同意，所以我才會說裡頭很多細節
然後如果弄的起來的話，經驗真的會起飛..
雖然可能還沒弄成功前，自已就先起飛了XDDD
不過採購單價小數點第幾位，通常是可設定參數就是
這樣的認知差異可能就是系統了解宏不宏觀的問題
多數的user很直覺的就是，我現在就是都到第2位，你就寫第2位
玩過較多系統的人就可能會考慮到要設成參數形式讓他可修改
這部份細節多到嚇死人，而且需要大量的經驗來支撐

我個人是傾向，拿已購買需客制的系統來參考
我想這樣會省事很多，不過工作量還是很龐大的~~
老實說，雖然我不熟寫程式這塊，但也知道不是一個人短期內能搞定的

站在公司角度來看，這決策問題很大，壓根就不應該只請一個人搞，失敗機會超高
站在原po角度來看，是個機會學習，那怕沒能完全搞定，也能學不少

當然如果是我，我是不會自找苦吃啦，感覺就是會被操翻
走與留，就讓原po自已考慮，小的只是提供想留下來可能可以操作的方向~~
※ 編輯: esla (114.217.176.70), 04/13/2018 11:53:20
→ konkonchou: 換個角度想，若第二段的重點123都有被實現，怎會有失
→ konkonchou: 敗率超高的問題
失敗率超高就是因為這三個重點很難達成啊XDD
尤其是一個還搞不清楚內部流程的人
舉個例子，從採購買料到最後付款，所有模組怎麼勾稽這件事
你核價完成到下採購單，單價有沒有一致，是否開放上下限讓採購修改?
下完採購單後，是否可以超交或缺交，交易條件是否能修改?
進貨完成後可否分批請款，訂金或扣款要怎麼處理，
應付是否會自動與進貨單勾稽，有扣款成本又要怎麼認列?
這一大坨東西，我玩了近十年的erp，都不見得說的完整
讓一個新手去考慮，基本上有點難，讓各單位去考慮，其實也有一定的難度
通常user只會了解各自模塊的需求，要串起來並勾稽才是最難的
降低人員工作量也是一樣道理，user告訴你我每天算考勤好辛苦
有沒有簡單一點的方式，那你怎辦，你得先了解他考勤到底怎麼算的
公式是什麼，例外是什麼，資料來源又是什麼，然後算出來後要怎麼驗証
這差不多等於是要求一個寫程式的人，去了解這套系統所有使用者在幹嘛
這段真的需要強大的經驗才有辦法一次搞定
不然就只能參考其它系統，然後try & error了...

老實說，我還是覺得一個人要完全搞定很難
但以學經驗的角度來看，我倒是覺得是不錯
※ 編輯: esla (114.217.176.70), 04/13/2018 16:22:18
推 purplvampire: 推自己先起飛XDDD
我真的覺得起飛的機會不低就是xd
→ konkonchou: 其實導ERP的本質就那三點，反過來用導系統的思維去作
→ konkonchou: 最常見的是增加工作量，資料稽核有更奇怪的問題
→ konkonchou: 光 CPFR 要弄到好一般要有錢有時間，一個人可不可以作
→ konkonchou: 可以，但就 80/20 看用到什麼程度
→ konkonchou: 每個需求存在都有背後的意義，但如何談出來一勞永逸地
→ konkonchou: 解決它才是價值所在，不然技術債永遠還不完
是啊，所以就是要想辦法去達成這三個重點
這三個重點裡頭包括太多太多東西了，怎麼談出來真的才是這份工作的精髓
像之前看過k大的文章，我就覺得k大是真神人，有辦法一個人去處理這樣的事情
但像我的能力不足，談需求可能都談不詳細了，而何況要我寫程式
這樣的工作量，真的要做的好，說真的像k大這樣神人真的不多就是..
我只能建議原po用這樣的思維去分析，畢竟聽起來原po並沒有這方面的經驗
而且聽起來苦惱的就是公司無法提出明確的需求
站在一個程設人員的角色來說，他的確不需要去了解，這段是pm的工作
但如果需要身兼pm的工作的話，就得引導user把這需求提出來，並達到這三大目的
我原文的意思就是，原po如果真的要自行引導出user需求
比起漫無目的的東問西問，還不如配合之前系統導入需客製的部份
配合user想改善的地方，再以這三大目的為主軸來進行，可能會比較有個方向就是..

※ 編輯: esla (114.217.176.70), 04/13/2018 18:47:05
→ konkonchou: 成果已經出來，老闆很多事就比較聽得進去
→ konkonchou: 自己知道要導什麼 >>>> 別人希望導入什麼
現在問題就是在，負責人員根本不知道要導什麼
需求人員不知道是不清楚需求是什麼，還是不會表達
我看起來問題就是在這，老實說還滿糟的
※ 編輯: esla (221.225.211.233), 04/16/2018 12:07:03
→ konkonchou: 思考從面，解決從點，一方面可直接切入問題獲得立即
→ konkonchou: 效益，一方面建立信任去更深入瞭解問題核心，甚至多
→ konkonchou: 點時間學產業相關
→ konkonchou: 個人最怕的不是講不出問題的人，有很多是講得一嘴好
→ konkonchou: 問題，最後要作沒半點成效
→ konkonchou: 原PO的問題同上，真的不要去想再導入系統
→ konkonchou: 主管請人來寫系統，結果變成請一個人再外購一個系統
→ konkonchou: 萬一路走得不順,這主管就黑了,寫不出來只是一個人責任
→ konkonchou: 借殼客製是一條捷徑，但這後面會有不可預期技術債要還
→ konkonchou: 能短期自製系統核心...會作得出來基本上也不會PO在這
→ konkonchou: 快逃...不見得好, 皮一點就他找你免洗你找他練經驗