Чи збираєтеся впровадити канбан у бізнес-процеси? Ось із чого варто почати. Система Канбан: що таке, з чого почати, як впровадити, основні засади

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

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

1. Що таке канбан-метод?

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

Канбан, як інструмент в IT-менеджменті, був представлений Девідом Дж. Андерсоном в компаніях Microsoft (2005) і Corbis. А широке поширення та назву, як метод, отримав у 2007 році.

2. Канбан-метод і Канбан Тойоти – це те саме?

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

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

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

3. Чи можна використовувати Канбан-метод не в ІТ?

Так. Канбан-метод підходить для візуалізації потоку будь-якої творчої та інтелектуальної роботи. Але набагато ефективніше використовувати його через призму сервісної парадигми. Подивіться на те, що ви робите як на сервіс. Через які стадії відбувається робота, щоб сервіс був наданий? За якими критеріями ви зрозумієте, що сервіс надається відповідно до очікувань Замовника? Це відправна точка застосування Канбан-метода. Канбан-практики називають цю точку “почніть із того, що є зараз”.

4. Канбан – це як Скрам?

Ні. Скрам – це фреймворк із жорсткими правилами та кордонами. Ви можете використовувати різні інструменти та методології всередині Скраму, але якщо ви відмовилися від чогось обов'язкового у Скрамі, він уже не може вважатися Скрамом. Канбан – це метод, інструмент із набором практик та принципів. Ви можете використовувати всі практики, частину практик або не використовувати їх взагалі. У Канбані немає суворого поняття, що є Канбан, а що не є Канбан. Однак, розумне використання практик може суттєво допомогти вам зробити сервіс максимально якісним та відповідним очікуванням клієнтів.

5. Канбан має цінності?

Так. Їх дев'ять: прозорість, баланс, співпраця, клієнтоорієнтованість, потік, лідерство, розуміння, злагода, повага.

6. Ви написали про принципи Канбана. Які вони?

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

  1. Почніть із того, що є зараз.
  2. Домовитеся про еволюційний розвиток.
  3. Заохочуйте розвиток лідерства на всіх рівнях.

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

  1. З'ясуйте потреби та очікування замовника.
  2. Керуйте роботою, дайте людям організуватись навколо неї.
  3. Розвивайте правила, щоб покращити показники.

7. А що за практики у Канбані?

Їх також шість:

  1. Візуалізуйте.
  2. Обмежуйте незавершену роботу.
  3. Керуйте потоком роботи.
  4. Використовуйте певні правила.
  5. Вводьте петлі зворотного зв'язку (каденції).
  6. Поліпшуйте та еволюціонуйте.

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

8. О, каденції! Що таке каденції у Канбані?

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

  1. Канбан-мітинг (щоденна). Тут обговорюємо статус заблокованих завдань.
  2. Зустріч за наповненням черги (зазвичай раз на два тижні). Беремо він зобов'язання, що робити, як сервіс.
  3. Зустріч щодо планування поставки (зазвичай раз на два тижні). Повертаємо виконані зобов'язання назад.
  4. Зустріч щодо огляду сервісу (зазвичай раз на два тижні). З метриками обговорюємо якість сервісу та як його покращити, якщо потрібно.
  5. Операційна зустріч (зазвичай раз на місяць). З метриками обговорюємо якість взаємодії пов'язаних сервісів.
  6. Зустріч щодо огляду ризиків (зазвичай раз на місяць). З метриками обговорюємо вплив заблокованих завдань на роботу сервісу.
  7. Зустріч щодо огляду стратегії (зазвичай раз на квартал). З метриками обговорюємо зміни у стратегії.

9. Я чув про класи обслуговування. Що це?

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

  1. Прискорений клас – невідкладна швидка реанімація. Їде виділеною смугою. Немає часу відкладати вирішення проблеми. Потрібно якнайшвидше.
  2. Клас із фіксованою датою – вартість затримки різко зростає після певного періоду. Приклад: проект як ФЗ з фіксованою датою початку дії. Не встигнемо вчасно, є ризик втратити ліцензію.
  3. Стандартний клас – вартість затримки зростає пропорційно до часу. Якщо робимо одразу, отримуємо прибуток одразу. Якщо робимо довго, отримуємо прибуток довго.
  4. Нематеріальний клас – робимо, але явного прибутку ця робота не несе, вартість затримки зростає повільно. Наприклад, прибирання у будинку. Можна і не забиратися регулярно, але через півроку доведеться робити генеральне прибирання.

10. Що щодо метрик? Як поміряти ефективність роботи сервісу?

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

11. З якими проблемами стикається Канбан під час впровадження?

Основні труднощі – це пояснити людям всіх рівнях цінність практик Канбана: візуалізації та обмеження незавершеної роботи. Через те, що люди не бачать обсягу інтелектуальної праці, їм складно зрозуміти, на яке навантаження вони зазнають. Адже мозок, наприклад, такий самий м'яз, як і біцепс. Уявіть тренажерний зал: ви приходите і бачите вагу на штанзі: “Так, це занадто мало. А зараз – надто багато. А ось це якраз!” З мозком потрібно працювати так само: “Ось це – велике завдання, а це – маленьке, та й взагалі якось багато я на себе взвалив. Обмежу-но я навантаження”. Коли на всіх рівнях ми робимо наскрізну візуалізацію потоку роботи та обмежуємо кількість незавершеної роботи, ми створюємо принцип, що витягує, для інтелектуальної праці і робимо рівномірний потік його результатів для наших клієнтів.

12. А які програми для Канбан-метода?

Їх також багато. Перелічимо лише професійні, розроблені спеціально під метод. Наше серце віддано російській розробці Kaiten. Крім неї є ще TargetProcess, SwiftKanban, LeanKit та інші.

13. І в яких компаніях використовується Канбан-метод?

Серед росіян це Альфа-Банк, Хоум Кредит Банк, Пошта-Банк, Додо Піца, HeadHunter, Clever та інші. З іноземних: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr. Dobb's, Siemens, Tupalo. Цей список можна продовжувати довго.

14. Чи є ще щось важливе?

Так. Насамкінець хотілося б відзначити важливість двох ролей у Канбан-методі. Це менеджер сервісу поставки (service delivery manager) та менеджер сервісу запитів (service request manager). Перший відповідає за усунення перешкод у потоці постачання. Другий – за керування потоком запитів до сервісу від багатьох замовників. Дуже важливо, щоб ці дві ролі були партнерами та працювали у парі.

15. Окей, я зрозумів. З чого розпочати використання Канбана у створенні?

Щоб розпочати впровадження Канбана в організаціях, ми використовуємо інструмент S.T.A.T.I.K. - Системний підхід до застосування Канбану. Докладніше про нього можна прочитати в Інтернеті. Але ми рекомендуємо відвідати тренінг, на якому цей інструмент викладається у форматі бізнес-ігри. На прикладі свого сервісу (організації) ви можете спроектувати Канбан-систему для подальшого застосування у бойових умовах.

Тренер та консультант з гнучких методологій, Скрамтрек.

Добридень!

Одним із моїх професійних інтересів, як координатора команди тестувальників, є методологія розробки програмного забезпечення. В даний час все більшої популярності набувають так звані Agile-методології, особливо Scrum і Kanban. На «розпіаренних» термінах грають недобросовісні «тренери», семінари та сертифікації («сертифікований Scrum-майстер», «сертифікований Product owner» тощо) ростуть як на дріжджах.

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

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

Історія терміна
Kanban - японський термін, який почали використовувати стосовно виробництва в 60-х роках 20-го століття в компанії Toyota. В основу цього принципу покладено конвеєрний метод виробництва, а також різні швидкості виконання окремих технологічних операцій на виробництві. Спробую пояснити на пальцях. За будь-якого виробництва є основне виробництво («головний конвеєр») та додаткове виробництво («додаткові конвеєри»). Темп випуску кінцевих виробів задає головний конвеєр, у той час як додаткові конвеєри не можуть прискорити темп випуску виробу, але можуть уповільнити його у разі несвоєчасного випуску необхідних деталей.

Додатково при виробництві може відбутися зміна пріоритетів. Наприклад, з'ясувалося, що станція, яка виробляла ліві дзеркала, виробила 20 шт., а станція, що виробляла праві дзеркала - 10 шт., у той час як на конвеєрі знаходяться 15 автомобілів і необхідно 15 штук дзеркал обох типів. В наявності конфлікт метрики - кількісно виробництво не впало (додаткові конвеєри випустили 30 виробів на строк), але виробництво все одно ризикує зупинитися. Kanban покликаний допомогти з цією проблемою.

У спрощеному варіанті, Kanban включає два простих правила:

  • виробнича станція має план виробництва деталей (backlog). План відсортований за пріоритетом, і може змінюватись у будь-який час (наприклад станція, що виробляє занадто багато лівих дзеркал, повинна мати можливість переключитися на праві якнайшвидше);
  • кількість завдань, що виконуються на станції одночасно обмежена (тобто виробляти не більше заданої кількості дзеркал одночасно). Це обмеження необхідне управління швидкістю виробництва на станції, і навіть швидкістю реагування зміни плану.
Теперішній час
Останнім часом, Kanban набирає великої популярності у виробництві програмного забезпечення. Деякі команди вважають цю методологію виключно корисною, деякі використовують за принципом культу Карго. На основі мого емпіричного досвіду чистий Kanban погано працює для продуктових команд (читай - «основний конвеєр»), але відмінно працює з командами підтримки, такими як:
  • групи підтримки програмного забезпечення, де не важливий план, але важлива швидкість реагування на зміни;
  • групи тестування, які працюють окремо від груп розробки;
  • служби підтримки;
  • інші приклади "неосновних виробництв".

Окремо слід зазначити, що Kanban добре працює в стартапах, які не мають чіткого плану, але активно працюють над розробкою. Пропоную розглянути приклад використання Kanban у розробці програмного забезпечення. Наперед прошу пробачити за негарні ілюстрації. Уявімо собі команду з одного розробника, що працює над невеликим проектом. План розробки (backlog) відсортований у порядку пріоритету шматків роботи, ліміт команди на завдання у процесі – 1 шт.

Для управління процесом керівник проекту може:

  1. змінити ліміт на кількість завдань у роботі;
  2. додати завдання з вищим пріоритетом (наприклад p0) у тому щоб було взято якнайшвидше;

У процесі роботи може так статися, що робота заблокована (зламався хостинг, не завантажено потрібну framework і т.д.). Загалом, заблокована робота повертається в backlog, і вибирається нове завдання, з максимальним пріоритетом. Залежно від характеру завдань та типу команди, ліміт може бути збільшений або зменшений. Наприклад, наш розробник може одночасно малювати форму реєстрації та ознайомитися з процесом розгортання нового сервера. Проте, якщо час завершення завдань буде меншим за необхідний, керівник проекту може зменшити ліміт, або збільшити команду. Таким чином, при грамотному керівництві Kanban забезпечує максимально можливу для цієї команди швидкість роботи, максимальну швидкість реагування на зміни і в той же час скоротити «витрати» на підтримку методології. Загалом, усе! Kanban – це не просто, просто. Це дуже просто!

До обмежень Kanban"а при використанні його в продуктових командах можна віднести:

  • дана методологія погано працює з більшими командами (більше 5 осіб);
  • у чистому вигляді Kanban погано працює з крос-функціональними командами. Тобто. на відміну від Scrum, важко поєднати тестування та розробку в одній команді. Найбільш вдалою думкою є розбити процес на «станцію» розробки та «станцію» тестування з окремими керівниками та backlog-ами;
  • через свою історію та специфіку, Kanban не призначений для довгострокового планування.
Висновок
Насамкінець, хочу додати, що порівняння будь-яких методологій за принципом «хто крутіший» не продуктивне і контр-конструктивне (капітан очевидність). Кожна, більш-менш поширена, методологія має свої плюси, мінуси та межі застосування. Додатково Agile-методології в принципі накладають великі вимоги на спрацьованість і досвід членів команди.

У разі виникнення інтересу до теми продовжу розгляд Kanban'a докладніше. Згодом пропоную розібрати по поличках і картинках Scrum і RUP.

Більш докладно, і наочно можна подивитися.

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

Сутність поняття та основні особливості методу

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

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

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

Подробиці процесу

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

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

  1. З n-го етапу на n-1 запитується ("витягується") необхідну кількість незавершеного виробництва.
  2. З n-1-го етапу на n-ий прямують ресурси матеріального характеру у необхідному обсязі.

Інструменти передачі інформації

Щоб краще зрозуміти, канбан - що це таке, слід усвідомити, що інструментом передачі відомостей у цій системі є спеціальні картки, які класифікуються на дві групи:

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

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

Ефективні методи використання канбанів - що це таке?

Тайіті Оно, президент корпорації Toyota Motor Corporation, розробив низку принципів, що дозволяють з максимальною ефективністю застосовувати картки канбан:

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

Особливості застосування карток

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

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

Переваги застосування методу канбан – що це таке?

Підприємствам, що застосовуються, здійснюється щоденне постачання матеріальних ресурсів (а часто і кілька разів протягом дня). Це дозволяє повною мірою оновлювати виробничі запаси приблизно 100-300 разів протягом року. Якщо порівняти канбан з такими системами, як MRP або MAP, то в цьому випадку відбувається оновлення приблизно в 10 разів частіше.

Доцільні для оцінки методу канбана приклади, що виявляють його абсолютну перевагу над іншими, менш продуктивними. Так, корпорація Toyota Motors на одну з багатьох ділянок виробництва в 1976 році постачала ресурси тричі на день, а в 1983 р. - вже кожних десять хвилин.

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

Основні елементи методу

Найважливішими компонентами системи канбан є такі:

  1. Інформаційний комплекс, який містить у своїй структурі не лише картки, а й графіки виробничого, транспортного чи постачальницького характеру, а також карти технологічної спрямованості.
  2. Комплекс, що має пряме відношення до контролю над потребами та у професійному плані.
  3. Комплекс, що дозволяє здійснити загальний (TQM) та вибірковий ("Дзидока") контроль якості продукту.
  4. Комплекс здійснює абсолютне вирівнювання виробництва.

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

Недоліки системи та результати її застосування

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

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

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

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

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

Походження

Як і концепція ощадливого виробництва (Lean) система канбан була розроблена менеджерами Toyota. Автора системи, японського інженера Тайіті Оно, надихнув принцип роботи американських супермаркетів, де покупець сам вибирав потрібні товари. Роль "супермаркету" в корпорації Toyota виконав склад.

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

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

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

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

Принципи канбану

Менеджери Toyota сформулювали 6 системоутворюючих правил:

  1. Виконавці з нижнього потоку вилучають стільки деталей зі складу, скільки зазначено в канбані.
  2. Представники верхнього потоку теж поставляють запчастини строго відповідно до карток
  3. Ніщо не виробляється чи не переміщається без канбану
  4. Канбан має бути завжди прикріплений до деталей
  5. Браковані запчастини не використовуються в системі
  6. Зменшення кількості карток канбан робить керування більш чутливим до змін. Але без необхідності міняти усталену кількість карток не варто.
Канбан — це система, що «витягує». У ній створюється баланс між постійним потоком, який усуває витрати на очікування, та мінімальною кількістю роботи в процесі (РВП), що знижує ризики надвиробництва. РВП регулюється за допомогою карток: їхня кількість зафіксована, а інструкції в них направляють виконавців нижнього потоку.

Правило обов'язково прикріпленої бирки працює як закон збереження енергії.

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


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

Застосування канбан у IT

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

Тільки картки, на яких вказано інформацію про терміни виконання, опис або номер процесу та ім'я виконавця, тепер прикріплюються не до тари з запчастинами, а до дошки з розкресленими колонками:

  • Белог - завдання, які треба виконати
  • Завдання, які зараз розробляються
  • Завдання, які виконані, але ще не передані тестувальникам
  • Завдання готові до передачі відділу тестування
  • Завдання, які проходять перевірку проект-менеджером (ПМ)
  • Виконані завдання

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


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

  • Ще може додаватися колонка з пріоритетною чергою.Коли виконавець звільняється, він повинен спустошити саме цю колонку із завданнями, та був братися інші.
  • Завдання, які були виконані, або повертаються в бэклог, або викреслюються зі схеми.
  • Канбан не заохочує багатозадачність, тому встановлюється ліміт процесів одного виконавця.
  • Виконана робота краще кількох розпочатим.
  • Братися за другу роботу можна, якщо першу було заблоковано.
  • Час виконання завдання має бути збалансовано.Занадто короткий термін позначиться на якості. Занадто розтягнутий ліміт розтрачує ресурси команди та підвищує вартість процесу.


Чому повсюдно використовується канбан-дошка, а не, наприклад, планшети чи величезний монітор? Як відповідають це питання шанувальники системи, звичайна дошка має дві переваги: ​​вона проста і забезпечує візуальний контроль. На ній легко вносити зміни, і вона забезпечує тактильну та соціальну взаємодію між учасниками команди.

Переваги та недоліки канбан

Kanban має такі переваги:

  1. Гнучкість планування. Команда зосереджується лише на поточній роботі, пріоритет завдання виставляється менеджером.
  2. Високе залучення команди до процесу розробки. Завдяки постійним зборам, прозорості процесів та можливостям самоорганізації працівники гуртуються та виявляють щирий інтерес.
  3. Найменша тривалість циклу. Якщо кілька людей має схожі навички, тривалість скорочується, якщо тільки один — з'являється вузьке місце. Тому співробітники повинні ділитися знаннями і цим оптимізувати тривалість циклу. Тоді вся команда зможе взятися за роботу, яку забуксувала, та відновити плавний потік.
  4. Менше вузьких місць. Ліміти РВП дозволяють швидко знаходити вузькі та проблемні місця, які з'явилися через дефіцит уваги, людей чи навичок.
  5. Наочність. Коли всі виконавці мають доступ до даних, вузькі місця легше помітити. Kanban-команди, крім самих карток, зазвичай використовують два загальні звіти: графіки управління та сукупного потоку.

Насправді система добре себе демонструє у сферах неосновного виробництва:

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

Канбан має й недоліки:

  1. система погано працює з командами чисельністю понад 5 осіб
  2. він призначений для довгострокового планування.

Відмінності від Скраму

Скрам, як і agile kanban, є гнучкою методикою і також часто застосовується в IT-сфері. Відмінності з-поміж них не очевидні здавалося б. Існує багато схожостей, наприклад, наявність беклог в обох підходах.

Скрам

Канбан

Темп

Повторювані спринти фіксованої тривалості

Безперервний процес

Випуск релізу

Наприкінці кожного спринту після схвалення проектним менеджером (власником продукту)

Потік триває без перерв або на розсуд команди

Ролі

Власник продукту, Scrum-майстер, команда розробників

Команда під керівництвом ПМ, в деяких випадках залучаються тренери з agile kanban

Головні показники

Швидкість команди

Провідний час

Прийнятність змін

У ході спринту зміни небажані, оскільки можуть призвести до неправильної оцінки завдань

Зміна може статися будь-якої миті

Приклади застосування в ІТ

Поряд з Microsoft: Дебют Канбан у сфері програмних розробок

Використання принципів канбану у сфері інформаційних технологій розпочалося трохи більше 10 років тому. Девід Андерсон, один із головних популяризаторів канбану для програмних розробників, консультував у 2005 році компанію Microsoft. Там були незадоволені роботою свого відділу – XIT Sustained Engineering, який усував помилки у внутрішніх додатках. На початок звітного року цей відділ був найгіршим у своєму департаменті. Беклог перевищив допустимий розмір у 5 разів, а час на обробку одного запиту провідний час- Зазвичай займало 5 місяців.

Новий ПМ за допомогою консультацій Андерсона за 9 місяців підвищив продуктивність проблемного відділу на 155%. Провідний частепер становило 5 тижнів, белог повернувся до нормального розміру, а своєчасне виконання завдань утвердилося на рівні 90%. Усі ці результати були досягнуті з мінімальним залученням нових працівників, персонал продовжував тими самими методами виправляти програмні помилки. змінилися лише підходи до роботи.

Цікавий факт: програмний менеджер Драгос Думітріу, який взявся переламати ситуацію в XIT, був захоплений книгою Андерсона. На свій подив, він зустрів ідеолога програмного канбану в самій компанії Microsoft, куди той напередодні влаштувався. Думітріу попросив Андерсона допомогти зі своїм завданням і останній погодився застосувати принципи своєї книги на практиці.

Думітріу застав відділ, що складався з трьох розробників і трьох тестувальників, у яких у белогу накопичилося 80 запитів. Сам ПМ був призначений тимчасово, оскільки вимоги до вакансії включали вміння роботи з технологією ASP, адміністрування за допомогою SQL Server та знання MS Project Server. Начальство бачило на цій посаді «технаря», який вміє програмувати, має складати звіти та прогнозувати завантаження беклогу. Як вважалося тоді, проблему відділу буде виявлено, якщо зібрати значний масив даних. Думітріу ж таким "технарем" не був.

Проте, почавши разом з Андерсоном аналізувати роботу XIT, він швидко виявив ключові фактори, які негативно впливали на швидкість відділу:

  • На прогнозування наслідків (ROM), до яких приведе виконання запиту, витрачалося дуже багато часу. І розробнику, і тестувальнику доводилося витрачати повний робочий день, щоб провести необхідні обчислення, перевірку коду та заповнити документацію. У середньому щодня надходив один запит. За підрахунками ПМ, на ROM йшло 40% від продуктивності відділу;
  • Пріоритет віддавався запитам із більшою вартістю. XIT отримував фінансування рахунок вартості замовлення. Пріоритетність запитів обговорювалася щомісяця на зустрічі менеджерів відділу із замовниками — менеджерами інших відділів. При розпираючий беклог при поточній швидкості, коли за місяць оброблялися лише 6-7 запитів, постійно змінювалися пріоритети інших заявок через час, що минає. Багато хто з них був відкладений на значне «потім», що не дорівнює навіть наступного місяця.
  • На стадії ROM відсівалася половина запитів. Частина з них була надто велика і перекваліфікувалася на проекти з передачею іншим відділам, інші були надто дорогими і просто скасовувалися. Деякі запити не бралися в розробку через те, що їхнє впровадження виявилося б надто довгим. Таким чином, 40% продуктивності відділу йшло на аналіз запитів, 50% з яких були забраковані. Близько 15-20% робочих ресурсів витрачалося даремно.
  • Підготовча робота на запит могла тривати місяцями, як починалося впровадження. Обчислення на стадії ROM могли за цей час загубитися або забути. Особливо якщо впровадженням займався не той розробник, який починав аналіз.

Рішення Канбан для проблемного відділу Microsoft

  1. Думітріу та Андерсон наполягли у розмові з керівництвом та менеджерами-замовниками на відмові від стадії ROM. Розрахунки проводилися безпосередньо перед використанням і тим самим виконавцем, тобто залишалися «свіжими».
  2. Пріоритизація запитів проводилася не під час щомісячних нарад, а щодо ситуації, за допомогою телефонних дзвінків або електронних листів. 80 завдань у белог розсортували залежно від замовників. Останніх попросили виділити основні запити, які необхідно виконати насамперед.
  3. Фінансування XIT стало фіксованим.
  4. Вартість запитів перестала братися до уваги.
  5. ПМ запровадив буфери на канбан-дошці. Розробники брали роботу із двох зон: схвалені та виконані завдання. У буфері було 6 запитів, 5 бралися в роботу. Тестувальники вибирали з буфера «очікує тестування». Деякі завдання, які не вимагали змін у коді, потрапляли туди, оминаючи розробників. Розбивши запити на однозадачні процеси, ПМ міг краще контролювати ситуацію, а також забезпечити прозорість для замовників. Введення буферів зменшило провідний час. Замовники в умовах передбачуваної системи стали краще визначати, чий запит повинен потрапити до наступного буфера.
  6. За надто великими чи дорогими запитами рішення приймалося одразу. Якщо розробник підтверджував, що він готовий виконати завдання протягом 15 днів або зміни варті того, запит брався в роботу незалежно від розміру або вартості.
  7. Поспостерігавши за потоком у відділі, ПМ дійшов висновку, що структуру штату варто змінити на користь розробників, які були завантажені роботою. Зміни проводилися у співвідношенні 2:1: у XIT стали працювати 4 розробники та 2 тестувальники.



За підсумками 2005 року продуктивність відділу зросла на 155%. Щоб ще покращити роботу XIT, туди залучили двох співробітників: одного розробника та одного тестувальника. Кількість запитів у белогу знизилася до 10, а один розробник став стабільно обробляти 11 заявок за квартал. У середньому за квартал завершувалося 56 запитів проти 11 раніше. Вартість запитів впала з $7500 до $2900.

Застосування в компанії Corbis

Досягши успіху в Microsoft, Андерсон в 2006 році приступив до вирішення нового складного завдання. Тепер він працював у Corbis - іншій компанії Білла Гейтса, який тоді ще не покинув MS. Одним із видів діяльності Corbis було ліцензування фотографій. На той момент це був другий найбільший у світі фотосток із базою близько 3,5 тис. знімків.

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

В офісі Corbis з'явилася канбан-дошка, біля якої Андерсон щодня розмовляв із колективом. Метою ПМ було покращити візуальний контроль над процесами, сприяти самоорганізації та більшій персональній відповідальності виконавців. Також система канбан була спрямована на зменшення нагляду з боку менеджерів та збільшення продуктивності.


Окрім різнокольорових карток та графіків, на дошці з'явився «сміттєвий кошик» — до нього вирушали завдання надто великого розміру.


Фото з офіційної
A Kanban System for Sustaining Engineering on Software Systems, David J Anderson

Система kanban прояснила, коли потік перестає бути плавними і де виникають затримки, так звана пляшка. Швидкі обговорення із командою допомагали виявити поточні проблеми. Наприклад, тестування тривало 3 дні, що негативно відбивалося на терміні релізу. Троє співробітників об'єдналися та знайшли спосіб, як зменшити час до однієї доби.

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

Ліміти для канбан-карток двічі встановлювалися емпіричним шляхом. У колонці «готово розробки» ліміти було збільшено. Також з'явилася нова колонка – «готово для тестування». Багато запитів нижнього потоку були некоректно сформульовані, викликаючи зайві витрати часу. Тому ПМ досліджував роботу верхнього потоку та знайшов помилки.

Обробка запитів могла займати 100 днів, але релізи все одно почали виходити раз на два тижні, як і планувалося. Рішення щодо вмісту випуску приймалося за 5 днів до публікації. Практика підрахунків, як і у випадку з відділом XIT Microsoft, була відкинута на користь продуктивності. Пріоритет завданням розставлявся відповідно до «вартості затримок» чи готовності ресурсів.

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

Що таке методологія kanban і як вона дозволяє виконувати завдання у поставлені терміни?

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

Хвилина історії kanban

Основу ідеї kaban було придумано компанією Toyoyta Motors. Виробник автомобілів зазнав великих втрат через неправильний розподіл запасів і потужностей на виробничій лінії. Частина етапів виробництва могла простоювати, а частина була перевантажена.

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

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

Давайте сформулюємо що таке kanban і перенесемо його на розробку інтернет продуктів.

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

Вище зображено kanban дошку. Це основний інструмент відображення статусу задач. Головний принцип: ми бачимо на якому етапі виробничого процесу є те чи інше завдання. Плюс, відстежується час на всіх ділянках, тобто завжди можна виявити “ ” у системі та попрацювати з ними.

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

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

Вибачте, що перериваю читання. Приєднуйтесь до мого телеграм каналу . Свіжі новини статей, розвиток digital продуктів та growth hack, там все. Чекаю вас! Продовжуємо…

Принципи kanban

  • Візуальне відображення завдань. Усі завдання мають бути представлені у вигляді карток та відображені на дошці. Дуже важливо оновлювати статус завдань. Наприклад, якщо розробники підготували код і передали у тестування, то картка із завданням має перейти у відповідний стовпець. Таким чином, будь-який учасник команди у будь-який момент часу може подивитися на якому етапі є завдання.
  • Обмеження по шпальтах WIP (work in progress або роботу, виконувану одночасно) кожному етапі виробництва. Щоб система рано чи пізно не "захлинулась" від потоку завдань, необхідно встановлювати обмеження. Наприклад, на kanban дошці вище в стовпці Analisis (аналітика) у нас працюють 2 людини і вони можуть обробляти не більше 2 завдань, немає сенсу навантажувати їх більше, оскільки наступні етапи системи простоюватимуть. Обмеження по шпальтах підбираються досвідченим шляхом.
  • Фокус на невиконаних завданнях. Дивлячись на дошку із завданнями насамперед приділяйте увагу тим завданням, які “підвисають” у тому чи іншому стовпці. Якщо у вас якийсь із етапів займає найбільше часу, то спробуйте перерозподілити ресурси або додати людей, якщо є така можливість.
  • Постійне вдосконалення. Як тільки ви врівноважите навантаження у системі, вам буде простіше спостерігати за всім процесом загалом. Вимірюйте час циклу (скільки завдання висить в окремому стовпці, а скільки від моменту потрапляння в To do до релізу Done). Змінюйте навантаження в системі та скорочуйте час на проходження всіх стадій.
  • Приділяйте увагу дрібниці. Наприклад, якщо код, який пишуть розробники періодично не проходить тестування і повертається на доопрацювання, то, можливо, є варіанти покращити якість розробки, щоб у тест потрапляв якісніший продукт?

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

Інструменти kanban

Або де вести kanban дошку.

  • Excel таблиці
  • Дошка зі стікерами
  • Ще фантазія…

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

Приклади kanban дощок

Ось дошка, що висить на стіні, де кожне завдання відображено на стікерах.

Або це може бути хмарний сервіс, типу Trello.

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

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

Нюанси/мили

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

  • Швидше за все, введення лімітів WIP на стовпець може трохи налякати управлінський склад проекту. Адже як визначити скільки розробник чи, наприклад, тестувальник можуть паралельно вирішувати задач? А раптом ми введемо обмеження і вони просто прохолоджуватимуться?

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

  • Як стверджують гуру kanaban, система ідеально працює у крос-функціональних командах. Ну щось на зразок того, якщо тобі нема чого робити, йди допоможи товаришеві по цеху. Щоправда, щоб сколотити собі команду, де розробники можуть бути тестувальниками і навпаки, а архітектор системи допоможе дизайнеру, потрібно буде викласти чималі гроші та й чи варто?

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

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

Разом

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