Инновации. Бережливо, но эффективно

Чем больше «нет», тем ближе «да»

Ну, что ж, никто не говорил, что будет просто и вам дадут с ходу денег на проведение пилота. Даже при условии, что вы провели proof-of-concept, сделали все возможные расчеты. И даже если в совете директоров сидят максимально толерантные к инновациям люди, вопросы всегда возникают.

В лучшем случае бюджет вам согласуют, но разблокируют его при устранении полученных замечаний, в худшем – отправят на доработку материалов. В любом случае нельзя бояться отказов – отрабатываете замечания и пробуете снова. Как говорят продавцы пылесосов Kirby: «Чем больше “нетˮ, тем ближе “даˮ»! Также часто на защите бюджета возникают вопросы из разряда «а все ли ты учел?».

И часто инициаторы проектов пытаются со всех сторон сэкономить еще неполученные деньги, тем самым пессимизируя те или иные статьи расходов. Например, выкидывают строку по разработке архитектуры, и в трубу вслед за ней улетает информационная безопасность. Или решат, что можно не включать статью на командировки, и пилот запускается потом бесконтрольно-удаленно где-то за Уралом. Кто-то сочтет, что виртуальной машине подрядчика хватит места и на действующем сервере, а потом ходит по коллегам в поисках недостающей памяти. Бывает, что люди просто боятся указывать рассчитанную сумму, считая ее запредельно большой. При этом в их головах большой может оказаться как 10-15 млн руб., так и 1-3.

Сейчас, имея за плечами проекты и за 500 тыс. руб., и за 500 млн, и больше миллиарда, участвуя в этих проектах в различных ролях: и руководителя, и заказчика, и спонсора, и партнера – мне легко рассуждать. Но помню себя в бытность моего стартапа, когда мы с компаньоном пришли на встречу с вице-президентом по развитию одного российского банка. Мы хотели получить инвестиции на развитие и за 10 мин. до встречи, два раза поседев, решились исправить в финансовой модели сумму с 45 млн руб. на 60. Мы почти час
(сколько же у него было терпения!) рассказывали про проект, и вот нас спросили, сколько же требуется денег.

Мы сказали, что нам нужно 60 млн, и затаили дыхание. Банкир спросил нас: «Рублей или долларов?». Услышав, что мы имели в виду рубли, он сказал: «Ребята, когда будете готовы к 60 млн долларов, приходите».

Железо

Но давайте не будем прыгать из крайности в крайность и более подробно обсудим принцип формирования бюджета пилота на примере проекта роботизации участка склада. Безусловно, самая капиталоемкая статья – это роботы. Их количество вам рассчитает ваш поставщик. Вы, конечно, и сами можете сделать расчеты и сказать, сколько «вешать в граммах», но зачастую вендор (а это в 99% случаях будет Китай) или интегратор не готов нести ответственность за эффективность проекта, основанную на ваших расчетах. И его можно понять, ведь если вы, не имея должной экспертизы, ошибетесь в меньшую сторону, то под угрозой окажется производительность системы. А если ошибетесь в большую – проект рискует не показать экономической эффективности. И в том, и в другом случае поставщик несет риски, что по результатам пилота технология получит негативную оценку.
Но все же в расчеты ваших поставщиков стоит погрузиться в следующих аспектах. Надо помнить, что китайцы часто очень осторожны с точки зрения безопасности и, как следствие, скоростей передвижения своих роботов. И практически всегда их расчеты будут строиться на заниженных по нашим меркам показателям: мы, например, готовы к 2 км/ч, а у них и в проекте и даже в настройках самого робота — 1 км/ч. Также стоит обратить внимание, что у китайцев своеобразное отношение к техническому обслуживанию и поддержке, вследствие чего российские поставщики довольно размыто транслируют эту опцию. Некоторые в виду незнания оборудования сильно перезакладываются по деньгам, некоторые чрезмерно много запасного фонда запчастей закладывают в стоимость роботов.

От проекта к проекту и от вендора к вендору обстановка, конечно, разнится, но с точки зрения безо пасности эксплуатации можно 7-10% роботов заложить поверх проектного расчета в качестве подменного фонда и 3-5% от общей стоимости роботов – на годовое обслуживание. Но если ваш проект подразумевает работу машин в агрессивной человеческой среде: с активным трафиком пилотируемой техники, с незрелыми сотрудниками склада – суммарно по запчастям можно терять и по половине стоимости робота в месяц. В таком случае в первую очередь будут выходить из строя лидары, датчики, бамперы.

Софт

Следующая статья, требующая детального анализа и расчета, – это ИТ-компоненты. И тут к вашему бюджету могут начать прилипать стоимость лицензий. За WCS Warehouse Control System) лицензию вам могут выставить разовую за проект, кто-то делает в привязке к количеству роботов, кто-то нет, но к 25-50 тыс. долл. будьте готовы. RMS (Robot Management System) привязана непосредственно к количеству роботов – лицензия на одну машину вам обойдется в 1-2 тыс. долл. Некоторые предложения у вас будут даже с лицензией на китайскую WMS (Warehouse Management System) – таким образом китайцы хотят обезопасить себя в интеграционных процессах, ведь потоки данных своей WMS с WMS заказчика поженить гораздо проще, чем с другими системами, с которыми у них под капотом уже будет реализована интеграция. У вас в предложениях также могут мелькать такие аббревиатуры, как RCS и WES, но, на мой взгляд, на ранних стадиях не стоит даже погружаться в их изучение.

В сухом остатке я бы оставил следующее. Если у вас в проекте один тип оборудования и один вендор, то RMS этого вендора вам будет достаточно для управления роботами через интеграцию WMS-RMS. Если подразумевается управление разными типами оборудования (например, роботами и палетными стекерами), то без WCS вам не обойтись. Но тут я бы смотрел в сторону российской WCS — с нашими разработчиками будет проще договориться о включении в пул проекта того или иного стороннего вендора. Но, оценивая стоимость ИТ-обвязки, не стоит забывать про стоимость самой интеграции. У поставщика она часто может быть заложена в стоимость лицензий, но об этом с ним надо проговорить в явном виде.

Российский поставщик, не имея большого опыта в интеграции китайского ПО, может неадекватно оценить усилия, и там, где он уверенно интегрировал за 1-2 мес. клиенту российскую WMS, с китайской RMS/WCS может запросто провозиться 3-4 мес., а, может быть, и больше. Тут и культура написания кода китайцами, и разница в часовых поясах. Да и разница в менталитете большая – редко какой китаец будет сидеть до ночи или в выходные только потому, что у Ивана в России образовался какой-то форс-мажор. Вы можете сказать, что это проблемы не ваши – поставщик сам на это подписался. Но когда деньги, рассчитанные на 2-3 мес. интеграции, у поставщика начнут заканчиваться, начнет расти риск того, что и качество работ будет снижаться – на сухарях с водой далеко не уедешь.

Хотя, положа руку на сердце, в вопросе интеграции будет также много зависеть от бодрости и зрелости вашей WMS-команды. Ведь зависания на вашей стороне будут также сильно аффектить на расходы поставщика. И, чтобы снизить количество корнер-кейсов, я бы рекомендовал заложить в бюджет 1-2 мес. на совместное с поставщиком написание бизнес-функциональных требований (БФТ). Далее полмесяца на декомпозицию БФТ в конкретные задачи. И еще минимум 3-4 мес. на саму интеграцию. Таким образом, на своей стороне вы сможете рассчитать примерное количество FTE (full time equivalent) ваших аналитиков, разработчиков и руководителей проекта.

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

Также не забывайте про серверную инфраструктуру. Если у вас централизованная архитектура, вам надо будет расширять мощности ЦОД, а это не всегда быстро, бесплатно и безболезненно. Но даже если ПО будет крутиться на сервере, стоящем на складе, надо понимать ограничения, связанные с вашей информационной безопасностью. Ведь помимо виртуальных машин вам может потребоваться место под развертывание систем управления базами данных (СУБД), а также место под back-up для них. А это все требует как дискового пространства, так и определенных показателей производительности оборудования. И, вроде бы, деньги тут небольшие — 2-3 тыс. долл., но в виду того, что серверное оборудование сейчас не валяется на каждом шагу, этот момент стоит учесть заранее.

Люди

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

И, на первый взгляд, кажется, что все эти расходы несущественны по отношению к стоимости самого проекта. Но директор объекта, где будет проводиться внедрение, вряд ли разделит такое суждение и с радостью воспримет, что это все ляжет на его отчет о прибылях и убытках (P&L). Он за эти деньги лучше крышу залатает или ТСД новых купит, а «ваш проект еще не факт, что взлетит». Поэтому лучше заложить эти расходы в бюджет проекта и потом сделать рекласс на МВЗ хозяйства.

Конечно же, нельзя забывать про команду внедрения. Минимум на 2-3 мес. после монтажа будут нужны ребята, которые в прямом смысле слова будут жить на объекте бок о бок с командой вашего поставщика. Тут потребуется и проектный менеджер, который будет координировать все процессы, и технолог склада, который будет предметно приземлять все задачи на объект. Также точно потребуется оператор роботизированного решения, который будет как наседка ходить за роботами. А еще нужен сотрудник ИТ поддержки, который будет оперативно решать задачи первой линии.

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

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

До скорых встреч!