Анотація: У цій лекції розглядається поняття бізнес-процесу. Розповідається про виконуваної семантиці бізнес-процесів, про їх зв'язок з web-сервісами. Коротко розглядаються ERP-системи. Представлено введення в мову моделювання бізнес-процесів - новий стандарт комітету OMG під назвою BPMN
Нова концепція бізнесу - орієнтація на бізнес-процеси
До цього моменту в бізнесі панувала ідея функціонального поділу праці. Спрощено її можна пояснити так. Процес створення деякого вироби ділився на різні функції. Виріб виготовляє не один майстер, а кілька людей, кожен з яких виконує окрему функцію. У підсумку, пропускна здатність такого процесу виходить значно вище, ніж в ремісничому виробництві. Тобто кілька людей, що спеціалізуються на окремих функціях розробки вироби, випускають в одиницю часу більше виробів, ніж якби кожен з них виготовляв весь виріб цілком.
Цю ідею в кінці XVIII століття вперше сформулював Адам Сміт. На її основі були створені мануфактури, які в XIX столітті витіснили ремісничі цехи і кустарне виробництво товарів. На початку XX століття Генрі Форд удосконалив цю ідею і створив складальний конвеєр на своїх автомобільних заводах, що дозволило значно збільшити продуктивність праці. Зараз такі конвеєри існують у багатьох галузях промисловості. Після цього Альфред Стоун, керівник компанії "Дженерал Моторс", застосував ідею поділу праці до управління великим виробництвом.
Бізнес-процес - це організований комплекс взаємопов'язаних дій, які в сукупності дають цінний для клієнта результат. На виході бізнес-процесу клієнт обов'язково отримує якийсь результат (можливо, не остаточний). Саме така націленість на результат для клієнта і становить суть нового підходу. Інакше замовлення і послуги надаються "розмазали" по функціональних відділах компанії, у кожного з яких немає зацікавленості в кінцевому результаті. В результаті падає якість сервісів, замовлення обробляються не оптимальне, з великими витратами.
ERP-системи
На сьогоднішній день існують стандартні системи комплексної автоматизації бізнесу компанії, орієнтовані на підтримку бізнес-процесів в компанії і називаються ERP-системи (Enterprise Resource Planning). Лідерами в цій галузі є системи SAP R / 3, Oracle Applications, BAAN, Microsoft Axapta.
ERP-система намагається "відтворити" бізнес-процеси компанії в програмному забезпеченні і асистувати дії того чи іншого працівника, надаючи йому додаткові сервіси - "просунуті" засоби обліку робочої інформації, доступ до різних електронних довідників, додаткові професійні послуги тощо. Д. ERP -система є набором стандартних модулів, наприклад, "головна книга банку", "складський облік", "управління закупівлями". Для кожної компанії проводиться настройка вибраних модулів на потрібну кількість користувачів (і той і інший параметр сильно впливають на вартість системи).
Важливою частиною настройки ERP-системи є формалізація бізнес-процесів компанії. Тут важливо, що, по-перше, не можна автоматизувати хаос, по-друге, ERP-системи розраховані на певну модель бізнесу.
Переваги таких систем очевидні. Бізнес-компанії у вигляді ERP-системи отримують інтегровані рішення для свого бізнесу: різні їх підрозділи та філії будуть тепер пов'язані разом єдиною системою обліку, контролю, матимуть доступ до єдиного банку даних і т. Д.
Недоліком ERP-систем є висока вартість (в порівнянні з ціною готових систем, вирішальних будь-які приватні завдання бізнесу), а також висока ціна на їх впровадження, яка, як правило, в кілька разів перевищує ціну самої системи. Подальшу інформацію про ERP системах можна почерпнути в [9.4].
Моделювання бізнес-процесів
Переорієнтація компаній на бізнес-процеси - бізнес-реінжиніринг - означає перебудову її внутрішньої роботи і системи управління. Це важка і болюча процедура, яка супроводжується ламкою звичних укладів працівників компанії, переглядом їх обов'язків, зменшенням / збільшенням їх заробітної плати та часто - звільненнями. Тут багато різної роботи, і серед іншого - проектування нових схем бізнесу, а значить, і нових бізнес-процесів.
Чому хороша формалізація бізнес-процесу важлива?
- Вона дозволяє зробити наші думки предметом широкого обговорення.
- Вона дає можливість донести нові правила роботи до тих співробітників, які будуть їх виконувати.
- Формалізовані бізнес-процеси легше змінювати і модернізувати.
- Формалізація бізнес-процесів є хорошою основою для подальшої автоматизації бізнесу в компанії: створення / встановлення різних інформаційних систем і стандартних пакетів автоматизації.
Приклад бізнес-процесу
Весь бізнес-процес розбитий на дії, які зображуються прямокутниками із закругленими кутами. Переходи між діями показані стрілками, а документи, які породжуються або використовуються будь-якою дією, показані прямокутниками із загнутим правим кутом. Ці прямокутники з'єднані штриховими лініями з тим дією, в результаті якого вони створені, і з тими діями, в яких вони використовуються.
Виділимо наступні дії бізнес-процесу.
- "Оформлення замовлення". Спочатку клієнт оформляє замовлення. Передбачається, що перед цим він визначився в головному - що йому потрібно. Наприклад, кухонний гарнітур. Тоді у відділі з торгівлі кухонними меблями він, разом з одним з менеджерів цього відділу, складає дизайн-проект для своєї покупки (відповідно до розмірів його кухні і своїми побажаннями), уточнює параметри свого замовлення і точно визначається з комплектуючими і матеріалами.
- "Отримання товарів". Клієнт йде на склад і сам вибирає всі складові частини свого замовлення, маючи точний перелік того, що йому потрібно. При цьому йому допомагають працівники складу.
- "Оплата товарів і оформлення доставки". Клієнт разом зі своїми обраними товарами (він везе їх на візку) слід до каси і оплачує то, що він вибрав. Далі, з оплаченими товарами, він переходить до відділу доставки, де оформляє і оплачує доставку своїх меблів, а також її збірку (якщо йому це потрібно); після цього він їде додому.
- "Доставка". Рекламні товари клієнту доставляють протягом трьох днів.
- "Збірка". Після цього, якщо клієнт оформив збірку, то до нього приїжджає майстер-складальник і збирає доставлену меблі.
На рис. 9.1 одні і ті ж документи присутні кілька разів. Це зроблено з міркувань зручності, щоб не було великої кількості ліній на діаграмі. Тут використовується концепція завантаження елемента моделі на діаграму, обговорювана в попередніх лекціях: один і той же елемент моделі можна завантажити на діаграму багато разів. При цьому відповідних діаграмних елементів багато, а модельний - один.
Декомпозиція бізнес-процесів
Зрозуміло, що цілком, з усіма деталями бізнес-процес. представлений вище, істотно більше. Але якщо всі ці деталі помістити на одному листі, то вона буде надзвичайно важка для сприйняття і придатна тільки для автоматичної обробки. За допомогою такої діаграми можна буде пояснити співробітникам і клієнтам порядок робіт. вона не зможе служити зручним практичним посібником. Однак якщо обмежитися тільки деталями верхнього рівня, то вийде специфікація "в принципі" - її можна буде вставляти в звіти для начальства і використовувати тільки для самого першого, "шапкового" знайомства з тим, як в магазині продаються меблі. Але хочеться, щоб специфікація бізнес-процесу була зрозуміла і доступна людям, а також була б повною. Тоді різні фахівці могли б спростити знайомство з принципами роботи магазину, використовуючи наші специфікації - і ті, хто бажає отримати лише загальне уявлення. і ті, хто повинен детально розібратися в якомусь одному фрагменті, і ті, до то повинен / хоче зрозуміти все. Повна специфікація потрібна, наприклад, відповідального за діловодство магазину. Крім того, багатьом фахівцям, відповідальним за окремі ділянки процесу, необхідно детально знати процес роботи суміжників, тобто їм би дуже знадобився відповідний фрагмент повної специфікації бізнес-процесу. Нарешті, повна специфікація потрібна для автоматизованої підтримки бізнес-процесу.
Детальність і доступність одночасно досягаються декомпозицией бізнес-процесу. Так, дія "Оформлення замовлення" з рис. 9.1 розкривається в окрему діаграму, представлену на рис. 9.2.
На цьому малюнку можна побачити, що ця діяльність складається з інших, більш дрібних - "Створення дизайн-проекту", "Очікування клієнта", "Уточнення і перевірка проекту" і "Видалення проекту". Після того, як клієнт і дизайнер- продавець разом створили проект комплекту меблів, потрібного клієнту, а також склали список товарів, що відповідають цьому дизайн-проекту, клієнт може оплатити і отримати товар. оформити доставку і т. д. У цьому випадку дія "Оформлення замовлення" завершується і бізнес-процес йде далі.
Але може бути і так, що клієнтові потрібно обговорити проект зі своєю сім'єю, або він не готовий прямо зараз же заплатити, або він має не всю потрібну інформацію (наприклад, він пам'ятає розміри своєї кухні, для якої він купує меблі, лише приблизно, і проект повинен бути уточнений). У цьому випадку він йде, а створений для нього проект зберігається і зберігається в інформаційній системі магазину не більше десяти днів. Тоді бізнес-процес знаходиться в очікуванні, перебуваючи в дії "Очікування клієнта". Якщо по закінченні цього часу покупець не повертається, то проект видаляється.
Необхідно відзначити, що якщо оформлення замовлення закінчилося неуспішно, то подальші кроки бізнес-процесу, показаного на рис. 9.1. неможливі. Однак на рис. 9.1 існує всього один перехід з дії "Оформлення замовлення", отже, рис. 9.1 і рис. 9.2 Не є коректною специфікації. Але я і не ставив завдання створити повністю коректну специфікацію, оскільки в цьому випадку вона перестала б добре "працювати" в ілюстративних цілях.