Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Мал. 2.6. Взаємодія між процесами

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

Будь-яку виробничу систему можна подати, як сукупність бізнес-процесів, де продукт попереднього бізнес-процесу є вхідним потоком для наступного процесу (Рис.2.7.).

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


Мал. 2.7. Послідовність бізнес-процесів


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

За структурою процеси класифіковані, як:

· Горизонтальні процеси, що в першу чергу пов’язані із виробництвом продукції

· Вертикальні процеси, які відображають управлінську діяльність компанії.

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

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

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

Для цього організація може розглянути наступні запитання:

· Які процеси є необхідними для нашої системи управління?

· Хто є споживачами продуктів кожного із процесів (внутрішні та зовнішні)?

· Які вимоги цих споживачів?

· Хто є „власником” кожного із процесів?

· Чи виконуються будь-які із процесів зовні організації (субпідрядники)?

· Які вхідні і вихідні потоки кожного із процесів?

У системі менеджменту якості, що відповідає вимогам ISO 9001, провідні консалтингові компанії, як правило, виділяють наступні процеси (21):

Ø QM Процес управління якістю.

Ø RM Процес управління ресурсами.

Ø RR Процес обліку законодавчих та нормативних вимог .

Ø DC Процес управління документацією.

Ø RK Процес управління протоколами якості.

Ø PL Процес планування.

Ø TR Процес підготовки персоналу.

Ø IA Процес внутрішнього аудиту.

Ø RV Процес аналізу зі сторони керівництва.

Ø MM Процес вимірювання та моніторингу.

Ø NC Процес управління невідповідностями.

Ø MR Процес маркетингових досліджень.

Ø CN Процес оцінки вимог споживачів.

Ø CC Процес зв’язків із споживачами.

Ø PD Процес проектування і розробки продукції .

Ø PU Процес закупок .

Ø PP Процес виробництва.

Ø SP Процес надання послуг.

Ø PT Процес захисту продукції.

Ø IC Процес внутрішнього інформування.

Ø CI Процес постійного покращення.

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

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

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

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

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

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

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

 

 

 

 

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

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

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

Виконання  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

 

Більш узагальнено
Більш детально

Цей функціональний блок є батьківським для діаграми А4

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

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

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

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

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

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

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

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

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

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

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

 

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

Последнее изменение этой страницы: 2016-07-23

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...