Внутренняя ИТ-разработка. Ограничения, компромиссы, инсайты

Работая над проектом цифровизации мы сформировали единую платформу управления производством, охватывающую все основные процессы (сбор отчетности, обеспечение и комплектацию, управление персоналом, базу знаний и нормативно-правовых документов и т.д.), мы столкнулись с одной задачей, которой хотим поделиться в этой статье.

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

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

В чем преимущества внутренней разработки?

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

• оцифровывает ключевые бизнес-процессы;

• снижает издержки на десятки миллионов рублей в год;

• масштабируется, интегрируется с 1С и работает даже при слабом интернете или на старой инфраструктуре;

• улучшает качество управления, оперативность и безопасность.

Другая сторона медали

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

Рассмотрим каждое из них.

Бизнес-процессы

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

Заказчики из бизнеса

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

Бюджет

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

В итоге то, что вчера было гибким и быстрым решением, через 2–3 года превращается в тяжеловесную и уязвимую систему:

• команда устала или сократилась;

• разработка оказывается завязанной всего на паре ключевых сотрудников, которые легко заболевают звездной болезнью;

• скорость отклика падает;

• интерес бизнеса охлаждается;

• система становится «черным ящиком».

И что с этим делать?

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

Но чтобы выжить и приносить пользу, продукт должен:

• иметь четкую стратегию развития и отказаться от желания «сделать всё»;

• разделять ответственность между бизнесом и ИТ — бизнес должен быть вовлечён не только как потребитель, но и как инвестор и партнёр;

• обладать модульной архитектурой и документацией, чтобы не зависеть от конкретных людей;

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

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

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