同類事項會扎堆，最近遇到很多不切實際的項目需求，形形色色。還是要聊一下，否則無法解決“爛尾”的根本問題。奇葩需求一：10萬的ERP系統重新實施項目（軟件不變），總經理要求，項目組成員必須是博士學位，最差也要碩士。
1、成本角度：博士的人天成本和一般顧問的差別可想而知，既要性價比、又要高能力，不現實；2、經驗角度：博士的智商和學歷都雙高，卻不等同于甲方行業經驗和乙方交付經驗豐富，容易陷入理想的本本主義；3、定位角度：如果博士學位的人愿意從一線交付做起，那可能是兩極分化了，要么真找不到工作了（某方面確實差）、要么是代表高層指指點點。當然我們并不是偏激否定甲方的立場，確實很多甲方認為管理提升不是什么能力的人都能做好的，那什么是合適的人，在不熟悉的情況下，衡量標準可能就是一些標簽。只是，對于數字化項目而言，適合>高光。奇葩需求二：用低代碼平臺構建PLM、ERP、MES、等等一籮筐。
1、平臺角度：現在是個公司都能搞低代碼，但低代碼平臺的能力多數從某個細分領域的專長項做起，真能發展成兼顧研發技術場景的PLM、適合業財一體化的ERP、適合現場執行和IOT的MES的平臺，對產品經理和開發經理要求極高，不是一個月兩個月能成熟的；2、時間成本：大多數的成熟套裝系統都可以滿足90%以上的業務需求，異構系統之間的集成也越來越成熟。這些成熟平臺也是通過了成千上萬的最佳實踐迭代的。指望低代碼平臺從頭搭建、貌似是“一體化、去孤島、少集成”了，實際上是用時間成本去驗證可行性；3、交付能力：這是我不相信那些“啥都行”的公司宣傳的關鍵點！任何數字化項目成功的核心要素都是交付和研發，平臺只占三分。有多少乙方能批量招聘到“啥都會啥都懂”的項目團隊、去覆蓋市場上形形色色的業務類型和需求？重申一下，我們不是否定低代碼和零代碼的技術趨勢，畢竟它確實減少了很多信息部的開發工作量、常態化的需求迭代、以及輕量級的應用構建，從而也減少了甲方的很多建設成本和運維成本。只是，解決不了平臺研發的多適應能力源頭、以及平臺交付的多適應能力過程，那就做不到“啥都行”！
奇葩需求三：乙方更專業，希望乙方把活兒都干了，盡量不讓業務部門參與，業務部門不靠譜。
1、需求角度：誰用系統誰發言，乙方的項目經驗再貼近甲方行業、也會存在各家細節需求上的不一致，從而導致藍圖方案的設計也不一致、不萬能；
2、配置角度：數據、流程、科目等的配置，業務部門不參與，怎么可能做出來適配甲方業務的系統？總不希望花了大把錢、就買了一套產品吧？
3、應用角度：很多甲方認為操作手冊的書寫應該是乙方做的，乙方不做就是偷懶！實際真不是！操作手冊就像學生熟悉課本的知識點一樣，自己不做一遍試題，是不可能清楚公式里的彎彎繞繞還有應用場景的。寫在最后：
周五了，輕松點。用戶后臺留言給了一些價值性課題研究，六日研究完了寫一下分享給大家。做數字化行業時間久了，尤其接觸了各類角色的信任和寄托，良心成分大于利益成分。很多時候面對甲方的一些奇怪的需求，乙方很清楚：說出來實話很可能挑戰了甲方的固有認知、逆了鱗、項目也就可能首先被pass；但如果順著甲方的無稽思路去設計，最后項目必然爛尾！但是，管理改善，其實首先改善的不就是一把手、選型人的意識嘛？否則為什么說數字化轉型90%以上都是吹牛的？因為人的秉性認知很難改！同時呼吁廣大甲方：腳踏實地提需求、藥方交給專業的人去開具。閱讀原文：https://mp.weixin.qq.com/s/M5xpbyI-qQPQ3y50wXK8uw點晴模切ERP更多信息：http://moqie.clicksun.cn，聯系電話：4001861886
該文章在 2024/12/13 9:02:11 編輯過
400 186 1886
