Кастомні CRM/ERP-системи та інтеграції LLM, побудовані навколо процесу, який у вас уже є, а не навпаки.
Поговорити з намиПроблема
Робота
Замовлення, виробництво, склад, собівартість і звітність в одній моделі — щоб цифри, за якими керівник ухвалює рішення, походили звідти ж, де фіксується робота, а не зі щомісячної звірки між чотирма інструментами. Побудована навколо процесу, який у компанії вже є, а не замість нього процесом вендора.
Витяг даних із документів і фотографій, класифікація та маршрутизація, чернетки всередині робочого процесу. Кожен випадок обмежений схемою, у яку він пише, перевірений на ваших власних даних, перш ніж від нього щось залежить, і достатньо дешевий за виклик, щоб не вимикати.
Для внутрішнього ПЗ, яке бізнес переріс, але на якому досі працює. Ми описуємо, що воно насправді робить, разом із поведінкою, якої ніхто не задокументував, а потім переносимо його по одному сценарію, поки стара система обслуговує те, що їй лишилося.
У продакшені
Обидві системи працюють на тих самих даних, тож переносити нічого і відновлювати з копії теж нічого. Нова отримує другу адресу, а не адресу старої: ключові співробітники освоюються на ній, поки решта працює як раніше, а коли освоїлися — стара адреса веде редиректом на нову, і нікого не вчать маршруту, який ось-ось зникне. За тим редиректом вона лишається живою як запасний варіант, а не вимикається. Відкат на будь-якому кроці — це зміна домену, а не відновлення бекапу. І запис, який обидві сторони обробили в одну хвилину, не стає двома: унікальний ключ та upsert роблять того, хто був другим, порожньою операцією, а не другим сповіщенням.
Витяг передає те, що прочитав, — суму й кількість, — а ділить і переводить одиниці код. Ніщо з того, що видала модель, не потрапляє в запис, не пройшовши ту саму перевірку, що й набране руками. Відмовлений запис повертається з названою причиною: одиниця не переводиться, назва ні з чим не збігається, під умову підходить більше ніж одне замовлення. Асистент зобовʼязаний сказати, яка саме, а не зобразити успіх, якого не було. Саме тому це безпечно тримати ввімкненим цілий день — збій має вигляд видимої відмови, а не тихо неправильної цифри.
Матеріал підбирається під власні слабкі місця людини семантичним пошуком — поверх таксономії, яка лишається детермінованою і придатною до перевірки. Векторне сховище не має власної вартості експлуатації: воно працює скануванням збережених векторів, без окремого пошукового індексу, переходить на керований індекс однією зміною налаштування і без міграції того, що вже лежить, а коли сервіс ембедингів недоступний — повертає порожньо, а не здогад. Семантика лише додає до розмітки під нею; від неї нічого не залежить. Прибирає вона той місяць, за який новачок самотужки зʼясовує, у якій частині роботи він найслабший.
Розподіл, нагадування і підсумок дня — це розклад, а не звичка, тож звернення, яке ніхто не взяв, стає станом, на який система реагує, а не проміжком, якого ніхто не бачить. А цифри, які читає керівник, — не окрема звітна вправа: це ті самі записи, у які пишеться робота, і саме тому нікому не треба перевіряти їхню свіжість перед нарадою. Розбір дня стає читанням того, що сталося, а не його відновленням.
На практиці
Рецепт, специфікація або наряд, перетворені на щось із цифрами: вихід, втрати, собівартість одиниці і те, скільки робота насправді заробляє, а не виставляє в рахунку. Та сама робота, що інакше живе в зошиті поруч із таблицею.
На вхід іде фото рукописного документа або чека постачальника; на виході — розпізнані позиції й актуальні ціни у вигляді структурованих записів, на яких і так працює решта системи. Модель обмежена цією структурою. Саме тому вона витримує, коли з нею працюють цілий день.
Розрахунки виконуються на пристрої, тож обʼєкт без звʼязку залишається робочим, а бек-офіс бачить дані, щойно зʼявляється підключення.
Випускаємо в стори або на власну інфраструктуру компанії, локалізуємо там, де є користувачі, і супроводжуємо релізним циклом, а не передаємо й забуваємо.
Довга дистанція
Це не проєкт із передачею наприкінці. Система, на якій працює компанія, живе роками: вона приходить етапами, кожен придатний до роботи ще до початку наступного, а далі її треба тримати живою, поки бізнес навколо змінюється.
Ми розбираємося в роботі, роблячи роботу: дивимося на процес таким, як він працює насправді, включно з тим, чого ніхто не записав. На виході — модель даних, на яку нашаровуються наступні пʼять років, а не список функцій.
Перший реліз повністю закриває один реальний сценарій і йде в щоденну роботу. Далі рішення обговорюються проти того, як бізнес поводиться насправді, а не проти документа.
Операційці на двадцять людей і на двісті потрібні різні системи. Ми будуємо під те, де бізнес зараз, із запасом на наступну стадію, а не під оргструктуру, якої ще немає.
Моделі йдуть туди, де прибирають ручне введення. Схема обмежує, що саме їм дозволено записати, і їх міряють на реальних даних, перш ніж бізнесу дозволено залежати від результату.
Старі системи виходять по одному сценарію, і обидві працюють, поки нова не забере трафік. Перезапис із перемиканням рубильника — це те, як компанії втрачають рік.
Релізи, моніторинг і зміни, яких просять на другий і третій рік. Разом із передачею частин внутрішній команді, коли вона зростає. Більшість кастомного ПЗ помирає саме на цій фазі, тому ми плануємо її найпершою.
Розкажіть, як процес виглядає зараз і де він ламається.