Если коротко
Процессное управление проваливается не из-за того, что выбрали не тот свод. Оно проваливается, когда начинают с регламента. Регламент, написанный первым, описывает работу, которой ещё нет, — и остаётся единственным местом, где она существует.
Порядок ниже устроен наоборот. Регламент здесь одиннадцатый шаг: сначала новый порядок живёт на одной команде и показывает, что работает, и только потом это записывают.
Первые шесть шагов не требуют ни бюджета, ни закупок, ни согласований. Если после них станет заметно легче — продолжайте. Если нет, дальше идти незачем, и это тоже результат.
Этап первый. Подготовка
Здесь ничего не меняется в работе. Здесь выясняется, что менять.
Шаг 1 · без бюджетаНазовите, зачем
Прежде чем выбирать практику, ответьте, что должно измениться в работе компании.
Ответ должен звучать на языке бизнеса, а не процессов. «Заявки станут закрываться быстрее» — это про ИТ. «Магазин не встанет на полдня из-за кассы» — про компанию.
Проверка. Закончите фразу «через полгода в компании перестанут…» или «…начнут…». Получается закончить только словами про ИТ — цели пока нет, есть намерение навести порядок у себя.
Шаг 2 · без бюджетаВыберите одну практику. Одну
Цель есть — теперь выберите, чем её достигать. Взяться сразу за инциденты, изменения, проблемы и каталог услуг — самая частая ошибка. Через два месяца не сдвинется ничего: внимание размазано, а сопротивление сложилось.
Выбирают по двум признакам сразу: где чаще всего болит и что легче всего изменить, чтобы достичь цели. Практика, где болит, но с целью не связана, даст улучшение, которого никто не ждал; практика, связанная с целью, но безболезненная, не найдёт себе сторонников.
- Признак правильного выбора: вы можете в одно предложение объяснить, как эта практика двигает цель из первого шага.
- Признак неправильного: практику выбрали потому, что она первая в оглавлении ITIL.
Шаг 3 · без бюджетаОпишите, как есть. Не как надо
Прежде чем проектировать целевой процесс, зафиксируйте фактический — со всеми обходными путями, звонками напрямую и заявками в мессенджере. На одной странице, схемой или списком шагов.
Страница выйдет неприятная. Она же самая полезная: почти всегда выясняется, что процесс не один, а два-три параллельных, и люди из разных подразделений описывают его по-разному.
Если два человека описали один и тот же процесс по-разному — это не ошибка описания. Это и есть ваша находка.
Шаг 4 · без бюджетаНазначьте владельца
Практика без ответственного не улучшается сама, сколько её ни измеряй. Владелец — не тот, кто выполняет работу, а тот, кто отвечает за то, как она устроена, и имеет право менять правила.
Проверка простая. Спросите трёх человек, кто отвечает за управление инцидентами. Назвали троих разных или пожали плечами — владельца нет, что бы ни было написано в положении о подразделении.
- У владельца должно быть выделенное время на эту роль, иначе она превращается в приписку к должности.
- Один человек не может быть владельцем более трёх-четырёх практик — дальше начинается имитация.
Шаг 5 · без бюджетаСоберите, что болит
Сядьте с теми, кто в процессе работает, и выпишите, что не устраивает. Не «как должно быть по науке», а что мешает сегодня.
Здесь же обычно рождается метрика. Жалоба «заявки висят неделями» превращается в срок исполнения, «одно и то же спрашивают по десять раз» — в долю повторных обращений. Метрика, выросшая из жалобы, потом не требует объяснений: все помнят, откуда она.
Проверка. Боль записана словами того, кто её чувствует, а не переведена на язык процессов.
Шаг 6 · без бюджетаИзмерьте, где вы сейчас
Свод называет это отправной точкой и предупреждает: маршрут нельзя проложить, не зная, откуда идёшь. Без замера до изменений вы потом не докажете, что стало лучше, — ни другим, ни себе.
Измерить получается не всегда, и это нормально. Но если получается, цифра до изменений стоит дороже любых доводов: она единственная, которую нельзя оспорить задним числом.
- Считать по тому, что уже есть: выгрузка из системы, журнал обращений, переписка.
- Один-два показателя, не двенадцать. Один из них — тот, что вырос из жалобы на прошлом шаге.
Этап второй. Проверка на одной команде
Здесь новый порядок появляется — но не везде, а в одном месте, где его не страшно поправить.
Шаг 7Определите фактор успеха
Вы знаете, где находитесь. Теперь скажите, где хотите оказаться и к какому сроку. Цель должна быть измеримой и иметь конечную дату. И ещё: цель — это движение к замыслу, а не его полное достижение. Улучшение, а не совершенство.
Заодно назовите признак провала. Не «если станет хуже», а конкретно: при каком результате вы честно скажете, что затея не сработала.
Зачем это до пилота, а не после. Пропустите — и судить о результате будет нечем. Спор о том, получилось или нет, выиграет тот, кто громче.
Шаг 8Закрепите базовые правила
Продумайте, что должно работать по-другому, и запишите. Коротко и без красот: базовые принципы и то, что меняется. Это ещё не регламент — это памятка, по которой команда сможет работать завтра.
Хороший объём — страница. Если получилось больше, вы описываете не изменение, а всё подряд.
Шаг 9Возьмите одну команду
Если команд много, начинать со всех нельзя. Возьмите одну, расскажите замысел, предложите поработать по-новому, обучите правилам и дайте базовые инструкции.
Команду выбирайте не самую удобную, а ту, где боль из шага пятого чувствуется сильнее всего. Пилот на равнодушных ничего не покажет.
- Скажите вслух, что это пилот и что правила будут меняться. Иначе первое же неудобство прочитают как «нам опять спустили сверху».
- Договоритесь, кто и как быстро правит правила по ходу. Пилот, в котором нельзя ничего поправить, — не пилот, а внедрение.
Шаг 10Поживите по-новому
Дайте новому порядку поработать и смотрите, что получилось. В ходе пилота видно то, чего не видно в проектировании: что не заработало — убираем, что получилось — фиксируем как целевое состояние.
Свод отдельно предупреждает: не считайте, что раз план запущен, результат достигнут. Проверять надо и то, достигли ли цели, и то, осталась ли цель нужной.
Проверка. Сравните с цифрой из шага шестого. Сдвинулась в нужную сторону — идём дальше. Не сдвинулась — возвращаемся к шагу восьмому, а не пишем регламент поверх нерабочего порядка.
Этап третий. Закрепление
Здесь порядок, сработавший на одной команде, становится общим.
Шаг 11Опишите в регламенте и согласуйте
Только теперь. К этому моменту у вас есть работающий порядок, владелец, метрика и опыт одной команды. Регламент фиксирует то, что уже происходит, и нужен новым сотрудникам и проверяющим.
Написанный в этом порядке, он короткий. Написанный первым — длинный, красивый и мёртвый.
Согласовывать надо со всеми, кого он касается, а не только с ИТ. Заинтересованная сторона, узнавшая о регламенте после его утверждения, становится источником сопротивления надолго.
Шаг 12Обучите всех и масштабируйте
Обучите тех, кто должен работать по-новому, и переводите команды последовательно — не все разом. У каждой следующей найдётся своя особенность, и разбираться с ними по очереди дешевле, чем со всеми сразу.
Опыт первой команды здесь ценнее любой инструкции: люди, которые уже поработали по-новому, объясняют коллегам убедительнее, чем документ.
Шаг 13Добейтесь устойчивого результата
Последний шаг пропускают чаще остальных. Если не закрепить новый порядок, улучшения останутся единичными, достигнутое со временем потеряется, а поддержку следующих начинаний получить будет труднее.
Что закрепляет на практике:
Если результат не получился, это тоже надо назвать вслух: что не сработало и что сделаем иначе в следующий заход. Свод считает такую открытость условием того, что следующая попытка вообще состоится.
- Регулярный разбор. Показатель, который считается, но не обсуждается, перестаёт считаться примерно через квартал.
- Разговор об успехе. Расскажите, что получилось, и назовите тех, кто это сделал. Следующее изменение продавать будет легче.
- Новичок как проверка. Человек, пришедший через полгода, должен разобраться по документу, а не по рассказам коллег.
Чего делать не надо
- Не начинайте с покупки инструмента. Инструмент закрепляет тот порядок, который есть; если порядка нет, он закрепит беспорядок и сделает его дороже.
- Не описывайте сразу все практики. Каталог из тридцати описанных и ни одного работающего процесса — распространённый результат такого захода.
- Не назначайте владельцем того, у кого нет полномочий менять правила. Это гарантированный тупик через два месяца.
- Не вводите метрики, за которые наказывают. Их начнут улучшать напрямую, минуя работу, и вы потеряете и метрику, и доверие.
- Не пишите регламент до пилота. Документ, согласованный до того, как порядок проверили в работе, потом никто не решается менять — проще не соблюдать.
- Не ждите готовности организации. Она не наступит; наступает только момент, когда стало достаточно больно.
Как понять, что получилось
- Новый сотрудник разбирается в процессе по документу, а не по рассказам коллег.
- На вопрос «кто отвечает» все называют одного человека.
- Показатель из шага шестого сдвинулся в нужную сторону, и это видно по цифрам, а не по ощущениям.
- Правила меняются, когда меняется работа, а не раз в три года при пересогласовании.
Откуда этот порядок
Каркас этого подхода — модель постоянного улучшения ITIL 4, раздел 4.6 книги ITIL Foundation. Шаги про пилот и масштабирование опираются ещё и на практическое руководство ITIL по управлению организационными изменениями.
Разбивка на три этапа, проверки и признаки в шагах, раздел «чего делать не надо» — наши. В своде их нет.