数字化转型系列：最后一英里

如果您正在阅读这篇文章，那么您可能还没有进入转型项目的最后一英里。

通常，转型项目的最后几个月非常紧张，以至于完全消耗殆尽——无论您的项目规划、沟通和团队组织多么出色。 这仅仅是因为数字化转型经常影响公司的一个非常大的结构——甚至可能是公司所见过的最大的影响。

在许多情况下，数字化转型比以往任何事情都涉及公司更多的技术、业务和组织要素。

鉴于这种影响，公司很容易退缩——中途缩小范围，分阶段推出以减少影响，增加监督，从而减慢项目速度。 通常，这些方法——这些下意识的反应——是错误的。 我在之前的帖子中说过，数字化转型是一种艰难的、公司变革的经历。 让整个公司支持变革——从上到下——将决定项目的最终成功程度。 不要退缩！ 您可以在项目的最后几英里采取一些步骤，以最大限度地提高转型对业务的影响和价值。

如果您的使命陈述和项目沟通在项目早期得到了良好的管理（并针对其进行了交付），则可以减少在部署的最后阶段可能出现的许多噪音。

最后一个阶段是讨论当前项目可以交付的价值的绝对错误的地方。 最容易做的事情是让那些制造噪音的人回到最初的、执行支持的项目使命。 也就是说，经常会出现新的参与者——尤其是当转型可能产生的破坏程度变得清晰时。

使命宣言和高管认可可以对新玩家产生巨大的平静影响，与他们分享之前的沟通也可以帮助他们接受并感觉更多地参与到这个过程中。

通常情况下，在项目的后期阶段，时间表会受到压力，您将寻找压缩时间表的方法。 在这里你必须非常小心。

一个项目中有四个方面经常受到损害——这对项目的成功造成了极大的损害。

数字化转型项目：测试

数字化转型通常由 IT 管理。 测试一开始可能是技术和业务验收测试的结合，但在交付压力下，这似乎是一个很大的目标。 通常希望压缩项目的测试周期。 项目团队在项目时间线中可能首先考虑的地方之一是业务用户验收测试。 这是一个非常危险的切割区域。

让业务用户接受和评论软件是项目的关键部分，并且需要时间来完成这个周期。 它可能感觉不像应用于系统和单元测试的严格程度，但它至少同样重要。 为了节省时间线而在此​​处截断可能会导致大量的返工工作，因为用户直接拒绝或挑战已构建的内容。 这会影响时间线，但也会损害项目成功的动力和支持。 保持业务用户的参与并尽可能促使他们及时响应。 任何其他减少用户测试的课程都会使您的风险成倍增加。

整合阶段

部署新软件不是凭空发生的。 总是有其他系统可以连接。 转型项目中更常见的错误之一是假设与这些遗留系统的集成将像过去一样工作。 在几乎所有情况下，这都是一个糟糕的假设。

我最近与一位客户合作，他确定了 50 多个必须交付才能最终上线的集成。 通过与我们的专家服务团队合作，他们能够一一确定对项目至关重要的内容以及可能延迟的内容。

由于您的集成验证要到项目后期才能进行，因此自然会倾向于加速集成部分。 这是一件非常危险的事情——我们经常将集成失败视为转型面临的最后一刻的重大挑战。 花时间确定哪些集成是实时的，哪些是接近实时的，哪些可以推送到批处理中，可以帮助克服集成挑战。

我们经常发现，被确定为需要最“昂贵”实时调用的集成变得不那么重要——并且可以应用近乎实时的策略。 一个典型的例子——当有人查看目录中某个项目的详细信息时，您真的需要实时库存验证吗？ 如果将其添加到购物车中，您甚至需要实时验证吗？ 在许多业务案例中，唯一的实时库存调用发生在确认购物车以进行结帐时。

在到达最后一英里之前，您越能记录和验证集成问题，您就越有可能在此测试中幸存下来。 多年来构建的旧系统集成在连接到新系统时通常不会以相同的方式执行。 尽早深入研究只能帮助您完成这项关键工作。 这是一个未经验证的假设将回来给您带来重大挑战的领域。

负载测试

与集成工作密切相关的是负载测试。 客户经常根据供应商软件的库存性能对负载做出假设。 这是错误的推理。 您正在根据您的特定需求调整和定制解决方案。 每一个更改的设置和每一个自定义工作流程都会让您远离供应商为吞吐量提供的任何基准。 更重要的是，您的集成将对您的解决方案的性能产生重大影响——您的供应商无法预测这种影响会是什么。

作为性能验证的一部分，您应该有一个特定的供应商参与来审查您的架构、设置、集成和自定义工作。 不这样做可能会导致您的上线出现重大问题。 我最近有一位客户在推出了 40 个国家/地区推出计划中的前四个后联系了我——四个中最大的一个是爱尔兰。 他们遇到了严重的规模问题。 在与我们的性能团队进行紧急接触后，很明显需要对解决方案进行大量重构。 额外的部署不得不推迟到系统通过负载测试——这导致了 CIO 可以避免的执行团队尴尬。

我之前强调过，系统负载测试需要成为项目的基础部分。 缺少或代表这一步几乎总是很糟糕。

训练

当项目面临时间/交付压力时，公司首先考虑的事情之一就是培训部分。 在这里切割似乎是另一种减少对项目按时交付挑战的影响的简单方法。 不要这样做！

从数字化转型项目开始，培训往往得不到充分体现。 没有什么比因为没有人可以使用而导致新系统失败更糟糕的了。 这通常不是技术问题。 人们让系统工作——或不工作。 这些人必须知道并购买他们将要使用的东西。

培训大致分为两个主要部分——不要忽视其中任何一个。

系统培训：这是针对将管理您在项目中设计的工作流和业务流程的团队的培训。 这是大部分培训重点所在。 确保人们了解系统推出的原因和方式，以及他们的工作将如何改变，对于最后一英里的工作至关重要。 如果您要大幅改变已经存在很长时间的业务流程，那么这里有相当多的工作。 确保团队知道他们在做什么以及为什么！

这是一个激发对新解决方案的兴奋的机会，让这些团队参与进来将消除您在推出过程中不可避免的颠簸。 该培训应包括三个方面：在课堂或现场进行供应商培训，系统集成商针对为您的业务创建的任何独特性进行修正，以及用户可以在安全环境中犯错的沙盒体验。 请——无论你做什么，不要假设用户会简单地接受你给他们的东西。 这不是建立在数字化转型中取得成功所需的动力的好方法……制定适当的培训计划，不要偷工减料。 派人参加培训并让他们参与其中——这将带来回报。

最终用户培训：这是另一个在数字化转型推出中经常未能提供的领域。 您可以做的最好的事情是与最终用户的样本进行交流，看看他们需要多长时间才能掌握并相应地制定您的培训计划。 通常，公司喜欢将一组最终用户作为解决方案的“拥护者”。 这可以很好地为用户社区“播种”一个已经了解系统的团队。

最后一英里总是紧缩的地方。 但上述步骤将帮助您从容应对挑战。