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

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

— построение математической модели;

— составление программы для компьютера;

— оценка адекватности модели;

— интерпретация результатов моделирования.

Рассмотрим каждый этап отдельно.

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

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

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

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

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

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

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

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

Составление программы для компьютера. На этом этапе перед разработчиком модели возникает проблема ее описания на языке, приемлемом для использования компьютера. Быстрый переход к компьютерному моделированию привел к развитию большого числа специализированных языков программирования, предназначенных для этой цели. На практике, однако, большинство предложенных языков ориентировано на определенную математическую схему. Например, язык GPSS хорошо приспособлен для исследования задач массового обслуживания, а язык СИМУЛА был разработан прежде всего для имитации больших экономических систем, которые описываются эконометрическими моделями с большим числом уравнений.

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

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

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

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

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

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

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

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

Приняв во внимание все это, сформулируем конкретные критерии, которым должна удовлетворять хорошая модель. Такая модель должна быть:

— простой и понятной пользователю;

— удобной в управлении;

— надежной в смысле гарантии от абсурдных решений;

— полной с точки зрения возможностей решения главных задач;

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

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

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

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

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

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

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

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

Существуют определенные правила проверки, в частности, многие из них описаны в документации по IDEF0 [2] и |3]. Простейшая схема проверки адек­ватности представлена на рис. 3.33.

Цикл проверки адекватности (цикл «автор — читатель») начинается с под­готовки аналитиком рабочей группы подшивки схем моделей бизнес-процес­сов. Оптимальный объем такой подшивки — не более 10—12 листов формата А4. Комплект моделей большего объема будет очень трудно воспринимать, что приведет к снижению качества проверки. Количество листов в подшивке определяется из расчета, чтобы время проверки занимало у рецензента не бо­лее полутора-двух часов.

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

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

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

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

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

Аналитик просматривает замечания рецензента. В случае согласия с замеча­ниями он вносит исправления в модели процессов. После этого формируется новый комплект испра1енных моделей также фиксируют­ся в архиве проекта.

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

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

• знать основные цели проекта;

• четко понимать, что от него требуется и в какой форме следует делать
замечания к моделям;

• обучиться основам чтения схем процессов;

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

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

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

Глава 3 Описание и анализ бизнес-процессов______________________________ 1 31

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

Таблица 3.12 Реакция руковолите.чей при проверке адекватности

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

Второй по частоте появления в проекте является попытка рецензента углу­биться в более детальное описание процесса. В этом случае критика модели ведется не по существу, а с той точки зрения, что модель недостаточно под­робна. К сожалению, не многие руководители могут понять концепцию по­этапного рассмотрения процесса сверху вниз. У них постоянно возникают вопросы: «А где накладная?», «Почему вместо трех функций моего отдела здесь стоит одна общая?» и т.п.

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

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

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

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

Источник: poisk-ru.ru

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

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

Такая работа называется проверкой адекватности моделей бизнес-процессов. Существуют определенные правила проверки, в частности многие из них описаны в документации по IDEF0 [2; 3]. Простейшая схема проверки адекватности представлена на рис. 3.35.

Рис. 3.35. Цикл «автор — читатель»

Цикла проверки адекватности (цикл «автор — читатель») начинается с подготовки аналитиком рабочей группы подшивки схем моделей бизнес-процессов. Оптимальный объем такой подшивки — не более 10-12 листов формата А4. Комплект моделей большего объема трудно воспринимать, что приведет к снижению качеству проверки. Количество листов в подшивке определяется из следующего расчета: время проверки должно занимать у рецензента не более полутора-двух часов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: laws.studio