«Сейчас выберем тот самый сервис деск и решим наши проблемы» — иногда кажется, что при внедрении нового решения или замене текущего именно так и рассуждают. Реальность готовит адептам этого подхода жесткую посадку. Мало подобрать систему под текущие потребности и учесть запас функций для роста — без аудита внутренних процессов старт затянется, а беспорядок не уйдет.
В статье расскажем, как не повторить распространенные ошибки и что нужно сделать перед запуском, чтобы не натягивать систему на неудачные паттерны.
Зачем нужен аудит до старта
Если коротко: без предварительного анализа процессы зависят от системы, хотя должно быть наоборот. Автоматизация должна помогать сотрудникам, а не ставить рамки. Например, прежде чем настраивать автоматическое назначение ответственности, нужно узнать, а кто в действительности за что отвечает.
Аудит процессов нужен не для галочки «мы все проверили». Он позволяет:
Понять, как реально работают люди. Сотрудники могут обрабатывать заявки совершенно по-разному, даже если существуют общие регламенты.
Выявить слабые стороны. На чем теряется время, дублируются ли данные, где ручную работу нужно заменить автоматизацией, а где — лучше оставить, как есть.
Определить точные требования к системе. Не абстрактное «настроить распределение заявок», а «нам нужна автоматическая маршрутизация заявок по командам с учетом типа оборудования и локации».
Если проанализировать все внутренние процессы еще на этапе выбора — шанс, что сервис деск быстро начнет приносить пользу, вырастает в разы.
Как правильно провести аудит
Чтобы автоматизация действительно упростила работу, важно заранее проанализировать ключевые аспекты. Вот на что стоит обратить внимание.
Роли: кто за что отвечает
Когда понятна ролевая модель — процессы ложатся на нее сами. Сразу становится ясно, какие права нужны каждой роли, какие процессы должны видеть те или иные сотрудники. Если роли не определить заранее — появятся дублирующие задачи и споры об ответственности.
Оптимально вначале добавить небольшое количество ролей с разграничением по процессам. Например, администратор всей системы, менеджеры процессов — заявок, изменений, базы знаний, плюс оператор поддержки и клиент. Затем дорабатывать ролевую модель по мере необходимости.
Процессы: что на самом деле делают сотрудники
Если не выяснить заранее, какими инструментами пользуются работники и где возникают проблемы, автоматизация просто зафиксирует существующие ошибки и не упростит работу. Также когда в компании меняют систему, не обязательно переносить процессы «как было». Не исключено, что в новом сервис деске их можно упростить.
Например: все привыкли к тому, что в прошлой системе были стандартные правила маршрутизации. Все заявки стекались в поддержку, где ответственные назначались вручную, что порой приводило к неравномерной загрузке. В новом service desk есть возможность настроить поочередное распределение заявок — так почему бы этим не воспользоваться.
Интеграции: с какими системами нужна связь
Интеграции — не дополнительный самостоятельный этап, а часть внедрения. Она обычно встроена в рабочие процессы. Например, есть процесс «оформили заявку → передали клиенту в доставку». В такой ситуации без интеграции с системой курьерской службы не обойтись.
Если учесть все интеграции заранее, подобрать подходящий сервис деск будет гораздо проще. Оптимальный вариант — система с готовыми интеграциями плюс открытый API для кастомных связок. Например, облачный сервис деск ITSM 365 предлагает 9 готовых интеграций и детальную документацию для настройки обмена данными практически с чем угодно: от 1С до самописного ПО.
Бизнес-ценность: станет ли процесс лучше
Система должна приносить конкретную пользу: заявки обрабатывают быстрее, ошибок делают меньше, процессы стали прозрачнее. Автоматизация ради автоматизации — путь в никуда. Перед тем, как добавить новое поле, нужно определить — зачем. Если нет реальной пользы — не стоит усложнять.
Представьте: клиент захотел настроить закрытие запросов на обслуживание только после того, как специально обученный сотрудник согласовал их выполнение. В итоге из-за большого количества согласований запросы постоянно зависали. Также часто вводят дополнительные промежуточные статусы для отслеживания работы. В итоге десять статусов вместо трех основных. Сотрудники забывают их менять, пользы ноль — только ад бюрократии.
Какие ошибки встречаются чаще всего
Даже если аудит провели, это не гарантирует отсутствие ошибок. Поделимся наблюдениями на этот счет.
Нет описанных процессов. Типичная ситуа��ия: придумали процессы работы в системе, но не описали их логику и удобство, не согласовали с сотрудниками, для которых они предназначены. Через несколько месяцев клиент сворачивает автоматизацию: «система непонятна, лучше без нее».
Ошибки с правами доступа. От «всем все можно» до «никому ничего нельзя». Если нет четкой ролевой модели, успешно внедрить систему не удастся. Порой доходит до абсурда: руководитель не может просмотреть наполнение своей команды или базовую статистику по заявкам.
Усложнение процессов. Когда схема «как будет» явно больше схемы «как было» — что-то идет не так. Исключение: если добавляются автоматизированные этапы, которые раньше делались вручную. Тогда схема может быть сложнее, а нагрузка на сотрудников при этом — меньше.
Игнорирование специфики. Требования к срокам, особенности обслуживание клиентов или работы с оборудованием — все компании разные и это норма! Например, клиент использует вместо услуг виды оборудования, чтобы при регистрации заявки пользователь сразу выбирал нужный вид техники. Так сделано потому, что SLA зависят от скорости поставки деталей — для разных моделей она разная. Нестандартно? Да. Зато все сразу знают, сколько времени займет починка, поэтому так удобнее.
Размер компании также порой влияет на характер ошибок. Небольшие предприятия могут недооценивать возможные риски, а крупные — переоценивать свои потребности.
Малый бизнес
С заявками работает всего несколько человек, ресурсы ограничены. В такой ситуации руководители нередко пускают внедрение на самотек. Всем выдают права администратора: «Сотрудники сами разберутся». На первый взгляд, это удобно: не нужно думать над настройкой ролей, все могут все. А потом случаются сюрпризы — от неверных настроек SLA до удаления важных данных.
Крупные предприятия
Часто вижу, как руководители хотят автоматизировать каждый микрошаг. Например, настроить автораспределение заявок с учетом множества факторов: присутствие на рабочем месте, количество заявок в работе, соответствие тематики запроса компетенциям сотрудника и так далее. Настройки занимают полгода, а прод по-прежнему лишь маячит вдалеке. Деньги потрачены, система простаивает и не помогает ни бизнесу, ни сотрудникам.
Чтобы не затянуть запуск на долгие месяцы, всегда агитируем за поэтапный запуск процессов. Вначале — базовые, чтобы быстро собрать по ним обратную связь и доработать недостатки. Потом — все рюшечки и хотелки. Когда база работает как следует, половина допнастроек невысокого приоритета отвалится сама по себе.
Как понять свои бизнес-процессы
Отдельный вопрос: нужны ли схемы BPMN? Честный ответ: не всегда.
Если процессы просты и их ценность понятна — можно обойтись без схем, достаточно описать текстом.
Но для сложных интеграций, для больших команд, где процесс затрагивает разные роли и включает множество развилок, визуализация весьма желательна — она поможет избежать ошибок и недопонимания.
Что точно нужно сделать перед запуском:
Опросить сотрудников — чем они пользуются, чем не пользуются, что хотели бы улучшить.
Выделить ключевые процессы — запускаем не все сразу, достаточно 3–5 самых важных.
Оценить зрелость процессов — что работает по регламентам, а что — как получится. Безрегламентные нужно вначале обдумать и описать, обкатать регламент процесса на практике и только потом переходить к автоматизации.
Задать ключевые вопросы — какие типы заявок поступают, через какие каналы? Как фиксируются, классифицируются, обрабатываются и закрываются? Кто участвует в процессе? Все это поможет понять, как перенести процесс в систему.
Главное — собрать достаточно информации, чтобы принимать обоснованные решения, а не настраивать систему по наитию или основываясь на убеждении «все компании в нашей отрасли так делают».
Сервис деск — не волшебная таблетка
Выбор подходящей системы — это вопрос готовности компании к изменениям. Если процессы не выстроены, беспорядок перейдет и в сервис деск. Если роли размыты, начнутся споры о том, кто за что отвечает. Если не учтена специфика бизнеса, сотрудники будут обходить систему стороной.
Вот что дает аудит процессов:
Точность выбора — компания покупает не «самое популярное» решение, а то, что решает реальные задачи.
Меньше доработок после внедрения — когда требования ясны с самого начала, не приходится месяцами перенастраивать процессы.
Быстрая адаптация команды — сотрудники участвовали в обсуждении, их мнение учтено, а, значит, они знают, как будут работать и заинтересованы в успехе автоматизации.
Оптимизация процессов до старта — неудачные процессы чинят заранее и только потом запускают в системе.
Не бойтесь вводить систему постепенно. Лучше работающий минимум через месяц, чем идеальная система через полтора года, которой так и не будет.
Если вы выбираете сервис деск, попробуйте ITSM 365 — изучите возможности на сайте, заполните форму для доступа к демо-стенду или напишите нам на sales@itsm365.com. Мы подробно проконсультируем, поможем подготовиться к запуску и поддержим во время внедрения.
