Оформляємо розділ «відомості про господарську та іншу діяльність» пноолр. Тотальне управління якістю

Що таке бізнес-процеси? Приклади дозволять нам краще розібратися в цьому предметі, тому ми активно їх використовуватимемо.

Загальна інформація

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

Давайте розглянемо побутовий приклад. Є домогосподарка, яка хоче помити посуд (бізнес-процес). Вона доручає це завдання посудомийній машині. На вході ми маємо брудний посуд. Під час процесу використовуватимуться вода, миючий засібта електрику. І на виході ми отримаємо чистий посуд. За такою схемою і будуються бізнес-процеси. Приклади, які будуть наведені надалі, лише підтвердять ці слова.

Функціональний підхід

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

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

Процесний підхід

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

Уявіть карту. У самому центрі знаходиться Він поділяється на окремі складові. Їх супроводжують керуючий та підтримуючий процеси, які стежать за тим, щоб все виконувалося так, як потрібно. Це і буде процесний підхід. Коли роботу одного елемента завершено, його напрацювання передаються наступному.

Опис бізнес-процесів

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

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

Порядок розробки

Давайте розглянемо практичний прикладбізнес-процесу для підприємства. Спочатку нам необхідно подбати про робочу команду проекту. Вона формується із співробітників компанії. Найчастіше виявляється, що однієї робочої команди недостатньо. Що тоді може бути зроблено? Для поповнення нестачі сил можна залучити тимчасову групу. Не завадить створити і опис того, як процес функціонує на даний момент часу. У цьому слід прагнути виявити всі зв'язки між діями, а чи не фіксувати дрібні подробиці.

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

Чому слід звернути увагу?

Слід зосередитися на наступних розділах:

1. Стандартні форми.
2. Карта.
3. Маршрути.
4. Матриці.
5. Блок-схеми.
6. Опис стиків.
7. Допоміжні описи.
8. Документування.
9. Розгорнутий опис.
10. Визначення індикаторів та показників.
11. Регламент виконання.

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

Про карти замовимо слово

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

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

Матриці

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

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

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

Навіщо застосовують блок-схеми?

Згадані системи покликані виконувати такі функції:

Розробляти новий процес;

Описувати та документувати поточний алгоритм;

Розробляти зміни до цього процесу або вивчити ланки з можливим появою помилок і збоїв;

Визначати коли, де і як можна змінювати поточний алгоритм, з метою перевірки стійкості всієї системи.

Розробка послідовності операцій

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

Типи алгоритмів

На практиці найчастіше застосовують наступні видиблок-схем:

Графічна, тобто в основі є геометричні символи;

Словесна: складається за допомогою звичайних слів тієї чи іншої мови;

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

Програмне забезпечення: Для запису використовуються виключно мови програмування.

Блок-схема пристрою: опис

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

Основні елементи, які вживаються при складанні блок-схем

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

Елементи блок-схеми:

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

2. Рішення. Цей блок застосовується для позначення переходу керування за певною умовою. У кожному такому елементі вказується питання, порівняння чи умова, що його визначає. Іншими словами, рішення - це вибір напряму для виконання програми чи алгоритму залежно від якогось змінної умови. Графічний вигляд цього елемента - це ромб. Згаданий символ може використовуватися як зображення наступних уніфікованих структур: вибір, повна і неповна розвилка, цикл «до» і «поки».

3. Модифікація. Цей блок означає початок циклу. Він застосовується в організацію циклічної конструкції. Всередині такого елемента записують параметр кола дій, вказують початкові значення, граничну умову, а також крок зміни параметра для подальшого повторення. Інакше кажучи, модифікація - це виконання мінливих команд чи його груп, операцій, змінюють програму. Графічне зображенняцього символу є шестикутник.

4. Зумовлений процес означає обчислення за заданою або стандартній програмі. Його використовують для вказівки звернення до допоміжного алгоритму, що існує автономно у вигляді окремих самостійних модулів, а також звернення до бібліотечних підпрограм. Графічно вигляд цього символу представлений прямокутником із двома вертикальними полями по краях. Цей елемент служить для вказівок звернень до функцій, процедур, програмних модулів.

5. Введення-виведення даних у загальному вигляді.

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

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

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

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

10. Лінії потоку – це стрілки, які вказують послідовність зв'язків. Жодна блок-схема структури неспроможна обходитися без цього елемента. Існують певні правилазображення цих символів. Перерахуємо їх:

Дані елементи повинні бути паралельними лініям зовнішнього периметра або межі сторінки, на якій зображена ця блок-схема;

Напрямок лінії зверху вниз або ліворуч праворуч вважається основним, стрілками воно не позначається, інші випадки вказівки напрямків позначені ними;

Зміна напрямку даного елемента провадиться тільки під кутом 90 про.

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

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

13. Коментар - це зв'язок між різними елементамиблок-схеми із поясненнями. Згаданий елемент дозволяє включати формули та іншу інформацію.

Побудова блок-схем

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

Масиви та побудова алгоритмів

Масив є сукупністю однотипної інформації, яка зберігається в послідовних кластерах пам'яті і має спільне ім'я. Такі осередки називаються "елементами системи". Усі кластери нумеруються по порядку. Такий номер називається "індексом елемента масиву". Як скласти блок-схему для такої системи? Розглянемо приклад створення алгоритму елементарного типу. Найпростіша системамає умовно вигляд рядка. Задамо ім'я для даного масиву – «А». Вважатимемо, що наша система складається з восьми осередків (від 1 до 8). Кожен із згаданих кластерів містить випадкове число, яке називається "елементом масиву". Для звернення в конкретному осередку необхідно вказувати ім'я (). Розглянемо приклад, у якому блок-схема масиву призначена заповнення системи випадковими числами з наступним виведенням інформації на екран. Що таке алгоритм? Це проста система. По суті вона не має практичного застосування, проте зручна для навчального процесу. Розглянута блок-схема (приклад побудови описаний нижче) містить лише сім основних елементів, з'єднаних лініями переходів.

Опис послідовності виконання завдання

1. Першим елементом схеми буде символ "Початок".

2. Другим блоком – «Процес», усередині якого вписуємо «ініціалізація random».

3. Наступний елемент – «Модифікація», в блоці вписуємо значення осередків масиву.

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

5. У цьому блоці «Модифікації», згідно з вписаною функцією, відбувається переадресація на наступний елемент.

6. «Висновок» відображає інформацію про новий вміст масиву на моніторі з наступним направленням на попередній блок. Далі – на останній елемент.

7. "Кінець" роботи алгоритму.

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

"Редактор блок-схем"

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

Висновок

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

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

Але чи потрібно проводити моніторинг кожного процесу? Чи потрібно встановлювати показники для кожного процесу? У які процеси вкладати кошти?
Ні і ще раз ні. Необхідна вибірковість. Насамперед необхідно стежити за собівартістю та витратами на збір даних. І насамперед моніторингу піддавати пріоритетні процеси. Як виділити пріоритетні процеси і як визначити які з процесів вимагають поліпшень, які реінжинірингу і які тільки підвищеної уваги? особливої ​​увагипотрібно виходити з наступних критеріїв:
1. Важливість процесу:
чим процес важливіший, тим більше уважно слідкувати за ним;
важливість процесу визначається важливістю його результатів.
-Показники: і результативність, і ефективність.
2. Результативність процесу – здатність процесу відповідати цілям, що вимірюються задоволеністю споживача процесу.
3. Ефективність процесу – витрати та терміни виконання.
Критерієм вибору є визначальне значення показників Щодо важливості найкращим суддею за визначенням є керівництво організації. Однак хоча керівництво і має визначати пріоритетність різних сфер діяльності та категорій споживачів чи інших зацікавлених осіб, у межах кожного класу споживачів чи інших зацікавлених осіб найкраще судити про відносну важливість того, що вони отримують від організації можуть самі споживачі чи інші. зацікавлені особи. Тому саме з них слід виміряти ступінь важливості.
! Само собою зрозуміло, рішення щодо остаточної оцінки результатів, зокрема, рішення щодо відносної важливості різних процесівсеред основних процесів корпорації, має приймати керівництво. Щодо показників суддею завжди має бути користувач результатів процесу.
Споживачі найкраще можуть судити про придатність до використання – і взагалі про відповідність очікуванням – виробів і послуг, які вони отримують.
Інші зацікавлені особи (акціонери, керівництво, працівники, ділові партнери, суспільство) також краще за інших можуть судити про якість того, що вони отримують.! Визначення відносної важливості різних категорій споживачів та інших заінтересованих осіб – це питання стратегії, отже, лежить на відповідальності керівництва.
Після цього слід залучити споживачів та інших заінтересованих осіб до визначення відносної важливості кожного елемента очікуваної якості.
-Внутрішній споживач для допоміжних процесів;
-Зовнішній споживач для процесів, спрямованих на ринок;
-Інші зацікавлені особи для процесів, спрямованих на них.
Іншими словами, споживачі та інші зацікавлені особи знають фактори, що викликають задоволеність, і як визначити їхню вагомість.
! Вище керівництво приймає кінцеве рішення про «затвердження» результатів процесу, в якому споживачі та інші зацікавлені особи визначали важливість (і доповнює її тим, що стосується її

Мене часто запитують – що почитати про бізнес-процеси?
Одним з найкращих сайтів на просторах рунету є www.klubok.net. Я сам "виріс" на форумі та статтях цього сайту. Багато статей не втратили актуальності і зараз. Почати вчитися рекомендую саме з нього.

А от якщо говорити про книги - то впевнено можу сказати найкраща книгапро бізнес-процеси - це книга, написана Рєпіним та Єліферовим: "Бізнес-процеси компанії. Побудова, аналіз, регламентація".

Опис бізнес-процесів: прагнення простоти.

У статті розглянуто питання щодо вибору нотації для опису процесів з метою подальшої регламентації. Порівнюються між собою нотації Work Flow, що часто використовуються, такі як: «Проста блок-схема» в MS Visio, «Процедура» Business Studio, нотація ARIS eEPC та інші.

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

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

Вступ

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

Порівняння нотацій

Для порівняння було обрано наступні нотації опису процесів:

1. "Проста блок-схема" (з відображенням руху документів, з використанням блоку "Рішення");
2. «Проста блок-схема» (без відображення руху документів, без використання блоків «Рішення»);
3. «Процедура» системи Business Studio (один із можливих варіантівуявлення);
4. ARIS eEPC.

Як тестовий приклад було обрано простий та інтуїтивно зрозумілий процес. Результати опису цього процесу представлені на рис. 1-4.

Мал. 1. Схема процесу у нотації «Проста блок-схема» у MS Visio (з рухом документів, з використанням блоку «Рішення»).

На схемі рис. 1. Послідовність виконання операцій процесу у часі показано з допомогою жирних стрілок, а рух документів - з допомогою тонких пунктирних стрілок. Блоки "Рішення" використані класичним чином. Вони відображають інформацію (питання), від яких «залежить» подальший перебіг процесу. Такий підхід до використання «ромбиків» дуже поширений. Але фактично, вся логіка прийняття рішень та формування тих чи інших виходів (документів) має полягати всередині операцій процесу. Якщо замислитись, то цінність (сенс) малювання цих «ромбиків» не є очевидною. Що це за об'єкти: операції процесу, події? Начебто ні те, й не інше. Це швидше оператори ухвалення рішення за якоюсь умовою. Але ж ми розробляємо схему процесу для людей, а не пишемо комп'ютерну програму спеціальною мовою. У комп'ютерної програми«ромбик» був би повноцінною операцією порівняння умов тощо. Але на схемі процесу потрібно показувати реальні об'єкти - процеси, що виконуються людьми, документи, інформаційні системиі т.п. Подумайте, чи правильно показувати «ромбики» окремо від операції процесу на схемі? Натомість можна:

а) описати логіку прийняття рішення у вигляді послідовності операцій на схемі аналізованого процесу;
б) описати логіку у вигляді схеми кроків відповідного підпроцесу, переходячи до рівня нижче;
в) описати логіку текстом (у текстових атрибутах операції) й надалі вивести регламент виконання процесу.

Сформулюємо «плюси» та «мінуси» розглянутого вище (рис. 1) способу використання «ромбиків».

"Проста блок-схема" в MS Visio (з рухом документів, з використанням блоку "Рішення")
«Плюси»	«Мінус»
Наочне відображення "логіки" вибору тих чи інших виходів процесу. Акцентування уваги виконавця на точку прийняття рішення/розгалуження процесу в залежності від умов.	Винесення логіки прийняття рішення «назовні» операції процесу (некоректно з погляду формальної декомпозиції процесів). Незручно документувати процес (доводиться дублювати «ромбики» текстом для формування текстового опису операції). Схема процесу стає інформаційною перевантаженою. "Ромбики" часто використовуються надто формально, без реальної необхідності.

На рис. 2. показаний приклад того самого процесу, тільки описаного без використання блоків «Рішення» і документів. Легко перевірити, що на цій схемі на 24 графічні елементи менше, ніж на схемі рис. 1. Схема рис. 2. виглядає набагато простіше. Від графічних елементів не рябить в очах, а з погляду інформативності, ця схема цілком зрозуміла і доступна кінцевому користувачеві. Якщо кожної операції процесу описати вимоги до її виконання текстом, то комбінуючи табличну і графічну форми подання, можна цілком адекватно описати порядок виконання процесу співробітникам компанії.

Мал. 2. Схема процесу в нотації "Проста блок-схема" в MS Visio (без руху документів, без використання блоку "Рішення").

«Плюси» та «мінуси» графічного представлення процесу у формі, представленій на рис. 2., показано нижче.

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

На рис. 3. представлена ​​схема процесу, сформована у нотації «Процедура» середовища моделювання Business Studio. Схема має кілька особливостей. По-перше, блоки «Рішення» використано не стандартним чином – не як графічний елемент для відображення питання та розгалуження, а як повноцінна операція процесу, пов'язана з прийняттям рішень. У Business Studio «ромбік» має багато атрибутів повноцінного процесу, але не може бути декомпозований (можливо, розробники системи з часом зроблять таку можливість). Використання «ромбика» (замість чотирикутника) робить схему наочнішою. При цьому до атрибутів «ромбика» можна внести будь-яку текстову інформацію: опис, початок, завершення, вимога до термінів тощо.

Друга особливість схеми процесу, представленої на рис. 3. є застосування стрілок. Для відображення послідовності операцій можна використовувати стрілку з одним наконечником – стрілку «попередження». Для відображення руху документів можна використовувати стрілку із двома наконечниками. Але саме в Business Studio можна скористатися тільки одним типом стрілок - стрілками «попередження». При цьому до іменованих стрілок можна прив'язувати необхідна кількістьдокументів, визначених у довіднику об'єктів діяльності. Такий підхід дає можливість:

• суттєво скоротити кількість графічних елементів на схемі процесу, і при цьому:
• вивести в регламент процесу необхідну інформацію про вхідні та вихідні документи.

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

«Плюси» та «мінуси» графічного представлення процесу у формі, представленій на рис. 3., показано нижче.

Мал. 3. «Процедура» системи Business Studio (варіант із нетрадиційним використанням блоків «Рішення»).

У разі застосування Business Studio нотація «Процедура» може бути використана дещо по-різному. Автор статті схиляється до підходу, наведеного на рис. 3.

На рис. 4 представлена ​​схема аналізованого процесу, розроблена в нотації ARIS eEPC. Зауважимо, що у схему не помістилися деякі операції процесу. Ця неповна схема найпростішого процесу, виконана в нотації ARIS eEPC, містить чотири оператори логіки та вісім подій! Співробітник, який читає схему, має вміти правильно інтерпретувати всі ці логічні оператори. Без спеціального навчання та наявності деяких навичок читання подібних схем, рядовий співробітник навряд чи зможе зрозуміти логіку процесу без докладного текстового опису або допомоги кваліфікованого бізнес-аналітика.

Зауважимо, що схема процесу в нотації ARIS eEPC займає суттєво більше місця, Чим схеми, представлені на рис. 1-3. Трудомісткість формування такої схеми так само суттєво вища.

Схема процесу в нотації ARIS eEPC (побудована у Business Studio)
«Плюси»	«Мінус»
p align="justify"> При формуванні схеми витримується строга, формальна логіка процесу. Чітко визначено всі події, що виникають у процесі.	Складність сприйняття. Значна трудомісткість формування схеми. У співробітників мають бути спеціальні навички та досвід інтерпретації подібних схем. Інформаційна надмірність. Займає дуже багато місця, що незручно для документування.

Загалом, якщо Ви не збираєтеся купувати SAP R/3, то вибір та використання нотації ARIS eEPC не є, з погляду автора статті, оптимальним рішенням. Варто звернути увагу на наочніші та інтуїтивніше зрозумілі виконавцям нотації опису процесів. Втім, комусь нотація ARIS eEPC може здатися наочнішою і зрозумілішою. До певної міри це питання смаку.

Мал. 4. Схема процесу в нотації ARIS eEPC (побудована Business Studio).

Опис процесу з метою подальшої автоматизації

Цікаво подивитися на схему процесу, що розглядається, у разі, якщо вона описана в нотації BPMN 2.0. Ця нотація варта опису «виконуваних» процесів, тобто. процесів, які підтримує система BPM.

Своєю думкою про використання BPMN 2.0. ділиться А.А. Білайчук - Генеральний директоркомпанії «Бізнес-консоль»:

На рис. 5 зображено той же процес у нотації BPMN. Як бачимо, цей малюнок схожий на рис.1: у нотації BPMN завдання зображуються прямокутниками, розвилки - ромбами, дані - піктограмою, схожою документ. Потоки управління – суцільні лінії, потоки даних – пунктирні. Треба враховувати, що на цій діаграмі задіяна лише мала частина нотації BPMN: тільки один вид розвилок з 5 наявних на палітрі, один вид задач з 8. , що взаємодіють один з одним через повідомлення або дані. Крім того, ця нотація суворіша: у ній визначені не тільки значки, а й правила, за якими вони можуть поєднуватися один з одним. Необхідність таких правил диктується тим, що нотація BPMN орієнтована не лише на те, що її читатимуть люди, а й на безпосереднє виконання спеціальним. програмним забезпеченням- «Двигунком» BPM-системи. У той же час, як свідчить даний приклад, При використанні обмеженого підмножини палітри BPMN виявляється не складніше звичної блок-схеми. Ну а тим, хто хоче освоїти BPMN професійно, ми рекомендуємо спеціалізований тренінг www.bpmntraining.ru.

Мал. 5. Схема процесу у нотації BPMN 2.0.

Практика життя

На рис. 6 показаний фрагмент схеми процесу, розроблений бізнес-аналітиками цілком конкретної компанії у вигаданій ними нотації. Схема побудована із застосуванням принципів «Простий блок-схеми» - застосовується блок «Рішення» у своєму класичному варіанті. Крім цього, на схемі представлено безліч інших умовних позначень, використаних не зовсім стандартним чином.

p align="justify"> При формуванні схеми рис. 6, бізнес-аналітики очевидно, «боролися» за наочність та максимальну зрозумілість для пересічного користувача. Вони прагнули звести до мінімуму або взагалі відмовитися від текстового коментаря до схем процесів. Виконавцям просто друкувалася схема формату А3, під час читання якої все одразу ставало зрозуміло: що робити, як, які документи використовувати тощо.

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

Висновки

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

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

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

В.В. Рєпін, к.т.н., доцент, Виконавчий директор ТОВ «BPM Консалтинг Груп», зав. кафедрою Управління бізнес-процесами НОУ ВПО «ІЕФ «Синергія», засновник порталу www.FineXpert.ru

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

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

Перед тим, як почати описувати бізнес процеси, необхідно . компанії – платформа, з якої потрібно починати.

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

Схема бізнес процесу – інструкція для нетерплячих

1 – Встановіть межі процесу

Кожен бізнес процес починається та закінчується з події. Перше, що необхідно зробити, це позначити події початку та закінчення.

2 – Намалюйте основні блоки процесу

Розташуйте основні блоки (підпроцеси, операції) у тому порядку, в якому вони виконуються.

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

3 – Додайте розвилки та інші події

А ось тепер настав час трохи ускладнити. Додайте основні варіанти розвитку процесу та основні проміжні події. Доповніть схему відсутніми операціями.

4 – Позначте ролі учасників процесу

У бізнес-процесах немає посад або конкретних співробітників. Натомість використовується поняття – роль. Одні співробітник може виконувати багато ролей. Одну роль може виконувати багато співробітників. З набору ролей складається посада.

За потреби додайте відсутні операції.

5 – Розмістіть на схемі документи

Документ, це не обов'язково офіційний папір із сімома підписами. З точки зору управління бізнес-процесами, документ це інформація на будь-якому інформаційному носії. Електронний лист, доповідь, презентація, СМС – це документи.

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

6 – Додайте використовувані програми та бази даних

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

7 – Розташуйте інструменти та матеріали

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

8 – Визначте показники ефективності у бізнес-процесі

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

9 – Зв'яжіть отриману схему з іншими процесами

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

10 – Перевірте отриману модель бізнес-процесу

У принципі схема готова. Схема бізнес-процесу має відповідати на такі питання:

• З чого починається і чим закінчується бізнес-процес?
• З якими процесами він пов'язаний? Чим обмінюється?
• Які операції виконуються? В якому порядку?
• Хто виконує операції у процесі?
• Які документи використовуються та з'являються у процесі? У яких операціях ці жокументи використовуються/з'являються?
• Які інструменти, матеріали, ПЗ та бази даних використовуються в процесі та в яких операціях?
• Які показники ефективності та де саме фіксуються у бізнес-процесі?

Якісно підготовлена ​​схема має бути простою для сприйняття і досить інформативною.
Схема бізнес-процесу має бути зрозумілою «людині з вулиці».
Схема бізнес-процесу, на етапі опису, повинна відображати те, як процес виконується в реальному житті.

Даний алгоритм дозволить вам досить просто і швидко описати необхідні бізнес-процеси. Далі я докладно розповідатиму про опис бізнес-процесів. Залишайтеся на зв'язку.