ЛИМС является системой, и как минимум объединяет в себе несколько журналов, позволяет использовать информацию из одних журналов в других, например использовать сведения об оборудовании в журнале по измерениям (испытаниям), или использовать сведения из журнала по отбору проб в журнале выдачи протоколов. За счёт объединения в одной системе нескольких журналов, справочников можно добиться новых свойств и функций ведения записей. Получается, что за счёт системности достигают эмерджментные свойства.

Одной из важных особенностей ЛИМС являются свойства управления записями, которые недоступны при использовании бумажных журналов. Как правило при внедрении ЛИМС у лаборатории возникают требования о необходимости соблюдения требований ГОСТ ISO/IEC 17025-2019 к ведению записей изложенных в п. 7.5 и п. 8.4. Понятно, что в ЛИМС должна быть возможность фиксации результатов, отслеживания изменений, запрет изменений, архивирование, резервное копирование. В той или иной форме все производители ЛИМС стремятся всё это реализовать. Конечно бывают не очень удобные и практичные формы реализации, но в любом случае можно запрограммировать, чтобы автоматически записывались дата, время внесения и изменения данных, пользователь и информация о нём. При этом пользователь не будет иметь возможность редактирования этой информации.

Но это всё в ЛИМС, а вот если задуматься, то становится понятно, что на бумаге этого не обеспечить.

Например, сотрудник может заполнить журнал с результатами не в момент проведения испытаний (измерений), а позже или даже в другой день, ведь информация о времени и дате вносится им же, если и вносится вообще.

Тоже самое касается изменений, всегда можно внести исправление и подписаться другой датой. Можно вообще целиком переписать лист измерений (первичный протокол) и даже журнал измерений. При необходимости можно и исправления в журнале внести любой датой.

Ведение записей на бумаге не обеспечивают выполнение требований к техническим записям и их изменению. Без полноценной ЛИМС реализовать все требования к техническим записям не получится

Практика показывает, что лабораториям трудно успешно внедрить ЛИМС. Основные ошибки при внедрении ЛИМС не сильно отличаются от ошибок внедрения других информационных систем:

1. Отсутствие внятного технического задания на внедрение. Как правило при внедрении ЛИМС лаборатория берёт техническое задание поставщика. Понятно, что ту часть, которая о функциях и возможностях программы, менять после выбора конкретной программы не стоит, но есть ещё часть технического задания, которая касается внедрения. И вот к этому разделу ТЗ необходимо уделить как можно больше внимания;

2. Лаборатория тащит в ЛИМС все свои печатные/рукописные формы ведения записей. Ну здесь наверно пояснять не надо. Если вы переходите на электронные записи, то надо отказываться от старых бумажных. Возможно они были вами оптимизированы и удобны в заполнении, но в программе однозначно всё будет не так. Не стоит держаться за свои сдвоенные и строенные таблицы;

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

4. Разновидностью третьей ошибки является и не совсем правильное выполнение методик. Если ЛИМС предполагает, что будут вестись записи и расчёты по методикам, то необходимо очень хорошо прописать последовательность действий персонала по внесению этих записей и хорошо проанализировать формулы расчёты. К сожалению встречается в практике недопонимание методик персоналом, а потом это всё ещё тащится и закрепляется в ЛИМС;

5. Серьёзной ошибкой лаборатории является неготовность переделывать документацию СМ(К) под ЛИМС. Внедрение ЛИМС в любом случае меняет процессы в лаборатории и это всё должно быть отражено в документации СМ(К). К сожалению и со стороны разработчиков ЛИМС не всегда есть люди, хорошо разбирающиеся в этом;

6. Лаборатория не готова проводить валидацию ЛИМС. Валидация подобного ПО фактически является обязательной, так же как валидация расчётов в электронных таблицах. Лаборатории стараются получить подтверждение от разработчиков, но ведь в процессе внедрения вносятся множество изменений и продукт, установленный у одного заказчика, может сильно отличаться от продукта у другого заказчика. Конечно поставщики ЛИМС предъявляют какие-то сертификаты на своё ПО. Но подобная сертификация у нас в стране не регулируется и такие сертификаты выдают не аккредитованные органы, что нарушает закон о техническом регулировании (184-ФЗ), и следовательно никакой силы такие красивые бумажки не имеют.

7. Лаборатория со своей стороны не сформировала группу ответственных за внедрения. Ну эта ошибка везде присутствует. С одной стороны у разработчика должна быть команда внедрения с руководителем проекта внедрения, а с другой стороны лаборатория тоже должна иметь ответственных людей, которые обязуются довести это внедрение до конца. Уполномочить ответственных можно приказом или каким-то ещё способом, принятым в организации. Естественно, что ответственный за внедрение должен обладать необходимыми полномочиями, чтобы менять документы СМ, составлять ТЗ, планировать валидацию и т. д.;

8. Ну и последняя ошибка - это отсутствие целеполагания во внедрении. Нельзя правильно внедрить то, что не известно зачем внедряется. Бывает что высшее руководство принимает такое решение, потому что у других есть или какой-то регулятор требует, но не ставит правильных целей. Такое внедрение ради внедрения никому не нужно и как правило проваливается.

Если мы внедряем что-то новое в лаборатории, да и в любой деятельности, необходимо сначала поставить ЦЕЛЬ. При чем само по себе внедрение нового целью не является. Цель должна быть описана и визуализирована. Если цель можно описать и визуализировать, то она реальна и достижима.

Какие же цели может ставить себе лаборатория?

1. Автоматически выдавать протоколы испытаний для уменьшения ошибок и человеческого фактора.

2. Автоматически принимать заявки и пробы, чтобы легче было отслеживать и контролировать движение проб и сроки проведения работ.

3. Получать точные и подробные отчёты по работе лаборатории без запроса.

4. Избавиться от использования (заполнения) рукописных форм.

5. Ускорить работу лаборатории (хотя такую цель надо ставить с осторожностью).

Можно выбрать несколько непротиворечивых целей, для каждой определить критерий достижения. Например цель по формированию отчётов будет достигнута, если можно будет сформировать целевой отчёт за шесть месяцев работы.

Критерии достижения целей необходимо прописывать для каждой цели, в общем то это является частью визуализации. Критерии позволяют нам сосредоточить внимание и обозначить границы, после прохождения которой можно считать проект внедрения завершённым.

Если в организации используют какие-то системы скоринга или KPI при премировании, то критерии достижения целей позволяют мотивировать ответственных за внедрение. Команда по внедрению должна собираться на этапе целеполагания, поскольку именно от целей зависит состав этой команды. В процессе формирования команды могут появиться и дополнительные цели и критерии их достижения.

Цель руководства, как правило, заключается в повышении контроля за работой сотрудников, автоматизации отчетов, снижении ошибок. А цель сотрудников - автоматизация своей работы, упрощение рутинных операций. Необходимо, чтобы руководство и сотрудники имело мотивацию, чтобы ЛИМС решала какие-то их серьезные проблемы, тогда внедрение возможно будет успешным.

Когда Руководство лаборатории определилось с целью и визуализировало её, необходимо сформировать команду ответственных за внедрение. В эту команду должны входить руководитель лаборатории, руководители отделов, менеджер по качеству, ключевые сотрудники - владельцы процессов. Желательно, чтобы размер команды не превышал 5-7 человек, иначе им будет трудно между собой договариваться.

На команду ложится тяжкое бремя:

1. Описание функциональных требований к ЛИМС;

2. Знакомство и выбор продукта из имеющихся на рынке;

3. Составление ТЗ на внедрение в соответствии с функциональными требованиями лаборатории и возможностями выбранного ЛИМС;

4. Согласование плана внедрения, представленного поставщиком ЛИМС;

5. Контроль процесса внедрения, общение с командой внедрения со стороны поставщика, уточнение требований, проверки ЛИМС и описание ошибок;

6. Валидация ЛИМС после внедрения.

Работы по внедрению могут растянуться на довольно долгий срок и состоят из многих этапов, поэтому команда должна периодически собираться и обсуждать текущий статус по внедрению, проблемные моменты, что еще нужно сделать на текущем этапе, согласовать какие-то изменения и доработки.

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

Про процессы можно долго говорить, но в целом понятно, что если лаборатория не может описать свои процессы, то при внедрении ЛИМС столкнется с проблемами.

Поэтому есть вариант разделить работу над ТЗ на три этапа:

1) Лаборатория пишет ТЗ и передает поставщику ЛИМС;

2) Поставщик ЛИМС проводит обследование лаборатории по ТЗ, выявляет нюансы

конкретной лаборатории, знакомит сотрудников с ЛИМС, в ходе знакомства и обсуждения выявляются многие скрытые вопросы и проблемы в процессах;

3) Поставщик по итогам обследования составляет конечное подробное ТЗ и согласовывает с

лабораторией.

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

Документация по внедрению (базовый перечень):

• Цель и функциональные требования — внутренний документ;

• Техническое задание — внутренний документ и/или приложение к договору (контракту);

• Договор, контракт, соглашение или иной документ с поставщиком (подрядчиком);

• План работ, согласованный с поставщиком, приказ о закреплении ответственного со стороны лаборатории;

• Акты, протоколы приема-передачи ЛИМС, запуска тестовой эксплуатации, приказ о закреплении ответственного (ых);

• Журнал или протокол тестовой эксплуатации (ТЭ);

• Акт или протокол передачи в опытно-промышленную эксплуатацию (ОПЭ), приказ о закреплении ответственного (ых);

• План валидации, протоколы валидации, отчет о валидации;

• Акт завершения ОПЭ;

• Приказ о запуске в промышленную эксплуатацию.

Часть этих документов подготовит сам поставщик, но необходимо принимать в этом самое деятельное участие. Продвинутые поставщики ЛИМС могут предоставить документацию по ГОСТам серии 19 и 34, но строго говоря, для лабораторий это не обязательно. Следует следить за соблюдением формальных сроков и их переносом при необходимости. Документация по внедрению должна остаться в лаборатории для того, чтобы потом можно было к ней обратиться при проведении изменений, доработок и ревалидации ЛИМС. Также эта документация может понадобиться при аккредитации или очередном подтверждении компетентности, поскольку эксперты по аккредитации могут её запросить. До завершения внедрения (или в момент завершения) необходимо также издать новые документы (процедуры) СМ(К), в которых будет описана работа сотрудников лаборатории в ЛИМС.

Очень часто задают вопрос: «Почему же так сложно (дорого) автоматизировать процессы в лаборатории?»

Ответ тут на самом деле очень простой. В отличии от других сфер деятельности (бухгалтерия, кадры, производство), у лаборатории много процессов. Даже не так — очень много процессов. Во многих случаях каждый метод испытаний это отдельный процесс, в том числе с ветвлениями и циклами. А еще в каждой лаборатории даже одинаковые вроде бы процессы реализуются по своему, и какого‑то универсального решения тут нет. Поэтому нормальная автоматизация в виде внедрения программы, которая настраивается под все процессы, становится очень дорогой. Ну и понятно, что для быстрой реализации расчетов по различным методикам измерений и испытаний так или иначе необходимо использование каких‑то лоу‑код инструментов. Поэтому самый лучшей реализацией ЛИМС будет приложение‑конструктор с элементами ноу‑кода и лоу‑кода.

Но к сожалению не все разработчики подобных программ это понимают и продолжают следовать парадигме классической разработки

ЛИМС является системой, и как минимум объединяет в себе несколько журналов, позволяет использовать информацию из одних журналов в других, например использовать сведения об оборудовании в журнале по измерениям (испытаниям), или использовать сведения из журнала по отбору проб в журнале выдачи протоколов. За счёт объединения в одной системе нескольких журналов, справочников можно добиться новых свойств и функций ведения записей. Получается, что за счёт системности достигают эмерджментные свойства.

Одной из важных особенностей ЛИМС являются свойства управления записями, которые недоступны при использовании бумажных журналов. Как правило при внедрении ЛИМС у лаборатории возникают требования о необходимости соблюдения требований ГОСТ ISO/IEC 17025-2019 к ведению записей изложенных в п. 7.5 и п. 8.4. Понятно, что в ЛИМС должна быть возможность фиксации результатов, отслеживания изменений, запрет изменений, архивирование, резервное копирование. В той или иной форме все производители ЛИМС стремятся всё это реализовать. Конечно бывают не очень удобные и практичные формы реализации, но в любом случае можно запрограммировать, чтобы автоматически записывались дата, время внесения и изменения данных, пользователь и информация о нём. При этом пользователь не будет иметь возможность редактирования этой информации.

Но это всё в ЛИМС, а вот если задуматься, то становится понятно, что на бумаге этого не обеспечить.

Например, сотрудник может заполнить журнал с результатами не в момент проведения испытаний (измерений), а позже или даже в другой день, ведь информация о времени и дате вносится им же, если и вносится вообще.

Тоже самое касается изменений, всегда можно внести исправление и подписаться другой датой. Можно вообще целиком переписать лист измерений (первичный протокол) и даже журнал измерений. При необходимости можно и исправления в журнале внести любой датой.

Ведение записей на бумаге не обеспечивают выполнение требований к техническим записям и их изменению. Без полноценной ЛИМС реализовать все требования к техническим записям не получится

Практика показывает, что лабораториям трудно успешно внедрить ЛИМС. Основные ошибки при внедрении ЛИМС не сильно отличаются от ошибок внедрения других информационных систем:

1. Отсутствие внятного технического задания на внедрение. Как правило при внедрении ЛИМС лаборатория берёт техническое задание поставщика. Понятно, что ту часть, которая о функциях и возможностях программы, менять после выбора конкретной программы не стоит, но есть ещё часть технического задания, которая касается внедрения. И вот к этому разделу ТЗ необходимо уделить как можно больше внимания;

2. Лаборатория тащит в ЛИМС все свои печатные/рукописные формы ведения записей. Ну здесь наверно пояснять не надо. Если вы переходите на электронные записи, то надо отказываться от старых бумажных. Возможно они были вами оптимизированы и удобны в заполнении, но в программе однозначно всё будет не так. Не стоит держаться за свои сдвоенные и строенные таблицы;

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

4. Разновидностью третьей ошибки является и не совсем правильное выполнение методик. Если ЛИМС предполагает, что будут вестись записи и расчёты по методикам, то необходимо очень хорошо прописать последовательность действий персонала по внесению этих записей и хорошо проанализировать формулы расчёты. К сожалению встречается в практике недопонимание методик персоналом, а потом это всё ещё тащится и закрепляется в ЛИМС;

5. Серьёзной ошибкой лаборатории является неготовность переделывать документацию СМ(К) под ЛИМС. Внедрение ЛИМС в любом случае меняет процессы в лаборатории и это всё должно быть отражено в документации СМ(К). К сожалению и со стороны разработчиков ЛИМС не всегда есть люди, хорошо разбирающиеся в этом;

6. Лаборатория не готова проводить валидацию ЛИМС. Валидация подобного ПО фактически является обязательной, так же как валидация расчётов в электронных таблицах. Лаборатории стараются получить подтверждение от разработчиков, но ведь в процессе внедрения вносятся множество изменений и продукт, установленный у одного заказчика, может сильно отличаться от продукта у другого заказчика. Конечно поставщики ЛИМС предъявляют какие-то сертификаты на своё ПО. Но подобная сертификация у нас в стране не регулируется и такие сертификаты выдают не аккредитованные органы, что нарушает закон о техническом регулировании (184-ФЗ), и следовательно никакой силы такие красивые бумажки не имеют.

7. Лаборатория со своей стороны не сформировала группу ответственных за внедрения. Ну эта ошибка везде присутствует. С одной стороны у разработчика должна быть команда внедрения с руководителем проекта внедрения, а с другой стороны лаборатория тоже должна иметь ответственных людей, которые обязуются довести это внедрение до конца. Уполномочить ответственных можно приказом или каким-то ещё способом, принятым в организации. Естественно, что ответственный за внедрение должен обладать необходимыми полномочиями, чтобы менять документы СМ, составлять ТЗ, планировать валидацию и т. д.;

8. Ну и последняя ошибка - это отсутствие целеполагания во внедрении. Нельзя правильно внедрить то, что не известно зачем внедряется. Бывает что высшее руководство принимает такое решение, потому что у других есть или какой-то регулятор требует, но не ставит правильных целей. Такое внедрение ради внедрения никому не нужно и как правило проваливается.

Если мы внедряем что-то новое в лаборатории, да и в любой деятельности, необходимо сначала поставить ЦЕЛЬ. При чем само по себе внедрение нового целью не является. Цель должна быть описана и визуализирована. Если цель можно описать и визуализировать, то она реальна и достижима.

Какие же цели может ставить себе лаборатория?

1. Автоматически выдавать протоколы испытаний для уменьшения ошибок и человеческого фактора.

2. Автоматически принимать заявки и пробы, чтобы легче было отслеживать и контролировать движение проб и сроки проведения работ.

3. Получать точные и подробные отчёты по работе лаборатории без запроса.

4. Избавиться от использования (заполнения) рукописных форм.

5. Ускорить работу лаборатории (хотя такую цель надо ставить с осторожностью).

Можно выбрать несколько непротиворечивых целей, для каждой определить критерий достижения. Например цель по формированию отчётов будет достигнута, если можно будет сформировать целевой отчёт за шесть месяцев работы.

Критерии достижения целей необходимо прописывать для каждой цели, в общем то это является частью визуализации. Критерии позволяют нам сосредоточить внимание и обозначить границы, после прохождения которой можно считать проект внедрения завершённым.

Если в организации используют какие-то системы скоринга или KPI при премировании, то критерии достижения целей позволяют мотивировать ответственных за внедрение. Команда по внедрению должна собираться на этапе целеполагания, поскольку именно от целей зависит состав этой команды. В процессе формирования команды могут появиться и дополнительные цели и критерии их достижения.

Цель руководства, как правило, заключается в повышении контроля за работой сотрудников, автоматизации отчетов, снижении ошибок. А цель сотрудников - автоматизация своей работы, упрощение рутинных операций. Необходимо, чтобы руководство и сотрудники имело мотивацию, чтобы ЛИМС решала какие-то их серьезные проблемы, тогда внедрение возможно будет успешным.

Когда Руководство лаборатории определилось с целью и визуализировало её, необходимо сформировать команду ответственных за внедрение. В эту команду должны входить руководитель лаборатории, руководители отделов, менеджер по качеству, ключевые сотрудники - владельцы процессов. Желательно, чтобы размер команды не превышал 5-7 человек, иначе им будет трудно между собой договариваться.

На команду ложится тяжкое бремя:

1. Описание функциональных требований к ЛИМС;

2. Знакомство и выбор продукта из имеющихся на рынке;

3. Составление ТЗ на внедрение в соответствии с функциональными требованиями лаборатории и возможностями выбранного ЛИМС;

4. Согласование плана внедрения, представленного поставщиком ЛИМС;

5. Контроль процесса внедрения, общение с командой внедрения со стороны поставщика, уточнение требований, проверки ЛИМС и описание ошибок;

6. Валидация ЛИМС после внедрения.

Работы по внедрению могут растянуться на довольно долгий срок и состоят из многих этапов, поэтому команда должна периодически собираться и обсуждать текущий статус по внедрению, проблемные моменты, что еще нужно сделать на текущем этапе, согласовать какие-то изменения и доработки.

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

Про процессы можно долго говорить, но в целом понятно, что если лаборатория не может описать свои процессы, то при внедрении ЛИМС столкнется с проблемами.

Поэтому есть вариант разделить работу над ТЗ на три этапа:

1) Лаборатория пишет ТЗ и передает поставщику ЛИМС;

2) Поставщик ЛИМС проводит обследование лаборатории по ТЗ, выявляет нюансы

конкретной лаборатории, знакомит сотрудников с ЛИМС, в ходе знакомства и обсуждения выявляются многие скрытые вопросы и проблемы в процессах;

3) Поставщик по итогам обследования составляет конечное подробное ТЗ и согласовывает с

лабораторией.

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

Документация по внедрению (базовый перечень):

• Цель и функциональные требования — внутренний документ;

• Техническое задание — внутренний документ и/или приложение к договору (контракту);

• Договор, контракт, соглашение или иной документ с поставщиком (подрядчиком);

• План работ, согласованный с поставщиком, приказ о закреплении ответственного со стороны лаборатории;

• Акты, протоколы приема-передачи ЛИМС, запуска тестовой эксплуатации, приказ о закреплении ответственного (ых);

• Журнал или протокол тестовой эксплуатации (ТЭ);

• Акт или протокол передачи в опытно-промышленную эксплуатацию (ОПЭ), приказ о закреплении ответственного (ых);

• План валидации, протоколы валидации, отчет о валидации;

• Акт завершения ОПЭ;

• Приказ о запуске в промышленную эксплуатацию.

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

Очень часто задают вопрос: «Почему же так сложно (дорого) автоматизировать процессы в лаборатории?»

Ответ тут на самом деле очень простой. В отличии от других сфер деятельности (бухгалтерия, кадры, производство), у лаборатории много процессов. Даже не так — очень много процессов. Во многих случаях каждый метод испытаний это отдельный процесс, в том числе с ветвлениями и циклами. А еще в каждой лаборатории даже одинаковые вроде бы процессы реализуются по своему, и какого‑то универсального решения тут нет. Поэтому нормальная автоматизация в виде внедрения программы, которая настраивается под все процессы, становится очень дорогой. Ну и понятно, что для быстрой реализации расчетов по различным методикам измерений и испытаний так или иначе необходимо использование каких‑то лоу‑код инструментов. Поэтому самый лучшей реализацией ЛИМС будет приложение‑конструктор с элементами ноу‑кода и лоу‑кода.

Но к сожалению не все разработчики подобных программ это понимают и продолжают следовать парадигме классической разработки

Agile — это ценности, а не методология

Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

   Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.

Waterfall: миф о жестком подходе

Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.

Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:

1. Техническое задание

2. Эскизный проект

3. Технический проект

4. Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)

5. Внедрение (Подготовка и передача программы)

Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:

1. Устранение ошибок.

2. Развитие и усовершенствование продукта.

Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в 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 и итерационными методами зависит от четырёх факторов:

1. Предсказуемость требований.
   Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.

2. Стоимость изменений.
   В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.

3. Регуляторные ограничения.
   В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.

4. Культура команды и заказчика.
   Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.

Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum

Заключение: за пределами маркетинговых мифов

Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:

1. Какова степень неопределённости требований?

2. Какие ограничения накладывают регуляторы или бюджет?

3. Насколько команда и заказчик готовы к гибкости?

Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:

1. Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».

2. Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).

3. Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.

Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.

И теперь ты сидишь и задаёшься вопросом:
«Где я ошибся(лась)?»

Ответ: ты не ошибся(лась).
Ты просто играл(а) по честным правилам, которые уже давно никто не соблюдает.

1. Старые правила больше не работают. Вот почему

Когда-то брак был способом выжить.
Оба супруга зависели друг от друга — физически, экономически, социально.
Развод был катастрофой для всех. Поэтому его старались избегать.

Сегодня брак — это временный союз по расчёту.
И оба партнёра получили «свободу» — но ценой новых, невидимых оков.

Мужчина сегодня:

Ты делал всё «правильно»:
работал, не изменял, помогал, терпел, когда было тяжело, — потому что «мужчина не жалуется».

Но мир перестал вознаграждать за это.
Теперь:

• Твоя надёжность теперь — просто фон, на который никто не обращает внимания.

• Твоя верность вызывает не уважение, а вопрос: «А ты вообще пробовал с кем-то ещё?»

• Твоя готовность ставить семью выше себя воспринимается не как сила, а как признак того, что тобой можно управлять.

Ты проиграл не потому, что был плохим.
Ты проиграл, потому что играл в шахматы, а все остальные — в покер.

Женщина сегодня:

Ты тоже делала «всё правильно»:
вела хозяйство, растила детей, поддерживала мужа, старалась быть привлекательной.
Но мир перестал вознаграждать и тебя.

Теперь:

• Твоё тело после родов — не символ материнства, а «проблема, которую нужно решить».

• Твоя усталость — не повод для беспокойства, а «признак того, что ты не справляешься».

• Твой внутренний мир почти невидим, если ты не «горишь» эмоциями или сексуальностью.

Соцсети, подруги, сериалы нашептывают:

«Ты достойна большего».
«Ты ещё молода — успеешь найти «настоящего»».
«После 30 тебя никто не захочет».

И тогда ты начинаешь бояться не мужа, а собственного «истечения срока годности».
Ты смотришь на партнёра и думаешь:

«Он хороший... но вдруг есть кто-то лучше? А вдруг я уже «не та»?»

Ты проиграла, потому что верила в честную игру, а все остальные меняли правила на ходу.

2. Два мифа, разрушивших современный брак

Сегодня брак расторгают два противоположных, но одинаково ложных мифа.

Миф №1 (для мужчин):

«Если ты будешь надёжным добытчиком, тебя полюбят, будут уважать и останутся с тобой навсегда».

Этот миф учит мужчину:
— не выражать эмоции,
— не просить о поддержке,
— ставить семью выше себя.

Но в реальности надёжность перестала быть гарантией лояльности.

Миф № 2 (для женщин):

«Ты имеешь право на всё: на карьеру, на свободу, на любовь, на безопасность — и при этом не обязана ни за что платить».

Этот миф учит женщину:
— рассматривать отношения как возможность, а не как обязательство,
— считать свои деньги «личными», а его — «семейными»,
— видеть в разводе не катастрофу, а «новый шанс».

Результат?
Оба играют по разным правилам,
оба чувствуют себя обманутыми,
и оба винят друг друга, вместо того чтобы увидеть:

Их заставили играть в одну игру по двум разным инструкциям.

3. Кому выгоден этот раскол?

Подумай:
— Кто получает миллиарды на разводах, алиментах, разделе имущества?
— Кто зарабатывает на психотерапии, антидепрессантах, курсах «как вернуть мужчину»?
— Кто продаёт тебе новую машину, новую квартиру, новую одежду после развода?

Ответ один: система.

🔸 1. Государство: хочет детей — но не семью

Государство громко заявляет о «низкой рождаемости» — и даёт материнский капитал, льготы, пособия.
Но молчит о разводах, хотя они — главная причина, по которой люди не хотят рожать второго ребёнка.

Почему?

Потому что рождение — это пополнение ресурсов.
А крепкая семья — это независимая ячейка, которую оно не контролирует.

Государству выгодно, чтобы ты родил(а) ребёнка — но не обязательно растил(а) его в стабильной паре.
Стабильная, самодостаточная семья менее управляема. Ей не нужны бесконечные пособия, её сложнее вписать в парадигму тотального потребления. Её лояльность направлена друг на друга, а не на систему. Система же предпочитает атомизированных, легко управляемых индивидов.

🔸 2. Рынок недвижимости: студии как инвестиция в одиночество

В 2020–2023 годах государство запустило ипотеку под 5–6% для семей.
Цель: «сделать жильё доступным».

На деле:

• Цены на жильё выросли на 60% за два года (ЦИАН, 2022) .

• 58% нового жилья — студии и однокомнатные квартиры, где цена за кв. м на 30% выше, чем в трёхкомнатных квартирах (Известия, 2022).

• Инвестиции в недвижимость побили исторический рекорд (РБК, 2023).

Кто выиграл?

• Государство: налоги, НДС, рост ВВП.

• Банки: рекордные объёмы кредитования.

• Застройщики: всё раскуплено, цены подняты.

• Инвесторы: пассивный доход, защита от инфляции.

Кто проиграл?

• Молодые семьи: не могут позволить себе даже двухкомнатную квартиру, платят за аренду инвестору, который воспользовался «их» льготной ипотекой.

Это не забота. Это перекачка ресурсов от будущих семей к элите.

🔸 3. Корпорации: развод = двойное потребление

Вы состоите в браке — покупаете одну стиральную машину на двоих.
Вы развелись — покупаете две.

Факты:

• (IKEA, 2022) Продажи «товаров для одного» растут в два раза быстрее .

• (DSM Group, 2022) Рынок антидепрессантов растёт на 15 % в год .

• Алкоголь и табак приносят 6% ВВП за счёт акцизов (Минфин РФ, 2022) .

Семья покупает молоко, фрукты, билеты в кино.
Одинокий человек — бутылку вина, сигареты, еду на дом, платный контент.

Системе выгодно твоё одиночество — оно дороже и предсказуемее.

🔸 4. HR и фармацевтическая индустрия: человек как расходный материал

• HR-менеджеры чаще продвигают по службе холостых сотрудников, так как они «более гибкие» (HeadHunter, 2021) .

• Фармацевтические корпорации наживаются на вашем выгорании → стабильная семья — плохой клиент.

Это не теория заговора.
Это — экономика поведения.

4: Цитадель. Как строить отношения в мире, который их разрушает

1. Цитадель вместо крепости

Многие, пережившие предательство — мужчины и женщины — строят крепость:
«Больше никому не доверюсь».

Но крепость — это одиночество под замком.
Цитадель — это целостность с возможностью союза.

• Мужчина, построивший цитадель, больше не будет донором, ожидающим благодарности.

• Женщина, построившая цитадель, больше не будет искать спасителя, чтобы заполнить внутреннюю пустоту.

Оба станут источниками, а не потребителями.

2. Фильтрация, а не убеждение

Не трать силы на тех, кто говорит:

«Ты скряга, если хочешь знать, куда уходят деньги».
«Ты эгоистка, если не хочешь жить ради семьи».

Такие люди живут по старым мифам.
Их нельзя переубедить. Их можно только отсеять.

3. Практика цитадели: первые шаги

Цитадель строится не за один день. Но начать можно уже сегодня.

• Неделя 1–2: информационная гигиена. Удалите из соцсетей аккаунты, в которых вы чувствуете себя неудачником. Перестаньте читать истории «идеальных пар».

• Неделя 3–4: Финансовый аудит. Составьте личный бюджет. Поймите, на что вы тратите деньги и почему. Это основа вашей независимости.

• Неделя 5–6: Физический фундамент. Сон, вода, 30-минутная прогулка. Ты не сможешь строить, если у тебя нет энергии.

• Неделя 7–8: составление «Манифеста Цитадели». Письменно ответьте на вопросы: Каковы мои нерушимые границы? Что я готов(а) дать партнёру? Что я хочу получить взамен? Это ваш внутренний устав.

4. Договоренности вместо клятв

«Навсегда» — красивая сказка.
Договор — взрослая реальность.

• Брачный контракт — это не «недоверие». Это уважение к труду друг друга.

• Раздельные счета + общий на бытовые нужды — это не «расчёт», а ясность.

И да — это работает для обоих полов:

• Мужчина не боится, что его «используют и бросят».

• Женщина не боится, что её «загонят в угол материнства».

5. Союз адекватных

Ищи не «родственную душу», а того, кто такой же, как ты:

• прошёл через боль,

• видит систему,

• не верит в сказки,

• но всё равно готов строить что-то настоящее.

Такой союз не исключает страсти. Напротив, только два полноценных человека могут позволить себе роскошь настоящей, а не зависимой страсти.

6. Для тех, кто ещё не вступил в отношения

Не верьте в то, что «любовь преодолеет всё».
Задайте друг другу вопросы до получения ответа «да»:

• Как мы относимся к деньгам?

• Кто будет вести быт?

• Что будет, если один из них захочет уйти?

Если вы не можете обсудить это спокойно — не вступайте в союз.

7. Для тех, кто уже прошёл через ад

Ваша задача — не «исправить» следующего человека.
Ваша задача — не допустить повторения.

И если вы построите цитадель —
вы не станете «холодным циником».
Вы станете тем, с кем можно строить — не боясь, что вас разрушат.

Послесловие: ты больше не ресурс. Ты — человек

Ты не обязан быть добытчиком, чтобы быть любимым.
Ты не обязана быть «мамой и женой», чтобы быть ценной.

Ты не должна молчать о своей усталости.
Ты не должна скрывать свои амбиции, чтобы «не отпугнуть мужчину».

Любовь, построенная на жертвенности, — не любовь. Это долг.
Семья, построенная на долге, — не семья. Это тюрьма.

Система хочет, чтобы ты:

• работал(а),

• рожал(а),

• потреблял(а),

• молчал(а).

Но ты — не винтик.
Ты — человек.

Построй свою цитадель.
Не как укрепление против мира.
А как свидетельство: я больше не играю по их правилам.

И если рядом появится тот, кто строит свою —
— вы сможете создать то, что система не может ни купить, ни сломать:

близость, которую нельзя купить по акции, нельзя прописать в законе и нельзя отобрать через суд. Это твой личный суверенитет, добровольно разделённый с тем, кто его заслужил.

Это не утопия.
Это — выбор.
И он начинается сегодня.

«Эта статья была подготовлена с использованием технологий искусственного интеллекта при участии и редактуре автора.»

И так, какие же кейсы есть с применением LIMIT

1. LIMIT + OFFSET

   Многие помнят про LIMIT, но забывают про то, что можно еще применять сдвиг.

   SELECT *
   FROM users
   ORDER BY id
   LIMIT 10 OFFSET 20;

   Этот запрос вернёт 10 строк, начиная с 21-й.

   Такой прием применяется, например, в постраничной выдаче результатов запроса.
   
   Но этот кейс имеет и минусы: OFFSET все равно просматривает первые 20 строк, чтобы добраться до нужных. При больших объемах OFFSET работает медленно.
   

2. LIMIT в UPDATE и DELETE

   Да, да - в этих операторах тоже можно использовать LIMIT, не только в SELECT

   DELETE FROM logs ORDER BY created_at ASC LIMIT 1000;

   Так чистят таблицу порциями, чтобы не завалить базу огромным удалением.
   

3. LIMIT в подзапросах

   Об этом часто помнят, т.к. подзапрос является запросом, а в запросах использование LIMIT - вполне привычное дело.

   
   Найдем самый дорогой заказ:

   SELECT *

   FROM orders

   WHERE id = (SELECT id FROM orders ORDER BY price DESC LIMIT 1);

   Это иногда проще, чем возиться с MAX() и джойнами.
   

4. LIMIT vs FETCH … WITH TIES

   В некоторых СУБД (например, SQL Server, Oracle) есть фича:

   SELECT *

   FROM products

   ORDER BY price DESC

   FETCH FIRST 3 ROWS WITH TIES;

   Такой запрос вернёт не просто 3 строки, а все строки, у которых цена такая же, как у третьей записи.
   (например, если на третьем месте несколько товаров с одинаковой ценой).

   
   LIMIT показывает первые N строк после сортировки
   А вот WITH TIES говорит: «Выдай все строки, которые наравне с последней по значению сортировки».

   
   В других СУБД такой синтаксис можно реализовать через LIMIT + подзапрос с оконной функцией RANK()
   

5. LIMIT 0

   Очень полезный трюк.

   SELECT * FROM users LIMIT 0;

   Вернёт пустую таблицу, но со всеми названиями и типами столбцов.
   Это часто используют для генерации схемы в BI-инструментах или в тестах
   

6. LIMIT в CTE (PostgreSQL)

   Можно ограничивать данные прямо на уровне общего табличного выражения (CTE), чтобы уменьшить нагрузку:

   WITH top_orders AS (

   SELECT * FROM orders ORDER BY price DESC LIMIT 100

   )

   SELECT * FROM top_orders WHERE customer_id = 42;

Так мы сначала берём только 100 дорогих заказов, а потом фильтруем по клиенту.

В итоге LIMIT — это не просто «дай 10 строк», а инструмент для оптимизации, постраничной навигации, аккуратных обновлений и даже для защиты от перегруза.

Подписывайся на мой ТГ канал На связи: SQL, чтобы узнавать/вспоминать еще больше нюансов SQL запросов.