Kliv

    Цю сторінку перекладено з англійської.

    Інструменти для бізнесу

    Побудуйте систему погодження заявок

    Kliv — ШІ-конструктор застосунків. Опишіть свої правила погодження заявок — пороги сум, маршрутизацію, делегування, погодження в Slack, звіти та журнал аудиту — і він створить застосунок.

    kliv.dev

    Просто введіть свою ідею в текстове поле, і AI створить її для вас

    353 символів

    Що таке Kliv?

    Kliv — не готовий сервіс із фіксованими кроками, а ШІ, який створює програмне забезпечення за вашим описом.

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

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

    Чому погодження гине в пошті

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

    Kliv будує систему погодження навколо ваших правил. Заявки, маршрутизація, рішення, делегування та звіти зберігаються у базі даних, яка належить вам, тож відповідь на питання «хто це погодив?» — це запис, а не пошук у пошті.

    Записи, які запитав би аудитор

    Система погодження має довести, що сталося пізніше. Ці записи це роблять.

    Заявки

    Кожна заявка містить позицію, суму, центр витрат і додану комерційну пропозицію у сховищі файлів.

    Правила маршрутизації

    До 20 000 ₴ — керівнику. Від 20 000 до 200 000 ₴ — керівнику відділу. Понад цю суму — фінансовий відділ і керівник майданчика. Версія правила, за яким маршрутизували заявку, зберігається разом із нею.

    Рішення

    Погодження, відмова та повернення на доопрацювання — це рядки з виконавцем і часовою міткою.

    Делегування

    Погоджувач може передати чергу на визначений період. Рішення, ухвалені під час делегування, назавжди позначаються відповідно.

    Видимість

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

    Приклад: виробник деталей Олени

    Ось як один виробник міг би використовувати систему погодження, побудовану на Kliv. Це лише приклад — ви опишете власні пороги сум, категорії, правила делегування та вимоги до аудиту.

    01

    Заявка на закупівлю починається з потрібних фактів

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

    02

    Сума визначає маршрут

    150 000 ₴ потрапляють між порогами, тож заявка йде до керівника відділу, а потім у фінансовий відділ. Обраний ланцюжок погодження фіксується разом із заявкою.

    03

    Погоджувач діє зі Slack

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

    04

    Делегування покриває відпустку контролера

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

    05

    Заявка закривається з перевіреним слідом

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

    Опишіть правила погодження, які вам потрібні

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

    kliv.dev

    Погодження закупівель

    Порогові суми, центри витрат і прикріплені комерційні пропозиції.

    “Побудуй робочий процес погодження закупівель. Заявки до 20 000 ₴ ідуть керівнику, від 20 000 до 200 000 ₴ — керівнику відділу, а понад 200 000 ₴ — у фінансовий відділ і керівнику майданчика. Вимагай прикріплення комерційної пропозиції, відстежуй центри витрат, підтримуй делегування на час відпустки та щомісяця надсилай поштою звіт про витрати за відділами.”

    kliv.dev

    Погодження витрат

    Фото чеків, черги керівників і вивантаження для фінансового відділу.

    “Побудуй застосунок для погодження витрат, де співробітники фотографують чеки, керівники погоджують їх із черги, витрати понад 40 000 ₴ додатково потребують фінансового відділу, а погоджені витрати вивантажуються у щомісячний реєстр із співробітником, категорією, ПДВ і посиланням на чек.”

    kliv.dev

    Контроль випуску креслень

    Погодження конструкторського відділу й відділу якості перед випуском.

    “Побудуй робочий процес випуску інженерної документації, де кожне креслення потребує погодження конструкторського відділу та відділу якості, перш ніж стати випущеною редакцією. Зроби старі редакції доступними лише для читання, фіксуй, хто погодив кожен перехід, і сповіщай у Slack про випуск креслення.”

    Як усе працює разом

    Правила можна змінювати. Пороги сум, категорії та ланцюжки погодження — це дані, які ви редагуєте. Якщо політика зміниться, достатньо описати зміну, і Kliv оновить застосунок.

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

    Спробу самопогодження можна перевірити. Kliv може запустити сценарій, у якому заявник намагається погодити власну заявку на 150 000 ₴, і перевірити, що спробу відхилено.

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

    Погодження заявок часто веде до інших внутрішніх інструментів; сторінка про внутрішні інструменти продовжує цю тему.

    Поширені запитання

    Що таке Kliv?

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

    Я отримую справжній застосунок чи шаблон?

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

    Чи можна змінити його після створення?

    Так. Ви можете змінити порогові суми, погоджувачів, категорії, канали Slack, звіти чи правила делегування, просто попросивши про це.

    Чи можна редагувати історію заднім числом?

    Ні. Рішення — це записи лише для додавання, з виконавцем і часовою міткою. Виправлення — це новий запис, що посилається на попередній.

    Що відбувається, коли погоджувач відсутній?

    Записи делегування охоплюють визначені дати початку й закінчення, а рішення, ухвалені під час делегування, позначаються відповідно.

    Чи впливають зміни правил на заявки, що вже в процесі?

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

    Чи можуть погоджувачі діяти зі Slack?

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

    Як погоджувачі входять у систему?

    Через облікові записи у вашому застосунку: електронна пошта й пароль, вхід через Google, passkeys і двофакторна автентифікація, якщо вони вам потрібні.

    Чи можуть заявники бачити чужі заявки?

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

    Чи можу я використати власний домен?

    Так. Застосунок може працювати на вашому власному домені.

    Чи можу я згодом піти від Kliv?

    Так. Код застосунку синхронізується з вашим власним репозиторієм Git, тож перехід — це git pull, а не переписування з нуля.

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

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