NorthWest - CRM для логістичної консалтингової компанії

У цьому проєкті автоматизації логістичних компаній була нестандартна й ризикована розробка, яку ми не рекомендуємо Вам повторювати в домашніх умовах, але в цьому проєкті все закінчилося добре й з вигодою для замовника. Адміністративні системи не славляться унікальним і красивим дизайном. Адмінки частіше роблять абияк, аби працювало. Але цей клієнт - велика транспортна компанія North West - вимагав якісний дизайн з акцентом на UI\UX і стильний інтерфейс для всіх користувачів цієї CRM.

Замовники називали цю систему просто CRM-кою. Формально ж це TMS (Transportation Management System, тобто система управління транспортними процесами). Але якщо говорити по-людськи, то перед нами був великий робочий інструмент для транспортного бізнесу, де потрібно враховувати компанії, водіїв, траки, документи, задачі, переписки та статуси. І все це — без відчуття, що ти зранку знову відкриваєш цифрову філію пекла =)

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

За своєю суттю це багаторівнева B2B-платформа з вираженою рольовою моделлю доступу (RBAC, розмежування прав за ролями), станами об’єктів (state machine, допустимі переходи між статусами) і складним документообігом. Якщо вам цікаві схожі проєкти в логістиці й транспорті, зверніть увагу також на NorthWest, LEX, Svit BUS, BusTicket і UNO Taxi.

Відеоогляд третього етапу

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

Особливості розробки

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

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

Це ризиковано, але в нашому випадку спрацювало. У нас були власні засоби автоматизації, які дозволяли збирати робочі контури системи у стислі строки. Особливо допоміг SFL — структурна фрактальна мова, за допомогою якої можна швидко описувати сутності, зв’язки, API і документацію, а не ліпити все вручну по шматках. Паралельно був застосований FRACTAL.ingello — наша технологія детермінованої генерації коду та прискореного конструювання застосунків. Це не про магію нейромереж і не про випадкову генерацію, а про інженерну передбачуваність: коли архітектурний каркас проєкту виростає з його внутрішньої логіки, а не з хаосу.

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

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

Плюси обраного підходу

Дизайн став спільною мовою між бізнесом і розробкою

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

Делегування задач відбувалося легко

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

Свобода інженерного трактування дала швидкість

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

Вдалося швидко вийти на великий MVP

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

FRACTAL дав економію там, де інші команди роздули б бюджет

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

Якщо вам близька тема корпоративної автоматизації, подивіться також platFORMA, FORMA BPM і FORMA CRM. Це хороші приклади того, як ми підходимо до складних внутрішніх систем, процесів і управлінських контурів.

Мінуси та обмеження

Відсутність повноцінного ТЗ

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

Великий обсяг ранньої версії потребував стабілізації

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

Довелося приймати компроміси

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

Головні виклики проєкту

Складна ієрархічна предметна область

По суті це була багаторівнева B2B-система: керівна сторона, компанії-клієнти, співробітники, водії, транспорт, документи і статуси. Майже B2B2B2B, якщо дивитися на це після третьої чашки кави =)

Немає класичного етапу проєктування

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

Фіксований бюджет і жорсткі терміни

Потрібно було зібрати велику систему без нескінченного розростання кошторису. Саме тому внутрішня автоматизація і повторно використовувані рішення стали не просто зручними, а стратегічно важливими.

Базові стани екранів не були описані заздалегідь

Порожні сторінки, помилки, валідації, конфліктні статуси, обмеження ролей — усе це рідко малюють у красивих макетах, але саме там зазвичай починається реальне життя продукту. І так, ці речі довелося добудовувати по ходу.

Рішення щодо функціональності

Суперадмін

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

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

Менеджер

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

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

Компанія-клієнт

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

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

Технічна адмінка

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

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

Службові та адміністративні розділи

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

Планування та робочі інтерфейси

Загальний екран управління завданнями

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

Річний календар із кольоровим маркуванням

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

Інтерактивний календар

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

Профіль і персональні налаштування

Профіль користувача

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

Завантаження персональних файлів

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

Документи і статуси

Реєстр документів

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

Транспорт і компанії

Реєстр траків

Цей екран показує список траків, VIN-коди і можливість налаштувати кожен об'єкт окремо. Тут уже видно предметне ядро платформи: транспорт як повноцінна сутність зі своїми атрибутами, ідентифікаторами і робочими діями.

Компанії і транспорт в одному контурі

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

Завантаження та обробка документів

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

Єдина управлінська панель

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

База знань і підтримка користувачів

Розділ запитань і відповідей

Тут показано розділ запитань-відповідей по системі з можливістю поставити своє запитання, отримати відповідь, а після модерації — автоматично поповнити базу знань. Це корисний шар продукту: він знижує навантаження на підтримку і поступово перетворює розрізнені звернення користувачів на накопичену корисну пам'ять системи.

Календар завдань

Завдання на день і деталізація статусів

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

Внутрішні комунікації

Чат для спілкування й обміну документами

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

Технології

Чому цей стек дав замовнику реальну перевагу

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

SFL дозволив прискорити прототипування бази даних, API і документації. PHP дав передбачувану серверну основу для складної бізнес-системи. JavaScript, HTML і CSS забезпечили живий і зрозумілий інтерфейсний шар. Linux, BASH, Docker, Docker Compose, FastCGI Process Manager, MySQL і Nginx дали стабільне серверне оточення і керовану експлуатацію.

Але головну перевагу дав не просто стек, а те, як він був зібраний навколо FRACTAL.ingello. Саме фрактальний підхід дозволив різко скоротити частку ручної рутини, швидше зібрати каркас системи і вмістити в бюджет обсяг функціональності, який у звичайної команди часто закінчується словами це вже буде у другій фазі. Тут багато що увійшло одразу. І саме тому замовник отримав не просто MVP на папері, а велику, живу, насичену систему, яку можна було показувати, тестувати і розвивати далі.

Якщо вам цікаві інші проєкти, де ми будували не просто інтерфейси, а повноцінні управлінські контури, подивіться platFORMA, FORMA BPM, FORMA CRM, а також транспортні кейси NorthWest, LEX, Svit BUS, BusTicket і UNO Taxi.

Чому замовники приходять до нас із такими проєктами

Ми вміємо працювати там, де в інших починається хаос

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

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

Для замовника це дає не абстрактну розробку, а конкретну вигоду

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

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

Ненав'язливо, але чесно

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