BPwin 4.0: прийшов

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


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


Якщо вірити сучасній науці про походження людини, його, тобто людину, завжди відрізняла від інших видів жага діяльності. Причому не просто жага діяльності як такої, а прагнення до вдосконалення цієї діяльності, прагнення до розвитку, залучення у свою діяльність нових технологій. Чим займалися ділові люди в епоху динозаврів? Найвигідніший і життєво необхідний бізнес тих часів – полювання, скажімо, на мамонта. Як добувати такого великого звіра? Це бізнес-процес, який вимагав від щасливих мисливців ретельної підготовки і навчання. Але як можна було навчати підростаюче покоління в ті часи, коли лексичні засоби були ще недостатньо виразні, а писемності не було як такої? У цей важкий момент на допомогу людині прийшов засіб, приголомшливе своєю простотою і виразністю – Малюнок. Процес полювання можна було намалювати. Звичайно, спочатку не обходилося і без непорозумінь, таких, наприклад, як описані у Р. Кіплінга, але казуси відбувалися, тільки поки мова малюнка ще не сформувався повністю, поки не було зрозуміло, що є що, як зобразити перспективу, і як відтворити точну схему. Так малюнок став основним засобом моделювання бізнес-процесів. Йшов час, бізнес-процеси ставали все різноманітнішими, підтвердження чому можна знайти на стінах храмів давньої Індії, на барельєфах стародавньої Греції, вже на папірусі в Єгипті і т.д. Спершу малюнок зображав лише завершився процес, тобто показував, як прийнято робити що-небудь у відповідності із сталим розпорядком. Потім малюнки стали застосовуватися і для того, щоб показати, як можна поміняти сформовану структуру бізнес-процесів, з тим щоб поліпшити їх, тобто малюнок став допоміжним засобом для реінжинірінгу бізнес-процесів. Протягом досить тривалого часу у малюнка був тільки один істотний недолік – Будучи зведеним у ранг мистецтва, він був підвладний лише майстрам, які, до того ж, витрачали на кожен малюнок багато часу. Потім з'явилися книги, і потреба в малюнку, як засобі моделювання відпала, малюнок став у кращому випадку ілюстрацією до написаного. Йшов час, темп людської діяльності експоненціально ріс, ускладнювалися бізнес-процеси. У двадцятому столітті бізнес-процеси стали настільки складні, що жодна людина, що працює на більш-менш великому проекті, не в змозі уявити собі роботу всього підприємства в тій мірі, яка необхідна, для створення інформаційної системи або для реінжинірінгу бізнес-процесів.


Звичайно, можна намагатися документувати структуру бізнес-процесів, але як зробити це швидко? Як швидко отримати чітке уявлення про те, що відбувається на підприємстві? Як визначити характер передбачуваних змін і дивіденди, які ці зміни принесуть?


Існує інструмент, який допоможе відповісти на всі ці питання. Це Computer Associates BPwin, Версія 4.0 якого вийшла в цьому році. BPwin є потужним інструментом для створення моделей, що дозволяють аналізувати, документувати і планувати зміни складних бізнес-процесів. BPwin пропонує засіб для збору всієї необхідної інформації про роботу підприємства і графічного зображення цієї інформації у вигляді цілісної і несуперечливої моделі. Причому, оскільки модель є деяким графічним поданням дійсності, можна стверджувати, що чоловік повернувся до свого улюбленого засобу документування бізнес-процесів – до малюнка. Але повернення це сталося на новому рівні – цілісність і несуперечність моделі-малюнка (якості, про які раніше не було й мови) гарантуються поруч методологій і нотацій, яким слідують творці моделі. BPwin підтримує три таких методології: IDEF0, DFD та IDEF3, що дозволяють аналізувати ваш бізнес з трьох ключових точок зору:



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


IDEF0. Основний з трьох методологій, підтримуваних BPwin, є IDEF0. IDEF0, відноситься до сімейства IDEF, яке з'явилося в кінці шістдесятих років під назвою SADT (Structured Analysis and Design Technique). IDEF0 може бути використана для моделювання широкого класу систем. Для нових систем застосування IDEF0 має на меті визначення вимог і вказівка функцій для подальшої розробки системи, відповідає поставленим вимогам і реалізує виділені функції. Стосовно до вже існуючих систем IDEF0 може бути використана для аналізу функцій, виконуваних системою і відображення механізмів, за допомогою яких ці функції виконуються. Результатом застосування IDEF0 до деякої системи є модель цієї системи, що складається з ієрархічно упорядкованого набору діаграм, тексту документації і словників, пов'язаних один з одним за допомогою перехресних посилань. Двома найбільш важливими компонентами, з яких будуються діаграми IDEF0, є бізнес-функції або роботи (представлені на діаграмах у вигляді прямокутників) і дані та об'єкти (зображувані у вигляді стрілок), що зв'язують між собою роботи. При цьому стрілки, в залежності від того в яку грань прямокутника роботи вони входять або з якої межі виходять, діляться на п'ять видів:



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


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


Як видно на Рис.1, BPwin дозволяє виділяти роботи та стрілки різними кольорами, а також прив'язувати імена стрілок до самих стрільцям (стрілка на ім'я "Звітність"), що підвищує наочність і читаність діаграми.


Після того як контекст описаний, проводиться побудова наступних діаграм в ієрархії. Кожна наступна діаграма є більш докладним описом (декомпозицією) однієї з робіт на вищестоящої діаграмі. Приклад декомпозиції контекстної роботи показаний на Рис.2. Опис кожної підсистеми проводиться аналітиком спільно з експертом предметної області. Зазвичай експертом є людина, яка відповідає за цю підсистему і, тому, що досконально знає всі її функції. Таким чином, вся система розбивається на підсистеми до потрібного рівня деталізації, і виходить модель, апроксимуюча систему із заданим рівнем точності. Отримавши модель, адекватно відображає поточні бізнес-процеси (так звану модель AS IS), аналітик з легкістю може побачити всі найбільш вразливі місця системи. Після цього, з урахуванням виявлених недоліків, можна будувати модель нової організації бізнес-процесів (модель TO BE).


Рис. 2 Приклад діаграми декомпозиції


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


Всього DFD використовує чотири важливих елементи:



Рис.3 Приклад діаграми DFD


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


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


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


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


Модель, виконана в IDEF3, може містити такі елементи:



Рис. 4 Приклад діаграми IDEF3


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


Застосування універсальних графічних мов бізнес-моделювання IDEF0, IDEF3 і DFD забезпечує логічну цілісність і повноту опису, необхідну для досягнення точних і несуперечливих результатів. За допомогою набору графічних інструментів для відображення дій і об'єктів, BPwin дозволяє легко побудувати схему процесу, на якій показані вихідні дані, результати операцій, ресурси, необхідні для їх виконання, управляючі дії, взаємні зв'язки між окремими роботами. Інтерактивне виділення об'єктів забезпечує постійну візуальну зворотний зв'язок при побудові моделі. BРwin підтримує посилальну цілісність, не допускаючи визначення некоректних зв'язків і гарантуючи несуперечність відносин між об'єктами при моделюванні.


BPwin володіє зручним інструментом для навігації за рівнями декомпозиції моделі. Це Model Explorer (див. Рис. 5), який з організації дуже схожий на звичний усім провідник Windows. Роботи IDEF0 показуються в Model Explorer зеленим кольором, DFD – жовтим і IDEF3 – синім. Клацаючи мишею по будь-якій з робіт, представлених в провіднику, користувач може переходити на діаграму, що містить вибрану роботу. У версії BPwin 4.0 провідник моделі пропонує користувачеві покращений інтерфейс, який включає в себе нову вкладку об'єктів (Objects), і допрацьовану вкладку діаграм (Diagrams). За допомогою вкладки об'єктів можна методом Drag & Drop розміщувати об'єкти зі словника на будь-який діаграму. За допомогою вкладки діаграм можна переглядати всю ієрархію діаграм, включаючи Organization Chart, Node Tree, Swim Lane, FEO, і IDEF3 Scenario, про яких мова піде пізніше.


Рис. 10 Приклад Swim Lane діаграми.


Але й описавши допоміжні діаграми, ми далеко не вичерпали всі можливості BPwin, оскільки цей продукт є не лише потужним засобом графічного подання інформації, а й інструментом її аналізу. Як вже говорилося вище, при реорганізації бізнес-процесів вже існуючої системи будуються дві моделі: AS IS і TO BE. Модель AS IS покликана показати, як система функціонує в даний момент і є свого роду фотографією системи. А модель TO BE, яка будується виходячи з результатів аналізу моделі AS IS, показує, як система буде працювати після реорганізації. Як же провести цей аналіз? Деталізація бізнес-процесів дозволяє виявити недоліки організації навіть там, де функціональність на перший погляд здається очевидною. Ознакою неефективної діяльності можуть бути непотрібні, некеровані і дублюються роботи, неефективний документообіг (потрібний документ не опиняється в потрібному місці в потрібний час), відсутність зворотних зв'язків з управління (на проведення роботи не надає вплив її результат) і входу (об'єкти або інформація використовуються нераціонально) і т.д. Крім того, BPwin містить ряд засобів, які допомагають аналітику аналізувати і виправляти модель AS IS. Перш за все, мова йде про те, що BPwin вказує на синтаксичні помилки в моделі, які можуть бути викликані неправильною організацією системи. Коли всі такі помилки будуть виправлені, перед аналітиком повинна встати завдання оптимізації, а для коректної постановки цієї задачі, як відомо, необхідний критерій. Тут BPwin знову приходить аналітику на допомогу, пропонуючи йому те, що для оптимізатора означає анітрохи не менше, ніж точка опори для Архімеда. BPwin дає аналітику метрику – вартісної аналіз, заснований на роботах (Activity Based Costing, ABC) і властивості, що визначаються користувачем (User Defined Properties, UDP).


Вбудований в BPwin механізм обчислення вартості дозволяє оцінювати і аналізувати витрати на здійснення різних видів ділової активності. Механізм обчислення витрат на основі виконуваних дій (Activity-Based Costing, ABC) – це технологія, яка застосовується для оцінки витрат і використовуваних ресурсів. Вона допомагає розпізнати і виділити найбільш дорогі операції для подальшого аналізу. ABС є широко поширеною методикою, яка використовується міжнародними корпораціями і державними організаціями (в тому числі Департаментом оборони США) для ідентифікації істинних рушіїв витрат в організації. Вартісний аналіз являє собою угоду про облік, що використовується для збору витрат, пов'язаних з роботами, з метою визначити загальну вартість процесу. Вартісний аналіз заснований на моделі робіт, оскільки кількісна оцінка неможлива без детального розуміння у функціональності підприємства. Зазвичай ABC застосовується для того, щоб зрозуміти походження вихідних витрат і полегшити вибір потрібної моделі робіт при реорганізації діяльності підприємства. За допомогою вартісного аналізу можна вирішити такі завдання як визначення дійсної вартості виробництва продукту, визначення дійсної вартості підтримки клієнта, ідентифікація робіт, які коштують більше всього (ті, які повинні бути поліпшені в першу чергу).


Механізм підтримки ABC в BPwin, хоча і враховує вартість виконання кожної роботи, тривалість кожної роботи з часу і скільки разів необхідно виконати роботу протягом одного циклу бізнес-процесу, все-таки дає досить грубі оцінки і, до того ж вимагає, щоб всі діаграми, для яких проводиться оцінка були виконані в IDEF0. Якщо вартісних показників недостатньо, є можливість внесення власних метрик – властивостей, визначених користувачем (User Defined Properties, UDP). Є можливість завдання 18 різних типів UDP, у тому числі керуючих команд і масивів, об'єднаних за категоріями. Кожній роботі можна поставити у відповідність набір UDP і проаналізувати результат в спеціальному звіті Diagram Object Report.


І, нарешті, творці BPwin дуже добре розуміють, що один у полі не воїн, навіть якщо цей "один" – BPwin 4.0, і тому BPwin тісно інтегрується з низкою відомих продуктів Computer Associates і інших компаній. Серед цих продуктів:



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

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


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

Коментарів поки що немає.

Ваш отзыв

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

*

*