Петр Грек - 10 практических советов для успешного директора. Мои советы многим заменят МВА!

Рассмотрим их роли. Генеральный директор – он понимает и осознает, что без описания, оптимизации, измерения и автоматизации БП компании наступит трындец. Он инициирует, руководит и направляет всю работу проектной группы, защищает ее от нападок тех, кому «ничего не надо, все и так хорошо», и объясняет владельцам компании, зачем вообще все это надо, на что тратятся деньги и что это даст.

Ответственный менеджер внутри компании – он давно знает свою компанию, всех сотрудников, их сильные и слабые стороны. А главное, он может (если надо) сказать любому: «…мы уже поняли, что ты думаешь: „Это все ерунда, жили 20 лет без этого и еще столько же проживем“, но тем не менее расскажи, чем ты занимаешься». Рекомендуемый статус этого сотрудника – заместитель проектной группы.

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

Четвертый сотрудник – это директор по ИТ или бизнес-аналитик из программистов, который сможет перевести c русского языка на «программистский» и сразу начнет формализовывать свежеиспеченные БП.

С остальных участников проектной группы (всех начальников служб и отделов) нужно собрать план-график собеседований по их отделам и направлениям. Рекомендуемый срок – от 2 до 4 месяцев, за меньший срок не успеете, за больший – уже забудете, с чего начинали.

Мой совет – по мере формализации и перенесения БП в ИТ-систему начинайте все оптимизировать по горячим следам. А после того, как вы поняли, что на данном этапе дальнейшая оптимизация невозможна, вместе с директором по персоналу начинайте измерять основные параметры БП: что туда вошло (задача, продукт и т. п.) и что на выходе получилось, кто главный за этот процесс и как он на него влияет, как его мотивация зависит от того, что на самом деле получается на выходе из БП. По своему опыту скажу: первая реакция шоковая – более 80% ответственных лиц за БП никак и нигде не мотивированы вообще! А остальные 20% не мотивированы в достаточной мере, чтобы сделать этот БП качественно и быстро. Еще оказывается, что не менее 80% БП не измерялись до начала проекта вообще никак.

Для каждого БП нужно описать всего несколько пунктов:

– Что происходит внутри процесса

– Кто в нем участвует

– Кто старший и отвечает за него

– Какие параметры измеряются на входе и выходе из БП

– Кто и как отвечает за то, что происходит внутри БП и мотивирован на их улучшение

– Как и где процессы на входе, внутри и на выходе из БП отражаются в ИТ-системе

Нормальная ситуация в российском бизнесе из 1990-х – начала 2000-х по всем шести пунктам выглядит так:

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

Есть, конечно, и другие крайности. Совсем недавно побывал на вебинаре по этому вопросу, важные люди с умным видом чертили графики, кучу таблиц давали, что, мол, каждый БП нужно измерять по 28 (!) параметрам… Ну, как говорится, «флаг им в руки и все параметры на шею»!Сложность – это другая крайность, и так делать не надо. Ну сами подумайте, если в среднем для описания компании хватает от 200 до 300 БП, да перемножить почти на 30 параметров измерения в каждом, получаем почти 10 тыс. параметров, которые нужно постоянно контролировать. Тогда впору создавать новую компанию – и только для контроля. Даже не смешно…

По моему опыту, достаточно всего двух-четырех параметров для одного БП, а лучше одного-двух. Я использую четыре основных параметра, основанных на здравом смысле:

1. Время выполнения БП

2.Производительность (какое количество документов, товаров, услуг, информации, распоряжений и т. п. проходит через этот БП в единицу времени)

3. Качество (если можно оценить) проходящей информации через БП (количество ошибок, возвратов и т. п. критериев)

4. Кто отвечает за этот самый БП и есть ли у него мотивация это делать

Часто бывает так (а точнее почти всегда, и я говорю это, опираясь на опыт четырех полноценных внедрений в компаниях, где работает от 100 до более чем 1000 сотрудников) – по мере описания БП сотрудники с удивлением и даже любопытством вдруг узнают, чем же они на самом деле занимаются. Главное, в этот момент любопытства подхватить их интерес и довести проект до конца. Сформированная группа должна закончить описание всех БП в период от 2 до 4 месяцев, если меньше, то есть риск поверхностного описания состояния компании, если больше – то можно будет забыть, с чего вообще начинали.

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

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

Далее – по мере работы над проектом фиксируйте сразу все нестыковки, явные провалы, видимые проблемы в БП, например отсутствие контроля в ИТ-системе, отсутствие мотивации на выполнение процесса, отсутствие ответственного за процесс. Очень важно, описывая БП, делить его на более мелкие операции и хорошо бы сразу понимать – производится ли фиксация времени начала и конца каждой операции. Каждый БП вводите в ИТ-систему и измеряйте точно, как только возможно. Советы по измерению: при описании БП ведите запись прохождения через этот БП товара, услуги или информации сразу в двух контрольных точках. Например, для торговой компании – где товар находится физически и где это отображается виртуально (в ИТ-системе). Это правило сильно упрощает жизнь и позволяет видеть, что же на самом деле происходит с товаром.

На основе описанных БП вы сможете не только увидеть внутренние ресурсы для развития, но и сделать это без рекламы, тихо и бесшумно для конкурентов, и тем самым создать совершенно незаметно для рынка новое конкурентное преимущество. Например, у меня в одной торгово-производственной компании был один достаточно сложный бизнес-процесс – «прием заказов и отправка заявки на производство», там постоянно возникали проблемы как с полным и качественным приемом заказов, так и со сроком выполнения. После описания и оптимизации время этого БП уменьшилось в 6 (!) раз – с 3 часов до 30 минут. И все только на основании ввода в ИТ-систему (в данном случае 1С8 УПП) всех пунктов этого БП в виде простых выпадающих меню, которые шаг за шагом, поэтапно подводили пользователей к нужному результату. В итоге у персонала просто не осталось шанса ошибиться. Понятно, что все эти «выпадающие меню» с вариантами ответов и, как следствие, логики дальнейших действий для рядового пользователя были заранее обсуждены и многократно проверены в течение как минимум пары месяцев. Не говоря уже о том, что только для этого БП пришлось проанализировать более 40 вариантов различных ответов на заявки… Иными словами, детально описанный, улучшенный и автоматизированный БП должен в итоге дать вам выигрыш в двух направлениях: