Сервисный подход в бизнес информатике

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

Содержание

• 1 «Элементарно, Ватсон»
• 2 Всё в порядке?
• 3 Будущее не за горами
• 4 А оно нам надо? И кому нам?
• 5 А надо ли оно ИТ?
• 6 Что делаем
• 7 Не слышали? Расскажем
  • 7.1 Зачем рекламируем?
  • 7.2 Кто рекламирует?
  • 7.3 Как рекламировать?
• 8 «Это мы не проходили, это нам не задавали»
• 9 Мастер отчётов
• 10 Вместо заключения

«Элементарно, Ватсон»

Всё в порядке?

1. Обращаюсь в ИТ-службу из-за медленной работы компьютера и жду…
2. Моргает лампа над головой, звоню в АХО и жду…
3. Заказал справку в кадрах и жду…
4. Нужен акт сверки от бухгалтерии — снова жду…

К самому процессу ожидания можно относиться спокойно, но вместе с тем незнание, как долго оно продлится (потому что нет ни обратной связи, ни информации о текущем статусе поданной заявки), озадачивает.

Знакомо? Это НЕ порядок.

Пора наводить порядок, если:

• сокращение расходов и оптимизация штата — это уже не просто цель, записанная на бумаге;
• ремонтные и сервисные подразделения работают, как придётся, а из нареканий от сотрудников и клиентов можно опубликовать отдельную книгу;
• АХО работает, как местный ЖЭК, которого не дождёшься;
• бухгалтерские и кадровые службы долго готовят справки, выписки и другие документы;
• в компании накопились обращения, сервис и скорость выполнения по которым оставляет желать лучшего.

Будущее не за горами

Можно ли представить сегодняшний мир без мобильных приложений? Вероятно, ответ будет отрицательным. А ведь в недалеком прошлом ситуация была совершенно иная. Недавно вопрос использования сервисного подхода за рамками ИТ обсуждался с известным в ИТ-мире человеком, профессором, в прошлом руководителем крупной ИТ-компании. Он вспоминал, как в конце 90-х — начале 2000-х, все скептически относились к мобильным приложениям. Денег на разработку не выделяли. Считали, что это всё никому не нужно. По его мнению, аналогичная ситуация сейчас происходит и с сервисным подходом. Ещё не дозрели.

Но за этим будущее. Убеждён, только сервисно-ориентированная команда будет востребована в завтрашнем дне. Как внутри компаний, так и на внешнем рынке.

А оно нам надо? И кому нам?

Есть такая шутка: «Не бывает здоровых людей, бывают недообследованные». В точку. Другое дело, что мы на обследование не ходим. Так этим себе же хуже и делаем.

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

Сервисный подход часто предлагает способы решения этих проблем.

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

А надо ли оно ИТ?

В книге по ИТ-тематике «Проект „Феникс“. Роман о том, как DevOps меняет бизнес к лучшему» запомнилась цитата: «В последние 10 лет, как по часам, CIO сменялись каждые 2 года. CIO — мы расшифровывали как „career is over“, то есть „карьера закончилась“…».

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

Использование информационных систем класса service desk только для нужд ИТ — это как минимум нерационально. Это как быть владельцем автобусного парка и перевозить «воздух», много не заработаешь.

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

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

И это только укрупнённые заказчики. Внутри каждого «пассажира» — различные подразделения.

Из этого возникают 2 ключевых вопроса:

1. Где взять ресурсы?
2. Что конкретно делать?

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

В небольших компаниях — это или руководитель ИТ-отдела, или директор по ИТ. В компаниях покрупнее — свои ответственные. А в крупных холдингах — это либо целые отделы, либо департаменты. Это и есть ресурсы. Главное — правильно их мотивировать и использовать.

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

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

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

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

Что делаем

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

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

Не слышали? Расскажем

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

Зачем рекламируем?

Рекламировать ITSM, рассказывать о всех его «вкусняшках» надо бизнес-руководителям. А точнее — лицам, принимающим решения (ЛПР). Но также нельзя забывать о исполнителях, и о простых пользователях, ведь именно они становятся будущими рекламными «агентами» ИТ-продукта.

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

Кто рекламирует?

Внутренний лидер проекта. Главное — его уверенность в том, что внедряемые новшества работают. Плюс его опыт, основанный на конкретных кейсах.

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

Как рекламировать?

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

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

«Это мы не проходили, это нам не задавали»

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

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

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

Мастер отчётов

• Исходные данные.

Важный этап, который часто оставляют «на потом». И это большая ошибка.

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

• Цель.

Отчет — не просто «для информации». По его результатам должны быть действия.

• Инициатор.

Отчет не обезличен. У него должен быть конкретный заказчик.

• Правила.

Прописываем правила формирования отчета, а также, как и в каком режиме он формируется и показывается.

• Вид.

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

• Оповещения.

Часто заказчик забывает посмотреть отчет. Правильно настроенное оповещение в этом случае снимает проблему.

Вместо заключения

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