Моментът между избора на доставчик на CMMS и подписването на договора е най-важният момент във целия процес на оценка.
Това е и моментът, през който повечето купувачи бързат.
Оценката е завършена.
Демонстрацията беше впечатляваща.
Преговорите за цената приключиха.
Подписването изглежда като формалност.
Не е така.
Вижте как Fabrico обединява OEE и поддръжката в една платформа.
Поискайте демоПроблемите, които карат CMMS внедряванията да не постигнат очакваното, неуспехи при приемането от потребителите, изненади по отношение на свързаността, пропуски в поддръжката след пускането в експлоатация, проблеми с преносимостта на данните, почти винаги могат да бъдат открити преди подписването на договора.
Те рядко се откриват, защото купувачите спират да задават въпроси в момента, в който са избрали доставчик.
Този контролен списък е предназначен да затвори тази пропаст.
Той обхваща петте области на надлежна проверка, които имат най-голямо значение преди сключване на договор за CMMS в производството, с конкретни стъпки за проверка за всяка една.
Завършете всяка секция преди подписване.
Не защото очаквате да намерите проблеми.
Защото намирането на проблеми преди подписването на договора не струва нищо.
Намирането им след това струва значително повече.
Най-надеждният сигнал дали CMMS ще постигне обещаните резултати във вашето съоръжение е структуриран пилотен проект, проведен върху вашите реални активи с вашите реални техници.
Ако сте завършили 30-дневен пилот, следната валидация вече трябва да съществува.
Ако не сте провели пилот преди достигане до етапа на договор, проведете такъв преди подписване.
Доставчик, който не е склонен да подкрепи 30-дневен пилот на представителна селекция от вашите активи преди договорно обвързване, предава важно послание относно увереността си в представянето на платформата в реални условия.
Контролен списък за валидация на пилота
☐ По време на пилота е потвърдена свързаността на машините за поне един съвременен дигитализиран актив, един наследен (legacy) актив и една ръчна или хибридна станция.
☐ Връзката беше стабилна през целия период на пилота, без необясними пропуски в данните, прекъсвания на сигнала или проблеми с точността.
☐ Поне един условно задействан превантивен ремонт (condition-based PM) се задейства автоматично от машинен сигнал по време на пилота, не ръчно планиран календарен PM.
☐ Процентът на приемане/използване от техниките достигна над 70% до ден 30 от пилота, измерено чрез действителна честота на влизане в мобилното приложение, а не чрез самосъобщено съответствие.
☐ Най-малко един запис от одитната следа за съответствие бе прегледан изцяло, потвърждавайки, че съдържа потребителска атрибуция, отметка за време, използвани части, версия на SOP и подпис на нивото, което изисква вашата регулаторна рамка.
☐ Данните за OEE от периода на пилота бяха прегледани заедно със записите за поддръжка, потвърждавайки, че и двата набора данни съществуват в една и съща среда и че кръстосаното им сверяване не изисква ръчен експорт и интеграция на данни.
Договорите за производствен CMMS съдържат клаузи, които създават продължаващи задължения и ограничения, лесни за пренебрегване, когато основният фокус е върху цената.
Тези условия имат по-голямо значение, отколкото повечето купувачи осъзнават на етапа на подписване, особено тези, които уреждат преносимостта на данните, подновяването на договора и промяната на обхвата.
Контролен списък за условията на договора
☐ Клауза за преносимост на данните потвърдена.
Договорът изрично посочва, че всички данни, записи за активите, история на работните поръчки, записи за поддръжка, данни за OEE, могат да се експортират в стандартен машинно-четим формат (CSV, JSON или XML) по всяко време и при прекратяване на договора.
Доставчик, който се съпротивлява на ясна клауза за преносимост на данните, създава бъдещи разходи за смяна, които трябва да включите в общата стойност на притежанието сега.
☐ Период за предизвестие при прекратяване е документиран и разумен.
Договори, изискващи 6-12 месеца предизвестие за прекратяване при годишни абонаменти, създават значително заключване.
30-90 дни е разумен период за предизвестие при прекратяване за производствен CMMS.
☐ Условията за покачване на цените са дефинирани.
Годишните увеличения на цените над определен таван, обикновено CPI плюс 2-3%, трябва да изискват вашето изрично съгласие, а не автоматично прилагане.
Потвърдете дали договорът включва клауза за покачване на цените и какви са нейните условия.
☐ Обхватът на включената поддръжка е изрично дефиниран.
Поддръжката при внедряване, управлението на акаунта след стартирането, ангажиментите за време за отговор при критични оперативни проблеми спрямо въпроси за конфигурация или употреба и процесът за ескалация на нерешени проблеми, всичко това е дефинирано в писмена форма, а не оставено на устни уверения по време на търговския процес.
☐ Обхватът на свързаността е документиран.
Конкретните активи, включени в проекта за машинна свързаност, са изброени, с пътя на свързаност за всеки (директен PLC, IoT шлюз, компютърно зрение) и страната, отговорна за инсталацията.
Неочаквани проблеми със свързаността по средата на внедряването са едни от най-честите източници на забавяне в графика и конфликт по бюджета.
☐ Гаранции за наличност и достъпност на данните са посочени.
Потвърдете дали в договора са включени условия за SLA относно наличността на платформата, особено релевантно за платформи, хоствани в облак, и какви са средствата за защита, ако те не бъдат изпълнени.
Качеството на поддръжката след стартирането е най-подценяваният фактор за успеха на внедряване на CMMS.
Търговският екип и екипът по внедряване, които са били внимателни и отзивчиви по време на оценката, не винаги са същите хора, които ще поддържат експлоатацията след стартирането.
Валидирането на модела за поддръжка след стартирането преди подписване не е скептицизъм, това е стандартна дължима проверка.
Контролен списък за поддръжка след стартирането
☐ Именуван мениджър на акаунт е потвърден.
Името на мениджъра на акаунта, който ще отговаря за взаимоотношението след стартирането, е документирано.
Потвърдете дали този човек е бил ангажиран в процеса на внедряване или е нов контакт, който започва работа при стартирането.
☐ Ангажиментите за време за отговор на поддръжката са в писмен вид.
Договорът прави разграничение между ангажиментите за време за отговор при критични оперативни проблеми (недостъпност на платформата, загуба на данни, системни сривове, засягащи производствените операции) и стандартни въпроси за конфигурация или употреба.
Времена за отговор при критични проблеми под 4 часа през работно време и дефиниран път за ескалация при критични случаи извън работно време са разумни очаквания за платформа за производствени операции.
☐ Процесът за комуникация при актуализации на продукта е дефиниран.
Доставчикът има документиран процес за комуникация на актуализации на платформата преди тяхното внедряване, включително промени, които засягат конфигурираните работни потоци, интеграции или структури за документация за съответствие.
Попитайте конкретно как актуализациите на продукта са повлияли на конфигурациите на съществуващите клиенти през последните 12 месеца и как тези клиенти са били уведомени и подпомогнати през промените.
☐ Референтни клиенти, които са оперирали след стартирането, са били контактувани.
Поне двама референтни клиента, които са 12-24 месеца след стартирането в подобна производствена среда, са били контактувани директно, не през организирани от доставчика референтни разговори.
Конкретните въпроси, които да зададете на референтите:
„Как се промени качеството на поддръжката на доставчика между фазата на внедряване и фазата след стартирането?“
„Имаше ли изненади след стартирането, проблеми със свързаността, пропуски в документацията за съответствие, проблеми с усвояването, които не бяха идентифицирани по време на оценката?“
„Бихте ли внедрили тази платформа отново, знаейки това, което знаете сега?“
За производители с налична ERP инфраструктура, SAP, Microsoft Dynamics, NetSuite, интеграцията между CMMS и ERP е критично оперативно изискване, което заслужава специфична валидация преди подписване.
Контролен списък за интеграция и свързаност с ERP
☐ Архитектурата на интеграцията е документирана писмено.
Конкретните потоци от данни между CMMS и ERP, производствени поръчки от ERP към CMMS, разходи за поддръжка от CMMS към ERP, работни потоци за закупуване на резервни части, са документирани с посочен технически метод за интеграция.
„Ние се интегрираме със SAP“ не е достатъчна документация.
„Ние се свързваме със SAP чрез двупосочен REST API, синхронизираме производствените поръчки на всеки 15 минути и изпращаме данните за разходите по поддръжката в SAP PM при затваряне на работната поръчка“ е достатъчна.
☐ Отговорността за интеграцията е възложена.
Кой е отговорен за изграждането, тестването и поддържането на интеграцията, доставчикът, вашият IT екип или трети интегратор, е изрично дефинирано в договора.
☐ Тестването на интеграцията е включено в обхвата на внедряването.
Графикът на внедряването включва конкретна фаза за тестване на интеграцията преди стартиране, с определени критерии за приемане, които интеграцията трябва да изпълни, преди платформата да бъде обявена за работеща.
☐ Отговорността за поддръжка на интеграцията е дефинирана след стартирането.
Когато ERP или CMMS платформата се актуализира и интеграцията се счупи, което рано или късно ще се случи, кой е отговорен за нейното отстраняване, в какъв срок и на каква цена, е документирано.
Екипът за внедряване, който всъщност ще конфигурира и внедри платформата, не винаги са същите хора, които представяха по време на оценката.
Валидирането кои ще бъдат на място по време на вашето внедряване, и какъв е реалистичният график въз основа на сравними внедрявания при клиенти, е последна стадийна проверка, която повечето купувачи пропускат.
Контролен списък за екипа за внедряване и графика
☐ Именувани членове на екипа за внедряване са потвърдени.
Инженерът по автоматизация и мениджърът на акаунта, които ще бъдат назначени за внедряването, са идентифицирани поименно преди подписване на договора.
Ако доставчикът не може да назове конкретните членове на екипа за внедряване на етапа на договора, попитайте кога ще бъдат назначени и направете договора обусловен от потвърждение за назначаване на екипа преди започване на внедряването.
☐ Графикът на внедряването е базиран на данни от сравними клиенти.
Доставчикът може да предостави документирани срокове за внедряване от поне три сравними внедрявания при клиенти, подобен размер на съоръжението, подобни типове оборудване, подобна сложност на свързаността.
Ако обявеният график е значително по-бърз от сравнимите внедрявания, попитайте какво ще бъде отложено или изключено, за да се постигне той.
☐ Критериите за стартиране са дефинирани в договора.
Конкретните условия, които трябва да бъдат изпълнени, за да се обяви внедряването за завършено, процент на свързаност на машините, процент на приемане от техниките, конфигурация на документацията за съответствие, са посочени в договора, а не оставени на усмотрението на доставчика.
☐ Потвърдена е възможността за свързване на наследени активи.
Ако съоръжението включва наследено оборудване, което ще изисква внедряване на IoT шлюз или покритие с компютърно зрение, подходът за свързаност за тези конкретни активи е валидиран по време на пилота или чрез документирана предпроектна оценка.
Неочаквани проблеми със свързаността при наследените активи са най-честата причина за забавяне на графика на внедряването.
След като завършите всеки раздел от този контролен списък, един последен въпрос си струва да бъде зададен директно на търговския представител на доставчика, не на екипа по внедряване или мениджъра на акаунта.
„Ако това внедряване не постигне резултатите, които обсъдихме по време на оценката, какви средства за защита имаме?“
Отговорът разкрива повече за увереността на доставчика в тяхната платформа от всяко демо или сравнение на функции.
Доставчик, който отговаря със специфични, документирани механизми, гаранции за представяне, определени процеси за корекция, клаузи за излизане, свързани с неизпълнение на измерими резултати, е доставчик, който застава зад своето внедряване.
Доставчик, който отговаря с уверения, отклонения или прехвърляне към обсъждане защо неизпълнението е малко вероятно, вместо това какво се случва, ако то се случи, предава нещо, което си струва да се отбележи преди подписване.
| Област на проверка | Статус |
|---|---|
| Пилотната валидация завършена, свързаност, процент на приемане, условно задействане, одитна следа за съответствие | ☐ |
| Клауза за преносимост на данните потвърдена | ☐ |
| Период за предизвестие при прекратяване документиран и приемлив | ☐ |
| Условия за покачване на цените дефинирани | ☐ |
| Обхват на свързаността документиран за всеки актив | ☐ |
| Моделът за поддръжка след стартирането е дефиниран писмено | ☐ |
| Именуван мениджър на акаунт потвърден | ☐ |
| Референтни клиенти контактувани независимо | ☐ |
| Архитектура на ERP интеграцията документирана | ☐ |
| Отговорност за поддръжка на интеграцията възложена | ☐ |
| Именуван екип за внедряване потвърден | ☐ |
| Критерии за стартиране дефинирани в договора | ☐ |
| Свързаността на наследените активи валидирана | ☐ |
| Последният въпрос за средства за защита зададен и получил отговор | ☐ |
Подписвайте само когато всяка кутия е маркирана.
Не преди това.
Разумно ли е да поискаме пилот от доставчика преди подписване?
Да, и готовността на доставчика да подкрепи структуриран пилот преди договорно обвързване сам по себе си е смислен сигнал за увереността в представянето на платформата в реални условия.
30-дневен пилот на представителна селекция от активи, обхващащ валидацията на свързаността, измерването на процента на приемане и потвърждението на одитната следа за съответствие, описани в Област на проверка 1, е разумно изискване преди подписване за значима технологична инвестиция.
Какво ако доставчикът се съпротивлява да включи критерии за стартиране в договора?
Съпротивата към дефинирани критерии за стартиране е знак, който трябва да се вземе сериозно.
Критериите за стартиране защитават и двете страни, те дават на доставчика ясна дефиниция какво представлява успехът и дават на купувача обективна основа за обявяване, че внедряването е завършено.
Доставчик, който се съпротивлява на дефинирани критерии за стартиране, обикновено се притеснява, че критериите ще разкрият разлика между прогнозирания му график и реалната му способност за доставки.
Колко важна е преносимостта на данните за CMMS, хостван в облак?
Критично важна.
Вашата история на поддръжката, записи за активите и документацията за съответствие са оперативни активи, които вашата организация притежава, независимо коя платформа ги съхранява.
Договор за CMMS, който не гарантира изрично вашата възможност да експортирате тези данни в стандартен формат по всяко време, включително при прекратяване, създава зависимост, която значително увеличава разходите за смяна, ако платформата не отговаря на очакванията.
Трябва ли да договаряме условията на договора или да приемем стандартните условия?
Договаряйте.
Конкретно: клаузи за преносимост на данните, периоди на предизвестие при прекратяване, тавани за покачване на цените, критерии за стартиране и ангажименти за време за отговор при поддръжка след стартирането.
Тези условия са преговаряеми при повечето доставчици, и доставчици, които отказват да ги преговарят по какъвто и да е въпрос, предават динамика на сила между продавач и купувач, която ще влияе на взаимоотношението през целия период на договора.
Ако всеки елемент от този контролен списък е потвърден и последният въпрос е получил задоволителен отговор, договорът е готов за подпис. Ако някой елемент остава неразрешен, разрешете го първо. Внедряването още не е започнало. Това е последният момент, когато нерешените въпроси не струват нищо да бъдат адресирани.
Вижте OEE & CMMS на живо за 15 минути.
Заявете демо
Вход
Блог
