Что является самым большим препятствием на пути цифровой трансформации и инноваций? Многие организации сегодня ответят, что это ИТ-отдел, но это опасная точка зрения. Например, согласно Gartner, одна из ошибок, которую совершают компании, когда речь заходит об автоматизации — важнейшем компоненте цифровой трансформации, — заключается в убеждении, что они могут сделать это без ИТ-специалистов, пишет на портале TechBeacon Майк Фицморис, вице-президент компании WEBCON.

Давайте сделаем шаг назад, чтобы понять, как мы пришли к такому образу мышления. Во многом это происходит от движения «гражданских разработчиков» — представления о том, что любители могут сами создавать приложения без какой-либо помощи со стороны ИТ-службы. Но это движение основано на ряде ошибочных предположений: гражданские разработчики хотят и могут заниматься разработкой и кодирование — единственное препятствие для разработки. Следовательно, ключ к успешной разработке заключается в том, чтобы обойти ИТ-отдел.

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

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

Управление напрасными усилиями

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

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

ИТ-специалисты могут помочь предотвратить напрасную трату усилий на слишком сложные проекты. Многие люди всегда ассоциировали их со сложными проектами (старые монолитные приложения), но современные айтишники расположены к более гибкому подходу. И наоборот, гражданская разработка, как правило, включает в себя множество вещей, соединенных вместе с помощью ситуативной партизанской интеграции, подобно машине Руба Голдберга.

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

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

Путь к интеграции

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

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

Дело не в получении разрешения, а в сотрудничестве. И держать ИТ-отдел в неведении просто вредно.

Остальные 90%

ИТ-отдел также помогает избежать сиротства приложений. Многие приложения являются полезными, но затем их разработчики становятся недоступными (уходят из компании, уезжают в отпуск и т. д.). Кто-то должен присматривать за приложением, пока они отсутствуют. Обычно эта задача ложится на плечи ИТ-службы.

На ИТ-отдел возложена задача по доставке приложений. Строительство — это только 10% доставки. В процесс вовлечены многие другие важные аспекты: сбор требований, переговоры, выбор инструмента, проектирование, спецификации, отладка, метрики, профилирование, аудит, безопасность, сопровождение, управление изменениями, развертывание, итерации, документация, обучение пользователей, ИТ-образование.

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

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

Эти 90%, которые не являются строительством, и есть то, что делает ИТ устойчивой практикой. Предположение о том, что для того, чтобы волшебство свершилось, нужно всего лишь устранить ИТ-отдел, ошибочно. Устранить кодирование недостаточно. Если вы собираетесь разрабатывать решение, вы все равно должны думать как разработчик — даже если вы не собираетесь писать код как разработчик. Кодируете вы или нет, но размышления о паттернах проектирования, нормализации, понятиях повторного использования и тому подобном имеют большое значение.

Привлечение ИТ-отдела правильным способом

Не поймите меня неправильно: ИТ-службы могут быть узким местом, и мы не можем с этим мириться. Но что мы можем тут сделать?

Существует третий путь — между крайностями формальной и гражданской разработки — так называемая «разработка с помощью гражданских». Одна из ключевых концепций этого пути — привлечение всех заинтересованных сторон, включая пользователей, лиц, принимающих бизнес-решения, ИТ- и технических специалистов. При разработке с помощью гражданских вы получаете команду коллег (иногда называемую «fusion team»), каждый из которых вносят свой вклад в создание эффективных приложений, исходя из своей специализации, формируя при этом более широкую среду, в которой приложения процветают.

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

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

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

Поиск золотой середины

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

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