В 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 поддерживается компьютерными программами. Применение компьютерных программ на стадии описания процессов позволяет не только повысить эффективность решения этой задачи, но также использовать эти модели на стадии менеджмента процессами, интегрируя их в корпоративную информационную систему организации.
А. Г. Курьян, П. С. Серенков
Введение
Успех страхового бизнеса в России целиком зависит от уровня его автоматизации.
Убеждать в пользе и необходимости автомобильного страхования сегодня уже не приходится. В условиях интенсивной автомобилизации населения наиболее убедительные аргументы в пользу страхования – ежедневные сводки ГАИ о количестве дорожно-транспортных происшествий и угонов автомобилей. Все больше водителей, надеясь на лучшее, чувствуют себя на дороге увереннее лишь благодаря автострахованию. Но страхование, не только автострахование, нуждается в информационной поддержке. Очевидно, что для успешного формирования единого информационного пространства страховой деятельности необходима совместимость различных супер магистралей. Один из возможных подходов к этому - стандартизация электронного взаимодействия. · Страхование, являясь мощным фактором положительного воздействия на экономику и страховой защитой юридических и физических лиц от случайных опасностей, основывается на жесткой многоуровневой системе управления процессом страхования и нуждается в информационном обслуживании и сопровождении. · Процесс, страховой деятельности предусматривает решение различных функциональных задач, начиная от оформления заключаемых договоров страхования, информационного отображения в ИС их юридических и содержательных аспектов и заканчивая формированием бухгалтерской и статистической отчетности, подготовкой управленческих решений, что требует автоматизации трудоемких информационных процессов. · Особенности информационного обеспечения решения функциональных задач в области страхования, территориальная сосредоточенность компаний, филиалов, АРМ специалистов, занятых страховой деятельностью, определили необходимость использования ПЭВМ и коммуникационных средств информационного взаимодействия специалистов, занятых в этой отрасли. · Практика создания и применения АИТ в страховой деятельности подтверждает целесообразность эксплуатации распределенной информационно-вычислительной сети или многоуровневой сети, предусматривающей наличие единой технологической платформы, с общей информационной базой для взаимодействия, как с файл-сервером, так и с другими ресурсами сети.
Цель курсового проекта – выполнить начальное проектирование информационной системы выбранной предметной области. Разрабатываемая ИС должна поддерживать выполнение конкретной деятельности организации и обеспечивать выполнение набора функционально связанных операций, характерных для этой деятельности. В данном случае необходимо рассмотреть процесс страхования клиентов, выплат страхового возмещения и выполнить проектирование соответствующей ИС.
Для реализации данной цели перед выполнением курсового проекта были поставлены следующие задачи:
Рассмотреть предметную область деятельности предприятия;
Изучить способы проектирования ИС и разработать модели данных различных видов;
Выполнить логическое и физическое проектирование ИС;
Подобрать подходящую архитектуру для рассматриваемой системы.
Объектом исследования является страховая компания «Росгосстрах».
Теоретическая часть
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, а в выразительности схем при обсуждении и принятии решений большим количеством участников в сжатые сроки (в объеме презентации).
Одна картинка стоит тысячи словНародная мудрость
Зачастую в моей работе возникает необходимость не просто изучить и решить определенную проблему, но выявить ее местонахождение в общей модели работы компании. Мало понимать, что определенное подразделение работает неправильно, важно понимать, каким образом оно взаимодействует с другими. Иначе невозможно выявить все существующие проблемы и выбрать оптимальный метод решения поставленной задачи. А для этого требуется изучить работу компании и составить ее функциональную модель.
Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об IT системе от лида до заявки. Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.
И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя - много-много слов. И понять в итоге, что же происходит, было очень сложно.
А потому идея Сытина была поистине революционной - он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.
Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERP-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену - это и правда очень сложно.
Этому клиенту я предложил альтернативный вариант - описать все, что можно, графически в виде нотаций. Показал ему примеры моделирования. В итоге они сейчас переосмысливают свои пожелания и оформление технического задания.
Знаю я также много других примеров, когда графическое моделирование бизнес-процессов помогало в работе как моим коллегам, бизнес-консультантам и разработчикам, так и самим бизнесменам.
После изучения существующего положения вещей я, как и любой другой сторонний специалист, создаю коммерческое предложение, в котором максимально подробно раскрываю мое видение текущей ситуации, а также действия, которые необходимо выполнить для решения поставленной задачи, и, конечно, ожидаемый результат.
Такие отчеты об обследовании работы получаются объемные, занимают не одну страницу, что с одной стороны, необходимо, а с другой – усложняет восприятие. Вначале я, как и многие, думал, что объемные отчеты - это хорошо, ведь человек платит за работу и нужно ему предоставить максимум подробной информации.
Часто при моделировании на бумаге или в различных программах пользователи пытаются повысить наглядность за счет использования разных цветов. Это одна из самых распространенных ошибок. На самом деле, применение разноцветных стрелок и блоков только вносит дополнительную путаницу, а также искажает восприятие схемы.
Ваша модель должна читаться в черно-белом виде, без каких-то дополнительных цветовых решений. Такой подход одновременно помогает избежать недоразумений и дисциплинирует создателя модели, в результате читабельность и грамотность модели повышаются.
Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.
Аналогично, если я решу добавить какой-то блок, важно убедиться, чтобы он также имел все необходимые атрибуты. Здесь очень важна внимательность, так как при моделировании сложных бизнес-процессов изменения в одной части модели могут повлечь за собой изменения в другой. Их обязательно нужно внести.
Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.
При этом я считаю, что бизнес-аналитик - это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0.
А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками. Только если ваша функциональная модель «как есть» будет действительно отражать реальное положение вещей, можно вносить какие-то изменения и предложения. А для достижения качественных результатов в такой работе требуется, прежде всего, практический опыт и знание особенностей того или иного вида бизнеса.
Еще статьи по данной теме.
Страховые компании - это финансовые посредники, которые специализируются на предоставлении страховых услуг. Их деятельность состоит в формировании на основании договоров с юридическими и физическими лицами (через продажу страховых полисов) специальных денежных фондов, из которых осуществляются выплаты страхователям денежных средств в обусловленных размерах в случае наступления определенных событий (страховых случаев).
Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск
Введение………………………………………………………………..………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), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию. | |||
