У себя на канале я много пишу о разработке и внедрении документации систем менеджмента, а также улучшении работы систем менеджмента через автоматизацию. Одним из таких направлений сейчас является внедрение ИИ-помощников. Для средних и больших компаний можно создавать решение на базе ИИ в качестве универсального помощника в повседневных задачах, который разбирается во внутренних процессах и регламентах. На общедоступный портал компании или мобильное приложение выводится чат-бот с ИИ, который может быстро ответить на вопросы и/или предоставить ссылки на внутренние документы компании (регламенты, инструкции). Кроме очевидной пользы для всех сотрудников, которым трудно ориентироваться в многообразии внутренних документов, большую пользу такой ИИ принесет и тем, кто отвечает за разработку и внедрение регламентов и инструкций. Позволит выстраивать правильную систему без противоречий и с обновляемыми связями. Вот перечень систем, которые позволяют реализовать это на внутренних серверах компании или в облаке.
TEAMLY AI https://teamly.ru/ai Особенности: Один из лидеров на рынке. ИИ обучается исключительно на ваших данных (документы, таблицы) и не использует внешние источники, что минимизирует ошибки и гарантирует конфиденциальность. Отличается глубоким пониманием контекста диалога и строгой системой контроля доступа (сотрудник видит только ту информацию, к которой у него есть права). Безопасность: Данные хранятся на ваших серверах. Интеграции: Встраивается в корпоративные порталы, CRM, мессенджеры. Для кого: Универсальное решение для всех отделов: поддержка, HR, маркетинг, продажи, производство.
KT-Team (ИИ-ассистент для правил) https://www.kt-team.ru/solutions/ai-for-business/ai-corporate-rules-helper Особенности: Специализированный помощник для работы с огромными базами правил, регламентов и инструкций (от 100+ документов). Понимает запросы на естественном языке, даже если формулировка не точная. Идеален для обеспечения соблюдения внутренних стандартов. Плюсы: Автоматически актуализирует ответы при изменении регламентов и предоставляет модуль для тестирования знаний сотрудников. Для кого: Крупные компании с сильно регламентированными процессами (финансы, производство, строительство).
Ontoloo https://ontoloo.ru/ai-chat-bots Особенности: Платформа для создания разных типов ботов (корпоративный, продавец, поддержка). Использует векторные базы данных для интеллектуального поиска по всем корпоративным знаниям. Гибкость: Поддерживает различные LLM (ChatGPT, Gemini, Claude, YandexGPT) и развертывание на собственных серверах. Есть интеграция с Битрикс24. Для кого: Компании, которым важна гибкость выбора модели и многоканальность (веб-сайт, Telegram и др.).
Personik (для обучения и HR) https://personik.ai/solutions/learning Особенности: Сфокусирован на сценариях обучения и адаптации персонала. Позволяет легко создавать интерактивные курсы, тесты и квизы на основе загруженных материалов (инструкций, документации). Форматы: Диалоговые тренажеры, микро-обучение прямо в мессенджерах (Telegram, Viber). Для кого: В первую очередь для HR-департаментов и учебных центров.
Minerva Knowledge https://minervasoft.ru/kms Особенности: Профильный сервис для базы знаний с ИИ-инструментами. Входит в линейку продуктов Minerva, среди которых — Minerva Learn, решении для создания обучающих материалов, тестов и анализа результатов. Плюсы: Семантический поиск по всем типам контента выдает релевантную информацию из базы знаний. Доступна быстрая миграция из Confluence, Notion, Zendesk и других зарубежных систем. Поддерживает диаграммы из Draw.io и PlantUML, доски из Miro, видео с YouTube и другой контент из сторонних сервисов. Можно сделать внешний портал с базой знаний для клиентов и партнеров. Встроенный ИИ дает подсказки из базы знаний в CRM-системе и других программах. Есть мобильные приложения для iOS и Android. Доступно коробочное решение. Для кого: Для компаний, заинтересованных в внедрении универсальных решений. Подходит командам, где минимум 15 сотрудников — меньшее количество лицензий купить нельзя.
Я работаю системным и бизнес-аналитиком, но периодически вижу обсуждения, что аналитики не нужны, либо не нужны были изначально, потому что DDD и вот это всё, либо не нужны становятся сейчас из-за развития нейросетей и трансформации разработки. Однако на своем опыте я вывел несколько причин, почему аналитики всё таки нужны:
Разделение труда - системный и бизне-аналитик это результат разделения труда и специализации. Естественный процесс в любой деятельности, где работает больше трех человек.
Дешевая замена - аналитики в рамках выделения своей ролевой специфики часто выступают для сокращения затрат на разработчиков.
Тушитель пожаров - аналитики на проектах часто выступают в роли затыкателя дыр, выполняя все возможные временные функции от тестировщика до техписа.
Собиратели конструкторов - аналитики заменяют разработку в проектах с лоу-код и ноу-код конструкторами.
Вайб-кодеры - в настоящее время за счет нейросетей аналитик может самостоятельно тестировать идеи в коде и прототипах вообще без разработчиков. Далее рассмотрим подробнее.
1. Разделение труда - основа эффективности
Разработка ПО — уже давно не ремесло одного мастера, а командная работа множества специалистов. Разделение труда здесь не прихоть менеджмента, а необходимое условие масштабирования. Разработчик фокусируется на архитектуре и коде, тестировщик — на качестве, дизайнер — на опыте пользователя. А кто же будет отвечать за смысл? Именно аналитик переводит запросы бизнеса в технические требования. Он задаёт ключевые вопросы: — Какую проблему мы решаем? — Кто наш пользователь? — Как мы поймём, что решение работает? Аналитик создаёт общее понимание между заказчиком, который говорит «хочу одну кнопку», и разработчиком, который спрашивает: «А что именно делать?».
Это ведь не просто «бумажная работа» по записи требований. Это управление сложностью. И чем масштабнее проект, тем выше цена недопонимания. Ошибка в требованиях на раннем этапе может стоить десяток переделок в дальнейшем, поэтому работе аналитика следует уделять внимание.
2. Дешёвая замена - страховка от некомпететености
К целом аналитик на рынке стоит дешевле, чем программист. Конечно аналитик не замещает программистов, но позволяет им сконцентрироваться на написании кода, сократив время на созвоны с заказчиком и переведя эту работу на себя. К тому же, аналитики могут на ранних этапах предусмотреть какие-то проблемы в реализации требований, найти противоречия, а значит сократят время на споры и переделки. В этом случае, аналитик экономит не за счет зарплаты, а за счет повышения эффективности работы команды.
Более того, в продуктовых компаниях и на синьорном уровне разрыв в зарплатах уже сокращается. Потому что зрелый аналитик влияет на разработку не меньше программиста, и также приносит значительную ценность.
3. Тушитель пожаров и «универсальная затычка»
В идеальном мире каждая роль выполняет свои функции. В реальности — аналитик часто закрывает пробелы за других.
Руководитель проекта перегружен и не успевает расставить приоритеты? Аналитик делает это сам.
Тестировщики не понимают бизнес-логику? Аналитик пишет сценарии и проверяет функции ПО.
Технического писателя нет? Аналитик создаёт документацию, инструкции, да ещё и обучает пользователей.
Разработчик не хочет вникать в нюансы? Аналитик «додумывает» логику и исправляет требования постфактум.
На проекте нет специалистов технической поддержки? Аналитики будет принимать заявки от пользователей, консультировать их, либо передавать выявленные баги разработке.
Конечно это не совсем здоровые ситуации, но реальность такова. Сейчас во многих проектах программисты пишут код, а аналитики и с заказчиком общаются, и документы пишут и доработки тестируют.
4. Собиратели конструкторов - аналитик становится разработчиком
С приходом платформ вроде Bubble, Airtable, Power Apps, ELMA, Первая форма аналитик получил суперсилу: он может сам создавать рабочие решения без единой строчки кода. Теперь он не просто описывает форму для приложения — он может собрать её сам и она сразу будет работать, при это не требуется писать код. Я знаю, что на Хабре мало поклонников ноу-код, но тем не менее такие платформы используются, работают и выполняют свои функции. Если в компании внедряют какую-то лоу-код платформу, то ей нужны аналитики, которые будут там настраивать и править, сразу реализуя то, что нужно пользователям. Программисты в этом случае конечно тоже нужны, но только для написания плагинов, коннекторов, каких-то базовых функций и т.д. Здесь вот про это подробно описано https://habr.com/p/977318/ Это превращает аналитика в продуктового инженера одного лица: от идеи до MVP — за день. Но есть и риски. No-code — не панацея. Такие решения часто не масштабируются, сложны в поддержке и могут стать «цифровым мусором», если не продумана архитектура. Аналитик должен понимать границы возможностей платформ и вовремя передавать зрелые продукты в руки программистов то, что требует классической разработки через код.
5. Вайб-кодинг и ИИ: от ТЗ к архитектуре намерений
Самый мощный тренд 2024–2025 годов — вайб-кодинг (vibe coding): когда достаточно описать желаемое поведение на естественном языке, чтобы ИИ (GitHub Copilot, Cursor, V0, Lovable) сгенерировал рабочий интерфейс или даже full-stack приложение.
Это не отменяет аналитика — наоборот, делает его роль критичной. Теперь его главная задача — не писать многостраничные спецификации, а формулировать точные, структурированные промпты, которые ИИ поймёт без искажений. Аналитик становится валидатором намерений: он проверяет, правильно ли ИИ интерпретировал логику, учтены ли крайние случаи, не нарушена ли связность системы. Ещё важнее — фокус на гипотезах и метриках. Если реализация занимает минуты, то главный вопрос — не «как сделать», а «зачем и как измерить эффект». Аналитик переходит от описания функций к управлению бизнес-ценностью. То самое "сделать хорошо".
Выводы
Аналитик это необходимая во многих случаях роль (и должность) на проектах связанных с разработкой и внедрением ПО. Сейчас, в ряде случаев, это может быть единственная роль технического специалиста в команде. И эта роль будет долго существовать в том или ином смысле.
Очень часто, когда обсуждают подходы к проектированию и проектному управлению проводят аналогии со строительством или машиностроением. Не стала исключением и моя статья про аджайл https://pikabu.ru/story/mifyi_i_realnost_est_li_osnovanie_protivopostavlyat_agile_i_waterfall_13485192 Конечно всякие аналогии имеют свои границы применимости, но в случае сравнения строительства и разработки ПО об этой границе забывают. Между тем она есть и даже люди далекие и от первого и от второго быстро поймут эту разницу, если просто о ней написать. Основная разница заключается в сравнении стоимости проектирования и создания итогового продукта. Для сравнения я также решил привести пример из машиностроения с созданием серийного продукта. Имеются фундаментальные различия экономических моделей этих отраслей в аспекте тиражирования решений и распределения стоимости по этапам жизненного цикла. Для подкрепления мнения некими данными я попросил нейросеть Qwen набросать примерные оценки по стоимости.
Стоимостная характеристика трех отраслей: строительство, машиностроение, разработка ПО.
Строительство: много материальных затрат на этапе производства
В строительстве классическое распределение затрат выглядит так:
Проектирование: 5-10% от общей стоимости
Материалы: 50-60%
Строительно-монтажные работы: 30-40%
Пуско-наладка и сдача: 5-10%
Физическая реальность создает "точку невозврата". После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.
Машиностроение: баланс между разработкой и производством
Машиностроение занимает промежуточное положение:
НИОКР и проектирование: 20-30%
Создание прототипов и испытания: 15-25%
Освоение производства (оснастка, станки, линии): 30-40%
Серийное производство: 10-20% на единицу продукции
Здесь ключевой момент — амортизация разработки на количество единиц продукции. Чем больше тираж, тем ниже себестоимость единицы. Но первоначальные затраты на разработку и освоение производства огромны. Изменения после запуска серийного производства чрезвычайно затратны — часто проще разработать новую модель, чем модифицировать существующую линию.
IT-разработка: "бесплатное" тиражирование
В IT-разработке принципиально иное распределение:
Проектирование и анализ: 30-40%
Разработка: 40-50%
Тестирование и внедрение: 20-30%
Поддержка и развитие: 15-25% годовых от стоимости разработки
Самая революционная особенность IT — практически нулевая стоимость тиражирования. Разработка программного продукта может стоить миллион долларов, но выпуск миллиона копий обойдется в несколько рублей за штуку. Это создает уникальную экономическую модель, где можно позволить себе эксперименты и итерации.
Почему в IT можно начинать с весьма "сырого" продукта?
В машиностроении нельзя создать мотоцикл, а потом превратить его в автомобиль. Для этого потребуется полностью перепроектировать платформу, перенастроить производственные линии, переобучить персонал. Стоимость такой "эволюции" будет сравнима со стоимостью разработки нового автомобиля с нуля.
В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.
Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.
Это возможно благодаря:
Нулевой стоимости копирования - можно создать сотню экспериментальных версий без финансовых потерь
Модульной архитектуре - компоненты можно заменять независимо друг от друга
Быстрому циклу обратной связи - пользователи тестируют изменения в реальном времени
Стоимостные риски и их управление
Строительство: страхование через детализацию
В строительстве основной риск — физическая невозможность или чрезвычайная стоимость исправления ошибок. Поэтому:
80-90% рисков управляются на этапе проектирования
Используются детальные 3D-модели и BIM-технологии
Предусматриваются запасы прочности в конструкциях
Стоимость изменений после начала строительства кратно превышает стоимость проектирования
Кстати этап проектирования в строительстве сильно перекликается с разработкой ПО. На этом этапе можно всё менять и переделывать, при этом мы всё еще будем нести финансовые затраты гораздо меньше, чем сама стоимость строительства и стоимость отдельных изменений на этапе строительства. Конечно в строительстве есть примеры возведения серийных домов (хрущевки, панельки) с удешевлением производства, но в данном случае удешевление было не за счет единого проекта, а за счет использования типовых решений, которые можно изготавливать серийно, как и продукцию машиностроения.
Машиностроение: управление через прототипирование
В машиностроении риски распределены между разработкой и производством:
Создаются физические прототипы для проверки концепций
Проводятся ресурсные испытания в экстремальных условиях
Используются CAD/CAM системы для виртуального моделирования
Освоение производства идет поэтапно с постоянной доработкой
Стоимость ошибки, которая выявится после запуска серийного производства может достигать миллионов за простой и переналадку линии, поэтому инвестиции в тестирование и прототипирование оправданы. И бывает очень сложно вносить изменения в готовый продукт серийного производства, потому что изменения могут привести к необходимости полной переделке производственных циклов, а это уже затраты, сопоставимые с разработкой продукта с нуля.
Разработка ПО: управление через итерации
В программировании и разработке ПО риски управляются иначе:
Риск несоответствия требованиям минимизируется через постоянную обратную связь
Технические риски снижаются через рефакторинг и технический долг
Рыночные риски управляются через A/B тестирование и постепенный rollout
Безопасность обеспечивается через непрерывное тестирование и обновления
Стоимость ошибки в IT относительно невысока - можно быстро выпустить горячий фикс или откатиться к предыдущей версии. Это позволяет брать на себя больше рыночных рисков в обмен на возможность быстрого тестирования идей. При этом стоимость подробного проектирования будет не ниже, чем сама разработка, а в некоторых случаях без какого-то прототипа очень сложно определиться с треком дальнейшего развития.
Распределение стоимости по этапам
Практические примеры от нейросети Qwen
Строительство: Burj Khalifa Стоимость проектирования составила около $100 млн из общего бюджета $1.5 млрд. Изменения в процессе строительства были минимальны — любое отклонение от проекта могло привести к катастрофе. Тиражирование невозможно — это уникальный объект.
Машиностроение: Tesla Model 3 Разработка и освоение производства обошлись в $2+ млрд. Но при производстве 500,000 автомобилей в год себестоимость единицы становится конкурентоспособной. Изменения в процессе производства требуют остановки линий и перенастройки оборудования.
IT разработка: Facebook Начинался как простой сайт для студентов Гарварда. Стоимость тиражирования для миллиарда пользователей — доли цента на пользователя в месяц. Изменения вносятся ежедневно без остановки сервиса. Первоначальная разработка стоила тысяч долларов, текущая стоимость компании — сотни миллиардов.
Почему аналогии вредны в проектном управлении и как найти баланс
Следовательно сравнение разработки ПО со строительством некорректно именно из-за разного распределения затрат. Поэтому проектное управление в разработке ПО просто обязано опираться прежде всего на итерации и сбор обратной связи, а не на исходное ТЗ и проектные документы.
практические советы для IT проектов:
Архитектурный фундамент - закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857
Итеративное наполнение - добавляйте функции постепенно, получая обратную связь на каждом этапе. Первоначальный план при этом будет постоянно меняться, адаптироваться. Концентрируйтесь на важных и востребованных функциях.
Управление техническим долгом - регулярный рефакторинг - это инвестиция в будущую гибкость. При этом надо пересматривать не только код, но и документацию продукта.
Бесплатное тиражирование - используйте преимущество нулевой стоимости копирования для быстрого тестирования гипотез и масштабирования успешных решений.
Вывод
Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться. Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации - это самая эффективная модель разработки с экономической точки зрения.
В своей работе в качестве консультанта лабораторий по внедрению ЛИМС и системного аналитика часто сталкиваюсь с двумя понятиями: цифровизация и автоматизация. А недавно услышал интересное мнение, что цифровизация это не помощник, а надсмотрщик.
Конечно захотелось разобраться в чем разница и почему так происходит.
Путем недолгого запроса в нейросеть Qwen получил следующие определения: Цифровизация — это перевод процессов, данных или взаимодействий в цифровой формат. Это не замена человека машинами, а переход от аналоговых или бумажных систем к цифровым инструментам.
Автоматизация — это использование технологий для выполнения задач без человеческого вмешательства. Здесь речь идет о замене ручного труда машинами, программами или алгоритмами.
Получается, что цифровизация не обязательно включает автоматизацию, а автоматизация хоть сейчас часто использует цифровые технологии, но так было не всегда (например есть механические автоматические линии на производстве без компьютеров). Рассмотрим на примере производственных лабораторий, с которыми я работал.
Цифровизация бывает без автоматизации В лаборатории результаты измерений (испытаний) с приборов (СИ или ИО) вручную переписываются в программу LIMS.
Данные теперь в электронном виде (вместо бумажного журнала).
Но нет автоматизации. Прибор не передает данные автоматически — человек сам пишет цифры, и даже сам их пересчитывает по заданным в методике формулам.
Автоматизация без цифровизации (редкий случай в современности)
например механический автомат на конвейере.
но данных с него нет или требуется собирать вручную
Цифровизация + Автоматизация (идеальный сценарий) Датчики IoT на производственной линии автоматически передают данные в систему MES, которая: +Анализирует показания в реальном времени, +Сама останавливает линию при отклонениях,
Формирует отчеты для менеджеров. Таким образом, данные переведены в цифровой формат (выполнена цифровизация), и задачи выполняются без человека (существует автоматизация). Процесс становится эффективным — ошибки сократились, время трудозатрат уменьшилось.
Простой пример из работы маленькой лаборатории: Если вы просто перенесли бумажный журнал в Excel — это цифровизация. Если Excel сам считает по формулам и генерирует протокол — это автоматизация. Если вы сделали и то, и другое — это цифровизация с автоматизацией.
Сейчас конечно цифровизация — это база, а автоматизация — инструмент для улучшения этой базы. Без цифровизации в современном понимании автоматизация невозможна, но цифровизация сама по себе не гарантирует автоматизации. При этом зачастую цифровизацию внедряют именно так, без автоматизации, и конечным результатом становится не облегчение труда рядовых сотрудников, а облегчение **контроля за работой ** рядовых сотрудников через разные полуавтоматические отчеты по количеству сделанных записей.
Когда цифровизация используется не для упрощения работы, а для усиления контроля, она перестаёт быть инструментом прогресса и превращается в надсмотрщика над сотрудниками. Это происходит, когда данные собираются, анализируются и используются исключительно для мониторинга сотрудников, а не для улучшения их условий труда и, соответственно, производительности. Технологии становятся "глазами" менеджмента ("большого брата"), которые фиксируют каждое движение, но не помогают решать проблемы в организации.
Вот еще пример из нашей лабораторной жизни Часто компании внедряют ЛИМС, но не настраивают автоматизированную интеграцию с оборудованием, автоматический расчет результатов и так далее. В результате сотрудники вынуждены вручную вносить показания приборов, результаты испытаний или измерения в электронные формы в программе. При этом еще остаются бумажные формы записей, которые частично задублированы в электронные формы. Эта цифровизация преподносятся как автоматизация, но на практике усложняет работу, добавляя рутину, ошибки и потерю времени. Зачем так делают? Формальные причины: -Соответствие регуляторным стандартам
Внутренние требования руководства
Формальность «мы цифровизировались»
А на выходе отсутствие прибавки производительности труда, сопротивление сотрудников, выгорание и вот это всё
ЛИМС — это автоматизированная лабораторная система, которая собирает и обрабатывает (управляет) данные (ми). Некоторые считают, что ЛИМС это набор из электронных журналов, используемых Лабораторией, но настоящая ЛИМС это специализированная программа, которая служит для ведения учета, расчетов, отчетов, контроля и т. д.
ЛИМС это часть лабораторной деятельности
ЛИМС является системой, и как минимум объединяет в себе несколько журналов, позволяет использовать информацию из одних журналов в других, например использовать сведения об оборудовании в журнале по измерениям (испытаниям), или использовать сведения из журнала по отбору проб в журнале выдачи протоколов. За счёт объединения в одной системе нескольких журналов, справочников можно добиться новых свойств и функций ведения записей. Получается, что за счёт системности достигают эмерджментные свойства.
Функционал ЛИМС может покрывать все процессы в лаборатории
Одной из важных особенностей ЛИМС являются свойства управления записями, которые недоступны при использовании бумажных журналов. Как правило при внедрении ЛИМС у лаборатории возникают требования о необходимости соблюдения требований ГОСТ ISO/IEC 17025-2019 к ведению записей изложенных в п. 7.5 и п. 8.4. Понятно, что в ЛИМС должна быть возможность фиксации результатов, отслеживания изменений, запрет изменений, архивирование, резервное копирование. В той или иной форме все производители ЛИМС стремятся всё это реализовать. Конечно бывают не очень удобные и практичные формы реализации, но в любом случае можно запрограммировать, чтобы автоматически записывались дата, время внесения и изменения данных, пользователь и информация о нём. При этом пользователь не будет иметь возможность редактирования этой информации.
Но это всё в ЛИМС, а вот если задуматься, то становится понятно, что на бумаге этого не обеспечить.
Например, сотрудник может заполнить журнал с результатами не в момент проведения испытаний (измерений), а позже или даже в другой день, ведь информация о времени и дате вносится им же, если и вносится вообще.
Тоже самое касается изменений, всегда можно внести исправление и подписаться другой датой. Можно вообще целиком переписать лист измерений (первичный протокол) и даже журнал измерений. При необходимости можно и исправления в журнале внести любой датой.
Ведение записей на бумаге не обеспечивают выполнение требований к техническим записям и их изменению. Без полноценной ЛИМС реализовать все требования к техническим записям не получится
Практика показывает, что лабораториям трудно успешно внедрить ЛИМС. Основные ошибки при внедрении ЛИМС не сильно отличаются от ошибок внедрения других информационных систем:
Отсутствие внятного технического задания на внедрение. Как правило при внедрении ЛИМС лаборатория берёт техническое задание поставщика. Понятно, что ту часть, которая о функциях и возможностях программы, менять после выбора конкретной программы не стоит, но есть ещё часть технического задания, которая касается внедрения. И вот к этому разделу ТЗ необходимо уделить как можно больше внимания;
Лаборатория тащит в ЛИМС все свои печатные/рукописные формы ведения записей. Ну здесь наверно пояснять не надо. Если вы переходите на электронные записи, то надо отказываться от старых бумажных. Возможно они были вами оптимизированы и удобны в заполнении, но в программе однозначно всё будет не так. Не стоит держаться за свои сдвоенные и строенные таблицы;
Процессы, которые лаборатория хочет автоматизировать, в системе менеджмента прописаны не чётко, есть неясности и не точности в описаниях, не приписано поведение сотрудника при выборе альтернативных вариантов. Процесс не является "прозрачным". Об этом можно говорить долго, и это тема вообще отдельно должна рассматриваться. Разработчик и внедренец ЛИМС часто сталкивается с тем, что лаборатория вроде как документировала процессы, прописала формы записей. Но по факту присутствуют не документированные записи, и поведение сотрудника при возникновении альтернативных вариантов не всегда прописано. То есть какие-то действия происходят, но происходят они по привычке или потому что руководитель сказал сделать так, а в СМ(К) это не включали. Вот простой пример - "процесс регистрации пробы". Казалось бы зарегистрировать пробу это очень просто, и весь процесс описывается двумя предложениями. "Сотрудник принимающий пробу вписывает информацию в журнал (приложение 1). Номер присваивается по порядку в журнале." Но здесь кроются разные нюансы. Например лаборатории могут использовать специфическую кодификацию/нумерацию проб, иметь несколько журналов регистрации, каждый под свой вид проб (скажем по объектам, по государственному заданию и отдельно платные), по подразделениям также могут делить, да и состав вносимой информации может сильно отличаться. Дополнительно сотрудник может делать приписки в журнале между строк с какой-то ещё информацией о пробе (например указывать состояние пробы или примечание к отбору проб);
Разновидностью третьей ошибки является и не совсем правильное выполнение методик. Если ЛИМС предполагает, что будут вестись записи и расчёты по методикам, то необходимо очень хорошо прописать последовательность действий персонала по внесению этих записей и хорошо проанализировать формулы расчёты. К сожалению встречается в практике недопонимание методик персоналом, а потом это всё ещё тащится и закрепляется в ЛИМС;
Серьёзной ошибкой лаборатории является неготовность переделывать документацию СМ(К) под ЛИМС. Внедрение ЛИМС в любом случае меняет процессы в лаборатории и это всё должно быть отражено в документации СМ(К). К сожалению и со стороны разработчиков ЛИМС не всегда есть люди, хорошо разбирающиеся в этом;
Лаборатория не готова проводить валидацию ЛИМС. Валидация подобного ПО фактически является обязательной, так же как валидация расчётов в электронных таблицах. Лаборатории стараются получить подтверждение от разработчиков, но ведь в процессе внедрения вносятся множество изменений и продукт, установленный у одного заказчика, может сильно отличаться от продукта у другого заказчика. Конечно поставщики ЛИМС предъявляют какие-то сертификаты на своё ПО. Но подобная сертификация у нас в стране не регулируется и такие сертификаты выдают не аккредитованные органы, что нарушает закон о техническом регулировании (184-ФЗ), и следовательно никакой силы такие красивые бумажки не имеют.
Лаборатория со своей стороны не сформировала группу ответственных за внедрения. Ну эта ошибка везде присутствует. С одной стороны у разработчика должна быть команда внедрения с руководителем проекта внедрения, а с другой стороны лаборатория тоже должна иметь ответственных людей, которые обязуются довести это внедрение до конца. Уполномочить ответственных можно приказом или каким-то ещё способом, принятым в организации. Естественно, что ответственный за внедрение должен обладать необходимыми полномочиями, чтобы менять документы СМ, составлять ТЗ, планировать валидацию и т. д.;
Ну и последняя ошибка - это отсутствие целеполагания во внедрении. Нельзя правильно внедрить то, что не известно зачем внедряется. Бывает что высшее руководство принимает такое решение, потому что у других есть или какой-то регулятор требует, но не ставит правильных целей. Такое внедрение ради внедрения никому не нужно и как правило проваливается.
Если мы внедряем что-то новое в лаборатории, да и в любой деятельности, необходимо сначала поставить ЦЕЛЬ. При чем само по себе внедрение нового целью не является. Цель должна быть описана и визуализирована. Если цель можно описать и визуализировать, то она реальна и достижима.
Какие же цели может ставить себе лаборатория?
Автоматически выдавать протоколы испытаний для уменьшения ошибок и человеческого фактора.
Автоматически принимать заявки и пробы, чтобы легче было отслеживать и контролировать движение проб и сроки проведения работ.
Получать точные и подробные отчёты по работе лаборатории без запроса.
Избавиться от использования (заполнения) рукописных форм.
Ускорить работу лаборатории (хотя такую цель надо ставить с осторожностью).
Можно выбрать несколько непротиворечивых целей, для каждой определить критерий достижения. Например цель по формированию отчётов будет достигнута, если можно будет сформировать целевой отчёт за шесть месяцев работы.
Критерии достижения целей необходимо прописывать для каждой цели, в общем то это является частью визуализации. Критерии позволяют нам сосредоточить внимание и обозначить границы, после прохождения которой можно считать проект внедрения завершённым.
Если в организации используют какие-то системы скоринга или KPI при премировании, то критерии достижения целей позволяют мотивировать ответственных за внедрение. Команда по внедрению должна собираться на этапе целеполагания, поскольку именно от целей зависит состав этой команды. В процессе формирования команды могут появиться и дополнительные цели и критерии их достижения.
Цель руководства, как правило, заключается в повышении контроля за работой сотрудников, автоматизации отчетов, снижении ошибок. А цель сотрудников - автоматизация своей работы, упрощение рутинных операций. Необходимо, чтобы руководство и сотрудники имело мотивацию, чтобы ЛИМС решала какие-то их серьезные проблемы, тогда внедрение возможно будет успешным.
Когда Руководство лаборатории определилось с целью и визуализировало её, необходимо сформировать команду ответственных за внедрение. В эту команду должны входить руководитель лаборатории, руководители отделов, менеджер по качеству, ключевые сотрудники - владельцы процессов. Желательно, чтобы размер команды не превышал 5-7 человек, иначе им будет трудно между собой договариваться.
На команду ложится тяжкое бремя:
1. Описание функциональных требований к ЛИМС;
2. Знакомство и выбор продукта из имеющихся на рынке;
3. Составление ТЗ на внедрение в соответствии с функциональными требованиями лаборатории и возможностями выбранного ЛИМС;
4. Согласование плана внедрения, представленного поставщиком ЛИМС;
5. Контроль процесса внедрения, общение с командой внедрения со стороны поставщика, уточнение требований, проверки ЛИМС и описание ошибок;
6. Валидация ЛИМС после внедрения.
Работы по внедрению могут растянуться на довольно долгий срок и состоят из многих этапов, поэтому команда должна периодически собираться и обсуждать текущий статус по внедрению, проблемные моменты, что еще нужно сделать на текущем этапе, согласовать какие-то изменения и доработки.
Выбрав какой-то ЛИМС их имеющихся на рынке или приняв решение разработать свое, каждая команда по внедрению сталкивается с проблемой написания ТЗ. Если выбран коммерческий вариант, то, как правило, фирма-поставщик ПО предоставляет своё ТЗ, слегка модифицированное согласно переданным ФТ. Не стоит ожидать там какой-то детализации планируемых решений. Всё будет описано общими обтекаемыми фразами, основной упор будет сделан на какие-то технические моменты (например используемый сервер базы данных). Для поставщика ПО основная проблема заключается в том, что для составления подробного ТЗ необходимо обследовать процессы лаборатории, ознакомить сотрудников с предлагаемыми решениями, определить и согласовать объем необходимых настроек, доработок и изменений. Это занимает довольно много времени, и поставщику ПО нет смысла этим заниматься до заключения контракта. Команда внедрения хотя и заинтересована в подробном ТЗ, но, во-первых, не обладает соответствующими знаниями и навыками (компетенциями), во вторых, не имеет полной информации о возможностях выбранной ЛИМС в настройке под нужды лаборатории, в-третьих, зачастую имеет неполное представление о процессах лаборатории из-за их непрозрачности, не ясности в описании, безальтернативности. Про проблему с прозрачностью процессов, я писал еще в начале. Нельзя написать хорошее ТЗ, если процессы "непрозрачные". Необходимо сначала внести в ясность в описание процессов, определить уровень детализации и т.д.
Про процессы можно долго говорить, но в целом понятно, что если лаборатория не может описать свои процессы, то при внедрении ЛИМС столкнется с проблемами.
Поэтому есть вариант разделить работу над ТЗ на три этапа:
1) Лаборатория пишет ТЗ и передает поставщику ЛИМС;
2) Поставщик ЛИМС проводит обследование лаборатории по ТЗ, выявляет нюансы
конкретной лаборатории, знакомит сотрудников с ЛИМС, в ходе знакомства и обсуждения выявляются многие скрытые вопросы и проблемы в процессах;
3) Поставщик по итогам обследования составляет конечное подробное ТЗ и согласовывает с
лабораторией.
Для поставщиков ЛИМС имеет смысл включать этап обследования в этапы по контракту и прописывать, что по итогам обследования будет уточнен перечень методик, журналов, форм и отчётов, которые будут внедрены в лаборатории (настроены поставщиком в ЛИМС). Некоторые формы и отчёты лаборатории можно в этот период изменить, если непосредственно в том же виде реализовать в ЛИМС не получится.
Документация по внедрению (базовый перечень):
Цель и функциональные требования — внутренний документ;
Техническое задание — внутренний документ и/или приложение к договору (контракту);
Договор, контракт, соглашение или иной документ с поставщиком (подрядчиком);
План работ, согласованный с поставщиком, приказ о закреплении ответственного со стороны лаборатории;
Акты, протоколы приема-передачи ЛИМС, запуска тестовой эксплуатации, приказ о закреплении ответственного (ых);
Журнал или протокол тестовой эксплуатации (ТЭ);
Акт или протокол передачи в опытно-промышленную эксплуатацию (ОПЭ), приказ о закреплении ответственного (ых);
План валидации, протоколы валидации, отчет о валидации;
Акт завершения ОПЭ;
Приказ о запуске в промышленную эксплуатацию.
Часть этих документов подготовит сам поставщик, но необходимо принимать в этом самое деятельное участие. Продвинутые поставщики ЛИМС могут предоставить документацию по ГОСТам серии 19 и 34, но строго говоря, для лабораторий это не обязательно. Следует следить за соблюдением формальных сроков и их переносом при необходимости. Документация по внедрению должна остаться в лаборатории для того, чтобы потом можно было к ней обратиться при проведении изменений, доработок и ревалидации ЛИМС. Также эта документация может понадобиться при аккредитации или очередном подтверждении компетентности, поскольку эксперты по аккредитации могут её запросить. До завершения внедрения (или в момент завершения) необходимо также издать новые документы (процедуры) СМ(К), в которых будет описана работа сотрудников лаборатории в ЛИМС.
Очень часто задают вопрос: «Почему же так сложно (дорого) автоматизировать процессы в лаборатории?»
Ответ тут на самом деле очень простой. В отличии от других сфер деятельности (бухгалтерия, кадры, производство), у лаборатории много процессов. Даже не так — очень много процессов. Во многих случаях каждый метод испытаний это отдельный процесс, в том числе с ветвлениями и циклами. А еще в каждой лаборатории даже одинаковые вроде бы процессы реализуются по своему, и какого‑то универсального решения тут нет. Поэтому нормальная автоматизация в виде внедрения программы, которая настраивается под все процессы, становится очень дорогой. Ну и понятно, что для быстрой реализации расчетов по различным методикам измерений и испытаний так или иначе необходимо использование каких‑то лоу‑код инструментов. Поэтому самый лучшей реализацией ЛИМС будет приложение‑конструктор с элементами ноу‑кода и лоу‑кода.
Но к сожалению не все разработчики подобных программ это понимают и продолжают следовать парадигме классической разработки
ЛИМС — это автоматизированная лабораторная система, которая собирает и обрабатывает (управляет) данные (ми). Некоторые считают, что ЛИМС это набор из электронных журналов, используемых Лабораторией, но настоящая ЛИМС это специализированная программа, которая служит для ведения учета, расчетов, отчетов, контроля и т. д.
ЛИМС это часть лабораторной деятельности
ЛИМС является системой, и как минимум объединяет в себе несколько журналов, позволяет использовать информацию из одних журналов в других, например использовать сведения об оборудовании в журнале по измерениям (испытаниям), или использовать сведения из журнала по отбору проб в журнале выдачи протоколов. За счёт объединения в одной системе нескольких журналов, справочников можно добиться новых свойств и функций ведения записей. Получается, что за счёт системности достигают эмерджментные свойства.
Функционал ЛИМС может покрывать все процессы в лаборатории
Одной из важных особенностей ЛИМС являются свойства управления записями, которые недоступны при использовании бумажных журналов. Как правило при внедрении ЛИМС у лаборатории возникают требования о необходимости соблюдения требований ГОСТ ISO/IEC 17025-2019 к ведению записей изложенных в п. 7.5 и п. 8.4. Понятно, что в ЛИМС должна быть возможность фиксации результатов, отслеживания изменений, запрет изменений, архивирование, резервное копирование. В той или иной форме все производители ЛИМС стремятся всё это реализовать. Конечно бывают не очень удобные и практичные формы реализации, но в любом случае можно запрограммировать, чтобы автоматически записывались дата, время внесения и изменения данных, пользователь и информация о нём. При этом пользователь не будет иметь возможность редактирования этой информации.
Но это всё в ЛИМС, а вот если задуматься, то становится понятно, что на бумаге этого не обеспечить.
Например, сотрудник может заполнить журнал с результатами не в момент проведения испытаний (измерений), а позже или даже в другой день, ведь информация о времени и дате вносится им же, если и вносится вообще.
Тоже самое касается изменений, всегда можно внести исправление и подписаться другой датой. Можно вообще целиком переписать лист измерений (первичный протокол) и даже журнал измерений. При необходимости можно и исправления в журнале внести любой датой.
Ведение записей на бумаге не обеспечивают выполнение требований к техническим записям и их изменению. Без полноценной ЛИМС реализовать все требования к техническим записям не получится
Практика показывает, что лабораториям трудно успешно внедрить ЛИМС. Основные ошибки при внедрении ЛИМС не сильно отличаются от ошибок внедрения других информационных систем:
Отсутствие внятного технического задания на внедрение. Как правило при внедрении ЛИМС лаборатория берёт техническое задание поставщика. Понятно, что ту часть, которая о функциях и возможностях программы, менять после выбора конкретной программы не стоит, но есть ещё часть технического задания, которая касается внедрения. И вот к этому разделу ТЗ необходимо уделить как можно больше внимания;
Лаборатория тащит в ЛИМС все свои печатные/рукописные формы ведения записей. Ну здесь наверно пояснять не надо. Если вы переходите на электронные записи, то надо отказываться от старых бумажных. Возможно они были вами оптимизированы и удобны в заполнении, но в программе однозначно всё будет не так. Не стоит держаться за свои сдвоенные и строенные таблицы;
Процессы, которые лаборатория хочет автоматизировать, в системе менеджмента прописаны не чётко, есть неясности и не точности в описаниях, не приписано поведение сотрудника при выборе альтернативных вариантов. Процесс не является "прозрачным". Об этом можно говорить долго, и это тема вообще отдельно должна рассматриваться. Разработчик и внедренец ЛИМС часто сталкивается с тем, что лаборатория вроде как документировала процессы, прописала формы записей. Но по факту присутствуют не документированные записи, и поведение сотрудника при возникновении альтернативных вариантов не всегда прописано. То есть какие-то действия происходят, но происходят они по привычке или потому что руководитель сказал сделать так, а в СМ(К) это не включали. Вот простой пример - "процесс регистрации пробы". Казалось бы зарегистрировать пробу это очень просто, и весь процесс описывается двумя предложениями. "Сотрудник принимающий пробу вписывает информацию в журнал (приложение 1). Номер присваивается по порядку в журнале." Но здесь кроются разные нюансы. Например лаборатории могут использовать специфическую кодификацию/нумерацию проб, иметь несколько журналов регистрации, каждый под свой вид проб (скажем по объектам, по государственному заданию и отдельно платные), по подразделениям также могут делить, да и состав вносимой информации может сильно отличаться. Дополнительно сотрудник может делать приписки в журнале между строк с какой-то ещё информацией о пробе (например указывать состояние пробы или примечание к отбору проб);
Разновидностью третьей ошибки является и не совсем правильное выполнение методик. Если ЛИМС предполагает, что будут вестись записи и расчёты по методикам, то необходимо очень хорошо прописать последовательность действий персонала по внесению этих записей и хорошо проанализировать формулы расчёты. К сожалению встречается в практике недопонимание методик персоналом, а потом это всё ещё тащится и закрепляется в ЛИМС;
Серьёзной ошибкой лаборатории является неготовность переделывать документацию СМ(К) под ЛИМС. Внедрение ЛИМС в любом случае меняет процессы в лаборатории и это всё должно быть отражено в документации СМ(К). К сожалению и со стороны разработчиков ЛИМС не всегда есть люди, хорошо разбирающиеся в этом;
Лаборатория не готова проводить валидацию ЛИМС. Валидация подобного ПО фактически является обязательной, так же как валидация расчётов в электронных таблицах. Лаборатории стараются получить подтверждение от разработчиков, но ведь в процессе внедрения вносятся множество изменений и продукт, установленный у одного заказчика, может сильно отличаться от продукта у другого заказчика. Конечно поставщики ЛИМС предъявляют какие-то сертификаты на своё ПО. Но подобная сертификация у нас в стране не регулируется и такие сертификаты выдают не аккредитованные органы, что нарушает закон о техническом регулировании (184-ФЗ), и следовательно никакой силы такие красивые бумажки не имеют.
Лаборатория со своей стороны не сформировала группу ответственных за внедрения. Ну эта ошибка везде присутствует. С одной стороны у разработчика должна быть команда внедрения с руководителем проекта внедрения, а с другой стороны лаборатория тоже должна иметь ответственных людей, которые обязуются довести это внедрение до конца. Уполномочить ответственных можно приказом или каким-то ещё способом, принятым в организации. Естественно, что ответственный за внедрение должен обладать необходимыми полномочиями, чтобы менять документы СМ, составлять ТЗ, планировать валидацию и т. д.;
Ну и последняя ошибка - это отсутствие целеполагания во внедрении. Нельзя правильно внедрить то, что не известно зачем внедряется. Бывает что высшее руководство принимает такое решение, потому что у других есть или какой-то регулятор требует, но не ставит правильных целей. Такое внедрение ради внедрения никому не нужно и как правило проваливается.
Если мы внедряем что-то новое в лаборатории, да и в любой деятельности, необходимо сначала поставить ЦЕЛЬ. При чем само по себе внедрение нового целью не является. Цель должна быть описана и визуализирована. Если цель можно описать и визуализировать, то она реальна и достижима.
Какие же цели может ставить себе лаборатория?
Автоматически выдавать протоколы испытаний для уменьшения ошибок и человеческого фактора.
Автоматически принимать заявки и пробы, чтобы легче было отслеживать и контролировать движение проб и сроки проведения работ.
Получать точные и подробные отчёты по работе лаборатории без запроса.
Избавиться от использования (заполнения) рукописных форм.
Ускорить работу лаборатории (хотя такую цель надо ставить с осторожностью).
Можно выбрать несколько непротиворечивых целей, для каждой определить критерий достижения. Например цель по формированию отчётов будет достигнута, если можно будет сформировать целевой отчёт за шесть месяцев работы.
Критерии достижения целей необходимо прописывать для каждой цели, в общем то это является частью визуализации. Критерии позволяют нам сосредоточить внимание и обозначить границы, после прохождения которой можно считать проект внедрения завершённым.
Если в организации используют какие-то системы скоринга или KPI при премировании, то критерии достижения целей позволяют мотивировать ответственных за внедрение. Команда по внедрению должна собираться на этапе целеполагания, поскольку именно от целей зависит состав этой команды. В процессе формирования команды могут появиться и дополнительные цели и критерии их достижения.
Цель руководства, как правило, заключается в повышении контроля за работой сотрудников, автоматизации отчетов, снижении ошибок. А цель сотрудников - автоматизация своей работы, упрощение рутинных операций. Необходимо, чтобы руководство и сотрудники имело мотивацию, чтобы ЛИМС решала какие-то их серьезные проблемы, тогда внедрение возможно будет успешным.
Когда Руководство лаборатории определилось с целью и визуализировало её, необходимо сформировать команду ответственных за внедрение. В эту команду должны входить руководитель лаборатории, руководители отделов, менеджер по качеству, ключевые сотрудники - владельцы процессов. Желательно, чтобы размер команды не превышал 5-7 человек, иначе им будет трудно между собой договариваться.
На команду ложится тяжкое бремя:
1. Описание функциональных требований к ЛИМС;
2. Знакомство и выбор продукта из имеющихся на рынке;
3. Составление ТЗ на внедрение в соответствии с функциональными требованиями лаборатории и возможностями выбранного ЛИМС;
4. Согласование плана внедрения, представленного поставщиком ЛИМС;
5. Контроль процесса внедрения, общение с командой внедрения со стороны поставщика, уточнение требований, проверки ЛИМС и описание ошибок;
6. Валидация ЛИМС после внедрения.
Работы по внедрению могут растянуться на довольно долгий срок и состоят из многих этапов, поэтому команда должна периодически собираться и обсуждать текущий статус по внедрению, проблемные моменты, что еще нужно сделать на текущем этапе, согласовать какие-то изменения и доработки.
Выбрав какой-то ЛИМС их имеющихся на рынке или приняв решение разработать свое, каждая команда по внедрению сталкивается с проблемой написания ТЗ. Если выбран коммерческий вариант, то, как правило, фирма-поставщик ПО предоставляет своё ТЗ, слегка модифицированное согласно переданным ФТ. Не стоит ожидать там какой-то детализации планируемых решений. Всё будет описано общими обтекаемыми фразами, основной упор будет сделан на какие-то технические моменты (например используемый сервер базы данных). Для поставщика ПО основная проблема заключается в том, что для составления подробного ТЗ необходимо обследовать процессы лаборатории, ознакомить сотрудников с предлагаемыми решениями, определить и согласовать объем необходимых настроек, доработок и изменений. Это занимает довольно много времени, и поставщику ПО нет смысла этим заниматься до заключения контракта. Команда внедрения хотя и заинтересована в подробном ТЗ, но, во-первых, не обладает соответствующими знаниями и навыками (компетенциями), во вторых, не имеет полной информации о возможностях выбранной ЛИМС в настройке под нужды лаборатории, в-третьих, зачастую имеет неполное представление о процессах лаборатории из-за их непрозрачности, не ясности в описании, безальтернативности. Про проблему с прозрачностью процессов, я писал еще в начале. Нельзя написать хорошее ТЗ, если процессы "непрозрачные". Необходимо сначала внести в ясность в описание процессов, определить уровень детализации и т.д.
Про процессы можно долго говорить, но в целом понятно, что если лаборатория не может описать свои процессы, то при внедрении ЛИМС столкнется с проблемами.
Поэтому есть вариант разделить работу над ТЗ на три этапа:
1) Лаборатория пишет ТЗ и передает поставщику ЛИМС;
2) Поставщик ЛИМС проводит обследование лаборатории по ТЗ, выявляет нюансы
конкретной лаборатории, знакомит сотрудников с ЛИМС, в ходе знакомства и обсуждения выявляются многие скрытые вопросы и проблемы в процессах;
3) Поставщик по итогам обследования составляет конечное подробное ТЗ и согласовывает с
лабораторией.
Для поставщиков ЛИМС имеет смысл включать этап обследования в этапы по контракту и прописывать, что по итогам обследования будет уточнен перечень методик, журналов, форм и отчётов, которые будут внедрены в лаборатории (настроены поставщиком в ЛИМС). Некоторые формы и отчёты лаборатории можно в этот период изменить, если непосредственно в том же виде реализовать в ЛИМС не получится.
Документация по внедрению (базовый перечень):
Цель и функциональные требования — внутренний документ;
Техническое задание — внутренний документ и/или приложение к договору (контракту);
Договор, контракт, соглашение или иной документ с поставщиком (подрядчиком);
План работ, согласованный с поставщиком, приказ о закреплении ответственного со стороны лаборатории;
Акты, протоколы приема-передачи ЛИМС, запуска тестовой эксплуатации, приказ о закреплении ответственного (ых);
Журнал или протокол тестовой эксплуатации (ТЭ);
Акт или протокол передачи в опытно-промышленную эксплуатацию (ОПЭ), приказ о закреплении ответственного (ых);
План валидации, протоколы валидации, отчет о валидации;
Акт завершения ОПЭ;
Приказ о запуске в промышленную эксплуатацию.
Часть этих документов подготовит сам поставщик, но необходимо принимать в этом самое деятельное участие. Продвинутые поставщики ЛИМС могут предоставить документацию по ГОСТам серии 34, но строго говоря, для лабораторий это не обязательно. Следует следить за соблюдением формальных сроков и их переносом при необходимости. Документация по внедрению должна остаться в лаборатории для того, чтобы потом можно было к ней обратиться при проведении изменений, доработок и ревалидации ЛИМС. Также эта документация может понадобиться при аккредитации или очередном подтверждении компетентности, поскольку эксперты по аккредитации могут её запросить. До завершения внедрения (или в момент завершения) необходимо также издать новые документы (процедуры) СМ(К), в которых будет описана работа сотрудников лаборатории в ЛИМС.
Очень часто задают вопрос: «Почему же так сложно (дорого) автоматизировать процессы в лаборатории?»
Ответ тут на самом деле очень простой. В отличии от других сфер деятельности (бухгалтерия, кадры, производство), у лаборатории много процессов. Даже не так — очень много процессов. Во многих случаях каждый метод испытаний это отдельный процесс, в том числе с ветвлениями и циклами. А еще в каждой лаборатории даже одинаковые вроде бы процессы реализуются по своему, и какого‑то универсального решения тут нет. Поэтому нормальная автоматизация в виде внедрения программы, которая настраивается под все процессы, становится очень дорогой. Ну и понятно, что для быстрой реализации расчетов по различным методикам измерений и испытаний так или иначе необходимо использование каких‑то лоу‑код инструментов. Поэтому самый лучшей реализацией ЛИМС будет приложение‑конструктор с элементами ноу‑кода и лоу‑кода.
Но к сожалению не все разработчики подобных программ это понимают и продолжают следовать парадигме классической разработки
Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья с Хабра и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Кажется, что waterfall (каскад) это старая и неповоротливая система
Agile — это ценности, а не методология
Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.
Если коротко, то Аджайл - это крик души замученного разработчика
Waterfall: миф о жестком подходе
Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.
Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:
Техническое задание
Эскизный проект
Технический проект
Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)
Внедрение (Подготовка и передача программы)
Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:
Устранение ошибок.
Развитие и усовершенствование продукта.
Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.
Ведь в Каскаде обратная связь не запрещена, просто требуется документирование
Почему возникает миф о несовместимости?
Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».
Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут: - Давайте заново начнем.
Однако в реальности:
Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками. Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum. Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.
Кажется, что это разные подходы, но это не так
Синтез вместо конфронтации: гибридные подходы
На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например: Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.
Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.
Например работа по непосредственной разработке ПО может идти итеративно, спринтами
Как же выбирать методологию? Нужно опираться на критерии, а не догмы Выбор между Waterfall и итерационными методами зависит от четырёх факторов:
Предсказуемость требований. Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.
Стоимость изменений. В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.
Регуляторные ограничения. В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Культура команды и заказчика. Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.
Выбор методологии зависит от многих вводных. Но нужно понимать плюсы и минусы каждой.
Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum
Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:
Какова степень неопределённости требований?
Какие ограничения накладывают регуляторы или бюджет?
Насколько команда и заказчик готовы к гибкости?
Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:
Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».
Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).
Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.
Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.
