Разработка бизнес процессов на примере предприятия. Моделирование бизнес-процессов: доступно о сложном

Понятие бизнес-процесс, структура процессов и подпроцессов

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

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

Группы бизнес-процессов

Выделяют основные, вспомогательные и процессы управления – это главные группы БП. Как выполняемый единожды уникальный процесс отдельно выделяется БП развития. Направленность БП основной группы:

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

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

• создание продуктов для внутренних сфер бизнеса;
• поддержание функций компании, ее инфраструктурной составляющей

Процессы управления координируют всю совокупность БП (основные, поддерживающие, БП развития).

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

Представленная классификация не является окончательной. БП в каждой компании зависят от ее конкретных отличительных особенностей.

Описание основных БП для производственно-торговой компании (пример):

• маркетинговые процессы;
• проектирование, разработка продукта или услуги;
• производство конечного продукта;
• логистические процессы (сбыт, доставка, снабжение);
• управление продажами и обслуживанием

Поддерживающие БП:

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

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

БП развития – совершенствование деятельности, своего рода бизнес-инжиниринг.

Описание и анализ БП

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

Визуализация модели.

Модель обычно отображают в виде схем, таблиц с описаниями, либо сочетание графика и текстового описания (нотация) и т.п. Степень детализации объекта, полнота описания, зависят от конкретного применения данной модели. Задачей любого из этих способов будет описание БП по принципу: «действие-функция». У каждого БП есть свой исполнитель – это тоже нужно указывать. Им будет являться подразделение либо определенная должность. «Входы» - это материальные, информационные и финансовые, а «выходы» представляются в виде перечня продуктов либо услуг. Результатом действия исполнителя будет являться «выход», действия также могут объединяться по принципу логической связи между собой, тогда «входы» и результаты должны быть согласованы между ними. Связь «входа» и «выхода» обеспечивается деятельностью, направленной на достижение результата при переходе между ними.

Как реализуется описание БП

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

1. Текстовое описание.

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

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

2. Табличная форма. Подходит для описания последовательных процессов. Может применяться в качестве переходной к графической реализации в качестве базы данных.

3. Графическое описание в виде моделей и диаграмм.

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

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

Технологии, которые используются для описания БП:

1. IDEF - принята за стандарт практически повсеместно. Integration Definition for Function Modeling –технология моделирования функционала. Поддерживается следующим программным обеспечением – BPWIN, MS Visio и пр. Это совокупность методов моделирования позволяет детализировать БП всех уровней, представляя их как в одном блоке, так и в отдельных схемах.

2. Технологии моделирования используют унифицированный язык моделирования (UML). Он позволяет описывать БП непосредственно на языке понятном компьютерным программам, является средством автоматизации. Поддерживается ведущими разработчиками ПО, основным инструментом для реализации является программное средство Rational Rose от IBM.

3. Диаграммы еЕРС (extended Event-Process Chain). Благодаря им, есть возможность отобразить последовательность операций, участников, используемые ресурсы, отображая состояние на текущий момент времени.

4. Технология ARIS (Architecture of Integrated Information Systems) используется как встроенный инструмент в одну из крупнейших систем автоматизации – SAP R/3.

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

Алгоритм действий при моделировании:

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

2. Описания всего окружения БП, а именно указание всех процессов с которыми он связан на «входе» и «выходе», включая все ресурсы на этих этапах.

3. Описание функционального содержания БП. Подразумевает описание всех зон ответственности для каждого из подразделений или должности в организации.

4. Описание БП потоков и их структуры. Определяется целями, которое оно преследует. Если необходимо улучшить информационную систему, тогда описываются потоки информации, документооборот и т.п., если цель распределить правильно финансы – тогда финансовый поток и БП в них.

УДК 65:519.86 Е.М.Михайлова СГГА, Новосибирск

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ ПРЕДПРИЯТИЯ

Ye.M. Mikhailova

Siberian State Academy of Geodesy (SSGA) 10 Plakhotnogo Ul., Novosibirsk, 630108, Russian Federation

MODELING OF ENTERPRISE BUSINESS-PROCESSES

The paper investigates theoretical and methodological basis for modeling business-processes at modern enterprises. This type of modeling is shown to be significant for increasing efficiency of companies activities. Advantages of business-process modeling are emphasized as well as the problems to be solved through it and the stages of business processes description. Special attention is paid to the characteristics of the techniques applied in modeling.

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

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

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

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

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

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

Бизнес-модель - это формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов.

Цели моделирования бизнес-процессов обычно формулируются следующим образом:

1) Обеспечить понимание структуры организации и динамики происходящих в ней процессов;

2) Обеспечить понимание текущих проблем организации и возможностей их решения;

3) Убедиться, что заказчики, пользователи и разработчики одинаково понимают цели и задачи организации;

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

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

1. Основные бизнес-процессы (например маркетинг, производство, поставки и сервисное обслуживание продукции).

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

3. Бизнес-процессы управления.

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

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

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

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

Выделяют следующие этапы описания бизнес-процессов:

1. Определение целей описания.

2. Описание окружения, определение входов и выходов бизнес-процесса, построение IDEFO-диаграмм.

3. Описание функциональной структуры (действия процесса), построение IDEF3-диаграмм.

4. Описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм.

5. Построение организационной структуры процесса (отделы, участники, ответственные).

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

1. Методологии моделирования бизнес-процессов (Business Process Modeling)

Наиболее широко используемая методология описания бизнес-процессов - стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов -программных продуктов для моделирования бизнес-процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.). Методология IDEF0 предоставляет аналитику широкие возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа - по информации, управлению, движению материальных ресурсов. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании. Их основное преимущество состоит в возможности описывать управление процессами организации.

2. Методологии описания потоков работ (Work Flow Modeling)

Вторая важнейшая методология описания процессов - IDEF3,

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

3. Методологии описания потоков данных (Data Flow Modeling)

Еще одна группа методологий, активно используемых на практике, -нотации DFD (Data Flow Diagramming), предназначенные для описания потоков данных. Они позволяют отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами. Кроме того, нотация DFD предоставляет возможность описывать потоки документов (документооборот) и материальных ресурсов (например, движение материалов от одной работы к другой). Методология DFD может эффективно использоваться для описания процессов при внедрении процессного подхода к управлению организацией, так как позволяет максимально снизить субъективность описания бизнес-процессов. С помощью схемы процессов в DFD выявляют основные потоки данных, что важно для последующего создания моделей структуры данных и разработки требований к информационной системе организации.

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

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

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

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

© Е.М. Михайлова, 2009

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

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

РЕГЛАМЕНТ КАК ДОКУМЕНТ

Наш словарик

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

Регламенты строго индивидуальны и могут действовать только в той организации, которая утвердила их для себя. Так, при составлении инструкции по делопроизводству обычно используют ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» и Методические рекомендации по внедрению ГОСТ Р 6.30-2003 . На основе этих документов создаются внутренние инструкции и в небольшом магазине, и в ОАО федерального уровня. А вот, например, порядок прохождения внутренних документов, установленный в одной организации, может совершенно не подходить для другой.

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

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

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

Какие процессы подлежат регламентации?

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

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

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

СТРУКТУРА И СОДЕРЖАНИЕ РЕГЛАМЕНТА

Как правило, регламент состоит из следующих основных разделов:

1. Общие положения.
2. Термины, определения, сокращения.
3. Описание процесса.
4. Ответственность.
5. Контроль.

ОСНОВНЫЕ РЕКВИЗИТЫ РЕГЛАМЕНТА

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

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

Кстати

Требования к оформлению перечисленных реквизитов установлены ГОСТ Р 6.30-2003. Методические рекомендации по внедрению ГОСТ Р 6.30-2003 разъясняют и конкретизируют порядок внедрения и применения данного стандарта.

МОДЕЛЬ БИЗНЕС-ПРОЦЕССА

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

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

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

ПОРЯДОК РАБОТЫ НАД РЕГЛАМЕНТОМ

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

Утверждение регламента может производиться несколькими способами:

1. напрямую (руководитель собственноручно расписывается на документе);
2. косвенно (путем издания приказа) (см. Пример 1). В данном случае в гриф утверждения будут внесены регистрационные данные приказа.

Пример 1

Приказ об утверждении и введении в действие
регламентов бизнес-процессов

(ООО «Перспектива»)

ПРИКАЗ

23.07.2014 № 456-Пр

г. Москва

Об утверждении и введении в действие регламентов бизнес-процессов

В целях совершенствования процедур делопроизводства ООО «Перспектива»

ПРИКАЗЫВАЮ:

1. Утвердить и ввести в действие с 01.08.2014 регламенты следующих бизнес-процессов:

1.1. Регистрация и учет документов.

1.2. Контроль исполнения документов.

1.3. Хранение и поиск документов.

2. Назначить ответственным за выполнение требований, указанных в п. 1 данного приказа, административного директора Легостаева А.В.

3. Начальнику канцелярии Паршиной В.К. обеспечить ознакомление работников ООО «Перспектива» с настоящим приказом под роспись и передать копии утвержденных регламентов в структурные подразделения ООО «Перспектива» до 30.07.2014.

4. Контроль исполнения настоящего приказа оставляю за собой.

Генеральный директор Максимов Д.А. Максимов

С приказом ознакомлены:

Легостаев А.В. Легостаев 24.07.2014

Паршина В.К. Паршина 24.07.2014

П.А. Карпенко

23-78

Регламент бизнес-процесса «Контроль исполнения документов» приведен в Примере 2.

Пример 2

Регламент бизнес-процесса «Контроль исполнения документов»

Общество с ограниченной ответственностью «Перспектива»
(ООО «Перспектива»)

РЕГЛАМЕНТ №7
бизнес-процесса «Контроль исполнения документов»

1. Общие положения

1.1. Регламент бизнес-процесса «Контроль исполнения документов» (далее - Регламент) определяет порядок контроля исполнения заданий по документам в ООО «Перспектива» (далее - Организация).

1.2. Требования и правила Регламента распространяются на все структурные подразделения Организации.

1.3. Утверждение Регламента, внесение в него изменений и отмена производятся приказом генерального директора Организации.

1.4. Работники Организации обязаны знать и выполнять требования Регламента. Все вновь принятые на работу сотрудники Организации должны быть ознакомлены руководителями структурных подразделений с установленным порядком контроля исполнения документов в Организации.

2. Термины, определения, сокращения

2.1. В Регламенте используются следующие термины и определения:

Документ - зафиксированная на носителе информация с реквизитами, позволяющими ее идентифицировать.

Задание - поручение руководителя.

Задача - см. задание.

Исполнитель - работник Организации, которому поручено исполнение задачи.

Контроль - совокупность действий, обеспечивающих своевременное исполнение документа.

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

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

Руководитель - должностное лицо, выносящее резолюцию.

Срок исполнения - календарная дата исполнения задачи. Срок исполнения документа начинается со дня его регистрации в канцелярии Организации и исчисляется в календарных днях. Документы подлежат исполнению в следующие типовые сроки:

С конкретной даты исполнения - в указанный срок, если документ поступил в Организацию не позже чем за три дня до истечения указанного срока;

Без указания конкретной даты исполнения и специальных пометок - в течение 30 дней;

Без указания конкретной даты, с пометкой «Срочно» или «Немедленно» - в течение трех дней;

Без указания конкретной даты, с пометкой «Оперативно» - в течение 10 дней.

3. Описание процесса

3.1. Постановка документа на контроль.

3.1.1. Контролю подлежат все зарегистрированные документы, требующие исполнения.

3.1.2. Основанием для постановки документа на контроль является резолюция генерального директора Организации или его заместителя.

В резолюции указываются:

Исполнитель документа;

Срок исполнения задачи;

При необходимости - содержание задачи.

3.1.3. Получив документ с резолюцией, секретарь генерального директора или секретарь заместителя генерального директора (далее - Секретари) готовят скан-копию документа с резолюцией. Отсканированный документ помещается в папку «На контроле».

3.1.4. Файл копии документа вкладывается в электронное сообщение, направляемое исполнителю.

3.1.5. В параметрах электронного сообщения устанавливается срок исполнения задачи и включается опция уведомления автора задачи о ее получении.

3.1.6. После получения электронного сообщения с задачей исполнитель направляет автору задачи уведомление о ее получении.

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

3.2. Выполнение задания.

3.2.1. Исполнитель выполняет поставленную перед ним задачу в установленный в резолюции срок.

3.2.2. Если последний день исполнения задачи приходится на нерабочий день, документ подлежит исполнению на следующий рабочий день.

3.2.3. Если выполнить задание в установленный в резолюции срок не представляется возможным, исполнитель обязан доложить об этом руководителю до истечения срока выполнения и объяснить причину задержки. Если причина является уважительной, руководитель может продлить срок выполнения задачи.

3.2.4. В случае если срок выполнения задачи был продлен руководителем, автор задачи изменяет срок ее выполнения в электронной карточке документа.

3.3. Отчет о выполнении задания.

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

3.3.2. Получив отчет о выполнении задачи, автор задачи ставит статус «Выполнено» в электронной карточке документа. Документ изымается из папки «На контроле» и помещается в дело.

3.3.3. В случае если автор задачи не получил отчет о выполнении задачи в срок, указанный в резолюции, он направляет исполнителю электронное сообщение-запрос с требованием указать причину невыполнения задачи. О невыполнении задания автор задачи докладывает руководителю с приложением объяснений исполнителя. Если причина является уважительной, руководитель может продлить срок выполнения задачи.

3.3.4. В случае если срок выполнения задачи был продлен руководителем, автор задачи изменяет срок выполнения в электронной карточке документа.

3.4. Формирование отчета о выполнении задач.

3.4.1. Секретари ежемесячно формируют отчет о выполнении задач по документам, который представляют руководителю.

В отчете указывается:

Общее количество поставленных задач за отчетный период;

Количество выполненных задач;

Количество задач с продленным сроком исполнения;

Количество задач, не выполненных в срок.

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

4. Ответственность

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

5. Контроль

Контроль исполнения Регламента осуществляет административный директор Организации.

Введение

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

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

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

процессов составила методология SADT. В настоящее время наиболее широко используемая методология описания бизнес-процессов – стандарт США IDEF.

Главное достоинство идеи анализа бизнес-процессов предприятия посредством создания его модели - ее универсальность. Во-первых,

моделирование бизнес-процессов это ответ практически на все вопросы,

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

1 Сущность и значение моделирования бизнес-процессов

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

Существует несколько подходов к определению понятия

«моделирование бизнес-процессов»:

1) моделирование бизнес-процессов - это описание бизнес-

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

2) моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия;

3) моделирование бизнес-процессов - это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;

4) моделирование бизнес-процессов - это метод, позволяющий дать оценку текущей деятельности предприятия по отношению к требованиям,

предъявляемым к его функционированию, управлению, эффективности,

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

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

6) моделирование бизнес-процессов - это всегда верный способ выявления текущих проблем на предприятии и предвидения будущих.

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

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

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

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

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

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

Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты

деятельности компании:

 изменение организационной структуры;

 оптимизацию функций подразделений и сотрудников;

 перераспределение прав и обязанностей руководителей;

 изменение внутренних нормативных документов и технологии проведения операций;

 новые требования к автоматизации выполняемых процессов и т.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

1) существующая организационная структура;

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

3) структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

4) диаграммы взаимодействия для конечных бизнес-процессов,

отражающие последовательность создания и перемещения документов

(данных, материалов, ресурсов и т.п.) между действующими лицами.

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

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

Детальная модель бизнес-процесса должна включать:

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

2) диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

3) диаграммы взаимодействия, отражающие схемы документооборота.

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

В случае если после построения моделей согласование не было достигнуто – в модель должны быть внесены необходимые уточнения и коррективы. Процесс итерации (согласование, внесение корректив и уточнений) должен повторяться до момента полного подтверждения, что модель понятна и однозначно представляет детали бизнес-процессов.

2 Методика проведения моделирования бизнес-процессов

Под методологией (нотацией) создания модели (описания) бизнес-

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

– теоретическая база;

–описание шагов, необходимых для получения заданного результата;

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

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

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

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

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

инструментом реорганизации бизнес-процессов в рамках создания системы автоматизации.

Необходимо учитывать важные характеристики моделирования бизнес-

процессов. В частности, к преимуществам моделирования бизнес-процессов относят: повышение качества и скорости производства продукции с одновременным снижением издержек; рост профессионализма сотрудников;

повышение конкурентоспособности компании. Недостатки, в свою очередь:

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

3 История развития методологий моделирования бизнес-процессов

Основу многих современных методологий моделирования бизнес-

процессов составила методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и

алгоритмические языки, применяемые для разработки программного обеспечения.

В сжатом виде история развития методологий моделирования бизнес-

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

Рисунок 2 - История развития методологий моделирования бизнес-

процессов

В настоящее время для описания, моделирования и анализа бизнес-

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

 моделирования бизнес-процессов (Business Process Modeling);

 описания потоков работ (Work Flow Modeling);

 описания потоков данных (Data Flow Modeling).

Методологии моделирования бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-

процессов – стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-

процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.).

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

различного типа – по информации, управлению, движению материальных ресурсов .

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

настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий ―Сущность-взаимосвязь‖

(ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных;

IDEF2 – методология динамического моделирования развития систем.

В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе;

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

описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая

функция может быть представлена в виде отдельного процесса средствами

IDEF4 – методология построения объектно-ориентированных систем.

Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 – методология исследования сложных систем .

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

организационные модели, представляющие структуру системы -

иерархию организационных подразделений, должностей и конкретных лиц,

связи между ними, а также территориальную привязку структурных подразделений;

функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций,

необходимых для достижения поставленных целей;

информационные модели, отражающие структуру информации,

необходимой для реализации всей совокупности функций системы;

модели управления, представляющие комплексный взгляд на

реализацию бизнес-процессов в рамках системы.

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

В целом, применение схем в формате, подобном представленному на Рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.

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

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

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

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

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной блок-схемы. Ну, а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинги bpmntraining.ru .»

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность