Моделирование и анализ процессов как есть

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

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

Собственно моделирование бизнес процессов преследует несколько целей:

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

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

Состав стадий, которые включает в себя моделирование бизнес процессов следующий:

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

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

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

Наиболее часто, для целей совершенствования процесса применяют следующие виды моделирования:

• Функциональное моделирование. Этот вид моделирования подразумевает описание процессов в виде взаимосвязанных, четко структурированных функций. При этом строгая временная последовательность функций, в том виде, как она существует в реальных процессах, не обязательна.
• Объектное моделирование — подразумевает описание процессов, как набора взаимодействующих объектов – т.е. производственных единиц. Объектом является какой-либо предмет, преобразуемый в ходе выполнения процессов.
• Имитационное моделирование – при таком виде моделирования бизнес-процессов подразумевается моделирование поведения процессов в различных внешних и внутренних условиях с анализом динамических характеристик процессов и с анализом распределения ресурсов.

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

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

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

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

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

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

Flow Chart Diagram (диаграмма потока работ) – это графический метод представления процесса в котором операции, данные, оборудование процесса и пр. изображаются специальными символами. Метод применяется для отображения логической последовательности действий процесса. Главным достоинством метода является его гибкость. Процесс может быть представлен множеством способов.

Data Flow Diagram (диаграмма потока данных). Диаграмма потока данных или DFD применяется для отображения передачи информации (данных) от одной операции процесса к другой. DFD описывает взаимосвязь операций за счет информации и данных. Этот метод является основой структурного анализа процессов, т.к. позволяет разложить процесс на логические уровни. Каждый процесс может быть разбит на подпроцессы с более высоким уровнем детализации. Применение DFD позволяет отразить только поток информации, но не поток материалов. Диаграмма потока данных показывает, как информация входит и выходит из процесса, какие действия изменяют информацию, где информация хранится в процессе и пр.

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

IDEF (Integrated Definition for Function Modeling) – представляет собой целый набор методов для описания различных аспектов бизнес-процессов (IDEF0, IDEF1, IDEF1X , IDEF2, IDEF3, IDEF4, IDEF5). Эти методы строятся на базе методологии SADT (Structured Analysis and Design Technique). Для моделирования бизнес процессов наиболее часто применяют методы IDEF0 и IDEF3.

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

IDEF3 – этот метод позволяет создать «поведенческую» модель процесса. IDEF3 состоит из двух видов моделей. Первый вид представляет описание потока работ. Второй – описание состояний перехода объектов.

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

Unified Modeling Language (UML) — представляет собой объектно-ориентированный метод моделирования процессов. Он состоит из 9-ти различных диаграмм, каждая из которых позволяет моделировать отдельные статические или динамические аспекты процесса.

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

источник

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

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

К основным этапам оптимизации бизнес-процессов можно отнести:

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

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

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

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

Моделирование и анализ бизнес-процессов «как есть» включает следующие этапы:

• 1. Создание моделей организационной структуры;
• 2. Создание вспомогательных моделей (деревья функций, документов, материальных ресурсов и т.д.);
• 3. Разработка моделей бизнес-процессов верхнего уровня;
• 4. Проверка адекватности моделей верхнего уровня;
• 5. Разработка моделей детальных бизнес-процессов (несколько уровней де­композиции);
• 6. Проверка адекватности детальных моделей;
• 7. Создание моделей документов, данных и т.д.
• 8. Проведение анализа моделей.
• 9. Формирование отчетов.

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

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

После определения результата следует разобраться с последовательностью действий, составляющих процесс.

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

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

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

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

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

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

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

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

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

Высокоуровневую диаграмму процесса, показывающую его крупные шаги (обычно не более десяти) и связанные с ними роли;

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

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

источник

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

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

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

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique — метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing) и алгоритмические языки.

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

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

— Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

— Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

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

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

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

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

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

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

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

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

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

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

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

Этапы описания бизнес-процессов:

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

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

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

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

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

IDEF0

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

Место соединения дуги с блоком определяет тип интерфейса:

— Управляющая информация входит в блок сверху.

— Входная информация входит в блок слева.

— Результаты выходят из блока справа.

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

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

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

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

IDEF3

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

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

Все связи в IDEF3 являются однонаправленными и организуются слева направо.

Типы связей IDEF3:

— Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.

— Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.

— Нечеткое отношение (Relationship), пунктирная стрелка.

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

Ветвление процесса отражается с помощью специальных блоков:

— «Исключающее ИЛИ» («одно из»), блок со знаком Х.

Если действия «И», «ИЛИ» должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно — одной.
Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.

DFD

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

Основными компонентами диаграмм потоков данных являются:

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

— системы и подсистемы (например, подсистема по работе с физическими лицами);

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

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

— потоки данных (на диаграмме — стрелки).

Необходимо размещать на каждой диаграмме от 3 (меньше нет смысла) до 7 (больше — не воспринимаемо) процессов, не загромождая диаграммы несущественными на данном уровне деталями.

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

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

При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации.

ARIS

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

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

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

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

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

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

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

Основная бизнес-модель ARIS — eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается.

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

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты — «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть сроинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.

Основные объекты нотации eEPC:

— Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.

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

— Организационная единица. Например, управление или отдел.

— Документ. Отражает реальные носители информации, например, бумажные документы.

— Кластер информации. Характеризует набор сущностей и связей между ними.

— Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.

— Логический оператор. Оператор «И», «ИЛИ» или исключающее «ИЛИ», позволяет описать ветвление процесса.

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: На стипендию можно купить что-нибудь, но не больше. 9089 — | 7270 — или читать все.

источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

–рекомендации по использованию как отдельно, так и в составе группы методик [2].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

источник

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

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

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

• Моделирование бизнеса. Основные подходы
• Знакомство с нотацией IDEF0 и пример использования
• Краткое описание BPMN с примером
• Что такое BPMS
• Использование GAP-анализа для выявления и согласования задач по проекту

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

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

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

А потому я предлагаю договориться:

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

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

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

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

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

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

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

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

Нотация/бизнес нотация — язык описания бизнес процессов.

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

Для наглядности я предоставляю вам таблицу (последовательность колонок и строк не имеет значения):

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

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

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

1. Знание бизнес-анализа и умение работать с нотациями.
2. Информация о работе определенного процесса.
3. Требования по оптимизации: к какому результату стремится руководство компании.

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

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

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

Очень распространенная ситуация – оптимизация работы интернет-магазина.

Изначально на обработке заказов работало несколько человек:

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

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

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

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

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

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

Количество заказов, обрабатываемых в день, теперь ограничивается только возможностями складского работника. Человек видит постоянную «очередь заказов». Ее же наблюдает и его начальство, и привычно выражает недовольство.

Даже если нет негатива «сверху», человек и сам видит постоянный «завал», работать приходится больше, чем раньше. Конечно, частично это компенсирует повышение зарплаты. Но все равно из-за повышенной нагрузки копится усталость, в том числе, психологическая. Человек – не машина, он не может идеально работать изо дня в день без перерывов. У каждого человека есть определенный максимум – сколько заказов он способен обработать за смену.

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

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

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

В результате можно прийти к следующей схеме:

1. Заказ такси – автоматически, через сайт или приложение без участия диспетчера.
2. Доставка клиента до места назначения
3. Оплата – автоматически, с банковской карты или интернет-денег после поездки на основе GPS-данных.

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

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

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

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

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

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

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

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

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

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

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

Еще один важный фактор, который объединяет описанные выше примеры:

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

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

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

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

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

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

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

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

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

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

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

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

источник