Как посчитать затраты и подготовить сотрудников: STALOGISTIC делится опытом автоматизации

Как новые технологии повышают стоимость компаний из реального сектора и привлекательность бизнеса — для инвесторов? На что важно обратить внимание, запуская современные ИТ-платформы и решения — например, ERP? Выступая на сцене форума HI-TECH NATION, опытом цифровой трансформации в компании STALOGISTIC откровенно поделились ее основатель и председатель совета директоров Сергей Капустин, а также Андрей Тараченко, директор High Level (компания внедрила основные ИТ-решения в STALOGISTIC).

Рассказывая про свой опыт, эксперты дополняли и комментировали месседжи друг друга. Мы выбрали несколько важных тезисов из общего выступления.

Генеральный партнер события — Альфа-Банк (Беларусь)
Партнеры — Великий камень, компания Айрон,
консалтинговая компания Административный Ресурс, Microsoft, Pro trade, Chivas
Юридический партнер — Алейников и Партнеры
Образовательный партнер — IT-колледж Digital Unicorn

— Для чего нужно ИТ в реальном бизнесе? Для начала приведем пример из сферы ритейла, где, как известно, есть 2 конкурирующих модели:

• Компания Walmart, которая еще несколько лет назад по капитализации, объему продаж была № 1. Она придерживается классической технологии работы с клиентами — продажа товаров на своих торговых площадях
• Amazon. Если посмотреть на биржевые котировки, сегодня компания по капитализации в разы превышает Walmart. При сопоставимом объеме продаж.

Почему инвесторы реагируют на стоимость акций Amazon так активно? Технология взаимодействия реального бизнеса и ИT позволила сформировать бизнес-модель, за которую сегодня инвесторы голосуют долларом — покупают акции. Потому что они верят, что эта бизнес-модель гарантированно приведет в будущем больше клиентов, чем компания Walmart. Инвесторы голосуют за будущий денежный поток.

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

Понимая это, в STALOGISTIC — маленькой (по сравнению с мировыми гигантами) компании с большими планами — сейчас создаются предпосылки для того, чтобы выйти на новый уровень — уровень цифрового оператора.

Если нам удастся перейти на этот уровень, оценка стоимости бизнеса будет осуществляться не по привычной формуле: «EBITDA, умноженная на некий мультипликатор (коэффициент)». Она будет следующей: объемы продаж (выручка), помноженная на коэффициент. А это совсем другой, более привлекательный подход.

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

На примере внедрения ERP-системы, которое мы осуществили несколько лет назад, поделимся опытом подготовки STALOGISTIC к будущим шагам по развитию. Отметим, что у компании есть опыт внедрения других решений: запущена система бизнес-анализа, реализован проект по переносу инфраструктуры в Центр обработки данных (ЦОД).

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

Выбор вендора и ПО: на что обратить внимание

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

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

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

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

• С точки зрения роста ее пользователей
• С точки зрения интеграции в систему новых сервисов.

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

Выход для себя мы видим в поиске отраслевых решений под эти новые сервисы, их интеграции в общий информационный контур.

Внедрение и выбор интегратора

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

Вот на что мы рекомендуем обратить внимание:

1. Экспертиза. Мы заметили, что почти каждая компания-интегратор продвигает собственное ПО либо вендора, партнером которого она является. И даже если компания говорит, что у нее большая экспертиза и она может охватить все ваши процессы всем своим ПО, зачастую это не так. В реальности на рынке есть либо очень низкая экспертиза, либо интегратор все-таки профилируется на чем-то одном. Вы можете столкнуться с тем, что вам хорошо сделают одну часть системы, а все остальное будет по принципу «как получится».

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

Оценка инвестиций в проект

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

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

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

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

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

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

Бюджет и модель работы с подрядчиками

В основном бывают 2 контракта, по которым регулируется оплата за разработку и внедрение ИТ-систем. Это Time and Material (оплата согласно потраченному времени) и Fixed-price (фиксированная цена). Последний больше нравится бизнесу, потому что он считает: «Мы заплатим вам Х денег и за это хотим получать вот такой результат». Time and Material не нравится, потому что компании не могут спланировать свой бюджет. «Мы не знаем, чем вы там, разработчики, занимаетесь и к чему мы придем», — один из распространенных аргументов заказчиков.

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

Мы в STALOGISTIC, например, сначала работали по модели Fixed-price. Но — как и в большинстве случаев — первоначальное техзадание очень отличается от того, что мы получили уже в середине этого проекта. Поэтому мы сменили поставщика. И после уже работали по Time and Material.

С другой стороны, у нас был опыт запуска еще одного — инфраструктурного проекта. Там мы четко понимали, какой результат должен быть в конце. Могли просчитать все риски, отклонения, было разработано расписание по дням работ. В таком случае мы использовали Fixеd-price. Более того, заложенные в бюджет риски там не сработали, и мы сэкономили достаточно приличные деньги.

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

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

Готовность команды к изменениям

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

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

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

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

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

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

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

• На первых этапах высока вероятность технических ошибок. Во время внедрения ERP-системы мы предполагали, что эффективность в первые 2 недели у сотрудников упадет на 70%. Мы предполагали, что на уровень, который был до запуска проекта, компания вернется через 2 месяца. Этот риск сработал не на 100%. Уже через месяц наша команда работала с той же самой эффективностью, как до внедрения
• Переход на новую платформу требует двойного ввода. То есть нужно поддерживать добавление информации в старую систему, чтобы бизнес-процессы не рухнули, — и одновременно вводить соответствующие данные в новую систему.
  
  Мы планировали, что это существенно увеличит ресурс рабочего времени. Поэтому мы наметили запуск проекта не в период отпусков, чтобы все люди были на месте. Заранее попросили сотрудников быть готовыми к переработкам. Сделали все, чтобы компания понимала: период перехода на новую систему будет непростым. Эта проактивность нам позволила заложить больше рисков, и мы прошли период с меньшими потерями.

Улучшения системы после ее запуска

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

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

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

Как заказчику понимать подрядчика: совет от Сергея Капустина

Реализовав несколько проектов по автоматизации, мы поняли: мир ИT и мир бизнеса живут в разных системах координат. Например, если для наших коллег нормальным и постоянным является применение программы управления проектами Jira, то для нас как заказчика эта система управления проектами стала некой новостью. Я уверен, что любой бизнес, который производит конкретный продукт или услугу, более консервативен, чем среда ИT-разработчиков и ИT-команд. И в этом смысле между ними происходит рассинхронизация. Это нужно понимать, иначе будет взаимное недовольство. Поэтому во время совместной работы важно синхронизировать корпоративные культуры в области управления проектами.

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

Читайте также

• Как не провалить проект по автоматизации: пример с ЕRP
• «Нас предупреждали: там все выжжено напалмом» — как «Синэво» захватывала украинский рынок