چرا پروژه های انتقال تکنولوژی شکست می خورند؟
چرا پروژه های انتقال تکنولوژی شکست می خورند؟
وقتی دانش فنی منتقل می شود، اما توانمندی اجرایی اثبات شده نه
در نگاه اول، پروژه های انتقال تکنولوژی شبیه یک فرایند فنی به نظر می رسند: فرمولاسیون، دستور ساخت، پارامترهای فرایند، مستندات، اعتبارسنجی و در نهایت تولید موفق در مقیاس تجاری. اما در عمل، بسیاری از پروژه ها نه به دلیل ندانستن، بلکه به دلیل ناتوانی در تبدیل دانش به توانمندی اجرایی اثبات شده با مشکل مواجه می شوند.
بر اساس راهنمای WHO (TRS 1044, Annex 4, 2022)، انتقال تکنولوژی یک فرایند سیستماتیک برای انتقال محصولات، فرایندها، دانش، مستندات و تخصص حرفه ای است؛ نه صرفا جابه جایی چند سند از واحد فرستنده به واحد پذیرنده. بنابراین، اگر بخواهیم واقع بینانه نگاه کنیم، ضعف ارتباطات تنها علت شکست نیست؛ اما یکی از مهم ترین عواملی است که می تواند انتقال دانش، فرض ها، ریسک ها و مسئولیت ها را مختل کند و توانمندی واحد پذیرنده را برای اجرای پایدار فرایند کاهش دهد.
انتقال تکنولوژی، چیزی فراتر از مستندات است
یکی از خطاهای رایج این است که انتقال تکنولوژی را معادل تحویل مستندات بدانیم. مستندات ضروری است، اما کافی نیست. در عمل، یک زنجیره حیاتی وجود دارد:
انتقال مستندات ← انتقال دانش ← آموزش و درک فرایند ← اثبات توانمندی ← فرایند قابل بازتولید
Documentation ≠ Knowledge ≠ Demonstrated Capability
داشتن سند، لزوما به معنای فهمیدن نیست؛ فهمیدن هم لزوما به معنای توانستن نیست؛ و توانستن در مقیاس آزمایشگاهی، لزوما به معنای توانایی تولید پایدار در مقیاس تجاری نیست.
نکته مهم این است که این زنجیره یک رابطه خطی یک طرفه نیست. در رویکرد Lifecycle، این یک چرخه بازخورد است:
Knowledge ↔ Process Understanding ↔ Control Strategy ↔ Validation ↔ Monitoring ↔ New Knowledge
ICH Q10 نیز انتقال تکنولوژی را بخشی از Pharmaceutical Quality System می داند که در آن دانش حاصل از توسعه و انتقال، پایه ی طراحی فرایند تولید، استراتژی کنترل و اعتبارسنجی فرایند را تشکیل می دهد.
در ادبیات رسمی انتقال تکنولوژی، معمولا از دو مفهوم کلیدی استفاده می شود:
- Sending Unit (SU): واحدی که دانش، فرایند و مسئولیت انتقال را بر عهده دارد.
- Receiving Unit (RU): واحدی که باید توانایی اجرای پایدار فرایند را به دست آورد.
موفقیت انتقال تکنولوژی فقط زمانی معنا پیدا می کند که RU بتواند فرایند را به صورت مستمر، تحت استراتژی کنترل تعریف شده و در چارچوب الزامات کیفیت و رگولاتوری بازتولید کند. البته این یکی از مهم ترین معیارهای موفقیت است، نه تنها معیار؛ چرا که WHO بر برنامه ریزی پروژه، معیارهای پذیرش از پیش تعریف شده، اعتبارسنجی، مستندات و نظارت کیفی نیز تاکید دارد.
ارتباطات کجا واقعا اهمیت پیدا می کند؟
در پروژه های انتقال تکنولوژی، ارتباط فقط به معنای برگزاری جلسه یا ارسال ایمیل نیست. ارتباط موثر یعنی ایجاد درک مشترک بین واحدهایی که هر کدام زبان، اولویت و نگرانی متفاوتی دارند:
- SU ↔ RU
- توسعه ↔ تولید
- QA/QC ↔ تولید
- مهندسی ↔ تولید
- رگولاتوری ↔ تیم های فنی
واحد توسعه معمولا از فرمولاسیون، پارامترهای بحرانی و منطق طراحی صحبت می کند. واحد تولید نگران قابلیت اجرا، پایداری خط، ضایعات و زمان تغییر است. کنترل کیفیت بیشتر به انتقال روش های تحلیلی، نمونه برداری، مشخصات، آزمون ها و آمادگی آزمایشگاه توجه دارد. تضمین کیفیت بر مدیریت ریسک، کنترل تغییر، انحرافات، مستندات و انطباق با GMP تمرکز دارد. واحد رگولاتوری نیز به اثر تغییرات بر پرونده ثبتی، مشخصات، روش ها و تعهدات نظارتی توجه می کند.
وقتی این واحدها فقط اطلاعات رد و بدل کنند، اما با هم به درک مشترک نرسند، پروژه ممکن است روی کاغذ پیش برود، اما در واقعیت متوقف شود.
چهار شکست ارتباطی پنهان
در تجربه های اجرایی و مشاوره ای، چند الگوی تکراری دیده می شود که لزوما در ابتدای پروژه خودشان را نشان نمی دهند، اما در مراحل بعدی هزینه ساز می شوند.
۱. فرض های بیان نشده هر فرض یا ویژگی فرایندی که بر کیفیت، ایمنی یا انطباق موثر است، باید شناسایی و بر اساس اهمیت و ارزیابی ریسک اولویت بندی شود. اگر فرضی بحرانی باشد ولی منتقل نشود، می تواند به یک ریسک پنهان تبدیل شود.
۲. مسئولیت های نامشخص بسیاری از مشکلات انتقال تکنولوژی در ناحیه خاکستری بین واحدها رخ می دهند. چه کسی مسئول تایید یک پارامتر بحرانی است؟ چه کسی ریسک تغییر در مقیاس را می پذیرد؟ اگر این مرزها از ابتدا روشن نباشند، پروژه وارد چرخه ای از جلسات تکراری و تاخیرهای پیاپی می شود.
۳. منتقل نشدن «چرایی» فرایند اگر واحد پذیرنده نداند چرا یک پارامتر حساس است یا چرا یک مرحله کنترلی اضافه شده، ممکن است در عمل آن را ساده سازی کند. انتقال تکنولوژی موفق، فقط انتقال «چه کاری» نیست؛ انتقال «چرایی» و منطق پشت تصمیم ها نیز هست.
۴. تاخیر در تصمیم گیری و escalation مسئله اصلی فقط شفاهی بودن تصمیم نیست؛ مسئله نبود traceability در سیستم کیفیت است. تصمیم هایی که بر کیفیت، اعتبارسنجی یا وضعیت رگولاتوری اثر می گذارند باید مستند، قابل ردیابی و در صورت نیاز از مسیر کنترل تغییر یا مدیریت انحراف عبور کنند.
پشتوانه رگولاتوری: یک چارچوب یکپارچه، نه یک چک لیست
برای اینکه انتقال تکنولوژی فقط یک گفت وگوی مدیریتی باقی نماند، باید به چارچوب های شناخته شده کیفیت و رگولاتوری متصل شود. اما نکته مهم این است که این عناصر مستقل از یکدیگر نیستند؛ بلکه باید در قالب یک برنامه یکپارچه انتقال تکنولوژی و مبتنی بر مدیریت ریسک مدیریت شوند:
Gap Analysis (شناخت تفاوت های فنی، کیفی، رگولاتوری، تجهیزات، تاسیسات، سیستم های کامپیوتری، HSE و صلاحیت نیروی انسانی بین SU و RU) ← Quality Risk Management بر اساس ICH Q9(R1) (شناسایی و ارزیابی ریسک ها) ← Control Strategy و Change Control (کنترل و رفع تفاوت ها) ← Qualification و Validation (اثبات توانمندی RU) ← Continued Verification (پایش مستمر و بهبود)
در این چارچوب، Control Strategy یک مجموعه برنامه ریزی شده از کنترل هاست که از درک فعلی محصول و فرایند مشتق می شود و شامل کنترل ویژگی های مواد، پارامترهای فرایند، کنترل های درون فرایندی، مشخصات و سایر کنترل های مرتبط است. CQAها و CPPها اجزای Control Strategyنیستند؛ بلکه بخشی از درک محصول و فرایند هستند که Control Strategy بر اساس آن ها طراحی می شود.
همچنین، نقطه پایانی انتقال تکنولوژی Validation نیست. داده های حاصل از scale-up، PPQ و تولید تجاری باید به چرخه monitoring و continual improvementبازگردند.
حالت خاص: محصولات پرخطر (Hazardous Products)
وقتی انتقال تکنولوژی شامل محصولات پرخطر می شود، موضوع حساس تر می شود. در این موارد، صرفا طبقه بندی خطر کافی نیست. باید با تکیه بر HBEL/PDE، ارزیابی ریسک آلودگی متقابل، استراتژی containment، کنترل های مهندسی و سازمانی و الزامات نظارتی، سطح کنترل متناسب با ریسک تعیین شود.
در چنین پروژه هایی، انتقال منطق پاک سازی نیز اهمیت ویژه ای دارد:
HBEL → Risk Assessment → Scientifically Justified Cleaning Limits → Cleaning Strategy → Sampling & Analytical Method → Validation/Verification → Cross-contamination Control
اگر این زنجیره به درستی منتقل و اثبات نشود، ممکن است واحد پذیرنده فرایند را اجرا کند، اما کنترل کافی بر ریسک آلودگی متقابل نداشته باشد.
یک مشاهده اجرایی: وقتی یک فرض ساده پرهزینه می شود
در یکی از تجربه های اجرایی، مشاهده کردم که پروژه انتقال تکنولوژی از نظر مستندات تقریبا آماده بود، اما در مرحله scale-up با تاخیر جدی مواجه شد. در بررسی های اولیه، تصور می شد مشکل از تجهیزات یا روش ساخت است. اما پس از چند جلسه کارشناسی مشخص شد که یک فرض فرایندی در تیم توسعه معتبر بوده، اما در مقیاس تجاری به دلیل تفاوت در دینامیک تجهیزات و فرایند، دیگر همان اعتبار را نداشته است.
Scale-up فقط یک مسئله ارتباطی نیست. تغییر مقیاس می تواند به دلایلی مانندmixing، انتقال حرارت، انتقال جرم، shear، زمان ماند، هندسه تجهیزات، ترتیب افزودن مواد، hold time و ویژگی های مواد، رفتار فرایند را تغییر دهد. اما اگرrationale و ریسک این فرض ها به درستی منتقل و ارزیابی نشده باشد، مشکل تشدید می شود.
پنج توصیه کاربردی
۱. انتقال تکنولوژی را از ابتدا یک پروژه بین واحدی ببینید.حضور زودهنگام تولید، کیفیت، مهندسی و رگولاتوری در کنار تیم توسعه هزینه نیست؛ سرمایه گذاری برای کاهش دوباره کاری است.
۲. Gap Analysis را جدی بگیرید. قبل از شروع انتقال، تفاوت های فنی، کیفی، رگولاتوری، تجهیزات، تاسیسات، HSE، روش های تحلیلی، صلاحیت نیروی انسانی و وضعیت اعتبارسنجی بین SU و RU ارزیابی شود.
۳. فرض ها و منطق تصمیم ها را مستند کنید. هر فرضی که ممکن است بر کیفیت، فرایند یا انطباق اثر بگذارد باید شناسایی، ارزیابی و در صورت نیاز کنترل شود.
۴. ارتباط موثر درباره ریسک ها و انتقال دانش مرتبط با آن ها، بخشی از انتقال دانش است. اگر واحد پذیرنده نداند کدام ریسک ها مهم هستند و چرا کنترل شده اند، ممکن است ناخواسته آن ها را بازتولید کند.
۵. موفقیت را با Demonstrated Capability واحد پذیرنده تعریف کنید. موفقیت انتقال تکنولوژی زمانی است که واحد پذیرنده بتواند فرایند را به صورت مستمر، تحت استراتژی کنترل تعریف شده و در چارچوب الزامات کیفیت و رگولاتوری بازتولید کند؛ و این توانمندی باید با شواهد اثبات شود، نه صرفا با ادعا.
نتیجه گیری
انتقال تکنولوژی موفق، فقط انتقال فرمولاسیون، دستور ساخت یا مستندات نیست. انتقال تکنولوژی زمانی کامل می شود که دانش، منطق تصمیم ها، ریسک ها، استراتژی کنترل و توانمندی اجرایی به واحد پذیرنده منتقل شود؛ و این توانمندی باید قابل اثبات باشد.
انتقال تکنولوژی زمانی موفق است که واحد پذیرنده نه تنها فرایند را بفهمد، بلکه بتواند آن را به صورت مستمر، تحت استراتژی کنترل تعریف شده و در چارچوب الزامات کیفیت و رگولاتوری بازتولید کند؛ و شواهد این توانمندی را ارائه دهد.
بنابراین، اگر می خواهیم پروژه های انتقال تکنولوژی کمتر شکست بخورند، باید بیش از آنکه فقط روی مستندات تمرکز کنیم، روی ایجاد درک مشترک، مدیریت ریسک، شفافیت مسئولیت ها و اثبات توانمندی واحد پذیرنده تمرکز کنیم.
منابع
- WHO TRS 1044, Annex 4 — Guidelines on Technology Transfer in Pharmaceutical Manufacturing, 2022
- ICH Q10 — Pharmaceutical Quality System
- ICH Q9(R1) — Quality Risk Management
- ICH Q8(R2) — Pharmaceutical Development
- EU GMP / EudraLex Volume 4, Chapter 5 — Production
- EMA Guideline on setting health-based exposure limits (HBEL) & EMA Q&A on HBEL/Cross-contamination