Вновь в фокусе идея применения сервисного подхода за рамками ИТ. Ранее уже анализировал:

зачем и кому это нужно;
когда пора наводить порядок;
как это сделать.

Сегодня остановлюсь на этапах, по которым успеваешь пройти на практике, пока внедряешь сервисный подход в процессы компании.

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

Пробегусь по оставшимся:

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

Ищем внутреннего заказчика

Что такое «поиск внутреннего заказчика»? На мой взгляд, это важный этап.

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

Похожая ситуация и со «здоровьем» многих бизнес-процессов. Даже если руководитель подразделения знает о проблемах, он не всегда об этом будет говорить. И тем более обращаться к кому-то за помощью. Чаще промолчит и «лечится» самостоятельно.

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

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

Более того, решать их можно точечно, по шагам, не принимая радикальных мер. Он с большей вероятностью, чем другие, знает, к кому обратиться, чтобы помочь. Подчеркиваю – обратиться, а не навязать какое-то решение. Нельзя человека сразу, а еще хуже прилюдно огорошить информацией типа: «А я знаю, что у вас есть такая-то проблема. Хотите, я помогу вам её решить?». Эффект получится совершенно обратный.

Как же поступить? Где попытаться провести такую беседу?

В народе говорят, что основные вопросы решаются «курилке». Но это же образ. Важно понимать, что разговор лучше начинать в удобном для этого месте. Это может быть лифт, очередь в столовую, на остановке. На месте виднее, где эти «курилки». Главное – не бояться подойти, начать разговор и вывести его в нужное русло. Фактически выяснить, что и где «болит».

Пример из практики. Разговор с главным бухгалтером. «Коллега, знаю, что в ваш отдел поступает много заявок на подготовку актов сверки. Как удаётся вовремя справляться с таким объёмом?».

Мы спросили о проблеме абсолютно безобидно. Вопрос задан – теперь ждём ответ.

«Да. Заявок очень много. Все люди заняты, но всё равно не успеваем».

Вот он момент. Пора предложить «лекарство».

«Предлагаю заявки на акты сверки подавать через систему service desk?».

Далее – дело техники.

Этот алгоритм поиска внутреннего заказчика называю методом «пяти П»:

Подойти.
Поговорить.
Послушать.
Предложить (дать попробовать).
Продать (внедрить).

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

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

Моделируем процессы

При правильной организации этот этап – практически готовое техническое задание для внесения изменений.

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

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

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

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

Исполнителям при такой реализации гораздо проще понять сущность нововведений. Созданные вместе рисунки позволяли сразу напоминать о каждом шаге процесса в системе.

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

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

Выбираем инструмент

Речь идёт не о технических критериях выбора и не о сравнении ТТХ различных программ. Акцент скорее на функциональной и психологической стороне вопроса.

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

Игрушки в разном возрасте разные: когда-то мягкие и пушистые, а когда-то уже большие и железные. Учитываем «возраст ребенка» – зрелость организации. Зачем использовать мощный service desk для решения простейших задач? Или наоборот. Разве удобно в обычной почте выстроить процесс управления обращениями в крупном холдинге?

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

Пример из практики.

«Для чего Вам нужен Service Desk?»

«Для управления программистами».

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

Создаём атмосферу в команде

Говорят, если ты любишь то, что делаешь, ты вроде, как и на работу не ходишь.

Если не верить в своё дело, то как же приводить в восторг других? Важен лидер проекта. Это генератор идей с чётким пониманием задач и готовностью донести их до других. Именно он и создаст правильную атмосферу.

Мне в этом плане повезло. Мне нравится то, что я делаю. И я чётко понимаю, что именно даст то или иное изменение для команды исполнителей. Остаётся правильно донести это до коллектива. Важно подготовить почву, но не переусердствовать. Не навредить.

Пример из практики. Проект внедрения управления инцидентами в ИТ в компании нефтегазового сектора. Среди исполнителей – инженер по связи, без пяти минут пенсионер. Он сразу сказал, что видел он «сервис деск в одном месте»… В то время в компании все айтишники в конце недели заполняли в Excel «зеркало» рабочего дня – отчёт о своей занятости. От этого зависели их KPI и премия. Уже в период тестовой эксплуатации я предложил заменить отчёт данными из service desk. В результате у инженера-связиста там было пусто. Его заявки, решенные «мимо кассы», я назвал «калымом». А за него премия не положена. Конечно, это была шутка. Но цель была достигнута. На следующий день уже он объяснял пользователям, почему надо обязательно делать заявку в системе.

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

Еще один момент – развеять страх. Как правило, люди считают так: «Нас посчитают, потом скажут, что нас много, и скорее всего кого-то уволят».

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

Подводим итоги

Завершить вторую часть статьи хочется не общими фразами, а реальной историей.

Звонок руководителя подразделения: «Дмитрий, говорят ваш service desk может решить почти любые вопросы. Нам очень нужна ваша помощь».

Я: «Кто говорит?».

Ответ: «Народ говорит».

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

Спрашиваю: «Чем могу помочь?».

Ответ: «Нужна автоматизация процесса управления обращениями определенного типа».

Тема пройдена уже не раз. Процесс реализации прост. Через 10 минут уточнения задачи, проверив текущую загрузку, говорю, что через 5 дней сможете тестировать. В трубке тишина.

Я: «Алло, вы тут?».

Ответ: «Вы шутите? Так быстро разве бывает?».

Я: «Бывает. Процесс похожий уже есть».

Через неделю запустили в работу. Благодарности были долгими. В народ пошла новая информация о «чуде».

Вот так и работаем. Интересно. С удовольствием. Доставляя заказчику маленькие радости и накапливая всё больше опыта в практике внедрения сервисного подхода. Этими кейсами и поделюсь в следующей статье.

Очевидное благо: как и зачем использовать сервисный подход за рамками ИТ (Часть 2)