Коли ми в iCOLOR розпочинаємо впровадження чергового проєкту в OneBox OS, перед очима постає конструктор бізнес-процесів. За замовченням у ньому можна назвати статуси як завгодно, розфарбувати їх у будь-які кольори, додати потрібні поля, автоматичні дії та правила. Чи створюєте ви власні управлінські стандарти? Далі буде про внутрішні стандарти системи iCOLOR.
Свобода налаштування — це чудово. Але з часом виникає інша сторона цієї свободи: якщо кожне рішення приймати заново з нуля, сама можливість вибору починає породжувати хаотичні відмінності між процесами. В одному відділі м’ятний колір означає «роботу завершено», в іншому — «дзвінок зроблено», а в третьому — «очікуємо оплату».
Як робоче рішення потрапляє у внутрішні стандарти системи
У нашій роботі стандарти рідко створюються за письмовим столом як теоретичні інструкції. Вони проходять природний шлях від практичної задачі до зафіксованого правила:
- Виникнення проблеми. У повсякденній роботі помічається незручність — наприклад, співробітники плутаються в статусах різних відділів або витрачають зайвий час на зчитування стану задач.
- Пошук та перевірка рішення. На одному з проєктів випробовується проста схема, яка вирішує цю незручність.
- Повторення у проєктах. Якщо рішення показує себе вдало в інших задачах і не створює нових складностей, ми починаємо використовувати його за замовчуванням.
- Документування. Згодом виникає логічне питання: навіщо щоразу згадувати це з пам’яті й пояснювати на пальцях? Правило занотовується.
- Внутрішній стандарт. Зафіксоване правило стає базовим орієнтиром для нових конфігурацій та навчання команди.
Стандарт у нашій практиці зазвичай не вигадується наперед. Він фіксує рішення, яке ми вже перевірили в роботі й вирішили використовувати як базове.
Перший приклад с побудови стандартів
Один із перших зафіксованих елементів у нашій системі — це стандарт кольорового кодування статусів. Й він складає важливий рівень, що впливає й на інші стандарти.
Коли колір обирається випадково, виникає кольоровий шум. Якщо ж колір прив’язаний до чіткої операційної ролі, людина швидко розуміє стан справи в будь-якому процесі компанії.
Ми зазвичай починаємо не з налаштування складних автоматизацій, а з приведення візуальної мови системи до єдиної логіки.
Поточна палітра iCOLOR
Нижче наведено структуру палітри, яка потрапила у наші внутрішні стандарти системи та яку ми використовуємо при конфігурації статусів під час впровадження OneBox OS:
| Колір | HEX-код | Роль статусу в процесі | Приклад використання |
|---|---|---|---|
| Жовто-помаранчевий | #f9a825 | Точка входу / Новий процес | Новий лід, Стартовий статус |
| Світло-жовтий | #fff59d | Пасивне очікування / Уточнення | Очікує відповіді клієнта |
| Світло-сірий | #e0e0e0 | Транзитний шлюз / Проміжна точка | Передано далі, Проміжний стан |
| Пастельно-бузковий | #e1bee7 | Основна активна робота | В розробці, Виконується |
| Темно-синій | #1058C4 | Пауза / Відтермінування | Відкладено до дати |
| Яскраво-блакитний | #0d76ff | Сервісне нагадування | Потребує уваги |
| Темно-червоний | #c62828 | Скасування / Відмова | Скасовано, Відхилено |
| Деревно-коричневий | #6d4c41 | Повернення на допрацювання | Повернуто на виправлення |
| Темно-зелений | #558b2f | Контроль якості / Перевірка | На перевірці у керівника |
| М’ятний | #a5e3be | Повне остаточне закриття | Задачу закрито |
Окреме правило для фінальних статусів
З цієї палітри випливає одне критичне правило, щодо якого ми дотримуємося суворої дисципліни: м’ятний колір (#a5e3be) використовується виключно для закриваючих (фінальних) статусів бізнес-процесу. Введені стандарти стають кориснишими під час повсякденної експлуатації програми.
Якщо розфарбувати в м’ятний колір проміжний статус (наприклад, «КП відправлено» або «Дзвінок зроблено»), виникає хибне відчуття завершеності. Людина бачить сигнал, який у нашій системі означає завершення, хоча об’єкт усе ще перебуває в роботі. Для проміжного контролю якості використовується темно-зелений колір (#558b2f), тоді як м’ятний означає лише одне: процес повністю пройдено, і він виведений з операційного фокусу.
Стандарт не замінює аналіз, правила конфігурації CRM можуть змінюватися
Наявність правил полегшує налаштування, але вона не вирішує бізнес-задачу замість архітектора.
По-перше, жодна палітра чи інструкція не скасовує необхідності спочатку розібратися, як реально рухається робота в компанії. Якщо сам процес побудований плутано, правильні кольори лише акуратно розфарбують цю плутанину.
По-друге, ми дотримуємося простого принципу: стандарт фіксує не те, що є правильним назавжди, а те, як ми домовилися працювати зараз.
Якщо завтра практичний досвід покаже, що якесь із правил перестало допомагати або створює зайві перешкоди, це правило потрібно не захищати, а переглядати й змінювати. Інакше документування перетворюється на бюрократію заради бюрократії.
Навіщо ми документуємо внутрішні стандарти системи
Сьогодні ми розібрали лише кольорове кодування статусів. Поступово до нього додаватимуться інші спостереження щодо налаштування полів, прав доступу чи сценаріїв взаємодії тощо.
Фіксація таких правил дозволяє накопичувати не просто набір окремих конфігурацій OneBox OS, а цифрову пам’ять про те, чому система налаштована саме так, а не інакше. Це допомагає зберігати наступність рішень і розвивати архітектуру бізнесу спокійно та послідовно.
