Прототипування системи продажів для виробництва

Компанія виробляє та продає ритуальну продукцію (рамки, скло, панелі) і послуги з фото-дизайну. У ході проєкту проводився бізнес-аналіз і аудит бізнес-процесів компанії "Cкло" та розробка програмного прототипу. У межах проєкту було спроєктовано, візуалізовано й розроблено (рання версія) застосунок для клієнтів, застосунок для менеджерів з продажів, застосунок для дизайнерів. Було написано технічне завдання (ТЗ) на 98 сторінок, яке описувало не тільки вимоги до функціональності, а й вимоги до системної якості та стандартів. У фіналі була проведена оцінка бюджету й запропоновано кілька варіантів реалізації за різними цінами fixed-price.

Проєктування системи для виробництва ритуальної продукції: аудит, прототип і ТЗ на 98 сторінок =)

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

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

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

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

Застосунок для клієнта: зрозумілий вхід у складний процес

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

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

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

Застосунок для менеджерів: продажі, контроль і менше ручного шаманства

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

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

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

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

Застосунок для дизайнерів: де творчість має дружити з процесом

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

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

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

ТЗ на 98 сторінок: не список забаганок, а інженерний документ

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

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

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

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

Якщо вам теж потрібен не декоративний інтерфейс, а серйозне опрацювання продукту — з аудитом процесів, архітектурою, прототипом, ТЗ і зрозумілою fixed-price оцінкою — переходьте на Ingello Systems. Там можна подивитися, як ми підходимо до проєктування, вивчити принципи роботи, відгуки й залишити заявку на безкоштовну консультацію.