<h3 class="mt-4">SAP Karlılık Analizi ve Performans Yönetimi</h3>

		
			
				Günümüzde şirketlerin veri hacminin artması, verilerin birçok farklı sistemde tutulması, performansı yüksek, hızlı işlem 
				yapabilecekleri ürünleri tercih etmesine sebep oluyor. SAP’nin PaPM(eski adıyla SAP FS-PER) ürünü, HANA üzerinde çalışarak
				büyük hacimli verilerle işlem yapabiliyor ve karlılık analizi ya da karmaşık hesaplamalı modellerin oluşturulmasına olanak 
				sağlıyor.
			
		

		
			Karlılık analizi, finansman, planlama ve simülasyon, tedarik zinciri süreçlerinde kullanılan PaPM’i genel olarak birçok farklı 
			sistemden veri aktarabilen ve bu verileri hesaplamalarda kullanabilen yüksek performanslı bir ürün olarak tanılmayabiliriz. 
			PaPM, ürün-müşteri-.. bazında karlılık raporlaması, KPI belirleme, yönetme, plan/gerçekleşen karşılaştırmaları ve varyans analizleri, 
			tedarik zinciri sürecinde karar önerici hesaplamalar kurgulama gibi birçok alanda kullanılabilmektedir. Genel olarak karlılık analiz 
			süreçleriyle öne çıktığı için SAP ERP COPA yerine konumlandırıldığı düşünülse de PaPM diğer operasyonlarda da kullanılmaktadır.
		

		SAP PaPM ürünü S4HANA, BW4HANA ya da BWonHANA sistemleri üzerine kurulabiliyor.

		<h5 class="mt-4">Veri Aktarımları</h5>
		
			PaPM ürün bağımsız tüm veri tabanlarına Smart Data Access(SDA) teknolojisi ile bağlanıp ilgili sistemlerden veri toplayabiliyor. 
			PaPM, okunan verileri herhangi bir yere yazmadan(on the fly) raporlayabiliyor, manipüle edebiliyor ve hesaplamalarda kullanabiliyor. 
			Sap ve Non-Sap sistemlerden veri toplamasına ek olarak, MS Excel, CSV gibi formatlar ile beslenebiliyor ve oluşturalacak ekranlar 
			ile veri girişlerine imkan sağlıyor. Veri girişi imkanı, ERP sistemlerinde atılan düzeltme kayıtlarına olan ihtiyacı kaldırırken, 
			dönem kapanışlarını beklemeden hesaplamalar çalıştırılmasını ve raporlamalar yapılmasını sağlıyor. Kapanmış dönemlere düzeltme 
			kaydı atma ve year-to-date hesaplamaları sene başından itibaren düzelterek ilerletme yeteneği ile gerçek karlılık ve maliyet 
			verilerini raporlama imkanı sunuyor.
		

		<h5 class="mt-4">Karlılık Dağıtımı ve Analizleri</h5>
		
			Karlılık dağıtımları fonksiyonları SAP ERP COPA dağıtım işlevleriyle benzeşiyor fakat PaPM’deki dağıtımların daha esnek 
			olduğunu söyleyebiliriz. Birçok farklı dağıtım şekli(doğrudan, dolaylı, top-down vb) PaPM’in standart fonksiyonlarıyla 
			oluşturulabiliyor. SAP’nin HANA ile birlikte karlılık analiz yaklaşımında hesapsal(Account-based) yapının ön plana çıkmasıyla 
			beraber dolaylı dağıtımlar önem kazanmıştır. PaPM’deki dolaylı dağıtımlarda ERP PA yapısındaki tüm karakteristiklerie dağıtılan 
			verilerin hangi hesaptan geldiği rahatlıkla takip edilebilmektedir.
		

		
			ERP COPA’da dağıtım yapısı tek defterde ve tek dağıtım anahtarına uygun tasarlanmıştır. Bu yapıya bir alternatif olarak PaPM’deki 
			tüm dağıtımlar birden fazla defterde, birçok farklı dağıtım anahtarına göre yapılabilmekte, hesaplamalar sonucu defter bazlı solo 
			ve konsolide karlılık raporlaması yapılabilmektedir.
			Büyük hacimli veriye sahip şirketlerde ERP COPA’daki dağıtım devrelerinin çalışmasının tamamlanması günler sürebilmektedir. PaPM, 
			yüksek hacimli verilerle çalışmak için tasarlanan, verilerin yazılmadan çalışma prensipli yapısıyla bu süreyi oldukça kısaltmaktadır.
		

		
			Dağıtım devrelerine yeni bir karakteristik eklenmesi, devrelerde herhangi bir değişiklik yapılması son kullanıcı tarafından 
			kolaylıkla yapılabilir. Ek olarak dağıtım devrelerinde taslak bir yapı belirlenip bu taslağa uygun Excel’de hazırlanan dağıtım
			devrelerinin sisteme aktarılması, sistemden dağıtım devrelerinin Excel’le dışarı aktarılabilmesi fazla sayıda dağıtım devresi
			bulunan şirketler için kolaylık sağlamaktadır. Dağıtım kurallarına göre dağıtılamayan veriler için ek kurallar tanınlanabilmektedir.
		

		
			Karlılık dağıtımları çalıştırıldığında herhangi bir yere muhasebesel bir kayıt atılmaması, dolayısıyla yeniden çalıştırıldığında ters 
			kayıt almak zorunda kalınmaması, istenildiği kadar tekrar çalıştırılabilmesi ERP COPA ile karşılaştığında en büyük avantajı olarak 
			öne çıkıyor.
		

		<img src="https://i.ibb.co/88B8rrx/Image-1x-1400x482.jpg" width="100%" />

		<h5 class="mt-4">Hesaplamalar</h5>

		
			PaPM’deki tüm hesaplamalar uygulama katmanı yerine veritabanında yürütülür, bu sebeple çalışma performansı oldukça yüksektir. 
			Veri zenginleştirme ve türetme gibi birçok standart fonksiyonun SQL komutlarıyla çalışmasının yanında R dilindeki fonksiyonlar, 
			Stored Procedure, ABAP programları, SAP BPC fonksiyonları ve web servisleriyle de çalışabilmektedir. Ek olarak ileri analitik 
			kütüphanesi sayesinde 2020 yılındaki versiyonuyla(SP08) sınıflandırma(classification), kümleme(clustering) ve makina öğrenmesi 
			(Machine Learning) algoritmalarıyla istatistiksel tahmin modelleri oluşturulabilecek.
			Hesaplamalar sonucunda oluşan veriler SAP ERP veya BW’da istenilen tabloya yazdırılabilmektedir.
		

		<h5 class="mt-4">Raporlamalar</h5>
		
			PaPM’in raporlama ara yüzü SAP Analysis olup, aktarılan veriler, hesaplama sonuçları, fonksiyon önizlemeleri ad-hoc olarak 
			görüntülenebiliyor. SAP BW sistemindeki tüm raporların açılmasının yanı sıra doğrudan PaPM içinde de sorgular oluşturulup 
			raporlar yapılabiliyor. Sorguların Analysis ile açılabilmesine ek olarak aşağıdaki şekilde diyagram ve çeşitli görsellerle de 
			fiori ara yüzünde görüntülenebilir.
		

		<img src="https://i.ibb.co/PzyyBd3/2.jpg" width="100%" />

		<img src="https://i.ibb.co/vhDJcRH/3.jpg" width="100%" /> 

		<h5 class="mt-4">Kullanıcı Ara Yüzü</h5>
		
			SAP HANA’yla birlikte Fiori uygulamalarının zenginleştirilmesiyle birlikte, PaPM’de de Fiori ve Analysis for Excel ile 
			kullanıcılara esnek ve dinamik raporlama imkanı sunuyor. Projedeki genel yapının danışmanlar tarafından oluşturulmasından 
			sonra iş birimlerinin sahiplenebileceği bir uygulama olması sayesinde fonksiyonlardaki bakımlar, yeni raporların oluşturulması 
			kullanıcılar tarafından kolaylıkla yapılabiliyor.
		

		<h5 class="mt-4">Simülasyon</h5>
		
			PaPM’deki tüm hesaplamalar birçok kez çalıştırılabilinip birçok farklı şekilde simülasyon yapılabilmektedir. PaPM’in genel çalışma 
			prensibi veriler silinip(aynı bazda çalıştırılması durumunda silme işlemi yapılır) tekrar yazılması olarak tasarlanmış olup, eğer 
			istenirse senaryo bazlı çalıştırılıp hesaplama girdilerinde(kur vb.) veya mantığında değişikliklerle what-if analizleri yapılabilir.
		

		<h5 class="mt-4">Entegrasyon</h5>
		
			PaPM genellikle SAP BW4HANA üzerine kurulmaktadır. Bu sebeple BW4HANA’daki tüm nesne ve raporlar PaPM’de kullanılabilmektedir. 
			Hesaplamalar sonucu oluşurulan veriler BW’da Open ODS yapılarında tutulduğu için doğrudan raporlanabilir. Buna ek olarak eğer 
			istenirse PaPM’in içerisindeki veri yazma fonksiyonuyla da çıktılar BW’daki aDSO’ya yazdırılıp halihazırda yapılmış olan BW 
			raporlarında da kullanılabilmektedir.
			Şirketlerin bütçe planlama süreçleri için SAP BPC kullanması durumunda bütçe verileri de PaPM’de kullanıp bütçe simülasyonları 
			da yapılabilmektedir. BPC ile entegrasyonda genel olarak tercih edilen yapı ise fiili dağıtım anahtarları kullanılarak bütçe 
			verilerinin dağıtılması ve bütçe-fiili analizlerinin yapılması oluyor. BPC’den sadece karlılık için değil, istenen tüm 
			hesaplamalar için aktarım gerçekleştirilip kullanılabilmektedir.
			BW4HANA’ya verilerinin yazılabilmesi sayesinde SAP Analytics Cloud, SAP Design Studio gibi ürünlerin yanında BW4HANA’dan veri 
			aktarımı yapılabilen tüm analitik ürünlerle de (Power BI, Tableau vb.) çalışabilmektedir.
		

		<h5 class="mt-4">Rol ve Aktivite Yapısı</h5>
		
			SAP EPM ailesindeki diğer ürünlerde olduğu gibi PaPM’de de aktivite bazlı süreç takipleri yapılabiliyor. Aktivitelerin kullanım 
			avantajı ise sadece Aktiviteler için kullanıcı yetkilendirmesi de yapılabildiği gibi, aktivite loglarının takipleri de raporlarla 
			alınabilmektedir.
		

		
			Kısacası, SAP PaPM farklı sistemden veri aktarımı yapabilen, birçok sistemle entegre çalışabilen, istenilen tüm 
			hesaplamaların/modellerin oluşturabildiği, kullanıcı dostu arayüzü olan performans yönetimi güçlü bir ürün.

SAP PaPM (Profitability and Performance Management) SAP FS-PER

<h2>Çözünürlük Yükseltmeye (SR) Genel Bir Bakış</h2>&nbsp;Çok uzun bir süredir düşük çözünürlüklü bir fotoğrafta yüksek çözünürlüklü fotoğraf elde etme çabası içindeyiz. Bu amaçla bulunmuş yöntemleri ve algoritmaları genel olarak ikiye ayırmayı uygun buluyorum. İlki enterpolasyon bazlı konvansiyonel yöntemler olarak karşımıza çıkıyor. Daha modern algoritmalarsa yapay zeka algoritmalarının gelişmesiyle ortaya çıkıyorlar. Özellikle görüntü işlemede başarı sağlayan Convolutional Neural Network (CNN) ve verilen örneklere benzer çıktılar üretmeleriyle ön plana çıkan Generative Adversarial Network (GAN) tabanlı algoritmaların bu konuda başarılı olduğunu söyleyebiliriz.&nbsp;&nbsp;<h2>Konvansiyonel SR Modelleri</h2>&nbsp;Bilgisayarlar fotoğrafları tensörler olarak görürler. Klasik bir fotoğrafın kırmızı, yeşil ve mavi için üç kanalı bulunur. Yani, fotoğraf 256x256 piksel ise bu fotoğraf bilgisayarda (256x256x3)’lük bir tensör olarak tutulur.256x256’lık fotoğrafı 1024x1024’lük bir fotoğrafa genişletmek istediğimiz noktada önce 1024x1024’lük bir tuvale gereriz. Bunun sonucunda doğal olarak içerisindeki veriyi bilmediğimiz pikseller oluştururuz. Konvansiyonel yöntemlerde bu piksellerin değerleri var olan piksellerin verilerinden enterpolasyon (sofistike bir ortalama alma yöntemi diyebiliriz) kullanılarak çıkartılabilir. Bu tarz yöntemlere bilinear enterpolasyon, bicubic enterpolasyon gibi yöntemleri de dahil edebiliriz.&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/919683ea-8c7e-4679-a16c-c024baddc2ff.png" alt="Low-Cost Implementation of Bilinear and Bicubic Image Interpolation for Real-Time Image SuperResolution (Donya Khaledyan et al.)"></figure>&nbsp;Bu tarz konvansiyonel modeller eğitim verisine ihtiyaç duymazlar ve genelde daha hızlı sonuçlar verirler.Bu tür yöntemlere başka bir örnekse Deep Image Prior (Deep Image Prior, Dmitry Ulyanov et al. 2017) algoritmasıdır. Deep Image Prior denoising, SR gibi işlemler için kullanılan başka bir algoritmadır.&nbsp;<h2>Yapay Zeka SR Modelleri</h2>&nbsp;Yapay Zeka modellerini diğerlerinden ayıran iki ana etmen vardır. Bu modeller diğerlerine göre çok daha karmaşıklardır ve bir eğitim datasından öğrenerek sonuca ulaşırlar.Genel görüntü işleme konularındaki başarısı nedeniyle, bu konuda da ciddi ilk denemeler CNN mimarisiyle gerçekleştirilmiştir. (Image Super-Resolution Using Deep Convolutional Networks, Chao Dong et al. - 2014).Sonrasında yine görüntü işleme konusunu takip ederek, görüntü işlemede büyük başarılar sağlayan ResNet, SR işlemleri için eğitilmiştir(SRResNet, Ledig et al. 2017). Son olarak yeni örnekler (fotoğraflar) çıkarma görevlerinde başarı sağlayan GAN mimarisi ile denemeler yapılmıştır.Şu anda en çok başarı sağlayan iki model olarak SRResNet ve SRGAN’ı dikkate alabiliriz.&nbsp;&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/ae42ec4a-5166-49cc-8bed-349bc4db7514.png" alt="Photo-Realistic Single Image Super-Resolution Using a Generative Adversarial Network (Christian Ledig et al.)"></figure>&nbsp;<h2>Uydu Resimlemede SR</h2>&nbsp;Genel kullanımdaki Yapay Zeka SR modelleri başarılı olmalarına rağmen öğrenme hedefleri genellikle fotoğraflar üzerinedir. Bu nedenle uydu fotoğrafları üzerine ince ayar gerektirebilirler.&nbsp;<h3>Pan Sharpening</h3>&nbsp;Uydu fotoğrafları için elimizdeki farklı bir araçsa Pan Sharpening’dir.Optik Uydu sensörleri belli bir S/N (signal to noise ratio) üzerine çalışmak için tasarlanırlar. Bu nedenle sensörlerin tasarımı sırasında spectral ve spatial verilerin kalitesi arasında bir seçim yapma gereksinimi doğar. Spectral olarak daha başarılı (daha dar bir ışık spectrum’unu yakalayabilenler) olan sensörler, spatial (görüntüleme) olarak daha düşük çözünürlüğe sahipken, spectral olarak geniş ışık dalgalarını alan (yani bu dalgalar arasında ayrım yapamayan) sensörler yüksek çözünürlüğe sahip olabilmektedirler.Örnek olarak Airbus’ın <a href="https://up42.com/goingup/pleiades-neo">Pléiades Neo</a>&nbsp;uydularının görüntüleme bantlarını inceleyebiliriz.&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/e054f572-7855-4073-bc22-9cb1e5a788b8.png"></figure>&nbsp;Burada görebildiğimiz gibi Panchromatic sensörler daha geniş bant genişliğinde ışığa duyarlı olmalarına karşın 0.3 m resolution ile görüntü yakalayabilmektelerken, spectral olarak özelleşmiş sensörlerin resolution’ı daha düşüktür.Pan Sharpening yüksek çözünürlüklü tek kanal (örneğin panchromatic) resimlerin, daha düşük çözünürlükte de olsa spectral resimlerle birleştirilerek keskinleştirilmesi ve netleştirilmesi için kullanılan bir metoddur. Pan Sharpening diğer SR algoritmaları için bir başlangıç noktası oluşturmak için de kullanılabilir. Hatta iki ayrı uydudan alınan verilerin aynı şekilde netleştirilmesi için de kullanılması mümkündür. (Fusion of Landsat 8 OLI and Sentinel-2 MSI Data, <a href="https://ieeexplore.ieee.org/author/37897563500">Qunming Wang</a>, et al.).&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/b88ead7b-3c47-4904-92cb-db4579aa7d9f.png" alt="Pan Sharpening (Solda Multi Spectral Resim, Sağda Pan Sharpened Resim) – Kaynak: UP42 "></figure>&nbsp;Pan Sharpening uydu resimlerinde Object Detection’dan, Semantic Segmentation’a birçok hedef için zeka modellerinin başarısını yükseltmektedir:Improving Object Detection of Remotely Sensed Multispectral Imagery Via Pan-sharpening, Feng Chen et al. – 2020The Impact of Pan-Sharpening and Spectral Resolution on Vineyard Segmentation through Machine Learning, Eriita G. Jones et al. – 2020Genellikle uydu resimleri söz konusu olduğunda Pan Sharpening sonrası amaca uygun çeşitli yapay zeka modelleri denenmektedir.&nbsp;<h2>Genel Görüntü İşleme Modelleri</h2>&nbsp;Görüntü işlemede başarılı olmuş modellerin uydu görüntüleme sistemlerinde kullanılmasının önünde hiçbir engel yoktur. Ancak görüntü işleme modellerinin büyük bir çoğunluğu ImageNet ve Coco gibi fotoğraf veri kümeleri üzerine öğrenim gördüklerinden, bu tür fotoğrafları işlemede daha başarılı olabilirler. Yalnız tabii ki, bu modellerin uydu görüntülerine uygulanması ince ayarlar ve transfer learning’le gayet mümkün olmaktadır. (Satellite and Scene Image Classification Based on Transfer Learning and Fine Tuning of ResNet50, Amsa Shabbir et al. 2021).Genel görüntü işlemede araştırılan birçok model uydu görüntüleri için de kullanılabilir:&nbsp;<h2>Semantic Segmentation</h2>&nbsp;Semantic Segmentation bir görüntüdeki piksellerin hangi sınıfa ait olduğunun ölçümünü yapmaya çalışan bir görüntü işleme problemidir. Otonom araba algoritmalarında bolca kullanılan bir yöntemdir.&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/6663878e-487c-49de-8219-6e8067145ceb.png" alt="Semantic Segmentation resim piksellerini sınıflara ayırmaya çalışır. - Kaynak: Keymakr"></figure>&nbsp;Semantic Segmentation uydu görüntülerinde; tarım, orman, şehir, yol gibi alanların birbirinden ayrıştırılması ve bu ayrıştırma üzerinden istatistik çalışmalarının yapılması için kullanılabilir.&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/eac2b14b-7acb-4c35-ba5c-a1cddd69708c.png" alt="Segmentation model based on convolutional neural networks for extracting vegetation from Gaofen-2 images, Chengming Zhang et al. – 2018"></figure>&nbsp;Bu tarz modellerin farklı tarihlerde kullanılması durumunda tarımın bir bölgede nasıl geliştiği izlenebilir, doğal afetlerin sonuçları üzerine analizler yapılabilir.Semantic Segmentation klasik bir görüntü işleme problemidir, çözümünde genellikle CNN tabanlı algoritmalar kullanılır. Yakın dönemde transformer modelleriyle de iyi ilerlemeler kaydedilmiştir. Bu konuda öne çıkan bir algoritma olaran Swin Transformer, RedNet ve U-Net’i gösterebiliriz.&nbsp;&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/2acb600e-0753-48d1-a71e-0bf8b2423d9d.png" alt="U-Net ile yapılmış bir Semantic Segmentation örneği"></figure>&nbsp;<h2>Object Detection</h2>&nbsp;Object Detection görüntü işleme konusunda çok karşılaşılan başka bir konudur. 2006 yılında ImageNet veri kümesiyle başlayan ve daha sonra Coco gibi veri kümelerinin ortaya çıkmasıyla devam eden canlılık, görüntü işleme alanını kısa sayılabilecek bir sürede hızlı bir şekilde ileri taşıdı. Bu sırada ortaya çıkan CNN gibi mimariler sadece görüntü işlemede değil, neredeyse tüm yapay zeka konularında kullanılmaya başlandı.&nbsp;Object Detection ve Instance Segmentation bir resimde bulunan farklı objeleri yakalayıp, sınıflandırmak için kullanılan yöntemlerdir.&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/c17cd9a9-b0dc-4011-96b2-e6a07f910fc9.png" alt="Kaynak: Medium"></figure>&nbsp;Object Detection algoritmaları veri etiketlemenin ve bulmanın kolaylığı itibariyle Instance Segmentation’dan daha kolay eğitilebilirler. Object Detection için başarılı algoritmalar arasında CNN, ResNet'i, Instance Segmentation için ise Mask RCNN’i sayabiliriz. İki yaklaşımın da uydu görüntülemede kullanılması mümkündür. Ancak uydu görüntülerinde etiketleme problemleri nedeniyle şu anda Object Detection’ın genellikle daha başarılı olduğunu söylemek gerekir.&nbsp;<figure class="image"><img src="https://novadsacomphotos.s3.eu-central-1.amazonaws.com/1ac73e78-bb16-4c8b-957b-013733282d97.png" alt="Kaynak: DetectNet, NVIDIA"></figure>&nbsp;<h2>Uydu Görüntüleri Yapay Zeka Çalışma Süreci</h2>&nbsp;Yukarıda da açıklandığı gibi, uydu görüntüleri üzerinde yapay zeka süreçleri eğer mümkünse Pan Sharpening’le başlamalıdır. Pan Sharpening’le netleştirilmiş ve keskinleştirilmiş görüntüler üzerine düşünülen konulardaki yapay zeka modelleri üzerine çalışılmalı ve sonuçlar karşılaştırılmalıdır. Burada dikkat edilmesi gereken nokta yapay zeka modellerinin eğitim verisine “overfit” olmasının engellenmesidir. Yağmur ormanları görüntüleriyle eğitilmiş bir modelin Türkiye’de çalışması beklenemez. Bu nedenle çalışılacak bölgeye uygun veri hazırlanıp model seçimi üzerine çalışılmalı ve sonuçlar değerlendirilmelidir. Tabii sadece bölgesel değil, dönemsel farklılıklar da göz önünde bulundurulmalıdır. Ağustos ayındaki görüntülerle, şubat ayındaki görüntülerin farkının model tarafından öğrenilmesi isteniyorsa, iki dönemden de görüntülerin eğitim verisinde bulunması gerekebilmektedir.&nbsp;<h2>Örnek Bir Çalışma Süreci</h2>&nbsp;Uydu verileri üzerinden tarım topraklarının gelişiminin incelendiği bir proje yapıldığını farz edelim. Bu durumda tabi ki tüm Dünya’nın uydu görüntülerini incelememiz mantıklı olmayacaktır. Tarımsal toprakların bulunduğu bölgeleri incelememiz gerekecektir.Bu amaçla önce tarım yapılan toprakların koordinatlarının çıkarılması gerekecektir. Bu konuda üç yöntem izleyebiliriz.·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bir Semantic Segmentation yöntemiyle tarım arazilerinin keşfi ve takibi·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Vegetation Index gibi spektral veriden çıkarılan indekslerin yüksek olduğu yerlerin incelenmesi·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Manuel olarak incelenecek yerlerin belirlenmesiİlk madde için eğitilmiş bir modele ihtiyacımız varken, ikinci madde ormanlarla tarım arazilerini karıştırabilmektedir. Üçüncü maddeyse bir insan eforuna ihtiyaç duymaktadır. Yani mühendislik çalışmalarının hepsinde olduğu gibi burada da seçimler yapmamız ve bu seçimlerin avantaj ve dezavantajlarıyla projeye devam etmemiz gerekecektir. Sonrasında seçilen bölgelerdeki tarım arazilerinin yine benzer yöntemlerle ayrıştırılması ve dönemsel değişikliklerin takip edilmesi gerekecektir. Yeni verilerle modellerin yeniden eğitimlerinin sağlanması için gerekli MLOps yapıları kurulmalı ve sistemin devamlılığı sağlanmalıdır. Sonrasında ise ortaya çıkan bilgilerden bir analitik ortamında fayda sağlanması için çalışmalar yapılmalıdır.&nbsp;&nbsp;<h2>Göz Önünde Bulundurulması Gereken Konular</h2>&nbsp;Uydu görüntüleme sistemlerinin yarattığı verinin boyutu ve frekansı nedeniyle bu tarz projeleri AWS gibi bulut servis sağlayıcılarında yapmak hem performans hem de maliyet açısından avantaj sağlamaktadır. Ayrıca yapay zeka modellerinin birçoğu gelişmiş ekran kartlarında eğitilmekte olduklarından yine bu konuda da büyük bulut servis sağlayıcılarından yararlanmak maliyetlerinizi olabildiğince azaltacaktır.&nbsp;&nbsp;NOVADSA DevOps &amp; AI ManagerMert Tomruk

Pan Sharpening (Solda Multi Spectral Resim, Sağda Pan Sharpened Resim) – Kaynak: UP42 

Çözünürlük Yükseltme & Uydu Görüntüleri İşleme

<h3 class="mt-4">The Problem About Building New Products</h3>

		
			The thing about building a product from ground up is basically the development and hosting costs. Being a new product, it will not generate revenue right away. At the same time, we should design a reliable and resilient system so that, if we are up against large amounts of traffic the system should stay responsive. This gives rise to a paradox:
 <li>The new product does not generate any revenue yet.</li>
 <li>We should rent or buy servers to keep up with any number of requests, so the system remains responsive.</li>
			 
 This is why we see a lot of startups are searching desperately for funding and backers. 	
 But this also gives rise to another problem. Even if we rented or bought a bulky server to cope up with a huge traffic. Eventually maybe in a year or two, our traffic can easily outgrow our servers. Then we will need to replace our server or maybe we can buy another server and make changes to our code so it can work with multiple servers.

			
		


		<h5 class="mt-4">A Solution: Serverless Architecture</h5>
		
			There are different solutions to the problem we just described, maybe one of the most used is setting up Auto Scaling Groups for rented servers (EC2 instances in case of AWS) where a monitoring system like AWS CloudWatch scales up or down the group (i.e., terminates servers or rent new ones continuously depending on CPU or network loads).
While Auto Scaling Groups can be a good candidate for the problem we are facing, we think serverless services like AWS Lambda and Docker shine in this scenario. Auto Scaling Groups can scale up to demand, yes; but after all they are clusters of rented servers and we need to manage these servers (Operating System operations etc.). Auto Scaling Groups make update operations a bit hard on the fly: Think of a scenario where almost all of servers are updated but the update on the last server fails, will you roll back all the updates? Remember you cannot kill every server in your group and update them, since then your app would be offline.
Of course, there are ways to deploy updates without huge rollbacks and offline applications (e.g., Blue-Green deployment) but they are rather cumbersome and a bit slow.
By all means, Auto Scaling Groups are beautiful constructs; but we think they should be used where having a server is required. Setting up development environments, some Big Data applications and of course easily altering legacy applications so they can be scalable.
As we said earlier, we think that serverless services shine in these scenarios. AWS Lambda is a container service for lightweight jobs like sending e-mails, running small SQL queries, etc. It basically means that you write your code and AWS runs it in some computer for you. It is a perfect tool to form the backbone of a web server. We can host the web server on AWS Amplify and every interaction it makes with backend services can be made through AWS Lambda.
However, there are downsides to AWS Lambda too. Two big ones are cold starts and limited compute power. 
<li>When a Lambda function is called, AWS wraps up a container for the function to run on. It can take up to one second to deploy the container. It also makes the function warm which means that a second deploy is much faster. This is where the name comes from: if a function is not called for a while, it becomes cold and it takes longer to deploy a container. There are ways to mitigate this effect, perhaps most used is to warm up functions by calling them at times we expect high traffic.</li> 
<li>AWS Lambda is a service designed for lightweight jobs. Thus, it has restrictions on size of libraries we can include, size of code, RAM requirements etc.</li>
Meanwhile Docker is designed to do almost everything, so it is a good practice to use Lambda for lightweight background jobs and a Docker Container Service (e.g., AWS ECS) for difficult computations.

		

		<h5 class="mt-4">Product </h5>
		
			Mixit is essentially a multi-objective optimization tool. It takes a list of chemical properties from different products (source products), a target product list as an input. It computes a mixture matrix where the user can see how to mix source products, so he or she can get as close as possible to listed target products. It also can take into account product prices and volumes.
		

		

		

		<h5 class="mt-4">Architecture</h5>

		
			As we discussed above, we are a huge advocate for serverless technologies. Hence, we wanted to use Lambda for our application backend. Maybe it will be easier if we list choices we made on our development journey:
		
		
		<img src="https://i.ibb.co/TL0tGyb/Foyer1.png" alt="Foyer1" border="0">
		
		<h5 class="mt-4">Database</h5>
		
Since the shape operational data is not constant (there are 10 products in one project and 7 in another, same with chemical properties), we wanted to use a No-SQL database for the operational data. AWS DynamoDB was perfect for this job; it stores data as JSON, so no restrictions on shape, it can scale up almost infinitely and it is a managed service, hence no rented servers or whatsoever.
The client data is highly structured, so we used an AWS RDS Postgres server to host our client data.

		


		<h5 class="mt-4">Serverless Services</h5>
		
We deployed a REST API as a frontend-backend communication protocol. Each method of the API is linked to a Lambda function. Those functions handle basic database queries, integrates with AWS Cognito for authorization, basically almost everything.
Only the optimization process is too much for Lambda, it cannot handle it. So we wrapped it up in a Docker image and when an optimization job is requested a Lambda function deploys the image to AWS ECR Fargate (serverless container service of AWS).

		
		
		
		
		<h5 class="mt-4">Optimixit.com</h5>
		
			<a href="http://www.optimixit.com">Well, try it!</a>
			
			 
			 
			 
			<a href="https://www.linkedin.com/company/novadsa">Follow us on Linkedin!</a>

Foyer

SAP PaPM (Profitability and Performance Management) SAP FS-PER

Çözünürlük Yükseltme & Uydu Görüntüleri İşleme

The Problem About Building New Products

References

Customer Comments

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Uğur Duman

Hakan Okçuer

Kaya Aydın

Benefit From Our Services Now

Subscribe to E-Newsletter

Visit