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

我们已经将近十年没有升级RDBMS或服务器操作系统。另一个关键任务软件包已经使用了近二十年，并且在大部分时间里都没有得到其供应商的支持。我们管理层中的一些人似乎认为这是一件好事-我们不购买升级产品就节省了很多钱！现在，关键软件需要升级，但是新版本将不支持已有十年历史的产品。现在，我们当中的少数人正在努力寻找解决方法，以找出如何在最少的停机时间内立即升级所有产品的方法。

为了避免将来发生这种情况，我们中的一些人正在考虑创建IT战略计划文档（该文档将适合组织的战略计划，充实与IT相关的较大文档中的项目...也许使IT文档成为战术计划？），希望我们能够将其采纳为该机构总体战略计划的一部分。我自愿尝试组装“软件生命周期管理”（或类似的内容）部分，以解决上述问题（与战略计划分开的单独文件中可能包含粗俗的说法）。几乎所有软件供应商都为其产品发布生命周期和弃用计划，并且考虑到该信息以及我们组织的需求，很容易为每个软件确定一个“最佳位置”。棘手的部分（无论如何对我来说）是将每个部分的计划组合在一起，使内容更具有凝聚力。

如何记录台式机客户端A，B，C ...依赖于台式机OS X和RDBMS Y，而台式机OS X和RDBMS Y则取决于服务器OS Z，然后这就是我们将所有这些客户端置于“最佳位置”的方法？那里肯定有书，但是我的所有搜寻工作仅使我对升级单个软件的策略而不是确定何时实施这些策略的策略有所了解。

看来您正在尝试立即解决许多问题（而且似乎不是一个好主意）。

从我读到的内容：

• 过时的操作系统和应用程序
• 没有长期战略
• 文档基础架构时出现问题
• 迫切需要升级关键基础架构

升级“关键软件”

您的基础架构由于某人的决定而过时了，这很容易理解。在过去的某个时候，这似乎是个好主意。这归结为迈克尔·汉普顿（Michael Hampton）在评论中写道：对于管理层，您正在谈论利弊。因此，如果管理层愿意冒险，那就好（无论您个人如何考虑），这是他们从现在开始的责任。但是，IT人士必须告诉他们潜在的风险。

因此，我首先要寻找的是：经理是否了解过时的软件风险？他们被告知了吗？

老实说，我觉得您可能会发现对它没有任何用处，所以我不会花太多时间在它上面。它只是可以帮助您“过去五年来我们一直在告诉您”的方法。

我只是分析执行该升级的真正含义。准备简单的电子表格，其中包含活动及其进行的时间（如果您不知道，请提供最佳猜测，并明确强调您不确定是否知道）。但是请记住，此“升级任务”没有明确指定，因此无法作为“修复时间/修复价格”来完成。

制作此类列表还将帮助您深入研究整个问题。接下来是创建风险日志和所需资源列表。

最后，您应该具有活动列表，风险列表，所需材料/人员。 简而言之，不要将升级视为日常问题，而应将其作为项目来完成。 这将使您至少可以控制公司的紧急需求。

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

请注意，如果您有一些如何进行升级的选择，则应向经理们提供可能解决方案的书面说明（如果有更多解决方案），并用几句话总结，包括成本，结果和风险；理想地提及您推荐的选项以及原因。因为最终的选择是他们要做的-毕竟他们是经理。

可能在这种情况下：提到根本不可能进行升级。

没有长期战略

制定战略计划现在对您无济于事。如果它是IT部门内部编写的文档，则对您完全没有帮助。战略计划是需要与业务需求联系在一起的。

业务需求示例：两年内，我们将在中国和澳大利亚开设新办事处。

派生IT任务：准备好让新员工陷入困境，在外国办事处中建立基础架构，为新员工提供培训（可能使用其母语），提供从这些办公室到中心的安全连接，...

如果一切顺利，也许您可​​以在几个月内制定策略？那么大约半年，直到一切都达成一致？

维护和记录基础架构

这是过去的遗产，现在您必须进行更改。优先排序。列出您想/必须要做的事情，以使大多数事情保持最新状态。选择可以等待的，制定粗略的路线图。（如果您有此路线图，它应该是您的IT策略的一部分。）

如果您要更新顺利，请把它当作日常工作来处理。如果您要处理可能会变坏的事情（在花费的时间，分配的人员等方面“很大”），则将其作为项目来处理。

有一些可以帮助您解决文档和服务依赖性的工具-CMDB（例如iTop）。但是，使其正常工作可能需要一些时间，并且您仍然需要一些文档工具。最好的主意是为文档设置一个Wiki，从此以后每个人都可以开始文档编制/做笔记。您可以在半小时内建立一个Wiki，因此这是开始工作的非常有效的方法。

个人说明：升级旧版本的OS将是巨大的PITA，没有提到（可能是坏的/丢失的）文档。从头开始重新安装服务器，迁移应用程序和记录所有内容是否更容易？