Популярність
Ступінь автоматизації
04.09.2007.
Поняття реінжинірингу бізнес-процесів (РБП)
1.РБП - новий напрямок теорії менеджменту.
2.Понятие реінжинірингу бізнесу.
3.Поняття бізнес-процесу.
1.РБП - новий напрямок теорії менеджменту.
Основні програми підприємства в основному сьогодні базуються на принципах, що випливають з теорії А. Сміта: від працівника потрібна висока кваліфікація, вміння виконувати роботу на основі завдань (одного або декілька). Однак ці принципи не відповідають вимогам часу, тому що продукція перестає бути масовою, орієнтується на вузькі групи споживачів. При цьому працівники повинні бути високо кваліфікованим, дуже відповідальним і відповідальність з нього питається (прораховується завдав працівник збиток / створив прибуток). Іде конкуренція за споживача. За останні 10 років світ, в якому живуть підприємці сильно змінився:
-Клієнти в цивілізованому світі взяли в свої руки контроль на ринку;
-Боротьба за клієнта відмела поняття «клієнт взагалі» на поняття «саме цей клієнт» (як вирішувати цю проблему).
-У клієнтів сформувалися нові очікування щодо пропонованих їм товарів і послуг: повна орієнтація на потреби клієнта, поставка товарів зручна для клієнта, постачання товарів в точний час зручний для клієнта і їм назване (!) Найбільш істотним організація управління можлива тільки з використанням ІТ. Для створення таких систем необхідно зрозуміти інжиніринг бізнесу, його найголовніше напрямок реінжиніринг і після цього розробляти системи. В основу покласти синхронізацію виробництва до потреб споживача. Інжиніринг - це побудова підприємства на принципах інженерної справи.
Інжиніринг бізнесу - набір прийомів і методів, які компанія використовує для проектування бізнесу у відповідності зі своїми цілями. Необхідність його проведення можна пояснити наступним чином. Найбільш фундаментальна рушійна сила компанії - потреба у поліпшенні фінансового становища. Щоб вижити в сучасних умовах будь-яка фірма повинна пристосовуватися до змінюється оточенню. Для цього мало видавати вказівки. Тут потрібен інжиніринг бізнесу, який дозволяє постійно відстежувати зміни в зовнішніх ознаках. Компанія весь час повинна змінюватися. При цьому не поступатися суперникові, знаходити свободу дій в рамках деякого «кістяка» - бізнес-процесу, орієнтованого на клієнта. Інжиніринг базується на багатьох методиках. Ці методики включають покрокові процедури проектування бізнесу, систему позначень (мова), що описує проектування бізнесу, евристики і прагматичні рішення, що дозволяють виміряти ступінь відповідності спроектованого бізнесу заданим цілям. Практично інжиніринг - це новий спосіб мислення, орієнтований на побудову компанії як інженерної діяльності. Його об'єктами є процеси, а не компанія. Компанія виробляє реінжиніринг не відділень та продажу, компанія здійснює реінжиніринг роботи. Хаммер пропонує фундаментальне переосмислення і радикальне перепроектування ділових процесів для досягнення різких стрибкоподібних досягнень у вирішальних сучасних показниках діяльності компанії.
Фундаментальний:
-Чому компанія робить те, що вона робить;
-Чому компанія робить те, що вона робить в такий спосіб;
-Якою хоче стати компанія.
Радикальний:
-Перепроектування всього процесу. (Відкидаються всі існуючі структури і процедури та пропонується зовсім інший спосіб роботи). Реінжиніринг - винахід, а не поліпшення існуючого способу роботи.
Різкий - підвищення ефективності не на відсотки - це кратність (в 10, в 20 ...). Проведення реінжинірингу необхідно, якщо необхідно різко поліпшити своє становище. Реінжиніринг слід проводити:
-Якщо компанія знаходиться на грані краху; (ціни вище, ніж у конкурента, клієнти йдуть, якість помітно нижче);
-Якщо компанія знаходиться в скрутному становищі;
-Ця компанія лідери (не відчувають труднощів і страхів).
2.Понятие реінжинірингу бізнесу.
В даний час поняття бізнес-процесу пов'язують з виконанням конкретних завдань, робіт, структур, людьми.
Бізнес процес - це безліч внутрішніх кроків діяльності, що починається з одного або більше входів і закінчуються створенням продукції, необхідної клієнту. Призначення кожного бізнес-процесу полягає в тому, щоб запропонувати клієнтові товар або послугу, що б його вартості, довговічності, сервісу і якості. Термін клієнт слід розуміти в широкому сенсі - це може бути дійсно просто клієнт, а може бути й інший процес, що протікає в зовнішньому оточенні компанії (у партнерів, субпідрядників). Різниця між структурою підрозділу і процесом здійснення діяльності полягає в тому, що структурна ієрархія має ім'я процес-ні. При цьому у традиційній структурі увага фіксується на завданнях, роботах, а не на самих процесах. Процес - це специфічно упорядкована сукупність робіт і завдань у часі і просторі із завданням початку і кінця і точним визначенням входів і виходів. Хаммер рекомендує називати процеси так: (за початковим і кінцевим статусам) Розробка продукту: від вимог на продукт - до продукту. Продаж від заявки до замовлення. Це дозволяє відокремити процеси від підрозділів. По суті справи рекомендується для назви процесів використовувати віддієслівні форми.
/ / На практиці за своєю тематикою дати назву завдань.
Для того, щоб правильно налагодити бізнес-процес, пропонується їх ділити на процеси зовнішні (преценденти) і внутрішні. Концентрація організації на процесах, які виробляють цінності, дозволяє найкращим способом виконувати те, що повинно бути зроблено фірмою. При аналізі бізнесу, виявиться багато робіт і завдань, не орієнтованих на цілі фірми.
Приклади успішного реінжинірингу. (Досвід ЕОМ-креіт)
Займається кредитуванням клієнтів. Проблема філії була в тому, що при існуючому технологічному циклі, вирішення питання про кредитування клієнта займало в середньому 6 днів, а в складних випадках до 2 тижнів. Таке тривале оформлення кредитів призводило до втрати клієнтів. Втрата клієнта впливала на джерела фінансування. Крім того компанія при існуючій технології не могла відповісти на питання клієнта «на якому кроці обробки знаходиться його запит і коли буде дано відповідь. Тривалість диктувалася наступним - треба було здійснити 5 кроків в деякій послідовності в 5 різних підрозділах компанії. При цьому передача рішення одного підрозділу іншому здійснювалася в паперовому вигляді. Компанія зробила спробу вирішити проблему через реінжиніринг.
Дії:
-Аналіз поточного стану справ;
-Порядок завершення кожного кроку;
-Після рішучих роздумів два старших менеджера фірми вирішили самі спробувати оформити всі 5 кроків. При цьому виявилося, що на обробку запиту витрачається 90 хвилин, а решту часу витрачалося на передачу запитів. Фірма об'єднала всі кроки і підпорядкувала одному спеціалісту.
Умови успішного реінжинірингу.
1.Фактори успіху.
2.Тіпічние помилки при проведенні реінжинірингу.
1.Фактори успіху.
Досвід впровадження принципів реінжинірингу показав, що 50% впровадження принципів реінжинірингу закінчувалися невдачею. Для того, щоб з'ясувати причини цих невдач 40 фірм зазнали вченими обстеженню і були виявлені недоліки і фактори успіху.
До факторів успіху відносяться:
1.Мотівація - мотив повинен бути ясний і зафіксовано, керівництво має вірити заздалегідь в його успіх, керівництво повинно розуміти, що структура повинна змінюватися, виникнуть проблеми з трудовими ресурсами. Вірячи в необхідність реінжинірингу керівництво має визначити кращі сили на підприємстві та створити команду реінжинірингу.
2.Руководство. Проект повинен виконуватися під управлінням керівництва компанії. Керівник повинен мати великий авторитет серед робітників. Взяти на себе відповідальність. Доведено - ймовірність успіху вище у тих компаній, які реалістично оцінюють очікувані результати. Дуже важливо твердо й уміло управляти командою з реінжинірингу. До реінжинірингу керівник повинен дати собі звіт про ті труднощі, які його чекають, про те, що на нього будуть тиснути стара система, зуміти переконати, що проект необхідний.
3.Сотруднікі.
За Віллору співробітники діляться на 3 категорії:
1. «Тигри» - молоді кар'єристи, працюють з ентузіазмом у проекті, уміють концентруватися на нових завданнях іноді на шкоду думки інших.
2. «Осли» - співробітники, що досягли якихось цілей своєї кар'єри, ті, що бажають спокійно в роботі, стабільності, туго сприймають нове.
3. «Акули» - ті, які розробили процедури, інструкції для керування операції компанії, мають реальну силу в компанії, але тим не менш можуть створювати величезні проблеми шляхом саботування реальних змін у компанії.
У компанії беруться люди, які можуть приймати нові завдання, вірять у реінжиніринг і можуть добиватися певних успіхів (тигри).
4.Понятность.
Нові задачі в компанії повинні бути зрозуміло сформульовані.
Успіх залежить від того, як рядові співробітники і керівництво розуміють ті методи, які вони хочуть використовувати для успіху.
5.Бюджет.
6.Фокусірованіе над більш престижних цілях.
Чітке визначення ролей та обов'язків.
7.Осязаемие результати.
Повинні бути представлені конкретні результати.
8.Технологіческая підтримка.
Повинно бути сучасне ПЗ.
9.Консультація.
Консультація повинна виконувати не керуючу, а підтримуючу роль.
2.Тіпічние помилки при проведенні реінжинірингу.
1.Крах проекту може настати, якщо відповідальний за проект має не високий посадовий ранг.
2.Якщо команда зайво концентрується на технологічних питаннях.
3.Якщо менеджери думають «зробіть це для мене», а самі при цьому не беруть участі в цьому процесі.
4.Ріск, пов'язаний зі зміною процесу.
5.Ріск, пов'язаний з використанням самої технології.
6.Компанія намагається поліпшити існуючий процес замість того, щоб його перепроектувати.
7.Компанія не концентрується на бізнес-процесах.
8.Компанія концентрується тільки на проектуванні процесів, ігноруючи все інше.
Недооцінка ролі цінностей і переконань виконавців.
Згода задовольнятися малим.
Передчасне завершення реінжинірингу.
Обмежена постановка задачі.
Існуюча корпоративна структура і прийняті в компанії принципи можуть перешкоджати реінжинірингу.
Спроба здійснити реінжиніринг знизу-вверх.
Не можна призначати відповідальним менеджера, що не розуміє що таке реінжиніринг.
Компанія розробляє відразу кілька проектів з реінжинірингу.
Не можна проводити реінжиніринг перед зміною керівництва.
Не можна проводити реінжиніринг розтягнуто.
Що не є реинжинирингом:
-Використання нового ПЗ;
-Дрібна реконструкція і дрібні поліпшення;
-Вирівнювання цілей компанії;
11.09.2007.
Вплив реінжинірингу на об'єкт господарювання
1.Совершенствованіе бізнесу на основі реінжинірингу і роль ІТ в ньому.
2.Особенности перепроектування бізнес-процесів.
3.Ресультати реінжинірингу бізнес-процесів (РБП).
4.Отлічае традиційної і нової структури компанії.
1.Совершенствованіе бізнесу на основі реінжинірингу і роль ІТ в ньому.
Інжиніринг бізнесу = реінжиніринг бізнесу + удосконалення бізнесу.
Якщо реінжиніринг проводиться один раз, то удосконалення робиться постійно.
Різниця між удосконаленням та реинжинирингом бізнесу.
Будь-реінжиніринг проходить 4 етапи:
1.Розробка образу майбутньої компанії.
На цьому етапі проектується картина того, як слід розвивати бізнес, щоб досягти стратегічних цілей.
2.Аналіз-етап існуючого бізнесу.
Проводиться дослідження компанії і складається схема її функціонування в даний момент і називається ця схема «як є».
3.Розробка нового бізнесу.
Розглядається зміна процесів і підтримуюча їх інформаційна система.
Виконується Прототипування і тестування нових процесів.
4.Внедреніе нового бізнесу.
РБП пройшов деякі періоди.
1. 1990-1993 - удосконалення програми: управління якістю, функціонально-вартісної аналіз, виробництво «саме вчасно»
2. 1004-1996 - більшість бізнес процесів охоплюється реинжинирингом. Ефективність роботи компанії зростає в рази.
3. 1996 - до цього дня. - Глобальний період. На цьому етапі механізм реінжинірингу зобов'язаний забезпечити постійний перегляд БП, бізнес-стратегій, відповідно до змін в навколишньому світі.
У всьому цьому велика роль ІТ. (Хаммер, Чемпер).
1.Компанія, яка не може змінювати своє мислення з дедуктивного на індуктивне не готовий на проведення реінжинірингу.
2.Компанія, яка ставить знак рівності між технологією і автоматизацією.
3.Компанія, яка спочатку шукає проблеми, а потім для їх вирішення підшукує технології.
Реінжиніринг використовує індуктивне мислення, тобто спочатку розглянути ефективне мислення, а потім шукати проблеми, які воно може вирішити.
Основна помилка більшості компаній у тому, що на даному етапі вони розглядають ІТ через призму існуючих процесів. Вони формулюють проблему таким чином: як використовують нові технології, що б поліпшити те, що ми зараз робимо. Однак виявляється, що просте накладання ІТ на існуючі процеси не призводить до істинної трансформації бізнесу. І навіть навпаки може блокувати процес перебудови, зберігши колишні способи. Компанія повинна формулювати проблему інакше «як за допомогою нової технології робити те, що ми ще не робили».
Реінжиніринг - використання останніх інформаційних технологій для досягнення зовсім нових ділових цілей.
Нові інформаційні технології, що змінюють правила роботи компанії.
В даний час місія інформаційних технологій змішується від обслуговуючих функцій до формування основ конкурентоспроможності компанії, тобто інформаційна технологія стає частиною життя компанії.
Інформаційні технології повинні припускати наступне:
1.Всегда містити в собі досягнуті переваги в бізнесі, а так само «нові» проривні рішення.
2.Распространять наявні переваги (контролінг). Ступінь автоматизації
04.09.2007.
Поняття реінжинірингу бізнес-процесів (РБП)
1.РБП - новий напрямок теорії менеджменту.
2.Понятие реінжинірингу бізнесу.
3.Поняття бізнес-процесу.
1.РБП - новий напрямок теорії менеджменту.
Основні програми підприємства в основному сьогодні базуються на принципах, що випливають з теорії А. Сміта: від працівника потрібна висока кваліфікація, вміння виконувати роботу на основі завдань (одного або декілька). Однак ці принципи не відповідають вимогам часу, тому що продукція перестає бути масовою, орієнтується на вузькі групи споживачів. При цьому працівники повинні бути високо кваліфікованим, дуже відповідальним і відповідальність з нього питається (прораховується завдав працівник збиток / створив прибуток). Іде конкуренція за споживача. За останні 10 років світ, в якому живуть підприємці сильно змінився:
-Клієнти в цивілізованому світі взяли в свої руки контроль на ринку;
-Боротьба за клієнта відмела поняття «клієнт взагалі» на поняття «саме цей клієнт» (як вирішувати цю проблему).
-У клієнтів сформувалися нові очікування щодо пропонованих їм товарів і послуг: повна орієнтація на потреби клієнта, поставка товарів зручна для клієнта, постачання товарів в точний час зручний для клієнта і їм назване (!) Найбільш істотним організація управління можлива тільки з використанням ІТ. Для створення таких систем необхідно зрозуміти інжиніринг бізнесу, його найголовніше напрямок реінжиніринг і після цього розробляти системи. В основу покласти синхронізацію виробництва до потреб споживача. Інжиніринг - це побудова підприємства на принципах інженерної справи.
Інжиніринг бізнесу - набір прийомів і методів, які компанія використовує для проектування бізнесу у відповідності зі своїми цілями. Необхідність його проведення можна пояснити наступним чином. Найбільш фундаментальна рушійна сила компанії - потреба у поліпшенні фінансового становища. Щоб вижити в сучасних умовах будь-яка фірма повинна пристосовуватися до змінюється оточенню. Для цього мало видавати вказівки. Тут потрібен інжиніринг бізнесу, який дозволяє постійно відстежувати зміни в зовнішніх ознаках. Компанія весь час повинна змінюватися. При цьому не поступатися суперникові, знаходити свободу дій в рамках деякого «кістяка» - бізнес-процесу, орієнтованого на клієнта. Інжиніринг базується на багатьох методиках. Ці методики включають покрокові процедури проектування бізнесу, систему позначень (мова), що описує проектування бізнесу, евристики і прагматичні рішення, що дозволяють виміряти ступінь відповідності спроектованого бізнесу заданим цілям. Практично інжиніринг - це новий спосіб мислення, орієнтований на побудову компанії як інженерної діяльності. Його об'єктами є процеси, а не компанія. Компанія виробляє реінжиніринг не відділень та продажу, компанія здійснює реінжиніринг роботи. Хаммер пропонує фундаментальне переосмислення і радикальне перепроектування ділових процесів для досягнення різких стрибкоподібних досягнень у вирішальних сучасних показниках діяльності компанії.
Фундаментальний:
-Чому компанія робить те, що вона робить;
-Чому компанія робить те, що вона робить в такий спосіб;
-Якою хоче стати компанія.
Радикальний:
-Перепроектування всього процесу. (Відкидаються всі існуючі структури і процедури та пропонується зовсім інший спосіб роботи). Реінжиніринг - винахід, а не поліпшення існуючого способу роботи.
Різкий - підвищення ефективності не на відсотки - це кратність (в 10, в 20 ...). Проведення реінжинірингу необхідно, якщо необхідно різко поліпшити своє становище. Реінжиніринг слід проводити:
-Якщо компанія знаходиться на грані краху; (ціни вище, ніж у конкурента, клієнти йдуть, якість помітно нижче);
-Якщо компанія знаходиться в скрутному становищі;
-Ця компанія лідери (не відчувають труднощів і страхів).
2.Понятие реінжинірингу бізнесу.
В даний час поняття бізнес-процесу пов'язують з виконанням конкретних завдань, робіт, структур, людьми.
Бізнес процес - це безліч внутрішніх кроків діяльності, що починається з одного або більше входів і закінчуються створенням продукції, необхідної клієнту. Призначення кожного бізнес-процесу полягає в тому, щоб запропонувати клієнтові товар або послугу, що б його вартості, довговічності, сервісу і якості. Термін клієнт слід розуміти в широкому сенсі - це може бути дійсно просто клієнт, а може бути й інший процес, що протікає в зовнішньому оточенні компанії (у партнерів, субпідрядників). Різниця між структурою підрозділу і процесом здійснення діяльності полягає в тому, що структурна ієрархія має ім'я процес-ні. При цьому у традиційній структурі увага фіксується на завданнях, роботах, а не на самих процесах. Процес - це специфічно упорядкована сукупність робіт і завдань у часі і просторі із завданням початку і кінця і точним визначенням входів і виходів. Хаммер рекомендує називати процеси так: (за початковим і кінцевим статусам) Розробка продукту: від вимог на продукт - до продукту. Продаж від заявки до замовлення. Це дозволяє відокремити процеси від підрозділів. По суті справи рекомендується для назви процесів використовувати віддієслівні форми.
/ / На практиці за своєю тематикою дати назву завдань.
Для того, щоб правильно налагодити бізнес-процес, пропонується їх ділити на процеси зовнішні (преценденти) і внутрішні. Концентрація організації на процесах, які виробляють цінності, дозволяє найкращим способом виконувати те, що повинно бути зроблено фірмою. При аналізі бізнесу, виявиться багато робіт і завдань, не орієнтованих на цілі фірми.
Приклади успішного реінжинірингу. (Досвід ЕОМ-креіт)
Займається кредитуванням клієнтів. Проблема філії була в тому, що при існуючому технологічному циклі, вирішення питання про кредитування клієнта займало в середньому 6 днів, а в складних випадках до 2 тижнів. Таке тривале оформлення кредитів призводило до втрати клієнтів. Втрата клієнта впливала на джерела фінансування. Крім того компанія при існуючій технології не могла відповісти на питання клієнта «на якому кроці обробки знаходиться його запит і коли буде дано відповідь. Тривалість диктувалася наступним - треба було здійснити 5 кроків в деякій послідовності в 5 різних підрозділах компанії. При цьому передача рішення одного підрозділу іншому здійснювалася в паперовому вигляді. Компанія зробила спробу вирішити проблему через реінжиніринг.
Дії:
-Аналіз поточного стану справ;
-Порядок завершення кожного кроку;
-Після рішучих роздумів два старших менеджера фірми вирішили самі спробувати оформити всі 5 кроків. При цьому виявилося, що на обробку запиту витрачається 90 хвилин, а решту часу витрачалося на передачу запитів. Фірма об'єднала всі кроки і підпорядкувала одному спеціалісту.
Умови успішного реінжинірингу.
1.Фактори успіху.
2.Тіпічние помилки при проведенні реінжинірингу.
1.Фактори успіху.
Досвід впровадження принципів реінжинірингу показав, що 50% впровадження принципів реінжинірингу закінчувалися невдачею. Для того, щоб з'ясувати причини цих невдач 40 фірм зазнали вченими обстеженню і були виявлені недоліки і фактори успіху.
До факторів успіху відносяться:
1.Мотівація - мотив повинен бути ясний і зафіксовано, керівництво має вірити заздалегідь в його успіх, керівництво повинно розуміти, що структура повинна змінюватися, виникнуть проблеми з трудовими ресурсами. Вірячи в необхідність реінжинірингу керівництво має визначити кращі сили на підприємстві та створити команду реінжинірингу.
2.Руководство. Проект повинен виконуватися під управлінням керівництва компанії. Керівник повинен мати великий авторитет серед робітників. Взяти на себе відповідальність. Доведено - ймовірність успіху вище у тих компаній, які реалістично оцінюють очікувані результати. Дуже важливо твердо й уміло управляти командою з реінжинірингу. До реінжинірингу керівник повинен дати собі звіт про ті труднощі, які його чекають, про те, що на нього будуть тиснути стара система, зуміти переконати, що проект необхідний.
3.Сотруднікі.
За Віллору співробітники діляться на 3 категорії:
1. «Тигри» - молоді кар'єристи, працюють з ентузіазмом у проекті, уміють концентруватися на нових завданнях іноді на шкоду думки інших.
2. «Осли» - співробітники, що досягли якихось цілей своєї кар'єри, ті, що бажають спокійно в роботі, стабільності, туго сприймають нове.
3. «Акули» - ті, які розробили процедури, інструкції для керування операції компанії, мають реальну силу в компанії, але тим не менш можуть створювати величезні проблеми шляхом саботування реальних змін у компанії.
У компанії беруться люди, які можуть приймати нові завдання, вірять у реінжиніринг і можуть добиватися певних успіхів (тигри).
4.Понятность.
Нові задачі в компанії повинні бути зрозуміло сформульовані.
Успіх залежить від того, як рядові співробітники і керівництво розуміють ті методи, які вони хочуть використовувати для успіху.
5.Бюджет.
6.Фокусірованіе над більш престижних цілях.
Чітке визначення ролей та обов'язків.
7.Осязаемие результати.
Повинні бути представлені конкретні результати.
8.Технологіческая підтримка.
Повинно бути сучасне ПЗ.
9.Консультація.
Консультація повинна виконувати не керуючу, а підтримуючу роль.
2.Тіпічние помилки при проведенні реінжинірингу.
1.Крах проекту може настати, якщо відповідальний за проект має не високий посадовий ранг.
2.Якщо команда зайво концентрується на технологічних питаннях.
3.Якщо менеджери думають «зробіть це для мене», а самі при цьому не беруть участі в цьому процесі.
4.Ріск, пов'язаний зі зміною процесу.
5.Ріск, пов'язаний з використанням самої технології.
6.Компанія намагається поліпшити існуючий процес замість того, щоб його перепроектувати.
7.Компанія не концентрується на бізнес-процесах.
8.Компанія концентрується тільки на проектуванні процесів, ігноруючи все інше.
Недооцінка ролі цінностей і переконань виконавців.
Згода задовольнятися малим.
Передчасне завершення реінжинірингу.
Обмежена постановка задачі.
Існуюча корпоративна структура і прийняті в компанії принципи можуть перешкоджати реінжинірингу.
Спроба здійснити реінжиніринг знизу-вверх.
Не можна призначати відповідальним менеджера, що не розуміє що таке реінжиніринг.
Компанія розробляє відразу кілька проектів з реінжинірингу.
Не можна проводити реінжиніринг перед зміною керівництва.
Не можна проводити реінжиніринг розтягнуто.
Що не є реинжинирингом:
-Використання нового ПЗ;
-Дрібна реконструкція і дрібні поліпшення;
-Вирівнювання цілей компанії;
11.09.2007.
Вплив реінжинірингу на об'єкт господарювання
1.Совершенствованіе бізнесу на основі реінжинірингу і роль ІТ в ньому.
2.Особенности перепроектування бізнес-процесів.
3.Ресультати реінжинірингу бізнес-процесів (РБП).
4.Отлічае традиційної і нової структури компанії.
1.Совершенствованіе бізнесу на основі реінжинірингу і роль ІТ в ньому.
Інжиніринг бізнесу = реінжиніринг бізнесу + удосконалення бізнесу.
Якщо реінжиніринг проводиться один раз, то удосконалення робиться постійно.
Різниця між удосконаленням та реинжинирингом бізнесу.
| Найменування параметра | Удосконалення | Реінжиніринг |
| 1.Рівень змін | Нарощуваний | Радикальний |
| 2.Начальная точка | Існуючий процес | «Чиста дошка» |
| 3.Частота змін | Безперервно | Одноразово |
| 4.Требуемое час | Коротке | Тривалий |
| 5.Направленіе | Знизу-вгору | Зверху-вниз |
| 6.Охват | Вузький (на рівні функцій) | Широкий, міжфункціональних |
| 7.Основні засіб | Статичний управління | Інформаційні технології |
| 8.Тіп змін | Культурний | Структурний та культурний |
1.Розробка образу майбутньої компанії.
На цьому етапі проектується картина того, як слід розвивати бізнес, щоб досягти стратегічних цілей.
2.Аналіз-етап існуючого бізнесу.
Проводиться дослідження компанії і складається схема її функціонування в даний момент і називається ця схема «як є».
3.Розробка нового бізнесу.
Розглядається зміна процесів і підтримуюча їх інформаційна система.
Виконується Прототипування і тестування нових процесів.
4.Внедреніе нового бізнесу.
РБП пройшов деякі періоди.
1. 1990-1993 - удосконалення програми: управління якістю, функціонально-вартісної аналіз, виробництво «саме вчасно»
2. 1004-1996 - більшість бізнес процесів охоплюється реинжинирингом. Ефективність роботи компанії зростає в рази.
3. 1996 - до цього дня. - Глобальний період. На цьому етапі механізм реінжинірингу зобов'язаний забезпечити постійний перегляд БП, бізнес-стратегій, відповідно до змін в навколишньому світі.
У всьому цьому велика роль ІТ. (Хаммер, Чемпер).
1.Компанія, яка не може змінювати своє мислення з дедуктивного на індуктивне не готовий на проведення реінжинірингу.
2.Компанія, яка ставить знак рівності між технологією і автоматизацією.
3.Компанія, яка спочатку шукає проблеми, а потім для їх вирішення підшукує технології.
Реінжиніринг використовує індуктивне мислення, тобто спочатку розглянути ефективне мислення, а потім шукати проблеми, які воно може вирішити.
Основна помилка більшості компаній у тому, що на даному етапі вони розглядають ІТ через призму існуючих процесів. Вони формулюють проблему таким чином: як використовують нові технології, що б поліпшити те, що ми зараз робимо. Однак виявляється, що просте накладання ІТ на існуючі процеси не призводить до істинної трансформації бізнесу. І навіть навпаки може блокувати процес перебудови, зберігши колишні способи. Компанія повинна формулювати проблему інакше «як за допомогою нової технології робити те, що ми ще не робили».
Реінжиніринг - використання останніх інформаційних технологій для досягнення зовсім нових ділових цілей.
Нові інформаційні технології, що змінюють правила роботи компанії.
| Колишнє правило | Технологія | Нове правило |
| Інформація може з'являтися в один час в одному місці | Розподілена БД | Інформація може з'являтися одночасно в різних місцях тоді, коли вона необхідна |
| Складну роботу можуть виконувати лише експерти | Експертні системи | Роботу експерта може виконувати спеціаліст з загальних питань (спеціаліст з загальних питань) |
| Необхідно вибирати між централізацією і децентралізацією | Телекомунікаційні мережі | Можна одночасно отримувати переваги від централізації і децентралізації (багаторівневі БД) |
| Усі рішення приймають менеджери | Засоби підтримки прийняття рішень, повинен бути забезпечений доступ до БД, повинні використовуватися засоби моделювання | Прийняття рішень є частиною роботи кожного співробітника. Для керівництва прийняття ієрархічних рішень |
| Фахівцям для отримання, зберігання, пошуку і передачі інформації потрібний офіс | Бездротова зв'язок і стерпні комп'ютери | Фахівці можуть посилати і отримувати інформацію з того місця де вони знаходяться |
| Кращий контакт з потенційним покупцем - особистий контакт | Інтерактивний відеодиск, сайти | Кращий контакт з потенційним покупцем - ефективний контакт |
| Для того, щоб знайти деяку сутність, необхідно знати де вона знаходиться | Технологія автоматичного індексування і відстеження | Сутності говорять вам де вони знаходяться |
| План переглядається періодично | Високопродуктивні ЕОМ | План переглядається оперативно, але в міру необхідності |
Інформаційні технології повинні припускати наступне:
1.Всегда містити в собі досягнуті переваги в бізнесі, а так само «нові» проривні рішення.
3.Сократіть переваги інших компаній шляхом копіювання їх досягнень.
Питання стосовно інформаційних технологій повинен бути переглянутий.
«У чому мета ІТ?»
Колишній відповідь: підвищення продуктивності, економія фінансів, підготовка обгрунтованих рішень. - Відноситься до короткострокових переваг.
Головна ж мета при впровадженні інформаційних технологій на підприємства, що здійснюють реінжиніринг, розуміється так: стратегічна мета ІТ - сприяє менеджменту реагувати на динаміку ринку, створювати, підтримувати і поглиблювати конкурентні переваги.
2.Особенности перепроектування бізнес-процесів.
Розглянемо характерні властивості перепроектований бізнес-процесів:
1.Несколько робіт об'єднується в одну (горизонтальне стиснення).
Характерною властивістю перепроектований процесів є відсутність складального конвеєра на кожному робочому місці якого виконуються прості завдання. Ці завдання просто інтегруються. Дуже важливо мати прямий доступ до БД.
2.Ісполнітелі приймають самостійне рішення (вертикальне стискання).
3.Шагі процесів виконуються в природному порядку.
Немає розривів.
4.Процесси мають різні варіанти виконання.
Будь-яке вплив зовнішнього світу враховується.
5.Работа виконується там, де це найбільш доцільно.
Реінжиніринг роботу між кордонами, усуває зайву інтеграцію і призводить до підвищення ефективності процесу.
Зменшення перевірок та управлінських впливів.
6.Реінжінірінг передбачає більш збалансований підхід. Замість перевірки всіх виконаних робіт перепроектований процес часто агрегує ці роботи, включає налагоджені перевірки та управляючі, що скорочує обсяг і вартість перевірок.
7.Предполагает мінімізацію погоджень.
Передбачає повну самостійність прийняття рішень.
8.Предполагает змішування централізованого та децентралізованого підходу.
02.10.2007.
Особливості об'єктно-орієнтованого підходу.
1.В основі цього способу лежать поняття об'єкт, клас, інкапсуляція, успадкування, поліморфізм.
Під об'єктом можна розуміти як конкретні предмети, так і деякі процеси. Всі об'єкти і виділені в них класи відрізняються особливою поведінкою і індивідуальністю. (Поведінка - ситуація, в якій може опинитися об'єкт). Класи успадковують властивості об'єкта: склад і структуру даних, що описують атрибути класу та відповідних об'єктів. Спадкування - сукупність методів, це взаємодія об'єкта та його класів з зовнішнім середовищем. (Об'єкт - магазини, класи - окремі магазини). Інкапсуляція - приховування інформації. (При цьому методі ми можемо закрити інформацію (доступ до атрибутів), крім як через його методи). Виходить, що користувач повинен надіслати деяке повідомлення, ініціюючи виконання якогось потрібного методу. Це дозволяє уникнути небажаних побічних ефектів у програмній системі, зменшується можливість появи помилок та можливості їх виправлення. Метод наслідування дозволяє створити з класу нові класи за принципом від загального до конкретного. Поліморфізм - здатність об'єктів вибирати метод на основі типів даних, які приймаються у повідомленні. Кожен об'єкт може реагувати по своєму на одне й те саме повідомлення. Поліморфізм дозволяє спростити вихідні тексти програм, забезпечувати їх розвиток за рахунок введення нових методів. Життєвий цикл розробки включає наступні етапи: аналіз, проектування, еволюція, модифікація.
Головна особливість Ж.Ц. полягає в тому, що немає суворої послідовності виконання окремих етапів. Впровадження модулів може бути навіть при не закінчення розробки проекту. Але мірило тут - незалежність модуля від інших. Переваги об'єктно-орієнтованого підходи: розпаралелювання робіт, спрощення внесення зміни за рахунок успадкування, використання програмних компонентів (керуватися треба: чим більш високого рівня об'єкти ви можете повторно використовувати, тим більшого ви досягнете). При цьому керуватися: усвідомити вигоди такого підходу, знати які частини завдання можуть бути вирішені із застосуванням існуючих програмних засобів. Займатися пошуком, відповідним для повторного використання програм. Природність опису. (Фірми виконують замовлення. Об'єкти фірма, замовлення. Виконують - процес).
Недоліки об'єктно-орієнтованого підходу. До недоліків відносяться такі особливості програмування: пошук методу, за яким користувач звертається до бази. Якщо відійти від цього принципу, то виходить зайва численність викликів. Динамічне створення і видалення об'єктів при цьому методі передбачає розміщувати такі об'єкти при створенні програми, а не під час роботи алгоритмів. Уникнути цих недоліків у нових умовах можливе за інтегрованих підходах до розробки моделей. Визнано, що базовою методологією бізнес-процесів реінженерінга стає об'єктно-орієнтоване моделювання. При створенні попереднього покоління систем відштовхувалися від даних (опис даних та їх взаємозв'язки), нове покоління орієнтоване на поведінку сутностей у різних ситуаціях.
Основні етапи реінжинірингу бізнес-процесів.
1.Структура та етапи реінжинірингу.
2.Основанія для початку робіт з реінжинірингу.
3.Розробка образу майбутньої компанії.
4.Спеціфікація цілей компанії.
5.Розробка моделей існуючого та нового бізнесу.
6.Управленіе проектами з реінжинірингу бізнесу.
1.Структура та етапи реінжинірингу.
Для проведення реінжинірингу кожна компанія повинна виділити ресурс, що відповідає за розробку та супровід бізнес-процесів компанії. Ця група на вході має нові цілі, а на виході змінену компанію. Розробка бізнесу - це не звичайний бізнес-процес. У нього немає зовнішнього споживача.
Проект з реінжинірингу включає 4 етапи:
1.Розробка образу майбутньої компанії. (Визначається стратегія компанії, потреби клієнтів, визначається майбутній рівень компанії в бізнесі і вивчається поточний стан компанії).
2.Створення моделі існуючої компанії - ретроспективний інжиніринг. Дуже детально описується існуюча компанії, ідентифікуються і документуються її основні бізнес-процеси, оцінюється їх ефективність (контролінг).
3.Розробка нового бізнесу (прямий інжиніринг):
-Перепроектування бізнес-процесів (поміняти завдання, цілі, елементи).
-Визначити використання інформаційних технологій і зміни в роботі персоналу. Розробка бізнес процесів компанії на рівні трудових ресурсів (організація команди, створення системи мотивації, підготовка фахівців).
-Розробка систем, що підтримують бізнес-процеси.
09.10.2007.
Впровадження перепроектований процесів.
На цій стадії має проводитися тестування процесів, навчання співробітників, установка самої системи, перехід до нової роботи на нових підставах.
Всі ці етапи можна звести до такого короткого порозуміння: реінжиніринг бізнесу = зворотний інжиніринг бізнесу + прямий інжиніринг бізнесу.
При розробці цих етапів необхідно звернути увагу на нововведення, прорахувати їх ефект, визначити зрілість цих нововведень. Не зріле нововведення може підірвати довіру робітників. Звернути увагу на управління нововведеннями. Не можна щоб кожен вводив нововведення. Цим процесом потрібно керувати як єдиним цілим. Нововведення потрібно накопичувати (накопичені нововведення називаємо версіями). Згідно цих версій складаємо метрики, а потім по них розробляється модель майбутньої компанії.
2.Основанія для початку робіт з реінжинірингу.
Підстави Хаммер і Чемпер представляють у вигляді «Аргументи для дій». При бажанні ввести реінжиніринг враховується:
-Розглядається оточення компанії (хто клієнт, хто конкурент, як змінюється це оточення);
-Враховуються очікування клієнтів (які побажання цих клієнтів і чому не інші);
-Збільшення конкуренції і особливо в обслуговуванні клієнтів;
-Труднощі, з якими зіткнулася компанія (що не правильно, чому не правильно);
-Діагноз компанії (чому компанія повинна переосмислити свої дії);
-Ризик (ризик залишитися на тому ж рівні або ризик від вводяться змін).
3.Розробка образу майбутньої компанії.
Перш, ніж розробляти образ майбутньої компанії, необхідно розробити модель існуючого бізнесу, дати поняття існуючого бізнесу, існуючої стратегії бізнесу, визначити специфікації цілей і порівняти з вимогами клієнтів.
На основі цих матеріалів узагальнюються вимоги клієнтів і дається оцінка досягнутого рівня компанії. Такий аналіз дозволяє зрозуміти як функціонує компанія, порівняти її з оточенням і визначити вузькі місця в роботі компанії. При цьому завжди є потреба у проведенні реінжинірингу, тому відразу створюється команда (клієнтів компанії).
Стратегія.
Обирана стратегія не повинна грунтуватися виключно на фінансових цілях, оскільки ці цілі розпливчасті і їх побачити складно. Стратегія формулюється чітко і повинна бути вимірна. Стратегія повинна фокусуватися на обмеженій і реальної ідеї, стратегія повинна надихати робітників.
Вимоги клієнтів: надання додаткових послуг, підвищення якості, асортименту вироблюваної продукції, виконання термінових замовлень, надання пільг для постійних клієнтів.
Розуміння існуючого бізнесу.
Оцінка рівня - перш ніж ми будемо проводити реінжиніринг або вже його проведемо, завжди потрібно спробувати оцінити рівень компанії. При оцінці враховуються такі вимоги: репутація, задоволення потреб клієнта, якість продукції, лідерство і, нарешті, інтереси з точки зору оцінки рівня.
Візуалізація результатів реінжинірингу.
По-перше треба довести колективу, що процеси, які турбували компанію дозволені. Шляхи вирішення проблем обрані як життєво важливі і мають шанси на успіх.
Специфіка цілей компанії.
Мета - передбачити наступні моменти в описі компанії: ідентифікація та уточнення назв бізнес-процесів, опис майбутніх процесів, визначити вимірні властивості процесу, їх цілі, визначити технології, що підтримують ці процеси, сценарії майбутнього, скласти список критичних чинників успіху і ризиків.
5.Опісаніе моделі існуючого бізнесу.
Опис моделі існуючого бізнесу - це зворотний реінжиніринг. При розробці моделі існуючого бізнесу слід виділити пріоритетні процеси, оцінити їх і скласти опис цих процесів (з урахуванням такту і здорового глузду). Не варто шукати глибоко істину того, що відбувається, варто порівнювати стан компанії, яке склалося в момент реінжинірингу в зовнішній і внутрішньому середовищі.
6.Управленіе проектом з бізнес-процесу.
Перш за все управління зібраним матеріалом, складеної програмою реінжинірингу повинно починатися з адаптації до існуючого бізнесу. Проекти з реінжинірингу розрізняються по тому, які компанії вони беруть до дослідження, від чого залежать масштаби реінжинірингу. При реинжиниринге великих компаній виділяють сутності та події найбільш істотні для даної компанії. Особлива увага приділяється тому, хто має очолювати реінжиніринг, враховується мотивація, роз'яснення завдань, спеціалізація бізнесу, потім визначається методика самого бізнесу і змісту майбутнього проекту.
16.10.2007.
Можна виділити наступні роботи з управління проектом:
1.Предварітельное вивчення.
1.1.Постановка задач проектування.
1.2.Вирабативаются мети і дається їх оцінка.
1.3.Определяются потреби ідеї.
1.4.Обеспечівается технічна та економічна здійсненність проекту.
2.Планірованіе.
2.1.Організація і планування робіт по проекту. / / Календарний план до диплому.
3.иполненіе.
4Окончаніе.
4.1.ключается у виробленні рекомендацій та висновку за самого проекту і методів його виконання.
Визначення відповідності між етапами реінжинірингу і роботами з управління проектом.
Етапи реінжинірингу:
1.Розробка образу майбутньої компанії через зворотній інжиніринг, прямий інжиніринг та впровадження, а роботи з управління проектом включають попереднє вивчення, планування, виконання та закінчення.
2.Обговорення проекту. Воно буває формальне і неформальне. При неформальному вивченні, як правило, виявляють помилки і вирішують як їх виправити. Формальне обговорення - обговорення спеціальною комісією на рівні інспекції проекту - це потужний апарат оцінки, що має методику оцінки, що забезпечує контроль і статус результатів реінжинірингу. Обов'язково оформляється письмово, при цьому фокус уваги зосереджений на обговоренні моделей бізнесу:
-Чи правильно визначені межі бізнесу;
-Чи відповідають прецеденти специфікаціям цілей;
-Чи потрібно змінювати специфікацію цілей;
- Чи можна зрозуміти що входять в модель прецеденти;
-Чи всі ролі з оточення бізнесу описані у вигляді суб'єктів;
-Чи для всіх суб'єктів визначено адекватні безлічі прецедентів;
-Задовільно чи описані інтерфейси;
-Чи є потоки подій у прецедентах коректними і повним;
-Чи всі альтернативні потоки описані.
Управління проектом є ключем до хорошій якості і повинно бути піддано ретельному обговоренню.
Архітектура інжинірингу бізнесу.
1.Требованія до бізнес-моделі.
2.Внешняя модель.
3.Внутренняя об'єктна модель.
4.Опісаніе прецеденту.
1.Требованія до бізнес-моделі.
Архітектура відноситься до архітектури конкретного бізнесу, а так само до різних типів архітектур, які можуть бути представлені у вибраному мові моделювання. Саме друге значення цього слова і є для нас головним. Під архітектурою компанії увазі найбільш важливі статичні або довго живуть структури компанії.
Типові елементи структури - функції компанії, а елементи структури - процеси, продукція, ресурси. Всі вони пов'язані між собою і в кінцевому підсумку формують структуру. Елемент речовинний, відчутний, йому можна присвоїти значення. Хоча архітектура складає основу моделі бізнесу, в моделі необхідно відобразити і динаміку, тобто що робить компанія в різних ситуаціях. Необхідно визначати які слід приймати рішення в різних ситуаціях для управління компанією.
Процес, функція, під бізнес.
Процес показує як клієнт може використовувати бізнес і включає в себе повний потік подій в системі (як клієнт починає, веде і завершує бізнес-процес). У літературі процес - це структурований і вимірюваний набір дій, створений, щоб провести певний вихід для конкретного клієнта або ринку. Це поняття дозволяє відобразити інтереси компанії, клієнтів (бізнес зовні). Мова моделювання повинен описувати різні типи завдань або внутрішніх процесів з яких складається майже кожен бізнес-процес, а так само спосіб взаємодії внутрішніх процесів при обслуговуванні клієнтів.
Подбізнес - мається на увазі, що більшою бізнес підрозділяється на декілька функцій (подбізнесов), кожна з яких покриває конкретну сферу компетенції. У процесно-орієнтованих компаніях під бізнес - це не традиційна сфера відповідальності (як, наприклад, фінанси і маркетинг), а область компетенції (така, як знання конкретного типу продукції вироблених компаній). Подбізнес не має свого менеджера, але має власника ресурсу, який удосконалює управлінський персонал і продає його лідерам процесу. Використовуючи власників процесу і власників ресурсу традиційна відповідальність поділяється на два компоненти: один веде компанію до фінансових цілям, інший вдосконалює ресурси персоналу, сприяючи досягненню фінансових цілей. Безумовно, що моделювання повинно бути узгодженим. Узгодження настає через створення двох моделей: зовнішньої і внутрішньої. Зовнішня модель описує компанію і зовнішній для неї світ. Вона описує процеси, які задовольняють інтереси клієнтів та інтереси поза компанією. Інтерфейс Інтерфейс між кожним процесом і навколишнім середовищем компанії життєво важливий і повинен бути ретельно описаний. Внутрішня модель компанії описує як будується кожний бізнес-процес з різних робочих завдань (внутрішні процеси) і які ресурси він використовує. Внутрішня модель використовує об'єкти, відповідні робочим завданням та об'єкти, відповідні предметів бізнесу, наприклад, продукції. На відміну від статичних інформаційних систем, динамічні дозволяють динамічно (під час роботи програми) створювати, модифікувати і видаляти об'єкти. Динамічно встановлюють відносини між об'єктами. Зберігати історію зміни значень змінних в часі. Динамічно оновлювати значення змінних (опитуючи зовнішнє оточення або виконуючи умовивід. Виконувати умовиводи, що враховують не тільки значення змінних, але і задані моменти часу. Динамічно призначати і звільняти ресурси (наприклад, вантажників). Динамічно обчислювати показники вартісних оцінок і продуктивності окремих операцій і всього процесу в цілому. Накопичувати необхідні, поточні, статистично показники в будь-якій точці модельованого процесу. Змінювати модель не перериваючи процес її функціонування. Це під силу розвинутим інформаційним системам, що дозволяє описувати динаміку.
2.Внешняя модель.
П-модель. Називається прецедент-моделлю. Зовнішня П-модель описує бізнес так, як його видно із зовні, тобто як він сприймається тими, хто хоче його використовувати. Поняття П-моделей грунтується на таких поняттях як бізнес-системи, суб'єкт, прецедент. Бізнес-системи мають кордону і їх потрібно визначати. Визначаються кордону між системою та її оточенням. Коли система моделюється, межа ще не визначена. При побудові моделі, вона чітко окреслена. Для позначення деякої бізнес-системи в П-моделях використовують прямокутник з розташуванням над ним імені цього бізнесу. Все що усередині прямокутника відноситься до бізнес-системи. Все що поза ним, відноситься до зовнішнього оточення. Оточення відбивається через суб'єкти. Суб'єкт позначає роль, яку хто-то или что-то може грати по відношенню до бізнесу. Суб'єкти можна розділяти на 2 групи: людські і технічні.
23.10.2007.
Розвиток зовнішньої П-моделі здійснюється через опис прецедентів. Оскільки прецедентів багато і вони можуть бути однаковими, то їх класифікують, тому при моделюванні необхідно розрізняти клас суб'єктів і фактичних суб'єктів. У моделі реальні люди є не примірниками деякого класу, а реалізаціями екземплярів цього класу. Кожен суб'єкт є деяку роль, яку відіграють реальні люди. Запишемо, що один і той же чоловік миє грати кілька ролей, тобто реалізовувати декілька примірників суб'єкта. Т.ч. слід розрізняти клас і екземпляр прецеденту. Клас прецедентів визначається його писанням, а екземпляр прецеденту - діями, які виконуються коли потік подій, відповідає опису прецедентів, проходить через систему. Клас прецедентів може містити кілька альтернативних шляхів через систему, але екземпляр повинен слідувати тільки одному з них. Щоб надати П-моделі велику глибину, складаються детальні описи кожного прецеденту і взаємодія між ними. Фактично ці дії можна розглядати як машину стану подій. У цій машині подій стан примірника прецеденту представляється як стимул, який може бути отриманий від іншого прецеденту і може викликати перехід до іншого стану після завершення транзакції. Можна так сказати, що прецедент може слідувати різними шляхами, примірник всередині нього - своїм, але все це направлено на завершення транзакції. При побудові П-моделі необхідно дослідити взаємодію між суб'єктом і прецедентом. Відомо, що суб'єкти взаємодіють з системою, посилаючи стимули. Щоб краще зрозуміти суб'єкт, необхідно знати в якому прецеденті він бере участь. У П-моделі він показується стрілкою. Розгляд П-моделі дозволяє зробити такі висновки, що П-модель дає зовнішнє представлення системи. Це означає, що модель призначена в 1 чергу для замовників і користувачів системи, а не для тих хто її реалізує. Прецеденти повинні виражати що бізнес повинен робити в той час, як внутрішня буде виражати як працює. П-модель - «що модель».
3.Внутренняя об'єктна модель.
Внутрішня об'єктна модель. П-модель - хороший засіб для опису вимог до бізнесу, вони ілюструє функції до бізнесу, його оточення і бізнес-процеси, які він пропонує зовнішнього світу. Тим не менш П-модель не дає ясної картини про внутрішній устрій бізнесу, тобто про те як різні види діяльності реалізують бізнес-процеси. Для більш повного розуміння бізнесу необхідно розробити внутрішню модель. На відміну від П-моделі, внутрішня модель не описує аспекти бізнесу, які не можуть мати пряме відношення до бізнесу. Бізнес не може займатися нічим. У розрахунок необхідно приймати вимоги, що регулюють бізнес-процеси і називати ці речі процесами, що відносяться до бізнесу. Використовують 2 види внутрішніх моделей: ідеальні і реальні. Ідеальна модель - модель, яка не враховує як компанія повинна реалізовуватися на практиці. Наприклад, географічне розташування, наявність філій. Реальна - враховує всі фактори. Наприклад, що компанія не має в своєму розпорядженні потрібних персоналом з потрібною компетенцією, передбачуваної ідеальної моделі. Відповідно до тенденцій, наміченими сьогодні, при описі внутрішньої моделі будемо базуватися на понятті об'єкт, тому внутрішню модель позначимо як О-модель. При описі О-моделі, об'єкти представляють учасників процесів і різного роду сутності (продукти, предмети, завдання), що використовуються в ході виконання процесів. Ім'я, яке дається класу об'єктів, має як більш ясно виражати суть, властиву екземплярів цього класу. Класам часто дають імена, що складаються з декількох слів. Ім'я моделі повинно бути унікальним, тобто схожих імен не повинно бути. Імена класів як правило виражаються іменниками (меню, кухар, гардеробник ....). Об'єкт може відповідати завданням, продукції, або сутностей бізнесу. Завдання діляться на 2 типи: ті, що забезпечують взаємодію суб'єкта з бізнесом і ті, які є внутрішніми. Зручно визначити тип об'єкта для того, щоб зробити ясними завдання, які вони виконують в моделі - це об'єкти суті, виконують моделі та інтерфейсні моделі. Інтерфейсні та керуючі об'єкти представляють завдання, а не типи ресурсів. Але завдання виконуються людьми, що відносяться до певної категорії ресурсів (див. рис 5.3.). Інтерфейсні - представляють у бізнесі операції, які повинні виконуватися якимось ресурсом, причому одним і тим же. Це завдання включає взаємодію з навколишнім бізнесом => до комунікабельності людей, що виконують це завдання, пред'являються певні вимоги. Інтерфейсний об'єкт може брати участь в декількох прецеденти. Часто вони несуть відповідальність за координацію процесу. Керуючі об'єкти становлять операції бізнесу. Вони, як правильно, багатоекземплярної і їх об'єднують в якийсь керуючий об'єкт, наприклад, розробник продукції. Між об'єктами існують відносини, які встановлюються розробниками і зображуються стрілками або дугами. Відносини пов'язують 2 об'єкти - примірник і клас. Між ними є посилання від 1 примірника об'єкта до іншого. Відносини бувають: успадкування (пов'язують 2 класу), так само може знадобитися співвіднести клас з екземпляром (метаотношенія). Найчастіше використовують бінарні напрямки відносини. Якщо відносини двонаправлені, то використовують стрілку (дугу).
30.10.2007.
Відносини між прецедентами встановлюються у вигляді відносин між об'єктами і їх класами і вказуються стрілками. (Рис 5.4.).
Відносини типу зображених на рис 5.4. - Називаються відносини типу посилання між а і б. Наприклад, замовлення-рахунок. Об'єкт-ставлення-об'єкт. Імена відносин повинні бути віддієслівними. Приклад «замовлення готує кухар» можна прочитати «замовлення готуватися кухарем». Існують правила формування відносин між об'єктами (рис 5.5.). В об'єктно-орієнтованому світі все розглядається з точки зору об'єкта. Постає питання «як один об'єкт залежить від інших об'єктів». Поняття цього дадуть поняття про ролі, які виконують об'єкти (інші) по відношенню до даного, тому ці об'єкти називають по імені тієї ролі, яку вони виконують.
Об'єкт А висуває вимоги до ролей, які інші об'єкти повинні грати по відношенню до А. Введення імені відносини, що визначає роль інших об'єктів сприяють структуруванню моделі. Щоб не плутати класи з відносинами, імена класів пишуться з великої літери, відносин - з малої.
Агрегати об'єктів - відносини «складається з» і представляє собою варіанти ставлення посилання. Вони використовуються для вираження того, що об'єкт складається з інших об'єктів. Конструкція такого типу називається агрегатом. (Див рис 5.6.). Відносини комунікацій правильно називати в дипломі. Відносини комунікації повинні мати можливість обмінюватися даними. У нашому випадку об'єкт кухар повинен дізнатися з об'єкта замовлення які страви він повинен готувати. (Див рис 5.7.). Відносини комунікацій говорить про те, що вони можуть розмовляти один з одним.
Відносини спадкування.
Приклад. Метрдотель відповідає за прийом відвідувачів, розподіл місць та інші загальні питання. Виходить, що він і офіціант мають загальні характеристики. Як розбити, щоб не сплутати їх роботу.
Атрибути. Характеристики об'єкта моделюються атрибутами об'єкта. Атрибут є одиницю інформації, що зберігається в об'єкті і складається з відношення «бути атрибутом» і його типу. Відношення «атрибут» представляє собою значення атрибута в той час, як тип атрибута позначає його структуру і тип. Відношення «атрибут» має ім'я, яке описує роль, яку атрибут грає по відношенню до об'єкта. Атрибут характеризується потужністю, яка вказує скільки примірників атрибута може бути асоційоване з цим ставленням. Відносини «атрибут» зазвичай пов'язують екземпляр класу об'єктів з примірником типу атрибута. У об'єктному моделі можна описувати не всі атрибути об'єкта, а тільки ті, які потрібні для розуміння ролі об'єкта та його зобов'язань у бізнесі. Наприклад, об'єкт замовлення може мати атрибути, що вказують які страви і напої замовлені. Якщо поняття «страва» і «напій» потрібні тільки для замовлення, то цей варіант кращий, ніж вводити відносини «замовлення складається з страв, напоїв». При розробці БД враховуються стану об'єктів. Об'єкт може отримувати різні стимули в залежності від значення атрибутів і від попередньо виконаних операцій, тобто об'єкт має різні стани (див рис 5.8.). Якщо кухар має багато замовлень, він знаходиться в стані повністю зайнятий. В інших випадках кухар знаходиться в стані не повністю зайнятий. Взаємодія об'єктів у прецеденті зображено на рис 5.9. Взаємодія об'єкта в прецеденті відображає динаміку об'єктної моделі. Містить об'єкти і відносини між об'єктами для виконання прецеденту (відносини комунікації). Модель дає можливість визначити потоки подій та необхідну інформацію, дає відповідальність, дає можливість нагадувати що робити.
Діаграма взаємодій прецедентів, тобто бізнес-процесів усередині. См рис 5.10. Діаграма показує як взаімодействуюшіе об'єкти реалізують прецедент, при цьому ідентифікуються стимули, які передаються між об'єктами. Описуються параметри стимулу, ідентифікуються протоколи взаємодії об'єктів, по вертикалі роль кожного об'єкта в цьому прецеденті. Ці аналітичні розкладання дозволяють правильно виділити бізнес-завдання, що об'єднуються в певні підсистеми. Виділення частин бізнесу називають визначенням високорівневої архітектури бізнесу. Підсистемі як би відповідає певний прецедент (оформлення замовлень, формування договорів). У підсистему включається завдання. Завдання - функція даного бізнесу.
06.11.2007.
Моделювання існуючого та нового бізнесу.
1.Модель існуючого бізнесу.
2.Модель нового бізнесу.
1.Модель існуючого бізнесу.
При розробці майбутнього реінжинірингу повинна бути конкретизована мета підприємства. Цілі визначаються при аналізі того що є. Після аналізу необхідно зрозуміти як функціонує підприємство. Робота по створенню моделі існуючого процесу підприємства - зворотний інжиніринг. На підставі даних зворотного інжинірингу здійснюється прямий інжиніринг.
Етапи зворотного інжинірингу:
1.Моделирование на основі прецедентів (П-модель). Моделювання використовується для створення про опису моделі існуючого бізнесу в термінах суб'єктів і прецедентів. Ця модель буде зовнішнім поданням підприємства в дипломі. На підставі моделі визначаються пріоритетні процеси - прецеденти. Описуються потоки подій в цих процесах. Для кожного потоку будується метрика.
2.Об'ектное моделювання О-модель. (Моделі, реалізовані усередині підприємства - моделі існуючого бізнесу.). На цьому етапі слід моделювати тільки функціональну ієрархію компанії і як моделі розподіляються через функціональну структуру. Мета зворотного інжинірингу не тільки розкрити вузькі місця в роботі підприємства, але і під час його проведення залучити персонал на його бік.
Зворотній інжиніринг дозволяє:
-Членам комісії з реінжинірингу зрозуміти недоліки існуючого бізнесу;
-Зрозуміти як змінювати бізнес (процеси за які ніхто не відповідає, процеси зайві, процеси відсутні);
-Співробітникам пояснити чим погані колишні процедури роботи і чому повинні перейти на нові;
-Виміряти нові прецеденти (виміряти вартість наших змін). На підставі матеріалів обстеження троїться П-модель, що включає пріоритетні прецеденти.
Процес побудови моделі включає в себе:
-Виявлення суб'єктів (якщо моделювати частину компанії, то решта частини буде виступати в ролі суб'єктів). При виявленні суб'єктів визначають ролі кожного з них для компанії, групують по відношенню до компанії, наприклад, постачальник, покупець, клієнт.
-Виявлення прецедентів. Виявлено перелік суб'єктів, можна визначати набір прецедентів бізнесу. Рекомендується починати з суб'єктів-клієнтів. Не рекомендується виділяти багато прецедентів бізнесу, а тільки пріоритетні. При цьому пам'ятати, що прецедент - завершений потік подій.
Визначення пріоритетних прецедентів.
Пріоритетні прецеденти мають такі характеристики:
1.Оказивает найбільший вплив на клієнтів бізнесу.
2.Характерістіа за якою більшої з більшою ймовірністю приведе до поліпшення.
3.Визначення проблем існуючого бізнесу.
4.Определяются проблемні прецеденти.
Оцінюються прецеденти на легко і швидко покращувані.
Кожен пріоритетний прецедент моделі повинен бути повністю описаний. Прецедент описується не формально із зазначенням суб'єктів, відносин, що дозволить нам надалі визначити інтерфейс між прецедентами і суб'єктами. Потім на підставі прецедентів будуть визначені інформаційні потоки, їх послідовність, альтернативність (альтернативи дуже важливо враховувати). Дуже важливо визначити межі П-моделювання. Прецеденти повинні бути виміряні (вибір метрик). Якщо немає виміру, немає контролю. Немає контролю - не можна керувати. Якщо не можна управляти - не може бути поліпшення. Реінжиніринг рекомендує вибирати метрики з точки зору клієнта. Наприклад, середня вартість обробки одного замовлення, вартість послуги, середній час замовлення, відсоток відмови. Безумовно будь проектування обговорюється.
При обговоренні ставляться наступні питання:
-Чи правильно описано взаємодію суб'єктами;
-На скільки детально описано хід подій і відповідні;
-Чи є хід подій коректним і завершеним;
-Чи всі важливі альтернативні потоки подій описані.
Після створення П-моделей проектують О-моделі, які відповідають внутрішньому бізнесу підприємства. Все Про-моделі групуються в підсистеми, причому прецеденти можуть працювати з об'єктами з різних підсистем (см рис.6.3.). Більшість компаній мають ієрархічну структуру, яка може бути промодульована виділенням однієї підсистеми на кожну функціональну одиницю. У кожній компанії ці одиниці називаються по своєму (відділення, секція, департамент, лабораторія, відділ). Оскільки кожна одиниця може включати в себе більш дрібні, то існує кілька рівнів підсистем. Ріс6.3. містить приклад верхнього рівня з відношення складається з виділені підсистеми. Виявлення об'єктів проводиться під час реінжинірингу. При цьому визначається на скільки буде глибоким проект, тривалість його розробки, як буде змінюватися сам бізнес.
19-22.06.08 - захист ДАК
Побудова інформаційної системи в рамках реінжинірингу.
1.Наряду з проведенням реінжинірингу на підприємстві, відразу ж визначають його вплив на майбутню інформаційну систему.
Розробка ІС базується на розробці ПЗ - це бізнес-процес, результатом якого є інтелектуальна праця. Одним з прецедентів є розробка ПЗ. Входом цього прецеденту є вимоги до програмного продукту, а виходом - нова версія цього продукту. Розробка ІС - це процес створення моделей, що описують різні сторони цієї системи. Докладно бізнес-системі, розробка ІС теж має своїх учасників: власник процесу, учасник процесу лідер процесу, аналітик, проектувальник та інші. Кожен з них може бути або не бути суб'єктом. Учасник - це один чоловік, що висуває вимоги до ІС або просто зацікавлений в ній. Найбільш важливими учасниками є замовники і користувачі. У контексті реінжинірингу бізнес-процесів, замовники є одночасно і власниками бізнес-процесу. Користувачі системи - учасники цих процесів. Як правило останніх не цікавить як буде реалізована інформаційна система. Для них важливо що вона їм надає. Ці сценарії і закладаються в П-моделі системи. Суб'єкти у цих моделях відображають різні ролі, які можуть грати учасники бізнес-процесів і користувачі ІС. Системним аналітикам необхідна модель на основі якої вони можуть створити гнучкі, легко модифікуються системи. Модель не повинна мати високу деталізацію. У ньому важливо виділити незалежні функціональні групи в системі такі, щоб внесення змін у додатки не впливало на всю систему (інженерія предметної області). Для того, щоб задовольняти цій вимозі, доцільно розробити ідеальні моделі ІС, абстрагується від особливостей конкретної реалізації.
Проектувальники. Їм потрібна модель, що дозволяє описувати різні способи виконання системи аж до створення програмного коду. Інші члени команди і члени з тестування системи потребують моделі, яка б перевірила реальність програмного продукту (модель контрольного прикладу) при цьому кожному прецеденту відповідає одна тестова задача. Етапи розробки моделей ІС представлені на малюнку 8.1. Відповідно з цим малюнком збираються:
1. всі пропозиції, ідеї, побажання і вимоги клієнтів.
2.анализ вимог. На цьому етапі проводиться аналіз повноти і не суперечливості специфікації вимог. На цьому етапі будується П-модель ІС, а так само інтерфейсу користувача.
3.Реальне проектування. Розробляється модель, що служить базисом для реалізації ІС.
4. реалізація. На цьому етапі створюється ПЗ.
5.тестірованіе. Перевіряється відповідність ІС до пропонованим до неї вимогам.
У П-моделі ІС, суб'єкти представляють ролі, які можуть виконувати користувачі системи, а прецеденти ті дії, які вони можуть виробляти з неї. Кожен прецедент - це завершений потік подій в системі, розглядають з точки зору користувача.
Прецеденти в ІС грають дві важливі ролі:
1.Прецеденти природним чином описують функціональні вимоги до ІС. П-модель визначає систему через безліч прецедентів. Оточення інформаційної системи визначається описом різних суб'єктів, які використовують цю систему так, як це описано у прецедентах. П-модель доповнюється О-моделями. П-модель - внешни погляд на ІВ. О-модель - погляд зсередини.
2.Прецеденти структурують кожну об'єктну модель. При цьому корисно структурувати О-модель таким чином, щоб кожна з них представляла деякий окремий аспект її використання. Аспект відповідає одному прецеденту ІС. І його опис включає тільки ті об'єкти, які беруть участь у цьому прецеденті. Ідеальна модель використовує об'єкти 3 типів: інтерфейсні, керівники і об'єкти-сутності. Об'єкти-суті - мало змінювані сутності «живуть довше, ніж екземпляри прецедентів, в яких вони беруть участь». Використовуються для подання атрибутів, відносин і поведінки тих чи інших явищ, подій, персоналу. Керуючі об'єкти використовуються для опису поведінки системи, що задається прецедентами. Зазвичай вони керують іншими об'єктами і виконують роль координаторів моделі. Об'єкти бізнес системи представлені в рис 8.2. Порядок збору вимоги описаний в 8.3. Аналіз вимог представлений на рис 8.4.
П-модель. Називається прецедент-моделлю. Зовнішня П-модель описує бізнес так, як його видно із зовні, тобто як він сприймається тими, хто хоче його використовувати. Поняття П-моделей грунтується на таких поняттях як бізнес-системи, суб'єкт, прецедент. Бізнес-системи мають кордону і їх потрібно визначати. Визначаються кордону між системою та її оточенням. Коли система моделюється, межа ще не визначена. При побудові моделі, вона чітко окреслена. Для позначення деякої бізнес-системи в П-моделях використовують прямокутник з розташуванням над ним імені цього бізнесу. Все що усередині прямокутника відноситься до бізнес-системи. Все що поза ним, відноситься до зовнішнього оточення. Оточення відбивається через суб'єкти. Суб'єкт позначає роль, яку хто-то или что-то може грати по відношенню до бізнесу. Суб'єкти можна розділяти на 2 групи: людські і технічні.
23.10.2007.
Розвиток зовнішньої П-моделі здійснюється через опис прецедентів. Оскільки прецедентів багато і вони можуть бути однаковими, то їх класифікують, тому при моделюванні необхідно розрізняти клас суб'єктів і фактичних суб'єктів. У моделі реальні люди є не примірниками деякого класу, а реалізаціями екземплярів цього класу. Кожен суб'єкт є деяку роль, яку відіграють реальні люди. Запишемо, що один і той же чоловік миє грати кілька ролей, тобто реалізовувати декілька примірників суб'єкта. Т.ч. слід розрізняти клас і екземпляр прецеденту. Клас прецедентів визначається його писанням, а екземпляр прецеденту - діями, які виконуються коли потік подій, відповідає опису прецедентів, проходить через систему. Клас прецедентів може містити кілька альтернативних шляхів через систему, але екземпляр повинен слідувати тільки одному з них. Щоб надати П-моделі велику глибину, складаються детальні описи кожного прецеденту і взаємодія між ними. Фактично ці дії можна розглядати як машину стану подій. У цій машині подій стан примірника прецеденту представляється як стимул, який може бути отриманий від іншого прецеденту і може викликати перехід до іншого стану після завершення транзакції. Можна так сказати, що прецедент може слідувати різними шляхами, примірник всередині нього - своїм, але все це направлено на завершення транзакції. При побудові П-моделі необхідно дослідити взаємодію між суб'єктом і прецедентом. Відомо, що суб'єкти взаємодіють з системою, посилаючи стимули. Щоб краще зрозуміти суб'єкт, необхідно знати в якому прецеденті він бере участь. У П-моделі він показується стрілкою. Розгляд П-моделі дозволяє зробити такі висновки, що П-модель дає зовнішнє представлення системи. Це означає, що модель призначена в 1 чергу для замовників і користувачів системи, а не для тих хто її реалізує. Прецеденти повинні виражати що бізнес повинен робити в той час, як внутрішня буде виражати як працює. П-модель - «що модель».
3.Внутренняя об'єктна модель.
Внутрішня об'єктна модель. П-модель - хороший засіб для опису вимог до бізнесу, вони ілюструє функції до бізнесу, його оточення і бізнес-процеси, які він пропонує зовнішнього світу. Тим не менш П-модель не дає ясної картини про внутрішній устрій бізнесу, тобто про те як різні види діяльності реалізують бізнес-процеси. Для більш повного розуміння бізнесу необхідно розробити внутрішню модель. На відміну від П-моделі, внутрішня модель не описує аспекти бізнесу, які не можуть мати пряме відношення до бізнесу. Бізнес не може займатися нічим. У розрахунок необхідно приймати вимоги, що регулюють бізнес-процеси і називати ці речі процесами, що відносяться до бізнесу. Використовують 2 види внутрішніх моделей: ідеальні і реальні. Ідеальна модель - модель, яка не враховує як компанія повинна реалізовуватися на практиці. Наприклад, географічне розташування, наявність філій. Реальна - враховує всі фактори. Наприклад, що компанія не має в своєму розпорядженні потрібних персоналом з потрібною компетенцією, передбачуваної ідеальної моделі. Відповідно до тенденцій, наміченими сьогодні, при описі внутрішньої моделі будемо базуватися на понятті об'єкт, тому внутрішню модель позначимо як О-модель. При описі О-моделі, об'єкти представляють учасників процесів і різного роду сутності (продукти, предмети, завдання), що використовуються в ході виконання процесів. Ім'я, яке дається класу об'єктів, має як більш ясно виражати суть, властиву екземплярів цього класу. Класам часто дають імена, що складаються з декількох слів. Ім'я моделі повинно бути унікальним, тобто схожих імен не повинно бути. Імена класів як правило виражаються іменниками (меню, кухар, гардеробник ....). Об'єкт може відповідати завданням, продукції, або сутностей бізнесу. Завдання діляться на 2 типи: ті, що забезпечують взаємодію суб'єкта з бізнесом і ті, які є внутрішніми. Зручно визначити тип об'єкта для того, щоб зробити ясними завдання, які вони виконують в моделі - це об'єкти суті, виконують моделі та інтерфейсні моделі. Інтерфейсні та керуючі об'єкти представляють завдання, а не типи ресурсів. Але завдання виконуються людьми, що відносяться до певної категорії ресурсів (див. рис 5.3.). Інтерфейсні - представляють у бізнесі операції, які повинні виконуватися якимось ресурсом, причому одним і тим же. Це завдання включає взаємодію з навколишнім бізнесом => до комунікабельності людей, що виконують це завдання, пред'являються певні вимоги. Інтерфейсний об'єкт може брати участь в декількох прецеденти. Часто вони несуть відповідальність за координацію процесу. Керуючі об'єкти становлять операції бізнесу. Вони, як правильно, багатоекземплярної і їх об'єднують в якийсь керуючий об'єкт, наприклад, розробник продукції. Між об'єктами існують відносини, які встановлюються розробниками і зображуються стрілками або дугами. Відносини пов'язують 2 об'єкти - примірник і клас. Між ними є посилання від 1 примірника об'єкта до іншого. Відносини бувають: успадкування (пов'язують 2 класу), так само може знадобитися співвіднести клас з екземпляром (метаотношенія). Найчастіше використовують бінарні напрямки відносини. Якщо відносини двонаправлені, то використовують стрілку (дугу).
30.10.2007.
Відносини між прецедентами встановлюються у вигляді відносин між об'єктами і їх класами і вказуються стрілками. (Рис 5.4.).
Відносини типу зображених на рис 5.4. - Називаються відносини типу посилання між а і б. Наприклад, замовлення-рахунок. Об'єкт-ставлення-об'єкт. Імена відносин повинні бути віддієслівними. Приклад «замовлення готує кухар» можна прочитати «замовлення готуватися кухарем». Існують правила формування відносин між об'єктами (рис 5.5.). В об'єктно-орієнтованому світі все розглядається з точки зору об'єкта. Постає питання «як один об'єкт залежить від інших об'єктів». Поняття цього дадуть поняття про ролі, які виконують об'єкти (інші) по відношенню до даного, тому ці об'єкти називають по імені тієї ролі, яку вони виконують.
Об'єкт А висуває вимоги до ролей, які інші об'єкти повинні грати по відношенню до А. Введення імені відносини, що визначає роль інших об'єктів сприяють структуруванню моделі. Щоб не плутати класи з відносинами, імена класів пишуться з великої літери, відносин - з малої.
Агрегати об'єктів - відносини «складається з» і представляє собою варіанти ставлення посилання. Вони використовуються для вираження того, що об'єкт складається з інших об'єктів. Конструкція такого типу називається агрегатом. (Див рис 5.6.). Відносини комунікацій правильно називати в дипломі. Відносини комунікації повинні мати можливість обмінюватися даними. У нашому випадку об'єкт кухар повинен дізнатися з об'єкта замовлення які страви він повинен готувати. (Див рис 5.7.). Відносини комунікацій говорить про те, що вони можуть розмовляти один з одним.
Відносини спадкування.
Приклад. Метрдотель відповідає за прийом відвідувачів, розподіл місць та інші загальні питання. Виходить, що він і офіціант мають загальні характеристики. Як розбити, щоб не сплутати їх роботу.
Атрибути. Характеристики об'єкта моделюються атрибутами об'єкта. Атрибут є одиницю інформації, що зберігається в об'єкті і складається з відношення «бути атрибутом» і його типу. Відношення «атрибут» представляє собою значення атрибута в той час, як тип атрибута позначає його структуру і тип. Відношення «атрибут» має ім'я, яке описує роль, яку атрибут грає по відношенню до об'єкта. Атрибут характеризується потужністю, яка вказує скільки примірників атрибута може бути асоційоване з цим ставленням. Відносини «атрибут» зазвичай пов'язують екземпляр класу об'єктів з примірником типу атрибута. У об'єктному моделі можна описувати не всі атрибути об'єкта, а тільки ті, які потрібні для розуміння ролі об'єкта та його зобов'язань у бізнесі. Наприклад, об'єкт замовлення може мати атрибути, що вказують які страви і напої замовлені. Якщо поняття «страва» і «напій» потрібні тільки для замовлення, то цей варіант кращий, ніж вводити відносини «замовлення складається з страв, напоїв». При розробці БД враховуються стану об'єктів. Об'єкт може отримувати різні стимули в залежності від значення атрибутів і від попередньо виконаних операцій, тобто об'єкт має різні стани (див рис 5.8.). Якщо кухар має багато замовлень, він знаходиться в стані повністю зайнятий. В інших випадках кухар знаходиться в стані не повністю зайнятий. Взаємодія об'єктів у прецеденті зображено на рис 5.9. Взаємодія об'єкта в прецеденті відображає динаміку об'єктної моделі. Містить об'єкти і відносини між об'єктами для виконання прецеденту (відносини комунікації). Модель дає можливість визначити потоки подій та необхідну інформацію, дає відповідальність, дає можливість нагадувати що робити.
Діаграма взаємодій прецедентів, тобто бізнес-процесів усередині. См рис 5.10. Діаграма показує як взаімодействуюшіе об'єкти реалізують прецедент, при цьому ідентифікуються стимули, які передаються між об'єктами. Описуються параметри стимулу, ідентифікуються протоколи взаємодії об'єктів, по вертикалі роль кожного об'єкта в цьому прецеденті. Ці аналітичні розкладання дозволяють правильно виділити бізнес-завдання, що об'єднуються в певні підсистеми. Виділення частин бізнесу називають визначенням високорівневої архітектури бізнесу. Підсистемі як би відповідає певний прецедент (оформлення замовлень, формування договорів). У підсистему включається завдання. Завдання - функція даного бізнесу.
06.11.2007.
Моделювання існуючого та нового бізнесу.
1.Модель існуючого бізнесу.
2.Модель нового бізнесу.
1.Модель існуючого бізнесу.
При розробці майбутнього реінжинірингу повинна бути конкретизована мета підприємства. Цілі визначаються при аналізі того що є. Після аналізу необхідно зрозуміти як функціонує підприємство. Робота по створенню моделі існуючого процесу підприємства - зворотний інжиніринг. На підставі даних зворотного інжинірингу здійснюється прямий інжиніринг.
Етапи зворотного інжинірингу:
1.Моделирование на основі прецедентів (П-модель). Моделювання використовується для створення про опису моделі існуючого бізнесу в термінах суб'єктів і прецедентів. Ця модель буде зовнішнім поданням підприємства в дипломі. На підставі моделі визначаються пріоритетні процеси - прецеденти. Описуються потоки подій в цих процесах. Для кожного потоку будується метрика.
2.Об'ектное моделювання О-модель. (Моделі, реалізовані усередині підприємства - моделі існуючого бізнесу.). На цьому етапі слід моделювати тільки функціональну ієрархію компанії і як моделі розподіляються через функціональну структуру. Мета зворотного інжинірингу не тільки розкрити вузькі місця в роботі підприємства, але і під час його проведення залучити персонал на його бік.
Зворотній інжиніринг дозволяє:
-Членам комісії з реінжинірингу зрозуміти недоліки існуючого бізнесу;
-Зрозуміти як змінювати бізнес (процеси за які ніхто не відповідає, процеси зайві, процеси відсутні);
-Співробітникам пояснити чим погані колишні процедури роботи і чому повинні перейти на нові;
-Виміряти нові прецеденти (виміряти вартість наших змін). На підставі матеріалів обстеження троїться П-модель, що включає пріоритетні прецеденти.
Процес побудови моделі включає в себе:
-Виявлення суб'єктів (якщо моделювати частину компанії, то решта частини буде виступати в ролі суб'єктів). При виявленні суб'єктів визначають ролі кожного з них для компанії, групують по відношенню до компанії, наприклад, постачальник, покупець, клієнт.
-Виявлення прецедентів. Виявлено перелік суб'єктів, можна визначати набір прецедентів бізнесу. Рекомендується починати з суб'єктів-клієнтів. Не рекомендується виділяти багато прецедентів бізнесу, а тільки пріоритетні. При цьому пам'ятати, що прецедент - завершений потік подій.
Визначення пріоритетних прецедентів.
Пріоритетні прецеденти мають такі характеристики:
1.Оказивает найбільший вплив на клієнтів бізнесу.
2.Характерістіа за якою більшої з більшою ймовірністю приведе до поліпшення.
3.Визначення проблем існуючого бізнесу.
4.Определяются проблемні прецеденти.
Оцінюються прецеденти на легко і швидко покращувані.
Кожен пріоритетний прецедент моделі повинен бути повністю описаний. Прецедент описується не формально із зазначенням суб'єктів, відносин, що дозволить нам надалі визначити інтерфейс між прецедентами і суб'єктами. Потім на підставі прецедентів будуть визначені інформаційні потоки, їх послідовність, альтернативність (альтернативи дуже важливо враховувати). Дуже важливо визначити межі П-моделювання. Прецеденти повинні бути виміряні (вибір метрик). Якщо немає виміру, немає контролю. Немає контролю - не можна керувати. Якщо не можна управляти - не може бути поліпшення. Реінжиніринг рекомендує вибирати метрики з точки зору клієнта. Наприклад, середня вартість обробки одного замовлення, вартість послуги, середній час замовлення, відсоток відмови. Безумовно будь проектування обговорюється.
При обговоренні ставляться наступні питання:
-Чи правильно описано взаємодію суб'єктами;
-На скільки детально описано хід подій і відповідні;
-Чи є хід подій коректним і завершеним;
-Чи всі важливі альтернативні потоки подій описані.
Після створення П-моделей проектують О-моделі, які відповідають внутрішньому бізнесу підприємства. Все Про-моделі групуються в підсистеми, причому прецеденти можуть працювати з об'єктами з різних підсистем (см рис.6.3.). Більшість компаній мають ієрархічну структуру, яка може бути промодульована виділенням однієї підсистеми на кожну функціональну одиницю. У кожній компанії ці одиниці називаються по своєму (відділення, секція, департамент, лабораторія, відділ). Оскільки кожна одиниця може включати в себе більш дрібні, то існує кілька рівнів підсистем. Ріс6.3. містить приклад верхнього рівня з відношення складається з виділені підсистеми. Виявлення об'єктів проводиться під час реінжинірингу. При цьому визначається на скільки буде глибоким проект, тривалість його розробки, як буде змінюватися сам бізнес.
19-22.06.08 - захист ДАК
Побудова інформаційної системи в рамках реінжинірингу.
1.Наряду з проведенням реінжинірингу на підприємстві, відразу ж визначають його вплив на майбутню інформаційну систему.
Розробка ІС базується на розробці ПЗ - це бізнес-процес, результатом якого є інтелектуальна праця. Одним з прецедентів є розробка ПЗ. Входом цього прецеденту є вимоги до програмного продукту, а виходом - нова версія цього продукту. Розробка ІС - це процес створення моделей, що описують різні сторони цієї системи. Докладно бізнес-системі, розробка ІС теж має своїх учасників: власник процесу, учасник процесу лідер процесу, аналітик, проектувальник та інші. Кожен з них може бути або не бути суб'єктом. Учасник - це один чоловік, що висуває вимоги до ІС або просто зацікавлений в ній. Найбільш важливими учасниками є замовники і користувачі. У контексті реінжинірингу бізнес-процесів, замовники є одночасно і власниками бізнес-процесу. Користувачі системи - учасники цих процесів. Як правило останніх не цікавить як буде реалізована інформаційна система. Для них важливо що вона їм надає. Ці сценарії і закладаються в П-моделі системи. Суб'єкти у цих моделях відображають різні ролі, які можуть грати учасники бізнес-процесів і користувачі ІС. Системним аналітикам необхідна модель на основі якої вони можуть створити гнучкі, легко модифікуються системи. Модель не повинна мати високу деталізацію. У ньому важливо виділити незалежні функціональні групи в системі такі, щоб внесення змін у додатки не впливало на всю систему (інженерія предметної області). Для того, щоб задовольняти цій вимозі, доцільно розробити ідеальні моделі ІС, абстрагується від особливостей конкретної реалізації.
Проектувальники. Їм потрібна модель, що дозволяє описувати різні способи виконання системи аж до створення програмного коду. Інші члени команди і члени з тестування системи потребують моделі, яка б перевірила реальність програмного продукту (модель контрольного прикладу) при цьому кожному прецеденту відповідає одна тестова задача. Етапи розробки моделей ІС представлені на малюнку 8.1. Відповідно з цим малюнком збираються:
1. всі пропозиції, ідеї, побажання і вимоги клієнтів.
2.анализ вимог. На цьому етапі проводиться аналіз повноти і не суперечливості специфікації вимог. На цьому етапі будується П-модель ІС, а так само інтерфейсу користувача.
3.Реальне проектування. Розробляється модель, що служить базисом для реалізації ІС.
4. реалізація. На цьому етапі створюється ПЗ.
5.тестірованіе. Перевіряється відповідність ІС до пропонованим до неї вимогам.
У П-моделі ІС, суб'єкти представляють ролі, які можуть виконувати користувачі системи, а прецеденти ті дії, які вони можуть виробляти з неї. Кожен прецедент - це завершений потік подій в системі, розглядають з точки зору користувача.
Прецеденти в ІС грають дві важливі ролі:
1.Прецеденти природним чином описують функціональні вимоги до ІС. П-модель визначає систему через безліч прецедентів. Оточення інформаційної системи визначається описом різних суб'єктів, які використовують цю систему так, як це описано у прецедентах. П-модель доповнюється О-моделями. П-модель - внешни погляд на ІВ. О-модель - погляд зсередини.
2.Прецеденти структурують кожну об'єктну модель. При цьому корисно структурувати О-модель таким чином, щоб кожна з них представляла деякий окремий аспект її використання. Аспект відповідає одному прецеденту ІС. І його опис включає тільки ті об'єкти, які беруть участь у цьому прецеденті. Ідеальна модель використовує об'єкти 3 типів: інтерфейсні, керівники і об'єкти-сутності. Об'єкти-суті - мало змінювані сутності «живуть довше, ніж екземпляри прецедентів, в яких вони беруть участь». Використовуються для подання атрибутів, відносин і поведінки тих чи інших явищ, подій, персоналу. Керуючі об'єкти використовуються для опису поведінки системи, що задається прецедентами. Зазвичай вони керують іншими об'єктами і виконують роль координаторів моделі. Об'єкти бізнес системи представлені в рис 8.2. Порядок збору вимоги описаний в 8.3. Аналіз вимог представлений на рис 8.4.