Çalışan ekipmanlarını ve erişim haklarını izleyen bir web uygulamasını planlamayı, tasarlamayı ve inşa etmeyi öğrenin; işe alım, transfer ve offboarding için net iş akışlarıyla.
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.
Gerçek risk veya tekrarlayan iş yaratan öğeleri listeleyerek başlayın:
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.
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:
Sadece gereksinim toplamıyorsunuz—bir şey kaybolduğunda veya erişim yanlış verildiğinde kimin hesap vereceğini de belirliyorsunuz.
İlk günden takip edebileceğiniz birkaç metrik seçin, örneğin:
İ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.
İ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.
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:
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 öğ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:
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.
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.
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.
Pratik bir Sürüm 1 seti genelde şunları içerir:
“Her şeyi ya hiç” yaklaşımından kaçının. İzinleri riske eşleyen eylemlere bölün:
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.
Ekipman atama IT içinde tek başına çözülebilir, ama ayrıcalıklı erişim tipik olarak onay gerektirir. Yaygın kurallar:
Hassas işlemler için aynı kişinin oluşturup onaylamasını engelleyin:
Bu, denetim izinin güvenilirliğini artırır ve “kaşe basma” riskini azaltır, günlük işleri yavaşlatmadan.
İş 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.
Ortak yaşam döngüsü anlarını kapsayan adım adım kontrol listeleri oluşturun:
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.
Gerçek hayat nadiren ideal yol üzerindedir; her davadan tetiklenebilen “istisna eylemleri” ekleyin:
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.
Kullanıcıların ne yapacağını merak etmemesi için iş akışını tasarlayın. Her vaka şunu göstermelidir:
Bu, uygulamanızı proje yönetimi aracına dönüştürmeden sürecin ilerlemesini sağlar.
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.
Organizasyonun yetenekleri ve mevcut ekosistemle uyumlu bir framework seçin. İç araçlar için yaygın, kanıtlanmış seçenekler şunlardır:
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 tercihiniz bakım maliyetlerini özelliklerden daha çok etkiler:
Birçok ekip için managed platform, güvenilir bir varlık yönetimi web uygulaması için en hızlı yoldur.
İlk günden üç ortam kurun:
Konfigürasyonu ortam değişkenlerinde (veritabanı URL'leri, SSO ayarları, depolama bucket'ları) tutun, kod içinde değil.
Herkesin aynı zihinsel modeli paylaşması için basit bir diyagram dokümante edin:
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.
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.
Her biri net bir amaç ve tahmin edilebilir düzeni olan sayfalar oluşturun:
Ü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:
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).
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.
Çalışan ve ekipman detay sayfalarında, kat üstünde birkaç birincil eylem yerleştirin:
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.
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.
Her gün sorgulayacağınız varlıkları modelleyin:
Sonra güncel atamayı temsil eden ilişki tabloları ekleyin:
Bu yapı “Alex’in şu an neye sahip olduğu?” sorusuna yıllarca geçmişi taramadan kolayca cevap verir.
Denetim ihtiyaçları genelde tarihçe sonradan eklendiğinde başarısız olur. Zaman içinde olayları kaydeden tablolar oluşturun:
Pratik bir desen: her durum değişikliği için bir satır; üzerine yazmayın—sadece ekleyin.
Veritabanı kurallarıyla dağınık kayıtları durdurun:
returned_at >= assigned_at gibi check kısıtları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'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.
Ö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-grantsGET /api/workflows/{id} ve POST /api/workflows/{id}/steps/{stepId}/completeGraphQL de kullanılabilir, ancak iç araçlarda REST genellikle daha hızlı uygulanır ve önbellekleme/pagination yönetimini basit tutar.
UI zaten girişleri kontrol etmiş olsa bile, her create/update sunucu tarafında doğrulanmalı. Örnekler:
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.)
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.
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.
V1 için “tamamlandı”nın ne olduğunu tanımlayın: yüksek riskli varlıkların ve erişimlerin güvenilir takibi, temel onaylar ve bir denetim izi.
Pratik bir v1 genellikle şunları içerir:
QR tarama, derin raporlama, HRIS/IdP/ticketing entegrasyonları gibi ekstraları çekirdek iş akışı benimsendikten sonra erteleyin.
Sahip olduğunuz her şeyi değil, kayıp riski veya erişim hatası yaratanları takip edin.
İyi bir v1 kategorileri:
Her kategori için günlük işlemler için gereken minimum alanları yakalayın (ör. seri numarası, varlık etiketi, durum, atanan kişi, konum).
Tekrar kullanılmayacak benzersiz bir tanımlayıcı kullanın. HR tarafından verilen bir employee_id genellikle e-postadan daha güvenlidir çünkü e-postalar değişebilir.
Manuel girişle başlarsanız ekleyin:
Erişimi bir checkbox yerine veri olarak modelleyin.
Pratik yapı:
Bu, onayları, sonlandırmaları ve denetimleri özel durum mantığı olmadan kolaylaştırır.
İş bazlı rollerle başlayın, sonra izinleri eyleme göre ayırın (en az ayrıcalık).
Yaygın v1 rolleri:
Yaygın eylem izinleri:
Tutarlı bir şekilde sorgulayacağınız varlıklar için ilişkisel bir veritabanı (genelde PostgreSQL) ve eklenebilir tarihçe kullanın.
Tipik “güncel durum” tabloları:
Denetim günlükleri daha sonra eklendiğinde başarısız olur—onları birinci sınıf veri olarak ele alın.
En azından loglayın:
Her olay şunu içermeli: yapan kişi, ne değişti (önce → sonra), zaman ve mümkünse gerekçe. Append-only kayıtları ve soft delete tercih edin.
Yazma işlemlerine doğrulama ve çakışma yönetimi koyun, böylece UI tutarsız kayıtlar yaratan hatalar oluşturamaz.
Ana uygulamalar:
Eğer bir IdP (Okta/Azure AD/Google Workspace) varsa SSO genelde ilk tercihtir çünkü offboarding tek bir kontrol noktasıyla yapılabilir.
SSO yoksa, e-posta/şifre + MFA (TOTP veya WebAuthn) kullanın ve şunları ekleyin:
HttpOnly, Secure, SameSite)Çekirdek akışınız kararlı olduktan sonra tarama ekstra iş yükünü azaltır; bu bir “güçlendirme”, önkoşul değil.
Tarama başarılı olsun diye:
Entegrasyonlar (HRIS/IdP/ticketing) için önce salt-okuma ile başlayın ve her alan için gerçek kaynağı tanımlayın.
Tüm izinleri sunucu tarafında zorlayın, sadece UI butonlarını gizlemekle yetinmeyin.
employees, equipment, access_resourcesequipment_assignments (nullable returned_at ile)access_grants (nullable revoked_at ile)Kötü veriyi önleyecek kısıtlar ekleyin:
asset_tag ve serial_numberreturned_at >= assigned_at gibi kontrollerHangi kimlik doğrulama yöntemi olursa olsun, RBAC veritabanında tutulmalı ve sunucu tarafında zorlanmalıdır.