Ідеальна еталонна модель у якій представлені основні. Властивості моделей та вимоги до них. Геометродинаміка програма розробки алгоритмів побудови аналітичних рішень рівнянь, що описують двовимірні та тривимірні рухи суцільних середовищ: моногр
Ідея управління за еталонною моделлю, запропонована в 1961 р., може бути реалізована при невеликій модифікації схеми на рис. 11.27. Ця ідея дуже вплинула на роботи з систем управління. Суть її у тому, щоб побудувати, синтезувати чи адаптувати систему, загальна імпульсна характеристика якої найкраще відповідає характеристиці еталонної моделі чи характеристиці деякої ідеальної моделі.
Припустимо, наприклад, що динамічні характеристики керування літаком суттєво відрізняються для швидкостей до звукового бар'єру та надзвукових. Щоб надати пілоту можливість адекватно керувати літаком незалежно від його швидкості, вводиться автопілот, який приймає сигнали керування пілота і приводить у дію сервомеханізми. Реакція літака на сигнали управління пілота відповідає реакції деякої еталонної моделі, яка вибирається розробником системи так, щоб забезпечити літак «почуттям керма», зручним для пілотів. Багато фізичних систем синтезуються так, що їх характеристики подібні до характеристик моделей, і багато з цих систем є адаптивними.
Реалізувати описаний підхід неважко, видозмінивши схеми на рис. 11.11 чи 11.27. Для цього потрібно просто замінити зворотну модель із затримкою на еталонну. Тоді загальна характеристика системи швидше буде подібна до характеристики еталонної моделі, ніж просто затриманому стрибку. Така модифікація схеми наведено на рис. 11.28.
У системах на рис. 11.11 та 11.27 затримка введена для забезпечення можливості точного зворотного моделювання, що відповідає низькому рівню СКО їй. За наявності затримки можна отримати хоч і затриманий, але точніший відгук. Як зазначено вище, введення затримки необхідно у тих випадках, коли є затримка реакції в керованій системі або ця система не є мінімально-фазовою. При заміні затримки на еталонну модель у разі, коли затримка потрібна для точного зворотного моделювання, зазвичай, її необхідно вводити й у еталонну модель.
Рис. 11.28. Управління із адаптивною зворотною моделлю, аналогічне рис. 11.27, але із включенням еталонної моделі
При цьому потрібно формувати таку характеристику еталонної моделі, яку можна реалізувати при послідовному включенні керованої системи та адаптивного фільтра, якщо вагові коефіцієнти цього фільтра відповідають мінімальній СКО. Схема на мал. 11.28 добре функціонує тоді, коли для адаптивної системи задаються гнучкі умови. Не слід, однак, вважати, що ця схема менш інерційна або має більш точний відгук, ніж це можливо для керованої системи та адаптивного пристрою управління з кінцевою імпульсною характеристикою.
Наприклад адаптивної системи управління із застосуванням зворотного моделювання по еталонної моделі розглянемо таку реалізацію схеми на рис. 11.28:
еталонна модель: вагових коефіцієнтів у моделі вагових коефіцієнтів у влаштуванні управління ітерацій адаптивного процесу. На рис. 11.29 показаний відгук на одиничний стрибок некомпенсованої керованої моделі, а на рис. 11.30 - відгук компенсованої системи, накладений на відгук еталонної системи. Вочевидь, що отримано дуже близьке наближення.
Для узгодження роботи пристроїв мережі від різних виробників, забезпечення взаємодії мереж, які використовують різне середовище поширення сигналу, створена еталонна модель взаємодії відкритих систем (ВОС). Еталонна модель побудована за ієрархічним принципом. Кожен рівень забезпечує сервіс вищого рівня та користується послугами нижчого рівня.
Обробка даних починається з прикладного рівня. Після цього дані проходять через всі рівні еталонної моделі, і через фізичний рівень відправляються в канал зв'язку. На прийомі відбувається зворотна обробка даних.
У еталонній моделі OSI вводяться два поняття: протоколі інтерфейс.
Протокол – це набір правил, основі яких взаємодіють рівні різних відкритих систем.
Інтерфейс – це сукупність засобів та методів взаємодії між елементами відкритої системи.
Протокол визначає правила взаємодії модулів рівня в різних вузлах, а інтерфейс – модулів сусідніх рівнів щодо одного вузлі.
Усього існує сім рівнів еталонної моделі OSI. Варто зазначити, що у реальних стеках використовується менше рівнів. Наприклад, у популярному TCP/IP використовується лише чотири рівні. Чому так? Пояснимо трохи пізніше. А зараз розглянемо кожен із семи рівнів окремо.
Рівні моделі OSI:
- фізичний рівень. Визначає вид середовища передачі даних, фізичні та електричні характеристики інтерфейсів, вид сигналу. Цей рівень має справу з бітами інформації. Приклади протоколів фізичного рівня: Ethernet, ISDN, Wi-Fi.
- Канальний рівень. Відповідає за доступ до середовища передачі, виправлення помилок, надійну передачу даних. На прийоміотримані з фізичного рівня дані упаковуються в кадри, після чого перевіряється їх цілісність. Якщо помилок немає, дані передаються на мережевий рівень. Якщо помилки є, кадр відкидається і формується запит на повторну передачу. Канальний рівень поділяється на два рівні: MAC (Media Access Control) і LLC (Locical Link Control). MAC регулює доступ до фізичного середовища, що розділяється. LLC забезпечує обслуговування мережевого рівня. На канальному рівні працюють комутатори. Приклади протоколів: Ethernet, PPP.
- Мережевий рівень. Його основними завданнями є маршрутизація – визначення оптимального шляху передачі, логічна адресація вузлів. Крім того, на цей рівень можуть бути покладені завдання пошуку несправностей в мережі (протокол ICMP). Мережевий рівень працює із пакетами. Приклади протоколів IP, ICMP, IGMP, BGP, OSPF).
- Транспортний рівень. Призначений для доставки даних без помилок, втрат та дублювання у тій послідовності, як вони були передані. Виконує наскрізний контроль передачі від відправника до одержувача. Приклади протоколів TCP, UDP.
- Сеансовий рівень. Керує створенням/підтримкою/завершенням сеансу зв'язку. Приклади протоколів: L2TP, RTCP.
- Представницький рівень. Здійснює перетворення даних у потрібну форму, шифрування/кодування, стиснення.
- Прикладний рівень. Здійснює взаємодію між користувачем та мережею. Взаємодіє з програмами на стороні клієнта. Приклади протоколів HTTP, FTP, Telnet, SSH, SNMP.
Після знайомства з стандартною моделлю, розглянемо стек протоколів TCP/IP.
У моделі TCP/IP визначено чотири рівні. Як видно з малюнку вище – один рівень TCP/IP може відповідати кільком рівням моделі OSI.
Рівні моделі TCP/IP:
- Рівень мережевих інтерфейсів. Відповідає двом нижнім рівням моделі OSI: канальному та фізичному. Виходячи з цього, зрозуміло, що даний рівень визначає характеристики середовища передачі (кручена пара, оптичне волокно, радіоефір), вид сигналу, спосіб кодування, доступ до середовища передачі, виправлення помилок, фізичну адресацію (MAC-адреси). У моделі TCP/IP цьому рівні працює протокол Ethrnet та її похідні (Fast Ethernet, Gigabit Ethernet).
- Рівень міжмережевої взаємодії. Відповідає мережевому рівню моделі OSI. Бере він всі його функції: маршрутизацію, логічну адресація (IP-адреси). На цьому рівні працює протокол IP.
- Транспортний рівень. Відповідає транспортному рівню OSI. Відповідає за доставку пакунків від джерела до одержувача. На цьому рівні використовуються два протоколи: TCP і UDP. TCP є більш надійним, ніж UDP завдяки створенню попереднього з'єднання, запитів на повторну передачу при виникненні помилок. Однак, в той же час, TCP повільніше, ніж UDP.
- Прикладний рівень. Його головне завдання – взаємодія з додатками та процесами на хостах. Приклади протоколів: HTTP, FTP, POP3, SNMP, NTP, DNS, DHCP.
Інкапсуляція – це метод упаковки пакета даних, у якому незалежні друг від друга службові заголовки пакета абстрагуються від заголовків нижчих рівнів шляхом їх включення до вищестоящих рівнів.
Розглянемо на конкретному прикладі. Нехай ми хочемо потрапити із комп'ютера на сайт. Для цього комп'ютер повинен підготувати http-запит на отримання ресурсів веб-сервера, на якому зберігається потрібна нам сторінка сайту. На прикладному рівні до даних браузера додається HTTP-заголовок. Далі на транспортному рівні до нашого пакету додається TCP-заголовок, що містить номери портів відправника та одержувача (80 порт – для HTTP). На мережному рівні формується IP-заголовок, що містить IP-адреси відправника та одержувача. Безпосередньо перед передачею, на канальному рівні додається Ethrnet-заголовок, який містить фізичні (MAC-адреси) відправника та одержувача. Після всіх цих процедур пакет у вигляді біт інформації передається по мережі. На прийомі відбувається зворотна процедура. Web-сервер на кожному рівні перевірятиме відповідний заголовок. Якщо перевірка пройшла вдало, заголовок відкидається і пакет переходить на верхній рівень. В іншому випадку, весь пакет відкидається.
Підтримайте проект
Друзі, сайт Netcloud щодня розвивається завдяки вашій підтримці. Ми плануємо запустити нові рубрики статей та деякі корисні сервіси.
У вас є можливість підтримати проект і внести будь-яку суму, яку вважаєте за потрібну.
Еталонна модель
Еталонна модель(Англ. reference model, master model) - це абстрактне уявлення понять та відносин між ними у певній проблемній галузі. На основі еталонної будуються більш конкретні та детально описані моделі, в результаті втілені в реально існуючі об'єкти та механізми. Поняття еталонної моделі використовується в інформатиці.
Приклади Еталонних моделей
- Мережева модель OSI (Open Systems Interconnection Reference Model),
- модель Відкритого геопросторового консорціуму (англ.),
- архітектура фон Неймана - модель еталонної моделі з послідовними обчисленнями,
- еталонна модель Архітектури державного підприємства (англ.),
- Еталонна інформаційна модель HL7 (Reference Information Model, RIM HL7),
- Еталонна модель (Reference Model, RM) openEHR .
Wikimedia Foundation. 2010 .
Дивитися що таке "Еталонна модель" в інших словниках:
еталонна модель- ієрархічна модель - [Л.Г.Суменко. Англо-російський словник з інформаційних технологій. М.: ДП ЦНДІС, 2003.] Тематики інформаційні технології загалом Синоніми ієрархічна модель EN reference model …
еталонна модель- etaloninis modelis statusas T sritis automatika atitikmenys: angl. master model; reference model vok. Referenzmodell, n rus. еталона модель, f pranc. modele de référence, m; modele standard, m … Automatikos terminų žodynas
еталонна модель- 3.1.41 еталонна модель (reference model): Структурований комплект взаємопов'язаних уявлень про об'єкт (наприклад, інформаційну систему), що охоплює даний об'єкт загалом, спрощує розбиття зв'язків за тематикою, що може бути… Словник-довідник термінів нормативно-технічної документації
еталонна модель ВОС- Модель взаємодії відкритих систем, розроблена ISO 1984 р. Дозволяє універсальним чином описати логіку інформаційного обміну між взаємозалежними системами та абонентами. Повна модель містить сім рівнів. На самому нижньому... Довідник технічного перекладача
еталонна модель ISO/OSI- Семирівнева еталонна модель протоколів передачі. Визначає рівні: фізичний, канальний, мережевий, транспортний, сеансовий, представницький та прикладний. У CAN мережах зазвичай реалізуються тільки фізичний, канальний та прикладний рівні. Довідник технічного перекладача
еталонна модель протоколів широкосмугової ISDN-мережі- Модель включає чотири горизонтальні рівні (фізичний, ATM, адаптації ATM і верхні рівні) і три вертикальні площини (користувача, управління та адміністрування). Відповідність між моделями В ISDN та OSI забезпечується на фізичному… Довідник технічного перекладача
еталонна модель BOC- ЕМВОС Модель, розроблена МОС, що містить сім рівнів (шарів) протоколів та призначена для комунікації між пристроями в мережі. [Е.С.Алексєєв, А.А.Мячов. Англо-російський тлумачний словник з системотехніки ЕОМ. Москва 1993] Тематики ... Довідник технічного перекладача
еталонна модель взаємодії відкритих систем- - Тематики електрозв'язок, основні поняття EN ISO/OSI reference model... Довідник технічного перекладача
еталонна модель протоколу- - [Л.Г.Суменко. Англо-російський словник з інформаційних технологій. М.: ДП ЦНДІС, 2003.] Тематики інформаційні технології загалом EN protocol reference modulePRM … Довідник технічного перекладача
еталонна модель з'єднання відкритих систем- - [Л.Г.Суменко. Англо-російський словник з інформаційних технологій. М.: ДП ЦНИИС, 2003.] Тематики інформаційні технології загалом EN reference model of open systems … Довідник технічного перекладача
Книжки
- Комп'ютерні мережі. У 2 томах. Том 1. Системи передачі даних, Р. Л. Смілянський. Наведено теоретичні основи систем передачі даних, характеристики основних видів фізичних середовищ, способи кодування та передачі аналогових та цифрових даних, основи організації.
Пропонована еталонна модель BPM (Business Process Management) ґрунтується на ланцюжку наступних передумов:
Підвищення продуктивності підприємства як складної системи потребує її раціональної побудови, а процесне управління є найсучаснішою концепцією для такої побудови;
BPM (як дисципліна) пропонує системний підхід реалізації процесного управління;
На кожному процесно-керованому підприємстві є своя BPM-система – портфоліо всіх бізнес-процесів, а також методів та інструментів для керівництва розробкою, виконання та розвитку цього портфоліо;
Гнучкість BPM-системи підприємства є основним чинником успіху;
Спеціалізована програмна платформа (BPM suite) для реалізації BPM-системи підприємства потрібна, але недостатня, тому що BPM займає особливе місце в архітектурі підприємства.
Ціль: підвищення продуктивності підприємства
Для управління своєю продуктивністю більшість підприємств використовують принцип зворотного зв'язку (рис. 1), що дозволяє адаптуватися до зовнішньої бізнес-екосистеми шляхом виконання певної послідовності дій:
Вимірювання ходу виконання виробничо-господарської діяльності (зазвичай такі виміри представлені у формі різних метрик або індикаторів, наприклад, відсоток клієнтів, що повертаються);
Виокремлення із зовнішньої бізнес-екосистеми важливих для підприємства подій (наприклад, законів або нових потреб ринку);
визначення стратегії розвитку бізнесу підприємства;
Реалізація прийнятих рішень (шляхом внесення змін до бізнес-системи підприємства).
Відповідно до класичної рекомендації Едварда Демінга, автора численних робіт у галузі управління якістю, у тому числі відомої книги «Вихід із кризи», всі удосконалення мають проводитися циклічно, безперервно та з перевіркою на кожному циклі. Ступінь і частота цих удосконалень залежить від конкретної ситуації, але рекомендується робити такі цикли досить компактними. Різні удосконалення можуть торкатися різних аспектів роботи підприємства. Питання, як підприємство може досягти найкращих результатів у кожному конкретному випадку? Існують дві об'єктивні передумови для оптимізації діяльності підприємства як єдиного цілого:
Забезпечення керівництва належною інформацією та інструментами для ухвалення рішення;
Гарантія того, що бізнес-система підприємства здатна до здійснення необхідних змін у необхідному темпі.
Найсучасніша концепція організації роботи підприємства - процесне управління, у якому процеси та служби стають явними.
Процесне керування
Світ бізнесу давно зрозумів (див. такі методики, як TQM, BPR, Six Sigma, Lean, ISO 9000 та ін.), що служби та процеси – це основа функціонування більшості підприємств. Багато підприємств використовують процесне управління для організації своєї виробничо-господарської діяльності, як портфоліо бізнес-процесів та методів управління ними.
Процесне управління, як управлінська концепція, постулює доцільність координації діяльності окремих служб підприємства з метою отримання певного результату за допомогою явно та формально визначених бізнес-процесів. У цьому служби - це операційно незалежні функціональні одиниці; підприємство може мати багато елементарних нанослужб, які організовані в мегаслужбу (власне підприємство).
Використання явного визначення координації дозволяє формалізувати взаємозалежність між службами. Наявність такої формалізації дає можливість використовувати різні методи (моделювання, автоматизована перевірка, контроль за версіями, автоматизоване виконання тощо) для покращення розуміння бізнесу (для прийняття більш правильних рішень) та підвищення швидкості розвитку бізнес-систем (для більш швидкої реалізації змін ).
Окрім процесів та служб, бізнес-системи підприємств працюють із подіями, правилами, даними, індикаторами роботи, ролями, документами тощо.
Для реалізації процесного управління підприємства використовують три популярні дисципліни постійного вдосконалення бізнес-процесів: ISO 9000, Six Sigma та «ощадливе», або «економне» виробництво (Lean production). Вони впливають на різні галузі бізнес-системи підприємства, проте завжди передбачається збір даних про фактично виконану роботу та використання певної моделі бізнес-процесів для прийняття рішень (хоча іноді ця модель знаходиться тільки в голові якоїсь). У той же час вони пропонують різні та взаємодоповнюючі методи для того, щоб визначити, які саме зміни необхідні для покращення функціонування бізнес-системи підприємства.
Що моделюєте, те й виконуєте
На рис. 2 наведено узагальнену модель процесно-керованого підприємства.
У чому основна проблема оптимізації діяльності такого підприємства? Різні частини бізнес-системи використовують різні описи одного й того самого бізнес-процесу. Зазвичай ці описи існують окремо і розроблені різними людьми, оновлюються різними темпами, не обмінюються інформацією, а деяких їх просто немає в явному вигляді. Наявність єдиного опису бізнес-процесів підприємства дозволяє усунути цей недолік. Цей опис має бути явно і формально визначено, щоб одночасно служити моделлю для моделювання, виконуваною програмою та документацією, яку легко розуміють всі залучені в бізнес-процес співробітники.
Такий опис - основа дисципліни BPM, що дозволяє моделювати, автоматизувати, виконувати, контролювати, вимірювати та оптимізувати потоки робіт, що охоплюють програмні системи, співробітників, клієнтів та партнерів у межах та поза межами підприємства. Дисципліна BPM розглядає всі операції з бізнес-процесами (моделювання, виконання тощо) як єдине ціле (рис. 3).
На даний момент у індустрії BPM ще не склалася належна система стандартів на формати формального опису бізнес-процесів. Три найбільш популярні формати: BPMN (Business Process Modelling Notation, графічне представлення моделей бізнес-процесів), BPEL ( Business Process Execution Language, формалізація виконання взаємодії між Web-сервісами) та XPDL (XML Process Description Language, www.wfmc.org, специфікація з обміну моделями бізнес-процесів між різними програмами) були розроблені різними групами і для різних цілей і, на жаль, адекватно не взаємодоповнюють один одного.
Ситуація посилюється тим, що за різними форматами стоять різні виробники і кожен намагається проштовхнути на ринок своє рішення. Як це неодноразово повторювалося, у подібній боротьбі інтереси кінцевого споживача мало беруться до уваги - сьогодні немає достатньо потужної організації, що представляє інтереси кінцевого споживача BPM (за аналогією з групою стандартів для HTML, успіх якої пояснюється прийняттям усіма розробниками Web-браузерів єдиного тесту ACID3 для порівняння своїх продуктів). Ідеальною ситуацією в BPM було б стандартне визначення семантики виконання для BPMN-подібного опису бізнес-процесів. Саме стандартна семантика виконання гарантувала б однакову інтерпретацію бізнес-процесів будь-яким програмним забезпеченням. Додатково такий опис має дозволяти адаптацію ступеня опису бізнес-процесів для потреб конкретного споживача (наприклад, користувач бачить грубу діаграму, аналітик – докладнішу тощо).
Усе це означає, що BPEL чи XPDL стануть непотрібними - їх використання приховано, як це відбувається у сфері підготовки електронних документів. Один і той самий електронний документ може одночасно існувати в XML, PDF, PostScript і т.п., але тільки один основний формат (XML) використовується для модифікації документа.
Дисципліна BPM у культурі підприємства
Окрім процесів та служб, бізнес-системи підприємства працюють з такими додатковими артефактами, як:
події(events) - явища, що відбулися в межах та поза межами підприємства, на які можлива певна реакція бізнес-системи, наприклад, при отриманні замовлення від клієнта необхідно розпочати бізнес-процес обслуговування;
об'єкти(data and documents objects) - формальні інформаційні описи реальних речей та людей, що утворюють бізнес; ця інформація на вході та виході бізнес-процесу, наприклад, бізнес-процес обслуговування замовлення отримує на вході власне формуляр замовлення та інформацію про клієнта, а на виході формує звіт про виконання замовлення;
діяльності(activities) - дрібні роботи, що перетворюють об'єкти, наприклад, автоматичні діяльності типу перевірки кредитної картки клієнта або діяльності, що здійснюються людиною, такі як візування документа керівництвом;
правила(rules) - обмеження та умови, за яких функціонує підприємство, наприклад, видача кредиту на певну суму має затверджуватись генеральним директором банку;
ролі(roles) - поняття, що представляють відповідні навички або обов'язки, які потрібні для виконання певних дій, наприклад, тільки менеджер вищої ланки може підписати конкретний документ;
аудиторські сліди(audit trails) - інформація про виконання конкретного бізнес-процесу, наприклад, хто зробив, що і з яким результатом;
основні індикатори продуктивності(Key Performance Indicator, KPI) - обмежена кількість показників, що вимірюють рівень досягнення поставлених цілей.
Рис. 4 ілюструє розподіл артефактів між різними частинами бізнес-системи підприємства. Вираз "процеси (як шаблони)" означає абстрактні описи (моделі або плани) процесів;
вираз "процеси (як екземпляри)" означає фактичні результати виконання цих шаблонів. Зазвичай шаблон використовується для створення багатьох екземплярів (подібно до незаповненого бланку, який багаторазово копіюється для заповнення різними людьми). Вираз «служби (як інтерфейси)» означає формальні описи служб, доступні їх споживачів; вираз "служби (як програми)" означає засоби виконання служб - такі засоби забезпечуються постачальниками служб.
Для успішної роботи з усією складною сукупністю взаємозалежних артефактів у будь-якого процесно-керованого підприємства є своя власна BPM-система – це портфоліо всіх бізнес-процесів підприємства, а також методів та інструментів для керівництва розробкою, виконанням та розвитком цього портфоліо. Іншими словами, BPM-система підприємства є відповідальною за синергетичне функціонування різних частин бізнес-системи підприємства.
BPM-система, як правило, не ідеальна (наприклад, деякі процеси можуть існувати лише на папері, а деякі деталі «живуть» тільки в умах певних людей), але вона існує. Наприклад, будь-яку реалізацію ISO 9000 можна як приклад BPM-системы.
Покращення BPM-системи підприємства, окрім суто технічних аспектів, має враховувати соціотехнічні питання. BPM-система підприємства має багато зацікавлених осіб, кожна з яких вирішує свої завдання, сприймає BPM-дисципліну своїм чином і працює зі своїми артефактами. Для успішного розвитку BPM-системи підприємства необхідно звернути особливу увагу на проблеми всіх зацікавлених осіб та заздалегідь пояснити їм, як покращення BPM-системи підприємства змінить їхню роботу на краще. Вкрай важливо досягти єдиного розуміння всіх артефактів серед усіх зацікавлених осіб.
Спеціалізоване ПЗ для реалізації BPM-систем
Зростання популярності та великий потенціал BPM викликали появу нового класу корпоративного ПЗ - BPM suite, або BPMS, що містить такі типові компоненти (рис. 5):
Інструмент моделювання (Process modelling tool) – графічна програма для маніпулювання такими артефактами, як події, правила, процеси, активності, служби тощо;
Інструмент тестування (Process testing tool) – середовище функціонального тестування, яке дозволяє «виконувати» процес за різними сценаріями;
Сховище шаблонів (Process template repository) - база даних шаблонів бізнес-процесів з підтримкою різних версій одного й того самого шаблону;
Виконавець процесів (Process execution engine);
Сховище екземплярів (Process instance repository) - база даних для виконуваних та вже виконаних екземплярів бізнес-процесів;
Список робіт (Work list) - інтерфейс між BPM suite та користувачем, який виконує деякі активності в рамках одного або декількох бізнес-процесів;
Приладова панель (Dashboard) – інтерфейс оперативного контролю за виконанням бізнес-процесів;
Інструмент аналізу (Process analysis tool) – середовище для вивчення тенденції виконання бізнес-процесів;
Інструмент імітаційного моделювання (Process simulation tool) – середовище для тестування продуктивності бізнес-процесів.
Необхідність взаємодії між BPM suite та корпоративним ПЗ, яке підтримує інші артефакти, викликала появу нового класу корпоративного ПЗ – Business Process Platform (BPP). Типові технології BPP (рис. 6):
Business Event Management (BEM) - аналіз бізнес-подій у режимі реального часу та запуск відповідних бізнес-процесів (BEM пов'язаний з Complex Event Processing (CEP) та Event Driven Architecture (EDA));
Business Rules Management (BRM) - явне та формальне кодування бізнес-правил, які можуть бути модифіковані користувачами;
Master Data Management (MDM) - спрощення роботи зі структурованими даними за рахунок усунення хаосу при використанні тих самих даних;
Enterprise Content Management (ECM) – управління корпоративною інформацією, призначеною для людини (узагальнення поняття документ);
Configuration Management Data Base (CMDB) - централізований опис усієї інформаційно-обчислювальної середовища підприємства, що використовується для прив'язки BPM до інформаційно-обчислювальних ресурсів підприємства;
Role-Based Access Control (RBAC) - управління доступом до інформації з метою ефективного поділу контрольних та виконавських повноважень (separation of duty);
Business Activity Monitoring (BAM) – оперативний контроль функціонування підприємства;
Business Intelligence (BI) – аналіз характеристик та тенденцій роботи підприємства;
Service-Oriented Architecture (SOA) - архітектурний стиль для побудови складних програмних систем у вигляді набору універсально доступних та взаємозалежних служб, що використовується для реалізації, виконання та управління службами;
Enterprise Service Bus (ESB) – середовище комунікацій між службами в рамках SOA.
Таким чином, дисципліна BPM здатна забезпечити єдиний, формальний та здійснений опис бізнес-процесів, який може використовуватися в різних інструментах BPM suite, причому реальні дані збираються під час виконання бізнес-процесів. Водночас висока гнучкість BPM-системи підприємства не гарантується автоматично після купівлі BPM suite або BPP - здатність конкретної BPM-системи розвинутись у необхідному темпі має проектуватися, реалізовуватися та постійно контролюватись. Як і здоров'я людини, все це не можна купити.
BPM в архітектурі підприємства
Необхідність залучення практично всього корпоративного програмного забезпечення в єдину логіку поліпшення BPM-системи підприємства порушує питання про роль та місце BPM в архітектурі підприємства (Enterprise Architecture, EA). EA є на сьогодні усталеною практикою ІТ-департаментів з упорядкування інформаційно-обчислювального середовища підприємства. В основі EA лежать такі правила:
Поточна ситуація з інформаційно-обчислювальним середовищем підприємства ретельно документується як вихідна точка as-is;
Бажана ситуація документується як кінцева точка to be;
Будується і виконується довгостроковий план щодо переведення інформаційно-обчислювального середовища підприємства з однієї точки до іншої.
Усе це, здавалося б, цілком розумно, але відразу видно різниця з підходом, що передбачає невеликі поліпшення, що є основою процесного управління. Як поєднати ці два протилежні підходи?
Дисципліна BPM може вирішити основну проблему EA – дати об'єктивну оцінку виробничо-господарських можливостей (а не лише інформаційно-обчислювальних) того, що буде у точці to-be. Незважаючи на те, що EA описує повну номенклатуру артефактів підприємства (його генотип), вона не може достовірно сказати, які зміни в цьому генотипі впливають на конкретні виробничо-господарські характеристики підприємства, тобто на фенотип підприємства (сукупність характеристик, властивих індивіду на певній стадії розвитку ).
Зі свого боку, дисципліна BPM структурує взаємозалежність між артефактами у вигляді явних та виконуваних моделей (бізнес-процес – це приклад взаємозалежності між такими артефактами, як події, ролі, правила тощо). Наявність таких моделей дозволяє з деяким ступенем достовірності оцінити виробничо-господарські характеристики підприємства при зміні генотипу підприємства.
Звичайно, чим більше взаємозалежностей між артефактами змодельовано і чим достовірніші ці моделі, тим точніше такі оцінки. Потенційно симбіоз номенклатури артефактів підприємства та формально певних взаємозалежностей між ними дає модель підприємства, що виконується, на конкретний момент часу. Якщо будувати такі моделі, що виконуються на єдиних принципах (наприклад, krislawrence.com), то з'являється можливість для порівняння ефекту від застосування різних стратегій розвитку підприємства та появи більш систематичних і передбачуваних технологій з перетворення одних виконуваних моделей в інші.
У певному сенсі комбінація EA+BPM може стати свого роду навігатором, який забезпечує керівництво та практичну допомогу у розвитку бізнесу та ІТ під час реалізації генеральної лінії підприємства.
Не секрет, що сьогодні виробники ПЗ визначають та розвивають BPM по-різному. Проте, більш перспективний шлях розвитку BPM - це BPM, орієнтований потреби кінцевих споживачів, і еталонна модель BPM - перший крок створення єдиного розуміння BPM серед усіх зацікавлених осіб.
Пропонована у статті еталонна модель заснована на практичному досвіді автора з проектування, розробки та супроводу різних корпоративних рішень. Зокрема, ця модель використовувалася для автоматизації щорічного виробництва понад 3 тис. складних електронних продуктів із середнім часом підготовки продукту у кілька років. Через війну обслуговування та розвитку цієї виробничої системи зажадали у кілька разів менше ресурсів, ніж із традиційному підході. n
Олександр Самарін ([email protected]) - корпоративний архітектор ІТ-департаменту уряду кантону Женева (Швейцарія)
Process Frameworks для BPM
Підхід до реалізації технологій управління бізнес-процесами, що спрощує впровадження BPM-систем, має на увазі чітке визначення бізнес-завдання та відповідних їй бізнес-процесів; реалізацію цих процесів терміном трохи більше трьох місяців із єдиною метою демонстрації цінності даного підходу; подальше розширення реалізації на основні бізнес-завдання. Однак головна труднощі на цьому шляху - непорозуміння та відсутність узгодженості між бізнес- та ІТ-підрозділами. Значно спростити проект впровадження та скоротити витрати дозволяють спеціалізовані референсні моделі (Process Frameworks).
Референсна модель- пакет аналітичних та програмних ресурсів, що складається з опису та рекомендацій щодо організації високорівневої структури бізнес-процесу, набору атрибутів та метрик оцінки ефективності виконання, а також програмних модулів, створених для швидкої побудови прототипу бізнес-процесу для подальшої його адаптації під специфіку конкретної компанії.
Референсні моделі допомагають у визначенні та встановленні вимог і дозволяють налагодити бізнес-процеси, вони засновані на галузевих стандартах і включають галузевий досвід. Для типових процесів референсні моделі здатні допомогти при виборі та моделюванні основних послідовностей роботи, визначенні ключових показників ефективності (КPI) та параметрів, що дозволяють оцінити результативність у ключових областях, а також при управлінні діяльністю та вирішенням завдань, аналізі вихідних причин та обробці виняткових випадків.
До структури типової референсної моделі входять: рекомендації та опис предметної галузі; елементи композитних користувальницьких інтерфейсів (екранні форми та логічно зв'язні в ланцюжку портлети); оболонки сервісів для швидкої реалізації доступу до бізнес даних; приклади типових бізнес-правил; ключові показники ефективності та елементи для їх аналізу; виконувані моделі процесів; моделі даних та атрибути процесу; адаптації до законодавчої бази та специфіки бізнесу у конкретній країні; рекомендації щодо етапів розгортання та реалізації процесів. Такий набір ресурсів дозволить швидше адаптуватися до реалізації процесного підходу в рамках конкретної системи управління бізнес-процесами, скоротити час ітерацій циклу розробки, тестового виконання та аналізу процесів. При цьому досягається максимальна відповідність технічної реалізації та існуючого бізнес-завдання.
Однак, як зазначають аналітики AMR Research, «технології та методи самі по собі не здатні забезпечити будь-які переваги – «більше» не завжди означає «краще». Деякі компанії застосовують безліч різних рішень, проте ефективність лише падає. Важливою є грамотність застосування таких технологій». У референсних моделях як основа використовуються прийняті в галузі стандарти та досвід компанії Software AG щодо створення еталонної моделі для визначення вимог клієнтів. Насправді ця модель стає відправною точкою, з допомогою якої клієнти можуть створити потрібну модель.
Process Framework, наприклад, для бізнес-процесу обробки замовлень, включає базову модель процесу зі схемами дій для різних користувачів і ролей, обрані KPI з моделі SCOR (The Supply-Chain Operations Reference-model) для процесу в цілому і окремих етапів, правила підтримки різних послідовностей обробки, наприклад, з урахуванням сегмента клієнтів, цільові показники для різних сегментів клієнтів, типів продукції та регіонів, а також панелі індикації, що допомагають контролювати особливі ситуації.
Process Framework дозволяє акцентувати увагу на необхідності та можливості корекції KPI для конкретних груп клієнтів та їх конфігурування з урахуванням появи нових товарів, виходу на нові регіони чи сегменти ринку. Подібна інформація дозволить керівникам, які відповідають за ланцюжки поставок, торгові операції, логістику та виробництво, покращити контроль над конкретною діяльністю, а керівникам ІТ-відділів швидко оцінити реальну працездатність ІТ-систем, що підтримують обробку замовлень.
Володимир Оленцов ([email protected]) - консультант з BPM та SOA, представництво Software AG в Росії таСНД (Москва).
Первинне уявлення про професіограму тієї чи іншої професії дає її структурний зміст. В описані професіограми професій, що включають наступні розділи - загальна характеристика професії, її значення; опис трудового процесу, виконувані роботи; вимоги професії до особи; умови праці; необхідні знання; необхідні вміння та навички; де можна здобути спеціальність; економічні умови праці
Існує і професійний метод вивчення особистості та діяльності сучасного вчителя.
Професіограма – це ідеальна модель вчителя, викладача, класного керівника, педагога, зразок, еталон, в якому представлені:
Основні якості особистості, якими повинен мати вчитель;
Знання, вміння, навички до виконання функцій вчителя.
Виходячи з цього розуміння сенсу поняття «професіограма», можна говорити і про професійний метод вивчення особистості, при якому здійснюється порівняння наявних у педагога знань, умінь та навичок з тими, які могли б у нього бути відповідно до ідеальної моделі. Не важко уявити, що такий метод дозволяє проектувати особистісне та професійне зростання педагога.
Разом про те професіограма вчителя - документ, у якому дана повна кваліфікаційна характеристика вчителя з позицій вимог, що висуваються для його знань, умінь і навичок, для його особистості, здібностям, психофізіологічним можливостям і рівня підготовки .
Таке уявлення про професіограму складалося попередні десятиліття. Так, можна говорити про професіограму класного керівника, складену Н. І. Болдирєвим.
Н. І. Болдирєв виділив пріоритетні якості особистості класного керівника: ідейність, моральну та громадянську зрілість, суспільну активність, захопленість професією вихователя, любов до дітей, гуманне, дбайливе ставлення до них, високу вимогливість до себе та учнів, комунікативність, дружбу у спілкуванні, психологічну сумісність коїться з іншими членами педагогічного колективу та інші, необхідні ідеальному спеціалісту.
Для виконання великої різноманітності функцій вчителю, на думку Н. І. Болдирєва, необхідні такі вміння:
встановлювати ділові відносини з адміністрацією школи, з батьками, громадськістю (вміння спілкування, за сьогоднішніми уявленнями, близькі до комунікативних);
інформаційні вміння та навички;
вміння яскраво, виразно, логічно викладати свої думки (за сьогоднішніми уявленнями – дидактичні та мовні);
вміння переконати, залучити до себе, зробити своїм прихильником (за сьогоднішніми уявленнями – дидактичні, комунікативні).
Для реалізації даних умінь необхідно створити високий емоційний настрій, забезпечити діловий життя, праці.
Немаловажну роль Н. І. Болдирєв відводив якостям особистості, які крім пріоритетних непогано було б мати вчителю (класному керівнику): такт, витримка, самовладання, спостережливість, щирість, винахідливість, твердість, послідовність у словах і діях, акуратність, зовнішня .
Класному керівнику важливо знати основи теорії та методики виховання, вміти:
працювати з батьками (громадськістю); планувати виховну роботу;
відбирати на основі діагностики колективів (груп), окремих осіб необхідні види діяльності;
правильно враховувати та оцінювати результати виховання; виявляти та організовувати актив;
здійснювати контроль та допомогу у виконанні доручень.
Для виконання складних та різноманітних функцій педагогу добре було б опанувати деякі прикладні творчі художні вміння:
малювати (образотворчі);
грати на музичних інструментах, співати (музичні); виразно читати (художньо-літературні); танцювати (хореографічні);
ходити у походи (спортивно-туристські чи спортивно-трудові).
А. С. Макаренко у вступному слові до «Книги для батьків» написав: «Уміння виховувати – це все-таки мистецтво, таке ж мистецтво, як добре грати на скрипці чи роялі, добре писати картини, бути хорошим фрезерувальником чи токарем».
Якщо йти від функціонального принципу, тобто від тих дій функцій, які повинен виконувати педагог, то можна перерахувати функції вчителя. Так, одними з перших (1971 року) виділили вісім функцій вчителя в школі А. І. Щербаков, Н. А. Риков. Їм належить така класифікація функцій вчителя:
Інформаційна (вчитель транслює ту чи іншу інформацію);
Розвиваюча (розвиває мислення, уяву, ті чи інші вміння, мова тощо);
орієнтує (орієнтує у різноманітті інформації, моральних цінностях);
мобілізаційна (мобілізує виконання вправ, завдань, справ);
конструююча (конструює урок, позакласну справу, різнорівневі завдання, самостійні роботи, спілкування та багато іншого);
комунікативна (функція спілкування з батьками, іншими вчителями, адміністрацією, психологами, валеологами та ін.);
організаційна (організує учнів, інших вчителів, батьків, себе, а також організовує уроки, позакласні справи, які проводить);
дослідницька (уміє досліджувати як окрему особистість, групу учнів - колектив, так і навченість та вихованість учнів тощо).
Згадка останньої функції, на наш погляд, дозволяє говорити про функції не тільки вчителя, а й педагога - у широкому значенні слова.
У підручниках педагогіки минулих років автори виділяють функції вихователя, класного керівника:
організаційну (організує всі виховні впливи та взаємодії у колективах, у тому числі у вигляді виховних справ - екскурсії, поїздки, збори, класний годинник, анкетування як дослідження тощо);
виховну (внаслідок якої різними шляхами та засобами здійснюється виховання, формування та розвиток якостей особистості, властивих учню як члену дитячого колективу, сім'янину, громадянину Росії, громадянину Миру, творчої особистості та індивідуальності);
стимулюючу (в результаті якої здійснюється стимулююча діяльність учнів, дитячого колективу, батьків, громадськості тощо);
координаційну (внаслідок якої здійснюється координація діяльності як дітей, коли це необхідно, так і вчителів, що працюють в одному класі, паралелі, а також може здійснюватися зв'язок із зовнішнім світом, якщо освітня установа розглядається як відкрита система;
роботу з документами (журналами, щоденниками учнів, їх особистими справами, різними планами).
Функцій, які мають виконувати вчителі, вихователі, класні керівники досить багато. Якими ж знаннями та вміннями вони повинні для цього мати? Уявлення про вміння та навички, якими повинні мати і вчителі, і класні керівники, дає поняття професіограми, розглянуте нами вище. Однак просто знань та вмінь, про які говорилося раніше, недостатньо. Як вважають психологи, багато залежить від природних передумов, задатків особистості (які можуть розвинутись у ті чи інші здібності), від психологічної готовності особистості, її прагнення (бажання) добре виконувати дані функції. Багато чого виховується, виробляється лише результаті тривалої роботи з себе; головне у самовихованні - терпіння і контроль над своєю поведінкою.
Психолог В. А. Крутецький у підручнику «Психологія» пропонує структуру професійно-значимих якостей особистості та вмінь, які необхідно мати вчителю. Якщо професійно-значущі якості особистості вчителя ми за В. А. Крутецким представимо як сукупності чотирьох блоків (частин чи підструктур) (1. Світогляд особи; 2. Позитивне ставлення до педагогічної діяльності; 3. Педагогічні здібності; 4. Професійно-педагогічні знання, вміння та навички), то отримаємо досить цілісне уявлення про ті вимоги, які пред'являються до професії вчителя та інших педагогічних професій.
Розглянемо ці блоки професійно значущі якості особистості вчителя докладніше.
1-й блок. Гуманістичне світогляд (мова йде про ті переконання, ідеали, які притаманні вчителю-вихователю; виховує лише той, хто сам вихований; бажано, щоб вихователь мав високий рівень загальної культури та високий моральний образ, а головне - любив би інших людей).
2-й блок. Позитивне ставлення до педагогічної діяльності (йдеться про педагогічну спрямованість особистості, педагогічні схильності як стійке бажання і прагнення присвятити себе педагогічній діяльності; не може бути добрим учителем той, хто байдуже ставиться до своєї роботи; діти безпомилково визначають тих вчителів, які їх не люблять або не люблять педагогічну діяльність загалом).
3-й блок. Педагогічні здібності (ґрунтуючись на природних передумовах, вони за певних умов реалізуються – чи ні – у професійно-педагогічні знання, уміння, навички, інакше кажучи – педагогічні здібності) – це узагальнена сукупність індивідуально-психологічних особливостей та професійно-значущих якостей особистості, які відповідають вимогам педагогічної діяльності, що забезпечують досягнення у ній високих результатів, визначають успіх педагога загалом у оволодінні цією діяльністю (докладніше див. у гл. 1).
4-й блок. Професійно-педагогічні знання, уміння, навички (йдеться про знання в галузі предмета, що викладається, і технології навчання).
В. А. Сухомлинський згадує про чотири ознаки педагогічної культури. Стисло його думки можна висловити так. Необхідно: 1) щоб у педагога були академічні знання, щоб можна було звернутися до розуму та серця вихованця; 2) щоб педагог читав літературу (педагогічну, психологічну, публіцистичну тощо); 3) щоб педагог знав багатство методів вивчення; 4) володів мовленнєвою культурою.
Отже, фахівці вважають, що хороші передумови для того, щоб стати педагогом, мають ті, хто.