※ 引述《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://webptt.com/m.aspx?n=bbs/MIS/M.1523527903.A.139.html 嗯，同意，所以我才會說裡頭很多細節 然後如果弄的起來的話，經驗真的會起飛.. 雖然可能還沒弄成功前，自已就先起飛了XDDD 不過採購單價小數點第幾位，通常是可設定參數就是 這樣的認知差異可能就是系統了解宏不宏觀的問題 多數的user很直覺的就是，我現在就是都到第2位，你就寫第2位 玩過較多系統的人就可能會考慮到要設成參數形式讓他可修改 這部份細節多到嚇死人，而且需要大量的經驗來支撐 我個人是傾向，拿已購買需客制的系統來參考 我想這樣會省事很多，不過工作量還是很龐大的~~ 老實說，雖然我不熟寫程式這塊，但也知道不是一個人短期內能搞定的 站在公司角度來看，這決策問題很大，壓根就不應該只請一個人搞，失敗機會超高 站在原po角度來看，是個機會學習，那怕沒能完全搞定，也能學不少 當然如果是我，我是不會自找苦吃啦，感覺就是會被操翻 走與留，就讓原po自已考慮，小的只是提供想留下來可能可以操作的方向~~ ※ 編輯: esla (114.217.176.70), 04/13/2018 11:53:20 失敗率超高就是因為這三個重點很難達成啊XDD 尤其是一個還搞不清楚內部流程的人 舉個例子，從採購買料到最後付款，所有模組怎麼勾稽這件事 你核價完成到下採購單，單價有沒有一致，是否開放上下限讓採購修改? 下完採購單後，是否可以超交或缺交，交易條件是否能修改? 進貨完成後可否分批請款，訂金或扣款要怎麼處理， 應付是否會自動與進貨單勾稽，有扣款成本又要怎麼認列? 這一大坨東西，我玩了近十年的erp，都不見得說的完整 讓一個新手去考慮，基本上有點難，讓各單位去考慮，其實也有一定的難度 通常user只會了解各自模塊的需求，要串起來並勾稽才是最難的 降低人員工作量也是一樣道理，user告訴你我每天算考勤好辛苦 有沒有簡單一點的方式，那你怎辦，你得先了解他考勤到底怎麼算的 公式是什麼，例外是什麼，資料來源又是什麼，然後算出來後要怎麼驗証 這差不多等於是要求一個寫程式的人，去了解這套系統所有使用者在幹嘛 這段真的需要強大的經驗才有辦法一次搞定 不然就只能參考其它系統，然後try & error了... 老實說，我還是覺得一個人要完全搞定很難 但以學經驗的角度來看，我倒是覺得是不錯 ※ 編輯: esla (114.217.176.70), 04/13/2018 16:22:18 我真的覺得起飛的機會不低就是xd 是啊，所以就是要想辦法去達成這三個重點 這三個重點裡頭包括太多太多東西了，怎麼談出來真的才是這份工作的精髓 像之前看過k大的文章，我就覺得k大是真神人，有辦法一個人去處理這樣的事情 但像我的能力不足，談需求可能都談不詳細了，而何況要我寫程式 這樣的工作量，真的要做的好，說真的像k大這樣神人真的不多就是.. 我只能建議原po用這樣的思維去分析，畢竟聽起來原po並沒有這方面的經驗 而且聽起來苦惱的就是公司無法提出明確的需求 站在一個程設人員的角色來說，他的確不需要去了解，這段是pm的工作 但如果需要身兼pm的工作的話，就得引導user把這需求提出來，並達到這三大目的 我原文的意思就是，原po如果真的要自行引導出user需求 比起漫無目的的東問西問，還不如配合之前系統導入需客製的部份 配合user想改善的地方，再以這三大目的為主軸來進行，可能會比較有個方向就是.. ※ 編輯: esla (114.217.176.70), 04/13/2018 18:47:05 現在問題就是在，負責人員根本不知道要導什麼 需求人員不知道是不清楚需求是什麼，還是不會表達 我看起來問題就是在這，老實說還滿糟的 ※ 編輯: esla (221.225.211.233), 04/16/2018 12:07:03