Глосарій Канбан-методу

Дії, що виконуються в межах робочого процесу надання сервісу (service delivery) та просувають робочий елемент до наступного кроку в процесі виявлення/дослідження знань (knowledge discovery). Одна або кілька активностей можуть бути візуалізовані як колонка на Канбан-дошці.

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

У Канбан-методі Барабан-Буфер-Канат є одним із механізмів реалізації системи витягування.

Те, що перешкоджає потоку елемента роботи. Блокування може бути частковим або повним.

Управління блокерами є фундаментальною практикою для підвищення ефективності робочого процесу та скорочення часу виконання (lead times). Блокер визначається як несподівана, непередбачувана подія, яка зупиняє просування активного робочого елемента. Оскільки блокери створюють очікування та збільшують обсяг незавершеного виробництва (WIP), вони є основним рушієм затримок у постачанні та причиною появи «довгого хвоста» (fat-tailed) у розподілі часу виконання.

Типові причини виникнення блокерів

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

• Обмеження ресурсів: тимчасове переведення члена команди зі спеціалізованими знаннями на інше завдання або відсутність доступу до необхідної системи.

• Проблеми з якістю: виявлення дефекту або потреба в непередбаченому переробленні (rework), що зупиняє прогрес до моменту вирішення проблеми.

У системному мисленні буфер визначається як стабілізаційний запас відносно потоку (наприклад, рівень запасів або резервні фонди). Однак існує ключова концептуальна відмінність між тим, як буфери визначаються та застосовуються в методі Канбан, порівняно з традиційною Теорією обмежень (TOC).

У Канбан буфер — це фізична або віртуальна черга робочих завдань (представлених у вигляді карток на дошці), розміщена перед певною активністю або обмеженням (constraint), щоб гарантувати постійне надходження роботи. Натомість у традиційній TOC та її системі планування «Барабан-Буфер-Мотузка» (Drum-Buffer-Rope, DBR) буфер — це визначений проміжок часу, а не фізичні об'єкти. Буфери в TOC контролюють випуск матеріалів, щоб гарантувати їхнє прибуття до обмеження за визначений час до початку запланованої обробки.

Слід взяти до уваги, що необмежені буфери руйнують Канбан-системи - робота накопичується, рівень багатозадачності стрімко зростає, а час виконання (lead time) подовжується і стає вкрай непередбачуваним.

Щоб відновити передбачуваність потоку організації повинні поступово ліквідувати буфери. Насамперед це досягається шляхом об'єднання лімітів WIP для суміжних колонок — наприклад, поєднання колонки активності (як-от «Тестування») та її черги «Готово» (Done) під єдиним спільним лімітом WIP. Це чітко демонструє, що ці дві колонки складають єдину активність, не дозволяючи черзі «Готово» перетворитися на неконтрольовану чергу.

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

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

Одна з 6 загальних практик Канбан-методу. Ми хочемо зробити роботу та її потік видимими, щоб вони не були прихованими. Ми також хочемо зробити інформацію про роботу, її ризики або процес видимою за допомогою таких елементів, як діаграми.

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

Зазвичай їх визначають як етап робочого процесу, який демонструє найдовший середній локальний час циклу (local cycle time).

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

• У необмежених системах (без лімітів WIP): велика кількість незавершеної роботи природним чином накопичується безпосередньо перед вузьким місцем, тоді як наступні етапи (downstream) часто залишаються «голодними» (без роботи) або простоюють. На діаграмі накопичення потоку (CFD) це легко помітити як кольорову смугу, що розходиться та розширюється, відображаючи зростання черги.

• У обмежених системах (із лімітами Канбан/WIP): вузькі місця виявити набагато важче, оскільки ліміти WIP не дозволяють роботі накопичуватися. У цьому випадку вузьким місцем зазвичай є етап процесу, що знаходиться безпосередньо перед першою точкою «голодування» у робочому процесі. На CFD це візуалізується, коли кольорова смуга практично зникає, оскільки на цьому наступному етапі робота повністю відсутня.

2. Правило розміщення вузького місця
Фундаментальним архітектурним правилом у Канбан є те, що вузькі місця завжди повинні перебувати після точки прийняття зобов'язань (commitment point).
Якщо вузьке місце розташоване до точки прийняття зобов'язань (під час дослідження чи аналізу), це означає, що команда доставки (downstream), яка знаходиться далі за потоком, має дорогу та змарновану надлишкову потужність (slack capacity). Часто цей надлишок маскується тим, що працівників із наступних етапів залучають на попередні етапи для допомоги з оцінюванням, плануванням або створенням прототипів. Таке втручання порушує передбачуваність на етапі доставки, роблячи надання послуг непередбачуваним і невідповідним потребам (unfit-for-purpose).
Загальне правило: якщо ви можете відкинути або скасувати роботу, поки вона перебуває у вашому вузькому місці, то ваша точка прийняття зобов'язань розташована не в тому місці. Ви не повинні витрачати цінні ресурси обмеженого вузького місця на роботу, яка згодом може втрати актуальність.

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

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

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

• Розгалуження (Bifurcation): спрямовуйте завдання з нижчим рівнем ризику в обхід вузького місця, дозволяючи неспеціалізованим працівникам із вільною потужністю виконувати цю роботу (можливо, з меншою точністю чи якістю), щоб захистити обмеження.

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

Крок 2: Підпорядкуйте все інше вузькому місцю (Subordinate)
Узгоджуйте решту робочого процесу з темпом роботи вузького місця:

• Контролюйте вхідний потік: дозволяйте новій роботі надходити в систему лише з тією швидкістю, з якою вузьке місце завершує роботу (впроваджуючи систему витягування типу «Барабан-Буфер-Канат» / Drum-Buffer-Rope).

• Якість на попередніх етапах (Upstream): забезпечте контроль якості до вузького місця, щоб елементи низької якості до нього не надходили.

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

Крок 3: Розширте вузьке місце (Elevate)
Якщо максимальне використання та підпорядкування не дають достатньо потужності, інвестуйте ресурси у збільшення потужності вузького місця:

• Додайте більше людей, спеціалізованих інструментів або обладнання.

• Частково або повністю автоматизуйте діяльність у вузькому місці, щоб збільшити пропускну здатність і усунути затримки, пов'язані з доступністю ресурсів.

• Проводьте навчання для підвищення якості та скорочення часу циклу.

Частина канбан-системи до точки прийняття зобов’язань (commitment point), де запити клієнтів досліджуються, оцінюються та перетворюються на опції. Робота у вхідному потоці є необов’язковою: її можна відкинути без витрат, доки вона не перетнула точку прийняття зобов’язань і не стала частиною низхідного потоку (downstream) — обов’язкової до виконання доставки.

Управління вхідним потоком (дослідження, аналіз, пріоритезація опцій) часто називають upstream kanban або discovery kanban.

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

Графік, який відображає вимірювану метрику в часовій послідовності. Зазвичай використовується для візуалізації минулих показників часу виконання (Lead Times) або швидкості постачання (Delivery Rates). Однією з головних переваг графіка динаміки є можливість побачити тенденції (тренди) у даних. Поширене запитання, яке варто розглянути при аналізі: «Час виконання зростає, зменшується чи залишається в межах очікуваного коливання?»

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

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

Ця модель високоефективна та маловитратна альтернатива традиційним ініціативам «спроєктованих та керованих» змін (designed and managed change). Замість того щоб нав'язувати деструктивну реорганізацію згори донизу, еволюційний підхід починається з поточного стану, поважає існуючі ролі та процеси і дозволяє придатним для використання (fit-for-purpose) методам роботи виникати природним шляхом.
Нормативні зміни проти структурних
Щоб зрозуміти, чому люди чинять опір корпоративним трансформаціям, метод спирається на соціальну психологію та розділяє зміни на дві категорії:

• Нормативні зміни (Normative Change): це зміна інструменту, практики або методу, яка не змінює соціальні відносини, статус, ідентичність, повагу чи гідність. Оскільки ці зміни не загрожують професійній ідентичності людини, вони не викликають опору.

• Структурні зміни (Structural Change): це зміна, яка змінює соціальні структури, лінії підпорядкування, взаємовідносини, посади, статус або організаційну ієрархію. Люди на підсвідомому рівні переживають структурні зміни як психологічну кризу (яка характеризується тривогою за свій статус, роль та гідність).

Традиційні Agile-трансформації зазвичай починаються саме зі структурних змін - нові ролі, посади, крос-функціональні команди. Це миттєво занурює працівників у психологічну кризу.
Метод Канбан, заснований на Теорії загрози ідентичності (Identity Threat Theory), уникає цього, впроваджуючи спочатку нормативні зміни. Оскільки працівники співпрацюють для покращення потоку, вони добровільно відмовляються від старих посад і адаптують свої відносини, дозволяючи структурним змінам виникати органічно, без провокування страху чи активного опору.

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

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

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

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

J-крива аналізується за трьома структурними вимірами:

• Безпека (Глибина): Відображає серйозність падіння продуктивності. Вона ставить питання: наскільки низько може впасти ефективність системи, перш ніж організація зазнає негативних наслідків

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

• Управлінська толерантність (Executive Tolerance): Разом Безпека та Терпіння формують «управлінську толерантність» - поріг, до якого якого керівництво готове терпіти, перш ніж вони запанікують, скасують ініціативу та і повернуть систему назад до застарілого процесу.

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

Архетип класу сервісу, що застосовується до елементів роботи, для яких вплив затримки настає в певну дату.

Шість загальних практик Канбан-методу:

• Візуалізація

• Обмеження незавершеної роботи (WIP)

• Управління потоком

• Явні правила

• Цикли зворотного звʼязку

• Спільне вдосконалення, розвиток через експерименти

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

Тип циклу зворотного звʼязку, призначений для зосередження на управлінні роботою, наприклад:

• Командна зустріч щодо поповнення

• Командна канбан-зустріч

• Командна ретроспектива

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

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

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

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

Візуальне відображення карток, які представляють елементи роботи в канбан-системі. Зазвичай дошки організовані у вертикальні колонки, які представляють активності. Деякі дошки використовують горизонтальні доріжки (swimlanes) для подальшого покращення візуалізації правил, типів робіт, класів сервісу або іншого атрибуту, який є важливим для управління роботою. Додаткові елементи можуть бути представлені кольором або іншими атрибутами картки. Картки переміщуються вправо по колонках відповідно до прогресу елементів роботи, які вони представляють. WIP ліміти та інші правила можуть бути представлені візуально.

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

Фундаментальна когнітивна модель Канбан-методу для перегляду, управління та вдосконалення сучасної інтелектуальної роботи (knowledge work). Замість традиційного погляду на організацію крізь ієрархічні функціональні підрозділи, Канбан-лінза представляє підприємство як органічну мережу взаємопов’язаних сервісів, що регулюються чіткими правилами.

Канбан-лінза встановлює три ключові постулати: творча інтелектуальна праця є сервіс-орієнтованою; надання послуг передбачає робочий потік (workflow); а сам робочий потік — це серія дій із відкриття знань (knowledge discovery).

Метод для визначення, управління та вдосконалення сервісів, які виконують інтелектуальну роботу.

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

Мотивація використання методу Канбан структурована навколо трьох основних контекстів:

• Контекст сталого розвитку (The Sustainability Agenda): спрямований всередину організації для зменшення перевантаження, створення кращої якості та зміцнення професійної гордості й задоволеності клієнтів.

• Сервіс-орієнтований контекст (The Service Orientation Agenda): спрямований назовні з фокусом на ефективність та задоволеність клієнтів, гарантуючи, що організація може впевнено брати зобов'язання щодо постачання та приймати управлінські рішення.

• Контекст життєздатності (The Survivability Agenda): спрямований у майбутнє для розвитку стійкості та конкурентоспроможності, що дозволяє бізнесу дотримуватися своїх обіцянок, успішно реалізовувати стратегію та покращувати ринкове позиціонування.

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

Візуальне представлення елемента роботи. Картку також можна називати тікетом.

Картка є візуальною метафорою елементу роботи - незалежно від того, чи це окрема задача, функція продукту,кінцевий результат (deliverable) або запит на обслуговування від клієнта. Основна мета картки — зробити невидиму інтелектуальну працю (knowledge work) видимою та консолідувати ключову інформацію на одному візуальному артефакті для полегшення швидкого та якісного прийняття рішень.

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

• Прискорений

• З фіксованою датою

• Нематеріальний

• Стандартний

Клас обслуговування визначається набором чітких правил (explicit policies), які диктують, як саме конкретне робоче завдання має опрацьовуватися під час його проходження крізь систему. Будучи фундаментально заснованими на вартості затримки (cost of delay), ці класи розроблені для того, щоб узгодити процес надання сервісу із очікуваннями клієнтів та оптимізувати економічну ефективність організації.

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

Час між отриманням запиту клієнта та його виконанням.

Час виконання для клієнта (Customer Lead Time) — який у зрілих системах часто називають просто часом виконання (lead time) — є критично важливою зовнішньою метрикою

Визначення часу виконання для клієнта

• Вікно «від запиту до доставки»: Час виконання для клієнта — це час, що минув з моменту, коли клієнт вважає, що його замовлення було прийнято (точка запиту — request point), до моменту, коли завдання стає готовим до доставки.

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

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

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

Діаграма, зазвичай діаграма виконання (run chart), що показує контрольні діапазони, за межами яких процес може вважатися «неконтрольованим» у певному специфічному сенсі.

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

Головна функція контрольної карти полягає в тому, щоб допомогти якісно та кількісно розрізняти два абсолютно різних джерела коливань (варіативності) ефективності процесу:

• Загальні (випадкові) причини коливань (Common Cause Variation): це «природні» коливання, викликані самою конструкцією, правилами та політиками системи (наприклад, поточними лімітами WIP, навичками, інструментами та управлінськими процедурами). Якщо варіативність через загальні причини є занадто великою або неприйнятною, необхідно змінювати дизайн самої системи (наприклад, модифікувати ліміти WIP, змінювати чіткі правила або коригувати розподіл потужностей).

• Спеціальні (невипадкові) причини коливань (Special Cause Variation): це коливання, пов'язані з тимчасовими, зазвичай зовнішніми обставинами, які виходять за межі нормальних параметрів роботи системи (наприклад, збої у постачальників, загальний страйк, суворі погодні умови або вимкнення електроенергії). Зміна дизайну системи не є правильною відповіддю на спеціальні причини коливань; натомість організації повинні застосовувати стратегії управління ризиками та пом'якшення їхніх наслідків (такі як плани дій на випадок непередбачених обставин або обхідні шляхи).

Використання контрольних карт для правильної класифікації коливань дозволяє уникнути двох критичних помилок, визначених піонером управління якістю В. Едвардсом Демінгом:

• Помилка управління №1: Відсутність будь-яких змін у дизайні системи чи її чітких правилах, коли небажані показники ефективності є очевидним системним збоєм (загальна причина).

• Помилка управління №2: Перепроектування або втручання в систему (tampering) у відповідь на тимчасову, зовнішню подію (спеціальна причина).

Показник, за яким оцінюється, чи відповідає сервіс потребам і очікуванням клієнта (fit-for-purpose). У Канбан-методі клієнтський час виконання є прикладом орієнтованого на клієнта критерію відповідності, який використовується для оцінки життєздатності сервісу.

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

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

• Lead time (час виконання) у різних варіаціях.

• Delivery rate (швидкість постачання) або throughput (пропускна здатність).

• Рівні WIP (незавершеного виробництва) на різних етапах системи.

• Blockers (блокери) — чинники, що зупиняють роботу.

• Failure demand (запити на доопрацювання) — запити, спричинені недоліками попередньої роботи.

Інші метрики, такі як якість або переробки, можуть бути досить цінними. Командам не слід мати надто багато метрик для початку, але водночас вони повинні усвідомлювати, що «ви отримуєте те, що вимірюєте», тому збір метрик має бути спроєктований так, щоб мінімізувати маніпуляції системою («gaming the system») і водночас підтримувати управління потоком. Поширені візуалізації метрик, що використовуються для розуміння системи:

• Розподіл часу виконання (Lead time distribution).

• Графік динаміки часу виконання або швидкості постачання (Run chart).

• Діаграма накопичення потоку (Cumulative flow diagram).

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

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

KMM побудована на трьох фундаментальних стовпах:

• Культура («Як ми живемо»): явні та приховані цінності, принципи та норми, які визначають, що люди відстоюють, і визначають їхню поведінку.

• Практики («Як ви робимо речі»): регулярні дії, метрики, рутини та каденції, що використовуються для управління роботою.

• Результати («Чого ми досягаємо»): спостережувані результати, які демонструють клієнтам та стейкхолдерам, чи є бізнес відповідним потребам (fit-for-purpose), стабільним та життєздатним.

Вкрай важливо, що KMM спирається на підхід, орієнтований на цінності: бажані результати приходять слідом за впровадженням практик, впровадження практик підтримується культурою, а культура керується цінностями.

KMM визначає сім рівнів зрілості, які характеризуються результатами, культурою та практиками:

• Рівень 0: Неусвідомлений (Oblivious) – фокус повністю зміщений на персональні завдання та індивідуальний тайм-менеджмент; робота непередбачувана.

• Рівень 1: Орієнтований на команду (Team-Focused) – початкова колаборація всередині малих груп; робота характеризується принципом «ніколи однаково двічі», спираючись на індивідуальний героїзм.

• Рівень 2: Керований клієнтом (Customer-Driven) – сформовано основний робочий потік; робота послідовна, але результати суперечливі («ніколи однакового результату двічі»), що вимагає управлінського героїзму для проштовхування завдань.

• Рівень 3: Відповідний призначенню (Fit-for-Purpose) – встановлено синхронні зобов'язання перед клієнтами та збалансовані наскрізні робочі процеси; очікування клієнтів стабільно виконуються без героїзму.

• Рівень 4: Хеджований від ризиків (Risk-Hedged) – реалізовано кількісне управління ризиками на основі моделей, хеджування ризиків (наприклад, розподіл потужностей) та стабільна економічна ефективність («більше жодних сюрпризів»).

• Рівень 5: Лідер ринку (Market Leader) – невтомне прагнення до досконалості та мінімальних покращень (marginal gains) з використанням наукового методу та експериментів для випередження конкурентів.

• Рівень 6: Створений для виживання (Built for Survival) – здатність до подвійного контуру навчання (double-loop learning) для переосмислення та перезапуску того, «як, що, чому і ким» є організація, щоб виживати під час руйнівних галузевих зрушень.

Три класичні форми втрат із Lean і виробничої системи Toyota, на боротьбу з якими історично спрямована практика обмеження незавершеної роботи (Limit WIP):

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

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

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

Цикл зворотного звʼязку, розроблений для ітеративного наближення до кращого розуміння певної ситуації. Кроки наукового методу:

• Спостереження

• Гіпотеза

• Експеримент

• Збір даних

• Аналіз результатів

• Прийняття або відхилення гіпотези

• Повторення

Архетип класу сервісу, що застосовується до елементів роботи, для яких вплив затримки є невідомим.

Одна з 6 загальних практик Канбан-методу. Ми хочемо обмежити незавершену роботу, щоб зробити можливою систему витягування для покращення передбачуваності та потоку. Коли незавершена робота не обмежена, система часто може перевантажуватися, що призводить до поганої пропускної здатності, передбачуваності та якості. Незавершена робота зазвичай обмежується правилами WIP лімітів.

Обмеження незавершеного роботи є ключовою практикою впровадження візуальних сигналів (канбанів) для лімітування кількості активних, незавершених завдань у системі. Історично ця практика розроблена для боротьби та усунення трьох класичних форм втрат, визначених у Lean та виробничій системі Toyota: muri (перевантаження людей і систем), mura (нерівномірність потоку) та muda (діяльність, що не додає цінності, затримки та транзакційні витрати). Див. Муда, Мура, Мурі.
Головні цілі обмеження WIP включають:

• Захист працівників від перевантаження, що запобігає стресу, падінню якості та надмірній кількості перероблень (rework).

• Протидію багатозадачності, яка призводить до затягування окремих завдань і робить час їхнього завершення вкрай непередбачуваним.

• Прискорення потоку для підвищення загальної швидкості постачання та скорочення часу виконання завдань для клієнта (customer-facing lead times).

• Заохочення відтермінованого прийняття зобов'язань, що дозволяє приймати рішення ближче до «останнього відповідального моменту» (last responsible moment), коли доступна краща інформація.

• Стимулювання співпраці, спонукаючи членів команди гуртуватися (swarm) навколо заблокованих або застряглих карток для звільнення активної потужності, замість того щоб починати нову, ще не узгоджену роботу.

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

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

• Огляд надання послуг (Service Delivery Review)

• Огляд ризиків (Risk Review)

• Операційний огляд (Operations Review)

До моменту прийняття зобов'язань (commitment point) у нас є багато ідей, вимог або потреб, що надходять від клієнтів і можуть мати цінність. Дехто називає це «беклогом» (backlog), проте в методі Канбан ми віддаємо перевагу терміну «опції» (options) для позначення того, що потенційно має цінність. Вони керуються у висхідній (upstream) частині Канбан-системи. Ми прагнемо перевіряти ці варіанти та обмежувати їх відповідно до наявних потужностей, враховуючи при цьому їхню терміновість. Це часто призводить до відсіювання багатьох варіантів ще до моменту надання послуги, що допомагає гарантувати, що процес надання послуг зосереджений на запитах з високою цінністю.
Це поняття «варіантів» допомагає команді уникати перевантаження роботою, яка може виявитися непотрібною. Чи є у вас запитання щодо того, як саме відокремити ці «варіанти» від робочих завдань, що вже знаходяться в потоці виконання?

Критична точка переходу в pull системі, коли команда повинна або взяти зобов'язання розпочати роботу над завданням, або визнати, що, швидше за все, вона доставить його із запізненням.

Хоча цей термін неформально використовується в літературі з Lean вже понад двадцять-тридцять років, метод Канбан дає йому суворе математичне визначення, засноване на імовірнісній природі часу виконання (lead times).

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

Останній відповідальний момент (LRM) формально визначається як 50-й перцентиль (медіана) розподілу часу виконання у вашій системі до бажаної дати доставки (Desired Delivery Date / DDD).

Формула: LRM=Desired Delivery Date−0.50×Lead Time Rang

Будь-яка дата початку, яка настає після LRM, класифікується як «безвідповідально пізня». У цей момент, оскільки ви перетнули медіану вашого розподілу часу виконання, ймовірність вчасної доставки завдання становить менше ніж 50%.

Те, чого можна очікувати в майбутньому від надання сервісу на основі попередньої ефективності. В інтелектуальній роботі ми маємо природню невизначеність і надаємо перевагу встановленню очікувань на основі історичних ймовірностей. Якщо ми знаємо, що історично у нас є стабільна система, яка виконує 85% елементів роботи впродовж 10 днів, ми можемо встановити відповідний очікуваний рівень сервісу (SLE) у 10 днів із 85% впевненістю.

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

У середовищах професійної інтелектуальної праці (knowledge work) робота здебільшого є невидимою, через що її неймовірно легко накопичувати та «проштовхувати» (push) занадто великий обсяг попиту на команду. Коли в організації відсутні можливості або правила для балансування вхідного попиту та її фактичної спроможності до доставки (delivery capacity), система стає перевантаженою.

Цей брак контролю призводить до серйозних наслідків:

• «Екзистенційне перевантаження» (The Existential Overhead): коли працівники змушені займатися багатозадачністю та тримати занадто багато відкритих, незавершених завдань, вони відчувають важкий когнітивний тягар. Вони втрачають здатність фокусуватися, завдання затягуються, а терміни їхнього завершення стають вкрай непередбачуваними.

• Падіння якості та переробки (Rework): робота в стані постійного перевантаження безпосередньо погіршує якість. Багатозадачність та перевантаження пам'яті призводять до збільшення кількості дефектів та переробок, що створює замкнене коло подальших затримок.

• Соціально-емоційне виснаження: постійне перевантаження руйнує задоволеність працівників, підвищує рівень стресу та завдає шкоди професійній гордості.

Робота, яку запитують клієнти сервісу. Канбан-системи прагнуть привести попит і ємність до рівноваги.

Замість того щоб розглядати всю вхідну роботу як однорідний, некерований потік, який потрібно розпочати негайно, Канбан ставиться до попиту як до багатовимірної змінної. Її необхідно активно класифікувати, вимірювати та балансувати з можливостями організації (delivery capacity).

Розуміння якості вашої вхідної роботи є передумовою для управління нею. Канбан поділяє попит на три основні економічні категорії:

• Попит на цінність (Value Demand)

• Попит на доопрацювання (Failure Demand)

• Хибний попит / Нецільова робота (False Demand): Робота, прийнята командою, яку вона насправді не повинна виконувати, зазвичай тому, що вона повністю виходить за межі того, що має надавати цей бізнес-підрозділ.

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

• Попит, який можна відхилити (Refutable Demand): Необов'язкова робота, яку команда може безпечно відхилити, відмовити або скасувати на попередньому етапі (upstream). Це дозволяє ухвалити повноцінне рішення щодо сортування (triage) у точці поповнення (replenishment point): зробити це зараз, зробити це пізніше або не робити взагалі.

• Попит, який не можна відхилити (Irrefutable Demand): Обов'язкова (недискреційна) робота, від якої немає можливості відмовитися. Це відбувається тому, що зобов'язання було взято на вищому рівні. Це юридичні/нормативні вимоги або критично важливі завдання (наприклад, відновлення робочого середовища після збою). Оскільки команди не можуть сказати «не робити взагалі», вони керують цим попитом, активно плануючи та згладжуючи його в часі на основі вартості затримки (cost of delay).

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

Термін введений Джоном Седдоном, який у ранній літературі з Канбан іноді називався failure load.

На відміну від «попиту на цінність» (value demand), який представляє фактичні, корисні результати, яких дійсно бажають клієнти, failure demand являє собою непотрібну роботу, якої можна було б уникнути і яка існує лише тому, що попередні результати роботи організації не виправдали потреб або очікувань клієнтів щодо якості.

У сфері професійних послуг та середовищах інтелектуальної праці (knowledge work) failure demand зазвичай проявляється кількома різними способами:

• Виправлення дефектів та багів (Defect-Fixing and Bugs): обробка та усунення виробничих дефектів або програмних помилок, виявлених клієнтами під час реальної експлуатації.

• Переробки через неузгоджені специфікації (Rework from Misaligned Specifications): переробки через поганий дизайн системи або фундаментальну нездатність належним чином зрозуміти та передбачити потреби клієнта під час початкового аналізу.

• Підтримка клієнтів та обхідні шляхи (Customer Support and Workarounds): обробка сплеску звернень у службу підтримки або впровадження ручних обхідних шляхів для користувачів, оскільки основні функції продукту є занадто повільними, неінтуїтивними або зламаними.

• Скасована робота (Aborted Work): робота, щодо якої вже було взято зобов'язання, яку було розпочато і яка спожила цінні зусилля команди, але в підсумку була скасована до її завершення. Оскільки така робота споживає потужність, так і не доставивши клієнту цінності, вона класифікується безпосередньо як втрати (waste) та failure demand.

• Хибний попит / Нецільова робота (False Demand / Unintended Work): робота, прийнята командою, яка ніколи не повинна була бути отримана або оброблена, оскільки вона повністю виходить за межі того, що насправді має надавати цей бізнес-підрозділ.

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

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

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

• Відмова від оцінювання (Eliminating Estimation). Традиційні зустрічі з планування є вкрай дорогими, оскільки команди витрачають значну частину своєї потужності на оцінювання завдань. Високозрілі Канбан-системи кардинально знижують транзакційні витрати на поповнення, повністю відмовляючись від оцінювання стандартних завдань. Натомість вони використовують історичні розподіли часу виконання (lead-time distributions) для встановлення угод про рівень обслуговування (SLA).

• Пріоритет терміновості над ROI. Під час поповнення основним критерієм прийняття рішень є терміновість та вартість затримки (Cost of Delay), а не традиційне вибудовування черги на основі повернення інвестицій (ROI). Питання полягає не в тому, яке завдання принесе найбільшу фінансову вигоду, а в тому, якою буде вартість затримки цього конкретного завдання протягом наступного інтервалу до наступної зустрічі з поповнення.

Основні принципи Канбан-методу для надання сервісу:

• Зрозуміти та зосередитися на потребах і очікуваннях клієнта

• Управляти роботою; дайте людям можливість самоорганізовуватися навколо неї

• Регулярно переглядати систему сервісу та її правила для вдосконалення

Канбан-метод підходить до еволюційних змін, використовуючи наступні три принципи:

• Почніть з того, що ви робите зараз

• Погодьтесь на вдосконалення шляхом еволюційних змін

• Заохочуйте прояви лідерства на усіх рівнях

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

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

Кількість елементів роботи, що виходять із системи або певної її частини; вимірюється в елементах роботи, завершених за певний період часу. Пропускну здатність часто називають частотою поставки.

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

Загальна практика робити правила явними розроблена для встановлення зрозумілих, письмових та узгоджених на основі консенсусу правил щодо того, як саме ведеться робота і як ухвалюються рішення в організації. Правила не є статичними бюрократичними інструкціями; натомість вони є частиною самої Канбан-системи, визначаючи, як робота рухається крізь кожен етап процесу, як вона візуалізується і як управляються взаємовідносини — як внутрішні, так і з клієнтами.
Роблячи правила чіткими, організації зменшують неоднозначність, що безпосередньо мінімізує затримки, тривожність та страх, викликані невизначеністю. Дослідження поведінкових економістів Урі Гнізі та Джона Ліста (детально описані в книзі «The Why Axis») показують, що середовища з чіткими, недвозначними правилами є більш справедливими, рівноправними та мають вищий рівень довіри. У Канбан візуалізація та закріплення правил є прямим способом підвищення соціального капіталу (рівня довіри всередині соціальної групи) та створення фундаменту для того, щоб працівники могли самостійно ухвалювати послідовні й логічні рішення.

Робочі елементи, які увійшли до системи або етапу та ще не вийшли з нього.

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

Одна з 6 загальних практик Канбан-методу. Див. Еволюційні зміни.

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

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

Фундаментальною архітектурною концепцією в Канбан є економічне розмежування двох різних типів партій:

• Технологічна партія (Process Batch): це партія роботи, яка виконується однією людиною, командою або на певному етапі діяльності перед її передачею далі. Технологічні партії традиційно оптимізуються для забезпечення локальної ефективності ресурсів, спеціалізації та зменшення накладних витрат на «налаштування» (setup) і «завершення» (cleanup). Наприклад, у Feature-Driven Development технологічною партією може бути невеликий пакет функцій, призначений одному розробнику.

• Партія доставки (Transfer Batch): це партія роботи, яка фактично передається далі ланцюжком створення цінності наступній групі працівників або доставляється безпосередньо кінцевому клієнту (наприклад, реліз програмного забезпечення). Партії оптимізуються з урахуванням подальших транзакційних витрат та витрат на координацію (downstream costs), таких як розгортання у клієнта, навчання користувачів, міграція баз даних та готовність служби підтримки.

Партії бажано розділяти. Наприклад, команда розробників може працювати дуже малими технологічними партіями (доставляючи окремі історії щодня), але об'єднувати їх у більший реліз раз на місяць, щоб підлаштуватися під ліміти сприйняття (absorption limits) клієнта.

Діаграма, що показує частоту спостережуого часу виконання елементів роботи. Вимірювання часу виконання має бути послідовним: вимірюється або Клієнтський час виконання, або Час виконання системи. Різні типи елементів роботи або різні класи сервісу можуть мати різний розподіл часу виконання. Розподіл часу виконання може бути індикатором передбачуваності системи.

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

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

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

• Діапазон від моди до медіани (Mode-to-Median Range): найпоширеніший результат (мода) разом із середньою точкою набору даних (медіаною).

• Високий перцентиль (85-й перцентиль): поріг, у межах якого доставляються 6 із 7 завдань. Такий показник успішності («шість із семи») цілком відповідає психологічним рамкам очікування більшості клієнтів у сфері професійних послуг і є основою для надійних угод про рівень обслуговування (SLA).

• Тип хвоста (Tail Type): є розподіл «тонкохвостим» (thin-tailed — передбачуваним) чи «товстохвостим» (fat-tailed — непередбачуваним).

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

На найнижчому рівні деталізації сервісом може вважатися конкретний тип роботи (наприклад, вирішення інциденту чи надання звіту), хоча зазвичай він складається з кількох внутрішніх дій (міні-сервісів), які можуть залишатися невидимими для кінцевого клієнта.
Замість того, щоб розглядати організацію крізь призму традиційних, ієрархічних функціональних та структурних підрозділів, Канбан використовує системне мислення та представляє підприємство як органічну мережу взаємопов'язаних сервісів, що регулюються чіткими правилами (explicit policies) через так звану Канбан-лінзу.
Канбан-лінза забезпечує фундаментальну когнітивну модель для перегляду, управління та вдосконалення сучасної інтелектуальної праці (knowledge work). Вона встановлює три ключові постулати:

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

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

• Робочий потік — це серія дій із відкриття знань (knowledge-discovery): замість фізичного складання, інтелектуальна праця просувається вперед шляхом поступового перетворення ідеї з високим рівнем невизначеності на повну, визначену та цінну інформацію.

Елемент роботи у вхідному потоці може бути витягнутий вниз за потоком лише тоді, коли є наявна спроможність. Наявна спроможність є сигналом. У канбан-системі сигналом є те, що обсяг незавершеної роботи нижчий за поточний WIP ліміт.
Правильне сприйняття сигналів витягування є важливим для переходу від системи проштовхування, яка перевантажує команди, до передбачуваної системи витягування.
Поширеною помилкою в Agile-спільноті є переконання, що картки або стікери на дошці — це і є «канбани». У справжній Каньан-системі все з точністю до навпаки:

• Картки представляють фактичні робочі елементи, запити клієнтів або результати роботи (deliverables).

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

Робочий елемент не може перетнути точку прийняття зобов'язань або перейти на наступний етап, доки порожнє місце - сигнал витягування - не дозволить йому це зробити.

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

• Ліміти WIP як межі спроможності: встановлюючи чітке обмеження на те, скільки завдань може одночасно перебувати в будь-якій частині робочого процесу, ви визначаєте максимальну спроможність системи.

• Метафора сигналізації: у справжній системі витягування картки на дошці представляють роботу, тоді як сам «канбан» (візуальний сигнал) — це насправді порожнє місце або вільний слот, що вказує на наявну вільну спроможність.

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

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

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

Вимірювання продуктивності системи. Вимірювання можуть включати час виконання та пропускну здатність. Для отримання додаткової інформації щодо вимірювань дивіться Метрики.

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

Абревіатура від «Підхід системного мислення до запровадження канбан» (Systems Thinking Approach To Introducing Kanban) — рекомендований підхід до запровадження канбан у новому контексті. Це настанова для проєктування сервісно-орієнтованих канбан-систем. Типові активності при використанні STATIK включають:

• Визначте джерела невдоволення

• Проаналізуйте попит та спроможність

• Змоделюйте робочий потік

• Визначте класи сервісу

• Спроєктуйте канбан-систему

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

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

1. Аналіз поточної ситуації: ретельне вивчення того, як саме зараз функціонує процес надання сервісу.

2. Виявлення реальних потреб: чітке визначення того, що виконавці та клієнти насправді прагнуть покращити.

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

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

Управлінська концепція Еліяху Голдратта, згідно з якою пропускна здатність будь-якої системи обмежена одним найслабшим елементом — вузьким місцем. Канбан-метод адаптує три кроки теорії обмежень для управління вузькими місцями: максимально використовуйте обмеження (exploit), підпорядкуйте йому решту системи (subordinate) і за потреби розширте його потужність (elevate).

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

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

Точка, в якій приймається рішення щодо початку активностей для постачання елемента роботи. До цієї точки виконана робота підтримує рішення щодо того, чи необхідно постачати елемент роботи (див. Вхідний потік).

Це життєво важлива межа на Канбан-дошці, де опції (ідеї, пропозиції або елементи беклогу) переходять у категорію взятої в роботу (committed) праці, яку команда доставки погоджується виконати, а клієнт — отримати. Вона діє як фізичний або віртуальний шлюз, що розділяє дослідження на попередніх етапах (upstream discovery), де робота є необов'язковою і її можна відкинути, та доставку на наступних етапах (downstream delivery), де робота вже є обов'язковою до виконання та готовою до витягування (pull).

Щоб робочий елемент перетнуі точку прийняття зобов'язань, він має задовольняти дві окремі умови:

1. Зобов'язання з боку клієнта: Клієнт повинен мати чітке очікування, що робота буде виконуватися, і зобов'язатися прийняти (та оплатити) готовий результат.

2. Зобов'язання з боку команди доставки: Сервісна команда повинна мати вільну спроможність для виконання роботи та зобов'язатися затягнути (pull) завдання й виконати його.

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

Відповідність сервісу очікуванням клієнта щодо тієї конкретної мети або потреби, яка в нього була під час формування запиту.

Три виміри функціональної придатності. Згідно з фреймворком «Fit for Purpose», створеним Девідом Дж. Андерсоном та Олексієм Жегловим, організація повинна управляти трьома окремими вимірами, щоб гарантувати, що її пропозиції відповідають призначенню:

• Дизайн (Design): Функціональна якість та характеристики продукту чи послуги. Цей вимір визначає, чи володіє пропозиція належними можливостями та рівнем точності («достатньо хорошим» — good enough), щоб задовольнити конкретні вимоги користувача.
• Реалізація (Implementation): Фізична, технічна або нефункціональна якість результату роботи (deliverable). Вона гарантує, що продукт створено правильно, мінімізуючи рівень просочування дефектів (defect-leakage rates) до клієнта та усуваючи потребу у переробках (rework) на пізніх етапах.
• Надання сервісу (Service Delivery): Досвід клієнта під час споживання послуги, де переважають такі транзакційні критерії, як час виконання (lead time), передбачуваність та своєчасність. Високоякісний дизайн, доставлений із запізненням або непередбачувано, все одно буде вважатися клієнтом невідповідним призначенню (unfit-for-purpose).

Див. Попит.

Одна з 6 загальних практик, описана як «Впровадьте цикли зворотного звʼязку» у Канбан-методі. Цикл зворотного звʼязку починається з інформації про існуючу систему, а потім вимагає дій, що базуються на відповідності результату бажаним цілям чи необхідності його змінити для покращання або узгодити з цими цілями. Зворотній звʼязок без дії лишається інформацією та не формує цикл.

Різниця в часі (наприклад, хвилини, години, дні тощо) між двома точками в робочому потоці. Див. Клієнтський час виконання та Час виконання системи.

Витрачений час, потрібний елементу роботи, щоб перейти від точки прийняття зобовʼязань до першої колонки на канбан-дошці, яка не має WIP ліміту.

Див. Пропускна здатність.