Вольный перевод статьи McKemsey.
Близорукие решения повторяющихся проблем - это антипаттерны, которые препятствуют трансформации компании.
Независимо от того, называются ли преобразования гибкими, цифровыми или разработками (по другому - DevOps), их основная цель - создании добавленной стоимости. Добавленная стоимость бизнеса весьма успешно создается за счет коротких, итеративных и непрерывных циклов, оснащенных обратной связью "продукт-клиент". Такой гибкий подход значительно улучшает продукт и сокращает время выхода продукта на рынок.
Конечно, технологии играют решающую роль в реализации быстрого и гибкого подхода. Но антипаттерны решений, принимаемых в рамках этих технологий, наооборот, имеют серьезные, и иногда фатальные, последствия для бизнеса.
Близорукие решения повторяющихся проблем - это антипаттерны, которые препятствуют трансформации компании.
Независимо от того, называются ли преобразования гибкими, цифровыми или разработками (по другому - DevOps), их основная цель - создании добавленной стоимости. Добавленная стоимость бизнеса весьма успешно создается за счет коротких, итеративных и непрерывных циклов, оснащенных обратной связью "продукт-клиент". Такой гибкий подход значительно улучшает продукт и сокращает время выхода продукта на рынок.
Конечно, технологии играют решающую роль в реализации быстрого и гибкого подхода. Но антипаттерны решений, принимаемых в рамках этих технологий, наооборот, имеют серьезные, и иногда фатальные, последствия для бизнеса.
Вот эти антипаттерны.
Остерегайтесь тех случаев, когда технологические решения выбираются без учета потребностей бизнеса. Например, во многих организациях мы слышим о подходе «сначала микросервисы». Хотя микросервисы являются важным или даже критическим компонентом ряда этапов модернизации ИТ, но не всегда микросервисы, это то что нужно. Или то, что соответствуют требованиям бизнеса.
Рекомендация. Руководители должны задавать «глупые» вопросы до тех пор, пока не поймут логику и пользу предлагаемых технологических решений.
Стабильность и масштабируемость являются двумя ключевыми "качествами" ИТ-организации. Поэтому необходима тщательная и комплексная проверка предлагаемых решений на базе "передовых" технологий. Такая проверка позволит избежать внедрения пока не созревших технологий. Руководители должны с осторожностью относиться к любым, особенном "модным", рекомендациям в части "передовых" технологий.
Рекомендация. Выбирайте простые, проверенные технологии, с которыми знакомы ваши сотрудники.
Компании стремятся воспользоваться преимуществами новых платформ и технологий, таких как оркестраторы контейнеров, бессерверные платформы, аналитические решения и тому подобное. Это сложные технологии. Крупные поставщики облачных услуг постоянно развивают эти технологии как с точки зрения расширения их возможностей, так и с точки зрения снижения цены для завоевания рынкаи увеличения своей доли на рынке. Если облачная инфраструктура не ваш основной бизнес, вам не стоит сравнивать себя с поставщиками облачных услуг. Не стоит оценивать набор компетенций своей ИТ-организации с набором необходимых компетенций и способностей, требуемых для создания и запуска собственных облачных платформ. Вы почти наверное не сможете обеспечить надлежащее качество собственных облачных ИТ-услуг.
Изменения в инструментах и архитектуре могут помочь бизнесу, но они должны быть эффективными, должны сочетаться с изменениями инженерных практик, с изменениями процессов и с изменениями организационного поведения. Запуск программ крупного изменения архитектуры и инструментов часто требует минимальных усилий и привлекает внимание руководителей. Это также позволяет создать впечатление, что "дела движутся". Однако, без изменений инженерных практик, процессов и поведения такие программы могут быть малополезными.
Рекомендация. Определите слабые и сильные места бизнес-процессов. Изменения в архитектуре и инструментах должны устранять слабые места, сохраняя сильные места.
Рекомендация. Вместо того, чтобы управлять ИТ как центром затрат, подумайте о компетентности. Создайте истинное представление о совокупной стоимости владения (TCO) продуктов. Это позволит принимать разумные компромиссные решения о том, стоит ли инвестировать в новые функции, в автоматизацию или в оптимизацию инфраструктуры.
ИТ-организации справедливо вкладывают значительные усилия и ресурсы в создание и развертывание надежных платформ. Однако довольно часто бизнес не участвует в проектировании или разработке платформы, что приводит к появлению новых платформ с минимальной значимостью для бизнеса и, как следствие, плохим внедрением.
Рекомендация. Сосредотачивайтесь на бизнес-проблемах и убедитесь, что все заинтересованные стороны в бизнесе и в технологиях несут совместную ответственность за добавленную стоимость. Создавая платформу, сосредоточьтесь на создании сценариев ее использования. Возможно понадобиться провести рефакторинг некоторых элементов платформы, возможно понадобиться добавить больше функций и вариантов использования платформы.
Если ваши основные технологические знания или интеллектуальная собственность переданы на аутсорсинг, вы рискуете ограничить возможности трансформации и будете зависеть от третьей стороны. Такая зависимость сильно ограничивает организации в принятии смелой стратегии и в выборе партнеров. В этом случае нет контроля собственной интеллектуальной собственности.
Рекомендация. Четко обозначьте границы аутсорсинга критически важных для бизнеса технологий или видов деятельности. Если в настоящее время критический вид деятельности передан на аутсорсинг, подумайте о том, как теснее интегрироваться с поставщиками аутсорсинговых услуг и получить широкий доступ к технологиям.
Карьерный рост в большинстве организаций обычно предполагает управление людьми. Постепенно талантливые сотрудники, которые когда-то демонстрировали отличные технологические навыки и способности, начинают больше времени тратиь на управление людьми. Им приходится заниматься административной деятельностью в ущерб инженерному делу. Со временем они уже не могут участвовать в глубоких технических обсуждениях в командах, формировать пути решения технических проблем, не могут планировать инновации и, что наиболее опасно, не могут эффективно управлять технической стороной работы команды. Поэтому, в организациях всегда имеется ИТ-группа, которая отстает от развития ИТ технологий.
Рекомендация. Возложите на технических менеджеров конкретные технологические обязанности. Поощряйте культуру технических знаний для "технологических" менеджеров с помощью денежных и немонетарных стимулов. Для создания инженерной культуры определите точные и понятные критерии оценки эффективности работы с технологиями.
Данная заметка переведена с авторскими изменения. Первоисточник:
Ten ‘antipatterns’ that are derailing technology transformations July 21, 2020 | Article
1. Технологические решения внедряются "силовым решением"
Остерегайтесь тех случаев, когда технологические решения выбираются без учета потребностей бизнеса. Например, во многих организациях мы слышим о подходе «сначала микросервисы». Хотя микросервисы являются важным или даже критическим компонентом ряда этапов модернизации ИТ, но не всегда микросервисы, это то что нужно. Или то, что соответствуют требованиям бизнеса.
Рекомендация. Руководители должны задавать «глупые» вопросы до тех пор, пока не поймут логику и пользу предлагаемых технологических решений.
2. Внедрение недостаточно зрелых "передовых" технологий
Стабильность и масштабируемость являются двумя ключевыми "качествами" ИТ-организации. Поэтому необходима тщательная и комплексная проверка предлагаемых решений на базе "передовых" технологий. Такая проверка позволит избежать внедрения пока не созревших технологий. Руководители должны с осторожностью относиться к любым, особенном "модным", рекомендациям в части "передовых" технологий.
Рекомендация. Выбирайте простые, проверенные технологии, с которыми знакомы ваши сотрудники.
3. Создание собственной облачной инфраструктуры без достаточных компетенций и возможностей
Компании стремятся воспользоваться преимуществами новых платформ и технологий, таких как оркестраторы контейнеров, бессерверные платформы, аналитические решения и тому подобное. Это сложные технологии. Крупные поставщики облачных услуг постоянно развивают эти технологии как с точки зрения расширения их возможностей, так и с точки зрения снижения цены для завоевания рынкаи увеличения своей доли на рынке. Если облачная инфраструктура не ваш основной бизнес, вам не стоит сравнивать себя с поставщиками облачных услуг. Не стоит оценивать набор компетенций своей ИТ-организации с набором необходимых компетенций и способностей, требуемых для создания и запуска собственных облачных платформ. Вы почти наверное не сможете обеспечить надлежащее качество собственных облачных ИТ-услуг.
Рекомендация. Сосредоточьте свои инвестиции в сфере ИТ в общедоступном облаке. Начните работать с одним из поставщиков общедоступного облака. Не следует в начале пути применять мультиоблачный подход: разные платформы различаются в настройке и использовании, для их настойки требуется усилия и инвестиции для индивидуальной настройки. Максимально используйте решения SaaS. Для рабочих процессов используйте те шаблоны инфраструктуры, которые знаете, которые можете безопасно и надежно выполнять в любых ситуациях.
Проекты замены систем сложны, затратны и по сути - рискованны. Они также отвлекают организацию от создания ориентированных на клиента решений. Стоит избегать проектов по замене больших систем до тех пор, пока не будут оценены другие жизнеспособные пути.
Рекомендация. Прежде чем приступить к замене большой системы, получите ответы на следующие вопросы:
4. Замена больших систем, вместо того, чтобы быстрой и рентабельной модернизации этих систем
Проекты замены систем сложны, затратны и по сути - рискованны. Они также отвлекают организацию от создания ориентированных на клиента решений. Стоит избегать проектов по замене больших систем до тех пор, пока не будут оценены другие жизнеспособные пути.
Рекомендация. Прежде чем приступить к замене большой системы, получите ответы на следующие вопросы:
- Возможно ли постепенное улучшение старой системы вместо ее замены?
- Если необходима новая система, то принесет ли эта система дополнительную пользу?
- Возможно ли постепенно отказываться от старой системы в пользу новых решений?
5. Сосредоточение внимания на улучшении архитектуры и инструментов без улучшения процессов и дисциплины выполнения процессов.
Изменения в инструментах и архитектуре могут помочь бизнесу, но они должны быть эффективными, должны сочетаться с изменениями инженерных практик, с изменениями процессов и с изменениями организационного поведения. Запуск программ крупного изменения архитектуры и инструментов часто требует минимальных усилий и привлекает внимание руководителей. Это также позволяет создать впечатление, что "дела движутся". Однако, без изменений инженерных практик, процессов и поведения такие программы могут быть малополезными.
Рекомендация. Определите слабые и сильные места бизнес-процессов. Изменения в архитектуре и инструментах должны устранять слабые места, сохраняя сильные места.
6. Сосредоточение внимания на ИТ-результатах, а не на бизнес-результатах.
Пусть технологи и бизнес сформулируют конкретные и измеримые бизнес- и технические результаты, а не технологические показатели программных сред и инфраструктуры. Магия заключается в понимании компромиссов между бизнес-результатами и технологическими результатами. Далее - в осознанном выборе приоритетов с тем, чтобы сбалансировать краткосрочные цели с долгосрочной стабильностью.Рекомендация. Руководители должны определить совместную ответственность на желаемых результатах. Эти результаты деляться на две группы:
- Бизнес-результаты: потребительские свойства продуктов (количество клиентов, ежедневное использование) и удовлетворенность клиентов (чистые баллы промоутера, количество запросов на поддержку).
- Технологические результаты: функциональная доступность, безопасность продукта, эффективность разработки (частота выпуска, трудозатраты).
7. Управление ИТ ориентируясь исключительно на затраты выполнения ИТ-функций.
Управление ИТ как центром затрат - это устаревшее мышление. И это может иметь серьезные последствия, начиная от неспособности привлечь нужных специалистов и заканчивая отказом от использования критически важных и дорогих технологий и платформ.Рекомендация. Вместо того, чтобы управлять ИТ как центром затрат, подумайте о компетентности. Создайте истинное представление о совокупной стоимости владения (TCO) продуктов. Это позволит принимать разумные компромиссные решения о том, стоит ли инвестировать в новые функции, в автоматизацию или в оптимизацию инфраструктуры.
8. Инвестирование в разработку новых платформ без участия бизнеса.
ИТ-организации справедливо вкладывают значительные усилия и ресурсы в создание и развертывание надежных платформ. Однако довольно часто бизнес не участвует в проектировании или разработке платформы, что приводит к появлению новых платформ с минимальной значимостью для бизнеса и, как следствие, плохим внедрением.
Рекомендация. Сосредотачивайтесь на бизнес-проблемах и убедитесь, что все заинтересованные стороны в бизнесе и в технологиях несут совместную ответственность за добавленную стоимость. Создавая платформу, сосредоточьтесь на создании сценариев ее использования. Возможно понадобиться провести рефакторинг некоторых элементов платформы, возможно понадобиться добавить больше функций и вариантов использования платформы.
9. Передача основных процессов, обеспечивающих создание добавленной стоимости, на аутсорсинг.
Если ваши основные технологические знания или интеллектуальная собственность переданы на аутсорсинг, вы рискуете ограничить возможности трансформации и будете зависеть от третьей стороны. Такая зависимость сильно ограничивает организации в принятии смелой стратегии и в выборе партнеров. В этом случае нет контроля собственной интеллектуальной собственности.
Рекомендация. Четко обозначьте границы аутсорсинга критически важных для бизнеса технологий или видов деятельности. Если в настоящее время критический вид деятельности передан на аутсорсинг, подумайте о том, как теснее интегрироваться с поставщиками аутсорсинговых услуг и получить широкий доступ к технологиям.
10. Создание армии менеджеров вместо развития инженерной культуры.
Карьерный рост в большинстве организаций обычно предполагает управление людьми. Постепенно талантливые сотрудники, которые когда-то демонстрировали отличные технологические навыки и способности, начинают больше времени тратиь на управление людьми. Им приходится заниматься административной деятельностью в ущерб инженерному делу. Со временем они уже не могут участвовать в глубоких технических обсуждениях в командах, формировать пути решения технических проблем, не могут планировать инновации и, что наиболее опасно, не могут эффективно управлять технической стороной работы команды. Поэтому, в организациях всегда имеется ИТ-группа, которая отстает от развития ИТ технологий.
Рекомендация. Возложите на технических менеджеров конкретные технологические обязанности. Поощряйте культуру технических знаний для "технологических" менеджеров с помощью денежных и немонетарных стимулов. Для создания инженерной культуры определите точные и понятные критерии оценки эффективности работы с технологиями.
Данная заметка переведена с авторскими изменения. Первоисточник:
Ten ‘antipatterns’ that are derailing technology transformations July 21, 2020 | Article
Комментариев нет:
Отправить комментарий