Для разработки модели «как есть» предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии:
Создание модели в стандарте IDEF0.
Функциональная модель предназначена для описания существующих бизнес - процессов на предприятии (так называемая модель AS-IS «как есть») и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы.
Построение модели ИС начинается с описания функционирования предприятия (системы) или отдельной ее части (в нашем случае это страхование населения) в целом в виде контекстной диаграммы. На Рис.2 представлена контекстная диаграмма ИС «Страхование населения»:
Рис.2.
На контекстной диаграмме видно, что в страховую компанию от клиента поступает заявление на замену или выдачу полиса, а так же паспорт, СНИЛС, действующий полис (в случае замены). Механизмами управления являются нормативно-правовые акты, должностные инструкции, устав предприятия, а так же дополнительные соглашения. Сотрудники- ресурсы, необходимые для бесперебойной работы в сфере страхования населения. Результатами страхования будет новый страховой полис, отчеты по выданным полюсам и отчёты о финансовом состоянии предприятия, которые направляются в главный офис для отслеживания динамики.
Далее весь процесс страхования разбивается на подпроцессы, которые в свою очередь могут быть декомпозированы на ещё более мелкие подпроцессы. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции. (см. Рис.3):
Рис.3.
В результате дальнейшего разбиения функции «Работа с населением» получаем следующую диаграмму декомпозиции (см. Рис.4):
Рис.4.
Производим декомпозицию функции «Прием документов и регистрация» и получаем конечную диаграмму(см.Рис.5):
Рис.5.
На диаграммах наглядно показаны, процессы, протекающие при получении полиса, начиная с процесса получения документов от клиента и заканчивая выдачей ему полиса. Также полученные документы проходят проверку, а каждый клиент, получивший полис, учитывается, в результате чего составляются отчеты, необходимые вышестоящему руководству.
Теперь добавляется такой ресурс как БД, с помощью которой можно упростить процесс документооборота в ОАО «Согаз-Мед (см.Рис.6) :
Рис.6.Контекстная диаграмма модели «как должно быть».
На диаграммах «Страхование населения», «Работа с населением» и «Прием и регистрация документов» так же добавился ресурс БД. В ранее уже рассмотренной диаграмме декомпозиции «Прием и регистрация документов» произошли изменения. Теперь прием документов и их проверка-это единый процесс, к результате чего выявляется наличие полиса у клиента. Так же можно отследить дату, когда действие полиса заканчивается и заранее уведомить об этом клиента.(см.Рис.7):
Рис.7.
Из модели «как должно быть» следует, что применение в сфере страхования населения БД, заметно уменьшает время обработки не только поступивших от клиентов документов, но и дает возможность более тщательно отслеживать сроки действия полисов, что в свою очередь ведет к благоприятным успехам в работе с клиентской базой и улучшению имиджа компании.
канд. физ.-мат. наук,
доцент кафедры «Программное обеспечение и интеллектуальные системы»,
Донецкий государственный институт искусственного интеллекта
Ручкина В.Н
.,
аспирант Донецкого национального университета
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. Система пользовательского интерфейса. Может помочь пользователям при работе с ЭС, даже если они не знают, как она организована; объясняет пользователю, как получить результат.
Профессионально структурированная компьютерная информационная система увеличит конкурентное преимущество страховой компании, информационные потоки которой с каждым днем увеличиваются. Процесс перехода страховой компании к компьютерным информационным системам включает этапы разработки, программирования и внедрения. Данная система позволит автоматизировать ввод информации получения отчетов деятельности компании, централизованно вести учет и обработку данных, осуществлять электронную обработку данных и обмен информацией, оперативно анализировать деятельность с последующим определением тактики компании, прогнозировать и планировать деятельность компании. Трудности перехода к компьютерным информационным системам - прежде всего временные затраты на разработку и внедрение системы, высокие денежные затраты (дорогостоящий процесс по стандартизации и описанию бизнес-процессов страховой компании), изменение устоявшихся традиций компании. Тем не менее, они в идеале экономически оправданы и позволяют конкурентоспособно трудиться на рынке финансовых услуг.
Также по этой теме.
Страховые компании - это финансовые посредники, которые специализируются на предоставлении страховых услуг. Их деятельность состоит в формировании на основании договоров с юридическими и физическими лицами (через продажу страховых полисов) специальных денежных фондов, из которых осуществляются выплаты страхователям денежных средств в обусловленных размерах в случае наступления определенных событий (страховых случаев).
Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск
Введение………………………………………………………………..………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) для представителя застрахованного лица:
9) для законного представителя застрахованного лица:
Из вышеперечисленного понятно, что сотрудникам страховой компании ОАО «Согаз-Мед» приходится тратить много времени на работу с документами, причем зачастую на работу, напрямую не связанную с профессиональным бизнесом. Распространена ситуация, когда недостаточно внимания уделяется коммуникации с клиентами, так как большую часть времени страховщики занимаются сканированием документов и освоением систем документооборота.
В итоге нерациональное использование ресурсов и смещенные приоритеты страховой компании серьезно снижают конкурентоспособность компании на страховом рынке и препятствуют расширению бизнеса.
Поэтому компании нужно оптимизировать документооборот так, чтобы он не требовал привлечения большого количества людских ресурсов и позволял легко и оперативно извлекать из хранилища необходимую в данный момент информацию. Для компании это будет означать два выигрышных момента: безусловное улучшение качества предоставляемого сервиса и снижение времени обслуживания одного клиента, благодаря чему можно сократить численность персонала.
Важно и то, что оптимизация не просто позволит упорядочить потоки документов, но и поможет сократить расходы на их создание и обработку.
Преимущества автоматизации документооборота страховой компании ОАО «Согаз-Мед»:
Для разработки модели «как есть» предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии:
Создание модели в стандарте 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 , предоставляющая средства для управления данными в информационной системе поддержки работы получения полиса. Полученная программа была протестирована.
Список литературы
Приложение
Листинг
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), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию. | |||
В 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 поддерживается компьютерными программами. Применение компьютерных программ на стадии описания процессов позволяет не только повысить эффективность решения этой задачи, но также использовать эти модели на стадии менеджмента процессами, интегрируя их в корпоративную информационную систему организации.
А. Г. Курьян, П. С. Серенков
Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные).
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.
Функциональные методики , наиболее известной из которых является методика IDEF , рассматривают организацию как набор функций , преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.
С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации . Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT ( Structured Analysis and Design Technique ). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing ). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы ( IDEF = Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США ( NIST ).
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий .
(Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис. 6.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
Рис.
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 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов:
Что поступает в подразделение "на входе"?
На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.
