Моделі бізнес-процесів та моделювання. Моделювання бізнес-процесів – огляд нотацій Принципи моделювання бізнес-процесів

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

Існує чотири основні способи розробки бізнес-моделей. Перерахуємо їх у порядку зменшення рівня ефективності побудови та використання бізнес-моделей:

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

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

• дерево (ієрархічний список) бізнес-процесів (рис. 1);
• графічні моделі бізнес-процесів;
• модель організаційної структури (рис. 2);
• моделі цілей та показників (стратегічні карти BSC/KPI);
• моделі бібліотеки документів (дерево документів); моделі інформаційних систем (системна архітектура) (рис. 3);
• моделі продуктів та послуг (рис. 4);
• моделі з менеджменту якості та багато іншого.

Всі ці моделі дають змогу розробити професійні програмні продукти бізнес-моделювання (ППБМ).
Більше 10 років автор використовує у проектах та власних розробках більшість відомих на ринку ППБМ-рішень: Business Studio, ARIS, AllFusion Process Modeler (BPWIN), Бізнес-інженер, Microsoft Visio. Кожен з них має свої функціональні особливості, обмеження та переваги. Докладніше ознайомитися з розробленою автором методикою порівняння програмних продуктів можна у книзі Ісаєв Р.А. Банківський менеджмент та бізнес-інжиніринг, глава 8. У програмному продукті Business Studio автором ведеться розробка «Комплексної типової бізнес-моделі комерційного банку», яка становить інтерес для фінансових організацій.

Мал. 1. Дерево бізнес-процесів банку (верхній рівень)

Мал. 2. Модель організаційної структури банку (верхній рівень)

Мал. 3. Модель бібліотеки документів банку (фрагмент)

Мал. 4. Модель товарів та послуг банку (верхній рівень)

«Джентльменський набір» знань та інструментів бізнес-аналітика

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

1. Програмні продукти бізнес-моделювання: Business Studio, ARIS, AllFusion Process Modeler (BPWIN), Бізнес-інженер, Microsoft Visio.

2. Нотації бізнес-моделювання та описи бізнес-процесів: IDEF0, IDEF3, Data Flow Diagram (DFD), розширений Event Driven Process Chain (eEPC), Value Added chain Diagram (VAD), Cross Functional Flow t та ін.
У кожному програмному продукті бізнес-моделювання закладено свій набір нотацій, і вони докладно описані у Посібнику користувача до програмного продукту.

3. Методики та методи бізнес-інжинірингу / менеджменту:

• Розробка та впровадження системи збалансованих показників BSC/KPI;
• Опис бізнес-процесів;
• Аналіз, оптимізація, підвищення якості бізнес-процесів;
• Управління бізнес-процесами на довгостроковій основі;
• Функціонально-вартісний аналіз (ФСА) та імітаційне моделювання;
• Опис та оптимізація організаційної структури, чисельності персоналу;
• Побудова систем мотивації персоналу;
• Побудова та організація функціонування системи управління якістю (ISO 9000);
• Управління проектами (зокрема з PMBOK - Project management body of knowledge);
• Побудова комплексної бізнес-моделі організації;
• Бенчмаркінг;
• Lean, 6 Sigma;
• TQM (загальне управління якістю);
• Різні галузеві методики та стандарти, розробки консалтингових компаній.

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

Таким чином, можна сформувати таку схему (рис. 5): Методика + Типові рішення + Програмний продукт = Результат.

Мал. 5. «Джентльменський» набір знань та інструментів бізнес-аналітика

Тут Методики та методипоказують, як виконувати проекти та завдання.

Типові рішення та матеріалидемонструють, що має вийти на виході (результат).

За допомогою ППБМавтоматизується виконання всіх завдань та проектів. Це у кілька разів скорочує час та підвищує ефективність робіт. Наприклад, система Business Studio дозволяє за натисканням однієї кнопки автоматично сформувати документацію, що регламентує, на основі розроблених моделей бізнес-процесів, забезпечуючи значну економію фінансових і трудових ресурсів.

Бізнес-моделювання: особливості практичного застосування

Головна особливість бізнес-моделювання полягає в тому, що в його основі мають бути бізнес-процеси. Саме система управління бізнес-процесами (СУБП) є фундаментом, на якому будується велика кількість інших систем управління та технологій.

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

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

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

Щоб впроваджувана в організації методика (технологія) та проект загалом були успішними та принесли заплановані результати, бажано, щоб вони:

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

Тут також доречно навести 8 головних принципів менеджменту якості, які належать до всіх завдань бізнес-моделювання та дозволяють забезпечити їх виконання:

• орієнтація на споживача;
• лідерство керівника;
• залучення працівників;
• процесний підхід;
• системний підхід до менеджменту;
• постійне покращення;
• прийняття рішень, що ґрунтується на фактах;
• взаємовигідні відносини із постачальниками.

Справді, недотримання навіть одного-двох принципів може вплинути на розвиток організації.

Значення бізнес-моделювання

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

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

Однак є й інші аспекти, які не так добре відомі широкому колу керівників та власників бізнесу.

Бізнес-моделювання та пов'язані з ним технології/рішення істотно впливають на рейтинги організації, які присвоюються рейтинговими агентствами, у тому числі міжнародними (Fitch, Moody's, S&P та ін.).

В результаті аналізу методик присвоєння рейтингів різних міжнародних та російських агентств (включаючи Методологію присвоєння рейтингу банкам, FitchRatings), а також за підсумками інтерв'ю з представниками агентств, автору вдалося з'ясувати, що багатьма агентствами при розрахунку рейтингів організацій враховується група факторів під умовною назвою. /менеджмент» (нефінансові оцінки). Цей параметр включає наступні фактори:

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

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

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

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

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

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

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

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

Практика бізнес-моделювання у фінансово-кредитних організаціях

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

«Вся діяльність банку щодо натискання однієї кнопки на комп'ютері»

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

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

Голова правління залишився задоволеним виконаною роботою. Слід зазначити, що робота була виконана у стислий термін: з моменту постановки завдання до отримання фінальних результатів минуло 1,5 роки. Високу швидкість реалізації проекту вдалося забезпечити завдяки використанню як методичну основу типового рішення - «Комплексну типову бізнес-модель комерційного банку», яка є системою взаємопов'язаних моделей, документів і довідників, що описують більшість сфер діяльності та систем управління універсального комерційного банку.

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

"Системний підхід до розвитку банку"

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

1. Ми опишемо всі ключові бізнес-процеси, створимо процесні команди та навчимо їх, забезпечимо ефективну взаємодію всіх учасників бізнес-процесів, щоб бізнес-процеси виконувалися швидше.

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

3. Коли бізнес-процеси та управління ними стануть прозорими та налагодженими, ми перейдемо до наступного завдання – побудова системи менеджменту якості банку (за стандартами ISO 9000) на основі системи управління процесами. Тобто СМЯ буде надбудовою для системи управління процесами. Це дозволить банку отримати сертифікат відповідності ISO 9001 та підвищити свій імідж як серед клієнтів, так і серед партнерів. Також завдяки СМЯ та стандартам ISO 9000 ми значно знизимо кількість претензій клієнтів до банку та витрати на неякісні продукти та послуги, мінімізуємо операційні ризики, доповнимо діяльність банку новими вимогами та методами управління.

4. Паралельно з цим ми розпочнемо автоматизацію бізнес-процесів. Обновимо і переведемо на якісно новий рівень системи електронного документообігу та оперативного управління (DocFlow / WorkFlow), взаємодії з клієнтами (CRM) та ін. щоб дана діяльність являла собою систему.

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

Висновок

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

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

14.02.2017, Вт, 16:00, Мск , Текст: Андрій Коптелов

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

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

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

Текстовий формат опису бізнес-процесу

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

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

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

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

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

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

Табличний формат опису бізнес-процесу

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

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

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

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

Єдиним недоліком табличної форми є складність відображень логіки бізнес-процесу, так як для кожної операції в таблиці доводиться описувати в якому випадку яка дія виконується, наприклад, «якщо документ узгоджений, то виконується операція 5, а якщо не узгоджений, то виконується операція 6 », що завжди зручно розуміння особливостей бізнес-процесу та її аналізу.

Графічна модель бізнес-процесу

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

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

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

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

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

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

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

Система моделювання бізнес-процесів

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

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

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

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

Від моделювання до автоматизації

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

Цілком логічно перекласти контроль правильності виконання бізнес-процесів на автоматизовану систему, в якій закласти всю необхідну логіку його виконання. При використанні спеціалізованих систем класу Business Process Management Suite модель бізнес-процесу стає виконуваною, і інформаційна система сама управляє бізнес-процесом відповідно до правил, описаних у моделі, призначаючи виконавців операцій і маршрутизуючи заявки відповідно до логіки бізнес-процесу.

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

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

Що ж вибрати?

Щоб визначитися з форматами опису бізнес-процесів потрібно проаналізувати розмір організації, її зрілість у сфері управління бізнес-процесами, і навіть визначити споживачів створюваного описи.

У компанії від 50 до 500 осіб для вдосконалення та регламентації бізнес-процесів цілком достатньо текстового або табличного опису процесів, при цьому опис може вестися силами співробітників та керівників, які пройшли спеціалізоване навчання на тему управління бізнес-процесами.

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

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

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

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

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

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

Кому це треба

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

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

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

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

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

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

● Намір впровадити автоматизовану систему управління.Справа в тому, що придбання та встановлення АСУП далеко не завжди призводить до позитивних результатів. Фахівці з впровадження таких систем незалежно від своєї продуктової орієнтації сходяться в одному: «неможливо автоматизувати бардак». Найдосконаліша система управління не працюватиме без чіткого розподілу відповідальності між співробітниками, які працюють у ній. І навіть за наявності чіткої системи управління варто подумати, перш ніж вкладати чималі ресурси в придбання та впровадження АСУП, а чи не містить система якісь вади, які не варто закріплювати в жорсткій комп'ютерній логіці.

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

Зрозуміло, можливі інші причини – чи комплекс причин, через які проектування системи управління стає необхідним. Головне, при ухваленні рішення не слід забувати просту істину: «Якщо працює – не ремонтуй!». (Під час написання статті у авторів виникли деякі розбіжності у трактуванні цієї приказки. Зупинилися на такому її уточненні: те, що чудово працює сьогодні – завтра може стати проблемою. І, звичайно, далекоглядний керівник просто зобов'язаний передбачити відповідний «ремонт»).

Небагато прикладів із життя

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

ІТ-компанія – типове підприємство середнього бізнесу. Основні напрямки діяльності:

● Продаж засобів автоматизації бізнесу – від продажу бухгалтерських та офісних програм до повномасштабних АСУП

● Впровадження засобів автоматизації бізнесу

● Системна інтеграція

● Послуги з навчання та сертифікації фахівців Замовника

● Виробництво та реалізація власного програмного забезпечення.

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

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

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

Різні приклади, різні цілі та підходи до вирішення завдань. Але всі підприємства об'єднує одне – необхідність проектування та застосування системи управління підприємством, заснованої з урахуванням бізнес-процесів.

З чого почати?

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

Малюнок 1.

Побудова карти починається з визначення мети власника. Що він чекає від свого підприємства? У наведеному прикладі мета проста та зрозуміла – збільшення вартості бізнесу на довгостроковому горизонті подій та зростання прибутку у найближчій перспективі. Можливі й інші цілі – збільшення інвестиційної привабливостінаприклад. Головна умова – досяжність мети, її чітке та ясне визначення (наприклад: «хочу мати можливість через три роки продати цей бізнес за 10 мільйонів»). Як правило, постановка мети проводиться у діалозі власника з бізнес-аналітиками та топ-менеджерами компанії, чиє завдання довести не дуже чіткі побажання до конкретних цифр та фактів, яких бажано досягти за певний проміжок часу. На цих нарадах намічаються і способи досягнення головної мети. У нашому прикладі найвищу мету – підвищення вартості бренду – можна розділити на дві підцілі – висока вартість бренду компаніїі брендів продуктів компанії- Так вирішили аналітики, вивчаючи діяльність підприємства. На нижніх рівнях показано, за рахунок чого можна збільшити ці цінності. Картка, що вийшла в результаті, чітко виділяє основні напрямки, в яких слід діяти для досягнення головної мети, зазначеної власником.

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

Які елементи аналізуються? Насамперед, асортимент пропонованих компанією товарів та послуг. Складається реєстр – повний пакет цих пропозицій – і його аналіз. Чи все з того, що ми виробляємо, вигідно, корисно та сприяє досягненню основних цілей? Чи варто розширити наш асортимент? Чи потрібно скоротити його щодо невигідних товарів чи послуг? Чи можна невигідні товари чи послуги зробити вигідними (а вигідні – суперприбутковими?). Складається перспективний пакет товарів та послуг, котрим і проводитиметься моделювання бізнес-процесів. Для продуктового аналізу, наприклад, можна використовувати матрицю Boston Consulting Group (рисунок 2).

Малюнок 2.

У застосуванні до статті проектування бізнес-процесів найбільш актуальне для «зірок» (у тому числі потенційних) і «дійних корів».

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

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

Команда учасників

"Кадри вирішують все!". Це гасло, як ніде актуальне у процесі вдосконалення системи управління. Для вирішення цього завдання неможливо просто найняти професійних виконавців, які зроблять все за вас. Зацікавлена ​​участь ключових співробітників компанії є обов'язковою умовою вирішення цього завдання. З іншого боку, запрошення сторонніх професіоналів хоч і бажано, але необов'язково – якщо свої співробітники беруться до виконання всіх необхідних функцій. Спробуємо описати ці функції та набрати формальну команду виконавців, а також вказати на важливість професійних навичок для кожного.

Стратег.Він же Керівник проекту. Завдання цієї людини у проекті – втілювати очікування власника у стратегію їх досягнення, координувати дії інших учасників, вирішувати конфлікти у випадках, коли потрібно бачення ситуації цілком. Стратег, якщо застосовувати військові асоціації, має представляти картину битви загалом – тобто мають виконуватися оборонні дії. На одних ділянках – наступальні, на інших – кіннота в певний момент має вискочити із засідки для забезпечення прориву, танки скористатися цими проривами для прориву в тил і розгрому противника… Його не хвилює, яким строєм рухатимуться танки – це місцеве тактичне завдання. Його не хвилює, який транспорт буде використано для підвезення боєприпасів – їх просто мають доставити у потрібній кількості. У той же час, якщо відділ постачання та командир танкової бригади не зможуть домовитися про кількість та строки підвезення снарядів, стратег, знаючи загальну логіку роботи системи, має вирішити конфлікт між службами, керуючись своєю думкою про необхідний баланс. Одна з найреальніших кандидатур на виконання цієї функції – генеральний директор (втім, буває й так, що генеральний директор є «весільним генералом», або надто зайнятий і може довірити функцію стратега заступнику чи зовнішньому консультанту). Залежно від досвіду, завантаженості, наявності спеціальних знань на допомогу йому можуть залучатися як заступники, так і зовнішні консультанти (наприклад, керівник або координатор проекту з боку виконавця). Однак ухвалення остаточних рішень залишається все-таки саме за цією єдиною людиною, або іноді за власником підприємства.

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

Проектувальники бізнес-процесів нижнього рівня.Для того, щоб зрозуміти – хто ці люди, розглянемо завдання з погляду завдання. Для невеликого підприємства, як правило, виділяються 7-8 бізнес-процесів верхнього рівня (наприклад, виробництво продукції, продажу, постачання, відтворення персоналу тощо). Кожен з них ділиться ще на 7-8 дрібніших підпроцесів – більш детальних (так, «виробництво продукції» може включати в себе виробництво деталей, збирання виробів, контроль якості) – тобто, в результаті маємо близько півсотні бізнес-процесів. У великих компаніях, як правило, необхідний подальший поділ - ще на один або два рівні. (Малюнок 3)

Малюнок 3. Приклад розподілу бізнес-процесів середнього підприємства. Для великих - просто додайте один-два поверхи вниз.

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

Мал. 4. Належність бізнес-процесів. Чорними стрілками позначено перебіг внутрішніх бізнес-процесів підрозділів, кольоровими – процесів вищого рівня.

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

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

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

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

Власне проектування.

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

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

Концентрація зусиль виконання стратегічних цілей. Бізнес-процеси, що не мають впливу на ключові показники, розробляються в останню чергу або не розробляються взагалі. Проведемо найпростіший розрахунок: для підприємства, що має три рівні бізнес-процесів (тобто не дуже велике унітарне підприємство), ми маємо 7-8 процесів верхнього рівня, кожен з яких ділиться на 7-8 БП другого рівня, такий же принцип розподілу зберігається і нижче . Як результат, вже на третьому рівні маємо понад 350 бізнес-процесів. У середньому кожен бізнес-процес складається з десятка операцій, що дає чотири тисячі операцій в цілому для підприємства. І це лише для невеликого! Геометричну прогресію до четвертого та п'ятого рівня пропоную порахувати самостійно. Звісно, ​​п'ятого рівня деталізації вимагають лише такі монстри, як Газпром чи РАО ЄЕС – але й четвертого рівня кількість операцій виявляється не маленьким. Кожен процес, кожну операцію, в ідеалі, потрібно оптимізувати, регламентувати та переглядати хоча б раз на рік чи принаймні зміни зовнішніх умов. Враховуючи кількість операцій, розуміємо, що ідеал, як завжди, недосяжний, а гонитва за ним призведе лише до невиправданого перевитрати ресурсів. Доводиться приймати сумне, але правильне рішення – взявши стратегічну карту, проектувати лише ті бізнес-процеси, які відповідають зазначеним у ній цілям. І, якщо прибирання внутрішньої території не впливає на жодну з цілей чи підцілей стратегічної карти, не впливає на жодний показник із ССП – то нехай її регламентують самі прибиральники. Хоча б доти, доки ми не розібралися остаточно з виробництвом, збутом та постачанням…

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

Не забувати під час проектування задавати основні параметри бізнес-процесу (рисунок 5).

Малюнок 5. Основні параметри бізнес-процесу

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

Оцінка проблемності та важливості процесу. Також дозволяє зрозуміти, які процеси слід проектувати одразу, а які можуть і зачекати. Серед основних критеріїв тут можна розглянути: 1) критичність для бізнесу. Тобто, наскільки неправильне виконання процесу може нашкодити компанії – підвищити витрати, призвести до втрати клієнта, затримати прийняття важливого рішення… 2) Частота повторення процесу (рідко, часто, регулярно). 3) Кількість передач відповідальності у межах одного процесу, наприклад, від підрозділу до підрозділу. Такі процеси потенційно небезпечні і тягнуть у себе безліч проблем.

Лідери з усіх трьох номінацій – явні кандидати до проектування та оптимізації.

Малюнок 6. Ілюстрація процесного підходу

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

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

Що очікуємо в результаті

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

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

Оцінка потреби у ресурсах

Якщо вам раніше доводилося займатися подібною діяльністю – то ви вже уявляєте собі, наскільки полегшить проектування Ваш розрахунковий рахунок, скільки співробітників ви тимчасово втратите, як повноцінні бойові одиниці (і скільки взагалі втратите). Міркування нижче скоріше для тих, хто вперше планує приступати до такої роботи – небезпечно як переоцінити, так і недооцінити масштаби майбутніх втрат. Завищена оцінка складності може призвести до відмови від проекту взагалі (разом із надіями стати лідером галузі) або до надмірно високих сум за договором з виконавцем. Занижена оцінка призведе до того, що в якийсь момент ресурсів не вистачить, і проект буде покинутий – що знову означає втрачені гроші. Тимчасова оцінка не менш важлива – і з тих самих міркувань. Практика показує, що компанії середнього розміру – від 500 до 1000 осіб – розробляють та впроваджують нову систему управління цілком за один рік. Компаніям із 10 тис. співробітників знадобиться приблизно 2-3 роки. Втім, залежно від складності ситуації, час впровадження може збільшитися і вдвічі, і втричі.

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

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

Питання: Чи можна зменшити витрати на проектування системи управління?

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

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

● Друга причина бере початок у розумінні основ ефективності. Процеси, що часто повторюються, є критичними для загального ходу справи – адже, незважаючи на простоту і шаблонність, їх внесок у загальні трудовитрати дуже значний. У проектуванні бізнес-процесів досить багато шаблонних дій, що повторюються, які, при ручній роботі, заберуть левову частку всього часу розробки. Звичайно, застосування методик CTRL-C - CTRL-V помітно полегшує роботу в WORD або Excel при їх введенні, проте спеціалізоване програмне забезпечення надає ще зручніше середовище для проектування.

● Третя причина – взаємопов'язаність усіх об'єктів – від підрозділів та співробітників до процесів різного рівня та стратегічних цілей. У грамотно побудованій системі все має підкорятися єдиній стратегічній системі цілей. Спеціалізоване ПЗ забезпечує такий взаємозв'язок, допомагає уникнути прикрих прорахунків від неуважності під час введення інформації.

● Четверта причина – оптимізація. Нехай на сьогоднішній день і не існує програми, здатної самостійно спроектувати оптимальний варіант бізнес-процесу (інакше й необхідність у керівниках та бізнес-аналітиках відпала б сама собою, комп'ютер дешевше) – але зробити симуляцію сотень циклів проходження кожного з тисяч бізнес-процесів у десятках варіацій їхньої взаємодії… Спробуйте зробити це за допомогою Excel! А без статистичної обробки в даному випадку не обійтися - адже система працюватиме в реальному світі, де всяке трапляється.

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

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

Наталія Єлманова
Комп'ютерПрес №7"2008
(www.compress.ru)

Про умови успіху засобів моделювання на світовому та російському ринках

У загальносвітовому масштабі (насамперед для багатонаціональних компаній і в деяких випадках - для компаній американських) одним із найсерйозніших критеріїв вибору програмного забезпечення для здійснення того чи іншого виду діяльності є висока оцінка продукту аналітичними компаніями, такими як Gartner Group, Forrester Research, IDC та Meta Group.

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

Про компанію QPR

Фінська компанія QPR є присутньою на світовому ринку досить давно - вона була заснована в 1991 році з метою створення інтерактивного програмного забезпечення, що значно покращує процес прийняття рішень на будь-якому організаційному рівні. В даний час компанія QPR займається науково-дослідною роботою та розробкою програмного забезпечення, призначеного для управління ефективністю діяльності організації.

Кілька років тому QPR була названа аналітичною компанією Gartner Group одним з провідних виробників засобів моделювання, що мають бачення ринку та перспективи його розвитку, багато в чому завдяки підтримці концепції BSC (Balanced Scorecard), дуже популярної в галузі стратегічного планування. Втім, про підтримку BSC у продуктах QPR ми розповімо трохи згодом.

QPR ProcessGuide - моделювання та документування бізнес-процесів

Підтримувані нотації

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

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

Модель процесу в QPR ProcessGuide

З іншого боку, цей засіб моделювання не відрізняється великою кількістю різних типів діаграм на кшталт тих, що доступні користувачам ARIS Business Architect або Microsoft Visio, - фактично цей інструмент має єдиний тип моделей, що підтримує декомпозицію кроків процесу. Але заради справедливості зауважимо, що QPR ProccessGuide дозволяє розширювати бібліотеку символів - елементів бізнес-процесів, тому формально дотриматися будь-якої графічної нотації можна, наприклад, у випадку, коли вона є корпоративним стандартом, прийнятим у компанії.

Документування процесів

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

Можливості документування процесів у QPR ProcessGuide дуже широкі - даний продукт має програмний інтерфейс на основі технології COM, що дозволяє звернутися до абсолютно будь-яких даних, що містяться в моделях, а вбудована мова програмування є Visual Basic for Applications. Останній факт значно спрощує генерацію звітів у форматах програм Microsoft Office - за наявності встановлених офісних програм можна звертатися зі скрипту звітності, створеного для QPR ProcessGuide, безпосередньо до COM-інтерфейсів Word, Excel, PowerPoint. Крім того, наявність програмного інтерфейсу такого класу дозволяє створювати на основі QPR ProcessGuide різні прикладні рішення, такі як засоби обміну моделями з іншими інструментами моделювання, засоби інтеграції з різними інформаційними системами тощо.

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

Імітаційне моделювання та вдосконалення процесів

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

Результати імітаційного моделювання в QPR ProcessGuide

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

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

Публікація моделей на корпоративному інтранет-порталі

QPR ScoreCard – підтримка технології BSC

Balanced Scorecard (BSC), або система збалансованих показників (ССП), - це розроблений у 1992 році професорами Гарвардського університету Робертом Капланом та Девідом Нортоном інструмент управління, що дозволяє перетворювати стратегічні цілі компанії на чіткий план оперативної діяльності підрозділів та ключових співробітників та оцінювати результати їх діяльності з погляду реалізації стратегії компанії з допомогою ключових показників результативності. Застосування збалансованої системи показників дозволяє здійснити цілеспрямований моніторинг діяльності підприємства, прогнозувати та запобігати появі проблем, контролювати найбільш суттєві фінансові та нефінансові показники діяльності підприємства.

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

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

Дерево цілей компанії в QPR ScoreCard

Стратегічна карта компанії QPR ScoreCard

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

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

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

Продукти QPR у Росії

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

На російському ринку доступні російськомовні версії товарів компанії QPR. Їх постачання, впровадження та підтримку здійснює компанія «Тродос Консалтинг» - ексклюзивний дистриб'ютор QPR Software plc у Росії та СНД. Крім того, зазначена компанія постачає на російський ринок ряд створених на основі зазначених продуктів прикладних рішень з використанням даних, отриманих з облікових систем, наприклад рішення для автоматизації управління штатним розкладом, формування системи мотивації персоналу, бюджетування, планування. На даний момент цією компанією здійснено кілька десятків успішних впроваджень – як продуктів QPR, так і власних рішень на їх основі. Це означає, що компанії, які зважилися не просто впровадити продукти QPR, а й інтегрувати їх з інформаційними системами, що є у них (а сучасні бізнес-користувачі, як правило, категорично наполягають на подібній інтеграції), не залишаться з цими завданнями віч-на-віч.

Відзначимо також, що для користувачів QPR доступне навчання застосуванню продукту російською мовою тривалістю від 2 до 5 днів, що включає спільне створення разом із замовником робочого прототипу моделі діяльності його компанії, що є по суті консалтинговою послугою.

Продукти QPR вигідно купувати при велику кількістьліцензій. Так, пакет ліцензій QPR Process Guide для невеликої кількості розробників (2-5) та кількох десятків користувачів (20-100) з річною техпідтримкою коштує від 12 до 30 тис. євро, тоді як у випадку кількох десятків розробників (20-40) та кількох сотень користувачів (200-400) вартість ліцензій та річної технічної підтримки становить від 60 до 115 тис. євро. Втім, основними споживачами продуктів подібного класу якраз і є досить великі компанії, адже саме їм насамперед потрібні спеціалізовані інструменти, які допомагають удосконалювати бізнес-процеси.

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

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

При подальшому аналізі розглядатимуться лише характеристики програм ARIS ToolSet (далі, ARIS), BP-Win – Erwin (далі, BP-Win) та ОРГ-Майстер (далі, ORG-Master). Програму Rational Rose - як найбільшою мірою орієнтовану на побудову суто програмних, а не організаційних систем, щоб спростити виклад ми виключимо з розгляду, тим більше що методологія UML, що лежить в її основі, реалізована зараз в АРІС).

Функціональні можливості засобів моделювання бізнес-систем

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

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

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

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

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

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

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

Так, наприклад, після побудови моделі бізнес-процесу в BP-Win, за допомогою ERwin будується окрема модель даних, в якій встановлюються зв'язки між компонентами системи (сутностями моделі даних за методологією). Потім ці моделі зв'язуються за допомогою механізму, по суті своїй схожим з механізмом побудови проекцій, що використовується в ORG-Master (див. Додаток 1. Компоненти моделей програмно-методичного комплексу ОРГ-Майстер).

З урахуванням цього, друга з аналізованих можливостей аналізу моделі: аналізу розподіл відповідальності за реалізацію окремих функцій та витрачання ресурсів системи, Виявляється автоматично реалізованою в процесі побудови моделі бізнес-процесу в системі ORG-Master. Справді, проекції виду Оргзвенья – Функції та Функції – Ресурси, що задаються при побудові моделей бізнес-процесів у ORG-Master, безпосередньо показують відповідальних за ту чи іншу ділянку роботи чи ресурс (і дозволяють проаналізувати їх будь-які комбінації). Крім того, ORG-Master дозволяє експортувати матричні проекції до MS Excel, де на їх основі формуються діаграми організаційного аналізу.

В ARIS та BP-Win для цієї мети необхідно або вручну простежити всі зв'язки з діаграм бізнес-процесів (і моделям даних у BP-Win), або спеціально будувати відповідні списки або звіти.

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

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

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

Більш адекватні результати можна отримати з допомогою імітаційного моделювання поведінки системи. Однак, для часів затримок обслуговування доводиться або приймати приблизні припущення про закон розподілу їх у часі, або проводити досить дорогі та трудомісткі процедури хронометражу та подальшу статистичну обробку. При цьому достовірність отриманих результатів не буде надто високою або потребуватиме значних додаткових витрат. Тому, розумним є підхід, який полягає в тому, що: «вартість витрат на моделювання для отримання будь-якої інформації, не повинна перевищувати цінність (вартість) результатів її використання. Крім того, завжди треба пам'ятати про закон Парето, з якого, стосовно розглянутої проблеми, випливає, що 20% зусиль з моделювання забезпечують 80% ефекту.

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

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

Крім того, до сімейства ОРГ-Майстер входить і програмний комплекс "Тайм-Майстер", один з компонентів якого, що забезпечує управління процесами (workflow), дозволяє накопичувати статистику по ходу їх виконання, що забезпечує отримання оцінок для необхідних для аналізу часових параметрів процесів.

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

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

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

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

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

Організація діяльності підприємства (компанії), спрямована на досягнення певних цілей, регламентується на сучасному рівні наступним стандартним набором базових організаційних документів:

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

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

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

У ORG-Master такі положення та інструкції генеруються автоматично як текстові форми опису процедур, представлених відповідними класифікаторами і відносинами-проекціями зв'язків між ними. Графічні форми (різні орграфи та діаграми процесів) служать гарним доповненням цих документів.

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

У BP-Win пряму можливість отримання різних регламентів не обумовлено.

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

У частині документації для розробки інформаційної системи найбільш традиційні можливості передбачає середовище BP-Win/ERwin, яке, власне, для цього створювалося.

Можливості ARIS приблизно аналогічні: у перших версіях моделі даних описувалися за схемою сутність-відношення, у пізніших – мовою UML. Однак, інструмент ARISToolset забезпечує більш розвинені функції розробки інформаційних систем.

Можливості ORG-Master дозволяють повністю уявити структури даних, необхідні організації інформаційної підтримки моделюваних бізнес-процесів з допомогою власних універсальних засобів – класифікаторів і проекцій. Немає формалізму типу ER-діаграм, хоча в останніх версіях можлива візуалізація в стандарті DFD. Крім того, з'явилася можливість відображати на IDEF0-діаграмах взаємодію між функціональними блоками не тільки за допомогою безпосередньої передачі документів і файлів, але й через бази даних, що розділяються!

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

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

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

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

У середовищі ARIS така можливість передбачена пакеті ARIS Toolset лише на рівні специфікації проекту та визначення параметрів баз даних.

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

Генерація програмних кодів прикладних чи системних засобівв системах ARIS і ORG-Master не передбачається, оскільки вони є засобами проектування бізнес-систем, а чи не програмного забезпечення. Певною мірою ця можливість реалізована лише у BP-Win.

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

Функції управління проектомСтворення баз даних та програмних засобів є специфічними саме для розробки програмних продуктів. У такій формі вони реалізовані у BP-Win. Управління проектами у сімействі ОРГ-Майстер повністю підтримує програмний комплекс «Тайм-Майстер». (Хоча, строго кажучи, дані функції не є обов'язковими для класу інструментальних засобів, що розглядається).

Інтеграція з іншими програмними продуктами передбачає розширення сфери застосування розглянутого засобу і може проводитися як у рамках розробки сімейства сумісних програмних засобів (на кшталт фірми Platinum Technologies) або з програмними засобами інших розробників (third party software).

Інтеграція з програмними продуктами "третіх сторін" виконується з однією з наступних цілей:

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

З погляду функціональної спрямованості можна розглядати інтеграцію з:

• CASE засобами,
• ERP систем,
• прикладними програмами.

ARIS має інтерфейси з деякими CASE-засобами, а також є засобом створення моделей для безпосереднього налаштування таких систем керування підприємствами, насамперед SAP R/3. Як зазначалося вище, система спирається на власну нотацію для представлення бізнес-процесів, тому в ній використовуються вбудовані засоби імітаційного моделювання та інструмент вартісного аналізу, результати яких, втім, можуть експортуватися у формати MS Excel.

Системи ORG-Master і BP-Win підтримують систему позначень IDEF0 для опису бізнес-процесів. У принципі, це є деякою сполучною ланкою як між цими засобами, так і для зв'язку з іншими програмними продуктами, що використовують цю методологію. Проте, не розглядаючи тут питання «віку» нотації IDEF0, слід зазначити, що внутрішнє уявлення даних у кожній системі своє, а стандартний інтерфейс на кшталт “сокетів” чи класів системи IDEF0 не обумовлено. Разом з тим існує стандартизований формат файлів для представлення IDEF діаграм. Тому, хоча описи, зроблені з його допомогою і не надто зручні як для людини, так і для ЕОМ, використовувати їх як засіб обміну моделями можливо за наявності відповідних конвертерів даного формату. Такий конвертер передбачається у наступних версіях ORG-Master.

BP-Win підтримує методологію IDEF0, DFDі IDEF3і інтегрується з наступними програмними продуктами (в основному того ж виробника):

• інструментом моделювання даних ERwin (Platinum Technology),
• системою управління та зберігання проектів ModelMart (Platinum Technology),
• спеціалізованим генератором звітів за моделлю RPTwin (Platinum Technology),
• системою імітаційного моделювання BPSimulator (System Modeling Corporation),
• інструментом вартісного аналізу EasyABC (ABC Technologies).

(*Platinum Technology – з 1999 р. увійшла до Computer Associates)

ORG-Master спочатку позиціонується як система організаційного класу, орієнтована на вирішення завдань моделювання та проектування бізнес-процесів і структур та підтримки прийняття організаційних рішень. У ньому передбачена можливість інтеграції з власними пакетами розробника (BIG-SPB Software), орієнтованими на вирішення різних функціональних завдань. У системі ORG-Master, при необхідності, автоматично створюються прості виконавчі інформаційні системи серед MS Office:

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

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

Можливе (і було випробувано в проектах) сполучення за даними через файли обміну в рамках побудови інтегрованих інформаційних систем з виконавчими та аналітичними програмами фірм-партнерів: 1С, АіТ: Софт, Інталев, Комтех+, ІНЕК та ін., а також з комплексними системами управління ресурсами підприємства (наприклад, IPS-виробництво).

У нової версіїтакож передбачаються механізми експорту описів бізнес-процесів до програмного комплексу «Тайм-Майстер», що поєднує властивості систем типу Project Management, WorkFlow та Personal Information System та побудовану на технологіях Internet/Intranet.

Резюме у розділі:

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

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

Однак у ході обговорення функціональних можливостей наголошувалося, що безпосередньо для вирішення завдань бізнес інжинірингу окремі групи функціональних можливостей мають різне значення. Цей факт відображено коефіцієнтами, записаними у графі “Bес”, Таблиці 2. З урахуванням цього видно, що загальна оцінка комплексу ORG-Master трохи перевищує ARIS.

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

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

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