ИТ: и в хозяйстве пригодится

Расскажу вам историю трансформации Service Desk-подразделения в Enterprise Service Management-подразделение и поделюсь опытом решения проблем, которые возникли в ходе этой трансформации.

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

Не буду говорить про сертификаты, дипломы и прочие профессиональные ачивки.

Хочу сказать, что в ИТ я давно. Все началось с замечательной книги – «Энциклопедия профессора Фортрана». Это первая ИТ-литература, которую мне в детстве подарили родители. Она мне так понравилось, что после этого я стал изучать математику и программирование.

Я долго программировал, занимался развитием ИТ-поддержки и внедрял в бизнесе различные решения.

До сих пор не могу остановиться и найти выход из ИТ – пришлось приехать сюда и рассказать об этом.

О проекте

Начнем с компании, в которой я работаю.

Центральный офис группы компаний «Доброфлот» находится во Владивостоке. Мы занимаемся всем, что связано с рыбой: вылов, перевозка, хранение, переработка, консервирование. Также у нас есть судоремонтный завод, производство орудий улова и жестяных банок. Еще у нас есть учебно-тренажерный центр для рыбаков.

Мы постоянно расширяемся, что-то покупаем и строим: заводы, склады, суда и офисы.

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

В ИТ-отделе порядка 60 сотрудников, из которых 15 задействованы напрямую в техподдержке – занимаются тем, что оказывают консультации и решают инциденты, которые возникают в ходе работы.

У нас классическая организационная структура в ИТ. Во главе всего стоит ИТ-директор, которому подчиняется несколько подразделений:

• Разработка

• Поддержка

• Системное администрирование и связь

• Информационная безопасность

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

С таким разнообразным ИТ-ландшафтом нам нужно поддерживать как пользователей, так и сами бизнес-системы.

У нас классическая схема обработки обращений с разбивкой по линиям и классификацией обращений согласно каталогу ИТ-услуг:

• пользователь обращается на первую линию в единый центр обращений;

• обращение регистрируется и решается;

• если обращение не могут решить, его эскалируют на вторую линию;

• на второй линии происходит то же самое, кроме регистрации;

• если нет прав доступа или каких-то полномочий, вторая линия эскалирует на третью линию;

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

При этом у нас довольно высокая степень регламентации ИТ-процессов в компании: процессы измеряются, считаются различные KPI и метрики, ИТ-услуги предоставляются, инциденты решаются, удовлетворенность собирается. В общем все здорово.

С какими проблемами мы столкнулись при предоставлении услуг

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

Оказание услуг происходит хаотично и ситуативно:

• что-то теряется;

• что-то выполняется слишком долго;

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

Самые очевидные внутренние услуги:

• административные услуги – заказ печати штампов, перевод документов, отправка посылок и другие услуги, которые оказывают офис-менеджеры;

• кадровые услуги – заказ справок, копии трудовых книг и так далее;

• ИТ-услуги;

• бухгалтерские услуги – заказ справок 2-НДФЛ, выписки из реестра, заказ пакетов документов;

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

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

Проблема №1 – множество исполнителей

Первая проблема возникает из-за отсутствия информации о том, к кому конкретно нужно обращаться по тем или иным вопросам.

Например, у сотрудника есть потребность заказать справку для ипотеки. Он делает звонок условной Зине из отдела кадров: «Сделай мне, пожалуйста, справку». На что Зина ему отвечает: «Я такие справки не делаю, обратись к Тамаре из бухгалтерии». Наш герой идет к Тамаре, и она ему говорит то же самое: «Иди к Зине, она ошиблась, я не делаю справок».

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

Проблема №2 – «пинг-понг» обращений

Проблема «пинг-понга» касается общения между сотрудниками одного или нескольких подразделений.

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

Проблема №3 – отсутствие контроля над обращениями

Следующая проблема – отсутствие контроля над обращениями. Причем отсутствие с двух сторон, как со стороны заказчиков услуг, так и со стороны руководителей исполнителей.

• Заказчик услуги может не знать, когда ему окажут его услугу.

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

Потому что в этом случае заказчик начинает долбить руководителя исполнителя – звонить и спрашивать, условно: «Когда же починят мое рабочее место?». Так тоже быть не должно.

Проблема №4 – отсутствие регламентации процессов

Еще одна интересная проблема – отсутствие регламентации процессов.

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

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

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

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

Проблема №5 – отсутствие измерений и показателей

Следующая проблема – не определены методики измерения и KPI. Если у нас не измеряется оказание услуг, мы не понимаем, насколько качественно оказываем услуги и есть ли у нас какая-нибудь своевременность.

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

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

С этим клубком надо было что-то делать. Я подумал, чем же могу быть полезен со своим ITSM-опытом для компании? Как я могу помочь компании, чтобы услуги оказывались правильно по обозначенным проблемам?

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

Как мы нашли решение проблем

Я начал думать, чем же конкретно могу быть полезен в решении этих проблем.

Самое первое, что мне пришло в голову, – взять опыт нашего ИТ-подразделения и применить его на всю компанию:

• сформировать каталоги услуг;

• назначить владельцев и исполнителей;

• назначить границы и время выполнения услуг;

• определить процесс обработки обращений по этим услугам;

• все это автоматизировать и активно пиарить в компании.

Пока я размышлял об идеальном мире, где все получают идеальные услуги, я вспомнил, что у западных коллег и в России уже есть успешный опыт применения принципов ITSM вне ИТ – этот подход называется ESM (Enterprise Service Management).

Идея ESM заключается в том, чтобы применять ITSM и в целом ИТ-подходы для бизнес-функций, которые не имеют отношения к ИТ. Это как раз то, что нам и было нужно.

Чтобы начать применять ESM у себя в компании, мы должны были принять следующие принципы:

• Что все сотрудники компании – это клиенты. Они могут обращаться в единый центр для получения услуги с гарантированным сроком выполнения и гарантированным качеством. Также они должны в принципе знать, какие услуги оказывает компания внутри.

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

• Также мы должны были научиться управлять запросами на обслуживание и инцидентами в рамках ESM.

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

• Кроме этого, нужно было выставить для каждой услуги KPI и научиться все это считать.

Как мы запустили проект трансформации SD в ESM

Чтобы организовать такое масштабное изменение в крупной компании, мне нужно было упаковать проект ESM в проект с уставом, целями, обещаниями и гарантированными результатами.

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

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

Суть проекта заключалась в том, что:

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

• В единый центр нужно было передать функции координации измерения и управления услугами.

При этом на первых порах нужно было охватить наиболее популярные услуги и определить цели. Мной были определены операционные цели:

• оптимизация рабочего времени;

• унификация и стандартизация бизнес-процессов;

• повышение удовлетворенности.

Эти операционные цели были сопоставлены со стратегической целью компании – снижение неэффективных временных затрат.

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

План проекта по трансформации подразделения SD в ESM почти не отличался от плана проекта по организации Service Desk, который я и моя команда уже реализовывали два года назад в ГК «Доброфлот». Мы взяли полученный опыт и применили его к новому проекту.

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

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

Какие проблемы были при запуске проекта

Проект спланирован, ресурсы выделены, одобрение начальства есть, – можно работать. Казалось бы, что может пойти не так?

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

Исторически сложилось, что в компании основная система для исполнения процессов – это «1С: Документооборот».

Но весь ИТ-отдел работает в Creatio – мы в ней решаем инциденты, работаем с запросами на обслуживание, вводим туда все изменения.

Мы прикинули, что добавить новых исполнителей в Creatio будет очень сложно, потому что сервисных подразделений много – во-первых, нужно купить лицензии; во-вторых, нужно потратить время на обучение. И решили собственными силами сделать интеграцию между Creatio и 1С:Документооборот.

На практике для пользователя это выглядит так:

1. Пользователь обращается в единый центр – например, запрашивает справку 2-НДФЛ.

2. Запрос регистрируется диспетчером в Creatio.

3. Поскольку справка 2-НДФЛ классифицируется как «не ИТ-услуга», запрос направляется в 1С:ДО, где в зависимости от услуги запускается процесс по шаблону на определенную роль – в данном примере, на роль расчетчика зарплаты,

4. Расчетчик зарплаты работает в 1С:ДО и получает задачу там. Когда он выполняет задачу в «1С:ДО», обращение в Creatio также закрывается, а пользователю отправляется решение.

5. Для пользователя вообще ничего не поменялось, он не понимает, где происходит решение проблемы, главное – ему пришло сообщение: «Ваша справка готова. Заберите ее на стойке офис-менеджера».

6. Если пользователь запрашивает ИТ-услугу, она целиком обрабатывается в Creatio.

7. Диспетчер может контролировать в Creatio все обращения вне зависимости от их типа и видеть статус выполнения.

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

Следующая проблема при реализации – двойное и подробное описание услуг.

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

• Первое описание – очень краткое и понятное, отвечающее на вопрос «что вы получите, если закажите эту услугу». Это описание адресовано потребителям услуги, оно размещается на портале самообслуживания и в документации.

• Второе описание – сложное и детальное для исполнителей по услуге, что и как делать, с каким сроком и так далее.

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

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

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

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

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

Причиной саботажа и сопротивления сотрудников стала прозрачность.

До запуска они все делали, а тут появился какой-то процесс с четкими сроками, в которые нужно уложиться.

Например, оказалось, справка с места работы должна быть сделана не в течение дня, а в течение 10-15 минут. Раньше рабочий с производства мог приехать за справкой в офис, а его отправляли обратно – т.к. специалиста нет на месте, или он занят и просит зайти позже.

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

Инструменты реализации

В рамках реализации проектов применялись следующие инструменты и методологии:

• ITIL – это основная ITSM-методология;

• ESM – опыт других компаний;

• BPMN – методология описания бизнес процессов;

• Классический РМ (Project Management) для управления самим проектом;

• 1С:Документооборот и Creatio для автоматизации процессов;

• Microsoft Power BI для снятия аналитики по процессам.

• Кроме этого, мы много занимались внутренним маркетингом. Например, сделали QR-коды и развесили их по офису, чтобы сотрудники могли заказать услугу по коду, находясь в курилке – чтобы не нужно было идти в офис с производства. Еще сработало какое-то сарафанное радио, конкурсы пользователей на портале, новости.

Результаты проекта

Несмотря на все проблемы, которые были связаны с первой волной коронавируса в 2020 году, проект был реализован и закрыт вовремя.

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

Теперь у нас для этого есть регламенты и средства для автоматизации – все это уже наработано и работает очень даже неплохо.

Мы поделились результатами этого проекта с сообществом itSMF Russia – это сообщество профессионалов ITSM. Мы приняли участие в конкурсе «Проект года 2020-2021» и выиграли в номинации «ITSM своими руками». Это номинация для проектов по реализации принципов ITSM, которые были выполнены самостоятельно без привлечения интеграторов, вендоров, консультантов.

Не стыдно даже было поделиться результатами.

В начале доклада я говорил, что перед и после реализации проекта мы проводили опросы. Сейчас покажу реальные и честные цифры, которые мы получили.

Скорость и качество. Перед запуском проекта я пообещал бизнесу, что мы повысим удовлетворенность по внутренним услугам. Поскольку удовлетворенность по не ИТ-услугам до этого не измерялась, мы провели опросы до и после проекта, и получилось так, что формально мы даже немного повысили удовлетворенность.

Цифры оценки качества выглядят смешными – рост всего на 0.07%. Но позже, когда я пообщался с людьми, которые делали похожие проекты у себя в компании, оказалось, что реальные цифры у них упали. Получается, мы достигли отличного результата.

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

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

• Почти 73% опрошенных сказали: «Конечно доступны. Один клик мыши и услуга уже заказана».

• 26% сотрудников сказали: «Всё нормально, но пришлось приложить какие-то усилия».

• Только 1% сказал, что все ужасно и ничего не понятно.

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

Простота получения услуг. Мы спросили у пользователей о простоте получения услуг с помощью ESM.

• 88% респондентов считают, что стало проще и легче получать услуги.

• Почти 12% сказали, что в принципе все нормально.

• Не было ни одного человека, который сказал, что все плохо.

Нам все равно стоит направить силы на выяснение причин, почему мы не захватили 100% и сделать корректировки. Ранее я озвучивал возможные причины снижения этого процента.

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

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

• Чуть меньше людей знали, какие вообще подразделения оказывают услуги через ЕЦО. Допустим, не все знали, что через единый центр обращений можно заказать справку от отдела кадров.

• И около 22% сотрудников вообще не знали, какие услуги можно заказать через единый центр обращений.

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

Соотношение. По итогам 2020-го года мы посмотрели в процентном соотношении, какие услуги мы обрабатываем.

• В основном это ИТ-услуги.

• Примерно четверть услуг предоставляется другими подразделениями.

Еще много услуг, которые не покрыты нашими процессами. Есть еще, что регламентировать и автоматизировать – оцифровать.

Планы

Перечислю планы по итогам проекта и по личным ощущениям. Нам нужно:

• больше автоматизировать рутину, сокращать человеко-часы на обработку обращений;

• сделать услуги доступнее, судя по опросам;

• минимизировать усилия, которые прилагаются в комплексных услугах;

• расширить наши каталоги;

• расширить географию, потому что офисы есть во многих городах России, и не везде все услуги работают;

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

Выводы

Как показала практика, сервисный подход к управлению не ИТ-услугами работает, но:

• Внедрение ESM-подхода требует ресурсов. Чтобы получить эти ресурсы, важно объяснить бизнесу, какую ценность это принесет. Если мы скажем бизнесу: «Мы сейчас все упакуем, будет здорово и красиво», это неправильно. Нужно донести ценность, которая будет на выходе подобных трансформаций, и объяснить, что снизится, а что повысится. И желательно в цифрах.

• Наш опыт показывает, что позитивные изменения одномоментно не настанут – должно пройти какое-то время.

• Обязательно нужно заниматься рекламой услуг.

• Нужно быть готовым к тому, что возникнут трудности. Если у кого-то есть планы по автоматизации чего-то подобного, хочу пожелать, чтобы вы держались и крепились – это все довольно сложно. Даже если мы берем ИТ-подразделение и занимаемся внутри только ИТ-услугами, это тоже сложно. Это тоже требует ресурсов и времени. А здесь мы говорим о всей компании, в которой до этого часть подразделений не оцифровали свои услуги. Нужно им донести ценность. Нужно понимать, что мы находимся в крупной компании. Мы не можем все поставить на паузу и сказать: «Давайте мы полгода не будем работать, все сейчас настроим и поедем дальше».

Практика подтверждает, что ITSM-методологии применимы вообще к любым услугам.

Важно понимать, что является услугой, а что не является услугой. Тогда все получится.

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

Больше статей можно прочитать здесь.