Капанът на копирането и поставянето: Повечето RFP се провалят, защото са копирани от остарели шаблони, които дават приоритет на „списъците с функции“ пред „използваемостта“.
„Убийствените въпроси“: Конкретни въпроси, които да включите във вашата заявка за предложения (RFP), които незабавно елиминират тромавия остарял софтуер.
Фокусът върху надеждността: Как да прехвърлите изискванията си от „Проследяване на поддръжката“ към „Надеждност на производството“ (OEE).
Писането на заявка за предложение (RFP) за софтуер за поддръжка обикновено е мъчителен процес.
За да спестят време, мениджърите по снабдяването често изтеглят общ шаблон от интернет. В крайна сметка те получават 50-страничен документ, в който се задават въпроси, които не са актуални от 2010 г. насам, като например „Системата поддържа ли Windows XP?“ или „Може ли да се инсталира локално?“.
Лошите RFP водят до лош софтуер.
Ако задавате общи въпроси, получавате общи отговори. В крайна сметка купувате система, която изглежда добре на хартия, но е мразена от техниците, които трябва да я използват.
За да закупите модерна система като Fabrico , ви е необходима модерна заявка за предложение (RFP). Трябва да спрете да искате характеристики и да започнете да искате резултати.
Ето вашето ръководство за писане на RFP, което филтрира „Shelfware“ и намира „Reliability Engines“.
Повечето заявки за предложения (RFP) започват със списък от 200 характеристики. („Трябва да има работни поръчки. Трябва да има инвентар.“)
Всеки продавач на земята ще отбележи с „Да“ тези квадратчета. Това не ви помага да решите.
Вместо това, започнете вашата заявка за предложения (RFP) с бизнес цели . Принудете доставчиците да обяснят как решават вашия специфичен проблем.
Лошо изискване: „Системата трябва да проследява времето на престой.“
Добро изискване: „Опишете как системата се интегрира с PLC данни, за да категоризира автоматично времето на престой и да изчисли OEE в реално време.“
Причина номер 1 за неуспеха на внедряването на CMMS е ниската степен на приемане от потребителите. И все пак, повечето RFP едва споменават потребителското изживяване (UX).
Включете раздел във вашата заявка за предложения, посветен на използваемостта на мобилните устройства .
Изискване: „Доставчикът трябва да демонстрира мобилен работен процес за персона „Техник“, който изисква по-малко от 5 кликвания за затваряне на работна поръчка.“
Изискване: „Доставчикът трябва да поддържа офлайн възможности и качване на снимки директно от компютъра.“
Ако даден доставчик отговори с „Не“ или „Използваме обвивка на браузър“, дисквалифицирайте го. Вие предпазвате „Майк“ (мениджър поддръжка) от закупуване на инструмент, който екипът му ще намрази.
Използвайте тези специфични въпроси, за да разкриете разликата между съвременните платформи и остарелия bloatware.
Доставчиците на стари системи ще кажат „Интегрирано“ (което означава, че разчитат на партньор от трета страна).
Фабрико отговаря „Native“. Защо това има значение? Защото, ако OEE се повреди при интеграция на трета страна, доставчикът обвинява партньора. Ако е native, един екип за поддръжка го поправя.
Попитайте как системата обработва кратки спирания (микроспирки), които не изискват работна поръчка.
Старите инструменти ще ви принудят да създавате работна поръчка за всяка 30-секундна спирка (създавайки боклук от данни).
Съвременните инструменти (Fabrico) използват логика, за да ги категоризират като „Оперативни загуби“, без да претрупват дневника за поддръжка.
Отговор от предишни версии: „Пускаме основна версия на всеки 2 години.“ (Това означава, че ще се борите с грешки в продължение на 2 години).
Съвременен отговор: „Публикуваме актуализации всяка седмица чрез облака.“ (SaaS).
„Паула“ (стратегически лидер) трябва да знае, че това е подходящо за ИТ отдела.
API на първо място: Не питайте „Интегрирате ли се със SAP?“. Питайте „Документацията ви за API публична ли е и базирана ли е на REST?“. Това доказва, че са модерни.
Сигурност: Поискайте сертификат SOC 2 Type II. Това е стандартът за 2026 г.
В старите RFP (заявки за предложения) често се изисква ценообразуване „на място“. Това ви наказва за растежа.
Поискайте модел „Лиценз за сайт“ или „Неограничен заявител“ .
Искате всеки оператор на машина да може да подаде заявка. Ако доставчикът ви таксува за всяко влизане на оператор, никога няма да постигнете пълна продуктивна поддръжка (TPM).
Целта на RFP не е да се намери софтуерът с най-много функции. Целта е да се намери софтуерът, който е подходящ за вашата фабрика.
Като фокусирате вашата заявка за предложения (RFP) върху интеграция , използваемост и надеждност , вие филтрирате „динозаврите“ и намирате гъвкавите инструменти.
Нуждаете се от шаблон?
Не започвайте от нулата. [Свържете се с екипа на Fabrico] и ние можем да ви предоставим шаблон за технически изисквания, който да ви помогне да структурирате оценката си.
Login
Блог
