来源：白话聊IT
现在，老生但是不常谈：选型信息化系统的核心考量点，我认为是2分软件、3分实施、3分开发、1分运维、1分……感觉。
首要重点“从原则性立场划圈”，是军工就别看saas，要信创就别看外资； 第二重点“先看5年内、再看切合实际的5年后”，不要好高骛远一口吃个集团化，也不要谨慎闭塞忽略规划内的组织扩充战略； 第三重点“用行业化特色需求验证软件产品的门当户对”，不要问成本还原怎么做、排产计划怎么落，这些都是甲方敢问、乙方就敢答的，同时也避免IT部门过度技术化的选型； 该表态的要表态，这个现象尤其在央国企站队现象突出，不敢担责任、然后按照评分表一堆人打分，打完分还得推给“上面”，结果“上面”都不知道前期的所有……
其实，“同业案例”没用，起码我是这么认为的。做过案例的那些人才是最重要的。企业再大同、也有小异，如何应对小异才是考验项目组的，否则，不是一个项目组的人、拿着同业案例的蓝图去搬家，项目灵魂就变成了影子； 首要重点，项目经理！注意是现场干活的那个领头人！我的标杆项目都有这个共同点，靠谱的项目经理。为人靠谱比简历靠谱强多了，假如一个说话办事都靠谱的人但ta不具备某平台实施经验，与一个具备平台经验但办事没着落的人比较，我宁愿选择前者；（靠谱是什么，百度一下就有答案） 第二重点，如果一个项目涉及2个以上的子项目，一定考察这个团队的习惯性表达（“这部分是我们另一个部门……”），分居一样的子项目沟通关系，还不如选型的时候找两家； 第三重点，稳定性。项目经理天天被拉去做售前，主力实施顾问换了一个又一个，最初调研的细节就是100%落实在报告上，也不如亲耳听到的全面。换一个主力，你会发现一伐不如一伐。
很多甲方选型都容易忽略开发集成能力的考量，然而这部分是很多项目“按下葫芦浮起瓢”的关键。位居后宫的妃子，听前线人员报道战况之后绣出的花、多么栩栩如生也是高仿版； 这一点和交付不太一样的是，研发总监+研发经理+研发顾问的能力都要看，如果说交付是网状关联“看核心”、那开发更像是点状关联“看散点”，很多时候一个问题的解决办法，问一下技术大拿（无论前后场），一个点睛的办法能节省前场开发的无限倍努力，还可以规避未来很多运维麻烦； 如果从产品能力看开发，这一点，别抱太大希望。大多数开发还是习惯后场，不具备业务思维的开发、做不出来人性化可被验证的产品。
成功上线≠上线成功。前者是一阵子，后者是一辈子。影响实施成果延续的，通常都是实施撤场之后的运维固化，就是任正非说的“先僵化、后优化、再固化”； 运维机制的健全性。有些厂商“实施即运维”，有些厂商缺乏体系、运维问题多了就是谁家着急、谁家会催、就优先排期，靠人不靠体系的运维，对运控的要求极高。
这个不是玄学，往往说不清楚的不良感觉、无法闭环的质疑验证、氛围欠佳的沟通交流，甚至是让理性的选型都添加了对星座、属相的考量……很多时候不用怀疑，大多是乙方隐藏了你想揭穿的真相，以及短期的不良感觉只会在长期的交付中变本加厉。
文章版权归原作者所有,如有侵权请联系删除。
免责声明：本文系网络转载，版权归原作者所有。本文内容为原作者观点，并不代表本公众号赞同其观点和对其真实性负责。
【2024百千工程】免费咨询，免费培训
只要五分钟填写下方申请表，就能让我们之间的信息孤岛连上光纤：
