Спасибо за развернутый комментарий! С "архаичностью" я бы поспорил, все-таки считаю, что нефтегазовая промышленность в нашей стране применяет передовые технологии: например, после перевода с промысла в офис я 2 года участвовал в разработке цифрового двойника месторождения. Но некоторые работы действительно могут выполняться по древним технологиям😅

В качестве первичной метрики проекта был выбран удельный показатель "Количество "полетов" / Среднедействующий фонд скважин, д.ед./период". При этом основными вторичными метриками стали длительность ремонта, затраты на ремонт и т.д., а основной метрикой последствий - стоимость эксплуатации на скважину. Т.е. комплексно разложили бизнес-процесс на CTx согласно "треугольнику эффективности". О нем подробно расскажу далее в своих постах.

14 дней были определены статистически для данных условий эксплуатации. Вначале был определен нелинейный коэффициент снижения дебита до критической отметки - в зависимости от дебита по скважине. Понятно, что данный коэффициент обычно закладывается регламенты по эксплуатации оборудования, но на практике могут применяться несколько иные управленческие решения, в данном случае и наш расчетный коэффициент оказался больше регламентного. Затем построена кривая наджености, где точкой перегиба оказались те самые 14 дней. То есть при превышении этих 14 суток эксплуатации с момента снижения дебита до критического резко возрастала вероятность "полета" оборудования.

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

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

Эффект по проекту составил более 30 млн руб.

К сожалению, еще не все абреввиатуры адаптированы под русский язык, тот же DMAIC, знакомый многим, могут не узнать, если писать или говорить ОИАСК☺️

Благодарю! Подписывайтесь на канал, впереди еще много интересного, в т.ч. практика применения Lean Six Sigma в ИТ.

Добрый день! В чем вы измеряете сложность?

Очень много шагов и процессов. Можно всё сократить в 2 раза. Начать с - описание процессов сделать по mini. И т.д и т.п.

Какие этапы, на ваш взгляд, можно исключить? Что лишнее? Забегая вперед, простым проектом кайдзен/А3 тут было не обойтись - требовалась статистика и анализ гипотез, чтобы выявить значимые факторы.

Как я писал убрать R-Sipoc-R и кросс-функциональные диаграмы, заменить на простую таблицу SIPOC. Упростить сбор входных данных. И так пройтись по каждому этапу. Нужно помнить что цель скорость ремонта, а не процесс перед ним.

Цель проекта заключалась не в скорости ремонта, а в сокращении “полетов”, т.е. аварий. Рабочей группой выделены причины, в которые также входил хим. состав добываемой продукции (он в том числе оказался влияющим на случаи “полетов”). Формулирование требований ко входам и выходам при построении SIPOC не требует много времени, но позволяет получить дополнительную информацию, например, тип покрытия труб, спускаемых в скважину, что также можно в дальнейшем анализировать, как потенциальную причину, влияющую на количество аварий, и т.д. Кросс-функциональные диаграммы позволяют выявить “скрытые фабрики”, если их, конечно же, строить в Гемба, а не сидя в теплом кабинете) “Скрытые фабрики” зачастую направление для быстрых улучшений процесса. Если вам знакома структура проектов LSS по DMAIC, то вы должны понимать, что только в редких случаях мы отказываемся от использования каких-либо инструментов, а вот каких - возможно расскажу в следующих своих постах.

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

Все зависит от текущего уровня развития бизнес-процессов. Если проводить аналогии, то ранее достаточно было черпать нефть с поверхности земли, а сейчас требуется строить сложные высокотехнологичные скважины. Следовательно, если раньше нам в случае возникновения проблемы требовалось простое улучшение из разряда "заделать отверстие в ведре чопиком", чтобы при транспортировке эта нефть не вытекала на землю, то сейчас все несколько сложнее. В любом случае буду рад ознакомиться с вашим опытом реализации проектов улучшений.

Основная проблема в основном, чтобы работникам не усложняло жизнь, было понятно и втягивались в процесс. Наблюдал не раз на месторождениях, что заполняли всякие формы для верху, а потом сами на коленке решали за 5 минут что делать и распределили этапы по ответственным.