Порівняння функціональної та процесної моделі управління

Розуміння процесного підходу

Застосування в організації системи управління, що передбачає ідентифікацію (визначення) процесів, їх взаємодії, а також управління ними називається „процесним підходом” (ISO-9004:2000).

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

Згідно Міжнародного стандарту ISO 9001:2008 «Системи управліня якістю. Вимоги», процесний підхід - це будь-яка діяльність, в якій використовуються ресурси для перетворення „входів” у„виходи”.

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

Зміст процесного підходу (Рис.1.1.) полягає в тім, що організація:

· розглядає свою діяльність з точки зору споживача;

· перетворює вимоги споживача у конкретні вимоги до продукції, послуги;

Рис.1.1. Зміст методики процесного підходу

· ідентифікує ключові процеси, які впливають на якість продукції, послуги;

· визначає взаємозв’язок та взаємодію між ключовими процесами;

· описує процеси через систему критеріїв та показників;

· виділяє ресурси для здійснення процесів;

· визначає відповідальних за процеси;

· розробляє методики вимірювання показників процесів;

· здійснює моніторинг за процесами (їх показниками);

· аналізує невідповідності встановлені протягом протікання процесів;

· здійснює коригуючі та запобіжні заходи;

· проводить постійне удосконалення процесів;

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

Порівняння функціональної та процесної моделі управління

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

· технічна діяльність;

· комерційна діяльність;

· фінансова діяльність;

· забезпечення безпеки (власності, людей);

· діяльність з обліку, аналізу та статистики.

Рис. 1.2. Функціональна модель управління

Управлінська дія, згідно теорії А.Файоля, підпорядкована 14 принципам:

· функціональний розподіл праці;

· влада;

· дисципліна;

· підзвітність лише одному керівнику;

· єдиноначалля (один керівник);

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

· справедлива винагорода;

· оптимальне співвідношення централізації і децентралізації;

· ефективна взаємодія;

· порядок в роботі;

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

· стабільність персоналу;

· заохочення ініціативи;

· корпоративний дух.

Функціональний розподіл праці та функціональна ієрархія володіє рядом властивих їй недоліків (Рис.1.3.). У першу чергу слід зазначити:

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

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

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

• незначне делегування повноважень і відповідальності, ускладнення системи погоджень (бюрократія);

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

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

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

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

Рис. 1.3. Недоліки функціональної моделі управління

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

Таблиця 1.1

Рис. 2.1. Модель процесу

Вихідні потоки – це результат перетворення (трансформації) вхідних потоків. На практиці вихідні потоки включають:

· те, що відповідає вимогам;

· те, шо не відповідає вимогам;

· відпади;

· інформацію про зміст самого процесу.

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

Рис. 2.2. Зв’язок між постачальниками та споживачами процесу

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

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

Ресурси процесу – це фактори, що сприяють створенню вихідного потоку, але самі не трансформуються у вихідні потоки. Наприклад, це можуть бути люди, (індивідууми або групи), обладнання, матеріали, приміщення, вимоги до оточуючого середовища…

Оператор процесу – особа, що управляє процесом. Його роль:

· вносити оперативні зміни в процесс;

· рекомендувати власнику процесу варіанти покращення процесу.

Власник процесу – особа, що несе повну відповідальність за процес та його результат. Його роль:

· контролювати, аналізувати і покращувати процес;

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

· підтримувати взаємодію з іншими власниками процесу;

· звітуватися перед керівництвом щодо ефективності процесу.

Рис. 2.3. Схематичне зображення бізнес-процесу

Рис. 2.4. Почерговість опису процесу

Рис. 2.5. Модель бізнес-процесу виробництва

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

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

Моделювання бізнес-процесів

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

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

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

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

Четверта сукупність об'єднує функції контролю та аналізу виконання планових показників.

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

Рис.2.8. Сукупності робіт при формуванні моделі процесів

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

Стандарт ISO-9001:2009 рекомендує застосовувати для моделювання всіх процесів системи управління чотирьох блоків робіт:„планування – виконання - перевірка – коригування”. Підтримка і постійне поліпшення процесів може бути досягнута за допомогою зазначеного циклу на всіх рівнях організації.

Мал. 2.9. Управлінський цикл

Суть застосування циклу “П-В-П-К” у відношенні до процесів полягає у наступному:

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

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

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

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

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

2.3. Методологія опису бізнес-процесів

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

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

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

· IDEF₁ - методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їхню структуру, взаємозв'язки;

· IDEF_1X (IDEF1 Extended) - методологія побудови реляційних структур. IDEF1X ставиться до типу методологій “Сутність-взаємозв'язок” (ER - Entity-Relationship) і, як правило, використається для моделювання реляційних баз даних, що мають відношення до розглянутої системи;

· IDEF₂ - методологія динамічного моделювання розвитку систем. У зв'язку із серйозними складностями аналізу динамічних систем від цього стандарту практично відмовилися і його розвиток призупинився на самому початковому етапі. Однак у цей час присутні алгоритми і їхні комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF₀ у динамічні моделі, побудовані на базі “розфарбованих мереж Петрі” (CPN - Color Petri Nets);

· IDEF₃ - методологія документування процесів, що відбуваються в системі (наприклад, при дослідженні технологічних процесів на підприємствах). За допомогою IDEF₃ описують сценарій і послідовність операцій для кожного процесу. IDEF₃ має прямий взаємозв'язок з методологією IDEF₀: кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF₃;

· IDEF₄ - методологія побудови об’єктно-орієнтованих систем. Засоби IDEF₄ дозволяють наочно відображати структуру об'єктів і закладені принципи їхньої взаємодії, тим самим дозволяючи аналізувати та оптимізувати складні об’єктно-орієнтовані системи;

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

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

2.4. Нотація IDEF₀ та рекомендації щодо її використання

Методологію IDEF₀ можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). IDEF0, як стандарт, був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, що носила назву ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США.

Із 1981 року стандарт IDEF₀ перетерпів кілька незначних змін, в основному обмежуючого характеру, і його остання редакція була випущена у грудні 1993 року Національним Інститутом Стандартів і Технологій США (NIST).

Графічна мова IDEF₀ є проста і гармонійна. В основі методології лежать чотири основних поняття.

Першим із них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (див. Рис. 2.10.) і персоніфікує собою деяку конкретну функцію в рамках розглянутої системи. Згідно вимог стандарту назва кожного функціонального блоку повинна бути сформульована у формі дієслова (наприклад, “робити послуги”, а не “виробництво послуг”).

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

· верхня сторона має значення “Регламентування” (Control);

· ліва сторона має значення “Вхід” (Input);

· права сторона має значення “Вихід” (Output);

· нижня сторона має значення “Механізм” (Mechanism).

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

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

Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування «інтерфейсної дуги» повинне бути сформульовано у формі іменника.

Рис. 2.10. Функціональний блок

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

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

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

При побудові IDEF₀-діаграм важливо правильно відокремлювати вхідні інтерфейсні дуги від регламентних, що часто буває непросто. Приміром, на рис. 2.11. зображено функціональний блок “Обробити заготовку”. У реальному процесі робітникові, що проводить обробку, видають заготовку і технологічні вказівки з обробки (або правила техніки безпеки при роботі з верстатом). Помилково може здаватися, що і заготовка і технологічні вказівки є вхідними потоками. Однак, це не так. У цьому процесі заготовка обробляється за правилами відображеними у технологічних вказівках, які повинні відповідно зображуватися регламентною інтерфейсною дугою.

Рис.2.11.Функціональний блок та інтерфейсні дуги

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

Рис.2.12. Функціональний блок та інтерфейсні дуги

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

Обов'язкова наявність регламентних інтерфейсних дуг є однією з головних відмінностей стандарту IDEF₀ від інших методологій класу DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

Третім основним поняттям стандарту IDEF₀ є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розкладенні складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

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

Модель IDEF₀ завжди починається з подання системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що простираються за межі розглянутої області. Така діаграма з одним функціональним блоком називається контекстною діаграмою, і позначається ідентифікатором “А-0”.

У пояснювальному тексті до контекстної діаграми повинна бути зазначена мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).

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

Рис.2.13. Декомпозиція функціональних блоків

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

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

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

Часто бувають випадки, коли окремі інтерфейсні дуги не має змісту продовжувати розглядати в дочірніх діаграмах нижче якогось певного рівня в ієрархії, або навпаки - окремі дуги не мають практичного змісту вище якогось рівня. Наприклад, інтерфейсну дугу, що зображує “деталь” на вході у функціональний блок “Обробити на токарному верстаті” не має змісту відображати на діаграмах більше високих рівнів – це буде тільки перевантажувати діаграми та робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися від окремих “концептуальних” інтерфейсних дуг і не деталізувати їх глибше певного рівня. Для рішення подібних завдань у стандарті IDEF₀ передбачене поняття тунелювання. Позначення “тунелю” (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги означає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася з “тунелю” (тільки на цій діаграмі). У свою чергу, таке ж позначення навколо кінця стрілки інтерфейсної дуги в безпосередньої близості від блоку-приймача означає, що в дочірній стосовно цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії. У такому випадку, вони спочатку “поринають у тунель”, а потім, при необхідності “повертаються з тунелю”.

Останнім з понять IDEF₀ є глосарій (Glossary). Для кожного з елементів IDEF₀: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення та підтримка набору відповідних визначень, ключових слів, оповідальних викладів і т.д., які характеризують об'єкт, відображений даним елементом. Цей набір називається глосарієм та є описом сутності даного елемента. Наприклад, для регламентної інтерфейсної дуги “розпорядження про оплату” глосарій може містити перелік полів відповідній дузі документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочна графічна мова, розвиваючи діаграму необхідною додатковою інформацією.

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

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

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

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

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

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

Рис.3.1. Модель системи менеджменту якості згідно ISO 9001:2008

Система управління якістю, що відповідає вимогам міжнародних стандартів ISO 9000:2000 створює для організації можливість:

Ø гарантувати своєчасну поставку якісної продукції замовнику;

Ø зменшувати число дефектів, зменшуючи обсяг переробок та затрат на проведення гарантійних ремонтів;

Ø виявляти помилки на ранніх стадіях і не повторювати їх;

Ø покращувати керованість у період зміни ситуації на ринку або розширенні виробництва;

Ø покращувати обізнаність персоналу про цілі організації;

Ø чітко визначити обов’язки і права персоналу;

Ø покращити використання ресурсів і матеріалів;

Ø покращити взаємодію із постачальниками та споживачами;

Ø використовувати у рекламних матеріалах визнану емблему ISO 9000 , якщо система сертифікована.

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

ü ідентифікувати потреби і очікування споживачів та інших зацікавлених сторін;

ü розробити політику і цілі організації у сфері якості;

ü ідентифікувати процеси і відповідальність, необхідні для досягнення цілей у сфері якості;

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

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

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

ü визначити засоби, необхідні для попередження виникнення

невідповідностей та усунення їх причин;

ü розробити і застосувати процес постійного покращення системи менеджменту якості.

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

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

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

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

Здійснення зворотного зв’язку у системі управління якістю дозволяє реалізувати вимоги п.4.1. стандарту ISO 9001:2008, а саме здійснювати спостереження, вимірювання і аналіз процесів та впроваджувати організаційні заходи щодо постійного покращення цих процесів та вдосконалення самої системи управління якістю.

Рис. 4.2. Спрощена класифікація оціночних критеріїв процесу

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

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

Показники тривалості виконання процесу:

• середній час виконання процесу в цілому;

• середній час простоїв;

• середній час виконання окремих функцій процесу;

• інші.

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

Найпростішим, але дієвим на практиці, прикладом розрахунку та анал<