Ekipman ve Erişim Takibi için Web Uygulaması Nasıl Kurulur

Sürüm 1 için Sorunu ve Kapsamı Tanımlayın

Bir veritabanı seçmeden veya ekranlar çizmeye başlamadan önce çözmekte olduğunuz problemi netleştirin. Çalışan ekipman takip uygulaması kolayca “her şeyi takip et” projesine dönüşebilir—bu yüzden Sürüm 1, kayıpları azaltan ve erişim hatalarını önleyen asgari unsurlara odaklanmalıdır.

Takip etmeniz gerekenleri (ve göz ardı edebileceklerinizi) kararlaştırın

Gerçek risk veya tekrarlayan iş yaratan öğeleri listeleyerek başlayın:

• Cihazlar: laptoplar, masaüstü bilgisayarlar, tabletler, telefonlar
• Çevre birimleri: monitörler, docklar, şarj cihazları, kulaklıklar
• Yazılım lisansları: oturma (seat) bazlı araçlar; atama geçmişi gerekir
• Fiziksel erişim: kartlar, anahtarlar, park izinleri

Her kategori için işletmek üzere ihtiyaç duyduğunuz minimum alanları not edin. Örnek: bir laptop için varlık etiketi, seri numarası, model, durum, mevcut atanan kişi ve konum gerekebilir. Bu, varlık yönetimi web uygulamanızı günlük kararlara dayandırır, “iyi olurdu” veriye değil.

Paydaşları ve karar vericileri belirleyin

Ekipman ve erişim hakkı yönetimi takımlar arasındadır; bu yüzden kimlerin değişiklik oluşturduğunu, onayladığını ve denetlediğini netleştirin:

• IT: cihaz envanteri, ekipman atama iş akışı, iade, onarım
• HR: başlangıç tarihleri, rol değişiklikleri, offboarding tetikleyicileri
• Tesisler: anahtarlar, odalar, oturma yerleri
• Güvenlik: kart düzenleme, erişim grupları, uyumluluk beklentileri
• Takım yöneticileri: iş gerekçesi, onaylar, istisnalar

Sadece gereksinim toplamıyorsunuz—bir şey kaybolduğunda veya erişim yanlış verildiğinde kimin hesap vereceğini de belirliyorsunuz.

Ölçülebilir başarı metrikleri tanımlayın

İlk günden takip edebileceğiniz birkaç metrik seçin, örneğin:

• Daha az “kayıp” varlık ve daha hızlı kurtarma
• Daha hızlı işe alım süresi (talep → atandı → hazır)
• Offboarding sırasında kaçırılan erişim iptallerinin azalması
• Daha net bir denetim izi ve uyumluluk kanıtı (kim neyi, ne zaman değiştirdi)

Sürüm 1 kapsamını kilitleyin (gerisini kenara bırakın)

İyi bir v1, çalışanlar için güvenilir envanter takibi, temel RBAC ve basit bir denetim izi sunar. İleri düzey özellikleri—barkod ve QR tarama, kapsamlı raporlar ve HRIS/IdP/ticketing entegrasyonları—çekirdek iş akışı çalışıp benimsendikten sonra sonraki sürümlere bırakın.

Verilerinizi Modelleyin: Çalışanlar, Ekipman ve Erişim Hakları

İyi bir veri modeli her şeyi kolaylaştırır: iş akışları, izinler, denetim geçmişi ve raporlama. İlk sürüm için varlık sayısını küçük tutun, ancak tanımlayıcılar ve durum alanları konusunda katı olun.

Çalışanlar: bir “gerçek kaynak” tanımlayıcı seçin

Hiçbir zaman yeniden kullanılmayacak benzersiz bir çalışan tanımlayıcısı seçin. Birçok ekip HR tarafından verilen employee_id veya kurumsal e-posta kullanır. E-posta kullanışlıdır ama değişebilir; HR ID daha güvenlidir.

Çalışan kayıtlarının nereden geldiğine karar verin:

• HR sistemi senkronu (uzun vadede en iyi): çalışanlar otomatik oluşturulur/güncellenir.
• Manuel giriş (başlamak için en hızlı): doğrulama kuralları ve bir “inactive/terminated” bayrağı ekleyin.

Atamalar için gereken temel bilgileri saklayın: isim, takım/bölüm, konum, yönetici ve istihdam durumu. Erişim/ekipman listelerini doğrudan çalışan kaydına gömmekten kaçının; bunları ilişki olarak modelleyin.

Ekipman: türleri normalize edin, aranacak özellikleri yakalayın

Ekipman öğeleri (bireysel varlıklar) ile ekipman türlerini (laptop, telefon, kart okuyucu) ayırın. Her öğe benzersiz bir varlık etiketi ve üretici tanımlayıcılarına sahip olmalıdır.

Başlangıç için yaygın özellikler:

• Seri numarası, model, satın alma tarihi, garanti bitiş tarihi
• Durum (ör. yeni/iyi/hasarlı) ve yaşam döngüsü durumu (stokta/atanmış/onarımda/emekli)
• Mevcut konum (ofis, depolama, uzaktan)

Erişim hakları: erişimi birinci sınıf varlık olarak ele alın

Erişim türlerini geniş tanımlayın: SaaS uygulamaları, paylaşılan klasörler, VPN, fiziksel kapılar, güvenlik grupları/roller. Pratik bir model Access Resource (ör. “GitHub Org”, “Finance Drive”, “HQ Door”) ve bir Access Grant—çalışanı bu kaynakla bağlayan ve durum (requested/approved/granted/revoked) gösteren ilişki—olabilir.

İş akışları: durum geçişlerini erken haritalayın

Ekranları inşa etmeden önce ana akışların veriyi nasıl değiştirdiğini haritalayın: assign, return, transfer, repair ve retire. Her akışı basit bir durum değişimi + zaman damgası ve “bunu kim yaptı” olarak ifade edebiliyorsanız, uygulamanız büyüdükçe tutarlı kalır.

Roller, İzinler ve Onay Kurallarını Belirleyin

Uygulamanız hem ekipmanı hem erişim haklarını takip ediyorsa, izinler “iyi olsaydı” değil—kontrol sisteminin parçasıdır. Ekranları, iş akışlarını ve denetim kurallarını buna göre inşa edebilmek için rolleri erken tanımlayın.

İş bazlı, net rollerle başlayın

Pratik bir Sürüm 1 seti genelde şunları içerir:

• Admin: yapılandırma yönetimi (konumlar, ekipman türleri, erişim sistemleri), kullanıcı hesapları ve acil durum geçersizlemeleri
• IT Technician: ekipman atama/iade, cihaz durumunu güncelleme (stokta, verildi, kayıp), erişim talepleri başlatma
• Manager: doğrudan raporları için erişim taleplerini onaylama ve offboarding adımlarını doğrulama
• Auditor: geçmişe, raporlara ve kanıtlara (kim neyi, ne zaman ve neden onayladı) okuma erişimi
• Read-only: hiçbir şeyi değiştirmeden kayıtları görüntüleme (helpdesk, güvenlik masası, HR ortağı)

Sayfa bazlı değil, eylem bazlı en az ayrıcalık uygulayın

“Her şeyi ya hiç” yaklaşımından kaçının. İzinleri riske eşleyen eylemlere bölün:

• Çalışan profili görüntüleme vs düzenleme
• Ekipman atama vs kayıp/emekli olarak işaretleme
• Erişim talep etme vs onaylama vs iptal etme
• Raporları dışa aktarma (genelde düşündüğünüzden daha hassastır)

Ayrıca alan düzeyinde kısıtlar düşünün: örneğin Auditor onay günlüklerini ve zaman damgalarını görebilir ama kişisel iletişim bilgilerini göremez.

Risk yüksekse onayları ekleyin

Ekipman atama IT içinde tek başına çözülebilir, ama ayrıcalıklı erişim tipik olarak onay gerektirir. Yaygın kurallar:

• Yükseltilmiş erişimler için yönetici onayı (admin panelleri, prod sistemleri, finans araçları)
• Geçici projeler için sona erme tarihli zaman sınırlı erişim
• Hassas talepler için gerekçe zorunluluğu (onay kaydıyla birlikte saklanır)

Görev ayrımını zorunlu kılın

Hassas işlemler için aynı kişinin oluşturup onaylamasını engelleyin:

• Talep eden kişi kendi talebini onaylayamaz.
• Erişimi provisioning yapan kişi tek onaylayıcı olamaz.

Bu, denetim izinin güvenilirliğini artırır ve “kaşe basma” riskini azaltır, günlük işleri yavaşlatmadan.

Çekirdek İş Akışlarını ve Kontrol Listelerini Tasarlayın

İş akışları, bir ekipman ve erişim takip uygulamasını gerçekten faydalı kılar. “Kimin neye sahip olduğu” bilgisini saklamaktan ziyade insanları tekrarlanabilir adımlarla, net sahiplik, son teslim tarihleri ve tek bir açık sonraki eylemle yönlendirmeye odaklanın.

Üç temel kontrol listesi ile başlayın

Ortak yaşam döngüsü anlarını kapsayan adım adım kontrol listeleri oluşturun:

• Onboarding: laptop ve çevre birimleri isteği, telefon atama (gerekirse), standart uygulamalar verilmesi, tamamlanmanın onayı ve imza alınması.
• Rol değişikliği: mevcut erişimi gözden geçirme, yeni role göre araç ekleme/çıkarma, isteğe bağlı ekipman değişimi ve onaylayıcının belgelendirilmesi.
• Offboarding: hesapları kilitleme/aktarma, ekipman iade planlama, teslim alma doğrulama, silme/reimage işlemleri ve vaka kapatma.

Her kontrol listesi öğesi: bir sahip (IT, yönetici, HR, çalışan), bir durum (Not started → In progress → Done → Blocked) ve bir kanıt alanı (yorum, ek, referans) içermelidir.

İstisnaları akışı bozmadan yönetin

Gerçek hayat nadiren ideal yol üzerindedir; her davadan tetiklenebilen “istisna eylemleri” ekleyin:

• Kayıp ekipman: son bilinen sahibi kaydedilir, kayıp olarak işaretlenir, yedekleme görevi oluşturulur ve olay detayları tutulur.
• Acil erişim: zorunlu gerekçe ile zaman sınırlı erişim verilir ve otomatik süresi dolma ayarlanır.
• Geçici ödünçler: iade tarihi, beklenen durum ve hafif bir check-in adımı ile ödünç başlatılır.

SLA'lar, hatırlatmalar ve periyodik incelemeler

Basit hizmet seviye beklentileri tanımlayın: işten ayrılmadan sonra ekipman X gün içinde iade edilmeli, bir ödünç 24 saat içinde onaylanmalı vb. Kontrol listesi öğelerine son tarihler ekleyin ve mevcut sahibi için hatırlatmalar gönderin.

Erişim hakları için, hassas sistemler için “her 90 günde erişimi gözden geçir” gibi tekrarlayan görevler planlayın. Çıktı açık bir karar olmalı: tut, kaldır veya yükselt.

Durumları ve “sonraki eylemi” belirgin tutun

Kullanıcıların ne yapacağını merak etmemesi için iş akışını tasarlayın. Her vaka şunu göstermelidir:

• mevcut durum (ör. “Çalışanın iadesi bekleniyor”)
• sonraki eylem (tek, uygulanabilir cümle)
• kimin sorumlu olduğu ve son tarih

Bu, uygulamanızı proje yönetimi aracına dönüştürmeden sürecin ilerlemesini sağlar.

Teknoloji Yığını ve Yüksek Seviyeli Mimarininizi Seçin

Bu uygulama kimlerin hangi ekipmana ve hangi sistemlere eriştiğine dair hassas verilerle uğraşır; bu yüzden “en iyi” teknoloji ekibinizin yıllarca güvenle işletmeyi bildiği yığındır—özellikle akşam 6'da acil bir offboarding güncellemesi gerektiğinde.

Ekibinizin destekleyebileceği bir yığın seçin

Organizasyonun yetenekleri ve mevcut ekosistemle uyumlu bir framework seçin. İç araçlar için yaygın, kanıtlanmış seçenekler şunlardır:

• Node.js + Express (veya NestJS): kuruluşunuz TypeScript kullanıyorsa ve esnek bir API istiyorsanız iyi bir seçim.
• Django: güçlü admin araçları, hızlı CRUD geliştirme ve olgun güvenlik varsayımları.
• Ruby on Rails: iş akışı ağırlıklı iç araçları hızlıca üretken şekilde inşa etmeye uygundur.
• Laravel (PHP): birçok şirkette geniş bir yetenek havuzu ve sağlam konvansiyonlar.

Hangi seçimi yaparsanız yapın, öncelik verin: iyi kimlik doğrulama kütüphaneleri, veritabanı değişiklikleri için migrationlar ve rol tabanlı erişim kontrolü (RBAC) uygulamanın net bir yolu.

İlk dahili sürümde daha hızlı ilerlemek isterseniz, bu tür bir sistemi prototiplemek (sonra sertleştirerek) için Koder.ai gibi bir platformu kullanabilirsiniz—sohbette iş akışlarını tarif ettiğinizde çalışan bir React UI ve Go + PostgreSQL backend üreten bir vibe-coding platformu. CRUD, RBAC ve onay akışlarını hızla iskeletlendirirken, kod tabanını dışa aktarma seçeneğini korur.

Dağıtım: VM, managed platform veya konteynerler

Dağıtım tercihiniz bakım maliyetlerini özelliklerden daha çok etkiler:

• Cloud VM (basit): işletim sistemi güncellemelerini, ölçeklemeyi ve yedekleri siz yönetirsiniz.
• Managed platform (en hızlı işletim): Heroku-benzeri platformlar veya bulut uygulama servisleri çoğu ops işini halleder.
• Konteynerler (Docker + Kubernetes/ECS) (en esnek): zaten konteyner altyapısı varsa tekrarlanabilir ortamlar için en iyisi.

Birçok ekip için managed platform, güvenilir bir varlık yönetimi web uygulaması için en hızlı yoldur.

Ortamlar için plan yapın (dev, staging, production)

İlk günden üç ortam kurun:

• Dev: günlük çalışma için (yerel + paylaşılan dev)
• Staging: onay akışları ve entegrasyonları test etmek için production'a benzeyen bir alan
• Production: daha sıkı erişim, yedeklemeler ve izleme ile kilitli

Konfigürasyonu ortam değişkenlerinde (veritabanı URL'leri, SSO ayarları, depolama bucket'ları) tutun, kod içinde değil.

Basit bir mimari diyagramı çizin

Herkesin aynı zihinsel modeli paylaşması için basit bir diyagram dokümante edin:

• UI: panolar ve arama için web frontend (server-rendered veya SPA)
• API: atamalar, iadeler ve erişim hakları değişiklikleri için iş mantığı
• Database: çalışanlar, ekipman, erişim grantleri için ilişkisel veritabanı (genelde Postgres)
• Dosya depolama: makbuzlar, fotoğraflar, imzalı formlar için opsiyonel

Bu küçük “harita” kazara karmaşıklıkları önler ve iç araçlar için web uygulama mimarisinin büyürken anlaşılmasını kolaylaştırır.

UI Tasarımı: Panolar, Arama ve Detay Sayfaları

Bir takip uygulaması, insanların basit sorulara ne kadar hızlı cevap alabildiğine bağlıdır: “Bu laptop kimde?”, “Neler eksik?”, “Hangi erişimler bugün kaldırılmalı?” UI'yi bu günlük anlara göre tasarlayın, veritabanı tablolarına göre değil.

Dört ana ekranla başlayın

Her biri net bir amaç ve tahmin edilebilir düzeni olan sayfalar oluşturun:

• Çalışan profili: atanan ekipmanı, aktif erişimleri, açık talepleri ve son değişikliklerin küçük bir zaman çizelgesini görebileceğiniz tek bir yer.
• Ekipman listesi: durum (atanmış/uygun/emekli), konum ve son görüldüğü/güncellendiği tarih ile envanter tablosu.
• Erişim listesi: sistemler ve gruplar (ör. GitHub org, VPN, bordro) ile kimde ne var, artı süre sonu/gözden geçirme tarihleri.
• Talepler kuyruğu: dikkat gerektiren onaylar ve eylemler (yeni işe alım kurulumu, transfer, offboarding), aciliyete göre sıralı.

Arama ve filtreleri birinci sınıf yapın

Üst navigasyona global bir arama kutusu koyun ve toleranslı yapın: isimler, e-postalar, seri numaraları, varlık etiketleri ve kullanıcı adları çalışmalı.

Liste sayfalarında filtreleri çekirdek işlevsellik olarak ele alın. Fayda sağlayan yaygın filtreler:

• Kişi, bölüm, yönetici
• Seri numarası / varlık etiketi
• Durum (atanmış, iade bekliyor, kayıp, iptal edildi)
• Tarih aralıkları (atanma tarihi, son denetim, offboarding tarihi)

Filtre durumunu URL'de tutun, böylece kullanıcılar bir görünümü takım arkadaşlarıyla paylaşabilir (ve daha sonra kolayca dönebilir).

Formları hataları önleyecek şekilde tasarlayın

Hataların çoğu veri girişinde olur. Bölümler için açılır menüler, çalışanlar için typeahead, denetimler için zorunlu alanlar kullanın (seri numarası, atama tarihi, onaylayıcı gibi denetim esnasında gerektiği durumlar).

Anında doğrulama yapın: seri numarası zaten atanmışsa uyarı verin, bir erişim hakkı politika ile çakışıyorsa bildirin veya iade tarihi gelecekteyse uyarın.

Hızlı eylemleri (hunt olmadan) destekleyin

Çalışan ve ekipman detay sayfalarında, kat üstünde birkaç birincil eylem yerleştirin:

• Assign ekipman
• Return ekipman
• Revoke access
• Generate receipt (teslim/iadeye yönelik PDF veya yazdırılabilir sayfa)

Bir eylem sonrası net bir onay gösterin ve güncellenmiş durumu hemen sunun. Kullanıcılar gördüklerine güvenmezlerse tekrar spreadsheet oluşturmaya başlarlar.

Veritabanı Şeması ve Denetim Geçmişini Oluşturun

Temiz bir veritabanı şeması, ekipman ve erişim takip uygulamasını güvenilir kılan şeydir. İç araçların çoğu için ilişkisel veritabanı (PostgreSQL veya MySQL) en uygun tercihtir çünkü güçlü tutarlılık, kısıtlar ve kolay raporlama gerekir.

“Güncel durum” tabloları ile başlayın

Her gün sorgulayacağınız varlıkları modelleyin:

• employees: id, name, email, status (active/offboarding/terminated), department
• equipment: id, asset_tag, serial_number, type, model, status (in_stock/assigned/retired)
• access_resources: id, system_name, resource_name, owner_team

Sonra güncel atamayı temsil eden ilişki tabloları ekleyin:

• equipment_assignments: id, employee_id, equipment_id, assigned_at, expected_return_at, returned_at (nullable)
• access_grants: id, employee_id, access_resource_id, granted_at, revoked_at (nullable)

Bu yapı “Alex’in şu an neye sahip olduğu?” sorusuna yıllarca geçmişi taramadan kolayca cevap verir.

Tarihçe ve onayları birinci sınıf veri olarak planlayın

Denetim ihtiyaçları genelde tarihçe sonradan eklendiğinde başarısız olur. Zaman içinde olayları kaydeden tablolar oluşturun:

• assignment_events (veya her atama satırını immutable tutup sonlandırma zamanlarını işaretleyin)
• access_grant_events (requested/granted/revoked/expired)
• approvals: request_id, approver_id, decision, decided_at, reason

Pratik bir desen: her durum değişikliği için bir satır; üzerine yazmayın—sadece ekleyin.

Kötü veriyi engelleyen kısıtlar ekleyin

Veritabanı kurallarıyla dağınık kayıtları durdurun:

• serial_number ve asset_tag üzerinde benzersiz kısıtlar
• Geçerli employee_id ve equipment_id gerektiren yabancı anahtarlar
• returned_at >= assigned_at gibi check kısıtları
• Bir öğeyi çift atamayı engelleyen kısmi benzersizlik (ör. yalnızca bir “açık” atama)

Saklama kurallarını erken belirleyin

Bir kişi veya varlık “silindiğinde” ne olacağını tanımlayın. Uyum ve soruşturmalar için soft delete (deleted_at) tercih edin ve denetim tablolarını append-only tutun. Her kayıt tipi için saklama politikası belirleyin (örneğin erişim ve onay geçmişini 1–7 yıl saklamak) ve bunu Legal/HR ile dokümante ettirin.

API Katmanını ve İş Mantığını Uygulayın

API'niz, kimin neye atandığı, kim onayladığı ve ne zaman olduğuna dair “tek gerçek kaynağı” olmalıdır. Temiz bir API katmanı, UI'ye sızan karmaşık kenar durumları önler ve ileride tarayıcılar veya HR sistemleri gibi entegrasyonları kolaylaştırır.

Kaynakları ve uç noktaları tanımlayın (REST veya GraphQL)

Önce ana isimleri ve eylemleri modelleyin: employees, equipment, access rights ve iş akışları (assignment, return, offboarding).

REST yaklaşımları şöyle görünebilir:

• GET /api/employees, GET /api/employees/{id}
• GET /api/equipment, POST /api/equipment, PATCH /api/equipment/{id}
• POST /api/assignments (ekipman atama)
• POST /api/returns (ekipman iadesi)
• GET /api/access-rights ve POST /api/access-grants
• GET /api/workflows/{id} ve POST /api/workflows/{id}/steps/{stepId}/complete

GraphQL de kullanılabilir, ancak iç araçlarda REST genellikle daha hızlı uygulanır ve önbellekleme/pagination yönetimini basit tutar.

Her yazmada doğrulama koyun

UI zaten girişleri kontrol etmiş olsa bile, her create/update sunucu tarafında doğrulanmalı. Örnekler:

• Bir ekipman zaten atanmışsa yeni atama yapılamaz (transfer destekleniyorsa açıkça izin verin).
• Offboarding iş akışı eksik adımlar varken “tamamlandı” olarak işaretlenemez.
• Erişim grantleri izin verilen sistemlerle ve geçerli sona erme kurallarıyla uyumlu olmalıdır.

Doğrulama hataları tutarlı ve insan tarafından okunabilir olmalı.

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Equipment is already assigned to another employee.",
    "fields": { "equipmentId": "currently_assigned" }
  }
}

(Bu kod bloğu aynen korunmuştur.)

Kritik eylemleri idempotent yapın

Atama/iade eylemleri mobil tarama, yeniden denemeler veya çift tıklama gibi nedenlerle tekrar tetiklenebilir. Tekrarlayan isteklerin çoğaltma yapmaması için bir idempotency anahtarı (veya deterministik bir istek ID'si) ekleyin.

Sayfalama, sıralama ve öngörülebilir hatalar sağlayın

Liste uç noktalarında ilk günden sayfalama ve sıralama olsun (örneğin: ?limit=50&cursor=...&sort=assignedAt:desc). Hata kodlarını sabit tutun (401, 403, 404, 409, 422) ki UI doğru tepki verebilsin—özellikle “zaten iade edilmiş” veya “onay gerekli” gibi çakışma durumları için.