Читать онлайн «Практика и проблематика моделирования бизнес-процессов». Страница 11

♦ иерархическая несовместимость. Несовместимость процесса с подпроцессами, его составляющими;

♦ «наследственная» несовместимость. Наличие конфликта между основными и последующими процессами.

Динамика процессов исследуется с помощью динамической (имитационной) модели.

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

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

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

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

Операционный риск критичен для тех процессов, которые характеризуются:

♦ значимостью для деятельности организации в целом;

♦ большим числом транзакций в единицу времени;

♦ сложной системой технической поддержки.

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

Этапы анализа рисков процесса:

1) структуризация рисков;

2) описание рисков и процессов, их предотвращающих;

3) определение рисков в бизнес-процессах.

Основу процесса составляют выполняемые функции. Для выполнения каждой из функций требуются ресурсы:

♦ людские – участники процесса (кто выполняет);

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

♦ материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);

♦ информационные – данные, документы, информация (на основании чего выполняет);

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

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

Например, операционное окружение таможенных процессов включает:

♦ организационное наполнение (перечень исполнителей на уровне должностных лиц и подразделений, участвующих в процессе);

♦ системное наполнение (перечень информационных и технических систем, используемых в процессе);

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

♦ информационное наполнение (перечень документов и данных разного типа, используемых в процессе).

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

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

Необходимо отметить, что постановка задачи по построению модели объекта определяется фиксированием ряда таких составляющих, как:

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

♦ формализация (нотация);

♦ лингвистическое обеспечение (система классификации и кодирования).

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

♦ методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, МЕТА Group и др.;

♦ модель Захмана;

♦ методика TOGAF;

♦ методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная архитектура госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве обороны США DoDAF (Department of Defence Architecture Framework).

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

♦ описание методов проектирования архитектуры в терминах использования определенных «строительных блоков»;

♦ описание того, как эти «строительные блоки» связаны между собой;

♦ набор инструментов для описания элементов архитектуры;

♦ общий словарь используемых терминов.

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

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

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

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

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

Определение модели согласно Захману (Zachman Framework for Enterprise Architecture). Модель представляет собой общий словарь, набор перспектив или структур для описания современных сложных, корпоративных систем и преследует две основные цели: с одной стороны, логическое разбиение поставленной задачи на отдельные блоки для упрощения формирования и восприятия итогового решения, с другой – обеспечение возможности рассмотрения целостной архитектуры решения с выделенных точек зрения или соответствующих уровней абстракции.