«Космический корабль» или Рабочий продукт с достаточным функционалом

Проблема выбора и проектирования TMS

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

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

История 1

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

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

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

Как правило, в таких проектах ситуация осложняется катастрофической занятостью руководителей, что растягивает предпроектный анализ во времени на 3-4 месяца вместо стандартных 1,5-2.

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

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

История 2

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

Собственником была поставлена амбициозная, но достижимая цель — начать работу в системе «Кругорейс» с 1 января и нас отделяли от этой даты 1,5 месяца. Весь бизнес-анализ удалось сделать удалённо ввиду нахождения собственника в длительном отъезде и острой эпидемической ситуации. После нескольких первых сессий у нас уже появилось понимание структуры задач и, не дожидаясь окончания бизнес-анализа, мы начали «развёртывание» системы на своих серверах, попутно дополняя необходимым для старта функционалом.

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

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

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