我最近遇到一个系统，这是一个比较基础的系统，如果是高度定制的业务系统，一般不会存在这个问题。

问题是，这个系统原先是v1.0，后面升级到v2.0，我们用了2年才发现，v2.0比v1.0多了十几个模块，我们居然都没用。

为了补充原先v1.0的一些功能缺陷，我们在外围做了一些开发，实际上v2.0都已经有了。

当然，在意识到这个问题后，双方一起对齐梳理了没在使用的模块，问题很快就解决了。有些开始用了，有些就是没用。

为什么一直没有发现这个问题？我们就开始反思。信息化推进进度的影响因素中，一定不是单方面的原因，甲方乙方都是有责任的。

AI的回答

一个产品有大升级，他一定是解决了很多旧版本的痛点的，但是我们为什么一直还在用v1.0的思维使用着v2.0的系统？我请AI帮忙回答这个问题。

我的Prompt：你是一个信息化专家，你负责某个公司的信息化推进工作。你原先在负责运维某个业务系统的旧版本，后期这个业务系统进行升级到了新版本，但是过了很长时间你才发现你们还在用旧版本的思维在使用新版本，新版本的很多功能都没有启用，这是为什么？请从你作为用户和提供这个业务系统的厂商等角度进行一步步分析。你认为未来应当如何避免？

AI的回答：

作为信息化专家和负责运维业务系统的人员，发现公司仍在使用旧版本的思维来操作新版本的系统是一个常见的情况。这可能涉及到以下几个方面的因素：

  1. 缺乏培训和教育：在系统升级后，如果没有进行足够的培训和教育，员工可能会继续使用他们熟悉的旧版本操作方法。他们可能不清楚新版本的功能和优势，也不知道如何最好地利用这些功能来提高工作效率。升级到新版本可能需要用户重新学习系统的操作方法和功能。如果这需要投入大量的时间和精力，用户可能会选择继续使用他们熟悉的旧版本，而不愿意花费额外的精力去适应新版本。

  2. 文化和组织惯性：企业文化和组织惯性可能会导致员工更倾向于坚持现有的工作方式，而不愿意接受新的变化。如果公司的文化不支持创新和变革，员工可能会更难接受新版本系统的改变。人们往往会习惯于某种方式的操作或使用，即使新版本提供了更好的功能和体验，他们也可能会坚持使用旧版本的方式。这种惯性可能需要一段时间才能被打破。

  3. 信息不对称：提供业务系统的厂商可能没有充分地向用户传达新版本的改进和优势，或者没有提供足够的支持和培训来帮助用户顺利过渡到新版本，或者用户没有花时间去了解新版本的特性。这可能会导致用户对新版本系统的认知不足，以及对新功能的了解不够。

  4. 缺乏动力和激励：员工可能缺乏足够的动力和激励来学习和利用新版本系统的功能。如果他们觉得旧版本的工作方式已经能够满足需求，或者他们没有意识到新版本系统可以带来的好处，他们可能会选择继续使用旧版本的操作方法。

解决这些问题可能需要采取以下措施：

  • 提供全面的培训和教育，帮助员工了解新版本系统的功能和优势，并学习如何最有效地利用这些功能。
  • 建立积极的变革文化，鼓励员工接受新的工作方式和技术，以及与之相关的培训和学习机会。
  • 与厂商密切合作，确保他们提供充分的支持和培训，以帮助用户顺利过渡到新版本系统。
  • 设立激励机制，鼓励员工积极参与到新版本系统的学习和应用中，并充分认识到新系统带来的好处和提升。

通过这些措施，可以帮助公司更好地推进新版本系统的使用和应用，提高员工的工作效率和企业的信息化水平。

回答得非常好，我再提供一些新的思路。

这确实是一个常见的情况

Change is a constant。

年初我在准备将连接了北通手柄的戴尔笔记本接到我的Sony电视机的时候，我翻箱倒柜到处找HDMI线，终于在一个角落里找到一个全新未拆封的HDMI包装盒，然而当我看了一眼盒子，我立刻就把他原封扔了。

这根HDMI线大品牌，线径很粗，接头镀金，有多个屏蔽层，但是他的协议支持是1.4的。1.4协议是2009年出现的，现在最新版都已经是2.1了。

物理外观你看不到任何变化，但是其实软件上协议上早已经升级迭代很多个版本了。

为什么我推荐手机每年都要换新，很多时候你感觉你平时就用下微信，打打电话，好像不换也没关系。实际上不是的。有很多底层的焕新你是肉眼看不到的，更重要的还有安全，它没有功能上的更新，不会让你体验升级，但是在抵抗攻击方面默默在守护你。

我们在用的开源软件Ubuntu、Zabbix、Gophish等，我经常就要去看下版本升级的changelog，生怕有什么新功能没有使用到。

老的经验和思维有时候无伤大雅，有时候会带来大问题。比如RAID5，在我们以前的印象里，RAID5平衡了容量、速度和数据冗余多个因素，是我们首选的磁盘阵列选择。但是在单个硬盘容量不断变大后，RAID5已经不再适用。

因为在大硬盘模式下，在你RAID5发生故障时，重建时间增加，而且在重建期间，由于会大量执行读取操作，如果这个期间再次出现另外一次磁盘故障，数据就会丢失。而且bit rot风险也会增加。

信息领域跟科学、时尚界一样，它会不停地否定自己，用新的东西来替代旧的，但是他也有周期性，可能过段时间，又会使用到旧的某些经典的模式。

比如对于数据库自增ID的选择，以往我们都推荐使用数据库自带的自增ID，不要自己去实现跟数据库自身无关的任何的自增算法。但是在现在分布式环境下，我发现越来越多应用使用UUID作为ID了。以往UUID无法排序、不可读的缺点都得到了修正，UUID自身也有5个版本，从基于时间、命名空间、时间戳优先等等都有。

能怎么解决

从甲方层面，AI都说够了。

从乙方层面，厂商可以有什么作为？

一般的厂商，在持续运维一个产品时，通常会有巡检，很多巡检只是看看CPU内存，巡了等于没有巡。

也会有大小版本升级，可能升级停机几个小时，就完成了，怎么用就不管了。

收集用户的习惯

其实我们在用的所有软件，都会在收集用户的使用习惯，并最终为新功能的开发排期和改进提供公司内部的建议，但是很多都不会向用户开放。

软件开发出来后，就脱离产品经理的控制了，用户什么花样都会玩出来，很多产品经理到用户现场调研时，有时候会发现用户独辟蹊径，就是不按他们的想法使用软件。这是允许的，有些药的副作用后面就被开发成另外一种药出来。

当然，如果这个用户高级一点，可能就会挖出一些安全问题出来。Never Trust User Input，搜索和网站内容的Injection

互联网上还有专门一些教别人怎么“不按出厂设置使用物品”的，把一些原先设计在工业用途的东西拿来家用，比如买个病房的床头柜放家里，把矿渣拿来当NAS，解锁不一样的技能。

不要依赖产品经理的现场调研，通过收集用户的使用习惯，给出问题或者其他最佳实践建议，不要出现80%的用户只使用了20%的功能。

举个网站群的例子

比如网站群来说，一般网站群都会提供一个能力，如果你要在不同网站发送相同内容的文章，他会有个“投递”的功能，就是不需要你在每个网站都发同样的内容，而是发一次，投递到各个网站，并且在投递时可以选择是断开连接还是持续保持内容更新。

有些用户不知道，还是会每个站点去重复发送，最后还要怪你好麻烦。

如果有后端分析，可以发现多篇内容相同的文章，回溯发布的路径，再剔除是其他人转载的数据，最后就可以分析出来，某个人，可能不知道有“投递”的这个功能。

这时候，就可以弹出，告诉用户，我发现你是这么用的，其实我们有这个功能，或者现在我们有这个新功能替代了，但是我发现你都没用，是因为不喜欢吗？

当然，大家都怕数据被提交给远程。

数据被提交到远程的问题

在应对软件供应链风险时，面对版本不一致，公司不掌握各个部署环境情况，我曾经提了个建议，语义化版本，每次更新发布版本，建立用户部署版本数据库等。

但是，这样也会有一些风险。

我有一个朋友，他有天跟我聊起。某B2B公司，有天过来给他介绍PPT，里面统计了他公司使用该2B公司的数据，并且希望跟公司做深度合作。当然，愿景非常好，通过分析，发现你们公司底下人已经用脚投票在零星使用我们产品了，如果能合作，这些人成本可以下降，通过推广，让更多的人可以用到更好的服务，2B公司收益也会更高，双赢。

刚看到数据他是震惊，一个是被分析结果震惊了，一个是，PPT里甚至有Top使用者姓名和使用场景。

他都能想到在2B公司早会，销售们分到一个个PPT，是Top几使用率的客户，领导要求一个个拿下。但是他不知道到底有多少人可以掌握到这些明细或者汇总数据？是研发？公司高管？还是销售经理还是普通的销售人员？他也不知道这些销售离职后这些文件会在哪里。

我笑他想得太黑暗了。但是仔细再一想想，确实是，现在大家平台用得越来越多，这些平台掌握的数据，会以各种脑洞，被挖掘出有价值的信息出来，侧信道攻击的例子实在太多了。

这个2B公司分析得非常好。而我们私有化部署的系统，能否在我们本地分析？能否控制知悉范围？在用户建设和维保费用全部交完后也可以持续分析？

结论

信息化系统，除了实现需求，安全外，可以再加入对本身系统使用分析的功能。

因为数据库数据都在，如果研发发现新加了几个表，但是这些表内数据都是空的，这就有问题了。

或者通过辛苦埋点收集使用数据再给出结论。

而且要，后顾一下那些长期使用，各个版本一步步爬梯升级上来从思想和习惯都僵化的老客户，而不是新购用户。​