Знакомство с нотацией IDEF0 и пример использования. Функциональная методика IDEF0

Одна картинка стоит тысячи слов

Народная мудрость

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

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

Несколько слов о преимуществах графики

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

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

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

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

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

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

Почему это важно для моей работы

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

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

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

Типичные ошибки

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

Использование различных цветов

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

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

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

Слишком большое количество блоков

При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок. Читабельность при этом теряется.

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

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

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

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

Выгоды использования IDEF0

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

В чем трудность применения IDEF0

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

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

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

Еще статьи по данной теме.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

курсовая работа , добавлен 03.05.2014


Создание сети подпроцессов. Определение цели процесса. Описание процесса верхнего уровня в методологии IDЕF0. Описание детальных процессов в методологии DFD. Управление проектированием с помощью методологии IDЕF3. Управление корректирующими действиями.

контрольная работа , добавлен 05.06.2016


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

курсовая работа , добавлен 13.02.2012


Понятие бенчмаркинга, его виды, этапы разработки в страховой компании и роль в управлении. Финансово-экономический анализ доходов и расходов страховой компании. Характеристика страховой компании. Управление в "АльфаСтраховании" посредством бенчмаркинга.

курсовая работа , добавлен 14.04.2014


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

дипломная работа , добавлен 28.04.2011


Управление кадрами в страховой компании. Характеристика страховой компании ЗАО СК "АСКО-Центр" и совершенствование менеджмента человеческих ресурсов. Расчет экономической эффективности при увеличении количества рабочих мест и подготовки кадров фирмы.

дипломная работа , добавлен 02.03.2008


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

контрольная работа , добавлен 15.09.2014


Теоретические основы условий труда персонала. Анализ деятельности и оценка использования рабочего времени менеджеров страховой компании Филиал ООО "РГС-Урал" "Управление по Челябинской области", предложения по совершенствованию условий труда ее персонала.

дипломная работа , добавлен 22.12.2010

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

Ручкина В.Н .,
аспирант Донецкого национального университета

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

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

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

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

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

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

Методология объектно-ориентированного анализа и проектирования с помощью унифицированного языка моделирования UML («Unified Modeling Language») позволяет отразить динамику процессов компании.

Следующим шагом на этом этапе является выбор средств и систем моделирования бизнеса. Системы CASE («Computer-Assisted Software Engineering» ) наиболее подходят для этого. Выбор CASE зависит от выбранной методологии моделирования. Технология классического структурного моделирования полностью реализуется с помощью системы BPWin, входящей в комплекс программ Computer Associates AllFusion Modeling 4.1. В системе BPWin создаются модели процессов следующих стандартов (нотаций): IDEF0, DFD и IDEF3.

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

Созданные с применением BPWin диаграммы позволяют точнее сформулировать постановку задачи и наметить этапы ее решения.

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

Учет договоров страхования включает следующие процессы:

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый шаг на этапе программирования предусматривает выбор и проектирование модели хранения данных. ERWin, входящий в набор Computer Associates AllFusion Modeling 4.1, позволяет спроектировать выбранную модель данных с использованием диаграмм DFD.

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

Последним шагом на этапе программирования является тестирование и отладка как отдельных частей программы, так и всей системы.

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

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

Рассмотрим подробнее работу экспертного блока. Этот блок представляет собой экспертную систему (ЭС) способную решать основные задачи компании, такие, как:
- оперативность принятия решения по выбору продукта страхования для клиента по заданным условиям страхования;
- возможность проведение андеррайтенговой политики в режиме on-line для структурных подразделений компании, которые удалены от головного офиса компании;
- анализ и прогнозирование тарифной политики по видам страхования, страховым продуктам компании;
- анализ деятельности компании на отчетную дату по заданным классификационным параметрам (например, поступления платежей по продающим подразделениям компании, по видам страхования, по страховым продуктам; оперативная информация по заявленным убыткам по компании, по видам страхования, по страховым продуктам; оперативная информация по фактическим выплатам; информация о техническом результате деятельности компании на любую дату).
Экспертная система оперирует как со знаниями, выработанными в области страхования, так и данными, накапливаемыми страховой компании. Программа решает поставленные задачи посредством логического вывода, имея доступ к системе фактов, и выводит заключения из информации, имеющейся в базе знаний. База знаний (БЗ) состоит из трех частей:

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

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

3. Система пользовательского интерфейса. Может помочь пользователям при работе с ЭС, даже если они не знают, как она организована; объясняет пользователю, как получить результат.

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

Также по этой теме.

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

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

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

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

Функциональная методика IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT ( Structured Analysis and Design Technique ). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing ). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы ( IDEF = Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США ( NIST ).

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

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

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

• верхняя сторона имеет значение "Управление" (Control);
• левая сторона имеет значение "Вход" (Input);
• правая сторона имеет значение "Выход" (Output);
• нижняя сторона имеет значение "Механизм" ( Mechanism ).

Рис. 6.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Какие функции и в какой последовательности выполняются в рамках подразделения?
  • Кто является ответственным за выполнение каждой из функций ?
  • Чем руководствуется исполнитель при выполнении каждой из функций ?
  • Что является результатом работы подразделения (на выходе)?

  На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

Введение

Успех страхового бизнеса в России целиком зависит от уровня его автоматизации.

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

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

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

Рассмотреть предметную область деятельности предприятия;

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

Выполнить логическое и физическое проектирование ИС;

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

Объектом исследования является страховая компания «Росгосстрах».

Теоретическая часть

1.3 Case- средство AllFusion Process Modeler

AllFusionProcessModeler (далееBPwin) – CASE-средство для моделирования бизнес-процессов, позволяющая создавать диаграммы в нотации IDEF0, IDEF3, DFD. В процессе моделирования BPwin позволяет переключиться с нотации IDEF0 на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. BPwin поддерживает функционально-стоимостной анализ (ABC).

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

Рисунок 1 – Создание новой модели

От выбора типа модели зависит в каких нотациях можно производить декомпозицию работ. Так, если выбрать тип Business Process (IDEF0), то в созданной модели можно производить декомпозицию работ в нотациях IDEF0, IDEF3 и DFD; если выбран тип DataFlow (DFD) – в нотациях DFD и IDEF3; если же выбран тип Process Flow (IDEF3) – то только в нотации IDEF3.

После ввода имени модели и выбора ее типа BPWin сразу предложит задать параметры модели (рис. 2):

Рисунок 2 – Окно задания свойств модели

Numbering – формат нумерации работ и диаграмм и порядок ее отображения на диаграммах;

Display – список элементов отображения на диаграммах;

Layout – параметры расположения;

ABC Units – единицы функционально-стоимостного анализа;

PageSetup – параметры страницы;

Header/Footer – параметры верхнего и нижнего колонтитула.

После задания свойств модели появляется главное окно программы (рис.3), состоящее из трех основных частей:

Рисунок 3 – Главное окно программы

1 Обозреватель модели (ModelExplorer) – отображает структуру модели (имеющиеся диаграммы и их иерархию);

2 Основная часть – в ней отображаются диаграммы, с которыми ведется работа;

3 Панели инструментов, из которых наибольший интерес представляет панель инструментов ModelToolbox.

Примечание. В созданной модели с настройками по умолчанию некорректно отображаются русские символы. Чтобы устранить этот недостаток, необходимо подкорректировать используемые в модели шрифты. Для этого в меню Model ->DefaultFonts необходимо последовательно пройтись по всем пунктам (рис. 4), выбрать в выпадающем списке Script значение кириллический и поставить галочку Change all

occurrences (рис. 5).

Рисунок 4 – Пункты меню, отвечающие за настройки шрифта

Рисунок 5 – Параметры шрифта

Панель инструментов ModelToolbox.

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

Таблица 1 – Вид и назначение кнопок ModelToolbox

Вид кнопки	Название кнопки	Назначение кнопки
		Превращает курсор в стрелку указателя для того, чтобы можно было выделять объекты
IDEF0 - DFD - IDEF3		Добавление на диаграмму новой работы
	PrecedenceArrowTool	Добавление на диаграмму новой стрелки
		Связывание названия стрелки с самой стрелкой
		Добавление на диаграмму текста
	DiagramDictionaryEditor	Вызов окна менеджера диаграмм для просмотра имеющихся диаграмм по типам и переход к выбранной
	GotoSiblingDiagram	Переход между стандартной диаграммой, деревом узлов и FEO диаграммой
	GotoParentDiagram	Переход к родительской диаграмме
	GotoChildDiagram	Переход к дочерней диаграмме
	ExternalReferenceTool	Добавление на диаграмму внешней сущности
		Добавление на диаграмму хранилища данных
		Добавление на диаграмму перекрестка

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

Рисунок 6 – Окно свойств работы

Далее необходимо разместить на диаграмме стрелки. Для этого следует нажать на ModelToolbox кнопку PrecedenceArrowTool (курсор примет форму крестика со стрелкой), щелкнуть по тому месту, откуда стрелка должна выходить и затем щелкнуть по тому месту, куда стрелка должна заходить (BPwin подсветит эти места при наведении на них курсора). Для задания названия стрелки нужно нажать на ModelToolbox кнопку PointerTool и затем дважды щелкнуть по стрелке. В появившемся окне ArrowProperties название работы вводится в поле ArrowName или выбирается из списка имеющихся названий стрелок.

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

Рисунок 7 – Создание дочерней диаграммы

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

Практическая часть

2.2 П реимущества использования AllFusion Process Modeler

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

2.3 Построение моделей бизнес - процессов

С помощью CASE-средства All Fusion Process Modeler для моделирования бизнес-процессов созданы:

Рисунок 9 – Концептуальная модель

Рисунок 11 – 3 уровень модели данных

Рисунок 12 – Дерево функциональной модели данных

Список терминов и сокращений

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

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

Заключение

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

Мировая практика урегулирования ущерба по договорам страхования гражданской ответственности владельцев транспортных средств свидетельствует о том, что более 2/3 всех выплат, осуществляемых страховщиками, приходится на материальный (имущественный) ущерб. Следовательно, для развития системы ОСАГО в России и повышения уровня доверия общества к данному виду страхования особое значение имеет своевременное решение проблем, возникающих при определении размеров и осуществлении страховых выплат за вред, причиненный имуществу потерпевших в результате ДТП. Внесение необходимых изменений в действующее законодательство об обязательном страховании гражданской ответственности владельцев транспортных средств будет способствовать правильному уяснению смысла Закона, его последовательному исполнению участниками страховых правоотношений и применению в практике работы юрисдикционных органов.