Информативность графических схем процессов

Лекция 30 Информативность графических схем процессов Информативность графических схем процессов Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение») Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение») Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение») Схема процесса в нотации ARIS eEPC Формирование регламентирующих документов на основе описания процессов Информативность графических схем процессов Одна из важнейших целей формирования графических схем процессов – их последующее использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, не обученные сложным нотациям, не имеющие навыков системного анализа. Для них очень важны простота и наглядность схем. Сложные, запутанные схемы, содержащие массу условных обозначений, плохо воспринимаются, и это затрудняет их практическое использование. Поэтому очень важен корректный выбор и использование нотации описания процессов. По каким критериям следует выбирать, как сравнивать разные нотации между собой? Рассмотрим следующие популярные нотации и попытаемся ответить на эти вопросы: • «Простая блок-схема» (с отображением движения документов, с использованием блока «решение»); • «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»); • «Процедура» системы Business Studio (один из возможных вариантов представления); • ARIS eEPC. В качестве тестового примера выбран простой и понятный процесс. Результаты его описания представлены на рис. 1–5. Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение») 1 Анализ доставок за предыдущий день. Корректировка графика доставки на следующий 2 На рис. 1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой подход к использованию ромбиков – весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты – операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме? Вместо этого можно: • описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса; • описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже; • описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса. Сформулируем плюсы и минусы рассмотренного использования ромбиков. (рис. 1) способа Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение») На рисунке 2 приведен пример того же процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на 3 этой схеме на 24 графических элемента меньше, чем на рисунке 1. Схема на рис.2 выглядит гораздо проще: от графических элементов не рябит в глазах,а с точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, то, комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. Рисунок 2.- Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение») Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день 4 5 Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение») Применение схем в таком же формате, как представленный на рис. 2, удобно как для разработчиков (бизнес-аналитиков), так и для сотрудников. На рисунке .3 показана схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение»[11] использованы нестандартным образом – не как графический элемент для отображения ветвления (оператор логики, развилка), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию: описание, начало, завершение,требование к срокам и т. п. Рис. 3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение») Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день 6 7 Вторая особенность схемы процесса на рис 3 – применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником – стрелку «Связь предшествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок – стрелками «Связь предшествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах. Таким образом, не загромождая схему лишними элементами, мы можем полностью описать процесс и выгрузить в регламент всю необходимую информацию. Тот факт, что название стрелки в Business Studio не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, – «Сформировать отчет по инкассации за день». Плюсы и минусы графического представления процесса на рис. 3 показаны ниже. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение») Обратите внимание, что в Business Studio нотация «Процедура» может использоваться по-разному. На рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий. 8 Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика. Рис.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio) OR – неисключающее логическое «ИЛИ»; XOR – исключающее логическое «ИЛИ». 9 10 Трудоемкость ее формирования также гораздо выше ,чем на предыдущих рисунках. Схема процесса в нотации ARIS eEPC (построена в Business Studio) На рис. 5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 1:в нотации BPMN задачи изображаются прямоугольниками, развилки – ромбами, данные – пиктограммой, похожей на документ. Потоки управления – сплошные линии, потоки данных – пунктирные. Рис. 5. Схема процесса в нотации BPMN 2.0 11 12 Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: лишь один вид развилок из пяти имеющихся и один вид задач из восьми. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но и несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, это более строгая нотация: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована и на то, что ее будут читать люди, и на непосредственное исполнение специальным программным обеспечением – движком BPMсистемы. В то же время, как показывает данный пример, при использовании ограниченного подмножества BPMN оказывается не сложнее привычной блок-схемы. При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к: • трудностям при интерпретации схем рядовыми сотрудниками; • невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение; • значительному увеличению формирование схем; трудозатрат бизнес-аналитиков на • дополнительным сложностям при документировании схем (например, большой объем). Нотация моделирования должна соответствовать уровню процессной культуры организации. Если сотрудники компании делают первые шаги в области описания процессов, то желательно выбрать простую, наглядную и удобную нотацию. Формирование регламентирующих документов на основе описания процессов После того как процессы описаны в среде моделирования (говоря шире – создана объектная модель организации), можно и нужно использовать эту информацию для регламентации деятельности. 13 В этом параграфе приведен пример использования среды моделирования Business Studio для формирования регламентирующих документов. Рассматриваются процессы управления транспортным отделом одной из российских компаний С технической точки зрения точно так же можно описывать любые процессы и другие объекты регламентации (подразделения, должности). На рис. 6 показана структура процессов управления транспортным отделом (ТО) крупной торговой компании, разработанная в рамках проекта Рис. 6- Структура процессов управления транспортным отделом Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск). Описание процессов выполнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам 14 Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Business Studio, но в рамках предложенной задачи ее использование вполне адекватно. Для описания процессов внутри контуров управления использована нотация «Процедура». На рис. 6 показана кросс-функциональная схема процесса «Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем. Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты: • содержание деятельности; • начало процесса; • результат процесса. Этих атрибутов на первых порах вполне достаточно, но можно использовать и другие (в том числе создавать новые, необходимые бизнесаналитику). Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на трех уровнях: 1. описание контура управления; 2. описание процесса в контуре управления; 3. описание операций процесса (в табличной форме) и схему процесса. На рис.7 показана работа мастера отчетов среды моделирования Business Studio. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета – регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущен на выполнение для объекта «Управление ТО» (рис. 8.). Рис7- Мастер отчетов Business Studio. Разработка регламента управления на трех уровнях 15 Рис.8.- Запуск отчета для объекта «Управление ТО» 16 Отчет, запущенный для объекта модели «Управление ТО», сгенерировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. 9). Рис. 9 - Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business Studio Рис. 10 Вывод информации о процессе управления в табличной и графической форме 17 На рис. 10 показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе формата А4. Видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы: • номер операции; • наименование операции; • исполнитель; • инициирующие события; • входящие документы; • описание операции; • завершающие события; • исходящие документы. Графическая схема процесса представлена в кросс-функциональном виде. Объем регламента процесса управления составил для процесса «Управления ТО» около 70 страниц в MS Word, что совсем немного для такого значительного количества процессов. 18 Среда моделирования Business Studio позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе: • регламенты выполнения процессов; • положения о подразделениях; • должностные инструкции (на должности и роли). Литература: 1.Репин В.В.,Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов.- М.: РИА «Стандарты икачество», 2004.408 с.. 2.Репин, В.В Бизнес-процессы: моделирование, внедрение , управление 3. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов. – М.: Альпина Паблишер, 2012. 4. Репин В. В. Бизнес-процессы компании: регламентация. М.: Стандартыи качество, 2007. построение, анализ, 5. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007. 6. Бьёрн А. Бизнес-процессы. Инструменты совершенствования. – М.: Стандарты и качество, 2003. 7. Де Гиус А. Живая компания. Рост, научение и долгожительство в деловой среде. – СПб.:Стокгольмская школа экономики в Санкт-Петербурге, 2004. 8. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. –М.: Стандарты и качество, 2004. 9. Руководство пользователя Business Studio (2012). 10. Руководство технического специалиста Business Studio (2012). 11. Создание пользовательских отчетов Business Studio. Методика (2012). 12. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler. – М.: Диалог-МИФИ, 2008. 19 13. Черемных С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем: IDEF-технологии. – М.:Финансы и статистика, 2001. 14. Моделирование бизнеса. Методология ARIS. Практическое руководство / М. Каменнова [и др]. –М.: Серебряные нити, 2001. 15. Silver B. BPMN Method and Style: A levels-based methodology for BPM process modeling andimprovement using BPMN 2.0. – Cody-Cassidy, 2009. 20