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

Это не история взлета с нуля до миллиардов. Это хроника накопления экспертизы, состоящая из шишек, разочарований и постепенного кристаллизирования простых, но почему-то неочевидных для многих истин.

Глава 1. Дистрибуция: Ликбез по термотрансферной ленте и рождение философии «добавленной стоимости»

Мой старт в индустрии автоматизации в 2007 году был максимально прозаичным. Я устроился в дистрибьюторскую компанию, которая представляла на нашем рынке гиганта — Zebra Technologies. Моей задачей как «менеджера по развитию бизнеса» было продвижение... расходных материалов. Да, тех самых этикеток и термотрансферной красящей ленты (риббона), которые многие воспринимали как неизбежное зло, нечто вроде канцелярии.

Провальная модель, с которой я столкнулся №1: «Товар — это просто товар».
Большинство дистрибьюторов тогда (да и сейчас многие) работали по простой схеме: закупил оптом → держи на складе → отгружай партнерам мелкими партиями. Их ценность для партнеров измерялась лишь двумя параметрами: цена и наличие на складе. Это была классическая «транспортная» логистика с минимальной наценкой. Конкуренция шла в основном по цене, и это был тупиковый путь.

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

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

Моя работа превратилась в непрерывный ликбез. Я не продавал. Я объяснял:

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

• Как состав риббона влияет на стойкость отпечатка к истиранию и УФ-излучению.

• Почему использование неподходящей ленты приводит к ускоренному износу термоголовки принтера, и как посчитать совокупную стоимость владения (TCO), где экономия в 10% на риббоне оборачивается ремонтом за 50% стоимости самого принтера.

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

Результат? За несколько лет оборот с $30 тыс. вырос до $2 млн. И дело тут не в моих выдающихся способностях к продажам. Дело в том, что я, по сути, создал новый продукт. Я продавал не этикетку, а стабильность бизнес-процесса. Партнеры, которые начинали прислушиваться, видели, что их клиенты становятся спокойнее и лояльнее. Они, в свою очередь, начинали доверять нам все больше.

Ключевые инсайты, вынесенные из этапа дистрибуции:

1. Ошибка: Продавать товар без экспертного контекста — путь в товарную яму с бесконечной ценовой войной.

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

2. Ошибка: Воспринимать сделку как разовое событие.

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

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

Глава 2. Системная интеграция: Миллион на фоне ста миллионов, или осознание ничтожности «железа»

Желание быть ближе к конечному заказчику и видеть результат своей работы вживую привело меня в системный интегратор. Это была уже серьезная компания, которая брала на себя комплексные проекты: от поставки терминалов сбора данных (ТСД) и принтеров до развертывания Wi-Fi-инфраструктуры и внедрения складских программных комплексов (WMS).

Именно здесь мое мировоззрение перевернулось. Я стал видеть всю картину целиком.

Один из самых показательных проектов: автоматизация крупного распределительного центра. Мы поставляли туда всё: от камер видеонаблюдения и промышленных точек доступа до ТСД, принтеров и, конечно, WMS-системы одного известного зарубежного вендора. Сумма контракта была огромной — под $1 000 000. Мы были на седьмом небе.

Позже, в неформальной беседе, мы узнали общую стоимость всего проекта по строительству и оснащению этого склада. Цифра оказалась ошеломляющей — около $100 000 000.

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

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

Логика была сломана: на фундаменте, который нельзя изменить, не экономят. А на софте, который как раз и определяет, насколько эффективно будет работать этот фундамент, — экономят до последнего.

Но и это была лишь верхушка айсберга. Главная боль открылась позже, когда мы как интеграторы пытались предложить заказчику комплексное решение «железо + ПО». Мы упирались в абсолютную неповоротливость и негибкость вендоров программного обеспечения.

Ситуация была всегда одной и той же:

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

• Мы передавали этот запрос вендору.

• В ответ получали: «Это не входит в стандартный функционал», «У нас такая архитектура», «Мы можем рассмотреть это в планах на следующий год», «Это невозможно».

Мы, находившиеся на передовой, видящие глаза клиента и несущие перед ним прямую ответственность, оказывались абсолютно беспомощны. Мы не могли выполнить свои обязательства не по своей вине. Сделки срывались, проекты затягивались на месяцы, клиенты уходили к конкурентам (у которых, как выяснялось позже, были ровно те же проблемы).

Я провел в системной интеграции 5 лет, дорос до коммерческого директора и вынес оттуда четкие, выстраданные на практике выводы.

Ключевые инсайты, вынесенные из этапа системной интеграции:

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

Решение: Настоящий системный интегратор должен либо иметь собственный ПО, либо иметь с вендором настолько тесные и эксклюзивные отношения, что может влиять на roadmap и приоритеты разработки. Без контроля над «софтом» ты не хозяин своей судьбы.

2. Ошибка: Позволять клиенту дробить проект на части, думая, что он сэкономит.

Решение: Ценность интегратора — в гарантии работы комплекса. Клиент, покупая «из одного окна», покупает не столько железо, сколько уверенность. Уверенность в том, что когда Wi-Fi «падает», ТСД не видит сервер, а принтер не печатает ярлык, он знает, кому звонить. И этот один человек (компания) обязан все починить. Экономия в 5-10% при самостоятельной закупке компонентов — ничто по сравнению с риском получить «винегрет» из несовместимого оборудования, где все винят друг друга, а проблема не решается.

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

Глава 3. Вендор: Бунт на корабле, или почему программисты не должны быть единственными властителями логистики

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

Мне дали высокую должность, я стал вторым человеком в компании. И с огромным энтузиазмом я попытался превратить этого чистого «продуктового» вендора в того самого идеального интегратора, о котором я мечтал. Я начал наращивать вокруг ядра - WMS - экспертизу по сопутствующему оборудованию: Wi-Fi, ТСД, видеонаблюдение. Я хотел, чтобы компания могла предлагать рынку полноценное решение.

Это был полный провал.

Я столкнулся не с техническими трудностями, а с ментальной стеной. Компания была создана и управлялась технократами. Их мир вращался вокруг кода, архитектуры, рефакторинга и новых «фич». Все, что было за пределами их IDE, они считали второстепенным, почти грязным.

Их логика была железобетонной:

• «Наш код работает с любым терминалом. Какая разница, какой?»

• «Wi-Fi — это не наша проблема. Это задача клиента или интегратора обеспечить стабильное покрытие».

• «Мы не будем советовать клиенту менять его бизнес-процессы. Его дело — описать, как он работает, наше — автоматизировать это».

Они принципиально не хотели брать на себя ответственность за что бы то ни было, кроме строк своего кода. Попытки объяснить, что успех проекта зависит от тысячи мелочей (качество связи, эргономика ТСД, удобство интерфейса для кладовщика) разбивались о глухую стену непонимания.

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

Содержать в штате не только программистов, но и сильных консультантов-технологов, которые понимают в логистике не по книжкам, — дорого. И они не видели в этом смысла. Зачем? Лицензии и так продавались.

Именно в этот момент во мне окончательно созрело решение: все, хватит. Пора делать самому. Я увидел корень зла, пройдя всю цепочку: дистрибьютор → интегратор → вендор.

Ключевые инсайты, вынесенные из этапа работы у вендора:

1. Ошибка: Ставить код и его «идеальность» выше потребностей живого бизнеса клиента.

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

2. Ошибка: Говорить клиенту «нет» на обоснованные запросы по доработке.

Решение: Система должна быть гибкой. Если клиент хочет протестировать свою, даже кажущуюся вам странной, бизнес-гипотезу и готов за это заплатить — ваша задача дать ему такую возможность. Остановить многомиллионный проект из-за спора о необходимости кастомной доработки стоимостью в 50-100 тысяч рублей — верх абсурда. Мы в своей практике используем подход «быстрого кастома»: быстрая и недорогая реализация нестандартной функции для одного клиента. Если она приживется и докажет свою эффективность — она идет в базовый функционал. Нет — значит, гипотеза не подтвердилась, но клиент не чувствует себя ущемленным.

3. Ошибка: Игнорировать «улучшайзинг» и пользовательский опыт (UX).

Решение: Большинство интерфейсов WMS, особенно на ТСД, — это наследие эпохи динозавров. Унылые, неудобные, медленные экраны. А ведь с ними работают люди по 8-12 часов в день! Их эффективность и настроение напрямую зависят от того, насколько им удобно. Нельзя экономить на визуальной составляющей, юзабилити, скорости отклика. Нужно постоянно двигаться вперед, подстраиваясь под современные тренды.

К этим выводам добавилось и понимание важности дорожной карты (roadmap). У многих вендоров ее просто нет. Развитие хаотично. Мы же выстроили свою разработку по трем независимым направлениям:

• Эволюция UX/UI: Постоянное обновление интерфейсов, внедрение элементов геймификации, BI-отчетности, 3D-визуализации склада. То, что делает работу проще и приятнее.

• Функциональные блоки: Анализ всех кастомных доработок и пожеланий от разных клиентов. Мы их аккумулируем, перерабатываем и превращаем в готовые модули, которые полезны широкому кругу заказчиков.

• Оперативная разработка: Закрытие текущих нужд внедряемых проектов.

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

Глава 4. INTEKEY: Синтез опыта. Попытка собрать идеальную модель

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

Из чего мы слеплены:

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

• Из системной интеграции мы взяли принцип тотальной ответственности за проект «под ключ». Мы не просто «поставляем софт». Мы проектируем, подбираем железо, строим сеть, внедряем, обучаем и сопровождаем. Мы — то самое «одно окно», которое избавляет клиента от головной боли с согласованием работ с десятком подрядчиков.

• Из опыта работы у вендора мы взяли главное — полный контроль над собственным программным продуктом. Мы сами его разрабатываем, сами определяем приоритеты развития и сами решаем, какие доработки делать. Никаких отписок «вендор не может». Если клиенту нужно, мы находим способ.

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

Глава 5. Неочевидные вещи: Юристы и команда

Есть вещи, которые со стороны не видны, но являются фундаментом. Работая у вендора, я увидел, сколько судебных споров возникает вокруг прав на ПО. Это сформировало мое серьезное отношение к юридической чистоте.

Мы с самого начала вложились в профессиональную юридическую проработку всех наших правоустанавливающих документов. Наш заказчик должен быть на 100% уверен, что он приобретает легальный продукт, защищенный от любых претензий третьих лиц. Исключительные права четко закреплены за INTEKEY. Для крупного бизнеса это — вопрос безопасности и гарантий.

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

Вместо эпилога

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

Если вы выбираете партнера для автоматизации, смотрите не на список «фич», а на компанию:

• Кто эти люди?

• Какой у них опыт?

• Контролируют ли они свою разработку?

• Готовы ли они брать на себя ответственность за комплекс?

• Есть ли у них внятный план развития их продукта?

• Как они относятся к своим текущим клиентам?

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

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