※ 引述《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/cn.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