Реализация управляющей компоненты
Формирование управляющей компоненты ню для имитационной модели осуществляется по пожеланиям руководителя объекта, который подвергается имитационному моделированию. Формализация процедуры построения модели управляемого прогноза может быть зафиксирована следующей последовательностью действий:
1) Вычислить все составляющие данного динамического ряда;
2) Оценить составляющие динамического ряда, выбрать те, которые подлежат управлению. Как правило, формировать ню следует отдельно для каждой составляющей с учетом управления на предыдущих этапах.
3) Построить модель управления на базе информации, содержащейся не только в данном динамическом ряду (для воздействия на трендовую или сезонную составляющие).
Целевые ф-ии и крит, исп при иммод
Иммод не ограничивает формы и методы формирования целей и критериев их достижения. Более того, иммод способно применять многокритериальные модели без взвешивания целевых ф-ий и даже без последовательной оптимизации по составляющим многокритериальной ЦФ. Осуществляется увязка критериев вместе с помощью компромисса, когда оптимальное значение по одной ЦФ уменьшается на какой-то процент без учета оптимальных значений других составляющих ЦФ.
Ф-ион мод сист
Построение функциональной модели системы относится к этапу построения структуры объекта. Для построения функциональных моделей можно использовать нотации IDEF0 и IDEF3. Построение функциональных моделей по этим нотациям автоматизируется в программе BPWin.
|
|
|
Описание нотации IDEF0, IDEF3
Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Нотации IDEF0 и IDEF3 используют следующие объекты.
| № | Наименование | Описание | Графическое представление | ||
| Нотация IDEF0 | |||||
| 1 | Модуль поведения (UOB) | Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. | 
| ||
| 2 | Стрелка слева | Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции. | 
| ||
| 3 | Стрелка справа | Стрелка описывает исходящие документы, информацию, материальные ресурсы, являющиеся результатом выполнения функции. | 
| ||
| 4 | Стрелка сверху | Стрелка описывает управляющее воздействия, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки сверху, отражающей управляющее воздействие. | 
| ||
| 5 | Стрелка снизу | Стрелка снизу описывает т.н. механизмы, т.е. ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д. | 
| ||
| Нотация IDEF3
| |||||
| 1 | Модель работы (UOW) | Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. | 
| ||
| 2 | Ссылочный объект | Объект, используемый для описания ссылок на другие диаграммы модели, циклические переходы в рамках одной модели, различные комментарии к функциям | 
| ||
| 3 | Логическое «И» | Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса | 
| ||
| 4 | Логическое «ИЛИ» | Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса | 
| ||
| 5 | Логическое исключающее «ИЛИ» | Логический оператор, определяющий связи функциями в рамках процесса. Позволяет описать ветвление процесса | 
| ||
Таблица 2.
|
|
|
В моделях могут использоваться стрелки трех видов, показанных в следующей таблице 3.
| № | Тип стрелки | Графическое представление |
| 1 | Стрелка предшествования. Соединяет последовательно выполняемые функции. | 
|
| 2 | Стрелка отношения. Используется для привязки объектов-комментариев к функциям. | 
|
| 3 | Стрелка потока объектов. Показывает поток объектов от одной функции к другой. | 
|
Таблица 3.
Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил.
Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рисунке 5. (Этот процесс представлен в нотации ARIS eEPC на рисунке 3).
Рисунок 5.
На рисунке 6 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рисунке 4.)
Рисунок 6.
В ходе реализации программы интегрированной компьютеризации производства (ICAM), предложенной в свое время ВВС для аэрокосмической промышленности США, была выявлена потребность в разработке методов анализа взаимодействия процессов в производственных системах. Для удовлетворения этой потребности была разработана методология IDEF0 (Integrated Definition Function Modeling), которая в настоящее время принята в качестве федерального стандарта США.
|
|
|
Методология успешно применялась в самых различных отраслях, продемонстрировав себя как эффективное средство анализа, проектирования и представления деловых процессов. В настоящее время методология IDEF0 широко применяется не только в США, но и во всем мире. В России IDEF0 успешно применялся в государственных учреждениях (к примеру, в Государственной Налоговой Инспекции), в аэрокосмической промышленности (при проектировании космодрома в Плесецке), в Центральном Банке и коммерческих банках России, на предприятиях нефтегазовой промышленности и предприятиях других отраслей.
Основные понятия IDEF0
В основе IDEF0 методологии лежит понятие блока, который отображает некоторую бизнес-функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение “входа”, правая - “выхода”, верхняя - “управления”, нижняя - “механизма” (см. рис. 1).
Взаимодействие между функциями в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно “входным”, “выходным”, “управляющим”.
Принципы моделирования в IDEF0
В IDEF0 реализованы три базовых принципа моделирования процессов:
принцип функциональной декомпозиции;
принцип ограничения сложности;
принцип контекста.
Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав (см. рис. 2).
Принцип ограничения сложности. При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок - главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, “продавать продукцию”. Главная бизнес-функция системы - это “миссия” системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии.
При определении главной бизнес- функции необходимо всегда иметь ввиду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному.
Контекстная диаграмма играет еще одну роль в функциональной модели. Она “фиксирует” границы моделируемой бизнес- системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию.
Применение IDEF0
После ознакомления с базовыми понятиями и принципами функционального моделирования деловых процессов естественным является вопрос: как это помогает повышать эффективность и качество деятельности предприятия.
01 Построение модели КАК ЕСТЬ. Обследование предприятия является обязательной частью любого проекта создания или развития корпоративной информационной системы. Построение функциональной модели КАК ЕСТЬ позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов.
02 Бизнес-правила. Модель деловых процессов позволяет выявить и точно определить бизнес- правила, используемые в деятельности предприятия.
На рис. 3 представлен фрагмент функциональной модели документооборота. При выполнении операции “сортировать документы” используется бизнес-правило: “регистрации не подлежат: документы, присланные в копии для сведения, телеграммы и письма о разрешении командировок и отпусков ...”. Это правило зафиксировано в инструкции по документообороту. Функциональная модель позволяет не только идентифицировать существование этого правила, но также определить, при выполнении какой операции и на каком рабочем месте оно должно применяться.
В рамках функциональной модели бизнес-правило выглядит следующим образом: “если в приемную поступил документ, предназначенный руководству, он подлежит сортировке, в результате которой на основании инструкции определяется, подлежит ли документ регистрации или нет”.
Если при разработке информационной системы не будет учтено это бизнес- правило, то такая система будет функционировать неадекватно.
Очень часто бизнес- правила на предприятии не записаны в инструкции: они как бы есть, но и их как бы нет. В результате попытки изменить что-либо в деятельности предприятия или подразделения могут закончиться неудачей только лишь потому, что эти изменения противоречат сложившимся бизнес- правилам.
03 Построение модели КАК БУДЕТ. Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес- правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.
04 Распределение ресурсов. Функциональная модель позволяет четко определить распределение ресурсов между операциями делового процесса, что дает возможность оценить эффективность использования ресурсов.
Особенно эта задача актуальна при создании новых деловых процессов на предприятии. Например, компания, которая специализируется на разработке заказного программного обеспечения, приняла решение создать собственную службу сбыта. Функциональная модель делового процесса по продаже программного обеспечения позволит руководству компании четко определить, какие ресурсы необходимо выделить для того, чтобы обеспечить функционирование службы сбыта, сколько сотрудников необходимо привлечь для работы в новой службе, какие функциональные обязанности эти сотрудники должны выполнять и т.д.
Дата добавления: 2021-01-20; просмотров: 61; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!