M365Con 2027 – безкоштовна онлайн-конференція · 11–22 Jan 2027 · 120 sessions→ m365con.net

Блог · Mirko Peters

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

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By ·

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

Automatically translated with AI from the original post. Read the English original

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

Головне

  • Найкраще програмне забезпечення для картування потоку створення цінності на вашому виробництві — це те, яке зберігає метод незмінним, використовує ваші власні дані і редагується людьми, які керують потоком.
  • Перевірте, чи інструмент моделює потік матеріалів і потік інформації, підтримує карти поточного та майбутнього стану і працює для кожної товарної родини окремо.
  • Стандартні дані процесу, як-от час циклу, час переналагодження, доступність обладнання та %C&A, мають бути полями в інструменті, а не вільним текстом.
  • Запитайте, звідки беруться дані, як часто вони оновлюються і хто їх перевіряє. Карта, побудована на застарілих даних, — це просто гарніший плакат.
  • Протестуйте кожного кандидата на одній реальній товарній родині з вашими власними даними, а відмову зробити це вважайте відповіддю.

Що робить програмне забезпечення для картування потоку створення цінності найкращим для вашого виробництва?

Подумайте про три перевірки, у такому порядку.

  1. Метод. Чи зберігає інструмент логіку картування потоку створення цінності, чи це загальна блок-схема з lean-шаблоном зверху?
  2. Дані. Чи містить карта реальні показники вашого виробництва і чи може оновлювати їх без повторного введення?
  3. Люди. Чи команда, яка відповідає за потік, справді відкриватиме його щотижня?

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

Чи зберігає програмне забезпечення метод незмінним?

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

Перекладаємо це на перевірки інструмента:

  • Два потоки. Чи можна намалювати інформаційний потік, наприклад графік або сигнал замовлення, який отримує кожен процес, а не лише блоки в ряд?
  • Поточний і майбутній стан. Чи можна зберігати обидві карти для однієї товарної родини, порівнювати їх і зберігати старіші версії?
  • Товарна родина як одиниця. Чи можна групувати продукти та карти за родинами, щоб на одному виробництві не накопичувалася купа непов'язаних схем?
  • Стандартні іконки. У статті LEI про основи відсутність стандартних іконок названо типовою помилкою, адже тоді іншим людям важко читати карту. Інструмент має пропонувати стандартний набір, а не спонукати кожного вигадувати власний.
  • Дані процесу як поля. Та сама стаття описує блоки даних процесу під кожним кроком: час циклу, простої, час роботи, час переналагодження, відсоток завершеності з першого разу (%C/A) і доступність, а також часову шкалу з часом виконання замовлення. Якщо ці дані є структурованими полями, програмне забезпечення може їх підсумовувати, порівнювати карти та передавати дані на інформаційну панель. Якщо ж це текст у фігурі, нічого з цього не вийде.
  • Розрахунки, які можна перевірити. Якщо інструмент показує час виконання замовлення або коефіцієнт, ви маєте бачити, як його розраховано. Число, яке неможливо простежити, не витримає першої скептичної розмови з керівником виробництва.

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

Звідки беруться дані?

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

Запитайте у постачальника перелік способів, якими числа можуть потрапити на карту:

  • Введення вручну командою після обходу цеху. Завжди можливо, і часто це правильний початок.
  • Імпорт з електронних таблиць або експортованих файлів, наприклад даних про замовлення, маршрути та запаси з вашої ERP-системи.
  • Підключення до ERP або систем цеху, щоб показники оновлювалися без участі людини.

Далі поставте складніші запитання:

  1. Які поля можна заповнювати автоматично, а які потребують участі людини?
  2. Як часто оновлюються дані і чи видно на карті дату останнього оновлення?
  3. Коли імпортовані числа не збігаються з тим, що команда бачить у цеху, як їх виправити і чи збережеться виправлення після наступного імпорту?
  4. Хто відповідає за якість даних на вашому заводі? Інструмент цього не скаже.

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

Хто користуватиметься інструментом і кому він потрібен для перегляду?

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

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

Якщо ваші KPI з карти потрапляють на інформаційну панель, Power BI є поширеним місцем призначення в середовищах Microsoft. Microsoft документує для нього безпеку на рівні рядків у Microsoft Learn: роль із фільтром визначає, які рядки бачить користувач, а обмеження діє для користувачів із роллю Viewer у робочій області. Це зручно для передачі показників цеху потрібній аудиторії, але такий підхід обмежує рядки, а не стовпці. Плануйте модель даних із цим на увазі.

Як це масштабується між сімействами продуктів і майданчиками?

Одна карта — просто. Двадцять карт на трьох заводах — це вже питання управління.

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

  1. Найменування та структура. Папки або бібліотеки за майданчиком, потоком і сімейством продуктів, щоб люди легко знаходили потрібну карту.
  2. Спільні шаблони. Єдиний корпоративний стандарт для іконок, полів даних і визначень KPI.
  3. Узгоджені KPI. Якщо час виконання розраховують по-різному на кожному майданчику, порівнювати майданчики немає сенсу.
  4. Відповідальність. Кожна карта має мати названого власника в інструменті, а власник має отримувати нагадування, коли дані застарівають.
  5. Локальні відмінності. Майданчикам потрібен простір для власних кроків, але без порушення спільного стандарту.

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

Що мають запитати ІТ-відділ і закупівлі?

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

  • Розміщення та безпека. Де зберігаються дані і яка документація з безпеки доступна?
  • Вхід у систему. Чи працює інструмент з вашим єдиним входом (single sign-on), щоб не вести окремий набір паролів?
  • Експорт. Чи можна вивантажити всі карти та дані у придатному для використання форматі? Якщо ні, ви опиняєтеся в залежності від постачальника.
  • Модель ціноутворення. За користувача, за карту, за майданчик чи за модуль? Розрахуйте вартість, виходячи з реальної кількості переглядачів, яку ви очікуєте.
  • Підтримка і навчання. Хто допоможе, якщо карта не імпортується, якою мовою і в якому часовому поясі?
  • Дорожня карта і відповідальність. Що станеться з продуктом, якщо постачальник змінить напрямок розвитку?

Як зважувати відповіді та не пропускати тривожні сигнали?

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

Тривожні сигнали, на які варто звернути увагу:

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

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

Типові помилки

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

Де тут Polaris

Якщо хочете включити до пілотного проєкту варіант, що спирається на дані, розгляньте iFAKT Polaris. iFAKT описує Polaris VSM як модуль Polaris для картографування потоків цінності на основі даних. Він моделює матеріальні та інформаційні потоки у спільному режимі, працює на 100% у браузері та робить видимими втрати і вузькі місця. За даними iFAKT, дані з таких систем, як SAP, можна експортувати в Excel і імпортувати в інструмент. Оцінюйте його за тими самими критеріями, що й будь-якого іншого кандидата, на одній зі своїх родин продуктів.

Пов'язані теми для вивчення

  • Від карти до щоденної рутини. Хто відповідає за потік після воркшопу і як проходить щотижневий огляд.
  • Картографування на основі даних з ERP. Які поля імпортувати, які вимірювати на виробничій ділянці і як позначати різницю між ними.
  • Малювання майбутнього стану. Як перетворити карту майбутнього стану на план робіт з іменами та датами.
  • KPI для потоку цінності. Які кілька показників описують потік і як відобразити їх на дашборді.
  • Папір проти програмного забезпечення. Коли достатньо маркерної дошки і коли інструмент виправдовує свою вартість.

Наступний крок

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

Підписатися на подкастSpotify

Entities in this article

Value stream mapping Enterprise resource planning (ERP) Power BI Polaris VSM iFAKT GmbH

Related articles

RSS

Спонсорський матеріал

iFAKT GmbH