Idef — Создание логических моделей ПО (методология Aris, IDEF)

Содержание

Методологии IDEF и ARIS

Методологии IDEF и ARIS в задачах моделирования и анализа деятельности предприятия

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

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

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

IDEF позволяет создавать следующие модели:

  • функциональные, отвечающие на вопрос «что делается на предприятии?» (методология IDEF0); эти модели являются основой для создания остальных моделей;
  • информационные модели, представляющие информационную поддержку деятельности (методология IDEF1.x);
  • функционально-стоимостные модели, показывающие «сколько это стоит или может стоить в будущем»;
  • имитационные модели, позволяющие представить «а что будет, если…?», т.е. обыграть некоторые альтернативные варианты развития при различных начальных условиях.

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

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

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

IDEF – более строгое, дешевое и простое в освоении и использовании средство, позволяющее легко решать небольшие по сложности задачи.

ARIS требует больше знаний от аналитиков, однако позволяет решать более серьезные задачи, создавать емкие и наглядные для непрофессионалов модели, имеет интерфейсы с некоторыми CASE-средствами, системы управления проектами, системы электронного документооборота – Workflow, а также является средством создания моделей для непосредственной настройки таких систем управления предприятиями, как R/3 и BAAN. Система содержит готовые библиотеки моделей предприятий различного профиля деятельности (машино- и автомобилестроения, производства мебели, проектирования заводов и т.д.).

Методологии IDEF0 и ARIS для моделирования бизнес-процессов управления персоналом

Читайте также:

  1. I. ОРГАНЫ МЕСТНОГО САМОУПРАВЛЕНИЯ, ПАРТИИ (320 человек)
  2. II. Историческая справка об организации у нас контрразведки до создания Главного управления Генерального штаба и перед Великой войной
  3. II. Японский стиль управления.
  4. III. Компоненты управления цепями спроса
  5. N) стандартные механизмы заключения контрактов с национальным и иностранным персоналом.
  6. V. Ключи к искусству управления 1 страница
  7. V. Ключи к искусству управления 2 страница
  8. V. Ключи к искусству управления 3 страница
  9. V. Ключи к искусству управления 3 страница
  10. V. Ключи к искусству управления 4 страница
  11. V. Ключи к искусству управления 4 страница
  12. V. Ключи к искусству управления 4 страница

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

Вопросы для самопроверки

1. Какие работы являются этапами цикла стратегического управления?

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

3. Чем отличается информационный продукт от информационного сервиса/услуги?

4. Чем отличается методология от стандарта?

5. Как соотносятся проектный и сервисный подходы в жизненном цикле корпоративной информационной системы (КИС)?

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

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

Эти методологии можно представить в виде своего рода промежуточного слоя между бизнесом и ИТ. Гибридность же заключается в том, что в условиях, например, диверсификации бизнеса перед ИТ встают новые задачи по ИТ-поддержке бизнеса, то есть развивать ИТ в компаниях нужно в том же темпе, в котором развивается бизнес. Таким образом, в этих методологиях представлено одновременное сочетание сервисного подхода с проектным. Рассмотрим кратко две наиболее популярные методологии: IDEF0 и ARIS.

IDEF0 — методология и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique).

Исторически IDEF0 как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF — ICAM DEFinition). Последняя его редакция была выпущена в декабре 1993 г. Национальным Институтом по Стандартам и Технологиям США (NIST).

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

ARIS (сокр. от англ. Architecture of Integrated Information Systems) — методология и программный продукт компании немецкой IDS Sheer для моделирования бизнес-процессов компании. Методология ARIS рассматривает предприятие как совокупность четырех взглядов (views): на организационную структуру, структуру функций, структуру данных, структуру процессов. При этом каждый из этих взглядов разделяется еще на три подуровня: описание требований, описание спецификации, описание внедрения. Таким образом, ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту.

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

В основном мы будем рассматривать методологию IDEF0. Выбор обусловлен тем фактом, что методология IDEF0 лежит в основе наших ГОСТов 34-й серии, которые мы рассмотрели в теме № 3, посвященной ИТ, ИС и КИС.

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

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

· бизнес-функции описывают, что делает бизнес;

· бизнес-процессы, описывают, как предприятие выполняет свои бизнес функции;

· организационная структура, определяет, где исполняются бизнес-функции и бизнес-процессы;

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

· роли, определяющие, кто исполняет бизнес-процессы;

· правила, определяющие связь что, как, где, когда и кто.

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

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

Как правило, в «доинформационную эпоху» для этого использовались графические средства в виде схем, украшавшие стены кабинетов менеджеров, в которых отражались «организационно-штатная структура», «диаграммы потоков данных» (ДПД или DFD — Data Flow Diagramming, предназначенные для описания потоков данных), документооборот компании. Эти «телодвижения» менеджеров стали прообразом методик ДМД-моделирования, входящих в семейство CASE-технологий (computer aided software engineering) — компьютерное проектирование программных систем.

Напомним основные элементы и понятия IDEF0.

В основе графического языка методологии IDEF0 лежат четыре основных понятия:

1. Понятие функционального блока (Activity Box).Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемого бизнеса. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

o верхняя сторона имеет значение «Управление» (Control);

o левая сторона имеет значение «Вход» (Input);

o правая сторона имеет значение «Выход» (Output);

o нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

2. Вторым понятием является понятие интерфейсной дуги (Arrow) . Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент бизнес-системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта наименование должно быть оборотом существительного. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие бизнес-процессы. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом «источником» может быть только выходная сторона блока, а «приемником» любая из трех оставшихся. Необходимо отметить, что любой функциональный блок по требованиям IDEF0 должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно — каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Существуют трудности в различии между входящими и управляющими интерфейсными дугами, которые имеют внешне схожую природу. Однако для преодоления этих трудностей, а также для проведения более определенного разграничения, экосистему бизнеса классифицируют на пять основных видов объектов:

o материальные потоки (детали, товары, сырье и т.д.);

o финансовые потоки (наличные и безналичные, инвестиции и т.д.);

o потоки документов (коммерческие, финансовые и организационные документы);

o потоки информации (данные о намерениях, устные распоряжения и т.д.);

o ресурсы (сотрудники, компьютеры, машины и т.д.).

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

o Что поступает в подразделение «на входе»?

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

o Кто является ответственным за выполнение каждой из функций?

o Чем руководствуется исполнитель при выполнении каждой из функций?

o Что является результатом работы подразделения («на выходе»)?

3. Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного бизнес-процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель бизнеса в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель IDEF0 всегда начинается с представления бизнеса как единого целого — одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой и обозначается идентификатором «А-0». В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Различные цели моделирования предполагают разработку и различных моделей бизнес-процессов, то есть, например, цель «оптимизируем финансовые потоки» приводит к другой модели, нежели цель «оптимизируем логистические цепочки». Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на моделирование бизнеса. Это и понятно, так как точка зрения, допустим, финансового директора предприятия может существенно отличаться от точки зрения главного технолога на одни и те же бизнес-процессы. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком — Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит — родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм — каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует. Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот — отдельные дуги не имеют практического смысла выше какого-то уровня — это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования . Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии — в таком случае они сначала «погружаются в туннель», а затем, при необходимости, «возвращаются из туннеля».

4. Последним из понятий IDEF0 является глоссарий (Glossary) . Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) существует набор соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

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

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

1. Анализ бизнес-среды.

2. Разработка стратегии предприятия.

3. Формирование общего видения компании (глобальный уровень).

4. Формирование детального описания процессов компании «как есть» и «как будет».

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

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

7. Описание требований к информационным системам поддержки деятельности.

8. Проектирование интегрированных информационных систем.

9. Проведение документирования результатов проекта.

10. Проведение анализа разработанных моделей (количественный и сравнительный анализ, анализ семантики, анализ стоимостных и временных характеристик).

11. Интеграция моделей с функционирующими информационными системами (актуализация организационной структуры, номенклатуры, показателей).

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

5.2.Примеры моделирования бизнес-процессов: «Прием специалиста в штат», «Увольнение сотрудника»

Рассмотрим опыт применения систем бизнес-моделирования для потребностей менеджера по управлению персоналом по рекомендациям консалтинговой компании «Бизнес-инжиниринговые технологии».

Итак, первый бизнес-процесс «Прием специалиста в штат компании» имеет:

· точку зрения на бизнес-процесс от генерального директора компании;

· цели бизнес-процесса в виде «Формирования штата»;

· назначение бизнес-процесса – «Обеспечение компании необходимыми специалистами»;

· выходы — «Заполненное рабочее место», «Приказ, трудовая книжка, личное дело, карточка учета Т-12», «Информация об отказе», и «Объявления»;

· клиентов бизнес-процесса — «Профильное подразделение», куда поступает на работу сотрудник, «Кадровый архив», «Соискатель должности» и «Средства массовой информации — СМИ»;

· входы и поставщиков бизнес-процесса – «Запрос», «Соискатель», «Резюме», «Информация о кадровом резерве», «Профильное подразделение», «Рынок труда», «Кадровые агентства», «Сотрудники компании»;

· кроме того, поставщиками данного бизнес-процесса являются два других бизнес-процесса — «Сбор данных по специалистам» и «Формирование кадрового резерва»;

· основные стадии бизнес-процесса — «Первичный отбор», «Проведение встречи», «Вторичный отбор», «Стандартное согласование кандидатур», «Оформление трудовых отношений»;

· начало бизнес-процесса — «Запрос от профильного подразделения»;

· окончание бизнес-процесса — «Специалист принят в штат и занял рабочее место».

Таблица 5.1
Структура действий по стадиям бизнес-процесса

Структура действий (функциональная структура) бизнес-процесса «Прием специалиста в штат компании»
1. Первичный отбор 2. Проведение встречи 3. Вторичный отбор 4. Стандартное согласование кандидатур 5. Оформление трудовых отношений
1.1. Просмотр резюме 1.2. Форматирование списка звонков 1.3. Выполнение звонков 2.1. Согласование времени встречи 2.2. Проведение встречи 2.3. Сортировка резюме 3.1. Составление представлений 3.2. Согласование интересных представлений с начальником управления персоналом 3.3. Формирование группы из трех кандидатов 4.1. Оформление листа согласований 4.2. Прохождение согласования 4.3. Принятие решения о предоставлении листа согласованиий Генеральному директору 4.4. Получение решения у Генерального директора 5.1. Определение даты выхода на работу 5.2. Сбор документов 5.3. Оформление приказа о приеме на работу 5.4. Передача приказа на подпись Генеральному директору 5.5. Направление на рабочее место

Таблица 5.2
Структура потоков объектов информации

Структура потоков объектов бизнес-процесса «Прием специалиста в штат компании»
Информация на бумажных носителях (документы) Устная информация Информация в электронном виде Прочие потоки объектов
  • запрос
  • ежедневный отчет
  • представление
  • лист согласований
  • резюме (от соискателей, используемое при отборе)
  • приказ, трудовая книжка, личное дело, карточка Т-12
  • решение директора о приеме на работу
  • запрос к соискателю
  • телефонный звонок
  • устные комментарии
  • информация об отказе
  • контакт с соискателем
  • объявления
  • резюме (из кадровых агентств, из бизнес-процесса «Сбор данных по специалистам», от соискателей
  • информация о кадровом резерве
  • соискатель
  • заполненное рабочее место

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

Таблица 5.3
Матрица ответственности бизнес-процесса «Прием специалиста в штат»

Организационная структура бизнес-процесса Структура действий (функциональная структура) бизнес-процесса
1. Первичный отбор 2. Проведение встречи 3. Вторичный отбор 4. Стандартное согласование кандидатур 5. Оформление трудовых отношений
Генеральный директор (ГД) х
Начальник управления персоналом (НУП) х
Руководитель профильного подразделения (РПП) х
Менеджер по подбору персонала (МПП) х х х
Менеджер по документообороту трудовых отношений (МДТО) х

Второй бизнес-процесс, бизнес-моделирование которого мы рассмотрим — это «Увольнение сотрудника», выполненный в нотациях DFD и IDEF0:

· первичная диаграмма А0 ;

· диаграмма А0. Бизнес-процесс «Увольнение сотрудника» ;

· диаграмма А1. «Визировать заявление у непосредственного руководителя и оформить обходной лист» ;

· потоки объектов бизнес-процесса «Заполнить обходной лист» ;

· декомпозиция блока «Издать приказ об увольнении». Диаграмма А2 ;

· декомпозиция блока «Произвести расчеты с бухгалтерией». Диаграмма А3 ;

· декомпозиция блока «Оформить и выдать трудовую книжку сотруднику». Диаграмма А5 .

Дата добавления: 2015-07-02 ; Просмотров: 2674 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Сравнительный анализ нотаций ARIS и IDEF

равнительный анализ нотаций ARIS и IDEF приводится в табл. 5.

Таблица 5. Объекты нотаций ARIS, IDEF0 и IDEF3

Критерии сравнения ARIS IDEF0 IDEF3
Принцип построения диаграммы/логика процесса Временная последовательность выполнения процедур Принцип доминирования (см. стандарт IDEF0) Временная последовательность выполнения процедур
Описание процедуры процесса Объект на диаграмме Объект на диаграмме Объект на диаграмме
Входящий документ Используется отдельный объект для описания («документ») Стрелка входа, стрелка управления Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Входящая информация Используется отдельный объект для описания («кластер», «технический термин») Стрелка входа, стрелка управления Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Исходящий документ Используется отдельный объект для описания («документ») Стрелка выхода Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Исходящая информация Используется отдельный объект для описания («кластер», «технический термин») Стрелка выхода Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)
Исполнитель процедуры Используется отдельный объект для описания («позиция», «организационная единица») Стрелка механизма Нет (может быть отражен в модели только привязкой объекта ссылки)
Используемое оборудование Используется отдельный объект для описания Стрелка механизма Нет (может быть отражен в модели только привязкой объекта ссылки)
Управление процедурой Нет. Может быть отражено только символами логики и событий (последовательность выполнения процедур) и/или указанием входящих документов Стрелка управления Только временная последовательность выполнения процедур и логика процесса
Контроль выполнения процедуры Нет. Может быть отражен указанием входящих документов Стрелка управления Нет (может быть отражен в модели только привязкой объекта ссылки).
Обратная связь по управлению/контролю Нет. Может быть отражена только символами логики (последовательность выполнения процедур) Стрелка управления Нет
Обратная связь по входу Нет. Может быть отражена только символами логики (последовательность выполнения процедур) Стрелка входа Нет

Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления — стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Workflow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются.

На рис. 12 функция 4 является контрольной и служит для проверки результатов работы, выполняемой функциями 2 и 3. Но данная модель не отвечает на вопросы:

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

2. раскрыта только в виде описания в атрибутах объектов модели;

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

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

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

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

Лучшие изречения: Сдача сессии и защита диплома — страшная бессонница, которая потом кажется страшным сном. 8776 — | 7148 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Методология >

Методология моделирования IDEF1X, являясь расширением стандарта IDEF1, предназначена для описания данных (информации). В ее основе лежит язык семантического моделирования, основанного на концепции «сущность — связь», позволяющей определять данные и связи между ними. Методология используется для создания информационной модели предметной области с помощью идентификации ее сущностей и связей между ними. Чаще всего такая методология используется для описания данных в целях последующей автоматизации их обработки с помощью систем управления базами данных. Таким образом, можно говорить о том, что модели данных в нотации IDEF1X используются для создания баз данных.

Основными элементами модели IDEF1X являются сущности, атрибуты и отношения.

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

  • • диаграмма «Сущность — связь» (Entity Relationship Diagram — ERD);
  • • модель данных, основанная на ключах (Key Based Model — КВМ);
  • • полная атрибутивная модель (Fully Attributed Model — FAM).

Диаграмма «сущность — связь» используется для описания данных

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

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

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

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

  • • первая нормальная форма (1NF):
  • • вторая нормальная форма (2NF);
  • • третья нормальная форма (3NF):
  • • нормальная форма Бойса — Кодда (усиленная 3NF);
  • • четвертая нормальная форма (4NF):
  • • пятая нормальная форма (5NF) [1] .

Основными элементами модели IDEF1X являются: сущности, атрибуты и отношения.

Сущность — это множество реальных или абстрактных объектов, обладающих общими характеристиками, например, персонал, явления, предметы. Каждый такой объект может быть представлен только одной уникальной сущностью.

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

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

Рис. 5.14. Сущность в нотации IDEF1X

Сущности бывают зависимые, которые представляют типы данных, зависящие от других данных. Такие сущности всегда имеют отношения с другими сущностями. Различают несколько типов зависимых связей [2] :

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

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

Примеры независимых сущностей показаны на рис. 5.15.

Рис. 5.15. Независимые сущности в нотации IDEF1X Атрибут — характеристика сущности. Каждый атрибут имеет один или несколько экземпляров атрибутов, т.е. конкретных значений. Таким образом, каждый конкретный экземпляр сущности будет иметь конкретный экземпляр атрибутов.

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

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

Первичный ключ, который наследуется от родительской сущности, называется внешним ключом.

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

Отношения — это связи между двумя и более сущностями.

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

  • • идентифицирующие отношения (сущность однозначно определяет другую сущность);
  • • неидентифицирующие отношения;
  • • отношения «многие ко многим»;
  • • отношения категоризации.

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

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

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

Рис. 5.16. Связь типа «многие ко многим» в нотации IDEF1X

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

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

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

  • 1) одному экземпляру родительской сущности соответствует 0, 1 или много экземпляров дочерней сущности, на диаграмме связь не помечается каким-либо символом;
  • 2) одному экземпляру родительской сущности соответствует 1 или много экземпляров дочерней сущности, на диаграмме связь помечается символом «Р», например «сотрудник»;
  • 3) одному экземпляру родительской сущности соответствует О или 1 экземпляр дочерней сущности, на диаграмме связь помечается символом «Z»;
  • 4) одному экземпляру родительской сущности соответствует заранее заданное количество экземпляров дочерней сущности, на диаграмме связь помечается цифрой, соответствующей количеству экземпляров дочерней сущности.

Примеры приведены в табл. 5.2.

Примеры типов мощностей связей между сущностями

Методология функционального моделирования >

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

IDEF (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).[1]

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

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

IDEF0 – Integration DEFinition language – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей. [pdf]

Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

IDEF0 используется для создания функциональной модели, то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0.

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

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

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

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

Цели стандарта IDEF0 [pdf]

Основные цели (objectives) стандарта:

задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;

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

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

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

общий (generic) – для анализа систем и предметных областей;

строгий и точный (rigorous and precise) – для создания корректных, пригодных к использованию моделей);

краткий (concise) – для облегчения понимания, коммуникации, согласия между заинтересованными лицами и проверки. (to facilitate understanding, communication, consensus and validation);

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

гибкий ­– для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision) [IDEF.com (http://www.idef.com/IDEF0.htm)]

Правила IDEFØ требуют достаточной строгости и точности для удовлетвроения нужд без чрезмерных ограничений аналитика (to satisfy needs without overly constraining the analyst). IDEFØ правила включают следующее:

управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпозиции;

связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей;

связанность интерфейса диаграмм (Diagram Interface Connectivity) – номера узлов, функциональных блоков, C-numbers и Detail Reference Expression);

связанность структуры данных. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий;

синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;

ограничения на разветвления стрелок данных (Data Arrow Branch Constraint) – метки для ограничений потоков данных на разветвлениях;

разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);

маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);

наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;

цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

Основные понятия IDEF0

В основе методологии лежат четыре основных понятия:

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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

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

верхняя сторона имеет значение «Управление» (Control);

левая сторона имеет значение «Вход» (Input);

правая сторона имеет значение «Выход» (Output);

нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Последним из понятий IDEF0 является глоссарий (Glossary).

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

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

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

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

Сравнительный анализ нотаций ARIS и IDEF при описании процессов Текст научной статьи по специальности « Экономика и экономические науки»

Похожие темы научных работ по экономике и экономическим наукам , автор научной работы — Кривоносова И.Н., Сюткин Г.Н.,

Текст научной работы на тему «Сравнительный анализ нотаций ARIS и IDEF при описании процессов»

Сектор услуг является единственным быстрорастущим в российской экономике.

И.Н. Кривоносова, аспирант ГОУВПО «МГУС» г. Москва Г.Н. Сюткин

к.э.н., доцент кафедры «Стандартизация, патентоведение и менеджмент качества»

ГОУВПО «МГУС» г. Москва

СРАВНИТЕЛЬНЫЙ АНАЛИЗ НОТАЦИЙ АЯК И ШЕЕ ПРИ ОПИСАНИИ

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

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

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

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

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

Любая графическая схема должна удовлетворять следующим требованиям:

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

2) на схеме должны отображаться реальные документы, ресурсы;

3) схема должна быть проста и понятна для визуального восприятия;

4) схема процесса должна иметь компактный размер.

Графическая схема должна давать ответы на следующие вопросы:

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

— в какой последовательности выполняются эти процедуры;

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

— кто выполняет процесс;

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

— какие исходящие документы/информацию генерирует процесс;

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

— какая документация/условия регламентирует выполнение процесса;

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

В настоящее время для целей описания процессов наиболее часто используют схемы потоков работ (Work Flow): ARIS eEPC, IDEF0, IDEF3, блок-схемы в Visio.

Сравнительный анализ нотаций ARIS и IDEF

Процессы в нотациях ARIS, IDEF 0 и IDEF 3 представляют собой последовательность процедур, расположенных в логическом порядке их выполнения. Реальная длительность выполнения процедур визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Таким образом, при помощи нотаций можно описывать процессы в виде потока последовательно выполняемых работ (процедур, функций).

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

Одним из важнейших аспектов описания моделей процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF каждая процедура должна иметь хотя бы одно управляющее воздействие. Если при создании модели в ARIS указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром».

Часто одним из недостатков IDEF сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. В ARIS ограничения на количество объектов нет, а вот в IDEF оно составляет от 0 до 8 и при большом объеме данных нотацию IDEF использовать затруднительно.

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

Таким образом, для ведения небольших по масштабам и длительности проектов рационально использовать IDEF. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения процессов) больше подходит ЛЫЖ

Описание бизнес-процессов: SADT, >

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

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

Модель бизнес-процессов и описание бизнес-процессов, разработанные компанией BSC, дают ответы на следующие вопросы:

Для построения моделей бизнес-процессов и описания бизнес-процессов компания BSC использует методологии SADT, семейства IDEF, DFD, UML, ARIS и другие.

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

SADT (Structured Analysis and Design Technique)

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

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


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


DFD (Data Flow Diagrams)

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

UML (Unified Modeling Language)

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

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

ARIS (Architecture of Integrated Information Systems)

Методология и программный продукт компании IDS Sheer для моделирования бизнес-процессов и описания бизнес-процессов компании. Методология ARIS является достаточно рафинированной. Организация в ARIS рассматривается с четырех точек зрения:

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

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

Нотации IDEF0 и ARIS VAD

В табл. 2.4 приведен сравнительный анализ нотаций моделирования бизнес-процессов ARIS VAD и IDEFO. Обе эти нотации предназначены для описания процессов организации на верхнем уровне.

Таблица 2.4 Сравнение нотаций IDEFO и ARIS VAD

Критерии Нотация
п.п. сравнения ARIS VAD IDEFO
Принцип Временная последовательность Принцип доминирования
построения выполнения процедур. (см. стандарт IDEF0).
диаграммы Используется тип связи Функции связаны потоками
is predecessor of данных и материальных
ресурсов
Описание процедуры Объект на диаграмме Объект на диаграмме
процесса
Использование Не регламентировано. Стороны Регламентировано. Каждая
сторон объекта объекта Value-added process chain сторона объекта Activity
«процесса» не имеют специального назначения (функция, процесс) имеет
для отображения специальный смысл:
различных видов входы, выходы,
входов управление, механизмы
Входящий Не используется специальный Стрелка входа, стрелка
документ объект для отображения документов. управления
Может использоваться объект
Technical Term
Входящая Используется отдельный объект Стрелка входа, стрелка
информация Cluster. Может быть использован управления
объект Technical Term
Исходящий Не используется специальный Стрелка выхода
документ объект для отображения документов
Может использоваться объект
Technical Term
Исходящая Используется отдельный объект Стрелка выхода
информация Cluster. Может быть использован
объект Technical Term

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

Таблица 2.4 (окончание)

N9 Критерии Нотация
п.п. сравнения ARIS VAD IDEF0
Исполнитель Используются отдельные объекты Стрелка механизма
процесса для описания: Position,
Organizational Unit
Используемое Используется отдельный объект Стрелка механизма
оборудование для описания: Product, Product/Service.
Может быть использован объект
Technical term
Управление Нет средств для отображения Стрелка управления
процессом управления процессом. (стрелка сверху)
Возможно косвенное отображение
управления при помощи входящих
документов, информации
Обратная связь Не может быть отображена. Стрелка управления.
по управлению/ Есть возможность однократно (Есть требования
контролю показать обратную связь типа по отображению обратных
is predecessor of связей по управлению)
Обратная связь Не может быть отображена. Стрелка входа
по входу Есть возможность однократно (Есть требования
показать обратную связь типа по отображению обратных
is predecessor of связей по информации)
Миграция потоков Принципиально невозможна Предусмотрена
данных и ресурсов миграция стрелок
при декомпозиции вниз и вверх
Туннелирование Принципиально невозможна Предусмотрено
потоков данных туннелирование стрелок
и ресурсов вверх и вниз
при декомпозиции
Автоматическая Не предусмотрена Предусмотрена
нумерация узлов
(процессов)
Стандартная форма Не регламентирована. Регламентирована.
представления Нет рекомендаций Рамка IDEF0.
диаграммы по форматированию моделей Развитая система
процесса при ARIS VAD при документировании обозначений на диаграмме
документировании
Ограничения по ко- Количество объектов Рекомендовано не более
личеству объектов не ограничено шести. Общее количество
на диаграмме не ограничено
процесса

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

Глава 2 Выбор методологии описания бизнес-процессов______________________ 105

вательность процедур во времени — больше подходит для создания моделей клас­са Work Row (например, моделей IDEF3). Метод ARIS VAD лишен важнейших практически необходимых инструментов, таких как отображение входов управле­ния процессом, возможность описания обратных связей, миграция связей (вхо­дов/выходов процесса) при декомпозиции и др.

В методических материалах [6| по использованию нотации ARIS VAD можно найти следующие рекомендации. На первом этапе работы формируют модели верхнего уровня в нотации ARIS VAD. Затем эти модели декомпозируют в нота­ции ARIS eEPC. Но допускается также создание нескольких уровней декомпо­зиции в нотации ARIS VAD, что исключительно неудобно, так как декомпози­руемые модели никак не связаны с моделями верхнего уровня (кроме формаль­ной принадлежности). При дальнейшеи декомпозиции процессов в нотации ARIS eEPC приходится «вручную» заботиться о связности создаваемых моделей, так как на верхнем уровне составляющие процессов в нотации ARIS VAD были слабо взаимоувязаны между собой через потоки информации и ресурсов, носи­ли чисто иллюстративный характер, как показано на рис. 2.45.

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

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

здесь мы делаем акцент на том, что описание процессов в ARIS VAD на верхнем уровне существенно менее удобно, чем в IDEF0. Кроме того, работа в ARIS VAD является значительно более трудоемкой. Так, количество операций по ото­бражению процесса в ARIS VAD увеличиваются в два и более раз, чем при создании аналогичной модели в IDEF0. На рис. 2.46 и 2.47 приводится поясне­ние данной оценки трудоемкости.

Видно, что для отображения простейшего процесса из двух функций в IDEF0, включающего один поток материальных ресурсов и две обратных связи, потре­бовалось отображение пяти объектов (две функции и три стрелки). В нотации ARIS VAD для отображения рассматриваемого процесса потребовалось 12 объек­тов (два объекта Value-added process chain, два — Cluster, один — Technical term.

Глава 2 Выбор методологии описания бизнес-процессов 107

семь стрелок). Таким образом, трудоемкость описания процесса в нотации ARIS VAD существенно больше, а это отражается на времени выполнения проекта и величине требуемых ресурсов.

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

Таблица 2.5 Способы описания бизнес-процессов верхнего уровня

Способ блок-схем Комплексный подход
Данный подход предполагает быстрое Использование методологии IDEF0 является
эскизное описание схем бизнес-процессов оптимальным вариантом для описания
верхнего уровня. Не требуется создавать бизнес-процессов на верхнем уровне, так как
комплексную модель. При такой постановке позволяет отобразить информационные
задачи можно использовать простейшие и материальные потоки, требования
средства визуализации блок-схем процессов, к персоналу и инфраструктуре, управляющие
например MS Word или Visio. воздействия и обратные связи. Методология
Использование IDEF0 не рекомендуется, соответствует определению процесса
так как получаемые схемы процессов в МС ИСО 9000:2000.
являются слишком сложными. Использование ARIS VAD не обеспечивает
Использование ARIS VAD возможно, получения комплексных, связных моделей
но не дает существенных преимуществ верхнего уровня, поэтому не рекомендуется
для создания моделей такого типа

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

На заметку

Путеводитель по нотациям и методологиям

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

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

3. Сравнить методологии и нотации моделирования для вашего типа модели и выбрать подходящую для вас методологию:

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

4. Построить модель.

Путеводитель по нотациям и методологиям

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

Методологии
\Типы
Модель управления / модель потоков данных Модель потоков работ
(детализация бизнес процесса)
Информационная
модель
Классические методологии DFD WFD ERD
Семейство IDEF IDEF0 IDEF3 IDEF1x
ARIS VADC
(Value Added Chain),
FAD
(Function Allocation Diagramm)
eEPC,
BPMN,
UML Activity Diagramm
ERD
(Entity Relationship Diagramm),
UML Class Diagramm
UML Use Case Diagramm UML Activity Diagramm UML Class Diagramm

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

Классические методологии

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

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

DFD (Data Flow Diagram) — стандарт описания процессов верхнего уровня и потоков данных, которые преобразуются функциями данного процесса.

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

WFD (Workflow Diagram) — стандарт описания потоков работ. Используется для детализации функций бизнес процесса.

Нотация WFD имеет дополнительные элементы для описания бизнес процесса:

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

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

ERD (Entity Relaishionship Diagram) — стандарт описания информационной модели.

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

Основные нотации: ERD (Нотация Чена), UML (Class Diargamm), IDEF1x.

Семейство методологий IDEF

Семейство методологий IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing).

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

  • IDEF0 — методология моделирования бизнес процессов верхнего уровня.
  • IDEF1X (IDEF1 Extended) — методология построения реляционных структур и построения информационной модели бизнес процесса.
  • IDEF3 — методология детализации функций бизнес процесса. С помощью методологи описываются сценарий и последовательность операций для каждого процесса.

Методология (подход) Swimmer lanes

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

В основе методологии — диаграмма Румлера-Брейча. Румлер предложил разделить диаграмму на дорожки по следующему принципу:

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

Широко известная нотация моделирования бизнес процессов BPMN является прямым потомком диаграммы Румлера-Брейча.

ARIS методология

Согласно методологии, организация рассматривается с четырех точек зрения:

  • Организационной структуры;
  • Функциональной структуры;
  • Структуры данных;
  • Структуры процессов.

Среди множества типов диаграмм, которые предлагаются в методологии, можно выделить следующие:

  • VADC (Value Added Chain) — диаграмма цепочки добавленной стоимости. Используется для моделирования бизнес процесса верхнего уровня и потоков данных. Разновидность DFD стандарта.
  • FAD (Function Allocation Diagram) — диаграмма окружения процесса.
  • eEPC (extended Event-driven process chain) — диаграмма расширенной модели цепочки процессов, управляемых событиями. Разновидность WFD — диаграмм, является расширением нотации IDEF3. Используется для детализации функций бизнес процессов и моделирования потоков работ.
  • ERD (Entity-Relaishionship Diagram) — диаграмма типа «Сущность-Связь». Используется для описания структуры информации и построения концептуальной модели данных.
  • UML;

[note]Так же методология поддерживает нотацию BPMN.[/note]

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

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

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

  • Activity Diagram — диаграмма деятельности, используется для детализации бизнес процесса.
  • >

Курсовая работа: Разработка модели предприятия тепличного хозяйства, используя методологии проектирования > Название: Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD и IDEF3
Раздел: Рефераты по экономико-математическому моделированию
Тип: курсовая работа Добавлен 10:17:47 26 ноября 2009 Похожие работы
Просмотров: 14143 Комментариев: 16 Оценило: 7 человек Средний балл: 4.1 Оценка: 4 Скачать

Министерство образования и науки РФ

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

«Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD и IDEF3»

2. Теоретическое введение

3. Описание предметной области

4. Описание BPwin

4.1 Принцип построения модели IDEF0

4.2 Принцип построения модели DFD

4.3 Принцип построения модели IDEF3

5.1 Модель тепличного хозяйства

5.2 Математическая модель

6. Сравнительный анализ

6.2 Сравнение инструментальных средств

Целями данной курсовой работы были:

применение методов предпроектного обследования предприятия;

анализ полученных материалов для последующего моделирования;

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

описание документооборота и обработки информации в стандарте DFD;

описания процессов в стандарте IDEF3;

разработка смешанной модели описания процесса на основе стандартов IDEFO, DFD и IDEF3.

создание сценариев работы предприятия;

построение структурной схемы предприятия;

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

2. Теоретическое введение

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

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

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

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

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

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

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

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

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

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

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

3. Описание предметной области

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

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

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

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

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

Служба охраны труда, основная функция которого подготовка персонала;

Бухгалтерский отдел занимается документооборотом;

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

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

Отделы, службы и рабочие места данного предприятия представлены в таблице №1:

Задачи и функции нашего тепличного хозяйства показаны в таблице №2:

Документация представлена в таблицах №3:

Справочник организаций представлен в таблице №4:

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

Схема сценария работы предприятия

4. Описание BPwin

BPwin относится к малым интегрированным средствам моделирования, которые поддерживают несколько типов моделей и методов.

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня — BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Основной из трех методологий, является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.

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

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

В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEFO, так и IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А3.1 А3.2, АЗ.З, А3.4 и т. д.

В результате дополнения диаграмм, IDEFO диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEFO изображаются зеленым цветом, DFD – синим.

BPwin так же как и локальные интегрированные системы, практически не позволяют выполнить комплексный анализ систем, который в большей или меньшей степени необходим для создания малых, средних и крупных ИСУП. С их помощью можно разрабатывать локальные ИС или небольшие подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, т. е. когда нет необходимости в комплексном анализе предприятия. Типичная сфера использования малых интегрированных средств — решение задач так называемой “кусочной” автоматизации предприятия.

4.1 Принцип построения модели IDEFO

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

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

Модель может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

диаграммы дерева узлов;

диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

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

верхняя сторона имеет значение «управления»;

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

Изобразительным элементом, представляющим «поток», является стрелка.

Управление — это что управляет деятельностью бюро, в данной разрабатываемой модели — это законы об индивидуальном ПУ.

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

Стрелки «выхода» – выходные данные. В контекстной диаграмме – это различные сведения, которые подаются в Пенсионный фонд РФ.

Стрелка «механизма» — это влияющие на процессы данные. В диаграмме – это персонал и ПК.

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

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

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

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor.

4.2 Принцип построения модели DFD

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

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.

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

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

4.3 Принцип построения модели IDEF3

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

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

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

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

разветвления стрелок (Fan-out Junction)

Обозначение Наименование Смысл в случае слияния стрелок (Fan-in Junction)
||& Asynchronous AND Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены
||&|| Synchronous AND Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно
||O Asynchronous OR Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
||O|| Synchronous OR Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно
||X Только один предшествующий процесс завершен Только один следующий процесс запускается

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEFO и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка |R| – (добавить в диаграмму объект ссылки — Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Цукерберг рекомендует:  Консольное приложение на Java за час

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих