Даже если вам кажется, что вы все знаете о своем бизнесе, всегда минимум на треть что-то можно улучшить. Само по себе описание бизнес-процессов (БП) автоматически «открывает» глаза на положение дел в компании и на то, как эти бизнес-процессы улучшить. Я для себя вывел такое определение успешности проекта по описанию БП: если в итоге будет как можно меньше двойных толкований персоналом любых действий внутри этого самого БП (а лучше, чтобы их не было совсем), тогда БП описан правильно. Тогда люди будут действовать только по прописанным правилам, а ИТ-система не даст им соскочить с них, и, как следствие, резко повысится скорость обработки процессов и уменьшится количество ошибок.
Начнем с формирования команды. Процесс описания БП возможен, если в нем участвует генеральный директор, ответственный менеджер внутри компании (освобожденный от других задач) и привлеченный сторонний специалист, у которого есть опыт описания БП в других отраслях, и он этим опытом поделится, и, конечно же, специалист по ИТ, который будет помогать перекладывать описанные БП в ИТ. Если кого-то из этих четырех людей не будет, то начинать процесс бессмысленно. Кроме этих людей нужно создать так называемую проектную группу, в которую включаем также всех руководителей основных подразделений (коммерческого директора, финансового, по персоналу, по логистике и т.п.), и по одному человеку из каждого крупного отдела или службы как ответственного исполнителя.
Рассмотрим их роли. Генеральный директор — он понимает и осознает, что без описания, оптимизации, измерения и автоматизации БП компании наступит трындец. Он инициирует, руководит и направляет всю работу проектной группы, защищает ее от нападок тех, кому «ничего не надо, все и так хорошо», и объясняет владельцам компании, зачем вообще все это надо, на что тратятся деньги и что это даст.
Ответственный менеджер внутри компании — он давно знает свою компанию, всех сотрудников, их сильные и слабые стороны. А главное, он может (если надо) сказать любому: «...мы уже поняли, что ты думаешь: «Это все ерунда, жили 20 лет без этого и еще столько же проживем», но тем не менее расскажи, чем ты занимаешься». Рекомендуемый статус этого сотрудника — заместитель проектной группы.
Третий сотрудник — привлеченный специалист. Как правило, это человек из консалтингового агентства. Он знает, как и что спрашивать, а главное, как правильно все это записывать и фиксировать на бумаге в виде текста и таблиц. Он сторонний человек, и хотя бы перед ним многие сотрудники не будут хамить, отлынивать и т.п., а попытаются хоть что-то внятное сказать.
Четвертый сотрудник — это директор по ИТ или бизнес-аналитик из программистов, который сможет перевести c русского языка на «программистский» и сразу начнет формализовывать свежеиспеченные БП.
С остальных участников проектной группы (всех начальников служб и отделов) нужно собрать план-график собеседований по их отделам и направлениям. Рекомендуемый срок — от 2 до 4 месяцев, за меньший срок не успеете, за больший — уже забудете, с чего начинали.
Мой совет — по мере формализации и перенесения БП в ИТ-систему начинайте все оптимизировать по горячим следам. А после того, как вы поняли, что на данном этапе дальнейшая оптимизация невозможна, вместе с директором по персоналу начинайте измерять основные параметры БП: что туда вошло (задача, продукт и т. п.) и что на выходе получилось, кто главный за этот процесс и как он на него влияет, как его мотивация зависит от того, что на самом деле получается на выходе из БП. По своему опыту скажу: первая реакция шоковая — более 80% ответственных лиц за БП никак и нигде не мотивированы вообще! А остальные 20% не мотивированы в достаточной мере, чтобы сделать этот БП качественно и быстро. Еще оказывается, что не менее 80% БП не измерялись до начала проекта вообще никак.
Для каждого БП нужно описать всего несколько пунктов:
- Что происходит внутри процесса
- Кто в нем участвует
- Кто старший и отвечает за него
- Какие параметры измеряются на входе и выходе из БП
- Кто и как отвечает за то, что происходит внутри БП
- Как и где процессы на входе, внутри и на выходе из БП отражаются в ИТ-системе
Нормальная ситуация в российском бизнесе из 1990-х — начала 2000-х по всем шести пунктам выглядит так: нам это и даром не надо, мы ничего не измеряем и ни за что не отвечаем, хотя рулить очень любим, все валится само собой и как-то работает. Есть, конечно, и другие крайности. Совсем недавно побывал на вебинаре по этому вопросу, важные люди с умным видом чертили графики, кучу таблиц давали, что, мол, каждый БП нужно измерять по 28 (!) параметрам… Ну, как говорится, «флаг им в руки и все параметры на шею»! Сложность — это другая крайность, и так делать не надо. Ну сами подумайте, если в среднем для описания компании хватает от 200 до 300 БП, да перемножить почти на 30 параметров измерения в каждом, получаем почти 10 тыс. параметров, которые нужно постоянно контролировать. Тогда впору создавать новую компанию — и только для контроля. Даже не смешно…
По моему опыту, достаточно всего двух-четырех параметров для одного БП, а лучше одного-двух. Я использую четыре основных параметра, основанных на здравом смысле:
- Время выполнения БП
- Производительность (какое количество документов, товаров, услуг, информации, распоряжений и т.п. проходит через этот БП в единицу времени)
- Качество (если можно оценить) проходящей информации через БП (количество ошибок, возвратов и т.п. критериев)
- Кто отвечает за этот самый БП и есть ли у него мотивация это делать
Часто бывает так (а точнее почти всегда, и я говорю это, опираясь на опыт четырех полноценных внедрений в компаниях, где работает от 100 до более чем 1000 сотрудников) — по мере описания БП сотрудники с удивлением и даже любопытством вдруг узнают, чем же они на самом деле занимаются. Главное, в этот момент любопытства подхватить их интерес и довести проект до конца. Сформированная группа должна закончить описание всех БП в период от 2 до 4 месяцев, если меньше, то есть риск поверхностного описания состояния компании, если больше — то можно будет забыть, с чего вообще начинали.
Позволю себе дать еще один совет. Перед тем как внешний консультант начнет опросы сотрудников, неплохо было бы поручить этим самым сотрудникам, в лице их руководителей, попытаться самим в самом общем варианте описать свой функционал: чем они конкретно занимаются. Для этой цели могу порекомендовать применить вот такой незамысловатый шаблон. Раздайте его сотрудникам, и пусть через неделю отдадут его заполненным. Это будет серьезным подспорьем для участников проекта внедрения.
Бывает так, что даже этот простецкий документ заставляет задуматься участников бизнес-процесса о том, что в нем хорошо, а что — не очень, и уже к началу проекта они будут в состоянии не только грамотно описать свой функционал, но и предложить пути его улучшения.
Далее — по мере работы над проектом фиксируйте сразу все нестыковки, явные провалы, видимые проблемы в БП, например отсутствие контроля в ИТ-системе, отсутствие мотивации на выполнение процесса, отсутствие ответственного за процесс. Очень важно, описывая БП, делить его на более мелкие операции и хорошо бы сразу понимать — производится ли фиксация времени начала и конца каждой операции. Каждый БП вводите в ИТ-систему и измеряйте точно, как только возможно. Советы по измерению: при описании БП ведите запись прохождения через этот БП товара, услуги или информации сразу в двух контрольных точках. Например, для торговой компании — где товар находится физически и где это отображается виртуально (в ИТ-системе). Это правило сильно упрощает жизнь и позволяет видеть, что же на самом деле происходит с товаром.
На основе описанных БП вы сможете не только увидеть внутренние ресурсы для развития, но и сделать это без рекламы, тихо и бесшумно для конкурентов, и тем самым создать совершенно незаметно для рынка новое конкурентное преимущество. Например, у меня в одной торгово-производственной компании был один достаточно сложный бизнес-процесс — «прием заказов и отправка заявки на производство», там постоянно возникали проблемы как с полным и качественным приемом заказов, так и со сроком выполнения. После описания и оптимизации время этого БП уменьшилось в 6 (!) раз — с 3 часов до 30 минут. И все только на основании ввода в ИТ-систему (в данном случае 1С8 УПП) всех пунктов этого БП в виде простых выпадающих меню, которые шаг за шагом, поэтапно подводили пользователей к нужному результату. В итоге у персонала просто не осталось шанса ошибиться. Понятно, что все эти «выпадающие меню» с вариантами ответов и, как следствие, логики дальнейших действий для рядового пользователя были заранее обсуждены и многократно проверены в течение как минимум пары месяцев. Не говоря уже о том, что только для этого БП пришлось проанализировать более 40 вариантов различных ответов на заявки… Иными словами, детально описанный, улучшенный и автоматизированный БП должен в итоге дать вам выигрыш в двух направлениях:
- Теперь этот БП делается без ошибок, так как персонал не сможет нести «отсебятину» внутри процесса, а значит, априори будет обходиться вашей компании дешевле, чем раньше.
- Новый БП будет выполняться быстрее.
С какой степенью детализации необходимо проводить описание БП? Сколько нужно таких БП описать — 10, 20 или 100? Единственно верного ответа быть не может: небольшой компании хватит и 5-10 укрупненных БП, а, например, для средней розничной сети в самый раз 100 БП (плюс еще сотня, если у торговой сети есть свой склад). Для большой сетевой компании с филиальной структурой и матричной системой управления прекрасным результатом будет описание от 400 до 500 БП (при довольно хорошей детализации).
Начать описание БП советую с пяти самых простых, которые охватывают:
- планирование продаж и закупки,
- логистику закупок и логистику внутри компании,
- собственно процесс продажи,
- логистику доставки клиенту,
- сопутствующий всему этому «безобразию» документооборот.
Остальные БП подтянутся во время работы. Логика всего процесса описания проста: «протяните» ваш товар или услугу через всю компанию от точки входа до точки выдачи клиенту. И вы очень многое увидите и узнаете о своей компании.