Portal Yazılım Nedir? Türleri, Modülleri ve Proje Planlama Rehberi

Portal yazılım; müşterilerin, bayilerin, çalışanların veya iş ortaklarının kendilerine tanımlanan bilgi ve işlemlere güvenli bir hesap üzerinden erişmesini sağlayan web tabanlı çalışma alanıdır. İyi planlanmış bir portal yalnızca belge göstermez; talep oluşturma, sipariş verme, onay alma, ödeme yapma ve işlem durumunu izleme gibi görevleri belirli kurallarla yürütür.

Bu nedenle ilk karar “hangi ekranlar olacak?” değil, “kim hangi işi, hangi veriyi kullanarak ve hangi yetkiyle tamamlayacak?” olmalıdır. Bu rehber, portal türünü seçmekten rol ve veri matrisini hazırlamaya, entegrasyon sınırlarını belirlemekten teklifleri karşılaştırmaya kadar uygulanabilir bir yol sunar.

Portal yazılım ne işe yarar?

Portalın temel değeri, dağınık iletişim ve işlem adımlarını kullanıcıya göre düzenlenmiş tek bir akışta birleştirmesidir. Bir müşteri e-postalarda güncel sözleşmeyi aramak yerine hesabından doğru sürümü görebilir. Bir bayi kendisine tanımlanan fiyatla sipariş oluşturabilir. Bir çalışan izin veya satın alma talebini doğru onay zincirine gönderebilir. Bir iş ortağı yalnız paylaşılması gereken proje belgelerine ulaşabilir.

Burada önemli olan, bütün bilgiyi tek ekrana taşımak değildir. Her rol için gerekli bilgi ve işlemi görünür kılmak; diğer verileri ise sınırlandırmaktır. Portal başarısı da ekran sayısıyla değil, kullanıcının görevi güvenli ve izlenebilir biçimde tamamlayabilmesiyle değerlendirilmelidir.

Portal türleri nasıl ayrılır?

“Portal” tek bir ürün türünü ifade etmez. Aynı teknik temel farklı kullanıcı ve süreçlere göre değişebilir.

Bir kurum birden fazla portal türüne ihtiyaç duyabilir. Ancak bütün kullanıcıları aynı menü ve veri modeline sıkıştırmak, yetki karmaşası ve kullanım zorluğu doğurabilir. Ortak altyapı kurulsa bile kullanıcı yolculuklarının ayrı tasarlanması daha sağlıklıdır.

Müşteri tarafındaki üyelik, belge, talep ve ödeme kapsamının bütçeyi nasıl etkilediğini ayrıca ele alan müşteri portalı maliyeti rehberimiz, bu yazının tamamlayıcısıdır.

Portal kapsam matrisi nasıl hazırlanır?

Kapsam toplantısında uzun bir özellik listesi çıkarmak kolaydır; fakat hangi özelliğin hangi probleme bağlı olduğu belirsiz kalabilir. Kumsal Ajans portal kapsam matrisi her kullanıcı grubunu altı soruyla tanımlar:

1. Rol: Sisteme kim girer?
2. Görev: Bu kişi portalda hangi sonucu elde etmek ister?
3. Veri: Görevi tamamlamak için neyi görür veya değiştirir?
4. İşlem: Hangi talebi, onayı, belgeyi ya da ödemeyi yönetir?
5. Kural: Yetki, doğrulama, süre, limit ve istisna koşulları nelerdir?
6. Kanıt: İşlemin tamamlandığı nasıl kaydedilir ve kim izler?

Örneğin bayi satın alma kullanıcısı “sipariş oluşturur” demek tek başına yeterli değildir. Hangi fiyat listesini göreceği, stok yoksa ne olacağı, cari limit aşımında kimin onaylayacağı, siparişin ERP sistemine ne zaman aktarılacağı ve başarısız aktarımın nasıl ele alınacağı da tanımlanmalıdır.

Bu yöntem, tekliflerde yalnız görünen ekranları değil arka plandaki kural ve sorumlulukları da karşılaştırmayı sağlar.

Kullanıcı rolleri ve yetkiler nasıl tasarlanır?

Portal güvenliği giriş ekranında bitmez. Kullanıcı sisteme girdikten sonra hangi kaydı okuyabileceği, değiştirebileceği, indirebileceği veya onaylayabileceği her işlem için belirlenmelidir. OWASP, erişim kontrolünde en az yetki, varsayılan olarak reddetme ve her istekte izin doğrulama ilkelerini önerir. Ayrıntılı uygulama ilkeleri OWASP Authorization Cheat Sheet kaynağında açıklanır.

Rol tasarımında şu sorular cevaplanmalıdır:

• Bir kullanıcı birden fazla firmaya veya şubeye bağlı olabilir mi?
• Firma yöneticisi kendi kullanıcılarını açabilir ve kapatabilir mi?
• Hassas belge indirme, ödeme veya limit değişikliği için ek doğrulama gerekir mi?
• Kullanıcı şirketten ayrıldığında erişim nasıl sonlandırılır?
• Geçici yetki ve vekâlet süresi dolduğunda ne olur?
• Yönetici, kimin hangi kaydı görüntülediğini veya değiştirdiğini inceleyebilir mi?

NIST’in sıfır güven mimarisi rehberi de ağ konumu veya varlık sahipliği nedeniyle otomatik güven varsayılmamasını vurgular. Bu yaklaşımın kapsamı NIST SP 800-207 belgesinde incelenebilir. Bu kaynaklar tek başına güvenli bir ürün garantisi değildir; proje için tehdit modeli, test planı ve işletim sorumluluğu ayrıca belirlenmelidir.

Portalda hangi modüller bulunabilir?

Modül seçimi portal türüne göre yapılmalıdır. Her projede bütün modüllerin bulunması gerekmez.

• Hesap ve profil: Firma bilgileri, kullanıcılar, iletişim tercihleri ve yetkiler.
• Belge merkezi: Sözleşme, fatura, sertifika, rapor veya kullanım dokümanı; sürüm ve erişim kaydıyla birlikte.
• Talep yönetimi: Destek, servis, teklif, değişiklik veya bilgi talebi; durum, sorumlu ve yanıt süresi alanlarıyla.
• Sipariş ve ödeme: Ürün seçimi, özel fiyat, limit, sipariş onayı, ödeme ve sevkiyat görünürlüğü.
• Onay akışları: Tutar, rol, kategori veya istisnaya göre doğru yetkiliye yönlendirme.
• Bildirimler: E-posta, SMS veya uygulama içi bildirim; olay, alıcı ve tekrar koşullarıyla.
• Raporlama: Tamamlanan işlemler, bekleyen talepler, hata oranları ve kullanım eğilimleri.
• Yönetim paneli: İçerik, kullanıcı, rol, kural, entegrasyon ve işlem kayıtlarının yönetimi.

Modül başlıklarının bulunması yeterli değildir. “Belge merkezi var” ifadesi yerine belgeyi kimin yüklediği, sürümün nasıl değiştiği, eski belgenin görünür kalıp kalmadığı ve erişimin nasıl denetlendiği yazılmalıdır.

Entegrasyon kapsamı nasıl belirlenir?

Portal çoğu zaman verinin asıl sahibi değildir. Cari hesap ERP’de, müşteri ve fırsat bilgisi CRM’de, ödeme sonucu ödeme kuruluşunda, kullanıcı kimliği ise kurumun kimlik sisteminde tutulabilir. Bu nedenle her veri alanı için “kaynak sistem” belirlenmelidir.

Entegrasyon tablosunda en az şu bilgiler bulunmalıdır:

API, ERP, CRM ve ödeme sistemleri arasındaki sorumlulukları ayrıntılandırmak için web yazılım entegrasyonları rehberimizi kullanabilirsiniz.

Kullanıcı deneyimi ve erişilebilirlik neden kapsamın parçasıdır?

Portal düzenli kullanılan bir iş aracıdır. Kullanıcı sık yaptığı görevi bulamıyor, uzun formları tamamlayamıyor veya hata sonrası nasıl devam edeceğini anlayamıyorsa teknik olarak çalışan sistem operasyonu yavaşlatabilir.

Görev bazlı menü, açık durum adları, geri alınabilir işlemler, anlaşılır hata mesajları ve klavye erişimi tasarımın başında ele alınmalıdır. W3C’nin Web Content Accessibility Guidelines 2.2 standardı; algılanabilir, kullanılabilir, anlaşılabilir ve sağlam arayüzler için test edilebilir ölçütler sunar.

Masaüstü tasarımına ek olarak gerçek telefon ekranında oturum açma, belge indirme, tablo kullanımı, form tamamlama ve hata düzeltme senaryoları da test edilmelidir.

Hazır platform mu, özelleştirme mi, özel geliştirme mi?

Karar, “özel yazılım her zaman daha iyidir” varsayımıyla verilmemelidir.

Hazır bir ürün standart belge paylaşımı, temel talep yönetimi veya yaygın entegrasyonlarla ihtiyacı karşılıyorsa daha hızlı devreye alınabilir. Buna karşılık lisans, kullanıcı sayısı, veri taşınabilirliği ve özelleştirme sınırları incelenmelidir.

Hazır altyapının özelleştirilmesi, süreçlerin büyük bölümü standartken marka, rol, form veya rapor ihtiyaçları farklı olduğunda dengeli bir seçenek olabilir.

Projeye özel geliştirme, fiyatlandırma, onay, veri modeli veya entegrasyon kuralları hazır ürünlerin sınırlarını aştığında anlamlıdır. Bu model daha fazla analiz, test, güvenlik ve uzun dönem bakım sorumluluğu getirir.

Doğru seçim, ekran sayısından önce süreçlerin ne kadar özgün olduğu ve hangi değişikliklerin beklenildiği değerlendirilerek yapılır.

Portal projesi hangi aşamalardan geçer?

1. Keşif: Kullanıcılar, sorunlar, mevcut sistemler ve başarı ölçüleri belirlenir.
2. Kapsam: Rol–görev–veri–işlem matrisi ile modüller ve istisnalar yazılır.
3. Bilgi mimarisi: Menü, ekranlar ve içerik ilişkileri kullanıcı görevlerine göre kurulur.
4. Prototip: Kritik akışlar gerçekçi veriyle tıklanabilir biçimde test edilir.
5. Teknik tasarım: Veri sahipliği, entegrasyon, yetki, kayıt ve hata davranışları tanımlanır.
6. Geliştirme ve entegrasyon: İşlevler küçük, doğrulanabilir teslimatlara ayrılır.
7. Kabul testi: Normal akışlarla birlikte yetkisiz erişim, eksik veri ve bağlantı kesintisi senaryoları denenir.
8. Geçiş ve eğitim: Kullanıcı, veri, belge ve sorumluluk devri planlanır.
9. İşletim: İzleme, destek, yedekleme, güncelleme ve iyileştirme süreci sürdürülür.

Bu aşamalar sabit bir takvim sözü değildir. Süre; kullanıcı grubu, modül, entegrasyon, veri aktarımı ve onay hızına göre değişir.

Teklif almadan önce hangi bilgiler hazırlanmalı?

Karşılaştırılabilir bir teklif için aşağıdaki bilgileri paylaşın:

• Portal türü ve hedef kullanıcı grupları
• Her rolün tamamlayacağı üç ila beş ana görev
• Mevcut ERP, CRM, ödeme ve kimlik sistemleri
• Aktarılacak veri ve belgelerin yaklaşık kapsamı
• Kritik yetki, onay ve kayıt gereksinimleri
• Beklenen kullanıcı, firma ve işlem büyüklüğü
• Mobil kullanım ve erişilebilirlik beklentileri
• Teslim, test, eğitim, destek ve bakım sorumlulukları
• Veri sahipliği, dışa aktarma ve teknik devir beklentisi

Bir teklifi değerlendirirken yalnız toplam fiyata değil; kapsam dışı alanlara, üçüncü taraf lisanslarına, test yöntemine, güvenlik sorumluluklarına ve değişiklik sürecine de bakın.

Portalınız için sonraki adım

Portal ihtiyacınız müşteri, bayi, çalışan veya iş ortağı süreçlerinden hangisine dayanıyorsa önce üç gerçek kullanıcı görevi seçin. Bu görevleri rol, veri, işlem, kural ve kanıt alanlarıyla yazın. Ortaya çıkan matris, gerçekten gerekli modülleri ve entegrasyonları görünür hale getirir.

Kumsal Ajans ile bir portal projesini değerlendirmek isterseniz mevcut iş akışınızı, kullanıcı gruplarınızı ve bağlantı kurulacak sistemleri paylaşabilirsiniz. İlk görüşmenin amacı hazır bir paket önermek değil; ihtiyacın standart bir ürünle, özelleştirmeyle veya projeye özel web yazılım geliştirme yaklaşımıyla karşılanıp karşılanamayacağını netleştirmektir.