Dijital dönüşüm bir amaç değil araçtır. Onu bir amaç yerine koymaya başladığınızda dönüşüm yolculuğunda karşınıza çıkabilecek soruları cevaplamanız, tercihleri sağlıklı bir şekilde değerlendirmeniz ne yazık ki mümkün olmaz.

Dijital dönüşüm yarışında geride kalmamak pek çok işletmenin ve yöneticinin arzusudur. Hele ki bu kadar trend olmuşken. Dönüşüm ve yenileşme isteği kendi başına çok olumlu olmasına rağmen işin sadece bir yanı. Bu istek tüm ekibi motive edecek ve kaynakları dijital dönüşüme yönlendirecektir, ancak bu enerjinin ve kaynakların sonuç vermesi için net bir vizyona ve hedeflere odaklanması gerekir. Burada dijital dönüşüm vizyonunu bulanıklaştıran, biraz da toplumsal kültürden kaynaklı bazı sorunlara, ve bunları aşmak için odaklanmanızı sağlayabilecek bazı önerilere değineceğim.

Dünya Ekonomik Forumu kurucusu ve başkanı Klaus Schwab dördüncü sanayi devrimi üzerine yazdığı kitapta [1] teknoloji ile ilgili iki yanıltıcı bakış açısına dikkat çekiyor. Burada yer vereceğimiz birinci yanıltıcı bakış açısı “teknoloji geleceği belirler” diye özetleyebileceğimiz, yöneticiler ve profesyoneller arasında çok yaygın olan bir bakıştır. Buna göre teknolojik ilerlemenin etkileri değiştirilemez, durdurulamaz, ve geleceğin nasıl olacağını tamamen teknoloji belirler. Bu bakış açısı ile sektör sohbetlerinde, iş dünyasının geleceği ile ilgili yapılan teknoloji sunumlarında bolca karşılaşırsınız. Size örneğin akıllı robotların üretim hatlarını nasıl değiştirdiğini anlatırlar ve siz de işletmenizde aynısını yapmanızın rekabet gücünüzü korumak için kaçınılmaz olduğunu söylerler. Teknolojik gelişmenin gerçekten de çok hızlandığı ve küresel rekabetin kızıştığı günümüzde bu bakış açısı bir “sürü” etkisi yaratıyor. Öyle ki diğer, rekabetçi işletmelerin teknolojik uygulamalarını benimsemekte tereddüt etmek ilerleme karşıtlığı, hatta gericilik gibi görünecektir. Bu bakış açısının gölgesinde teknolojinin etkilerini sorgulamaya çalışmanın veya yönünü belirleme çabasının pek yeri yoktur.

Bu bakış açısı çok yaygın ve beraberinde önemli bir sorunu getiriyor. Sorun şu ki bu bakış açısınna kendinizi kaptırdığınızda teknolojik uygulamaların kendisi bir amaç haline geliyor. Bu etkileri sizin de işletmenizde kullanmış olabileceğiniz türden dönüşüm hedeflemelerinde görebilirsiniz “E-ticarete girmeliyiz, çünkü rakiplerimiz öyle yapıyor”, “sevkiyat alanımız çok düzensiz, kapsamlı bir depo yönetim yazılımı kurmalıyız”, vb. Gerçek işletmelerde karşılaştığım bu örnekleri özellikle seçtim, çünkü iki örnekte de yapılan teknolojik hamleler ya boşa gitmiş ya da daha kötüsü iş süreçlerinde olumsuz ve yıkıcı etkiler yapmıştır. Gördüğünüz gibi bu yaygın bakış açısı teknolojik çözümlerin sorgulanmaksızın yararlı oluğunu, hatta bunun kaçınılmaz kabul ettiği için dönüşüm ile ilgili değerlendirmelerimizi ciddi şekilde kısıtlamaktadır.

Bu bakış açısının sahada gözlemlediğim bir olumsuz etkisi daha var ki alttaki sıkıntıyı daha da iyi gözler önüne seriyor: bu bakışla alınan dijital dönüşüm kararları çoğu zaman onları hayata geçirecek çalışanlar ve ara düzey yöneticiler için boşlukta kalmaktadır. Çünkü yukarıda iki örneğini verdiğimiz türden dijital dönüşüm projeleri gerçekleştirme süreci içerisinde çok sayıda tasarım kararı vermeyi gerektirir: “e-ticaret için hangi yazılım seçilecek, neye göre?”, “hangi sevkiyat süreç şablonları bizim için daha uygundur?”, vb. Dönüşüm sürecindeki pek çok küçük adımın anlamlı bir yere doğru evrilmesi için buna benzer soruları cevaplarken sırtınızı dayayabileceğiniz bir vizyona ve işletme için anlamlı hedefler koymaya ihtiyaç vardır.

Dolayısıyla bu çözümleme geldiğimiz noktayı şöyle özetleyebiliriz: dijital dönüşüm bir amaç değil araçtır. Onu bir amaç yerine koymaya başladığınızda dönüşüm yolculuğunda karşınıza çıkabilecek soruları cevaplamanız, tercihleri sağlıklı bir şekilde değerlendirmeniz ne yazık ki mümkün olmaz.

Bu noktada tersine örneklerden yola çıkarak bir alternatif ortaya koyabiliriz. Büyük ve küresel işletmelere dijital dönüşüm desteği vermekte oldukça geniş ve eski tecrübe sahibi bir şirket olan IBM’in sitesinden alıntı yapacak olursam [2] “dijital dönüşüm dijital-öncelikli müşteri, iş ortağı, ve çalışan deneyimlerini benimsemektir”. Bu son derece rafine tanımlamada teknoloji kavramının hiç geçmediğine dikkatinizi çekerim. Onun yerine dijital dönüşüm tamemen hedefleri açısından tanımlanmıştır. Üç önemli iş paydaşı grubunun giderek dijitalleştiğini kabul ediyor ve onlarla olan etkileşimi dijitale taşıyacak bir dönüşüm öneriyor. Öncelikle bu bakış açısının sınırlı ancak gerçekçi olduğunu not edelim: teknolojik gelişmeyi ve iş çevresinde yarattığı değişimi yadsımıyor, kucaklıyor. Öte yandan teknolojik değişimin kendisine, yani araca odaklanmak yerine onun öznesine (müşteriler, iş ortakları ve çalışanlar) odaklanıyor.

Yukarıdaki başarısız örnekler üzerinde incelersek, ilk örnekteki orta ölçekli imalat şirketi e-ticaret girişimini başka işletmeleri taklit ederek şekillendirmiştir. Ancak işletme B2B pazara sahip iken benimsediği model ve araçlar tamamen B2C pazarlara yönelik. Bu örnekte işletme araçlara odaklanmış ve e-ticaret projesini diğer işletmelerin popüler tercihlerine göre şekillendirmiş. Oysa seçilen yazılımlar, teknolojiler ve onların tasarımına esas olan B2C ticaret modelleri işletmeye uymuyordu. IBM’in tanımı üzerinden ifade edersek firmanın kendi pazarının ve müşterilerinin deneyimine değil başka birilerinin deneyimine uygundu. Bu örnekte e-ticaret girişimi 2 yıldan az bir zamanda sönümlenerek başarısız olmuştur. İkinci örnekteki orta-büyük ölçekli imalat şirketi ise OEM pazarına uygun bir depo yönetim teknolojisi seçmiştir; yine teknoloji seçimi amaç değil araç odaklı olduğundan rakiplere, popüler teknolojilere bakılarak tercihler yapılmış. Oysa işletmenin müşteri portföyü OEM müşteriler kadar spot pazara yönelik karışık alım yapan müşterilerden oluşuyor. Dolayısıyla depo stok yönetimi ve sevkiyat süreçleri tercih edilen teknolojilerin tasarımına esas oluşturan süreçlerden farklı. Hedefe odaklanma eksikliği burada da yanlış tercihlere yol açmıştır. Bu ikinci örnekteki işletmede kurulan sistem iç paydaşlar arasında ciddi bir kargaşaya, sevkiyat aksamalarına ve stok takibinde sorunlara neden olmuştur.

Burada yöneticiler için bir sonuçtan bahsetmek gerekirse: dijital dönüşüm başka birilerinin, onların geliştirdikleri teknolojilerin belirlediği birşey değildir. Teknolojik gelişmeleri takip etmekte zorlansanız bile bu dönüşümü belirli hedeflere odaklamak yerine onu teknokratlarınıza (örn. IT departmanına) bırakmanız kısa vadede bir kaçış ama orta vadede başarısızlık, zarar ziyandan başka bir sonuç doğurmayacaktır. Dönüşümdeki öncelikli paydaşları (müşteriler, tedarikçiler, operasyonu yürüten çalışanlar) ve onların öncelikli ihtiyaçlarını belirleyip çerçevelemeden dönüşümü sağlıklı bir şekilde projelendiremezsiniz. Ayrıca bu şekilde ilerlemek projeyi yürütmesiniz beklediğiniz uzmanlarınızın da hedefe odaklanmasını ve gerekli detaylara size yük getirmeksizin karar verebilmelerini sağlayacaktır.

Bu şekilde daha sağlıklı bir yaklaşımın nasıl bir prosedür ile gerçekleştirilebileceğini ilerideki yazılarda inceleyeceğiz.

Programlama dili neden önemsizdir?

Programlamaya başlayanlar bir programlama dilini gözüne kestirmek ihtiyacı hissederler ve bunu çok önemserler. Çünkü göz korkutucu görünen bir iştir. Olsa olsa bir programlama dili öğrenebileceklerini düşünür ve haklı olarak en doğrusunu seçmek isterler.

İşin doğrusu şu ki asıl öğrenilmesi gereken algoritmik düşüncedir. Şöyle düşünün bir dili bilmek sizin o dilde güzel öyküler yazabileceğiniz anlamına gelmiyor. Güzel bir öykü yazmak kompozisyon ve anlatım tekniklerini bilmeyi gerektirir. Bu şekilde tasarladığınız bir öyküyü bildiğiniz herhangi bir dilde yazabilirsiniz. gerçekten de güzel öyküler farklı dillere çevrildiğinde gücünden hiçbirşey yitirmiyor. Buna benzer şekilde algoritmik düşünce bir hesaplama hikayesini doğru şekilde ifade etmeniz için temel bilgidir.

Zaman zaman ortaokul-lise düzeyinde öğrencilerle çalışıyorum. Bu eğitimlerde amacımız onlara problemlere sistematik yaklaşma ve çözümleri doğru ve güzel ifade etme becerilerini kazandırmak. Bu yüzden dünyanın en basit programlama dillerinden biri olan ve kökeni 1950’lere kadar giden Scheme’i kullanıyoruz. Çok basit ve öğrenmesi çok kolay bir dil. Bu basitliğine rağmen algoritma kurma ve hesaplama problemlerini sistematik olarak çözmek için gerekli tüm temel söz dizimlerini sağlıyor. Böylece bir hikaye oluşturmak için aşmak gereken önemli bir zorluğu, yani dilin grameri ve sözdizimi sorununu, neredeyse ortadan kaldırmış oluyoruz. Bu sayede öğrenenler daha temel olan algoritmalara odaklanabiliyorlar.

Programlama dili neden önemlidir?

Programlama öğrenmeye yeni başlayacak herkes içi Scheme iyi bir öneri. Ne var ki daha ileri yaşta üniversite öğrencileri veya profesyonellerin soruları genellikle “Programlama için Java mı, C++ mi, Python mu?” veya “En geçerli veri analitiği dili R mı Python mu?” şeklinde geliyor. Ben de bu soruya doğrudan yaklaşacağım. İlk bölümde söylediklerimize rağmen bu sorunun şöyle bir anlamı var: her programlama dilnin tasarımı ve tarihsel gelişimi onu bazı konularda daha yetkin yapıyor. Programlama dili bizim algoritmalarımızı ifade etmemiz için bir araç. Aynı hikayeler gibi algoritmaları da dil sayesinde yazmıyoruz (ilk bölümün anlattığı bu) ama onları dil ile yazıyoruz. Eğer seçtiğiniz dil o hikayenin ihtiyaç duyduğu sözcükleri sağlamıyorsa çok zorlanırsınız. Bu yüzden dil seçiminin hala bir anlamı vardır.

Ancak dil seçimi anlatmak istediğiniz hikayenin konusuna, yani algoritmanızın çözeceği progleme bağlı. Burada iş analitiği problemlerinden bahsettiğimizi hatırlayalım. Öncelikle C/C++ seçeneğini masadan kaldıralım. Bilgisayarın derinliklerine (işlemciye ve donanımın diğer parçalarına, programcıların deyişiyle ‘çıplak metal’e) ulaşabilen bu diller bir bilgisayar sisteminin alt katmanlarında (metal’in hemen üstünde) yer alan bilgisayar programları için uygun. Günümüzde bunları yazan az sayıda programcı var. İşletim sistemi veya donanım sürücüsü yazmıyorsanız bu dile ihtiyacınız yok demektir.

Şimdi Java ve Python’u karşılaştırabiliriz. Bunlar neredeyse birbirinin tam tersidir. Java yazılım endüstrisi tarafından geliştirilmiş bir dildir. İki temel tasarım ilkesi vardır: (1) Bir kere yazılan kodun farklı müşterilerin sistemlerinde çalışabilmesi (platform bağımsızlık), ve (2) “Yazılımı yazılımcıdan korumak” olarak tarif edebileceğim “kati tipleme” (programlama dili jargonunda ‘strict typing’). Birinci ilke Java’nın ‘metal’den olabildiğince uzak durması anlamına geliyor. Gerçekten de bir C/C++ programı ne kadar ‘metal’e yakın bir yerde çalışıyorsa bir Java programı da o kadar metal’in üstünde ve uzaktır. Böylece sistemden sisteme olan donanım farklılıklarından etkilenmez. Java programı ‘Java Virtual Machine’ denilen bir tür farazi bilgisayar üzerinde çalışırlar. Java sisteminin üreticileri farklı bilgisayar sistemleri için bu farazi bilgisayarın uyarlamalarını yapıyorlar. Böylece java yazılımı üretenler bu farklılıklardan etkilenmiyor, ürünleri platform bağımsız oluyor. Bu yüzden de en yaygın dillerden biri. İkinci tasarım ilkesi ise programcılar için bir cehennem. Java dili yazılımcının istediği algoritmayı ifade etmesini ön plana çıkartarak tasarlanmamıştır. Onun yerine yazılım imalatının kalabalık şirketlerde yapıldığı, ürünü tasarlayanlar, kodu yazanlar, grafik arayüzü üretenler gibi farklı yazılım departmanlarının bir endüstriyel plana göre çalışacağı, ve aralarındaki en küçük uyumsuzluğun tespit edilebileceği, sıkı kontroller gözetilerek tasarlanmıştır. Bir programcı için java programlamak bir avuç çivi yutuyormuş hissi verir. Gençlere ilk dil olarak Java öğretmeye kalkışmak onların programcılıktan soğumasını garantiler; bunun ne kadar yaygın olduğunu düşünmek tüylerimi ürpertiyor.

Bununla karşılaştırıldığında Python kodu yazmak ise Mango meyvası yemek gibidir diyebilirim. Python’un temel tasarım ilkesi programcının zihnindeki algoritmaları ifade etmesini kolaylaştırmaktır. Bu yüzden programcının zihnindeki algoritma hatalı ise hata -Java’da olduğu gibi- hiçbir engelle karşılaşmadan koda yansır. Dolaysıyla müşteriye doğrudan satışı yapılacak bir yazılım için en uygun seçenek olmayabilir. Ama örneğin Google’da en yaygın kullanılan dildir. Çünkü Google kodlarını değil bu kodların çalışmasıyla ortaya çıkan servisleri müşteriye satıyor. Ve evet hataları da oluyor. Ancak hızlı inovasyon yapmak istiyorsanız, problemlerinize düşündüğünüz çözümleri hızla koda dökmek istiyorsanız Python idealdir. Python da C/C++’ın aksine ve Java’ya benzer olarak (onun kadar olmasa da) ‘metal’e uzaktır. Python kodu farklı sistemlerde hemen hiç değişiklik gerektirmeden çalışır.

Python’un bir başka temel özelliği de muazzam miktarda farklı amaçlar için yazılmış kitaplık olması. Ticari satışa pek elverişli olmaması, ama programcılar tarafından pek çok farklı iş için kullanılıyor olması biraraya gelince bu programcılar kodlarını da açık kaynak olarak paylaşıyorlar (Python paket endeksi’nde an itibariyle 166,075 farklı proje bulunuyor). Ayrıca Internet forumlarında da çok büyük miktarda örnek ve yardım bulmak mümkün, java’da olmayan ölçüde. Hepsi iyi kalitede olmasa de muazzam bir bolluk bu.

Veri analitiği için bazılarınca Python’un cazip bulunmasının bir nedeni bu paket bolluğu. Ancak şunu söylemek gerek ki Python çok amaçlı ve kod yazımı kolay bir dil olarak tasarlanmış. Bu tasarım ilkesi onun kendi kulvarlarında Java veya C++ ile yarışamayacağı anlamına geliyor. C/C++’ın hızına yaklaşması veya metal’e erişmesi mümkün değil. Java kadar hata tespitinde yetenekli ve platform bağımsız da değil. Ancak yeni bir algoritmik problemin çözümünü hızlıca üretmek konusunda kimse eline su dökemez.Dolayısıyla programın çalışma hızı değil ama programcının çalışma hızı konusunda iddialı bir dildir.

Neden R?

Yine de Python veri analitiği konusunda ihtisaslaşmış bir dil değil, aksine ihtisaslaşmaya karşı bir dil. R ise bir istatistiksel programlama platformu. Dolayısıyla veri analitiği ve istatistik konuları söz konusu olduğunda R ile Python’u karşılaştırmak İsviçre çakısı ile motorlu testereyi karşılaştırmak gibi olurdu. Ağaç kesmek için çakı kullanmadığınız gibi kampa giderken de ağaç testeresi götürmenin alemi yoktur. Eğer veri analitiği ile uğraşacaksanız tercihiniz kesinlikle R olmalı!

R kullanarak veri analitiği yapacak profesyonellerin fazla algoritma becerisine ihtiyacı yoktur. Onun yerine hangi analiz yönteminin (örn. karar ağaçları, regresyon, sepet analizi, kümeleme, vb.) hangi iş problemini çözeceği konusuna odaklanırlar. İş analitiğinin aşamalarını yerine getirmek için birkaç satırdan oluşan R komutları yazıp çalıştırmaları yeterli olacaktır.

Öte yandan standart olmayan bir analiz algoritması geliştiriyorsanız bunu yapan bir R (veya başka bir dilde) paketi bulamazsınız. bu durumda yapılacak doğru şey Python veya R ile bu algoritmayı kodlamak olmalıdır. Böyle bir durumda hangisinin doğru olduğunu söylemek zor. Algoritmanın alt parçaları için ihtiyaç duyduğunuz kitaplıkları hangi platformda bulabiliyorsanız onu kullanın diyebilirim.

Bitirirken şunu da söyleyelim: bir programlama dilinde edindiğiniz beceriler diğer programlama dillerinde de ‘hikaye yazma’nızı kolaylaştıracaktır. İhtiyaçlarınıza uygun dili öğrenip kullanmadıkça hikayeyi doğru anlatamazsınız. Çakıyla ağaç kesmeye çalışır duruma düşmekten kaçının.

Nasıl/Hangi R?

Nasıl veya hangi R gibi bir soruyu ticari yazılımlarla ilgili olarak sormazsınız. Ama yazılım açık kaynak olunca sınırları da belirsizleşir. Açık kaynak yazılımlar başka yazılımlarla etkileşir, birleşir, büyür. Bu da kafa karıştırıcı olabilir. R istastistik platformunun temel bileşeni diyebileceğimiz istatistik motoru (R-engine) hala çekirdek bir ekip tarafından koordine ediliyor, birçok büyük açık kaynak yazılımda olduğu gibi. Ancak R’ı farklı kullanıcı türlerine ve kullanım senaryolarına uygun hale getirmek için farklı şirket veya birey/gruplarca üretilmiş yazılım bileşenleri var. Bunlara baktığınızda açık kaynak ve kapalı kaynak sınırları belirsizleşiyor. Bu konuda dikkatli ama pragmatik olmanızı öneririm. Burada genel bir bakışın yanında somut (ama kişisel) önriler de vermeye çalışacağım.

R ekosistemi temel R motoru’nun yanı sıra sayıları 20.000’e yaklaşan R paketinden oluşuyor. Bunlar CRAN (Comprehensive R Archive Network-Kapsamlı R Arşivleri Ağı) web servisi üzerinden tarama, arama, kurulum ve dökümantasyonuna ulaşabileceğiniz kitaplıklar. Biotistatistik, finansal analiz gibi birçok alanda kullanabileceğiniz paketler mevcut. Çoğu zaman benzer işlevler sunan birden fazla paket var. Aynı bir pazar yeri gibi, seçenek bol ama biraz da kafa karıştırıcı. Bazı kitaplıklar istatistik işlevleri değil de kullanım kolaylığı sunuyor. Örneğin Rattle kitaplığı makine öğrenmesi kitaplıklarını bir grafik arayüzden yönetmek amaçlı üretilmiş. Makine öğrenmesi odaklı bir eğitimde katılımcılara bir satır bile R kodu yazdırmadan kullanabileceğiniz türden bir arayüz sağlıyor. RCommander dahil buna benzer R grafik arayüzleri bulunuyor (bkz https://www.linuxlinks.com/guisforr/).

Ben eğitimlerin başlangıcında katılımcıların sade R motoru ile çalışmalarını tercih ediyorum. Bu şekilde R’ın tadına varmak ve motoru tanımak mümkün oluyor. R motoru sadece bir terminal ekranından kontrol ediliyor. Tam anlamıyla programlama diline yoğunlaşmayı sağlıyor. Bu aşamada R programlama dili ile veri yapılarını öğrenmek, temel betimsel istatistik işlemleri yapmak oldukça da rahat.

Ancak biraz ilerleyince RStudio kullanmaya geçiyorum. RStudio “iyi huylu” bir ticari R sistemi. RStudio R motoru’nun üzerinde çalışan iyi tasarlanmış bir grafik arayüzü ve bazı R kitaplıklarından oluşuyor. Şirket grafik arayüz dahil kişisel kullanıma yönelik temel bazı bileşenlerini açık kaynak olarak paylaşıyor. Ancak kurumsal ortak çalışmaya yönelik bileşenler (RServer ismini vermişler) ücretli. RStudio’ya geçmemin birinci nedeni iyi tasarlanmış grafik arayüzü. Bu arayüz bir iş analitiği süreci için güzel bir kumanda paneli ve araç kutusu sağlıyor. Güzel de bir editörü var.

RStudio tercihimin ikinci nedeni ise sistemin bir kitaplığı. RMarkdown kitaplığı iş analitiği için gerekli çok önemli bir ihtiyacı karşılıyor: raporlama. Normalde R veya başka bir programlama dili ile yaptığınız işin sonuçlarını, mesela görselleri ve metrikleri kopyalayıp bir dökümana yapıştırarak, çıktıralı nasıl yorumladığınızı da ekleyerek raporlaştırmanız gerekir. Ancak bu şekilde iş analisti bir iş organizasyonunun diğer bileşenleriyle iletişim kurabilir. Dolayısıyla yeni verilerle analizler yaptığınızda veya analizinizde geliştirmeler yaptığınızda tekrar tekrar kesip yapıştırmanız gerekir. Bu zahmetli, zaman alan, ama katma değeri olmayan bir işlemdir. RStudio tarafından sağlanan RMarkdown paketi tam da bu işi yapıyor. RStudio ile sıkı entegre çalışan bu paket sayesinde R programı ile analiz raporunu tek bir döküman olarak çalışabiliyorsunuz. Bir işletme işlevi olarak iş analitiği sürecinin bu ve diğer unsurları, ayrıca RMarkdown kullanımı ayrı bir yazıyı hak ediyor.

Burada anlattığım reçete kendi saha deneyimimden yola çıkarak yaptığım bir tercih. Ancak başta söylediğim gibi seçeceğiniz R araç kiti amacınızın ve kullandığınız bağlamın ne olduğuna bağlı. Büyük bir şirketteki 20 kişilik iş analitiği ekibi ile bağımsız bir iş analistinin ihtiyaçları farklı. Hem programlama dillerini hem de araçları seçerken esnek olmak en doğrusu. Kendinizi trendlerle değil sadece kendi hedefiniz ve ihtiyacınızla sınırlayın.