Makineyi, cihazı ya da ekipmanı satmak işin yarısı. Diğer yarısı, o ürün müşterinin sahasında arızalandığında ne kadar hızlı ve düzenli müdahale ettiğinizde saklı. Çoğu işletmede satış sonrası servis hâlâ dağınık çalışır: müşteri WhatsApp’tan yazar, teknisyen telefonda randevu alır, kullanılan yedek parça bir deftere not düşülür, fatura ise günler sonra kesilir. Bu akışta ne verilen sözün tutulup tutulmadığı ölçülebilir, ne de servisin gerçekte kâr mı zarar mı ettiği görülebilir.
Servisi ERP’nin içine aldığınızda bu kopukluk kapanır. Servis talebi, garanti kaydına; iş emri, teknisyen takvimine; harcanan parça, stok ve maliyet kaydına bağlanır. Aşağıda satış sonrası servis ve periyodik bakımın bir ERP içinde nasıl kurulduğunu, hangi süreçleri kapsadığını ve neyi ölçülebilir kıldığını adım adım ele alıyoruz.
Servis verisi neden ERP’nin içinde olmalı?
Ayrı bir servis takip programı ya da elektronik tablo ilk başta yeterli görünür. Sorun, o verinin şirketin geri kalanından kopuk kalmasıdır. Teknisyenin taktığı yedek parça stoktan otomatik düşmezse, depoda görünen miktar ile raftaki gerçek miktar zamanla ayrışır. Servis ücreti ayrı bir yerde tutulursa, cari hesaba ve muhasebeye elle taşınır; bu da gecikme ve hata demektir.
Servis ERP’nin parçası olduğunda zincir şöyle kapanır:
- Gelen her talep, ürünün seri numarasına ve müşterinin cari kaydına bağlanır; “bu cihaz daha önce kaç kez arızalandı?” sorusunun cevabı hazır durur.
- İş emrinde kullanılan yedek parça, stoktan otomatik düşer; servis aracının üzerindeki parça bile ayrı bir depo gibi izlenebilir.
- İşçilik ve parça, servis faturasına ve maliyetine kendiliğinden yansır; ücretli mi garanti kapsamında mı olduğu kayda geçer.
- Kapanan iş emri, ürünün arıza geçmişine eklenir ve kalite tarafına sinyal olur.
Tek platform yaklaşımının değeri burada görünür. Qera’da servis verisi stok, satış, muhasebe ve cari hesap ile aynı veritabanında durur; rapor almak için sistemleri birbirine bağlamak gerekmez. Yedek parça deposunun nasıl kurulduğunu daha önce ERP’de stok ve depo yönetimi yazısında ayrıntılı anlatmıştık.
Servis talebinden iş emrine: servis döngüsü
Düzenli bir servis akışı, talebin kaydından işin kapanışına kadar tek bir zincirde ilerler. Adımlar şöyle işler:
- Talep kaydı. Müşteri arıza ya da bakım için başvurur. Talep; ürün, seri numarası, arıza tanımı ve iletişim bilgisiyle açılır. Kanal telefon, e-posta ya da web formu olabilir; hepsi aynı kayda düşer.
- Ön değerlendirme ve garanti kontrolü. Sistem, seri numarasından ürünün garanti ve sözleşme durumunu gösterir. İş ücretli mi, garanti kapsamında mı, bakım sözleşmesine mi dahil — daha en baştan belli olur.
- İş emri açma. Talep bir servis iş emrine dönüşür. İş emri; atanan teknisyeni, planlanan tarihi, yapılacak işi ve öngörülen parçaları taşır. Yapısı, üretimdeki iş emrine benzer; farkı, sahada ya da serviste yürümesidir. Üretim iş emirlerinin mantığını üretim ERP’sinde MRP, reçete ve iş emri yazısında ele almıştık.
- Müdahale ve kayıt. Teknisyen işi yapar; harcanan süreyi, değişen parçaları ve yaptığı işlemi kaydeder. Müşteri onayı (imza ya da form) alınır.
- Kapanış ve faturalama. İş emri kapanır; ücretli kısım faturaya, parçalar stoğa, işlem ise ürünün geçmişine yazılır.
Bu döngü tek sistemde döndüğünde, “hangi talep hangi aşamada?” sorusu bir panoda görünür. Açık talepler, geciken işler ve bugün planlı ziyaretler tek ekrandan takip edilir.
Teknisyen çizelgeleme ve saha servisi
Saha servisinde en kıymetli kaynak teknisyenin zamanıdır. Kimin nerede, ne zaman, hangi işte olduğunu görmeden yapılan planlama, boş yolculuklara ve gecikmelere yol açar. ERP, iş emirlerini bir takvim üzerinde teknisyenlere dağıttığında, kapasite ve uygunluk aynı ekranda görünür.
Pratikte işe yarayan noktalar şunlar:
- İş yükü dengesi: Bir teknisyenin günü dolmuşken diğerininki boşsa, atama sırasında görünür. İşler beceriye ve bölgeye göre dağıtılır.
- Öncelik ve aciliyet: Üretimi durduran bir arıza ile rutin bir bakım aynı sıraya konmaz; kritik talepler öne alınır.
- Mobil erişim: Teknisyen iş emrini, müşteri geçmişini ve kullanılacak parçaları sahadan görebildiğinde, ofise dönüp kayıt girmesi gerekmez. Qera bulut tabanlı çalıştığı için bu erişim tarayıcı üzerinden, ek sunucu kurmadan sağlanır.
Amaç teknisyeni sıkı takibe almak değil; boş yolculuğu, ikinci ziyareti ve “yanlış parçayla gitme” durumunu azaltmaktır. Doğru parçayla ilk seferde çözülen arıza, hem maliyeti hem müşteri sabrını korur.
Yedek parça stoğu ve servis maliyeti
Servisin en çok sızıntı verdiği yer yedek parçadır. Parça sahada takılır ama sistemde düşülmezse, envanter zamanla gerçeği yansıtmaz; bir sonraki iş için parça arandığında raf boş çıkar. Servis ERP’ye bağlı olduğunda her iş emri, kullanılan parçayı stoktan otomatik düşer.
Burada üç ayrıntı işi rayında tutar:
- Servis aracı stoğu. Her servis aracı ayrı bir “depo” gibi tanımlanabilir. Teknisyenin üzerindeki parça sayılır; azaldığında merkez depodan ikmal edilir.
- Parça–arıza ilişkisi. Hangi üründe hangi parçanın ne sıklıkla değiştiği birikir. Bu veri, kritik parçaların minimum stok seviyesini belirlemede yol gösterir.
- Maliyet ve ücret ayrımı. İş emri; işçilik, parça ve yol maliyetini toplar. Garanti kapsamındaki iş maliyet olarak kaydolur ama müşteriye faturalanmaz; ücretli iş ise faturaya döner. Böylece “servis departmanı kâr mı ediyor?” sorusu tahminle değil, kayıtla yanıtlanır.
Servis gelir ve giderleri muhasebeye kendiliğinden aktığında, ay sonunda departmanın gerçek katkısı görünür hâle gelir.
Periyodik (önleyici) bakım ve sözleşme yönetimi
Bekleyip arıza çıkınca müdahale etmek (tepkisel bakım) çoğu zaman en pahalı yoldur; plansız duruş, üretim kaybı ve acil parça temini demektir. Önleyici bakım ise ekipmanı arızalanmadan, planlı aralıklarla elden geçirir. ERP burada iki türlü tetik kurabilir:
- Zamana dayalı: “Her 6 ayda bir” ya da “her yıl” gibi takvim tabanlı planlar. Tarih yaklaştığında sistem iş emrini otomatik önerir.
- Kullanıma dayalı: Çalışma saati, üretilen adet ya da kat edilen mesafe gibi sayaçlara bağlı planlar. Eşik aşıldığında bakım tetiklenir.
Bakım sözleşmeleri de aynı yapıda yaşar. Bir müşteriyle yıllık bakım anlaşması yaptıysanız, sözleşme kapsamındaki ziyaretler, dahil olan parçalar ve periyot sistemde tanımlıdır. Sözleşme yenileme tarihi yaklaştığında uyarı gelir; böylece yenileme fırsatı gözden kaçmaz. Düzenli bakım geliri, servis departmanını arızaya bağlı dalgalı bir yapıdan öngörülebilir bir gelir kaynağına çevirir.
Servis SLA’sı, garanti ve arıza geçmişi
Verdiğiniz servis sözünü ölçemiyorsanız, tutup tutmadığınızı da bilemezsiniz. Servis seviyesi anlaşması (SLA – Service Level Agreement), “talebe kaç saatte dönülür”, “yerinde müdahale kaç saatte başlar” gibi hedefleri tanımlar. ERP bu süreleri iş emri üzerinde tutar: talep açılış saati, ilk yanıt, yerinde müdahale ve kapanış zaman damgalarıyla kaydolur. Hedef aşımına yaklaşan işler için otomatik uyarı ve eskalasyon kurulabilir.
Garanti takibi de aynı kaydın parçasıdır. Her ürün seri numarasıyla satıldığında, garanti başlangıcı ve süresi bellidir; servis talebi geldiğinde kapsam otomatik belirir. Bu, hem müşteriye tutarlı bir yanıt verir hem de garanti dışı işlerin ücretsiz yapılmasının önüne geçer.
Zamanla biriken arıza geçmişi kaliteye ışık tutar. Belirli bir modelde aynı parçanın sürekli arızalanması, bir tasarım ya da tedarik sorununun işaretidir. Servisten gelen bu sinyal, ürün ve satınalma tarafına geri beslendiğinde, sorun tek tek müşteride değil kaynağında çözülür.
Servisi rapora ve karara dönüştürmek
Tüm bu veri tek platformda biriktiğinde, servis artık “masraf kapısı” olmaktan çıkıp yönetilebilir bir iş koluna dönüşür. Yapay zekâ destekli raporlama bu noktada işe yarar: en çok arıza üreten ürün grubu, ortalama çözüm süresi, SLA’ya uyum oranı, teknisyen başına tamamlanan iş ve servis kârlılığı panoda kendiliğinden öne çıkar. Bu göstergeleri karara nasıl çevireceğinizi ERP verisini karara dönüştürmek: yapay zekâ destekli raporlama yazısında ayrıntılı ele almıştık.
Qera bu modülü tek platform mantığıyla sunar: servis, stok, satış ve muhasebe aynı sistemde çalışır. Microsoft Azure altyapısı üzerinde bulut olarak sunulduğu için sahadan erişim ek kurulum gerektirmez; anahtar teslim yapısıyla da 100 kullanıcıya kadar ek kullanıcı maliyeti çıkmaz, sürpriz lisans kalemleriyle karşılaşmazsınız.
Sıkça Sorulan Sorular
Servis modülü küçük işletmeler için de gerekli mi?
Ürün satıp sonrasında bakım, onarım ya da garanti hizmeti veren her işletme için yararlıdır — birkaç teknisyenle çalışan bir firma bile “hangi cihaz kimde, ne zaman servise geldi, hangi parça takıldı” sorularının cevabını tek yerde tutmaktan kazanç sağlar. Ölçek büyüdükçe, çizelgeleme ve SLA takibi olmadan servisi düzenli yürütmek giderek zorlaşır.
Saha teknisyeni sistemi telefonundan kullanabilir mi?
Qera bulut tabanlı ve tarayıcı üzerinden çalıştığı için teknisyen, iş emrini ve müşteri geçmişini sahadan görüntüleyebilir, harcanan süre ve parçaları kaydedebilir. Ayrı bir sunucu ya da yerel kurulum gerekmez.
Yedek parça stoğu servis iş emriyle otomatik güncellenir mi?
Evet. İş emrinde kullanılan parça, bağlı olduğu depodan (merkez depo ya da servis aracı stoğu) otomatik düşer. Böylece envanter gerçeği yansıtır ve kritik parçalar için minimum stok uyarısı kurulabilir.
Periyodik bakım hatırlatmaları nasıl kurulur?
İki yöntemle: takvim tabanlı (örneğin her 6 ayda bir) ya da kullanıma dayalı (çalışma saati, üretim adedi gibi bir sayaç eşiği). Tetik oluştuğunda sistem bakım iş emrini otomatik önerir; bakım sözleşmesi varsa kapsam ve periyot da tanımlıdır.
Garanti kapsamındaki işler ücretlilerden nasıl ayrılır?
Her ürün seri numarasıyla ve garanti süresiyle kaydedildiği için, servis talebi geldiğinde kapsam otomatik belirir. Garanti içindeki iş maliyet olarak kaydolur ama faturalanmaz; kapsam dışındaki iş ücretlendirilir. Bu ayrım manuel karar bekletmeden yürür.
Servisi tek platformda yönetmeye başlayın
Dağınık servis takibi, kaçan yedek parçalar ve ölçülemeyen sözler; hepsi tek bir sistemde birleştiğinde çözülür. Qera’nın servis ve bakım yönetimini işletmenizin gerçek akışıyla görmek isterseniz, Qera ERP çözümünü inceleyebilir ya da ekibimizle bir ücretsiz demo planlayabilirsiniz — kendi servis senaryonuz üzerinden nasıl işlediğini birlikte gösterelim.
