Kaynak Planlama Uygulaması: Çifte Rezervasyon, Tampon Süre ve Gerçek Kullanım Oranı

Aşağıdaki örnek ayda bir titreşim test cihazının saatlerinin %85,9’u ayrılmış, %60,5’i kullanılmış görünüyor; arada ayrılmış ama kullanılmamış 56 saat var ve masada “cihaz hep dolu” gerekçesiyle ikinci cihaz için satın alma talebi duruyor. Paylaşılan Excel ya da takvim “kim ayırdı” sorusunu cevaplar, “kullanıldı mı” sorusunu cevaplamaz. Kaynak planlama uygulaması, birden çok ekibin paylaştığı kaynakları (toplantı odası, eğitim salonu, test cihazı, kalibrasyon tezgâhı, havuz aracı, uzman teknisyen) çakışmasız ayırtan, tampon süreyi kendisi ekleyen, öncelikli işin hangi koşulda bir rezervasyonu bozabileceğini yazılı kurala bağlayan ve ayrılan saatle kullanılan saati ayrı kaydeden çok kullanıcılı bir web uygulamasıdır. Bunu şirketinize özel kuruyorum.

Sayfa 150–300 kişilik bir üreticinin ya da test laboratuvarının iç kaynakları içindir; tek kişilik bir işletmenin müşteri randevu defteri konusu değil. Kaynağın kendi bakım ve kalibrasyon vadesi periyodik bakım takip uygulamasının işi; burada yalnız vadesi geçmiş kaynağın ayrılamaması konuşuluyor.

Kaynak planlamada hangi kayıtlar birbirinden ayrı tutulur?

Rezervasyon, kullanım ve iç fatura üç ayrı kayıttır; biri ötekinin yerine sayılırsa kapasite raporu da maliyet dağılımı da yanlış çıkar. Sayfada geçen kavramlar:

• Tampon süre: rezervasyon bitince kaynağın sonraki kullanıma hazırlanması için ayrılan süre (oda toparlama, fikstür değişimi, araç kontrolü). Takvimde görünmez, kaynağı meşgul tutar.
• Check-in ve bırakma: kullanıcının “başladım” ve “bitirdim” kaydı. Kullanım bu ikisinin arasından ölçülür.
• Gelinmeyen rezervasyon: başlangıçtan sonra check-in yapılmamış rezervasyon. Bırakılmayan saat: iş erken bittiği hâlde kaynağın serbest bırakılmadığı saat.
• Kullanılabilir saat: kaynağın açık olduğu vardiya saatleri, bakım ve kalibrasyon engeli düşülerek. Örnekte tek vardiya, 08:00–18:00. Ekip değişimlerindeki tampon bu saatin içinde kalır (örnek ayda 13 saat), bu yüzden kullanım oranı %100’e ulaşamaz. Gözetimsiz gece testi yapılabilen bir cihazda gece ayrı bir dilim olarak tanımlanır ki gündüz oranı sulanmasın.
• Rezervasyon oranı: ayrılan saat ÷ kullanılabilir saat. Kullanım oranı: fiilen kullanılan saat ÷ kullanılabilir saat. Sayfada “kullanım oranı” yalnız bu anlamda geçer.
• Bozma: daha yüksek öncelikli bir talebin mevcut rezervasyonun yerini alması.
• İç fatura: kaynağın maliyetinin onu kullanan departmanlara dağıtılması; muhasebe faturası değil, maliyet muhasebesi raporu.

Örnek ay: cihaz “dolu” ama saatlerin yaklaşık yüzde kırkı boş

Örnek veri, kurgusaldır; sayıları bir betikle birbirine karşı sınadım. Yaklaşık 260 kişilik, elektrik pano bileşenleri üreten bir firma düşünün. Ortak kaynakları: iki toplantı odası (Oda A, Oda B), 40 kişilik eğitim salonu, bir titreşim test cihazı ve iki test teknisyeni, bir kalibrasyon tezgâhı, üç havuz aracı. Titreşim cihazını dört departman kullanıyor: Ar-Ge denemeleri, Kalite sevkiyat öncesi testleri, Satış müşterinin gelip izlediği tanık testleri, Üretim proses değişikliği sonrası doğrulama. Ay pazartesi başlıyor ve 22 iş günü sürüyor, günleri iş günü sırasıyla yazıyorum. Uygulama bu ay ilk kez kullanılıyor; check-in kaydediliyor, ama otomatik bırakma ve iç fatura kuralları henüz kapalı.

Kullanılan, gelinmeyen, bırakılmayan ve ayrılmamış satırları 220’ye tamamlanır; son iki satır ayrı bilgidir.

1. iş günü, geçiş. Excel’de tutulan, üç ayı kapsayan rezervasyon listesinden 146 satır aktarıldı; uygulama 3 çakışma buldu (ikisi aynı saate iki ekip, biri tamponun ihlali) ve üçü aktarım bitmeden çözüldü.

Diğer kaynaklar. 3 havuz aracının 52 rezervasyonundan 5’i 30 dakikadan fazla geç döndü; en uzunu 6. iş günü 1 saat 40 dakikaydı ve sıradaki satış temsilcisi taksiyle gitti. Toplantı odalarında 118 rezervasyonun 17’sinde (%14,4) check-in yoktu.

9. iş günü, taşma. Ar-Ge’nin 08:00–13:00 testi 15:00’te bitti. Kalite’nin 13:30–17:30 testi tamponla ancak 15:30’da başladı ve iki saat kaybetti; kalan iki saat 10. iş günü 08:00–10:00’a yeni rezervasyonla kondu, sevkiyat yarım gün kaydı.

12. iş günü, son boş aralık. 15. iş günü öğleden sonraki son boş dört saati Kalite ve Üretim aynı dakikada istedi. Uygulama kaydetme anında uygunluğu yeniden kontrol etti: önce kaydeden Üretim aldı, Kalite’ye sonraki boş aralık önerildi. Excel’de ikisi de satırını kaydeder, çakışma sonradan fark edilirdi.

14. iş günü, bozma. Bir müşteri 17. ve 18. iş günü tanık testine gelmek istedi; cihaz o iki gün Ar-Ge’deydi. Satış bozma talebi açtı, bildirim 3 iş günü önceydi, laboratuvar sorumlusu onayladı ve Ar-Ge sunulan üç alternatiften 21.–22. iş gününü seçti. Tanık testinin 20 saatinin 18’i kullanıldı: 18. iş günü denetçi 16:00’da ayrıldı, cihazı kimse bırakmadı.

Ay boyu, yer tutan rezervasyonlar. Ar-Ge’nin üç rezervasyonuna (10, 6 ve 4 saat) hiç gelinmedi; üçü de “numune gelirse” diye önceden tutulmuştu. Satış’ın iki numune ön testi (4’er saat) numune gelmediği için yapılmadı.

Ay sonu: ikinci cihaz neden bekliyor?

Kalite müdürünün ikinci cihaz talebinin tek dayanağı itilen 41 saatlik talepti. Fabrika müdürü önce bu talebin boşa geçen saatlere sığıp sığmayacağını sordu; betikle hafta hafta yerleştirdim.

• Ayrılmamış 31 saat talebi karşılamadı: 13 saati ekip değişimlerindeki tampondu, 12 saati itilen taleplerin hiçbirinin düşmediği geçiş haftasındaydı, kalan 6 saat ayın geri kalanına dağılmış 1–2 saatlik parçalardı. İtilen en kısa test 3 saatti.
• Yalnız check-in kuralı açık olsaydı: gelinmeyen rezervasyon 30 dakikada düşer, aynı gün hazır olan talep o saati alırdı. 9 talebin 5’i, 18 saat sığıyor; kullanım oranı %68,6’ya çıkıyor.
• Yer tutma da kalksaydı: Ar-Ge’nin “numune gelirse” rezervasyonları önceden ayrılabilir olurdu; 7 talep, 29 saat sığıyor, kullanım oranı %73,6. Sığmayan 12 saat kalıyor: 4 saatlik bir Kalite testi ve 8 saatlik bir tanık testi.

Kalan 12 saat ikinci cihaz için zayıf bir gerekçe; bu yüzden fabrika müdürü talebi iki ay bekletti ve dört kural koydu:

1. Başlangıçtan 30 dakika sonra check-in yoksa rezervasyon düşer, o güne bekleyen talep sahiplerine haber gider.
2. İç fatura ayrılan saate göre kurulur; istisnaları aşağıda.
3. Taşma, planlanan bitişte sıradaki kullanıcıya ve laboratuvar sorumlusuna bildirilir; tamponu aşan uzatma onlardan birinin onayını ister.
4. İkinci cihaz iki ay sonra şu ölçütle yeniden açılır: kurallardan sonra kullanım oranı %75’i ve itilen talep ayda 20 saati geçiyorsa. Eşikler başlangıç önerimdir.

Rezervasyon kuralları: çakışma, tampon, iptal, geç bırakma ve arıza

Kuralların hepsi örnek firma için başlangıç önerimdir; eşikler kaynağa, vardiyaya ve departmanlar arası anlaşmaya göre değişir ve ilk adımda yazılı onaylanır.

Öncelik kuralı: hangi iş hangi rezervasyonu bozabilir?

Mevcut bir rezervasyonu yalnız daha yüksek öncelik sınıfındaki bir talep bozabilir, bozma ayrı bir onaydan geçer ve bozulan ekip alternatifi ilk seçen olur. Önerdiğim sınıflar: (1) müşteriye bağlı iş: tanık testi, sevkiyat öncesi test; (2) üretim: hattı bekleten doğrulama; (3) geliştirme: Ar-Ge, eğitim, iç toplantı. Sınıfı talep eden değil, kaynak sorumlusu tanımlı listeye göre atar; sınıf 1 için talepte müşteri, sipariş ya da sevkiyat referansı zorunludur.

Bozma koşulları (başlangıç önerim): bildirim en az 3 iş günü önce, onaylayan kaynak sorumlusu; daha kısa bildirimde fabrika müdürü. Bozulan saat bozulan ekibe yazılmaz. Henüz ayrılmamış bir aralığı isteyen iki talep arasında sınıf farkı fark etmez, ilk kaydeden alır (12. iş günündeki gibi); bozma yalnız mevcut rezervasyon içindir.

Kullanım oranı neden rezervasyon oranından ayrı ölçülür?

İkinci cihaz, yeni salon ya da ek araç gibi yatırım kararları kullanım oranına bakılarak verilmelidir, çünkü rezervasyon oranı yer tutmayı da sayar. Örnek ayda biri %85,9, öteki %60,5’ti.

Aradaki 56 saat iki kaynaktan geliyor: gelinmeyen 34 saat check-in kuralıyla, bırakılmayan 22 saat bırakma bildirimi ve aşağıdaki iç fatura istisnasıyla azalır. Taşma kullanım oranını düşürmez, saati bir ekipten ötekine kaydırır.

Ar-Ge’nin 58 saatinin 2’si 9. iş günündeki taşma; Kalite’nin kaybettiği 2 saat bu yüzden iki sütunda da yer almaz (56 = 44 + 10 + 2).

Kullanım oranı check-in kayıtları kadar güvenilirdir. Önerim: kullanıcı kendi check-in’ini yapar; teknisyenin başkası adına girdiği kayıt işaretli durur ve geç check-in ile düzeltmeler aylık raporda sayılır. İkinci cihaz talebini açan Kalite müdürüyse ve check-in kayıtlarını Kalite’ye bağlı teknisyenler giriyorsa, karara dayanak olan kullanım raporunu üçüncü bir kişi (finans ya da fabrika müdürü) onaylar.

İç fatura: maliyet ayrılan saate mi, kullanılan saate mi yazılır?

Ayrılan saate göre yazılmasını öneririm, çünkü ayrılan saat başka bir ekibin o saati kullanamaması demektir. Saf ayrılan saat kuralı erken bırakmayı ödüllendirmez; bu yüzden dört istisna koyarım:

1. En az 1 iş günü önce iptal edilen saat ayırana yazılmaz.
2. Bozma yüzünden kaybedilen saat bozulana yazılmaz.
3. Erken bırakılan ya da gelinmeyip düşen saati başka bir departman kullandıysa o saat ayırana değil kullanana yazılır; kimse kullanmadıysa ayırana yazılır.
4. Taşmanın yediği saat taşırana yazılır.

Cihazın aylık maliyet havuzu (amortisman, bakım ve kalibrasyon, teknisyen payı) %100 kabul edilirse örnek ayın payları:

Bu ay kurallar kapalı olduğu için düşen saati kimse kullanmadı; istisnaların tek etkisi taşmanın 2 saatini Kalite’den Ar-Ge’ye taşımak. Kurallar açık olsaydı check-in kuralıyla sığan 18 saatin 11’i Ar-Ge’nin gelinmeyen rezervasyonlarına (8., 13. ve 19. iş günü: 4 + 4 + 3 saat) oturacak, bu saatleri kullanan departmanlara yazılacak ve Ar-Ge’nin payı %42,9’a inecekti. Gelinmeyen saatin başkasınca kullanılmasının karşılığı budur. Havuz ayrılan saatlere bölündüğü için ayrılmamış 31 saatin maliyeti de bu paylarla dağılır. Tutarı finans girer; uygulama yalnız payı hesaplar.

Roller: kim neyi görür, kim ayırır, kim onaylar?

Kimse kendi talebini onaylamaz.

• Kullanıcı: kendi rezervasyonunu açar, iptal eder, check-in ve bırakma yapar; başka ekiplerinkini “dolu” ve ekip adıyla görür, tanık testindeki müşteri adını görmez.
• Ekip lideri: ekibinin rezervasyonlarını ve kullanımını görür, ekibi adına bozma talebi açar.
• Kaynak sorumlusu (laboratuvar, idari işler, filo): kaynağı, tamponu, yetki listesini, bakım engelini tanımlar; öncelik sınıfını atar, ufku aşan rezervasyonu, bozmayı ve uzatmayı onaylar. Kendi departmanının talebi fabrika müdürüne gider.
• Test teknisyeni: atandığı testleri görür; check-in, bırakma ve not girer.
• Satış ve finans: Satış tanık testlerinin müşteri adını görür, bozma talebi açar ama onaylayamaz; finans iç faturayı görür, havuz tutarını girer, rezervasyon değiştiremez.
• Fabrika müdürü: her şeyi görür; kısa bildirimli bozmayı ve kural değişikliğini onaylar.
• Denetçi: her şeyi salt okur, iz kaydını dışa aktarır.

Kişilere iş dağıtmak bu sayfanın değil, ekip görev dağılımı takibinin konusu.

İz kaydı. Her rezervasyon, iptal, bozma, uzatma, check-in ve bırakma için kimin yaptığı, ne zaman yaptığı, eski ve yeni değer ve gerekçe silinemeyen bir satır olarak tutulur; kullanım oranı ve iç fatura bu satırlardan hesaplanır. Düzeltme yeni satırdır; geçen ayın kullanım oranı geriye dönük değişmez.

Yapay zekâ ne yapar, ne yapmaz?

Çakışmayı, tamponu, bozma ve iç fatura hesabını kurallar yapar, kararı insan verir. Yapay zekânın iki işi var, ikisi de öneridir:

1. Serbest talep metninden kaynak ve süre önerisi. “Yeni pano numunesi, üç eksende sinüs titreşim testi, salı başlasın” metninden cihazı ve teknisyeni, geçmişteki benzer testlerden süreyi ve ilk uygun aralığı önerir. “Perşembe 35 kişilik bayi eğitimi, projeksiyon gerekli” metninden eğitim salonunu ve 30 dakikalık hazırlığı önerir. Talep eden onaylar ya da değiştirir; model rezervasyonu kendisi kaydetmez.
2. Gelinmeyen rezervasyon örüntüsü. Gelinmeyen ve bırakılmayan rezervasyonların açıklamalarını (“numune gelmedi”, “müşteri iptal etti”, “test erken bitti”) sınıflandırıp kaynak sorumlusuna rapor olarak getirir: örnek ayda Ar-Ge’nin üç gelinmeyen rezervasyonunun üçü de “numune gelmedi” türündendi. Ufku kısaltmayı kaynak sorumlusu önerir, fabrika müdürü onaylar.

Model rezervasyon bozmaz, iptal etmez, öncelik sınıfı belirlemez, iç fatura yazmaz. Modele hiçbir satır kullanıcının yetki filtresinden geçmeden gitmez; cevap yalnız kullanıcının görebildiği ekip ve müşteri adlarını anar.

Rezervasyon kayıtlarında çalışan adları geçer; önerim, modele adın değil rolün gitmesi (“Ar-Ge kullanıcısı 3”). Kişisel veri kalıyorsa ve model yurt dışındaki bir sağlayıcıda çalışıyorsa bu aktarım 6698 sayılı KVKK md. 9 hükümlerine tabidir (7499 sayılı Kanun md. 34, RG 12.03.2024/32487, yürürlük 1 Haziran 2024; maddenin bu hâlini 15 Ekim 2026’da mevzuat.gov.tr’deki güncel metinden okudum). Hukuki görüş vermiyorum; modele hangi alanların gittiğini yazılı veririm.

Havuz araçlarının konumunu izlemek bu tasarımın parçası değil; aracın kullanımı teslim alma ve bırakma kaydından ölçülür.

Excel ya da paylaşılan takvim tam olarak nerede kırılır?

Excel çakışmayı tampon dahil formülle bulabilir ama engelleyemez; ortak takvim çakışmayı engeller ama tampon, öncelik ve maliyet alanı sunmaz; ikisi de kullanımı, bozmayı ve iç faturayı tutmaz.

Excel’de kalacaksanız önerdiğim sütunlar: A kaynak, B başlangıç (gerçek tarih-saat değeri), C bitiş, D tampon (dakika), E durum (iptalde “İptal”, etkin satırda boş; yazım farkı olmasın diye liste doğrulamasıyla seçtirin), F başlangıç dakikası, G tampon dahil bitiş dakikası, H çakışma sayısı.

• F2: =YUVARLA(B2*1440;0)
• G2: =YUVARLA(C2*1440;0)+D2
• H2: =EĞER(E2="İptal";0;ÇOKEĞERSAY($A$2:$A$500;A2;$F$2:$F$500;"<"&G2;$G$2:$G$500;">"&F2;$E$2:$E$500;"<>İptal")-1)

H 0’dan büyükse satır başka bir etkin rezervasyonla, iki tarafın tamponu dahil, üst üste biniyor. Liste 500 satırı aşarsa aralıkları genişletin. Dakikaları tam sayıya çevirmek, ondalık tarih-saat değerlerini tam tampon sınırında karşılaştırırken doğabilecek yuvarlama sapması riskini baştan kaldırır. Mantığı Python’da yedi satırla sınadım: Oda A’da 14:00–15:00 ve 15 dakika tamponla 15:00 başlangıcı çakışıyor, 15:15 çakışmıyor, iptal satırı sayılmıyor.

Kırıldığı yer formül değil:

• Formül işaretler, engellemez. İki kişi aynı anda aynı saate yazarsa iki satır da kaydedilir, H ikisini sonradan işaretler. Formülü veri doğrulamaya koysanız da Microsoft’un belgesine göre doğrulama yalnız hücreye doğrudan yazılan ya da “Değerler” seçeneğiyle yapıştırılan veride çalışır, düz yapıştırmada devreye girmez (Microsoft Learn).
• Kullanım görünmez. Kimin geldiği, işin ne zaman bittiği hiçbir hücrede yoktur.
• Çok kaynaklı rezervasyon iki ayrı satırdır; biri silinince öteki ortada kalır.
• Bozma iz bırakmaz; kimin onayladığı ve ne önerildiği kaybolur.

Ortak takvimde (Microsoft 365 ya da Google Workspace) oda ve ekipmanı kaynak hesabı olarak açmak Excel’den bir adım ileridir: çakışan davet kabul edilmez. Okuduğum dört belge kırılmanın nerede başladığını gösteriyor (hepsini 15 Ekim 2026’da okudum):

• Tekrarlayan seri. Exchange’in kaynak posta kutusunda çakışma sınırlarının varsayılanı 0’dır; bu yüzden varsayılanda çakışan örneği olan seri tümden reddedilir. Yönetici sınırı yükseltirse seri kabul edilir, çakışan örnekler reddedilir ve yanıt ayrıntıları ayarı varsayılan olarak açık olduğundan düzenleyene her reddedilen örnek için e-posta gider; belgeye göre bu e-posta ayarın açık olmasına bağlıdır, kapatılırsa gelmez (Set-CalendarProcessing). Google Workspace’te kaynak, çakışan örnek 8’i ve toplamın yarısını aşmıyorsa serinin tamamını kabul eder, uygun olmayan tarihleri reddeder ve her biri için bildirim gönderir (Google Workspace yönetici yardımı). “Her salı ayrıldı” sanılan serinin bazı salıları ayrılmamış olabilir.
• Tampon, öncelik ve maliyet alanı yok. Exchange’in Set-CalendarProcessing parametreleri arasında bunları görmedim; Google’ın kaynak takvimi sayfası da tampondan söz etmiyor.
• Check-in ve bırakma odaya göre kurulmuş. Microsoft’un otomatik bırakması check-in’i Teams paneli, Teams Rooms konsolu, Teams sohbeti ya da e-postayla alıyor, varsayılan süresi 10 dakika ve lisans koşulu var; Microsoft özelliği panel ya da Teams Rooms cihazı olan odalarla sınırlamayı öneriyor (Microsoft Learn). Google’ın oda bırakması katılımcılardan biri hariç herkes daveti reddedince çalışıyor ve 20 ve daha fazla kişilik odaları bırakmıyor (Google Workspace yönetici yardımı). Titreşim cihazı ya da havuz aracı için bu yollar hazır değil.

Web uygulamasında tanımlanan iş kuralı veri girilirken uygulanır: tampon, yetki listesi, bakım engeli ve öncelik rezervasyon kaydedilirken kontrol edilir.

Excel ya da takviminiz yetiyorsa bu uygulamaya gerek yok

Ayrı bir uygulamaya ihtiyacınız olup olmadığını aşağıdaki dört sayı gösterir ve onları ölçmek için uygulama gerekmez. Başlangıç önerim: iki hafta cihazın başına bir kâğıt asın; rezervasyon sahibi, gerçek başlangıç ve bitiş saati ve “dolu” denip geri çevrilen talep yazılsın, sonra rezervasyon listenizle karşılaştırın. Ayrı uygulama yaptırmayın, eğer:

1. Ortak kaynağınız yalnız toplantı odalarıysa ve takvim sisteminizde odalar kaynak hesabı olarak açıksa.
2. Bir cihazı iki üç kişi paylaşıp sırayı konuşarak ayarlıyorsa; yukarıdaki formüllü dosya yeter.
3. Ölçtüğünüz dört sayı düşükse. “Düşük” için başlangıç önerim: (a) çifte rezervasyon ayda en çok 1; (b) gelinmeyen saat kullanılabilir saatin %5’inden az; (c) taşma yüzünden geciken iş ayda en çok 1; (d) “dolu” denip itilen talep kullanılabilir saatin %5’inden az. Örnek firmada (a) uygulamadan önceki üç aylık Excel listesinde 3 çakışma, yani ayda 1’di; (b), (c) ve (d) örnek ayda %15,5, 1 ve %18,6’ydı. Dördünden ikisi eşiği aşıyor.
4. Departmanlara maliyet yansıtmıyorsanız ve tek soru bir yatırım kararıysa; iki haftalık kâğıt da bunu gösterebilir.

Özel uygulama; aynı kaynağı birden çok departman öncelik farkıyla kullanıyorsa, bir kaynak başka biriyle (cihaz ve teknisyen) birlikte ayrılıyorsa, kullanım bakım, kalibrasyon ya da yetkiye bağlıysa ya da bir yatırım kararı “dolu” görünen bir takvime dayanıyorsa fayda sağlar.

Nasıl başlanır, veri ve kod kimin?

İlk sürümü en çok tartışma çıkan tek kaynak grubuyla (örnekte titreşim cihazı ve teknisyenleri) kuruyorum; bütün oda, araç ve cihazları aynı anda taşımıyorum. Geçişte son üç ayın rezervasyon listesini aktarıp çakışmaları ilk hafta önünüze koyuyorum. İlk adımın çıktısı yazılıdır: kaynak listesi, tampon süreler, öncelik sınıfları, bozma, iptal ve iç fatura kuralları, rol listesi, ilk sürümün kapsamı ve takvimi.

Uygulama sizin adınıza açılabilen bir sunucuda (VPS) çalışır; veri sizindir ve tamamını istediğiniz zaman Excel ya da CSV olarak alırsınız, kaynak kodun tamamı erişiminizdeki bir depoda çalıştırma talimatı, bağımlılık listesi ve bilinen sınırlarla teslim edilir. Kullanıcı başına lisans yok; maliyet sunucunun aylık ücreti ve bakımdan oluşur ve küçük ve orta ölçekli bir ekipte kullanıcı eklemek bu maliyeti değiştirmez.

Herkes kendi kullanıcı adıyla tarayıcıdan girer; rezervasyon kayıtları çalışan adı taşıdığından erişim, güvenlik ve barındırma gereksinimlerini başlangıçta ayrıca değerlendiririm. Outlook ya da Google Takvim’le bağlantı istenirse hangi tarafın esas olacağını ve bağlantının nasıl kurulacağını, takvim sisteminizi ve BT politikanızı gördükten sonra ilk adımda yazılı belirleriz; bugün söz verdiğim bir bağlantı değil.

Kaç ortak kaynağınız olduğunu, hangi departmanların aynı kaynağı paylaştığını ve son üç ayın rezervasyon listesini (ad yerine departmanla) iletişim sayfasından paylaşın; ilk görüşmede listenizdeki rezervasyon oranının kullanım hakkında ne söyleyip ne söylemediğine birlikte bakarız.

Sıkça Sorulan Sorular

Kapasitesi birden fazla olan kaynak nasıl ayrılır?

40 kişilik eğitim salonu kişi sayısıyla ayrılır ve aynı saatteki rezervasyonların toplamı kapasiteyi aşamaz. Üç havuz aracı üç ayrı kaynaktır ki hangisinin geç döndüğü görülsün. Aynı anda iki numune alan bir test cihazının kapasitesi 2 tanımlanır, tampon her rezervasyonun arkasına yine eklenir.

Rezervasyon başka departman adına açılabilir mi?

Ekip lideri ya da kaynak sorumlusu başka bir departman adına rezervasyon açabilir; kayıtta açan kişi ve adına açılan departman ayrı alanlarda durur, iç fatura o departmana yazılır. Bu yetkinin kimde olacağını ilk adımda yazılı belirleriz.

Check-in unutulursa ya da yanlış basılırsa ne olur?

Önerdiğim akış şu, kapsamı ilk adımda yazılı belirleriz: düşmeden önce kullanıcıya hatırlatma gider; rezervasyon düştükten sonra kaynak hâlâ boşsa kullanıcı onu geri alabilir ve kayıt iz kaydına “geç check-in” diye düşer; yanlışlıkla yapılan bırakma, kaynağı başkası almadıysa geri açılır. Geç check-in ve düzeltme sayısı aylık raporda görünür; bu sayı yüksekse kullanım oranına o ay temkinli bakın.