CC BY
90
УДК 681.3
О.Ю. МЕЛЬНИКОВ, канд. техн. наук (ДДМА),
О.Л. ОЛЬХОВСЬКА
ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
ДЛЯ НЕВЕЛИКОЇ СТРАХОВОЇ КОМПАНІЇ
Розглянуті переваги і недоліки існуючих інформаційних систем для автоматизаціі роботи страхової компанії. З використанням мови моделювання UML розроблена модель інформаційної системи, намічені шляхи її комп’ютерної реалізації.
The advantages and lacks of existing information systems for automation of work of the insurance company are considered. In language of modeling UML the model of projected information system is developed, the ways of its computer realization are planned.
Стан проблеми. Розвиток страхової діяльності на Україні супроводжується рядом проблем. Однією найбільш важливою проблемою страхування є повільна (у порівнянні з банківською діяльністю) автоматизація страхування. Ця проблема найбільше гостро виявляється в отриманні оперативної інформації стосовно укладених договорів страхування, що у свою чергу не дозволяє повною мірою реагувати на зовнішні впливи й ефективно приймати управлінські рішення. Особливо це стосується невеликих страхових компаній, що мало відомі на страховому ринку.
Аналіз літератури. У страховому бізнесі, як і в будь-якій іншій галузі економіки, йде безперервний пошук ефективних технологій і методів підвищення рентабельності. На даний час найбільш популярними є різні рішення, розроблені на основі сучасних інформаційних технологій. Для страхових компаній ринок сучасних ІТ-технологій пропонує різні по апаратному складі і програмному забезпеченні варіанти - від окремих систем, додатків і модулів до універсальних систем, що забезпечують досить повну автоматизацію усіх виробничих, технологічних і допоміжних процесів [1-4].
Так, модульна інформаційна система INSTRAS-4 призначена для комплексної автоматизації обліку в страхових і перестрахувальних компаніях. Вона замикає усі бізнес-процеси в страховій компанії в єдиний інформаційний простір, погоджуючи й оптимізуючи них, забезпечує комплексну автоматизацію всіх ключових відділів і служб страхової (перестрахувальної) компанії. Інтерфейс цієї програми нагадує найбільш популярні на українському ринку програми бухгалтерського обліку.
Для використання в страховому маркетингу пропонується ще цілий ряд програмних продуктів. Наприклад, Marketing Expert і БЕСТ Маркетинг - для стратегічного планування, Косатка і Маркетинг Мікс - для стратегічного й оперативного планування. Програма Marketmg Analyse призначена для аналізу, прогнозу, планування і містить у собі елементи CRM. Програма Sales
Expert забезпечує керування прямими продажами. Спеціалізовані програмні продукти, призначені для рішення задач планування, мають і інші убудовані маркетингові інструменти, використовувані для SWOT-анализу і ряду інших маркетингових операцій у процесі обробки даних. Тією чи іншою мірою перераховані вище програмні продукти можна застосовувати з метою прогнозування і розробки сценаріїв розвитку подій в інтересах рішення маркетингових задач страхової компанії.
Ринок ІТ-технологій пропонує й інші інформаційні рішення. Наприклад, система Contact Manager є універсальним засобом адміністрування робочого часу і керування системою збуту. Вона дозволяє ефективно контролювати ділову активність співробітників системи продажів на всіх рівнях керівництва, відслідковувати історію контактів фахівців агентської мережі - від першого телефонного дзвоника до укладання договору. Contact Manager інтегрований із системою операційного обліку договорів. Можлива інтеграція з технологіями саіі-центру, бізнесу-планування і звітності.
Нова версія інформаційної системи UNICUS EASY ОСАГО v. 1.6. являє собою автоматизоване робоче місце (АРМ) працівника страхової компанії, що дозволяє виконувати наступні операції: повнофункціональний продаж полісів ОСАГО; врегулювання збитків; облік бланків строгої звітності; експорт даних у форматі XML у зовнішні інформаційні бази.
Система ICI (Insurance Company Information System), що випускається фірмою T-systems, може розглядатися як проміжний варіант між індивідуальним і стандартним програмним забезпеченням. У цій системі комплексної автоматизації, розробленої спеціально для страхових компаній, є такі сучасні функції, як CRM, керування документообігом, ведення статистики й інші. Вона легко інтегрується з уже наявними в страховій компанії бек-офісними рішеннями.
Але треба пам’ятати, що інтегровані інформаційні системи типу Insurance Company використовуються, як правило, великими страховими компаніями, тому що мають високу ринкову вартість і недоступні для дрібних страхових компаній. Для автоматизації своєї діяльності дрібні страхові компанії використовують або системи власних розробок, або недорогі системи, що пропонують обмежений набір можливостей.
Ціль статті. Ми пропонуємо інформаційну систему, розраховану на великое коло користувачів, тобто для тих офісних робітників, робота яких безпосередньо пов’язана з базою даної інформаційної системи. Система, що проектується, не виключає використання її будь-якими невеликими страховими компаніями. Вона повинна припускати повну автоматизацію діяльності страхової компанії і підтримувати повний цикл процесу обробки інформації з усіх видів страхування [5 - 7].
Вибір методів проектування. Через достатню складність проектуємої інформаційної системи звичайний структурний підхід не підходить, тому що
при ньому основою системи є алгоритм - послідовність дій за рішенням задач. Опис функціонування страхової компанії у виді алгоритму недоцільно, і ми застосуємо об’єктно-орієнтований підхід. Інформаційна система в такому випадку буде являти собою сукупність взаємозалежних об'єктів. У свою чергу, кожен об'єкт є екземпляром визначеного класу, а класи утворять ієрархію спадкування.
Розробка інформаційної системи проводиться в три етапи:
1. Об’єктно-орієнтований аналіз предметної області: визначення ключових абстракцій, ідентифікація класів і об'єктів.
2. Концептуальне, логічне і фізичне моделювання інформаційної системи; побудова відповідних діаграм.
3. Програмна реалізація розробленої моделі.
Перший етап включає аналіз дій, здійснюваних у процесі страхування, виділення активних і пасивних класів (об'єктів). Актором (активним об'єктом) у нашому випадку буде оператор уведення даних (у першому наближенні), а пасивними об'єктами - дані по укладених договорах страхування.
На другому етапі створюється інформаційна модель проектованої системи, для чого використовується уніфікована мова моделювання UML [8]. В даний час уніфікована мова моделювання (Unified Modeling Language) є одним з найбільш популярних у сфері інструментів розробки об’єктно -орієнтованих систем. Вона є візуальною мовою моделювання, що дозволяє системним архітекторам представляти своє бачення системи в стандартній і легкій для розуміння формі. Крім того, надає ефективний механізм спільного використання проектних рішень і взаємодії розроблювачів один з одним.
Побудова концептуальної моделі. Проектування починається з формулювання вимог до розроблювальної системи, визначення функцій, яки вона повинна реалізувати, і задач, яки вона повинна вирішувати. На основі цих даних формується діаграма варіантів використання. У нашому випадку діаграма варіантів використання («прецедентів») ґрунтується на вимогах, функціях, задачах страхової компанії, які повинна виконувати система, що розробляється. Відповідно до діаграми, прецедент «Робота з даними» є основою для прецедентів: отримання даних; введення даних; модифікація даних; перегляд даних; контроль правильності введених даних. Прецедент «Обробка даних» є основою для прецедентів: перегляд даних; звірення даних; формування звіту; видача вихідної інформації. Прецедент «Робота з вихідною інформацією» є основою для прецедентів: перегляд даних; обробка вихідної інформації; формування звітів.
Побудова логічної структурної моделі. Далі будується структурна схема системи у виді діаграми класів (рис. 1), які являють собою відправну крапку процесу розробки.
Рис. 1. Діаграма асоціацій класів
Діаграми класів допомагають при аналізі предметної області та дозволяють аналітику звертатися з клієнтом у його термінології і стимулюють
процес виявлення важливих деталей у проблемі, що потрібно вирішити. Аналіз предметної області процесу функціонування невеликої страхової компанії відображено на рис. 1. На рис. 2 представлено деталізацію класів.
Клієнт::Оператор
уведення
ПІБ
Адреса
Дата народження
Отримати () Проконтролювати () Повернути () Опрацювати () Ввести () Модифікувати () Провірити () Порівняти () Сформувати ()
Клієнт::Група
кінцевих
користувачів
Найменування
Продивитися () Провірити () Опрацювати () Сформувати ()
Вихідні дані
Період
Умова
Звіт
Продивитися () Проаналізувати ()
Клієнт::Агент Клиент::Бухгалтер
ПІБ ПІБ
Адреса Адреса
Дата народження Дата народження
Передати () Отримати ()
Контролювати () Продивитися ()
Виправити () Опрацювати ()
Сформувати ()
Клієнт::Страхувальник
ПІБ
Адреса
Дата народження
Вибрати () Заключити ()
Вхідні дані
Код
Номер
Страхувальник
Агент
Об’єкт
Дата підписання договору Дата початку дії Дата закінчення дії Ризики
Брати участь у розробці ()
Рис. 2. Діаграма деталізації класів
Клієнт-страхувальник звертається до страхової компанії до клієнта-агента з метою укласти договір страхування. Узгоджуються умови страхування, підписується договір страхування. Клієнт-агент передає записані вихідні дані клієнта-страхувальника (страховий поліс) клієнтові-операторові введення, що у свою чергу, обробляє ці дані і заносить у ПК (збереження в базу). Також
клієнтові-операторові уведення надходять бухгалтерські дані від клієнта-бухгалтера. Після того, як усі дані оброблені і збережені в базі, клієнт-оператор уведення формує вихідну інформацію (у виді звіту визначеної форми) і передає клієнтові-бухгалтерові для звірення. У свою чергу, клієнт бухгалтер після перегляду й обробки отриманої інформації також формує вихідну інформацію (у виді звіту визначеної форми). Сформовані й оброблені дані, як клієнтом-оператором уведення, так і клієнтом-бухгалтером передаються клієнтові-групі кінцевих користувачів. Вербальний опис процесу роботи страхової компанії з клієнтами дозволяє виділити наступні класи: клієнт-страхувальник, клієнт-агент, клієнт-оператор уведення, клієнт-бухгалтер, клієнт-група кінцевих користувачів, що уводять дані, вихідні дані.
Побудова логічної динамічної моделі. Під час роботи системи об'єкти взаємодіють один з одним, і ця взаємодія проходить у часі. Діаграма послідовностей показує вимір часу по взаємодії об'єктів. Об'єкти розташовуються вгорі, а час виміряється зверху вниз. Таке графічне представлення дозволяє побачити, скільки затрачається часу кожному об'єктові для виконання своїх функцій. Кожна лінія зі стрілочкою, що з'єднує одну лінію життя з іншої відповідає передачі повідомлення від одного об'єкта до іншого.
У нашому випадку фігурка представляє страхувальника (виконавця), що ініціює послідовність, хоча, у принципі, ця фігурка не є частиною діаграми послідовностей. Об'єкт "Оператор уведення" одержує повідомлення від агента, після чого відбувається обробка отриманих даних. У процесі роботи об'єкт "Оператор уведення" одержує асинхронне повідомлення від об'єкта "Бухгалтера" (тобто об'єкт "Бухгалтер" не очікує відповіді від об'єкта "Оператор уведення"). Після обробки даних об'єкт "Оператор уведення" передає дані об'єктові "Бухгалтер" у виді синхронного повідомлення, тобто очікує відповіді від об'єкта "Бухгалтер", а саме йде уточнення з боку об'єкта "Бухгалтер" у виді умови: оброблені дані вірні або оброблені дані невірні. У випадку дані невірні - йде доробка, а у випадку дані вірні - відбувається відправлення повідомлення кінцевому користувачеві, тобто групі кінцевих користувачів.
Діаграма кооперації, також як і діаграма послідовностей, відбиває взаємодію об'єктів. Але розходження цих двох діаграм полягає в тім, що діаграма послідовностей упорядкована у відповідності згодом, а діаграма кооперації - у відповідності з просторовим розташуванням об'єктів, тобто орієнтована на стан і загальну організацію взаємодіючих об'єктів.
На рис. 3 показана діаграма кооперації роботи страхової компанії. Діаграма описує послідовність інформації, що надходить до об'єкта у виді повідомлення. У нашому випадку деякі повідомлення є дочірніми стосовно інших. Вони представлені з використанням десяткової крапки для позначення рівня вкладеності. Так об'єкт "Оператор уведення" може передати оброблені дані об'єктові "Бухгалтер" тільки після того, як одержить бухгалтерські дані
від цього ж об'єкта. Тому що без бухгалтерських даних не можливо сформувати кінцеві дані. У свою чергу кінцеві дані об'єкт "Група кінцевих користувачів" від об'єкта "Оператор уведення" одержує тільки після передачі вихідних даних від об'єкта "Бухгалтер".
Діаграма станів представляє, як об'єкти змінюють свій стан у відповідь на події, що відбуваються, і з часом, показує початковий і кінцевий стан об'єкта. При включенні комп'ютера відбувається завантаження. Тому включення комп'ютера є перемикаючою подією, що приводить до переходу інтерфейсу в стан ініціалізація, а завантаження - дія, що відбувається під час переходу. Результатом виконання дій у стані ініціалізації є вироблення перемикаючої події, що викликає перехід у стан роботи. При щиглику на кнопці завершення роботи здійснюється перехід у стан "Завершення роботи", і в остаточному підсумку комп'ютер виключається.
Стан реєстрації нового страхового поліса в базі є підлеглим. Система знаходиться в стані "Очікування введення даних", поки оператор уведення не уведе відповідну умову. Далі активізуються стани "Обробка даних" і "Збереження даних". Підсумковий стан - "Візуалізація результатів".
(вихідні дані) Рис. 3. Діаграма кооперації
Діаграма діяльності реально описує усе, що відбувається під час операції або процесу. У нашому випадку діаграма видів діяльності розбивається на "плавальні доріжки" - рівнобіжні сегменти, що відповідають ролям (рис. 4). Показано, як проходять дії, що відбуваються під час функціонування об'єкта.
Побудова фізичної моделі. Діаграма компонентів відображає елементи реального світу - компонента програмного забезпечення. Кожен компонент є фізичною частиною системи, тобто робочою частиною системи. У нашому випадку для роботи з даними необхідний компонент "Таблиця", а для представлення дані таблиці - інтерфейс "Робота з даними". У свою чергу робота з даними може включати: перегляд даних, реєстрацію нових даних, редагування даних, формування звіту по заданій умові. Отже, виділимо наступні інтерфейси: "Перегляд", "Редагування", "Вибір", "Автоматичний підбор", "Звіт". Кінцевий від діаграма компонентів буде мати беспосередньо перед комп’ютерною реалізацією моделі.
Виводи. Запропонована модель інформаційної системи припускає повну автоматизацію діяльності страхової компанії в цілому та підтримує повний цикл процесу обробки інформації з усіх видів страхування. Вона поєднує в собі наступне: простоту використання, невисокі вимоги до використовуваної комп'ютерної техніки, доступність, тобто порівняльна дешевина в порівнянні з відомими інформаційними системами, розширені можливості системи. Також інформаційна система припускає максимальну ефективність обробки даних, необмежений обсяг інформації і кількості користувачів [9]. Комп’ютерну реалізацією створеної моделі буде зроблено в середовищі візуального програмування Borland-Delphi, в основі якої лежить об'єктно-орієнтована мова програмування Object-Pascal.
Список літератури: 1. Заруба О.Д. Страхова справа: Підручник. - К.: КНЕУ, 1998. 2. Біленчук Д.П., Біленчук П.Д., Залетів О.М., Кліменко Н.І. Страхове право України: Підручник. -К.: Атака, 1999. - 368 с. 3. Ротова Т.А., Руденко Л.С. Страхування: Навч. посібник. - К.: КНЕУ,
2001.- 400 с. 4. Осадець С.С. Страхування: Підручник. Вид. друге, перероб. і доп. - К.: КНЕУ,
2002. - 599 с. 5. Береза А.М. Основи створення інформаційних систем: Навч. посібник. - К.:
КНЕУ, 2001. - 214 с. 6. Проектування інформаційних систем: Посібник / За ред.
В.С. Пономаренка. - К.: Академія, 2002. - 486 с. 7. Черенков А.П. Информационные системы для экономистов: Учебное пособие. - М.: Экзамен, 2002. - 192 с. 8. ЛеоненковА.В. Самоучитель UML. - СПб.: БХВ-Петербург, 2004. - 432 с. 9. Ольховская О.Л. Проектирование информационной системы для функционирования страховой компании // Комп’ютерне моделювання та інформаційні технології в науці, економіці та освіті: Збірник наукових праць. - Кривий Ріг: КЕІ КНЕУ, 2005. - С. 305-306. 10. Скрипник Г.Г. Экономическая эффективность информационных систем. - М.: ДМК-Пресс, 2002. - 256 с.
Поступила в редакцію 13.10.2005
