Kurumsal mobil uygulama geliştirme, bir şirketin operasyonlarını, müşterileriyle temas noktalarını veya saha ekiplerini mobil cihazlar üzerinden yönetilebilir hale getiren yazılım sürecidir. Bireysel bir tüketici uygulamasından farkı; güvenlik, yetkilendirme, entegrasyon, raporlama, ölçeklenebilirlik ve bakım beklentilerinin çok daha yüksek olmasıdır.
Bir e-ticaret markası için mobil uygulama yalnızca ürün listeleme ekranı değildir. Sepet, ödeme, kargo, iade, kampanya, üyelik, bildirim, stok, ERP ve CRM gibi birçok sistemin birlikte çalışması gerekir. Bir saha operasyonu uygulamasında ise ekip konumu, görev atama, fotoğraf yükleme, çevrim dışı çalışma, imza alma ve merkez ofise raporlama gibi süreçler kritik hale gelir.
Atalay Tech tarafında mobil uygulama, web platformu, yönetim paneli ve AI entegrasyonu içeren projelerde en sık gördüğümüz hata şudur: Şirketler uygulamayı ekranlardan ibaret sanır, fakat kurumsal başarıyı belirleyen asıl katman backend, veri modeli, entegrasyon ve sürdürülebilir bakım mimarisidir. Bu yüzden mobil uygulama geliştirme süreci, fikir aşamasından önce iş modeli ve operasyon akışıyla birlikte ele alınmalıdır.
Kurumsal mobil uygulama; bir işletmenin müşteri, çalışan, bayi, tedarikçi veya saha ekipleriyle mobil cihazlar üzerinden kontrollü, güvenli ve ölçülebilir şekilde çalışmasını sağlayan özel yazılımdır. Bu uygulamalar genellikle şirketin mevcut sistemleriyle entegre olur ve tek başına çalışan basit bir mobil arayüz olarak düşünülmez.
Örneğin bir B2B satış ekibi için geliştirilen mobil uygulama, müşteri listesini, cari hesapları, sipariş geçmişini, stok durumunu, iskonto kurallarını ve ödeme takibini tek panelde gösterebilir. Satış temsilcisi müşterinin yanında sipariş oluştururken merkez ofis aynı anda stok ve tahsilat durumunu görebilir.
Bir insan kaynakları uygulamasında ise çalışan izin talepleri, vardiya planı, bordro evrakları, duyurular, eğitim videoları ve performans geri bildirimleri mobil cihaz üzerinden yönetilebilir. Burada değer, uygulamanın “güzel görünmesi” değil; şirket içi iş yükünü azaltması ve ölçülebilir veri üretmesidir.
Kurumsal tarafta uygulama genellikle şu hedeflerden birini taşır:
Bu nedenle kurumsal mobil uygulama geliştirme, klasik bir uygulama tasarım işinden daha stratejik bir yazılım yatırımıdır.
Bir uygulama fikri “bizim de mobil uygulamamız olsun” seviyesinde kalırsa proje çoğu zaman gereksiz maliyet üretir. Kurumsal mobil uygulamanın anlamlı olması için net bir iş problemine bağlanması gerekir.
Örneğin dağıtım yapan bir şirketin saha ekipleri sipariş ve teslimat bilgisini WhatsApp üzerinden iletiyorsa, merkez ofis anlık durumu göremez. Teslimat fotoğrafı, imza, müşteri notu ve gecikme bilgisi farklı kanallarda dağılır. Mobil uygulama bu noktada görev, teslimat, lokasyon, fotoğraf ve raporu tek akışta toplar.
Bir üretim şirketinde bayi siparişleri telefonla alınıyorsa, stok kontrolü gecikir. Yanlış ürün kodu, yanlış fiyat veya eksik iskonto hatası oluşabilir. Bayi mobil uygulaması, yetkili kullanıcıya özel fiyat, stok, kampanya ve sipariş geçmişi göstererek hatayı azaltır.
Aşağıdaki tablo, kurumsal mobil uygulamanın hangi probleme hangi yazılım bileşeniyle cevap verdiğini gösterir:
| İş problemi | Mobil uygulama çözümü | Backend / panel ihtiyacı | Ölçülebilir çıktı |
|---|---|---|---|
| Saha ekipleri dağınık çalışıyor | Görev, konum, fotoğraf ve teslimat ekranları | Operasyon paneli, rol bazlı yetki | Görev tamamlama süresi |
| Bayiler siparişi telefonla veriyor | Bayi sipariş uygulaması | Stok, fiyat, iskonto, ERP entegrasyonu | Sipariş hata oranı |
| Müşteri bağlılığı düşük | Sadakat, kupon, bildirim, üyelik | Kampanya ve segment yönetimi | Tekrar satın alma oranı |
| Çalışan iletişimi kopuk | Duyuru, eğitim, izin, vardiya modülleri | İK paneli, doküman yönetimi | Talep çözüm süresi |
| Yönetim raporu geç geliyor | Mobil veri toplama ve anlık dashboard | Raporlama altyapısı | Karar alma hızı |
Kurumsal uygulamada başarı, “kaç ekran var?” sorusuyla değil, “hangi operasyon daha hızlı, daha güvenli ve daha ölçülebilir hale geldi?” sorusuyla değerlendirilmelidir.
Kurumsal mobil uygulama tek bir kategori değildir. Şirketin hedef kitlesine ve iş modeline göre farklı türlerde tasarlanabilir. Aynı şirketin hem müşteri uygulaması hem saha uygulaması hem de yönetim paneli olabilir.
Müşteri odaklı uygulamalar, son kullanıcının marka ile doğrudan ilişki kurduğu mobil ürünlerdir. E-ticaret, randevu, sadakat, üyelik, kampanya, ödeme ve destek modülleri bu gruba girer.
Bir klinik için müşteri uygulaması; randevu alma, doktor seçme, geçmiş işlemleri görme ve bildirim alma işlevleri sunabilir. Bir perakende markası için aynı yapı; ürün keşfi, favoriler, sepet, ödeme, kargo takibi ve kampanya bildirimi şeklinde çalışır.
Bu tür projelerde kullanıcı deneyimi çok kritiktir. İlk açılış süresi, kayıt akışı, ödeme güvenliği, bildirim izinleri ve mağaza yorumları doğrudan dönüşüm oranını etkileyebilir. Google’ın mobil deneyim rehberlerinde hız, erişilebilirlik ve güvenilir gezinme yapısı özellikle vurgulanır. Teknik ekipler tasarım kararlarını yalnızca estetikle değil, performans ve kullanılabilirlik verileriyle de değerlendirmelidir.
Saha uygulamaları, şirket dışındaki personelin merkez ofisle senkronize çalışmasını sağlar. Teknik servis, lojistik, temizlik, güvenlik, satış, bakım ve denetim ekipleri için sık kullanılır.
Örneğin teknik servis ekibi, müşteriye gitmeden önce cihaz geçmişini, garanti durumunu ve önceki servis notlarını görebilir. İş tamamlandığında fotoğraf yükler, müşteriden dijital imza alır ve merkez ofise raporu otomatik düşer. Böyle bir yapı, hem evrak yükünü azaltır hem de müşteri itirazlarında kanıt üretir.
Bu tür uygulamalarda çevrim dışı çalışma özelliği önemlidir. Depo, fabrika, bodrum kat, saha alanı veya internet bağlantısı zayıf bölgelerde uygulama veri kaybetmeden çalışmalıdır. Veri cihazda geçici olarak tutulur, bağlantı geldiğinde sunucuya güvenli şekilde aktarılır.
Bayi ve B2B uygulamaları, şirketin iş ortaklarıyla dijital kanaldan çalışmasını sağlar. Bu uygulamalarda kullanıcı deneyimi kadar fiyatlandırma, yetki ve entegrasyon modeli de önemlidir.
Bir bayi uygulamasında her kullanıcı aynı fiyatı görmeyebilir. Bölgeye, cari hesaba, sözleşmeye veya kampanyaya göre farklı fiyat, iskonto ve ödeme koşulu tanımlanabilir. Bu nedenle uygulama arayüzü basit görünse bile arkada karmaşık bir yetkilendirme ve fiyat hesaplama sistemi çalışır.
Bu modelde özel yazılım geliştirme yaklaşımı daha doğru olur. Hazır paketler genellikle şirketin fiyat politikası, stok kuralı, bayi segmenti veya ERP akışına tam uymaz. Kurumsal mobil uygulamanın gerçek avantajı, işletmenin çalışma biçimine göre şekillenmesidir.
Kurumsal mobil uygulama geliştirme süreci, yalnızca yazılım kodlama aşamasından oluşmaz. Doğru proje, iş ihtiyacının netleştirilmesiyle başlar ve yayın sonrası bakım modeliyle devam eder.
Atalay Tech yaklaşımında süreç genellikle keşif, kapsamlandırma, UX/UI tasarım, MVP geliştirme, test, yayın ve bakım aşamalarına ayrılır. Her aşama, sonraki aşamanın maliyetini ve riskini doğrudan etkiler.
| Aşama | Amaç | Somut çıktı | Tipik süre |
|---|---|---|---|
| Keşif | İş hedefi ve kullanıcı akışını anlamak | Kapsam notu, rol listesi, öncelik matrisi | 3-7 gün |
| UX/UI tasarım | Ekran akışlarını netleştirmek | Wireframe, tasarım sistemi, prototip | 1-3 hafta |
| MVP geliştirme | İlk kullanılabilir sürümü üretmek | Mobil app, backend, temel panel | 4-10 hafta |
| Test | Hata, güvenlik ve performansı kontrol etmek | Test raporu, hata listesi, düzeltmeler | 1-3 hafta |
| Yayın | App Store ve Google Play sürecini tamamlamak | Mağaza yayını, sürüm notları | 3-10 gün |
| Bakım | Uygulamayı sürdürülebilir tutmak | Güncelleme, izleme, destek, yeni modüller | Sürekli |
Bu tablo genel bir çerçevedir. ERP entegrasyonu, ödeme sistemi, canlı mesajlaşma, medya altyapısı, çoklu dil veya AI modülleri eklenirse süre değişir.
Keşif aşamasında en önemli soru “uygulamada hangi özellikler olacak?” değildir. Daha doğru soru şudur: “Hangi kullanıcı, hangi işlemi, hangi koşulda ve hangi yetkiyle yapacak?”
Örneğin bir saha operasyonu uygulamasında şu roller olabilir:
Her rolün göreceği ekran, yapabileceği işlem ve erişeceği veri farklıdır. Bu ayrım baştan yapılmazsa proje ilerledikçe “bu kullanıcı bunu görmemeliydi” veya “bu rapor sadece yöneticide olmalıydı” gibi revizyonlar artar.
Kapsamlandırmada ayrıca entegrasyonlar belirlenmelidir. ERP, CRM, muhasebe, ödeme, SMS, e-posta, harita, kargo, bildirim ve analitik sistemleri proje başında listelenmelidir.
Kurumsal uygulamalarda tasarım, yalnızca estetik arayüz üretmek değildir. Kullanıcının sahada, ofiste, toplantıda, depoda veya müşteri yanında uygulamayı nasıl kullanacağını düşünmek gerekir.
Örneğin bir depo personeli eldivenle çalışıyorsa küçük butonlar sorun yaratır. Bir satış temsilcisi müşterinin yanında hızlı sipariş girmek zorundaysa ürün arama, favori ürünler ve tekrar sipariş ekranı çok hızlı açılmalıdır. Bir yönetici mobil dashboard kullanıyorsa grafikler sade, filtreler net ve raporlar okunabilir olmalıdır.
Tasarım prototipi, yazılıma başlamadan önce yanlış anlaşılmaları azaltır. Özellikle kurumsal projelerde tasarım onayı alınmadan geliştirmeye geçmek, sonraki aşamalarda maliyeti artırır.
MVP, uygulamanın en küçük ama gerçek kullanıcıya değer sağlayan ilk sürümüdür. Kurumsal mobil uygulamada MVP, yalnızca demo ekranlarından oluşmamalıdır. Gerçek veriyle çalışan, yetkilendirme içeren ve temel operasyonu tamamlayan bir sürüm olmalıdır.
Örneğin bayi sipariş uygulaması için MVP şu modülleri içerebilir:
Sadakat puanı, gelişmiş kampanya motoru, AI öneri sistemi veya segment bazlı bildirimler ikinci faza bırakılabilir. Bu yaklaşım, bütçeyi daha kontrollü kullanmayı sağlar.
Kurumsal bir projeye başlamadan önce mobil uygulama yaptırmak isteyen şirketlerin MVP kapsamını net ayırması gerekir. Her özelliği ilk sürüme koymak, çoğu zaman yayın tarihini geciktirir ve öğrenme hızını düşürür.
Kurumsal uygulamalarda test süreci yalnızca “butona basınca çalışıyor mu?” kontrolü değildir. Rol bazlı yetki, veri güvenliği, cihaz uyumluluğu, düşük internet senaryosu, bildirim davranışı, ödeme akışı ve mağaza kuralları birlikte test edilmelidir.
Apple App Store ve Google Play süreçlerinde gizlilik politikası, hesap silme, veri toplama beyanları, izin açıklamaları ve uygulama içi ödeme kuralları önemlidir. Apple’ın App Review Guidelines dokümanı, uygulama yayını sırasında dikkat edilmesi gereken temel kuralları açıklar. Android tarafında ise Android Developers kaynakları performans, güvenlik ve yayın süreçleri için teknik referans sağlar.
Bakım aşaması da projenin ayrı bir parçasıdır. Mobil işletim sistemleri, cihazlar, mağaza politikaları ve üçüncü parti servisler değiştikçe uygulamanın güncellenmesi gerekir. Kurumsal mobil uygulama, yayınlandıktan sonra kendi haline bırakılacak bir ürün değildir.
Kurumsal mobil uygulama geliştirme için teknoloji seçimi, bütçe ve hız kadar bakım kabiliyetiyle de ilgilidir. Yanlış teknoloji seçimi kısa vadede ucuz görünse bile uzun vadede entegrasyon, performans ve ekip bulunabilirliği tarafında maliyet yaratabilir.
| Kriter | Native iOS/Android | React Native / Flutter | No-code / Low-code |
|---|---|---|---|
| Performans | En yüksek | Yüksek | Sınırlı |
| Geliştirme hızı | Orta | Hızlı | Çok hızlı |
| Bakım maliyeti | İki ayrı ekip gerekebilir | Tek ekip avantajı | Platform bağımlı |
| Kurumsal entegrasyon | Çok güçlü | Güçlü | Kısıtlı olabilir |
| Özelleştirme | Çok yüksek | Yüksek | Sınırlı |
| MVP için uygunluk | Bütçeye bağlı | Çok uygun | Basit fikirlerde uygun |
| Büyük ölçekli proje | Çok uygun | Uygun | Dikkatli seçilmeli |
React Native veya Flutter gibi cross-platform teknolojiler, tek kod tabanıyla iOS ve Android geliştirmeyi mümkün kılar. Bu, özellikle MVP ve orta ölçekli kurumsal projelerde hız ve maliyet avantajı sağlayabilir.
Native geliştirme ise kamera, Bluetooth, yüksek performanslı grafik, özel donanım entegrasyonu veya çok yoğun platform özellikleri gereken projelerde daha doğru olabilir. No-code araçlar ise hızlı prototip için kullanılabilir; fakat ERP entegrasyonu, özel yetki modeli, offline çalışma veya karmaşık veri yapısı olan kurumsal projelerde sınırlara hızlı ulaşabilir.
Atalay Tech tarafında teknoloji seçimi yapılırken yalnızca ilk geliştirme maliyeti değil, 12-24 aylık bakım, ekip devri, API mimarisi, mağaza güncellemeleri ve yeni modül ekleme ihtimali birlikte değerlendirilir.
Kurumsal mobil uygulama maliyeti; özellik sayısı, kullanıcı rolleri, entegrasyonlar, tasarım seviyesi, backend karmaşıklığı, yönetim paneli, güvenlik gereksinimleri ve bakım kapsamına göre değişir. Aynı “mobil uygulama” ifadesi, 250.000 TL’lik bir MVP için de 3.000.000 TL üzeri kurumsal platform için de kullanılabilir.
Aşağıdaki aralıklar 2026 Türkiye yazılım pazarı için tahmini ve proje kapsamına göre değişebilen referans aralıklardır:
| Proje seviyesi | Kapsam örneği | Tahmini geliştirme maliyeti | Tipik süre |
|---|---|---|---|
| MVP | Giriş, profil, temel listeleme, basit panel, bildirim | 250.000 - 600.000 TL + KDV | 4-8 hafta |
| Orta ölçek | Ödeme, rol yönetimi, gelişmiş panel, raporlama, entegrasyon | 600.000 - 1.500.000 TL + KDV | 8-16 hafta |
| Kurumsal platform | ERP/CRM entegrasyonu, çoklu rol, offline, gelişmiş güvenlik, AI modülü | 1.500.000 - 5.000.000 TL + KDV | 4-9 ay |
| Sürekli geliştirme | Yeni modüller, bakım, izleme, sürüm güncellemeleri | Aylık 25.000 - 250.000 TL + KDV | Sürekli |
Bu rakamlar kesin teklif değildir. Aynı proje, kapsam detayına göre ciddi şekilde değişebilir. Örneğin yalnızca ürün listeleyen bir bayi uygulaması ile ERP’ye çift yönlü bağlı, cari bakiye ve iskonto kuralları hesaplayan bir bayi uygulaması aynı maliyete sahip olamaz.
Bütçe planlaması yaparken mobil uygulama fiyatları aracı, ilk fikir seviyesinde kabaca bir maliyet perspektifi oluşturmak için kullanılabilir. Net teklif için teknik kapsam, kullanıcı rolleri ve entegrasyon listesi ayrıca değerlendirilmelidir.
Kurumsal mobil uygulamanın kullanıcıya görünen tarafı mobil ekrandır. Fakat uygulamanın gerçek gücü backend, API ve yönetim paneli tarafında ortaya çıkar.
Bir sadakat uygulamasında kampanyaları kim oluşturacak? Bir saha uygulamasında görevleri kim atayacak? Bir bayi uygulamasında ürün fiyatları nereden güncellenecek? Bir eğitim uygulamasında içerikleri kim yükleyecek? Bu soruların cevabı yönetim panelidir.
yönetim paneli geliştirme süreci, mobil uygulamayla birlikte düşünülmelidir. Panel eksik veya zayıf tasarlanırsa şirket her küçük değişiklik için yazılım ekibine bağımlı kalır.
Kurumsal panelde genellikle şu modüller bulunur:
Backend tarafında API güvenliği, hız, veri modeli ve loglama çok önemlidir. Mobil uygulama büyüdükçe kullanıcı sayısı, veri trafiği ve eş zamanlı işlem yükü artar. Bu yüzden kurumsal projelerde backend mimarisi kısa vadeli değil, ölçeklenebilir şekilde kurulmalıdır.
Kurumsal mobil uygulama, çoğu zaman kişisel veri, müşteri bilgisi, ödeme verisi, şirket içi belge veya ticari işlem verisi taşır. Bu nedenle güvenlik, proje sonunda eklenecek bir detay değildir; mimarinin başında planlanmalıdır.
Türkiye’de kişisel verilerle çalışan projelerde KVKK yükümlülükleri dikkate alınmalıdır. Uygulamada hangi verinin toplandığı, hangi amaçla işlendiği, ne kadar süre saklandığı ve kullanıcının verisini nasıl silebileceği açık olmalıdır. KVKK’nın resmi kaynağı olan Kişisel Verileri Koruma Kurumu bu konuda temel referans noktasıdır.
Kurumsal uygulamalarda dikkat edilmesi gereken temel güvenlik başlıkları şunlardır:
| Güvenlik alanı | Risk | Uygulanabilecek önlem |
|---|---|---|
| Kimlik doğrulama | Yetkisiz giriş | Güçlü parola, OTP, sosyal giriş, cihaz kontrolü |
| Yetkilendirme | Yanlış veriye erişim | Rol bazlı izin, kaynak bazlı kontrol |
| API güvenliği | Veri sızıntısı | Token yönetimi, rate limit, loglama |
| Veri saklama | Kişisel veri riski | Şifreleme, minimum veri politikası |
| Oturum yönetimi | Hesap ele geçirme | Oturum süresi, cihazdan çıkış, refresh token |
| Dosya yükleme | Zararlı dosya | MIME kontrolü, boyut sınırı, güvenli depolama |
Özellikle saha, sağlık, finans, e-ticaret ve B2B projelerinde veri erişimi rol bazlı tasarlanmalıdır. Bir bayi yalnızca kendi siparişlerini görmeli, bölge müdürü kendi bölgesini izlemeli, merkez admin ise tüm veriye erişebilmelidir.
Güvenlik tarafında OWASP’ın Mobile Application Security kaynakları, mobil uygulama tehditlerini anlamak için güçlü bir referanstır. Kurumsal projelerde bu başlıklar geliştirme sürecinin doğal parçası olmalıdır.
Kurumsal mobil uygulama çoğu zaman şirketin mevcut dijital ekosistemine bağlanır. Bu bağlantılar doğru tasarlanmazsa uygulama ayrı bir veri adasına dönüşür. Kullanıcı mobilde işlem yapar, fakat merkez sistem farklı bilgi gösterir. Bu durum operasyonel güveni azaltır.
Yaygın entegrasyon örnekleri:
AI entegrasyonu kurumsal mobil uygulamalarda özellikle destek, içerik üretimi, raporlama ve öneri sistemlerinde değer yaratabilir. Örneğin bir saha uygulaması, yüklenen fotoğrafı AI ile sınıflandırabilir; bir müşteri destek uygulaması, sık sorulan talepleri otomatik yanıtlayabilir; bir satış uygulaması, kullanıcıya geçmiş siparişlerine göre öneri sunabilir.
Fakat AI modülü ilk sürümde şart değildir. Verisi temiz olmayan veya temel operasyonu oturmamış bir uygulamada AI eklemek, projeyi gereksiz karmaşık hale getirebilir. Önce veri akışı ve temel işlem modeli kurulmalı, ardından AI destekli iyileştirme planlanmalıdır.
Somut bir senaryo üzerinden düşünelim. Ayşe, 34 yaşında bir operasyon müdürü. Türkiye genelinde 70 saha personeli olan bir servis şirketinde çalışıyor. Gün içinde yüzlerce görev açılıyor, ekipler farklı lokasyonlara gidiyor ve müşteriler işlem durumunu telefonla öğrenmeye çalışıyor.
Eski akışta görevler WhatsApp gruplarından dağıtılıyor. Fotoğraflar personelin telefonunda kalıyor. Merkez ofis raporu gün sonunda Excel’e işliyor. Müşteri bir itiraz yaptığında kimin ne zaman gittiği, hangi fotoğrafı çektiği ve hangi notu bıraktığı net bulunamıyor.
Kurumsal mobil uygulama sonrası akış şöyle olabilir:
| Eski süreç | Yeni mobil süreç | Kazanım |
|---|---|---|
| WhatsApp ile görev gönderimi | Panelden görev atama | İzlenebilir operasyon |
| Fotoğraflar kişisel telefonda | Göreve bağlı fotoğraf yükleme | Kanıt ve arşiv |
| Gün sonu Excel raporu | Anlık dashboard | Hızlı karar |
| Müşteri telefonla soruyor | Durum bildirimi ve SMS/e-posta | Daha az destek yükü |
| Personel performansı belirsiz | Görev süresi ve tamamlanma metriği | Ölçülebilir ekip yönetimi |
Bu senaryoda mobil uygulama yalnızca “ekran” değildir. Operasyonel hafıza, kanıt sistemi, raporlama altyapısı ve müşteri iletişim kanalı haline gelir.
Aynı mantık bayi siparişlerinde, eğitim platformlarında, sağlık randevularında, üyelik sistemlerinde veya kurumsal iç iletişim uygulamalarında da geçerlidir. Değer, şirketin tekrar eden iş yükünü azaltmasıyla ortaya çıkar.
Teklif sürecinde en doğru fiyat, en iyi hazırlanmış kapsamla çıkar. “Bize bir mobil uygulama lazım” ifadesi, yazılım ekibi için yeterli değildir. Projenin amacı, kullanıcı rolleri, modülleri, entegrasyonları ve beklentileri açık olmalıdır.
Teklif almadan önce şu sorulara kısa cevaplar hazırlanabilir:
| Hazırlık alanı | Sorulması gereken soru | Örnek cevap |
|---|---|---|
| Hedef kullanıcı | Uygulamayı kim kullanacak? | Müşteri, bayi, saha personeli |
| Ana işlem | Kullanıcı uygulamada ne yapacak? | Sipariş verecek, görev tamamlayacak |
| Admin ihtiyacı | İçerik ve veriyi kim yönetecek? | Operasyon ekibi panelden yönetecek |
| Entegrasyon | Hangi sistemlere bağlanacak? | ERP, ödeme, SMS, kargo |
| Platform | iOS, Android veya ikisi mi? | iOS + Android |
| Yayın hesabı | Mağaza hesabı kimde olacak? | Şirket adına Apple/Google hesabı |
| Bakım | Yayın sonrası kim destek verecek? | Aylık bakım ve geliştirme ekibi |
Bu hazırlık, teklifin daha net olmasını sağlar. Ayrıca gereksiz özellikler erken fark edilir. İlk sürüm için kritik olmayan modüller ikinci faza alınabilir.
Kurumsal projelerde teklif yalnızca fiyat dokümanı değildir. Kapsam, teknik yaklaşım, teslimatlar, revizyon sınırları, bakım modeli, güvenlik yaklaşımı ve yayın süreci birlikte değerlendirilmelidir.
Kurumsal mobil uygulama yayına alındığında başarı yalnızca indirme sayısıyla ölçülmez. Özellikle B2B, saha ve şirket içi uygulamalarda indirme sayısı sınırlı olabilir; fakat operasyonel etkisi yüksek olabilir.
Örneğin 200 saha personelinin kullandığı bir uygulama, milyonlarca indirmeye ulaşmaz. Buna rağmen görev tamamlama süresini %20 azaltıyorsa, destek taleplerini düşürüyorsa veya raporlama süresini kısaltıyorsa başarılıdır.
Takip edilebilecek metrikler:
| Metrik | Ne anlatır? | Örnek hedef |
|---|---|---|
| Aktif kullanıcı oranı | Uygulamanın gerçekten kullanılıp kullanılmadığı | Aylık %60+ aktiflik |
| Görev tamamlama süresi | Operasyon hızını gösterir | %15-30 azalma |
| Hata / çökme oranı | Teknik kaliteyi gösterir | Kritik crash oranı <%1 |
| Tekrar işlem oranı | Kullanıcı alışkanlığını gösterir | Haftalık düzenli kullanım |
| Destek talebi sayısı | Süreç netliğini gösterir | Çağrı merkezi yükünde azalma |
| Sipariş dönüşüm oranı | Ticari etkiyi gösterir | Sepet tamamlama artışı |
Dünya genelinde mobil kullanımın artışı, kurumsal yazılım yatırımlarını da mobil öncelikli hale getiriyor. GSMA’nın mobil ekonomi raporları, mobil internet ve akıllı telefon kullanımının küresel ölçekte büyümeye devam ettiğini gösteriyor. GSMA Mobile Economy raporları, mobilin artık yalnızca iletişim kanalı değil, iş süreçleri için temel altyapı olduğunu ortaya koyan önemli kaynaklardan biridir.
Bu nedenle kurumsal mobil uygulama geliştirirken ilk günden ölçüm planı yapılmalıdır. Analytics, event takibi, hata izleme ve yönetim raporları sonradan eklenen parçalar değil, ürün mimarisinin parçası olmalıdır.
Kurumsal mobil uygulama geliştirme, bireysel kullanıcıya yönelik basit bir uygulama üretmekten daha kapsamlıdır. Normal bir uygulamada temel amaç kullanıcıya belirli bir deneyim sunmak olabilir; kurumsal uygulamada ise operasyon, güvenlik, yetkilendirme, entegrasyon ve raporlama ön plandadır. Örneğin bir yemek tarifi uygulaması içerik ve favori sistemiyle çalışabilir. Fakat bir bayi sipariş uygulaması stok, fiyat, cari hesap, sipariş onayı, admin panel ve ERP entegrasyonu gerektirir. Bu nedenle kurumsal projelerde yalnızca mobil ekranlar değil, backend mimarisi, API güvenliği ve bakım modeli de birlikte planlanmalıdır.
Maliyet farkının temel nedeni, “mobil uygulama” ifadesinin çok geniş bir alanı kapsamasıdır. Basit bir MVP ile ERP bağlantılı, çok rollü, ödeme sistemli ve offline çalışabilen kurumsal platform aynı teknik yükte değildir. Kullanıcı rolleri arttıkça yetkilendirme karmaşıklaşır. Entegrasyon eklendikçe test süresi uzar. Yönetim paneli detaylandıkça backend geliştirme maliyeti artar. Ayrıca App Store ve Google Play yayın süreçleri, bakım, sunucu, bildirim, analitik ve güvenlik ihtiyaçları da bütçeye etki eder. Bu yüzden doğru fiyat için önce kapsam, kullanıcı senaryosu ve entegrasyon listesi netleşmelidir.
Evet, çoğu kurumsal proje için MVP mantıklıdır; fakat MVP yanlış anlaşılmamalıdır. Kurumsal MVP, sadece tıklanabilir demo veya yarım çalışan ekranlar değildir. Gerçek kullanıcıların temel iş akışını tamamlayabildiği ilk sürümdür. Örneğin bayi uygulamasında ilk MVP; giriş, ürün listesi, stok gösterimi, sepet, sipariş ve temel admin paneli içerebilir. Gelişmiş kampanya, AI öneri veya detaylı raporlar sonraki faza bırakılabilir. Bu yaklaşım şirketin daha erken geri bildirim almasını, bütçeyi kontrollü kullanmasını ve gereksiz modülleri ilk sürüme yığmamasını sağlar.
Kurumsal uygulamalarda çoğu zaman iOS ve Android birlikte düşünülür, çünkü çalışanlar, bayiler veya müşteriler farklı cihazlar kullanabilir. Ancak bütçe sınırlıysa önce hedef kullanıcı kitlesinin cihaz dağılımı analiz edilebilir. Sadece şirket içi kullanım varsa ve cihazlar standartlaştırılmışsa tek platformla başlamak mümkün olabilir. Müşteri veya bayi uygulamalarında ise tek platform riskli olabilir; kullanıcıların bir kısmı uygulamaya erişemez. React Native veya Flutter gibi cross-platform teknolojiler, iki platformu aynı anda daha kontrollü maliyetle geliştirmek için güçlü bir seçenek olabilir. Karar, hedef kitleye ve teknik gereksinime göre verilmelidir.
Çoğu kurumsal mobil uygulama için yönetim paneli şarttır. Çünkü uygulamadaki kullanıcıları, içerikleri, siparişleri, görevleri, bildirimleri, raporları veya talepleri birinin yönetmesi gerekir. Panel olmazsa şirket her küçük değişiklik için yazılım ekibine bağımlı kalır. Örneğin kampanya metni değiştirmek, kullanıcı yetkisi vermek, saha görevi atamak veya sipariş durumunu güncellemek için panel gerekir. Yönetim paneli doğru tasarlanırsa operasyon ekibi teknik bilgiye ihtiyaç duymadan sistemi yönetebilir. Bu nedenle mobil uygulama bütçesi çıkarılırken panel ve backend kapsamı ayrı bir kalem gibi değil, projenin ana parçası gibi düşünülmelidir.
Güvenlik; giriş ekranına parola koymakla sınırlı değildir. Kurumsal mobil uygulamada kimlik doğrulama, rol bazlı yetki, API koruması, veri şifreleme, oturum yönetimi, dosya yükleme güvenliği ve loglama birlikte ele alınmalıdır. Örneğin bir saha personeli yalnızca kendi görevlerini görmeli, bölge müdürü kendi bölgesini izlemeli, merkez admin ise tüm veriye erişebilmelidir. Ayrıca KVKK kapsamında hangi kişisel verilerin işlendiği ve kullanıcının hesap silme ya da veri talebi süreçleri net olmalıdır. Güvenlik, proje sonunda “kontrol edilecek” bir konu değil, veri modelinden API tasarımına kadar baştan planlanması gereken bir mimari karardır.
Evet, kurumsal mobil uygulamalar çoğu zaman ERP, CRM, muhasebe, ödeme, kargo, SMS, e-posta veya harita servisleriyle entegre edilir. Buradaki kritik nokta, mevcut sistemin API desteği ve veri yapısıdır. Bazı ERP sistemleri modern API sunarken bazıları özel ara katman geliştirmeyi gerektirebilir. Örneğin bayi sipariş uygulamasında ürün, stok, fiyat ve cari hesap bilgileri ERP’den alınabilir; mobilde oluşturulan sipariş tekrar ERP’ye gönderilebilir. Bu entegrasyon doğru kurulmazsa mobil uygulama ile merkez sistem arasında veri farkı oluşur. Bu yüzden entegrasyonlar proje başında teknik olarak analiz edilmelidir.
Evet, bakım gerekir. Mobil uygulamalar yayınlandıktan sonra işletim sistemi güncellemeleri, cihaz uyumlulukları, mağaza politikaları, güvenlik yamaları ve üçüncü parti servis değişiklikleri nedeniyle düzenli takip ister. Ayrıca kullanıcı geri bildirimleri geldikçe yeni modül, performans iyileştirmesi veya ekran revizyonu gerekebilir. Kurumsal uygulamalarda bakım daha da önemlidir, çünkü uygulama çoğu zaman şirketin operasyonuna bağlı çalışır. Bir bildirim servisi, ödeme entegrasyonu veya API bağlantısı bozulduğunda iş süreçleri aksayabilir. Bu nedenle yayın sonrası destek, hata takibi, versiyonlama ve izleme planı teklif aşamasında konuşulmalıdır.
Mobil uygulamada teknik borç; hızlı teslim, eksik test, zayıf mimari ve plansız bakım yüzünden uygulamanın zamanla pahalı, kırılgan ve yavaş geliştirilir hale gelmesidir. Bu rehber; teknik borcu önlemek için mimari, test, sürümleme, bakım ve maliyet kararlarını somut örneklerle açıklar.
Mobil uygulama güncelleme süreci yalnızca yeni sürüm yüklemek değildir. Kapsam analizi, sürüm notu, test, mağaza onayı, kademeli dağıtım, hata takibi ve bakım planı birlikte yönetildiğinde uygulama daha stabil, güvenli ve sürdürülebilir olur.
Mobil uygulama bakım ve destek süreci; yayındaki bir uygulamanın güvenli, hızlı, güncel ve kullanıcı beklentilerine uygun kalmasını sağlar. Bu rehberde bakım kapsamını, destek seviyelerini, maliyet aralıklarını, mağaza uyumluluğunu, güvenlik kontrollerini ve Atalay Tech'in proje sonrası yaklaşımını pratik örneklerle in
