Технологический Трансфер без Технологических Нюансов

Технологический трансфер это

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

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

Трансфер актуален для всего этапов третей фазы, начиная с 3A и заканчивая 3D. Так как по ходу разработки субстанции и препарата технология кочует с площадки на площадку и конечно её надо надлежащим образом сопровождать, чтоб обеспечить производство, соответствующие объемы на клинические испытания и подготовку документов для IMPD/CTD.

На второй фазе (2A→2D) разработки drug discovery формальный трансфер не особо применим. Там и так хватает поводов потратить денег.

Коммерческая технология (этап 3D)

Итак начнем с конца. Если вы попали на фармацевтический завод в разряде технолога/аппаратчика (возможно даже по ТК РФ, но это не точно), то вам придется изучить технологический процесс, который работает как часы. Скорее всего нарабатывается уже n серия продукта, имеются все документы - маршрутная карта, спецификации, методы анализа, планирование загрузки оборудования, все сырье с запасом в несколько месяцев на складе и т.д.

Встает резонный вопрос (как и у всех мыслителей начиная с Аристотеля) - “а в принципе как все началось, почему технология именно такая, почему мы добавляем этот реагент два часа, а не сразу заливаем все залпом в реактор, так же быстрее будет”

Валидационные серии (этапы 3C,3D)

Собственно если отматывать назад то мы утыкаемся в первую веху - валидационные серии.

Формальное определение из рекомендации №11 от ребят которых надо слушать:

Валидационная серия – серия активной фармацевтической субстанции или лекарственного препарата, произведенная способом, который полностью соответствует и воспроизводит промышленный способ производства

Неформальное определение - вот как мы сейчас сделаем препарат, так его и будем делать. Не дай бог кто-то тут включит ученого и хоть что-то поменяет. Его не сразу, но все же покарают все кому не лень, и дирижерами пыток будут ООК и УЛ. Вот прям, как в маршрутной карте и регламенте (последний несколько устарел как документ, но стоит упомянуть) написано, так и делаем. Никакой самодеятельности.

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

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

Думаю все понятно, ползем дальше.

Инженерные серии

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

Формальное определение:

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

Также есть регуляторное требование на минимальный объем инженерных серий - не менее 1/10 от промышленной, который строго должен соблюдаться (см. всё ту же рекомендацию). Но конечно никто не запретит, кроме руководства, обкатывать технологию на чуть меньших или больших объемах пока не надоест.

В классическом случае на этом этапе может и должен участвовать R&D персонал. Пока мы подразумеваем что у нас классический трансфер R&D → производство, но жизнь может быть чуть сложнее. Пока пусть x будет равно классическому трансферу.

В целом если компании не все равно на свой продукт, то сотрудника R&D стоит командировать на производственную площадку пока не останется никаких вопросов к инженерным сериям.

Инженерную серию стараются проводить на таком же оборудовании как и для коммерческого выпуска. Это значит что необходимо использовать аппараты большого объема, в которые надо заливать/засыпать/задувать приличное количество реагентов соответственно. И в принципе несложно догадаться, что стоимость реагентов используемых для фармацевтики чуть выше сливочного масла (хотя с этим можно поспорить). В итоге стоимость одного прогона инженерной серии может легко улететь в космос и догнать “Вояджер-1”.

По опыту автора средняя стоимость инженерной серии находится на уровне >10,000 $, но бывали случаи по 0.5 MM$.

Конечно менеджмент обычно не очень рад тратить астрономические суммы на “пробные” серии, которые сливают в утиль (привет эко повестка) и любезно настаивает на минимизации количества таких серий. И как раз тут на помощь приходит R&D, чтобы сопроводить технологический трансфер и помочь с адекватной оценкой рисков и тщательной проработкой документов. Осознание рисков позволяет нивелировать все возможные нюансы теоретически прежде чем приступать к инженерным сериям практически и даже сократить количество необходимых серий.

Мы спускаемся на следующий уровень в жизненном цикле технологии

Технологический трансфер

Герой сегодняшнего текста.

Так вот. В голове у обывателя передача процесса выглядит как передача уникального рецепта пирогов от бабушки: можно просто написать на листочке чего и сколько закидывать и потом просто воспроизвести у себя на кухне. И если уж в быту никогда не получается повторить “тот самый аромат или вкус” любимого блюда, то что уж говорить о чуть более сложных процессах таких как получение лекарств, например.

Трансфер состоит из двух взаимосвязанных сущностей, навалим опять формализма:

"Трансфер аналитических методик" - передача аналитических методик от лаборатории передающей стороны в лабораторию принимающей стороны

&

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

А если переводить на чуть более приземленный, то это передача самой технологии, аналитических методов и всё что с ними связано на другую площадку. Целью трансфера является создание производственной линии продукта, которая будет обеспечивать АФС/ГЛФ в нужном годовом объеме с целевым качеством.

Разработка технологии ну или PR&D (этапы 3A/3B)

Последняя остановка на сегодня в этой ретроспективе.

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

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

Этапы трансфера

Несмотря на то, что имеются некоторые регуляторные документы (см. список в конце), описывающие трансфер - сам процесс и его нюансы не высечены в камне. У каждой компании свой подход к передаче технологии. Спектр подходов колеблется от “мы не можем сопротивляться энтропии вселенной” до “мы не будем делать ничего дальше, пока документ не будет вылизан и подписан всеми со сотрудниками от CEO до пса Барбоса, отвечающего за pest контроль”

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

Акт 1. Сбор команды

По звонку проектного менеджера (PM) собирается роковой патруль по трансферу состоящий из:

Представителей передающей стороны (Sending Unit, SU)

• Обычно это менеджеры от R&D лаборатории - химики и аналитики, которые участвовали в разработке технологии и аналитических методов. Я подчеркиваю, что аналитическая часть настолько же важна и не надо к ней относится как просто к приятному бонусу.
• Как бонус, и это очень редко, подключаются еще RnD QA специалисты. Их наличие в компании это прям зеленый флаг, что ребята в разработке не в детский сад играют.

Представители принимающей стороны (Receiving Unit, RU). Списочек может быть обширным, но хорошо было бы видеть следующие функции

• Тех трансфер лид (Technology Transfer Program Manager) - да это может быть и проектный менеджер на худой конец. Но лучше не надо - хорошо бы, чтобы это было отдельный представитель соответствующего департамента. Да прям Technology Transfer Department.
• Инженеры или технологи (Process Engineering, MS&T) - чтобы могли сразу сказать можно ли засунуть полет мыслей химиков-разработчиков на производство или сразу куда-нибудь поглубже. В общем наряду с ОКК - ядро команды.
• ОКК (Quality control) - как представители принимающей аналитической лаборатории оценивают методики, надо ли что-то закупать и придется ли дорабатывать методику (спойлер - да, придется)
• Операционщики (Operations) - будут держать в курсе какие слоты на производстве свободные, то есть когда можно будет поставить инженерную серию (спойлер, новый год). Возможно по совместительству помогут с заказом сырья, или делегируют кому-нибудь, например в снабжение (procurement).
• БЖД (HSE) - следят за тем чтобы люди оставались живы на производстве и общая сумма конечностей оставалась неизменной на протяжении всей смены.
• Ну и конечно самое сладкое - ООК (Quality Assurance) составляют шаблоны документов и различные анализы рисков для того, чтобы в итоге оформить уже шаблоны вышеупомянутых маршрутных карт. Сложно переоценить важность функции. Иногда ее растягивают на несколько отдельных департаментов, но суть думаю ясна.

Не совсем касается завода, это скорее уровень уже стейкходеров (stakeholders). Особенно если трансфер внешний:

• Хорошо бы держать Sales/Marketing команды в курсе, потому что сроки и стоимость трансфера напрямую влияют на маржинальность финального продукта.
• Участие представителей регуляторики (Regulatory + CMC) не помешает, чтобы быть уверенными, что документы в итоге подадут в срок и в процессе ничего кардинального не изменится.
• До кучи можно (а иногда нужно) подключить представителей клинического департамента (Medical Department), но это уже как пойдет. Могут помочь со спецификациями (если очень хорошо попросить) на продукт и с ними можно поторговаться касаемо финальных объемов продукта.

Акт 2. Составление общего плана

“У нас был какой-то план и мы его придерживались”.

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

- Оценки и известные воздействия, требуемые для соблюдения стандартов охраны здоровья, безопасности и окружающей среды (HSE)

- Обзор проекта и бизнес-движущих факторов (реверанс к объемам рынка)

- Список членов команды и утверждающих управленцев/бюджет (заинтересованных сторон)

- Основные цели и результаты - на чем собственно стоит закончить

- Основные сроки и необходимые ресурсы:

• Проект должен быть разделен на фазы, с обзором сделанного и «чеклистом на следующий этап» в конце каждой фазы
• График должен быть реалистичным и не предполагать 100% успеха на каждом шаге
• Необходимо определить значительные капитальные и операционные затраты, расчетное количество полного рабочего времени (FTE)
• Необходимо указать, какая единица будет отвечать за финансирование элементов проекта

- Пути разрешения проблем и управление, включая пути эскалации

- Регуляторная стратегия

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

- Указать допущения, включенные в предложенные сроки

- Потенциальные риски для проекта – оценка рисков

• Например, конкуренция за FTE и ресурсы с других программ, неблагоприятные клинические или регуляторные результаты параллельно трансферу, пробелы в понимании процесса при изменениях и масштабировании в рамках технологии передачи, невозможность смягчить значительные риски, проблемы совместимости продукта. Да вариантов много, но контроль рисков это неотъемлемая часть любого проекта даже не в фарме.

- Определение минимально необходимой информации для передачи технологии - когда R&D будет готов начать работать с производством.

- Идентификация возможностей для членов команды передачи технологии (например, для сотрудников приемной стороны) для ознакомления с процессом на стороне отправителя с целью получения неявных знаний и визуальной документации (например, консистентность взвешивания массы, консистенция раствора)

- Требования для хранения, транспортировки и дальнейшей обработки, такие как передача вещества в продукт.

Акт 3. Сбор документов/Оценка рисков

Очередной вопрос курицы и яйца. Но обычно стоит ожидать что передающая сторона собирает пакет документов и доблестная команда от принимающей стороны оценивает можно ли с этим работать.

1. Технический пакет - ну это технологическая схема, аппаратурная схема (P&ID), стратегия контроля, описание оборудования, отчет о квалификации аналитических методик (губозакаточная машина бонусом) и отчет о первичном масштабировании (например с 250 мл до хотя бы 2-5 л, если мы говорим про реакторы емкостного типа)

2. Оценка рисков - туда входят всевозможные теоретические анализы готовности площадки к той технологии которую передают и что может пойти не так (да вы уже догадались, та самая FMEA). Наверное стоит выделить, что главное рассмотреть передаваемую стратегию контроля процесса и оценить каждый шаг на вероятные трудности.

Например, в передаваемых документах упоминается, что скорость нагрева критически влияет на профиль примесей и необходимо обеспечить минимум Δ10 °С/мин. В колбе задача исполнимая, а на производстве в 1 м3 - могут возникнуть проблемки.

Способов оценки рисков достаточно большое количество, стоит просто упомянуть, что всё это изобилие описывается термином GAP-оценки (GAP analysis). Где как раз поэтапно сравнивают процессы между передаваемым сайтом (SU) и потенциальным процессом который будет реализован на принимаемом (RU). Конечно приходится идти на компромиссы и по возможности дорабатывать процесс на лету в цеху или помариновать разработку в лаборатории.

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

Акт 4. Подготовка площадки/собственно трансфер

Если команда принимающего сайта (Receiving Unit) довольна документами и уверена в процессе, то начинается процесс обкатки технологии. Было бы здорово сказать, что хватает 3-4 инженерных серий и можно начинать валидацию, но жизнь чуть более сурова. Особенно если оборудование на передающем сайте (Sending Unit) было далеко от производства.

Я уже писал немного про масштабирование, но напомню, что может пойти не так: профиль нагрева оборудования, гидродинамика внутри реактора (на малом объеме всегда легче добиться взвешенной суспензии, чем в многолитровом), принципиально другой тип оборудования (разные производители таблет-прессов, например) и т.д.

В плане документов, библией на данном этапе является стратегия контроля. Что за зверь? Ну там это, табличка в которой написано куда, когда и на что смотреть и контролировать во время процесса. Так вот - стратегия контроля будет активно меняться во время трансфера пока не эволюционирует в финальную версию, которую уже зацементируют в маршрутке.

Вот тут проводится оценка рисков по непосредственному уже процессу. И да каждое изменение и версия фиксируется, ну или должна.

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

Акт 5. Завершение трансфера

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

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

Можно приступать к валидационным сериям, ну или коммерческому выпуску, если валидация была частью трансфера.

Помимо очевидных вещей а-ля технологических схем и аналитических отчетов, что стоит иметь в финальном отчете:

• Финальная оценка рисков процесса, стратегия контроля
• Сравнение процессов до/после трансфера - какие действия были предприняты и почему были изменены некоторые операции и температурные режимы Если не сделать сейчас, то уже месяцев через 6 концов уже будет не найти.
• ООК составляет список всех отклонений и изменений во время трансфера - позволит проследить, а что изменилось в итоге. Change control и вот это всё.
• Можно приправить картами шухарта (shewhart chart) и индексами воспроизводимости процессов (capability index), но это уже в меру сил конечно
• Отдельный пункт стоит уделить финальной оценке аналитических методов и насколько они вообще валидны. Согласовать это всё с ОКК, чтобы потом сюрпризов не было.
• Отдельно от отчета по трансферу - анализ полученного опыта (Lesson Learned), что пошло не так и как это исправляли.

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

Кода

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

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

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

Можно (и настоятельно рекомендуется) разбирать разные технологические кейсы (тыц и тыц и тыц)- почему происходят задержки и фейлы и что всё-таки надо изучить в лаборатории прежде чем передавать процесс, но это всё ничто перед исконной проблемой, которой является - ЧЕЛОВЕК.

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

Примечание для менеджеров по трансферу: да я упростил общую схему для удобства, простите грешного, не надо мне слать письма с угрозами, я вполне успешно справляюсь сам.

Типы трансферов по…

Имеется несколько сценариев по тому откуда (Sending Unit) и куда (Receiving Unit) можно отправлять технологию/процесс:

I. типу площадки

1. Лаборатория → Производство - самый базовый вариант, который каждый и представляет у себя в голове. Ученые что-то разработали, описали в документах, передали их и на площадку с большими, взрослыми реакторами, начали что-то производить.

Если делать трансфер из лаборатории в производство напрямую как есть, без промежуточных этапов, то это будет попыткой перешагнуть через два лестничных пролета одним шагом: можно попробовать, но результатом будет только рваная ж*па. Приходится добавлять промежуточные этапы пилотных объемов. То есть не [250 мл → 2000 л], а [250 мл → 2 л → 20 л → 200 л → 2000 л]. Проблема в том, что если трансфер запустили, то менеджменту сложно объяснить “подождите, пожалуйста, дайте сделать как надо” всё надо исполнить завтра и желательно вчера, поэтому получается что получается. 🍑

2. Пилотная площадка → Производство - в некотором роде разновидность предыдущей опции. Но ввиду наличии собственного опыта, вынужден отметить это как отдельный вариант. Этот вариант применим когда пилотные серии промежуточного объема не являются частью трансфера, а как раз его исходная точка.

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

Если речь зашла о трансфере только сейчас, когда нарабатывается уже 50ая серия на пилоте, то тут уже скорее всего речь идет о эквиваленте 10 летнего BMW. Оно как-то работает, но кто и что там накрутил непонятно. То есть получить ответ на вопрос “а почему границы температур тут такие?” уже непросто. Обычным ответом будет - “таков путь”, а в худшем - “а ты откуда такой умный, не шпион ли часом?” Вариант встречается после долгой наработки препарата на клинику на одной площадке и при дальнейшей передачи технологии в коммерцию.

3. Производство → Производство - тут можно начинать что-то подозревать, но это в целом тоже привычный вариант, когда компания №1 продает свою технологию компании №2 за много денег или просто производит релокацию на другую внутреннюю площадку. Конечно тут можно допустить, что все документы уже есть - берем и передаем как есть. И да и нет. Чем сложнее продукт (сравниваем парацетамол и например энфувиртид), тем больше шансов что у принимающей стороны не будет такого же оборудования или квалификации персонала как у передающей. И если у вас вдруг появилась мысль, что изначально выбор принимающей площадки начинается с GAP оценки оборудования, чтобы минимизировать риски и не выбрать площадку которая тупо не потянет, то можете её закопать.

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

Ну и все костыли с предыдущего варианта тоже актуальны. Процесс может быть конечно уже обкатанным, но ни в одном документе не значиться, что валидированная Пелагея Ивановна нужным образом перемешивает суспензию перед тем как заливать её в реактор. Для тех кто не выкупил - к сожалению не всегда нормативные документы фиксируют “особенные” операции в технологии с которыми знакомы только некоторые технологи. Даже в век GMP такое происходит, конечно с уходом таких ценных технологов производственная линейка может наглухо встать. Не забываем про обучение персонала, как часть системы качества.

4. Производство → Лаборатория - погодите что? ага стрелочка разворачивается на 180°. Когда это может происходить - компания имеет производство на сайте №1, но технология устарела поэтому эта компания №1 просит лабораторию (CDMO) доработать процесс. Тут в итоге повториться вариант 1 с дальнейшим обратным трансфером на сайт №1 или №2, 3 и т.д. Как рыночек порешает.

5. Лаборатория → Лаборатория - а это тут вообще каким боком? Ну во первых по законам комбинаторики такой вариант должен был быть, а во вторых бывает что процесс не успевают доработать в одной лаборатории и его надо передать в другую. То есть то, что сейчас происходит с рынком CDMO, когда приходится доделывать технологию за восточными братьями. Иногда из-за политики, иногда из-за денег. Конечно это не самый тривиальный вариант и процесс передачи идет как пойдет.

II. аффилированности площадок

Каждый из вышеперечисленных вариантов может иметь следующие свойства:

1. Внутренний трансфер - принимающая площадка и передающая сторона юридически находятся в одной компании. То есть все работают с одним доменом @bigpharma.money. Такой расклад повышает шансы на успех и в принципе позволяет найти кнут даже на самых нерадивых сотрудников. Как обычно, многое еще зависит от коллаборации отделов.
   Если сотрудники лаборатории постоянно курят с производством и вообще ходят к друг другу на свадьбы шансы договориться во время трансфера резко возрастают.
   Сноска для менеджеров по трансферу - успешный трансфер не стоит того, чтобы насильно заставлять отделы дружить и исполнять роль Купидона
2. Внешний трансфер - ну тут все просто, да. RU и SU скреплены только тесными узами какого-либо договора. После трансфера SU отваливается от процесса как настоящая суррогатная мать. Конечно тут уже возникают сложности с тем, что люди друг друга не знают и насильно приходится выстраивать какую-то коммуникацию между разными компаниями, а времени и мотивации нет, поэтому возникают недомолвки и недопонимания
3. Внешний трансфер со звездочкой - что за зверь? Иногда Компания не имеет производственной площадки для продукта, поэтому они нанимают площадку №1 для производства продукта под лицензией, но ничто не вечно под луной и Компания может найти площадку №2 вместо площадки №1 для дальнейшего производства. И надо провести трансфер из площадки №1 в площадку №2, но каждая из них работает по своим правилам и на самом деле может быть не очень сильно заинтересован в продукте, поэтому команда трансфера из Компании организовывает процесс или еще хлеще нанимает четвертое лицо в виде CRO, которое организовывает трансфер и работает с площадками №1 и №2. Нетрудно понять, что два /три сломанных телефона хуже одного и такие сценарии не так просты в исполнении.

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

III. территориальному расположению

1. Трансфер в рамках населенного пункта/области - обычно возможен в случае когда это внутренний трансфер, но всякое бывает. Очевидно что сложностей тут нет, один часовой пояс, всегда можно доехать и разобраться, что там технологи начудили.
2. Трансфер в рамках страны - кхм, ну страны разные бывают, но тут подразумевается, что люди общаются на одном языке, имеют примерно одинаковые ценности и в целом с ними можно договориться без языкового барьера. Также можно прилететь за полдня и посмотреть как идет процесс. Да уже возникают сложности, что приходится постоянно созваниваться, сложно проследить все нюансы, но в целом терпимо.
3. Трансфер в другую страну - сложность резко возрастает. Даже если это одна компания с одними ценностями, то как никак возникает языковой барьер и следовательно может возникнуть культурный барьер. Появляется различие в часовых поясах, что не добавляет удобств.
4. Транcрегиональный трансфер - упаси боже вас в это влипнуть. Передача процесса из условной Европы в LatAm или APAC или из APAC в LatAM. Подразумевается что все знают английский язык и как-то можно передать процесс. Однако, есть нюансы. Во-первых часовые пояса становятся просто невыносимой проблемой, кто-то должен жертвовать work/life balance и рано вставать или допоздна работать (обычно страдает передающая сторона). Во вторых это культурные различия. Не сюрприз, что примерно 10,000 лет изолированного развития культур, наложили некоторые различия между странами, поэтому например добиться критики от Европейцев чуть сложнее чем от APAC или добиться вовлеченности от представителей LatAm это тот еще вызов. Сейчас можно подумать что автор нетерпим к другим национальностям, но это просто нюансы бизнеса, которые надо учитывать, даже книжки на эту тему есть.

Думаю на этом можно остановить перечислений основных категорий.

Tier List

Вот накидал я сверху этот список, несложно посчитать, что возможное количество вариантов стремиться к 60. По некоторым свойствам, не все варианты имеют право на жизнь, но как минимум несколько десятков можно накидать. Я люблю Tier List, поэтому вот тут его и изображу, просто потому что могу, и этой мой блог, кто мне может это запретить, кроме здравого смысла. Чтобы глаза не стремились друг к другу, пришлось оставить самые распространенные варианты.

Таблица приведена для развлечения и отражает субъективную перспективу автора. Думаю очевидно, что любой трансфер с нуля, внутри компании и одной страны имеет большие шансы на успех, чем что-либо остальное.

Кто виноват?

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

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

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

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

Основные проблемы трансфера

I. Люди - несмотря на наличие исключительной функции homo sapiens доносить информацию “словами через рот”, человек вопреки всему активно стремится использовать другие функциональные органы для того, чтобы обеспечить завершение задачи. При первой же неудобной ситуации возникают коммуникационные барьеры и на каждой стороне появляется присказка “а они там все редиски”, что в целом только подкрепляет негатив, который в итоге легко выливается в кучу потраченных денег без результата. Остается надеяться, что AI все поправит, но это не точно.

II. Амбиции - тех же самых людей, а точнее менеджеров (хотя возможно с причислением к людям я погорячился). Трансфер это обычно такого рода endgame. Вот у нас есть продукт, сроки, ресурсы - за N месяцев все передадим, наработаем клинические серии и запустим в коммерцию. На этом процессе завязана регистрация ЛП и последующий срок окупаемости продуктов. А еще конкуренты давят параллельно.

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

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

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

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

Ну и денюжки. Как-то так получается что CAPEX сваливается как снег на голову в РФ. Все его ожидают, но надеются до последнего, ну сейчас то он не выпадет. Принимающей стороне вечно не хватает какой-то НЁХ, которую внедрили мудрые разработчики, понятно что денег нет и приходится держаться.

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

Что делать?

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

Рецепт успеха трансфера это - найти время на подумать, а потом еще раз подумать, но уже всем вместе с командой. Записать о чем подумали и что решили, потом перечитать, согласовать с начальством и потом приступать к действиям. То есть не торопиться и спокойно двигаться в нужном направлении.

Разумеется сложно советовать пациенту с горящей жопой успокоиться и попросить подождать пока наряд по тушению приедет из соседнего села, поэтому к трансферу лучше готовиться заранее. СИЛЬНО ЗАРАНЕЕ. Осмелюсь предложить пару подходов, которые могут упростить весь процесс.

Решение №1. Вербальное

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

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

Небольшое дополнение: раз уж я коснулся разработчиков, есть один момент. Не стоит подпускать каких-то ученых-социофобов к общению с принимающей стороной. Обычно RU находит приличное количество изъянов в передаваемом процессе и разработчики это воспринимают как личное оскорбление. В итоге прямо на совещании начинается грызня и защита своего детища и всё превращается в ад.

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

Решение №2. Организационное

Трансфер это отдельный проект и им должна заниматься команда отдельно. Никаких- “ну там заодно что-то накалякаем”. Руководство обязано выделить рабочие часы под оформление документов, совещания и другую активность и желательно не отсвечивать при этом. Лучше вообще не грузить команду чем-то еще вообще, на удивление всегда найдется что сделать/обсудить и таким образом процесс пройдет намного быстрее. Также, чтобы было проще понимать кто за что ответственный можно сделать внезапно матрицу ответственности а-ля RACI. Да придется повозиться в начале, но зато поможет донести до вовлеченных лиц - кто за что отвечает.

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

Итого (а то сил уже читать это всё нет)

Вот вы потратили минут 15 осилить всё это и встает резонный вопрос: а ты чего к трансферу прикопался то, вроде везде похожие проблемы.

Произведение рисков (A x B), которые несет коммуникация между площадками и уже потраченных денег на продукт, кратно больше чем на любом другом этапе разработки препарата. Одно неосторожное слово разработчика, недооценённая серьезность параметра и вот уже последняя инженерка улетает в трубу вместе в остатками бюджета на проект. На этапе R&D еще не так много потрачено денег, а после трансфера, в производстве, рисков уже меньше.

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

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

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

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

Что почитать?

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

1. Рекомендация Коллегии ЕЭК от 08.06.2021 № 11 "О Руководстве по трансферу технологий и (или) аналитических методик при производстве лекарственных средств" - основной документ от которого стоит отталкиваться. Из минусов - документ основан (переведен) на старых версиях руководств от ISPE и ВОЗ. В принципе не критично, но в последних версиях оригиналов идет упор на риск-ориентированный подход, что является основной методологией в современных процессах. Именно в соответствии с этим документом у наших регуляторов будут возникать вопросы, поэтому стоит быть подкованным, если на вашем предприятии имплементируются несколько другие подходы
2. Good Practice Guide: Technology Transfer 3rd Edition | ISPE | International Society for Pharmaceutical Engineering - то самое руководство по трансферу. Да, чтобы почитать надо заплатить денюжку. Гайд удобен тем, что есть актуальные примеры документов.
3. WHO Expert Committee on Specifications for Pharmaceutical Preparations: fifty-sixth report (WHO Technical Report Series, No. 1044) - актуальная версия ВОЗ. Пару лет назад еще обновленный драфт новой версии подогнали. В целом документы сосредоточены больше на концепте, а не на актуальных примерах, но почитать на досуге лишним не будет.
4. ICH Q10 Pharmaceutical quality system - Scientific guideline | European Medicines Agency (EMA) - можно полистать Q10, где трансфер рассматривается как часть системы обеспечивающая качество продукта. Документу уже практически 20 лет, так что это просто для галочки.
5. Technology Transfer: Drug Product Manufacturing Process | SpringerLink - просто хорошая книга, с примерами, которая не бюрократическим языком описывает процессы трансфера, технологические нюансы, какие-то моменты для вышенаписанного опуса я взял из нее
6. Technology and Knowledge Transfer: Keys to Successful Implementation and Management | PDA - ссылку оставлю хотя сам не читал, книга не бесплатная, а репозитории пустые. Но имеются очень хорошие отзывы от коллег по цеху, вроде как с примерами “менеджмента неприятных ситуаций”. Если вдруг у читателя завалялась цифровая копия, буду рад принять в дар возмездно.

P.S.

Я начинающий специалист по трансферу, что делать?

Небольшой бонус от человека, который за 12 лет видел и слышал всякого, чего бы он не хотел видеть и слышать - если вдруг на этот трактат о величии воли в технологическом трансфере наткнулся специалист, которому вчера поручили организовать передачу процесса из круга ада A в круг ада B.

Вариант 1. Вы работаете в большой компании с опытом трансфера.

Под большой компанией, имеется ввиду, что у компании есть кое какой опыт. Вас не оставят без поддержки, есть СОПы и инструкции и какой никакой начальник. От вас требуется изучить имеющиеся процессы, посмотреть документы от предыдущих трансферов, возможно придется потратить свободное время, но оно того стоит. Главное подключить свои софт скиллы для организации команд, которые я упоминал выше и будет вам счастье.

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

Если вам не дали в руководители опытного менеджера с офигенным опытом работы и в штате нет опытных сотрудников ООК знакомых с трансфером (это правда важно, чтобы люди не думали исключительно производственными кальками) - бегите. Оно того не стоит. Придется учиться на собственных болячках и нервных клетках. В итоге конечно результат будет, но весь заработок придется спустить на психолога/психиатра. Но конечно выбор всегда за вами. Кто я такой, чтобы запрещать вам страдать.

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