Файл: Разработка регламента выполнения процесса «Обеспечение послепродажного обслуживания» на примере компании ООО «Блэкпринт».pdf

Минусы:

• Не компактно — описание больших процессов, со всем множеством подпроцессов и элементов, будет выглядеть как «простыня». Компактным такой вид назвать сложно.
• Отсутствует необходимая детализация — для того чтобы таблица имела более компактный вид, количество данных должно быть ограничено. Это значит, что даже если вы вносите текст в таблицу, он должен быть ограничен. А значит добиться необходимой детализации может стать не просто.
• Нет целостности восприятия — большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции (подпроцесса) в строке или данные одного типа в столбце — то лучше таблицы не придумать.
• Сложно отобразить ветвления — та же проблема, что и с текстом. Большое количество ветвлений, и , что важно, развитие процесса исходя из условий ветвления, довольно сложно отобразить наглядно.
• Требует подготовки — нужно потратить время на подготовку хорошего шаблона.

Описание в виде схемы, модели бизнес процесса.

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

Плюсы описания бизнес процессов в виде модели

• Простота восприятия — наш мозг устроен таким образом, что картинку мы воспринимаем быстрее чем что либо. Поэтому схему воспринимать очень просто. Мозг «фотографирует» схему и обрабатывает ее на бессознательном уровне, в разы быстрее, чем наше сознание. Схему воспринимать просто еще потому, что мы сразу видим взаимосвязи элементов.
• Целостность восприятия — 1 схема представляет из себя модель процесса на определенном уровне. Это значит, что схема сразу дает нам представление о процессе в целом. В частности о его границах, основных элементах и т.д.  Если процесс детализируется на нескольких уровнях, то схемы все равно остаются связанными.
• Необходимая и достаточная детализация — в тоже время, на схеме можно отобразить относительно больше количество деталей, без потери качества восприятия.
• Наглядное отображение ветвлений и путей развития процесса — правильно построенная схема сразу дает представление о том, каким путем должен развиваться процесс в правильном варианте. А также другие варианты развития событий.
• Удобство автоматизации — многие программные инструменты позволят переводить диаграммы в языки программирования, что очень сильно упрощает жизнь разработчикам и внедренцам ПО.

---

Минусы

• Требует специальных навыков — нужно знать, как правильно строить диаграммы. Знать разные нотации. А иногда, даже, самостоятельно сделать набор элементов, которыми вы будете пользоваться для описания, и правил.
• Относительно больше время на подготовку описания — хорошо построенная модель процесса должна быть проста и понятна. Для того, чтобы сделать схему таковой, необходимо потратить кучу времени. 

Семейство IDEF.

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

IDEF это не одна нотация, а целое семейство. Различаются они по порядковым номерам — IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Семейство IDEF безнадежно, морально, функционально устарело.
Дальше. Использовать модели бизнес-процессов, выполненных в IDEF крайне сложно. Как для изучения, так и для анализа. На рисунке 2 представлен пример схемы бизнес процесса. Рис. 2

Нотация имеет ограничения по количеству отображаемых на схеме процессов — не больше 7. В данном примере их 3. Отсюда возникает необходимость подстраивать описания под эти правила. Помимо этого, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес-процессов, так и «читателям».
В совокупности это влечет за собой огромное количество тяжелых для восприятия, крайне запутанных схем. Но есть и плюс — вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок схема будет ориентирована на лист формата А4 в альбомной ориентации. Т.е. распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающее моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своем, оно тоже устарело и не позволяет решать, актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес-процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами например, Microsoft Visio. Даже от руки, на листе бумаги, можно создать схему.
К слову, именно из потребности в автоматизации, т.е. переводу моделей бизнес-процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.

---

eEPC.

Событийная цепочка процессов (EPC-диаграмма, англ. event-driven process chain) — тип блок-схемы, используемой для бизнес - моделирования. EPC может быть использована для настройки системы планирования ресурсов предприятия, и для улучшений бизнес-процессов.

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

На Рисунке 3 приведен пример нотации eEpc.

Рис. 3

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

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

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

Нотация eEPC является не самым плохим решением для описания и моделирования бизнес-процессов.

---

BPMN.

Нотация по моделированию бизнес-процессов BPMN (The Business Process Modeling Notation) - это новый стандарт для моделирования бизнес процессов и сетевых услуг, который впервые был выпущен BPMI Notation Working Group в мае 2004 года. Последняя версия нотации BPMN 2.0 вышла в 2010 году.

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

Людям, занимающимся бизнесом, крайне удобно работать с бизнес-процессами, отображаемыми в виде блок-схем. Множество бизнес-аналитиков проектируют и описывают бизнес-процессы компаний с помощью простых диаграмм в нотации BPMN, т.к. язык нотации понятен даже на уровне пользователя. При этом модели процессов, описанных в нотации BPMN, являются ИСПОЛНЯЕМЫМИ (т.е. реализуются в любой BPM-системе), а не только документируются.

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

отображается их взаимодействие. И это крайне важно.

Рис. 4 Модель процесса в нотации BPMN.

Дело в том, что наибольшие проблемы в бизнес-процессах, лежат на стыках работ разных исполнителей (ролей, процессов). Модели в нотации BPMN позволяют увидеть и проанализировать все взаимодействия.
Набор знаков в BPMN, достаточен для описания любого процесса и обозначения любых типов событий. Кстати, только в этой нотации существует разделение событий на события начала, окончания и промежуточные события. Почему это важно? Потому что процесс всегда начинается и заканчивается событием. Или событиями. Данное разделение позволяет сразу понять, с чего начинается и чем заканчивается процесс.
Существует разделение потоков на рабочие, информационные и ассоциации. Это позволяет разделять поток работ, потоки обмена информацией и потоки, определяющие принадлежность, к примеру, документов к тому или иному процессу. В свою очередь, данное разделение облегчает чтение и анализ моделей бизнес-процессов.
Помимо стандартных наборов значков, BPMN позволяет создавать свои, что позволяет адаптировать нотацию к любым потребностям.

---

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

Есть еще возможности связки моделей BPMN и 1С. В итоге получается эффективная система управления процессами с возможностью отслеживания онлайн.

Резюме — нотацию BPMN выбирает большинство профессионалов в управлении бизнес-процессами. Она наиболее современная и активно развивающаяся.

На основе выше изложенного, средство моделирования будет MS Visio.

Нотацией будет BPMN.

1.3 Моделирование бизнес - процессов "как есть".

Общий вид схемы деятельности сервисного центра представлена на рисунке 5. Схема реализована с помощью инструментария MS Visio 2007 в нотации BPMN.

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

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

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

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

---