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