Меня часто спрашивают - что почитать о бизнес-процессах?
Одним из лучших сайтов на просторах рунета является www.klubok.net . Я сам "вырос" на форуме и статьях этого сайта. Многие статьи не потеряли актуальности и сейчас. Начать учиться рекомендую именно с него.
А вот если говорить о книгах - то уверенно могу сказать лучшая книга о бизнес-процессах - это книга, написанная Репиным и Елиферовым: "Бизнес-процессы компании. Построение, анализ, регламентация".
Описание бизнес-процессов: стремление к простоте.
В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие.
При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.
Для бизнес-аналитиков компаний тезисы, обсуждаемые в статье, - это серьезный повод задуматься, насколько эффективны используемые ими подходы к разработке графических схем процессов организации.
Введение
Одной из важнейших целей формирования графических схем процессов является последующее их использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, которые не обучены сложным нотациям, не имеют навыков системного анализа и т.п. Для них очень важна простота и наглядность схем. Сложные, запутанные схемы, содержащие много различных условных обозначений, плохо воспринимаются людьми, что затрудняет их практическое использование. Поэтому для практических целей важным является корректный выбор и использование нотации (методики) описания процессов. По каким критериям следует выбирать такую нотацию? Как сравнивать разные нотации между собой? Рассмотрим несколько популярных нотаций и попытаемся ответить на эти вопросы.
Сравнение нотацийДля сравнения были выбраны следующие нотации описания процессов:
- «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
- «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
- «Процедура» системы Business Studio (один из возможных вариантов представления);
- ARIS eEPC.
В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на рис. 1-4.
Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»).
На схеме рис. 1. Последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов - при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы ни то, и не другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т.п. Но на схеме процесса нужно показывать реальные объекты - процессы, выполняемые людьми, документы, информационные системы и т.п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:
а) описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
б) описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
в) описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.
Сформулируем «плюсы» и «минусы» рассмотренного выше (рис. 1.) способа использования «ромбиков».
| «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение») | |
| «Плюсы» | «Минусы» |
|
|
На рис. 2. показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме рис. 1. Схема рис. 2. выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности, эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.
Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»).
«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 2., показаны ниже.
В целом, применение схем в формате, подобном представленному на рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.
На рис. 3. представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы не стандартным образом - не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т.п.
Второй особенностью схемы процесса, представленной на рис. 3., является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником - стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок - стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход дает возможность:
- существенно сократить количество графических элементов на схеме процесса, и при этом:
- вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем, тем не менее, полно описать процесс и выгрузить в регламент всю необходимую информацию.
«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 3., показаны ниже.
Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»).
В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на рис. 3.
На рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.
Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на рис. 1-3. Трудоемкость формирования такой схемы так же существенно выше.
| Схема процесса в нотации ARIS eEPC (построена в Business Studio) | |
| «Плюсы» | «Минусы» |
|
|
В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.
Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio).
Описание процесса для целей последующей автоматизации
Интересно посмотреть на рассматриваемую схему процесса в случае, если она описана в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т.е. процессов которые поддерживает система BPM.
Своим мнением об использовании BPMN 2.0. делится А.А. Белайчук - Генеральный директор компании «Бизнес-консоль»:
На рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на рис.1: в нотации BPMN задачи изображаются прямоугольниками, развилки - ромбами, данные - пиктограммой, похожей на документ. Потоки управления - сплошные линии, потоки данных - пунктирные. Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением - «движком» BPM-системы. В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной блок-схемы. Ну а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинг www.bpmntraining.ru . |
Рис. 5. Схема процесса в нотации BPMN 2.0.
Практика жизни
На рис. 6 показан фрагмент схемы процесса, разработанный бизнес-аналитиками вполне конкретной компании в придуманной ими нотации. Схема построена с применением принципов «Простой блок-схемы» - применяется блок «Решение» в своем классическом варианте. Кроме этого, на схеме представлено множество других условных обозначений, использованных не совсем стандартным образом.
При формировании схемы рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п.
Рассматриваемая схема не является, конечно, образцом простоты и наглядности. Но она была сформирована, чтобы донести максимум полезной информации для исполнителей процесса.
Выводы
Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.
Использование сложных, формализованных нотаций при описании процессов приводит к:
- трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
- невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
- значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
- дополнительным сложностям при документировании схем (большой объем и т.п.);
Поэтому не стоит загромождать схему процесса различными графическими элементами. Но уже если их использовать, то лучше, чтобы они несли полезную информацию для сотрудников, а не были просто следствием формального применения нотаций моделирования.
В.В. Репин , к.т.н., доцент, Исполнительный директор ООО «BPM Консалтинг Групп », зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru
Именно эти простые принципы я и пытаюсь донести до руководителей предприятий, которые очарованные красивыми презентациями программных продуктов зачастую забывают, что часто простой чек-лист лучше 10 страниц регламентов.
При моделировании процесса в Visio нужно помнить, что основной целью является отображение логики процесса, его участников и выполняемых ими действий . Соответственно, для отображения логики процесса используем события и логические связи между ними, участников показываем с помощью ролевых дорожек, их действия – с помощью элементов вида «процесс». Все прочие аспекты (документы, ресурсы) должны отображаться таким образом, чтобы не затруднить понимание логики, для полного раскрытия этих аспектов процесса лучше использовать текстовое или табличное описание.
Для целей моделирования в данном примере мы рассмотрим упрощенный процесс продажи некого самостоятельно производимого товара.
Непосредственное моделирование лучше всего начать с указания наименования и уточнения границ процесса. Границы можно зафиксировать сразу в виде событий на схеме. В нашем примере граничными событиями будут «Выявлена потребность клиента» и «Потребность подкреплена взаимными обязательствами» (см. рис. 3).
Рис. 3. Заголовок и границы процесса
Чтобы облегчить восприятие схем, описание процесса должно начинаться в левом верхнем углу (см. рис. 4). Нарушение этого правила нежелательно, но возможно, если по каким-то причинам первоначально задан порядок исполнителей / дорожек, и первые работы в рамках процесса относятся к дорожке, находящейся в середине или внизу.
Каждая работа / процедура на схеме процесса должна быть оформлена как целостный блок, имеющий логические границы в виде событий, документов. Эти логические границы позволяют лучше осмыслить и более качественно структурировать процесс.
Структурирование описываемого процесса, если оно не было осуществлено заранее, целесообразно проводить исходя из понимания той цепочки промежуточных результатов (событий) , которая необходима для достижения цели процесса . Данная цепочка реализуется путем пошагового перехода от начального к конечному событию процесса. При формулировании событий желательно оперировать объектами и их состояниями ("потребность выявлена", "заказ обработан" и т.п.).
Упрощенный пример описания процесса показан на рис. 5.
Рис. 5. Упрощенный пример описания процесса
На схеме два блока ("Подготовка проекта договора" и "Включение заказа в план производства") обозначены как "подпроцессы". Это означает, что для них существуют соответствующие схемы декомпозиции - детализированные описания этих подпроцессов на отдельных страницах того же файла Visio или в других файлах.
При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.
Для бизнес-аналитиков компаний тезисы, обсуждаемые в статье, - это серьезный повод задуматься, насколько эффективны используемые ими подходы к разработке графических схем процессов организации.
Введение
Одной из важнейших целей формирования графических схем процессов является последующее их использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, которые не обучены сложным нотациям, не имеют навыков системного анализа и т.п. Для них очень важна простота и наглядность схем. Сложные, запутанные схемы, содержащие много различных условных обозначений, плохо воспринимаются людьми, что затрудняет их практическое использование. Поэтому для практических целей важным является корректный выбор и использование нотации (методики) описания процессов. По каким критериям следует выбирать такую нотацию? Как сравнивать разные нотации между собой? Рассмотрим несколько популярных нотаций и попытаемся ответить на эти вопросы.
Сравнение нотаций
Для сравнения были выбраны следующие нотации описания процессов:
- «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
- «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
- «Процедура» системы Business Studio (один из возможных вариантов представления);
- ARIS eEPC.
В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на рис. 1-4.
Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»).
На схеме рис. 1. Последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов - при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы ни то, и не другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т.п. Но на схеме процесса нужно показывать реальные объекты - процессы, выполняемые людьми, документы, информационные системы и т.п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:
а) описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
б) описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
в) описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.
Сформулируем «плюсы» и «минусы» рассмотренного выше (рис. 1.) способа использования «ромбиков».
| «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение») | |
| «Плюсы» | «Минусы» |
|
|
На рис. 2. показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме рис. 1. Схема рис. 2. выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности, эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.
Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»).
«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 2., показаны ниже.
В целом, применение схем в формате, подобном представленному на рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.
На рис. 3. представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы не стандартным образом - не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т.п.
Второй особенностью схемы процесса, представленной на рис. 3., является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником - стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок - стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход дает возможность:
- существенно сократить количество графических элементов на схеме процесса, и при этом:
- вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем, тем не менее, полно описать процесс и выгрузить в регламент всю необходимую информацию.
«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 3., показаны ниже.
Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»).
В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на рис. 3.
На рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.
Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на рис. 1-3. Трудоемкость формирования такой схемы так же существенно выше.
В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.
Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio).
Описание процесса для целей последующей автоматизации
Интересно посмотреть на рассматриваемую схему процесса в случае, если она описана в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т.е. процессов которые поддерживает система BPM.
Своим мнением об использовании BPMN 2.0. делится А.А. Белайчук - Генеральный директор компании «Бизнес-консоль»:
На рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на рис.1: в нотации BPMN задачи изображаются прямоугольниками, развилки - ромбами, данные - пиктограммой, похожей на документ. Потоки управления - сплошные линии, потоки данных - пунктирные. Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением - «движком» BPM-системы. В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной блок-схемы. Ну а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинги . |
Рис. 5. Схема процесса в нотации BPMN 2.0.
Практика жизни
На рис. 6 показан фрагмент схемы процесса, разработанный бизнес-аналитиками вполне конкретной компании в придуманной ими нотации. Схема построена с применением принципов «Простой блок-схемы» - применяется блок «Решение» в своем классическом варианте. Кроме этого, на схеме представлено множество других условных обозначений, использованных не совсем стандартным образом.
При формировании схемы рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п.
Рассматриваемая схема не является, конечно, образцом простоты и наглядности. Но она была сформирована, чтобы донести максимум полезной информации для исполнителей процесса.
Выводы
Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.
Использование сложных, формализованных нотаций при описании процессов приводит к:
- трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
- невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
- значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
- дополнительным сложностям при документировании схем (большой объем и т.п.);
Поэтому не стоит загромождать схему процесса различными графическими элементами. Но уже если их использовать, то лучше, чтобы они несли полезную информацию для сотрудников, а не были просто следствием формального применения нотаций моделирования.
, к.т.н., доцент, Исполнительный директор ООО « », зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru
- среда общения профессионалов
При необходимости анализа различных вопросов управления организацией (предприятием) рассматриваются проблемы «мешающие жизни» компании, например:
− низкая скорость принятия решений,
− безответственность сотрудников,
− сбои в работе.
Следствием этих проблем являются:
− снижение доходности и конкурентоспособности,
− замедление развития,
− даже прекращение деятельности компании.
И, когда, собственник или руководитель в один прекрасный момент поймут, что «так работать дальше невозможно!», то возникнут вопросы: « Кто виноват? Что сделать в первую очередь?»
При этом интуитивно понятно, что для решения проблем необходимо «навести порядок»:
− описать определенным образом, в соответствии с четкими правилами, всю деятельность организации, т.к. представить все бизнес-процессы сразу невозможно;
− объяснить сотрудникам как они должны работать, к чему стремиться
Иными словами, назревшие проблемы требуют системного подхода и формализации деятельности организации - набора удобных и простых в использовании документов, определяющих, что и как должно происходить, кто за что отвечает.
Если Вы поставите себе задачу разобраться в вопросах управления досконально – это потребует достаточно серьезных затрат времени и сил, возможно, у Вас даже возникнет желание пройти дополнительное обучение. Здесь же мы ответим на некоторые реальные вопросы, которые часто задают собственники бизнеса и руководители отечественных компаний, находящихся на разных этапах своего развития.
1. Ваша компания находится в начале своего развития : она недавно вышла на рынок и только начинает его освоение. Обычно на этой стадии количество сотрудников организации невелико (до 30 человек), организационная структура не слишком формализована, уровней иерархии не больше 3, в центре внимания руководства чаще всего находится производство и продажа Продукта/Услуги.
§ отсутствие четко обозначенной стратегии дальнейшего развития (к чему и зачем идем?)
§ неопределенность в разграничении обязанностей и ответственности каждого сотрудника и целых подразделений, снижающая качество выполнения работ и вызывающая внутренние конфликты
§ возникновение серьезных проблем при смене работников даже на нижнем уровне компании, поскольку нет механизмов передачи знаний и навыков новым сотрудникам, из-за чего им приходится учиться на своих ошибках. Столкнувшись с подобной ситуацией хотя бы пару раз, руководитель неизбежно начинает задумываться над необходимостью так или иначе формализовать правила работы подчиненных, выполняющих типовые операции изо дня в день.
§ невозможность дальнейшего развития компании без привлечения дополнительных специалистов , обладающих специальными знаниями и навыками.
Регулярность проявления этих и подобных трудностей свидетельствует о необходимости формирования в организации упорядоченной и формализованной системы управления. Иными словами, система управления должна стать, во-первых, правильно организованной, и, во-вторых, одинаково понятной для всех, т.е., зафиксированной документально в точных терминах.
Можно разрабатывать регламенты и поддерживать их актуальность вручную, однако через некоторое время это станет затратной пыткой. Эту задачу быстрее и проще решать путем построения бизнес-модели, которая обеспечит основу для развития компании в будущем.
Помимо того, что разработка бизнес-модели – занятие само по себе полезное и интересное, ряд положительных эффектов Вы сможете почувствовать достаточно быстро:
1. В процессе описания деятельности компании Вы начинаете лучше понимать, как же реально работает компания, т.е., как проходят в ней основные процессы. Велика вероятность, что уже на этом этапе начнут возникать идеи по системному улучшению работы .
2. Результатом описания является набор документов (регламенты процессов, должностные инструкции, положения о подразделениях и др.), который фактически фиксирует Вашу технологию выполнения работ . Впоследствии ее удобно использовать в случае необходимости оперативно подготовить персонал (если сотрудник уходит, обучить нового становится значительно проще).
3. Когда ясно представлена технология выполнения работ, руководителю оказывается гораздо проще разграничить сферы ответственности между сотрудниками.
4. В целом наличие реальной рабочей бизнес-модели повышает управляемость компании и эффективность использования ее ресурсов : если модель непрерывно актуализируется, то руководитель имеет возможность «держать руку на пульсе» компании, контролируя соответствие ее организационной структуры и распределения ресурсов реальным задачам.
В принципе, построить бизнес-модель небольшой компании можно «на коленке», используя привычные инструменты MS Office и широко применяемый для работы с графикой MS Visio. Однако, в дальнейшем, при развитии компании, Вам однозначно будет необходимо вносить изменения и дополнения в созданную путем проб и ошибок модель, причем, чем динамичнее развивается фирма, тем больше исправлений придется делать в разнообразных схемах и таблицах, а значит, затрачивать на это все больше времени. Поддерживать актуальность модели намного удобнее, если она изначально строится в специальной среде, предназначенной для бизнес-моделирования.
Большинство руководителей компаний-лидеров своих рынков, с успехом применяющих технологии бизнес-моделирования, признают: решив начать преобразования в своих организациях, они не предполагали, что начальный этап будет требовать сильной воли - приходится перестраивать не только собственные представления и стереотипы, но и мышление коллег и подчиненных, систему оценки их деятельности, привычную организационную структуру. Однако, проявив упорство и преодолев сиюминутное желание бросить проект, руководитель получает удобный инструмент для наведения порядка в своем бизнесе. Дополнительным «бонусом» для тех, кто в самом начале формирования организации не пожалел времени и сил на ее проектирование, является возможность избежать многих проблем на более поздних стадиях развития, а значит, значительное повышение шансов на успех в конкурентной борьбе.
В частности, формализация стратегии и описание бизнес-процессов компании позволяет сфокусировать внимание руководства на результатах деятельности организации. Понимая бизнес-процесс как набор действий, который выполняется в компании для получения заданного результата , а всю деятельность компании рассматривая как совокупность некоторого количества бизнес-процессов, процессный подход позволяет избежать чрезмерного разрастания численности персонала и снижает вероятность внутренней конкуренции между подразделениями организации.
2. Компания прошла начальный этап и активно растет , в ней появляется все больше функциональных подразделений и уровней управления, количество сотрудников таково, что высшее руководство уже не знакомо с каждым лично.
На практике в компаниях, где работает более 50 человек, чаще всего приходится сталкиваться с функционально-иерархической системой управления. Суть ее можно кратко охарактеризовать как выделение в деятельности предприятия некоторого количества функциональных областей и построение в соответствии с ними системы управления. Причем, по мере роста организации, в каждой из функциональных областей выстраивается своя иерархия управленцев – от руководителя (своего рода, «эксперта» в данной области) до рядового исполнителя, причем уровней этой иерархии тем больше, чем крупнее организация. И если поначалу вся система функционирует более-менее успешно, обеспечивая организации управляемость, то по мере роста компании ее эффективность неизбежно снижается. Это обусловлено спецификой принятия решений в системе, когда для рассмотрения проблемы со всех сторон необходимо взаимодействие всех «экспертов» по различным функциональным направлениям. Пока уровней иерархии в подразделениях немного, взаимодействие организуется достаточно оперативно, но вот с ростом организации время, затрачиваемое на принятие решений, превышает все разумные пределы. Результатом этого является перенос ВСЕХ решений на самый высокий уровень и глобальное снижение управляемости.
Возможные проблемы, которые заставляют задуматься об оптимизации управления:
§ Решение оперативных вопросов занимает все рабочее время руководителя
§ Рост штата компании опережает рост выручки
§ Конкуренция на рынке вынуждает искать резервы снижения себестоимости продукции
§ Каждое из функциональных подразделений компании «живет своей жизнью», координация между ними происходит только на самом верхнем уровне – на уровне директора.
На этом этапе руководству компании уже крайне трудно обойтись без четко оформленной модели системы управления, поскольку структура компании и информационные потоки в ней достаточно сложны, и управлять ими «по наитию» становится невозможно. При этом простое отображение иерархической функциональной структуры компании на листе бумаги, к сожалению, мало что дает для повышения эффективности ее деятельности. Особенно ярко проблемы функционального управления проявляются в крупных компаниях в период внешней нестабильности, когда скорость принятия решений становится критической характеристикой системы.
Решением проблем, присущих функциональному управлению, является переход к процессному управлению: всю деятельность, безотносительно того, к какому функциональному признаку она относится, группируют в смешанные подразделения , где каждый исполнитель отвечает за свой блок операций. Принципиальным различием этих подходов является переход от управления ФУНКЦИОНИРОВАНИЕМ организации (и ее структурных подразделений, объединенных на основе ПРЕДМЕТА деятельности: бухгалтерия, юротдел, снабжение, сбыт и т.п.) к управлению БИЗНЕС-ПРОЦЕССАМИ на основе РЕЗУЛЬТАТОВ деятельности. Таким образом, фокус внимания смещается в сторону эффективности работы организации . При этом все возможные ситуации при выполнении бизнес-процессов максимально подробно описываются, поскольку на практике 80% возникающих ситуаций являются типовыми, и для них целесообразно создавать подробный регламент деятельности. В этом случае персонал в типовых ситуациях может действовать максимально эффективным образом и, что особенно важно, самостоятельно, т.е., без участия руководителя . Фактически, руководитель включается в процесс только при возникновении нестандартной ситуации, действия в которой не регламентированы.
Благодаря переходу к управлению процессами компаниям с большим масштабом операций удается систематизировать свою деятельность, получив выигрыш сразу по двум направлениям:
1. Сокращается количество уровней иерархии, поскольку структура управления строится в соответствии со структурой процессов, а их на практике крайне редко бывает больше 5-6
2. Нормы управляемости при процессном подходе выше в 2-3 раза, поскольку управление заключается в координации сотрудников, и включении в процесс только при отклонении от его обычного протекания.
Чтобы реорганизовать систему управления на основе процессного подхода, руководству необходимо решить вопрос о проектировании новой системы, причем направление этого проектирования – сверху вниз , т.е. первоначально определяются стратегические цели и задачи организации, показатели их достижения, и на этой основе строится система процессов. Исходя из процессов, формируется организационная структура. Существенно уменьшить трудоемкость и ускорить проектирование позволяет использование современного программного обеспечения соответствующего назначения, в частности, системы бизнес-моделирования Business Studio. Кроме того, эта система позволяет не просто подготовить реорганизацию, но и осуществлять поддержку внедрения и последующего сопровождения процессного управления.
3. Организация вышла на новый этап своего развития: Вы открываете филиалы и превращаетесь в сетевую структуру.
Иногда развитие компании происходит настолько динамично, что она не успевает трансформировать систему управления. Обычно это происходит на быстрорастущих рынках при благоприятно складывающейся конъюнктуре.
Принимая решения решение об открытии удаленных подразделений, нельзя недооценивать значение внутренней готовности компании к такому шагу. Не секрет, что одни компании успешно воспроизводят и развивают бизнес вне зависимости от региона, тогда как у других многие филиалы убыточны.
Дело в том, что методы и технологии функционального управления, до определенного момента эффективные для «простого бизнеса», не могут работать на сетевых структурах.
Оценку готовности компании открывать региональные подразделения обычно проводят по следующим уровням:
§ управленческом;
§ финансовом;
§ маркетинговом;
§ процессном
Если управляемая по функционально-иерархическому принципу компания начинает формировать сеть – переход к процессному управлению становится практически неизбежным, т.к. серьезный масштаб задач и проблемы дистанционного управления бизнесом делают внедрение методик регулярного менеджмента настоятельной необходимостью.
Возможные проблемы, которые заставляют задуматься об оптимизации управления:
§ Отсутствие необходимой для быстрого старта филиалов формализованной эффективной технологии деятельности
§ Невозможность (либо высокая затратность) контроля всех аспектов деятельности дочерних подразделений
Обычно при открытии филиалов оптимальный со всех точек зрения путь - перенести туда уже наработанные технологии деятельности (да-да, те самые технологии, которые Вы получаете при описании и оптимизации бизнес-процессов организации). Это позволяет эффективно применить имеющийся опыт и «тиражировать» его с минимальными проблемами: ведь если технология деятельности не формализована, руководитель вынужден лично заниматься организацией филиала либо выделять для этого максимально компетентного сотрудника. А если открыть нужно не один и не два филиала, да еще в короткие сроки? Наличие бизнес-модели в этом случае решает немалую часть организационных вопросов.
Далее, просто открыть филиалы – это только первый шаг, и планируя такой путь развития, нужно отдавать себе отчет в том, что сетью придется управлять. Эффективное управление сетью филиалов невозможно без наличия у них высокой степени самостоятельности для адаптации к разнообразным внешним условиям. Корпоративный центр при этом выступает исключительно как координирующий орган, контролирующий финансовые и товарно-материальные потоки. Поэтому управление сетью сродни управлению процессами, когда внимание руководства сосредоточено не на функционировании, а на результатах деятельности.
Как показывает практика, большинство компаний с успешной региональной стратегией используют несколько инструментов:
1. оптимальная структура – гибкая и отвечающая требованиям рынка;
2. правильно выбранная модель управления филиалами , определяющая меру их самостоятельности;
3. детально проработанные инструкции, регламенты и документы , определяющие работу
4. филиальной сети.
В реальной рыночной ситуации корпоративный центр должен сформировать такую систему управления, которая, с одной стороны, обеспечит достаточно высокий уровень регламентации деятельности филиалов, а с другой, предоставит возможности гибкого реагирования на изменения рыночной конъюнктуры.
Каким образом определить оптимальную степень стандартизации отдельных процессов?
Одним из вариантов может быть использование такого алгоритма: определяя стандартные процессы, компания решает задачу по оптимальному распределению функций между центром и филиалами. Таким образом, каждый регламентированный процесс компании (управленческий, основной, вспомогательный), распределяется согласно правилу: выполняется только в центре , выполняется только в филиале , выполняется совместно . Очевидно, что процессы, выполняемые только в центре, являются стандартными и должны быть регламентированы. При выполнении процессов на обоих уровнях обычно бывает целесообразно также их стандартизировать и регламентировать. Для процессов уровня филиала возможно либо стандартизировать выполнение процесса – если все филиалы похожи, либо сделать стандартной отчетность по процессу – если выполнение процесса в разных филиалах может существенно отличаться.
В результате компания получает перечень процессов, которые нужно стандартизировать.
Чтобы успешно провести всю подготовительную работу и построить эффективную сетевую структуру, необходимо на основе четко определенных стратегических целей сформировать процессную систему управления с оптимальным распределением полномочий и ответственности между корпоративным центром и филиалами. Применение процессного подхода в данном случае диктуется логикой развития организации и необходимостью обеспечить ее адекватным управлением.
Таким образом, на какой бы стадии развития не находилась компания, чем раньше ее руководство и собственник обращают внимание на построение системы управления с использованием процессного подхода, тем больше вероятность опередить конкурентов и предупредить возникновение типичных «болезней роста» .
Проектирование системы управления, ее внедрение и последующее правильное функционирование существенно упрощается при использовании специализированного программного обеспечения для бизнес-моделирования.
Похожая информация.
Схема бизнес процесса отражает его суть и механизм работы. Создать схему, само по себе не очень сложно. Достаточно понимать на какие вопросы должна отвечать схема и придерживаться алгоритма создания. Если вам не терпится приступить к созданию моделей или вы не знаете с чего начать – эта статья для вас.
Хочу напомнить, что перед тем, как начать описывать бизнес процессы, необходимо . компании – платформа, с которой необходимо начинать.
Алгоритм, который я здесь привожу, будет полезен тем, кто только собирается описывать бизнес-процессы. Для тех, кто проходил у меня обучение, статья будет отличным повторением пройденного))))
Схема бизнес процесса – инструкция для нетерпеливых
1 – Задайте границы процесса
Каждый бизнес процесс начинается и заканчивается с события. Первое, что необходимо сделать, это обозначить события начала и окончания.
2 – Нарисуйте основные блоки процесса
Расположите основные блоки (подпроцессы, операции) , в том порядке, в котором они выполняются.
Не усложняйте схему на данном этапе. Отобразите блоки так, будто процесс выполняется идельно.
3 – Добавьте развилки и другие события
А вот теперь пора немного усложнить. Добавьте основные варинты развития процесса и основные промежуточные события. Дополните схему недостающими операциями.
4 – Обозначьте роли участников процесса
В бизнес процессах нет должностей или конкретных сотрудников. Вместо этого используется понятие – роль. Одни сотрудник может выполнять множество ролей. Одну роль может выполнять множество сотрудников. Из набора ролей складывается должность.
По необходимости добавляйте недостающие операции.
5 – Разместите на схеме документы
Документ, это не обязательно официальная бумага с семью подписями. С точки зрения управления бизнес процессами, документ это информация на любом информационном носителе. Электронное письмо, доклад, презентация, СМС – все это документы.
Иногда необходимо отобразить промежуточные продукты. Это заготовки, полуфабрикаты или просто важные части работы, которые переходят из одного блока процесса в другой. Добавьте их на этом этапе. По необходимости.
6 – Добавьте используемые программы и базы данных
Процесс должен отражать, какие программы и базы данных в нем используются.
7 – Расположите инструменты и материалы
Если в процессе используются инструменты и/или материалы, это также нужно отобразить. Основные моменты можно обозначить на схеме бизнес-процесса. Детальное описание лучше дать в комментариях и специальных разделах описания. Отличный вариант – составить схему, ориентированную именно на использование инструментов и материалов. В подобной схеме упор делается не на поток работ, а на то, как, в каком количестве и какие материалы используются в бизнес-процессе.
8 – Определите показатели эффективности в бизнес-процессе
Расположите на схеме бизне-процесса показатели эффективности, которые тем или иным способом учитываются в системе.
9 – Свяжите полученную схему с другими процессами
Каждый бизнес-процесс, это лишь часть большой системы. Все процессы связаны между собой. По сути, связь является чем то, чем процесс обменивается с другими процессами. Обратите внимание – необходимо указать ппроцессы, с которыми связан текущий процесс и то, чем они обмениваются.
10 – Проверьте полученную модель бизнес-процесса
В принципе, схема готова. Схема бизнес-процесса должна отвечать на следующие вопросы:
- С чего начинается и чем заканчивается бизнес-процесс?
- С какими процассми он связан? Чем обменивается?
- Какие операции выполняются? В каком порядке?
- Кто выполняет операции в процессе?
- Какие документы используются и появляются в процессе? В каких операция эти жокументы используются/появляются?
- Какие интсрументы, материалы, ПО и базы данных используются в процессе и в каких операциях?
- Какие показатели эффективности и где именно фиксируются в бизнес-процессе?
Качественно подготовленная схема должна быть проста для восприятия и достаточно информативна.
Схема бизнес-процесса должна быть понятна «человеку с улицы».
Схема бизнес процесса, на этапе описания, должна отражать то, как процесс выполняется в реальной жизни.
Данный алгоритм, позволит вам довольно просто и быстро описать необходимые бизнес-процессы. Далее я буду подробно рассказывать об описании бизнес-процессов. Оставайтесь на связи.
Открытие бизнеса
