...

среда, 18 июня 2014 г.

«Все врут!»™ или казуистика описания бизнес-процессов

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



Начну с небольшого дисклаймера: я не психолог, а бизнес-консультант, все выводы сделаны на основе руководства проектами в вымышленных организациях, совпадения случайны. Конечно, в маленькой организации с маленькими процессами такого может не наблюдаться, но начиная с уровня «управление» и «департамент» такое сплошь и рядом. Сразу скажу, что люди зачастую врут не специально и не осознанно, верьте в людей и всё такое.

1 причина: камуфляж собственной некомпетентности




На этапе планирования проекта, ответственный за предоставление данных руководитель подразделения назначает экспертов в полной уверенности, что они-то уж точно знают весь процесс и смогут ответить на все вопросы. Этим экспертам после назначения в проект деваться уже некуда, приходится нести ответственность за предоставление информации. Если ему задать вопрос не из его компетенции, то он делится своими фантазиями на тему «как бы это могло происходить по-моему». Сказать «я не знаю, обратитесь к другому эксперту» означает для него роспись в своей некомпетенции и соответствующими возможными оргвыводами со стороны назначившего его руководителя.


В одном из проектов я был приглашен на групповое перекрестное интервью в качестве третьего лица с целью поучаствовать в фарсе. Все было красиво — консультанты задают вопросы специально выделенному лицу, лицо торжественно отвечает, ведется протокол. Под конец встречи консультанты зачитывают результаты и уточняют у лица, всё-ли правильно, он утверждает, все счастливы и готовятся разойтись, но тут я задаю вопрос типа «А в какой момент собственно создаются документы А и Б?». Ответственное лицо мрачнеет и вспоминает что да, действительно, он немного приврал и процесс идет «немного по-другому».

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





Отсюда и первый совет — не дайте возможность людям соврать. Вместо вопроса «Как А превращается в Б?» надо спросить «Правильно ли я понимаю, что для превращения А в Б надо то и это?». Так эксперт пожурит вас «Да что вы понимаете в колбасных обрезках!» и с чувством собственного достоинства расскажет все детали как на духу. Но для этого надо проводить интервью подготовленным.

2 причина: корпоративная солидарность




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


На этапе построения модели добавленной стоимости VAD никак не получалось привязать никакую разумную ценность работы одного подразделения. Проект договора попадал в это подразделение на три-четыре дня, затем с визой шел дальше по процессу. Подразделение не профильное, не управляющее, блокировок процесса никогда на этом этапе не бывает. Странно. Несколько раз я посылал в это подразделение бизнес-аналитиков для разгадки — что происходит с документами в подразделении, зачем нужны подписи его руководителей? Через некоторое время руководство подразделения сдалось: оказывается, когда-то давно они у себя сами вели свой реестр проектов договоров, им было важно быть в курсе, что такие договора существуют. Затем внедрили специальное ПО для анализа рисков таких договоров, дали им доступ в него, а процесс изменить забыли. Вот так уже много лет они тормозили продукт на несколько дней, а признаваться нельзя — там целые отделы под это дело заточены.





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

3 причина: личная заинтересованность




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


Недавно один руководитель подразделения попросил меня помочь ему в расчетах эффективности и утилизации его сотрудников. В одной из строчек предоставленных данных глаз зацепился за операцию «Ксерокопирование документов — 1 час (цифра изменена)». Я уточнил, неужели так много низкоквалифицированной работы в подразделении такой солидной организации? Начальник говорит:

— Да, очень много такой работы.

— А ксероксов у вас сколько?

— Один

— А сотрудников?

— 15 (цифра изменена)

— Все врут!

(Дружище Ватсон! 8-ми часовой рабочий день, 15 исполнителей физически не смогут использовать один ресурс монопольно длительностью 1 час)





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

4 причина: доверяй, но проверяй...




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


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



Ну как, вы всё ещё верите результатам проведенных интервью с экспертами? Надеюсь вам повезет и результаты окажутся адекватными, не смотря ни на что.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий