Kontrolü değiştir

Bu konu, şu konunun bir parçasıdır: SG Systems Global Düzenleme ve operasyon kılavuzu kütüphanesi.

Değişiklik Kontrolü: Etkiyi değerlendirerek, değişiklikleri onaylayarak ve sonuçları kanıtlayarak kontrolsüz sapmaları önlemek.

Ocak 2026'da güncellendi • Değişiklik kontrolü, MOC, etki değerlendirmesi, CCB, CSV, belge kontrolü, risk matrisi • Sektörler arası

Değişiklik kontrolü , ürün kalitesini, hasta/müşteri güvenliğini, uyumluluğu veya operasyonel performansı etkileyebilecek değişikliklerin önerilmesi, değerlendirilmesi, onaylanması, uygulanması ve doğrulanması için belgelenmiş bir süreçtir. Bu, "süreci iyileştirdik" ile "bir şeyi değiştirdik ve şimdi sonuçlarını açıklayamıyoruz" arasındaki farktır.

Düzenlemeye tabi ortamlarda—ilaç sektörü ( 21 CFR Bölüm 211 ), tıbbi cihazlar ( 21 CFR Bölüm 820 , ISO 13485 ) ve Ek 11 gibi elektronik kayıt beklentileri —değişiklik kontrolü isteğe bağlı değildir. Onaylanmış bir durumun gayri resmi bir çözüm yolları topluluğuna dönüşmesini engellemenin yolu budur.

Değişiklik kontrolü sadece "kalite güvence evrak işi" değildir. Bu, üretim kontrolü ve işletme kontrolüdür. Güvenilir bir iz bırakmadan bir reçeteyi, ayar noktasını, test yöntemini, tedarikçiyi veya sistem yapılandırmasını değiştirebiliyorsanız, tasarım gereği kırılgan bir operasyonunuz var demektir. Güçlü kontrol, istikrarlı bir temel ve daha hızlı incelemeler sağlar.

Bu durum doğrudan veri bütünlüğüyle de bağlantılıdır . Kontrolsüz değişiklikler sadece süreci değil, kanıtları da değiştirir. Bir çalışma sayfası şablonunun ne zaman değiştirildiğini, bir rapor mantığının ne zaman değiştirildiğini veya bir erişim rolünün ne zaman güncellendiğini kanıtlayamazsanız, kanıtlarınız tartışılabilir hale gelir. Düzenlemeye tabi üretimde, tartışılabilir kanıtlar bir yükümlülüktür.

"Zamanı donduramadığınız bir süreci savunamazsınız."

1) Değişiklik kontrolü aslında ne anlama geliyor?

Değişiklik kontrolü, ürün üretme, test etme, piyasaya sürme ve destekleme süreçlerinin temelini değiştirmenin kontrollü yoludur. Temel, sadece "standart işletim prosedürü" (SOP) değildir. Gerçekliği tanımlayan kontrollü unsurların tamamıdır: özellikler, çalışma talimatları, ana veriler, ekipman ayarları, yazılım yapılandırması, etiket sürümleri, eğitim kuralları ve olanları kanıtlayan kayıtlar.

İyi bir süreç, beş soruyu açık ve tutarlı bir şekilde yanıtlar:

• Değişen nedir? Mevcut durumu ve önerilen durumu belirtin. Belirsiz ifadelerden kaçının.
• Neden değişiyor? İyileştirme, eskime, düzeltici eylem, uyumluluk, kapasite, maliyet—tetikleyici faktörü belirtin.
• Bu durum neleri etkileyebilir? Ürün kalitesi, güvenliği, doğrulama durumu, düzenleyici yükümlülükler, veri bütünlüğü, tedarik zinciri.
• Sahibi kim? Tek bir sorumlu sahip ve tanımlanmış değerlendiriciler; "herkes" ifadesi hiç kimsenin olmadığını gösterir.
• Bunun işe yaradığını nasıl kanıtlayacağız? Önceden tanımlanmış doğrulama, kabul kriterleri ve kanıtlar.

Değişiklik kontrolü aynı zamanda "kolay yollara" karşı da bir koruma sağlar. Eğer birisi kontrollü bir kayıt olmadan bir parametreyi ayarlayabilir, bir şablonu düzenleyebilir veya bir yapılandırmayı değiştirebilirse, sonunda kendi içinde tutarsız kayıtlar elde edersiniz. Bu durumda, dürüst insanlar bile dürüst görünmeyebilir çünkü kanıtlar artık tutarlı bir hikaye anlatmaz.

2) Değişiklik kontrolünün neden müzakere edilemez olduğu

Karmaşık üretim sistemleri tahmin edilebilir şekillerde başarısız olur: küçük varyasyonlar birikir, geçici çözümler yayılır ve gerçek süreç onaylanmış süreçten uzaklaşır. Değişiklik kontrolü olmadan, bu sapma, yeniden oluşturulamayan bir arıza yaratana kadar görünmez kalır.

Değişiklik kontrolünü zorunlu kılan dört etken vardır:

Acı gerçek şu: Değişimi kontrol edemeyen bir kuruluş, sonunda doğru değişim kontrolü yapmaktan daha fazla zamanı araştırma, yeniden düzenleme ve savunma ile geçirecektir. Başarısızlıklar biriktikçe "daha hızlı" olan şey yavaşlar.

3) Değişiklik kontrolü vs MOC vs DCR

Ekipler bu terimleri sıklıkla birbirine karıştırır, bu da kafa karışıklığına ve yanlış yönlendirilmiş işlere yol açar. Net bir yönlendirme, süreci daha hızlı ve temiz hale getirir.

Olgun bir sistemde, DCR (Belge Kontrol ve Yeniden Yapılandırma) işe başlama yönteminizdir, değişiklik kontrolü (Change Control) işi yönetme yönteminizdir ve MOC (Movement Control) ise değişikliğin operasyonel veya güvenlik sonuçları olduğunda daha derinlemesine risk analizi yapma yönteminizdir. Onaylanmış durumun sürümlendirilebilmesi ve erişilebilir olması için belge kontrolü ve revizyon kontrolü kullanın.

4) Kapsamı tanımlayın: Hangi değişikliklerin kontrol edilmesi gerekiyor?

Kapsam, değişiklik kontrolünün ya güçlü ya da anlamsız hale geldiği noktadır. Kapsam çok dar olursa, önemli değişiklikler kontrolden çıkar. Kapsam çok geniş olursa, süreç bir darboğaz haline gelir ve insanlar onu atlar. Amaç basittir: riske orantılı olarak doğru şeyleri kontrol etmek.

En azından, kapsam açıkça şunları içermelidir:

• Kontrollü belgeler: Standart işletim prosedürleri (SOP'ler), iş talimatları, teknik şartnameler ve formlar kapsamında Doküman Kontrolü.
• Proses ve ekipman ayarları: Ayar noktaları, tarifler, aletler, kalibrasyon yaklaşımları, yardımcı programlar ve bakım stratejileri.
• Ürün tanımı: Malzeme listeleri, formülasyonlar, etiketleme, ambalaj tasarımı, kabul kriterleri ve test yöntemleri.
• Bilgisayarlı sistemler: Yapılandırma, arayüzler, raporlar, yamalar ve erişim modelleri (CSV etkisi).
• Tedarikçiler ve malzemeler: Tedarikçi onayları, ikame işlemleri ve gelen doğrulama süreçlerindeki değişiklikler.
• Eğitim ve yetkilendirme: Kime ne yapma yetkisi veriliyor ve bu yetkinliği destekleyen kanıtlar neler?

Tipik tetikleyiciler konusunda kapsam açık olmalıdır, böylece koridorda daha az tartışma ve "duruma bağlı" ifadesi yaşanır. Basit bir değişiklik türü haritası, ekiplerin işleri doğru şekilde yönlendirmesine yardımcı olur:

"Gizli katmanı" göz ardı etmeyin. Serbest bırakma değerlerini hesaplamak için bir elektronik tablo kullanılıyorsa, yerel bir veritabanı partileri takip ediyorsa veya resmi olmayan bir gösterge paneli kararları yönlendiriyorsa, bunlar etkili sürecinizin bir parçasıdır. Gizli sistemleri kapsam dışında bırakmak, kontrolsüz sapmalara ve veri bütünlüğü hatalarına davetiye çıkarmaktır.

5) Risk temelli düşünme: etki, olasılık, tespit edilebilirlik

Risk tabanlı değişiklik kontrolü, düşük riskli işlerin ilerlemesini sağlarken, yüksek riskli değişiklikler için titizliği zorunlu kılar. Mekanizma basit olabilir, ancak tutarlı olmalıdır. Bir risk matrisi, ekiplerin baskı altında Cuma günü verecekleri kararı Pazartesi günü de vermelerine yardımcı olur.

Risk sınıflandırmasının büyük çoğunluğunu üç soru belirler:

• Etki: Değişiklik başarısız olursa, en kötü olası sonuç ne olur?
• Olasılık: Karmaşıklık, yenilik ve kontrol gücü göz önüne alındığında, başarısızlık olasılığı ne kadar yüksek?
• Tespit edilebilirlik: Ürün müşteriye/hastaya ulaşmadan önce hatayı tespit edebilir miydiniz?

Tıbbi cihazlar için, ISO 14971 gibi ürün risk yönetimi mantığına uygun bir yaklaşım benimseyin . İlaç ve diğer GxP ortamları için ise, ICH Q10 gibi kalite çerçevelerinden ve ICH Q7'den üretim kalitesi beklentilerinden elde edilen kalite risk yönetimi prensiplerini ve beklentilerini kullanın.

Risk ölçeklendirmesini gerçekçi hale getirmenin pratik bir yolu, ekibin her seferinde temel unsurlar üzerinde pazarlık yapmasına gerek kalmaması için "risk sınıfı → minimum kontroller" şeklinde bir tanım yapmaktır:

6) Yönetim: Sahipler, CCB ve kayıt disiplini

Değişiklik kontrolü yönetimi, karar alma yetkisi ve hesap verebilirliğin birleşimidir. İkisi olmadan onaylar göstermelik hale gelir: imzalar vardır, ancak kimse aslında neyin değerlendirildiğini açıklayamaz. Güçlü bir yönetim aynı zamanda, gözden geçirenlerin sadece birikmiş işleri azaltmak için imza attığı "yorgunluktan onay" durumunu da önler.

Minimum yönetim ölçütleri:

• Değişiklik sahibinin adı: Değerlendirme kalitesi, uygulama koordinasyonu ve kapanış kanıtlarından sorumludur.
• Kalite denetimi: Uyumluluğun, kayıt disiplininin ve risk ölçeklendirmesinin tutarlı bir şekilde uygulanmasını sağlar.
• İşlevler arası inceleme: Kapsam ve risk kriterlerine göre (üretim, mühendislik, doğrulama, BT, mevzuat, tedarik zinciri) dahil edildiler.
• Risk bazlı onay süreci: Küçük değişiklikler hızlıca yönlendirilebilir; büyük değişiklikler ise uzun bir süreçten geçer. CCB.
• Kontrollü sürümler: Değişiklikler, kontrol edilen öğeleri güncellemelidir. revizyon kontrolü.

Basit bir RACI tarzı bakış açısı, kafa karışıklığını ve görevlerin atlanmasını önler (bu bir örnek modeldir; kendi gerçekliğinize göre uyarlayın):

CCB'nin görevi biletleri onaylamak değildir. Görevi temel çizgiyi korumaktır: işleri önceliklendirmek, çatışmaları çözmek, test kapsamına açıklık getirmek ve kuruluşun güvenli bir şekilde kaldıramayacağı değişiklikleri durdurmaktır. Zayıf bir CCB sadece onay verir; güçlü bir CCB ise öngörülebilir hataları önler.

7) Değişiklik kontrol yaşam döngüsü (baştan sona)

Güvenilir bir yaşam döngüsü basit, tekrarlanabilir ve denetlenebilir olmalıdır. Süslü bir araca ihtiyaç duymaz, ancak kapanış standartlarına ihtiyaç duyar. Eğer kuruluşunuz yaşam döngüsünü bir dakikada açıklayamıyorsa, süreç tutarlı bir şekilde yürütülemeyecek kadar karmaşıktır.

En önemli yaşam döngüsü koruma kuralı sıralamadır: Acil olmayan değişiklikler onaylanmadan uygulanmamalıdır. "Şimdi uygula, sonra belgele" yaklaşımı, temel bütünlüğü kaybetmenize ve kanıtlanamaz geçmişler oluşturmanıza neden olur. Etkili değişiklikleri, işi yürüten ve inceleyen kişilere açıkça iletin.

8) Etki değerlendirmesi: Her seferinde kontrol etmeniz gerekenler

Etki değerlendirmesi, değişiklik kontrolünün önemini gösterdiği noktadır. Değerlendiricilerin neyin değerlendirildiğini ve neyin değerlendirilmediğini görebilmesi için serbest biçimli değil, yapılandırılmış olmalıdır. Sonuç bir karardır: neyin değiştirilmesi, neyin test edilmesi ve hangi kanıtların saklanması gerektiği.

Her etki değerlendirmesi en azından şu konuları ele almalıdır:

• Ürün ve süreç: Kritik parametreler, kabul kriterleri, verim, değişkenlik ve serbest bırakma kararları üzerindeki etkisi.
• Kalite sistemi: Hangi standart işletim prosedürleri/formlar/şartnameler değişiyor ve nasıl? Doküman Kontrolü Geçerlilik tarihlerini yöneteceğiz.
• Doğrulama durumu: ekipman yeterliliği, süreç validasyonu ve üzerindeki etkisi CSV varsayımlar.
• Veri bütünlüğü: hesaplamalar, inceleme yolları ve kanıt nitelikleri üzerindeki etki (ALCOA düşüncesi; bkz.) ALKOL).
• Elektronik kayıtlar: üzerindeki etkisi denetim izlerizaman damgaları ve E-imza anlamına gelir.
• Tedarikçi/malzeme etkisi: Kimlik, saflık, etki/performans ve karşılaştırılabilirlik kanıtları üzerindeki etkisi.
• Düzenleyici/piyasa etkisi: Taahhütler, etiketleme iddiaları veya müşteri/düzenleyici beklentileri üzerindeki etkisi.

Ayrıca “etkin kapsam”ı da tanımlayın. Değişiklik ne zaman geçerli olacak: bir sonraki parti, bir sonraki lot, belirli bir tarih, belirli bir satır, belirli bir tesis? Belirsiz kapsam, özellikle aynı zaman diliminde bir belgenin veya konfigürasyonun birden fazla sürümü mevcut olduğunda, daha sonra belirsiz soruşturmalara yol açar.

Değişiklik düzeltici nitelikteyse, onu gizlemeyin. Değişiklik kaydını, başlatıcı kalite olayına (sapma, uygunsuzluk, CAPA) bağlayın. Bu şekilde, kuruluşun sadece "bir belgeyi güncellemek" yerine, öğrendiğini ve geliştiğini kanıtlamış olursunuz.

9) Doğrulama ve geçerlilik stratejisi

Onaylar kanıt değildir. Değişiklik kontrolü, hangi doğrulamanın gerekli olduğunu ve hangi kanıtların saklanacağını tanımlamalıdır. Derinlik riske bağlıdır, ancak karar açık olmalıdır. "Yapabildiğimiz her şeyi test ettik" bir strateji değil, bir özürdür.

Tipik doğrulama/geçerlilik bileşenleri şunlardır:

• Belge doğrulama: Doğru revizyonlar, referanslar ve geçerlilik tarihleri; kontrollü dağıtım.
• Teknik doğrulama: Yapılandırma kontrolleri, parametre kontrolleri, kalibrasyon kontrolleri ve derleme kontrolleri.
• Operasyonel kontroller: Değişiklik devreye girdikten sonra deneme çalışmaları veya hedefli süreç içi kontroller.
• Sistem testi: Yazılım için, risk tabanlı testler şu şekilde uyarlanmıştır: Gamp 5.
• Kullanıcı kabulü: Amaçlanan kullanımın desteklendiğini doğrulayın (bkz. UAT).

Niteliklendirme dili uygun olduğunda, IQ ve OQ kavramlarını kullanarak çalışmalarınızı yapılandırın ve yaklaşımınızı Doğrulama Ana Planınızda (VMP) temellendirin . Bir sistem değişikliği gereksinimleri değiştiriyorsa, kanıtlarınız neyin değiştiğini, nasıl test edildiğini ve nasıl onaylandığını göstermelidir.

Son olarak, gerilemeyi planlayın. Tekrarlayan bir sapma yaratmanın en hızlı yolu, bir şeyi değiştirip farkında olmadan bitişik bir şeyi bozmaktır. Risk tabanlı gerileme testi, "her şeyi test et" anlamına gelmez; "değişikliğin nasıl yayılabileceğine bağlı olarak önemli olan şeyleri test et" anlamına gelir.

10) Saklanacaklar: Değişiklik kontrolü kanıt paketi

Değişiklik kontrolü, ancak gösterebildikleriniz kadar güçlüdür. Her değişiklik kaydının dedektiflik çalışmasına gerek kalmadan savunulabilir olması için standart bir kanıt paketi oluşturun. Bir değişikliği açıklamak için üç kişiye ve bir dosya aramasına ihtiyacınız varsa, kayıt disiplininiz çok zayıftır.

Önerilen delil paketi içeriği:

• Değişiklik talebi: Tanım, gerekçe, kapsam, sınıflandırma ve risk düzeyi.
• Etki değerlendirmesi: Net sonuçlar ve gerekli eylemlerle tamamlanmış değerlendirme.
• Onaylar: Risk düzeyine uygun onaylar (kullanıldığı durumlarda CCB kararları dahil).
• Güncellenmiş kontrollü öğeler: Gözden geçirilmiş standart işletim prosedürleri/teknik özellikler/formlar, kontrollü konfigürasyonlar ve temel referans noktaları.
• Doğrulama/geçerlilik kanıtı: Test kayıtları, sonuçları, sapmaları ve çözümleri.
• Eğitim kanıtları: Etkin kullanım için gerekli eğitimin tamamlanması gerekmektedir.
• Sürüm ayrıntıları: Yürürlüğe giriş tarihi, etkilenen siteler/hatlar ve aşamalı devreye alma kararları.
• Kapanış bildirisi: Tüm işlemlerin tamamlandığı ve açık risk kalmadığı teyit edildi.

Değişiklik elektronik kayıtları etkiliyorsa, kanıt zincirinin hala çalıştığına dair açık kanıtlar sunun: denetim izi incelemesi, önemli rapor kontrolleri ve elektronik imzaların hala doğru şekilde bağlandığının teyidi. İşte bu şekilde "başarılı bir güncellemenin" uyumluluk hatasına dönüşmesini önleyebilirsiniz.

11) Bilgisayarlı sistemler ve otomasyon değişiklikleri

Yazılım ve otomasyon, davranışları sessizce ve büyük ölçekte değiştirebilir. Sistem değişiklik kontrolünü bir BT formalitesi olarak değil, yüksek kaldıraçlı bir kontrol olarak ele alın. Tek bir yapılandırma güncellemesi, her bir toplu işlemin nasıl yürütüleceğini veya her bir kaydın nasıl oluşturulacağını değiştirebilir.

Daha sıkı kontroller gerektiren değişikliklere örnekler:

• MES güncellemeleri: yamalar ve yükseltmeler (bkz. MES yama yönetimi hem de MES siber güvenlik kontrolleri).
• Yürütme kayıtları: elektronik parti kayıtları ve cihaz geçmişi yürütmesi (bkz. eDHRÇünkü kayıt mantığı, kalite mantığıdır.
• Veri akışları ve entegrasyonları: arayüzler ERP, LIMS, ve eQMS.
• Bağlantı katmanları: OPC UA, ModBus TCP, ve mesaj aracıları.
• Güvenlik modelleri: Ayrıştırma ve onayları etkileyen rol/izin değişiklikleri.
• Raporlama mantığı: Hesaplamalarda, sorgularda ve "resmi" raporlarda yapılan değişiklikler.

Doğrulama, yalnızca çalışma süresini değil, kontrolleri de içermelidir: roller hala doğru şekilde çalışıyor mu, denetim kayıtları hala olayları yakalıyor mu, zaman damgaları tutarlı kalıyor mu, elektronik imza istemleri hala anlamlı mı ve sistemler arası mutabakatlar hala dengeli mi? Test planınız bunları kontrol etmiyorsa, kanıtları korumuyor demektir.

Son olarak, değişiklik kurtarma yollarını etkiliyorsa, bunu yedekleme doğrulaması , yüksek kullanılabilirlik veya felaket kurtarma gibi dayanıklılık kontrollerine bağlayın . Öngörülebilir şekilde geri yükleyemediğiniz bir sisteme güvenemezsiniz.

12) Tedarikçi ve dış kaynaklı değişiklikler

Tedarikçi değişiklik kontrolü, kalite ve tedarik zincirinin ya iş birliği yaptığı ya da risk yarattığı alandır. Değişiklik ürününüzü veya kanıtlarınızı etkiliyorsa, "Değişiklikten haberimiz yoktu" savunulabilir bir cevap değildir. Kalite anlaşmalarına beklentileri dahil edin: önceden bildirim, değişiklik açıklamaları, karşılaştırılabilirlik kanıtları ve denetim hakkı maddesi.

Tedarikçiyle ilgili kontrol edilmesi gereken değişiklikler arasında yeni tedarikçiler/tesisler, malzeme ikameleri, tedarikçi süreç değişiklikleri, spesifikasyon/test değişiklikleri ve koşulları değiştiren lojistik/depolama değişiklikleri yer almaktadır. Bu değişiklikler, tedarikçi denetim programı ve satıcı yeterlilik değerlendirmesi gibi yeterlilik ve izleme kontrolleriyle bağlantılı olmalıdır . Önemli olan dahili izlenebilirliktir: Tedarikçi değişikliği, belgelenmiş etki değerlendirmesi ve kabul kriterleriyle birlikte dahili bir değişiklik kaydına eşleştirilmelidir.

Dış kaynaklı işler de aynı disiplini gerektirir. Harici bir laboratuvar bir yöntemi değiştirirse, bir sözleşmeli üretici bir süreci değiştirirse veya bir yazılım tedarikçisi barındırılan bir kalite sistemini değiştirirse, risk yine de size aittir. Dahili değişiklik kontrol kaydınız, etkiyi kasıtlı olarak değerlendirdiğinizi ve kabul ettiğinizi kanıtlar.

13) Acil değişiklikler ve “geçici” çözümler

Acil değişiklikler olur. Kontrol, "asla acil değişiklik yapmayın" demek değildir. Kontrol, "acil durumun bir açık haline gelmesine izin vermeyin" demektir. Her acil değişiklik, en az getirdiği risk kadar güçlü bir iz bırakmalıdır.

Savunulabilir bir acil durum yolu şunları içerir: net kriterler, minimum onaylar, acil dokümantasyon, zaman sınırlaması, zorunlu değişiklik sonrası doğrulama ve acil durum bir arızadan kaynaklanıyorsa kalite olaylarına bağlantı (bkz. kalite olay yönetimi ). Değişiklik sonrası kayıt, o anda yapmaya zamanınız olmayan tam etki değerlendirmesini yaptığınız yerdir.

14) Performans göstergeleri ve çalışma temposu

Değişiklik kontrolü, yılda bir kez yapılan denetimle belirlenen bir unsur olarak değil, ölçülebilir sağlık göstergelerine sahip bir işletme kontrolü olarak yönetilmelidir.

Değişiklik kontrolü süreci, büyük değişiklikler için düzenli CCB incelemesini, periyodik olarak birikmiş işlerin önceliklendirilmesini ve değişiklik kontrolünü sapmalar ve CAPA etkinliğiyle ilişkilendiren trend incelemesini içermelidir. Değişiklik kontrolü zaman içinde önlenebilir hataları azaltmıyorsa, bir kontrol mekanizması olarak işlev görmüyor demektir.

15) Değişiklik kontrolü “blok testi” kontrol listesi

Blok testi, programın en tehlikeli davranışı, yani güvenilir bir iz bırakmadan gerçeği değiştirme davranışını engelleyip engellemediğini kontrol eden hızlı bir "geçti/kaldı" değerlendirmesidir. Bunu periyodik olarak çalıştırın ve başarısızlıkları "süreç iyileştirme fikirleri" olarak değil, kalite olayları olarak değerlendirin.

16) Yaygın arıza modelleri

• Onay damgası: Risk değerlendirilmemiş; test kapsamı belirsiz; kapatma işlemi kozmetik amaçlı.
• Değişiklik kontrolü = belge güncellemeleri: Standart operasyon prosedürleri değişir ancak sistemler, eğitim ve kontroller değişmez.
• Risk matrisleri sadece süs amaçlıdır: "Her zaman orta seviye" demek, sistemin asla ölçeklenmediği anlamına gelir.
• Gölge sistemler hızla çoğalıyor: Resmi olmayan elektronik tablolar ve araçlar gerçek sürecin yerini alıyor.
• Acil durum rutin hale geliyor: Geçici çözümler birikerek izlenemeyen temel duruma dönüşür.
• Sistem değişiklikleri bütünlüğü göz ardı eder: Yama işlemleri, denetim kayıtları, raporlar veya elektronik imzalar kontrol edilmeden uygulanır.
• Tedarikçi değişiklikleri tepkiseldir: İçsel izlenebilirlik ve karşılaştırılabilirlik eksikliği bulunmaktadır.
• Açık kalan değişiklikler asla kapanmaz: Biriken iş yükü "normal" hale gelir ve gerçek temel durumu kimse bilmez.

17) Sektörler arası örnekler

Değişiklik kontrolü evrenseldir, ancak "zarar veren" şey sektörden sektöre değişir. Başarısızlık modeli aynıdır: kontrolsüz sapma ve zayıf kanıtlar, zayıf sonuçlara yol açar.

• İlaç üretimi: Yöntem ve parametre değişiklikleri, yayın gecikmelerine ve zayıf incelemelere yol açabilir; sıkı bağlantı sapmalar hem de CAPA kritik.
• Tıbbi cihazlar: Kanıt zincirleri, tasarım ve üretim eserleri gibi unsurları kapsar. DV, DMR, ve DHRKüçük bir doküman değişikliği, ürünün tanımlanma, üretilme veya kabul edilme şeklini değiştirirse, tasarım kontrolü sorunu haline gelebilir.
• Gıda ve tüketim ürünleri: Tedarikçi ve etiketleme değişiklikleri yüksek risk taşır çünkü izlenebilirlik ve alerjen kontrolleri sessizce başarısız olabilir; değişiklik kontrolü, eşdeğer olmayan "eşdeğer" ikamelerin yapılmasını önler.
• Otomasyon ağırlıklı işlemler: PLC/MES değişiklikleri, yürütme mantığını ve kayıtlarını değiştirebilir; bunları BT görevleri olarak değil, kaliteyi etkileyen değişiklikler olarak değerlendirin. Mantık kaydı yönlendiriyorsa, uyumluluğu da yönlendirir.

Genel ders şu: Üretiminiz ne kadar yazılım odaklı hale gelirse, değişiklik kontrolü de gerçeği koruyan gerçek güvenlik önlemi haline gelir.

18) Genişletilmiş SSS

S1. Değişiklik kontrolü nedir?
Değişiklik kontrolü, ürün kalitesini, güvenliğini, uyumluluğunu veya operasyonel performansını etkileyebilecek değişikliklerin önerilmesi, değerlendirilmesi, onaylanması, uygulanması ve doğrulanması için belgelenmiş bir süreçtir.

S2. Değişiklik kontrolü, MOC'den nasıl farklıdır?
MOC Operasyonel ve güvenlik etkilerini değerlendirmek için yapılandırılmış bir yaklaşımdır; değişiklik kontrolü ise belgeler, sistemler, tedarikçiler ve onaylanmış durumlar genelindeki değişiklikleri yöneten daha geniş bir Kalite Yönetim Sistemi (KYS) sürecidir.

S3. Bir değişiklik kontrol kaydı her zaman neleri içermelidir?
Değişikliğin net bir açıklaması, risk temelli etki değerlendirmesi, gerekli onaylar, tanımlanmış doğrulama/geçerlilik, gerektiğinde eğitim kanıtı, etkili bir kapsam/tarih ve objektif kapanış kanıtı.

S4. Tüm değişiklikler doğrulama testine tabi tutulmalı mıdır?
Hayır. Testler risk temelli olmalıdır. Ancak her değişiklik, hangi doğrulamanın gerekli olduğu ve nedenine dair açık bir karar gerektirir ve daha yüksek riskli değişiklikler daha güçlü kanıtlar gerektirir.

S5. Bilgisayarlı sistemler için en büyük değişiklik kontrol riski nedir?
Kanıtları zedeleyen sessiz davranış değişikliği: bozuldu denetim izleriYanlış zaman damgaları, değiştirilmiş hesaplamalar veya zayıflatılmış erişim kontrolleri gibi sorunlar ortaya çıkabilir. Bunları test etmezseniz, veri bütünlüğünü koruyamamış olursunuz.

S6. Bir değişikliğin “önemli” olup olmadığına nasıl karar veririz?
Bir değişiklik, ürün kalitesini, güvenliğini, düzenleyici yükümlülükleri veya mevcut doğrulama kanıtlarının geçerliliğini değiştirebiliyorsa, bunu önemli bir değişiklik olarak değerlendirin. Kritik parametreleri, serbest bırakma kararlarını, etiketleme iddialarını, temel yazılım mantığını veya tedarikçi kimliğini/kritik işlemeyi etkiliyorsa, bunu önemli bir değişiklik olarak kaydedin ve daha güçlü doğrulama gerektirin.

S7. Çoklu lokasyonlu veya aşamalı devreye alma işlemlerini nasıl yönetiyoruz?
Kapsamı kesin olarak tanımlayın (hangi tesisler/hatlar/partiler), her kapsam için açık geçerlilik tarihleri ​​belirleyin ve birlikte çalışmayı kontrol edin. Dağıtım sırasında, paralel olarak iki geçerli durumunuz olabilir; kayıtlarınız hangi durumun hangi ürüne uygulandığını göstermelidir. Dağıtım kontrolünü, gayri resmi bir proje detayı olarak değil, değişiklik planının bir parçası olarak ele alın.

İlgili Okuma
• Yönetişim + Kayıtlar: Döküman kontrolu | Gözden geçirme | Belge Değişiklik Talebi | Kontrol paneli değiştir
• Risk + Doğrulama: Risk matrisi | CSV | Gamp 5 | VMP | UAT
• Dürüstlük + Kanıt: Veri bütünlüğü | ALKOL | Denetim İzi (GxP) | Elektronik İmzalar
• Kaliteli Bağlantı: Kaliteli Etkinlik Yönetimi | Sapma Yönetimi | Uygunsuzluk Yönetimi | CAPA
• Sistemler + Dayanıklılık: MES | MES Yama Yönetimi | MES Siber Güvenlik Kontrolleri | MES Yedekleme Doğrulama
• Tedarikçi Kontrolleri: Tedarikçi Denetim Programı | Satıcı Yeterliliği (VQ)