Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Про бизнес процессы…


snap

 

Бизнес процессы. Итак, надо ли их описывать? С какого этапа развития компании? Придет ли непременно к большой компании, не описывающей бизнес-процессы белый и пушистый зверь? На мой взгляд — это очередная легенда, рожденная консультантами и продавцами решений. Если не описаны бизнес-процессы — то это «кривой» бизнес, «может работать только при норме прибыли 200%», если не описано, то «они сами не знают чего им надо» и т.д. и т.п. и в том же духе. Причем, как и все маркетинговые легенды — эта аргументируется на соответствующем уровне: «нельзя же ездить на машине без руля», «что будет, если все процессы вдруг забудутся» …

Примем несколько аксиом:

  • Бизнес-процессы есть во всех фирмах. Независимо от того, описаны они формально или нет.
  • Описания бизнес процессов есть практически во всех фирмах. Звучит немного неожиданно, но это так. Вопрос лишь, это бумажка на стене в бухгалтерии: «Авансовые отчеты принимаются с 14 до16 в комнате №3» или автоматизированный репозитарий, с соответствующими процедурами, который постоянно поддерживает корректное описание всех выполняемых в фирме операций, с ролями, ответственными, картами и т.д. и т.п (такого у нас к сожалению до сих пор нет, и он нам очень бы не помешал, но мы верим в светлое будущее…).
  • Не описанные на бумаге (в компьютере) бизнес-процессы существуют в головах у их исполнителей.

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

  1. Использование в текущей работе. Рискну заявить — такой потребности нет (по крайней мере в нашей текущей ситуации нет). Никто по своей текущей работе описаний не читает — некогда, это и так в голове.
  2. Использование для обучения. Такая потребность, безусловно, есть. Всегда проще дать человеку почитать, чем объяснять, отвлекаясь от работы самому (мы стараемся прививать, нашим пользователям желанье читать инструкции, но сталкиваемся с постоянными попытками не делать этого). Тонкость: описание должно иметь вид учебного материала. Обучать людей по IDEF нотации наверно рискованно.
  3. Использование для редко выполняющихся процессов (раз в 3 года надо отель забронировать — как это сделать). Такая потребность тоже есть. Тонкость: описание должно иметь вид краткой пошаговой инструкции («Авансовые отчеты принимаются с 14 до16 в комнате №3»). IDEF-диаграмма и учебный курс менеджера по бронированию отелей тут не подходят.
  4. Анализ бизнес-процессов (например, в целях оптимизации, не встречал ни разу за последние несколько лет). Тут неочевидно. Ни разу не видел, чтобы по описаниям что-то реально удалось проанализировать или улучшить, но теоретически такую возможность допустить можно. Тонкость: описание должно быть в виде, пригодном для анализа (IDEF-диаграмма, например)
  5. Поиск виновного. Потребность есть, но её осмысленность более чем дискутабельна. Реально виновный и так известен, обычно это поиск стрелочника. Не думаю, что задача достаточно благодарна для вложения в неё средств и сил. Тонкость: описание должно быть в виде должностных инструкций.
  6. Сертификация и аудит. Например на ISO9000 или CMM. Вообще говоря: «Без мастерства черный пояс нужен только для поддержания штанов» (с) Б.Ли. Но иногда надо. Тонкость — требования к описанию у каждого сертификатора и аудитора свои.
  7. Стандартизация. Например внешний вид визиток :-).  Тонкость — описания есть описания стандартов (логотип в 3.456 мм от края визитки)

Что мы имеем в итоге? В итоге у нас минимум семь разных описаний, с разными документами друг к другу не подходящими и не заменяющими. И всё это хорошо бы иметь полное, непротиворечивое и актуальное. В общем, в хоть сколько-либо крупной компании — работа хорошему такому недешевому отделу. С непрерывным мониторингом всех аспектов деятельности: «ага, тут должность сократили — корректируем все процессы, где она была задействована». Выскажу мнение, что, Слава Богу никто данную идею на 100% не реализовал. Потому как не дожил бы до реализации. Так что истина, как всегда где-то посередине и чтобы её понять — надо понять плюсы и минусы наличия описания.

Плюсы.

  • Ну, наверно первым называют уменьшение зависимости от персоналий (на мой взгляд, это ключевой и достаточно фундаментальный момент, бывали случаи, когда при увольнении человека ИТ отдел, по крайней мере, полностью впадал в «гидростопор», что конечно же неблагоприятно сказывалось на бизнесе в целом). Не думаю, что это плюс вообще, в случае массового увольнения всех носителей знания о каком-то важном бизнес-процессе — от описаний тоже мало будет радости (но такое происходит не часто). Если же процесс мелкий — то он легко восстанавливается «на лету», а если крупный — то его знают многие и новичку расскажут.
  • Облегчение обучения. Это да, это безусловно. Учебные материалы иметь крайне желательно (с этим можно согласиться, но как заставить пользователей читать и знакомиться с этими учебными материалами, например, многократно сталкивался с тем, что пользователи просто не хотят учиться, пеняя на то, мол: «Зачем здесь тогда вы (имеется ввиду ИТишники), если нам самим надо знакомиться с учебными материалами?»).
  • Уменьшение «бардака». Вот тут надо подробнее. Во первых — хорошо определиться — что есть «бардак»? Не абсолютно одинаковые визитки это бардак или не нет? Выполнение одного и того же процесса в разных подразделениях по разному (но и там и там успешно) — это бардак? Ответ в каждом случае зависит от ситуации и политики компании и просто так тоже не дается. К тому же описания не обязательно означают отсутствие бардака — они могут означать описанный бардак, примеров чему несть числа. В общем, при большом количестве персонала, выполняющего одинаковые операции — скорее да, чем нет. При достаточно автономных подразделениях, быстро меняющейся внешней ситуации — скорее нет, чем да.
  • Так спокойнее. Действительно, наемным менеджерам незачем ломать систему, в которой им хорошо, они её наоборот укрепляют (с этим мы тоже повсеместно сталкиваемся).

Минусы

  • Это дорого и сложно.
  • Это приводит к сильному торможению инициативы на местах, поскольку мало придумать новый процесс — надо его теперь внести в репозиторий, получить одобрение. А оно (даже если процесс хороший) централизованым «гениям» надо? Мало что лишняя работа, так еще и синдром «не тут придумано». Чем выше степень описания — тем ниже чувствительность организации к внешним раздражителям. Это правило.
  • Часто описания подменяют реальную работу. Производится куча бумаги, не определившись с целью (классика жанра — IDEF на всё и вся), а потом — вроде оно и есть, но толку никакого, потому что по ним ни учить, ни лечить. И вообще они коммерческая тайна 🙂 Я не зря спрашивал (и не получил ответа), кто-нибудь у себя в корпорациях это реально читает? Ну, хотя бы для обучения? А после обучения?

Напоследок повторю Минцберга: есть несколько основных координирующих механизмов:

  1. Взаимное приспосабливание (обычно в небольших организациях, хотя, бывают исключения)
  2. Прямое руководство (обычно в средних организациях, хотя, бывают исключения)
  3. Стандартизация рабочих процессов (вот тут как раз всё описывается)
  4. Стандартизация результатов (например — мы контролируем прибыль, а подразделения вольны творить что хотят)
  5. Стандартизация навыков (любые организации из высококлассных специалистов — врачи, программисты, трейдеры и т.п.)
  6. Стандартизация норм (имеются в виду моральные ценности, наиболее яркие примеры — церковь, разведка, но так можно строить любую организацию)

Описания — это инструмент стандартизации рабочих процессов. Но не зря же существуют еще 5 механизмов, в большинстве которых детальное описание процессов скорее вредит, чем помогает. Более того, сейчас очень многие компании пытаются именно разбить себя на мелкие автономные единицы, именно потому, что бюрократизация висит на большой структуре камнем (мы предоставляем некие сервис услуги и с этим к большому сожалению нам пришлось неоднократно столкнуться, при том чем организация больше, тем больше и бюрократизация, вот такая вот прямопропорциональная зависимость). Поэтому — прежде чем заявлять «неописаный бизнес крив» надо сначала понять суть этого бизнеса и, если он из 3-й категории — то заявиить, а если не из 3-й — то подумать еще раз.

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

Ибо:

  • прямому руководителю нужен один коуч (если нужен),
  • стандартизация результатов консультантов особо не требует,
  • стандартизация навыков — требует специалистов по этим навыков и развитию персонала, что сложно,
  • взаимное приспособление и стандартизация норм — это построение культуры, тут вчерашними студентами не обойдешься

Так что есть широкий рынок именно поддерживающий модель, основанную на описании процессов. И он себя рекламирует.

Всем хорошей работы!!!

Реклама

05.12.2013 - Posted by | it management/itil/itsm

Sorry, the comment form is closed at this time.

%d такие блоггеры, как: