如何记录升级商业软件的策略？

Question

我们已经有近十年没有升级RDBMS或服务器操作系统了。另一个关键任务软件包已经接近20年历史，并且在很长一段时间里一直没有得到其供应商的支持。我们管理层中的一些人似乎认为这是一件好事--我们通过不购买升级而节省了大量的钱！现在，一个关键的软件需要升级，但新版本将不支持十年前的东西。现在，我们中的一些人正在失去我们的头发，试图弄清楚如何在最短的停机时间内一次升级所有的东西。

为了避免将来发生这种情况，我们中的一些人正在考虑创建一个IT战略计划文档(它将适合于组织的strat计划，充实与IT相关的大型文档中的项目.也许这会使IT文档成为一个战术计划？)希望我们能把它作为该机构总体战略计划的一部分予以通过。我自愿尝试并组装“软件生命周期管理”(或类似的内容)部分，以解决上面提到的问题(可能在战略计划的单独文档中使用黄铜钉)。几乎所有的软件供应商都会发布他们的产品的生命周期和废弃计划，考虑到这些信息以及我们组织的需求，很容易确定每个软件的“甜蜜点”。最棘手的部分(无论如何，对我来说)是把每一块的计划组合成一个更有凝聚力的东西。

我怎么能记录下桌面客户端A，B，C.依赖于桌面OS X和RDBMS Y，这反过来又取决于服务器OS Z，下面是我们如何将它们保持在它们的“甜蜜点”？肯定有书，但我的谷歌搜索只会让我了解升级一款软件的策略，而不是决定何时实施这些策略的策略。

Answer 1

看起来你正在尝试同时解决许多问题(这看起来不是一个好主意)。

据我所知：

• 过时的操作系统和应用程序
• 无长期战略
• 记录基础设施的问题
• 迫切需要更新关键的基础设施

升级“关键软件”

您的基础设施由于某人的决定而过时，这是很容易理解的。在过去的某个时候，这可能是个好主意。这可以归结为迈克尔·汉普顿在评论中所写的话:对于管理层来说，你谈论的是利弊(风险)。因此，如果管理层愿意承担风险，那么好的(不管你个人怎么想)，从现在开始，这是他们的责任。但IT部门的人必须告诉他们风险有多大。

所以我要找的第一件事是:经理们知道过时软件的风险吗？他们被告知了吗？

老实说，我觉得你可能找不到任何有用的东西，所以我不会花太多时间在上面。这只是一件可以帮助你的事情，就像“我们在过去的五年里一直在告诉你”。

我只想简单地分析一下执行升级的真正含义。准备简单的电子表格与活动和他们将需要多长时间(如果你不知道，给你最好的猜测，并明确强调，你不确定)。但是请记住，这个“升级任务”并没有很好的说明，它不可能作为固定时间/固定价格来完成。

做这样的清单也会帮助你深入研究整个问题。下一步是创建风险日志和所需资源的列表。

最后，你应该有活动清单、风险清单、材料清单/你需要的人。总之，不要把升级作为一个日常问题来处理，而是把它作为一个项目来处理。这将使您至少对公司的迫切需求有一定的控制能力。

如果您在分析哪些活动需要完成时有问题，您可以尝试一些思维图(我最喜欢的sw是xMind)，然后将其转换为更正式的文档。

请注意，当您有一些如何进行升级的选项时，您应该给经理一个可能的解决方案(如果有更多的话)，总结为几句话，包括成本、结果和风险；最好提到您推荐的选项和原因。因为最终的选择是他们要做的--他们毕竟是经理。

也许在这种特殊情况下:提到升级可能根本不可能。

无长期战略

制定一个战略计划现在对你没有任何帮助。如果它是在您的It部门内酝酿的文档，那么它将对您毫无帮助。战略计划需要与业务需求挂钩。

业务需求:两年后，我们将在中国和澳大利亚开设新的办事处。

它的任务是:准备好让新雇员

如果一切顺利，你可以有个策略.几个月后？所以要半年后才能达成协议？

维护和记录您的基础设施

这是过去的遗产，现在你必须改变一切。优先次序。列出一张清单，列出你现在要做/必须做的事情，使大多数事情都能跟上时代潮流。选择哪个可以等待，制定一个粗略的路线图。(这个路线图应该是您的IT策略的一部分，如果您有一个。)

如果你正在更新一些进展顺利的东西，把它当作日常事务来处理。如果你正在处理一些可能会变坏的事情(在花费的时间、分配的人员等方面“很大”)，把它作为一个项目来处理。

有一些工具可以帮助您处理文档和服务依赖关系--CMDB(例如iTop)。但是，让它开始工作可能需要一些时间，而且您仍然需要一些文档工具。最好的方法是为文档设置一个wiki，从现在开始每个人都可以开始记录/做笔记。你可以在半个小时内建立一个wiki，所以这是一个非常有效的方法来开始工作。

个人注意:升级旧的操作系统将是巨大的皮塔，没有提到(可能是坏的/缺失的)文档。从一开始就重新安装服务器、迁移应用程序和记录所有内容，难道不是更容易吗？