Деталізація документованих описів процесів: як поєднати керованість і гнучкість
Тарас Калита, директор Центру систем якості «Прирост-Система».
Одним з важливих питань, які виникають під час розробки документованих описів процесів, є визначення рівня їх деталізації. Це питання особливо важливе для організацій, які не розробляють формальну систему управління якістю з єдиною метою - отримання сертифіката (у цьому випадку якраз все зрозуміло - розробляється мінімальний обсяг документів, що влаштує орган із сертифікації), але які намагаються по-справжньому ввести процесний підхід . Адже мова йде не тільки про розміри документа (кілька сторінок або кілька десятків), а про те, наскільки жорсткими будуть рамки, в яких працюють виконавці процесів.
Для того, щоб проілюструвати цю проблему, розглянемо декілька поширених ситуацій, що виникають в організаціях після розробки документованих описів процесів (хоча ця діяльність в організаціях частіше називається словами «розробка системи управління якістю за стандартом ISO 9001», надалі в статті акцент буде робитися не на вимогах стандарту, а на принципах процесного підходу).
Перша ситуація. В організації розроблені документи з дуже низькою деталізацією, що визначають лише ключові етапи процесу, не заглиблюючись у його суть. Головна реакція персоналу на ці документи така: ми не розуміємо, навіщо вони розроблені, вони не несуть ніякої додаткової користі чи інформації; ми всі це знали і робили і раніше; раніше ми це робили без них, а тепер з ними - більше нічого не змінилося . Виходячи з цього, співробітники роблять висновок: процесний підхід не має ніякого відношення до реальної роботи, все до чого він зводиться - це розробка незрозумілих документів. Одне з головних «переваг» цієї системи - те, що вона практично не створює проблем для організації, існуючи окремо від реальних робочих проблем.
Навіть витрати ресурсів на підтримку її актуальності мінімальний, адже такі мало деталізовані документи практично не потребують змін - на цьому рівні діяльність організації досить стабільна.
Друга ситуація. В організації розроблена дуже детальна документація, яка чітко регламентує кожен крок виконання процесу. Але її впровадження призвело до несподіваних результатів:
Співробітники скаржаться, що вони тепер виступають тільки в ролі виконавців інструкцій, що зменшилася можливість для творчості; як наслідок - знижується вмотивованість співробітників та їх відповідальність за кінцевий результат роботи;
Споживачі скаржаться, що організація стала менш гнучкою, гірше реагує на їхні нестандартні запити і особливі ситуації, що проблеми, які раніше вирішувалися оперативно і неформально тепер чи не вирішуються зовсім (вони не відображені в описах процесів), або вирішуються через складну і довгу процедуру;
Керівництво відчуває, що організація втратила гнучкість, гірше і повільніше реагує на нові можливості, якщо вони не задокументовані в описах процесів.
Третя ситуація. Організація розробила велика кількість дуже детальних документів.
Виходячи з різних причин, вона розглядає можливість її скорочення (або з міркувань, наведених в другій ситуації, або просто тому, що підтримувати в робочому стані такий обсяг документації занадто складно).
Але будь-які спроби вилучити якусь інформацію із документів, скоротити або спростити їх наштовхуються на контраргумент: ця інформація є цінною, вона відображає наш узагальнений досвід за багато років, уроки, витягнуті з наших помилок, її не можна чіпати.
Основні принципи рішення
Головний висновок, який можна зробити з розгляду цих ситуацій: це те, що питання дійсно існує, що організація повинна усвідомлювати його і шукати на нього відповідь. Безумовно, гіршим варіантом є той, за якого ніхто не задає собі питання, якими мають бути ці документи: які вийшли, такі й будуть. Детальність документів слід свідомо проектувати так само, як і всі інші важливі характеристики системи (структуру процесів, структуру документів, структуру планів та цілей і т.п.).
Зауважимо, що вищесказане не означає, що рівень деталізації повинен визначатися на рівні системи і бути однаковим для всіх процесів. Відповідне рішення повинні приймати власники процесів, адже документовані описи - це їх інструмент для реалізації своєї відповідальності за результати процесів. Але, по-перше, самі власники процесів повинні свідомо проектувати рівень деталізації документів, по-друге, можуть існувати загальносистемні обмеження з цих питань (причому, як зверху, так і знизу).
Другий очевидний висновок з аналізу наведених ситуацій: це те, що ми маємо справу з дилемою, коли в обох варіантів є як свої переваги, так і недоліки. Як і для будь-дилеми, для її рішення можна використовувати два підходи: або вибрати компромісний варіант, який дозволяє частково використовувати переваги обох варіантів, частково знівелювавши їх недоліки, або шукати «третє» нетрадиційне рішення, яке дозволить повною мірою зберегти сильні сторони обох варіантів .
Можливий компромісний варіант для дилеми щодо деталізації описів процесів очевидний - розробити документи з «середнім» рівнем деталізації. Не будемо зупинятися на ньому, вкажемо лише аспекти, які потрібно врахувати при виборі цього оптимального середнього рівня:
Складність процесу, ризики виникнення помилок при його виконанні;
Важливість процесу, можливі наслідки виникнення помилок (як для самої організації, так і для її зацікавлених сторін);
Необхідність забезпечення гнучкості при виконанні процесу, реагування на непередбачені зовнішні можливості або ризики;
Стабільність процесу, частота внесення змін до порядку його виконання і важливість цих змін (це питання буде детально розглянуто нижче; чим частіше вносяться зміни, тим більшою може бути потреба в детальному документі);
Рівень кваліфікації виконавців процесу (і можливість підтримувати його в майбутньому, зокрема - рівень плинності серед виконавців);
Рівень мотивованості виконавців процесу (наскільки вони будуть використовувати надану їм свободу дій для вибору оптимальних варіантів з точки зору організації або найпростіших варіантів зі своєї точки зору).
Що стосується «більш глибокого» оптимального рішення, то воно повинно зберегти і поєднати переваги обох підходів: забезпечити можливість детального визначення процесу (для управління ним, збереження знань, навчання) і, в той же час, гнучкість у його виконанні і зацікавленість персоналу у пошуку найкращих шляхів виконання. Повинна бути забезпечена «гнучка стандартизація» або «гнучка деталізація» описів процесів.
У традиції, прийнятої у вітчизняних організаціях, поняття «стандартизація» і «гнучкість» є протилежними. Можливо, таке подання пішло ще від радянських ГОСТів: мовляв, стандарти є дуже негнучкими, рідко переглядаються і можуть застаріти ще до перегляду, і сприймаються як зовнішня даність, на яку організація не має ніякого впливу.
Але існує й протилежний погляд, при якому стандартизація не є протилежністю гнучкості й удосконалення, а їх обов'язковою умовою. Адже якщо процес виконується за незмінною схемою протягом тривалого часу, потреба в детальному описі цієї схеми мінімальна: виконавці і так вивчать цю схему, а всі неузгодженості «притруться» в процесі роботи. Якщо ж порядок виконання процесу змінюється регулярно, то буде дуже проблематично забезпечити його ефективність без стандартизації. Очевидно, що детальний опис процесів потрібно для того, щоб забезпечити оперативне впровадження змін: можливість швидкого навчання персоналу новою схемою роботи та ефективного контролю за тим, щоб його робота відповідала новим вимогам. При частих змінах процесу організація просто не має можливості чекати, коли виконавці вивчать новий порядок роботи «на практиці», за цей час він сам може встигнути застаріти. Менш очевидним, але не менш важливим фактором є те, що необхідність відображення змін до документированном описі процесу вимагає глибокого аналізу нового порядку роботи, перевірки його узгодженості, обговорення всіх можливих проблем - ще на етапі підготовки до впровадження змін. А прийняття рішення про зміни без такого попереднього обговорення - це необхідність витрачати значний час на виявлення проблем та пошук шляхів їх усунення вже після впровадження. Коротше кажучи, зміни в порядок виконання процесу вносяться значно легше, якщо є конкретний документ, до якого можна ці зміни записати.
Для того, щоб документовані описи процесів дійсно запрацювали в користь гнучкості та удосконалення підходів, потрібно змінити їх сприйняття персоналом і керівництвом. Вони повинні сприйматися не як обмеження, які нав'язуються виконавцям процесів, а як відбиття найкращою існуючої практики виконання робіт (визначення, найбільш поширене в Японії). Але очевидно, що подання про найкращий варіант виконання робіт постійно змінюється, у міру накопичення нового досвіду - саме в цьому і полягає організаційне навчання, - відповідно, повинні змінюватися і опису процесів. З цієї точки зору, якщо опис процесу залишається незмінним протягом тривалого часу, це свідчить про те, що власник процесу не повною мірою виконує свої функції: не аналізує накопичений досвід і не використовує його для виділення кращої практики, яку потрібно стандартизувати, або можливих ризиків, які слід запобігати. Можна сказати, що при такому підході стандарти існують не для того, щоб їх виконували не замислюючись, а для того, щоб їх переглядали.
Звичайно, для того, щоб описані принципи працювали на практиці, потрібно, щоб внесення змін у документ, що містить опис процесу, було простим і оперативним. Інакше виявиться, що виконавцям простіше або взагалі не намагатися вдосконалювати процес (тоді опису процесів перетворяться на гальмо для розвитку організації), або удосконалювати порядок роботи, не відбиваючи його в документах (тоді вони перетворяться на купу застарілих паперів). Умов для простого внесення змін в опис процесів є два: проста і зручна процедура перегляду документів, а також форма документів, яка спрощує внесення змін.
Нижче наведені можливі рішення для впровадження вищеописаних принципів в діяльність організації.
Багаторівневі процеси
Безумовно, одним з головних чинників, які роблять зміни в описах процесів ускладненими і розтягнутими в часі, є необхідність затверджувати їх на рівні вищого керівництва організації (як правило - особисто першого керівника). При тому, що далеко не завжди перший керівник має можливість і бажання дійсно аналізувати зміст документа, ефективність запропонованої схеми виконання процесу. Якщо ж опис процесу є дуже детальним, він може містити такі деталі, в які першому керівнику дійсно немає сенсу вникати.
Альтернатива такому підходу зрозуміла: повинна існувати багаторівнева структура документів, які затверджуються керівниками різних рівнів самостійно. На першому етапі така структура може бути хоча б дворівневої - більш загальний опис процесу, яке затверджується першим керівником, і його деталізований опис, яке затверджується власником процесу. При цьому в першому описі визначаються вимоги щодо виконання процесу, висунуті першим керівником і які є важливими для нього - їх виконання він готовий контролювати особисто. У другому, деталізованому описі, власник процесу визначає, як саме він буде реалізовувати вимоги вищого керівництва, як він буде організовувати процес, щоб забезпечити досягнення поставлених перед ним цілей. Такий підхід дозволяє більш гнучко керувати порядком виконання процесу і вносити зміни в документи, в яких він описаний. Крім того, він сприяє більш чіткому визначенню ролі власника процесу, визначення його повноважень та їх розмежування з повноваженнями першого керівника. Якщо детальніше розглянути співвідношення цих документів, можна виділити такі ситуації:
певна діяльність взагалі не регламентована в загальному описі процесу і описується тільки у деталізованому (наприклад, перший керівник не цікавиться тим, як саме проводиться вивчення очікувань споживачів, все що його цікавить, це вимоги до виходу процесу - отримання двічі на рік звіту, що містить певний обсяг інформації; схему збору цієї інформації описує власник процесу в деталізованому описі);
певна діяльність позначена в загальному описі і не розкривається у деталізованому (перший керівник визначив в загальному описі, що двічі на рік має проводитися анкетування 50 найбільших споживачів та перелік питань для нього узгоджується на нараді зі стратегічного розвитку; власник процесу вирішив, що цієї інформації достатньо для нього і вона не потребує додаткової деталізації);
певна діяльність позначена в загальному описі та розкрито власником процесу в детальному (перший керівник визначив, що двічі на рік має проводитися анкетування ключових споживачів за узгодженою анкеті і подаватися звіт; власник процесу вирішив, що для успішного виконання цієї роботи йому потрібно детально описати порядок розробки анкет , формування вибірки споживачів, поширення анкет і контролю їх повернення тощо);
певна діяльність позначена в загальному описі, воно ж містить вимоги щодо її конкретизації і уточнення в детальному описі (перший керівник визначив, що двічі на рік проводиться анкетування ключових споживачів і вказав, що власник процесу повинен визначити та задокументувати в детальному описі порядок складання анкет, їх поширення і контролю надходження).
Надалі, така дворівнева структура документів може розвиватися до багаторівневої. Оптимальним шляхом для реалізації цього є поглиблення процесного підходу: визначення процесів нижчих рівнів, їхніх меж і власників. Звичайно, можна створити систему, в якій детальні описи складових елементів процесу розробляються і переглядаються керівниками відділів, цехів, дільниць. Але буде більш ефективно, якщо ці роботи виконуватимуть ті ж люди, але з повноваженнями власників процесів нижчих рівнів. Принципова схема залишається тією ж: власник процесу вищого рівня визначає вимоги до порядку виконання робіт, які він вважає обов'язковими, а власники процесів нижчого рівня розвивають і уточнюють їх, визначають, як саме вони будуть їх виконувати. В ідеалі, така схема має бути поширена на керівників усіх рівнів. Звичайно, вона буде вимагати суттєвого перегляду ролі керівників нижчих рівнів: вони повинні бути не тільки диспетчерами, які доводять до підлеглих рішення вищого керівництва, і наглядачами, що забезпечують та контролюючими виконання цих рішень, а справжніми керівниками, у яких є зрозумілі повноваження і які відповідають за їх ефективну реалізацію.
Згадаймо вищенаведене визначення процесу як найкращої існуючої практики виконання певних робіт. Накопичення знань в процесі виконання роботи, пошук шляхів її удосконалення, виділення найбільш ефективних методів виконання роботи і забезпечення їх застосування - усе це має бути невід'ємною функцією кожного керівника. І найкращим чином ці функції можуть бути реалізовані, якщо керівник є «власником» документа, що визначає детальний порядок виконання роботи в області його відповідальності і може самостійно вносити в нього зміни (в рамках, визначених у документах, затверджених керівниками вищих рівнів). А найкращим шляхом для узгодження таких документів, що ведуться багатьма керівниками на різних рівнях, є застосування процесного підходу з чітким визначенням і узгодженням меж і цілей процесів, їх входів і виходів (а відповідно - внутрішніх споживачів і постачальників, з якими потрібно узгоджувати зміни).
При такому підході постійний перегляд відповідного документа стає не просто повноваженням, а обов'язковою функцією керівника (точніше, відображенням того, що він виконує свою функцію накопичення і застосування нових знань про процес). І тут вже можна сказати, що якщо керівник, який є власником процесу певного рівня, протягом тривалого часу не вносив змін до документований опис цього процесу, до неї має виникати питання - чи виконує він функцію власника процесу.
Звичайно, для ефективної роботи описаної схеми, важливо щоб форма документів спрощувала внесення змін до них (включаючи забезпечення узгодженості різних документів: як «по горизонталі» між документами одного рівня, які описують суміжні процеси, так і «по вертикалі» між документами різних рівнів, які описують один процес). Оптимальним здається використання простої, графічної структури документів (у вигляді блок-схем, таблиць, можливо - малюнків).
Особливо зручним може бути подання документів в електронному вигляді. Це може дозволити:
спростити роботу з відображення змін до примірниках діючих документів (використання класичних методів управління змінами в паперових документах є досить трудомістким і може відобразити бажання постійно переглядати документи);
при використанні відповідних програмних систем - автоматизувати виконання рутинних робіт, пов'язаних з внесенням змін до процесів (перевірка узгодженості описів процесів, визначення впливу змін на посадові інструкції і положення про структурні підрозділи тощо).
Обов'язкові вимоги і рекомендована практика
Однією з можливих варіацій описаної системи є включення до документовані описи процесів не тільки обов'язкових вимог щодо їх виконання, а й кращої практики, яка має не обов'язковий, а рекомендований характер. Такий крок є логічним розвитком тези про те, що описи процесів відображають кращу практику їх виконання. А така практика може бути як бажаною, так і обов'язковою до використання. Причини того, що певні вимоги щодо порядку виконання процесу визначаються саме як рекомендовані можуть бути різними:
Недостатня перевіреність і апробованість запропонованих підходів;
Недостатня кваліфікація всього персоналу, залученого до виконання процесу, для того, щоб визначити підходи як універсальні;
Необхідність збереження гнучкості при виконанні процесу, недоцільність його занадто жорсткої регламентації.
Якщо з цим чи інших причин певні підходи до виконання процесу недоцільно визначити як обов'язки, але є бажання зафіксувати знання щодо цих підходів - допомогти може статус рекомендованої практики.
Іноді організації вводять ці два підходи: виділення кращої практики і процесний підхід незалежно один від одного. Створюється база кращих практик (як правило - у внутрішній комп'ютерній мережі), визначаються шляхи її поповнення, виконуються певні кроки по її пропаганді та поширенню - але все це без зв'язку з процесами та їх документованими описами. У кращому випадку структура бази кращих практик будується на основі процесної структури. Таке розділення може призвести до проблем як з поповненням бази, так і з її використанням. По-перше, з точки зору відповідних керівників виділення нових кращих практик стає окремою роботою, нарівні з удосконаленням порядку виконання процесу: а на дві окремі роботи завжди складніше знайти час і ресурси. Крім того, виникає ризик того, що обов'язкові вимоги і краща практика виконання однієї і тієї ж роботи можуть або дублюватися, або суперечити один одному. Але найбільш серйозна проблема при побудові «окремої» бази кращих практик - забезпечення її реального застосування виробниками робіт. Адже не зовсім зрозуміло, в яких саме ситуаціях виконавець повинен «заглянути» в базу і пошукати там рекомендації щодо кращих шляхів виконання своєї роботи.
Тому більш ефективним може бути варіант, коли і вимоги, і побажання до виконання процесу описуються спільно, в одному документі (як варіант: документ, який описує вимоги, містить посилання на описи найкращих практик). Це може бути особливо зручно, якщо вони правильно оформлені у вигляді інформаційної системи на електронних носіях з можливістю перехресних посилань між ними. Але головним є навіть не їх загальний опис, а спільна розробка, проектування робіт, загальне визначення того, що саме в роботі є обов'язковим, а що - бажаним, ніж можна пожертвувати заради гнучкості, а чим - ні. Введення в опису процесів рекомендованої практики полегшить дилему, з якою стикаються власники процесів: включення певних вимог до опису процесів може зменшити їх гнучкість, а «не включення» - призведе до втрати цінного досвіду.
Загальне проектування цих складових дозволяє також краще враховувати їх взаємодію при перегляді процесів. Зокрема, можуть виконуватися такі дії:
рекомендована практика може отримувати статус обов'язкових вимог (якщо вона підтвердила свою високу ефективність у порівнянні з іншими варіантами виконання процесу, стала загальновживаною);
частина обов'язкових вимог може переводитися у категорію рекомендованої практики (якщо стало важливим забезпечити гнучкість у виконанні процесу або якщо з'явилося бажання спробувати інші варіанти виконання робіт);
рекомендована практика може вилучатися з документа (якщо вона виявилася неефективною або якщо з'явилася краща практика).
Звернемо увагу на один широковідомий приклад документа, який містить як вимоги, так і рекомендації щодо виконання робіт - стандарт ISO 9004. Структура його відома: вимоги до певної діяльності взяті з стандарту ISO 9001 та виділені рамочкою, а далі йдуть коментарі щодо можливих шляхів реалізації цих вимог. Заодно цей приклад може заспокоїти ті організації, які хвилюються щодо реакції органу з сертифікації на подібну структуру документів.
Вводячи в документовані описи процесів «необов'язкові» елементи організація повинна визначити їх статус, наприклад:
абсолютно необов'язкові рекомендації, інформація для роздумів, рішення про застосування якої приймається виконавцем;
рекомендована схема, яка застосовується в більшості випадків, але виконавець може відступати від неї за власним рішенням (наприклад, якщо споживач пред'являє нестандартні вимоги, для задоволення яких потрібні нестандартні дії);
«Майже обов'язкова» схема, коли відхилення від неї можливі, але вони повинні реєструватися виконавцями або узгоджуватися з керівництвом (як варіант - керівництво повинні інформувати про такі відхилення постфактум).
Звичайно, можливий варіант, коли організація включає в опису процесів, поряд з обов'язковими вимогами, ще й рекомендації кількох різних рівнів «необов'язковості», але на практиці така ситуація малоймовірна. Така система може бути дуже складним як для її проектування власниками процесів, так і для її розуміння виконавцями.
Для того, щоб система документування кращої практики виконання процесів успішно діяла, важливо визначити джерело інформації про це та схему збору цієї інформації. Адже якщо обов'язкові вимоги та обмеження щодо виконання процесів задаються зверху, від керівництва, то краща практика може народжуватися в різних місцях, найчастіше - на рівні окремих виконавців. Тому її виділення та збір є важливим завданням, без вирішення якої відповідні розділи в описах процесів можуть просто залишатися порожніми.
Можливими джерелами інформації про кращу практиці можуть бути такі:
внутрішні аудити (їх процедура може передбачати виявлення і фіксацію відхилень від стандартного рівня роботи не тільки «вниз» - невідповідності, але й «нагору» - кращі практики);
звітність про виконання процесів або роботі підрозділів та її аналіз (особлива увага повинна приділятися випадків значного покращення результатів та виділенню причин такого поліпшення);
внутрішній бенчмаркінг (може проводитися на основі зіставлення звітності або в інших формах - якщо один підрозділ, фахівець і т.п. досягли значно кращих результатів, ніж інші - повинні виділятися причини цього);
пропозиції персоналу щодо кращої практики (на відміну від традиційних пропозицій щодо вдосконалення, вони можуть бути підтверджені власним досвідом: не «я пропоную робити», а «я зробив і отримав позитивні результати»);
зовнішнє навчання і зовнішній бенчмаркінг.
Зауважимо, що введення в опису процесів такого поняття, як рекомендована краща практика дозволяє поширити процеси на так звані «м'які» або «гнучкі» складові системи управління (англійською мовою - soft), тобто на ті, які складно або недоцільно алгоритмізувати і які, відповідно, складно описати в термінах обов'язкових вимог до порядку їх виконання. Прикладами такої діяльності можуть бути:
дії з розвитку корпоративної культури, поширення і застосування системи цінностей тощо;
мотивація персоналу, його залучення до процесів удосконалення і т.п.;
розвиток партнерських відносин з споживачами, постачальниками і т.п.;
глобальний аналіз діяльності організації, визначення стратегічних напрямків її розвитку, управління стратегічними змінами.
Розробити алгоритми виконання цих дій хоча б з мінімальним рівнем деталізації (щоб вони несли змістовне навантаження) може бути складно. Тому, на першому етапі, можна обмежитися описом основних принципів, рекомендацій, побажань щодо їх виконання. А вже в подальшому, накопичивши певний досвід управління цією діяльністю в рамках процесного підходу, можна розглядати доцільність більш глибокого документування.
Впровадження в опису процесів рекомендованої практики є показовим і з точки зору стилю відносин між керівництвом і персоналом організації. Мова йде про те, що керівництво може не тільки висувати вимоги до співробітників і контролювати їх виконання, але і радити їх, пропонувати, підказувати. Керівництво показує, що воно довіряє співробітникам самостійно приймати рішення про те, як краще діяти в конкретній ситуації, чи використовувати ці рекомендації.
Завершуючи статтю, варто сказати кілька слів про шляхи спільного використання двох зазначених підходів: створення багаторівневої структури описів процесів і виділення рекомендованої практики їх виконання. Звичайно, якщо організація вирішила піти по цьому шляху, відповідні кроки мають бути чітко спроектовані і узгоджені. Наприклад, можливим варіантом, який допоміг би спростити впровадження нової системи, є такий: на першому етапі керівники нижчих рівнів не описують обов'язкові вимоги до виконання процесів, а обмежуються розробкою рекомендацій щодо виконання вимог, оформлених вищим керівництвом (але ці рекомендації відразу повинні бути пов'язані з первісної структурою).