Радуга управления обращениями
На основе практического опыта сформировались «рецепты» того, что конкретно следует делать при создании систем управления обращениями. На мой взгляд, можно выделить семь основных шагов. Я представил их в виде радуги управления обращениями (рис. 3):
- реклама;
- поиск внутреннего заказчика;
- моделирование процессов;
- выбор инструмента;
- создание правильной атмосферы;
- обучение;
- отчётность.
Остановлюсь подробнее каждом из шагах.
Рис. 3. Семь шагов при создании систем управления обращениями – радуга управления обращениями.
Не слышали? Расскажем
Все мы знаем, какую роль играет реклама на старте продаж. Абсолютно такие же правила действуют при внесении изменений в различные бизнес-процессы.
Кому рекламируем? Рекламировать ITSM, рассказывать о всех его «вкусняшках» надо бизнес-руководителям, а точнее — лицам, принимающим решения. Но нельзя забывать и об исполнителях и простых пользователях, ведь именно они становятся будущими «рекламными агентами» ИТ-системы.
Пример из практики. Задача: изменить процесс управления обращениями по ремонту инженерной инфраструктуры. Вместо почты, телефона и устных обращений решили использовать имеющуюся систему класса Service Desk. Правильно проведённая рекламная кампания дала ожидаемые результаты. Инженеры, слесари и, конечно, их руководители быстро осознали всю полезность планируемых изменений и помогли объяснять заявителям, почему следует подавать заявку в системе Service Desk, а не старыми способами. Вскоре и пользователи «распробовали» новый продукт и понесли рекламу в массы, включив «сарафанное радио».
Кто рекламирует? Внутренний лидер проекта. Главное — он должен быть уверен в том, что внедряемые новшества работают, плюс его опыт, основанный на конкретных кейсах.
Пример из практики. Веду проект в крупном ритейле. Посещаю торговые точки, склады, общаюсь с непосредственными авторами будущих обращений, выясняю удобные для них способы подачи обращений. И при этом я делаю рекламу, будучи уверен, что новый процесс станет удобнее. Как именно? На реальных примерах из жизни: портал государственных услуг: помните, как раньше получали загранпаспорт или лицензию на оружие? А как сейчас? Лучше, удобнее? А главное быстрее! «Вот так же будет и с вашими обращениями», — резюмирую я. Сотрудники, конечно, сомневаются, что так и будет. Тогда я провожу дальнейшие разъяснения о регламентных сроках, ответственных, прозрачности процесса… И это действительно помогает убедить их.
Как рекламировать? Ответ прост: как позволяют внутренние правила компании, ваша собственная креативность и представленные возможности. Подойдут любые инструменты: презентация, почтовая рассылка, внутренняя газета, портал, личные встречи, общие собрания. Только придерживайтесь одного правила: внутри организации никому ничего не навязывать. Приводите правдивые аргументы, обещайте конкретный результат и старайтесь оправдывать ожидания клиента. По моему опыту там, где была проведена грамотная рекламная компания, проект ждали и он «взлетал». Там, где рекламы не было, возник первоначальный негатив и неуверенный старт проекта.
Ищем внутреннего заказчика
На мой взгляд, это важный этап. Мне нравится параллель с медициной: пойти к врачам на обследование нас заставляет только серьёзная проблема со здоровьем, профилактические осмотры мы игнорируем. Как говорится, пока гром не грянет… Похожая ситуация и со «здоровьем» многих бизнес-процессов. Даже если руководитель подразделения знает о проблемах, он не всегда будет об этом говорить и тем более обращаться к кому-то за помощью. Чаще он промолчит и будет «лечиться» самостоятельно. Поэтому попытки бизнеса провести обследование с помощью внутреннего или внешнего аудита, внедрения бережливого производства или ещё каких-то мер выявляют не все проблемы. Да и нацелены они часто совсем не на это.
И вот тут ИТ-руководитель может сыграть ключевую роль. Обладая знаниями об информационных системах, чётко понимая суть сервисного подхода, он должен хорошо видеть проблемы бизнеса, которые можно попытаться решить с помощью инструментов ITSM. Он с большей вероятностью, чем другие, знает, к кому обратиться, чтобы помочь. Подчёркиваю: обратиться, а не навязать какое-то решение.
Как говорить? Так, чтобы это не напоминало кулачный бой. Нельзя человека сразу, а ещё хуже прилюдно, огорошить информацией типа: «А я знаю, что у вас есть такая-то проблема. Хотите, я помогу вам её решить?» Эффект получится совершенно обратный. Искусству ведения беседы надо учиться, хотя овладеть им дано далеко не всем. Важно завладеть вниманием слушателя; если вас слушают с сонными лицами, то и результат будет такой же.
Где провести такую беседу? В народе говорят, что основные вопросы решаются в «курилке». Это образ, но надо понимать, что разговор лучше начинать в удобном для этого месте. Это может быть лифт, очередь в столовую, автобусная остановка — на месте виднее, где эти «курилки». Главное — не бояться подойти, начать разговор и вывести его в нужное русло. Фактически выяснить, что и где «болит».
Пример из практики. Разговор с главным бухгалтером:
— Коллега, знаю, что в ваш отдел поступает много заявок на подготовку актов сверки. Как удаётся вовремя справляться с таким объёмом?
(Заметьте: я спросил о проблеме абсолютно безобидно. Вопрос задан, теперь жду ответа.)
— Да, заявок очень много. Все люди заняты, но всё равно не успеваем.
(Вот он, момент! Пора предложить «лекарство».)
— А как вам идея попробовать подавать заявки на акты сверки через систему Service Desk?
Далее уже дело техники.
Алгоритм поиска внутреннего заказчика называют методом «пяти „П”» (рис. 4):
- подойти;
- поговорить;
- послушать;
- предложить (дать попробовать);
- продать (внедрить).
Рис. 4. Алгоритм поиска внутреннего заказчика методом «пяти „П”».
Моделируем процессы
Допустим, заказчик найден и проблема обозначена. Теперь важно оперативно и не сильно отвлекая заказчика смоделировать процесс и получить прообраз технического задания. На этом этапе необходимо общаться со всеми ключевыми участниками процесса.
Первый шаг перед моделированием — ознакомиться с процессом на месте. Ведя проект в крупной ритейловой компании, я самостоятельно посещал магазины и изучал процесс подачи заявок в ИТ. Потом анализировал процесс обработки заявок исполнителями. Только ознакомившись с процессом на месте, можно моделировать его на бумаге.
Моделирование начните с рисунков в стиле «вы рисуете, а заказчик правит». Представьте рассказы участников процесса в виде рисунков или схем, понятных каждому. Проработайте по ним все вопросы, и только затем перекладывайте в описание процессов.
Пример из практики. Идёт проект по автоматизации заявок на ремонт и техническое обслуживание автоматики оборудования. Объекты территориально распределённые, участников — исполнителей процесса — более 300 человек. На старте мы изучили рабочий день исполнителя: как он получает заявки, как докладывает о выполнении, пользуется ли компьютером или всё решает «в полях» по телефону. Потом поэтапно собирали ключевых сотрудников по объектам и с их слов рисовали схему процесса на маркерной доске. Учитывались все замечания и предложении, спорные вопросы фиксировались отдельно для принятия управленческого решения. В процессе такой дискуссии рисунок обретал вид схемы.
На основе этих рисунков описали процесс, подготовили и согласовали с заказчиком схему жизненного цикла заявок. При такой реализации участникам процесса гораздо проще понять сущность нововведений. Созданные вместе рисунки позволяли наглядно представить каждый шаг процесса в системе.
При правильной организации этот шаг даёт практически готовое техническое задание для внесения изменений. С помощью схемы и описания процесса в современных системах класса Service Desk можно легко и быстро создать новый функционал.
Выбираем инструмент
Не буду останавливаться на технических критериях выбора — на мой взгляд, важнее функциональные и психологические критерии. Здесь уместна аналогия с игрушками для детей. Если игрушка не понравится, ребёнок ни за что не будет в неё играть. Если система или инструмент неудобный, он не приживётся.
Учитываем и «возраст ребенка» — зрелость организации. Зачем использовать мощную систему Service Desk для решения простейших задач? Или наоборот: разве удобно будет в обычной почте выстроить процесс управления обращениями в крупном холдинге?
Теперь про функциональное назначение: необходимо чётко понимать, что будет происходить с этим инструментом и как он будет обслуживаться. Вам нужен «Мерседес» или «просто доехать»? Если именно «Мерседес», то есть ли ресурсы на его обслуживание и содержание? Бывает и такое: «Для чего вам нужен Service Desk? – Для управления программистами».
Не торопитесь с выбором мощной системы. Проанализируйте все аргументы «за» и «против». Возможно, достаточно простого облачного решения, а может, необходим целый проект с привлечением серьёзного подрядчика.
Создаём атмосферу в команде
Правильная атмосфера — тоже залог успешной реализации проекта. Говорят, если ты любишь то, что делаешь, ты, вроде как, и на работу не ходишь. Если не верить в своё дело, то как же приводить в восторг других? Лидер проекта незаменим, это генератор идей с чётким пониманием задач, готовый донести их до других. Именно он и создаст правильную атмосферу.
Мне в этом плане повезло: мне нравится то, что я делаю, и я чётко понимаю, что именно даст то или иное изменение для команды исполнителей. Остаётся правильно донести это до коллектива. Важно подготовить почву, но не переусердствовать и не навредить.
Пример из практики. Идёт проект внедрения управления ИТ-инцидентами в компании нефтегазового сектора. Среди исполнителей — инженер по связи, без пяти минут пенсионер. Он сразу сказал, что вполне «обходился без ваших сервис десков»… В то время в компании все ИТ-специалисты в конце недели заполняли в Excel «зеркало» рабочего дня — отчёт о своей занятости. От этого зависели их KPI и премия. Уже в период тестовой эксплуатации я предложил заменить отчёт данными из Service Desk. Заменили, и в результате у того инженера-связиста в отчёте о занятости было пусто. Его заявки, решённые в обход системы Service Desk, я назвал «калымом», за который премия не положена. Конечно, это была шутка, но цель была достигнута. На следующий день он уже объяснял пользователям, почему надо обязательно делать заявку именно в системе.
Поиск единомышленников необходим, и они всегда найдутся. Вовлекать в дискуссию приходится самых «строптивых», и часто ярые скептики становятся первыми помощниками.
Главное — нужно развеять страх. Как правило, люди убеждены: «Нас посчитают, потом скажут, что нас много, и скорее всего кого-то уволят». Если есть подобный страх, то надо пояснить, какие преимущества даст использование инструмента членам команды и заказчикам.
Обучение
Обучать необходимо как исполнителей, так и пользователей. Увы, это не всегда просто, особенно в крупной организации, где сотрудники находятся в удалённых точках, имеют разный уровень подготовки и работают по разным графикам.
Придётся задействовать весь арсенал: совмещать теорию с практикой, проводить обучение на реальной системе, комбинировать формы обучения (семинары, вебинары, тренинги непосредственно на рабочих местах). Важный момент: преподаватель должен знать специфику компании и конкретного процесса. Тогда обучение пройдёт гораздо эффективнее, а ответы на неудобные вопросы будут всегда под рукой.
Мастер отчётов
На вопрос: «Что можно будет получить в отчёте?» я всегда отвечаю заказчику: «То, что вы заведёте в систему». Поэтому уже на старте важно определить, какие данные нам понадобятся. При этом следует учитывать ряд параметров:
- цель: отчёт должен быть не просто «для информации», по его результатам должны быть предприняты действия;
- инициатор: отчёт не должен быть обезличен, у него должен быть конкретный заказчик;
- правила: прописываем правила формирования отчёта, а также то, как и в каком режиме он формируется и показывается;
- вид: диаграммы и графические отчёты нагляднее цифр, но всегда нужно быть готовым показать источник; заказчик вправе получить инструмент для проверки корректности отчёта;
- оповещения: часто заказчик забывает посмотреть отчёт, и правильно настроенное оповещение в этом случае снимет проблему.
* * *
В заключительной части статьи я поделюсь реальными примерами из своей практики, рассмотрю ситуации, где использовались системы класса Service Desk.
Чтобы оставить комментарий пожалуйста Авторизуйтесь