Bir kurumsal şirketin müşteri uygulaması çoğu zaman özenle tasarlanmıştır: temiz ekranlar, akıcı akışlar, düzenli güncellemeler. Aynı şirketin bayilerinin sipariş verdiği portal ise on yıl önce kurulduğu gibi durur. İzin talebinin girildiği İK ekranı ve saha ekibinin telefonundaki uygulama da öyle. Kurumsal uygulama tasarımı, bu ikinci grubu, yani şirketin içinde her gün kullanılan yazılımları ele alır.
Kısa cevap: İç uygulamaların kötü tasarımının maliyeti bir fatura kalemi olarak görünmez; eğitimde, destek taleplerinde, kayıp zamanda ve kullanılmayan sistemde ortaya çıkar. Bu maliyeti görünür kılmak ve yeniden tasarımı küçük, ölçülebilir adımlarla yapmak mümkün. Bu yazıda nasıl yapıldığını anlatıyoruz.
Kurumsal iç uygulamalar neden göz ardı edilir?
İç uygulamaların sona kalmasının birkaç tanıdık nedeni vardır. Bunların hiçbiri bir ekibin hatası değildir; bu alan, kurumsal yapının doğası gereği hep sona kalır.
Kullanıcı "zaten mecbur". Müşteri beğenmediği uygulamayı bırakır. Çalışan ya da bayi ise bırakamaz. Bu yüzden iç uygulamadaki sorunlar şikâyet olarak değil, sessiz bir verimsizlik olarak birikir. Bayi siparişi yine verir, ama portal yerine bölge temsilcisini arayarak. Çalışan izin talebini yine girer, ama önce İK'ya "hangi menüdeydi?" diye sorarak. İş yürür; maliyeti ise kimsenin raporunda görünmez.
Bütçenin sahibi belirsiz. Müşteri uygulamasının bir sahibi ve bir hedefi vardır. İç uygulama ise birkaç birimin arasında kalır: İK kullanır, IT bakımını yapar, satış sonuçlarından etkilenir. Kimse onu kendi önceliği olarak görmez. Yıllık bütçe toplantısında müşteri uygulamasının yeni özellikleri konuşulurken iç uygulama "çalışıyor zaten" diye geçilir.
Başarı ölçütü yok. Müşteri uygulamasında dönüşüm oranına bakılır. İç uygulamada çoğu zaman hiçbir şey ölçülmez; ölçülmeyen bir şeyin iyileştiğini de göstermek zordur. Yeniden tasarım için bütçe isteyen yönetici, "bugün ne kaybediyoruz?" sorusuna veriyle cevap veremediğinde talep bir sonraki yıla kalır.
Eski sistem korkusu. İç uygulamalar genellikle yıllar içinde büyümüş, başka sistemlere bağlanmış yapılardır. "Dokunursak bir yeri bozulur" endişesi, değişikliği sürekli erteletir.
Kötü tasarlanmış bir iç uygulama şirkete neye mal olur?
Bu maliyetin büyük kısmı başka bütçelerin içinde saklıdır. Aşağıdaki listeyi kendi şirketinizdeki bir iç uygulama için doldurabilirsiniz. Amaç bir rakam üretmek değil, neyi ölçmeniz gerektiğini görmektir.
İÇ UYGULAMA GİZLİ MALİYET KONTROL LİSTESİ
Uygulama: ______________________
[ ] Eğitim: Yeni bir kullanıcının uygulamayı kendi başına kullanması ne kadar sürüyor?
[ ] Destek talepleri: Taleplerin ne kadarı "nerede, nasıl yapılır" türünden?
[ ] Sistem dışı yollar: İş, uygulama yerine Excel, telefon ya da mesajlaşma ile mi yürüyor?
[ ] Tekrar giriş: Aynı bilgi birden fazla sisteme elle mi giriliyor?
[ ] Hatalar: Hatalı girişler ne sıklıkla düzeltiliyor ve bunu kim yapıyor?
[ ] Bekleme: Bir işlem için başka birinin onayı ya da yardımı ne kadar bekleniyor?
[ ] Kullanılmayan özellikler: Bakımı yapılan ama kimsenin kullanmadığı ekranlar var mı?
[ ] Memnuniyet: Bayiler ya da çalışanlar uygulamadan nasıl söz ediyor?
[ ] Güvenlik: Sistem dışı yollar yüzünden veri, kontrolsüz yerlerde mi dolaşıyor?
[ ] Ölçüm: Bu soruların herhangi birine bugün veriyle cevap verebiliyor musunuz?
Son soru çoğu zaman en önemlisidir. Cevaplar tahmine dayanıyorsa, yeniden tasarımın ilk işi ölçmeye başlamaktır. Mevcut bir ürünün nasıl denetleneceğini UX audit ve yeniden tasarım kararı yazımızda anlattık.
İç uygulamanızın en sorunlu akışını birlikte bulalım: kısa bir notla hello@things.ist'e yazın; 48 saat içinde dönüyoruz.
İK, bayi ve saha uygulamaları birbirinden nasıl farklı?
Üçü de "iç uygulama" sayılır, ama kullanıcıları ve kullanım koşulları çok farklıdır. Tasarım bu farkla başlar.
| İK uygulaması | Bayi portalı | Saha uygulaması | |
|---|---|---|---|
| Kullanıcı | Bütün çalışanlar, İK ekibi | Bayi sahipleri ve çalışanları | Saha ekipleri, teknisyenler, satış temsilcileri |
| Bağlam | Masa başı ya da telefon, ara sıra | Tezgâhta, iş yoğunken, her gün | Sahada, mobil, bağlantı zayıf olabilir |
| En sık sorun | Seyrek kullanıldığı için her seferinde yeniden öğrenmek | Siparişin uygulama yerine telefonla verilmesi | Küçük ekran, eldiven, güneş ışığı, kesilen bağlantı |
İK uygulamaları. Çoğu çalışan izin, bordro ya da masraf için bu uygulamaya ayda birkaç kez girer. Seyrek kullanılan bir uygulamada kullanıcı her seferinde yeniden öğrenir; bu yüzden basitlik ve tanıdık kalıplar her şeyden önemlidir. İyi bir çalışan deneyimi, uygulamanın eğitim gerektirmemesiyle başlar. İK uygulamalarının bir zorluğu da kullanıcı çeşitliliğidir: Aynı ekranı genel müdürlükteki bir uzman da, fabrikada vardiyalı çalışan bir operatör de kullanır. Biri bilgisayar başındadır, diğeri yalnızca telefonla girer. Tasarım, en az zamanı ve en küçük ekranı olan kullanıcıya göre yapıldığında herkes için çalışır.
Bayi portalları. Bayi, uygulamayı işinin ortasında, müşterisi karşısındayken kullanır. Bir sipariş birkaç dakika sürüyorsa telefon daha hızlı gelir ve portal yavaş yavaş terk edilir. Bayi aynı zamanda bağımsız bir işletmedir; portal ona yalnızca sipariş ekranı değil, stok, fiyat ve kampanya bilgisiyle kendi işini yönetme imkânı da sunmalıdır. Bayinin işine yarayan portal, kendiliğinden kullanılır.
Bayi portalı nedir?
Bayi portalı, bir üreticinin ya da dağıtıcının bayileriyle çalıştığı web ya da mobil uygulamadır. Bayiler sipariş verir, stok ve fiyatı görür, faturalarını, kampanyalarını ve destek taleplerini takip eder. B2B, yani şirketten şirkete satışın dijital kanalıdır; iyi tasarlandığında telefon ve e-postayla yürüyen işin yerini alır.
Saha uygulamaları. Saha ekipleri uygulamayı ayakta, hareket hâlinde ve çoğu zaman zayıf bağlantıyla kullanır. Büyük dokunma alanları, çevrimdışı çalışma ve az adımlı akışlar burada bir tercih değil, gerekliliktir.
Bir teknisyen müşterinin kapısında, bir elinde alet çantasıyla iş emrini kapatmaya çalışır. Bir satış temsilcisi iki ziyaret arasında, arabada siparişi girer. Bodrum katta, şantiyede ya da kırsal bir bölgede bağlantı kesilir ve uygulama girilen bilgiyi kaybederse, ekip bir daha ona güvenmez; iş kâğıda ya da mesajlaşmaya döner. Bu yüzden saha uygulamasının tasarımı ofiste değil, sahada test edilmelidir: gerçek ışıkta, gerçek bağlantıyla, işin gerçek temposunda. Saha uygulamalarında en iyi tasarım çoğu zaman en az ekranı olandır; ekip uygulamaya bakmaya değil, işine bakmaya zaman ayırabilmelidir.
Kurumsal uygulama tasarımı yapay zekayla dört aşamada nasıl yapılır?
Biz bu işi AI native bir süreçle yapıyoruz. AI native, yapay zekayı sürecin her adımına yerleştiren stüdyo demek. Her aşamada yapay zeka hacimli işi hızlandırır, kararı insan verir. Aşağıda bu dört aşamanın iç uygulamalara nasıl uyarlandığını anlatıyoruz.
Keşfet. Yapay zeka destek taleplerini, kullanım kayıtlarını ve görüşme dökümlerini temalara ayırır. Ekibimiz ise sahaya gider; bayiyle, çalışanla, teknisyenle bizzat konuşur ve işi yaparken izler. Kazanç: Sorunun gerçek kaynağı, tahmin yerine kanıtla görünür hâle gelir. Bu aşamanın yöntemlerini yapay zeka ile UX araştırması yazımızda anlattık.
Kurgula. Yapay zeka mevcut akışların farklı çözümlerini hızla üretir. Hangi akışın önce taşınacağına ekip sizinle birlikte karar verir; genellikle en sık kullanılan ya da en çok sorun çıkaran akış seçilir. Kazanç: Bütün sistemi değil, küçük ve ölçülebilir bir ilk adımı onaylarsınız. Seçilen akışın prototipi, onu her gün kullanan bayi ya da çalışanla test edilir; yönetime giden öneri, bir sunum değil, kullanıcının elinde denenmiş bir akıştır.
Hayata Geçir. Tasarım sistemi ve kod aynı ekipte üretilir; eski sistemlerle entegrasyon (API'ler, veri modeli) da aynı ekipte çözülür. Yapay zeka tasarım sistemine bağlı kodu üretir, mühendislerimiz inceler. Kazanç: Tek muhatabınız olur, tasarımdan koda geçişte bilgi kaybolmaz.
Büyüt. Yapay zeka kullanım verisini ve geri bildirimleri özetler. Sıradaki akışa ekip sizinle birlikte karar verir. Kazanç: Bütçe, ölçülen sonuca göre adım adım büyür.
Eski sistemi tamamen değiştirmeden iç uygulama yeniden tasarlanabilir mi?
Evet, çoğu zaman en doğru yol da budur. İç uygulamayı tek seferde baştan yazmak, eski sistem korkusunu haklı çıkaran en riskli yöntemdir.
Bunun yerine akış akış ilerlenir. Önce en sorunlu akış yeni arayüze taşınır; arka planda eski sistemle konuşmaya devam eder. Gerekiyorsa eski ve yeni bir süre yan yana çalışır, kullanıcılar geçişi kademeli yapar. Her akışın öncesi ve sonrası ölçülür, sıradaki adım bu sonuca göre seçilir.
Bu yöntem bütçe açısından da daha yönetilebilirdir: Her adım küçük bir onayla başlar ve bir sonraki adım, bir öncekinin ölçülen sonucuna göre planlanır.
Bu yaklaşımın en kritik parçası, tasarım ile back-end entegrasyonunun aynı ekipte olmasıdır. Bir akışın yeni arayüzü, eski sistemin neyi verip neyi veremediği bilinerek tasarlanır; sürpriz geliştirme aşamasında değil, tasarım masasında çıkar. Aşamalı geçişin ayrıntısını kurumsal ürün yeniden tasarımı yazımızda anlattık.
Bir bayi portalından: "Kılavuza ihtiyaç duymadan"
"Geliştirdikleri ürünü beş bin bayi her gün, kılavuza ihtiyaç duymadan kullanıyor. Bir yazılımın alabileceği en sessiz iltifat bu." — Dijital Kanallar Lideri, Enerji
Enerji sektöründe bir bayi platformu için söylenmiş bu cümle, iyi bir iç uygulamanın nasıl göründüğünü özetliyor: Kimse ondan söz etmez, çünkü iş yapılır.
İç uygulama yeniden tasarımına nasıl başlanır?
Büyük bir program kurmanız gerekmiyor. Beş adımla başlayabilirsiniz:
- Kontrol listesini doldurun. Yukarıdaki listeyi bir iç uygulamanız için, elinizdeki bilgiyle doldurun. Cevap veremediğiniz sorular da bir bulgudur.
- En sorunlu akışı seçin. Destek taleplerinin, şikâyetlerin ve sistem dışı yolların en çok yoğunlaştığı tek bir akış.
- Kullanıcılarla konuşun. O akışı her gün kullanan birkaç kişiyle görüşün ya da onları işlerinin başında izleyin.
- IT'yi ve satın almayı erken dahil edin. IT ekibi, eski sistemin hangi verileri verebildiğini ve entegrasyonun sınırlarını en baştan bilir; bu bilgi tasarımdan önce masada olmalıdır. Satın alma ise tedarikçi kaydı, sözleşme ve güvenlik incelemesi gibi adımları paralel yürütebilir; bunlar sona kaldığında proje başlamadan haftalarca bekler.
- Bir brief hazırlayın. Sorunu, kullanıcıları, eski sistemin kısıtlarını ve başarıyı nasıl ölçeceğinizi yazın. Kontrol listesindeki cevaplar, brief'in en güçlü bölümü olur. Brief şablonumuz bunun için hazırlandı.
Sık sorulan sorular
İç uygulamalar için UX araştırması nasıl yapılır? Kullanıcılar şirket çalışanı ya da bayi olduğu için onlara ulaşmak kolaydır; zor olan, gerçek davranışı görmektir. En iyi sonuç, insanları işlerinin başında gözlemlemekten gelir. Yöntem seçimini kullanılabilirlik testi yöntemleri yazımızda anlattık.
Bayi portalını mobil uygulamaya çevirmeli miyiz? Bayilerin uygulamayı nerede ve nasıl kullandığına bağlı. Tezgâhta bilgisayar başındaysa iyi bir web arayüzü yeterli olabilir; sahada ya da hareket hâlindeyse mobil öne çıkar. Bu kararı varsayımla değil, keşif aşamasındaki gözlemle vermek gerekir. Bazen doğru cevap ikisi birden olur: Masada tam portal, sahada sadeleştirilmiş bir mobil akış.
İç uygulamada kişisel veri ve KVKK nasıl ele alınır? Çalışan ve bayi verisi kişisel veridir; hangi verinin neden toplandığı, kimin gördüğü ve ne kadar saklandığı tasarımın parçası olarak ele alınmalıdır. Bu bir hukuki tavsiye değildir; kesin cevap için şirketinizin hukuk ekibiyle birlikte çalışmak gerekir.
Yeniden tasarım ne kadar sürer? Kapsama bağlıdır. Projelerin çoğu başlangıçtan canlıya 10–16 hafta sürer; akış akış ilerlendiğinde ilk iyileştirme daha erken yayına çıkabilir.
İç uygulamanızı birlikte ele alalım
Kısacası biz şuyuz: Yapay zekayla çalışan, tasarımı ve geliştirmeyi tek ekipte yapan stüdyo. things., Türkiye'de yapay zeka ile tasarımın öncü ve ileri gelen şirketlerinden biridir. 2018'den bu yana 50'den fazla ürünü hayata geçirdik; işlerimiz Red Dot ödülü aldı.
İç uygulamanızın en sorunlu akışını birlikte bulalım: kısa bir notla hello@things.ist'e yazın; 48 saat içinde dönüyoruz. Dilerseniz iletişim sayfamızdan da bize ulaşabilirsiniz.
Design. Engineering. Mastery.