İş ihtiyacından sürdürülebilir uygulamaya
BIG@ Kurumsal Yazılım ve Entegrasyon Çözümleri
Biga Bilişim; işletmenizin gerçek iş akışını anlayarak hazır ürün seçimi, yapılandırılabilir çözüm, özel yazılım geliştirme, API entegrasyonu, veri geçişi, otomasyon, test ve canlı sonrası destek seçeneklerini birlikte değerlendirir. Amaç daha fazla ekran üretmek değil; doğru kişiye doğru veriyi veren, ölçülebilir ve sürdürülebilir bir çalışma sistemi kurmaktır.
Yazılım ihtiyacınızı birlikte modelleyelim
Bugünkü çalışma yönteminizi, tekrar eden işleri, kullanılan uygulamaları ve beklenen sonucu paylaşın. Ürün veya teknoloji önermeden önce sorunu, kullanıcıları, veriyi, entegrasyon sınırlarını ve ilk aşamada ölçülecek başarıyı netleştirelim.
Önce iş sonucu
Kurumsal yazılım projesi hangi sorunu çözmelidir?
Kurumsal yazılım; sipariş, teklif, servis, onay, saha görevi, belge, stok, müşteri iletişimi veya raporlama gibi bir iş akışını tutarlı veri ve açık sorumluluklarla yönetilebilir hale getirmelidir. Kullanıcı hangi işi ne zaman yapacağını, yönetici hangi kaydın beklediğini, müşteri ise sürecin hangi aşamada olduğunu anlayabilmelidir. Sistem, aynı bilginin farklı dosyalara tekrar yazılmasını ve kişisel hafızaya bağlı takibi azaltmalıdır.
Başarı yalnızca uygulamanın çalışması değildir. İşlem süresi, eksik kayıt oranı, tekrar veri girişi, onay bekleme süresi, hata veya yeniden işleme sayısı gibi göstergeler başlangıçta tanımlanır. Böylece proje sonunda “ekranlar teslim edildi” yerine, belirlenen iş sonucunun gerçekten iyileşip iyileşmediği değerlendirilebilir.
Çözüm modeli
Hazır ürün, yapılandırma, entegrasyon veya özel geliştirme
Her ihtiyacın sıfırdan kodlanması gerekmez. Doğru çözüm; gereksinimin ne kadar standart olduğuna, mevcut sistemlerin kabiliyetine ve değişimin işletme için taşıdığı değere göre seçilir.
Hazır yazılım
Standart süreç, hızlı devreye alma ve üretici güncellemeleri öncelikliyse değerlendirilir. Lisans, veri dışa aktarma, kullanıcı sınırı ve entegrasyon seçenekleri kontrol edilir.
Yapılandırılabilir çözüm
Hazır ürünün form, rol, akış, bildirim ve rapor ayarları ihtiyacı karşılıyorsa kod geliştirmeden veya sınırlı eklentiyle ilerlenebilir.
Özel yazılım
İşletmeye özgü kural, deneyim, veri modeli veya rekabet avantajı belirleyiciyse kontrollü fazlarla özel geliştirme planlanır.
Entegrasyon ve otomasyon
Mevcut uygulamalar işlevsel fakat birbirinden kopuksa yeni bir ana sistem yerine veri aktarımı, onay akışı veya görev otomasyonu daha doğru olabilir.
Karma yaklaşım
Hazır bir çekirdek ürün, özel arayüz ve belirli entegrasyonlar birlikte kullanılabilir. Sorumluluk ve güncelleme sınırları baştan yazılır.
Değiştirmeden iyileştirme
Sorun yazılım değil veri, rol veya süreç disipliniyse önce mevcut sistemde sadeleştirme yapılır. Gereksiz yatırımın önüne geçilir.
Karar ölçütü: İlk satın alma fiyatı tek başına yeterli değildir. Uyarlama, entegrasyon, eğitim, barındırma, güncelleme, veri taşıma, destek ve olası çıkış maliyetiyle birlikte toplam sahip olma maliyeti değerlendirilir.
Keşif ve gereksinim
Ekran listesinden önce mevcut işi ve hedefi anlıyoruz
Keşif çalışması yalnızca toplantı notu toplamak değildir. Sürecin başlangıcı, karar noktaları, istisnalar, onaylar, veri kaynakları ve beklenen çıktılar örnek kayıtlar üzerinden incelenir.
- 01
Sorun ve hedef
Neden değişim gerektiği, bugün oluşan zaman veya kalite kaybı ve projenin sonunda hangi sonucun iyileşmesi gerektiği yazılı hale getirilir.
- 02
Kullanıcı ve bağlam
Ofis, saha, yönetim, müşteri veya tedarikçi rollerinin işi hangi cihazda, hangi sıklıkta ve hangi yetkiyle yaptığı belirlenir.
- 03
Gerçek senaryolar
Normal akış kadar iptal, eksik bilgi, gecikme, tekrar, iade veya bağlantı kesintisi gibi istisnalar da örnekleriyle modellenir.
- 04
Başarı ve kabul
İlk sürümün hangi işlemleri güvenilir biçimde tamamlayacağı ve hangi ölçütlerin kullanıcı kabulünü göstereceği önceden kararlaştırılır.
Süreç, veri ve sorumluluk
Uygulamanın omurgasını ekran değil, ilişkiler oluşturur
- İş nesneleri
- Müşteri, lokasyon, ürün, teklif, görev, belge veya servis kaydı gibi temel varlıkların anlamı ve birbiriyle ilişkisi tanımlanır.
- Durum geçişleri
- Bir kaydın taslak, onayda, planlandı, tamamlandı veya iptal gibi durumlara hangi koşulla geçeceği ve geri alınabileceği belirlenir.
- Roller ve yetkiler
- Kimin göreceği, oluşturacağı, değiştireceği, onaylayacağı veya dışa aktaracağı en az yetki yaklaşımıyla ayrılır.
- Veri kalitesi
- Zorunlu alan, benzersiz kayıt, doğrulama kuralı, referans kodu, saklama süresi ve arşiv yaklaşımı kullanım amacına göre planlanır.
- Bildirim ve eskalasyon
- Her değişiklik için bildirim üretmek yerine eylem gerektiren gecikme, hata, onay veya eşik olayları ilgili kişiye yönlendirilir.
- Rapor ve iz
- Yönetim göstergeleri ile denetim kaydı ayrılır. Raporun kaynağı, güncellik zamanı ve hesabı açıklanabilir olmalıdır.
Teknik mimari
Barındırma, ölçek, erişim ve işletim kararlarını birlikte veriyoruz
Web, mobil, bulut veya şirket içi kurulum yalnızca teknoloji tercihi değildir. Kullanıcı konumu, bağlantı koşulları, veri hassasiyeti, mevcut altyapı, yedekleme hedefi, kesinti toleransı ve işletim yetkinliği bu kararı etkiler.
Kullanım yükü
Eş zamanlı kullanıcı, günlük işlem, dosya boyutu, rapor yoğunluğu ve büyüme beklentisi gerçekçi aralıklarla tanımlanır.
Erişilebilirlik
Çalışma saatleri, kabul edilebilir kesinti, bakım penceresi, yedekleme ve geri dönüş beklentisi hizmet seviyesiyle uyumlu hale getirilir.
İşletim sorumluluğu
Alan adı, sunucu, bulut hesabı, sertifika, e-posta, izleme, log, yedek ve güncellemelerin sahibi açıkça belirlenir.
Gereksiz karmaşıklık güvenilirlik sağlamaz. İlk sürüm için anlaşılır, izlenebilir ve bakım yapılabilir bir mimari seçilir; ölçeklendirme noktaları ölçümle görülür hale geldiğinde geliştirilir. Kritik bağımlılıklar, tek hata noktaları ve geri dönüş adımları tasarım kararlarıyla birlikte kaydedilir.
Prototip ve kullanıcı deneyimi
Kodlamadan önce kritik akışları görünür hale getiriyoruz
Prototip neyi doğrular?
Menü yapısı, form sırası, karar noktaları, hata mesajları ve kullanıcının görevi tamamlamak için izleyeceği yol örnek ekranlarla değerlendirilir. Kullanıcılar ayrıntılı dokümandan önce somut akış üzerinde geri bildirim verir.
- Kritik işin en az adımla tamamlanması
- Zorunlu ve isteğe bağlı bilginin ayrılması
- Rol ve cihaz bağlamının görülmesi
- Kabul senaryosunun erken hazırlanması
Erişilebilirlik neden erkenden ele alınır?
Kontrast, klavye kullanımı, odak sırası, form etiketi, hata açıklaması ve farklı ekran boyutları sonradan eklenen süsler değildir. Hedef kullanıcı ve kapsam uygunsa WCAG 2.2 ilkeleri tasarım ve kabul ölçütlerine dahil edilir.
- Okunabilir ve tutarlı bilgi hiyerarşisi
- Yalnızca renge dayanmayan durum anlatımı
- Mobilde taşmayan, öngörülebilir kontroller
- Açıklanabilir hata ve yardım metinleri
API ve entegrasyon
Sistemleri bağlarken veri sahipliğini ve hata yönetimini netleştiriyoruz
Entegrasyon yalnızca iki uç nokta arasında veri göndermek değildir. Aynı müşteri, stok veya sipariş bilgisinin hangi sistemde asıl kayıt olduğu; güncellemenin hangi yönde ilerlediği ve bağlantı kesildiğinde ne olacağı belirlenmelidir.
Her bağlantı için yazılı teknik sözleşme
- Kaynak, hedef ve veri sahibi
- Alan eşleştirme ve sürüm
- Kimlik doğrulama ve yetki
- Sıklık, kota ve zaman aşımı
- Tekrar deneme ve yinelenen kayıt kontrolü
- Log, alarm ve operasyon sahibi
Üçüncü taraf sistemin API sunmaması, lisans gerektirmesi veya değişiklik yapması proje riskidir. Bu bağımlılıklar teklif ve test planında ayrı gösterilir. Uygunsa önce örnek veriyle teknik kanıt çalışması yapılır; tüm süreci bağlamadan temel veri alışverişi doğrulanır.
Güvenlik ve kişisel veri
Güvenliği geliştirme yaşam döngüsünün parçası yapıyoruz
Tehdit ve veri sınıfı
İşlenen veri, erişen roller, dış bağlantılar ve olası kötüye kullanım senaryoları gereksinim aşamasında değerlendirilir.
Kimlik ve yetki
Güçlü oturum yönetimi, uygun kimlik doğrulama ve en az yetki ilkesi kullanıcı rolü ve riskle uyumlu tasarlanır.
Güvenli geliştirme
Girdi doğrulama, hata yönetimi, bağımlılık takibi, sırların korunması ve kod değişikliği kontrolleri geliştirme sürecine eklenir.
Kayıt ve izleme
Güvenlik veya iş açısından anlamlı olaylar, hassas veri sızdırmadan ve sorumlusu belli olacak biçimde kaydedilir.
Yedek ve geri dönüş
Yalnızca yedek alındığı değil, hangi verinin ne sıklıkta korunduğu ve geri dönüşün nasıl doğrulanacağı planlanır.
KVKK sorumluluğu
Yazılım teknik tedbir sağlar; hukuki sebep, aydınlatma, saklama ve başvuru süreçleri veri sorumlusunun idari yükümlülükleriyle birlikte yürütülür.
NIST Secure Software Development Framework güvenli geliştirme uygulamalarını yaşam döngüsüne eklemek için ortak bir çerçeve sunar. OWASP ASVS ise web uygulaması teknik güvenlik kontrollerinin gereksinim ve test kapsamını tanımlamada kullanılabilir. Bunlar tek başına sertifika veya mutlak güvenlik garantisi değildir; proje riski ve kapsamı için ölçülebilir kontrol kaynağıdır.
Test ve kabul
Teknik test ile kullanıcı kabulünü birbirinden ayırıyoruz
Birim, entegrasyon, yetki, doğrulama ve hata senaryoları teknik kaliteyi kontrol eder. Kullanıcı kabul testi ise gerçek işin baştan sona beklenen sonuçla tamamlanabildiğini doğrular. Her iki katman da gereklidir.
Kabul senaryosu dört parçadan oluşur
- 01
Başlangıç koşulu
Kullanıcı rolü, örnek veri ve sistem durumu belirtilir.
- 02
İş adımları
Kullanıcının gerçek görevi anlaşılır sırayla yürütülür.
- 03
Beklenen sonuç
Kayıt, bildirim, rapor veya entegrasyon çıktısı ölçülebilir biçimde tanımlanır.
- 04
Kanıt ve karar
Sonuç, hata ve tekrar testi kayıt altına alınır; geçiş kararı yetkili kişiyle verilir.
Veri geçişi ve canlıya alma
Geçişi tek gecelik işlem değil, kontrollü bir operasyon olarak planlıyoruz
- 01
Temizlik ve eşleştirme
Kaynak alanlar, kodlar, tekrarlar, eksikler, tarih ve karakter biçimleri incelenir; aktarılmayacak veri açıkça ayrılır.
- 02
Pilot aktarım
Sınırlı veriyle ilişki, sayı, örnek kayıt, rapor ve kullanıcı erişimi doğrulanır. Sorunlar toplu geçişten önce düzeltilir.
- 03
Geçiş penceresi
Son veri alma zamanı, geçici çalışma yöntemi, sorumlular, iletişim kanalı ve gerekirse geri dönüş koşulu belirlenir.
- 04
İlk gün kontrolü
Giriş, kritik akış, entegrasyon, bildirim, rapor, yedek ve izleme kontrolleri tamamlanır; kullanıcı desteği görünür tutulur.
Teslim kapsamı
Proje sonunda yalnızca çalışan ekran değil, işletilebilir sistem teslim edilir
Kesin teslim listesi teklif ve sözleşmeye göre değişir. Aşağıdaki başlıklar, kurumsal yazılım çalışmasında sorumluluğu ve kabulü belirsiz bırakmamak için değerlendirdiğimiz temel çıktılardır.
KapsamGereksinim, rol, akış ve kapsam dışı konular
TasarımPrototip, veri modeli ve mimari kararlar
UygulamaKararlaştırılan modüller ve entegrasyonlar
KaliteTest kayıtları, kabul senaryoları ve sonuçlar
GeçişVeri aktarımı, canlıya alma ve geri dönüş planı
İşletimErişim, yedek, izleme, eğitim ve destek sınırları
Bakım ve değişiklik yönetimi
Canlı sistemin sağlığını ve yeni ihtiyaçları ayrı akışlarda yönetiyoruz
Olay
Çalışan hizmette kesinti veya ciddi performans sorunu oluştuğunda etki, öncelik, geçici çözüm ve kalıcı düzeltme kaydedilir.
Hata
Kararlaştırılan davranışın tekrarlanabilir biçimde gerçekleşmemesi örnek veri, adım ve beklenen sonuçla raporlanır.
Yeni özellik
Yeni iş ihtiyacı etki analizi, kapsam, test, maliyet ve sürüm planıyla ele alınır; acil hata gibi sisteme alınmaz.
Teknik bakım
Bağımlılık, işletim sistemi, veritabanı, sertifika, güvenlik güncellemesi ve kapasite göstergeleri planlı olarak izlenir.
Yedek ve izleme
Hizmet, hata, kaynak kullanımı ve yedekleme sonuçları anlaşılır alarm eşikleri ve sorumlu kişilerle takip edilir.
Sürüm ve kayıt
Değişikliğin nedeni, kapsamı, test sonucu, yayın zamanı ve geri dönüş yöntemi sürüm notunda korunur.
Uygun işletme profili
Hangi kurumlar için değerlendirilebilir?
- Tekrarlanan operasyonu olan işletmeler
- Teklif, sipariş, servis, onay, saha görevi veya belge akışı kişisel takip ve dağınık dosyalarla yürüyorsa süreç merkezileştirilebilir.
- Birden fazla sistem kullanan kurumlar
- CRM, ERP, web sitesi, e-posta, muhasebe veya saha uygulaması arasında tekrar veri girişi varsa entegrasyon ve otomasyon değerlendirilebilir.
- Çok lokasyonlu ekipler
- Şube, depo, saha, merkez ve müşteri tarafının aynı kaydın farklı aşamalarında çalışması gerekiyorsa rol ve durum yönetimi önem kazanır.
- Rapor güveni düşük yönetimler
- Aynı gösterge farklı dosyalarda farklı sonuç veriyorsa veri sahipliği, tanım ve kayıt zamanı ortaklaştırılabilir.
- Büyüme öncesi standartlaşmak isteyen KOBİ'ler
- İş sahiplerinin hafızasına bağlı süreçler ekip büyüdükçe risk oluşturuyorsa temel akışlar ölçülebilir hale getirilebilir.
- Kurumsal ve regülasyonlu yapılar
- Yetki, değişiklik izi, onay, saklama ve denetim beklentisi yüksekse gereksinimler teknik ve idari kontrollerle birlikte ele alınır.
Teklif sınırları
Süre ve maliyeti belirleyen başlıca etkenler
- Kullanıcı, rol ve lokasyon sayısı
- İş akışı, ekran ve istisna sayısı
- Rapor ve gösterge kapsamı
- API ve üçüncü taraf entegrasyonları
- Veri miktarı ve temizleme ihtiyacı
- Web, mobil ve çevrimdışı kullanım
- Güvenlik ve kayıt gereksinimleri
- Barındırma, süreklilik ve yedekleme hedefleri
- Test, eğitim ve canlı geçiş yöntemi
- Bakım ve hedef destek süreleri
İlk görüşmede kesin fiyat vermek yerine belirsizliği azaltacak bilgileri toplarız. Küçük ama kullanılabilir bir ilk faz, tanımlı kabul ölçütleri ve sonraki aşamalar için görünür öncelik listesi oluşturmak çoğu projede daha sağlıklı ilerleme sağlar.
Sık sorulan sorular
Kurumsal yazılım ve entegrasyon hakkında merak edilenler
Hazır yazılım mı, özel yazılım mı tercih edilmeli?
Tekrarlanan ve standartlaşmış bir süreç için hazır veya yapılandırılabilir ürün daha hızlı ve ekonomik olabilir. İşletmeye özgü kural, entegrasyon, yetki, rapor veya kullanıcı deneyimi rekabet açısından belirleyiciyse özel geliştirme değerlendirilir. Karar; lisans maliyeti kadar uyarlama sınırı, veri sahipliği, entegrasyon kabiliyeti, bakım yükü ve üç yıllık toplam maliyet birlikte incelenerek verilmelidir.
Yazılım projesine başlamak için hangi bilgiler gerekir?
İlk değerlendirme için çözülmek istenen iş sorunu, mevcut çalışma yöntemi, kullanıcı rolleri, yaklaşık işlem hacmi, zorunlu raporlar, kullanılan sistemler, veri kaynakları ve beklenen tarih yeterlidir. Ekran listesinden önce hedeflenen iş sonucu netleştirilir. Örnek dosya, form, Excel tablosu veya mevcut uygulama ekranı sürecin daha hızlı ve doğru modellenmesine yardımcı olur.
Mevcut ERP, CRM veya web sitesiyle entegrasyon yapılabilir mi?
Entegrasyon, ilgili sistemlerin güvenli API, web servis, webhook, dosya aktarımı veya desteklenen başka bir yöntem sunmasına bağlıdır. Her bağlantı için hangi verinin sahibi olduğu, aktarım yönü, sıklığı, kimlik doğrulaması, hata tekrarı ve kayıt sorumluluğu belirlenir. Üçüncü taraf lisansları, kullanım kotaları ve üretici kısıtları keşif aşamasında ayrıca doğrulanır.
Excel ve eski uygulamadaki veriler yeni sisteme aktarılır mı?
Kaynak veri erişilebilir ve anlamlı alanlara sahipse veri geçişi planlanabilir. Önce alan eşleştirme, yinelenen kayıt, eksik zorunlu bilgi, tarih biçimi, karakter kodlaması ve ilişki tutarlılığı incelenir. Temizlenen küçük bir örnek veriyle pilot aktarım yapılır; kayıt sayısı ve seçilmiş örnekler doğrulanmadan toplu geçiş tamamlanmış kabul edilmez.
Web ve mobil uygulama birlikte geliştirilebilir mi?
İş senaryosu gerektiriyorsa web arayüzü, mobil uyumlu web uygulaması veya ayrı mobil uygulama birlikte değerlendirilebilir. Mobil cihaz, kamera, konum, bildirim ya da çevrimdışı çalışma ihtiyacı teknik seçimi etkiler. Her projede mobil uygulama zorunlu değildir; kullanıcı bağlamı, bakım maliyeti, mağaza süreçleri ve güvenlik gereksinimleri değerlendirilerek en yalın uygulanabilir yaklaşım seçilir.
Kurumsal yazılım güvenliği nasıl ele alınır?
Güvenlik yalnızca canlıya çıkış öncesi test değildir. Veri sınıfları, kullanıcı rolleri, en az yetki, kimlik doğrulama, oturum yönetimi, girdi doğrulama, değişiklik kayıtları, yedekleme ve güncelleme sorumlulukları gereksinimlerle birlikte tanımlanır. Uygun projelerde NIST SSDF ve OWASP ASVS gibi çerçevelerden risk düzeyine uygun kontrol listeleri oluşturulur; KVKK yükümlülükleri veri sorumlusu süreçleriyle birlikte değerlendirilir.
Bir özel yazılım projesi ne kadar sürer?
Süre; kullanıcı rolü, ekran ve iş akışı sayısı, entegrasyonlar, veri geçişi, güvenlik, raporlama, mobil kullanım ve kabul sürecine göre değişir. Sağlıklı plan tek bir büyük teslim tarihi vermek yerine keşif, prototip, ilk çalışan sürüm, pilot ve canlı geçiş aşamalarını ayrı hedeflerle yönetir. Kapsam netleşmeden verilen kesin süreler genellikle yanıltıcıdır.
Kullanıcı kabul testi nasıl yürütülür?
Kabul testi teknik ekibin uygulamayı açabilmesi değil, yetkili kullanıcıların gerçek iş senaryolarını beklenen sonuçlarla tamamlamasıdır. Giriş koşulu, adımlar, örnek veri ve beklenen çıktı yazılı hale getirilir. Kritik sorunlar düzeltilir, tekrar test edilir ve kapsam dışı değişiklikler ayrı kayda alınır. Canlı geçiş kararı, üzerinde uzlaşılan kabul ölçütleri karşılandığında verilir.
Kaynak kod, kullanım hakkı ve bakım kapsamı nasıl belirlenir?
Kaynak kod erişimi, fikri haklar, üçüncü taraf bileşen lisansları, barındırma, yedekleme, alan adı, hesap sahipliği ve bakım sorumlulukları sözleşmede açıkça tanımlanmalıdır. Her proje aynı hak modeline sahip değildir. Biga Bilişim teklifinde teslim edilecek varlıkları, müşterinin erişim düzeyini, garanti veya bakım dönemini ve kapsam dışı değişikliklerin nasıl ele alınacağını yazılı hale getirir.
Canlıya geçişten sonra destek ve geliştirme devam eder mi?
Proje kapsamına göre hata düzeltme, izleme, yedekleme kontrolü, güvenlik güncellemesi, kullanıcı desteği ve değişiklik talepleri için ayrı bir işletim modeli oluşturulabilir. Olay, hata ve yeni özellik aynı kuyruğa konulmaz; öncelik ve hedef süreleri ayrılır. Yeni ihtiyaçlar etki analizi, kabul ölçütü ve sürüm planıyla yönetildiğinde sistem sürdürülebilir biçimde gelişir.
Teknik referanslar
Proje kapsamı ve risk düzeyine göre aşağıdaki resmi kaynaklardan uygun kontrol başlıkları seçilebilir. Bir kaynağa atıf yapılması tek başına sertifika, mevzuat uyumu veya eksiksiz uygulama iddiası değildir.
NIST SP 800-218 Secure Software Development Framework OWASP Application Security Verification Standard W3C Web Content Accessibility Guidelines 2.2 KVKK kişisel verilerin işlenmesine ilişkin temel ilkeler
İçerik ve kaynak kontrol tarihi: 21 Temmuz 2026. Teknik gereksinimler teklif ve proje kapsamına göre ayrıca doğrulanır.
Kurumsal yazılım ihtiyacınız için uygulanabilir ilk adımı belirleyelim
Mevcut süreci ve beklenen sonucu birlikte inceleyelim; hazır ürün, entegrasyon, otomasyon veya özel geliştirme seçeneklerinden hangisinin daha doğru olduğunu ölçülebilir kapsamla netleştirelim.