І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 31

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

Бізнес-процеси розділяють на головні й деталізовані; основні та допоміжні.

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

Деталізовані процеси мають узагальнюючий характер і можуть застосовуватися в багатьох секторах.

Основні процеси - це ті процеси, які додають нової якості продукції.

Допоміжні процеси формують інфраструктуру організації.

13.3.5. Модель правил

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

1.   Правила цілісності моделі організації.

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

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

Приклад.

Якщо є варіант бізнес-функції "Пряме постачання", то в моделі повинні бути представлені бізнес-функції "Обробка замовлення на придбання" і "Обробка замовлення на збут".

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

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

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

3.   Правила конфігурації (встановлення параметрів).

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

Приклад.

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

4.   Правила встановлення статичних умов.

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

Приклад.Якщо функція "Оформлення акредитива" не використовується у фазі впровадження, то гілка "Оформлення акредитива" забороняється і зображується в затемненому вигляді

13.3.6. Моделі об'єктів (даних)

 

У модельно-орієнтованій технології проектування ІС інтегрування різних бізнес-процесів (прикладних програм) здійснюється на основі біз-нес-об'єктів. Відповідно до визначення комітету Business Object Task Force OMG бізнес-об'єкти - це компоненти рівня предметної області, що використовуються в різних додатках у довільних комбінаціях і не залежать від них. При цьому додаток забезпечує середовище для функціонування бізнес-об'єктів. З одного боку, бізнес-об'єкти - це об'єкти-сутності в нотації UML, наприклад замовлення, рахунки, матеріали, постачальники і т. д. З іншого боку, на відміну від звичайних об'єктів-сутностей бізнес-об'єкти є самодостатніми, тобто мають стандартний інтерфейс, написаний мовою опису інтерфейсів IDL (Interface Definition Language), за допомогою якого бізнес-об'єкти можуть взаємодіяти один з одним через об'єктну шину - брокер об'єктних запитів (Object Re­quest Broker). Таким чином, бізнес-об'єкти мають більш складну внутрішню структуру порівняно з простими об'єктами.

 

13.3.7. Модель організаційної структури

 

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

Модель організаційної структури має таке призначення:

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

одержати уявлення про зміни в структурі підрозділів підприємства залежно від розташування їх у загальній системі і задокументувати їх;

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

модель організаційної структури складається з ряду організаційних

компонентів. Ці організаційні компоненти можна пов'язати з ім'ям, типом і

атрибутами;

між організаційними компонентами можуть бути встановлені функціональні відносини. З такими функціональними відносинами можна пов'язати текст;

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

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

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

Структура персоналу може бути описана на наступних рівнях:

на абстрактному рівні за допомогою опису ролей;

на конкретному рівні - зіставленням працівників і організаційних одиниць.

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

Розрізняють два типи ролей:

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

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

Обов'язок становить певне завдання, за допомогою якого специфі­кується роль (тобто функція, виконувана групою працівників), наприклад: "Консультування"; "Інформування"; "Ухвалення рішення"; "Виконання";"Контроль виконання".

З роботою може бути пов'язано не більше шести ролей. Для кожної ролі можна задати не більше шести обов'язків.

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


За допомогою інструмента BEW у моделі бізнес-процесу явно вказується закріплення автоматизованих функцій за організаційними одиницями: підрозділами або посадами (рис. 63).

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

Під час призначення роботи конкретному працівнику завжди здійснюється перевірка ролі, яку він може виконувати. Якщо при цьому тип конкретного працівника не відповідає ролі, то останній не одержує доступу до виконання.
Умовні позначення:

ВДВ - виробничо-диспетчерський відділ;

ВМТП - відділ матеріально-технічного постачання;

ВЗ - відділ збуту.13.3.8. Технологія модельно-орієнтованого проектування

 

Складність типової інформаційної системи обумовлює характерні риси типового модельно-орієнтованого проектування. До них можна віднести наступні особливості:

прив'язка типової ІС до умов конкретної організації здійснюється спіль­ними зусиллями фірми-виробника програмного продукту і проектної групи підприємства;

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

зростає роль керівника підприємства в організації і контролі за створенням ІС.

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

Технологія модельно-орієнтованого проектування включає чотири основні етапи:

вибір типового проекту;

розробку проектної моделі організації;

реалізацію проекту;

введення в експлуатацію і підтримку функціонування.

На всіх етапах використовується інструментарій моделювання предметної області організації. Слід розглянути далі докладно етапи модельно-орієнтованого проектування.

1. Вибір типової ІС - аналіз вимог.

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

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

Організація, що впроваджує типову інформаційну систему, прагне вибрати найкращий програмний продукт, що відповідає конкретним умовам. Тому на етапі вибору типового проекту в конкурсі може брати участь кілька фірм-конкурентів, програмні продукти не тільки оцінюються за методикою, розглянутою в п. 13.2.2, але й з позиції реалізації запропонованої моделі підприємства. У результаті аналізу вимог вибирається конкретна типова ІС.

2.   Розробка проектної моделі організації.

Для модельно-орієнтованої технології проектування ІС характерна прив'язка моделі організації до функціональності типової ІС, на основі якої надалі автоматично виконується конфігурація інформаційної системи. Тому на вході задається попередня модель організації, референтна модель фун­кціональності типової ІС і бізнес-правила відображення моделі, а на виході формується проектна модель підприємства, у якій визначаються компоненти типової ІС, компоненти інших програмних продуктів і компоненти, що повинні бути спеціально розроблені за допомогою інструментальних засобів, наприклад АВАР/4 (SAP), чи набори інструментів Tools (BAAN).

У процесі розробки проектної моделі підприємства виконуються наступні роботи:

інсталяція програмного продукту, що реалізує типову ІС; проведення навчання проектної команди;

прив'язка моделі підприємства до компонентів типової інформаційної системи;

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

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

Реалізація типового проекту передбачає встановлення наступних па­раметрів:

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

Під час завершення стадії реалізації здійснюється комплексне тестування усіх компонентів ІС.

4. Введення в експлуатацію і підтримка функціонування.

Введення в експлуатацію типового проекту здійснюється поетапно відповідно до визначеного плану. Перед початком експлуатації повинні бути виконані наступні роботи:

створення документації кінцевих користувачів і їх навчання;

встановлення програмно-технічного середовища експлуатації ІС;

наповнення інформацією нових БД або підключення і конвертація наявних БД.

У процесі експлуатації здійснюється системна підтримка для усунення виниклих зауважень. Особливу увагу приділяють розвитку проекту ІС. Для цього система повинна накопичувати статистику про характер функціонування ІС, на основі якої провадиться технологічне налагодження ефективності експлуатації ІС. Важливо також здійснювати аналіз ефективності організації за допомогою інформаційної системи бізнес-процесів на основі контролінгу економічних показників, який призводить до безперервного вдосконалення проектної моделі підприємства і до адаптації ІС до необхідних змін.

 

Контрольні запитання

1.    Що таке типове проектне рішення?

2.    Які виділяють методи типового проектування?

3.    Що є типовим елементом при елементному методі проектування?

4.    Охарактеризуйте склад ТПР для завдання.

5.    Назвіть переваги, недоліки і область застосування елементного методу проектування.

6.    Назвіть переваги і недоліки підсистемного методу проектування.

7.    Наведіть приклади функціональних ППП.

8.    Які вимоги висуваються до типових проектів?

9.    Що є типовим елементом за об'єктного методу проектування?

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки