Моделювання бізнес-процесів c Rational Software Architect. Частина 1

У статті розглянуті основні принципи моделювання бізнес-процесів предметної області при розробці програмного забезпечення з IBM Rational Software Architect . Розумний в гору не піде, розумний гору обійде … (Чому необхідно виконувати моделювання бізнес-процесів)


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



  1. Відсутність у розробників повноважень, необхідних для прийняття зважених проектних рішень щодо доцільності, технічної можливості, необхідності і т.д. реалізації вимог, що надходять від співробітників автоматизуються підрозділів та інших так званих внутрішніх замовників (у ролі яких можуть виступати і представники топ-менеджменту організації). Яскравим наочним прикладом описаної проблеми може бути ситуація, при якій у керівника проекту з автоматизації "зв'язані руки" в буквальному сенсі цього слова – тобто він, будучи особою, відповідальною за успіх проекту, не має можливості приймати рішення про те, що, як і в які строки має бути реалізовано.
  2. Ситуація, коли однією лише автоматизацією домогтися очікуваного ефекту неможливо просто тому, що безглуздо автоматизувати те, що саме по собі неефективно і, тим більше, не формалізована у вигляді чіткої документованої послідовності кроків або дій, що виконуються співробітниками автоматизуються підрозділів. Іншими словами, в результаті спроби автоматизувати безлад ризикуємо отримати не більше ніж автоматизований безлад. Причому ще невідомо, що гірше! Як невеликий ліричний відступ наведемо не зовсім точну цитату з досить відомої книги "Камінь програміста": "… кажучи, що складність за своєю внутрішньою суттю не піддається поясненню, <…> ми змушені створювати все більш складні процедури, щоб уникнути відповідальності ". У випадку, якщо ми приступаємо до автоматизації перш, ніж ключові моменти предметної області представлені у вигляді суворого формалізованого опису, ми з великою часткою ймовірності отримаємо замість добре структурованого програмного продукту щось до такого ступеня заплутане, що при перших же спробах внести в це "щось" будь-які зміни (будь то виправлення помилок або розширення існуючої функціональності) вирішимо, що простіше кинути це "марна справа "і все переробити!

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


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


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



  1. Розроблена і впроваджена ІВ не вирішує і половини тих проблем, для розв'язання яких вона була призначена. Позитивним моментом у даному випадку буде те, що інформаційна система, тим не менш, розроблена, більше того, впроваджена, можливо, використовується співробітниками автоматизується підприємства і, в кращому випадку, в чомусь спрощує виконання ними службових обов'язків, підвищуючи тим самим ефективність роботи всього підприємства.
  2. Інформаційна система містить близько половини запланованих до реалізації функціональних можливостей, тобто проект знаходиться десь на середині. Ситуацію можна охарактеризувати такою фразою: дійшли до середини шляху і зрозуміли, що все потрібно переробити, так як насправді треба не те, що реалізовано, а щось інше, причому це "щось інше" ніяким чином не вписується у вже існуючу структуру. Така ситуація, хоч і виглядає гнітючо, насправді є дуже поширеною. Вона виникає в тих випадках, коли замість того щоб скласти чітке уявлення про те, що є, які існують проблеми і які з них можуть і повинні бути вирішені за допомогою автоматизації, особи, задіяні у розробці, прагнуть якомога швидше реалізувати хоч що-небудь і представити на суд замовника. Плюс тут тільки один – шляхом неймовірних і зайвих зусиль, можливо, все-таки в кінці-кінців буде досягнуто розуміння того, що дійсно повинно бути зроблено для вирішення існуючих проблем, а також отримано уявлення про те, які на підприємстві існують проблеми.

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


Все, можливо, могло бути інакше … (Правила опису бізнес-процесів. Обгрунтування можливості застосування Activity diagram для опису бізнес-процесів у IBM Rational Software Architect )


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


Отже, який же має бути порядок наших дій, щоб вже на початкових стадіях виконання проекту з автоматизації уникнути описаних вище негативних наслідків? Для того щоб відповісти на це питання, звернемося до стандарту ДСТУ ISO 9001-2001, який представляє собою автентичний текст стандарту ІСО 9001-2000 "Системи управління якістю. Рекомендації щодо поліпшення діяльності". Даний стандарт "спрямований на застосування "процесного підходу" при розробці, впровадженні та поліпшенні результативності системи менеджменту якості з метою підвищення задоволеності споживачів шляхом виконання їхніх вимог ". Стандарт ДСТУ ISO 9001-2001 говорить про необхідність визначення та управління системою взаємопов'язаних процесів з метою підвищення ефективності діяльності організації. Загальною вимогою даного стандарту є те, що організація "повинна розробити, задокументувати, впровадити та підтримувати в робочому стані систему менеджменту якості", постійно покращуючи її результативність відповідно до вимог стандарту ДСТУ ISO 9001-2001. У рамках системи менеджменту якості організація повинна виконувати наступні дії.



  1. Визначати процеси, необхідні для системи управління якістю, та їхнє застосування у всій організації.
  2. Визначати послідовність і взаємодію цих процесів.
  3. Визначити критерії та методи, необхідні для забезпечення результативності як при здійсненні, так і при управлінні цими процесами.
  4. Забезпечити наявність ресурсів та інформації, необхідних для підтримки цих процесів та їх моніторингу.
  5. Здійснювати моніторинг, вимірювання та аналіз цих процесів.
  6. Вживати заходів, необхідних для досягнення запланованих результатів та постійного поліпшення цих процесів.

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


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


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


Атрибутами бізнес-процесу є:



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


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


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


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


Основними компонентами будь-якої технології, як відомо, є наступні.



  1. Процес, що визначає набір здійснюваних дій та їх послідовність.
  2. Отримувані на виході результати.
  3. Засоби і ресурси, необхідні для виконання зазначених дій і отримання потрібних результатів (у тому числі інструментальні засоби).
  4. Склад виконавців.

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



  1. Складається опис існуючих на підприємстві процесів, виконується побудова моделі процесів "Як є".
  2. На основі певних критеріїв виявляються "проблемні" процеси і / або дії, або, інакше, "проблеми".
  3. Намічаються шляхи вирішення виявлених проблем, окремо виділяються ті, які можуть бути вирішені за допомогою автоматизації.
  4. Будуються моделі процесів "Як буде", відзначаються ті, які будуть (повинні бути) автоматизовані.

Опис існуючих бізнес-процесів має відповідати таким вимогам.



  1. Опис виконується у вигляді набору дій і входів / виходів.
  2. Повинні бути вказані виконавці (співробітники конкретних підрозділів, програмні засоби, інші механізми і т.д.)
  3. Визначені в процесі опису дії, що становлять процес, повинні бути класифіковані у відповідності з необхідними критеріями.
  4. Опис бажано виконувати з використанням спеціалізованого інструментального засобу, що дозволяє відобразити всі необхідні атрибути бізнес-процесу.
  5. Результатами діяльності з опису бізнес-процесів повинні бути моделі бізнес-процесів автоматизується предметної області.

Виявлення "проблемних" процесів може бути виконано за допомогою використання спеціалізованого інструментального засобу або проблеми можуть бути просто перераховані в окремому документі. Безумовно, бажано, щоб виявлені проблеми були явно пов'язані з зухвалими їх діями та / або процесами. Ще краще, щоб тут же була продемонстрована зв'язок від проблем до шляхів їх вирішення.


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


Важливим моментом, що спрощує завдання виявлення і подальшого опису бізнес-процесів, є той факт, що більшість процесів для більшості предметних областей є "стандартними" в певному сенсі цього слова. Тобто можна стверджувати, що існує деяка досить загальна концептуальна схема, в яку можна "вкласти" практично будь-який процес. Наочним прикладом такої схеми є наступна: "Ініціація (виникнення) – Розвиток (становлення) – Існування (стадія" життя ") – Зникнення (загибель)". Якщо говорити про процес управління, то для нього загальнопоширеною є схема "Планувати – Робити – Контролювати (перевіряти) – Діяти", Покладена в основу стандарту ДСТУ ISO 9001-2001. При цьому, якщо ми хочемо застосувати описану схему процесу управління до того або іншого об'єкту або процесу, нам необхідно забезпечити виконання наступного набору дій: збереження інформації про плановані показники, облік інформації про поточний стан об'єкта, аналіз планової інформації та інформації про поточний стан керованого об'єкта і регулювання. Неважко помітити, що свого роду стандартні процеси або, інакше, так звані шаблони процесів присутні в будь-якій предметній області. Наприклад, якщо говорити про діяльність будь-якого магазину, то її можна укласти в наступну схему: "Забезпечення необхідного товару в наявності – Продаж товару". Якщо говорити про будівництво будівель, то схема буде виглядати приблизно так: "Вибір і оформлення місця будівництва – Будівництво – Здача готового об'єкта ". І, нарешті, всім нам добре відомо, що процес розробки програмного забезпечення також укладається у відповідну концептуальну схему.


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


Діаграми діяльності (Activity Diagram) уніфікованої мови моделювання UML у IBM Rational Software Architectяк раз і дозволяють відобразити не тільки сам процес, але і каркас, у який його можна "укласти", дозволяючи створити так звані контейнери для складових процес дій. Крім того, дії, що становлять аналізований процес, можуть бути класифіковані на діаграмі діяльності у відповідності з іншими критеріями, набір яких може залежати як від специфіки аналізованої предметної області, так і цілей, переслідуваних аналітиком. До найбільш загальним критеріям, тим не менш, можна віднести наступні:



Читати частина 2

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


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

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

Ваш отзыв

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

*

*