- •Конспект лекцій з дисципліни
- •План лекції
- •Основні поняття теми лекції
- •1.1. Інформатизація в системі управління підприємством
- •1.2. Поняття інформаційної системи
- •Приклади систем
- •Зміна підходу до використання інформаційних систем
- •1.3. Інформаційна стратегія як ключовий чинник успіху
- •1.4. Зовнішнє і внутрішнє інформаційне оточення підприємства
- •1.5. Інформаційний контур, інформаційне поле
- •Висновки
- •Критерії засвоєння
- •Рекомендована література до лекції
- •Питання для самоперевірки
- •План лекції
- •Основні поняття теми лекції
- •2.1. Загальні властивості інформаційних систем
- •2.2. Роль структури управління у формуванні іс
- •2.3. Типи даних в організації
- •2.4. Категорії іс, що підтримують різні типи рішень
- •2.5. Поняття про технології olap
- •2.6. Поняття про Data Mining
- •2.7. Поняття про інтелектуальні системи
- •2.8. Інформаційні системи підтримки діяльності керівника
- •2.9. Інтеграція інформаційних систем підприємства
- •Висновки
- •Критерії засвоєння
- •Рекомендована література до лекції
- •Питання для самоперевірки
- •План лекції
- •Основні поняття теми лекції
- •3.1. Принципи створення інформаційної системи
- •3.2. Структура середовища інформаційної системи
- •3.3. Модель створення інформаційної системи
- •3.4. Реінжинирінг процесів бізнесу
- •3.5. Відображення і моделювання процесів
- •3.6. Забезпечення процесу аналізу і проектування іс можливостями case-технологій
- •3.7. Впровадження інформаційних систем
- •Висновки
- •Критерії засвоєння
- •Рекомендована література до лекції
- •Питання для самоперевірки
- •План лекції
- •Основні поняття теми лекції
- •4.1. Методологія планування матеріальних потреб підприємства mrp
- •4.2. Стандарт mrp II
- •4.3. Erp і управління можливостями бізнесу
- •4.4. Склад erp-системи, основні відмінності систем mrp і erp
- •4.5. Особливості вибору і впровадження erp-системи
- •Співвідношення вартісних оцінок впровадження
- •Приклад побудови матриці "Критерії вибору іс"
- •4.6. Особливості та основні проблеми впровадження і використання erp-системи
- •Висновки
- •Критерії засвоєння
- •Рекомендована література до лекції
- •Питання для самоперевірки
- •План лекції
- •Основні поняття теми лекції
- •5.1. Необхідність забезпечення безпеки даних і інформаційного захисту
- •5.2. Засоби забезпечення безпеки даних і інформаційного захисту
- •5.3. Організація забезпечення безпеки даних і інформаційного захисту
- •5.4. Вибір засобів забезпечення безпеки даних і інформаційного захисту
- •Висновки
- •Критерії засвоєння
- •Рекомендована література до лекції
- •Питання для самоперевірки
- •Понятійний апарат навчальної дисципліни
- •Рекомендована література з навчальної дисципліни
2.9. Інтеграція інформаційних систем підприємства
Взаємозв'язок інформаційних підсистем підприємства. Яким чином зв'язані інформаційні системи усередині підприємства? Звичайний шлях для української компанії середніх розмірів - починати впровадження інформаційних технологій з автоматизації роботи бухгалтерії, відділу кадрів і документообігу. Дані цих систем найбільш формалізовані, процеси легко автоматизуються. Широко поширені пакети "1C: Бухгалтерія", "Бос: Кадровик", "LanDocs", "LanStaff", "Salary" та інші дозволяють нарощувати себе будь-якими додатками і, таким чином, інтегрувати їх в загальну інформаційну систему підприємства. Рис. 2.25 показує яким чином модулі інформаційної системи компанії пов'язані один з одним. Модуль TPS обслуговує основні виробничі і допоміжні процеси, і звичайно це головне джерело для інших інформаційних модулів. ESS - головний одержувач даних і внутрішніх систем із зовнішнього середовища.
Рис. 2.25. Взаємодія модулів ІС
Інші системи також обмінюються даними. І тут виникає одне з найважчих питань для керівника - пошук оптимального ступеня інтеграції. Велика спокуса мати абсолютно інтегровану систему, але така інтеграція надзвичайно трудомістка і коштує чималих грошей. І краще навіть не говорити, в що обходиться супровід такої системи. Тому потрібно зважити потреби в інтегрованих системах, поставивши їх на чашу ваг проти труднощів і дорожнечі великомасштабної ІС. Не існує стандартного рівня інтеграції або централізації - кожен керівник повинен самостійно (або за допомогою консалтингової фірми) вирішувати цю непросту проблему.
Зв'язки між DSS і сукупністю TPS, KWS, MIS навмисно показані невизначеними. Іноді DSS тісно пов'язана з іншими підсистемами. Але це тільки в тому випадку, якщо підприємство відрізняється високим ступенем автоматизації всіх процесів. Звичайно підсистема DSS ізольована від основних виробничих інформаційних систем і використовує їх дані і інформаційні потоки для роботи своїх аналітичних систем.
Так чи інакше, немає рецептів на всі випадки - все залежить від організаційно-функціональної структури конкретного підприємства, структури його бізнесу, реальних інвестиційних можливостей і політики розвитку.
Сервіс-орієнтована архітектура ІС. Інтеграція різнорідних і розподілених даних не в змозі вирішити всі питання управління підприємством. Відповідно до процесного підходу найбільшу цінність представляють не самі по собі дані, а використання інформації в тих або інших бізнес-процесах компанії. У найсучасніших ІС прийнято розглядати як "атомарну" одиницю не дані в "чистому" вигляді, а деякий сервіс, відповідний якомусь елементарному бізнес-процесу. Зокрема, такий сервіс може просто видавати якісь дані, будучи аналогом "атомарної" одиниці класичних ІС.
В даний час при формуванні інформаційної інфраструктури підприємства, при проектуванні і реалізації КІС все частіше застосовується сервіс-орієнтована архітектура (Service-Oriented Architecture - SOA). Це така архітектура ІС, в якій система будується з набору гетерогенних слабо зв’язаних компонентів (сервісів). SOA розуміється як парадигма організації і використання розподіленої безлічі функцій, які можуть контролюватися різними власниками. Базовими поняттями в такій архітектурі є "інформаційна послуга" і "композитний додаток".
Інформаційна послуга (сервіс) - це атомарна прикладна функція автоматизованої системи, яка придатна для використання при розробці додатків, що реалізовують прикладну логіку процесів, що автоматизуються, як в самій системі, так і для використання в додатках інших автоматизованих систем.
Сервіс звичайно характеризується наступними властивостями:
можливість багатократного застосування;
послуга може бути визначена одним або декількома технологічно незалежними інтерфейсами;
виділені послуги слабо зв'язані між собою, і кожна з них може бути викликана за допомогою комунікаційних протоколів, що забезпечують можливість взаємодії послуг між собою.
Композитний (складене) додаток - програмне рішення для конкретної прикладної проблеми, яке пов'язує прикладну логіку процесу з джерелами даних і інформаційних послуг, що зберігаються на гетерогенній безлічі базових інформаційних систем. Звичайно композитні додатки асоційовані з процесами діяльності і можуть об'єднувати різні етапи процесів, представляючи їх користувачу через єдиний інтерфейс.
Використання такого підходу при побудові архітектури складних інтегрованих інформаційних систем дозволяє:
створити систему корпоративних композитних додатків, заснованих на системі корпоративних Web-сервісів;
організувати інтеграцію додатків, процесів бізнесу, з автоматизацією процесів бізнесу, включаючи Human Workflow;
використовувати різні транспортні протоколи і стандарти форматування повідомлень, засобу забезпечення безпеки, надійної і своєчасної доставки повідомлень;
істотно підвищити швидкість розробки прикладних додатків і понизити витрати на ці цілі.
Завдяки спрощенню середовища управління і взаємодії знижується потреба в кодуванні нових програм; повторне використання сервісів скорочує витрати часу на розробку; раціоналізація успадкованих процесів допомагає зменшити загальне число процесів, що вимагають ексклюзивних методів управління; завдяки використанню простих протоколів значно скорочуються трудовитрати на підтримку додатків.
Обов'язковою умовою побудови і впровадження архітектури системи на основі SOA є використання єдиної інфраструктури опису сервісів (репозиторія сервісів), дозволених протоколів доступу і обміну повідомленнями, форматів повідомлень.
Згадана інфраструктура утворює так звану інтеграційну шину (ІШ) (Enterprise Service Bus - ESB), що є одним з центральних компонентів системи (рис. 2.26). Вона встановлює єдині правила публікації сервісів, управління і інформаційної взаємодії між додатками різних систем, що входять до складу інтегрованої системи. Це спрощує управління додатками і їх підтримку, а також знижує ризик фрагментації додатків і процесів.
Рис. 2.26. Структура побудови ESB і компоненти концепції SOA
Кожна із служб взаємодіє не з рештою служб безпосередньо, а тільки з шиною. ІШ утворює однорідне середовище інформаційної взаємодії і є фундаментом для інтеграції інформаційних систем, що функціонують в різних установах і відомствах. ІШ визначає, ким, де, яким чином і в якому порядку повинні оброблятися запити.
Якщо сервіс (інформаційний ресурс) не підтримує ці правила, необхідно створювати проміжний модуль-адаптер, який надає системі необхідний інтерфейс і забезпечує взаємодію з ресурсом.
За даними Gartner Group ("Predicts 2007: SOA Advances", 17 листопада 2006 року): "До 2008 року SOA стане пануючою архітектурою побудови ІТ-систем, що приведе до закінчення 40-річної ери панування архітектури монолітних додатків".
Зміна і вдосконалення процесів бізнесу в компаніях займає роки. За даними Gartner Group, 80% ІТ-бюджету - це витрати на супровід систем, з них 35% - витрати на інтеграцію додатків, 60% вартості впровадження корпоративної ІС складають витрати на інтеграцію, 50% ІТ-бюджету витрачено на забезпечення інтерфейсів систем. Використання SOA-архітектури дозволяє ефективно організувати оперативну адаптацію ІТ-систем під вимоги бізнесу, що дає стратегічну перевагу компанії, що полягає в:
підвищенні швидкості адаптації бізнесу до швидко змінних вимог ринку (Agility);
розширенні взаємодії гетерогенних корпоративних інформаційних систем при збереженні зроблених в них інвестицій;
скороченні витрат на ІТ-системи на основі повторного використання їх функціональних компонентів;
підвищенні продуктивності праці клієнтів, партнерів і співробітників (на основі архітектури Web 2.0).
З погляду бізнесу SOA можна представити як набір гнучких служб і процесів, які бізнес пропонує своїм замовникам, партнерам або усередині своєї власної організації. У даному контексті ці ж служби можна по-різному комбінувати і оснащувати, підтримуючи зміни або розвиток вимог бізнесу і моделей з часом.
Основні бізнес-цілі впровадження SOA-рішень полягають в ліквідації:
фрагментованості і дублювання даних;
дублювання реалізацій функцій бізнесу, процедур, процесів;
негнучкої архітектури.
Становлення і розвиток SOA відбувалося на базі практичних вимог бізнесу, що полягали перш за все в розумній економії програмних і технологічних засобів і витрат на реалізацію і супровід інформаційної інфраструктури:
забезпечувати спадкоємність інвестицій в IT, збереженні існуючих інформаційних систем і їх сумісному ефективному використанні для підвищення ROI від IT-вкладень;
забезпечувати реалізацію різних типів інтеграції:
призначена для користувача інтеграція (User Integration) - забезпечення взаємодії інформаційної системи з конкретним персоніфікованим користувачем;
інтеграція додатків (Application Connectivity) - забезпечення взаємодії додатків;
інтеграція процесів (Process Integration) - інтеграція процесів відповідно до бізнес-логіки діяльності підприємства;
інформаційна інтеграція (Information Integration) - інтеграція з метою забезпечення доступності інформації і даних;
інтеграція нових додатків (Build to Integrate) - інтеграція нових додатків і сервісів в існуючі інформаційні системи.
забезпечувати поетапність впровадження знов створених і міграції існуючих інформаційних систем;
мати стандартизовану технологічну забезпеченість реалізації і інструментарій розробки, що сукупно надають якнайкращі можливості повторного використання додатків, впровадження нових і міграції існуючих інформаційних систем;
дозволяти реалізацію різних моделей побудови інформаційних систем, особливо, таких як портальні рішення, grid-системи і on-demand-системи.
Сьогоднішній рівень розвитку SOA дозволяє стверджувати, що всі вказані вимоги в тій чи іншій мірі виконуються.
Зростання ринку продуктів для SOA-рішень - 100% в рік. У 2007 році SOA буде використана як основа створення 50% нових додатків, критичних для бізнесу і процесів бізнесу; до 2010 року цей показник виросте до 80%. Більше 80% додатків, введених в промислове використання в 2006 році, будуть частково або повністю перепроектовані до 2010 року, щоб бути використаними в побудові композитних додатків в SOA- архітектурі.
До 2010 року більше 80% всіх програмних інфраструктурних продуктів включатимуть корпоративну шину сервісів або вимагати її використання. Серед виконавчих директорів компаній 54% вважають, що в період до 2010 року в числі головних стратегічних переваг компаній нові моделі ведення бізнесу мають більше значення, ніж випуск нових продуктів і послуг. За даними Forrester ("The State of SOA in Financial Services", січень 2006), "Переважна більшість фінансових компаній використовуватимуть SOA до кінця 2008 р. Загалом, 50% європейських фінансових компаній або вже використовують SOA або знаходяться на останній стадії його впровадження".