Это Атвинта. Мы написали эту статью для тех, кто решает, какой путь выбрать для автоматизации и внедрения цифровых сервисов в крупной компании. Сделали обзор каждого подхода, рассказали, как в итоге поступить, и показали примеры всех вариантов на своих клиентах.
Подходы для внедрения цифровых сервисов
Представьте, вы руководитель и вам предстоит выбрать, кому доверить создание сервиса: вендору, подрядчику или же собрать свою команду. Каждый из этих подходов имеет свои преимущества и подводные камни. При этом вам нужно найти баланс между бюджетами, сроками и целями компании. А потом презентовать и согласовать решение с топ-менеджментом.
Для своих клиентов мы создали более 100 цифровых сервисов (экосистемы, ПО, личные кабинеты, BI-системы) и в этой статье расскажем, как выбрать правильный вариант без лишних затрат и с максимальным выхлопом для компании.
Навигация по статье:
1. Плюсы и минусы вендора
2. Плюсы и минусы аутсорс-разработки
3. Плюсы и минусы инхаус-команды
4. Что выбрать для базовых бизнес-процессов
5. Что выбрать, если речь про более сложные процессы
6. Кому подойдет своя команда
7. Подводим итоги + спойлеры к следующим статьям
Обзор подходов
Ниже рассказываем про плюсы и минусы каждого из вариантов, но если уже разбираетесь в них, то можете сразу перейти к рекомендациям и примерам.
Вендор
Вендор — это поставщик ПО, который предлагает готовые цифровые коробочные решения. При работе с вендором компания устанавливает базовое коробочное решение, которое опционально может быть доработано вендором под индивидуальный запрос. Примеры популярных российских вендоров: 1С, Касперский, Softline.
Вендора можно сравнить с магазином, потому что в нем можно купить готовую одежду, созданную по усредненным параметрам для всех.
Плюсы
- скорость внедрения — не нужно тратить время на разработку с нуля, базовый функционал настроен и готов к работе
- экспертиза — обычно вендоры обладают сильной экспертизой в рамках своего направления, например, цифровизация строительства
- стабильность — продукты проходят масштабное тестирование перед выпуском и до конечного пользователя обычно доходят без багов
- снижение затрат — не нужно вкладываться в собственную разработку, хотя в долгосрочной перспективе коробка может обойтись дороже
- техническая поддержка — всегда можно обратиться за рекомендациями или решением проблем
- льготы и возмещения — для компаний, внедряющих отечественное ПО, в России предусмотрены возмещение затрат на софт и снижение налоговой нагрузки
Минусы
- зависимость от поставщика — компания подсаживается на иглу коробочного решения, и в случае недобросовестного исполнения задач, появления проблем с софтом или техподдержкой будет тяжело отказаться от действующей системы
- недостаточная кастомизация — продукты вендора создаются “в среднем по больнице”, и часто заказчики страдают от нехватки функций и возможностей для своих процессов
- низкая гибкость — внесение доработок необходимо обсуждать с вендором и ожидать появления ресурсов для своих потребностей
- интегрируемость — не все продукты легко и бесшовно внедряются в действующую архитектуру компаний
- безопасность — риск утечки и сохранности данных, которые находятся в руках сторонней организации
Аутсорс-разработчики
Аутсорс-разработка — это формат, когда сторонний ИТ-подрядчик создает для заказчика цифровой продукт с нуля: сервис, ПО, систему, мобильное приложение или портал. При этом подрядчик отвечает и за внешнюю (интерфейс) и за внутреннюю (архитектура, бэкэнд) оболочку софта.
Мы, Атвинта, являемся таким цифровым подрядчиком и работаем с производственными и промышленными компаниями — создаем внутренние системы под бизнес-процессы компаний. У нас действует полный цикл разработки: аналитика, дизайн, разработка, тестирование развитие и техподдержка.
Аутсорс можно сравнить с ателье, где с тебя снимают мерки и шьют по индивидуальному эскизу.
Плюсы
- кастомизация — продукт создается с нуля под задачи компании и учитывает все ее особенности
- экспертиза здесь и сейчас — вы получаете готовую опытную слаженную команду, в то время как при инхаус-подходе придется потратить годы на выстраивание взаимодействия и найм талантливых сотрудников
- стоимость — аутсорс обходится дешевле содержания собственного ИТ-юнита и при этом остается преимущество гибкости и кастомизации, а одному из наших заказчиков разработка с Атвинтой обошлась даже дешевле коробочного решения
- больше контроля — если в готовых продуктах командой управляет вендор, то в заказной разработке вы сами определяете ТЗ, которое будет исполнено
- гибкость — компания не зависит от вендора и может реализовывать любые фичи в своем продукте, а методологии скрам и эджайл позволяют в моменте менять приоритеты и очередность задач
- специализация — подрядчик знает, как сделать качественный продукт с удобным интерфейсом, продуманной архитектурой и интеграциями. Наши клиенты говорят, что пришли к нам, так как их компании специализируются на отраслевом опыте (строительство, промышленность), а ИТ выполняет обслуживающую функцию, поэтому у них нет достаточного опыта для разработки сервисов
Минусы
- качество — не все подрядчики успешно выполняют свою работу, поэтому нужно внимательно относиться к выбору партнера
- зависимость от подрядчика — при долгом сотрудничестве подрядчик становится почти что частью компании, поэтому в случае чего разорвать партнерство будет сложно из-за погруженности, выстроенной коммуникации и потраченного времени
- замены в команде — в аутсорсе замены ощущаются острее, потому что заказчик чаще коммуницирует напрямую с командой, плюс при замене новый специалист тратит время на погружение
- отраслевая экспертиза — цифровой подрядчик может быть хорош в разработке, но редко когда у диджитал-агентства есть опыт со сложными отраслевыми бизнес-процессами. Например, в наших первых производственных проектах, чтобы погрузиться в бизнес заказчика, команда проходила специальные обучения и брала консультации у консалтеров
*Отметим, что аутсорс не равняется аутстаффу IT-специалистов, когда компании арендуют сотрудников и сами управляют процессом разработки.
Инхаус
Инхаус-команда — это ИТ-специалисты, которые трудоустроены внутри компании и работают над ее задачами. Крупные корпорации часто выделяют ИТ-юнит внутри структуры или же создают отдельные компании под разработку и технологии. Например, X5 Tech, Avito Tech, Сибур Диджитал, также своя ИТ-команда есть у Самолета.
Внутренняя команда как швейная машинка. Полный полет для фантазии, только нужно уметь обращаться с оборудованием и самому садиться за шитье.
Плюсы
- полный контроль — компания сама управляет командой, это самые быстрые коммуникации и отсутствие любых ограничений
- кастомизация и гибкость — как и в аутсорсе, продукт создается под задачи компании, может быть изменен и доработан по желанию заказчика
- отраслевая экспертиза — внутренние спецы максимально погружены в бизнес и понимают его специфику
- конфиденциальность — ниже риски утечки чувствительной корпоративной информации
- вовлеченность — сотрудники в штате высоко мотивированы, потому что ведут общее дело внутри компании
- опыт разработки — в процессе работы над продуктами формируется коммуникация, копятся успешные практики и кейсы, в результате отраслевой опыт усиливается экспертизой в ИТ. Например, технология put by light (световая комплектация товара) помогает Х5 быстрее находить товары на складе и ускорять работу сотрудников
Минусы
- высокие затраты — компанию ждут значительные расходы на найм, обучение и оплату труда
- долгий старт — на поиск талантливых сотрудников и организацию процесса разработки могут уйти годы, это усложняет запуск работы над сервисом
- меньше гибкости в кадрах — на новые задачи диджитал-агентство быстро поставит дополнительных спецов любой специализации благодаря большому штату, а для инхаус-команды придется тратить время на поиск подходящего сотрудника
- ситуации внутри коллектива — в команде выстраиваются межличностные отношения, которые могут влиять на принятие решений и качество работы
- ограниченность практики — инхаус-команда варится только в своих процессах, в то время как агентства работают с разными компаниями и накапливают множество технологий и идей, которые расширяют кругозор
Что выбрать: вендор, аутсорс или инхаус. Рекомендации и кейсы
Основной критерий для выбора — это специфичность бизнес-процессов, масштабы разработки, бюджет и сроки.
Если процессы стандартные
Таск-трекер или корпоративный мессенджер можно взять на рынке — отечественные вендоры предлагают огромное количество качественных и легких для внедрения решений за небольшой прайс. Здесь можно уверенно сделать выбор в пользу коробки и не тратить время и бюджеты на собственную разработку инхаус или с подрядчиком.
Пример: использование коробочного решения в эдтехе
Наш клиент, онлайн-школа по подготовке к ЕГЭ SMITUP, первые несколько лет использовала для обучения GetCourse. На старте приоритетом был простой и быстрый запуск за небольшие деньги, поэтому компания выбрала доступное коробочное решение.
Бизнес рос, и на новых масштабах работать без кастомизации стало сложно. Например, в GetCourse невозможно настроить тесты по формату ЕГЭ. Тогда SMITUP обратились к нам за созданием собственной образовательной платформы, где уже прошли обучение более 20 000 учеников. Однако на первом этапе сервис от вендора был идеальным решением для компании.
Если речь о более сложных процессах
Другое дело, когда компании нужно оцифровать более редкие отраслевые процессы. Например, системы по управлению оборудованием или производством.
Здесь появляются 2 сложности:
- ограниченный выбор готовых продуктов, а в некоторых случаях и их полное отсутствие
- как правило, такие процессы сильно отличаются от компании к компании, и появляется потребность в гибкости софта, чтобы его можно было настроить под себя
Также важны стратегические цели. Ответьте на вопрос — это будет точечное внедрение одного сервиса или планируется постоянное расширение системы и дополнение ее новыми функциями?
Если нужно закрыть только одну потребность, то выходом может стать как готовый продукт, так и собственная разработка с аутсорсерами.
Узнайте, какие решения предлагают вендоры для ваших задач, изучите предлагаемые функции и готовность дополнять софт под ваш запрос. Понравившиеся решения можно забрать на пилоты и выбрать лучшее.
Но если приоритетом остается гибкость, настройка под свои процессы, независимость и скорость изменений — даже с одним сервисом стоит обратиться к подрядчику и создать собственный продукт. После внедрения вы сможете купить пакет техподдержки и вносить небольшие доработки.
Когда не стоит выбирать вендора
Когда речь идет о масштабной разработке и долгосрочных планах по постоянному развитию ИТ-архитектуры — рекомендуем идти в самостоятельную работу, потому что в рамках продукта вендора рано или поздно станет тесно.
Есть нюанс. Здесь будет сложнее согласовать бюджет и обосновать внедрение перед топ-менеджментом — сроки дольше и цифры выглядят внушительно, по сравнению с оплатой коробки. Однако в долгосрочной перспективе собственные системы окупаются многократно.
В долгосрочной перспективе собственные системы окупаются многократно.
Для своих клиентов на старте мы проводим бизнес-аналитику, которая определяет необходимый функционал, бюджет на MVP и цифры по улучшению метрик. Это помогает убедиться в целесообразности внедрения, а также обосновать и презентовать проект топ-менеджменту.
Пример: переход от вендора к подрядчику
Такой опыт был у нашего клиента, лидера производственно-добывающей отрасли. Для компании мы создали экосистему сервисов для внедрения улучшений на производстве. Это редкий бизнес-процесс, и на рынке не так много коробочных предложений под такие задачи.
Сначала компания работала с иностранным вендором, но в результате решила перейти к собственному софту.
Причины перехода:
- отсутствие гибкости: вендор не был готов внедрять многие функции по запросу компании
- стоимость доработок, которые вендор все же был готов внести, обходились слишком дорого — с предлагаемыми бюджетами стало проще вложиться в свою разработку
- медленная техподдержка
- недружелюбный и нелогичный интерфейс
- был запрос на масштабирование, а перечисленные выше проблемы замедляли сроки и не позволяли реализовать все хотелки
После вендора компания обратилась к нам в Атвинту за разработкой собственных сервисов.
В нашем партнерстве заказчик больше всего ценит гибкость, возможность настраивать систему под свои бизнес-процессы, тестировать новые функции и быстро вносить доработки.
Мы начали с одной системы, которую постепенно раскатили на 24 производства. Потом на базе этого продукта разработали еще 4 сервиса, которые закрывают разные задачи в рамках внедрения улучшений на производстве.
Продукты экосистемы объединены единой базой данных и авторизацией. Мы сразу делали систему гибкой, потому что у заказчика был запрос на масштабирование ПО.
Если нужно очень много цифры
И последний вариант — инхаус.
Своя команда — это дорого и долго . Подходит для тех компаний, где цифра играет ключевую роль и есть смысл накапливать такую экспертизу внутри компании.
При этом вложения будут не только временные и денежные, но и менеджерские. Для полноценной разработки нужно нанять сильную команду из аналитиков, разработчиков, дизайнеров и продактов. А еще — внедрение фреймворков, регламентов работы и коммуникаций в команде.
Пример: создание инхаус-команды
Еще один наш заказчик — компания Телеконтакт. Это крупнейший аутсорсинговый колл-центр России. Для контроля качества звонков компания разработала внутреннюю систему со всеми необходимыми функциями и продолжает развивать ее.
Компания не только пользуется сервисом сама, но и представляет его на рынке как вендор, поэтому Телеконтакт содержит свой ИТ-юнит с техподдержкой и разработчиками.
А к нам компания обратилась за редизайном — по мере появления новых функций сервис обрастал новыми кнопками и разделами. Поэтому сотрудникам стало сложнее ориентироваться в интерфейсе. Мы обновили структуру и дизайн экранов.
Этот проект стал лучшим интерфейсом для бизнеса по итогам конкурса G8 2023.
Итоги
Кратко собрали основные критерии выбора в одном месте:
Следите за нашими апдейтами — в следующих статьях мы расскажем, как выбрать вендора, партнера для разработки или собрать свой ИТ-юнит. А также на подходе кейс об экосистеме сервисов для сбора идей по производственным улучшениям от сотрудников, о котором мы говорили выше.
