Что значит управлять процессом? Рассказываю про свой опыт

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

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

Процессы работали… пока не сломались

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

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

Устоявшиеся процессы и действительно работали. Так было пока компания не начала внедрять новую услугу — широкополосный доступ к интернету по технологии ADSL. Появились новые требования к линиям связи, по которым предоставлялся интернет. В процесс включились новые участники — техническая поддержка абонентов и выездные бригады, которые выполняли настройку абонентского оборудования и подключение клиента. Сложности еще добавляло то, что эти новые подразделения были из другой структурной единицы, со своим руководителем и со своим KPI. Из общего с ними у нас был только директор филиала, который точно не должен был вникать в тонкости «хождения» заявок по подразделениям.

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

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

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

Как исправляли ситуацию

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

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

· Как именно происходит проверка линии?

· Какими инструментами пользуется подразделение?

· Какие результаты на данном этапе могут получиться?

· Кому передается результат проверки?

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

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

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

Что изменилось после внедрения:

1. Количество возвратов проверок на доработку сократилось практически до нуля. Сроки локализации и устранения проблем значительно уменьшились. До того, как мы починили систему, заявка могла неделями переходить из подразделения в подразделение. Так могло продолжаться вплоть до отказа клиента от услуги.

2. Процесс стал прозрачнее. Контролировать его стало значительно проще.

3. Обучение сотрудников перестало сводится к указаниям типа «Вася, ты теперь делай это, а ты, Петя — это» и стало частью системного процесса.

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

Что показал мне этот опыт

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

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

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

Когда стоит детально разобрать бизнес-процесс

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

· Второй случай — компания масштабируется. Появляются новые сотрудники, которых нужно обучать, увеличивается объем работы, приходится пересматривать существующие процессы и, возможно, внедрять дополнительные инструменты. Очень важно понимать, как должен работать процесс в новом масштабе.

· Третий случай — внедрение новых услуг, продуктов. Именно этот случай я подробно разобрал выше.

Как начать регламентировать прямо сейчас

Никаких сложных инструментов не требуется. Достаточно будет текстового редактора или даже листа бумаги.

· Разделите процесс на этапы. Каждый этап должен заканчиваться понятным, осязаемым результатом.

· Определите исполнителя. Кто отвечает за выполнение этапа?

· Опишите действия. Что нужно сделать для получения результата? Если этап предполагает общение с клиентом — пропишите скрипты (разговорный сценарий, что в каких случаях нужно говорить, а что нельзя)

· Определите передачу результата. Кому и в каком виде передается результат этапа?

· Проверьте слабые места. Где возникают задержки? Какие сложности возникают у участников процесса?

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

В завершение

Конечно, одним регламентом все вопросы управления не решить. За каждым процессом стоят люди, а работу с людьми навряд ли можно описать какой-нибудь инструкцией.

К тому же ситуации в компаниях могут быть абсолютно разные. Если вы не собственник бизнеса, то вами тоже будет кто-то руководить и стратегическое направление будет вам доводиться «сверху». Тут можно оказаться очень сильно «зажатым» в полномочиях. Мне в этом плане повезло: мои предложения поддерживались, а системность в процессах была частью стратегии компании.

Плюс помимо регламентов есть еще и другие элементы управления — планирование, мотивация… Но все эти моменты — отдельные темы для размышления.