Бизнесмены vs айтишники: почему возникают разногласия и что с этим можно сделать

Некорректная презентация бизнес-требований и непонимание ограничений со стороны ИТ-отдела

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

В чем причина. ИТ-команде не получается внедрять сложные фичи, потому что бизнес-процессы не систематизированы:

• отсутствует понятное для всех сторон описание архитектуры;
• отсутствует согласованный процесс управления задачами;
• у некоторых ИТ-систем нет определенных владельцев.

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

Архитектурные изменения не фиксируются, что приводит к конфликтам с уже существующим функционалом. Как результат, с точки зрения ИТ-команды, задачи «пилятся» и работа движется, а бизнес не получает ценности в нужном объеме. Или получает, но низкого качества и с задержкой по срокам.

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

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

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

По теме. Что такое траблшутинг и зачем он нужен бизнесу

Неправильный выбор технического решения

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

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

Веб-сайт должен выдерживать большой поток посетителей. Система управления заказами (OMS-система) должна быть способна обрабатывать гораздо больше заказов, а количество менеджеров и процессы на складах должны соответствовать увеличенному объему работы. Обычно эти системы настроены на текущий объем. И если не учитывать планы на будущее, то можно потратить много денег на решения, которые через несколько лет придется переделывать или строить заново. А это всегда очень дорого.

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

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

Проблемы на этапе аналитики

Кейс. У руководства крупной сети бутиков женской одежды Fashion Fusion есть желание развивать свой популярный, но простой интернет-магазин: добавить оплату товаров «Долями», подключить кредитную программу и внедрить омниканальную лояльность, чтобы узнавать клиента и в офлайн-магазинах, и на сайте, и в приложении. 

Бизнес и ИТ рассчитали потенциальную прибыль и стоимость реализации, все взвесили, приняли решение и продумали стратегию. Далее вопрос ушел к системным аналитикам, которые описали требования к системам и процессам, используя различные методологии. Но, увидев документацию, разработчики заявили: «Ребята, тут очень много написано, мы не понимаем, какие у нас задачи».

В чем причина. При системном анализе потерялась суть. Ошибка могла быть и со стороны бизнес-аналитиков — слишком усложнили. И со стороны разработчиков — сопротивлялись непривычным требованиям.

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

Когда в компании работает одна ИТ-команда из 3–5 разработчиков, формальная документация им не нужна, всё умещается у них в головах. Но когда происходит масштабирование бизнеса, ИТ-команда растет, и появляется необходимость ее структурировать. Например, разделить на фронт, бэк и мобильное приложение. Тогда информация, находящаяся только в головах специалистов, уже не сработает, и необходимо формализовать процессы и взаимодействие. Без этого бизнес рискует потерять возможность роста и развития.

Что делать. Компании нужно выбирать такой способ описания ИТ-требований, чтобы он подходил ей в тот момент развития, в котором она сейчас находится, но и с оглядкой на ближайшие 2–3 года. Понятно, что правила, по которым живет ИТ-инфраструктура Microsoft, не подойдут Fashion Fusion с их текущим уровнем зрелости. А если бы Microsoft работал по правилам Fashion Fusion, он не был бы Microsoft.

По теме. 5 советов по нетворкингу для интровертов

Результат работы ИТ-команды не всегда понятен бизнесу

Кейс. Приведем в пример ту же сеть Fashion Fusion. Предположим, команда разработчиков поступила по-своему: требуемые доработки были декомпозированы на подзадачи, каждая их них выполнена и по отдельности передана тестировщикам.

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

В чем причина. В данном случае единственное, за счет чего все функционирует — это разработчики, к которым в итоге система привязывается. В компании появляются «незаменимые» люди, и только они представляют, как все должно работать. Если они уходят из компании, бизнес теряет понимание структуры процесса и, как следствие, огромное количество денег.

Что делать. Решение проблемы требует совместных усилий от всех участников проекта: бизнес-аналитиков, разработчиков, тестировщиков и руководства компании. Важно установить в компании четкие процессы и стандарты работы и быть последовательными в их внедрении.

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

Неправильный выбор ИТ-стратегии

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

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

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

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

Фото на обложке: Shutterstock