На наш взгляд к делу определения объекта последующего анализа и формирования стратегии надежности надо подходить «сверху вниз», иерархично. На первом этапе мы имеем полное право таким объектом считать все наше предприятие целиком! Сложный, многофункциональный объект, предназначенный (т.е. имеет Функцию) для выработки продукции нужного объема, качества и себестоимости. Старт анализа «сверху» начинается с определения самых главных Функций предприятия целиком. Такие функции должны коррелировать с основными, «генеральскими» КПЭ предприятия — объем выпуска продукции, его себестоимость, уровень брака, ESG-издержки и пр. Функция — это достижение соответствующего КПЭ! Соответственно, верхне-уровневые (тоже «генеральские») Функциональные отказы — это события, мешающие достижению КПЭ!
Понятно, что остановится на уровне предприятия целиком будет не хорошо — слишком сложный объект для анализа. Необходима декомпозиция на более «простые» подобъекты, в конце которой будут объекты ТОиР — единицы оборудования. Делать это можно разными способами, но, по нашему мнению, наиболее эффективный из них — это объединять оборудование по их прямому или косвенному участию в каком либо шаге техпроцесса (технологического передела), причем таком шаге, в конце которого можно четко указать его продукцию (конечную или полуфабрикат). Весь техпроцесс представляет собой цепь таких этапов, каждый из которых, получая на входе полуфабрикаты и ресурсы, выполняет свой набор функций по технологическому переделу и передает свои результаты (продукцию / полуфабрикаты, ресурсы, отходы) на другой этап. Деление целевого технологического процесса предприятия на такие этапы как правило уже хорошо продумано технологами и проектировщиками завода, каждый из этапов имеет свои КПЭ, встроенные в вышестоящие КПЭ, являются самостоятельной зоной ответственности и могут (но не обязаны) продолжать работать «на склад», даже если прервутся последующие этапы производства.
Совокупность оборудования, задействованного в каждом таком этапе, мы и называем Системой в контексте объекта анализа надежности.
Вот несколько правил формирования такой Системы:
- Должна быть однозначно определена «продукция», вырабатываемая Системой — полуфабрикат любой стадии; ресурс (электроэнергия, тепло, воздух, вода и пр.); брак; отходы. Это позволит адекватно определить все Функции, действительно важные для выработки данной продукции.
- Должен быть однозначно определен техпроцесс, реализуемый данной Системой — способ передела входных для данного техпроцесса ресурсов и полуфабрикатов в выходную «продукцию». Это позволит адекватно определить Функциональные отказы, а также их механизмы и причины.
- «Продукция» любой Системы должна представлять собой самостоятельную ценность, которую можно условно «положить на склад» (незавершенное производство) или отправить в распределительную сеть (энергия, вода и пр.). Это позволит адекватно оценивать экономический ущерб от перерыва производства на данном этапе.
- Оборудование, входящее в Систему, должно входить только в одну Систему. Если какая-либо единица оборудования «работает» на несколько техпроцессов (участвует в выработке разной «продукции»), значит она должна входить в Систему другого рода, обеспечивающую своей «продукцией» другие Системы в качестве «внутреннего поставщика». Это снизит ошибки анализа и позволит сформулировать эффективную стратегию для таких объектов — «многостаночников»
- Системы должны быть «выстроены» в единую технологическую схему предприятия (направленный граф), последовательно передавая входные (покупные) ресурсы через этапы их переработки до выпуска и отгрузки готовой продукции, с учетом схем резервирования Систем. Причем в этой схеме нужно «не забыть» вспомогательные процессы — энергетика, подготовка технологических сред, транспорт, АСУ ТП, утилизация отходов и пр. Это позволит адекватно учесть взаимовлияние Систем и их надежности друг на друга.
- Система не должна быть слишком большой. Система, состоящая из сотен единиц оборудования все еще слишком сложна для комплексного анализа. По возможности следует выделять подсистемы (с тем же набором правил), даже если технологи не прописывали явным образом структуру переделов в такой Системе. Можно без особых натяжек выделить промежуточную «продукцию» и сформировать вокруг нее подсистему, особенно если в рамках большой системы есть элементы параллельного процесса. В принципе ни что не мешает проводить такую детализацию процессов на подпроцессы еще несколько итераций в глубь, но тут можно перестараться — «нарезать» единый техпроцесс на слишком большое количество «простых» элементов, которые теперь будет сложно соединить воедино.
- Система может быть типовой. Например, системы подготовки воздуха, воды, энергоснабжение, типовые производственные линии, не уникальные на предприятии и по отрасли, могут быть типизированы. Для такой типовой системы может быть проведен обобщенный анализ (построена Модель надежности типовой Системы), которую затем можно будет много раз встраивать по соответствующим местам — формировать из нее Модель для уже конкретной Системы данного типа. Это может сильно упростить анализ и формирование стратегий.
Проведенная таким образом декомпозиция предприятия на системы и подсистемы позволит нам более эффективно разобраться с каждой из систем, не потеряв ее производственного контекста. Кроме того, мы получаем еще один взгляд на активы предприятия, еще одну иерархическую модель, которая позволяет «примирить» как минимум эксплуатацию (т.к. тут виден техпроцесс), ремонтников (т.к. эта модель собрана из их объектов ТОиР), специалистов АСУ ТП (т.к. тут учтено влияние систем АСУ ТП на техпроцесс и надежность) и управление бизнесом (т.к. тут видна взаимосвязь их бизнес-КПЭ со всей производственной системой, видны своего рода «Места Возникновения» КПЭ).
Модель, описывающая весь техпроцесс предприятия, составленная к тому же из конкретных «низовых» единиц оборудования с их оценкой рисков, надежности, текущего и ретроспективного техсостояния и режимов эксплуатации — это еще и прекрасная основа для последующего решения самых разных задач имитационного моделирования, как в сценарии «что, если?» так и «что нужно, чтобы?». А в случае информатизации предприятия, создании «цифрового двойника» — именно такая модель наиболее адекватна для целей агрегирования, отображения и моделирования данных, их анализа в самых разных разрезах.
Для задач анализа надёжности такая модель дает нам сразу несколько очень важных возможностей:
- Формирование Иерархии Функций — от самых главных бизнес-функций до узкоспециальных технических функций каждой единицы оборудования. Как следствие такой иерархии — формирование Иерархии КПЭ, так же сверху до низу. Это даст управлению всех уровней реальную «симфонию» целей и задач, как бы узко и «специфично» они не формулировались.
- Формирование Иерархии Функциональных отказов, их механизмов и причин с учетом взаимовлияния единиц оборудования в рамках системы.
- Формирование Последствий отказов и Матриц не сниженных рисков в привязке к реальному техпроцессу и месту анализируемого объекта в нем, выпускаемой и потребляемой «продукции», взаимовлиянию объектов друг на друга, резервированию
- Формирование Рекомендаций и Стратегий по каждой единице оборудования с учетом ее вхождения в Систему. Решение задач группирования воздействий (пакета воздействий на систему целиком) по срокам проведения, видам воздействий, с учетом оптимизации сроков плановых простоев, объединения / поглощения работ, невозможности или необходимости одновременного проведения работ и пр.
В качестве резюме вышесказанного — да, методология RCM так же рекомендует проводить анализ надежности для систем, однако способ формирования таких систем там во многом оставлен на усмотрение конкретного специалиста. Наш опыт показывает, что такая «свобода» не всегда хорошо — нужны какие-то правила. Все, описанное выше — это наша попытка такие правила прописать. О том, как системы, построенные по данным правилам, помогут в последующем планировании производства и ТОиР (и не только) будет описано в нашей следующей статье «Управление надежностью активов. Стратегия или план».