Отримання згоди у главного бухгалтера

Рисунок 4.7 – Приклад процесно-орієнтованого сценарію

Декомпозиція (або розбиття) забезпечує більш детальний опис БП (блоків ситуацій). Використання більше однієї декомпозиції для одного і того ж БП полягає в необхідності відобразити різні погляди на процес того або іншого БП. На малюнку 7 БП «Запит матеріалу» розкладено на складові частини в прямокутниках 1.1.7-1.1.10.

Об'єктно-орієнтовані уявлення: Об'єктна схема

Об'єктні схеми IDEF3 фіксують, управляють і відображають об'єктно-орієнтовані описи процесів, тобто інформацію про те, як:

- об'єкти різних видів перетворюються в об'єкти інших видів під час виконання процесу;

- об'єкти даного типу змінюють своє полягання під час виконання процесу;

- формується інформація про відносини між об'єктами в процесі.

В IDEF3 об'єкт – це будь-який матеріальний або абстрактний предмет, який використовується для опису того, що відбувається в конкретній області.

Імена об'єктів часто є іменами іменниками або оборотами іменниками. Імена об'єктів можуть зустрічатися як з описом полягання, так і без нього, наприклад:

- вода: кипіння;

- замовлення на покупку схвалене;

- блок.

Об'єктні схеми можуть бути розроблені в контексті одиночного сценарію – в цьому випадку характеристики змін полягань між об'єктами називаються подіями сценарію. Такі схеми називаються Схемами Переходу і дозволяють користувачам визначити умови переходу між подіями сценарію

У той же час, об'єктні схеми можуть ускладняться більш повними описами об'єктів, їх полягань, переходів.

Таким чином, об'єктні схеми IDEF3 розробляються для того, щоб забезпечити об'єктно-орієнтованим описом окремі процеси або сценарії. Тому схеми переходу (Transition Schematics) звичайно домінують над об'єктними схемами IDEF3.

Схема на рисунку 4.8 представляє об'єктну схему для сценарію «Замовлення матеріалу». Цей приклад ілюструє Схему Переходу.

Ключовий документ в цьому процесі – це форма «Вимога на покупку» (ВП). Врешті-решт ця форма перетвориться в «Замовлення на поставку» (ЗП).

Кожний об'єкт укладений в коло. Стрілки, які сполучають два кола, характеризують полягання переходу. Прямокутники, які приєднані до стрілок називаються посиланнями і допомагають описати відносини між поляганнями об'єктів і БП, сценаріями або іншими схемами переходів. З'єднання у вигляді маленького кола (в даному прикладі всередині містить Х) говорить про те, що існує один певний шлях переходу з декількох можливих.

Рисунок 4.8 – Приклад Схеми переходу

Схема на рисунку 4.8 може бути доповнена і іншою необхідною інформацією. Така схема одержала назву Розширеної Схеми Переходу (Enhanced Transition Schematic).

Базисні елементи мови опису процесу в IDEF3 показані на рисунку 4.9

Позначки для БП Позначки Окремі

Об’єктів позначки

Ланцюги Ланцюги

Простий ланцюг старшинства Сильний ланцюг переходу

Слабий ланцюг переходу

Приоритетний ланцюг обмеження

Допоміжний ланцюг

Зв’язки Обозначення з’єднань

Рисунок 4.9 – Базисні елементи мови

Загальні підходи до створення інформаційних систем на підприємстві

Науково-технічна революція відкрила небачені раніше можливості для збільшення масштабів і темпів розвитку виробництва, впровадження автоматизації виробничих процесів, ускладнивши при цьому інформаційні потоки між ланками господарства. Підвищення ефективності виробництва значною мірою визначається інтенсивністю розвитку наукових методів керування і використанням технічних засобів для обробки інформації.

Важливими функціями, що реалізуються в процесі управління підприємством, є: прогнозування, планування, облік, контроль, аналіз, координація та регулювання. Отримання інформації з метою реалізації цих фу­нкцій пов'язане з виконанням трудомістких операцій зі збирання, фіксації, передавання, обробки та зберігання даних, що характеризують виробничу діяльність підприємства. Достовірність і своєчасність отриманої інформа­ції впливають на ефективність прийнятих керівних рішень.

Якісне виконання всього комплексу дій з управління підприємством неможливе поза межами інформаційної системи, створення якої може базуватися на різних підходах: елементному, підсистемному, об'єктному, модельному.

Елементний підхід передбачає використання типових проектних рішень та програмних засобів по окремим функціональним задачам управління.

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

При об'єктному підході використовуються типові рішення для цілого класу об'єктів з урахуванням галузевої специфіки. Цей підхід виявився малоефективним, тому що потребуються значні доробки системи в процесі впровадження, адже кожне конкретне реальне підприємство навіть подібної сфери діяльності не співпадає з типовим об'єктом, як правило, за бага­тьма ознаками.

Крім цього, попередні три підходи дозволяють прискорити лише останній етап створення інформаційної системи – робоче проектування. Самими трудомісткими етапами створення інформаційних систем є допроектний аналіз і технічне проектування.

Модельний підхід до проектування інформаційних систем є найбільш перспективним і оснований на побудові різних типів моделей відповідно до рівнів базових інформаційних технологій – концептуального (коли створюється змістовний образ системи та її підсистем), логічного (виконується формалізований опис інформаційних процесів і функцій системи) та фізичного (що містить програмне, технічне та організаційне забезпечення інформаційної системи). Суть модельного підходу полягає у послідовній декомпозиції (розщіпленні) загальної моделі управління підприємством на окремі моделі і перетворенні їх з одного виду в інший в процесі проекту­вання інформаційної системи.

У методологічному відношенні модельний підхід базується на принципі системності, тобто на ідеях цілісності, цілеспрямованості і організо­ваності процесів, що вивчаються, інтегрованості і взаємозв'язку елементів, їх внутрішній активності та динамізмі.

Модельний підхід знайшов своє відображення в сучасних автоматизованих технологіях проектування інформаційних систем, що називаються CASE-технологіями (CASE – Computer Aided Software Engineering). За до­помогою такої технології та комп'ютера розробник може:

- описати предметну сферу (об'єкти, процеси, функції, зв'язки, властивості), основних учасників системи та їх повноваження, інформаційні потоки і документи, якими обмінюються учасники з урахуванням виконуваних функцій;

- побудувати моделі системи (інформаційні, функціональні, реляційні) з відповідним графічним зображенням;

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

У світі існує чимало CASE-продуктів, що відрізняються по ступеню комп'ютерної підтримки етапів проектування інформаційних систем. Час­тина з них забезпечує тільки графічне зображення функцій, виконуваних підрозділами підприємства, і потоків інформації між ними. В інших – автоматизований процес опису баз даних і складання окремих програм.

Одним з найбільш розвинутих і удосконалених напрямків CASE-методології на сьогодні є концепція Архітектури інтегрованих інформаційних систем (АРІС), а відомим прикладом її реалізації є система R/3 – розробка німецької фірми SAP. Система може бути використана в будь­-яких галузях промисловості та сферах діяльності і являє собою набір інтегрованих прикладних та інструментальних програмних модулів для контролю та обробки інформації.

Конфігурація системи під конкретне підприємство (або середовища під користувача) виконується шляхом інтеграції вже існуючих модулів. Цілісність всієї економічної і виробничої інформації, що підтримується мережевою архітектурою «клієнт-сервер»системи R/3, дозволяє здійсню­вати повний оперативний контроль за всіма етапами діяльності підприємс­тва, від стратегічного планування до відвантаження продукції споживачам. Концентрація інформації в централізованій базі даних гарантує її єдиність та достовірність.

R/З – відкрита система, тобто вона дозволяє спільне використання з іншими системами спеціального призначення (типа САПР, коли, напри­клад, потрібний ввод інформації безпосередньо з обладнання – датчиків, контролерів і т.ін.). Якщо саме в цьому немає потреби, то користувачеві такої системи не прийдеться використовувати інше організаційно-економічне програмне забезпечення – все, що потрібно у відповідній сфері діяльності, можна знайти або створити в межах ЯУЗ. Це підтверджується багаточисельними впровадженнями – налічується біля 10000 встановлених і діючих систем ЮЗ в різних галузях промисловості, фінансової сфери, торгівлі. Вона стала фаворитом американського ринку ділових систем масштабу підприємства, орієнтованих на потреби бізнесу. Одним з перших ко­ристувачів R/3 в Україні є Національний банк.

Особливо ефективним є використання даної системи на великих підприємствах, що мають складну організаційно-виробничу структуру і об'єднують різні управлінські, виробничі, фінансові та інші підрозділи, мають територіально віддалені філії і представництва, які займаються різноманітними видами діяльності.

Методологія АРІС

Ключовим поняттям розробленої німецькими вченими концепції АРІС (основоположник – професор А.В.Шеєр, кінець 80-х років) є понят­тя бізнес-процесу.

Під бізнес-процесом розуміється формалізований опис визначеного набору управлінських процедур, який включає: функції, що виконуються; дані, що використовуються; склад і взаємовідносини організаційних оди­ниць (підрозділів), які задіяні в виконанні вказаних функцій.

Концепція бізнес-процесу виникла в протилежність існуючим принципам організації інформаційних систем підприємств на базі багатьох ок­ремих автоматизованих робочих місць (АРМ). При останньому підході кожна функціональна підсистема підтримує власну базу даних, що народ­жує велику кількість надмірної інформації. Наприклад, фінансова підсистема обов'язково використовує бухгалтерські дані, тому вони по­винні бути введені вручну і в першу, і в другу підсистеми.

Крім надміру, виникає проблема цілісності даних – вони можуть відрізнятись як кількісно, так і якісно (із-за помилок оператора, неоднозчасності оновлення та ін.). Контроль невідповідностей дуже важкий, тому у довгостроковій перспективі доцільніше створювати єдину інформаційну систему підприємства, основану на модельному підході з використанням САБЕ-методології. Зробити це ефективно можна на основі теорії бізнес-процесів.

При побудові інформаційної системи, що базується на концепції бізнес-процесів, здійснюється комплексне вивчення об'єкта проектування з представленням його частин як цілеспрямованих взаємопов'язаних підпроцесів перетворення різних вхідних наборів інформаційних ресурсів в вихідні ресурси. Всі складові цих інформаційних потоків – функції, організації, дані – враховуються рівноправними.

З другого боку, в цілях зниження складності описуваної системи, бізнес-процес розщіплюється на окремі зрізи. Зміст зрізу – спільний роз­гляд тісно пов'язаних складових і абстрагування від інших, менш тісно зв'язаних компонентів. В описі бізнес-процесу виділяють чотири зрізи: три основних – функціональний зріз, зріз даних, організаційний зріз та до­датковий –управлінський зріз.

Слід підкреслити, що така методологія використовується при проек­туванні операційної частини інформаційної системи, тобто частини, в якій йдеться мова про накопичення і передачу даних. Друга частина інформаційної системи – аналітична, що розрахована на діставання інформації за запитами користувачів, будується за іншими правилами.

Рівні опису бізнес-процесу

Формалізоване проектування інформаційної системи в рамках АРІС засновано на строгому розподілі стадій процесу розробки. По ступеню наближення до закінченої інформаційної технології виділено три рівні опису бізнес-процесів: формулювання вимог, розробка технічних умов, опис реалізації.

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

Формулювання вимог представляє собою опис та деталізацію прикладної задачі бізнесу за певними правилами і на такій формалізованій мові, що в подальшому стане можливим послідовний переклад задачі в інформаційну технологію.

На рівні технічних умов понятійне оточення сформульованих вимог переводиться в стандартизовані категорії інформаційної системи –інтерфейси, коли замість самих функцій визначаються користувацькі транзакції, що виконують ці функції. Зв'язок між формулюванням вимог і технічними умовами односторонній – зміна вимог призводить до зміни технічних умов; самі ж вимоги повинні формулюватися так, щоб зміни технічного оточення не викликали перегляду вимог.

На третьому рівні – описі реалізації – технічні умови перетворюються в конкретні елементи апаратного та програмного забезпечення. Цей рівень тісно пов'язаний з розвитком інформаційних технологій (нові системи баз даних, мережеві технології, апаратне забезпечення) і тому найбільш схильний до змін та перегляду.

Взаємодія між рівнями та зрізами в операційній частині бізнес-процесу схематично зображена на рисунку 4.10.

Засоби зображення зрізів бізнес-процесу на рівні формулювання вимог

Зображення зрізів бізнес-процесу здійснюється графічними методами з використанням різних типів діаграм методології IDEF (ІСАМ Definition), що є промисловим стандартом для цілей проектування складних інформа­ційних систем. В даній роботі використовуються дві групи засобів зобра­ження IDEF-технології (методика SADT і діаграми ER-типу) та діаграми процесів PCD методології АРІС.

Рисунок 4.10 – Схема взаємодії зрізів та рівнів АРІС

1) Методика SADT. Розроблена Л. Россом і являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі будь-якої предметної сфери. Функціональнальна модель подається у вигляді SADT-діаграми, основними елементами якої є блоки. Взаємодія функціональних блоків один з одним описується за допомогою інтерфейсних ліній, що визначають, коли і яким чином функції виконуються та ким керуються.

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

У такому випадку відбувається розгалуження процесу, що на функціоальній діаграмі зображується у вигляді розділеного вертикальною лінією кола. Символи «V» чи «^» означають тип логічної умови «або» чи «і» (рисунок 4.11):

Рисунок 4.11 – Фрагмент функціональної діаграми

Пояснення до рисунку 4.11:

- запускаюча подія – функціональний блок ФБ1;

- перемикаюча подія – функціональний блок ФБ2. Залежно від результату перевірки умови, закладеної в ФБ2, виконується або ФБЗ, або ФБ4;

- завершуюча подія – блок ФБ5.

2) Діаграми ER-типу («сутність-відношення») є графічним засобом, за допомогою якого здійснюється зображення елементів зрізу даних і організаційного зрізу.

Сутність (Entity) – це реальний або абстрактний об'єкт (люди, предмети, показники, ідеї, події та ін.), що має суттєве значення з точки зору предметної сфери та інформація про який належить зберіганню в базі да­них.

Кожний екземпляр сутності повинен однозначно ідентифікуватися і відрізнятися від інших екземплярів даного типу сутностей. Для цього ко­жна сутність має ім'я та атрибути.

Атрибут – це якісна або кількісна характеристика сутності. Звичайно сутність має декілька атрибутів, значення яких дозволяють відрізняти ок­ремі екземпляри сутності.

Кожна сутність може мати зв'язки (відношення) з іншими сутностями моделі.

Відношення (Relationship) – це логічний зв'язок між сутностями, коли кожний екземпляр однієї, незалежної, сутності (сутність-батько) асоційовані з будь-якою кількістю екземлярів залежної сутності (сутність-потомок), а кожен екземпляр сутності-потомка асоційований в точності з од­ним екземляром сутності-батька. Тобто сутність-потомок може існувати тільки при наявності сутності-батька.

3) Діаграма ланцюга процесу PCD (Process Chain Diagrams), що пропонується методологією АРІС для зображення управлінського зрізу бізнес-процесу повинна охоплювати функції, організаційну структуру і дані, тобто поєднувати результати, отримані при аналізі окремих зрізів. Діаграма PCD має містити в єдиній таблиці детальний опис всіх елементів біз­нес-процесу:

- подій;

- функцій;

- даних, що обробляються відповідними функціями;

- інформаційних об'єктів, яким належать дані;

- типів обробки інформації (автоматична чи інтерактивна);

- організаційних підрозділів, що виконують відповідні функції;

- прав доступу до інформації.

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

Основні етапи побудови зрізів бізнес-процесу

Для побудови зрізів бізнес-процесу необхідно:

1) Зробити детальний аналіз складу і змісту бізнес-процесу і описати його. Виділити його основні складові частини, підпроцеси та події, що можуть змінювати хід або послідовність виконання окреміх підпроцесів.

Побудувати укрупнену схему бізнес-процесу та зробити опис запускаючих, перемикаючих та завершуючих подій.

2) Визначити склад підрозділів (організаційних одиниць), що задіяні в процесі, описати взаємозв'язки та підпорядкованість підрозділів, скласти діаграму організаційної структури бізнес-процесу.

3) Сформулювати зміст подій процесу, умов і послідовності їх виконання. Здійснити уточнення та функціональну розбивку і прив'язку подій до організаційної структури. Скласти функціональну схему процесу з роз­поділом функцій по підрозділам. Побудувати функціональну діаграму бізнес-процесу (з урахуванням впливу запускаючих, перемикаючих і завершуючих подій на протікання процесу).

4) Осмислити склад інформаційних потоків, визначити основні групи даних (зовнішніх, внутрішніх основних та довідкових). Скласти схему розподілу даних в межах організаційного та функціонального зрізів. Виділити набір сутностей, відношень між ними та атрибутів сутностей і побудувати елемент зрізу даних – модель ER-типу.

5) Об'єднати виконане на попередніх етапах та побудувати управлінський зріз, склавши діаграму ланцюга процесу PCD.

4.2.6 Деякі аспекти побудови зрізів на прикладі бізнес-процесу «Надання банківського кредиту»

Опис предметної сфери

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

Виділяються характерні в термінах АРІС події (запускаючі, перемикаючі, завершуючі), що визначають порядок та послідовність виконання функцій. Їх опис може бути зроблений, наприклад, у вигляді таблиці 4.1.

За результатами проведеного аналізу будується укрупнена схема основних елементів бізнес-процесу (підпроцесів, наприклад, як показано на рисунку 4.12).

Організаційний і функціональний зрізи будуються відповідно до рекомендацій п.2.5 (рисунки 4.13, 4.14; таблиця 4.2).

Зображення зрізу даних здійснюється за допомогою схеми інформаційної взаємодії між організаційними підрозділами (таблиця 4.3) та ER-діаграми, що містить декілька найбільш характерних для бізнес-процесу сутностей з атрибутами і відношеннями між ними (рисунок 4.15).

Діаграма PCD має містити опис всіх функцій функціонального зрізу бізнес-процесу (в таблиці 4.4 зображений тільки фрагмент управлінського зрізу).

Таблиця 4.1 – Опис подій

Зміст події	Тип події
1. Запит клієнта про надання кредиту	Запускаюча
2. Репутація клієнта 3. Фінансовий стан позичальника 4. Якість застави 5. Ціль використання кредиту 6. Якість документів, наданих кредитній раді	Перемикаюча
7. Видача кредиту 8. Відмовлення	Завершуюча

Організаційний зріз

Рисунок 4.12 – Укрупнена схема бізнес-процесу «Надання банківського кре­диту»

Рисунок 4.13 – Діаграма організаційної структури бізнес-процесу

Функціональний зріз

Таблиця 4.2 – Розподіл функцій по підрозділам

№ функціонального блоку	Зміст функціонального блоку	Підрозділ
1	2	3
ФБ1	Розгляд документів, реєстрація пози-чальника в системі	Кредитне управління (КУ)
ФБ2	Перевірка цілей кредитування та ділової репутації керівництва під-приємства, засновників і партнерів. Підготовка висновку	Служба безпеки банку (СББ)
ФБЗ	Аналіз кредитної історії позичаль-ника. Підготовка висновку	Кредитне управління (КУ)

Продовження таблиці 4.2

1	2	3
ФБ4	Аналіз фінансового стану, плато-спроможності та кредитоспромож-ності клієнта. Визначен­ня ліміту кре-дитування. Підготовка висновку	Кредитне управління (КУ) Фінансово-аналітичний відділ (ФАВ) Служба внутрішнього ау­диту (СВА)
ФБ5	Оцінка вартості та ліквідності застави. Підготовка висновку	Відділ оцінки застави (ВОЗ) Служба внутрішнього ау­диту (СВА)
ФБ6	Оформлення кредитних доку­ментів	Кредитне управління (КУ) Юридичний відділ (ЮВ)
ФБ7	Розгляд кредитної справи та прий-няття рішення про надання кредиту. Оформлення протоколу засідання кредитної ради	Кредитна рада (КР)
ФБ8	Перерахування коштів із ссудного рахунку на поточний	Розрахунковий відділ (РВ)

Рисунок 4.14 – Діаграма функціонального зрізу (П - висновок для кредитної ради позитивний, Н - негативний)

Зріз даних

Таблиця 4.3 – Схема інформаційної взаємодії

Рисунок 4.15 – Фрагмент моделі ЕR-типу «сутність – відношення»

Рисунок 4.16 – Фрагмент діаграми ланцюга процесу PCD