Все знают, как разрабатывать продукты для клиентов. Другое дело, когда задачу в разработку приносят не продакты, а коллеги из других команд: например, хотят автоматизировать свои процессы или внедрить новую систему. 

Они остаются наедине со своими проблемами. Идут к разработчикам — те просят ТЗ от аналитиков. Идут к аналитикам — те просят требования от службы безопасности, и это только начало. 

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

Внутри Lamoda Tech мы задумались о том, как не забивать на такие идеи. Эти проекты могли бы ускорить процессы и принести значительную выгоду компании. Но они редко доходят до реализации: слишком много усилий для этого нужно приложить. Большинство заказчиков сходят с дистанции задолго до финиша. 

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

Что не так с внутренними проектами

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

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

Конечно, компания в первую очередь выделяет ресурсы на основные процессы: они точно окупятся и принесут миллионы. Остальным гораздо сложнее добиться выделения бюджета и помощи от разработки. Особенно если финансовая выгода от условно «второстепенного» проекта не совсем очевидна. 

Чтобы исправить ситуацию, мы в первую очередь решили узнать, а в чем заключаются сложности?

Внутренняя разработка глазами заказчика 

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

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

1. Ошибки в требованиях на старте

Для начала работы и поиска подрядчика нужны четкие требования. Хорошо, если менеджер простым языком на листочке А4 напишет, что должно быть в системе. Часто нет и этого. Поэтому на старте легко упустить важные детали: например, сложности интеграции с другими внутренними системами — 1С и так далее. 

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

2. Экономический эффект равен нулю

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

Конечно, он не прав, и посчитать выгоду для компании реально. Но для этого нужен опыт и знания — или хотя бы подсказка, куда смотреть.    

3. Нет ресурсов на разработку 

Если заказчику все-таки удается доказать финансовую выгоду, то он отправляется на встречу по приоритизации проектов в разработке. Там его, как правило, заваливают непонятными вопросами про SSO и API. А потом показывают на длинный бэклог и объясняют, что очередь до проекта дойдет не скоро. 

4. Требования — в пользу подрядчиков

Следующий шаг — разработка детализированных требований. Наш заказчик берет листочек и пишет требования более подробно. По этим требованиям в итоге и будет составлен договор с подрядчиками. 

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

5. Согласование с ИБ и IT-архитектурой

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

6. К кому обращаться за поддержкой?

В Lamoda Tech есть первая линия техподдержки, которая занимается большинством вопросов. Но чтобы техподдержка взяла под свое крыло новую систему, опять необходимо соблюдение особых требований и новые согласования. Все эти условия логичны. Но как с ними должен справиться менеджер по командировкам? Этот вопрос мы и хотели решить.

Как помочь?

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

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

Это звено должно выполнять все задачи от старта проекта до его поддержки: 

• обработка входящего запроса; 

• оценка и приоритизация; 

• реализация проекта: либо своими силами (для простых задач), либо — и преимущественно — с помощью подрядчиков и существующих на рынке решений; 

• техническая поддержка. 

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

Так нам удалось решить вопрос ресурсов. Но одна проблема осталась: это приоритизация проектов. Как решить, какая из идей важнее, какую действительно стоит реализовать? 

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

Скоринг проектов по ROI 

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

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

Экономический эффект проекта всегда состоит из двух частей:

• То, что увеличивает продажи или сокращает затраты: например, за счет внедрения чат-бота мы сокращаем затраты на рассылку СМС. 

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

Как понять, где этот экономический эффект в проекте? Мы устраиваем брейншторм вместе с заказчиками. 

Например, к нам приходят рекрутеры с запросом на новую CRM для ведения базы кандидатов. Но посчитать профит от нее не могут. 

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

Дальше с этими мыслями и идеями заказчик уходит считать ROI (Return on investment) — коэффициент окупаемости инвестиций. Формула простая: в числителе стоит прибыль, а в знаменателе — затраты на реализацию проекта. Учитывают все затраты: 

• лицензии, 

• услуги (разовые и постоянные),

• затраты трудовых ресурсов: бизнес-заказчика, нашей команды, интеграции. 

Универсальность ROI в том, что он не показывает конкретных сумм и позволяет сравнивать проекты разной величины. На один проект потратят 50 миллионов, на другой — 5, но величина ROI зависит только от отношения профитов и затрат. 

В работу мы в итоге берем проекты, которые обладают наибольшим коэффициентом эффективности. Не было ни одного проекта, где мы не смогли бы посчитать такой коэффициент. 

Результаты

За два года команда внутренней автоматизации смогла реализовать несколько проектов, которые давно лежали в столе. Например, Gate Management: это система, которая позволяет нашим партнерам заранее бронировать время для передачи товаров на склад Lamoda. Когда машина с грузом подъезжает к складу, сотрудники уже готовятся принять конкретный товар и делают все быстро.

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

В новой системе забронировать удобный слот можно в реальном времени, не дожидаясь согласования с менеджером. От скопления машин теперь спасает система поощрения: если всегда приезжаешь вовремя и не опаздываешь, тебе доступно более удобное время для разгрузки. 

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

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

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

Конечно, у нас остаются определенные проблемы. 

• Ограниченность ресурсов: команда внутренней автоматизации не может делать все проекты в один момент. Когда появляется новая задача, мы не можем сходу взять проект в реализацию.

• Заказчики всегда хотят быстрее. Правда, сами они сами не всегда могут ускориться, ведь для них такой проект — это не основная деятельность. 

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

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