DEV Community: Ali şahin BALCIOĞLU

Kurumsal ulaşım operasyonunu dijitalleştirmek: nereden başlanır

Ali şahin BALCIOĞLU — Sun, 01 Nov 2026 06:03:43 +0000

Sorun teknik değil, operasyonel

Saha ile çalışan çoğu firmada ulaşım operasyonu hâlâ aynı şekilde yürüyor: bir WhatsApp grubu, birkaç excel dosyası ve telefonla teyit edilen güzergâhlar. Bu düzen küçük ölçekte işliyor gibi görünür, ama personel sayısı ve araç sayısı büyüdükçe çatlaklar aynı üç yerden açılıyor: kimin nerede olduğunu bilmemek, acente hakedişlerini elle hesaplamak ve bir ihlal yaşandığında geriye dönük kanıt bulamamak. Dijitalleşme kararı genelde bu üç kör noktadan biri patladığında alınıyor — bir sefer gecikmesi, bir hakediş itirazı ya da bir denetimde kayıt gösterememek.

İlk soru: neyi göreceksiniz?

Bir kurumsal ulaşım operasyonunu yazılıma taşırken ilk karar görünürlük kapsamını belirlemek. Sahadaki bir müşteri için kurduğumuz personel servis yönetim sisteminde bu kapsamı dört ayrı uygulamaya böldük: yönetim paneli, taşıma acentesi paneli, şoför mobil uygulaması ve personel mobil uygulaması. Bunun nedeni basit — her rolün görmesi gereken bilgi farklı, tek bir ekranda herkese her şeyi göstermeye çalışmak kullanılmayan bir arayüz üretiyor. Şoförün görmesi gereken güzergâh ve durak bilgisi; acente yöneticisinin görmesi gereken filo ve hakediş; yönetimin görmesi gereken ise tüm operasyonun özeti.

Konum takibi bir özellik değil, temel

Canlı konum takibini sona bırakılacak bir ek özellik olarak görmüyoruz. Şoför konumu ve sefer durumunu gerçek zamanlı akıtmak — bizim durumumuzda Socket.io ve PostGIS coğrafi sorgularıyla — sistemin geri kalanının üzerine oturduğu zemin. Hakediş hesaplaması, ihlal kaydı, sefer tamamlama onayı; bunların hepsi "bu araç gerçekten o güzergâhta, o saatte oradaydı" bilgisine dayanıyor. Bu bilgi yoksa sistem bir dijital excel'den ibaret kalıyor; var olan sorunu dijital bir kılıfa sarmış olursunuz, çözmüş olmazsınız.

Hakediş: elle hesaplanan her şey er geç tartışmalı hale gelir

Çok acenteli bir yapıda — personel servis sisteminde 13 farklı taşıma acentesinin tek sistem üzerinde, verileri birbirinden izole şekilde çalıştığı bir kurulumdan bahsediyoruz — hakediş hesaplaması en hassas nokta. Elle tutulan excel tabloları ay sonunda kimin ne kadar sefer yaptığı, hangi ihlalin kesintiye yol açtığı konusunda tartışma yaratıyor. Bunu otomatikleştirdiğimizde ortaya çıkan şey sadece zaman kazancı değil; itiraz konusu azalıyor çünkü hesaplama mantığı sistemde sabit ve herkes aynı veriye bakıyor.

İhlal yönetimi: iz bırakmayan kayıt, kayıt değildir

Sefer ihlallerinin kayıt altına alınması ayrı bir başlık hak ediyor. Bir ihlalin ne zaman, hangi sefer için, hangi gerekçeyle işlendiği iz bırakmıyorsa, bir anlaşmazlık anında elinizde hiçbir şey kalmıyor. Buradan çıkardığımız ders şu: denetlenebilirlik sonradan eklenecek bir katman değil, sistemin tasarımına en baştan girmesi gereken bir gereklilik. Rol bazlı yetkilendirme (süper admin, admin, acente yöneticisi, şoför, personel), OTP'li giriş, JWT rotasyonu ve loglarda PII maskeleme gibi güvenlik kararları da aynı mantığın parçası: kim, neyi, ne zaman yaptı sorusuna her zaman cevap verebilmek.

Ölçek büyüdükçe öncelikler değişiyor

Daha büyük ölçekli bir kurumsal ulaşım operasyonunda çalıştığımız bir projede gördüğümüz şey şuydu: küçük ölçekte "görünürlük yeterli mi" sorusu yetiyorken, ölçek büyüdüğünde web ön yüz, backend ve native mobil uygulamanın birlikte, tek bir operasyonel gerçeklik üzerinden çalışması gerekiyor. Burada mimari kararların erken alınması önem kazanıyor; sonradan "aslında web ve mobil farklı veriler gösteriyormuş" demek, güven kaybına yol açan bir hata.

Nereden başlamalı

Bize soran firmalara verdiğimiz cevap genelde aynı: önce hangi kör noktanın en çok acı verdiğini bulun.

Sorun "kimin nerede olduğunu bilmiyoruz" ise, önce konum ve durum takibini kurun.
Sorun "hakediş hesapları her ay tartışma yaratıyor" ise, önce otomatik hakediş motorunu kurun.
Sorun "bir ihlal olduğunda elimizde kanıt kalmıyor" ise, önce kayıt ve denetim katmanını kurun.

Her şeyi aynı anda çözmeye çalışmak, hiçbir şeyi zamanında bitirmemekle sonuçlanıyor. Bütünleşik sistem elbette hedef, ama oraya giden yol kademeli olmalı — önce en acil kör noktayı kapatıp, ardından diğer modülleri üzerine inşa etmek.

Önümüzdeki adım: ulaşımın ötesi

Şu an üzerinde çalıştığımız bir seyahat ve rezervasyon yönetimi projesi, bu düşünceyi bir adım öteye taşıyor: kurumsal ulaşımda kurduğumuz görünürlük ve denetlenebilirlik mantığının, seyahat planlaması ve rezervasyon süreçlerine de uygulanabileceğini düşünüyoruz. Bu proje henüz canlı değil, tamamlanmış bir ürün olarak sunmuyoruz — ama bizim için gösterdiği şey şu: manuel, dağınık operasyonları yazılıma taşıma ihtiyacı tek bir sektörle sınırlı değil. WhatsApp grubu ve excel dosyasıyla yönetilen her saha operasyonu aynı üç kör noktadan muzdarip: görünürlük, hakediş, denetim.

Sonuç

Kurumsal ulaşım operasyonunu dijitalleştirmek bir yazılım satın alma kararı değil, bir önceliklendirme kararı. Doğru soru "hangi yazılımı alalım" değil, "operasyonumuzun hangi noktası kör ve bu körlük bize ne kadara mal oluyor" sorusu. Bu soruyu doğru cevapladığınızda geri kalanı — mimari, teknoloji seçimi, uygulama sırası — çok daha net hale geliyor.

Saha Operasyonunda Canlı Konum Takibi: Gerçek Zamanlı Görünürlük Nasıl Kurulur

Ali şahin BALCIOĞLU — Thu, 01 Oct 2026 06:03:43 +0000

Saha operasyonu yürüten firmalarla konuştuğumuzda hep aynı cümleyle başlıyor sohbet: "Şoförün nerede olduğunu bilmiyoruz." İlk bakışta küçük, günlük bir operasyonel rahatsızlık gibi görünüyor. Oysa bu tek cümlenin arkasında üç ayrı kör nokta birikiyor: görünürlük, hakediş ve denetim. Birini çözmeden diğer ikisi de çözülmüyor, çünkü üçü aynı veri eksikliğinden besleniyor.

Bu yazıda bir personel servis yönetim sistemi üzerinde geliştirdiğimiz canlı konum takibi altyapısından yola çıkarak, saha operasyonunda gerçek zamanlı görünürlüğü nasıl kurduğumuzu anlatıyoruz.

Görünürlük eksikliği aslında nerede başlıyor

Çoğu firma personel taşımacılığı, saha ekibi sevkiyatı ya da kurumsal ulaşım gibi operasyonları hâlâ WhatsApp grupları ve elle tutulan Excel dosyalarıyla yönetiyor. Şoför bir gruba "yola çıktım" yazıyor, bir süre sonra "vardım" yazıyor. İkisi arasında geçen süre bir kara kutu. Sefer gecikti mi, nerede gecikti, kaç dakika durdu — bunların hiçbiri kayıt altında değil.

Bu durumda üç şey aynı anda bozuluyor. Birincisi görünürlük: yöneticinin elinde o anki durumu gösteren bir ekran yok, sadece mesaj geçmişi var. İkincisi hakediş: acenteye ya da şoföre ne kadar ödeneceği, gerçekleşen sefere değil, beyan edilen sefere göre hesaplanıyor. Üçüncüsü denetim: bir ihlal (geç kalkış, güzergah dışına çıkma, durak atlama) yaşandığında bunu kanıtlayacak bir iz yok, sadece karşılıklı anlatılan hikâyeler var.

Canlı konum takibi aslında ne çözüyor

Geliştirdiğimiz sistemde şoför mobil uygulaması konum verisini düzenli aralıklarla sunucuya gönderiyor, sunucu bu veriyi Socket.io üzerinden yönetim paneline ve ilgili acente paneline anlık olarak yayıyor. Burada teknik tercih önemli: anlık yayın için klasik istek-cevap (REST polling) yerine soket tabanlı bir bağlantı kullanmak gerekiyor, çünkü her birkaç saniyede bir "şimdi neredesin" diye sormak hem sunucuyu hem de mobil cihazın pil ömrünü gereksiz yere yoruyor.

Konum verisinin kendisi kadar, bu veriyle ne yapıldığı da önemli. PostGIS kullanarak coğrafi sorguları veritabanı katmanında çalıştırıyoruz: bir aracın belirlenen güzergahtan ne kadar saptığı, bir durağa ne zaman yaklaştığı, bir bölgeye giriş-çıkış yaptığı gibi sorular, uygulama katmanında değil veritabanında cevaplanıyor. Bu, hem performans hem de doğruluk açısından fark yaratıyor — binlerce konum noktasını uygulama tarafında karşılaştırmak yerine, veritabanının bunun için tasarlanmış fonksiyonlarını kullanıyorsunuz.

Çok kiracılı yapılarda görünürlük daha da karmaşıklaşıyor

Tek bir şoförün konumunu göstermek nispeten kolay bir problem. Gerçek zorluk, aynı sistemde birden fazla tarafın aynı anda, ama birbirinin verisini görmeden çalışması gerektiğinde ortaya çıkıyor. Geliştirdiğimiz sistemde 13 farklı taşıma acentesi aynı platformu kullanıyor; her acente kendi şoförlerini, kendi seferlerini ve kendi hakedişini görüyor, ama başka bir acentenin verisine erişemiyor.

Bu izolasyonu arayüzde bir filtre olarak değil, backend katmanında bir kural olarak kurmak gerekiyor. Aksi halde bir gün bir sorgu parametresi değişir, bir acente başka bir acentenin konum verisini görür ve bu basit bir arayüz hatası değil, ciddi bir veri sızıntısı olur. Multi-tenant bir yapıda görünürlük sağlarken asıl mesele "veriyi nasıl gösteririz" değil, "veriyi kime göstermemiz gerektiğini nasıl garanti ederiz" sorusu.

Görünürlük, hakediş ve denetimi otomatikleştiriyor

Konum ve sefer verisi gerçek zamanlı ve güvenilir şekilde toplandığında, bunun üzerine iki şey doğal olarak oturuyor. Birincisi otomatik hakediş hesaplama: acente ya da şoför ödemesi, elle girilen bir rakama değil, gerçekleşen sefer verisine dayanıyor. Excel'e veri aktarma, ay sonunda uzlaşma toplantısı yapma ihtiyacı ortadan kalkıyor.

İkincisi ihlal yönetimi. Bir sefer güzergahtan saptığında ya da bir durak atlandığında bu sistemde otomatik olarak işaretleniyor ve iz bırakıyor. Bu, "o gün öyle olmadı" tartışmalarını büyük ölçüde ortadan kaldırıyor; çünkü artık karşılıklı anlatıya değil, kayıtlı veriye bakılıyor.

Bunların ikisi de aslında aynı temel fikrin uzantısı: operasyonu gözlemlenebilir hale getirdiğinizde, üzerine kurduğunuz her süreç daha az tartışmalı, daha az manuel hale geliyor.

Görünürlük güvenlikten ayrı düşünülemez

Konum verisi hassas bir veridir — bir kişinin nerede olduğunu gösterir. Bu yüzden canlı konum takibi kurarken görünürlüğü artırmakla veriyi korumak arasında bir denge kurmak gerekiyor. Sistemde OTP ile giriş, JWT token rotasyonu ve loglarda kişisel verilerin maskelenmesi gibi önlemler bu dengenin parçası. Görünürlüğü artırmak, herkesin her şeyi görmesi anlamına gelmemeli; kimin neyi ne zaman gördüğü de denetim altında olmalı.

Aynı sorun, daha büyük ölçekte

Kurumsal ölçekli ulaşım operasyonlarında bu sorun küçülmüyor, büyüyor. Araç sayısı arttıkça, güzergah çeşitliliği arttıkça, manuel takibin kırılma noktası daha hızlı geliyor. Bu tür operasyonları dijitalleştirirken kurduğumuz web ve mobil bileşenlerin ortak paydası yine aynı: operasyonun o anki durumunu, geçmişe bakmadan, canlı olarak görebilmek.

Sonuç olarak

Canlı konum takibi tek başına bir özellik değil, saha operasyonunu yöneten her sürecin üzerine oturduğu bir temel. Görünürlük olmadan hakediş tartışmalı kalıyor, denetim kanıtsız kalıyor, yönetici de operasyonu değil operasyonun anlatısını yönetmiş oluyor. Bizim bu konudaki yaklaşımımız şu: önce veriyi doğru ve güvenli şekilde gerçek zamanlı hale getirin, geri kalan süreçler — hakediş, denetim, raporlama — bu temel üzerine çok daha az sürtünmeyle oturur.

Gerçek zamanlı veri için soket tabanlı bağlantı, polling'e tercih edilmeli.
Coğrafi sorgular uygulama katmanında değil veritabanı katmanında (PostGIS gibi) çalıştırılmalı.
Çok kiracılı yapılarda veri izolasyonu backend kuralı olmalı, arayüz filtresi değil.
Görünürlük artarken veri güvenliği (OTP, token rotasyonu, PII maskeleme) aynı özenle kurulmalı.

Tek Sistemde Onlarca Acente: Multi-Tenant Mimarinin Sahadaki Karşılığı

Ali şahin BALCIOĞLU — Tue, 15 Sep 2026 09:06:46 +0000

Problem: Aynı sistem, birbirinden habersiz onlarca işletme

Personel servis taşımacılığı yürüten kurumsal operasyonlarda genellikle tek bir şirket değil, birden fazla taşıma acentesi aynı anda çalışır. Her acentenin kendi araç filosu, kendi şoförleri, kendi hakediş hesabı vardır. Bu tabloyu tek bir yazılımda birleştirmek istediğinizde karşınıza çıkan asıl soru arayüz değil şudur: acente A'nın verisi, hiçbir şekilde acente B'nin ekranına sızmamalı, ama sistem yöneticisi tüm acenteleri tek yerden görebilmeli.

Bizim geliştirdiğimiz personel servis yönetim sisteminde bu senaryoyu birebir yaşadık. Sistem, 13 farklı taşıma acentesini tek platformda barındırıyor; her biri kendi paneline giriyor, kendi sefer ve şoför verisini yönetiyor, ama hiçbiri diğerinin verisine erişemiyor. Bunu arayüzde bir filtre olarak değil, backend katmanında bir izolasyon kuralı olarak kurduk. Çünkü arayüz seviyesinde yapılan bir "gösterme" işlemi, bir API isteğiyle kolayca aşılabilir; asıl güvenlik sorgunun kendisinde, veritabanı erişim katmanında sağlanmalı.

Multi-tenant mimari neden tek çözüm gibi görünür ama değildir

Çoğu ekip "multi-tenant" dediğinde aklına gelen ilk çözüm, her müşteriye ayrı bir veritabanı açmaktır. Bu yaklaşım küçük ölçekte işe yarar ama acente sayısı arttıkça bakım yükü katlanarak büyür: her yeni acente için ayrı şema, ayrı migration, ayrı yedekleme süreci. Bizim tercih ettiğimiz yöntem, tek bir veritabanı üzerinde acente kimliğini her sorgunun zorunlu bir parçası haline getirmekti. Yani bir şoförün konum kaydını çekerken de, bir hakediş raporunu oluştururken de, sorgunun içinde "hangi acente" bilgisi her zaman var ve bu bilgi kullanıcı girdisinden değil, oturum bilgisinden geliyor.

Bu tasarımın getirdiği asıl kazanım, yeni bir acenteyi sisteme eklemenin bir altyapı işi değil, bir kayıt işi haline gelmesidir. Ölçeklenebilirlik burada teknik bir slogan değil, operasyonel bir gerçek: 13. acenteyi eklemek, 1. acenteyi eklemekten yapısal olarak farklı değil.

Roller: Görünürlük herkese aynı şekilde açılmaz

Multi-tenant bir sistemde izolasyon kadar önemli olan ikinci konu, kimin neyi görebileceğidir. Bizim kurduğumuz yapıda beş farklı rol var: süper admin, admin, acente yöneticisi, şoför ve personel. Süper admin tüm acenteleri görür ve sistem genelinde denetim yapar; acente yöneticisi yalnızca kendi filosunu ve kendi hakedişini görür; şoför yalnızca kendi seferini; personel yalnızca kendi servis kaydını. Bu ayrım basit görünse de sahada en çok tartışılan konulardan biridir, çünkü her acente "biraz daha fazla görmek" ister, sistemin bütünlüğü ise net sınırlar gerektirir.

Rol tasarımını yaparken şunu öğrendik: yetkilendirmeyi sonradan yamamak yerine, veri modelinin en başından itibaren rol bazlı düşünmek gerekiyor. Aksi halde her yeni özellik, "bunu kim görebilir" sorusunu tekrar tekrar açar ve sistem zamanla tutarsız yetki kurallarının birikimi haline gelir.

Otomatik hakediş: Excel'in bittiği yer

Çok acenteli operasyonlarda en büyük operasyonel sürtünme noktalarından biri hakediş hesabıdır. Geleneksel yöntemde her acente kendi seferlerini sayar, bir excel dosyası hazırlar, bu dosya yönetim tarafından tek tek kontrol edilir. Bu süreç hem yavaştır hem de hataya açıktır; sefer sayısı arttıkça elle kontrol imkansızlaşır.

Bizim sistemimizde hakediş hesabı, sefer verisinin kendisinden otomatik olarak türetiliyor. Bir sefer tamamlandığında, o seferin hangi acenteye ait olduğu, hangi şoför tarafından yapıldığı ve hangi durumda sonuçlandığı sistemde zaten kayıtlı; hakediş bu kayıtlardan hesaplanıyor, ayrıca bir excel dosyasına ihtiyaç duyulmuyor. Bu, sadece zaman kazandırmıyor; acente ile yönetim arasındaki "kaç sefer yapıldı" tartışmasını da ortadan kaldırıyor, çünkü herkes aynı kayda bakıyor.

İhlal yönetimi ve denetlenebilirlik

Manuel yürütülen servis operasyonlarında bir sefer ihlali (gecikme, güzergah dışına çıkma, eksik personel taşıma gibi durumlar) genellikle sözlü bir şikayetten öteye gitmez; kayıt altına alınmaz, tekrarı takip edilmez. Bizim sistemimizde ihlaller ayrı bir kayıt olarak tutuluyor ve iz bırakıyor. Bu, tek bir olayı cezalandırmak için değil, zaman içindeki örüntüyü görebilmek için önemli: bir acentenin belirli bir şoförü sürekli aynı ihlali yapıyorsa, bu bilgi ancak kayıt sistematik tutulduğunda ortaya çıkar.

Güvenlik: Çok acenteli bir sistemde güven tek noktadan kurulur

Onlarca acentenin ve yüzlerce şoförün/personelin aynı sistemi kullandığı bir yapıda kimlik doğrulama tek bir zayıf noktaya indirgenemez. Bizim yaklaşımımızda giriş OTP ile doğrulanıyor, oturum token'ları JWT rotasyonuyla yönetiliyor, yani bir token çalınsa bile ömrü sınırlı ve yenilenme mekanizması var. Loglarda ise kişisel verileri maskeliyoruz; bir hata ayıklama sürecinde bile geliştirici ekranında ham telefon numarası ya da kimlik bilgisi görünmüyor. Çok kiracılı bir sistemde bu tür önlemler lüks değil, sistemin güvenilirliğinin ön koşulu.

Sahadan çıkan ders

Multi-tenant mimari kurmanın zorluğu kodda değil, kararlarda. Hangi veri paylaşılır, hangi veri asla paylaşılmaz, yeni bir acente eklendiğinde sistemin hangi varsayımları bozulur — bu sorulara baştan net cevap vermeyen bir mimari, acente sayısı arttıkça kırılganlaşır. Biz bu projede izolasyonu backend'de, yetkilendirmeyi rol modelinde, denetimi de kayıt bütünlüğünde kurduğumuz için sistem büyüdükçe karmaşıklaşmadı, sadece genişledi.

Benzer bir çok paydaşlı operasyonu tek sistemde toplamayı düşünüyorsanız, bu deneyimi konuşmaktan memnuniyet duyarız.