Monovi WIN EUROSIA 2019’da

By on 2019-01-29 in Uncategorized

14-17 Mart 2019 tarihleri arasında TÜYAP Fuar ve Kongre Merkezinde “WIN Eurosia’19” fuarı düzenleniyor. 

Endüstriyel Otomasyon alanından Elektrik-Elektronik, Akıllı Binalar gibi geleceğin endüstriyel teknoloji alanlarını kapsayarak katılımcılarını heyecanlandıracak olan fuarda Monovi’de yer alacak.

WIN EURASIA 2018, 140 ülkeden 75.368 ziyaretçiyi ve 1.813 katılımcıyı bir araya getirdi. WIN EUROSIA ile Geleceğin Parçası Olmak için 14-19 Mart 2019 tarihlerinde Monovi 4.Hol – B190 standımıza davetlisiniz.

Ürün portföyümüzü inceleyerek, yeni iş bağlantıları kurmak için bizi mutlaka ziyaret edin.

Monovi FIT 2019’da

By on 2019-01-08 in Uncategorized

21-24 Şubat 2019 tarihleri arasında Fuar İzmir’de “Future Industrial Technologies’19” fuarı düzenleniyor.  FIT Fuarı, Endüstriyel Otomasyon alanından Elektrik-Elektronik, Akıllı Binalar gibi geleceğin endüstriyel teknoloji alanlarını kapsayarak katılımcılarını heyecanlandıracak.

On Binlerce ziyaretçi hedeflenen böylesine büyük bir iş fuarında
Monovi H180 standımıza davetlisiniz.

Ürün portföyümüzü inceleyerek, yeni iş bağlantıları kurmak için bizi mutlaka ziyaret edin.

Girişimciler için Proje Yönetimi Neden Önemli?

By on 2019-01-02 in Uncategorized

Her bir girişim, nihayetinde ortaya bir ürün çıkartmak için yola çıkar. Fikir dediğiniz şey aslında bir ürünün hayalidir. Peki bu ürünü ortaya çıkartabilmek için yeterli bilgi ve tecrübeye, donanıma sahip miyiz? Bunu her girişimci takım kendilerine sormalı. Günümüzde girişimcilik üzerine verilen eğitimler, seminerler, sunumlar, mentorluk çalışmalarında hep şunlar anlatılır; business canvas, acı/problem, sizin buna çözümünüz, potansiyel müşterilerle ilgili pazar araştırmaları vesaire.  Bunlar neredeyse standart bir girişimci eğitimi müfredatı haline gelmiş durumda. Nereye gitseniz karşınıza çıkıyor. Ben bunun biraz fazla dışına çıkıp büyük resme bakmaktan ve metodik olmaktan yanayım. Kısacası her bir girişim fikri, aslında birer projedir ve proje yönetimi metodojileri ve prensipleri mutlaka uygulanmalıdır. Bunun aksi, çok büyük olasılıkla onca emek, zaman ve paranın boş yere heba edilmesine sebep olacaktır.

Peki, proje yönetimi (PY) deyince ne anlıyoruz? PY’yi yeterince biliyor muyuz? Metodolojilerini, prensiplerini, pratiklerini hiç deneyimledik mi daha önce? Teknikleri nelerdir? İşin aslına bakarsanız, herkes proje yöneticisi bu memlekette. Ama gerçekten Proje Yönetimi uygulayanımız yok gibi (varsa yazın, deneyiminizi paylaşın). Proje Yönetimi, doğru uygulanırsa, girişiminizin başarısını en baştan çok arttıracaktır. Business Canvas, vs. teknikleri tabi bir kenara koyun, unutun demiyorum. Ama size başka ve bence çok daha derin ve ufuk açıcı bir kavramdan bahsediyorum.

Peki proje yönetimi metodolojileri ve teknikleri nelerdir? Bu çok geniş ve büyük bir konu. Özetle proje yönetimi deyince akla gelen referanslar şunlar;

PMBOK/PMP: Genel anlamda özellikle ülkemizde proje yönetimi deyince akla ilk PMI PMBOK/ PMP gelir. Ve bu oldukça yaygındır, kimi iş ilanlarında PMP (Project Management Professional) sertifikası isteyenlere rastlanıyor artık. Tabii ki PMBOK/PMP genel kanının aksine PY metodolojisi değil. Aslında bu bir çerçeve (framework) de değil. Adından da anlaşılaağı üzere “Project Management Body Of Knowledge”. Yani bir çeşit araçlar, teknikler ve “best practices” kataloğu diyebiliriz. Oldukça da girifit bir yapısı var. Girişim projeleri için belki de en büyük dezavantajı, ürüne odaklanmaması. Bu büyük bir handikap. PMBOK’ta çok bilinen 5 süreç gurubu iskeletini oluşturur; Başlatma (initiating), Planlama (planning), Yürütme (executing), İzleme ve Kontrol (monitoring and controlling), Kapanış (closing). Risk yönetimi, planlama, WBS, kapsam yönetimi, insan kaynakları yönetimi gibi temel alanlarda genel kabul görmüş teknikleri içerir.

PMBOK Guide—Fifth Edition

PRINCE2: “PRojects IN Controlled Environments”ın kısaltması olan PRINCE2, özünde ürüne odaklanan, süreç-bazlı bir proje yönetimi “metodolojisi”dir. İngiltere kökenlidir ve belki de en ilginç yanı, PMBOK’un aksine, yazılım projelerinin yönetilmesi konusundaki ihtiyaçtan doğmuştur. Daha sonra başka alanlarda da kullanılabilecek şekilde genelleştirilmiş. PRINCE2’da temel olarak 7 tema ve 7 süreç bulunur. Proje ekibinin rolleri, hedeflenen ürün tanımı, yapılacak aktiviteler bir çerçeve içinde önceden tanımlıdır. Bu yönüyle de benim favorim, herşey yerli yerinde, al şablonu, özelleştir ve kullan. Güzel yanı, PMBOK’dan da çeşitli teknikleri de alarak kullanabileceğiniz gibi (bu ikisi birbirinin tamamlayıcısıdır aslında), sadece PRINCE2 ile de rahatlıkla girişiminizi/projenizi yönetebilirsiniz.

PRINCE2 Process Model

AGILE/SCRUM: Giderek çok daha sık duyduğumuz bir kavram “Agile/Çevik”, ya da “Agility”. SCRUM da bir Agile tekniği. Son 3-4 yılda özellikle yazılım projelerinin yönetiminde epey popüler oldu. İnternette pek çok kaynak bulabilirsiniz. SCRUM rehberini buradan ücretsiz olarak indirebilirsiniz. SCRUM, yazılım projelerinde yaygın biçimde kullanılıyor. İşin özü, geliştireceğiniz ürünün özelliklerini bölümlere/parçalara ayırarak hızlı ve ucuz bir şekilde ve her bir tanımlı parçasını guruplayarak (sprintler) çok yakından/günlük olarak takip ederek tamamlamaya çalışmaktır. Her bir sprint tamamlandığında bir diğerine geçersiniz. Tüm sprintler tamamlandığında ürününüz tamamlanmış olur.  Ürününüzü geliştirirken çok sıkı bir takip, denetim ve disiplin sağlar. Kişisel tecrübelerime göre daha çok projenizin “yürütme/execution” aşaması için, yani yazılımı geliştirdiğiniz aşama için kullanabileceğiniz bir metodolojidir. Biraz daha ileriye gidersem, bence mutlaka yazılım geliştirme sürecinizde SCRUM yapmalısınız.

Grafik: http://kod5.org/scrum-metodolojisine-giris/

PLCOR: Bir diğer proje yönetimi aracı ise diğerlerine göre çok az bilinen PLCOR; “The Product Lifecycle Operations Reference” modelidir. Diğerlerinden ayrılan en önemli özelliği, tüm süreçlerinde belirli metriklerin olmasıdır. PLCOR tek başına yeterli olmadığında, kardeşleri DCOR, CCOR, SCOR’dan da faydalanabilirsiniz. PLCOR’un yapısı oldukça basittir, herşey önceden tanımlanmıştır. Size güzel bir yol haritası sağlar. Ne zaman hangi sırada neyi yapacağınızı, başarım kriterlerinizi/metriklerinizi belirleyebilirsiniz. Buradan yalın, güzel ve kolayca uygulanabilir bir proje yönetimi modeli çıkartılabilir. Ülkemizde pek bilinmeyen APIC SCC (Supply Chain Council) modelleri yakın gelecekte bir sıçrama yapabilir ve yaygınlaşabilir. En azından bu potansiyeli taşıyor.

Evet, buraya kadar çok genel bir bilgi vereyim, farkındalık oluşsun istedim. Vakit buldukça her biri için tecrübeye dayalı (sadece ansiklopedik değil) detaylı yazıları yine paylaşırım. Burada vurgulamak istediğim, girişimciler olarak üretmeyi hedeflediğiniz ürününüzü gözü kapalı el yordamıyla hiç bir model/metodoloji kullanmadan geliştirmeye çalışmamanız. Özellikle teknolojik bir ürün geliştiriyorsanız mutlaka proje yönetimi uygulayın. A’dan Z’ye belki tüm teknikleri en başta uygulayamayabilirsiniz. Ancak size en azından çok değerli bir iş disiplini kazandıracaktır.

Çağlar Türkal

Business Development and Projects Director

“IT Projesi” mi? Yoksa “Kurumsal Girişim” mi?

By on 2018-12-26 in Uncategorized

Özellikle kurumsalda çalışanlar iyi bilir; şirketin IT ekibi, diğer birimlerden gelen proje isteklerini yönetir ve tamamlamaya çalışır. IT ekipleri her zaman yoğundur ve başlarını kaşıyacak vakitleri dahi çoğu zaman yoktur.

Teamwork works together to build a gear system

Üstelik teknoloji inanılmaz bir hızla gelişmeye ve değişmeye devam ediyor. Bu teknolojik değişim trendlerini IT ekipleri mutlaka çok yakından takip etmeli. Lakin, iş yoğunluğu, maliyet gibi nedenlerle bunu hakkıyla yapabilenler azınlıkta. Zaten kurumsal IT birimleri artık günümüzde doğrudan iş birimlerine hizmet sunmak yerine, daha çok dışarıdan hizmet satın almayı koordine ediyor. Bu model, firmalara aslında esneklik sağlıyor. Çünkü her an ihtiyaç duyulan teknoloji ve teknoloji tabanlı hizmet tipi değişebilir ve buna uygun istihdamı firma içinde sağlamak oldukça maliyetli olabilir.

IT ekipleri iş birimlerinden gelen ihtiyaçları/gereksinimleri değerlendirerek en uygun çözümü projelendiriyorlar. Bu IT’nin esas görevi zaten. Ancak, son zamanlarda, iş birimi ve IT arasındaki işleyişe olan bakış açımızı değiştirmeye başladık. Bilmem ne kadar farkındasınız ama artık IT projeleri klasik anlamda olağan “proje”ler değil. Çünkü iş birimi tarafından istenen projeler, esasen firmanın rekabetçiliğini arttırmak, yeni pazarlar bulmak, yeni ürünler geliştirmek, pazar payını korumak veya genişletmek gibi amaçlar için üretiliyorlar. Basit ve bilindik anlamda, çalışanlara birer bilgisayar vermek, e-posta hesabı açmak, kablolu/kablosuz ağ erişimi sunmak, sunucu hizmetleri gibi çoktandır standart işler artık projeden bile sayılmazlar.

Bunların yeni nesil adı “IT Factory“.  Bu konuya daha sonra başka bir yazıyla değiniriz.

Bu standardlaşmış IT hizmetlerinin haricinde, esas rekabetçiliğe odaklanmış pek çok proje, firmaların IT ekiplerinin bitmeyen “backlog”unda yer alıyor. İşte bu projeler sayesinde yönetim, “IT” birimine bakış açısını artık değiştirmeye başladı.  IT birimi yalnızca standard hizmetleri sunan bir ekip olmaktan çıkarak, firma için değer üretmeye ve  değer zincirine “doğrudan” katkı sunmaya başladı. İşte bu noktada onlardan “IT ekibi” ve projelere de “IT projesi” olarak bakmak çok eksik, hatta yanlış olur.

Peki  “yeni IT” mi diyeceğiz? Elbette hayır! Temel “IT” hizmetleri her zaman olmaya devam edecek. Ancak değer zincirine yönelik “teknoloji” projeleri ve bunlarla ilgilenen “teknik ekipler”  artık o firmaların “Kurumsal Girişimcileri” konumundalar ve onlara artık “Kurumsal Girişimciler” ve projelerine de “Kurumsal Girişim Projeleri” adını vermeliyiz.

Bu “Kurumsal Girişim” ekibi, şimdiki gibi “IT” biriminin içinde yer almaya devam edebileceği gibi, esasen gidişat bu ekibin “IT” den ayrı bağımsız bir iş birimi olarak organizasyonda konumlandırılması yönünde. Kişisel düşüncem de, “Kurumsal Girişim” biriminin “IT”den bağımsız olmasının daha yararlı olacağı. Artık “IT” ekipleri, çoğunlukla katalog hizmetlerini sunmaya odaklanmalı. Zaten bu alanda dış kaynak kullanımı oldukça fazla. “IT” katalog hizmetleri çalışma ortamı ve işin sürdürülebilmesi için gerekli altyapı, donanım, paket yazılım gibi hizmetleri sunmaya her zamanki gibi devam edecek.

“Kurumsal Girişimcilik” ekibi ise satış/pazarlama, finans,  üretim, operasyon gibi ön cephede savaşanlar arasına dahil olmalı ve onlara ihtiyaç duydukları yenilikçi/inovatif ve rekabetçi teknolojiyi sağlamak için çalışmalı. Cephede yer almak, Kurumsal Girişimciler’e resmin bütününü görmelerini sağlar. Bu, çoğunlukla “IT ekipleri”nin sahip olamadıkları bir ayrıcalık. Bu nedenle IT hep “masraf merkezi” (cost center) olarak görülmüştür. “Kurumsal Girişimcilik (Corporate Entrepreneurship  ya da Intrapreneurship)”  ise net olarak bir “kazanç merkezi” (profit center) olacaktır.

Kurumsal Girişimcilik ekiplerinin geleneksel IT’ye göre bir avantajı da, sahadaki ihtiyaçları görerek anlamak ve uygun proje önerileri sunmak. Yani, iş birimlerinden gelecek proje isteklerini beklemek yerine, proaktif bir şekilde yeni proje önerilerini/tekliflerini iş birimlerine sunmak.

Kurumsalda inovasyon konularında uzun süredir  kafa yoruluyor; her firma bir şekilde inovasyon yapmaya çalışıyor. İşte “Kurumsal Girişimcilik” birimi ve ekiplerinin en öncelikli sorumluluklarından biri “inovasyon” olmalı.

Tüm bunlar gösteriyor ki “IT” birimlerine bakışımız ve yüklediğimiz sorumluluklar artık değişmeli. IT içerisinden “Kurumsal Girişimcilik” çıkarmanın ve sahaya süvarileri sürmenin vakti geldi.

Bu, oyunun yeni kuralı..

Çağlar Türkal

Business Development and Projects Director

Yazılım Geliştirmede Çeviklik ve İşin Özü

By on 2018-12-18 in Uncategorized

Dünya bir önceki gün olmadığı gibi, işlerimizi yapış şeklimiz de ister istemez zamana ayak uyduruyor. Teknoloji genelinde ve yazılım geliştirme özelinde durum farklı değil. Zamanın ruhu, değişimlere daha hızlı uyum sağlamayı zorunlu kılıyor. Bir yazılım projesini konuşurken var olan gereksinimler, daha yazılım geliştirme sürecinin başında değişmeye başlıyor.

Bu hızdaki değişimi yönetmek, geleneksel proje yönetim methodolojilerinde bizi zorluyor. Çünkü bildiğimiz ve bugüne kadar uyguladığımız, waterfall olarak bilinen yazılım geliştirme yaklaşımında, gereksinimleri ve iş analizini ta en başında yapıyoruz ve müşteri ile mutabık kalındıktan sonra ürün geliştirme sürecine başlıyoruz. Tabi ürün geliştirme aşamasında başta belirlediğimiz ve müşteri ile üzerinde anlaştığımız ürün/proje kapsamında daha sonra yapılacak değişikliklere genelde pek sıcak bakılmıyor. Bu, en başta yaptığımız maliyet/süre tahminlerini etkileme riski oluşturduğu gibi, aynı zamanda projenin zamanında ve bütçesinde tamamlanamama riskini de oluşturabilir. Dolayısıyla başta belirlenen proje kapsamı, zorunlu olmadıkça değiştirilmez, ve bunun için çoğunlukla istenilen değişikliklere öncelik puanı verilmesi gibi bir prosedür kullanılır. Bu sayede istenilen değişikliğin katacağı değere göre önceliklendirilmesi ve yalnızca yapılması gerekli görülen değişikliklerin (örneğin yasal değişiklikler her zaman yüksek önceliklidir) kapsama dahil edilmesi mümkün olabilir.

Geleneksel yazılım projelerinin yönetiminde her ne kadar kapsam değişikliğini kontrollü bir şekilde yapacak prosedürlerimiz olsa da, ürün geliştirmesi bittiğinde zamanı yakalayamama riski her zaman oluyordu. Özellikle uzun süren projelerde, proje bittikten sonra ortaya çıkan ürün, o anki gerek duyulan fonksiyon ve özelliklerin tamamını karşılayamayabiliyor. Bu da ürüne yatırılan onca paranın geri dönüşümünü olumsuz etkiliyor, beklenilen faydayı tam olarak sağlayamıyor, yani fayda/maliyet oranında istenmeyen bir düşüşe sebep olabiliyor.

İşin sonunda para ve pazar kaybına yol açabilecek geleneksel yazılım proje yönetimi modelleri yerine, özellikle göreceli uzun sürebilecek ve karmaşık yazılım projelerinde farklı yöntemler aramaya başladık. Günümüzde aslında çok yeni bir kavram olmasa da Çevik (Agile) Proje Yönetimi modellerinin hızla popüler olması da aslında sürpriz olmadı. Ortada belirgin bir ihtiyaç olunca, o ihtiyaca cevap verecek çözümler için arayış girmek de gayeet doğal.

Biraz uzun bir giriş oldu, ama yukarıda anlattığım arka planı bilmeden Agility/Çeviklik ne demek anlamak zor olacaktı diye düşünüyorum. Yazılım projelerinde hızlı ve aynı zamanda daha iyi fayda/maliyet oranı sağlamanın daha iyi bir yolu olmalı arayışıyla 2001 yılını Şubat ayında 17 kişilik bağımsız bir gurup, ABD’nin Snowbird/Utah kasabasında bir araya gelirler. Bir yandan kayak yaparak eğlenen bu küçük gurup, başta yazılım projelerinde olmak üzere iş yapış şeklimizde önemli değişiklik yaratacak olan “Agile Manifesto”yu yayınladılar. Muhtemelen bunun etkisinin bu kadar büyük olacağını ve sınırları aşacağını kendileri de tahmin etmemişlerdir. Bu arkadaş gurubu, aslında var olan sıkıntıların bir resmini çekmişler ve daha iyisi için nelerin yapılması gerektiğini veya bir başka deyişle, projelerde nelere daha çok değer verilmesi gerektiğini sadece 4 maddede özetlemişler. Ve buna bir isim vermek gerektiğinde “Agile”, yani çevirisi “Çevik” kelimesini uygun bulmuşlar.

Çevikliğin 4 değeri kısaca şunlar:

1-Süreçler ve araçlardan daha çok bireylere değer vermek:

Bunun anlamı, Agile yöntemlerin süreç bazlı değil insan bazlı oluşudur. Yani açıkça insanlara daha çok yetkilendirmeyi, kendi kendine karar almayı teşvik etmeyi ve daha az bürokrasiyi savunur. Böylece değişimlere daha hızlı yanıt vermek mümkün olabilecektir.

2-Detaylı dokümantasyonlara vakit harcamaktansa bir an önce çalışan bir yazılım geliştirmeye değer vermek:

Projelerin başında yoğun emek ve para harcayarak oluşturulan detaylı gereksinim dokümanlarıyla uğraşıp değerli zamanımızı harcamak yerine, bir an önce en azından yüksek öncelikli ve katma değeri yüksek fonksiyon ve/veya özellikleri geliştirip kullanıma hazır hale getirmeye çalışmaktır. Elbette bu, Agile yöntemlerde hiç dokümantasyon olmayacak demek değil. Sadece gerektiği kadar detay bilgiye sahip, genellikle “User Story” (Kullanıcı Hikayesi) dediğimiz formatta hazırlanan dokümantasyonlar olur. Ve daha önemlisi, tüm ürün için gerekli dokümantasyon projenin başında tamamlanmak zorunda da değildir.

3-Müşteriyle sözleşme pazarlığı yerine müşteriyle devamlı iş birliğine önem vermek:

Müşteri, proje konusunda sözleşme aşamasında yoğun olarak etkileşimdedir. Çoğunlukla bir kez sözleşme imzalandı mı, proje bittikten ve kullanıcı kabul testi aşamasına gelene kadar, proje sürecine pek fazla bir katkısı olmaz. Agile yöntemlerde ise burada çok önemli yapısal bir değişiklik var, artık müşteri proje ekibinin aktif bir üyesi olarak karşımıza çıkıyor. Müşteri, en popüler Agile methodu olan Scrum’da “Product Owner” olarak geliştirilen üründen azami faydanın sağlanması, geliştirme ekibinin sorularına yanıt vererek ürün geliştirmeyi yönlendirmek gibi kritik sorumluluklar üstlenir.

4-Proje planını katı bir şekilde izlemek yerine değişimlere karşılık vermek:

Proje kapsamını en başta belirlediğimizden ve bunun çok gerekmedikçe değiştirilmediğinden bahsetmiştim. Agile/Çevik yöntemler ise değişime açıktır, hatta projenin son aşamasında değişim talebi gelse bile. Sonuçta amaç, klasik anlayışla “projeyi başta belirlediğimiz kapsamda hele bir tamamlayalım da, gerisi çok da önemli değil” yaklaşımı yerine, “asıl olan hızlı bir şekilde kısmi bir ürün ortaya çıkartarak o anki gereksinimleri ve müşterinin bu üründen beklediği faydayı en üst düzeyde sağlamaya çalışmak”. Yani aslında, yazılımı geliştiren proje ekibi, klasik “müşteri ve tedarikçisi” anlayışı yerine, birbirlerinin “iş ortağı” durumuna gelmekte. Dahası, müşterinin performans metrikleri (KPI) aynı zamanda proje iş ortağının da gözettiği ve değer verdiği metrikler olmakta; “müşteri kazanırsa biz de kazanırız, sonuçta aynı ekibiz” felsefesi hayatımıza girmekte.

Agile Manifesto yayınlandıktan bir süre sonra buna birde tamamlayıcı olarak 12 adet Agile prensibi eklendi. Bu prensiplere daha sonra başka yazı değiniriz.

Bu 4 Agile değeri, organizasyonlarda iş yapış ve düşünce geleneğinde ciddi bir değişiklik yapılmasını gerektiriyor. Yılların alışkanlığından hemen kurtulmak öyle kolay değil. Üstelik yalnız projeleri geliştiren teknik birim ve ekiplerin değil, aynı zamanda müşteri konumunda olan paydaşların da bu Agile dönüşümü desteklemesi şart. Yeni projelerde bunun için müşteri ile diyaloğa büyük önem vermeliyiz ve onları proje süresince proje ekibine dahil etmeliyiz.

Aslında çeviklikte işin özü, bu manifestoda bahsedilen değerler ve müşterinin projeye başından sonuna kadar katılımında yatıyor.

Çağlar Türkal

Business Development and Projects Director

Değer Teknolojileri

By on 2018-12-11 in Uncategorized

Bilgisayarların gelişimiyle beraber bilgi işleme, bilginin iletimi ve saklanması ile ilgili teknolojiler inanılmaz bir hızla gelişti ve de yaygınlaştı. Temelde bilgisayar ile ilgili teknolojilere kısaca Bilgi Teknolojileri, İngilizce kısaltmasıyla “IT” (Information Technology) diyoruz. Ancak yalnızca teknoloji değil, aynı zamanda iş beklentileri de büyük bir hızla değişti. Öyle ki, geleneksel “IT” hizmetleri sorgulanır oldu. Alt yapı hizmetleri buluta taşındı, yardım masası gibi temel IT hizmetlerinde dış kaynak kullanımına geçildi, yazılım ise çoğunlukla dışarıdan alınan bir hizmet oldu.

Ancak günümüzde artık bu “IT” hizmetleri, tepe yönetimlerce sorgulanmaya başlandı. Alınan hizmet kalitesinin beklentileri karşılayamaması, üstüne IT hizmetlerinin çok pahalıya mal oluşu, rekabette istenilen çevikliğin yakalanamaması gibi nedenler IT operasyonlarını yeniden ele almamızı gerektiriyor.

Bilgisayarlar, ağ iletişimi, paket yazılımlar, temel bilgi güvenliği gereksinimlerinin karşılanması gibi temel IT hizmetlerinden vazgeçmek elbette mümkün değil. Ancak bir de işletmenin pazarda rekabet edebilirliği, daha çok satış ve kaliteli üretim yapması için ihtiyaç duyacağı teknolojik destek için bu geleneksel IT hizmetleri olmazsa olmaz fakat artık yeterli değil.

Peki yeni, IT bakışımız ne olmalı? Ben şu şekilde olması gerektiğini düşünüyorum; standardlaştırılmış katalog IT hizmetlerine “IT Factory” ya da kısaca “Katalog Teknolojiler” diyebiliriz. İnovasyona ve yeni değer üretimine odaklanan IT’ye ise “Değer Teknolojileri” olarak gruplayabiliriz. Bu dönüşümü şematik olarak gösterecek olursak;

Özetle, hazır IT ürün ve çözümlerini sunan birime “Katalog Teknolojiler (CT)” ve işletmeye değer katacak projeler üreten, iş birimleri ile entegre bir şekilde çalışan IT birimine “Değer Teknolojileri (VT)” diyoruz.

“Katalog Teknolojiler” biriminin sunacağı hizmetler kolaylıkla dış kaynak kullanımı ile maliyet-etkin bir şekilde tedarik edilebilir. Çünkü bu katalog hizmetler standartlaşmıştır ve yaptığınız iş ne olursa olsun piyasadan sağlanabilir.

İşletmeye esas değer katacak IT çözümlerini sunacak olan ise “Değer Teknolojileri” birimidir. Esasen bu birim, işletme içerisinde faaliyet gösteren bir “kurumsal girişimci ekip” gibi çalışmalıdır.  İşletmenin belirlediği hedefe ulaşmak için ihtiyaç duyulan teknoloji tabanlı çözümlerin tasarlanması, üretilmesi ve uygulaması konusunda diğer tüm iş birimleriyle ortak hareket etmelidir. Yalnızca bu yönüyle bile geleneksel IT birimlerinden büyük farklılık gösterir ve fark yaratır.

“Değer Teknolojileri” birimi kendisini IT birimi içerisinde izole etmez, tam tersine, kendisi başlı başına bir “iş birimi”dir. Tıpkı üretim, finans, pazarlama gibi. Birincil amacı, işletmenin vizyonu ve hedeflerine ulaşmak için gerekli inovasyonu ve etkin çözümleri sunmaktır. Biz buna “değer yaratmak” diyoruz. Özetle “Değer Teknolojileri” birimi, işletmenin “değer zincirine” odaklanır. Katma değer üretecek ürün ve hizmetleri teknolojiyi en etkin şekilde kullanarak üretir.

Bu dönüşüm, kolay olmamakla birlikte bir zorunluluk. Son zamanlarda sağda solda “Kurumsal Girişimcilik (Corporate Entrepreneurship)” kavramını sık duyar olduk. Bu kavramın içini doldurmak için işletmeler IT birimlerini VT’ye (Value Technology) dönüştürmeleri şart. Yoksa çok geç olabilir.

Çağlar Türkal

Business Development and Projects Director

 

Dijitalleşmeden Neyi Kastediyoruz?

By on 2018-12-04 in Uncategorized

 

Son zamanlarda önüme çok çıkan bir konu bu “dijitalleşme”. Bir mühendis olarak bana bu tanım çok tuhaf geliyor. O nedenle artık bir yazı yazmam şart oldu. Nedir bu dijitalleşme dedikleri şey diye baktığımda şunu görüyorum; özetle kağıtla, telefonla yapılan iş süreçlerinin elektronik ortama taşınarak bilgisayar yazılımlarıyla yönetilmesi. Kimi yazılarda eposta kullanımı dahi dijitalleşmeye örnek olarak gösterilmiş. Konuya böyle bakılınca bir hayli yadırgıyorum. Yıl olmuş 2018 ve biz Türkiye’de “dijitalleşme”den bahsediyoruz. Transistör 1947 yılında icat edildi ve çok uzun süredir kişisel bilgisayarlar evlerimizde ve herkes internete neredeyse 24 saat bağ(ım)lı yaşıyor. Hal böyleyken bugün neden iş dünyamız “dijitalleşme”yi konuşuyor? Benim yorumum şu; sorunu ya da ihtiyacı yanlış okuyor ve bu nedenle yanlış isimlendiriyoruz.

Ülkemizde eposta kullanmayan firma zaten uzun yıllardır yok. Her ciddi firmanın web sitesi de var. Yani interneti iletişim kanalı olarak kullanıyorlar. Günlük operasyonel iş süreçlerine baktığımızda, mutlaka bir muhasebe/finans yazılımını herkes kullanıyor. Yazılım kullanmayan firma yok. Pek çok firma Microsoft Office programlarını ve özellikle Excel’i çok yoğun bir şekilde kullanıyor. Pek çok ihtiyaç için Excel adeta bir kurtarıcı. Üstelik maliyeti de çok düşük ve hatta yok gibi bir şey. Yani aslında firmalarımız zaten ve çoktandır “dijital”. Öyleyse nedir bu “dijitalleşme” dedikleri şey?

Günümüzde firmalarda ki operasyonel ihtiyaçlar hızla değişiyor. Üretimi, satışı, pazarlamayı, finansı, aklınıza gelebilecek her işi yönetmek için yazılımlara bağımlıyız. İşte zurnanın zırt dediği yer de bence burası. Kimi firmalarımız Excel gibi programlarla işlerini bir ölçüde yürütebiliyor olsalar da işin ölçeği büyüdükçe daha farklı ve gelişmiş (ve de o alanda özelleşmiş) yazılımlara ihtiyaç duyuyorlar. Örneğin üretim yapan bir firmanın ERP yazılımları kullanması aslında lüks değil zorunlu bir ihtiyaç. Ancak hemen her yerde tek başına bir ERP yazılımı da işleri yönetmeye yetmiyor. İş süreçlerinize özel başka yazılımlar da kullanmak zorunda kalıyorsunuz ve dahası, bu yazılımların önemli bir kısmı birbirleriyle haberleşmek, veri transferi yapmak durumunda.

Ülkemizde hatırı sayılır bir bilgi teknolojileri/yazılım sektörümüz olmasına rağmen firmalarımızın iş süreçlerinde yazılım ve otomasyon teknolojileri kullanımı istenilen seviyede değil. “Dijitalleşme”den kasıt da işte bence bu. Gelişmiş ülkelerden örneklere bakarak rahatlıkla onlardan daha az yazılım ve otomasyon kullandığımızı görebiliyoruz. Üstelik, yazılım konusunda onca yerli firmaya rağmen çoğu alanda yurt dışı kaynaklı yazılımlara bağımlıyız ya da firmalarımız daha çok yabancı yazılımları tercih ediyorlar (daha pahalıya mal olmalarına rağmen).

Özetle, firmalarımız daha iyi bir yönetim, verimlilik artışı ve büyüme için doğru kararlar almalı ve bunun için de öncelikle analiz yapabilmek için ortada canlı bir veri seti olmalı. Bu veri setlerini sağlayacak olan ise elbette iş yazılımları. Yani işletmenizde iş süreçlerinde ve otomasyonda olabildiğince yazılım kullanmanız gerekli. Bu yazılımlar hem iş süreçlerinizi bir standarda sokacak, hem de her an analizde kullanabileceğiniz anlamlı veriler üreteceklerdir. Bu veriler ile yapılan analizler, tepe yönetimin sahadaki operasyonu daha net bir şekilde görebilmesini, riskleri analiz edebilmesini ve doğru kararlar almasını sağlayacaktır. Bütün olay budur ve yazılım/otomasyon üreticilerinin sağladığı en büyük “katma değer” kontrol altına alınmış bilgi akışıdır.

Firmalarımız operasyonel bilgi akışını kontrol edebilmek için yazılım teknolojileri ve ürünleri seçiminde çok dikkatli olmalılar. Önerim, elbette mümkün olduğunca yerli alternatifleri değerlendirmeye almaları olacaktır. Bu hem daha ekonomik bir çözüm hem de daha iyi bir teknik destek sağlayabilir. Yüksek döviz kurlarının yazılım ve otomasyon projelerinde bu yıl ve önümüzdeki yıl öteleme yapabileceğini öngörüyorum. Ancak bu yerli yazılım sektörümüz için bir fırsat da sunuyor. Dövizde yaşadığımız yükseliş ve paramızın değer kaybetmesi birazda yerli ürün ve çözümleri avantajlı hale getirdi.

Tahminim, firmalarımız önümüzdeki iki yıl başta ERP çözümleri olmak üzere yazılım yatırımlarını öteleyecekler. Elbette üretimlerinin çoğunu ihraç edenleri ayrı tutuyorum. Firmalarımızın en azından ekonomik düzelme başladığında ellerinde bir aksiyon planı olması için bugünleri değerlendirmeleri çok faydalı olacaktır. Bunun için bir yazılım/teknoloji danışmanlığı da veren firmalarımızla çalışmalarını kesinlikle öneriyorum. Monovi olarak biz de bu konuda size yardımcı olabiliriz. Belki de ihtiyaç duyulan sistemlerin maliyeti beklediğiniz gibi yüksek olmayabilir ve alternatifler sunulabilir. Bunu yapan firmalar, fırtına dindiğinde herkesten önce limana varmış, mallarını satmış ve geri dönüyor olacaklar.

Çağlar Türkal

Business Development and Projects Director

FIT Fuarındayız

By on 2018-02-20 in News

Monovi olarak 22-25 Şubat 2018 tarihlerinde Fuarİzmir’de gerçekleşecek F.I.T’18 Geleceğin Endüstriyel Teknolojileri fuarına katılıyoruz.  D-240 numaralı standımıza bekleriz.

 

MONOVİ IT AKADEMİ Agile/SCRUM EĞİTİMİ

By on 2017-03-17 in Training

Monovi IT Akademi olarak bu yılın ilk planlı eğitimini 16 Mart 2017 tarihinde Alsancak’ta gerçekleştirdik. Dopdolu bir 3 saatin ardından sohbetimizle biraz daha uzattık. Monovi IT Akademi olarak amacımız, teknik ve kişisel gelişim eğitimlerini İstanbul’a gitmeye gerek kalmadan aynı kalitedeki eğitimleri İzmir’de gerçekleştirmek ve mümkün olduğunca fazla IT uzmanı ve IT yöneticileri ile güncel teknik ve yönetimsel bilgiyi paylaşmak.

 

Proje Yönetimi ve Çeviklik Semineri

By on 2016-11-27 in Uncategorized

Proje yönetimi ve çevik ürün geliştirme ile ilgiliyseniz bu seminer size göre.

Özellikle Bilişim sektörüne yönelik seminerimizde güncel proje yönetimi pratiklerini ve methodlarını konuşacağız. Başta SCRUM olmak üzere Agile/Çevik yöntemlerini, PRINCE2 ile proje yönetimini ele alacağız. Yazılım proje yönetimine giriş için gerekli temel bilgileri edinmiş olacaksınız. Ayrıca tecrübelerimizi de paylaşıyor olacağız.

Kimler katılmalı?

  • Yazılım geliştirme ekibi takım liderleri,
  • Yazılım geliştiri
  • Proje yöneticileri
  • İş analistleri
  • Şirket yöneticileri

Yer: Teknoparkİzmir İnovasyon Merkezi, seminer salonu, İYTE Kampüsü, Urla/İzmir

Konuşmacı: Çağlar Türkal

Zaman:  5 Aralık 2016 Saat 14:00 – 17:00

Yes: Teknoparkİzmir İnovasyon Merkezi, Seminer Salonu,  İYTE Kampüsü, URLA/İZMİR

Organizasyon:

Monovi IT Akademi

Teknoparkİzmir