Mevcut CRM geliştirilmeli mi, yeniden mi yazılmalı?

Önce hatayı, iş ihtiyacını ve erişimi birbirinden ayırın

“Sistem yetersiz” ifadesi tek başına fiyatlandırılabilir bir kapsam değildir. Örneğin fatura toplamının yanlış hesaplanması bir hata olabilir; yöneticinin yalnızca belirli bir tutarın üzerindeki siparişleri onaylaması ise yeni bir iş kuralıdır. Güncel stok verisinin başka sistemden gelmemesi entegrasyon sorunu olabilir. Aynı ekranda görülmeleri, aynı çözümü gerektirdikleri anlamına gelmez.

İlk incelemede sorunun hangi kayıt ve adımla tekrarlandığını, kimlerin etkilendiğini ve beklenen doğru sonucu yazın. Kaynak kod, veritabanı, kullanılan lisanslar ve yönetim erişimleri ayrıca değerlendirilmelidir. Ekrana giriş yapılabilmesi, kodun değiştirilebildiğini veya verinin tam dışarı alınabildiğini kanıtlamaz. Ön görüşmede şifre ya da gerçek müşteri verisi yerine kişisel bilgileri gizlenmiş bir örnek akış paylaşın.

Hangi durumda onarım, modül veya yeni sistem seçilir?

• Sınırlı onarım: mevcut akış ihtiyacı karşılıyor, hata tekrar üretilebiliyor ve güvenli müdahale için erişim bulunuyorsa değerlendirilir. Sadece hatalı sonuç değil, onu üreten kural da kontrol edilir.
• Modül geliştirme: çekirdek kayıtlar kullanılabilir, ancak yeni rol, rapor, onay veya entegrasyon gerekiyor. Yeni modülün hangi sistemden veri alacağı ve mevcut akışa nasıl bağlanacağı açık olmalıdır.
• Yeniden geliştirme veya ürün değişimi: temel model işletmenin ihtiyaçlarıyla uyuşmuyor, sürdürülebilir erişim/bakım sağlanamıyor ya da birikmiş bağımlılıklar sınırlı müdahaleyi anlamsızlaştırıyorsa gündeme gelir. Hazır ürün de özel yazılımla birlikte değerlendirilebilir.

Eski teknoloji tek başına yeniden yazma gerekçesi değildir. Yeni teknoloji de kendiliğinden güvenli ve ucuz değildir. Değerlendirmeye lisans, veri devri, mevcut bağlantılar, kullanıcı eğitimi, bakım ve kesinti riski dahil edilmelidir. Yeniden geliştirme teklifi alırken mevcut sistemde korunacak davranışları da listeleyin; yalnızca yeni özelliklere bakmak önemli ayrıntıları kaybettirebilir.

Gerçek deneyim: stok ve fatura CRM'inde önceki durumu korumak

Adrasya stok ve fatura CRM vaka kaydımız, canlı güncelleme ve fatura onarımı öncesi tarihli yedekler ile işlem öncesi veri kopyalarını belgeliyor. Somut problem, çalışan sistemdeki kritik kayıtları koruyarak müdahale yapmaktı. Doğrulanabilir çıktı, onarım öncesi durumun ve geri dönüş noktalarının ayrı tutulmasıdır.

Bu kapsamdan çıkardığımız ilke, ilk işin mevcut veriyi değiştirmek değil, başlangıç durumunu anlaşılır ve geri alınabilir hale getirmek olduğudur. Arşivde yedek bulunması her yedeğin her ortamda başarıyla geri yüklenmiş olduğunu göstermez. Yeni işte geri yükleme denemesi, kabul kapsamına ayrıca yazılmalıdır. Bu vakadan satış artışı, ölçülmüş hız kazancı veya bütün CRM'ler için aynı sonuç çıkarılamaz.

MySQL'in yedekleme ve kurtarma belgesi, veri korunması ve değişiklik öncesi yedek yaklaşımı için teknik bir dayanak sunar. Her sistem MySQL kullanmaz; uygun yöntem gerçek veritabanına ve uygulamanın dosya bağımlılıklarına göre seçilir. Veritabanı kopyası tek başına yüklenmiş belgelerin, yapılandırmanın ve uygulama sürümünün tamamını içermeyebilir.

Yeni modülün sınırı ekran değil, işlem akışı olsun

B2B sipariş sistemi çalışmamızdaki doğrulanabilir kapsam; satış personeli, bayi ve admin rolleri ile teklif, onay/ret, sipariş, cari ve stok modülleridir. Bu örnek, yeni bir onay ekranının diğer kayıtlarla ilişkisinin baştan kurulması gerektiğini gösterir. Projedeki süre, yorum veya ticari sonuçları yeni bir CRM müdahalesine vaat olarak taşımıyoruz.

Örneğin teklif onay modülü için ilk faz “bir form ve bir liste” değil; yetkili kullanıcının taslağı oluşturması, doğru kişinin onaylaması ve beklenen kayıtların oluşmasıdır. Onaylanan teklif değiştirildiğinde ne olacağı, iptal yetkisi ve stok bağlantısı da sınırın parçasıdır. Daha genel faz planı için ERP modülü geliştirme yol haritasına bakabilirsiniz; burada odak mevcut sistemin korunup korunamayacağıdır.

OWASP yetkilendirme rehberi, erişimin varsayılan olarak reddedilmesini ve izinlerin her istekte doğrulanmasını önerir. Düğmeyi gizlemek tek başına yetkilendirme değildir. Yeni rapor veya modül için yalnızca “admin görebilir” demek yerine rol, işlem ve erişilecek kayıt kapsamı birlikte tanımlanmalıdır.

Veri devrinde hangi çıktı istenmeli?

Yeni sisteme geçilecekse alan eşlemesi hazırlanmalıdır: eski kayıt kimliği, yeni kimlik, zorunlu alanlar, durumlar ve ilişkili kayıtlar. Toplam kayıt sayısının eşit olması yeterli değildir; müşterinin siparişleri, faturanın satırları ve tutar hesapları da tutarlı olmalıdır. Aktarılamayan veya çelişkili kayıtlar sessizce atlanmamalı, istisna listesine alınmalıdır.

Geçiş planında eski sisteme son yazma anı, aktarım sırasında gelen yeni kayıtların ele alınışı ve geri dönüşte iki sistemin nasıl uzlaştırılacağı bulunmalıdır. Eski yedeği geri yüklemek, geçişten sonra oluşan işlemleri kaybettirebilir. “Geri döneriz” ifadesini bu yeni kayıtların sorumlusu ve düzeltme yöntemiyle birlikte değerlendirin. Canlı veriyi paylaşma ve erişim yetkileri, gerçek proje tarafları arasında güvenli kanaldan netleştirilmelidir.

Teklifin yanına yazılabilecek kabul kriterleri

1. Hata onarımı: tanımlı başlangıç kaydıyla sorun yeniden gösterilir; müdahale sonrası beklenen sonuç ve etkilenmemesi gereken ilgili işlemler sınanır.
2. Yeni onay: yetkili rol onaylar; yetkisiz rol aynı işlemi sunucu üzerinden deneyince reddedilir. Oluşan durum ve değişiklik kaydı kontrol edilir.
3. Veri devri: sayılar, ilişkiler ve seçilmiş örneklerin mutabakatı yapılır; istisnaların nasıl çözüldüğü kaydedilir.
4. Kesinti: bağlantı zaman aşımı veya yinelenen işlem senaryosu için beklenen davranış ve manuel düzeltme yolu belirlenir.
5. Geri dönüş: yetkili izole ortamda yedek açılır; gerekli uygulama/dosya bileşenleri ve yeni işlemlerin uzlaştırılması doğrulanır.

Bunlar önceki müşteri projesinin yeniden yapılmış testleri değil, satın alacağınız iş için önerilen teslim kriterleridir. Güvenli test ortamı yoksa canlıda riskli deneme yapılmamalı; test sınırı, destek sorumlusu ve çözülmemiş risk yazılı kalmalıdır.

SRN Dijital'e hangi bilgilerle başvurabilirsiniz?

Mevcut sistemin adı/teknolojisi biliniyorsa onu, aksayan tek bir işlem örneğini, öncelikli ihtiyacı ve erişim durumunu paylaşmanız yeterli bir başlangıçtır. İnceleme sonrası onarım, ek modül ve yeniden geliştirme seçeneklerini kapsam, bağımlılık, kabul ve bakım açısından ayırabiliriz. Evrensel fiyat veya teslim günü vermiyoruz; veri ve erişim belirsizliği çözülmeden kesin iş kapsamı oluşmaz.

İzmir merkezli SRN Dijital, Türkiye genelindeki işletmeler için özel yazılım ve CRM geliştirme ile mevcut web tabanlı sistemlerde hata giderme çalışmaları yürütür. Başvuruda kaynak paketini veya erişim şifrelerini herkese açık alana bırakmayın. Önce ihtiyacı konuşalım, ardından gerekli güvenli inceleme yöntemini belirleyelim.

Kaynaklar ve doğrulama sınırı

• SRN Dijital: stok, fatura ve canlı sistem onarımı CRM vakası
• SRN Dijital: B2B sipariş ve teklif sistemi vakası
• MySQL: Backup and Recovery
• OWASP: Authorization Cheat Sheet

Kaynak kontrolü: 7 Ekim 2026. Örnek kabul listesi SRN Dijital'in editoryal yaklaşımıdır. Teknik kapsam; bağımsız müşteri memnuniyeti, ticari sonuç veya sıralama ölçümü olarak sunulmaz.

Kısa cevap: mevcut CRM'i değiştirmek şart mı?

Hayır. Mevcut akış kullanılabilir, erişim sağlanabilir ve sorun sınırlanabiliyorsa onarım veya modül ekleme değerlendirilebilir. Temel veri ve iş modeli ihtiyacı karşılamıyorsa yeniden geliştirme ya da hazır ürün seçeneği incelenir. Her seçenekte veri korunması, yetki, kabul testi ve geri dönüş birlikte planlanır.

SRN Dijital'in stok/fatura CRM ve B2B sipariş vakaları ilgili teknik deneyimin kanıtıdır. İşletmenize uygun müdahale mevcut sistem incelenerek belirlenir; yeni ekran sayısı veya teknoloji adı tek başına doğru yatırım ölçütü değildir.