Иван Денисов, GTLogistics: Сроком окупаемости проекта может стать месяц

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

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

Иван Денисов: Да, эта карта универсальна для всех наших проектов. В рамках любого проекта так или иначе мы с заказчиком проходим все этапы внедрения. И разработка программных продуктов и внедрение идут у нас по методологии [Scrum]. Такой подход необходим для того, чтобы и мы, и наши заказчики четко понимали, на каком этапе в какой момент проект находится, что уже сделано, что предстоит сделать в ближайшем будущем, и что происходит сейчас. Особо хочу подчеркнуть необходимость максимального вовлечения заказчика в проект. Многие клиенты считают, что заключая договор с вендором, они могут полностью устраниться от процесса. Однако опыт показывает, что такой подход не работает, ставить клиенту задачи нужно, начиная с самого первого этапа внедрения. Это необходимо в том числе и с психологической точки зрения. В случае, если вовлеченность клиента в проект недостаточна, он начинает «расслабляться» и проект затухает. Позиция: «мы поставили задачу и больше ни во что не вмешиваемся, а вы выполняйте» не приводит к нужному для заказчика результату и оборачивается потерей денег и времени. Мы всегда стремимся максимально минимизировать трудозатраты клиента, но до конца это не получается. Со стороны заказчика должна быть обязательно создана рабочая группа со своей зоной ответственности.

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

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

Иван Денисов: Мы стремимся к тому, чтобы это был месяц. Во многих проектах по внедрению транспортных систем мы уже добились этого результата. Прежде всего за счет универсальности, для 80% клиентов она стала «коробочным продуктом». Такую систему можно запустить за пару дней. При этом наша система по автоматическому построению маршрута экономит клиенту в среднем 15% транспортных издержек в месяц. Например, один из наших клиентов получает уже в течение четырех лет экономию в 2,5 млн руб. в месяц. Система управления складом внедряется дольше, так как требует больше времени на интеграцию, настройку оборудования, доводку и т.п. Однако возможность нашей архитектуры позволяет гибко подключать дополнительные функции. Мы планируем уже в ближайшем будущем довести время запуска до двух-трех недель. В таком случае через два месяца уже можно будет говорить об окупаемости.

Иван Денисов: О главных «граблях» я уже рассказал. Клиент запускает проект, желая получить « все и сразу», в результате процесс идет долго и дорого, а в итоге клиент использует не больше 30% функционала. И это в лучшем случае. Чаще получается нерадостная картина: техническое задание выполнено, формально к разработчику претензий нет, а система не работает. Приходится проводить дополнительные итерации за счет заказчика. Причина таких «подводных камней» во многом связана с недостатками методологии Waterfall — каскадного подхода к разработке, в рамках которой только на техническое задание уходит 4-5 месяцев, а потом еще 5-6 месяцев идет на доработку и кастомизацию, а на заказчике лежит гораздо больше ответственности, чем в случае использования методологии Agile. По этой причине мы не используем Waterfall в своих проектах.

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

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

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

Иван Денисов: Один из действенных способов — просветительская работа, повышение грамотности заказчиков. Мы очень много времени уделяем этому: рассказываем и показываем, какие есть инструменты и способы добиться максимальной эффективности с минимальными затратами, продвигаем «свежий взгляд» на оптимизацию складских транспортных процессов. Объясняем, что процесс внедрения может выглядеть иначе, чем они привыкли, и что функционал складских систем позволяет выполнять гораздо больше задач, чем они думали. В частности, не только осуществлять контроль за работой сотрудников, но и снижать объем неликвида. Для такой просветительской работы очень подходят профессиональные выставки. В ближайшее время мы собираемся участвовать в CeMAT Russia — выставке складской техники, систем автоматизации склада и логистических услуг.