Как бизнес-спецназу Амивео удалось превратить IT-департамент одной зарубежной компании из гадкого утёнка в белого лебедя

Всем привет, с вами снова Кирилл Тихонов, управляющий партнёр первого в России бизнес-спецназа Амивео. Бизнес-спецназ – это я, мой партнёр Ольга Павленко и наша команда. Те самые люди, которые сами «высаживаются» в компанию и сами отлаживают систему административного управления и настраивают все бизнес-процессы. Выводя владельца из рутины операционки и позволяя ему заниматься главным, на чём стоит его бизнес – продажами и/или производством.

Сегодня, вопреки ожиданиям, обойдётся без скандалов, интриг и расследований. Не будет массовых увольнений и расстрелов. Кейс будет во многом рутинным, но именно из этой рутины и складывается большая часть нашей работы. Именно таким образом, шаг за шагом, мы оздоровляем бизнес, налаживаем систему и приводим процессы в компаниях в порядок. И, что характерно, делаем это с полным погружением. В отличие от типичных консалтеров, мы не просто с маркером у доски рассказываем, что вам надо поменять в вашей компании, как построить оргструктуру, кого уволить-нанять. Мы САМИ садимся и начинаем руководить процессами — своими руками и присутствием решаем накопившиеся в компании проблемы.

Потому что, как известно, добрым словом и пистолетом добиться можно больше, чем просто добрым словом. Так что, вопреки рутинности, думаю, будет не скучно. Итак, поехали!

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

Небольшое отступление для понимания деятельности наших клиентов. Сами они продукт не производят. Но и масштабы у них не те, чтобы размещать по одной позиции на маркетплейсе. Компания заключает договор с производителями шуруповёртов и прочих дрелей, и после, на условном Otto Market или Zalando (прим. крупнейшие маркетплейсы Германии, аналоги наших Озон и Вайлдберрис), размещает сотни и тысячи позиций, способных удовлетворить спрос массового клиента: от строительного оптовика до частника, надумавшего сделать ремонт в гостиной.

Само собой, в компании установлена ERP-система, через которую проходят все бизнес-процессы, необходимые для управления бизнесом: финансы, кадровые вопросы, производство, цепочка поставок, услуги, закупки и многое другое. В эту систему они сначала массово загружают свои позиции. А поскольку система ERP у них интегрирована со всеми маркетплейсами, они буквально одной кнопкой выгружают в эти самые маркетплейсы тысячи своих товаров. Весь процесс предельно автоматизирован. Выполнить подобный объём работы руками практически нереально. Либо понадобится очень много специалистов, времени и денег, что, как я уже сказал, нереально.

И вот, собственно, проблема, с которой к нам пришла эта компания: в ней фактически отсутствовала коммуникация между департаментом IT и всеми остальными. Департамент IT состоял из двух отделов, назовём их Поддержка и Разработка. Первые как раз занимались тем, что устраняли различные сбои на внедрённых IT-системах и прочей рутиной. Про вторых же достаточно сказать, что вышеупомянутые мной интеграции в маркетплейсы – фактически собственные разработки компании. И таких систем у них настолько много, что мы на одно только составление схемы корпоративной информационной системы (КИС) потратили около месяца. То есть у них без преувеличения был очень серьёзный IT-ландшафт, который создавали профессионалы из отдела Разработки.

Но при этом постановка задач выглядела примерно таким образом: прибегает менеджер с криком: «Теперь торгуем на «Маркетплейсе Name», — и все начинают торговать там. Каким образом, почему интеграция с этим маркетплейсом выстроена именно так — решается в процессе. Иногда даже, когда процесс уже год как худо-бедно шевелится. Более того, периодически все забывали, как сделали эту интеграцию, аккаунты оказывались привязаны не к компании, а к сотруднику, который, уходя, спокойно забирал рабочие аккаунты с собой или просто отказывался отдавать пароли. Компания жила, как живётся, каждый делал то, что мог, и до определённого времени это всех устраивало. Но, согласно статистике, причиной закрытия бизнеса часто становятся не кризис или падение спроса, а рост компании. Вот и наши клиенты доросли до такого размера, когда пора бы уже звать бизнес-спецназ Амивео или идти по миру.

Ну, и самое главное. Поскольку компания изрядно разрослась, её учредители приняли стратегию увеличения количества продаж. Да настолько серьёзного увеличения, что старая IT-система не выдерживала. Фактически к нашему приходу она уже не работала и требовала вмешательства со стороны, чтобы наладить деятельность не только IT-департамента, но и взаимодействие его с остальными департаментами компании. На айтишников постоянно сыпались жалобы. Мол, делают долго, делают не то, а то, что надо – не делают. Всё это перерастало в некрасивую ругань между сотрудниками разных департаментов, которая постепенно выходила даже на уровень учредителей, каждый из которых курировал своё направление деятельности компании. Один учредитель курировал департамент по работе с партнёрами, т. е. людей, которые ищут новые бренды шуруповёртов и дрелей, и заключают с ними договор на сбыт их продукции. Этот же департамент отвечал за взаимодействие с маркетплейсами. Другой учредитель отвечал за складскую деятельность. Третий за учёт и логистику. И так далее. И был ещё один учредитель, который, собственно, и позвал на помощь бизнес-спецназ Амивео. Он то как раз и занимался IT-департаментом.

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

Мы начали с создания каталога конфигурационных единиц. Если простыми словами, то конфигурационная единица — это любой компонент, который нуждается в управлении для предоставления ИТ-услуг. То есть конфигурационной единицей может быть программа или техника, подведомственные IT-департаменту. Если конфигурационная единица находится в ведомстве отдела поддержки IT-департамента, значит, на неё мы можем принять ошибку и признать, что она (ошибка) все-таки есть. И мы будем её исправлять. Для чего это нужно? А для того, чтобы айтишники не занимались решением вопросов с компьютерными креслами только потому, что «они же компьютерные». Это не задача айтишников и даже не их сфера деятельности. Ещё проще: каталог конфигурационных единиц — это список того, за что мы отвечаем.

Все конфигурационные единицы мы разделили на три большие группы. Вот такие:

1. Mission critical – сбой на этой конфигурационной единице подразумевает, что нужно бросать всё, и все силы кидать на устранение этой ошибки.

2. Business critical – такие сбои неприятны, но не критичны. На их устранение мы отводим короткий, но разумный срок. Например, сутки.

3. Офисные системы – рутинные задачи, не особо влияющие на рабочий процесс. Решаются в спокойном режиме, в течение рабочей недели.

Для примера: если упала система приёма платежей, то это ошибка первой группы. Платежи от клиентов не проходят, компания теряет деньги. А вот система отчётности по этим платежам вполне может подождать до завтра, и это уже вторая группа ошибок. Если в офисе требуется обновить программу, эта заявка падает в третью группу. А если в принтере бумага закончилась – так это вообще не проблема IT-департамента.

Небольшое отступление. Когда мы только начали работать с каталогом, мы задали вопрос: сколько у вас конфигурационных единиц? Чтобы хотя бы примерно представлять, с чем мы дело имеем. Навскидку нам озвучили 50 единиц. А после нашего подсчёта выяснилось, что единиц на самом деле… 250. В пять раз больше! А я не устаю повторять: вы не управляете тем, что не учитываете. В ходе поверки, кстати, всплыли вовсе абсурдные вещи, к примеру, выяснилось, что на IT-департамент навешивали даже замену лампочек!

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

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

Следующим шагом мы определили информационные системы, через которые мы принимаем заявки и заводим их на IT-департамент. Потому что раньше заявки принимались как бог на душу положит. Хорошо, если через письма, хоть какая-то фиксация. Но чаще из одного отдела звонили в другой, там кому-то задачу делегировали и в какой-то момент она даже исполнялась. Возможно. Тут нам пришлось натурально создавать специальный совещательный орган, через который все остальные департаменты станут взаимодействовать с IT-специалистами. Мы внедрили в процесс так называемый CAB или Change Advisory Board. Грубо говоря, это совещательный орган, включающий специалистов IT-профиля и специалистов, занимающихся продажами. Впервые в компании спецы разных департаментов начали общаться за одним столом, лицом к лицу. Сразу начался конструктив. Люди стали меньше времени тратить на перекладывание ответственности и ругань-поливание коллег грязью, и больше – на решение конкретной задачи.

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

Запросы, которые поступали в IT-департамент, мы разделили на две большие группы: Инцидент и Изменение. Нам пришлось отрисовать процесс управления заявками по обеим группам. На каждую группу мы составили объёмный регламентирующий документ. В них всё было расписано досконально: как работает, на кого отправляется заявка, в какие сроки, с каким приоритетом и какими ресурсами они решаются etc.

И вот, что у нас получилось, если взять выжимку и опустить детали.

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

2. Изменение – не требует мгновенного вмешательства. Назревает постепенно и вводится при необходимости. Это спокойная и вдумчивая работа отдела Разработки.

И вот, исходя уже из этой точки, мы смогли разработать KPI и систему поощрений для сотрудников. Потому что неплохо, когда ты чётко понимаешь свои обязанности, но ещё лучше, когда за их своевременное выполнение получаешь премию. Более того, KPI рассчитывался автоматически, исходя из сложности заявок и скорости их закрытия. На эту систему расчётов уже невозможно было повлиять извне, приписать специалисту какие-то несуществующие заслуги, или наоборот, «забыть» о каких-то решённых задачах, чтобы сэкономить на премии. Я уже писал ранее про важность KPI на примере нашей работы с «Берёзкой» и БигБеном. Когда есть чёткий и понятный расчёт, сотрудник не просто видит, из чего складывается его зарплата, почему ему выплатили именно такую премию, но и понимает, что добросовестный труд поощряется и не ищет, куда бы сбежать. Таким образом решается ещё одна важная проблема – отток профессиональных кадров, желающих работать и зарабатывать.

Снова пример: Инцидент, который проходит с приоритетом Mission critical, описанный ранее, по регламенту должен быть исправлен в течение 8 часов. И KPI напрямую привязан к тому, успели сотрудники выполнить заявку в срок или нет. Причём сроки эти брались не с потолка, а были продуктом кропотливой аналитической работы и согласования СО ВСЕМИ отделами компании.

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

Что сделали мы? Устроили прямо внутри компании эдакую «кузницу кадров». Если попросту, то мы разделили запросы, приходящие в Поддержку, на три части или, как мы их назвали, линии. Запросы из них попадали к специалистам, которые так и назывались – специалист такой-то линии. Идея, на первый взгляд, простая, аналогичной системой пользуется, к примеру, один зелёный банк, но пока не пришли мы, на предприятии до неё никто не додумался.

Покажу развёрнуто: итак, ВСЕ заведённые запросы ВСЕГДА попадают к специалистам первой линии. Это не самые компетентные сотрудники, но ряд вопросов они решить в состоянии. Их функция – этакий буфер, которым они служат, чтобы не отвлекать мелочами действительно опытного сотрудника. На этой линии мы убрали разделение по системам, тут у нас работали специалисты максимально широкого профиля. Специалист первой линии самостоятельно закрывает тот участок работы, который в состоянии решить. И только если он получает задачу, с которой справиться НЕ МОЖЕТ, тогда он переводит её на специалиста второй линии поддержки, где уже сидят серьёзные инженеры. Ну и таким же образом задачи попадают на третью линию. Туда приходят задачи, которые не сумели решить на двух первых линиях поддержки. Третья линия — отдел Разработки, и здесь работают уже практически боги от IT, отвлекать которых можно только по очень серьёзным вопросам.

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

Кроме того, мы создали реестр компетенций сотрудников, который в дальнейшем превратился в хороший рабочий инструмент для руководителей. В реестре видно, какими компетенциями обладает каждый из сотрудников и в какой сфере их можно развивать. Заглядывает руководитель в реестр и видит: вот специалист А, умеет работать с Otto Market и с такой-то программой. Потенциально способен вести ещё и Zalando, где как раз не хватает человека. Но для этого сотруднику не помешало бы пройти курсы. И вот после прохождения этих курсов у руководителя появляется специалист более широкого профиля, а у самого специалиста повышается заработная плата. Так с помощью реестра руководители могут развивать рабочий коллектив и обучать нужных компании специалистов.

Над этой интересной, но не простой задачей мы работали четыре месяца. Планомерно, спокойно, неторопливо. И, как итог – эффективно.

Эффект от деятельности бизнес-спецназа Амивео начал проявляться мгновенно, ещё до окончания нашей работы:

Ну и напоследок — фрагмент из наших аналитических материалов, наглядно демонстрирующий, как стали распределяться заявки по приоритетам и линиям, и насколько всего за пару месяцев выросли показатели по исполнению заявок. При ожидаемых 80% все линии показали результат не ниже 91%!

Ну и в завершение истории. Описанная выше методика – не наше изобретение. Думаю, читатели, имеющие опыт в IT сразу поняли, что мы внедряли ITIL. Мы брали практики ITIL по управления услугами и адаптировали их под конкретного заказчика, решая именно те проблемы, которые существовали в этой компании. И это очень важно, ведь ITIL говорит, что делать, но не говорит – как делать. Из 17 практик управления услугами мы взяли 3. И внедрили их именно на том уровне, на котором заказчик не только сможет с ними работать, но и получит видимый результат. Когда компания вырастет ещё в 2 раза (а у меня нет сомнений, что так и будет), подход к управлению услугами придётся снова пересматривать и улучшать.

Кстати, возможно, и в вашей компании похожая система применяется и вы уже её часть. Или могла бы применяться. Интересен взгляд со стороны. Так что всех заинтересованных приглашаю к обсуждению!