Опис бізнес-процесів при впровадженні WMS

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

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

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

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

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

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

Характеристика бізнес-процессів

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

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

Бізнес-процеси структуруються:

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

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

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

За видами діяльності або складом робіт йде підрозділ на:

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

Насправді у вашій компанії розподіл може бути трохи іншим. Основна мета подібної декомпозиції – поділ всіх процесів на блоки в залежності від функціоналу і контроль працездатності кожного блоку при переході складу на роботу з WMS системою.

Створення бізнес-моделей

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

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

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

Отже, ви готові скласти бізнес-моделі протікають в компанії процесів. Після цього потрібно визначитися з тим, як їх складати. Дуже важливо визначитися з рівнем деталізації вимог. Наприклад, для вас має велике значення комплектація товару – важлива послідовність укладання коробів з товаром в палети, а також важлива подальша розукомплектування палет. Важливо при цьому зберігати інформацію про товар – кількість штук в кожному коробі, найменування, серійний номер і т.д. Для Вас ці речі природні, самі собою зрозумілі, а ось в WMS вони зовсім не обов’язково присутні, або ж, що буває частіше, присутні, але не в повному обсязі. Тому якщо Ви задасте питання продавцю WMS, чи може програма підтримувати ту чи іншу функцію, то, швидше за все, отримаєте позитивну відповідь. А ось якщо запитаєте, чи може вона виконувати конкретну послідовність дій, то тут виникнуть труднощі. Хоча вам можуть запропонувати оригінальне рішення, що дозволяє виконати операцію так само якісно, ​​але іншим способом. Саме тому при складанні бізнес-моделей дуже важливий формат збору вимог. Ви повинні чітко показати, як буду виконуватися процеси при новій системі. Невдало обраний формат збору вимог в 90 випадках зі 100 призводить до невдачі при впровадженні. Основні причини:

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

Тому щоб скоротити ризики помилок в процесі моделювання, необхідно буде визначити:

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

Стандарти підготовки бізнес-процесів

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

Стандарт ARIS (Arhitecture of Integrated Information System) розроблений німецькою фірмою IDS Scheer. Ця методика моделювання грунтується на теорії побудови інтегрованих інформаційних систем, що визначають принцип візуального відображення всіх аспектів функціонування аналізованої компанії. ARIS підтримує чотири типи моделей:

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

Моделі ARIS являють собою діаграми, елементами яких є об’єкти – «функція», «подія», «структурний підрозділ», «документ» і т.п. Між об’єктами встановлюються різноманітні зв’язки. Кожному об’єкту відповідає набір атрибутів, який дозволяє ввести додаткову інформацію про конкретний об’єкт. Основна бізнес-модель ARIS – eEPC (extended Event-driven Process Chain). Головне достоїнство методу ARIS полягає в його комплексності, яка проявляється у взаємозв’язку між моделями різних типів. Метод ARIS дозволяє описувати діяльність організації з різних точок зору і встановлювати зв’язки між різними моделями. Основний недолік – ліцензійна програма дорого коштує. Метод вимагає детального вивчення процесів, а отже – великих витрат людських ресурсів.

Метод функціонального моделювання SADT (IDEF0) Метод SADT (Structured analysis and Design Technique) вважається класичним методом процесного підходу до управління. Основний принцип процесного підходу полягає в структуруванні діяльності організації відповідно до її бізнес-процесами, а не організаційно-штатною структурою. Саме бізнес-процеси формують значимий для споживача результат, представляють цінність, і саме їх поліпшенням належить надалі займатися. З іншого боку, модель, заснована на бізнес-процесах, містить в собі і організаційно-штатну структуру підприємства. Відповідно до цих принципів бізнес-модель повинна виглядати наступним чином:

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

Метод SADT в найбільшою мірою підходить для опису процесів верхнього рівня управління.

Його основні переваги:

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

Недоліки методу:

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

Метод моделювання процесів IDEF3 Метод моделювання IDEF3 призначений для моделювання послідовності виконання дій і взаємозалежності між ними в рамках процесів. Основою моделі IDEF3 служить так званий сценарій процесу, який виділяє послідовність дій і підпроцесів аналізованої системи. Як і в методі IDEF0, основною одиницею моделі IDEF3 є діаграма. Інший важливий компонент моделі – дія, або в термінах IDEF3 «одиниця роботи». Істотні взаємини між діями зображуються за допомогою зв’язків. Все зв’язку є односпрямованим. Завершення одного дії може ініціювати початок виконання відразу декількох дій, або, навпаки, певним чином впливати може вимагати завершення декількох інших дій. З’єднання розбивають або з’єднують внутрішні потоки і використовуються для зображення розгалуження процесу:

• розгортаються з’єднання використовуються для розбиття потоку;
• згортають з’єднання об’єднують потоки.

У методі IDEF3 усунутий основний недолік IDEF0 – важка сумісність кількох процесів. Однак метод став більш важкий для сприйняття.

Висновки Можливо, після опису засобів для створення бізнес-моделей сама програма WMS здасться вам простою і доступною. Але насправді кошти моделювання не так вже й складні, як здаються. Важливо просто розуміти, навіщо все це потрібно. А описувати бізнес-процеси ви можете в будь-якому зручному форматі, робити графічні зображення в Excel або Visio і т.д. Головне – не забувати основні цілі бізнес-моделювання перед впровадженням WMS:

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

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

Автор: Оксана АБРАМОВА Джерело: skladpro.ru