Все выпуски  

От описания бизнес-процессов к эффективному управлению. О технологиях и результатах




 

 

 

 

Страница рассылки  Написать автору Форум рассылки  
 


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

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

 

 

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

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

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

  • Скорость и простота освоения специалистами (теми, кто эти работы выполняет)
  • Простота чтения и понимания результатов (теми, кто является потребителем результатов)
  • Высокая стоимость специализированных программных продуктов (профессиональных), предназначенных для таких задач и еще большая стоимость проектов, реализованных на таких продуктах (это еще и время немало занимает);
  • Сложность примеения таких результатов на практике. Они складываются в шкаф (реже в сейф), и лежат там годами, а меняется в жизни компании мало чего;
  • Необходимость применения результатв в проектах по автоматизации (IT-проектах). В наше время поддерживать какую-либо умно продуманную систему документооборота, грамотные алгоритмы расчета экономических показателей, сложную систему отчетности на бумаге и при помощи калькулятора (или в Excel) становится нереально. Нет, есть конечно примеры, но дела у них идут все хуже...

Что с этим делать?

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

Именно в этом ключе я и развиваю свою методику.

Используемая технология основана на комплексном подходе, включающем в себя методики сбора информации, ее систематизации и анализа. Для документирования результатов работ я рекомендую использовать простые и доступные средства: MS Word, Excel для текстовых и табличных описаний, MS Visio для графического представления. Что касается графических схем самих бизнес-процессов, рекомендую использовать хорошо показавшую себя на практике нотацию eEPC (extended Event Process Chain - Расширенная нотация описания цепочки процесса). Не пугайтесь названия, она крайне проста. Обучение чтению этой нотации займет 2 часа (могу доказать). Собственный корпоративный стандарт, основанный на этой нотации, гарантирует, что результат работ будет понятен тому, кому адресован, что немаловажно (думаю, Вам приходилось сталкиваться с ситуацией, когда многостраничный труд консультантов по обследованию Заказчиком даже не читается, т.к. ничего непонятно).

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

В целом можно выделить 3 основных этапа проведения работ по обследованию:

  • Сбор информации;
  • Анализ информации;
  • Документирование результатов в виде описания бизнес-процессов;

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

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

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

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

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

В целом методика бизируется на четырех вопросах:

  • Зачем вообще использовать какую-то технологию при обследовании бизнес-процессов?
  • Зачем это надо Заказчику?
  • Что Заказчик хочет увидеть в результате и как будет это использовать?
  • Какой уровень декомпозиции (детализации) будет для Заказчика достаточен?

Зачем вообще использовать какаю-то технологию при обследовании бизнес-процессов?

Те, кто однажды впервые столкнулся с задачей понимания, что происходит в компании (особенно крупной), а уж тем более, если это нужно как-то описать, наверняка задавал себе вопросы:

  • С чего начать?
  • Как понять формы и способы взаимодействия подразделений друг с другом, а сотрудников внутри подразделения?
  • Сколько времени на это потребуется и как его спланировать?
  • Сотрудников у Заказчика может быть очень много… Каких из них привлекать к процессу? А может, вообще их не спрашивать и ограничиться руководителями подразделений? (прямой путь к проблемному проекту). Как выявить из них наиболее полезных?
  • А как все документировать? А вдруг Заказчик захочет посмотреть промежуточные результаты…
  • Как не упустить важного отчета или документа?
  • Что делать с существующими системами автоматизации? Смотреть ли их вообще?
  • Что делать с кучей записей, полученных на встречах с ключевыми сотрудниками Заказчика? Как их обработать и ничего не упустить?
  • А что делать с множеством файлов, преимущественно MS Excel, которые глубоко прижились у сотрудников, а руководство хочет от них избавиться? Ведь их можно просто не увидеть…
  • Да и много подобных вопросов…

Как Вы уже догадались, все это относится к теме сбора и анализа информации. Мы обязательно этим займемся.

Зачем это нужно Заказчику?

Это очень важный вопрос: нужно ли это вообще Заказчику или нужно Исполнителю для успешного выполнения своей части работ? Ответ на этот вопрос будет определять не только подход к обследованию, но и формат представления результатов. Одно дело, когда Заказчик собирается внимательно изучать полученные результаты с целью принятия управленческих решений. В этом случаем описывать надо обязательно, главное договориться о форматах. Кстати, как показывает практика, сам формат представления результатов для Заказчика обычно не так важен. Главное, чтобы было понятно. Совсем другое дело, когда Заказчик говорит «это Вам надо, как хотите, так и делайте». В последнем случае вовсе не означает, что обследование нужно проводить на более низком уровне, но этот факт будет сильно влиять на полученный результат. А точнее, на его наглядность для понимания специалистами. Все это влияет на сроки, и, как результат, стоимость работ. Более подробную информацию на тему "зачем и когда это надо" советую прочитать в статье "Зачем обследовать бизнес-процессы?"

Что Заказчик хочет увидеть в результате и как будет это использовать?

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

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

Какой уровень декомпозиции будет для Заказчика достаточен?

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

  • Обследование основных принципов функционирования организации (ключевых бизнес-процессов верхнего уровня);
  • Обследование деятельности подразделений (бизнес-процессов подразделений операционного уровня) .
Причем первое плавно переходит во второе (т.е. они связаны, но как результат могут рассматриваться отдельно). Остановимся ни них подробнее.

Обследование основных принципов функционирования организации (ключевых бизнес-процессов верхнего уровня)

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

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

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

документы, определяющие функционирование организации в целом (на конкретном предприятии этот набор может отличаться):

  • Устав предприятия;
  • Положения об учетной политике;
  • Положения о системе качества;
  • Положения о планировании;
  • Положения о бюджетировании;
  • Положения о процессах и прочие документы, регламентирующих процессы и процедуры предприятия;
  • документы, определяющие направления деятельности;
  • Положение об организационной структуре;
  • Должностные инструкции;
  • Положения о подразделениях;
  • Положение о персонале;
  • документы, определяющие принципы стратегического управления;
  • ряд регламентирующих документов и инструкций (типа положения о материальной ответственности, выдаче подотчетных средств и.т.д.)

Конечно, ко всему этому добавится устное собеседование с ключевыми специалистами.

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

Результатом работ будет являться отчет, включающий в себя:

  • Схему организационной структуры предприятия и ее описание;
  • Схему организационной структуры подразделений и ее описание;
  • Описание видов деятельности;
  • Описание взаимодействия компании с внешним окружением (Поставщики, покупатели, государственные органы и пр.)
  • Схему ключевых бизнес-процессов;
  • Блок выводов по результатам обследования;

На основании этой информации можно принять следующие решения:

  • Если планируется внедрение программного продукта, то можно определиться с его выбором;
  • В зависимости от приоритетов можно определить этапность работ (т.е. составить план развития информационных систем) и оценить примерные сроки таких работ
  • Если речь идет об оптимизации работы компании, то можно выделить те ключевые процессы, в которые следует углубиться в первую очередь.

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

Обследование деятельности подразделений (бизнес-процессов подразделений операционного уровня)

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

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

В рассылке мы будем подробно изучать применяемые подходы, методики и пробовать их на практике. Лучше, если Вы будете это делать на своем предприятии (принесете ему практическую пользу).

Укрупненный перечень вопросов, которые мы будем изучать в рассылке (в части обследования предприятий):
  • Подготовка и планирование обследования
  • Проведение обследования
  • Технология анкетирования и обработки анкет
  • Проведение опросов
  • Выделение основных групп процессов, формирование класификатора бизнес-процессов
  • Система документооборота
  • Система отчетности
  • Информационные системы
  • Анализ организационной структуры
  • Описание бизнес - процессов
 

 


 

 Цитата дня: 

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

 Эрих Ремарк

 

 

  

 

 Случай из практики: 

Недавно читал в журнале "Директор" статью, которая называлась "Какой CASE-инструмент нанесет наименьший вред организации?". Так вот, в конце рассуждений автор делает вывод:

" в наибольшей степени свойствами подавления «мыслительных» шумов и целенаправленности среди проектных методологий обладает методология SADT. Однако и она не идеальна. Например,                  представление Bpwin-модели организации в виде множества рефлексных контуров видится очень  сложным, а сама модель представляется в виде «дурной» бесконечности триад рефлексии.  Следовательно, степень соответствия SADT «кибернетическому стандарту» также крайне низка

При всем моем искреннем уважении к журналу и автору (безусловно от отлично знает свое дело), но для какого директора этр написано? Лично мне мало чего понятно, а Вам?

 

 

 

 Практическое задание: 

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

 

 

 

 

 

 

 


 

 



В избранное