Предаване от проекта към експлоатация: контролен списък за пропуснати инженерни задачи

Ключови изводи

• Капиталният проект се пуска в експлоатация по график, екипът по проекта се разпуска и в рамките на шест месеца екипът по експлоатация се бори с проблеми, които екипът по проекта е разбирал, но никога не е документирал. Моделът е толкова постоянен, че предаването от проекта към експлоатацията заслужава собствена дисциплина.
• Осемте елемента, които най-често се пропускат при предаването, не са очевидните (чертежи, ръководства, резервни части). Те са „меките“ елементи: кой е бил инженерът на OEM, който познава този актив; каква е била недокументираната толерантност при инсталиране; кой трети интегратор притежава персонализирания код; какви настройки са направени на място, които никога не са стигнали до проектната документация.
• Решението е структурирана контролна карта за предаване, която се прилага през последните 30 дни на проекта, преди екипът да си тръгне, а не след като вече е продължил нататък. Контролната карта е кратка; дисциплината при нейното прилагане е всичко.
• Най-голямото преимущество от работещо предаване е по-високо MTBF през първото тримесечие. Заводите, които провеждат чисто предаване, имат значително по-малко повреди през първото тримесечие след пускане в експлоатация в сравнение със заводите, които го пропускат, защото екипът по експлоатация оперира актива така, както екипът по проекта е имал предвид, а не само по буквалното описание в ръководството.

Защо предаването се пропуска

Стимулът за екипа по проекта свършва с пускането в експлоатация. Договорът беше да се достави работещ актив; след като той започне да произвежда, проектът е приключил. Екипът се пренасочва към следващия проект. Документацията, която съществува в проектните файлове, но не е в ръцете на екипа по експлоатация, се губи при прехода. Знанието, което е живяло в главата на инженера по проекта, напуска сградата.

Екипът по експлоатация наследява актив, който работи в първия ден, и натрупва проблеми през следващото тримесечие.

Някои от тези проблеми са документирани в проектните файлове, които никой не е предал; някои са в главата на инженера на OEM, когото никой не е срещнал; някои са в кода за интеграция от трета страна, който никой не знае как да модифицира.

Първата голяма повреда принуждава упражнение по обратен инженеринг, което е трябвало да бъде 30-минутен разговор.

Решението е процедурно. Контролен списък за предаване, който се изпълнява през последните 30 дни на проекта, улавя повечето пропуски преди да се превърнат в оперативен дълг. Статията за системата за управление на работни наряди разглежда структурите от данни, в които изходът от предаването се интегрира.

Осемте елемента, които най-често се пропускат

1. Името и директният номер на инженера на OEM

Не търговският контакт, не имейлът за поддръжка, а действителният инженер, който познава конкретния актив. Когато нещо се обърка в четвъртия месец, екипът по експлоатация трябва да достигне до човек, който е работил по този актив, а не до обща опашка за поддръжка. При предаването трябва да се заснеме този контакт и на инженера трябва да му се каже да очаква обаждане.

2. Недокументирани толеранси при инсталиране

Всяка инсталация има толеранси, които са приложени на място, но никога не са се върнали в проектните документи. Активът е нивелиран до конкретна конфигурация от подложки; ориентацията е настроена на толеранс по-строг от стандартния; потокът на охлаждащата вода е настроен на стойност, която ръководството не споменава.

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

3. Собственост/отговорност на интегратора от трета страна

Персонализиран код, конфигурации, скриптове за интеграция, обикновено написани от трета страна по време на пускането в експлоатация. Екипът по експлоатация трябва да знае кой притежава този код, кой може да го променя и как изглежда споразумението за поддръжка. Без това първият проблем с интеграцията след шест месеца се превръща в многоседмично разследване кой изобщо може да промени кода.

4. Списъкът с промени на място

Какво е променяно по време на пускането в експлоатация, което не е било в оригиналния проект. Промени в окабеляването, пренасочване на тръби, корекции в контролната логика. Те практически винаги съществуват; почти никога не влизат в "as-built" чертежите, освен ако процесът на предаване не ги улови изрично.

5. Последователността при стартиране

Не документираната последователност за пускане, а действителната, която екипът по пускане е използвал. Повечето активи имат ритуал при стартиране, който OEM не документира: кой клапан се отваря първи, колко дълго да се чака преди включване, какво трябва да е първото отчитане. Този ритуал често е разликата между чист старт и повреда при стартиране.

6. Списъкът с известни особености

Всеки актив има особености, за които екипът по пускане знае. „Третият манометър показва с 5% повече; калибрирахме го спрямо мастера.“ „ПЛК-то стартира с 30 секунди по-дълго, отколкото пише в ръководството, след прекъсване на захранването.“ „Моторът черпи повече ток при студено пускане; това е нормално.“ Тези особености спестяват на екипа по експлоатация седмици разследване, когато ги срещнат.

7. Графикът за превантивна поддръжка, който OEM действително препоръчва, спрямо този в ръководството

Ръководствата описват общи честоти за превантивна поддръжка; инженерите на OEM често препоръчват по-стриктни или по-редки честоти за конкретната инсталация, натоварването и местните условия. Предаването улавя препоръката, която инженерът на OEM е дал, а не само стандартната стойност в ръководството. Материалът за графика за превантивна поддръжка обяснява как това информира дългосрочния дизайн на ПП.

8. Очакваните проблеми през първите 90 дни

Какво екипът по пускане няма да се изненада да види през първите 90 дни, дори при успешна инсталация. Новите уплътнения се нагаждат, определени болтове изискват повторно затягане след температурни цикли, дрейф на сензорите през първия месец е нормален. Без този списък всеки дребен проблем изглежда като монтажен дефект.

30-дневният контролен списък за предаване

Структурата, която улавя осемте елемента:

• Ден -30 (30 дни преди пускане в експлоатация): Екипът по проекта и екипът по експлоатация определят отговорника за предаването от всяка страна. Отговорникът за предаването е лицето, което отговаря за завършването на контролния списък, а не комитет.
• Ден -21: Горните осем елемента (или версията на списъка за завода) се разпределят на конкретни членове на екипа по проекта за събиране.
• Ден -14: Първо черново издание на пакета за предаване се разпространява. Екипът по експлоатация идентифицира пропуските.
• Ден -7: Финалният пакет е готов. Съвместен обход на площадката с екипите на проекта и експлоатацията, разглеждащ всеки елемент лично.
• Ден 0 (пускане в експлоатация): Пакетът за предаване се подписва. Стимулът за екипа по проекта да бъде достъпен за последващи въпроси се договоря като 90-дневен период на подкрепа след пускане в експлоатация.

Материалът за KPI-тата в поддръжката на производство разглежда пост-пусковите метрики, които показват дали предаването е било успешно.

Как да измерим качеството на предаването

Честната мярка е MTBF през първото тримесечие в сравнение с прогнозното MTBF, посочено за проекта. Чистото предаване дава първотримесечен показател, близък до прогнозирания. Пропуснатото предаване дава първотримесечен показател значително под прогнозирания, като разликата се затваря за 6, 12 месеца, докато екипът по експлоатация отново открива това, което екипът по проекта вече е знаел.

Заводи, които проследяват тази метрика през множество капиталови проекти, изграждат обратна връзка: екипи по проекти, които предават добре, получават повторни поръчки; екипи, които не предават, се държат към разликата. Дисциплината се разпространява с времето.

Какво прави Fabrico

Контролният списък за предаване работи във всяко предприятие с CMMS.

Където единна платформа OEE + CMMS помага е на две места: осемте елемента от предаването стават постоянни полета към актива (не са заровени в проектна папка), и списъкът с очаквани проблеми за първите 90 дни се връзва със събитийния поток на OEE, така че екипът по експлоатация може да различава „очаквания модел“ от „реален проблем“ без да разчита на паметта.

Fabrico е изградена за този работен поток. За да видите как изглежда запис на актив, готов за предаване, запазете демо .

Често задавани въпроси

Кой трябва да бъде отговорен за процеса по предаване?

Функцията за капиталови проекти на завода, като експлоатацията е приемащата страна. Ако заводът няма отделна функция за капиталови проекти, ролята поема заводският инженер или директорът по експлоатация. Без единен собственик контролният списък деградира до „отговорност на всички“.

Ако проектът е изпълнен от EPC изпълнител?

Контролният списък за предаване става договорно задължение. Изпълнителят трябва да бъде платен срещу успешно предаване, не само срещу пускане в експлоатация. EPC договори, които плащат само при пускане в експлоатация, последователно дават най-лошите резултати при предаването.

Колко дълъг трябва да бъде периодът на подкрепа след пускане в експлоатация?

Минимум 90 дни. Първите 90 дни разкриват повечето от проблемите, които предаването е пропуснало; наличността на екипа по проекта през този период запълва остатъчните пропуски.

Ако екипът по проекта вече е напуснал?

Това е неприятният сценарий. Екипът по експлоатация трябва да реконструира осемте елемента сам, обикновено чрез проби и грешки през първите 6, 12 месеца. Контролният списък съществува, за да предотврати този сценарий; след като е настъпил, единственото решение е да се документира това, което те открият, за да бъде следващото предаване по-добро.

Коя е най-честата грешка при прилагането?

Изпълняване на контролния списък като бумащина, а не като разговор. Осемте елемента по-горе най-добре се улавят при съвместен обход с екипите на проекта и експлоатацията заедно, а не като формуляр, който екипът по проекта попълва сам. Разговорът изважда наяве особеностите; формулярът фиксира отметките.