Використання BPwin в консалтингових проектах. Частина 1

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


Однак, приступаючи до вирішення даного завдання, керівник середнього і великого підприємства задається питанням: "А як у мене на підприємстві виконується та чи інша робота?". З цього моменту на підприємстві починається робота з дослідження та аналізу функціонування бізнес-процесів.


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


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


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



Всі перераховані цілі досягаються за допомогою програмного продукту компанії Computer Associates – BPwin. Ці цілі є фундаментом подальшого розвитку процесу обстеження підприємства, який лежить в основі проекту реструктуризації та переходу підприємства на новий, більш якісний рівень.


Методи моделювання в BPwin


BPwin автоматизує завдання, пов'язані з побудовою моделей розвитку, забезпечуючи семантичну строгість, необхідну для гарантування правильності і несуперечності результатів. Це досягається застосуванням у BPwin наступних методологій: IDEF0, DFD та IDEF3.


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


IDEF0


Перший інформаційний розріз – функціональність системи. У рамках методології IDEF0 (Integration Definition for Function Modeling) бізнес-процес представляється у вигляді набору елементів-робіт, які взаємодіють між собою, обмінюючись інформаційними і матеріальними потоками за допомогою людських і виробничих ресурсів, що споживаються кожною роботою. За допомогою функціонального моделювання можна провести системний аналіз бізнесу, зосередившись на регулярно розв'язуваних задачах чи функціях, на показниках їхнього правильного виконання, необхідних для цього ресурсах, результатах і вихідних матеріалах (сировина).


Перша діаграма в ієрархії діаграм IDEF0 завжди зображує функціонування системи в цілому. Такі діаграми називаються контекстними (Рис.1).


Рис.1 Контекстна діаграма

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


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


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


Рис. 2. Діаграма деталізації

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


Крім основних видів діаграм модель нотації IDEF0 в BPwin може включати наступні елементи:



Рис.3. Діаграма дерева вузлів

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



DFD


Другий інформаційний розріз – потоки інформації (документообігу) у системі.


Діаграми DFD (Data Flow Diagramming) можуть доповнити те, що вже відображено в моделі IDEF0, оскільки вони описують потоки даних, дозволяючи простежити, яким чином відбувається обмін інформацією як усередині системи між бізнес-функціями, так і системи в цілому із зовнішнім інформаційним середовищем (рис. 4).


Рис.4. Діаграма потоків даних

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


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


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


IDEF3


Третій інформаційний розріз – послідовність виконуваних робіт. На відміну від діаграм IDEF0 і DFD, елементи яких дозволяють точно описати функціональність системи і організацію документообігу, описати за їх допомогою логіку побудови системи не вдасться. Для опису логіки взаємодії інформаційних потоків, послідовності виконання робіт і сценаріїв взаємодії модель доповнюють діаграмами ще однієї методології – IDEF3, що також називають діаграмами workflow (мал. 5).


Рис.5. Діаграма потоків робіт

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


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


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


В останній версії BPwin є можливість використання моделі Swim Lane, заснованої на нотації IDEF3, що робить діаграми даної нотації більш читабельними і зрозумілими користувачеві (рис.6).


Рис.6. Діаграма Swim Lane

Діаграми Swim Lane представляють собою діаграму, розділену горизонтальними смужками на рольові області. Назва цього виду діаграм дано за аналогією доріжок для плавання. При цьому ми отримуємо наочне подання потоків робіт з урахуванням наявних ролей. У той же час модель не перевантажується додатковими елементами – посиланнями. Як ролей можуть бути використані, наприклад, назви відділів і підрозділів або ж модулі інформаційної системи. Варіантів подання ролей може бути багато.


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


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


В якості корпоративного стандарту побудови моделей діяльності нами прийнято метод, при якому верхні 3-4 рівня моделі будуються в нотації IDEF0, а завершальний нижній рівень – у нотації DFD. Цим досягається цілісність моделі без перевантаження її зайвою інформацією на верхніх рівнях деталізації (рис.7).


Рис.7. Рівні проектування моделі

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


Після побудови та верифікації моделі "AS IS" аналітику необхідно провести її якісне дослідження, оптимізацію, необхідну для побудови моделі "TO BE". Для того щоб визначити якість створеної моделі з точки зору ефективності бізнес – процесів, необхідна система метрики, тобто якість аналітику слід оцінювати кількісно.


В якості таких кількісних критеріїв оцінки в BPwin виступають вартісні показники робіт, так званий АВС-аналіз, і призначені для користувача властивості процесів – UDP (User Defined Properties).

Частина 2


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Трекбек і пінги

трекбеків / пінгів ще немає.

Відгуки

помогите пожалуйста скачать этот BPwin проект

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*