Шаблони організаційного бізнес-моделювання 2 страница

На нашу думку, наскрізний процес, також як і процес підрозділу, повинен обов'язково мати власника процесу. У його розпорядженні повинні знаходитися ресурси, необхідні для виконання процесу.

 

Рис 1. Наскрізний (міжфункціональний) процес

 

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

Особливості виділення процесів в організації та об'єднання їх в одну мережу.

Процес включає:

1. Власника процесу - посадовця, що має у своєму розпорядженні ресурси процесу, з певними правами, зоною відповідальності і повноваженнями;

2. Технології процесу - порядку виконання діяльності з перетворення входів у виходи;

3. Системи показників процесу - показників продукту, показників ефективності процесу, показників задоволеності споживачів;

4. Управління процесом - діяльність власника процесу з аналізу даних про процес і прийняттю управлінських рішень;

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

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

· Які процеси повинні бути в організації?;

· Де знайти список «обов'язкових процесів»?;

· Скільки процесів має бути в організації?;

· Хто такий «власник процесу» і які у нього права та обов'язки?;

· Як забезпечити взаємозв'язок процесів організації в єдину мережу?.

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

2. Класифікація процесів в організації.

По участі в додаванні якості до продукції/послуг процеси можна розділити на дві основні групи: основні і допоміжні.

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

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

Існують також і інші погляди на класифікацію процесів. Наприклад, в методології системи BAAN (BAAN Orgware) виділяється чотири, так звані, «категорії стратегічних моделей» в які входять всі процеси компанії.

- Модель фінансового управління (погляд на бізнес з погляду руху фінансових коштів).

- Маркетингова модель (оцінка впливу зовнішнього середовища на аналізований бізнес).

- Модель управління виробництвом.

- Модель управління логістикою (постачання і збут).

Всі процеси за методологією BAAN Orgware поділяються на основні і детальні.

· Основні процеси (main) - є специфічними для певного типу організації і визначаються з контрольної моделі потоку товарів.

· Детальні процеси - мають загальну природу, можуть застосовуватися в різних типах організацій.

Методологія пропонує наступний перелік детальних (загальних) процесів:

- Manufacturing - виробництво;

- ВА - Basic Data Process -основні дані;

- Sales Process - процес продажів;

- Purchasing- закупівлі;

- Planning (all resources) - планування;

- Finance - фінанси;

- Service - обслуговування;

- Warehousing - зберігання на складі;

- Engineering - конструювання;

- Formula Management - управління формулами;

- System Management - управління пристроями;

- Project Industries - проектні виробництва:

- Project Services - обслуговування проектів;

- Product Batch Management - управління упаковкою продукції;

- Quality Inspection - перевірка якості;

- Quality Management - управління якістю;

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

Для того щоб працювати з процесами, необхідно з'ясувати наступні моменти:

· з чого вони складаються;

· які існують засоби опису та документування;

· кого призначати відповідальними;

· як аналізувати ефективність того чи іншого процесу.

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

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

Так само виділяються основні і допоміжні процеси для організації.

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

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

 

 

3. Розмір і число процесів

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

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

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

· лінійно - функціональні;

· дивізіональні;

· матричні.

Правило 2. Розмір процесу повинен бути не менше, ніж величина об'єкта управління (підрозділу), для якого складається документований план.

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

· стратегічні (довгострокові), що розробляються на термін від 1 року і більше;

· поточні (оперативні), що розробляються на строк до 1 року з розбивкою по кварталах і / або місяцях;

Оскільки плани розробляються в організації за напрямами діяльності, вони повинні:

· бути ув'язані (скоординовані) між собою за термінами і використовуваних ресурсів;

· доведені до відома керівників, відповідальних за управління роботи;

· контролюватися і переглядатися по мірі їх виконання.

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

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

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

Правило 4. Розмір процесу, чисельність співробітників в ньому повинні бути досить великими, щоб створення такого комплекту було економічно доцільним.

Для управління процесом необхідно створення повноцінного комплекту документації. У нього входять: регламент процесу, посадова інструкція власника процесу і, як мінімум, документація з виконання технології процесу виконавцями. При побудові в організації системи процесного управління, дуже легко можна втопити здоровий глузд управлінської діяльності у великій кількості паперів.

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

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

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

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

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

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

Варіант 1 - вимагає створення 3 ЦФУ

Процес 1 Процес 2 Процес 3

Оп 1 Оп 2 Оп 3 Оп 4 Оп 5 Оп 6 Оп 7 Оп 8 Оп 9 О п 10

 

0 1 2 3

 

Варіант 2 - вимагає створення 4 ЦФУ

Оп 1 Оп 2 Оп 3 Оп 4 Оп 5 Оп 6 Оп 7 Оп 8 Оп 9 Оп 10

 

0 1 2 3 4

Рис.2. Два варіанти виділення процесів залежно від ланцюжка перетворення продукту (додавання цінності)

 

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

Для вирішення цього питання необхідно взяти до уваги два фактори:

а) хто відповідає за передачу напівфабрикату або кінцевого продукту на наступний етап або клієнта;

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

Якщо відповіді на ці питання різняться, то доведеться робити вибір на користь одного з керівників. У першому наближенні можна:

· обмежити виділення процесу межами структурних підрозділів, ґрунтуючись на зоні відповідальності власника процесу як адміністратора;

· встановити межі процесу за правилом Парето 80: 20- у процесі повинне виконуватися не менше 80% обсягу робіт по перетворенню входу у вихід.

Правило 7. Кількість процесів, що знаходяться в підпорядкуванні у одного власника, не повинно перевищувати типові норми керованості.

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

У свою чергу норма керованості накладає обмеження на кількість процесів, якими в змозі управляти керівник: їх теж може бути не більше 7-9 в одного власника. Чим вище по ієрархічній драбині керівник, тим складніше управління і тим менше напрямків має бути в його підпорядкуванні. Навпаки, чим нижче рівень керівництва, тим більше підлеглих може бути у керівника. Наприклад, вчителька в класі керує однотипними діями 25 учнів, а у генерального директора сучасного великого підприємства повинно бути не більше 4-5 безпосередньо підлеглих йому заступників.

На рівень норми керованості впливають:

· ступінь інформатизації підприємства;

· ступінь делегування підлеглим прав і повноважень;

· рівень компетентності керівника і підлеглих;

· складність управлінських завдань і розміри об'єктів управління (процесів).

Для того, щоб призначити власника процесу, необхідно відповісти на ряд питань:

1. Хто отримує планові завдання і несе відповідальність за результат процесу (продукт) перед наступним рівнем керівництва?

2. Хто має в своєму розпорядженні і управляє ресурсами та інформацією по процесу?

3. Хто відповідає за організацію робіт по процесу, визначає технологію робіт (операції)?

4. Хто організовує систему збору інформації про хід процесу?

5. Хто веде моніторинг (контроль і аналіз) ходу процесу?

6. Хто відповідає за реалізацію заходів щодо підвищення ефективності процесу?

Менеджер, що задовольняє всім зазначеним вище умовам, може розглядатися в якості претендента на посаду власника процесу.

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

Застосування правил виділення процесів.

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

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

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

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

Покрокове виділення процесів в організації.

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

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

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

· Ланцюг перетворень може виходити за межі підрозділу. Наприклад, документ може тимчасово потрапляти в інші підрозділи для узгодження будь-яких рішень з іншими керівниками, повертатися після узгодження або проходити кілька ітераційних циклів погодження;

· У ході робіт може бути використана додаткова інформація (входи), яка надходить від інших підрозділів;

· У підрозділах можуть паралельно або послідовно проводитися декілька перетворень різних продуктів.

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

Крок 1. Виділення процесів

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

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

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

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

· залежно від розмірів організації власниками процесів можуть бути призначені заступники директора (для невеликої організації 300-500 чоловік) або керівники середнього рівня, якщо чисельність організації перевищує 1000 чоловік.

Всі наведені дані про чисельність співробітників, діяльність яких можна віднести до процесу, поки не мають строгого математичного або наукового обґрунтування. Ці дані з'явилися на основі практичного досвіду впровадження в організаціях процесного підходу до управління.

Крок 2. Регламентація процесів.

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

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

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

На другому кроці проводиться перегляд і узгодження взаємодій між підрозділами. Складені раніше формальні документи мають отримати нове, реальне наповнення. Документація повинна стати корисною для керівників і співробітників. З досвіду роботи в організаціях цей крок є найбільш болючими для керівників. Виникає кілька типових управлінських проблем:

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

2. Документування взаємин між процесами призводить до «перетягування ковдри (ресурсів)» один у одного або до «перекладання відповідальності» один на одного і як наслідок цього, до конфліктів;

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

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

Крок 3. Оптимізація процесів

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

 

Тема 3. Опис бізнес-процесів

 

1. Рівні опису процесів (декомпозиція).

2. Цілі опису бізнес-процесів.

3. Способи опису бізнес-процесів.

4. Вертикальний і горизонтальний опис бізнес-процесів.

5. Етапи опису бізнес-процесів.

6. Стандарти опису бізнес-процесів.

7. Правила, що застосовуються при описі бізнес-процесів.

8. Формати і засоби опису бізнес-процесів.

1. Рівні опису процесів (декомпозиція).

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

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

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

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

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

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

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

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

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

2. Цілі опису бізнес-процесів.

Опис бізнес-процесів проводиться для наступних цілей:

· Документування і оптимізація побудови бізнесу.

· Розробка нових схем ведення бізнесу.

· Розробка IT системи.

· Розробка регламентуючих документів.

3. Способи опису бізнес-процесів.

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

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

Недоліком текстового опису є:

· труднощі сприйняття інформації;

· неможливість структурованого опису складних процесів;

· непридатність до застосування "просунутих" методів аналізу та оптимізації.

Найбільш прийнятним є комбінований спосіб опису, коли графічна інформація супроводжується текстовими коментарями.

Сім золотих правил опису бізнес-процесів:

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

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

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