Описание архитектуры и бизнес-процессов с помощью Графолайт

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

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

Что нужно описывать

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

Согласно ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011:

Архитектура (системы) — основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.

Как можно описать архитектуру

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

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

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

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

• Абстрактные модели данных для описания информационных структур, воплощаемых в дальнейшем в базы данных. Для изображения этого слоя Grapholite поддерживает ER-диаграммы.
• Схемы баз данных, отражающие структуру БД (таблицы, представления, отношения между ними и т. п.). В Grapholite можно проектировать схемы баз данных, используя диаграмму классов UML.
• Организационные структуры , отражающие административную иерархию предприятия. Реализуется с использованием организационной диаграммы (простейшие структуры), либо при помощи базовых элементов блок-схем (флоучартов), с помощью которых можно отобразить любые аспекты отношений между участниками предприятия.
• Бизнес-процессы, наиболее важная часть описания архитектуры. Для их отображения в Grapholite имеется несколько возможностей: блок-схемы, кросс-функциональные диаграммы (дорожки), EPC диаграммы, UML и BPMN.

В рамках описания архитектуры предприятия последний пункт представляет наибольший интерес и на нем стоит остановиться и разобрать более детально.

Языки (нотации) для описания корпоративной архитектуры

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

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

Кросс-функциональная диаграмма

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

Шаблон IDEF0, построенный в Grapholite из обычного прямоугольника и стрелок

ARIS eEPC (extended event driven process chain) — мощная, оснащенная и технологичная методология. Несмотря на свой возраст, она все еще находит свое применение. Grapholite поддерживает создание EPC диаграмм «из коробки».

Пример EPC-диаграммы

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

Пример диаграммы UML Activity (деятельности)

BPMN (Business Process Model and Notation) в настоящее время является наиболее подходящим решением для описания бизнес-процессов. Эта методология (и нотация) моделирования — отличная альтернатива конкурирующим между собой «частным» решениям. Это открытый, публичный стандарт. Grapholite поддерживает как предыдущую версию BPMN 1.2, так и новую 2.0.

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

grapholite.ru

Описание процессов при помощи блок-схем

Простейшим, но практически важным способом описания бизнес-процес­сов является методика составления блок-схем. Данный подход имеет много об­щего с графическими языками описания алгоритмов программного обеспече­ния. С точки зрения методологии формирование блок-схем проводится так же, как в нотации 1DEF3, хотя для упрощения символы логики можно опустить. Для разработки блок-схем используют стандартные офисные программные про­дукты, например MS Word или Visio. Основные графические объекты языка описания процессов при помощи блок-схем представлены в табл. 2.3.

Таблица 2.3 Графические объекты блок-схемы процесса

102_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению

Пример описания процесса при помощи блок-схем представлен на рис. 2.44.

Блок-схемы удобно строить на листе, располагая вертикально. При этом спра­ва от блок-схемы процесса остается место для описания выполняемых функ­ций, результатов выполнения функций, исполнителей, номеров входящих и ис-

Рис. 2.44. Пример блок-схемы процесса.

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

Глава 2 Выбор методологии описания бизнес-процессов 103

Описание процессов при помощи блок-схем имеет одно очень существен­ное преимущество — простота и доступность для восприятия руководителями и специалистами предприятия. Затраты на обучение исполнителей чтению блок-схем являются минимальными. Кроме того, для формирования блок-схем не требуются специализированные дорогостоящие программные продукты.

Сравнительный анализ нотаций ARIS и IDEF. Выбор нотации для описания процессов

Нотации IDEF0 и ARIS VAD

В табл. 2.4 приведен сравнительный анализ нотаций моделирования бизнес-процессов ARIS VAD и IDEFO. Обе эти нотации предназначены для описания процессов организации на верхнем уровне.

Таблица 2.4 Сравнение нотаций IDEFO и ARIS VAD

 

№	Критерии	Нотация
п.п.	сравнения	ARIS VAD	IDEFO
	Принцип	Временная последовательность	Принцип доминирования
	построения	выполнения процедур.	(см. стандарт IDEF0).
	диаграммы	Используется тип связи	Функции связаны потоками
		is predecessor of	данных и материальных
			ресурсов
	Описание процедуры	Объект на диаграмме	Объект на диаграмме
	процесса
	Использование	Не регламентировано. Стороны	Регламентировано. Каждая
	сторон объекта	объекта Value-added process chain	сторона объекта Activity
	«процесса»	не имеют специального назначения	(функция, процесс) имеет
	для отображения		специальный смысл:
	различных видов		входы, выходы,
	входов		управление, механизмы
	Входящий	Не используется специальный	Стрелка входа, стрелка
	документ	объект для отображения документов.	управления
		Может использоваться объект
		Technical Term
	Входящая	Используется отдельный объект	Стрелка входа, стрелка
	информация	Cluster. Может быть использован	управления
		объект Technical Term
	Исходящий	Не используется специальный	Стрелка выхода
	документ	объект для отображения документов
		Может использоваться объект
		Technical Term
	Исходящая	Используется отдельный объект	Стрелка выхода
	информация	Cluster. Может быть использован
		объект Technical Term

104___________________________ В.В. Релин, В.Г. Елиферов. Процессный подход к управлению

Таблица 2.4 (окончание)

 

N9	Критерии	Нотация
п.п.	сравнения	ARIS VAD	IDEF0
	Исполнитель	Используются отдельные объекты	Стрелка механизма
	процесса	для описания: Position,
		Organizational Unit
	Используемое	Используется отдельный объект	Стрелка механизма
	оборудование	для описания: Product, Product/Service.
		Может быть использован объект
		Technical term
	Управление	Нет средств для отображения	Стрелка управления
	процессом	управления процессом.	(стрелка сверху)
		Возможно косвенное отображение
		управления при помощи входящих
		документов, информации
	Обратная связь	Не может быть отображена.	Стрелка управления.
	по управлению/	Есть возможность однократно	(Есть требования
	контролю	показать обратную связь типа	по отображению обратных
		is predecessor of	связей по управлению)
	Обратная связь	Не может быть отображена.	Стрелка входа
	по входу	Есть возможность однократно	(Есть требования
		показать обратную связь типа	по отображению обратных
		is predecessor of	связей по информации)
	Миграция потоков	Принципиально невозможна	Предусмотрена
	данных и ресурсов		миграция стрелок
	при декомпозиции		вниз и вверх
	Туннелирование	Принципиально невозможна	Предусмотрено
	потоков данных		туннелирование стрелок
	и ресурсов		вверх и вниз
	при декомпозиции
	Автоматическая	Не предусмотрена	Предусмотрена
	нумерация узлов
	(процессов)
	Стандартная форма	Не регламентирована.	Регламентирована.
	представления	Нет рекомендаций	Рамка IDEF0.
	диаграммы	по форматированию моделей	Развитая система
	процесса при	ARIS VAD при документировании	обозначений на диаграмме
	документировании
	Ограничения по ко-	Количество объектов	Рекомендовано не более
	личеству объектов	не ограничено	шести. Общее количество
	на диаграмме		не ограничено
	процесса

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

Глава 2 Выбор методологии описания бизнес-процессов______________________ 105

вательность процедур во времени — больше подходит для создания моделей клас­са Work Row (например, моделей IDEF3). Метод ARIS VAD лишен важнейших практически необходимых инструментов, таких как отображение входов управле­ния процессом, возможность описания обратных связей, миграция связей (вхо­дов/выходов процесса) при декомпозиции и др.

В методических материалах [6| по использованию нотации ARIS VAD можно найти следующие рекомендации. На первом этапе работы формируют модели верхнего уровня в нотации ARIS VAD. Затем эти модели декомпозируют в нота­ции ARIS eEPC. Но допускается также создание нескольких уровней декомпо­зиции в нотации ARIS VAD, что исключительно неудобно, так как декомпози­руемые модели никак не связаны с моделями верхнего уровня (кроме формаль­ной принадлежности). При дальнейшеи декомпозиции процессов в нотации ARIS eEPC приходится «вручную» заботиться о связности создаваемых моделей, так как на верхнем уровне составляющие процессов в нотации ARIS VAD были слабо взаимоувязаны между собой через потоки информации и ресурсов, носи­ли чисто иллюстративный характер, как показано на рис. 2.45.

Справедливости ради следует отметить, что при декомпозиции процессов из нотации IDEF0 в нотацию IDEF3 мы сталкиваемся с теми же проблемами. Но

106_________________________________ В.В. Репин, В.Г Елиферов Процессный подход к управлению

здесь мы делаем акцент на том, что описание процессов в ARIS VAD на верхнем уровне существенно менее удобно, чем в IDEF0. Кроме того, работа в ARIS VAD является значительно более трудоемкой. Так, количество операций по ото­бражению процесса в ARIS VAD увеличиваются в два и более раз, чем при создании аналогичной модели в IDEF0. На рис. 2.46 и 2.47 приводится поясне­ние данной оценки трудоемкости.

Видно, что для отображения простейшего процесса из двух функций в IDEF0, включающего один поток материальных ресурсов и две обратных связи, потре­бовалось отображение пяти объектов (две функции и три стрелки). В нотации ARIS VAD для отображения рассматриваемого процесса потребовалось 12 объек­тов (два объекта Value-added process chain, два — Cluster, один — Technical term.

Глава 2 Выбор методологии описания бизнес-процессов 107

семь стрелок). Таким образом, трудоемкость описания процесса в нотации ARIS VAD существенно больше, а это отражается на времени выполнения проекта и величине требуемых ресурсов.

Если в организации поставлена задача описания деятельности организа­ции на верхнем уровне, можно решать эту задачу двумя путями, как показано в табл. 2.5.

Таблица 2.5 Способы описания бизнес-процессов верхнего уровня

 

Способ блок-схем	Комплексный подход
Данный подход предполагает быстрое	Использование методологии IDEF0 является
эскизное описание схем бизнес-процессов	оптимальным вариантом для описания
верхнего уровня. Не требуется создавать	бизнес-процессов на верхнем уровне, так как
комплексную модель. При такой постановке	позволяет отобразить информационные
задачи можно использовать простейшие	и материальные потоки, требования
средства визуализации блок-схем процессов,	к персоналу и инфраструктуре, управляющие
например MS Word или Visio.	воздействия и обратные связи. Методология
Использование IDEF0 не рекомендуется,	соответствует определению процесса
так как получаемые схемы процессов	в МС ИСО 9000:2000.
являются слишком сложными.	Использование ARIS VAD не обеспечивает
Использование ARIS VAD возможно,	получения комплексных, связных моделей
но не дает существенных преимуществ	верхнего уровня, поэтому не рекомендуется
	для создания моделей такого типа

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

Нотации IDEF3 и ARIS еЕРС

Втабл. 2.6 приводится сравнение нотаций IDEF3 и ARIS еЕРС. Нотация ARIS еЕРС является более новой с точки зрения времени ее появления, но фактически она — расширение IDEF3 за счет использования объекта «Собы­тие» (Event).

Таблица 2.6 Сравнение нотаций IDEF3 и ARIS еЕРС

 

 

 

№ п.п.	Критерии сравнения	Нотация
ARIS еЕРС	IDEF3
	Принцип построения диаграммы	Временная последовательность выполнения процедур	Временная последовательность выполнения процедур
	Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме
	Входящий документ	Используется отдельный объект для описания типа Document. Могут быть использованы другие объекты	Используется отдельный объект для описания. (Объект ссылки типа Objec или стрелка Object flow)

108_________________________________ В.В. Репин, В.Г. Епиферов Процессный подход к управлению

Таблица 2.6 (окончание)

 

№	Критерии	Нотация
п.п.	сравнения	ARIS еЕРС	IDEF3
	Входящая	Используется отдельный	Используется отдельный
	информация	объект для описания типа	объект для описания.
		Cluster и Technical term	(Объект ссылки типа Object
			или стрелка Object flow)
	Исходящий	Используется отдельный	Используется отдельный
	документ	объект для описания типа	объект для описания.
		Document.	(Объект ссылки типа Object
		Могут использоваться	или стрелка Object flow)
		другие объекты
	Исходящая	Используется отдельный	Используется отдельный
	информация	объект для описания типа	объект для описания
		Cluster и Technical term	(Объект ссылки типа Object
			или стрелка Object flow)
	Исполнитель	Используется отдельный	Нет. (Может быть отражен
	процедуры	объект для описания типа	в модели только привязкой
		Position, Organizational unit и др.	объекта ссылки)
	Используемое	Используется отдельный	Нет. (может быть отражен
	оборудование	объект для описания	в модели только привязкой
			объекта ссылки)
	Связь диаграмм	Для привязки к другим	Для привязки к другим
	при декомпозиции	диаграммам используется	диаграммам используется
		объект Process interface	объект ссылки
	Визуальное	Интуитивно понятные,	Сложно воспринимаются
	восприятие	легко читаемые диаграммы
	диаграмм процессов
	Стандартная форма	Не регламентирована.	Регламентирована.
	представления	Нет рекомендаций	Рамка IDEF0.
	диаграммы процесса	по форматированию моделей	Развитая система обозначений
	при	ARIS еЕРС при	на диаграмме
	документировании	документировании
	Ограничения по ко-	Количество объектов	Рекомендовано не более
	личеству объектов	не ограничено	шести. Общее количество
	на диаграмме		не ограничено
	процесса

Строго говоря, формально нотации ARIS еЕРС и IDEF3 не отличаются друг от друга, так как базируются на одних и тех же принципах моделирования пото­ков работ (Work Flow), предполагающих использование символов логики («пе­рекрестков» в IDEF3). При помощи этих символов отображаются ветвления и слияния потоков работ в рамках бизнес-процесса.

Возможность моделирования событий в ARIS еЕРС позволяет создавать бо­лее корректные и подробные описания процессов. При этом, однако, суще­ственно повышается сложность и трудоемкость описания. Дополнительные пре­имущества ARIS еЕРС заключаютсяв возможности визуальногоотображения

Глава 2 Выбор методологии описания бизнес-процессов________________________ 109

входящих/исходящих документов, информации, используемой инфраструктуры и т.п. при помоши специальных объектов. К сожалению, на практике наличие таких широких возможностей по описанию процесса в ARIS еЕРС часто приво­дит к отрицательным результатам — модели становятся слишком сложными и громоздкими, неудобными для документирования. С формальной точки зре­ния нотация ARIS еЕРС является наиболее применимой для детального описа­ния процессов. С ее помощью можно эффективно описывать процессы уровня рабочих мест с целью разработки должностных и рабочих инструкции

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

Распространенная ошибка моделирования в ARIS еЕРС и IDEF3 — создание «плоских» моделей потоков работ, проходящих только через рабочие места ис­полнителей нижнего звена. Подчеркнем, что этот факт не указывает на недо­статок конкретных нотаций, а свидетельствует о некорректных методических подходах к описанию процессов организации с их использованием. К сожале­нию, в российской практике эта ошибка очень распространенна.

В нотации ARIS еЕРС и IDEF3 не заложены средства описания управляю­щих воздействий, обратных связей по управлению и информации. Поэтому при формировании моделей процессов можно использовать несколько способов от­ражения управляющих воздействий. Более корректным было бы описывать про­цессы управления отдельно.

Предположим, что мы хотим использовать схему бизнес-процесса для регла­ментации (например, в документе «Регламент выполнения бизнес-процесса»). Эта схема должна удовлетворять следующим требованиям:

1) все отображенные на схеме операции бизнес-процесса должны существо­
вать реально и быть закрепленными за конкретными исполнителями;

2) на схеме должны отображаться реальные документы, файлы и ресурсы;

3) схема процесса должна быть проста и понятна для визуального воспри­
ятия;

4) схема процесса должна быть компактной.

Эти требования означают, что строить модель бизнес-процесса имеет смысл при описании операций уровня рабочего места исполнителя, в крайнем случае — лая операций небольшого (три-четыре человека) подразделения. Более укруп­ненные модели потоков работ могут дать общую информацию о процессе, но использовать такие модели для регламентации затруднительно вследствие раз­мывания ответственности между исполнителями процесса.

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

110________________________________ В.В. Репин, В.Г. Елиферов. Процессный подход к управлению

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

На рис. 2.48 показан «объемный» бизнес-процесс. Он состоит из нескольких моделей потоков работ, сформированных для каждого уровня: исполнители, заместители руководителя, руководитель (владелец) бизнес-процесса.

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

Каким же образом увязать деятельность руководителей и исполнителей при построении моделей потоков работ (ARIS eEPC, IDEF3)? Очевидно, что сделать это можно несколькими способами. Первый и самый простой способ состоит в следующем: отдельно описываются потоки работ, выполняемых как руководите­лями, так и исполнителями. Такой подход имеет несколько недостатков, основ­ной из которых состоит в том, что взаимодействие руководителя и исполнителя становится в модели неявным, а опосредованным при помощи обратных связей по информации. Другой способ состоит в том, что при описании работ исполни­телей можно указать прямые ссылки на процессы, выполняемые руководителя­ми, или прямо отобразить их вмешательство в работу (рис. 2.49).

Глава 2 Выбор методологии описания бизнес-процессов 111

На рис. 2.49 (вверху) показана простейшаяцепочка бизнес-процесса, состо­ящая из двух операций. Предположим, что эти операции выполняются испол­нителем и требуют управления со стороны руководителя. Как мы можем ото­бразить этот факт на модели? Согласно первому предложенному выше способу, мы указываем на модели процесса обратную связь по информации. В данном примере нотация ARIS еЕРС позволяет показать входящий и исходящий доку­мент А, содержащий некоторую информацию. Документ А попадает от испол­нителя к руководителю после выполнения Функции 2, а затем может быть воз­вращен на доработку при выполнении Функции 1. При этом «где-то в другом месте» мы должны описать работу руководителя по проверке этого документа и принятию решения. Это означает, что необходимо создать модель, описываю­щую деятельность руководителя.

На рис. 2.49 приводится еще два способа «встраивания» руководителя в биз­нес-процесс. Первый из них предполагает прямое включение в процесс «Функ­ции управления», второй — в виде дополнительного события «Принято управ­ленческое решение».

Какой способ для отображения участия руководителя в бизнес-процессе выбрать? Это определяет сама организация. Можно составить схему бизнес-

11 2_________________________________ В.В, Репин, В Г, Елиферов. Процессный подход к управлению

Глава 2 Выбор методологии описания бизнес-процессов 113

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

Подводя итог, следует отметить, что формально нотация ARIS еЕРС являет­ся более удобной и проработанной, чем IDEF3. Но. к сожалению, стоимость системы ARIS Toolset, позволяющей создавать модели в ARIS еЕРС, многократ­но превышает стоимость систем, поддерживающих IDEF3.



infopedia.su

Примеры составления схем бизнес-процессов

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

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

Что такое схема бизнес-процесса и для чего она нужна?

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

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

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

Благодаря такому набору плюсов блок-схемы пользуются все большей популярностью.

Основные виды блок-схем

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

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

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

• Простая схема, без символов и диаграмм. В такой схеме используется минимум графического оформления, а информации представляется в виде коротких текстовых пояснений. Такие схемы хороши для описания процессов технического обслуживания различных механизмов или производства сборочных единиц;
• Блок-схема с использованием специальных символов позволяет отразить систему взаимосвязей между этапами более наглядно. Они несколько более сложны. Для создания такой схемы нужно использовать специальное программное обеспечение. Такой схемой можно отразить организацию учета ТМЦ на предприятии или этапы обработки продукции на предприятии общепита;
• Схемы с использованием графов приоритета. В них в виде блоков отражены задания по производству определенного товара с раскладкой по времени выполнения, а стрелками показаны переходы от одного задания к другому. Такие схемы позволяют видеть места с необходимостью приоритетного снабжения, что позволяет организации внедрять в жизнь оптимизационные решения;
• Графически-описательные представления. Эти схемы представляют бизнес-процесс в табличной форме. Такие схемы позволяют отслеживать расход времени, а значит обеспечивать оптимальную занятость персонала.

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

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

Как строится блок-схема бизнес-процесса?

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

Вот пример алгоритма построения схемы, который может становиться основой для создания большинства подобных разработок:

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

Важно! Завершающий этап работы со схемой – соотнесение ее с другими бизнес-процессами. 

Схема бизнес-процесса продажи товара

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

Грамотно продуманная схема процесса позволит сотруднику выполнять свои обязанности эффективно, а менеджеру – контролировать ход бизнес-процесса и своевременно осуществлять оптимизационные решения. Поэтому блок-схемы высоко востребованы в этой отрасли бизнеса.

Как описывать и внедрять бизнес-процессы в компании? Данное видео поможет вам в этом вопросе:

dengikupera.ru

Зачем нужно рисовать блок-схемы бизнес-процессов? Конкретный пример…

Начнем с того что BPMN, EPC и IDEF — это умные слова и не более того. Попытка описывать ими бизнес-процессы приравнивается к попытке чесания ногой за ухом…

Если специалист говорит что описал процессы и в качестве результата будет показывать мне рисованные схемы, в Visio, Aris, в нотациях BPMN, EPC или IDEF и т д, то у меня в голове сразу включает сигнал тревоги: «умник прямо по курсу, от которого надо держаться по дальше».

Почему то в сообществе «специалистов по управлению / MBA / консультантов / экспертов / программистов» — нужно подчеркнуть, сложилось мнение что описание бизнес-процессов это аля рисование схемок и произношение умных слов.

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

Вот. Выговорился )))

Этот поток «комплиментов» относится именно к специалистам по BPMN/EPC/IDEF итд, но не к нотациям как таковым. Сами нотации — есть обычный инструмент. Но как и ножом — ими нужно уметь пользоваться и понимать где это нужно. К примеру бесполезно ножом есть суп, даже если у вас очень модный нож и вам очень сильно хочется им похвастаться.

За последний год, при том что удалось описать и информатизировать порядка 100 процедур, есть регламенты, инструкции и достаточно мощная информационная система, потребность в описании блок-схемы по процессу пока выявилась всего лишь 1 раз.

Задача косалась процедуры входящих документов. Там есть проблема с контролем (как выяснилось из-за ошибки в ПО ДИРЕКТУМ), которую нужно было найти, определить, обосновать руководству и поставить задачу программистам. Вот под эту конкретную задачу и понадобилось написать схему.

Восстановим хронологию событий:

1. Поставлена цель: отказ от бумаги

2. Начали проработку нового порядка действий

3. Выяснили, что отказаться от бумаги не можем, т.к. в ДИРЕКТУМе нет контроля исполнения РКК

4. Начали думать над постановкой контроля в ДИРЕКТУМе, чтобы видеть показатели типа: «Средняя длительность исполнения входящих документов», «Доля документов выполненных в сроки». Ну и увиедть конкретные записи по нарушениям. Например: РКК №123 — нарушение срока на 5 дней. Ответственный: Петров и Сидоров

5. Пытаюсь вывести отчет. Но не тут то было. В отчете есть план.дата, но в 99% записей нет факт.даты. А как посчитать среднюю длительность? И как узнать нарушен срок или нет? Никак! И те РКК, где План.дата меньше сегодняшней даты = просрочены. Хотя люди говорят что все выполнили и нажали Выполнено.

6. Начинаем разбирать ситуацию, почему в 1% записей факт дата есть, а в 99% — нет. Выясняем, что факт.дата проставляется и не проставляется в следующих вариантах:

6.1. Факт дата проставляется, если реквизит «На контроле» = «Да», документы выполнен, отправлено задание контроль на руководителя и принято. Все!

6.2. А не проставляется во всех остальных случаях, включая:

6.2.1. Реквизит «На контроле» = «Да», но руководитель не принял задание-контроль. Факт дата = Пусто. Документ считается просроченным.

6.2.2. Реквизит «На контроле» = «Нет». В этом случае ПО вообще не ставит Факт.дату. Все поручения обозначаются как просроченные.

7. И тут получаем большую проблему, в части п.6.1 — руководство, которое отвечает за процедурный тип деятельности, вынуждено обрабатывать очень большой поток входящи документов (ставить резолюции), и кроме того что человеку идет несколько десятков входящих на резолюцию, сюда же наваливается нагрузка этих же документов по контролю и получаем завал. Руководитель перестает справляться с потоком. ТМ зависает на контроле. Все РКК видны как просроченные.

Именно эту картинку я и попытался отобразить в виде схемы.

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

Т.е. взята конкретная точка зрения на конкретное место в процессе и схема более или менее информативна.

А если при помощи таких схем описать процесс в целом, то получается каша и ноль полезной информации.

club.directum.ru

Cхема бизнес процесса | Cхема бизнес процесса пример

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

Схема бизнес процессов

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

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

Третий вид схемы называется «Процедура». Ее структура немного усложнена и расширена, а создается такой эффект благодаря использованию знаков с расширенными функциями. Так, например, ромбик, имеет расширенные возможности, но не может быть декомпозирован. Таким образом, при использовании ромбика в схеме вместо четырёхугольника делает ее более наглядной. Еще одной изюминкой данной схемы становится стрелка, которая используется с одним наконечником, которая покажет последовательность операций. А вот если в данной схеме использовать стрелку, которая имеет два наконечника, тогда можно говорить о движении документов. Более того, в схеме к стрелкам можно привязать конкретный документ, что позволит отобразить информацию целостней. Плюсом данной схемы являются такие особенности – простота, акцентирование внимания на исполнения какой либо операции, предоставление большего количества полезной информации. Минус схемы «Процедура» заключается в блоке «решение», которые не может быть декомпозирован, а так же неоднозначность в наименовании стрелок, что может привести к недопониманию.

Если вы остановили свой выбор на блок схеме разработанной по методу ARIS eEPC, тогда вам стоит знать, что такая схема не читабельна для неподготовленного человека. Такая схема требует к себе больше знаний и умений, нежели первые три. Более того, данная схема относительно предыдущих трех имеет более габаритные размеры, что повышает уровень сложности в построении такой схемы. Плюсы такой схемы заключаются в содержании выдержанной и строгой логики процессов, четкость в определении событий. Минусы – сложность восприятия, усложненный процесс создания схемы, избыток информации, необходимость знаний для ее прочтения.

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

Читать так же:

comments powered by HyperComments

business-ideal.ru

Отличие BPMN от блок-схем — bpmn2.ru

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

Пару слов о BPMN

BPMN — это открытый международный стандарт, нотация для моделирования бизнес-процессов. Он похож на блок-схемы, за что его любят представители бизнеса. Он прост для понимания, но при этом выразителен и способен отобразить любую логику бизнес-процессов. Разрабатывается с конца 90-ых.

А что в блок-схемах?

Блок-схемы появились в 30-ых годах, в Америке. Постепенно они развились в UML и другие нотации типа DRAKON.

1. Встроенные правила и семантика

Каждый значок в BPMN имеет конкретное значение и правила взаимодействия друг с другом. Все правила описаны в стандарте.

Нажмите, чтобы скачать в большом размере

А что в блок-схемах?

Строгая семантика в большинстве типов блок-схем отсутствует (она есть только в некоторых UML-диаграммах). Это значит, что каждую новую схему, которую вы видите, нужно понимать с нуля.

2. Иерархия моделей

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

А что в блок-схемах?

Готовых инструментов для отображения иерархии нет, нужно изобретать свои.

3. Межпроцессное взаимодействие

BPMN позволяет моделировать взаимодействие процессов или внешних участников процессов.

А что в блок-схемах?

Нужно изобретать свои варианты. И учить окружающих их понимать.

4. Мощная поддержка событий

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

А что в блок-схемах?

Есть элементы для начала и завершения схемы процесса. Остальные события надо выдумывать самим.

5. Исполнимые процессы

Правильно составленная BPMN-модель может быть скомпилирована в программу.

А что в блок-схемах?

Ничего подобного нет.

В итоге

Блок-схемы подойдут для иллюстрации машиннного алгоритма, простой последовательности действий или урока информатики в 11 классе.

BPMN подойдёт для моделирования настоящих бизнес-процессов.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

bpmn2.ru

Зачем рисовать схемы бизнес-процессов? #bpm #СЭД #ECMJ

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

Начнем с того что BPMN, EPC и IDEF — это умные слова и не более того. Попытка описывать ими бизнес-процессы приравнивается к попытке чесания ногой за ухом…

Если специалист говорит, что описал процессы и в качестве результата будет показывать мне рисованные схемы (в Visio, ARIS, в нотациях BPMN, EPC или IDEF и т.д.), то у меня в голове сразу включает сигнал тревоги: «Умник прямо по курсу, от которого надо держаться подальше».

Почему-то в сообществе «специалистов по управлению / MBA / консультантов / экспертов / программистов» — нужно подчеркнуть, сложилось мнение, что описание бизнес-процессов — это «а ля рисование схемок и произношение умных слов».

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

Этот поток «комплиментов» относится именно к специалистам по BPMN/EPC/IDEF и т.д., но не к нотациям как таковым. Сами нотации — есть обычный инструмент. Но, как и ножом — ими нужно уметь пользоваться и понимать где это нужно. К примеру, бесполезно ножом есть суп, даже если у вас очень модный нож и вам очень сильно хочется им похвастаться.

За последний год, при том что удалось описать и информатизировать порядка 100 процедур, есть регламенты, инструкции и достаточно мощная информационная система, потребность в описании блок-схемы по процессу пока выявилась всего лишь 1 раз.

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

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

Именно эту картинку я и попытался отобразить в виде схемы.

Цель у этой схемы не описать процесс, а показать проблемную точку в процедуре, быстро поставить задачу программисту по поиску ошибки в ТМ и объяснить руководству, откуда завал. Т.е. взята конкретная точка зрения на конкретное место в процессе и схема более или менее информативна.

А если при помощи таких схем описать процесс в целом, то получается «каша» и ноль полезной информации.

 

Андрей Л.

На мой взгляд, гораздо более информативны схемы [в нотации BPMN — Прим. ред.]. И я честно говоря вообще не представляю как вы автоматизировали порядка 100 процессов не разу не нарисовав хотя бы элементарную блок схему.

 

Анатолий Юмашев

Очень хорошо 🙂

И это действительно один из не многих, хороших примеров ) исключение из сегодняшнего правила…

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

1. Эти схемы хороши для 2-х целей:

1.1. Смотрятся прикольно.

1.2. Позволяют наглядно показывать особенности процесса при обосновании каких-либо изменений. Будь то программирование, реорганизация или другие настройки процессов.

2. Но бесполезны для следующих:

2.1. Нет контроля действий. Нельзя сказать сотруднику, что он нарушил п.3 схемы такой то, что привело к ошибке такой то.

2.2. Нет контроля качества результатов. См. п.2.1

2.3. Нет контроля ввода данных и получения требуемой информации. См. п.2.1

Если у меня в конце периода, выявляется 20% нарушений сроков по РКК по Иванову, я иду к нему. А Ваня просто при выполнении не проставил нужную галочку. И что мне ему сказать? Ваня! Ты чо! Ты чо дурак! Ты разве не знаешь что вот этот квадратик на схеме «Исполнение документа», означает: проставить галочку «выполнено», на второй закладке в карточке записи.

Ваня с ума сойдет от такого контроля.

И если говорить об описании процессов, то я преследую в первую очередь цели из п.2, и только потом цели из п.1.

И как уже сказал, из 100 процедур, цель из п.1 возникла лишь один раз. А вот цели из п.2 — каждый день. Но они при помощи схем не решаются. Тут нужно словестное и попунктное описание процедуры 🙂

 

Алексей Н.

Зачем нужно рисовать блок-схемы бизнес-процессов?

Приземлимся до прикладного уровня.

Как Вы будет составлять типовой маршрут? По памяти и невнятным записям в блокноте, оставшимся после интервью с ключевыми пользователями? Я понимаю, что есть гении, которые видят всю картинку в голове и методично воплощают ее в коде. Но таких немного, согласитесь.

А как ставите задачи разработчикам, если являетесь консультантом? Как утверждаете ТЗ с заказчиком?

Без схем не обойтись. Для наших задач мне больше всего нравится BPMN и EPC. Конечно, можно не знать этих слов и что за ними стоит, но элементарную схему с «квадратиками» и «ромбиками» составлять необходимо в любом случае.

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

Мне сдается, что автор вместе с неприязнью ко схемам испытывает еще и классовую ненависть к консультантам в костюмчиках на проектах

 

Анатолий Юмашев

 

см. здесь:

задачу типа «поставить задачу программиста для ошибки в ТМ», можно заменить на «поставить задачу программисту для написания ТМ». если блок схема пишется для этой цели, я за 🙂

Я не управлял проектами разработки ПО. Хоть и занимался проектированием. Задачи ставил письменно. Приводя примеры.

И еще раз. Если стоит задача внесения изменений в ПО, в т.ч. разработка ТМ, то написание блок схем я признаю. Но эти блок схемы далее этого ТЗ не уйдут.

Их бесполезно позиционировать как описание процесса для управления.

1. Словестное описание + блок-схема = круто. Словестное описание = хорошо. Блок схема сама по себе = фуфло и понты.

2. К консультантам я отношусь нормально 🙂 Тем более что 2 года в ХХХХ за плечами, создание направления ЭДО с ноля, найм и переманивание в 3 захода вот этого специалиста (с первых 2-х раз не переманивался).

3. А вот «консультанты» меня вымораживают. И когда такое чудо мне сует блок-схему и говорит что это он бизнес-процесс описал, я готов ему это описание засунуть в одно месте.

 

Алексей Баранов

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

И, общем-то, суть статьи, как я понял, сводится к тому, что

Словесное описание само по себе — тоже не всегда хорошо. Часто требуется дополнительная «визуализация», для исключения неправильного толкования написанного (так же, как для блок-схем требуется описание деталей).

Если так — то полностью согласен.

 

Дмитрий Носивской

 

Ну вот теперь понятнее. А то после прочтения материала создалось впечатление, что если ты консультант и еще схемы в каких-либо нотациях рисуешь, то ты — «фуфло и понты».

 

Анатолий Юмашев

Правильное впечатление ) так и есть ))

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

И руководство ее слушает, по ряду причин, в т.ч. и потому что схемки у нее больно красивые )

И вот уже 1,5 года ходит и схемки рисует, называя это проектом внедрения СМК. Сделала кучу макулатуры. И все это без толку.

Вот и наболело у меня ))

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

И все это без единого рисунка.

И вот только после этого всего, я позволю себе сесть за рисование схем по процессам.

 

Алексей Баранов

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

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

Судя по тому, что —

руководству удобней «видеть сверху» (так в большинстве случаев и происходит)

А из этого —

понятно, что удобней для Вас.

У разных людей — разные задачи. Поэтому и подход разный.

 

Анатолий Юмашев

да слышал я эти байки ) мне их втирать не надо. какие они там решения принимают видя эти рисунки? можно пример? ))

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

Ага, а почему вы решили что это сверху? а не с правого или левого боку? ))

И еще раз… чего там руководство видит то? или может увидеть? может я глупый руководитель и только я не вижу толку в этих рисованных квадратиках? может быть у вас управленческого опыта поболе моего и вы мне расскажете про вашу практику, где руководства смотря «сверху» на эти «рисунки» че то там видело? И принимало какие то там решения? Не побоюсь этого слова — управленческие!

Я высказал 2 варианта целей описания процессов. (жаль этот движок не позволяет ссылаться на комментарии).

Интересны ваши примеры. Только чур без общих слов.

 

Алексей Баранов

Мой управленческий опыт, хоть и не связан с DIRECTUM (см. профиль), включает опыт общения и с руководством республики и федеральных органов.

Все, что я сказал выше — на нем и основано: я, как отвечавший за ИТ в большой организации, разделял информацию: для меня — детали, для руководства — визуальное представление, ответственные и цифры (суммы, сроки). Можно сказать, что это «вид сбоку», непринципиально. Руковдителя-эксперта на высшем уровне управления не встречал.

Извиняюсь, Анатолий, если неудачно выразился и каким-то образом задел, но думаю, в этом направлении не стоит дискуссию продолжать.

 

Анатолий Юмашев

Алексей, стоит )) Меня обидеть сложно )

Вы утверждаете что руководство в этих схемах че то видит. Я себя считаю руководителем (и не только проектов), но нифига полезного в этих схемах не вижу. Вы утверждаете обратное. Объясните. Дайте примеры. Аргументируйте.

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

Я тут много с какими топ-топами общаюсь, а еще у меня яблоко есть — вкусное. Но ни первый, ни даже второй аргумент не есть подтверждение моих слов.

 

Алексей Баранов

И все-таки уходим мы в сторону, как мне видится — причиной этому могло быть неоднозначно воспринятая высказанная мною идея. Чтобы подвести к логическому концу нашу «ветку», озвучу свою мысль с другой стороны:

Известно, что есть разные типы людей (визуалы, аудиалы, кинестетики, и пр.). Только с этим (а не с занимаемой должностью) связано — как кому легче воспринимать информацию.

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

Можно не учитывать то, как ВАШ руководитель принимает решения, попросту затратите бОльше энергии (так же, как дама-консультант, не учитывающая Ваше восприятие).

Для всего есть свое: время/место/обстоятельства.

В том числе для понимания — какие инструменты ЗДЕСЬ хороши, а какие не очень.

 

Анатолий Юмашев

Алексей, я согласен. Кучу психологий изучал. Как в плане аудиалов/визуалов, так и еще тцать теорий, от воды/огня, холериков/сангвиников, до соционики с MBTI и еще ряда шаманских учений ))

Я хорошо понимаю как преподать ту или иную информацию различным типам людей. И не спорю с этим.

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

Назовите 2-3 примера таких решений или даже 1 пример решения, которое может быть принято человеком-визуалом на основании рисованной блок-схемы.

И я же просил: ))

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

Опишите конкретные примеры ситуаций, подтверждающих вашу абстрактную гипотезу )

 

Тимур Ш.

Не поленился и накидал схемку, может она не так красива, но вполне информативна:

При необходимости можно выделить тот блок (приемка работ руководителем), при котором у вас начинается «завал и потеря информации

 

Анатолий Юмашев

зачем? )

да, информативно. можно и в таком виде показать.

но зачем именно в таком, если нет разницы?

Да и спор у меня сейчас с Алексеем ) жаждю конкретики ))

 

Наталья Глазырина

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

 

Анатолий Юмашев

Наталья, кто ж спорит? Я даже более скажу… внешнему аудитору, если хорошо договориться, можно даже аудиалом притвориться (в терминологии Алексея) и поверить нам на слово ))) в том плане что у нас все тип-топ. Он поверит и нам сертификат выпишет. Даже на схемы смотреть не будет. Ну а те что по умнее, те на схемы посмотрят и скажут — да! — это круто! пошуршат наличностью, напечатают сертификат и срулят восвояси.

Ну и туда же идем… коли о СМК речь завели… назовите мне пункт стандарта, который обязывает рисунки рисовать…

 

Алексей Баранов

без мелочевки, 2 «глобальных»:

Выбор варианта замены контрольно-кассовых машин (ККМ «Онега») работающих на перфолентах, на ККМ на базе ПК (выбор между Ленинградским ПО и Казанскими разработчиками, 1998). Модернизация была успешно проведена во всех отделениях связи республики.

Начало работ по «интернетизации» почтамтов и городских отделений почтовой связи (2001).

Не IDEF0 и BPM, но — схемы и объяснение в виде презентации.

 

Анатолий Юмашев

Супер ))) а тема то про что? ))

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

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

Но мы то ведем речь о описании в BPMN, IDEF итд процесса для управления? Мол руководству по такому описанию проще управлять. Я вот и хочу узнать че там руководство видит и почему ему проще по этим схемам чего то там понимать? Если там не отображена конкретная ситуация, под конкретную задачу.

И еще раз:

1. Рисование схем по процессу под конкретную задачу — это надо. Об этом и речь в статье.

2. Рисование схемы по процессу для управления. Зачем? И что это за управление такое? Что под ним понимается?

И если возьмем п.1, то мы увидим, что на один процесс или процедуру. Можно нарисовать 33 схемы. В зависимости от проблемы или задачи. Под каждую задачу будет своя схема, при том что процесс то один ))

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

Если убрать п.1 из внимания (т.к. это не предмет разногласия), а посмотреть на п.2 — то скажите мне, что это за руководство такое и какие такие решение оно может принимать? И какую пользу несут эти рисунки? ))

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

 

Алексей Баранов

Согласен, что не согласен с таким утверждением. 🙂

Не отношусь к таковым. Это — крайности.

Точно так же — как крайностью является утверждение:

Истина где-то между 🙂

 

Николай П.

Начнем с того что BPMN, EPC и IDEF — это умные слова и не более того. — Это о многом говорит…

Начнём с того что EPC служит для описания процессов НИЖНЕГО уровня где описываются события!

А IDEF0 — описывает логическое взаимодействие между работами… Т.е. ВЕРХНИЙ уровень процесса…

Статья выражает личное мнение автора и не содержит ничего интересного. Даже предложенный Тимуром BPMN вариант гораздо эффективнее и более информативен. Вы же изобразили какуюто странную вариацию FlowChart…

 

Елена Б.

Полезны, если их рассматривать с точки зрения описания ТМ под конкретную задачу.

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

 

Анатолий Юмашев

очень рад 🙂

потому что вот это…

мне ни о чем не сказало )

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

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

Ну, во-первых, я не знаю объективных методик, где описано понятие верхнего и нижнего уровня процессов с описанием IDEF и EPC.

Я знаю лишь, что бывают процессы, которые могут быть иерархически выстроены, которые действительно удобно описывать через IDEF. А есть процедуры, которые имеет смысл описывать через EPC, под конкретные задачи (как правильно заметила Елена Б.). Под конкретные задачи – означает, что описывать просто процедуру, просто в EPC — это глупость и не выполнимая задача. И пока я не нашел ни одного аргумента в защиту противоположной точки зрения. Все аргументы идут лишь в защиту моей статьи о том, что все эти схемы имеют смысл лишь в конкретных задачах. А когда мы говорим просто об описании процессов в целом, то они бесполезны.

Оригинал записи опубликован на DIRECTUM Club.

ecm-journal.ru