Домой Кредит на бизнес Моделирование работы страховой компании. Методологии моделирования предметной области

Кредит на бизнес

Моделирование работы страховой компании. Методологии моделирования предметной области

Введение

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

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

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

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

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

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

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

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

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

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

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 всех выплат, осуществляемых страховщиками, приходится на материальный (имущественный) ущерб. Следовательно, для развития системы ОСАГО в России и повышения уровня доверия общества к данному виду страхования особое значение имеет своевременное решение проблем, возникающих при определении размеров и осуществлении страховых выплат за вред, причиненный имуществу потерпевших в результате ДТП. Внесение необходимых изменений в действующее законодательство об обязательном страховании гражданской ответственности владельцев транспортных средств будет способствовать правильному уяснению смысла Закона, его последовательному исполнению участниками страховых правоотношений и применению в практике работы юрисдикционных органов.

В основе цикла BPI лежит разработка и внедрение функциональной модели предприятия «Как надо». С точки зрения SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) модель может быть сосредоточена либо на бизнес-процессах предприятия, либо на его объектах. SADT-модели, ориентированные на бизнес-процессы, принято называть функциональными моделями (стандарт IDEF0), а ориентированные на объекты (стандарт IDEF1) - моделями данных. Функциональная модель представляет с требуемой степенью детализации систему бизнес-процессов.

Первый и второй уровни декомпозиции модели «Как надо» (стандарт IDEF0) формируются, исходя из элементов и подэлементов стандарта ИСО серии 9000:2000. См. рис.7.1 . Следующие уровни декомпозиции модели «Как надо» формируются на основании модели потоков данных (проектируется, исходя из анализа ERP стандарта и модели «Как есть»).

Модель «Как надо» проектируется с помощью IDEF0-диаграмм и характеризуется:

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

Материальными, информационными и финансовыми потоками, описанными в модели потоков

Рис. 7.1: Основные элементы деятельности предприятия

данных. Информационные потоки делятся на три группы:

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

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

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

Механизмами, которые подразделяются на организационные, описанные в нормативной модели,

и технические, определяющие информационную систему предприятия (ИС класса ERP).

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

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

Контрольные вопросы

1. Функциональная модель - это:

2. Модель данных - это:

3. SADT-модель, описываемая стандартом IDEF0 - это:

модель, ориентированная на объекты. модель, ориентированная на бизнес-процессы;

4. SADT-модель, описываемая стандартом IDEF1 - это:

модель, ориентированная на бизнес-процессы; модель, ориентированная на объекты.

5. Модель «Как надо» характеризуется:

блоками синхронизации; функциями; механизмами;

управляющими воздействиями.

материальными, информационными и финансовыми потоками;

преобразующими блоками;

6. Информационные потоки делятся на следующие группы:

описательная информация; ограничительная информация; предписывающая информация. детализирующая информация; разрешительная информация;

Набрано баллов

8 Соответствие декомпозиции IDEF0-блоков с разработкой документации системы качества

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

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

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

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

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

Рис. 8.1: Преобразующие блоки в модели «Как надо»

1. Деятельность - совокупность бизнес-процессов, характеризующая нулевой уровень модели «Как надо». Деятельность преобразует входные потоки в выходные с использованием механизмов при управляющем воздействии со стороны внешней среды (государства, общества), например, стандарта ИСО 9001:2000 г.

2. Процесс . Преобразующие блоки первого уровня декомпозиции модели «Как надо» соответствуют элементам стандарта ИСО серии 9001:2000 г. Для каждого процесса ставится цель. Достижение целей всех процессов обеспечивает внедрение модели «Как надо», а значит, и переход предприятия на более высокий уровень BPI. Процессы протекают в соответствии с определенными целями, описанными в руководстве по качеству.

3. Подпроцессы . Преобразующие блоки второго уровня модели «Как надо» соответствуют подэлементам стандарта ИСО серии 9001:2000 г. Исходя из цели процесса, для каждого подпроцесса, входящего в него, определяется цель. Подпроцессы протекают в соответствии с определенными целями, описанными в руководстве по качеству.

4. Операция - совокупность последовательно или параллельно выполняемых действий. Операция выполняется:

в соответствии с МИКами (методическими инструкциями качества), являющимися третьим уровнем документации системы качества предприятии;

с потреблением ресурсов;

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

Операции, относящиеся к бизнес-процессам «Управление ресурсами» и «Реализация продукции» определяются в модели потоков данных (на базе анализа модели «Как есть» и ERP стан-

дартов). Таким образом, на уровне операций происходит стыковка стандарта ISO 9001:2000 с промышленными ERP-стандартами.

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

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

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

9 Проблемы моделирования бизнес-процессов управления

При моделировании бизнес-процессов, как одного из инструментов для поддержки деятельности руководителя предприятия на основе методологии IDEF (Integration definition for function modeling) возникают две проблемы.

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

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

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

Поделитесь работой в социальных сетях

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

Введение………………………………………………………………..………3

1. .….5

1.1. Экономический анализ деятельности страховой компании

ОАО «Согаз-Мед»……………………………………………………………..5

1.2. Оценка документооборота страховой компании ОАО«Согаз-Мед»…..7

1.3. Разработка функциональной модели «как есть»…………………..10

2. Проектирование базы данных страховой компании ОАО «Согаз-Мед»……………………………….16

2.1. Разработка функциональной модели «как должно быть»…………………...……………13

2.2. Разработка логико-физической модели………………………………16

3. Разработка БД для компании ОАО «Согаз-Мед»………...……………19

3.1. Выбор программной среды для разработки БД……………………

3.2. Основные функции и процедуры,используемые при разработке БД….(запрос по сортировке,фильтрации ит.п)

3.3. Тестирование приложения……

Заключение……………………………………………………………..…….25

Список литературы……………………………………………………..…...26

Приложения……………………………………………………………………..28

Введение

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

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

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

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

Целью курсового проекта является разработка базы данных «Страхование население» для ОАО «Согаз-Мед» в среде Delphi 7.0.

Объект: страховая компания ОАО «Согаз-Мед»

Задачи:

Анализ деятельности страховой компании ОАО «Согаз-Мед»;
Проектирование базы данных «Страхование населения»;
Реализация БД «Страхование населения».

1. Анализ деятельности страховой компании ОАО «Согаз-Мед»

Экономический анализ деятельности страховой компании

ОАО «Согаз-Мед»

Страховая медицинская компания ОАО «Согаз-Мед» создана в 1998 году как дочерняя компания «Газпрома» под наименованием «Газпроммедстрах», летом 2003 года в ходе консолидации страхового бизнеса включена в группу «Согаз».

Основные цели и задачи ОАО «Согаз-Мед»: совершенствование системы медицинского обеспечения, организация медицинской помощи и контроль её качества, рациональное использование средств, выделяемых на медицинское обеспечение, и защита прав застрахованных.

ОАО «Согаз-Мед» специализируется на осуществлении обязательного медицинского страхования (ОМС). По итогам 2013 года компания заняла 2 место в рейтинге страховых медицинских компаний России по страховым поступлениям по ОМС. На сегодняшний день ОАО «Согаз-Мед» - одна из крупнейших страховых медицинских компаний Российской Федерации с количеством застрахованных более 15,7 млн человек (более 11% населения России). Региональная сеть насчитывает более 550 подразделений на территории 38 субъектов Российской Федерации. Оплаченный уставный капитал Компании составляет 102,5 млн. рублей, по состоянию на 30 сентября 2014, что полностью соответствует требованиям действующего законодательства Российской Федерации к размеру уставного капитала и позволяет ОАО «Согаз-Мед» планировать свою деятельность по ОМС на долгосрочной основе.

ОАО «СОГАЗ-Мед продолжает реализацию программы внедрения современных технологических средств для развития системы ОМС. Ряд филиалов компании принял участие в реализации федерального проекта «Универсальная электронная карта» (УЭК). За истекший период количество принятых заявлений на выпуск УЭК на базе пунктов выдачи полисов филиалов ОАО «СОГАЗ-Мед» составило около 2,3 тыс. штук. Во многих офисах компании осуществляется выдача полисов ОМС единого образца в виде пластиковой карты с электронным носителем («электронный полис»).

ОАО «СОГАЗ-Мед» пользуется заслуженным авторитетом в профессиональном сообществе. В марте 2013 года Рейтинговое агентство «Эксперт РА» подтвердило рейтинг надежности и качества услуг на уровне «А++» страховой компании ОАО «СОГАЗ-Мед» («Исключительно высокий уровень надежности и качества услуг»)

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

всероссийский союз страховщиков;
межрегиональный союз медицинских страховщиков.

Генеральный директор ОАО «Страховая компания «СОГАЗ-Мед» Д.В. Толстов входит в состав Президиума Межрегионального союза медицинских страховщиков.

Экономический анализ показал, что по итогам 2014 года объем страховых сборов Общества по обязательному медицинскому страхованию составил 44,45 млн. рублей, что в 1,3 раза выше показателей предыдущего года. К тому же, страховые выплаты по ОМС составили 34,434 млрд. рублей или 95,34% от общей суммы страховых сборов.

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

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

Таблица1- Структура активов ОАО»Согаз-Мед»

Из приведенных данных можно сделать вывод, что в 2012 году произошло увеличение суммы основных средств предприятия на 1724 тыс. руб., однако в структуре активов доля основных средств уменьшилась на 0,55%. В 2013 году произошло снижение на 406 тыс. руб.

Нематериальных активов компания не имеет. Удельный вес долгосрочных финансовых активов в структуре активов также незначителен и имеет непостоянную динамику: 2012 год - 5,11%, 2013 - 7,19%, 2014- 3,13%.

В целом удельный вес внеоборотных активов в 2013 году вырос на 1,55%, в 2014 сократился на 4,36%.

Показатель второй группы активов - оборотные активы, имеет обратную тенденцию. В 2012 году их удельный вес составлял 93,30%, в 2013 году - 91,75%, в 2014 году он увеличился до 96,11%.

За анализируемый период основную часть оборотных активов составляет дебиторская задолженность, на ее долю приходится в 2012 - 66,38%, 2013- 62,24%, в 2014 доля сокращается до 46,63%.

Сумма денежных средств увеличивалась с каждым годом почти в 2 раза: с 401732 тыс. руб. в 2012 году до 740367 тыс. руб. в 2013 году и до 1705579 в 2014 году.

Все вышеперечисленное говорит о том, что финансовое состояние компании ОАО«Согаз-Мед» с каждым годом становится только лучше, а значит данная организация развивается, увеличивает клиентскую базу, что в свою очередь ведет к увеличению объемов работ в процессе документооборота организации.

1. 2. Оценка документооборота страховой компании ОАО«Согаз-Мед»

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

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

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

1) для детей после государственной регистрации рождения и до четырнадцати лет, являющихся гражданами Российской Федерации:

свидетельств о рождении;
документ, удостоверяющий личность законного представителя ребенка;
СНИЛС (при наличии).

2) для граждан Российской Федерации в возрасте четырнадцати лет и старше:

документ, удостоверяющий личность (паспорт гражданина Российской Федерации, временное удостоверение личности гражданина Российской Федерации, выдаваемое на период оформления паспорта);
СНИЛС (при наличии).

3) для лиц, имеющих право на медицинскую помощь в соответствии с Федеральным законом «О беженцах»:

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

4) для иностранных граждан, постоянно проживающих в Российской Федерации:

паспорт иностранного гражданина либо иной документ, установленный федеральным законом или признаваемый в соответствии с международным договором Российской Федерации в качестве документа, удостоверяющего личность иностранного гражданина;
вид на жительство;
СНИЛС (при наличии).

5) для лиц без гражданства, постоянно проживающих в Российской Федерации:

документ, признаваемый в соответствии с международным договором Российской Федерации в качестве документа, удостоверяющего личность лица без гражданства;
вид на жительство;
СНИЛС (при наличии).

6) для иностранных граждан, временно проживающих в Российской Федерации:

паспорт иностранного гражданина либо иной документ, установленный федеральным законом или признаваемый в соответствии с международным договором Российской Федерации в качестве документа, удостоверяющего личность иностранного гражданина, с отметкой о разрешении на временное проживание в Российской Федерации;
СНИЛС (при наличии).

7) для лиц без гражданства, временно проживающих в Российской Федерации:

документ, признаваемый в соответствии с международным договором Российской Федерации в качестве документа, удостоверяющего личность лица без гражданства, с отметкой о разрешении на временное проживание в Российской Федерации;
либо документ установленной формы, выдаваемый в Российской Федерации лицу без гражданства, не имеющему документа, удостоверяющего его личность;
СНИЛС (при наличии).

8) для представителя застрахованного лица:

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

9) для законного представителя застрахованного лица:

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

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

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

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

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

Преимущества автоматизации документооборота страховой компании ОАО «Согаз-Мед»:

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

Для разработки модели «как есть» предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии:

IDEF0 (функциональная модель);
DFD (DataFlow Diagram);
IDEF3 (Workflow Diagram).

Создание модели в стандарте IDEF0 .

Функциональная модель предназначена для описания существующих бизнес процессов на предприятии (так называемая модель AS- I S «как есть») и идеального положения вещей того, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»). Методология IDEF0 предписывает построение иерархической системы диаграмм единичных описаний фрагментов системы.

Построение модели ИС начинается с описания функционирования предприятия (системы) или отдельной ее части (в нашем случае это страхование населения) в целом в виде контекстной диаграммы. На Рис.2 представлена контекстная диаграмма ИС «Страхование населения»:

Рис.2. Контекстная диаграмма страхования населения

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

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

Рис.3. Диаграмма декомпозиции IDEF 0.Страхование населения

. В результате дальнейшего разбиения функции «Работа с населением» получаем следующую диаграмму декомпозиции (см. Рис.4):

Рис.4. Диаграмма декомпозиции IDEF 0.Работа с населением.

Производим декомпозицию функции «Прием документов и регистрация» и получаем конечную диаграмму(см.Рис.5):

Рис.5. Диаграмма декомпозиции IDEF

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

1.4. Разработка модели «как должно быть»

Теперь добавляется такой ресурс как БД, с помощью которой можно упростить процесс документооборота в ОАО «Согаз-Мед (см.Рис.6) :

Рис.6.Контекстная диаграмма модели «как должно быть».

На диаграммах «Страхование населения», «Работа с населением» и «Прием и регистрация документов» так же добавился ресурс БД. В ранее уже рассмотренной диаграмме декомпозиции «Прием и регистрация документов» произошли изменения. Теперь прием документов и их проверка-это единый процесс, к результате чего выявляется наличие полиса у клиента. Так же можно отследить дату, когда действие полиса заканчивается и заранее уведомить об этом клиента.(см.Рис.7):

Рис.7. Диаграмма декомпозиции IDEF 0.Прием и регистрация документов.

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

Глава 2.Программный раздел

2.1 Описание логической модели

На рисунке 8 представлена логическая модель системы, реализованная с помощью программы ERWin фирмы ComputerAssociates:

Рис.8. Логическая модель данных.

Логическая модель содержит 3 сущности.

Сущность «Вид документа» содержит в себе информацию о названии документа. Ключевое поле «ИД документа» с типом данных «целое число». Не ключевое поле «Вид документа» с типом данных «char(100)».

Сущность «Страховой полис» содержит в себе данные о клиенте, полисе и сотруднике. Ключевое поле «Номер страхового полиса» с типом данных «целое число». Не ключевые поля «ФИО» с типом данных «char(100)», «Дата рождения» с типом данных «», «ИД документа» int , «Серия номер документа» int , «СНИЛС» int , «Номер телефона застрахованного лица» int , «Дата регистрации полиса» DateTime , «Срок действия полиса» DateTime , «ИД сотрудника» int

Сущность «Сотрудник» содержит в себеданные о сотруднике. Ключевое поле «ИД сотрудника» с типом данных «целое число». Не ключевые поля «ФИО» и «Должность» с типами данных «char(100)».

2.2. Физическая модель данных

Рис.9.Физическая модель данных.

Генерация физической модели сделана с помощью возможностей программы CA Erwin Data Modeler. Выбираем меню Tools->Forward Engineer->Schema Generation и в появившемся окне нажимаем кнопку Generate. В появившемся окне указываем имя базы данных, созданной в Microsofr Server 2008, и сервер. База данных успешно сгенерирована.

Описать связи и нормалицацию)

Глава 3. Программный раздел

По нажатию на Radiobutton 1 (100 дней) срабатывает функция.

procedure TForm1.RadioButton1Click(Sender: TObject);

var s:string;

begin

Form1.Query2.Close;

Form1.Query2.SQL.Clear;

<:newdate1) ");

Form1.Query2.ExecSQL;

end;

По нажатию на Radiobutton 2 (50 дней) срабатывает функция.

begin

Form1.Query2.Close;

Form1.Query2.SQL.Clear;

Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS ");

Form1.Query2.SQL.Add("where (Date_reg_doc+50>:newdate1) ");

Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;

Form1.Query2.ExecSQL;

end;

По нажатию на Radiobutton 3 (10 дней) срабатывает функция

begin

Form1.Query2.Close;

Form1.Query2.SQL.Clear;

Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS ");

Form1.Query2.SQL.Add("where (Date_reg_doc+50>:newdate1)");

Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;

Form1.Query2.ExecSQL;

end;

При нажатии на кнопку в меню «Настройки» - > Регистрация сотрудника появляется диалоговое окно «Регистрация сотрудника» с двумя полями и кнопкой «Зарегистрировать»

Button1

begin

Form3.Query1.Close;

Form3.Query1.SQL.Clear;

Form3.Query1.ExecSQL;

end;

При нажатии на клавишу зарегистрировать срабатывает процедура TForm 2. Button 1 Click

begin

Form2.Query3.Close;

Form2.Query3.SQL.Clear;

Form2.Query3.ExecSQL;

Form2.Query4.Active:=FALSE;

Form2.Query4.Active:=TRUE;

end;

Заключение

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

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

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

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

Список литературы

Файзрахманов Р. А., Селезнев К. А. Учебное пособие к практическим занятиям «Структурно функциональный подход к проектированию информационных технологий и автоматизированных систем с использованием CASE-средств» / Перм. гос. техн. ун-т. -Пермь, 2012. - 245 с.
Ехлаков Ю.П. Теоретические основы автоматизированного управления. Томск: Изд-во Том. гос. ун-та систем управления и радиоэлектроники, 2013. 337 c.
Галисеев Г.В. Программирование в среде Delphi 7. Самоучитель. М.: Издательский дом «Вильямс», 2012.
Митчелл К. Керман Программирование и отладка в Delphi: Учебный курс: М.; СПб.; Киев, 2014.
Фаронов В.В. Delphi 6: Учебный курс. СПб.: Питер, 2011.
1. Гофман В.Э., Хомоненко А.Д. Delphi . Быстрый старт. СПб.: БХВ-Петербург, 2002.
Архипов, А. П. Страхование: учебник / А. П. Архипов. М. : КНОРУС, 2012. 288 с.
http://www.sogaz-med.ru/

Приложение

Листинг

Unit1

unit Unit1;

interface

uses

Dialogs, Menus, StdCtrls, ComCtrls, Grids, DBGrids, DB, DBTables;

type

TForm1 = class(TForm)

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

DBGrid1: TDBGrid;

GroupBox1: TGroupBox;

RadioButton1: TRadioButton;

RadioButton2: TRadioButton;

RadioButton3: TRadioButton;

Query2: TQuery;

DataSource1: TDataSource;

Procedure N4Click(Sender: TObject);

Procedure N5Click(Sender: TObject);

Procedure N3Click(Sender: TObject);

Procedure RadioButton1Click(Sender: TObject);

Procedure RadioButton2Click(Sender: TObject);

Procedure RadioButton3Click(Sender: TObject);

Private

{ Private declarations }

Public

{ Public declarations }

End;

Form1: TForm1;

implementation

uses Unit2, Unit3;

{$R *.dfm}

procedure TForm1.N4Click(Sender: TObject);

begin

Form2.show;

end;

procedure TForm1.N5Click(Sender: TObject);

begin

Form3.show;

end;

procedure TForm1.N3Click(Sender: TObject);

begin

Form1.Close;

end;

procedure TForm1.RadioButton1Click(Sender: TObject);// динамические запросы

var s:string;

begin

Form1.Query2.Close;

Form1.Query2.SQL.Clear;

Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS ");

Form1.Query2.SQL.Add("where (Date_reg_doc+100<:newdate1) ");

Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;

Form1.Query2.ExecSQL;

end;

procedure TForm1.RadioButton2Click(Sender: TObject);

begin

Form1.Query2.Close;

Form1.Query2.SQL.Clear;

Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS ");

Form1.Query2.SQL.Add("where (Date_reg_doc+50>:newdate1) ");

Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;

Form1.Query2.ExecSQL;

end;

procedure TForm1.RadioButton3Click(Sender: TObject);

begin

Form1.Query2.Close;

Form1.Query2.SQL.Clear;

Form1.Query2.SQL.Add("Select Number,FIO,SNILS,Telephone from dbo.OMS ");

Form1.Query2.SQL.Add("where (Date_reg_doc+50>:newdate1)");

Form1.Query2.ParamByName("newDate1").AsdateTime:=Form1.DateTimePicker1.DateTime;

Form1.Query2.ExecSQL;

end;

end.

Unit2

unit Unit2;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, StdCtrls, ComCtrls, DB, DBCtrls, DBTables;

type

TForm2 = class(TForm)

Label9: TLabel;

GroupBox1: TGroupBox;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Label6: TLabel;

Edit1: TEdit;

DateTimePicker1: TDateTimePicker;

Edit2: TEdit;

Edit3: TEdit;

Edit4: TEdit;

GroupBox2: TGroupBox;

Label7: TLabel;

DateTimePicker2: TDateTimePicker;

Label8: TLabel;

Button1: TButton;

DBGrid1: TDBGrid;

Query1: TQuery;

Table1: TTable;

DataSource1: TDataSource;

Table2: TTable;

DataSource2: TDataSource;

ComboBox1: TComboBox;

Query2: TQuery;

ComboBox3: TComboBox;

Query3: TQuery;

DateTimePicker3: TDateTimePicker;

Query4: TQuery;

DataSource3: TDataSource;

Procedure FormCreate(Sender: TObject);

Private

{ Private declarations }

Public

{ Public declarations }

End;

Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.FormCreate(Sender: TObject);

begin

While not query1.eof do begin

Combobox1.items.add(query1.fieldbyname("Name_doc").asstring);

Query1.next

End;

While not query2.eof do begin

Combobox3.items.add(query2.fieldbyname("FIO").asstring);

Query2.next

End;

Form2.Query4.Active:=FALSE;

Form2.Query4.Active:=TRUE;

end;

procedure TForm2.Button1Click(Sender: TObject);

begin

Form2.Query3.Close;

Form2.Query3.SQL.Clear;

Form2.Query3.SQL.Add("Insert into dbo.OMS (FIO,DB,ID_doc,number_doc,SNILS,Telephone,Date_reg_doc,Srok,ID_employee) ");

Form2.Query3.SQL.Add("Values(:newFIO,:newDB,(Select ID_doc from dbo.DOc where Name_doc = :newDoc1),:newNumber_doc,:newSNILS,:newTelephone,:newDate_reg_doc,:newSrok,(Select ID_employee from dbo.employee where FIO = :newDoc))");

Form2.Query3.ParamByName("newFIO").AsString:=Edit1.Text;

Form2.Query3.ParamByName("newDB").AsdateTime:=Form2.DateTimePicker1.DateTime;

Form2.Query3.ParamByName("newDoc1").AsString:=Combobox1.Items.Text;

Form2.Query3.ParamByName("newNumber_doc").AsString:=Edit2.Text;

Form2.Query3.ParamByName("newSNILS").AsString:=Edit3.Text;

Form2.Query3.ParamByName("newTelephone").AsString:=Edit4.Text;

Form2.Query3.ParamByName("newDate_reg_doc").AsdateTime:=Form2.DateTimePicker2.DateTime;

Form2.Query3.ParamByName("newSrok").AsdateTime:=Form2.DateTimePicker3.DateTime;

Form2.Query3.ParamByName("newDoc").AsString:=Combobox1.Items.Text;

Form2.Query3.ExecSQL;

Form2.Query4.Active:=FALSE;

Form2.Query4.Active:=TRUE;

end;

end.

Unit3

unit Unit3;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, DB, DBTables;

type

TForm3 = class(TForm)

Label1: TLabel;

Edit1: TEdit;

Label2: TLabel;

Edit2: TEdit;

Button1: TButton;

Query1: TQuery;

Procedure Button1Click(Sender: TObject);

Private

{ Private declarations }

Public

{ Public declarations }

End;

Form3: TForm3;

implementation

{$R *.dfm}

procedure TForm3.Button1Click(Sender: TObject);

begin

Form3.Query1.Close;

Form3.Query1.SQL.Clear;

Form3.Query1.SQL.Add("Insert into dbo.Employee (FIO,Position) ");

Form3.Query1.SQL.Add("Values(:newFIO,:newPosition)");

Form3.Query1.ParamByName("newFIO").AsString:=Edit1.Text;

Form3.Query1.ParamByName("newPosition").AsString:=Edit2.Text;

Form3.Query1.ExecSQL;

end;

end.

Project

program Project1;

uses

Forms,

Unit1 in "Unit1.pas" {Form1},

Unit2 in "Unit2.pas" {Form2},

Unit3 in "Unit3.pas" {Form3};

{$R *.res}

begin

Application.Initialize;

Application.CreateForm(TForm1, Form1);

Application.CreateForm(TForm2, Form2);

Application.CreateForm(TForm3, Form3);

Application.Run;

end.

Другие похожие работы, которые могут вас заинтересовать.вшм>
20665.		Проектирование и реализация базы данных аптеки	2.55 MB
	Новокузнецк задание на курсовую работу Необходимо спроектировать база данных включающую сведения представленные в виде группы атрибутов: Аптека Наименование лекарства; аннотация; место хранения; дата поступления; приход; остаток на конец месяца; фирма производитель; поставщик и т. Задание состоит в следующем: Создать базу данных. Организовать постоянные связи между таблицами для обеспечения целостности своей базе данных.
20182.		Проектирование базы данных дневное отделение колледжа	2.59 MB
	Проектирование базы данных дневное отделение колледжа Выполнила: студентка гр. В курсовой работе ставится задача разработать проект базы данных для накопления необходимой информации в организации создать наполнить базу данных. База данных должна быть спроектирована с учетом реализации запросов различного типа по получению информации. При проектировании базы данных следует учесть возможность выдачи бумажного отчета.
10007.		Проектирование базы данных «Каталог запчастей автомобиля»	182.36 KB
	Первоначально для накопления и хранения информации на ЭВМ применялись локальные массивы (или файлы), при этом для каждой из решаемых функциональных задач создавались собственные файлы исходной и результатной информации. Это приводило к значительному дублированию данных, усложняло их обновление, затрудняло решение взаимосвязанных проблемных задач.
14064.		Проектирование и создание базы данных «Архив МБУК Ижболдинский СДК»	24.67 KB
	Столбец таблицы содержит однотипную для всех записей информацию и называется полем. DBText Используется для отображения но неизменения текущих текстовых полей набора данных. DBEdit Предназначен для отображения и изменения текстовых полей набора данных. Подобен компоненту ComboBox страницы Stndrd но обслуживает текстовое поле БД.
20557.		Проектирование базы данных Станция технического обслуживания автомобилей	8.01 MB
	База данных – это, прежде всего, хранилище объектов данных, т.е. набор возможных понятий или событий, описываемых базой данных, с возможностью поиска этих объектов по признакам. Базой данных можно считать не только таблицы, индексирующие файлы со знаниями разных форматов, но и сами эти файлы, потому, что они являются не типизированными хранилищами знаний в такой базе данных. Базы данных могут применяться как вспомогательное средство, позволяющее реализовать какую-то полезную функцию.
13839.		Проектирование базы данных нотариальной конторы с использованием технологий СУБД Access	13.53 MB
	Нотариат – один из важнейших институтов правовой системы, призванный способствовать формированию демократического правового государства, в котором надежно защищены права и законные интересы граждан и юридических лиц путем осуществления нотариальных действий.
15115.		Тарифная политика страховой компании	28.09 KB
	Ошибки в расчете тарифов и при установлении страховой премии следующий за этим недостаток средств для обеспечения страховых выплат ошибки при выработке схемы перестраховочной защиты или определении ее участников и переплата перестраховочной премии или банкротство перестраховщиков завышенный уровень расходов на ведение дела - все это приводит к потерям источником покрытия которых служат собственные средства страховой организации. Актуальность выбранной темы обусловлена тем что тарифная политика страховщиков является основой стабильного...
13963.		ОРГАНИЗАЦИЯ СТРАХОВАНИЯ ТРАНСПОРТНЫХ СРЕДСТВ В СТРАХОВОЙ КОМПАНИИ ООО «РОСГОССТРАХ»	3.04 MB
	Сущность страхования состоит в формировании определенного денежного страхового фонда и его распределении во времени и пространстве по возмещению возможного ущерба убытков его участникам при несчастных случаях стихийных бедствиях и других обстоятельствах предусмотренных договором страхования.1 Различие страхования КАСКО от ОСАГО ОСАГО КАСКО ОСАГО КАСКО Страхование автогражданской ответственности носящее обязательный характер для всех владельцев транспортных средств Вид негосударственного страхования автомобиля связанный с защитой...
21849.		Организация и проведение PR-кампании по ребрендингу страховой компании ALLIANZ	1021.66 KB
	Приведем определения Сэма Блэка, первыми пришедшие к русскоязычному читателю: «РR - это одна из функций управления, способствующая установлению и поддержанию общения, взаимопонимания, расположения и сотрудничества между организацией и ее общественностью.
20319.		БАЗЫ ДАННЫХ И ИХ ЗАЩИТА	102.86 KB
	Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.

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

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

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

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

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

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

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

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

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

Рис. 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–модели.

Блоки SADT никогда не размещаются на диаграмме случайным образом. Они размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все остальные функции. Наиболее доминирующий блок обычно располагается в верхнем левом углу диаграммы, а наименее доминирующий – в правом нижнем углу. В результате получается «ступенчатая» схема.

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

1) присваивается код каждой зрительной связи. Используется I для входных дуг, С - для связей между дугами управления, О - для связей между выходными дугами, М - для связей между дугами механизма.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки IDEF0-диаграмм:

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

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

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

На рис. 2 приведена диаграмма IDEF0 верхнего уровня бизнес-процесса "Увольнение сотрудника".

Рис. 2. Диаграмма IDEF0 верхнего уровня бизнес-процесса "Увольнение сотрудника".

Контрольные вопросы:

1. В каком году был разработан стандарт IDEF0? В каком году была выпущена последняя его редакция?

2. Что является целью при использовании методологии IDEF0?

3. Какие четыре основных понятия лежат в основе методологииIDEF0?

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

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

6. Что обеспечивает декомпозиция при создании модели системы?

7. Что хранится в глоссарии?

8. Что необходимо определить,прежде чем приступать к описанию модели? Суть каждого из данных понятий.

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

10. Какой номер располагается в правом верхнем углу диаграммы?

11. За счет чего достигается структурная целостность IDEF0–модели?

12. Как применяется принцип доминирования при расположении функциональных блоков на диаграмме?

13. Использование ICOM-кодов при именовании дуг на диаграммах IDEF0.

14. Туннелирование дуг на диаграммах IDEF0.

15. Какие ограничения сложности приняты для диаграмм IDEF0?

16. Какие этапы выделяют при разработке функциональной модели с помощью IDEF0-диаграмм?

17. Недостатки IDEF0-диаграмм.

ТЕМА: Описание функциональности разработки: диаграммы потоков данных.

Литература: 1. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения.

2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения.

3. Камаев В. А., Костерин В. В. Технологии программирования.

4. Грекул В.И. Проектирование информационных систем.

Нотация DFD – моделирование потоков данных (процессов) – основа методологии Gane/Sarson, в соответствии с которой модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи объекту или субъекту. Контекстные диаграммы иерархии определяют основные процессы или подсистемы системы с внешними входами и выходами. Они детализируются при помощи диаграмм-потомков. Декомпозиция ведется до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно. Главная цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

·внешние сущности;

·системы/подсистемы;

·процессы;

·накопители данных;

·потоки данных.

Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна-Сарсана, вторая нотацией Йордона-Де Марко.

Таблица 1. Элементы методологии DFD в нотациях
Гейна-Сарсана и Йордона-Де Марко.

Введение

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

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

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

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

Менеджмент деятельностью организации должен основываться на менеджменте сетью процессов.

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

Представление процессов

В МС ИСО 9000:2000 используется следующее определение процесса:

«Набор взаимосвязанных и взаимодействующих операций (действий), которые преобразуют входы в выходы.

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

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

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

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

Процессы вместе с взаимосвязями и взаимодействиями представляют сеть процессов организации.

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

Впервые это обстоятельство было осознано в середине 70-х годов при реализации комплексных проектов по заказам ВВС США. В то же время была предложена и реализована программа комплексной компьютерной поддержки производства (ICAM — Integrated Computer-Aided Manufacturing), в рамках которой, в частности, применялась методология структурного анализа систем. Позже на базе этого подхода была разработана методология функционального моделирования IDEF0, которая в 1993 году была принята в качестве федерального стандарта в США, а в 2000 году — в качестве стандарта в Российской Федерации.

В методологии функционального моделирования IDEF0 для графического представления процесса используется следующая нотация (Рис. 2).

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

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

Модель процессов в рамках СК

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

Какие процессы в деятельности организации относятся к системе качества?

Какова структура этих процессов, включая выходы и потребителей процессов, входы и поставщиков и т.д.?

Как процессы взаимодейтсвуют друг с другом?

Как в рамках процессов выполняются требования, определенные в МС ИСО серии 9000 версии 2000 года?

Требования к функциональной модели

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

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

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

Функциональная модель должна содержать процессы, определенные как обязательные в рамках требований МС ИСО серии 9000 версии 2000 года. Перечень этих процессов приведен в МС ИСО 9001:2000 .

Функциональная модель должна содержать элементы (объекты), регламентируемые в МС ИСО серии 9000 версии 2000 года. Перечень таких элементов приведен в .

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

Особенности функциональной модели СК

Бизнес-процесс

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

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

Таким образом, функциональная модель бизнес-процесса будет охватывать процессы жизненного цикла, а также связанные с ними вспомогательные процессы и процессы менеджмента, входящие в состав деятельности организации. Это полностью согласуется с требованиями МС ИСО семества 9000 версии 2000 года.

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

Обязательные процессы и элементы

В МС ИСО 9001:2000 к обязательным процессам относятся:

Реализация ответственности высшего руководства в рамках системы качества;

Менеджмент ресурсов (вспомогательных производственных процессов);

Менеджмент основных производственных процессов (процессов жизненного цикла продукции);

Процессы измерения, контроля и улучшения СК.

К обязательным элементам относятся, в том числе:

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

Документы, содержащие ответственность сотрудников организации (должностные инструкции);

Записи качества, и т.д.

Соответственно, функциональная модель должна содержать все обязательные процессы и элементы в соответствии с требованиями МС ИСО серии 9000 версии 2000 года.

В нашем примере бизнес-процесс в швейном ателье будет иметь следующую структуру (Рис. 4).

На диаграмме (Рис. 4) процесс представлен в виде 4-х взаимодействующих между собой процессов. Каждый из 4 процессов является обязательным с точки зрения выполнения требований МС ИСО 9001:2000 .

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

Классификация процессов в СК

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

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

Классификация дуг

В рамках IDEF0-модели дуги в зависимости от их положения на диаграмме уже подразделены на 4 категории: входные, выходные, управления и механизма.

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

Материалы, сырье, продукция, ресурсы;

Информация, данные; записи качества; документы;

Распоряжения руководства, планы, графики; распорядительные документы;

Стандарты, нормативная документация;

Ответственные исполнители, сотрудники организации и т.д.

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

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

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

Примечание. Графические стили не являются частью методологи IDEF0. Использование графических стилей для классификации процессов впервые было предложено и реализовано в системе IDEF0/EMTool .

Классификация функциональных блоков

Функциональные блоки в IDEF0-модели могут быть классифицированы в зависимости от категорий процессов, которые они представляют. В рамках функциональных моделей СК следует использовать категории процессов, которые регламентированы в МС ИСО 9001:2000 .

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

Заключение

Процессный подход, составляющий основу новой версии МС ИСО 9000:2000, требует применения специальных средств для описания и классификации процессов, составляющих деятельность организации.

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

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

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

А. Г. Курьян, П. С. Серенков