Что же собой представляет практики GAMP в управлении проектами АСУ ТП?

Что такое GAMP

Вначале об очередных аббревиатурах – кажется, в последнее время их многовато)

GAMP– это Good Automation Manufacturing Practice, – де-факто стандарт фармацевтической промышленности по АСУ ТП. Сама аббревиатура GAMP является зарегистрированным товарным знаком Международного сообщества инжиниринга в фарма-индустрии (ISPE).  И в общем имеет те же корни, что и GMP (то же, только без automation) – очень знакомая аббревиатура всем отечественным фармацевтам. А если еще больше обобщать, то это один из десятков GxP стандартов, которые есть и в других отраслях. Их роль – фиксировать и  регламентировать лучшие практики и стандарты.

В силу высокой степени стандартизации в фармации, неудивительно, что стандарт по автоматизации родился именно здесь. Сегодня GAMP – один из самых цитируемых стандартов промышленной автоматизации и именно в области управления проектами, вышла уже 5-ая редакция, почему и часто встречается «GAMP 5».

Основные положения GAMP

Во-первых нужно сказать, что сама идея GAMP – не что иное, как попытка подняться на 3-ий уровень зрелости в модели СММ (Capability Maturity Level). Возвращаясь к нашей дискуссии на недавнем клубе АППАУ «интуитивное управление vs процессное и стандартизированное», можно смело проводить параллели с уровнями 2 и 3 этой модели. Практически очевидно, что ИТ-шники уже перешли на 3-ий и 4-ый уровни, в то время, как Системные интеграторы АСУ ТП находятся на переходе между 2-м и 3-им.

 

GAMP – это как раз о том, чтобы выйти на 3-ий и 4-ый уровни в области АСУ ТП.

Итак, что предлагает GAMP стандартизировать:

1. V-образный цикл разработки проектов по АСУ ТП. Однако в отличие от просто концепта, GAMP стандартизирует в деталях – сами этапы и документы, которые их сопровождают.

2. В качестве основных регламентирующих документов фигурируют:

• Architectural Diagram (AD) – диаграмма архитектуры АСУ
• Control System Strategy (CSS) – стратегия системы. Эта стратегия является обязательной для управления User Requirement Specification (URS) – требованиями заказчика.
• Functional Requirement Specification (FRS) – функциональные требования к системе. Она описывает, как поставщик будет выполнять требования, изложенные в URS.
• Logic Description (LD) – логические и другие диаграммы, функциональные блоки, описывающие тех процесс (важно упомянуть, что GAMP разработан для групповых (batch) процессов)
• Sofware Standards Document (SSD) – описывает требования по разработке и внедрению программного обеспечения.

3. Вероятно, GAMP включает слово «практика» (practice) поскольку не только регламентирует, но и дает практические рекомендации. Например, в оценках усилий, по фазам проекта интересен следующий расклад

Другими словами, если вы не тратите до 55% усилий на URS-FRS, то вряд ли вы получите хорошее качество проекта.

4. GAMP также регламентирует пошаговый подход к ведению проекта – последовательность шагов от создания предварительного URS и до финального пуска расписана в 15-20 этапах.

5. Также упомянутый документ приводит много других структурных распределений – по типам проектов, по рискам и т.п.

Что же считать Good-Bad-Ugly?

На этот вопрос указанный документ отвечает не совсем четко. Очевидно, придерживание всех указанных регламентов и будет ‘Good’. И, наоборот, их игнорирование может вести к ‘Ugly’. Кроме этих очевидных, но и банальных умозаключений, больше подсказок есть в презентации с аналогичным названием, автор David Chappell. В частности, он обращает внимание на качество и важность URS и предлагает его утверждение в 2 захода – в начальной фазе проекта (концепция проекта) и последующей (проектирование). Точно также в 2 захода утверждаются FRS. Также количество и глубина проработки ставятся в зависимость от типа проекта.

«И что же делать с Agile?» – вопрос интересный в контексте последних дискуссий

Конечно, подобные стандарты разрабатывались годами и в этом конкретном документе нет ни слова об Agile, который, как мы уже знаем, вышел из ИТ и то в последнее десятилетие. Напротив, обычный поиск по запросу “GAMP 5  Agile” вываливает вам массу более свежих документов, которые ясно говорят, что GAMP 5 в редакции 2008 года уже включал, – далее цитируем в переводе, –  «совместимость с широким рядом других моделей и методов. В частности, в области разработки ПО таких как – Rapid Application Development (RAD), Agile, Rational Unified Process (RUP), or Extreme Programming». Далее упомянутый по ссылке документ упоминает и SCRUM и объясняет, как все указанные методы соотносятся с GAMP 5. Процитируем в заключение «методы agile действительно имеют ряд преимуществ как:

• Использование итераций для лучшего подхода к решению
• Тестирование в реальном времени функциональности, согласованной с заказчиком
• Контроль и управление функциональностью непосредственно в приложении
• Раннее и постоянное вовлечение сообщества пользователей
• Гибкая реакция на изменения среды и спецификации
• Избежание внедрения кода и функциональности, которые становятся ненужными

… В то же время, ни один из указанных методов не покрывает требования по необходимым регламентным документам на всем жизненном цикле проекта, попадающем под условия практик GxP.»

Проще говоря, наш вывод напрашивается такой – «да, вы можете экспериментировать и пробовать с Agile/SCRUM и другими методами. Однако оставайтесь в рамках GAMP, – V-образная модель, специфицированная по этапам и типам проектов действительно оптимальная по своим регламентам».

Где узнать больше

Для членов АППАУ доступ к документам открыт в библиотеке ресурсов. Для других мы рекомендуем поискать ресурсы в открытом доступе в интернете – их на самом деле много по этой теме. Упоминания – разъяснения будут предоставлены на следующем вебинаре 8 июля. Вопросы, комментарии приветствуются.