Sap

На подготовку данной заметки меня натолкнула картина, которую я наблюдал совсем недавно в скоростном, двухэтажном поезде АО «ФПК» по направлению Новороссийск-Москва. Состав из 15 новых вагонов, произведенных на Тверском вагоностроительном заводе (ТВЗ, входит в состав АО «Трансмашхолдинг»). Серийно их делают с 2011 года, на рельсы они встали в 2013.

Итак, три уборных (WC) на вагон. В каждой уборной алюминиевый порог (в дверном проеме) имел незаводской рез по краям, как и часть наличника, которую также подпиливали болгаркой, чтобы порог установить в проем. Вероятно, на каком-то этапе производства допустили ошибку, которая теперь имеет системный и массовый характер. Дверной порог - сущая мелочь, а что если такую погрешность имеются детали вагона? Или вашего автомобиля? Или трактора/комбайна? И эта «мелочь» на протяжении многих лет остается без исправлений.

Некоторое время назад мы разрабатывали SRM-систему, одним из модулей в которой была работа с рекламациями по методологии 8D. Этой первая (базовая) версия программного обеспечения на данном предприятии, и большой шаг в сторону повышения качества конечного продукта.
Как обычно — работа под NDA, поэтому никаких скриншотов, прототипов, результатов :(

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

Чтож, попробую подробнее описать что это такое, потому как нам — разработчикам, все это казалось непонятным и далеким от каких-то методологий бережливого производства.

---

Обеспечение качества продукции — актуальна тема для любого предприятия и производства. Существуют системы менеджмента качества, одной из основных целей которых является обеспечение выпуска качественной продукции. Достигается это системными процессами и процедурами, которые должны функционировать на постоянной основе. Для повышения результативности этих процессов (и как следствие - качества продукции), должен применяться принцип постоянного улучшения — PDCA

(Планируй->Выполняй->Анализируй->Изменяй)

Для решения задачи в области сбора и анализа информации (сбор и анализ несоответствий и администрирования необходимых корректирующих действий) используют метод 8D (метод 8 дисциплин).

Это простой метод, и его рекомендуется использовать, когда на предприятии возникает брак.
Методология не имеет какой-то отраслевой специфики и рассчитана на различные производства. Отраслевые стандарты по качеству предписывают взаимодействие всех подразделений компании или предприятия в процессе обеспечения соответствия продукции нормам качества, поэтому компании стали задумываться о разработке и внедрении программного обеспечения в виде самостоятельных система контроля, либо модулей, которые интегрируются в существующие SRM (система управления взаимоотношениями с поставщиками). Такие решения рассчитана на командную работу и имеют необходимый для этого функционал.

Как мне видится проблематика?

Крупные Российские производители сходу на титульных страницах своих тендерных площадках (электронные закупки) публикуют регламент работы с поставщиками и нередко он также содержит бланки и инструкции 8D по решению проблем для поставщиков.

В дальнейшем подобные «отчеты» становятся в некотором роде отпиской. Команды не собираются, партии гарантированного качества отправляются наугад, а сама методика особо никому не нравится, так как является очень громоздкой. Да и мало кто разбирается в правдивости предоставленных данных. Проблемы вроде устраняются и без этих отчетов, и всех это устраивает.

Таким образом данные о контроле никак не передаются в систему анализа проблем. Этой системы попросту нет. И лежат эти промасленные протоколы, журналы у станков...

Но регламент работы с поставщиками соблюдается, а внутри конечного производства системой 8Д пользуются примерно также, как и с внешними подрядчиками — для отчетности.

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

---

8D (метод восьми дисциплин) - был разработан в компании «Ford» в 1987 году для решения локальных проблем (несоответствий) в процессах методологическим и аналитическим путем. Проблемы могут быть связаны с качеством, безопасностью, производительностью, гибкостью, управляемостью, эргономикой или стоимостью процесса. В рамках применения метода 8D проводится доскональное изучение процесса, в котором возникло несоответствие, и предотвращение возникновения подобного явления в будущем. Метод применяется для решения локальных проблем на устранение которых требуется не более 2 недель (без учета времени разработки и внедрения предупреждающих мер).

Основные преимущества данного метода работы с проблемами:

- Дает приобретение партнерских навыков;

- Способствует решению и предупреждению проблем;

- Улучшает качество и производительность;

- Предотвращает будущие проблемы;

- Улучшает удовлетворенность заказчика.

Основной недостаток - обучение данной методике обычно трудоемко, т. к. требует обучения использования других инструментов качества и требует жестких сроков выполнения этапов.

Этапы проведения методики 8D

Каждый шаг методики имеет в своем наименовании букву D, что означает discipline (дисциплина). Методика 8D включает следующие шаги:

D0– подготовка к проведению анализа8D

D1– создание команды

D2– подробное описание проблемы

D3– разработка действия промежуточного сдерживания (временные мероприятия)

D4– определение и проверка корневой (основной) причины и точки ускользания (EP)

D5– выбор и проверка постоянных корректирующих действий

D6– проведение и подтверждение (валидация) постоянных корректирующих действий

D7– выбор предупреждающих действий

D8– признание командных и индивидуальных вкладов, закрытие 8D

Данная методика проводит различие между симптомом и проблемой.

Симптом — событие/следствие, испытываемое потребителем. Например: внешнее проявление дефекта/несоответствия изделия, которое может быть описано и которое указывает на возможность существования одной или нескольких проблем.

- эффект или случай у клиента, указывающий на наличие проблем с качеством;

- воспринимается органами чувств человека;

- принимает вид жалобы или претензий;

- не содержит описание причины.

Пример — подшипник гудит

Проблема — отклонение от требований/ожиданий, любой нежелательный эффект от неизвестной причины.

- это несоответствующая деталь/продукт (причина несоответствия)

Итак, поехали подробнее.

Шаг D0 - подготовка к проведению анализа 8D

Оценка потребности в применении методики 8D. Если необходимо, то предпринимаются незамедлительные ответные действия для защиты потребителя:

-100% инспекция продукции;

-партия готовой продукции ставится на «карантин»;

-извещение заказчика о возможных дефектных изделиях;

-верификация производственного процесса.

Применение 8D необходимо при:

-возникновении проблемы для нового вида продукции;

-проблеме, связанной с внешним заказчиком;

-требовании заказчика выполнения 8D.

Целевые вопросы по D0:

- Как проявился дефект, зафиксированы ли его параметры?

- Было ли определено последствие?

- Было ли количественно определено последствие?

Шаг D1 - создание команды

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

Именно команда начинает процесс и определяет ход действий:

1. Определение владельца бизнес-процесса, который:

- предоставляет команде необходимые ресурсы для решения проблемы;

- назначает руководителя команды;

- принимает решение о реализации разрабатываемых командой мероприятий;

- контролирует реализацию всех мероприятий, принимаемых в рамках решения проблемы;

- принимает решение о завершении работы команды и закрытии 8D.

2. Основные задачи руководителя команды:

- организация и координация работы команды, проведение совещаний, необходимых для совместной выработки решений;

- управление процессом поиска решений;

- организация сбора и анализа информации о выявленной проблеме;

- согласование мероприятий, разрабатываемых при решении проблемы, с руководителями подразделений, ответственными за их выполнение;

- организация отслеживания результативности мероприятий;

- оформление карты решения проблемы, сбор и хранение необходимых приложений;

- подготовка промежуточных и итоговых отчетов по решению проблемы и презентация руководству.

3. Основные задачи участников команды:

- участие в совещаниях;

- выработка совместных решений;

- сбор информации;

- реализация мероприятий по принятым решениям, оформленных протоколом;

- проверка эффективности действий до и после реализации (верификация и валидация мероприятий).

Целевые вопросы по D1:

- Назначен ли руководитель команды?

- Кто имеет непосредственное отношение к появлению данного дефекта?

- Какими навыками должна обладать команда?

- Определен ли состав команды?

- Обладает ли команда достаточными полномочиями для принятия решений?

- Как будет происходить обмен информацией внутри команды и с другими подразделениями?

Шаг D2 - подробное описание проблемы

Ход действий:

- проверка имеющихся данных о проблеме и декомпиляция комплексных проблем до уровня одного объекта и одного несоответствия;

- оформление графического отображения проблемы в виде эскиза или фото;

- точное и однозначное формулирование проблемы.

Цели шага D2:

- получить четкое представление о проблеме, собрать, организовать, отфильтровать и суммировать информацию по проблеме;

- документировать и визуализировать проблему;

- описать проблему, используя ясные и конкретные формулировки;

- обеспечить доступ к информации всех заинтересованных лиц;

- дать направление деятельности по решению проблемы;

- заложить основу для последующего решения и анализа проблемы.

Источники информация для шага D2

- конструкторская документация;

- технологический процесс;

- DFMEA (процедуру анализа первоначально предложенной конструкции технического объекта и доработки этой конструкции), PFMEA (анализ рисков, связанных с производственным процессом);

- акты освоения ДСЕ (детали и сборочные единицы);

- отчеты о несоответствиях (рекламациях), отчеты по командировкам;

- опросы потребителей (внутренних или внешних);

- опросы исполнителей;

- предыдущие отчеты 8D.

Целевые вопросы по шагу D2:

- Зафиксирована ли проблема?

- Как часто появляется проблема?

- Возникала ли данная проблема ранее?

- С каким подобным объектом может быть такая же проблема?

- Зафиксированы ли начальные/конечные сроки возникновения проблемы?

- Где обнаружена и еще может появиться на объекте проблема?

- Обозначен ли процент брака?

- При каких условиях возникает и могла бы возникнуть еще проблема?

- Как была обнаружена и как можно было бы обнаружить проблему?

Шаг D3 - разработка действия промежуточного сдерживания (временные мероприятия)

Цели шага D3:

- Защита внешнего или внутреннего потребителя от воздействия проблемы, до принятия корректирующих действий;

- Ограничение ущерба в отношении издержек, качества, планирования поставок продукции;

- Выигрыш времени для поиска и устранения коренной причины несоответствия;

- Результативность временных сдерживающих мероприятий должна быть 100%.

Целевые вопросы D3:

- Какие срочные действия предложены?

- Произведена ли срочная проверка заделов на складе, в производстве, в пути к Покупателю или у Покупателя?

- Организован ли пост качества для сдерживания проблемы?

- Зафиксированы ли методы контроля для сдерживания проблемы? Позволят ли они устранить проблему?

- Разработаны ли мероприятия для оценки результативности сдерживающих действий? Имеются ли подтверждающие документы?

Важно! Срок выполнения этапов D1-D3 не позднее 48 часов от момента получения сообщения о симптоме D0

Шаг D4 - определение и проверка корневой (основной) причины и точки ускользания (EP)

Цели:

- Выявление и исследование коренных причин для их последующего исключения;

- Исследование коренных причин проблемы и наиболее раннего места в процессе, где можно обнаружить проблему;

- Определить, каким образом должна произойти замена сдерживающих мероприятий постоянным корректирующим действием.

Наиболее эффективным считается групповой метод анализа причин (мозговой штурм). При использовании метода необходимо обеспечить атмосфере для свободного высказывания членами группы мнения по поводу причин возникновения проблемы. Само обсуждение свести к минимуму, акцентируясь на идеях и фактах. Важно, что бы руководители не высказывались первыми и не давали оценки идеям и предложениям. Вести запись обсуждений.

Анализ причин на шаге D4.

Используется причинно-следственная диаграмма Исикавы (рыбий скелет, основные кости рыбы отображают факторы, обуславливающие возникновение проблемы. Каждый из возможных воздействующих факторов должен быть проверен и подтвержден соответствующей записью (акт допуска, протокол измерений, расчет прочности). Коренная причина (первопричина) — проверенная причина, которая вызывает проблему.

Для определения коренной причины может быть использован инструмент «лестница почему» (5 почему?), когда вопрос задается до тех пор, пока у команды не будет возможности дать адекватный ответ. Т.о. выявляются коренные причины.

Пример выявления коренной причина остановки станка (от Тайити Оно)

Вопрос 1: Почему остановился станок?

Ответ 1: Потому что из-за перегрузки перегорел предохранитель.

Вопрос 2: Почему возникла перегрузка?

Ответ 2: Потому что смазка подшипника была недостаточной.

Вопрос 3: Почему смазка была недостаточной?

Ответ 3: Из-за неисправности смазочного насоса.

Вопрос 4: Почему неисправен насос?

Ответ 4: Потому что износилась его ось.

Вопрос 5: Почему износилась ось насоса?

Ответ 5: Потому что в смазке встречаются загрязняющие примеси.

Итого на шаге D4 мы должны определить целевые вопросы:

- Определены ли все коренные причины возникновения и не обнаружения (пропуска) дефекта?

- Какова доля (в %) каждой из определенных причин в проблеме?

Шаг D5 - выбор и проверка постоянных корректирующих действий

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

Все предложения команды должны быть проанализированны и оценены по следующим критериям:

- ожидаемый эффект;

- ожидаемые затраты;

- ожидаемое время реализации;

- риск появления новых проблем.

Poka-yoke (пока-йоке) — Защита от дурака — специальный метод, благодаря которому дефекты не появляются. Этот метод нужен при малой частоте возникновения ошибки (забывчивости), существует возможность немедленной реакции человека, а сама система проста. Выделяют три уровня пока-йоке:

- сигнал;

- автоматический контроль;

- запрет.

Целевые вопросы D5:

- Разработаны ли корректирующие действия, направленные на устранение коренной причины проблемы?

- Внедрены ли данные корректирующие действия? Имеются ли подтверждающие документы об их внедрении?

- Определены ли необходимые ресурсы для внедрения и реализации корректирующих действий?

- Оценена ли результативность корректирующих действий?

Шаг D6 - проведение и подтверждение (валидация) постоянных корректирующих действий

- Выработка решений системного характера (изменения процессов, процедур, стандартов), направленные на исключение возможности повторного появления проблемы;

- Разработка предупреждающих действий, направленных на устранение потенциальной причины несоответствия;

- Планирование, введение, управление, контроль выполнения выбранных действий.

При планировании предупреждающих действий необходимо определить:

- что в будущем следует делать иначе?

- какие методы и требования необходимо регламентировать во внутренних нормативных документах?

- согласен ли владелец бизнес-процесса с предлагаемым предупреждающим действием?

- провести анализ возможного изменения FMEA, технологического процесса, плана управления, рабочих инструкций оператора, средств измерения и контроля и т. д.

Целевые вопросы D6

- Разработаны и внедрены ли предупреждающие действия?

- Распространены ли предупреждающие действия на процесс/продукт?

- Определены ли необходимые ресурсы для внедрения и реализации предупреждающих действий?

- Были ли обновлены системы, документы, методики и др.?

Шаг D7 - выбор предупреждающих действий

Основная цель данного шага — оценка результативности предпринятых действий. Необходимо выбрать подходящий метод и оценить результативность ранее предпринятых действий.

Целевые вопросы D7:

- Оценена ли результативность разработанных действий? Выбран ли подходящий метод оценки?

- Приведены ли соответствующие доказательства?

- Был ли полностью устранен дефект?

Шаг D8 - признание командных и индивидуальных вкладов, закрытие 8D

Цели:

- однозначно обозначить момент окончания работы по решению проблемы;

- гарантировать, что к моменту прекращения работы команды не осталось незавершенной работы, открытых вопросов и нереализованных мероприятий;

- подвести итоги проделанной работы;

- подтвердить значимость выполненной работы для компании;

- оценить вклад участников команды в решение проблемы;

- оценить эффективность ранее предпринятых действий;

- закрыть отчет 8D

Результативность решения проблемы определяется на основании отслеживания ее повторения на 100 единицах продукции (модель, на которой появилась проблема) с момента завершения реализации запланированных мероприятий. Оценка эффективности осуществляется после подтверждения положительной результативности.

Целевые вопросы D8:

- Оценена ли эффективность разработанных действий? Приведены ли соответствующие доказательства?

- Был ли полностью устранен дефект? Отсутствует ли повторяемость проблемы?

Выводы, которые можно сделать.

1) Внедрение цифровых продуктов в производство позволяет в значительной мере менять привычные (и нередко устаревшие) бизнес-процессы управления производством. Метод 8D получил широко распространение однако и многие компании адаптируют и расширяют его на российском рынке.

2) Применение данного метода будет безуспешно, если этого требует клиент, а для предприятия это остается простой формальностью. Первый вопрос, который должен задаваться при проведении метода 8D, это «Кто виноват?», а не «Что делать?».

По данной методике работает АвтоВаз, Рено, Камаз, Ростсельмаш, РусГидро, ТехноНиколь, Уралхим.

Материал получился большим и надеюсь полезным.

Предлагаю обсудить, как обстоит ситуация на вашем производстве и возможно накидать идей для оптимизации. А может у вас уже внедрена методика 8D в вашу ERP/SRM систему, тогда поделитесь опытом.

Вторая часть будет посвящена примерам, как можно внедрить программное обеспечение на конкретных участках производства.

Начал вести свой телеграмм-канал, подписывайтесь. Возможно будет интересно :)

PS. Для подготовки этой публикации использовались данные из различных статей и презентаций коммерческих организаций, которые находятся в открытом доступе. Не уверен, что могу их указать, т. к. Роскомнадзор может счесть это за рекламу, требующую маркировку.

Германская компания SAP, специализирующаяся на программном обеспечении, достигла соглашения о приобретении израильскую фирму WalkMe. Объем сделки составляет 1,5 миллиарда долларов

SAP согласилась купить WalkMe, инструмент, предлагающий работникам персонализированные инструкции по использованию программного обеспечения, за 1,5 миллиарда долларов наличными.

Эта цена на 45% выше, чем стоимость компании на американской бирже высоких технологий NASDAQ. Однако следует отметить, что на пике котировок в 2021 году WalkMe оценивалась в 2,6 миллиарда долларов.

WalkMe, штаб-квартира которой находится в Тель-Авиве, Израиль, продает платформу цифрового внедрения (DAP), которую предприятия могут использовать для предоставления работникам соответствующих функций руководства и автоматизации, обеспечивая более последовательное и эффективное внедрение нового программного обеспечения. По мнению руководителей SAP, с его помощью рабочие процессы могут выполняться более плавно в любом количестве приложений, что приводит к более широкому принятию базовых приложений пользователями и, таким образом, увеличивает добавленную стоимость, которую компании могут получить от внедрения нового программного обеспечения.

SAP рассматривает WalkMe как дополнение к своим предложениям в области управления трансформацией бизнеса, включая предыдущие приобретения Signavio и LeanIX . Цель SAP — предоставить своим клиентам большую поддержку в их цифровой трансформации.

«Приложения, процессы, данные и люди — это четыре ключевых элемента успешной трансформации бизнеса», — сказал Кристиан Кляйн, генеральный директор и член исполнительного совета SAP SE. «Приобретая WalkMe, мы удваиваем поддержку, которую мы предоставляем нашим конечным пользователям, помогая им быстро внедрять новые решения и функции, чтобы получить максимальную отдачу от своих инвестиций в ИТ».

Дэн Адика, генеральный директор WalkMe, назвал приобретение SAP важной вехой. Имеющиеся таким образом ресурсы позволили улучшить собственный ассортимент продукции и расширить присутствие на рынке. «Используя обширную экосистему SAP, мы готовы открыть существенные возможности для роста и принести еще большую пользу нашим клиентам», — говорится в заявлении Адика.

Платформа цифрового внедрения WalkMe работает поверх приложений других производителей, отслеживая их использование и предоставляя рекомендации. Платформа распознает возникновение проблем и предлагает необходимую поддержку и автоматизацию, позволяющую выполнять задачи независимо от задействованных приложений. Компания заявляет, что у нее более 2000 клиентов, включая IBM, Nestlé, ThermoFisher Scientific и Министерство обороны США.

Руководство SAP заверило, что даже после приобретения WalkMe продолжит полностью поддерживать приложения, не относящиеся к SAP.

WalkMe недавно анонсировала второй пилотный вариант своего DAP на базе искусственного интеллекта. При этом используется контекст и искусственный интеллект платформы, чтобы предложить пользователям лучший следующий шаг в рабочих процессах. Второй пилот WalkMe может работать на постоянной основе и накладывать на него приложения, включая любые дополнительные пилоты от разных поставщиков, которые компании используют в своих программных средах. SAP надеется, что функции WalkMe в новом программном обеспечении также позволят улучшить работу второго пилота SAP Joule и повысить производительность клиентов SAP.

Перевод с английского

ИСТОЧНИК