Серия цифровых трансформаций: последняя миля

Если вы читаете этот пост, вы, вероятно, еще не прошли последнюю милю своего проекта трансформации.

Часто последние несколько месяцев проекта трансформации настолько интенсивны, что полностью поглощаются — независимо от того, насколько хорошо вы планируете проект, коммуникативно и организованно работаете в команде. Это просто потому, что цифровая трансформация часто затрагивает очень большую структуру компании — возможно, даже самое большое влияние, которое компания когда-либо испытывала.

Во многих случаях цифровая трансформация затрагивает больше технических, деловых и организационных элементов компании, чем что-либо ранее.

Учитывая такое влияние, компаниям легко вздрогнуть — сократить масштаб на полпути, поэтапно внедрять, чтобы уменьшить влияние, усилить надзор и тем самым замедлить проект. Как правило, такие подходы — эти рефлекторные реакции — являются ошибкой. Я уже говорил в предыдущих постах, что цифровая трансформация — это сложный процесс, который меняет компанию. То, что за изменениями стоит вся компания — сверху вниз — определит конечный уровень успеха проекта. Не вздрагивайте! Есть шаги, которые вы можете предпринять на последних милях проекта, чтобы максимизировать влияние и ценность вашей трансформации для бизнеса.

Много шума, который может возникнуть на заключительном этапе развертывания, можно уменьшить, если ваше заявление о миссии и проектные коммуникации были хорошо организованы и реализованы на более ранних этапах проекта.

Последний этап — абсолютно неподходящее место для обсуждения ценности, которую может принести текущий проект. Проще всего указать тем, кто поднимает шум, на изначальную миссию проекта, поддерживаемую руководством. Тем не менее, часто появляются новые игроки, особенно когда становится ясно, какой разрушительный эффект может иметь трансформация.

Заявления о миссии и одобрение руководства могут оказать огромное успокаивающее воздействие на новых игроков, а обмен предыдущими сообщениями с ними также может помочь им поверить и почувствовать себя частью процесса.

Часто бывает так, что на более поздних этапах проекта сроки оказываются под давлением, и вы будете искать способы сократить график. Здесь нужно быть очень осторожным.

В проекте есть четыре области, которые часто подвергаются риску, что наносит большой ущерб успеху проекта.

Проект цифровой трансформации: Тестирование

Цифровая трансформация часто управляется из ИТ. Тестирование может начинаться как сочетание технического и бизнес-приемочного тестирования, но в условиях давления поставки оно становится большой целью. Обычно хотят сократить циклы тестирования проекта. Одно из самых первых мест, на которое проектная группа может обратить внимание в очереди проекта, — приемочное тестирование бизнес-пользователей. Это чрезвычайно опасное место для резки.

Привлечение бизнес-пользователей к принятию и комментированию программного обеспечения является ключевой частью проекта, и для прохождения этого цикла требуется время. Может показаться, что к системному и модульному тестированию применяется другой уровень строгости, но это не менее важно. Сокращение здесь, чтобы сохранить временную шкалу, может привести к большим усилиям по переработке, потому что пользователи прямо отвергли или оспорили то, что было создано. Это влияет на сроки, но также может повредить динамике и поддержке успеха проекта. Поддерживайте вовлеченность бизнес-пользователей и побуждайте их к своевременному ответу, насколько это возможно. Любой другой курс, который снижает пользовательское тестирование, многократно увеличивает ваш риск.

Этап интеграции

Развертывание нового программного обеспечения не происходит в вакууме. Всегда есть другие системы для подключения. Одна из наиболее распространенных ошибок в проекте преобразования заключается в предположении, что интеграция с этими унаследованными системами будет работать так же, как и в прошлом. Почти во всех случаях это было бы плохим предположением.

Недавно я работал с заказчиком, который определил более 50 интеграций, которые необходимо было выполнить для окончательного запуска. Работая с нашей командой экспертов по обслуживанию, они смогли пройти один за другим, определяя, что было критически важным для проекта, а что могло быть отложено.

Поскольку проверка ваших интеграций не может произойти до конца проекта, есть естественная склонность к ускорению части интеграции. Это довольно опасная вещь — мы часто рассматриваем сбои интеграции как главную проблему преобразования в последнюю минуту. Если вы потратите время на то, чтобы определить, какие интеграции выполняются в режиме реального времени, какие почти в реальном времени и какие можно отправить в пакет, это поможет решить проблему интеграции.

Часто мы обнаруживаем, что интеграции, которые определены как требующие самых «дорогих» вызовов в реальном времени, оказываются несколько менее важными — и могут применяться стратегии, близкие к реальному времени. Классический пример: вам действительно нужна проверка запасов в реальном времени, когда кто-то просматривает детали товара в каталоге? Нужна ли вам проверка в реальном времени, если товар добавляется в корзину? Во многих бизнес-кейсах единственный вызов инвентаризации в реальном времени происходит, когда корзина подтверждается для оформления заказа.

Чем больше вы сможете задокументировать и проверить проблемы интеграции, прежде чем перейти к последней миле, тем больше вероятность того, что вы переживете этот тест. Устаревшие системные интеграции, созданные годами, часто не работают так же при подключении к новым системам. Если вы углубитесь в это на раннем этапе, это только поможет вам в этом ключевом усилии. Это та область, где предположения без подтверждения могут вызвать серьезные проблемы.

Нагрузочное тестирование

С усилиями по интеграции тесно связано нагрузочное тестирование. Слишком часто клиенты делают предположения о нагрузке, основываясь на стандартной производительности программного обеспечения поставщика. Это ошибочное рассуждение. Вы подгоняете и настраиваете решение под свои конкретные нужды. Каждая измененная настройка и каждый настраиваемый рабочий процесс отдаляют вас еще на один шаг от контрольных показателей пропускной способности, предоставленных поставщиком. Более того, ваши интеграции окажут существенное влияние на производительность вашего решения, и ваш поставщик никак не может предвидеть, каким будет это влияние.

У вас должен быть конкретный поставщик для проверки вашей архитектуры, настроек, интеграций и пользовательских работ в рамках проверки производительности. Несоблюдение этого требования может привести к серьезным проблемам при запуске. Недавно ко мне обратился клиент после того, как развернул свои первые четыре плана развертывания из 40 стран — крупнейшей из четырех была Ирландия. У них были серьезные проблемы с масштабом. После экстренного взаимодействия с нашей командой по производительности стало ясно, что потребуется существенный рефакторинг решения. Дополнительное развертывание пришлось отложить до тех пор, пока система не пройдет нагрузочный тест, что привело к неловкому положению исполнительной команды для ИТ-директора.

Ранее я подчеркивал, что нагрузочное тестирование системы должно быть основополагающей частью вашего проекта. Отсутствие или недооценка этого шага почти всегда заканчивается плохо.

Обучение

Когда проект находится под давлением времени/доставки, одна из первых вещей, на которую обращают внимание компании, — это компонент обучения. Сокращение здесь часто кажется еще одним простым способом уменьшить влияние на проблемы своевременной доставки проекта. Не делай этого!

Обучение часто недостаточно представлено для начала проекта цифровой трансформации. Нет ничего хуже, чем иметь новую систему, которая дает сбой, потому что никто не может ее использовать. Часто это не технологический вопрос. Люди заставляют системы работать — или нет. Эти люди должны знать и покупать то, что они собираются использовать.

Обучение можно условно разделить на два основных компонента — не игнорируйте ни один из них.

Системное обучение: Это обучение для команды, которая будет управлять рабочими потоками и бизнес-процессами, которые вы разработали в проекте. Именно на это уходит основная часть тренировочного процесса. Крайне важно убедиться, что люди знают, почему и как развертывается система, и как изменится их работа. Здесь есть изрядный объем работы, если вы существенно меняете бизнес-процессы, которые существуют уже давно. Убедитесь, что команды знают, что они делают и почему!

Это шанс привлечь внимание к новому решению, и привлечение этих команд сгладит неизбежные неровности, с которыми вы столкнетесь при развертывании. Это обучение должно включать три аспекта: обучение поставщика в аудитории или на месте, поправка системного интегратора для любой уникальности, созданной для вашего бизнеса, и практический опыт в песочнице, где пользователи могут совершать ошибки в безопасной среде. Пожалуйста, что бы вы ни делали, не думайте, что пользователи просто возьмут то, что вы им дадите. Это не лучший подход к созданию импульса, необходимого для достижения успеха в цифровой трансформации… составьте надлежащий план обучения и не срезайте углы. Отправляйте людей на обучение и вовлекайте их в работу — это принесет дивиденды.

Обучение конечных пользователей: это еще одна область, которая часто недооценивается при развертывании цифровой трансформации. Лучшее, что вы можете сделать, это сообщить выборке конечных пользователей о том, что будет дальше, посмотреть, сколько времени потребуется им, чтобы понять, и соответствующим образом составить планы обучения. Часто компаниям нравится включать группу конечных пользователей в качестве «защитников» решения. Это может хорошо работать, чтобы «засеять» сообщество пользователей командой, которая уже понимает систему.

Последняя миля всегда там, где наступает решающий момент. Но шаги, описанные выше, помогут вам справиться с трудностями спокойно.