На демонстрации программы для лаборатории неразрушающего контроля всё выглядит просто: поступает заявка, создаётся задание, появляется заключение. После покупки выясняется, что лаборатория работает иначе. В заявке встречаются неполные обозначения, задания выполняются частями, документы возвращают на исправление. Эти ситуации не вошли в презентацию, поэтому команда снова ведёт параллельные таблицы.
До встречи с поставщиком полезно подготовить небольшой набор рабочих сценариев. Каждый должен начинаться с конкретных исходных данных и заканчиваться проверяемым результатом. Ниже — порядок подготовки такого задания для демонстрации. Он помогает сравнить программы по работе сотрудников и сохранности связей между записями.
Определите задачу программы и границы проверки
Запишите, где начинается и заканчивается процесс: например, получение заявки на контроль — передача согласованного комплекта документов заказчику. Затем перечислите действия, которые сегодня выполняются вне учётной системы: уточнение схемы по телефону, составление задания в редакторе, поиск оборудования в отдельном списке.
Выберите две-три проблемы с наблюдаемым результатом. «Нужна цифровизация» слишком широко. «При подготовке заключения специалист повторно вводит обозначения двадцати соединений» уже позволяет проверить улучшение. Не обещайте заранее убрать весь ручной ввод: часть сведений впервые появляется именно при выполнении работы.
ISO описывает назначение ISO/IEC 17025 через компетентность лаборатории и достоверность результатов. Наличие программы само по себе этого не подтверждает. Применимые требования, методы контроля, полномочия специалистов и порядок выпуска документов лаборатория определяет отдельно. Демонстрация проверяет организацию данных и действия пользователей.
Соберите небольшой, но показательный комплект
Подготовьте обезличенную заявку, фрагмент схемы с версией, перечень соединений, пример задания и комплект результата. Добавьте один проблемный случай: неверное обозначение, неполные исходные сведения или повторное обследование. Обезличивание должно сохранять связи: если заменить номер соединения, замените его во всех связанных примерах.
Укажите реальный масштаб: число пользователей одновременно, обычное количество заявок за смену, соединений в задании и файлов в комплекте. Среднее значение дополните пиковым. Программа, удобная для пяти строк, может потребовать другого сценария для нескольких сотен.
Согласуйте состав участников встречи. Координатор оценивает регистрацию, специалист — выполнение задания, проверяющий — комплект результата, руководитель — поиск незавершённых работ. Без будущих пользователей легко выбрать программу, которая хорошо выглядит только на экране руководителя.
Запишите требования через действие и результат
Для каждого требования используйте одинаковую структуру. Она отделяет обязательную задачу от пожелания к оформлению экрана.
- Код: НК-01.
- Пользователь: координатор контроля.
- Исходные данные: заявка З-042, четыре соединения, схема СХ-08 версии 2.
- Действие: создать два задания для разных исполнителей без повторного ввода обозначений.
- Ожидаемый результат: каждое задание связано с исходной заявкой; соединения не потеряны и не добавлены дважды.
- Проверка: открыть заявку, оба задания и карточку выбранного соединения; сравнить состав.
- Важность: обязательно для первого запуска.
- Доказательство: выполненный сценарий в демонстрационной среде и сохранённый пример результата.
Это учебный пример требования, а не обещание функции любого поставщика. В поле «доказательство» фиксируйте, что увидели: действие в работающей программе, описание будущей настройки или только устный ответ. Эти результаты имеют разную ценность для выбора.
Пройдите пять сценариев от заявки до архива
Сценарий 1. Принять заявку с неполными данными
Пусть у одного соединения отсутствует ссылка на актуальную схему. Покажите поставщику входящий комплект как есть. Попросите зарегистрировать обращение, отметить недостающие сведения и назначить ответственного за уточнение.
Проверьте, видно ли, почему работа ожидает уточнения, и можно ли продолжить после получения файла. Запись не должна выглядеть полностью готовой только потому, что пользователь заполнил обязательные поля случайными значениями. Правила готовности определяет ваша лаборатория.
Сценарий 2. Разделить работу между исполнителями
В учебной заявке четыре соединения: J-101, J-102, J-103 и J-104. Первое задание содержит J-101 и J-102, второе — J-103 и J-104. Исполнитель второго задания ещё не приступил к работе, тогда как по первому уже переданы материалы результата.
Попросите показать состояние каждого задания и исходной заявки. «Часть выполнена» должно отличаться от «вся заявка завершена». Отдельно проверьте, как пользователь видит основание назначения и связанные сведения о персонале и оборудовании. Технический выбор метода и допуск к работе не подменяются состоянием карточки.
Сценарий 3. Сохранить результат и замечание
Внесите заранее подготовленные демонстрационные данные и приложите файл. Затем попросите другого пользователя найти их через соединение, а не через известное имя файла. Это проверяет связь результата с объектом контроля.
Добавьте замечание к комплектности: в приложении указана другая версия схемы. Назначьте того, кто должен выяснить причину. Различайте такое расхождение и техническую оценку соединения: исправление реквизита не означает устранения дефекта или принятия работы.
Сценарий 4. Исправить запись и зарегистрировать повторное действие
После сохранения обнаружена опечатка в реквизите. Попросите показать исходное значение, исправление и основание изменения. Для уже выпущенного документа действуют согласованные лабораторией правила: кнопка редактирования не заменяет процедуру внесения изменений.
Затем создайте отдельное событие повторного контроля того же J-102. У соединения должен остаться прежний идентификатор, а у события — собственная запись и ссылка на основание. История первого действия сохраняется. Перезапись последнего результата поверх предыдущего делает восстановление последовательности ненадёжным.
Сценарий 5. Передать комплект и найти его позже
Сформируйте пример выдаваемого комплекта и откройте полученные файлы вне программы. Проверьте читаемость, состав, обозначения и версии. Уточните, какие действия означают подготовку, проверку и фактическую передачу заказчику.
После этого найдите документы по соединению и по заявке. Проверьте, сможет ли лаборатория получить свои записи и вложения при смене решения. Формат выгрузки, сохранение связей и порядок передачи архива нужно обсуждать до закупки.
Проверьте доступ, изменения и обмен
Попросите выполнить одно действие под разными ролями: например, просмотреть результат и попытаться изменить его. Проверяйте не только наличие настройки прав, но и фактическое поведение. Сформулируйте ожидаемые ограничения заранее, исходя из вашей ответственности и организационного порядка.
В руководстве Eurachem/CITAC, раздел 22 среди вопросов проверки лабораторных систем рассматриваются доступ, история изменений и целостность передачи данных. Руководство относится к аналитической химии; здесь эти вопросы служат инженерным ориентиром для демонстрации.
Если необходим импорт, передайте небольшой файл с повторяющейся строкой, пропуском и длинным обозначением. Проверьте, какие строки приняты, какие отклонены и как исправить ошибку. Не считайте фразу «обмен поддерживается» доказательством готового подключения к вашей системе. Общий подход к таким проверкам разобран в статье о надёжных интеграциях.
Сравните результаты по заранее выбранной шкале
Используйте простые отметки: «выполнено», «выполнено с ограничением», «требует настройки», «не показано». Для ограничения запишите влияние на работу и согласованный способ проверки. Количество красивых экранов в эту оценку не входит.
В условном сравнении поставщик А прошёл все пять сценариев, но показал выгрузку без вложений. Поставщик Б сохранил полный комплект, однако исправления потребовали отдельной настройки. Решение зависит от ваших обязательных условий и стоимости доведения; общий балл не должен скрывать критический пробел.
Перед следующим этапом убедитесь, что у каждого обязательного требования есть результат, открытые вопросы получили ответственного, а настройки отделены от разработки. Сохраните примеры и договорённости. После демонстрации нужен пилот на ограниченном объёме: презентационный успех ещё не доказывает работу в ваших условиях.
Что подготовить для разговора о Призме
В каталоге ExtentLab Призма описана как решение для управления НК: заявки и задания, сварные соединения и дефекты, квалификации и поверки оборудования, заключения и документы. Конкретные роли, формы, выгрузки и подключения стоит проверять по вашим сценариям.
Возьмите одну обычную заявку и один случай с исправлением. Если основная проблема — разрозненные документы, начните со схемы прослеживаемости контроля. Обсудите учёт контроля в Призме, чтобы согласовать, какую цепочку действий показать и по каким признакам оценивать результат.