Рішення / Внутрішні інструменти та операції
Замініть електронну таблицю, яка керує компанією
У кожної компанії є один — аркуш, спільна скринька вхідних повідомлень, процес, який об’єднує пам’ять. Опишіть це та отримайте справжній інструмент: ролі, схвалення, журнал аудиту та ваш стек.
Справа для його побудови
Навіщо створювати це замість builderа внутрішніх інструментів?
Розробники внутрішніх інструментів стягують плату за робоче місце за привілей створювати його самостійно — полотно віджетів над вашою базою даних, за ціною такою, що надання доступу всій компанії — це саме те, що ви не можете собі дозволити. І інструмент ще потрібно створити: написати запити, налаштувати дозволи, кожна зміна – черговий сеанс у їхньому редакторі. Kliv змінює угоду: опишіть процес, і інструмент прибуде зібраний — і він ваш, а не лічильник на робоче місце у ваших власних операціях.
Немає двох компаній, які схвалюють покупку через постачальника або передають заявку однаково — внутрішній процес — це найбільш індивідуальне програмне забезпечення, яке існує, тому воно живе в електронних таблицях. Опишіть свій: хто подає, хто схвалює, за якого порогу, що реєструється, який канал Slack про це чує. Цей опис є інструментом.
Анатомія системи
Що насправді знає інструмент операцій
Операційний інструмент — це чесний процес: запити під час польоту, правила, яких вони дотримуються, люди, яким дозволено їх переміщати, і слід, який вони залишають. Ось форму, яку буде будувати Kliv.
Робочі предмети
Все, що проходить через процес — запити, квитки, замовлення — як записи зі станом, а не рядки на аркуші.
Етапи та пороги
Ваш процес як дані: хто схвалює, понад яку суму, у якому порядку.
Люди та ролі
Подавачі, затверджувачі, адміністратори — доступ до організаційної схеми.
Аудиторський слід
Хто що робив, коли — кожна дія є записом, який ніхто не може спокійно редагувати.
Інтеграції
Інструменти, які вже керують компанією: рішення публікується в Slack, робота приземляється в Trello.
Приладові панелі
Глибина черги, тривалість циклу, хто на кого чекає — цифри в тих самих записах, а не щотижневий експорт.
Хто що бачить
Правила, які виконує база даних
- Відправник бачить власні запити — стіна належить базі даних, а не відфільтрованому перегляду.
- Порогові значення застосовуються, а не запам’ятовуються: запит у 1000 доларів США не може пропустити фінансування.
- Кожна зміна стану реєструється, хто і коли — контрольний журнал записується сам.
- Доступ залежить від ролей — коли хтось змінює команду, двері змінюються разом з ним.
Нічого з цього не є екзотикою. Це те, за що прикидалася електронна таблиця — з тією різницею, що тут правила діють, коли ніхто не дивиться.
Що збирає Kliv
Список покупок частин платформи — кожна вбудована, кожна комбінується з іншими.
Ролі та аудит
Подавачі, затверджувачі, аудитори — формований доступ до організаційної схеми, кожна дія реєструється.
Ваш процес як записи
Запити, етапи та рішення живуть у вашій власній базі даних — імпортовані з електронної таблиці, яку вони втекли.
Стек, підключений проводом
Рішення надсилаються в Slack, робота переміщується в Trello — команда зберігає свої інструменти.
Перед запуском
Перший тиждень, перед запуском
Інструмент замінює те, від чого компанія вже залежить, тому перший тиждень — це завоювання такої довіри.
Формуйте процес
Опишіть потік, як він насправді виконується: хто подає, хто затверджує, порогові значення, що потрібно реєструвати. Kliv створює перший попередній перегляд із уже застосованими правилами.
Зробіть це своїм
Слова вашої команди — якщо ви називаєте їх PO, інструмент називатиме їх PO. Суть замовлення в тому, що навчання нікому не потрібно.
Проведіть стек
Підключіть Slack, наведіть дошку Trello та імпортуйте електронну таблицю — її рядки стають записами інструменту, тож перший день починається з справжнього відставання.
Спробуйте його зламати
Надішліть запит на 1200 доларів як неправильну роль і все одно спостерігайте, як він направляється до фінансування. Схвали щось і спостерігай, як Slack почує про це. Потім прочитайте журнал — він уже повинен розповідати історію.
Передайте його команді
Запросіть усіх із їхніми реальними ролями — володіння інструментом означає, що ним може користуватися вся компанія. Електронна таблиця отримує прощальну вкладку: переміщено.
На замовлення, без індивідуального ризику
Спеціальне програмне забезпечення раніше означало бюджет, підрядника та контракт на обслуговування. Це інша угода.
Запчастини класу Enterprise
Вхід, примусові дозволи в базі даних, виставлення рахунків, аудит, email — компоненти вашої спеціально розробленої системи є тими самими надійними частинами, на яких працює кожен застосунок Kliv. Ви створюєте перевірену інфраструктуру; ви не замовляєте код з нуля.
Змінює корабель по порядку
Коли ваш процес змінюється, скажіть про це — зміни вбудовані в розмову, ви переглядаєте їх у режимі попереднього перегляду, і нічого не досягає ваших користувачів, доки ви не опублікуєте. Комерційні зміни можна навіть відрепетирувати в Sandbox із симуляцією грошей і часу.
Ніхто не може загасити
Стандартні інструменти змінюють ціну, переробляють і виводять з експлуатації згідно з графіком постачальника — і ваш робочий процес йде разом з ними. Ваш застосунок Kliv змінюється лише тоді, коли ви його змінюєте. Це ваш продукт, а не місце в чужому.
Скажи це одним реченням
“Створіть інструмент затвердження постачальника, де будь-хто може подати запит, фінансовий відділ схвалює все, що перевищує 1000 доларів США, схвалення надсилає на Slack, і кожне рішення реєструється тим, хто і коли.”
Ось як це справді починається — опишіть це, а потім уточніть у розмові.
Побудувати або купити
Чому б просто не використати builder внутрішніх інструментів?
| З полиці | З Kliv | |
|---|---|---|
| Хто його будує | Ви робите — у їхньому редакторі, віджет за віджетом, запит за запитом. | Ви описуєте процес; інструмент надходить зібраним і змінюється таким же чином. |
| Структура собівартості | За місце на місяць — доступ усієї компанії є дорогим випадком. | Ви володієте інструментом; Сенс полягає в тому, щоб ціла компанія використовувала його. |
| Ваш процес | Віджети, які ви підключаєте, щоб наблизити його. | Пороги, етапи та ролі застосовуються точно так, як описано. |
| Аудит і доступ | Журнали інформаційної панелі постачальника. | Журнал аудиту у вашій власній базі даних із правилами, які застосовуються в рядку. |
| довголіття | Підписка на запитання фінансового директора щороку. | Інструмент, який переживає розмови з постачальниками — ніхто не може його припинити. |
Хто його будує
З полиці: Ви робите — у їхньому редакторі, віджет за віджетом, запит за запитом.
З Kliv: Ви описуєте процес; інструмент надходить зібраним і змінюється таким же чином.
Структура собівартості
З полиці: За місце на місяць — доступ усієї компанії є дорогим випадком.
З Kliv: Ви володієте інструментом; Сенс полягає в тому, щоб ціла компанія використовувала його.
Ваш процес
З полиці: Віджети, які ви підключаєте, щоб наблизити його.
З Kliv: Пороги, етапи та ролі застосовуються точно так, як описано.
Аудит і доступ
З полиці: Журнали інформаційної панелі постачальника.
З Kliv: Журнал аудиту у вашій власній базі даних із правилами, які застосовуються в рядку.
довголіття
З полиці: Підписка на запитання фінансового директора щороку.
З Kliv: Інструмент, який переживає розмови з постачальниками — ніхто не може його припинити.
Загальні запитання
Чи може він забезпечити дотримання порогів затвердження?
Так, порогові значення – це правила даних, а не домовленості. Запит на 1000 доларів США спрямовується на фінансування кожного разу, включно з тим, коли всі зайняті, і ніхто не перевіряє.
Що фіксує аудиторський слід?
Кожна зміна стану: хто подав, хто схвалив, хто редагував і коли — записи у вашій власній базі даних, доступні для читання аудитором і експортовані за запитом перевірки.
Чи можемо ми імпортувати електронну таблицю, яку використовуємо сьогодні?
Так — його рядки імпортуються у вашу власну базу даних, тому інструмент починає працювати з реальним резервом, а не порожнім. Придумані вами стовпці стають полями з правилами.
Чи працює це з Slack та рештою нашого стеку?
Так, рішення та ескалації публікуються на вибраних вами каналах, а робота, яка живе в Trello, потрапляє туди як картки. Команда зберігає свої інструменти; відросток набирає ості.
Як ми контролюємо, хто що бачить?
Ролі, що застосовуються в базі даних: заявники бачать власні запити, ті, хто затверджує, бачать свою чергу, аудитори читають усе і нічого не торкаються. Спільний логін не може витікати тому, що рядки відмовляються.
Що відбувається, коли процес змінюється?
Скажімо так — новий етап, інший поріг, інший затверджувач. Перегляньте зміни в попередньому перегляді, опублікуйте їх, і інструмент слідуватиме організації, а не навпаки.
