Внедрение ЛИМС

Документация по внедрению (базовый перечень) Цель и функциональные требования — внутренний документ; Техническое задание — внутренний документ и/или приложение к договору (контракту); Договор, контракт, соглашение или иной документ с поставщиком (подрядчиком); План работ, согласованный с поставщиком, приказ о закреплении ответственного со стороны лаборатории; Акты, протоколы приема-передачи ЛИМС, запуска тестовой эксплуатации, приказ о закреплении ответственного (ых); Журнал или протокол тестовой эксплуатации (ТЭ); Акт или протокол передачи в опытно-промышленную эксплуатацию (ОПЭ), приказ о закреплении ответственного (ых); План валидации, протоколы валидации, отчет о валидации; Акт завершения ОПЭ; Приказ о запуске в промышленную эксплуатацию. Часть этих документов подготовит сам поставщик, но необходимо принимать в этом самое деятельное участие. Следует следить за соблюдением формальных сроков и их переносом при необходимости. Документация по внедрению должна остаться в лаборатории для того, чтобы потом можно было к ней обратиться при проведении изменений, доработок и ревалидации ЛИМС. Также эта документация может понадобиться при аккредитации или очередном подтверждении компетентности, поскольку эксперты могут её запросить. До завершения внедрения (или в момент завершения) необходимо также издать новые документы (процедуры) СМК, в которых будет описана работа сотрудников лаборатории в ЛИМС. #процессы #СМК #внедрение

Еще раз кратко о валидации ПО. Валидация ЛИМС, аттестация или сертификация - сделаем правильный выбор. Сертификации ПО такого типа в РФ нет. Конечно поставщики ЛИМС предъявляют какие-то сертификаты на своё ПО. Но подобная сертификация у нас в стране не регулируется, не является обязательной, и кроме того, такие сертификаты выдают не аккредитованные органы по сертификации, что нарушает закон о техническом регулировании (184-ФЗ), следовательно никакой юридической силы такие красивые бумажки не имеют. Однако многие заказчики хотят видеть сертификат на ЛИМС, а спрос, как известно, рождает предложение. Аттестация ПО существует в методических инструкциях Росстандарта (МИ 2174-91, МИ 2955-2010), но относится к аттестации метрологически значимой части ПО к средствам измерений (Р 50.2.077-2014). При утверждении типа СИ в обязательном порядке включается информация об используемом ПО (МИ 3650-2022). Естественно, что практически вся аттестация сводится к тому, какие результаты получаются при использовании данного СИ с данным ПО при испытании/поверке с эталоном, а также проверке наличия защиты от изменения ПО. К ЛИМС аттестация в таком виде не применима. Валидация ПО для аккредитованных лабораторий является обязательной, также как валидация расчётов в электронных таблицах в соответствии с требованиями п. 7.11.2 ГОСТ ISO/IEC 17025-2019. Лаборатории зачастую стараются получить подтверждение от разработчиков, но ведь в процессе внедрения вносятся множество изменений и продукт, установленный у одного заказчика, может сильно отличаться от продукта у другого заказчика. А при любых изменениях, включая изменения конфигурации программного обеспечения лаборатории или модификации коммерческого программного обеспечения, они должны быть утверждены, документированы и валидированы до введения их в действие. Валидация в терминах ГОСТ ISO/IEC 17025-2019 это "Предоставление объективных свидетельств того, что данный объект соответствует установленным требованиям, при котором установленные требования связаны с предполагаемым использованием". Соответственно для успешной валидации ПО необходимо прежде всего определиться с требованиями, то есть целями, задачами, функциональными требованиями, техническим заданием. Поскольку любые изменения конфигурации или модификации ПО должны быть утверждены и документированы, лаборатория обязательно должна составить Техническое задание (ТЗ) при внедрении ЛИМС. ТЗ самая важная часть валидации, поскольку именно на соответствие ТЗ лаборатория будет проверять (валидировать) ЛИМС. Про проблемы составления ТЗ я уже не раз упоминал, но повторюсь еще раз: "Необходимо сделать полное и непротиворечивое ТЗ на внедрение ЛИМС, чтобы потом использовать его для валидации ЛИМС". Более того, часто когда начинаю вести разговор о валидации ПО и объяснять, что это делается легко и просто, оказывается, что основная сложность заключается именно в составлении требований к ПО, то есть в написании ТЗ. #процессы #СМК #внедрение

Непосредственно внедрение ЛИМС Начало внедрения. После согласования ТЗ и подписания контракта, команда внедрения со стороны лаборатории начинает взаимодействие с командой внедрения со стороны поставщика (разработчика) ЛИМС. Поставщик, как правило, назначает одного сотрудника менеджером (руководителем) проекта, и всё дальнейшее взаимодействие происходит с ним. Команда внедрения лаборатории тоже должна выделить одного человека в качестве руководителя, чтобы взаимодействие двух команд было эффективнее. Менеджеру проекта необходимо ещё раз пройтись по ТЗ вместе с командой внедрения, уточнить все неясности, согласовать варианты реализации (исходя из возможностей выбранного ЛИМС). Если планируется внедрение расчётов по методикам испытаний, ведение всех первичных записей, то необходимо к обсуждению привлечь отдельных специалистов по каждой методике, чтобы уточнить все детали. Для уточнения форм отчётов, записей, процессов, менеджеру проекта необходимо запросить у лаборатории примеры по всем формам записей и ответов. Желательно иметь на каждую форму по несколько примеров готовых записей. Зачастую процессы лаборатории и заполняемые формы не оптимизированы, поэтому вылезает куча исключений из правил (пометки на полях, текстовые записи там где вроде бы должны быть числа, дополнительные расчёты и т.п.). По каждому такому отклонению необходимо провести обсуждение, чтобы решить как все-таки его записывать, необходимо ли добавлять отдельные поля, или просто сделать одно текстовое большое поле для примечаний. По итогам обсуждений и обследований форм записей менеджеру проекта необходимо сформировать и согласовать окончательный альбом форм отчетов, схемы процессов, которые будут реализованы в ЛИМС, формы записей результатов и расчёты по методикам. Дальнейшее внедрение фактически состоит из решения технических задач: 1. Установка необходимого оборудования (сервера, компьютеров), подключения к единой сети. 2. Установка на сервер и на компьютеры пользователей соответствующего программного обеспечения, его настройка (по необходимости). Этап настройки может быть достаточно длительным и сопровождаться доработками со стороны поставщика ЛИМС. 3. Обучение пользователей работе в ЛИМС. 4. Тестирование пользователями настроенных в ЛИМС форм расчетов, журналов, записей, отчетов, процессов. Передача обратной связи разработчику для устранения ошибок. 5. Исправление разработчиком ошибок, передача на повторное тестирование. Данный этап может несколько раз повторяться (проходить несколько итераций, улучшающих конечный продукт). 6. Передача в опытно-промышленную эксплуатацию. Пользователи начинают параллельно работать и в ЛИМС и по старому. 7. Валидация ЛИМС лабораторией. Подготовка протоколов и отчетов. 8. Исправление разработчиком замечаний, полученных при валидации. Передача в промышленную эксплуатацию. 9. Утверждение отчета по валидации ЛИМС. Переход лаборатории в промышленную эксплуатацию ЛИМС (Приказ о переходе, дополнение документов СМК и т. п.) 10. Сопровождение ЛИМС — это уже отдельный процесс, который также должен быть оформлен. #процессы #СМК #внедрение

ЛИМС vs Электронный журнал. Я задавал вопрос - чем электронный журнал отличается от ЛИМС. В первую очередь на ум приходит различие в форме. Электронный журнал ведётся, как правило, в отдельном текстовом или табличном файле. Как я уже указывал ранее, особой популярностью пользуются электронные таблицы. Электронный журнал создаётся по аналогии с бумажным журналом. Записи вносятся вручную одна за другой. Как отметил один из подписчиков, повышается скорость за счёт автоматизации расчётов, в остальном скорость заполнения журнала остаётся такой же, или даже уменьшается. На самом деле скорость заполнения электронного журнала зачастую повышается очень сильно из-за возможности копирования одних и тех же данных внутри электронного журнала. Также можно быстро переносить информацию между журналами просто копируя и вставляя ячейки. Если структура журналов будет схожей, то такое копирование значительно упрощает жизнь и ускоряет работу. Я уже писал, что такая малая автоматизация упрощает жизнь сотрудников, и идея внедрения идёт в основном от них, то есть внедрение снизу вверх. ЛИМС же является системой, и как минимум объединяет в себе несколько журналов, позволяет переиспользовать информацию из одних журналов в других, например использовать сведения об оборудовании в журнале по измерениям (испытаниям), или использовать сведения из журнала по отбору проб в журнале выдачи протоколов. Как отметила подписчица в комментариях, ЛИМС обеспечивает функции, недоступные в одном электронном журнале. За счёт объединения в одной системе нескольких журналов, справочников можно добиться новых свойств и функций ведения записей. Получается, что за счёт системности достигают эмерджментные свойства. Конечно часть журналов и в ЛИМС может быть только журналами, не имея новых свойств, и служить только для ручного ввода какой-то информации. Но, как минимум, при правильной разработке ЛИМС все журналы можно будет использовать для отчётов и контроля. Ещё приходилось слышать о том, что ЛИМС позволяет разграничить доступ, ограничить редактирование, обеспечивает резервное копирование. Конечно это важные свойства ЛИМС, которые должны быть, но при правильной организации хранения электронных журналов можно также разграничить доступ, обеспечить сохранность и резервное копирование. Также ЛИМС это не обязательно единая программа с базой данных. Теоретически можно создать ЛИМС на основе нескольких электронных журналов в электронной таблице, с разделением доступа на уровне файловой системы. Или сделать такую систему в каких-то онлайновых редакторах, наподобие Google Sheets. Также необязательно ЛИМС будет обеспечивать полную автоматизацию, это зависит от разработчиков. Вполне возможна ситуация, когда внесение информации в ЛИМС будет происходить медленнее чем в отдельный электронный журнал. #процессы #СМК #внедрение

В ответ на пост Для поставщиков ЛИМС имеет смысл включать этап обследования в этапы по контракту и прописывать, что по итогам обследования будет уточнен перечень методик, журналов, форм и отчётов, которые будут внедрены в лаборатории (настроены поставщиком в ЛИМС). Также некоторые формы и отчёты лаборатории можно в этот период изменить, если непосредственно в том же виде реализовать в ЛИМС не получится.

В ответ на пост Еще немного про ТЗ Большая ошибка любой лаборатории (любого заказчика) — доверить полностью работу с ТЗ поставщику (ЛИМС). Необходимо привлекать своих сотрудников команды внедрения и к написанию ТЗ. Для поставщика ПО основная проблема заключается в том, что для составления подробного ТЗ необходимо обследовать процессы лаборатории, ознакомить сотрудников с предлагаемыми решениями, определить и согласовать объем необходимых настроек, доработок и изменений. Команда внедрения со стороны лаборатории хотя и заинтересована в подробном ТЗ, но, во-первых, не обладает соответствующими знаниями и навыками (компетенциями), во вторых, не имеет полной информации о возможностях выбранной ЛИМС в настройке под нужды лаборатории. Поэтому есть вариант разделить работу над ТЗ на три этапа: 1) Лаборатория пишет ТЗ и передает поставщику ЛИМС; 2) Поставщик ЛИМС проводит обследование лаборатории по представленному ТЗ, выявляет нюансы конкретной лаборатории, знакомит сотрудников с ЛИМС, в ходе знакомства и обсуждения выявляются многие скрытые вопросы и проблемы в процессах; 3) Поставщик по итогам обследования составляет конечное подробное ТЗ и согласовывает с лабораторией. #внедрение #процессы