ITSM'den ESM'ye: Bir Platformun Veri Mimarisi Kurumsal Hizmetlerin Ölçeklendirilmesinde Başarıyı Neden Belirler?
6 Haziran 2025
güncellendi: 25 Eylül 2025
ESM (Kurumsal Hizmet Yönetimi) yaklaşımını benimseyen - yani BT Hizmet Yönetimi (ITSM) uygulamalarını İK, Hukuk, İdari ve diğer departmanlara genişleten - şirketler genellikle geleneksel sistem mimarileriyle barikatlara çarpıyor. Bu eski kurulumlar dijital dönüşümü yavaşlatabilir ve BT departmanına daha fazla yük getirebilir. Ancak dinamik bir veri modeli, esnek kurumsal hizmet sistemleri oluşturmanın yeni yollarını açar. Bu makalede SimpleOne uzmanları, verileri düzenlemeye yönelik modern bir yaklaşımın değişiklikleri uygulamak için gereken süreyi nasıl kısaltabileceğini ve iş birimlerine nasıl daha fazla bağımsızlık kazandırabileceğini açıklıyor.
ESM Dönüşümü Neden Duraksıyor?
Bir BT departmanını bir hizmet organizasyonuna (ITSM) dönüştürmek zaten değerini göstermiştir - net süreçler, hizmet katalogları ve öngörülebilir sonuçlar, işin maksimum verimlilikle yapılmasına yardımcı olur. Ancak şirketler bu hizmet araçlarını (hizmet portalları, hizmet katalogları ve uçtan uca süreçlerin otomatikleştirilmesi gibi) şirketteki tüm hizmet departmanlarına ölçeklendirmeye çalıştığında (bu ESM yaklaşımıdır), kullandıkları sistemlerdeki temel sınırlamalar nedeniyle işler genellikle tıkanır.
ESM sistemlerinin esnekliği ile ilgili sorunlar çeşitli düzeylerde ortaya çıkmaktadır. Örneğin, sistemle çalışırken departmanlar genellikle kendi iş süreçleriyle hiçbir ilgisi olmayan alanları doldurmak zorunda kalırlar. Aynı zamanda, her departmanın ihtiyaçlarını karşılamak için talep formları oluşturmak pahalı kaynaklar gerektirir. Bu nedenle şirketler kendilerini BT'ye bağlı buluyor - çoğu kuruluşta, programcıları dahil etmeden basit bir hizmet talep formunu bile değiştiremezsiniz. Sonuç olarak, hizmetlerin iş ihtiyaçlarına uyarlanması yavaş gerçekleşiyor ve BT departmanı özelleştirme talepleriyle dolup taşıyor.
Sorunun kökeni veri mimarisinde yatmaktadır. Statik iş süreçleri döneminden miras kalan geleneksel bilgi depolama yöntemleri, günümüzün esneklik ve hizmetlerin uyarlanmasında hız taleplerini karşılamamaktadır. Bir talep formunu değiştirmek, BT departmanı kaynaklarına ihtiyaç duymadan bir iş kullanıcısı için basit bir iş olabilir.
Çözüm, dinamik veri modeli kavramıdır - veri yapısının ana veritabanı şemasını değiştirmeden değişebildiği veya genişleyebildiği bir yaklaşım. Bu, REM (Record Extended Model) teknolojisi kullanılarak hayata geçirilmiştir. Verileri düzenlemeye yönelik bu mimari yaklaşım, ana sisteme dokunmadan gerekli niteliklere sahip talep türlerini ayarlamanıza olanak tanır. İK departmanı kendi başına yeni bir işe alma talebi türü ekleyebildiğinde, hukuk departmanı bir sözleşme onay formu oluşturabildiğinde ve finans bir ödeme onay talebi yapabildiğinde, değişiklikleri uygulama hızı önemli ölçüde artar. Ve tüm bunlar veri bütünlüğünden ödün vermeden veya tüm sistem yapısını yeniden inşa etmeye gerek kalmadan gerçekleşir.
Bilgi sistemleri oluşturmanın geleneksel yolu, sabit bir düzene sahip bir bina tasarlamaya benzer. Yarın yeni bir odaya ihtiyacınız olursa, duvarları yıkmanız gerekir. REM teknolojisi, ESM sisteminizi büyük bir revizyona gerek kalmadan yeni ihtiyaçlara uyum sağlayabilen bir transformatöre dönüştürür. Bu, bir işletmenin değişiklikleri ne kadar hızlı uygulayabileceğini temelden değiştirir.
Peki, verileri düzenlemeye yönelik hangi yaklaşım, hizmet yaklaşımını tüm şirket departmanlarına başarılı bir şekilde ölçeklendirmenize olanak tanıyacak? Modern sistemlerin nasıl inşa edildiğine ve bir ESM platformu seçerken veri mimarisinin neden önemli bir faktör haline geldiğine bakalım.
ESM Sistemlerinde Verileri Yapılandırma Yaklaşımları
Bir ESM sistemi kurarken, bir şirket genellikle verileri organize etmek için üç ana yol arasından seçim yapar. Her birinin, sistemin ne kadar esnek olduğunu ve değişikliklerin ne kadar hızlı yapılabileceğini doğrudan etkileyen kendi özellikleri vardır.
- Geniş veri tabloları
Bu yaklaşımla, tüm talep türleri çok sayıda alana sahip büyük bir tabloda saklanır. Yeni istek türleri ortaya çıktıkça, tabloya yeni alanlar eklenir. Geniş tabloların iyi yönleri şunlardır: ilk başta kurulumu oldukça basittir, tüm verileri tek bir yerde tutabilirsiniz ve karmaşık JOIN sorgularına ihtiyacınız yoktur.
Ancak bu şekilde veri depolamanın sınırları vardır:
- Alan sayısı arttıkça performans düşer.
- Aşırı bilgi yüklemesi - sistem kullanıcıları çok sayıda gereksiz alan görür.
- Filtreleri ve veri görünümlerini ayarlarken yüksek hata olasılığı.
- Veritabanı yönetim sisteminin teknik sınırları (örneğin, PostgreSQL tablo başına en fazla 1600 sütuna izin verir).
- Sistem büyüdükçe yönetim daha karmaşık hale gelir.
2. Tablo Kalıtımı
Bu durumda, ortak alanlara sahip bir temel tablo oluşturulur ve farklı istek türleri için birçok "alt" tablo yapılır. Her bir alt tablo üst tablodaki alanları devralır ve kendi alanlarını ekler. Bu yaklaşım geniş tablolardan daha yapılandırılmıştır - her istek türü yalnızca ihtiyaç duyduğu alanlara sahiptir ve veriler mantıksal olarak ayrılmıştır.
Sınırlamalar şunlardır:
- Veri yapısını değiştirmek için bir kullanıcının sistemde yönetici haklarına ve hatta bazen veritabanı erişimine ihtiyacı vardır.
- Farklı tablolar için geçerli olan iş mantığını ayarlamak zordur.
- Birbiriyle ilişkili birkaç tabloda değişiklik yapmak çok zaman alır.
- Tablo sayısı arttıkça sistem daha az esnek hale gelir.
Bir örneğe bakalım: bir ekipman talebi için "Ekipman Türü", "Model" ve "Envanter Numarası" gibi alanlara sahip ayrı bir tablo oluşturulur. Bir erişim talebi için "Sistem", "Erişim Seviyesi" ve "Gerekçe" gibi alanların bulunduğu başka bir tablo vardır. Tüm talep türlerine bir "Son Tarih" alanı eklemeniz gerekiyorsa, her tabloyu ayrı ayrı değiştirmeniz gerekir.
3. Dinamik Veri Modeli ve REM Teknolojisi
REM yaklaşımı, ek özniteliklerin modeller ve öznitelik koleksiyonları aracılığıyla dinamik olarak bağlandığı standart alanlara sahip bir temel tablo kullanır. Yeni talep türleri eklediğinizde, veritabanı yapısını değiştirmeniz gerekmez. Departmanlar BT'nin yardımı olmadan kendi formlarını oluşturabilir, bu da değişikliklerden çok daha hızlı değer elde edeceğiniz anlamına gelir (değere dönüştürme süresi). Nitelikler modellere göre net bir şekilde ayrıldığından, hata riski daha azdır ve kullanıcılar bir sürü alakasız alan görmez - sadece kendileri için önemli olanları görürler.
Örneğin: muhasebe departmanı bağımsız olarak "Ödeme Ayrıntıları" öznitelik koleksiyonuna sahip bir "Ödeme Onayı" modeli oluşturur. İK departmanı "Pozisyon", "Gerekli Deneyim" ve "Beklenen Maaş" gibi özniteliklere sahip bir "İşe Alım" modeli kullanır. Her iki talep için de ayarları çoğaltmadan ortak bir "Son Tarihler" koleksiyonu kullanılabilir.
Dinamik bir model oluşturmak için REM'in temel ilkelerini anlamanız yeterlidir. Modeli oluştururken, gereksiz verilerden, yinelenen bilgilerden ve örtüşen özniteliklere sahip modeller arasındaki olası çatışmalardan kaçınmak için koleksiyonları ve öznitelikleri dikkatlice tasarlamanız gerekir.
REM Nedir ve Esnek ESM Sistemleri Oluşturmaya Nasıl Yardımcı Olur?
Kayıt Genişletilmiş Modeli (REM), ana yapıyı değiştirmeden dinamik olarak genişletmenize olanak tanıyan, verileri düzenlemeye yönelik mimari bir yaklaşımdır. REM, klasik EAV (Entity-Attribute-Value) yaklaşımına dayanmaktadır.
REM, kurumsal bilgi sistemlerinin temel bir sorununu çözer - veri yapısını aşırı karmaşık hale getirmeden farklı departmanların çeşitli ihtiyaçlarına esnek bir şekilde uyum sağlama ihtiyacı.
REM Mimarisinin Ana Bileşenleri
REM, toplu olarak sistemin esnekliğini ve ölçeklenebilirliğini sağlayan üç ana bileşenden oluşur:
- Model: Ana tablodaki kayıtlara bağlanacak bir dizi ek alanı tanımlar. Bir ESM sistemi için model, örneğin "Ekipman Talebi" veya "Tedarik Siparişi" olabilir.
- Öznitelikler: Belirli bilgileri depolayan bireysel alanlar. Bir ekipman talebi için bunlar "Cihaz Türü", "Ekipman Modeli" ve "Miktar" olabilir.
- Öznitelik Koleksiyonları: Farklı modellerde kullanılabilen mantıksal olarak gruplandırılmış alan kümeleri. Örneğin, bir "Teslimat" koleksiyonu "Teslimat Adresi" ve "Tercih Edilen Teslimat Tarihi" gibi öznitelikler içerebilir.
REM ESM Süreçlerini Nasıl Dönüştürüyor?
Geleneksel veri düzenleme yöntemiyle, her departman değiştirilmesi pahalı olan sabit bir form setine sahip olur. REM bu modeli değiştirir ve ESM sistemlerinde merkezi olmayan hizmet yapılandırmasına olanak tanır - bunu BT departmanının sorumluluğundan bireysel departmanlara taşır. Bu da değişiklikler için geliştirme ve uygulama döngüsünü kısaltır.
Ayrıca, REM tüm taleplerin tek bir tabloda saklanmasına olanak tanır. Gerekirse, talep kaydedildikten sonra talep modeli (nitelikler kümesi) orijinal talep numarası korunarak değiştirilebilir. Bu, başlangıçta yanlış modeli seçtiklerinde yeni talepler oluşturmak zorunda kalmayan son kullanıcı için hayatı kolaylaştırır.
REM'in en büyük avantajlarından biri de ince ayarlı erişim kontrolüdür. Bilgiler modellere göre net bir şekilde ayrıldığından, sistem hakların bireysel nitelikler ve koleksiyonlar düzeyinde esnek bir şekilde yönetilmesine olanak tanır. Örneğin, İK departmanı yalnızca kendi modellerine, finans departmanı ise kendi modellerine erişebilirken, ortak niteliklere farklı görüntüleme ve düzenleme haklarına sahip herkes erişebilir. Bu yaklaşım gizli bilgi sızıntısı riskini azaltır ve en az ayrıcalık ilkesini izler.
REM özellikle çeşitli departmanların birlikte çalışmasını gerektiren karmaşık hizmetler oluştururken kullanışlıdır. Örneğin, yeni çalışan işe alım süreci İK, BT, Yönetici ve Muhasebe adımlarını içerir. REM, verileri tüm zincir boyunca tutarlı tutarken her departmanın sürecin kendi bölümünü kurmasına olanak tanır.
REM teknolojisine sahip ESM platformları, daha yüksek performans, daha az geliştirme kaynağı ihtiyacı ve daha basit ölçeklenebilirlik nedeniyle diğer sistemlere göre daha avantajlıdır. REM, bir ESM platformunu önceden tanımlanmış süreçlere sahip katı bir sistemden kurumsal hizmetler için esnek bir yapıcıya dönüştürür ve bu da özellikle dijital dönüşümün ortasında değerlidir.
Yaklaşımların Adım Sayısına Göre Karşılaştırılması
Verilerin nasıl yapılandırılacağını seçmek, hizmet yaklaşımını BT departmanının ötesine ölçeklendirmede ne kadar başarılı olacağınızı belirleyecek stratejik bir karardır. Verileri yapılandırmaya yönelik üç yaklaşım arasındaki farkı görmek için, bir ESM sistemine yeni bir talep türü ekleme sürecini karşılaştıralım:
| Adım | Geniş Masa | Tablo Kalıtımı | REM |
|---|---|---|---|
| 1 | DB yapısını değiştirmek için yönetici hakları alın | Yeni bir tablo oluşturmak için yönetici haklarını alma | Yeni bir model oluşturun (iş kullanıcısı bunu yapabilir) |
| 2 | Ana tabloya yeni alanlar ekleyin | Kalıtım ile yeni bir "alt" tablo oluşturun | Öznitelikler ekleyin veya mevcut koleksiyonları bağlayın |
| 3 | Gereksiz alanları gizlemek için görünümleri ayarlama | Yeni tablo için görünümleri ayarlama | Talep formunu yapılandırma (yerleşik işlevsellik) |
| 4 | Mevcut tüm alanları dikkate alarak iş kuralları oluşturma | Yeni tablo için iş kuralları oluşturun ve/veya mevcut olanları geçersiz kılın | İş kurallarını belirli bir model bağlamında yapılandırma |
| 5 | Değişikliklerin tüm sistemi nasıl etkilediğini test edin | Yeni tabloyu ve entegrasyonları test edin | Modeli etkinleştirin |
KEP süreci, derin teknik bilgiye sahip olmayan iş kullanıcıları tarafından gerçekleştirilebilir, bu da değişim uygulama döngüsünü hızlandırır ve uzmanlar için maliyetleri azaltır.
REM yaklaşımının benimsenmesi tipik olarak ESM süreci uygulama süresini 3-4 kat kısaltır. Daha da önemlisi, iş kullanıcılarının birçok hizmeti kendi kendine yapılandırmasına olanak tanır ve bu da bir kuruluşta hizmet kültürünün nasıl geliştiğini derinden değiştirir.
İş Vakaları: İşletme Departmanları için KEP
Bir kuruluş hizmet yaklaşımını BT departmanının ötesine ölçeklendirdiğinde, farklı departmanlarda çeşitli süreçlerle karşılaşır. Her departmanın kendine özgü özellikleri, benzersiz veri türleri ve bunları işlemek için gereksinimleri vardır. Bilgiyi yapılandırmaya yönelik geleneksel yaklaşımlar, entegre edilmesi ve uyarlanması zor olan katı, izole sistemlere yol açar. REM teknolojisinin iş akışlarını nasıl dönüştürdüğünü ve etkileşim verimliliğini nasıl artırdığını görmek için belirli departmanlardan örneklere bakalım.
İK Otomasyonu
İK departmanı, her biri benzersiz bir dizi alan gerektiren çeşitli süreçlerle ilgilenir:
- Devamsızlık taleplerinde tarihler,devamsızlık türü (tatil, iş gezisi, hastalık izni) ve kimin karşılayacağı belirtilmelidir.
- Belge talepleri gerekli belgeleri, bunların alınma amacını ve teslim biçimini listeler.
- Yeni çalışan işe alımı, pozisyon verileri, maaş ve gerekli ekipman için alanlar içerir.
Tüm bu alanları tek bir tabloya koyarsanız, sistem hantal ve yönetimi zor bir hale gelir. REM, İK departmanının tüm talepleri tek bir tabloda tutmasını sağlarken, her talep türü yalnızca ihtiyaç duyduğu nitelikleri alır. Ayrıca, tablo yapısını değiştirmeden hızlı bir şekilde yeni talep türleri oluşturmalarına ve farklı roller için formlar ayarlamalarına olanak tanır - bir yönetici bir alan kümesini, bir çalışan başka bir alanı ve bir İK uzmanı üçüncü bir alanı görür.
Hukuk Departmanı Otomasyonu
Hukuk departmanı, farklı niteliklere ve onay yollarına ihtiyaç duyan birçok belge türüyle çalışır:
- Karşı taraflarla yapılan sözleşmeler karşı taraf, tutarlar, şartlar ve özel koşullar hakkında veri gerektirir.
- Hukuki görüşler, yasal riskler ve tavsiyeler de dahil olmak üzere farklı niteliklere sahiptir.
- Vekaletnameler şartlar, yetkiler ve temsilciler hakkında bilgi içerir.
REM'in hukuk departmanında kullanılması, türlerine bağlı olarak esnek belge onay rotaları oluşturulmasına ve farklı belge türleri için ortak öznitelik koleksiyonlarının ("Karşı Taraf" gibi) kullanılmasına olanak tanır.
KEP, yasalar değiştiğinde hızlı bir şekilde uyum sağlamayı mümkün kılar. Yeni düzenlemeler yürürlüğe girdiğinde, hukuk departmanının formları ve onay süreçlerini hızla değiştirmesi gerekir. REM mimarisine sahip bir sistemde avukatlar, BT departmanına sormadan gerekli alanları ekleyebilir (örneğin, "Veri Gizliliği Yasası X için Uyumluluk Kontrolü") ve onay rotasında yeni kontrol noktaları uygulayabilir. Bu, departmanın şirketin yasal güvenliğini bağımsız olarak sağlayabileceği ve sistemin mevcut yasal gereklilikleri karşılamamasıyla ilgili riskleri en aza indirebileceği anlamına gelir.
Finansal Süreçler
Finans departmanı, sıkı erişim kontrolü ve çeşitli işlemler için farklı formatlar gerektiren hassas verilerle çalışır:
- Ödeme talepleri ayrıntıları, tutarları, bütçe kalemlerini ve ödeme nedenlerini içerir.
- Bütçe onayları planlanan rakamları, gerçekleşenlerle karşılaştırmayı ve sapmalar için açıklamaları içerir.
- Gider raporları, kalemlere ayrılmışgiderler, ekli belgeler ve farklı para birimlerinin kullanılmasını gerektirir.
REM, finans departmanına model ve öznitelik düzeyinde son derece esnek erişim kontrolü sağlar. Örneğin, ödeme taleplerindeki tutarlar ve karşı taraflar hakkındaki bilgiler yalnızca CFO ve baş muhasebeci tarafından görülebilirken, genel talep durumu tüm süreç katılımcıları tarafından kullanılabilir. Bütçelerle çalışırken REM, departman yöneticilerinin yalnızca kendi gider kalemlerini görebileceği, üst yönetimin ise konsolide verileri görebileceği şekilde erişim ayarlamanıza olanak tanır.
Departman Entegrasyonu: Birleşik Mimari ile Uçtan Uca Süreçler
REM özellikle birden fazla departmanı kapsayan uçtan uca süreçlerde değerli hale gelir. Örneğin, yeni çalışan işe alım süreci İK, BT, İdari ve Muhasebe adımlarını içerir:
- İK çalışan profilini oluşturur ve süreci başlatır;
- BT hesapları ve ekipmanı hazırlar;
- Yönetici çalışma alanını düzenler;
- Muhasebe, maaş hesaplaması için parametreleri ayarlar.
KEP olmadan her departmanın kendi tablolarını ve süreçlerini oluşturması gerekirdi. Verilerin entegrasyonu ve takibi daha zor olacaktır çünkü ayrı sistemler arasında birçok veri alışverişi arayüzünün geliştirilmesi ve sürdürülmesi gerekecektir. Bu da teknik borç yaratır ve bilgi aktarımı sırasında hata riskini artırır. Ayrıca, KEP olmadan uçtan uca bir süreçteki herhangi bir değişiklik aynı anda birden fazla sistemi etkiler ve güncelleme koordinasyonunu karmaşık bir görev haline getirir. KEP yaklaşımı ile tüm departmanlar ortak bir veri yapısına sahip tek bir sistemde çalışır. Herkes yalnızca kendi işiyle ilgili nitelikleri görür ve bir departmanın gereksinimleri değiştiğinde tüm sistemin yeniden oluşturulması gerekmez.
Sonuç
Dinamik bir veri modeli ve KEP teknolojisi sadece teknik bir avantaj değil, aynı zamanda hizmet yaklaşımını tüm bir kuruluş genelinde ölçeklendirirken başarı için stratejik bir faktör haline geliyor. Departmanların birbirinden izole edildiği "silo kültürünün" üstesinden gelmeye yardımcı olurlar ve farklı departmanların ihtiyaç duydukları bağımsızlığa sahipken birlikte etkili bir şekilde çalışabilecekleri birleşik bir dijital ortam yaratırlar.
REM'i destekleyen bir ESM platformu seçen şirketler, ihtiyaçlarıyla birlikte büyüyen ve yeniden geliştirme için önemli bir yatırım yapmadan iş süreçlerindeki değişikliklere uyum sağlayan bir araca sahip olurlar. Bu, değişiklikleri uygulama hızının bir rekabet avantajı olduğu ve BT uzmanları üzerindeki iş yükünün kritik seviyelere ulaştığı günümüz dünyasında özellikle önemlidir. REM, yetenekli teknik uzmanların rutin özelleştirme görevlerinden kurtulmalarını ve potansiyellerini yüksek iş değeri olan projelere yönlendirmelerini sağlar.