Вступ
Клієнт проводить близько 1 000 навчальних курсів щомісяця. Для кожного треба підтвердити тренера, зареєструвати учасників, забронювати приміщення, розіслати нагадування, донести зміни до всіх причетних і закрити курс звітом. Дані про курс розходилися по CRM, таблицях, поштовому листуванні, календарях та окремих системах логістики, а команда адміністраторів руками зводила її докупи. На цю координацію йшло приблизно 1 200 людино-годин на місяць.
2BBooster переніс процес у Бітрікс24: один запис курсу, автоматичні завдання та переходи статусів, шаблонні комунікації та звітність, яку операційні керівники читають самостійно. Кількість курсів при цьому не змінилася, а адміністративне навантаження впало до 420 людино-годин на місяць.
Коротка відповідь
Компанія професійних послуг вела близько 1 000 навчальних курсів на місяць у кількох не пов’язаних між собою системах. Адміністратори вносили одні й ті самі дані в кілька місць, а статус курсу з’ясовували, перепитуючи колег. Процес забирав близько 1 200 людино-годин щомісяця. 2BBooster зібрав управління курсами в Бітрікс24: стандартизована сутність курсу, автоматизовані завдання та статуси, шаблонні комунікації з учасниками й тренерами, централізована звітність. Потреба в робочих годинах упала до 420 на місяць, тобто на 65 %, при тій самій кількості курсів і без жодного зовнішнього інструмента автоматизації.
Клієнт
Клієнт (тут анонімізований) розробляє та проводить професійні навчальні програми по всьому світу. Курси — це те, що компанія продає, тож їхнє адміністрування є основною операційною роботою, обсяг якої зростає пропорційно обсягу продажів: 1 000 курсів на місяць, і за кожним стоять учасники, тренери, розклад, локація, комунікації та підсумковий звіт.
Цим займаються регіональні операційні команди з кількох офісів — і саме звідси починаються складнощі. Той самий тип курсу могли вести дві різні команди, кожна зі своїми звичками щодо інструментів і своїми неформальними кроками, ніде не зафіксованими.
Виклик: 1 000 курсів на місяць у розрізнених системах
Адміністрування курсів було розкидане між кількома інструментами, зв’язаними між собою ручними передачами даних. Інформація про один курс могла водночас лежати в записі CRM, у таблиці, у листуванні, у календарі та в системі логістики. Жодна система не тримала її повністю, а синхронізації даних між ними не було, тож адміністратори переносили інформацію руками, щоб курси рухалися далі.
Послідовність виглядала так:
- Створювалася заявка на курс, базова інформація вносилася в операційну систему.
- Адміністратор вручну перевіряв доступність і узгоджував тренерів, учасників і локації.
- Ті самі дані повторно вносилися в таблиці та підсистеми, якими користувалися інші команди.
- Підтвердження й нагадування надсилалися вручну, з додатковими запитами там, де бракувало даних.
- Будь-яку зміну дат, складу учасників, тренера чи локації доводилося проводити через кілька систем.
- Після проведення адміністратори збирали дані про завершення курсу й готували операційні звіти.
Наслідки були передбачувані. Одні й ті самі дані доводилося вносити повторно, а статус курсу можна було дізнатися хіба що в колеги, який ним займався. Процес тримався на пам’яті конкретних адміністраторів, і зміна, внесена в одній системі, до решти доходила не завжди.
На обсязі 1 000 курсів на місяць арифметика стає невблаганною. Процес забирав приблизно 1 200 людино-годин щомісяця — близько 72 хвилин координації на курс, і це ще до будь-яких переробок. Коли зміна локації не доходила до списку учасників, це спливало за кілька днів: люди приїжджали не за тією адресою, а виправлення коштувало більше часу, ніж саме бронювання.
Власними силами компанія цю проблему не розв’язала. Робота була розподілена між регіональними командами без єдиного власника процесу, і виправляти це треба було з боку процесу, а не з боку софту: спочатку дизайн, потім конфігурація.
Обстеження процесів
Картування процесів передувало будь-яким налаштуванням і дало два висновки.
Процес відрізнявся від регіону до регіону: команди виробили власні способи виконувати одну й ту саму дію. Частина відмінностей відображала реальну специфіку бізнесу, але більшість була звичкою. Автоматизувати кожен варіант окремо означало б отримати систему, яку ніхто не зможе підтримувати, тому картування розділило одне й друге ще до старту розробки.
Другий висновок: самі підсистеми переважно були в порядку. Кілька з них добре виконували свою роботу й підводили лише там, де дані мали переходити з однієї в іншу. Тож мета змістилася із заміни систем на їхню оркестрацію.
Забронювати безкоштовний розбір процесів.
Рішення: єдиний процесний шар на Бітрікс24
Бітрікс24 налаштували як шар процесів і координації, а не як базу контактів. Рішення складалося з п’яти блоків.
| Блок рішення | Що побудували | Яку проблему знімає |
|---|---|---|
| Управління курсами та подіями | Централізована сутність курсу з єдиними статусами, власниками, датами, локаціями, даними тренерів і учасників | Єдине операційне джерело даних; зникла звірка передач між системами |
| Автоматизація завдань і процесів | Автоматичне створення завдань, призначення виконавців, дедлайни, переходи статусів і нагадування, керовані подіями курсу | Рутинне керування знято; наступна дія видима без розпитувань |
| Координація учасників і тренерів | Шаблонні комунікації з учасниками й тренерами та нагадування, прив’язані до статусу й дат курсу | Ручні нагадування зникли; єдиний стандарт комунікації в усіх регіонах |
| Управління логістикою | Структурована робота з локаціями, розкладом і залежностями всередині того самого завдання | Прибрано паралельні таблиці та ручну синхронізацію |
| Звітність і операційний контроль | Централізовані статуси живлять управлінську звітність щодо обсягу курсів, навантаження і стану процесів | Замість зібраних вручну звітів — актуальна картина незакритої роботи |
Підсистеми залишилися на місці. Бітрікс24 узяв на себе координацію, спеціалізовані інструменти й далі робили те, що вже робили добре, а інтеграції будували лише там, де вони прибирали ручну роботу. Повна заміна систем приблизно подвоїла б обсяг проєкту і зіпсувала б системи, які працювали нормально.
Як проходило впровадження
Роботу вели поетапно:
- Обстеження і картування процесів. Опис того, як адміністрування курсів працює насправді, разом із незадокументованими обхідними шляхами.
- Дизайн процесу. Стандартизація спільного сценарію, контрольовані відгалуження для справжніх винятків.
- Розробка базової автоматизації. Сутність курсу, статуси, автоматизація завдань і процесів.
- Інтеграції та звітність. Підключення систем, які залишили, і шар управлінської звітності.
- Тестування і запуск. Перевірка на реальних курсах, поетапна передача операційній команді.
Перше впровадження зайняло близько 12 тижнів. Далі був контрольований запуск і період доналаштування. Етапи вмикали по черзі, щоб операційна команда встигала перевірити кожен процес, перш ніж в автоматизований потік переходив наступний обсяг роботи.
Технологічний стек
| Рівень | Інструменти | Призначення |
|---|---|---|
| CRM / операційне ядро | Бітрікс24 | Записи курсів, дані учасників і тренерів, зони відповідальності |
| Автоматизація процесів | Бізнес-процеси Бітрікс24 | Створення завдань, призначення, переходи статусів, умовна маршрутизація |
| Комунікації | Сповіщення та шаблони Бітрікс24 | Повідомлення учасникам і тренерам, нагадування |
| Звітність | Звіти Бітрікс24 | Автоматична звітність для керівництва: обсяг, навантаження, стан процесів |
| Інтеграції | Нативні інтеграції Бітрікс24 з наявними операційними інструментами | Підключення спеціалізованих систем до координаційного шару |
Стек навмисно короткий. Усе працює на штатній автоматизації Бітрікс24: без зовнішніх оркестраторів, без RPA-шару, без кастомного middleware. Причина в підтримці: такі зміни є налаштуваннями всередині платформи, якою операційна команда і так користується щодня.
Результати
| Показник | До | Після | Зміна |
|---|---|---|---|
| Навантаження на адміністрування | 1 200 людино-годин/міс. | 420 людино-годин/міс. | −65 % |
| Час адміністрування на курс | близько 72 хвилин | близько 25 хвилин | −47 хвилин на курс |
| Курсів на місяць | близько 1 000 | близько 1 000 | Обсяг той самий, зусиль менше |
| Кроки, що потребують ручної уваги | Багато, передачі між системами | Мало, керуються процесом | Суттєве скорочення |
Час на один курс виведено з місячних показників за обсягу близько 1 000 курсів.
Вивільнені 780 людино-годин на місяць повертаються в іншу роботу — це приблизно 4,5 ставки при 40-годинному робочому тижні. Помноживши ці години на повну вартість години роботи співробітника, клієнт отримує пряму щомісячну економію.
Результати, які не зводяться до цифри:
- Єдина операційна картина статусів курсів і відповідальних.
- Менша залежність від того, чи тримає адміністратор наступний крок у голові.
- Стабільніше виконання повторюваних завдань у різних регіонах.
- Брак даних і прострочені дії стають помітними раніше.
- Архітектура, яка розширюється на нові типи курсів без перебудови.
Що виявилося складним
Варіативність процесів. Автоматизація кожного регіонального винятку окремо дала б систему, яку неможливо підтримувати. Спершу визначили спільний сценарій, і лише після цього додали контрольовані відгалуження — тільки для справжніх бізнес-винятків. Це була найповільніша частина проєкту: стандартизація процесу, який люди роками виконували по-своєму, починається з перемовин, а не з проєктування. Питання треба було закрити до того, як на процес ляже автоматизація.
Межі інтеграції. Оскільки з обох боків спрацьовував інстинкт інтегрувати все, рішення про те, що саме не підключати, потребувало окремих обговорень. Правило, яке з цього вийшло: систему підключаємо там, де інтеграція знімає ручні кроки, і лишаємо як є там, де вона й так справляється зі своїм завданням.
Що це означає для схожих бізнесів
Такий підхід працює для організацій із великим обсягом повторюваних операцій, що вимагають координації. Провайдери навчання, організатори заходів, виїзні сервісні служби — будь-який бізнес, де той самий багатокроковий процес повторюється сотні разів на місяць у розподілених командах.
Ознаки того, що процес варто брати першим:
- Одні й ті самі дані вносяться більш ніж в одну систему.
- Статус можна з’ясувати, тільки запитавши людей.
- Процес залежить від того, чи пам’ятають конкретні адміністратори наступний крок.
- Зміни, внесені в одному місці, регулярно не доходять до інших.
На старті потрібні визначений власник процесу, згода щодо стандартного сценарію і готовність спершу навести лад у процесі, а вже потім автоматизувати. Останній пункт вирішує долю проєкту. Процес, автоматизований у стані, коли він ще відрізняється від команди до команди, фіксує ці відмінності назавжди. Розраховуйте на місяці, а не тижні, з приблизно рівним поділом зусиль між дизайном процесу і налаштуванням.
Як допомагає 2BBooster
Ми описуємо процес таким, яким він працює насправді, а не таким, яким він задокументований. Обхідні шляхи, які команди вибудовують навколо прогалин у системах, зазвичай і є місцем, де сидять витрати, — і в документацію вони майже ніколи не потрапляють. Далі визначаємо, які кроки варто автоматизувати, які спершу треба стандартизувати, а які краще не чіпати, і вже після цього беремося за налаштування. Якщо з роботою впорається платформа, яку клієнт уже має, ми будуємо всередині неї.
Релевантні послуги:
Часті запитання
Як виглядає проєкт впровадження Бітрікс24 такого типу?
Картування процесів, дизайн цільового процесу, розробка автоматизації, інтеграції та звітність, потім поетапний запуск. Тут перше впровадження зайняло 12 тижнів, доналаштування тривало й після нього. Етап картування визначає, що саме автоматизується і в якому порядку, тому робити його варто ґрунтовно.
Скільки часу насправді економить автоматизація такого процесу?
У цьому проєкті адміністрування скоротилося з 1 200 до 420 людино-годин на місяць при незмінному обсязі, тобто на 47 хвилин менше на кожному курсі. Більша частина економії припадає на зняті повтори: один реєстр на місці кількох, статуси, що перемикаються самі, і шаблонні комунікації — раніше кожен лист писали з нуля.
Чи потрібно замінювати наші поточні системи?
Зазвичай ні. Тут Бітрікс24 став координаційним шаром, а спеціалізовані системи зберегли ті ділянки, з якими вже добре справлялися. Інтеграцію будують там, де вона знімає з людей ручне перенесення даних.
А якщо наші процеси не задокументовані й кожен регіон працює по-своєму?
З цього починає більшість клієнтів. Опис того, як робота виконується насправді, разом із незадокументованими обхідними шляхами, є першим етапом проєкту, а не вимогою до входу. Регіональні відмінності змінюють порядок робіт: спершу визначається спільний сценарій, потім контрольовані відгалуження закривають справжні винятки.
Як виміряти результат такої автоматизації?
Відносно базових показників, знятих до старту проєкту: години співробітників на процес, кількість систем на одну операцію, переробки через те, що інформація не дійшла. Без цієї бази потім немає з чим порівнювати — тому її фіксують ще на етапі обстеження.
Із чого почати перегляд власного процесу
Якщо ваша команда веде великий обсяг повторюваних операцій у розрізнених системах, а статус можна дізнатися лише в колег, ми опишемо ваші поточні процеси й покажемо, які кроки варто звести докупи першими.