E-KİTAP-2-

EK/2014/578

MAYIS 2014

KURUMSALKAYNAK

PLANLAMASI

978-605-01-0622-0

Yeni

Nes

il ER

P Si

stem

leri

Plan

lam

a Yeniden organisazyo

n

Kurumsal Kaynak Planlaması

Seçim, Planlama ve Kurulum

derleyen: Aydın Bodur

TMMOBElektrik Mühendisleri Odası

1.Baskı, Ankara-Mayıs 2014ISBN:978-605-01-0622-0

EMO Yayın No: EK/2014/578

TMMOB Elektrik Mühendisleri OdasıIhlamur Sokak No:10 Kat:2 06640 Kızılay Ankara

Tel: (312) 425 32 72 Faks: (312) 417 38 18http://www.emo.org.tr E-Posta: emo@emo.org.tr

TMMOBELEKTRİK MÜHENDİSLERİ ODASI

658.0553 KUR 2014 Elektrik Mühendisleri OdasıKurumsal Kaynak Planlama 185 s.:24 cm (EMO Yayın No:EK/2014/578; ISBN: 978-605-01-0622-0 )

Kütüphane Katalog Kartı

DizgiTMMOB Elektrik Mühendisleri Odası

KURUMSALKAYNAK

PLANLAMASI

İçindekiler

Önsöz 1. Giriş 10

2. Tarihsel Perspektif 16 2.1 Yönetim Bilgi Sistemleri (EIS),

İş Zekası (BI) ve veri değeri 2.2 Elektronik Veri Değişimi (EDI) 2.3 Elektronik Ticaretin doğuşu 2.4 Tedarik/Arz Zinciri Yönetimi (SCM) 2.5 Müşteri İlişkileri Yönetimi (CRM) 2.6 Aynı hedefe ilerleme

3. Yeni Nesil ERP Sistemleri 34 3.1 ERP ve kurum uygulama yazılımı 3.2 ERP yazılımlarının özellikleri 3.2.1 Kurulum fazı 3.2.2 On-line faz 3.3 Uyum fazı 3.4 Uygulama işlevleri

4. Sonraki Kuşak, ERP II ve ERP III 44

5. Piyasa Dinamikleri 54 5.1 ERP pazarı yazılım tedarikçileri ve hizmet

sunucularının bulunduğu çalkantılı küresel bir havuz 5.2 Yazılım sunucuları 5.3 Katma Değer Üreten satıcılar, iş ortakları, danışmanlar 5.4 Kullanıcının korunması

6. Başlangıç Gereksinimi 63 6.1 Niçin 6.2 Maliyet 6.3 Doğrulama – maliyet – yarar

7. Gereksinimlerin Tanımlanması 72 7.1 Başlarken 7.2 Gereksinimlerin nasıl karşılanacağı

8. Satıcı/Tedarikçi Seçimi 77 8.1 Tedarikçinin nasıl seçileceğine karar vermek 8.2 Kısa liste metodu

8.2.1 Aşama 1: Kimlerle çalışılacak (ilk listeyi hazırlamak)

8.2.2 Aşama 2: Potansiyel tedarikçi firmalar 8.2.3 Aşama 3: Listeyi en uygun firmalara yer verecek şekilde kısaltmak 8.2.4 Aşama 4: Son seçim

9. Anlaşmayı Sonuçlandırmak 94 9.1 Sözleşme müzakereleri 9.2 Yankılar

10. Kuruluma Giriş 97 10.1 Tarihten dersler

11. Kurulum Metodolojisi 100 11.1 Genel yaklaşım 11.2 Projenin yönetilmesi 11.2.1 Organizasyon 11.2.2 Ölçek/(Faaliyet alanı) 11.2.3 Proje planı 11.2.4 Bütçe 11.2.5 Problem çözümü 11.2.6 Risk değerlendirme 11.2.7 Performans 11.2.8 Tedarikçi firmanın yönetimi 11.3 Sistem konuları 11.4 Eğitim ve eğitim stratejisine gereksinim 11.4.1 Öğrenme amaçlarını tanımlama 11.4.2 İçeriği belirlemek 11.4.3 Plan 11.4.4 Değerlendirme 11.4.5 Gözden geçirme 11.4.6 Maliyet/Bütçe 12. Uygulama 123 12.1 Eğitim stratejisinin uygulanması - faz 1 12.1.1 İçerik-Uygulama işlevselliğini kavramak 12.1.2 Planlama 12.2 Süreçlerin tanımlanması 12.2.1 Teorik iskelet 12.2.2 Toparlama 12.2.3 Şimdi ne yapıldığını anlamak 12.2.4 Hızlı Onarımlar

12.2.5 İş süreçlerinde yeniden kurulum 12.3 Prototip 12.3.1 Konular listesi 12.3.2 Yazılımın modifikasyonu – süreç ile

yazılım fonksiyonlarını uzlaştırmak 12.3.3 Kullanılabilirlik 12.4 Pilot 12.4.1 Hazırlık 12.4.2 Simülasyon 12.4.3 Takip 12.5 Sorumluluklar 12.6 Dokümantasyon 12.6.1 Prosedürler ve iş talimatları 12.6.2 İş tanımları 12.6.3 Raporlar 12.6.4 Kırtasiyecilik 12.7 Eğitim Stratejisinin Uygulanması – 2. faz 12.7.1 Program 12.7.2 Plan 12.7.3 Eğitimin tamamlanması ve değerlendirme 12.7.4 Gözden geçirme 12.8 Veri hazırlama 12.8.1 Verilerin göçü 12.9 Son dakika kontrolü

13. Canlıya Geçiş/Gözden Geçirme 152 13.1 Problemler ve problem çözümleri 13.1.1 Kullanıcı yardım masası 13.1.2 İlk ayın sonu 13.2 Gözden geçirme

14. Kullanıma Devam 155 14.1 Sürekli iyileştirme 14.1.1 Kültürel boyut 14.1.2 Örgütsel öğrenme ve öğrenen örgüt 14.2 Yeni yazılıma karşı terfi (upgrade)

15. Sık Yapılan Hatalar 162 16. Türkiye’deki ERP Yazılım Tedarikçileri 166

Önsöz Bu notlar, Kurumsal Bilgi Yönetim Sistemleri ve süreç mühendisliği alanlarında, özellikle küçük ve orta ölçekli işletmelerde yönetim bilgi sistemlerinin kurulması için çalışanlara, bu sistemlerin arka planını ve tatbiki bilgilerini birlikte vermek amacıyla derlenmiştir. Bir kuruluşta bilgi yönetim sistemleri kurulumunu en iyi şekilde planlamak ve icra etmek hiç kolay değildir. Bu notlar ile bir kurulumun planı verilmeye çalışılmaktadır. Amaç, gereksinimin farkına varılmasından başlayarak kurulumun neleri kapsadığını göstermektir. Tek bir tesis, tek bir işletmenin çalışması üzerine odaklanılmış olsa da konuların çoğu çok yerleşkeli ve çalışma konulu işletmelerle de ilgilidir. Notlar, ERP konusuna ya da ERP’nin kurulumu çalışmalarına daha yeni katılması muhtemel kişilere öğrenmeyi kolaylaştırmak amacıyla derlenmeye çalışılmıştır. ERP konusunda bir şeyler öğrenmeye çalışan bu kişiler, bir patron veya KOBİ müdürü veya büyük bir şirketin yeni atanan proje müdürü de olabileceği gibi, ERP konusunda fikir sahibi olmak isteyen teknik temelli kişiler de olabilir. Türkiye’de 80’lerden sonraki gelişme, daha çok çoğu mühendis teknik temelli kişilerin küçük ölçekli imalathane ve işyerleri açmak suretiyle, işlerini sürdürmeye çalışanların çoğalması şeklinde cereyan etmiştir. Dolayısıyla bu küçük ve orta ölçekli imalathanelerin verimlerini artırmak, daha çok kaynaklarının planlanması ile mümkün olduğu açıktır. Zaten çoğu mühendis kökenli işyeri sahipleri de bu bilinçle ERP’ye ilgi duymaktadır. Bu notlarda ERP kurulumunun ölçek ve kapsamı ile ERP seçim sürecinde tedarikçi firmalara ve seçilen firmanın danışmanlarına kurulum sırasında sorulması gereken konular ele alınmaktadır. Okuyucu, hem teknolojinin hem de pazarın hızlı değişen bir yapıda

6

olduğu konusunda uyarılmaktadır. Okuyucuya karşılaşabileceği potansiyel sorunlar ve onlardan nasıl kaçınabileceği de anlatılmaktadır. Başka kaynaklarda daha derin detay düzeylerinde ele alınan konular, bu kitapta giriş mahiyetinde işlenmiştir. Çok sayıda teknolojik konunun ele alındığı göz önünde tutulmuş ve fazla derine inilmemiştir. Teknik konular yalnızca okurun haberdar edilmesi amacıyla tanıtılmıştır. Notlarda problemlerin çoğu tanımlanmaya çalışılmıştır. Notların sonunda, ERP kurulum sürecinde karşılaşılan temel hatalardan da söz edilmiştir. Her durum farklıdır ve organizasyona ilişkin bir takım özel durumlar hep olacaktır. Ancak sunulan materyaller potansiyel problemlerin belirtilerine karşı okuru uyanık tutmak için yeterlidir. Uygun eylemi seçmek ve yapmak okura kalmıştır. Notlar, ERP kavramının temelini anlatmaya çalışmaktadır. Ancak yeni dönemde hızla gelişen internet ile birlikte, notlarda ERP II ve özellikle bulut teknolojisinin hızla yayılmasıyla birlikte ERP III kavramlarına da yer yer yenilik olarak yer verilmektedir. Notlar, S.Harwood’ın 2003 tarihli ERP Implementation Cycle, kitabı baz alınarak; J.Orlickly, Material Requirements Planning; M.Hammer, Re-En ginering ERP; S.Remenyi, Stop IT Project Failures kitapları ile İnternet Society ve OLAP Report siteleri, http://isc.org ve http://olapreport.com ile başka tedarikçi firma ve teşkilatların web siteleri: http://mcsolutions.co.uk, http://conspectus.com, http://wfmc.org …; G.Meissner, SAP Inside the Secret SW Power; Gartner Inc tarafından hazırlanmış ERP Eğitim Notları gibi kaynaklardan yararlanılarak derlenmiştir. EMO için notların derlenmesinde, S. Harwood’un kitabını 2003 yılında dilimize çeviren Halefşan Sümen’in katkılarını unutmamak gerekir. EMO’nun mühendis ve mühendis adayı okurları için teknik kitapları daha ucuz ve daha kolay erişilebilen e-kitap/pdf formatında kitap uygulamalarını sunduğu kitap portali önemli bir adımdır. Bu notların da ERP ile ilgilenen mühendis ve mühendis adaylarına aktarılması için katkılarından dolayı EMO Yönetimine, Yayın Kuruluna teşekkür, Oda Müdürü Emre Metin'e ve Hakkı Ünlü'ye ederiz. Yayına Hazırlayan Aydın Bodur

7

Başlarken Benzer kitaplarla ilgili güzel şey, bilgi vermeleri, düşünmek için ortam sunmaları ve eleştiri fırsatı yaratmalarıdır. Şirket ne kadar iyi olursa olsun, bazı istisnalar dışında yıllar sonra bile pişmanlıklar yaşanır. Yönetim teorisi, nelerin doğru olduğuna ilişkin olay incelemesi örnekleriyle doludur; ama inceleme konusu olan firmalar, genellikle kendisini krize götüren nedenleri çözerek başarıya ulaşmıştır. Benzer kaynaklarla ilgili temel problem, çıkabilecek tüm problemlere yanıt verememesidir. Bu notlar, hem teori ile hem de gerçek yaşam deneyimleri ile ilgilidir. Bir uygulamada pek çok konu gündeme gelebilir. Bir durum ile ilgili doğru, başka bir durumda yanlış olabilir. Konu bir kurallar setini izlemekten çok neler olup bittiğinden haberdar olmak ve ona uygun davranmak biçimindedir. Sunulan yaklaşım, acı çekilerek edinilen bir deneyimdir. Yaklaşımın çeşitleri bulunabilir. Anahtar mesaj, ERP uygulamasının karmaşıklık ile karakterize edildiğidir. Farkına varılması ve uğraşılması gereken çok sayıda konu bulunmaktadır. Bunların çoğu bu notların da konusu olmuştur. Kuşkusuz az ya da hiç dikkat edilmeyen konular da vardır. Her durum kendine özgüdür. Umut ederiz ki kitabın içeriği okuyucuya ERP uygulamasına ilişkin detayları anlamada yardımcı olur. ERP uygulamasının karmaşıklığı kimsenin, özellikle konuyla ilgili kişilerin beklenmeyeni beklememesidir. Anahtar görevler: nelerin olabileceğini bildirmek, olup bitenler konusunda tetikte olmak, ne kadar önemsiz görünseler de detaylara dikkat etmektir. Faaliyetlerin mantıklı ve proje planı kapsamında, büyük resme uygun biçimde koordineli olarak yapılması zorunludur.

8

ERP uygulaması insanla ilgilidir. Bir bilişim sistemi yalnızca insanlar onu kullandığında değer kazanır. İnsanların konuya dahil edilmesi, sistemin kullanımını garanti etmesi, dolayısıyla değer kazanması için gereklidir. Bu değer, daha ziyade fırsat gibi çıkan problemlerle baltalanır. Pek çok teknik konu çözümlenir. İnsanlara ilişkin problemlerin hepsi sonuç olarak çözümlenebilirse bile, üstesinden gelmek çok daha zordur. Bunun kanıtı nedeni ortaya çıkmamış kısır çekişmeler, tartışmalar ve düşük düzeyli motivasyondur. Politika yapmak veya ego mücadeleleri rahatsızlık verir, negatif etki yapar. Proje lideri, bir diplomat ve kolaylaştırıcı, kalın derili ve gücünü çabuk toparlayandır. Gösteriyi devam ettirmek esastır. Karmaşık yapılı ERP sistemini çalışır duruma getirip canlı kullanıma almak çok keyifli ve kutlanılan bir aşama olsa da işin tamamlanması anlamına gelmez. Bu düzeye ulaşıldığı için tatmin hisleri duymak, yapılması gereken sonraki işlerin önünü kesebileceği için zararlı olmaktadır. Nitekim “teknoloji çöplüğü”, bu aşamaya gelmiş, ancak doyum nedeniyle ERP fonksiyonlarının ya çok azının kullanıldığı, ya da tamamen terk edildiği firmalar için de sarf edilen bir ifadedir. Canlı kullanıma alınıncaya kadar firma, ERP sistemine sürekli yatırım yapmıştır. Firmanın ticari beklentisi, her yatırımda olduğu gibi kar etmektir. Kar, ERP’nin stratejik ve operasyonel yararlarından doğacaktır. Bu yararlar da ancak ve ancak canlıya geçiş anından başlayarak elde edilebilecektir. Kısaca yatırımın kendini geri ödemeye başlaması, eğer yazılım doğru seçilmiş ve kurulmuş ise, iyi kullanım ile gerçekleşebilecektir. Bu hemen kazanılabilecek bir beceri değildir. Her ne kadar yazılıma ilişkin bir eğitim alınmış olsa da hem bu bilgilerin oturması, hem de özümsenmesi için zaman ve çaba gerekmektedir. Literatürde de görülebileceği üzere canlı kullanım dönemi için hemen bütün iyi şirketlerde başarı indeksleri saptanmıştır. Bu indeksler, Kaizen hedefleri haline getirilmekte, periyodik ölçümlerle izlenmekte ve sürekli iyileştirme çalışmalarına konu edilmektedir. Burada önemli nokta, bunları bilmek değil yapabilmektir. Yatırımın karlılığını başka türlü sağlamaya olanak bulunmamaktadır. Canlı kullanım dönemine geçildikten sonra ERP projesinin tamamlanmış olduğunu varsaymak gerçekte önceki dönemlerde sarf edilen onca para ve çabanın çöpe atılması ile eşdeğerdedir. İçinde bulunduğumuz değişim hızında bir sistemin yararlı ömrünün kısalığı dikkate alınırsa -ki ERP sistemleri için bu süre beş yıl olarak öngörülmektedir- firmanın elini ne kadar çabuk tutması gerektiği açıktır.

9

Özetle firma, ERP kullanma becerisini dikine kalkışla artırmayı becermek zorundadır. Bundan sonra envanterler azalacak, döngü zamanları kısalacak, maliyetler düşecek, iş disiplini gelişecek, çalışma ortamı kalitesi yükselecek ve tüm yönetim pratikleri iyileşecektir. Yok edici rekabetin hüküm sürdüğü dönemimizde başka çare yoktur.

10

1 Giriş

Kaynak Planlamaya ilişkin tanım, ERP1, sözcüklerinin baş harfleriyle oluşturulmuştur. Her ne kadar dikkat çekecek kadar kısa bir zaman içinde başka fonksiyonlara ve sektörlere hitap eden bir duruma geldiyse de ERP’nin kökü, aslında imalatta yatar. ERP uygulamasının gerçekleştirilmesi, örgütsel değişim üzerinedir. ERP uygulamasının odağı ise ERP sistemidir. ERP sistemi, basit bir anlatımla işletmenin her yönüne hizmet veren bütünleşik bir enformasyon sistemi olarak tanımlanabilir. Bütün süreçleri, işlemleri ele alır, kayıtlarını tutar, gerçek zamanlı enformasyonu sunar, planlama ve kontrolü kolaylaştırır. Bununla birlikte etkin olması ise, uygulama döngüsünün başarısının sonucudur.

ERP uygulaması, sadece bir enformasyon teknolojisi projesi olarak görülmemelidir. Çok disiplinli bir takım çalışmasıdır. İşletmenin kalbine kadar girer, politikaları, uygulamaları, güç odaklarını tersyüz eder. Kimin güçlü olduğuna bakmadan birçok kişi, grup rahatsız olabilir. Pek çoğu anlık ve bir daha kullanılmayacak da olsa, yetenek setlerinin değişmesini talep eder. Başarılı olunduğu takdirde cömertçe ödüller sunar. İşlemler hızla gerçekleştirilir. Zamanında gelen enformasyon, neler olup bittiğinden haberdar olmayı sağlar. Eylemler daha proaktiftir. Alt düzeyde olumlu anlamda (pozitif) bir geri besleme görülür.

Bununla beraber ERP uygulamasının yanlış gitmesi de bir hayli kolaydır. Zaten işleri yoluna koymak her zaman zordur. Uygulama döngüsü ilerledikçe işlerin halli daha da zorlaşır ve maliyeti de daha yüksek olur. Eldeki tüm araştırma sonuçları ve deneyime karşın uygulama çalışmaları sürpriz şekilde kötü gidebilir, hatta bazı durumlarda iş ciddi yasal mücadelelere varabilir. I.1. Notların kullanımı

Bu notların derlenmesinin amacı, ERP uygulamalarını etkileyen sayısız konunun bulunduğu bir ortamda kılavuzluk yapmaktır. Bunu sağlamak için uygulamanın basit bir modeli geliştirilmiştir. Bu model ERP uygulamasını bir olaylar döngüsü şeklinde görür. Bu döngü, şekil 1.1’de verilmiştir.

1 ERP, Enterprise Resource Planning :Kurumsal Kaynak Planlama

11

Uygulamanın yaşam döngüsü, yeni bir enformasyon sistemine duyulan gereksinimin anlaşılmasıyla başlar. Mevcut sistem uygun değildir ve bir şeyler yapma gereksinimi bulunmaktadır. Pazar farkındalığı, mevcut, elde edilebilir teknolojinin ve bunu sunanların değerlendirilmesini sağlar. Bu da bizi gereksinimi karşılayacak çözümü aradığımız tedarikçinin seçimi sürecine götürür. Çözümün uygulanması, pek çok kişinin işe karıştığı karmaşık bir olay olup, canlı uygulama aşamasına geçişte karmaşa doruğa ulaşır. Canlı uygulama periyoduna geçişten sonra sürekli iyileştirme yönteminin benimsenmesi, sistemin tamamından yararlanmayı sağlar. Sonunda döngü, yeni sistemin uygun olup olmadığının anlaşılması ile sonuçlanır. Artık yeniden bir şeyler yapma gereksinimi belirecektir. Bu döngü içinde farklı faaliyetler yaşanır. Bu döngünün başlıca faaliyetlere göre kırılımı, Tablo I.1’de sunulmuştur.

Figür 1.1 ERP Uygulama Döngüsü

Hikaye, pazarda neler olup bittiği konusunda bir farkındalık geliştirmeye kalkışmak ile başlar. ERP yaşam çevriminin tüm aşamaları ile ilgili olmakla birlikte farkındalık düzeyi, bu pazara dahil olma gereksinimine göre değişir. Açık bir şekilde en kritik aşama, tedarikçi seçim sürecidir. Bununla beraber piyasa, diğer aşamalar süresince de göz ardı edilmemelidir. Yeni sistem için olası gereksinim uyarısı alındığında piyasa, bu gereksinimi kimin doğrulayacağına ilişkin bir referans sağlayacaktır. Canlı uygulama

12

sonrası gözden geçirme dönemleri boyunca satın alınan sisteme dönük dikkatleri çekme çalışması çok ilgi görmez (artık sistem alınmış ve uygulanmıştır!?). Ancak problemler aşılamaz bir hal alırsa, bir tedarikçinin ürününün başka bir satıcınınkine yeğlenmiş olduğu hatırlanacak sistem sorgulanacaktır. Daha sonraları iyileştirme aşaması boyunca, pratiklerin iyileştirilmesine, daha fazla işlevsellik kullanmaya, gerekirse işlevselliği çok artıracak özel yazılımlara ilgi duyulur. Sonuçta zaman içinde uygulama döngüsünün tamamlandığı bir noktaya gelinir: bir şeyler yapma gereksinimi vardır, yazılımı terfi ettirme veya başka bir yazılıma yönelmek üzere dikkatler yeniden piyasada neler olup bittiğine odaklanır.

Notların ilk üç bölümü öncelikli olarak teknolojiyle ilgilidir. ERP’nin gelişimi ilk başlardan başlayarak gözden geçirilmiştir (2. Bölüm). Teknolojinin nasıl evrim geçirdiğini anlayarak elde edilebilir olandan daha iyi yararlanma olanağı geliştirilir (3. Bölüm); önemli konuların nerede olduğu, neye bakmamız gerektiği anlaşılır (4. Bölüm). Bu, bizi neyin gereksiz olduğu konusunda uyarır. Bu, aynı zamanda alımda yapılan abartmalarla, fiilen uygulamada elde edilebilir olanları ayırmamızı da sağlar. Teknolojinin bu kadar karmaşık hale gelmesi ve hızlı değişime hassas olması perspektif kaybını kolaylaştırır. Aşama Odak Faaliyet Notlar

içindeki bölüm/kısım

0) Piyasa farkındalığı

Pazar Pazarda neler olup bittiğini anlamak

2,3,4,5

1) Gereksinimlerin tanımlanması

a) Gereksinimler, b) Maliyet-yarar,

a) Gereksinimleri ve gerekçelerini belirlemek, b) Maliyet ve yararların belirlenmesi,

a) 6.1 b) 7

2) Tedarikçi seçimi

Tedarikçiların ürünleri ve uygunlukları

a) Seçim sürecini belirlemek, b) Seçim sürecini yürütmek, c) Sözleşme hazırlamak ve imzalamak

a) 8.1 b) 8.2 c) 9

3) Projenin yürütülmesi

Projenin yürütülmesi için gereken koşulların hazırlanması ve korunması

a) proje katılımcılarının rollerini tanımlamak ve atamak b) katılımı sağlamak,

a) 11.2.1 b) 11.2.1

13

izlemek ve sürdürülmesini sağlamak, c) kapsamı tanımlamak d) plan hazırlamak, izlemek ve güncellemek e) bütçe hazırlamak, izlemek ve güncellemek f) problem çözümleme mekanizmaları oluşturmak ve yönetmek g) riskleri değerlendirmek ve yönetmek h) performansı sağlamak ve yönetmek i) tedarikçi firma ile ilişkileri yönetmek j) donanım, yazılım ve şebekeyi kurmak ve devreye almak k) eğitim stratejisi geliştirmek

c) 11.2.2 d) 11.2.3 e) 11.2.4 f) 11.2.5 g) 11.2.6 h) 11.2.7 i) 11.2.8 j) 11.3 k) 11.4

Proje planını uygulamak

a)proje ekibini eğitmek b)süreçleri tanımlamak ve geliştirmek c)yazılımı modifiye etmek d)süreçleri test etmek (pilot) e)süreçlere ilişkin sorumlulukları belirlemek ve atamak f)dokümantasyonu tasarımlamak ve oluşturmak g)kullanıcıları eğitmek h)verileri hazırlamak

a)12.1 b)12.2, 12.3 c)12.3.2 d)12.4 e)12.5 f)12.6 g)12.7 h)12.8

Canlı kullanım a)sorunları çözmek b)gözden geçirme

a)13.1 b)13.2

14

4) Canlı kullanıma geçiş sonrası iyileştirmeler

Süreç performansı Süreçleri iyileştirmek 14

Tablo 1.1 ERP Kurulum Döngüsünün Dökümü 5. Bölüm, piyasadaki gelişmelere odaklanmıştır. Burası durmadan değişen, kaygan bir zemin olup, farkında olmayanlara sürprizler yapar. Yerleşik isimler kaybolur. Şirketin iflas etmesi veya başka bir şirket tarafından ele geçirilmesi halinde satın alınan ürünün desteklenmeme tehlikesi bulunmaktadır. ERP uygulamasına yapılan beş yıllık bir yatırım pek çok şeyin olabileceği uzun bir süredir.

Sonraki iki bölüm, ERP’ye duyulan gereksinime ilişkin konulardır. 6. Bölüm, üç kısma ayrılmıştır. Birinci kısım, niçin gereksinim olduğu konusundaki olasılıkları keşfetmektedir. İkinci kısım, maliyet konusunu erken bir aşamada öne çıkartır. Maliyet konusundaki detaylar uygulama döngüsünün son aşamalarına kadar ortaya çıkmamakla birlikte, olası maliyetlerin ve kırılımlarının fark edilmesi, planlamayı ve müzakereleri kolaylaştırmak amacıyla erkenden talep edilir. Benzer şekilde üçüncü kısım, olası yararlar hakkındadır ve önerilen projeyi değerlendirme fırsatı verir. 7. Bölüm, gereksinimlerin ne olduğu ve bu gereksinimlerin nasıl sağlanacağı sorusuna yanıt arar. Bu sürecin bir kısmı gereksinimlerin tanımlanmasını kapsar. Bu konuya farklı yaklaşımlar bulunmakla beraber okuyucu bu sürecin ne olduğunu anlamaya yönelik teorik bir çerçeve ve gerekli verileri toplamaya yönelik bir metot sunan kısım 12.2’ye yönlendirilmektedir.

Bölüm 8 ve 9, tedarikçi seçimi süreci ile ilgili konuları keşfetmektedir. Tedarikçilerin detaylı profillerini önermelerini sunan bir yöntem tanıtılmaktadır. Amaç, gereksinimler ile öneriler arasında iyi bir uyum elde etmektir. Bu aynı zamanda tedarikçi ile iyi bir çalışma ilişkisi geliştirme fırsatıdır. Sözleşmeler değiş tokuş edildikten sonra; ilişkiyi bozmak çok zorlaşmaktadır.

Seçilen ERP yazılımının kurulum aşaması, pek çok kişinin projeye odaklandığı bir dönemdir. Bu aşama, asıl maliyetlerin oluştuğu ve problemlerin kendini gösterdiği dönemdir. Kurulum aşamasında çıkan problemlere ilişkin bir giriş, 10. Bölüm’de sunulmuştur. Sonraki iki bölüm, hazırlık işlemleri olarak nelerin tanımlanacağını keşfetmeye (Bölüm 11), proje fazlarını yürütülmesine (Bölüm 12) ilişkindir. Hazırlık işlemleri, projenin başarıyla yürütülmesi için gerekli koşulların yaratılması ve bakımını kapsar. İcraatın kendisi, iş

15

süreçlerine odaklanan bir seri aktiviteyi kapsar. Bu süreç tasarımı, geliştirme ve test yapma, kullanıcı eğitimleri ve destek malzemelerinin üretilmesini kapsar. Kısım 12.2.1, diğer tüm kısımlardan saparak bir sürecin ne olduğunu anlamaya yönelik teorik bir çerçeve sunmaktadır. Niyet daha derin bir anlayışa sahip olmak, sonra da daha etkin kavranmasını sağlamak ve buna göre eylemler yapmaktır.

13. Bölüm, canlı tatbikata geçiş ile ilgili konuları içermektedir. Bu aşamada beliren çok sayıdaki problem, süreç tasarımı ve geliştirme faaliyetlerinin yansımalarıdır. Süreçler, kendilerinden beklenenleri yapmakta mıdırlar?

Canlı aşamaya geçtikten sonraki bir noktada, süreçlerin oturmalarından sonra başlaması gereken iyileştirme süreci, notların 14.Bölümünde keşfedilmektedir. Bu faz boyunca, pek çok yararın farkına varılır. Bununla beraber sistemin fırsatlar sunmasından çok, engel olarak görüldüğü bir noktaya erişilir. Bundan sonra döngü tamamlanır ve sistemi terfi ettirmek mi, yoksa yeni bir paket aramak mı, soruları sorulur (Kısım 14.2).

Derlenen notlar, anahtar konulara kısaca değinerek tamamlanmaktadır. Aslında notların tamamı, her ne kadar ERP uygulama yaşam döngüsüne ilişkin derin bir bakış açısı vermeye çalışsa da; uygulama gerçeği, kendini karmaşa içinde gösterir. Dahası işler, tüm hazırlıklara ve iyi niyetlere karşın her zaman beklendiği gibi yürümez. Yine de işlerin tamamlanması için çaba harcamaya değer.

16

2. Tarihsel Perspektif

Hikaye, 1960’ların başında veri işleme yeteneğinde ani ve önemli gelişme yapan büyük dev, ana bilgisayarların hizmetine ticari olarak biraz daha kolay erişilebilir olmasıyla başladı. Hemen akabinde de envanter yönetim sistemleri konularında yoğun biçimde kullanılmaya başlandı. İlk uygulama alanı, malzeme listesinin işlenmesiydi. Bu kapsamda gelecekteki malzeme gereksinimlerinin belirlenmesini sağlayacak yazılımlar geliştirildi; Diğer deyişle: bunlar, malzeme siparişi verme ve planlama sistemleriydi. Bu malzeme gereksinimleri planlama2 sistemleriyle ilgili yazılımların kendilerini kullanan şirketler tarafından yazılma eğilimi başlamıştı ve ana bilgisayar tabanlıydılar. 1960’larda IBM bütünleşik üretim ve envanter yönetim kavramını geliştirdi. Bu üretim çizelgesinin malzeme gereksinimlerini yaratması anlamına gelmekteydi. Bu kavram, 1972 yılının başında COPICS3 kara kutusu adıyla yayınlandı. Önemi, bir imalat sistemi için detaylı veri akış yapısına sahip olmasından kaynaklanmaktaydı. Bu özelliğine rağmen o zamanlar MRP sistemleri, sınırlı sayıda A.B.D. firmasında kullanılmaktaydı. 1971 yılında MRP sistemleri APICS4 sponsorluğu ile adeta uçuşa geçti. Bu da 1970’li yıllarda uygulama sayısında hızlı bir artışa yol açtı. MRP daha sonra gelişerek Kapasite Gereksinimleri Planlaması5 ve Satış ve Operasyon Planlama6 konularını da kapsadı. Böylelikle kapalı çevrim MRP ortaya çıktı. 1975 yılında MRP kavramları, Joseph Orlicky’in efsanevi çalışması içinde yayınlandı. MRP, hızla geniş kabul gören ve kullanılan bir üretim aracı haline geldi.

Sonraki büyük adım, 1980’lerin başında atıldı. Malzemelerin planlanması ve kontrolü ile yetinmek yerine; sistemin kapsamı, imalatın tüm kaynaklarını içerecek şekilde genişletildi. Dahası finansman fonksiyonu ile de bütünleştirildi. Böylelikle operasyonel faaliyetlerle, maliyet ilişkileri konusunda farkındalık arttı. Oliver Wright İmalat Kaynakları Planlaması (MRP II)7 terimini kullanarak 2 MRP: Materials Resource Planning 3 COPICS: Communications Oriented Production Information and Control System 4 APICS: American Production and Inventory Control Society 5 CRP: Capacitiy Resource Planning 6 SOP : Sales and Operation Planning 7 MRP II: Manufacturing Resource Planning

17

uygulamanın imalat olduğunu vurguladı. Bilgisayarların maliyetlerinin düşüp performanslarının artması, yazılımların daha kolay elde edilebilir olmalarıyla birleşince uygulanan sistemlerin sayısında hatırı sayılır bir artış yaşandı. Ancak uygulamalar sıklıkla değişiklik gerektirmekteydiler ve sadece temel fonksiyonlar aynı kalıyordu. Yapılan değişiklikler de sonraki versiyonlarda standart hale gelince işlevsellik daha gelişmiş oluyordu. İşlevselliklerin kapsamı 2.1 no’lu şekilde görülmektedir. Maalesef pek çok uygulama, beklentilerle buluşamadı. Bu da uygulamalarla ilgili problemlerin anlaşılmasına ilişkin çalışmaları başlattı. Bununla birlikte pek çok imalat firmasında JIT, OPT, TQM8 gibi tamamlayıcı teknolojilerle birlikte MRP II uygulamaları yerleşti9.

Figür 2.1: MRP II Yapısı 1980’ler aynı zamanda Bilgisayar Bütünleşik İmalat 10 kavramının geliştiği dönemdir. Konunun gerisinde tam otomatik ve bütünleşik fabrika felsefesi yatmaktadır. Donanım ve yazılımdaki gelişmeler ürün tasarımı11 ile imalat ekipmanları12 arasındaki bütünleşmeyi sağladı. Ancak bu uygulama CIM’in yalnızca bir boyutuydu. CIM’in

8 JIT: Just in Time – TQM: Total Quality Management – OPT: Optimum Process Time 9 Don Ralson ve Randall Sadowski tarafından yazılmış pek çok makalede MRP II’nin ortaya çıkmasına ilişkin ayrıntılı bilgiler bulabilirsiniz. 10 CIM – Computer Integrated Manufacturing 11 CAD – Computer Aided Design 12 CAM – Computer Aided Manufacturing

18

algılanmasına ilişkin 10 yol tanımlandı13. Bu yollar, tek bir konu tanımından (örn. CAD/CAM) enformasyon sistemleri tanımlarına kadar (örn. MRP II) sıralanmakta ve tüm tanımları (toplam örgüt) içermekteydi. Her şeyin gerisinde de entegrasyon kavramı yer almaktaydı. Bu entegrasyon, teknolojilere ara yüz geliştirilmesi gereksinimi ve standartların geliştirilmesi çalışmalarıyla kolaylaştırıldı. 1978 yılında Uluslararası Standartlar Birliği, OSI - Açık Standartlar İçbağlantısı14 referans modelini yayınladı. Model her türlü veri iletim standardı geliştirmek için bir iskelet oluşturdu. 1970’lerin sonunda birbirlerinden izole edilmiş pek çok teknolojik birime sahip olan General Motors teknolojik uyumsuzluğun zorluklarıyla ve bunları birbirleriyle iletişir hale getirmenin yüksek maliyetiyle karşı karşıya geldi. Boeing benzer sorunlar yaşadı. 1985 yılında OSI çerçevesine oturan MAP - İmalat Otomasyon Protokolu15 ile Teknik ve Ofis protokollerini yayınladılar. O zamandan bu yana teknolojilerin sorunsuz haberleşmesine olanak sağlayan pek çok gelişme (Örn. Ethernet, Token Ring, SNA, TCP/IP) ortaya çıktı.

1980’lerdeki başka bir gelişme de, süreç/proses doküman ve görüntülerinin toplanmasına, depolanmasına, geri alınmasına ve dağıtılmasına ilişkin, diğer deyişle görüntü ve doküman yönetim sistemleri alanında gerçekleşti. Bunlardan sonra da iş akış yönetimi olarak bilinen konu doğdu. 1990’ların başında iş akış kavramı görüntü ve doküman işlemenin ötesine geçerek, süreç otomasyonu konusunu geniş bir şekilde kapsadı. İş akış yönetimi, İş Akışı Yönetim Ekibi tarafından dokümanların, enformasyonun ve görevlerin tanımlanmış bir kurallar setine göre katılımcılar arasında otomatik prosedürlerle dolaştırılması veya toplam işletme amacına katkıda bulunulması şeklinde tanımlandı. Çok sayıda rutin görevleri yerine getirebilen teknolojik yanı üstün ticari iş akış yazılım paketleri de pazara çıktı. Yüksek maliyetleri, bu yazılım paketlerinin yalnızca bazı büyük organizasyonlar tarafından benimsenmesiyle sınırlı kaldı. 1990’lar boyunca iş akış teknolojisi giderek artan şekilde ERP yazılımlarının bir özeliği haline dönüştü, son olarak da CRM uygulamalarının örneğin çağrı merkezi süreçlerinin tamamlayıcı unsuru oldu. 1990’lar güçlü PC’lerin, istemci-sunucu mimarisinin, hem yerel alan ağlarının hem de geniş alan ağlarının16 yükseliş dönemi oldu. İlk 13 Boaden ve Dayle 14 OSI – Open Standarts Interconnections 15 MAP - Manufacturing Automation Protocol 16 LAN ve WAN: Local Area Networks - Wide Area Networks

19

mikroişlemci 1971 yılında piyasaya sürülmüştü. Moore yasası, bir çip üzerindeki transistor sayısının her iki yılda bir, geometrik olarak arttığını ifade eder. Bu performans artışı ile çip maliyetlerindeki sürekli düşüşün bir araya gelmesi sonucu 1990’lar görece ucuz ve güçlü hesaplama ortamlarının hızla yaygınlaştığı dönem oldu.

Kullanıcıların kabulünü etkileyen bir diğer buluş, sıkıntı verici (itici) metin ekranlarını içeren ara yüzlere karşı, kullanıcı dostu arayüz alternatifi oldu. 1970’lerin sonunda yapılan bir buluş olan GUI - grafik kullanıcı arayüzü17, 1980’lerde Apple tarafından ticari olarak benimsendi. Ancak Microsoft’un 1990 Mayıs’ında Windows 3.0’ı piyasaya sunmasıyla doruğa ulaştı. GUI, halkın bilgisayar teknolojisini benimsemesine ve giderek karmaşıklaşan teknolojileri kullanmasına büyük katkı sağladı.

Ulusal ağ omurgasının gelişmesi ve diğer ağlarla bağlantılı hale gelmesi 1990’ları ortalarında Internet’in patlama yapmasını sağladı (kısım 2.3). Bu da e-mail kullanımında aşırı artışları doğurdu. E-mail (elektronik posta), 1960’lardan beri kullanılıyor olmasına karşın çoğunlukla ana bilgisayar kullanan çeşitli sayıda izole küçük gruplarla sınırlı kalmaktaydı. 1981 yılında Hynes ilk ticari modemi piyasaya sürdü. 1980’ler boyunca kurulan Compuserve, America Online gibi pek çok şirket e-mail de dahil olmak üzere modem üzerinden çevirmeli abonelik hizmetlerini satışa sundular. Bu uygulamalar sonraları Internet kullanarak dünyaya bağlanacak ev kullanıcılarının öncüleri tarafından satın alındılar.

1990 yılında bir A.B.D. şirketi olan ve iş teknolojileri konusunda yönlendirme ve önerilerde bulunan Gartner Inc. “ERP” kısaltmasını ilk defa kullandı. “Gartner Group tarafından geliştirilen sonraki kuşak imalat iş sistemleri ve imalat kaynakları planlama (MRP II) yazılımı. İstemci/Sunucu mimarisi ve grafik kullanıcı arayüzü (GUI) içerir ve açık sistem yapısı ile uyumludur. Sunduğu standart fonksiyonların yanı sıra başka özellikleri de (örn. Kalite, proses işlem yönetimi, periyodik raporlama vs.) haizdir. Ek olarak ERP sistemlerinde kullanılan temel teknoloji kullanıcılara yazılım ve donanım bağımsızlığı verdiği gibi kolay bir yeni versiyonlara geçiş yolu da sunmaktadır. Önemli bir ERP özelliği de kullanıcıların uyarlamalar yapabilmeleri, böylelikle kolay kullanılabilmesidir. (Gartner Inc. Definition: www.gartner.com)

17 GUI: Grafics User Interface

20

MRP II ile ERP arasındaki ana farklılıklar, tartışma konusu olsa da, fonksiyonlardaki önemli değişikliklerden çok teknolojik odak olarak farklılıklar, ileri sürülebilir. Bu konudaki başlıca buluş da istemci/sunucu mimariye geçiş oldu. İşlevsellik perspektifinden bakıldığında, 1990’lar boyunca çok sayıda buluş ortaya çıkmıştır. İlk olarak açıkça tanımlanmış fonksiyonel gereksinimleri hedefleyen özel yazılım paketleri geliştirildi. Bunlar içinde Arz Zinciri Planlama, Ürün Veri Yönetimi ve Müşteri İlişkileri Yönetimi sayılabilir. Aynı zamanda imalat dışı uygulamalar için, hizmet sektörü gibi alanlarda (örneğin varlık yönetimi, saha hizmet desteği vb...), geliştirilen yazılımlar da, pazarda boy gösterdi. Doksanlı yılların ikinci yarısı e-ticaret coşkusu ve e- yapıya geçişin sağlayacağı olanakların ballandırılarak anlatılmasıyla geçildi. Bu kapsamda da bankacılık, sigortacılık ve perakendecilik gibi konularda bağımsız yazılımlar geliştirildi.

Kısım 2.4’te daha ayrıntılı tartışılan Tedarik (ya da arz) Zinciri Planlama, daha az envanter yükü ve daha iyi kaynak kullanımı sağlayacak şekilde, müşteri talebi ile üretim çizelgelerini ve malzeme satın alımlarını daha iyi eşleştirmektedir. Tedarik/arz Zinciri Yönetimi şemsiyesi altında depo yönetimi, nakliye, taşıma ve tedarik konuları da bulunmaktadır.

Ürün Veri Yönetimi18 mühendislik tasarım süreçlerine destek sağlar. Verileri, doğrudan başlangıç kaynağı olan CAD yazılımlarından alır. Tasarım değişikliklerini ve onaylarını, aralarında Internet üzerinden alınan yan sanayici veri tabloları da bulunan tüm ilişkili dokümanları kontrol eder, tasarım geliştirme sürecinin tam tarihçesini sunar. Kısım 2.5 içinde daha detaylı biçimde tartışılan Müşteri İlişkileri Yönetimi19 müşteri ile ilişki kurulan, örneğin; satış, saha servisi, çağrı merkezi ve pazarlama gibi uç işletme faaliyetleri ile ilgilidir.

Uzman “best-of-breed” yazılım paketlerinin geliştirilmesi ile partnerlik ilişkisinin gelişmesi sayesinde, yukarıda belirtilen tedarikçilar ile ERP firmaları arasındaki entegrasyon daha da önemli hale gelmiştir. Bireysel ve pahalı arayüz programcılığından ODBC gibi ara kademe yazılımların kullanımını olanaklı kılan arayüz standartlarına doğru bir kayma görülmüştür. Internet üzerinden bağlantı kurmak için IBM ve Microsoft tarafından

18 PDM - Product Data Management 19 CRM - Customer Relationship Management

21

geliştirilen yeni bir spesifikasyon, Universal, Description, Discovery and Integration kelimelerinin baş harflerinden oluşan UDDI protokolüdür.

Yeni bin yıla girerken ERP tarafından yönetilen işletme uygulama yazılımları üzerinde uzlaşma sağlanamamış karmaşık, ama o kadar entegre olmamış modüller demeti şeklinde bir evrim geçirmektedir.

Sonraki kısımlar ana gelişme konularının beş tanesini detaylı biçimde ele almaktadır. Kısım 2.1 verilerden yararlı enformasyon elde etme fırsatlarını maksimize etme arzusu üzerine odaklanmıştır. Zaman içinde enformasyon sistemleri enformasyonu sakladıkları şeklinde ciddi bir şöhrete sahip olmuşlardır. Bunun üstesinden gelmek amacıyla yapılan çeşitli girişimler çeşitli araçların20 ortaya çıkmasıyla sonuçlanmış olup bu sayede, aranan enformasyonu elde etmek hızla kolaylaşmıştır.

Kalan dört kısım (2.2-2.5) işletme ara yüzlerine ilişkin özel gelişmeleri incelemektedir. Bunların ilki olan EDI, ikincisi e-commerce’in (e-ticaret) öncüsü olarak tanımlanabilir. Her ne kadar bazıları e-ticaret’in EDI’nin yerini aldığını iddia etseler de, e-ticaret alanındaki teknolojik gelişmelerin EDI’ye yeniden hayat verdiği ve şu anda e-ticaret şemsiyesi altında bir olanak sağlayıcı teknoloji konumuna geldiğinin kanıtları bulunmaktadır. Çok lafı edilen e-ticaret’in internet ve world wide web teknolojilerini kullanarak şirketler arası iletişimi destekleyici ve tamamlayıcı yeni bir kanal sağladığı görülmektedir. Üçüncü ve dördüncü gelişmeler SCP ve CRM enformasyon ve iletişim teknolojilerindeki gelişmeler ışığında daha özel olarak yan sanayicilere ve müşterilere odaklanmaktadırlar. 2.1 EIS-Yönetim Bilgi Sistemleri, BI-İş Zekası Sistemleri ve veri değeri

Uzun zamandan beri bilgisayar sistemleri tarafından yakalanan verilerin bir enformasyon kaynağı oldukları bilinmektedir. Ancak sıkça sorulan soru, bunun nasıl olduğudur. Her ne kadar standart raporlar, rutin ve standart sorgulamalar için ideal ise de bir defalık sorgulamalar için uygun olmamakta, normal dışı işlerle gönüllü olarak ilgilenmemekte veya olup bitenlere ilgi göstermemektedirler. Yararlı enformasyon, uzun bir zamandır veri tabanı içinde

20 EIS – Executive Information Systems; BI – Business Inteligence

22

kaybolmaktadır. Ne mutlu ki verilerin potansiyelinden yararlanmayı amaçlayan çeşitli gelişmeler bulunmaktadır.

1970’lerde Karar Destek Sistemleri geliştirildi. Bu araçlar yüksek hacimli verilerin analizini olanaklı kıldılar. Ancak karar destek sistemlerinin sağladıkları enformasyonun yöneticilerin çoğunluğu ad hoc yapıda olan enformasyon gereksinimleriyle bağdaşmadığı ve enformasyon aramada enformel yöntemleri kullandıkları dikkate alındığında başarısız oldukları iddia edilebilir.

1980’li yıllarda EIS – Yönetim Bilgi Sistemleri (Executive Information Systems ya da Management Information Systems) belirdi. Bu yazılımlar, anahtar performans ölçülerine odaklanan işletme yöneticilerine gereken üst düzey bakış açıları sunmak amacıyla geliştirildiler. Kullanıcı dostu olarak adlandırılan yapıda olup, özel koşulların raporlanmasını ve eğilim/trend analizleri yapılmasını sağlamaktaydılar. Veriler çoğunlukla grafik formatta gösterilmekteydi. Belirlenen normlardan bir sapma oluştuğunda uyarılar tetiklenmekteydi. Oluşan sapmalar, ham verilere kadar inilerek detaylarıyla incelenebilmekteydi. Bu yazılım kategorisindeki öncü tedarikçi firmalar olarak “MetaPraxis”, ürünü “Resolve”, “Comshare, ürünü “Commander”, “Pilot executive Software”, ürünü “Pilot” sayılabilir. Genel olarak MIS’lerin sınırlı başarıya ulaştıkları ifade edilebilir.

1993 yılında, OLAP21 – Canlı Analitik Süreçler terimi gündeme geldi. Bunun anlamı ilişkisel veri tabanlarının analiz aracı olmasıydı. OLAP veri toplama, yönetim, işleme ve analiz amaçlı gösterim araçlarını kapsamaktadır. Daha kesin olarak konuşursak bir ürünün OLAP kategorisine girebilmesi için yaratıcısı Dr. Codd’un on iki kuralına uyması gerekmekteyse de, bu kurallara uyma konusunda fazla bir talep olmadı. Kurallar çok boyutlu veri manipülasyonu, istemci/sunucu mimari, esnek raporlama ve çok kullanıcı desteği vb konularını kapsar. İlk OLAP ürünü 1990 yılında COGNOS tarafından pazara sunulan “PowerPlay’dir. O tarihten bu yana pek çok ürün geliştirilmiş bulunmaktadır. Kullanım genel olarak satış analizlerini kapsamaktadır.

1990’ların ortasında hala hüküm süren iki kavram daha geliştirildi: Veri Ambarı ve Veri Madenciliği22. İlk kavram çok sayıda veri tabanlarının birbirleriyle ilişkilendirilmesi ve analizi konusundadır. Aldatıcı derecede basit görünse de mayın tarlasından farksız bir 21 OLAP: Online Analythical Processing 22 Data Warehouse; Data Mining

23

tehdit oluşturur. Karmaşıklık veri tabanlarının yapısından ve onların birbirlerine bağlanmalarından kaynaklanmaktadır. Veri madenciliği, veriler içinde gizlenen ilişkilerin, örüntülerin, eğilimlerin güçlü istatistiksel araçlarla aranması konusundadır.

1989 yılında Gartner Inc. “Business Intelligence; BI, İş Zekası, terimini kullanmaya başladı. Amaç: bir şemsiye kavram olarak BI’i oturtup ve popüler kılarak uç kullanıcıların sayısal enformasyondan değer almalarını sağlamaktı. 1992- 1995 yılları arasında yapılan bazı erken dürtüleri takiben İş Zekası kullanım dışı kaldı. Pek çok tedarikçi yeni ve taze bir şeyler aradılar. “Veri Keşfi; Data Discovery” “Veri Eşeleme; Data Mining” “Enformasyona Erişim”, Veri Kavrama; Data Insight”, “İşletme Kavrayışı” ve benzeri kavramlar belirmeye başladı.

1998 yılında İş Zekası terimi yaygınlaşmaya başladı. İş Zekası, Gartner’ın 1989 yılında öngördüğü gibi 1990’larda daha önce sözü edilen teknolojilerle veri sorgulama uygulamalarını gerektirdi. Bu teknolojiler verilerden değer almada, güçlü yeni yollar doğmasını sağladılar. İş Zekası çözümlerinin kurulumları, teknik uzmanlık gerektirmekte ve pahalı olarak nitelenmektedir. Bununla beraber yalnızca sınırlı bilgiye sahip olan kullanıcıların bile interaktif analiz yapmasına olanak sağladığından; verileri kullanıcı dostu format ve görsel cazibe ile sunduklarından, gerçek zamanlı analiz işlemlerine olanak verip, önceki araçlara kıyasla gecikmeleri yok ettiklerinden ve dahası çok kullanıcılı olduklarından İş Zekası araçları çok tutuldu. Bu kapsamdaki ürünler, ERP firmalarından çok, niş üreticiler tarafından geliştirildiler. Ancak bu araçların sorunsuz bir şekilde, tam uyumla ERP sistemlerine monte edilmelerini sağlayan partnerlik anlaşmalarına da oldukça yüksek sayıda rastlandı. Bu araçlarla ilgili önemli nokta bunların yalnızca ilgili verilere erişmeleri halinde değer yaratabilecekleridir. Kullanıcı ERP sisteminin veri erişim sınırlarından haberdar olmalı, gereksinim duyacağı bazı veri alanlarına erişemeyeceğini bilmelidir. Ancak belki daha önemli olanı verilerin hatalardan arınmış olmaları gerektiğidir. 2.2 Elektronik Veri Değişimi (EDI)

İngiltere Ulusal Ekonomik Gelişim Konseyi EDI’yi şöyle tanımlamıştır:

Yapısal verilerin üzerinde mutabık kalınmış mesaj standartları ile bir bilgisayar sisteminden diğerine elektronik yollardan transferi

24

EDI, 1970 li yıllarda ABD’de rutin işlemlerle ilgili mesajların şirketler arasındaki iletimi için geliştirilmiştir. Alım hızı yavaş olup, şirketten şirkete otomatik işlem transferinin sağladığı yararları şöyle dengelenmiştir: - şirketlerin benimsediği çok sayıda standart ve bu standartların türevleri; üç standart hakim durumdadır: ANSI X12 (ABD), EDIFACT (Avrupa), TRADACOMS (İngiltere) ve - geliştirme için gereken zaman.

Bir şirket kendisini çok sayıda farklı standart kullanan başka şirketlerle işbirliği yaparken bulabilir. Dahası her işlem tipi her iki tarafa da çok fazla iş yükleyebilir. Aynı zamanda şirketlerin kendi enformasyon sistemlerinin gönderdikleri ve aldıkları enformasyon miktarı ile ilgili sınırları bulunmaktadır. Bu arada kontrol edilmemiş verilerin sisteme dahil edilmesi fikri etrafında oluşan bir güvensizlik de söz konusudur. Yine de EDI şirketler arasında sık sık yapılan standart ticari işlemlerin otomatikleşmesinden kaynaklanan bir cazibesi bulunmaktadır. Maliyet etkinliği de elle yapılacak girişlerin hata riski doğurması dikkate alınarak gerçekleştirilen otomatik işlem sayısına bağlı olarak belirlenmektedir. EDI büyük firmalar tarafından daha çok kullanılmaktadır.

Temel prensip, mesajın açıkça tanımlanmış bir formatı olmasıdır. Gerek duyulan veriler, şirketin veri tabanından yüklenmekte, ASCII dosyasına çevrilmekte, sonra iletim için EDI standart formatına dönüştürülmektedir. İletim, VAN -Katma Değerli Ağ üzerinden (örneğin Geis, BT, AT&T gibi firmaların sunduğu) emniyetli bir şekilde gerçekleştirilmektedir. Alınan mesaj yeniden ASCII dosyasına dönüştürülmekte, sonra alıcının veri tabanına yüklenmek üzere, eğer veri tabanına bir ara yüz yaratma konusunda isteksizlik varsa basılmak üzere uygun formata çevrilmektedir. Elektronik bir işlem olduğundan kurallar üzerinde önceden uzlaşma sağlanması gerekmektedir.

Internet’in ortaya çıkması Katma Değerli Ağ sunuculara bir alternatif oluşturmuştur. VAN’ın cazibesi, yedeklenmesi, emniyetli oluşu ve diğer VAN’larla bağlantılı yapısıdır. Ancak iletimin maliyetli oluşu, küçük işletmeler üzerinde caydırıcı etki yapan bir başka etken olmaktadır. Internet-EDI teknolojisi, geleneksel EDI mesajlarını kullanmakla beraber kriptolayıp halka açık şebeke üzerinden iletmekte, ya e-mail veya dosya transfer protokolünü23 kullanmaktadır. Bir güçlük, maliyeti geleneksel EDI’den çok daha az

23 FTP: File Transmission Protocol

25

olsa bile aynı teknolojinin iletim hattının sonunda da olması gerektiğidir. Internet geleneksel EDI’nin yavaşlığı dikkate alındığında gerçek zamanlı işlem yeteneği sunmaktadır. Aynı zamanda geliştirme maliyeti ve süresi önemli ölçüde azaldığından partner firma sayısının çok sayıda olmasına yol açmaktadır. Ancak kriptolamanın emniyetli olup olmadığı tartışma konusudur. Internet –EDI teknolojisi halen geliştirilmekte olup gelecekte oynayacağı rol açık değildir. Gerçek veya hayali de olsa güvenlik konusunun üstesinden gelinmesi gerekmektedir. EDI’ye alternatif olan web portalleri EDI’yi yerinden oynatabilecektir. Ancak gelecek ne olursa olsun bugün EDI elektronik ticaretin bir alt kümesi olarak görülmektedir. 2.3 Elektronik Ticaretin doğuşu

Yeni buluşlar, 1960’lardan bu yana çalışanlara yeni kapılar açmaktadır. Bilgisayarların birbirleriyle nasıl haberleşeceklerine ilişkin çeşitli araştırmalar yapılmıştır. Sonuçta çok sayıda ABD üniversitesini birleştiren ve ilk bilgisayar ağı olan ARPANET ortaya çıkmıştır. 1970’ler boyunca daha çok üniversite dahil olduğundan ARPANET büyüme göstermiştir. Teknoloji evrim geçirdikçe bir standart olan TCP/IP24 gelişmiştir. Bu farklı teknolojilerin birbirlerine ve diğer ağlarla bağlanmayı kolaylaştırmaktadır. İlk ağlar öncelikle akademik kurumları ve devlet dairelerini bir araya getirse de ticari potansiyelleri hemen dikkat çekti. Özel organizasyonlar mevcut altyapıya kendi ağlarını bağladılar.. 1980’lerde bağlı bilgisayar sayısı 1000’den 100.000’e yükseldi. Başlangıç uygulamaları elektronik posta, dosya paylaşımı ve uzaktan erişim idi. 1992 yılında bağlı bilgisayar sayısı bir milyona, 1995’de beş milyona, 2000 yılında da yüz milyona çıktı. 1990’larda gerçekleşen Internet’in benimsenme patlamasına başlıca katkılardan biri de World Wide Web; WWW’in icadı oldu. 1989 yılında CERN’de çalışan Tim Berners-Lee hipertekst tabanlı enformasyon geri alma sisteminin tarayıcı arayüzü olarak kullanılmasını önerdi. Amaç enformasyona erişimi iyileştirmek idi. Sonraki yıl yaptığı çalışmalarla işlevsel bir sistem geliştirdi. 1992 yılında CERN tarayıcıyı, bedelsiz/freeware olarak dağıtmaya başladı. Tarayıcı konsepti diğer insanları cezbederek başka tarayıcıların da yaratılmasını sağladı. 1994 yılında Netscape, lider firma idi. Tarayıcılar benimsenme ve kullanma kolaylığı sayesinde patlama yaptılar ve orijinal ismini Tim Berners-Lee’nin projesinden 24 TCP-IP : Transmission Control Protocol/Internet Protocol

26

alarak World Wide Web olarak refere edilir oldular. Elektronik postaya ek olarak kullanıcılar geniş bir yelpazedeki sitelere erişme ve enformasyon yükleme olanağı buldular.

On-line olan kullanıcıların potansiyel müşteriler olduğu yönünde bir tahmin ortaya atıldı. Bu tahmin, bu müşterilerin katalogları aramalarına, seçim yapmalarına ve ürün ve hizmetleri satın alıp kredi kartlarıyla ödeme yapmalarına ilişkin on-line kolaylıklar geliştirilmesine kadar vardı. Güvenlik konusundaki kuşkulara ve dolandırma potansiyeline karşın bu yapı çok tuttu. Müşterilere bu kolay erişim yeni bir ticari anlayış olarak, işletmeden müşteriye vizyonunu25, doğurdu. 1996 - 1998 yılları arasında .com türü işletmelerin kuruluşunda patlama yaşandı. Çok sayıda milyoner yarattıysa da, patlama fazla uzun sürmedi. İşin çökmesinde çok sayıda etken, öncülük etti. Bu işletmeler, potansiyel müşteri talebine ilişkin çok yoğun beklenti içindeydiler ancak maliyetleri karşılayacak cirolara erişemediler. Daha bu işletmelerin pek çoğu talebi karşılayacak sağlamlıkta bir altyapı geliştiremediler ve işlemleri de başarıyla tamamlayamadılar. 2000 yılında hem yatırımcıların güveni, hem de aralarında Boo.com gibi yüksek profilli olanların bulunduğu bu sanal işletmelerin çoğu yıkıldı. Kolay para saplantısı, emniyetli şirkete geri dönüş ile yer değiştirdi. Böylelikle bir süre içinde birçok işletme de, yeni ve sürekli yenilenen mecralar oluşturdular ve devamlılıklarını sağladılar.

Ancak aynı zamanda B2C alanındaki gelişmeler, yeni bir ortamda şirketten şirkete B2B26 ticaret için fırsatlar sunmuştu. İlgilenen şirketlerin çoğu yapı malzemeleri satan şirketlerdi. Web ortamındaki varlıkları bir örüntü/patern izler gibiydi. Başlangıçta ziyaretçilerin enformasyon aradığı bir web sitesi şeklindeydiler. Sonraki gelişmeler, kendi tarayıcılarını kullanarak, satış siparişleri vermelerine yol açtı. Şirketin kendi çalışanları, şirket müşterileri, kayıtlı ziyaretçiler, genel ziyaretçiler gibi farklı kullanıcı sınıfları oluştu. Sadece şirketlerin kendi çalışanlarına erişim olanağı veren intranetler geliştirildi, sonrasında dış kullanıcılara sınırlı erişim sunan ekstranetler kuruldu. Bütün bunlar web yeteneği olan ERP’lerin geliştirilmesine, SCM ve CRM uygulamalarına öncülük etti. e- tedarik ve e-ticaret iş bağlamı, İntranet kapsamı dışına çıkarak WWW ortamına, e-uzaya taşındı. Bu da müşteriler ve tedarikçilerin EDI, e-posta ve video konferans sistemleri ile iletişimlerini birleştirdi. Bütün bunların etkisi genelde değişim, bazı 25 B2C – Business to Customer 26 B2B – Business to Business

27

hallerde devrim şeklinde oluştu. Birbirleriyle doğrudan temas kurmaya ek olarak, sanal ticari değiş-tokuşların yapıldığı e-pazaryerleri doğdu. Bunlar yeni olmasa da (Londra borsası 1986 yılında bu yapıyla doğmuştu) doğrudan temasa bir alternatif oluşturdu. Müşteri ve tedarikçinin küçük komisyonlarla buluştuğu sanal ortamlar doğdu. Bu alanda gereğinden çok ortam kurulduysa da, büyük kısmı varlıklarını sürdürecek kadar faaliyet göstermeyi başarıyla sürdürmekte. B2C ile birlikte B2B’nin yaygınlaşması da pek çok şirketin kendisini bu alana açmaması nedeniyle beklenenin çok altında kaldı.

Uygulamanın B2B, B2C veya e-pazaryeri olmasından bağımsız olarak ticari e-uzay ortamlarının sunduğu fırsatlar, fazla gelişmemiş bulunmakta ve bu alanda çoğu pahalı birtakım hatalar yapılmaktadır. Teknolojinin kendi yolunu bulacağı gerçeği kolayca unutulmaktadır. e-tedarik ve e-ticaret geniş kapsamda yeni felsefeler ve kendi özel kurallarıyla yeni iş yapış şekilleri olarak tanımlanmaktadır. Belki de bu bir hayaldir!

Internet ve WWW müşterilerle tedarikçiler arasında çok güçlü ve küçümsenemeyecek bir kanal oluştururken yeni uygulamaların sonuçlarının işletmelerin yönetilmeleri gereken yeni iş kuralları olduğu hatasına düşülmemelidir. Kurallar değişmemiştir. İşletmeler güçlü stratejiler, finansal kontrol, operasyonel ve lojistik verimlilikler üzerine kurulmalıdırlar. Kar ve zarar, nakit akışı ve bilanço, anahtar ölçülerdir. Görece başarılı .com firmalarının (Amazon, Yahoo, Alibaba vb.) bu gerçeği kabul ettikleri görülmektedir. e-uzayda faaliyet gösteren ister B2C ister B2B olsun, geleneksel harç ve tuğla şirketlerin sağlam altyapıları, bu yeni kanaldaki yeni fırsatlardan yararlanmayı desteklemelidir. Bu yeni kanal yeni ve belki de köklü değişiklik gerektiren pratiklerin, örneğin çağrı merkezlerinin (call center) artmasını getirecektir. Bunlar aynı zamanda tamamlayıcı nitelikte olup geleneksel kanallarla yer değiştirme anlamına gelmeyecektir.

Bu yeni kanalın gelişiminin desteklenmesi ilgili süreçlerin anlaşılmasına bağlıdır. Bu süreçlere ilişkin süreçler, her ne kadar e- takısı ile başlasa da anlaşılmaları, tasarım ve uygulamaları diğer süreçlerden farksızdır. Yine de bu kanalın kavranması gereken, kendine özgü karakteristikleri bulunmaktadır. Bunlar hız, erişim ve görünürlüktür. İşlemler geleneksel araçlara kıyasla Internet üzerinden daha hızlı yapılabilmektedir. Yanıtların da uygun ve zamanında olması önemlidir. Internet global olarak bağlanan herkese açıktır. Bir siteye aniden yığınla kişinin üşüşmesi

28

çökmesine yol açacaktır (ancak bunlara da göreceli çözümler geliştirildi). Internet üzerindeki işlemler verimsizliklere karşı daha savunmasızdır. Problemler yaşandıkça ziyaretçilerde kötü izlenimler doğmakta, bu da onları geri dönüş yapmaktan alıkoymaktadır. Bu da e-ticaret teknolojilerinin kullanılması yönünde büyük baskı oluşturmaktadır.

Ancak giderek büyüyen başka bir boyut daha bulunmaktadır. Bu boyut e-ticaret kanallarının performansı ile daha az, Internet ve e-ticaret kullanımındaki davranışlarla daha çok ilgilidir. Computer Weekly dergisinde yayınlanan ilginç bir makalede davranışlarla ilgili dört başlık vurgulanmaktadır, bunlar; güvenlik, hukuksal, entelektüel sermaye ve mahremiyettir. Güvenlikle ilgili konulardan daha önce söz edilmişti. Hukuksal açıdan konular uluslararası uyumdan yasal dolandırıcılıklara ilişkin ulusal yargılama yetkilerine kadar uzanmaktadır. Entelektüel sermaye tartışmaları domain isimleri sahipliği üzerine oturmuş olmakla birlikte web sitesi içeriklerinin telif hakları ile de ilgilidir. Mahremiyet kullanıcı sistemlerine cookie adı verilen yazılımların yerleştirilmesi web sitesi ziyaretlerinde doldurulan formlardan elde edilen kişisel bilgilerin başka kişilere aktarılması, istenmeyen mektupların yollanması gibi konuları kapsamaktadır. Davranışsal boyuttaki gelişmelerin yavaş olduğu e-ticarete duyulan güveni baltaladığı görülmektedir. Bu alanın nasıl gelişeceğini, bize zaman söyleyecektir. 2.4 Tedarik/Arz Zinciri Yönetimi (SCM27)

MRP nelerin satın alınması ve ne zaman teslim edilmelerine ilişkin bilgilere olan gereksinimle büyüdü. Ancak bu konu müşteriden başlayan pek çok değişkene bağlıydı. Müşteri ne istiyor ve ne zaman istiyor? Dahası müşteriler vefasız, fikir değiştiren siparişlerini değiştiren veya farklı bir şey sipariş eden kişiler olarak bilinirler. Eğer çok sayıda müşteri bu şekilde davranırsa ve hammadde satın alımlarını da müşteri teslim tarihlerini tutturmayı hedefleyen imalat ile uyumlu kılmaya uğraşılırsa, iş bir kabusa dönüşür. Dikkate alınması gereken değişkenler, üretim kapasitesi, makina kullanılabilirliği, tedarik ve üretim ön süreleri, ürün ağacı yapısı, eldeki hammadde ve ürün stok değerlerini kapsar. Amaç her zaman minimum stok tutarak müşteri talebini karşılamaktır. MRP, MRP II ve ERP bu alanda yalnızca sınırlı çözüm sağladılar.

27 SCM: Supply chain management

29

Arz ile talep dengeleme problemlerinin anlaşılmasına yönelik olarak 1980’lerde çeşitli uygulamalar ortaya çıktı. Satış ve Operasyon planlama arz ve talep arasındaki karşılaştırmaya yukarıdan bir bakış atma olanağı sağladı. Tam Zamanında [:JIT] teslimler kart/kutu sistemi üzerine kuruldu. Bu sistem hangi mallara gereksinim bulunduğunu göstermekte ve bu malların tedarikçinın anlaşmaya dayanarak bulundurduğu stoklardan sevkini bir çağrı ile tetiklemektedir. Ürün geliştirme tasarım aşamasında, tedarikçiler ile müşteriler arasında işbirliği yapılması düşüncesini benimsemiştir. Bu aşamada yapılan uzmanlık paylaşımı hem tasarım maliyetlerinin bir kısmının dışarıya atılmasını sağlayacak hem de komponent havuzunun hacmini azaltıp, ölçek ekonomileri yaratacak şekilde standart parçalar geliştirilmesine olanak verecektir.

Planlamanın karmaşıklığı ile başa çıkma temel işi, tedarikçiler (örneğin; i2, Manugistics ve Preactor) için uzman planlama ürünleri yaratma fırsatı doğurmuştur. Bu ürünler, müşteri tahminlerini ve talebi, kapasiteyi ve kullanılabilirliği içerecek şekilde operasyonel kısıtları dikkate alarak üretim çizelgeleri ve satın alma gereksinimleri üretmektedir. Bu güçlü modelleme araçları, Tedarik/Arz Zincir Planlama ve İleri Planlama Sistemleri adlarıyla sunulmaktadır. Her ikisi arasında bir fark olup olmadığı tartışmaya açık bir konudur. Tüm gelişmişliklerine karşın bu planlama araçları tahmin yapma açısından zayıftırlar. İyimser veya kötümser tahmin perakendeciden distribütöre geçmekte ve arz zinciri içinde geriye doğru iletildiğinde, amplifiye olabilmekte envanter ve kullanılabilirlik üzerinde arzu edilmeyen etkiler yaratabilmektedir.

Başka fonksiyonel gelişmeler de belirmiştir. MRO - Bakım, Onarım ve Elden Geçirme28 çok sayıda parça numarasını, her parçadan küçük miktarlarda ve çok sayıdaki tedarikçiyi ekipmanların bakımlarıyla ilişkilendirerek yönetebilmektedir. Farklı envanter gereksinimleri, bunlar ister hub’larda, ister çok mekanlı depolarda, isterse aynı lokasyondaki farklı hesaplarda olsun, yönetilebilmektedir. Yeniden sipariş verme sistemleri de kontrol altında tutulabilmektedir. Nakliye sistemleri taşıma çizelgelerini, araçlar üzerinde transit halde bulunan malların gerçek zamanlı izlenmesini de kapsamaktadır. Internet, self-servis satın alma yapılabilen sitelerin ve alıcı ile tedarikçinin buluşup ticaret yaptığı, on-line mezatların gelişimini hızlandırdı.

28 MRO - Maintenance, Repair and Overhaul

30

Bir bütün olarak teklif verme modülü, arz zinciri yönetimi kavramı ile ilgili uygulamalara oldukça büyük destek vermektedir. Bu arada Tedarik Zinciri Planlama ile Tedarik Zinciri Yönetimi kavramlarının literatürde birbirlerinin yerlerine kullanıldığının da farkında olunması gerekir. Tedarik Zincir Planlama, planlama ile ilgilidir. Tedarik Zinciri Yönetimi, arz zincirine ilişkin tüm faaliyetleri içerir. Bunlar arasında tedarikçi seçimi, müzakere, ilişkiler ve performans da bulunur. Planlamaya, tedarik faaliyetine, teslim süreçlerine ve personel yönetimi ile eğitimlerine de yer bulunur. Tedarikçinin sahip olduğu tampon stoklar, tesislerdeki envanter düzeyleri, tesis dışında bulunan depoların yönetimi, nakliyenin etkin biçimde yapılması ve transit malların izlenmesi de yine yönetilen konular arasında yer almaktadır. Diğer konular; gümrük, ithalat dokümantasyonu ve döviz yönetimidir. Gerçek bir tedarik/arz zinciri uygulama yazılımı tüm bu konuları desteklemektedir. 2.5 Müşteri İlişkileri Yönetimi

Her ne kadar müşteri ilişkilerinin yönetilmesi yeni bir kavram değilse de 1998 yılı civarında bu konuya ilişkin her şeyi kapsayan bir kavram doğdu: “CRM - Müşteri İlişkileri Yönetimi29”. CRM’in bir dikkat çeken özelliği gelir yaratan faaliyetlere odaklanmış olmasıdır. Bu özellik ERP’nin daha geleneksel olarak odaklandığı işlemler ve işlemlerin iyileştirilip yararlarının artırılarak iş yapma maliyeti üzerindeki etkileri konuları ile çelişir.

CRM’in ortaya çıkması satış ve pazarlama alanlarındaki çok sayıda gelişmenin sonucudur. Bir yandan da teknolojik gelişmeler de devam etmektedir. MRP II, ERP sistemlerinin imalata ve ilişkili faaliyetlere odaklanıp, büyümekte olan satış ve pazarlama fonksiyonlarına olan gereksinimi karşılamakta yetersiz kaldığı giderek artan biçimde fark edilmekteydi. Müşteri temas yönetimi, ürün ve fiyat listeleri ve doğrudan pazarlama geliştirilen ilk fonksiyonlar arasında yer almaktaydı. Sonraki eklemeler arasında kampanya yönetimi, çağrı merkezi hizmetleri ve pazar istihbarat yönetimi yer aldı. Anahtar teknolojik konulardan biri farklı teknolojilerin entegrasyonu idi: veri tabanları, laptop’lar, mobil telefonlar, istemci/sunucu, bilgisayar-telefon vs. Internet yeni kanalları da üretti. e-mail ve portal’ler. Teknolojik bariyerlerin kaldırılmasıyla enformasyonun dünyanın her yerinden anında elde edilebilmesi olanağı doğdu. Ancak ana

29 CRM: Customer relations management

31

konulardan bir tanesi güvenlik oldu. Emniyet altına alınmamış kanallar müdahale ve sızma olanağı verdi. Geliştirilen çözümlerden bir tanesi kriptolama/kodlama’dır.

Aynı zaman diliminde daha fazla müşteri odaklı olmaya duyulan gereksinme büyüme göstermekteydi. Daha iyi uygulamalar ve daha büyük etkinlikler teknolojik gelişmelerle olanaklı kılınan araştırmaların konularıydı. Veri analizleri müşteri profillerinin daha iyi biçimde çıkarılmasına izin vermekte, böylelikle müşteriler daha verimli biçimde hedeflenmekteydiler. Uzak mekanlardan yapılan on-line veri girişleri müşteri enformasyonunu iyileştirmekte, böylelikle müşterilere erişim için daha verimli yollar geliştirmeyi olanaklı kılmaktaydı. Çağrı merkezlerinin geliştirilmesi, 24 saat müşteri desteği vermeyi olanaklı kılmıştı. On-line veri erişimi, müşterileri hesaplarının ve siparişlerinin cari durumlarını görmelerine olanak sağlamıştı. Lojistik teknolojisindeki gelişmeler, ürün takiplerinin daha iyi yapılabilmesini, böylelikle teslimle ilgili sorunların farkına erkenden varılmasını sağlamıştı. Varsayım, daha iyi bilgi sahibi olup, müşterilerin daha iyi tatmin edilmesidir.

O halde CRM nedir? Gartner Inc. CRM’i şöyle tanımlamaktadır:

Müşteri segmentlerine göre organize edilen, müşteri tatmini için yapılan davranışları teşvik eden ve müşteri merkezli süreçleri kullandıran, çıktısı karlılığı, gelirleri ve müşteri tatminini, optimize eden bir işletme stratejisi.

Bu tanım teknolojiden söz etmemektedir. Bir sonraki cümle ise şöyledir:

Tanım olarak CRM teknolojileri, müşterilerin daha iyi anlaşılmasını, müşteri erişiminin artmasını, müşterilerle daha etkin etkileşimleri ve tüm müşteri kanalları ile şirket arka ofisinin fonksiyonlarını entegre etmeyi olanaklı kılar.

Gartner Inc. CRM ile olanak sağlayan teknolojileri birbirlerinden ayırt etse de popüler dilde CRM ikisinin birlikteliği anlamında kullanılmaktadır.

CRM, geçmiş, şimdiki ve gelecekteki müşterilerle olan etkileşimi yönetme amacıyla geliştirilen ve uygulanan bir strateji olarak tanımlanabilir. Potansiyel Pazar tanımlarından müşteri sadakatinin korunmasına kadar tüm müşteri yönelimli faaliyetleri kapsar. Teknoloji kullanılarak gerçekleştirilir, veri yakalama ve analizi, enformasyon üretimi ve dağıtımı ile müşteri yönelimi ile ilgili faaliyetleri içerir. Şekil 2.2 CRM’in elemanlarını modellemektedir. Modelde bir merkezi veri tabanı, farklı etkileşim kanalları ve ERP

32

sistemi ile bütünleşme tanımlanmıştır. Farklı katılımcılar ve bu katılımcıları yönetme araçları bulunmaktadır. Son olarak müşteri ile yapılan hesap yönetimi, fırsat değerlendirme gibi işlerdeki farklı vurgular birbirlerinden ayırt edilmiştir.

CRM yolunu izlemenin çok sayıda potansiyel yararı bulunmaktadır. Artan otomasyon araçları mevcut kaynakların daha iyi kullanımını, enformasyonun daha kaliteli olmasını, daha kısa sürelerde yanıt vermeyi, müşterileri daha iyi hedeflemeyi, müşterileri daha iyi elde tutmayı ve satışların artırılmasını kolaylaştırılmaktadır. Ancak CRM sisteminin kurulumu “kolay değil” olarak tanımlanmakta ve beklentiler seyrek olarak karşılanmaktadır. Başarısızlık nedenleri olarak aşırı beklentiler, CRM’in ne olduğunu anlama eksikliği, CRM’in işletme çözümü olduğu değil, yanlış şekilde teknik bir çözüm olduğu inancı, gereksinimlerin zayıf şekilde tanımlanması, gerekli verilerin yakalanamaması ve erişilebilir olmaması, kurum içi destek yokluğu, şirket içi politikalar ve çalışanlara gereken dikkatin gösterilmemesi sayılabilir. Bununla birlikte teknolojinin varlığı tedarikçilerin müşterileri hakkında her şeyi bilmelerine olanak verse de, bunun eski “müşterini bil” deyişine göre yapılıp yapılmadığını izlemek gerekmektedir.

33

34

2.6 Aynı hedefe ilerleme

ERP, İş Zekası, EDI, e-ticaret, SCP ve CRM konularında gerçekleşen en son gelişmelere paralel bir şekilde evrim geçirmektedir. Her ne kadar her birinin kendi odaklandığı alanlar varsa da aralarında büyüyen bir tamamlanma vardır. Bu gelecekteki müşterileri düşünürken yalnızca üretim sistemini düşünmenin yeterli olmayacağının anlaşılmasından kaynaklanmaktadır. Gerçekte üretim tamamen yok olabilir ve hizmet yönelimli faaliyetler, çekirdek işletme faaliyetlerini oluşturabilir. Dahası müşteri firmalar müşteri ve tedarikçi ilişkilerini güçlendiren işlevsellikleri dikkate alabilir. Dikkatleri Internet’in sunduğu fırsatlara yönelmiş olabilir. Ayrıca neler olup bittiğini daha iyi anlamak için verilerin nasıl kullanılması gerektiği konusunu önemseyebilir. Bunu fark eden tedarikçiler ürünlerini bu gereksinimleri karşılayacak şekilde geliştirmektedirler. Her ne kadar bazı özel ürünlerin gücü geleneksel alanlardan gelmekteyse de partnerlerden temin edilen diğer işlevsellik veya entegrasyon da sunularak bir “komple çözüm”e ulaşılmaktadır. ERP firmaları CRM ve SCP tedarikçilerinin alanlarına uzansalar da aynı şekilde bu tedarikçiler de ERP firmalarının alanlarına girmektedirler. Sonuçta ERP, çok geniş bir işletme uygulama yazılım ürünlerinin erime potası haline gelmiştir.

35

3 Yeni Nesil ERP Sistemleri 3.1 ERP veya kurum uygulama yazılımı Bu notların asıl odağı, ERP yazılım kategorisidir; ancak ERP’yi incelediğimizde onun köklerini oluşturan MRP’nin, Malzeme Gereksinimleri Planlamasının çok ötesine uzandığını görürüz. ERP, hem verileri yönetme, hem de yazılımın uygulanması bağlamında genişleme göstermiştir. Uygulamalar, imalatın çok ötesinde tüm endüstriyel faaliyetleri kapsayacak şekilde genişlemiştir. Dahası ERP, hem müşteri ile ilgili konulara, hem de arz zinciri süreçlerine hitap eder olmuş, ancak bu çok temel düzeyde kaldığından SCP (Kısım 2.4) ve CRM (Kısım 2.5) kategorilerinde özel ürünler sunan yazılım geliştiricilerin özellikle dar pazarlarda ortaya çıkmasının önüne geçememiştir. Buna tepki olarak ERP tedarikçileri kendi sunumlarını bütünleşik çözümler olarak geliştirmişlerdir. Teknolojik ilerlemeler satıcıların ERP’nin desteklediği işlevsellik ve ara yüz sınırlarını daha ötelere itmelerine olanak sağlamıştır. World Wide Web’in ortaya çıkışı özellikle insanların uzak yerlerden etkileşimi için yeni kanallar açmak suretiyle yeni fırsatlar yaratmıştır. Yeni ticari boyut kazanan Kablosuz Uygulama Protokolü30, seyahat halindeyken ERP’ye erişim potansiyeli sunmaktadır31. Sonuçta ortaya herhangi bir uygulama yazılımını kurum içine yönlendiren teknoloji özellikli bir yazılım süiti çıkmıştır. Bu oluşumun modeli şekil 3.1’de sunulmuştur.

İşletme Stratejisi Arz Zinciri Yönetimi Tedarik Tedarikçi arayüzü Lojistik/dağıtım Ambar Nakliye Planlama

Şirket Yönetimi Araştırma & Geliştirme Ürün geliştirme/ operasyon tasarımı Üretim planlama ve kontrol Envanter ve varlık yönetimi Finansal yönetim İnsan kaynakları yönetimi

Müşteri Yönetimi Pazar istihbaratı Satış yönetimi Müşteri Arayüzü Self servis Müşteri özeni Çağrı merkezi Uyarlama

e-ticaret stratejisi

30 WAP: Wireless Application Protocol 31 WAP ötesinde bulut uygulamalarla, bilgisayarların mobilizasyonu en üst dereceye kadar çıkmıştır.

36

Olanak sağlayan teknolojiler Şebeke - Internet/e-mail - Kablosuz teknoloji - dijital video Masaüstü - Dizüstü/Palm - Mobil telefon - iş akışı Veri tabanı - İş Zekası

Figür 3.1 Kurumsal Uygulama Yazılımlarına bir örnek

Madem ki yazılım uygulamalarının kapsamı, tüm kurumdur; bunun organizasyon üzerindeki etkisi hakkında sorular sormak mümkündür. İşletme varlığını sürdürecekse bütünleşik bir enformasyon sistemine sahip olmasının zorunluluk olduğu ileri sürülebilir. Eğer durum böyle ise her rakip, potansiyel olarak diğer rakiplerle aynı sisteme sahip olacağından herhangi bir rekabet avantajı olmayacak mıdır?

Asıl mesele kurumun bir rakibi diğerinden ayıran uygulamayı nasıl benimsediği ve kullandığı ile ilgilidir. Bu durumda uygulama yazılımı, işletme stratejisinin uygulanmasını kolaylaştıran bir araç olarak görülmektedir. İşletme stratejisi, işletmenin nereye gittiğini, oraya nasıl ve ne zaman gideceğini tanımlar. Eğer teknoloji, bir olanak sağlayıcı olarak görülürse, işletme stratejisinin de kendi içinde ilgili teknolojilerin benimsenmesi ve geliştirilmesi için bir strateji barındırması gerekir. Rakipler arasındaki farklılaşma ve rekabet avantajı, iki faktör üzerine oturur. İlk önce uygulamayı kullanarak kazanılan liderlik söz konusudur, bu da uygulamanın benimsenme hızını vurgular. İkincisi işletmenin uygulamayı kullanma yeteneğidir. Bu da işletmenin buluşçu kullanımlar yapacak yaratıcı yeteneği üzerine kurulur. Buluşçu (ya da yenilenmeci) kullanım, rekabet avantajı yaratabilir. Rekabet avantajının kullanımlarına örnekler özellikle e-ticaretin yaygınlaştığı yakın dönemlerde bolca görülmüştür. 3.2 ERP yazılımlarının özellikleri

Bir ERP sistemi, yalnızca içine biraz program katılmış veritabanı değildir. Farklı sistemlere bakıldığında açıkça görülen konu, satıcıların kendi teknolojilerini farklı yollarla geliştirmiş olduklarıdır. ERP yalnızca işletme süreçleriyle uğraşmaz, aynı zamanda başka şeyler de sunar:

• enformasyona iyileştirilmiş ve hızlı erişim • süreç modelleme ve dokümantasyon da dahil olmak üzere,

kurulumun her alanına destek, • eğitim ve yazılım geliştirmeyi destekleyici araçlar.

37

Şekil 3.2 bir ERP sistemi ile ilgili çeşitli yazılım özelliklerini göstermektedir. Bu özellikler ERP kurulumunun üç ayrı fazı ile ilişkilendirilebilir: ana kurulum, canlı kullanıma geçiş sonrası dönem ve işlevsellik adaptasyonunun sürekli süreç iyileştirmenin bir parçası olarak görülmesi.

38

3.2.1 Kurulum fazı Kurulum süresince tedarikçinın uygun araçlar sunarak destekleyebileceği üç adım bulunmaktadır. İlki iş süreçlerinin modellenmesidir. Bunun sonucunda ortaya işletmenin nasıl

Ad

apta

syon

U

ygu

lam

a

On

-lin

e C

anlı

ku

llan

ım

İnte

rakt

if C

D-R

OM

G

ünlü

k iş

ler

Eğ

itim

Y

eni k

ulla

nıcı

e

ğitim

i

Sü

regi

den

gel

işm

e

Onl

ine

yard

ım v

e

dök

üman

tasy

on

V

eri t

aram

ası

İş m

odel

lem

e pa

ketle

ri –

iş s

ürec

i m

odel

lenm

esi

Si

stem

kon

figür

asyo

n ar

açla

rı –

Siste

min

kon

figür

asyo

nu

D

oküm

an y

önet

im a

raçl

arı –

D

öküm

anta

syon

süre

ci

HA

REK

ETLE

R

İŞ

ZEK

ASI

W

eb o

lana

klı

a

rayü

z

inp

ut m

anue

l

Ekra

n/ra

por d

üzen

leyi

ci

S

td.

rap

orla

mal

ar e

nteg

re r

apor

lam

a

ar

açla

rı

Ad

hoc

e

nfor

mas

yon

sor

gu

Oto

. ver

i

topl

ama

G

UI

ara

yüz

(yeş

il

e

kran

)

İş M

antığ

ı

kanı

tları

OLA

P(on

line

Ana

litik

Pro

s.

Ara

çlar

ı

D

iğer

uy

gula

mal

ar

39

işleyeceğini gösteren diyagramlar kümesi ortaya çıkar. Sonraki adım uygulamanın tanımlanan modeli yansıtacak şekilde konfigüre edilmesidir. Bu; her bir işlevsellik parçasının nasıl işleyeceğini kontrol eden, tabloların yaratılmasını, önem derecelerini gösteren bayrakların konmasını, farklı özelliklerin açılıp kapatılmasını ve değer aralıklarının belirlenmesini içeren çok sayıda parametrenin konfigüre edilmesi aşamasıdır. Aynı zamanda güvenlik ve ekran parametrelerini de içerir. Üçüncü adım dokümantasyonun üretilmesidir.

Bazı tedarikçiler, bu üç adımın pürüzsüz bir şekilde ilerlemesini olanaklı kılan bütünleşik araçlar sunmaktadırlar. Böylelikle tanımlaması yapıldıktan sonra model yazılım içindeki parametreleri uygun değerlere getirmektedir. Konfigüre edilmiş yazılım ile de ilgili doküman taslaklarının kompozisyonu yapılabilmektedir. Yaklaşımın açık rahatlığına karşın, bu araçların kullanımı incelenmelidir. Bir defa özel konfigürasyon kurulduktan sonra sonraki bir tarihe kadar değişiklik yapmanın olanaklı olmayabileceğinden müşterinin haberdar olması gerekir. 3.2.2 On-line faz

Uygulama on-line hale geldiğinde yazılımın çok farklı yüzleri ortaya çıkar. Uygulamayı destekleyen veritabanıdır. Bununla ilgili olan da spreadsheet, iş zekası araçları, en iyi uygulamalar gibi diğer uygulamalarla erişimdir. Ortaklık sözleşmeleri ve genel ara yüz standartlarının benimsenmesi tak-çalıştır türü uygulamalarının sayılarının artmasını sağlamıştır. Gömülü dikişsiz bütünleşmeler gerçek zamanlı veri değiş tokuşu için fırsat sunmaktadır. Bir örnek bordro/insan kaynakları uygulama yazılımını arayüz ile ERP’ye bağlayarak en iyi oluşumu yaratmaktır. Bu durumda bordro detayları güncelleştirildiğinde muhasebenin ilgili hesaplarının güncellenmesi gerekmektedir.

Veritabanının üstünde iş mantığı oturur. Buradaki başlıca konu, müşterinin yazılımın ilk versiyonunu mu yoksa uyarlanmış şeklini mi kullandığıdır. Mamafih uygulamanın yükseltimi gündeme geldiğinde uyarlamanın ne yapılacağı problem haline gelir. Uyarlamanın yeniden yapılması hiç de az görülen şeylerden değildir. Bazı tedarikçiler, bazı alanların uyarlamalar için ayrılmasını sağlarlar, yükseltim yapıldığında da uyarlama işi sadece bu alanların transferidir. Çok sayıda tedarikçi, nesne yönelimli programlamanın teknolojik avantajlarından yararlanmak için uygulamalarını yeniden yazmaktadırlar. 1970 ve 1980’lerin sistemleri anıtsal varlıklar olsa

40

da, şimdi uygulama kodlarını yeniden kullanılabilir, yönetilebilir ve gerektiğinde birbirlerine bağlanabilir birimler halinde üretme fırsatı doğmuştur. Sonuçta ortaya çıkan bileşenler, birbirleriyle kolayca irtibatlandırılabilen küçük parçalardır. Bunun müşteriye yükseltim için yeni bir yol sunduğu düşünülmektedir. Tüm sistemi yükseltmek yerine müşteri, yalnızca gerek duyduğu parçaları kurmakta veya yükseltmektedir.

İş akışı rutin ekran tabanlı işlerin teknoloji yönelimli olmasına izin vermektedir. Bir kişi işi tamamlar tamamlamaz bir mesaj sonraki kişi tarafından alınmakta ve onu kendi işini yapma sırasının geldiği konusunda bilgilendirmektedir. Teknolojiye bağımlı olarak ilgili ekranlar ve dokümanlar çağrılabilir, iş tamamlanır ve sıradaki sonraki kişi ikaz edilir. Kurulum hayli çaba gerektirir, sonradan değişiklik yapılması da zordur. Bu nedenle sürecin kararlı olması ve her adımın kim, ne, ne zaman, nasıl yapıyor sorularına yanıtlarının verilerek açıkça tanımlanması önemlidir. Bunun avantajı işler arasındaki ölü zamanın azalmasıyla rutin süreçlerin zamanının önemli şekilde kısalmasıdır. İşlerin tamamlanması garanti edilmekte, izinler alınmakta, dokümantasyon hazır olmakta, ideal olarak mühendislik değişim süreçlerinin tümüyle kontrolü olanaklı olmaktadır. Dahası sürecin sürelerine ilişkin istatistikler derlenerek darboğazlar ve gecikmeler açıklığa kavuşturulmakta, böylelikle döngü zamanını daha iyileştirecek düzeltici önlemlerin alınması olanaklı kılınmaktadır. İş akışı canlı kullanıma geçtikten sonra da süreçlerin iyileştirilmesi ve kararlı hale getirilmesi istendiğinde sıklıkla kullanılmaktadır.

Kullanıcı ekran arayüzü, dikkat edilmesi gereken diğer bir katman sunmaktadır. Bugün tüm arayüzlerin, aşina olduğumuz grafik kullanıcı arayüzü formatında olması beklenmektedir. Çok az kalmış olmakla birlikte, grafik kullanıcı arayüzünü taklit eden ekranlara da rastlanabilmektedir. GUI’ye alışık kullanıcılar için bu eski teknoloji ekranların benimsenmesi geri adımdır ve uygulamanın bütünselliği üzerinde şüpheler uyandırır. Dahası ekranların kullanıcı dostu özelliğini artırmak için formların daha kabul edilebilir formatta tasarımlanması arzu edilmektedir. Bir örnek kullanıcının bir işi yapmak için çok sayıda ekran arasında gidip gelmesi olabilir. Bunun yerine işe hizmet eden tek bir ekran tasarımlamak olanaklı olabilir. Bunu yapmak için ekran tasarım aracı kullanılır. Bu aracı öğrenmek ve kullanmak için gereken uzmanlığın şirket içinde var olup olmayacağı düşünülmelidir.

41

Veri giriş enformasyon çıkış perspektifinden bakıldığında çeşitli seçenekler mevcuttur. Veri girişleri, klavye ve ekran kullanılarak manüel olabilir. Web ve portallerin ortaya çıkması özellikle uzak mekanlardan veri girişi için yeni fırsatlar yaratmıştır. Mamafih izinsiz ziyaretçilerin erişimini önlemek gerektiğinden güvenlik hakim konu haline gelmiştir. Alternatif olarak veri yakalama, örneğin bar kod tarayıcı, EDI veya kamera sistemleri kullanarak otomatik hale getirilmektedir. Otomasyon tapaj hatalarının önüne geçerken kullanılan düzeye göre de harcamaları artırmaktadır. Geleneksel olarak EDI kurulumunun çok iş yükü getirmesi nedeniyle pahalı olarak görülmektedir. Komple bir bar kod, imalat atölyesi izleme sistemi donamı ve kurulum olarak görece yüksek harcamalar oluşturmaktadır. Bu harcamaların sağlanacak yararlar tarafından veya gereksinimlerin yerine getirilmesi ile karşılanması gerekmektedir. Bileşenlerin, süreç içi stokların ve bitmiş ürünlerin hareketlerini izleme yeteneği, bitmiş ürünler arasında kritik ürünlerin bulunduğu ve imalatçının parti numarası ile geriye doğru gerekli olduğu böylelikle aynı partiye ait tüm ürünlerin tanımlanması gereken uygulamalarda bir güvenlik gereksinimi olabilir.

Eski sistemlerle ilgili şikayetlerden biri de: çok sayıda veri içerdiği fakat gerçekte neler olup bittiğine ilişkin az veri açığa çıkardıklarıydı. Uygulama ile gelen standart raporlar, arzulanan veri alanlarına erişilebilip gerekli hesaplamalar yapılabilmesi ile hazırlanan özel raporlarla tamamlanmaktaydı. Fiilen bir rapor üretebilme işi, çoğunlukla IT personelinde çok seyrek görülen uzmanlık birikimiyle hazırlanabilmekteydi. Bu durum bir miktar iyileşmiştir. Standart raporlara ek olarak özel raporların üretilmesi kolay hele gelmiştir. Rapor yazma araçlarının kullanımları daha kolaylaşmış olup, tedarikçiler müşterilerin çok geniş bir yelpazedeki verilere erişme gereksinimleri kavramışlardır. Böylelikle daha anlamlı raporlar üretmek olanaklı hale gelmiştir. Mamafih raporların bir sınırlaması, bir defalık sorgulamalara uygun bir eğilim göstermemeleridir. Bu nedenle pek çok uygulama, basit sorgulama dili kullanarak veritabanı sorgulama özelliği sunmaktadır. Veriler, on line gerçek zamanlı olarak incelenebilmekte veya daha derin analizler için başka ortamlara, örneğin excel benzeri hesap tablolarına yüklenebilmektedir. Böylece problemleri araştırmak için daha yetenekli kullanıcılar gerekmekte, veri alanlarını birbirlerine bağlayarak yanlış enformasyon yaratmaları tehlikesine karşı uyanık olunması gerekmektedir. Kullanıcılar için bir diğer seçenek, iş zekası araçlarıdır. Bunların kullanımları normal bir kişinin yetenek sınırları içinde olsa da kurulmaları bir dereceye kadar uzmanlık

42

gerektirmektedir. Kullanıcıya veri içindeki paternleri keşfetme olanağı sunmaktadırlar. Genel kullanımları, bölgeler arası veri etkileşimlerinin olduğu, ürün, tedarikçi ve diğer değişkenlerin incelenerek eğilimlerin çıkarıldığı satış analizleridir. Bir önemli yararları da kullanıcının veri girişi sırasında karakter dizilimlerinden emin olmayıp veri mi gireceğine, yoksa başka enformasyon mu arayacağı kararını veremediği zamandır. Buradaki özellik, bilinen karakterler ile bilinmeyen karakterlerin bileşiminin kullanımına olanak sağlayarak tüm ilgili veri girişlerini araştırabilmesidir.

Diğer bir gelişme, kaliteli yazıcıların kullanılabilir hale gelmesiyle standart dokümanların üretilebilir olmasıdır. Ön-baskılı32 evraklara yazmak yerine lazer yazıcılar ile komple basım yapmak veya e-mail veya faks ile arzulanan formatta gönderim yapmak olanaklı hale gelmiştir. Faturalar, siparişler, tablolar veya diğer dokümanlar ön-baskılı kağıtlara olan gereksinimi önlemektedirler. Bu araçlarla bu dokümanları üretmek şirket içinde normalde bulunan yeteneklerin ötesinde bir uzmanlık gerektirmektedir. Dahası bu yetenekleri içerde geliştirmenin maliyet etkin olup olmadığı sorgulanmalıdır. Bir defa başlangıç doküman seti hazırlandıktan sonra değişimler o kadar seyrek olabilir ki; dış desteğe bağımlı kalmak maliyet etkin olabilir. Bu araçlar, üçüncü parti malı olsa da tedarikçi, doğrudan veya kendine bağlı bir başka firma aracılığıyla gerekli desteği sunabilmelidir.

Bunlardan başka web’in gelişmesi ERP uygulamalarının uzaktan erişim sağlayan web olanaklı olması için talep yarattı. Bunun anlamı ekranların HTML veya XML gibi tarayıcı dostu format kullanılarak yaratılması idi. Erişilen verilere hangi nedenle erişildiği, kim tarafından ve hangi yolla erişildiği, tek mi iki yönlü mü erişildiği tasarım gereksinimi yaratmaktaydı. Dahası uygulamaya standart tarayıcı kullanarak erişim güvenlik konularını çağrıştırmaktaydı. Kamuya açık kapısı olan bir sistem hacker’ların veya virüslerin potansiyel ataklarına karşı savunmasızdı. Veri güvenliği alanında ciddi adımlar atılmasına rağmen, veri güvenliği hala en önemli meselelerden biridir. 3.3 Uyum fazı

Sistem canlı kullanıma geçtikten sonra fonksiyonların çalışıp çalışmadığını yeniden kontrol etmek için çeşitli vesileler ortaya çıkar. Bu vesileler, uygulamaları yeniden gözden geçirmek, yeni

32 Önceden tasarlanmış hazır formatlı dökümanlar

43

kullanıcıları eğitmek ve mevcut kullanıcıları geliştirmektir. Bu iş için çok çeşitli yardımcı araç bulunabilir. İnteraktif CD-ROM’lar yazılıma bağlanmadan kendi kendine öğrenmeyi sağlar. Bunun yararı öğrenme için atılacak adımların hızının öğrenici tarafından belirlenmesidir. Bir CD aynı zamanda basılı materyalin büyük hacimlerinden kurtulmayı sağladığından dokümantasyon için de uygun formattır. On-line olanaklar dokümantasyonu ve on-line yardımı içerir. Dokümantasyon sistemin kullanımını dikkate alarak kullanıcı prosedürlerini detaylandırır. On-line yardımın iki katmanı olabilir: ilk katman kullanıcı imleci ilgili alan üzerine pozisyonladığında, fonksiyon tuşunu, örneğin F1’i, kullandığında bir satırlık açıklama alır. Fonksiyon tuşu yeniden kullanıldığında tüm detayları içeren ikinci katman getirilir. On-line dokümantasyonun içeriğine kullanıcı dostu yorumlar eklemek ve böylelikle daha anlamlı açıklamalar sunmak olanaklıdır. On-line araçlar sistem hakkındaki sorulara yanıt aramayı kolaylaştırırlar.

Toplamda ERP uygulaması uygulamaya yönelik fonksiyonlarına ek olarak pek çok fonksiyonel özellik sunar. Mamafih tüm özellikler, tüm satıcıların ürünlerinde bulunmaz. Eski teknolojiler GUI kullanımı ile gizlenebilmesine ve yeni teknolojileri taklit etmeye çalışılmaları saklanabilmesine karşın eski ürünlerin bunları sunma olasılığı daha düşüktür. Öte yandan en son teknolojik ürünler hataya müsait olmaları ve test edilmeden sunulmaları nedenlerinden ötürü eleştirilebilirler. Bir seçenek ERP uygulamasını görece yenilerinden, ama alanında kanıtlanmış olanlarından seçmektir. Mamafih en son teknolojik ürünü almamanın kaybettirebileceği işsel ve operasyonel fırsatları dikkate almaya değer. Hangi yol seçilirse seçilsin dikkate alınması gereken bir karanlık yüzü olacaktır. 3.4 Uygulama işlevselliği

ERP konusundaki tartışmalar, yazılımın bazı işlevlerinden bahsedilmeden tamam olmaz. Elde edilebileceklerin ölçeği imalat yönelimli malzeme gereksinimleri planlaması ve sipariş verme yazılımlarından bu yana anlamlı şekilde artmıştır. Her fonksiyon modülünü veya bileşenini derinlemesine tasvir etmek her sunumun zenginliği için adil olmayacaktır. Bunun yerine okura ERP tedarikçilerinin web sitelerini keşfetmesi önerilmektedir. (bakınız yararlı kaynaklar)

Mamafih aşağıdaki örneği dikkate alarak, sunumların çeşitliliği hakkında bir nosyon kazanılabilir. Bu deneme ERP işlevselliğinin

44

çekirdeğinde hala imalat olmasına karşın bütünleşik ve zengin doğasını sunar.

Pazarlama personelinin temasları takip ettikleri bir müşteri listesi vardır. Bu liste temasların doğasının, onlara gönderilen materyallerin, verilen fiyat tekliflerinin izini tutar ve tekrar temas kurulması gerekiyorsa bunun işaretini taşır. Kampanya detayları kanıtlanan değerlendirmelere dayalı verimlilikleriyle kaydedilir. Uygun durumlarda satış personeli müşterinin yerinde müşterinin özel gereksinimini karşılayan ürünün bir araya getirmek ve anlık fiyat teklifi verebilmek için ürün konfigüratörü kullanırlar. İş zekası araçlarının kullanımı satış verilerinin derinlemesine analizi ile bölge, ürün, tedarikçi veya diğer farklılaştırıcı özelliğe göre yüksek ve düşük performans alanlarının görülmesini sağlar. Tasarım aşamasında parça listeleri CAD çizimlerinden yüklenebilir ve ürün ağacı oluşturmada kullanılabilir. Ürün ağacı geliştikçe tarihçe oluşturacak şekilde değişimler kaydedilir. İmalat süreci oluşturulduğunda imalatın hangi aşamasında hangi parçaya gerek olduğunu gösteren bir rota yaratılır. Bu aşamada kalite personeli muayene kriterlerini belirleyebilir ve bunları rotanın çeşitli aşamalarına tahsis edebilir. Böylelikle süreç içi işler belirli bir aşamaya geldiğinde operatör muayeneyi yapmak için tüm enformasyona sahip olur. Muayenenin sonuçları manüel veya otomatik olarak yakalanır ve gerektiğinde analiz edilir.

İmalat operasyonlarının kapasitesi, aşağı doğru bireysel makine düzeyine kadar tarif edilir. Dahası her makinenin yedek parçaların tanımlandığı ve satın alma detaylarının bulunduğu bir bakım çizelgesi vardır. Satın almanın tüm yapacağı parçalar belirlendiğinde gerektiği zaman elde bulunması için sipariş vermektir. Muhasebe diğer ekipmanlarla birlikte tüm makinelerin listesine sahiptir. Bu listeyi ay sonu hesapları için aylık amortismanların tutarlarının bulunması da dahil olmak üzer aktiflerin yönetiminde kullanırlar.

Satış tahminleri ve siparişler talebi belirlemede kullanırlar. Satış enformasyonu satış personeli tarafından doğrudan sisteme beslenirken güncelleştirilen siparişler haftada iki defa EDI ile alınır. Bu bilgi teslim tarihlerinin ekipman, malzeme kullanılabilirliği ve insan kısıtlarıyla birlikte değerlendirilmesi sağlanacak şekilde ileri planlama yazılımına verilir. Herhangi bir anlık siparişin yapılabilirliği test edilir. Çıktı üretim çizelgesi önerisidir. Bu daha sonra malzeme gereksinim planına verilerek sıkıntılar tanımlanır. Satın alma tedarikçileriyle temas kurarak bu sıkıntıların üstesinden gelip

45

gelemeyeceğini değerlendirir. Eğer üstesinden gelebilecekse satın alma siparişini elektronik yoldan tedarikçisine gönderir. Tedarikçi alıp çek ettiği siparişleri teslim eder. Mallar sistem üzerinde rezerve edildiğinde detaylar satın alma siparişi ile karşılaştırılır ve varsa farklar sorgulanır. Varsa muayene gereksinimleri işaretlenir ve yerine getirilir. Muhasebe tedarikçiden bir fatura alır ve sipariş detaylarıyla karşılaştırabilir. Daha sonra fatura için ödeme günlerinde ödenecek şekilde ödeme emri çıkarılabilir. Ödeme şirketin bankasına tedarikçi hesabına otomatik olarak fon transferi yapması için talimat gönderir ve borç kayıtlarını otomatik olarak günceller.

Uygun zamanda iş emirleri sistem tarafından yayınlanır. İzleme sistemi ham maddelerin, süreç içi işlerin ve bitmiş ürünlerin yer ve değerlerine ilişkin gerçek zamanlı enformasyonu sunarak envanter kayıtlarını günceller. Bir müşteri siparişi için bitmiş ürünler hazır olduğunda sevk dokümanları üretilir, satış faturası müşteriye gönderilir ve uygun alacak hesabı kayıtları güncellenir. Bir işaret müşteri ödemesini geciktirdiğinde kredi kontrolün takibat yapması için belirerek dikkat çeker.

Personelin istihdam yaşam döngüsü İnsan Kaynakları paketi ile yönetilir; bu paket tatilleri, hastalıkları, eğitimleri, disiplin cezalarını, iş tanımlarını ve yazışmaları kaydeder. Bordro ve Zaman & Devam ile arayüzü vardır. Çalışanlar mekana girerken ve çıkarken kart bastırırlar, bu onların devamları ve farklı faaliyetlerine ilişkin detay bilgileri sağlar. Birinciler iş maliyetine ilişkin enformasyon sağlarken, sonrakiler bordro programına gönderilerek devamsızlık ve geç kalmalara ilişkin düzenlemelerde kullanılır. Bordro hesaplandığında banka bağlantısı ile şirket banka hesabından çalışanların banka hesaplarına transfer yapılır ve büyük defterin uygun hesap kodları gereğine göre ayarlanır.

Bahsedilen defterlere ek olarak muhasebe nakit akış yönetimini, iş maliyetlendirmeyi ve proje maliyetlendirme fonksiyonunu da yapabilir. Farklı vergi rejimleri ve döviz cinsleri küçük şirketler için bile gereksinim olabilir.

Yukarıda sözü edilen model kesikli ve sipariş üzerine imalat süreci için açıklayıcıdır. Mamafih imalat bileşeni tüm süreçlerin yalnızca bir parçasıdır. İmalat operasyonu kendisini ikame edebilecek başka tip süreçleri içerebilir. Bazı tedarikçiler örneğin gıda sektörü için özel akış türü süreçler sunarlar. Burada önemli olan işlevselliğin

46

işletmenin diğer alanlarını da kapsaması, uygulamanın kullanımının mevcut imalat operasyonuna bağımlı olmamasıdır.

Depo ve dağıtım yönetimi, satış sonrası hizmetler ve ürün dokümantasyonu yazılımların sunduğu diğer ek fonksiyonlar arasında yer almaktadır.

İşlevselliğe daha derinden bakış özel satıcıların hangi dar endüstrileri hedefledikleri üzerinedir. Pek çok tedarikçi büyümeyi denemede ve her şeyi herkese sunmadan önce işe spesifik endüstrilerle başlamıştır. Geçen zaman içinde pek çok tedarikçi yeniden bu dar endüstri odağına dönmüştür. Bu onların geniş kapsamlı sunumlarını rafine ederek spesifik endüstrideki işletmelerin özel gereksinimlerine daha iyi karşılık vermelerini sağlamıştır. Bu segmentasyon, tedarikçide tedarikçiye anlamlı biçimde değişmekte, otomotiv, elektronik ve havacılıktan ormancılık, enerji ve içecek sektörlerine kadar dizilmektedir.

Bizim şimdiki yaygın formu içindeki ERP’yi anlayışımız yazılımın gelecek kuşak ürünlerini dikkate almamızı gerektirmektedir. Her ne kadar elemanlar bugün hazır ve elde edilebilir olsa da ERP II olarak adlandırılmadan önce yapılacak çok iş var gibi görünmektedir.

47

4 Sonraki Kuşak 2000 yılının başlarında internet tabanlı ERP II’ye yönelim, başladı. Yönelim, yazılımın içe dönük yapıdan dışa dönük ve web özelliği bulunan yapıya odaklanan değişimini yansıtmaktaydı. Bu değişimi dikkate alan Gartner Inc. yeni sürüm, ERP II’yi yarattı. ERP II şöyle tanımlandı:

şirket içi ve şirketler arası operasyonel işbirliğini ve finansal süreçleri olanaklı kılıp optimizasyonunu sağlayarak müşteri ve paydaş değeri oluşturan endüstriye özel uygulamalar seti ve bir işletme stratejisi (Gartner Inc., 2000)33

Sonraki bir tanımda işletme stratejisi kavramı rafine edilerek “uygulama ve yaygınlaştırma stratejisi”ni içerir hale getirilmiştir. ERP II’nin tablo 4.1’de özetlenen altı elemanı bulunmaktadır. ERP II imalat köklerini geride bırakarak en geniş anlamda bir işletme uygulaması yazılımı haline gelmiştir. İşlevselliği, işletmeninin bütününü geniş ve derin bir zenginlikle kapsamaktadır. Dışa dönük işlemleri ve şirketler arası etkileşimi vurgulaması arayüz standartları ile Internet alanlarındaki teknolojik gelişmeleri benimsediğini yansıtmaktadır. Her ne kadar Gartner Inc., satıcıların ürünlerinin henüz ERP II kriterlerini tutturamadığını ileri sürse de bu kaçınılmaz bir zorunluluk olmuştur. Eleman ERP ERP II Uygulamanın rolü İşletme optimizasyonu Değer zinciri katılımı İşletme içindeki yeri İmalat ve Dağıtım Tüm birimler/ segmentler Fonksiyonlar

İmalat, satış ve dağıtım ile finansman süreçleri

Çapraz endüstri sektörleri ve özel sektörel süreçler

Fonksiyonlar tarafından talep edilen süreçler

İçsel ve gizli

Dış bağlantılı

Sistem mimarisi

Kapalı, monolitik, web özellikli

Web tabanlı, açık, bileşen tabanlı mimari

Mimari içinde veri yönetim şekli

İçerde yaratılan ve tüketilen veri

İçerde ve dışarıda yayınlanan ve kaydedilen veri

Tablo 4.1 ERP, ERP II Karşılaştırması (Gartner Inc.,’dan alınmıştır 2000)

48

Evrimdeki sonraki adım bugün ERP olarak adlandırdığımız sistemin başlangıçtaki envanter kontrol sisteminden çok farklı olmasıdır. Evrimsel

yol tablo 4.2’den izlenebilir. Bu yol yönetsel düşünce, metodolojik yaklaşımlar, fonksiyonel talepler ve son teknolojik gelişmelerin ticarileştirilmesi konuları arasındaki karmaşık etkileşimleri göstermektedir. Gözden kaçırılmaması gereken nokta, her ne kadar

T

ablo

4.2

E

RP II

Evr

imse

l Mod

eli

49

isimler özel evrimsel durumları tasvir etmek amacıyla konmuş olsalar da, gerçek farklı noktalar arasındaki sınırların hiç de net olmadığıdır. Belki de daha önemli konu ERP II’nin kurulumudur. ERP’nin kurulumu incelendiğinde yirmi yıl önce MRP II’nin kurulumunda karşılaşılan sorunlarla karşılaşıldığı görülür. Teknolojinin daha gelişmiş olmasına karşı böyle olmuştur. Çünkü kurulumun gerisindeki prensipler aynı kalmıştır. Kurulumun temelinde süreçlere ve insanlara odaklanma bulunmaktadır. Süreçlerin anlaşılması ve gereksinimlerin tanımlanması gerekmektedir. İnsanların bilgilendirilmeleri, çalışmalara dahil edilmeleri ve eğitilmeleri gerekmektedir. Seçim süreci üzerinde fonksiyonel uygunluk, metodoloji ve satıcı ilişkileri gibi pek çok konunun ilk defa bu aşamada ortaya çıkması nedeniyle, özenle durulmalıdır. Kurulumlar, proje yönetimi ve detaylara dikkat gerektirmektedir. Teknolojinin karmaşıklığı ürkütücü olsa da genellikle teknolojik konular kurulum sırasında ciddi problemler yaratmamaktadırlar. Bu yorumlar aynen MRP II, ERP, SCP, CRM ve elektronik ticarete de uygulanabilir. ERP II ile de eşit derecede ilgili olduğunu belirtebiliriz. ERP III34 ERP uygulamaları, şirket içerisinde yürütülen operasyonları birbirine entegre ederek özellikle üretim odaklı işletmeleri yönetmek için geliştirilmiş çözümlerdir dedik. ERP II ile birlikte ERP kavramı, sadece üretici firmalara özel bir çözüm olmaktan çıkarak tüm diğer sektörlere de hizmet eder hale geldi. Ayrıca işin içine şirketin dışındaki satıcılar da dahil edilerek maliyet düşürme, arz/tedarik zincirinin etkinliğini artırma ve işbirliği ile daha hızlı, daha yenilikçi işletmeler yaratma özelliği ERP II çözümlerini klasik ERP çözümlerinden daha işlevsel kıldı. ERP II çözümleri, ayrıca tamamen kapalı sistemler olarak tasarlanan ERP çözümlerine internet erişim fonksiyonunu da ekleyerek interneti işin bir parçası olarak konumlandırdı. ERP III ise bir üst seviyeye yükselerek ERP II çözümünü tamamen internet tabanlı hale getiriyor. Özellikle klasik ERP çözümleri, sadece şirketin iç süreçlerinin hammaddeden faturaya kadar olan kısmıyla ilgiliydi. İşin içine arz/tedarik zincirinin katılması ve bu sayede üretim süreçlerinin optimizasyonunun sağlanması ile ERP II adını alan kurumsal yazılımlar, şimdi de yüzünü müşteriye dönmek ve işin ve 34 Ayrı bir ERP III kavramından sözediliyor olsa da aslında, ERP II ve ERP III kavramsal olarak (ve daha da ötesinde tatbiki olarak da) aynılaşan alanlardadır.

50

operasyonların diğer bileşenlerini de kapsamak zorunda. İşletmeleri daha etkin daha interaktif daha proaktif kılan ERP III, gelecek yılların yeni kurumsal çözüm kavramı olarak iş ve yazılım dünyasına damgasını vuracak. Eskiden işletmeler, sadece kendi iç bünyelerinde oluşan yapılandırılmış bilgiyi yönetmekle meşgullerdi. Ancak internetin hem iş dünyasının hem de tüketicinin hayatına girmesi ile her gün milyarlarca satır yapılandırılmamış bilgi üretilmeye başlandı. Bu bilgiyi üretenler içerisinde sizin şirketinizden, sizin ürünlerinizden, markalarınızdan, kendi kişisel veya kurumsal ihtiyaçlarından ve beklentilerinden bahseden insanlar var. Eğer bu bilgiyi yönetme, bu kişiler ile iletişim kurma ve yönlendirme yeteneğini kazanırsanız, rekabette öne çıkmak, yenilikçi olmak, olumsuzu olumluya çevirmek işte tam da o zaman mümkün oluyor. Peki bu nasıl olacak? Bu kadar dağınık ve yapılandırılmamış bilgiyi kendi şirketinizi daha iyiye daha ileriye götürmek için nasıl kullanacaksınız, dahası bu bilgiyi şirketinize nasıl yönlendireceksiniz? İşte İnterneti kendine temel teknoloji seçmiş, internet üzerindeki bilgi kaynakları ile etkileşime geçebilen, internetteki tüketiciyi, müşterinizi veya iş ortağınızı yönetmenize, ondan bilgi toplamanıza olanak sağlayacağı varsayılan ERP III ile olacağı söyleniyor.

ERP III ile ERP II farkı

ERP III kurumsal yazılım çözümlerinin geldiği son nokta olarak adlandırılıyor. Aslında tanımı günümüzde hızla değişen internet kullanıcı kitlesinin yönelimlerine göre ileride daha da değişmeye açık. Üç kavram ERP III’ü ERP II’den ayırıyor: Bütünleşik işlevsellik (yani konsalidasyon gücü), müşteri odaklılık ve kurumlar ve bireyler arası işbirliği ve etkileşim. İşletmenin tüm süreçlerini kapsayan, tüm departmanların, birimlerin, fonksiyonların ve operasyonların ihtiyaçlarını karşılayan, daha müşteri odaklı değer üretimine yönelik fonksiyonlar içeren ERP III çözümlerinin en temel özelliği, tamamen internet tabanlı olması. İnternet tabanlı olma özelliği ERP III çözümünüz üzerinden

51

müşterileriniz, bayileriniz, tedarikçileriniz ve tüm piyasa bileşenleri ile işbirliği yapma, iletişim kurma imkanını size sunuyor. Bu, ERP fonksiyonlarının içine hepimizin anladığı ve bildiği klasik CRM yeteneklerini eklemekten daha da öte bir şey. İşletmeyi daha geniş bir pazara ulaştırmak, müşteri ile doğrudan etkileşime sokmak yerine satış gücünü yönetmeye odaklanmış hepsi. ERP III, İnternet tabanlı altyapının sunduğu bir nimet olarak doğrudan kurumsal ERP sistemi üzerinden yönetilen B2B, B2C portal fonksiyonlarını, sosyal medya entegrasyonunu, video konferans, online mesaj, e-mail, forum, anket yönetimi gibi doğrudan iletişim araçlarını da işin içine katarak işletmeyi network’ü içerisindeki bayi, müşteri, tedarikçi gibi tüm Pazar bileşenleri ile yapılandırılmış bir diyalog ve bilgi paylaşımı içerisine sokmayı başarıyor. Bu sayede işletmeler artık yenilikçi, interaktif, reaktif yeteneklerini yükselterek daha iyi ürün ve hizmetler pazara sunarak bunu satıp dağıtabilecekler.

ERP III’ün İçerisinde Neler Var

İşbirliği Araçları ve Platformları – ERP III’ün en önemli özelliklerinden biri işletmeye sınırsız sayıda farklı web siteleri kurup tasarlama ve iç süreçler ile %100 entegre biçimde sistem üzerinden yönetme imkanı sunması. Özellikle B2B ve B2C portallerini doğrudan ERP sistemi üzerinden yönetebilen şirketler tedarikçileri, bayileri ve müşterileri ile bu portallerinde bilgi, belge paylaşımı yapabiliyor, ortak projeler yönetebiliyor, eğitimler verebiliyor, anlık iletişim kurabiliyor ve hizmet verebiliyor. Bayi portali, tedarikçi portali, servis ve destek portali, kurumsal veya bireysel müşteri portali, kariyer portali, proje portalleri, müşteri fun kulüpleri markalara veya ürünlere özel internet siteleri ile iş network’ü süreçlerin bir parçası haline getirilebiliyor. Sosyal Medya Araçları ve Entegrasyonu – Bugün kurumsal yazılım çözümlerinin geçmiş özelliklerinin yanında kullanıcılarını birbirleri ile tıpkı Facebook’ta veya başka sosyal ağlarda olduğu gibi iletişim ve etkileşim kurabilir hale getirmesi bekleniyor. Bu da ERP çözümüne güçlü bir intranet ve hatta kurum içi sosyal medya işlevselliği eklenmesi demek. ERP III kullanıcılarına bu ihtiyaçlarını giderecek fonksiyonlar sunabiliyor. Örneğin intranet içerisinde dijital doküman paylaşma, online mesajlaşma, forum modülü, video

52

konferans, kurumsal literatür içerikleri oluşturma, toplu mesaj gönderme gibi fonksiyonlar yer alıyor. ERP çözümünün içerisine kurumsal Twitter, Facebook sayfalarının widget’larının eklenmesi ile şirket tarafından anlık olarak takip edilebilir ve anında müdahale edilebilir hale getirilmesi de ERP III konsepti içerisinde Sosyal medya entegrasyonu konusunda yapılan çalışmalar arasında. Özelleştirme Seçenekleri – ERP çözümlerinin en çok şikayet edilen yönlerinden biri de kullanıcı dostu olmayan menü yapısı ve arayüz tasarımları idi. ERP II çözümlerinde bu konunun üzerine eğilen yazılım üreticileri ERP III çözümlerinde işi bir adım öteye taşıyarak kullanıcılara kendi özel menülerini tasarlama, farklı menü tasarım opsiyonlarını seçme, ana sayfalarını drag&drop teknikler ile istedikleri gibi tasarlama, arayüz renklerini değiştirme, hızlı erişilen sayfalar listesi oluşturma gibi çok farklı seçenekler sunuyor. ERP3’e tüm bunları yapma imkanını ise tamamen Web tabanlı teknolojisi veriyor. Yeni Fonksiyon ve Yönetim Araçları - Proje Yönetimi / İçerik Yönetimi / Web Tasarım Aracı / Fiziki Varlık Yönetimi / Servis Destek Yönetimi / Anket ve Pazar Araştırmaları / Eğitim Yönetimi Araçları ERP III’ün ERP II’den ayrılan en önemli özelliklerinden biri de şirketin bütününü kapsayacak şekilde genişletilmiş iç süreç ve operasyon yönetimi araçları. ERP III şirketlere sınırlarını genişletmenin yanı sıra tüm süreçlerini bütünlüklü (konsolide) bir yapıda tek bir yazılım kullanarak yönetme imkanı da sunuyor. Bu araçlar birkaç başlık altında toplanabiliyor. CRM ve Servis Yönetimi – ERP III’ün en çok eğildiği konu olan müşteri odaklılık özellikle potansiyel müşteri kitlesini oluşturma çalışmalarından satış sonrası servis hizmetlerinin takibine çok geniş kapsamda müşteri yaşam döngüsü araçlarını içeriyor. Müşteri ile e-mail, internet portalleri ve sosyal medya üzerinden içerik paylaşma, müşteriye web siteleri veya e-mail’ler üzerinde anketler yapma, tüm toplanan bilgilere göre müşteriyi segmente etme, bu segmentlere uygun online ve off line kampanyalar tasarlama, ürün önerme, özel fiyatlar promosyonlar yapma, fırsatları takip etme, aktif satış gücünü yönetme ve planlama, internet üzerinden satış ve sipariş, satış sonrası kapsamlı bakım ve servis fonksiyonları üzerinden müşteri ile ilişkiyi devam ettirme, şikayet yönetimi, ürün iade yönetimi ve müşteriye çapraz ve dikey satış fırsatları planlama… Bunların hepsinin ERP III içerisinde mevcut olduğu

53

söyleniyor, üstelik en ince detayına kadar raporlanabilir halde olduğu da avantajlarından biri. Proje Yönetimi de ERP III’ün İçinde – Proje Yönetimi fonksiyonları, özellikle proje bazlı üretim yapan veya işleri tamamen projeler ile yöneten işletmeler için ERP çözümlerindeki en büyük eksiklerden biri oldu bugüne kadar. Farklı proje yönetimi yazılımlarında projelerini yöneten şirketler bu çözümlerini ERP veya bekofis (backoffice) uygulamaları ile doğrudan entegre edemedikleri için zaman, finansman, iş gücü gibi kaynaklarını etkin yönetemediler. Projelerin planlanan ve gerçekleşen rakamlarını anlık olarak takip edemediler. Dahası birlikte proje yürüttükleri tedarikçi, taşeron veya herhangi bir 3. Parti şirketi bu sürece entegre etmeleri çok zor oldu. ERP3’ün içerisinde yer alan proje yönetimi internet tabanlılığın getirdiği bir nimet olarak projelerin tüm paydaşlarını bir araya getirip bir arada iş yaptırma yeteneğine sahip. Yani tam anlamıyla bir işbirliği platformundan sözediliyor. Ayrıca proje yönetiminin finans, insan kaynakları, ürün yönetimi, üretim yönetimi gibi diğer fonksiyonlar ile %100 entegre olması tüm operasyonları proje bazlı yönetme yeteneği sağlamanın yanı sıra işletmeye projelerini %100 real-time verilerle yönetme imkanı veriyor. İçerik Yönetimi – Sınırsız sayıda B2B ve B2C portal yaratmaya imkan sağlayan ERP III çözümleri doğal olarak bu portal ve internet sitelerini yaratacak ve yaşatacak içerik yönetimi, web tasarım araçları gibi fonksiyonları da içeriyor. Başlı başına intranet fonksiyonelliğine sahip ERP3 içerik yönetimi yukarıda bahsettiğimiz interaktif ve paylaşımcı kullanıcı grubunun yaratılmasına da hizmet ediyor. Web sitelerinize imajlar, hareketli banner’lar, içerikler ekleyebiliyorsunuz. Tasarım objeleri sayesinde Web üzerinden satış, B2B portal üzerinden sipariş işlemlerini tamamen ERP fonksiyonları ve stok, fatura, finans, ürün yönetimi gibi modüller ile entegre biçimde kullanabiliyorsunuz. Dijital Arşiv Yönetimi – Bilginin çoğalması eş orantılı olarak belgelerin de yönetilemeyecek kadar çoğalması anlamına geliyor. Artık her işletme dokümanlarını dijital ortamda saklamak, tasniflemek ve istendiğinde erişilebilir kılmak istiyor. ERP III çözümlerinin içerisinde dijital arşiv ve dokümantasyon yönetimi fonksiyonları çözümün ayrılmaz bir parçası olarak konumlandırılmış durumda. Fiziki Varlık Yönetimi – Bugüne kadar ERP çözümlerinin içerisindeki muhasebe modüllerinin sadece yasal kayıt tutma zorunluluğuna cevap üretmek için geliştirilmiş “Sabit Kıymet

54

Yönetimi” fonksiyonları işletmelerin klimadan motorlu araçlara, bilgisayardan binalara farklı fiziki varlıklarının satın alma, leasing, sigortalatma, bakım yapma, özellikle IT varlıklarının tüm bileşenleri ile kayıt altına alma gibi ihtiyaçlarına çözüm olamıyordu. ERP3 işletmelere ellerindeki fiziki varlıkları tüm yönlerden kayıt altına alma ve bakımlarını periyodik olarak yönetme imkanı vermesi ile yine ERP ve ERP II çözümlerinden farklılaşıyor. Eğitim Yönetimi – Hızla bilgi üreten işletmelerin en önemli sorunlarından biri de bu bilgiyi çalışanları, iş ortakları veya müşterileri ile paylaşmak. ERP3’ün içerisindeki on-line eğitim araçları doğrudan sistem üzerinden yönetilen portallerde farklı hedef gruplara süreli, ölçülebilen, online eğitimler verme imkanı da sunuyor. Anket ve Pazar Araştırmaları – Müşteri ihtiyaç ve beklentilerini belirlemek için kullanılan anket yönetimi, ERP III’ün kapsama alanındaki CRM fonksiyonları içerisinde özel bir yere sahip. Sistem üzerinde tasarlanıp, doğrudan internet, e-mail, mobil cihazlar, sosyal medya gibi farklı kanallardan yayına açılan anketler ile işletmenin dışındaki dünyanın görüşleri işinizin bir parçası haline geliyor. Bu anketler, özel raporlama araçları sayesinde satıştan, pazarlamaya, üretimden fiyatlamaya pek çok operasyonda yönlendirici rol oynuyor. ERP III’ün nedenlerinden biri Bulut Teknolojisi Son zamanlarda kendisinden sıkça söz ettiren bulut teknolojisi aslında yeni bir kavram sayılmaz 2000’li yılların başlarında ortaya çıkan ASP (Application Service Providing) terimiyle filizlenen iş modeli, Microsoft, Amazon, Google gibi büyük yazılım firmalarının son senelerde bu modele yaptığı yatırımlarla, geleceğimizi şekillendirecek gibi görünüyor. Bulut teknolojisi içinde üç kategoriyi barındırmakta.

IaaS - infrastructure as a service PaaS - platform as a service SaaS - software as a service

Üç kategori de içinde hizmet aktivitesini barındırmakta bu hizmetlerden herhangi birini talep edenler, sağlanacak hizmet karşılığı önceden belirlenmiş periyotlarda aldıkları hizmetin skalasına göre ücret ödemektedirler. Üç kategori de esnek bir yapıya sahiptir. Kullanıcı hizmeti kullandığı kadar ödeme yapar, istediği an farklı bir skalaya hızlı bir geçiş gerçekleştirebilir.

55

Bütün bu hizmetler, servis sağlayıcı tarafından yönetilir ve kullanıcının kendi içinde bir IT ekibi barındırması veya herhangi bir donanım satın alması gerekmez. Birçok ERP III uygulamaları, bu geleceğimizi şekillendiren teknolojiyi desteklemekte de öncü davranmakta ve Microsoft’un güçlü ‘’bulut’’ alt yapısı olan Windows Azure’yi kullanarak bu teknolojide kararlı adımlar atmaktadır. Yeni uygulamalar, iş yükü artışlarını yönetebilmek için müşterilere hızlı uygulama ve esnek talebe göre ölçek değiştirme gibi avantajlar sunuyor. Avantajlardan biri, hızlı uygulamanın müşterilere kaliteli üretim ortamını bir saatten kısa bir süre içinde tatbik etme olanağı sağlamasıdır. Ios, Android ve şimdi de Windows 7 platformlarını destekleyen uygulamalar ile mobil işgücüne kullanıcı dostu arayüzler sağlanmaktadır. Yine Windows Azure üzerinde hizmet veren uygulamalar, kullanıcılara platformdan ve versiyondan bağımsız bir sistem sağlamaktadır. Yeni bulut yapısı, kimi ERP III müşterilerinin seçeneklerini bulut tabanlı uygulamalarla genişletmesine olanak sağlayarak, bulut bilgi işlem stratejisinde yeni bir aşamalar sunmaktadır.

İşletmenin kaynaklarının tespiti ve mevcut kaynakların en doğru şekil ve en doğru zamanda değerlendirilmesi açısından ERP yazılımları büyük önem taşıyor. İşletme içerisindeki birimlerin birbirleriyle entegre çalışmasını sağlayan ERP, şirkette o anki tüm iş akışlarının istenildiği zaman raporlarla izlenmesini mümkün kılıyor. ERP sistemleri üst ve orta düzey yöneticilerin şirket stratejilerine yön vermelerini kolaylaştıracak araçlar olarak, şirketlerin geleceğini belirleyecek kararların en hızlı ve en az sapmayla alınmasına destek veriyor. Bir kurumun operasyonlarının, finanstan üretime, hemen her aşamasını otomatik hale getiren ERP, bu nedenle artık iş dünyasında yöneticilerin sağ kolu durumunda. Rekabette önde almak ve global pazarda kazanmak için güçlü bir temele sahip olmak gerektiğinin farkında olan yöneticiler, ERP alanındaki yeni gelişmeleri takip etmenin şirketleri için en doğru sistemi seçmek kadar önemli olduğunu biliyorlar. Zira dünyada ve Türkiye'de teknoloji alanında yaşanan hızlı değişim ERP alanını; ERP alanında yaşanan değişimler de şirketlerin kaderini doğrudan etkiliyor. Bulut bilişim, mobilite ve sosyal medya rol değiştiriyor: ERP dünyasında konuşulan trendlerin başında elbetteki son yılların en popüler konularından SAAS ve onun yansımalarından bulut bilişim geliyor. HTML5 alanındaki gelişmesiyle birlikte artık olgunluk çağını yaşamaya başlayan bir web teknolojisi haline gelen ERP, şirketler olarak web'e bakışımızı tamamen değiştirmeye hazırlanıyor. Bu nedenle, SAP gibi geliştiricilerin yeni SAAS çözümleri ortaya çıktı ve çok daha fazla şirket IT yapılarını "bulutlara" taşıyacak görünüyor. Özellikle küçük ve orta ölçekli şirketler, bu trendin başını çekiyor olacak. Büyük şirketler ise şube ve bayilerini, dünyanın dört bir yanında bulunan bölüm ve ofislerini daha iyi yönetebilmek adına bulut teknolojilerini uygulamaya koyacaklar. Ayrıca, kurumsal veriye erişip genişleten mobil çözümler ve sosyal ağların şirketlerin oyuncağı olmaktan kurtulduğu bir zamana doğru gidiyoruz.

56

Mobilite ve sosyal medya uygulamaları artık bir zorunluluk oldu, bunlar sayesinde şirketler, gerçek bir değer ortaya koyacaklar. Bu uygulamalara ait özellikleri kendi ERP sistemlerine adapte etmeyi başaran şirketler, yaptıkları çalışmaların faydasını somut olarak görmeye başlayacaklar. Zira bir şirkete ait hemen her bilgiyi kayıt altına alan bir sistem olarak ERP, sosyal medya araçlarının girileceği en doğru yer. Dahası, ERP üzerine yapılan adaptasyonlar güvenlik risklerinin ortadan kaldırılmasını sağlarken, çalışanların işlerini sosyal medyaya yaymasıyla da verimlilik artışı yakalanıyor olacak. SAP, ERP çözümleriyle şirketlere yeni ERP III olanakları sunuyor: Mobil çözümler, sosyal ağ araçları, bulut bilişim gibi tüm yeniliklere sahip olan SAP iş çözümleri, üretim planlamasından stok kontrolüne, müşteri ilişkilerinden insan kaynakları yönetimine kadar tüm iş süreçlerini kontrol altında tutarak firmaların verimliliklerini ve karlılıklarını artırmasına yardımcı oluyor. SAP iş çözümleri, küçük, orta ölçekli ya da büyük her ölçekteki firmanın aynı iş koşulları içinde hareket etmesini sağlayarak, rekabet ortamında eşitlik sağlıyor. SAP iş çözümleri sayesinde şirketler, farklı departmanlar arasında entegrasyonu sağlıyor, stok maliyetlerini azaltıyor, karlılıklarını artırıyor, işletmelerin planlı, hızlı ve verimli üretim yapmasını sağlamasının yanı sıra satış ve pazarlama faaliyetlerini de düzenliyor. Şirketlerin bulundukları sektöre özgü gereksinimlerini karşılamak üzere tasarlanan SAP ERP uygulaması, böylece kurumların sektöre özel ihtiyaçlarına da tam olarak cevap verebiliyor.

57

5 Piyasa Dinamikleri Kurumsal Kaynak Planlaması sisteminin satın alımı ve kurulumu için yapılan yatırım, bir şirketin harcamalarının pazarın doğasını dikkate almaya değecek kadar önemli bir kısmını oluşturur. Düşünün yeni bir sistemin canlı kullanım dönemi başladı ve ERP firması el değiştirdi ya da daha kötüsü firma iflas etti. Ne olacak peki? 5.1 ERP pazarı: yazılım tedarikçilerinin ve hizmet

sunucuların bulunduğu çalkantılı bir küresel havuz

Teknolojideki hızlı gelişmeleri, uygulama taleplerindeki hızlı artışları, yeni nesil teknolojik gelişmeleri benimseyen yeni giriş yapacaklar için fırsatları yansıtan ve hızla evrim geçiren bir pazar; piyasa. Birkaç on yıl içinde MRP evrim geçirerek önce MRP II oldu, sonra ERP, şimdi de ERP II’ye, hatta ERP III’e dönüştü. Benzer şekilde satıcılar da büyük ölçüde değişti. Şimdi müşteri uygulamasını ister yazılım evinden almak ve destek hizmetlerini kullanmak ile isterse dolaylı bir şekilde üçüncü taraf firmadan almak seçeneklerine sahip. Gelecekte neler olacağını öngörebileceğimiz kristal küremiz olmasa da geçmişten azar azar toplanan dersler bulunmakta. 5.2 Yazılım sunucuları

1960’ların başında büyük ölçekli kurumlar yazılım geliştirme ekipleri kurarak kendi özel sistemlerini geliştirmekteydiler. 1970’lerde yazılım evleri ortaya çıktı. 1978 yılında IBM, ilk ticari MRP paketlerinden MAPICS’i pazara sundu. Bu paket, MRP pazarına on yıldan daha fazla süreyle hakim oldu. MRP pazarının potansiyelinin farkına varan bazı büyük firmalar, kendileri için geliştirdikleri yazılımları ürün olarak pazara sundular. 1980’ler, sayıları giderek artan yazılım evleri ile karakterize edilebilir. Pek çoğu özel gereksinimlere hitap eden gereğinden fazla ürün, pazara sunuldu. 1970’lerin sonunda ve 80’lerin başında bugün iyi bilinen satıcıların çoğu kurulmuştu (tablo 5.1). 1990’lar, pazarda hızlı büyümenin, özellikle ikinci yarıda, görüldüğü dönem oldu. Bu büyüme bir şirketin, SAP’nin büyümesi ile gösterilmiştir (Şekil 5.1). Görece güçlü bir ekonominin olduğu, müşterilerin kendi iç pratiklerini iyileştirmek istedikleri; sonlara

58

doğru da 2000 yılı uyumu (Y2K) aradıkları bir dönem idi. Elbette ki tüm tedarikçiler, bu büyüme dönemini yaşamadılar.

Tab

lo 5

.1 B

aşlıc

a ER

P fir

mal

arı v

e El

değ

iştire

n ba

zı E

RP fi

rmal

arı v

e

59

Bu dönem içinde gelir sıralamasıyla, SAP35, Oracle, PeopleSoft, JD Edwards ve BAAN gibi büyük tedarikçiler ortaya çıktı. Pazarın en büyük olduğu 1997’de bu beş firmanın geliri, tüm dünya gelirinin yarısını aştı. Bu beş firmanın müşteri tabanı, dünyanın her yerine yerleşik büyük firmalardı. Gelir açısından bakıldığında, bu beş firmanın arkasında, ikinci kesimi oluşturan, aralarında DataWorks, IFS, MARCAM, QAD ve SSA’nin bulunduğu orta büyüklükteki tedarikçiler vardı. Bu firmaların müşteri tabanlarını geniş bir sektör yelpazesine yayılmış orta ve büyük şirketler oluşturmaktaydı. Üçüncü kesim tedarikçiler olan Kewill, Tetra, Swan, Excel, ve Fourth Shift’in müşterileri, geniş bir yelpazeye yayılan, ağırlıklı olarak orta ve küçük ölçekli şirketlerdi. Bunların dışında pek çok başka ERP firması daha bulunmaktaydı; ama bunların gelirleri küçük şirketleri veya dar pazarları hedeflediklerini gösterecek şekilde görece düşük düzeydeydi. Benzer şekilde JBA, MARKAM ve SSA finansman problemleri yaşadı. 1990’larda pazardaki büyümenin yavaşladığı gözlendi. İki bin yılı uyumu konusu 1997/8 döneminde ekstra bir talep artışı verdiyse de 1998’in ikinci yarısında global ekonomik durgunluğu ve potansiyel müşterilerin dikkatlerini Y2K konusuna yöneltmelerini yansıtan bir yavaşlama görüldü. 1998’in ortalarından başlayarak yüksek profilli tedarikçilerin konsolidasyonu pazara hakim hale geldi (Tablo 5.1). 1990’lardaki büyümenin bir bedeli oldu. Bazı şirketler için bu bedel çok büyük oldu. En büyük beş firmanın içinde yer alan BAAN,

35 SAP (Systems, Applications and Products in Data Processing), 1972 yılında beş eski IBM çalışanı tarafından Merkezi Almanya’nın Walldorf kentinde kuruldu. SAP Küçük ve orta ölçekli işletmelerden global şirketlere kadar her büyülükteki işletmelerin taleplerini karşılamak üzere dizayn edilmiş olup her gün daha da zorlaşan rekabet ortamında, işletmeler için büyük avantaj taşımaktadır. SAP Genel olarak ERP sektöründe yer almaktadırlar ve güçlü bir ERP çözümüdür. Hatta öyle ki: SAP ve ERP eşanlamda kullanılmaktadır. SAP'nin ayrıca hastaneler, bankalar, ticaret firmaları gibi farklı endüstri alanları içinde özel çözümleri mevcuttur. SAP R/3'deki "R" gerçek zamanlı ("Realtime") veri işleme özelliğini, 3 ise veritabanı, uygulama sunucusu ve istemciden oluşan üç seviyeli uygulama mimarisini simgeler. SAP R/3 , RDBMS (Relational Database Management System - İlişkisel veri tabanı yönetim sistemi) Oracle, Microsoft SQL, Informix sunucularının artılarını da kullanma imkanı sunar. SAP R/3 kendi içinde EDI (Electronic Data Interchange) ,Ofis yazılımlarını destekleyen arayüzü vardır. R/3 1992 yılında, R/2'nin ardından geliştirilmiştir ve pazara sunulmuştur. SAP tarafından geliştirilen diğer ürünler -APO (Advanced Planner and Optimizer)- BW (Business Information Warehouse)- CRM (Customer Relationship Management)- SRM (Supplier Relationship Management) vs olarak özetlenebilir. Türkiye’de yaklaşık 20 bin kullanıcısı bulunan SAP, ERP pazarında dünyada olduğu gibi Türkiyede de lider konumdadır.

60

büyük kayıplar yaşadılar. DataWorks’un hisse senedi fiyatları çok büyük düşüşler gösterdi. Neyse ki bu şirketlerin her biri sonradan başka firmalar tarafından ele geçirildi (Tablo 5.1)

Figür 5.1 1990’lar boyunca Gelişme

Çok sayıdaki başarılı firmayı karakterize eden bir özellik gelirlerinin %10 ila 20’sini ayırdıkları ürün geliştirme yatırımlarıdır. Bu yatırım yeni işlevselliğin geliştirilmesi ile nesne ve bileşen gibi yeni teknolojik gelişmelerin mevcut sistemlere adaptasyonu konuları arasında paylaşıldı. Bu paylaşım, şirketten şirkete önem verdikleri konulara değişim gösterdi. Teknolojilerini yükseltemeyen şirketler için ürünleri kendileri için zaman gecikmeli bir bomba gibi potansiyel tehlike arz etmeye başladı. Bununla birlikte, teknoloji yükseltme konusuna odaklanan firmalar için pazara erişim çok önemlidir. Kendi geleceklerine yatırım yapmaları karlılıkları için çok önemli bir kanal oldu. 1990’lar boyunca bu strateji, IFS gibi bazı firmalara geri ödemeler sağlarken, JBA ve SSA gibi çok geç kalan diğerleri için bir şey getirmedi.

Diğer Gelirler Hizmet Gelirleri

Ürün Gelirleri

SAP AG Gelirleri (mio Euro olarak)

61

Figür 5.2 Dünya ERP Pazarında aktörler

Yeni bin yılın başlamasıyla geleneksel ERP oyuncularında bir doygunluk belirdi ve pazar da olgunluk dönemini yaşamaya başladı. En büyük beş firma dünyanın önde gelen firmalarının tükenmeye başlayan taleplerine fazlaca bel bağlamışlardı. Daha az satın alma güçleri olan orta büyüklükteki firmalar pazarına bakmaya başladılar. Bu pazarın müşterilerinin geleneksel tedarikçileri ile çarpışmaya başladılar. Yıllık ciroları 40 milyon dolardan 900 milyon dolara kadar olan firmaları (kullanılan orta Pazar tanımına bağlı olarak) kapsayan orta büyüklükteki Pazar yeni savaş alanı haline geldi. Mamafih burada ERP çözümünün herhangi bir şekline sahip olmayan az sayıda firma bulunmaktaydı. Dahası bu pazardaki potansiyel müşteriler 1990’ların ikinci yarısında Y2K düzenlemelerinin bir kısmı olarak gereksinimlerini gözden geçirmişler ve ya sistemlerini terfi etmişler ya da yeni sistemler satın almışlardı.

Yeniden ortaya çıkan bir eğilim de tedarikçilerin elektronik, ilaç, yiyecek/içecek gibi bazı dikey sektörlere odaklanmasıydı. Bu strateji tedarikçilerin kendilerini özel uzmanlık veya işlevselliğe göre farklılaştırmaları olanağını verdi. Bu, “tek çözüm her şeye uyar” stratejisiyle çelişen yaklaşım, yalnızca çok az sayıda firma tarafından başarıyla uygulanabildi.

ERP’lerin en fazla birkaç yüz çalışan istihdam eden çok küçük işletmeler tarafından benimsenmesine ilişkin tartışmalar artık bitti. Sağladığı yararların maliyetleri dengelediği görüldü. Bu pazarı hedefleyen geleneksel tedarikçiler, uygun fiyatlandırma stratejileri uygularken; birinci ve ikinci katman satıcıları yüksek fiyatlandırma yaparak bu pazar segmentini görmezden geldiler. Ancak yine de

Diğerleri,

People Soft, JD Edwards, BAAN, Oracle vd..

SAP

62

ERP yazılımları, hızla daha kolay uygulanabilen paketler haline dönüştü. Yarar perspektifinden bakıldığında bir kurulumun geri ödeme sağlamasının ve beklenen yararların gerçekleşmesinin garantisi bulunmamaktadır. Geçmişteki birçok hikaye, ERP uygulamalarının yararlarının genellikle hayal kırıklığı yarattığını göstermektedir (Bölüm 10). Geçmişte daha küçük şirketler için giderler, ciroya göre da büyük, çalışan sayısı da görece daha büyük olduğu için, risk daha yüksekti. Dahası büyük şirketlerde bulunanlardan daha azına sahip oldukları için kurulumun kaynaklar üzerindeki talebi, daha fazlaydı. Ama bu yolu kat etmeyi istemek için oldukça güzel nedenler de vardı. Mevcut sistemler gelişigüzel ve büyüyen işletme hacmini ele almaktan uzaktı. Müşteriler daha iyi kontrol sistemleri arzu etmekteydiler. Kurulum daha açık ve daha iyi tanımlanmış uygulamalar, o zaman kadar elde edilemeyen gerçek zamanlı veri erişimi ve potansiyel ve mevcut müşterilerin daha çok cazip hale getirilmesi gibi sonuçlar getirecekti. Bu kullanılamayan potansiyel müşteri havuzu, birinci ve ikinci katman satıcılarını cezbetti. Bugün bu firmalar özel sektör veya endüstrilere dönük olarak, iş süreçleri modellerine dayalı işletme çözümleri sunmaktalar. Bu çözümler, hızlı kurulum metodolojileri ile kombine edildiklerinde maliyetler, bu daha küçük müşterilerin bütçelerine uyacak şekilde aşağılara çekilmiş oldu.

Bu geleneksel görüntüyü değişmeye zorlayan başka kuvvetler de bulunmaktadır. Müşteri talepleri içe dönük fonksiyonlara odaklanmaktan dışa dönük fonksiyonlara doğru bir kayma göstermekte. Bu kayma şirketlerin müşterileri ve tedarikçileri ile nasıl bir çalışma tarzı arzuladıklarını yansıtmakta. Bu talep elektronik ticaret içinde yükselen iletişim ve bilgisayar teknolojilerindeki gelişmelerle daha da artmakta. Arz zinciri ürünleri i2 Technologies, TXT ve Manugistics gibi firmalardan 2000’lerin başlarından beri temin edilebilir durumda. CRM görece olarak pazarda epeyce yol aldı. Pazar liderlerinden biri olan Siebel Systems Inc., yalnızca 1993 yılında kurulmuş olmasına rağmen çok hızlı bir büyüme gösterdi. SCM ve CRM’in çekiciliği, elektronik ticaretin bu konuları bütünleyici özellik taşıması nedeniyle epeyce arttı. Her iki yazılım grubu da genişleme fırsatları taşımaktalar. Geleneksel pazarın olgunlaşmasıyla ana ERP oyuncuları, kendilerini yeniden düzenlemekte ve hem yeni pazarlara hem de CRM, SCM ve elektronik ticaret gibi başka alanlara da girdiler. Bunu yaparken de daha küçük oyuncuları silip süpürdüler. Pazara girebilmek ve ürün ve uzmanlık geliştirmedeki zaman ve kaynak engellerini aşabilmek için iki stratejiden birini benimsediler. Bu

63

stratejilerden ilki en iyi çözümleri satan firmalarla partnerlik oluşturmak ve ürünleri uyumlu ve komple bir hale getirmek. Alternatif yol, gerekli teknoloji ve yetenek karışımına sahip firmaları ele geçirmek. Bu ele geçirme furyası 1997 ağustosunda, BAAN Aurum firmasını satın aldığında başladı36. 1999 yılında PeopleSoft firması CRM pazarının liderlerinden biri olan Vantive’i ele geçirdi. Farklı satıcı gruplarının bu birleşmeleri pazarın çok net görülememesine yol açtı. Bu durumda büyük beş firmanın hakim pozisyonlarını koruyup koruyamayacaklarını öngörmek olanaksızlaşmış bulunmakta. 5.3 Katma Değer Üreten Tedarikçiler, Partnerler,

Danışmanlar

Yazılım geliştiren firmalar ile müşteriler arasında arayüz oluşturan üçüncü kişi ve kurumların varlığı yeni değildir. 1970 ve 1980lerde müşterilerinin özel uygulamalarını kendi sistemlerinde onlar hesabına çalıştıran bürolar bulunmaktaydı. Bunlar arasında bordro hesaplama en yaygın konu idi. 1990’larda giderek daha fazla müşteri kendi bilgisayar donanımlarını edindi ve yeni bir üçüncü grup firma doğdu; tesis yöneticileri. Tesis yöneticileri müşterilerinin tüm IT fonksiyonunu onlar adına çalıştırmaya başladılar. Bu iş dış kaynak kullanımı, olarak adlandırıldı. Bu çalışma tarzının avantajı IT ekipmanlarına sahip olma ve işletme maliyetini düşürmesi idi. Ekipmanlar müşteri firmanın da olsa tesis müdürü uzmanlık havuzuna sahipti ve gereksinim üzerine çağrılmaktaydı. Müşterinin kendi asıl işine konsantre olmasını sağlamasının yanı sıra onu

36 Baan'ın hikayesi, işletme derslerinde önemli vak’a analizlerindendir. En büyük rakibi SAP firmasına göre en önemli avantajı, ürün ve hizmet fiyatlarının daha ucuz olması ve yaptıkları yazılımların satış sonrası destek konusunda fazla yardım gerektirmemesi idi. Kullanıcılar Baan'ın ürünlerinin basit ama rahat kullanılması konusunda çok memnun idiler. İşletme derslerinde örnek olay olarak seçilmesinin nedeni Baan'ın hızlıca büyürken yaptığı stratejik hatalardır. Şirketin halka açık kısmı üretim yaparken, şirketin kurucusu olan aile üyelerinin kurduğu diğer şirketler ise dağıtım ve satış konusunda hizmet veriyorlardı. Ortadaki sıkıntı şu idi: halka açık olan şirket malını aile üyelerinin yeni şirketine satarken, aile üyelerinin kurduğu şirket olan "Baan Business Systems" satış konusunda sıkıntı yaşıyordu. Bunda da en önemli etken, b2b müşterilerinin Asya krizi ve Rusya krizinden etkilenip giderlerini azaltması ek olarak yazılım piyasasındaki 2000 yılı sorununa değinmek için yazılım giderlerinin bir kısmını bu yöne kaydırması idi. Türkiye'de olsa tam tersi olurdu ancak 90'larda Baan'ın halka açık kısmındaki ortakların cebine büyük miktarda temettü girerken, ailenin kurduğu dağıtım şirketi zarar üstüne zarar etti. Zaten bir süre sonra mali denetim firmaları bu durumu raporlarında belirtince, ortalık karıştı ve Baan hisseleri hızla değer kaybetmeye başladı. Baan bunun üstüne birkaç kez ortaklık yapısını değiştirse de, 90'lardaki gücüne bir türlü ulaşamadı. eskiden SAP’ye kafa tutarken, müşteri portföyüne Ford, Boeing gibi firmaları katabilmişken, bunun devamını getiremedi.

64

yüksek ücret ödenmesi gereken çok sayıda IT personeli istihdam etmekten kurtarmaktaydı.

1998’lerde “ASP - Uygulama Hizmet Sunucu37” cümlesi doğdu. Bu terim pazarlama, altyapı ve uygulama konularında satış, kurulum, uyarlama, işletme, bakım, destek gibi hizmetleri sunan tüm firmaları kapsayacak bir içerik kazandı. Bu gruptaki bazı firmalar bu hizmetlerin tümünü sunarken diğerleri az sayıda konuya odaklandılar.

Bu firmalar, sistem entegratörlerini ve katma değer üreten tedarikçileri de kapsadı. Bu tür firmalarla muhatap olduğunda müşteri uygulama yazılım geliştiricisinden yazılımın lisans bedelini satın almakta sistem entegratöründen veya katma değerli satıcıdan da kurulum ve kurulum sonrası destekleri satın almakta. Pratikte pek çok sistem entegratörü ve katma değerli satıcı donanım, yazılım, kurulum, eğitim, uyarlama destek ürün ve hizmetlerinin tümünü sunmakta. Sistem entegratörü ile katma değerli satıcı arasındaki temel fark ikincinin ağırlıklı yazılım uyarlama faaliyetlerinde bulunması. Ancak bu noktada yazılımın uyarlanmış kısmının teklif hakkının kimin olduğu sorusunun sorulması gerekmekte.

ERP yazılım geliştirici firmalar ile sistem entegratörleri ve katma değerli tedarikçi firmaların iş ortaklıkları, hiç de az değil. Bundan doğan avantaj, geliştirici firmaya ek kurulum kapasite kazandırması ve erişebileceğinin ötesindeki coğrafi bölgelere uzanabilmesi. SAP firması da dahil olmak üzere bu firmalar, ERP firmalarının büyümesine büyük katkılarda bulundular. Müşteri açısından bakıldığında satıcının uygulama yazılımına bu firmaların vakıf olamaması tehlikesi bulunmakta. Bu durumda üçüncü firma ile satıcı firma arasındaki ilişkinin niteliği önem kazanmakta. Bu ilişki zayıf bir sözleşme ilişkisinden güçlü bir partnerlik ilişkisine kadar çeşitli niteliklerde olabilir ve seçim sürecinde bu ilişkinin sorgulanması gerekir. Problem çıkarsa çözüm kimin sorumlu olduğuna karar verilinceye kadar gecikebilir.

Müşteri için diğer seçenek kuruluma yardım edecek bağımsız bir danışman kullanmaktır. Danışman değerli kurulum ve işletme bilgisine sahip olsa da uygulama yazılımını tanımıyor olabilir.

Görece yeni olan veri merkezi kavramıdır. “Büro”ları hatırlatan biçimde bu kurumlar hem uygulamanın hem de altyapının

37 ASP - Application Service Provider

65

sahibidirler. Müşteri uygulama yazılımı ile ilgili geleneksel maliyetleri üstlenmek yerine kullandığı spesifik işlevsellik bedelini aylık olarak ödemektedir. Bu işleve bir aptal/dumb terminal aracılığıyla erişilebilir. ERP uygulamalarını küçük işlerin menzili içine sokmasından başka bu yaklaşım geleceğin hesaplama ortamı olarak da görülmektedir. Ancak tartışılması gereken farklı konular da bulunmaktadır, bunlar arasında güvenlik, veri sahipliği, hizmet güvenilirliği ve yanıt verme zamanı sayılabilir. Henüz doymamış olan bu pazar geliştikçe bu konulara da çözümler oluşturulacaktır.

Özel hizmet sunan bir diğer üçüncü taraf firma EAI - Kurum Uygulama Entegratörü38dür. Sistem entegratörü ve katma değer sunan satıcıdan farklı olarak kurum uygulama entegratörü ERP kurulumunu desteklemez. Onun yerine farklı sistemlerin bütünleşmelerini kolaylaştıran araçları sunar. Bu teknoloji görece yenidir ve sektörün nasıl gelişeceği soru işaretidir. Üçüncü taraf kurumların denkleme dahil edilmesi ile yönetilmesi gereken başka bir değişken daha ortaya çıkmıştır. Mamafih hizmet düzeyinde anlaşma’nın kullanılması ile tartışmaların sona ereceği düşünülmektedir. Bu sistemde anahtar faaliyetler için servis sağlayıcı tarafında kabul edilebilir performans ve sorumluluk düzeyleri tanımlanmaktadır. Konular arasında yanıtlama zamanı, güvenilirlik ve tarihlerin tutturulması gibi konular yer almaktadır. Performans düzeylerine erişilemediği takdirde devreye giren cezai müeyyideler telafi ve tazminatların ödenmesini getirmektedir. www.techrepublic.com adresinde örnek uygulama hizmet sunucuları bulunabilir. 5.4 Kullanıcının korunması

Bir ERP alıcısının satın aldığı uygulamayı kullanmaya başladığı anda hem teknoloji hem de satıcı evrimlerine devam etmeye başlamışlardır. Nasıl devam ettikleri tartışma konusu olabilir. Hareketsiz kalmak satıcının kesinlikle ölmesi, teknolojinin de eskimesi anlamına geleceğinden evrim devam etmek zorundadır. Bundan sonraki bölümler pazar güçlerinin nasıl hareket etmekte olduğuna ilişkin bilgiler sunmaktadır; teknolojinin nasıl sürekli evrim geçirmekte olduğu, tedarikçilerin nasıl sürekli hem kendi işletmelerini, hem teknolojilerini uyarlamak zorunda kaldıkları anlatılacaktır. Bugün gördüğünün yarın nasıl kaybolduğunun farkında olursa müşteri olaylar karşısında sürpriz yaşamaz

38 EAI - Enterprise Application Integrator

66

6 Başlangıç Gereksinimi 6.1 Niçin?

Birileri, bir yerde, yeni bir enformasyon sistemine gerek olduğu kararını verir. Bu karar işletmenin stratejik değerlendirmesinin bir sonucu da olabilir (Kısım 3.1). Tüm stratejik seçeneklerin bir arada değerlendirilmesi gerekse de, enformasyon sisteminin işletme performansı üzerinde büyük bir etkisinin olduğu sonucu kaçınılmazdır. Yeni enformasyon sistemine gereksinim olduğu kararı, genel müdürün kaprisi de olabilir. Bu kişi, bu kararın anlamını idrakten uzak da olabilir. Sistemin maliyeti, kurulum zamanının maliyeti, işler ters gittiğinde şirketin üstlenmiş olacağı risk, işleri yeniden düzeltmenin maliyeti, planlanan karlara ulaşamamanın yarattığı zararlar vb., vb., bunları uzatmak mümkün… Gereksinim, stratejiye de kaprise de bağlansa; kararın sağduyuya dayanması gerekir. Her iki halde de yine ERP sistemine duyulan gereksinimin kanıtlanması gerekecektir. Gereksinimin kanıtlanması, fırsatın keşfedilmesi ve tanımlanması olanağını sunar. Kendi içinde büyük bir iş olan yeni enformasyon sisteminin kurulması, pek çok çalışanı yerinden oynatacaktır. Ancak amaç bir sistemi başkasıyla değiştirmek ise bu fırsat kaybolur. Bu fırsat, işlerin nasıl yapıldığına bakmak ve nasıl daha iyi yapılabileceğini sorgulamaktır. Şimdi süreçlere odaklanma zamanıdır. Yazılım, uygulamada bazı değişikliklerin yapılmasını zorlayabilir; ama bu arzu edilen bir şey midir? Eğer üzerinde yoğunlaşılan konular, süreçlerin kendisiyse; bu, hem yazılım spesifikasyonlarını hem de seçimi etkiler. Vurgulamadaki bu farklılık, önemli örgütsel etkiler yaratır. Eğer IT, bir yer değişikliği yapılmasına odaklanmış ise; çok az kişinin katılımı ile gerçekleşecek kısa dönemli bir proje söz konusu olacaktır. Ama değişiklik süreç odaklıysa; herkesi kapsayacak ve yazılımın canlı kullanımının ötesine geçerek kültür yönelimli bir ortamda sürekli gelişme söz konusu olacaktır. Uygulamanın stratejiye bağlanması, teknolojinin stratejinin gerçekleşmesini olanaklı kılacak bir araç olmasını ve aynı zamanda hem müşterilerin hem tedarikçilerin bundan etkileneceğini gösterir. Ancak sisteme olan gereksinim keşfedilemez ise bu fırsat da kullanılamaz. Gereksinimin kanıtlanması ve fırsatın keşfi, değişikliğin yapılması gerektiğine dönük çıkarsa; bir sonraki soru, bu değişikliğin kimin

67

tarafından yapılacağıdır. Gereksinim, tek bir kişi tarafından mı kanıtlanacaktır, yoksa görüşlerin uzlaştırılmasıyla mı yapılacaktır? Kişi(ler)nin pozisyonu güçlü mü zayıf mı olmalıdır? Gereksinim, başkaları tarafından kabul edilmeli midir; kabul edilmezse, işin üstesinden nasıl gelinecektir? Bu senaryo, çeşitli şekiller alabilir. Ana konular en tepedeki insanın projeye destekçi olması ile izlenecek yolun sağlamlığıdır. Hangi senaryo sahnelenirse sahnelensin, ERP sistemine olan gereksinimin açıkça kanıtlanması gerekir. 6.2 Maliyet

Bir finans müdürünün böylesi bir taahhüdü, açık çek ile desteklemesi çok düşük bir olasılıktır. Bunun yerine işin başında bütçe gereksinimleri saptanır. Bu da maliyet tahminlerine dayandırılır. Hangi alanlarda maliyetlerin oluşacağını saptamak için aşağıdaki konular dikkate alınır:

• donanım • işletim sistemi • veri tabanı lisans bedeli • çekirdek yazılım lisans bedeli • ek modül lisans bedeli • üçüncü taraf yazılım lisans bedeli • üçüncü taraf yazılımın entegrasyonu • yazılım uyarlamaları • canlı kullanım için veri dönüşümü • proje yönetimi • danışmanlık • eğitim • ulaşım ve konaklama giderleri • yükseltimler.

Bu maliyet bilgisinin büyük kısmı, tedarikçi firmadan elde edilir. Satıcının her bir maliyet kalemi için hassas rakamlar vermesi düşük bir olasılık ise de alınan değerler, tahmin olarak kullanılabilirler. Yazılımın fiyatı, hassas olarak verilse de kapsamının bu aşamada belirsiz olması nedeniyle alınan bu rakam da tahmin sıfatının ötesine geçemez. Benzer durum, tarihin aşırı harcamalarla dolu olduğu danışmanlık giderleri için de geçerlidir. Bu durumda her bir maliyet kalemi için alt, üst ve en olası değerler belirlenerek potansiyel maliyetlerin doğru olarak yansıtılmasına çalışılır.

68

Bazı maliyet kalemleri, bir defalık harcamalar (donanım, eğitim, danışmanlık vs.) ise de diğerleri (bakım vs.) devam eden türdendir. Maliyetlerin daha doğru biçimde ortaya çıkarılması için uzun dönem açısından ele alınmaları zorunludur. Üzerinde anlaşılmış zaman ufku, beş yıldır. Beş yıl geçtikten sonra büyük olasılıkla yazılım gözden geçirilecek ve yükseltim ile kapsamlı ek fonksiyonların kazanımı benzeri ek çalışmalara dönük olarak yeni bütçe yapılacaktır.

Unutulmaması gereken bir konu da: çoğunlukla içerden kaynaklı dolaylı maliyetlerdir. Bu kapsamda aşağıdaki başlıklar gündeme gelir:

• proje süresi ve bu süre içindeki çalışanların maliyetleri • projeye dahil edilen kişilerin yerine geçici olarak

görevlendirilen kişilerin maliyetleri • proje üzerinde çalışmak nedeniyle yapılamayan diğer işlerin

getireceği ek maliyetler • ofis dışı yolculuk ve konaklama giderleri, örneğin eğitim

amaçlı… • iç kaynaklara dayanan maliyetler, örneğin; IT departmanı,

sistemi kimin yöneteceği, bakımını yapacağı ve iç teknik destek vereceği…

Tablo 6.1 maliyetlerin beş yıllık süre içinde nasıl bir kırılım göstereceğini sergilemektedir. Yıllık bakım maliyet tutarının toplam bütçenin ne kadar yüksek bir payını kapladığını görmek şaşırtıcıdır. Bu ödemenin karşılığında neyin alındığı sorulmaya değer bir konudur. Açık bir şekilde her bir durum, süreçlerin karmaşıklığı, kullanıcı sayısı, uyarlama konuları, danışmanlara bağımlılık gibi etmenlerin değişmesi nedeniyle farklılık gösterecektir. Tüm bunlara rağmen maliyetleri, özellikle ana maliyet kalemlerini biraz daha dar bir alana hapsetmek olanaklı olmalıdır. Yalnız bu durumda çoğunlukla beklenmeyen olaylar gerçekleşir ve maliyet yapısı bozulur. Bazı maliyetler, açık değildir ve gözden kaçırılabilirler. Bazen de küçümsenirler. Bütçe sabit tutulup proje ilerledikçe maliyetler yükseliş gösterirse tehlike de artar. Bu konu özellikle eğitim ve danışmanlık kalemleri için geçerlidir. Danışmanlık harcamalarının bütçe dışına taşması çoğunlukla eğitim maliyetlerinden kısıntı yapılarak karşılanır. Ancak bu tutum, eğitim maliyetlerinin ilk saptanan değerinden daha düşük düzeyde gerçekleşmesine yardım etmez. Burada karşılaşılan ikilem, proje başlanırken ne kadar yatırım yapılmış ise o kadar harcama

69

yapılmasıdır. Ancak bunun maliyeti nedir? Bu nedenle tüm proje boyunca maliyet kontrolü yapılması zorunludur. Proje planlama yazılımları, maliyetlerin faaliyetlerde kullanılan kaynaklara dayandırılması özelliğine sahiptir. Bu özellik dolaylı maliyetlerin belirlenmesi olanağını sunar. İşlemlerin tamamlanmasından sonra plan güncelleştirilerek fiili kaynak kullanımını ve harcanan zamanların toplamlarına erişilir. Bu toplamlar, fiili maliyetler hakkında fikir verirler ve iç personelin yarattığı maliyetlerin ölçümü için çok faydalıdır. Pratik açıdan bakıldığında maliyetlerin en fazla kontrol dışına çıkma eğilimi gösterdiği alan danışmanlık hizmetleridir. Satıcı firmanın personeline ödenen bedellerde beklenmeyen durumların ortaya çıkması durumunda hemen artışlar gösterir. Dolayısıyla sabit maliyet yaklaşımındansa; zaman ve malzeme tüketimine dayandırılacak bir maliyet sisteminin kurulması arzulanır. Teklif aşamasında bu durum daha yüksek bir tutar görüntülese de gerçekte durum tam tersidir.

Tablo 6.1 ERP Uygulamasının Toplam Maliyeti

70

6.3 Doğrulama- maliyet-yarar

Gereksinim ve maliyetler tanımlandıktan sonra yararların ne olduğunu belirlemek ve bu yararların maliyetleri karşıladığını belirlemek lazımdır. Bu sağlama, gereksinim hakkındaki kanıtı kuvvetlendirecektir. Gerçi bu sağlamanın nasıl yapılacağı ikilemi de birlikte doğacaktır. ERP kurulumu doğası itibariyle karmaşık bir faaliyettir. Uzun bir zaman dilimi boyunca koordineli biçimde hareket edip arzulandığı gibi fonksiyon göstermeyebilen bir teknolojiyi kullanarak çalışma üretecek çok sayıda kişiyi kapsar. Dahası hangi muhasebe tekniğinin kullanılacağına ilişkin anlaşmazlık da yaşanır; geri ödeme dönemi yöntemi mi kullanılacaktır, yoksa iskontolanmış nakit akımı mı? Her ikisinin de gerçeği kötü yansıttığı ileri sürülebilir. Benzer durum, yararların belirlenmesinde de yaşanabilir. Tutulan stok miktarlarındaki azalmanın getireceği somut yararlar doğru olarak sayısallaştırılabilirken daha verimli operasyonlar sayesinde gerçekleşecek gelir artışların kanıtlamak zor olacaktır. Dahası tüm soyut yararların sayısallaştırılması zordur. Mamafih pratikteki bakış açısıyla bu egzersiz, tam doğru olamayan ve tam doğrulukla talep edilmeyen bir bilimselliktedir. Amaç, durumun beklentilere bağlı kalarak yararlı bir fotoğrafını çekmektir. Tanımlanan maliyetler geleceğe ilişkin nelerin anlaşıldığına ve kazanılması beklenen yararlar çerçevesinde değerlendirilir. Genellikle beş yıl olan zaman dilimi içinde pek çok şey olabilecektir. Bu nedenle yaklaşımın sade ve varsayımların açık biçimde tanımlanmış olması gerekir. Bu analiz, aynı zamanda referans noktalarının ve mihenk taşlarının oluşturulmasında da kullanılabilir. Bunlar gelişmeleri değerlendirmede; böylelikle beklenen yararlara ulaşılıp ulaşılmadığını anlamada kullanılırlar. Dahası potansiyel kazanımlar konusunda tedbirli olmak gerekir. Tarih maliyetlerin zaman içinde yükseldiğini, yararların da gerçekleşmeme eğilimi gösterdiğini yazmaktadır. Bu maliyetleri kontrol edip, yararların gerçekleşmesini sağlayacak proje yöneticisi yeteneklerinin dışında bir konudur. Sonuçta dikkatler sağlama işleminin hangi kontekst içinde yapılacağında toplanır. Sağlamayı kim yapacaktır? Şimdi ve gelecekte mihenk taşlarını kullanacak diğer kişiler kimlerdir? Gelecekte durum değişiklikleri meydana geldiğinde spesifik mihenk taşları da değişikliğe uğrayacaktır. Çok daha sık bir şekilde tahmin edilen rakamlar, adeta taşa kazınmıştır ve değişiklikler oldukça bu rakamlar, anlamsız hale gelecek ve kullanılmaz olacaktır.

71

Burada sunulan yaklaşım, çok sade olup büyük resmi görmeyi amaçlamaktadır. Daha detaylı yaklaşımlar Remenyi et al. (2000)’da bulunabilir. Başlama noktası, mevcut iş süreçlerinin sade bir haritasını üretmektir. Bu yaklaşım, anahtar alanlara sistematik biçimde dikkat çekilmesini teşvik eder. Hipotetik bir örnek şekil 6.1’de sunulmuştur. Bu örnekte imalat yapan ve işlerin manuel olarak kağıt bazlı bir sistem üzerinde yürütüldüğü varsayılmaktadır. Harita incelendiğinde bir satış siparişi alma noktasında müşteriden bir akışın başladığı görülmektedir. Prosesin ilerlemesine bakıldığında aşağıdaki yararların elde edilebileceği düşünülmektedir.

72

Müşteri ilişkileri:

• müşteri sipariş sorgulamalarını yöneterek daha iyi yanıt zamanları sağlanabilir.

Üretim çizelgeleme:

• müşteri taleplerini değiştirmenin etkilerini değerlendirme yeteneği ve üretim çizelgesini optimize etme yeteneği kazanmak

• stok için üretimden çok sipariş için üretim yapma tarzına geçmek, böylelikle bitmiş ürün stoklarını azalmak ve stokların demode olma olasılıklarını azaltmak.

Malzeme gereksinimleri:

• gereksinimlerin ve potansiyel daha iyi görülmesini sağlamak, böylelikle hammaddesiz kalma olasılığını azaltmak.

Tedarikçi yönetimi:

• sınırsız satın alma tarzına geçerek haftalık tesellüm çizelgeleri hazırlamak, böylelikle envanter düzeylerini düşürmek, sonrasında da depolama ve finansman maliyetlerini azaltmak.

Malzeme yönetimi:

• satın alma emirleri ile tesellüm detaylarını on-line olarak karşılaştırmak, böylelikle kontrolü artırmak

• malzemelerin izlerini daha iyi sürebilmek, böylelikle kayıp malzemeleri azaltmak

• gerçek zamanlı stok hareketleri kayıtları yapmak, böylelikle güncel envanter analizlerini yapmak, yavaş hareket eden veya hareketsiz kalmış stokları saptamak.

İmalat:

• Süreç içi stokları daha iyi görmek, süreçleri izlemek, böylelikle müşterilerin siparişlerini teslim alma zamanlarını daha doğru biçimde öğrenmelerini sağlamak

• Daha iyi ve daha hassas imalat enformasyonu daha az hata yapmayı ve kısa temin sürelerini getirir.

Sevkiyat

73

• daha etkin dokümantasyon son ürünlerin daha hızlı sevkıyatı sağlar.

Kalite:

• on-line veri toplama iyileştirilmiş kalite enformasyonu getirecek, bu kalite problemlerinin azalmasına yol açacak, böylelikle müşteri iadeleri azalacak, bu sayede onarım maliyetleri ile garanti yükümlülükleri hafifleyecektir.

Muhasebe:

• satış, imalat ve satın alma fonksiyonlarının bütünleşmesi, böylelikle operasyonel performansa ilişkin gerçek zamanlı enformasyon sağlanabilecektir

• konsolide faturaların veya kendi kendini faturalama yönteminin uygulanması doküman işlem yükünü hafifletecektir.

Genel:

• iş akış mantığına geçiş daha kısa süreç döngü süreleri getirecektir

• gerçek zamanlı ve on-line veri erişimi daha az dokümantasyon demektir

• verilerin kaynağında girilmesi tekrarlanan veri girişlerinin önüne geçecek, böylelikle veri girişlerinde hata yapma olasılığı azalacaktır. Bu da veri hatalarından kaynaklanan problemlerin çözümü için harcanan zamandan tasarruf getirecektir.

Soyut:

• daha kolay ve etkin problem çözümü • daha verimli ve mutlu bir çalışma ortamı • işletmeyi iyileştirmede daha etkin ve proaktif bir tutum

takınılabilecektir.

Bu listenin tüm yararları yansıtmadığı bellidir. Bazı gözlenmeyenler yararlar dışında dikkat edilmemiş fonksiyonlardan kaynaklanan veya yeni uygulamayı buluşçu yollarla kullanmaktan doğan yararlar da sağlanabilir.

Bu çalışma kapsamındaki bir varsayım da işlerin yapıldığı tarzlarda değişiklik olacağıdır. İşlerin yapılması konusunda başka bir vizyon geliştirmenin yararlar getirmesi de beklenmelidir. Sık sık yeni teknolojinin personel sayısında azaltma getireceği ileri sürülür. Gerçekte bu durum seyrek olarak gerçekleşir. İşin doğasında olan

74

değişiklikler özel işlerin elimine edilmesine neden olabilir. Öte yandan yeni işler ortaya çıkar. Bu çalışmadan edinilen derslerden biri projenin IT sistemi ile ilgili olmadığıdır. Proje insanla ve değişim yönetimi ile ilgilidir.

Yararların sayısallaştırılması maliyet konteksti içinde değerlendirilecek ölçütler ortaya koyar. Sayı üretmek kolay, sayılar da hassastır. Çoğu zaman spekülasyondan medet umulur. Ancak yararlar konusunda iyimser olmak tehlikelidir. Yararlar gerçekleşemez ise bu yalnızca onların yarar potansiyeli taşımamaları nedeniyledir. Belki de en kötü öngörüleri yapmak en iyisidir ve ne beklendiği rakamla ortaya konmalıdır. Sayısallaştırmanın zor olduğu yararların yine de erişilebilecek yararlar olduğu hatırdan çıkartılmamalıdır. Bu tür yararlar nelere erişebilecek olduğumuzu daha iyi anlamamıza katkıda bulunur.

Yararların maliyetleri aştığını varsaymak yürürlüğe koyacağımızı doğrulamak anlamına gelir. Sayısallaştırma ise kurulumun başarısını değerlendireceğimiz bir kriter (mihenk taşı) oluşturur. Gelecekteki koşullara ilişkin sınırlı bir vizyonumuz olduğunu göz önüne alırsak; bu rakamları dikkatle yorumlamamız gerekir. Gerçekte bu vizyon kusurludur ve gelecekteki fiili koşullar başlangıç düşüncelerinin çok ötesinde oluşabileceği takdir edilmelidir. Eğer rakamlar saplantı haline gelirse, oluşabilecek bir negatif sapma başarısızlık olarak görülecek ve gösterilecektir. Bununla birlikte bu mihenk taşlarına pozitif bakış açısıyla yaklaşmak, yalnızca arzulanan hedefler koymak anlamındadır. Bu hedeften oluşacak negatif bir sapma incelendiğinde iyileştirme fırsatlarını ortaya çıkacaktır. Pozitif sapmanın gözden geçirilmesi ise orijinal hedefin uygun olmayan bir biçimde belirlendiğini düşündürecek ve sonuçta daha gerçekçi bir hedefin ortaya konmasını sağlayacaktır.

Yararların bu şekilde gözden geçirilmesi sistemin değerinin teknolojinin içinde değil, ama teknolojinin kullanış tarzında olduğunun fark edilmesini sağlayacaktır. Bu önemli nokta teknolojinin sunduğu fırsatın bir stratejiye erişme amacı olarak görülmesi gerektiğini ortaya koymaktadır. Dahası rekabetçi avantaj teknolojinin buluşçu bir şekilde kullanılmasıyla kazanılabilir, hele rekabet aynı ya da daha iyi teknoloji üzerine kurulmuşsa. Bu nedenle uygulama yazılımını işletme stratejisi konteksti içinde düşünmek anlamlı olacaktır.

75

7 Gereksinimlerin Tanımlanması Gereksinimlerin tanımlanması, kalabalık bir ekibin çalıştığı; tüm detayların yüksek hacimli dokümanlar oluşturacak şekilde kaydedildiği; çok zaman alan bir uğraştır. Tanımlama çalışmaları sırasında süreçlerde değişiklik olmadığı, olsa da tanımlama ekibinin bundan haberdar olup gereksinimler üzerinde güncelleme yapıldığı varsayılır. Gerçekte süreçlerin statik kalması olanaksızdır. Tersine süreçler, müşterilerden gelen taleplere yanıt vermek, problem çözme çalışmaları yapmak, personel değişiklikleri, işleri daha iyi yapma arzuları gibi etmenlere bağlı olarak sürekli değişim gösterirler. Değişiklikler farklı detay ve etki derecelerinde ortay çıkarlar ve hepsinin izlerini takip etmek de hayli zordur. Bütün bunlara bağlı olarak gereksinimlerin tanımlanması faaliyetleri sırasında hangi detay düzeyinde çalışılması gerektiği sorusu ortaya çıkar. Yazılımın çalışmanın kullanımından yaklaşık dokuz ay önce yapılacağını düşünürsek aradan geçecek zaman içinde bazı detaylar kaybolacak, yerlerine yenileri gelecek, öte yandan bazı detaylar atlanırsa da gereksinimler yanlış veya eksik tanımlanmış olacaktır. Bu soruya optimum yanıt için Michael Hammer “ERP kurulumu şirket içinde kültürel değişim ve değerlerin ortaya çıkması için bir fırsattır” yorumunu yapmaktadır. Bu yorum yeniden yapılanma kavramını ve işgücünün mobilizasyonunu çağrıştırmaktadır. Gerçekte soruya yanıt vermek için “biz ne yapmak istiyoruz?” sorusuna yanıt vermek gerekir. Bu yanıt; “en iyi uygulamalar” olsa bile yine de işletmeyi ve süreçlerini dikkate almayı gerektirir. Gerçekte en iyi uygulamalara bir gecede erişilemez. Onun yerine en iyi uygulamaların geliştirileceği altyapının kurulması gerekir. Gereksinimlerin tanımlanması perspektifinden bakıldığında şirketin neyi arzuladığını bilmesi gerektiğini söyleyebiliriz. Üzerinde düşünülecek diğer konu gereksinimlerin ölçeğidir. Kurulum şirketin bir kısmını mı yoksa tamamını mı kapsayacaktır? İnsan kaynakları ve bordro çok uygun bir sistem olarak görülebilir. Benzer şekilde pazarlama kendi veri tabanı üzerine kurulu genel amaçlı bir yazılım kullanıyor olabilir. Kalite departmanı istatistiksel proses kontrol desteği veren, dokümantasyon yönetimi sağlayan, eğitim ve hatalı ürün kayıtlarını tutan özel bir yazılıma sahip olabilir. Diğer mevcut yazılımlar da uygun görülebilir. Bütün bu bağımsız uygulama yazılımlarının entegre edilip edilmeyeceği arzusu üzerinde düşünmek gerekir. Bu arzu imkansızlık ve yüksek

76

entegrasyon maliyetleri ile çelişir. Eğer ERP içinde benzer işleri yapabilecek modüller var ise şirketin özel gereksinimlerini mevcut sistemlerden ERP ortamına taşımanın avantajlarını ve dezavantajlarını değerlendirmek sonraki bir tarihe bırakılabilir. Bu aşamada tanımlanan kısıtlar da o tarihte yeniden gözden geçirilir. 7.1 Başlarken

Gereksinimleri saptamanın çeşitli yolları bulunur. Amaç süreçleri tanımlamak, neler yaptığını belirlemek ve üzerinde çalışılacak anahtar konuları ortaya çıkarmaktır. Bütün bunlar bir listede toplanır. Bir işletme analistinin gereksinim tanımlamada kullanabileceği daha formel araçlar da bulunur. Bunlar arasında veri akış diyagramları, kişi-ilişki diyagramları ve IDEF modelleri bulunur. Ancak çoğu şirkette bu tür uzmanlık ve kaynaklar bulunmaz. Bu şirketlerin bazıları, bu işi dışarıya yaptırmayı yeğlerler. Bu tercih, tüm süreçleri detaylı bir şekilde ortaya koyan dokümanların üretimini sağlasa da, bu çalışma sırasında edinilen bilgi birikiminin şirket içinde kalmaması gibi bir dezavantaj söz konusudur. Dolayısıyla bu çalışmanın şirket içinde yürütülmesine hiç de az rastlanmaz. Aslında bu analiz çalışmasının iki yönlü değeri bulunmaktadır. İlk olarak süreçlerin detaylarının yakalanmasına ilişkin problemlerin öğrenilmesine katkıda bulunur; ki bu alanda edinilen öğrenme yeni süreçlerin tasarımında işe yarayacaktır. Dahası analizi yürüten kişi işletmeyi ve işletmeyi etkileyen konuları çok iyi biçimde kavrayacaktır. Bir süreci tanımlamak için sürecin ne olduğunu anlamak gereklidir. Her ne kadar bu konu 12.2 no’lu kısmın içinde ele alınacaksa da, aslında bir süreç birbirlerine bağlı kara kutuların oluşturduğu bir ağdır. Her kara kutu, girdileri çıktılara dönüştürür. Her girdi, başka bir kara kutunun çıktısıdır, benzer şekilde çıktılar da başka kara kutuların girdileridir. Her kara kutudan toplanan verilerin incelenmesiyle dönüştürme işlemlerini doğasını açığa çıkaracak ve sonuçta bu dönüştürme işlemine uygun bir ad konmasına yol açacaktır. Tüm kara kutular tanımlandıktan sonra ilişkilerinin haritası çizilebilir. Bu harita örgüt içindeki tüm süreçlerin akışlarını gösteren süreç diyagramıdır. Süreç diyagramına ilişkin sade bir örnek şekil 6.1’de çizilmiştir. Bu işin pratikte uygulanması için çeşitli seçenekler mevcuttur. Bir yaklaşım tüm süreçlerin içinde yürümek, kimin ne yaptığını tanımlamak, hangi materyallerin kullanıldığını, üretildiğini, bunları kimin sağlayıp kimin aldığını tanımlamaktır. Bu materyaller raporlar, tedarikçiden gelen, müşterilere giden raporlar, iç dokümanlar,

77

planlar, bilgisayar ekranları olabilir. Bir şey yapılan her nokta kara kutu olarak tanımlanır. Amaç tüm detayları kaydetmek, birbirini takip eden iç ve dış müşterileri not alarak tüm süreçleri içeren haritayı hazırlamaktır. Bu yaklaşımın getireceği problem neler olup bittiğinin yalnızca sade bir görüntüsünü ortaya koyması, izlerin farkına varılamamasıdır. Bu işle uğraşan kişiye yönetimin olayların kayıtlarını tutmasını söylemesi gerekir. Alternatif bir yol kısım 12.2.2’de toparlama /kolaj adıyla açıklanmıştır. Burada anılan yolun detaylarını vermeyip, yalnızca amacının tek kişinin tüm süreçlerin ayrıntılarını mevcut dokümanlardan yakalayarak büyük ve geniş tablolar halinde toparlamak olduğunu söylemekle yetinelim. Bu şekilde üretilen kağıt üzerindeki enformasyon süreçler hakkında en fazla bilgiye sahip personel ile görüşmeler yapmak için kullanılır. Bu görüşmeler sırasında en iyi uygulamaların geliştirilmesi, işlerin yapılacağı tarzın saptanması fırsatları kullanılmış olur. Yine bu görüşmelerde derhal etki veren değişiklikler ve kusur giderici önlemler alma olanağı da bulunur. Sonuçta her faaliyet tanımlanır ve gereksinim duyulan konular saptanmış olur. Diğer deyişle yalnızca sürecin temel taşları konuşulmaz, ek olarak arzulanan özellikler listesi de hazırlanır. Bu noktada temel gereksinimler ile, arzu edilen gereksinimleri birbirlerinden ayırmak gerekir. Dil, döviz, virgülden sonraki hane gibi özel gereksinimler kategorisi de oluşturulur. Bu aşamada yabancı bir yazılımın yerel vergi oranlarını sağlayamaması gibi durumsal gereksinimlerin gözden kaçırılmaması gerekir. Süreçlere ilişkin genel bir bakış açısı veren harita oluşturulduktan sonar faaliyetler listesi ile desteklenir ve çözüme bağlanması gereken konuların altı çizilir. Toparlama/kolaj işlemi çıktısı satıcı firmalarla gereksinimleri müzakere ederken çok yararlı bir araçtır. Burada yine tüm konsantrasyonun dokümanlara verilemesi, oysa ekranların bundan farklı olması nedeniyle doğabilecek sakıncalar da bulunmaktadır. Her iki halde de çalışma yönteminin de kayıt altında tutulması gerekir. Her iki yaklaşımda da normlardan oluşabilecek sapmaların gözden kaçırılması olasılığı bulunmaktadır. Sapmalar yeni sistemden talep edilecek özellikler için temel noktaları oluşturmaktadır. Bu sayede analist sürecin her noktasındaki sapmalara karşı alarm halinde olacak ve onları nasıl ele alacağını bilebilecektir. Mamafih hiç arzu edilmeyen mevcut yapı ve uygulamaların tekrar tanımlanması tehlikesi de vardır. Benzer şekilde süreçlerin stabilitesi konusuna dikkat etmek gerekmektedir. Süreçler statik ve değişmeyen yapıda mıdırlar, yoksa gereksinimler

78

doğrultusunda sürekli evrim geçirmekte midirler? Süreçler zaman içinde değişmekte ve gelişmekteyse gelecekteki gereksinimleri belirlemek son derece zordur. Hal böyleyse satın alınacak yazılımın esnek olması büyük önem taşır. Olmazsa olmaz gereksinimler ile olursa iyi olacağı düşünülen geleceğin gereksinimlerini birbirlerinden ayırmak zorunludur. Bu yapılırsa temel gereksinimlerden uygun olmayan yazılım ürünlerinin elenmesinde yararlanılacaktır. Bu ayrımı yapmak özel verilerin veya özel raporların üretilmesini gerektirebilir. Örnek olarak dövizle hazırlanan faturalar, son ürünlerin çoklu faturaları veya satın alma siparişleri ile tesellüm makbuzu ve satıcı faturası üçlüsünün birlikte işlenmesi verilebilir. Bu işlemler yaparken aşırı detayların özellikle süreç değişikliklerinde getireceği gereksiz yedekleme ile özel gereksinimlerin gözden kaçırıldığı yetersiz detay düzeyinin dengesinin gözetilmesi gerekir. Bu dengelemeyi etkileyen unsurlardan biri de kullanılabilecek zamandır. Bu çalışmanın sonunda analist satıcılara doğru zamanda vereceği gereksinimlerin açık ifadesini üretmiş olur. Bunun ikramiyesi de analistin satıcılarla yapacağı görüşmede kendisine çok yararı dokunacak işlemeyi çok iyi anlamış olması gerçeğidir. 7.2 Gereksinimlerin nasıl karşılanacağı

Artık gereksinimlerin neler olduğunun bilincine varılmış olup sıra bunların nasıl karşılanacağının saptanmasına gelmiştir. Bir düşünce bir satıcının ERP paketinin tüm gereksinimleri karşılayabileceğidir. Büyük satıcılar olan SAP, Oracle gibi ürünler için bu doğru olmakla beraber pratikte maliyet ve zaman gereksinimi sorunlarıyla karşılaşılır. Bu sistemlerin gerektirdiği zaman ve maliyet tutarı özellikle küçük ve orta ölçekli işletmelerin bütçelerinin hayli ötesindedir. Diğer satıcılar özel fonksiyonlarla ilgili modül veya bileşen sunmakla birlikte uzmanlık paketleriyle işlevsellik açısından kıyaslandığında ürünleri çok temel kalmaktadır. Tek bütünleşik, büyük sistemin avantajı tekrarlanan veri girişlerini engellemesi ve işletmenin her yerinde aynı konuyla ilgili tek bir rakam üretmeleridir. Herkes aynı verilere bakar. Gerçekte gereken tüm veriler ERP sistemi tarafından yakalanmaz. Ek veriler diğer veri tabanlarına veya hesap tablolarına kaydedilir. Ancak pek çok uygulama yazılımında bu tür veriler için ek alanlar bulunur. Bu ek alanlar müşterinin uygulamayı uyarlamasını ve üstelik bunun da yükseltim (upgrade) işlemi sırasında sorun olmamasını sağlarlar. Ancak uyarla ek maliyetleri de beraberinde getirir. Dahası daha özel gereksinimler söz konusu olduğunda da

79

bir uzmana başvurmayı veya çeşitli yazılımların en uygun modüllerini bir araya getirmeyi (best-of-breed) gündeme taşır. Farklı yazılımların en iyi ya da en uygun modüllerinin bir araya getirilmesi ile yapılacak çözüm daha önce denemiştir. Uzman paketler çoğunlukla uzun yıllar süren geliştirme çalışmalarının ürünleridir ve özel alanlara odaklanmışlardır. ERP yazılımlarında rastlanmayacak derecede uzmanlık içerirler. Hem lisans hem kurulum olarak yüksek maliyetlidirler. Kurulumları kendileri tarafından belirlenen proje yönetimi gerektirir. Bununla birlikte bu kitapta yapılan tüm yorumlar bu yazılımlar için de geçerlidir. Bu yazılımlarla ilgilenen kişi sayısı çok az olsa da. Burada temel faktör bu yazılımların kendi şebekelerine dahil olmalarıdır. Entegrasyon için ekstra maliyet getiren özel bir bağ kurulması gerekebilir. Ancak bu gereksinim satıcı firmaların müşterilerinin gereksinimlerini fark ederek yazılımlarına dahil ettikleri entegrasyon özelliği sayesinde giderek azalmaktadır. Hangi yolun seçileceği kararının verilmesinde kullanılacak faktörler, değerlendirme sürecinin tamamlanmasına kadar açıklığa kavuşturulamaz. Bu nedenle müşteri iki veya daha fazla seçim sürecini paralel yürütebilir. Bazen bu yollar, nihai seçim yapılıncaya kadar da devam eder.

80

8 Tedarikçinin Seçimi ERP sistemlerinin satıcısı, hem uygulama yazılımını hem de onun nasıl kullanılacağına ilişkin beceriyi sağlar. Tedarikçi, aynı zamanda uygulama yazılımının nasıl kurulacağına ilişkin uzmanlık bilgilerini de sunar ki: bunun içinde başarı için önemli olan şirket içi koşulların oluşturulması da vardır. Bu beceri ve uzmanlığın başarılı transferi, satıcı ile kurulan ilişkilerin kalitesini yansıtır. Satıcı ile yapılan görüşmelerin süresi kullanılacak yazılımın süresi içindir. Bu açıklamalardan anlaşılacağı gibi doğru tedarikçinin seçimi, önemli bir süreçtir. Müşteri, yazılımın yaşam çevrimi boyunca satıcı firma ile birlikte çalışacaktır. İlişkinin doğası, müşterinin satıcı firmaya oldukça bağımlı olması şeklindedir. Bu ilişkide satıcı/tedarikçi kendi uzmanlığını yazılımın kurulumu ile riskleri en aza indirmek için kullanmak durumundadır. İlişkide zorluklar ortaya çıkarsa müşteri, bunları elinden gelenin en iyisini yapacak şekilde yönetmelidir. İlişkileri kötüleştirmenin cezası, en iyi halde yazılımın bedeli ile o zamana kadar yapılan çalışmaların karşılığının toplamından oluşan proje maliyetidir. Pek çok şirket için de bu oldukça yüksek bir meblağdır. Bu meblağ, kaybolan zamanın kaçan fırsatların ve eski sistemi kullanmanın getirdiği kayıpların dışındadır. Bunların sonucunda müşteriler, ortak iş arkadaşları ile yaşamayı öğrenirler. Mamafih sorunlu bir ilişki içinde yaşamak her iki taraf için de sinir bozucudur ve gelişmelerin önünü kesecektir. Dolayısıyla satıcının seçim sürecine dikkat etmek yararlı olacaktır. 8. 1 Tedarikçinin nasıl seçileceğine karar vermek

Etkin tedarik yönetiminin kritik aşamalarından biri de tedarikçi seçim sürecidir. Satıcının iyi seçimi şu beş yoldan biri ile yapılabilir:

• rastlantısal • komşu, arkadaş tavsiyesi ile • isim yapmış satıcılara yönelmek suretiyle • işi uzman(lar)a devrederek • sistematik ve özenli çalışma ile.

İlk yaklaşım, hızlı ve zaman zaman başarılı olabilse de, başarı olasılığı şansa bağlı ve dolayısıyla da oldukça düşüktür. Başarılı seçim olasılığı ikincide daha yüksektir. İlişkilerin daha iyi kurulma olasılığı çok daha yüksek olmakla birlikte ürünün en iyi veya uygun olmasının garantisi bulunmamaktadır. Üçüncü yaklaşım şimdiye kadarkilerin en iyisidir, çünkü şöhret üründen önce gider! Ancak

81

tedarikçinin şöhretinin/isminin iyi olması, kullanıcı işletme için iyi olduğu anlamına gelmez. Bir diğer seçenek, danışman kullanmaktır. Maliyetin yüksek olmasının dışında danışmanın şirketi bilmemesi nedeniyle çalışmasında ortaya çıkaracağı bulguların kabul edilebilirliği tartışma konusudur. Üstelik danışmanın piyasa hakkında önyargısız olup olmadığı, hatta bir satıcıya özel yakınlığı bulunup bulunmadığı da ayrı konulardır. Kurulumdan sonra, satıcı firma ile ilişkilerin problem olması halinde neler olacağı da düşünülmelidir. Beşinci yaklaşım, daha fazla zaman gerektir; doğru seçim yapma garantisi de bulunmamaktadır. Ancak yanlış tedarikçinin seçilme olasılığı iyice azaltılmıştır. Kullanılan seçim kriterlerine bağlı olarak işletme gereksinimleri için daha iyi bir uyum yakalanabildiği gibi satıcı firma üzerinde de izlenimler bırakılabilir. Bu notlarda, son yaklaşım üzerinden konu anlatılmaya çalışılmaktadır.

Yaklaşıma karar verdikten sonra seçim sürecine kimlerin dahil edileceklerini belirlemek gerekir. Farklı değerlendirmeler yapılabilir. Yeni sistemin sahipleri kimlerdir, seçim sürecinde yer alacaklar mıdır, alacaklarsa nasıl alacaklardır? Sistemin zorla kabul ettirildiği duygusunu yaratmaktan kaçınmak gerekmekle birlikte herkesin tüm aşamalara dahil olması pratikte olanaksızdır. Dahası projenin bir IT projesi olmadığını hatırlamak ve projeyi IT departmanın sahiplenmesini önlemek de gerekmektedir. Bu şekilde hassas sayılabilecek bir kurum içi uzlaşmaya erişilebilir. Bir olasılık, anahtar müdürlerin ve kullanıcıların katılımını sınırlamaktır. Bu tutum, onların bilgi ve deneyimlerini yazılımın gereksinimlere olan uyumunu değerlendirme olanağı verir. Bu aynı zamanda diğer çalışanlara enformel bilgi yayma olanağı da sunar. Ancak onların seçim sürecinin başlangıç aşamalarında konuya çok fazla dahil edilmeleri de gereksizdir. Dahil edilirlerse işlevselliğin dışındaki konularla uğraşmaya başlama olasılıkları çok yüksektir. Platform ve veri tabanı gibi teknik konularla uğraşan personel, özellikle kurulumdan sonra sistemin bakımından sorumlu olacaklarsa; seçim sürecine daha fazla katılmayı arzulayabilirler. Bununla birlikte eleme listesi (kısa liste) yaklaşımı kapsamında bu kişilerin oluşturduğu küçük ekip, aşağıda görüleceği gibi, sürece ancak üçüncü aşamada dahil edilir. Onlar, satıcı firmaların demolarını ekip olarak izleyerek, her bir ürün hakkında bilgi sahibi olurlar. Daha sonra eleme listesinden bazı firmaları azaltmak için yapılan toplantılara da katılırlar. Satıcı araştırmalarından sorumlu kişi, gruba işlev dışı konularda bilgi verir. Ekip kullanıcıların

82

temsilcisi olarak hangi satıcının eleme listesine dahil edileceğine karar vererek sistemin sahipliğini üstlenmiş olur. Anahtar kısıt, zamandır. Daha gerçekçi biçimde ekibin satıcı ile ilk teması dördüncü aşamada, bu da eğer satıcı firma sayısı üç ya da dört ise, gerçekleşir. Tehlike, kullanıcı dostu fonksiyonlara sahip yazılım tedarikçisinin elenmesi ve listeye zayıf işlevselliğe sahip yazılımların üreticisi olan firmaların girmesidir. Bu aşamada ekip, satıcılarla ilgili tüm konuların kavranması konusunda önemli bir rol oynar; böylelikle satıcı firmanın seçimine araştırmacı değil, ekip karar vermiş olur. Bu şekilde hem karar, hem de kullanıcıların çalışacağı yeni sistemin sahiplenilmesine odaklanılmış olur. 8.2 Eleme listesi metodu

Satıcı onaylama süreci dört aşamayı kapsar: • aşama 1: kimlerin piyasada olduğunu belirlemek (ilk listeyi

hazırlamak) • aşama 2: gereksinimleri karşılama potansiyeli olan satıcılarla

ilgili kısa liste hazırlamak • aşama 3: en uygun olduğu varsayılan firmaların tutulmasıyla

eleme listesindeki firma sayısını azaltmak • aşama 4: nihai seçim.

Bu süreç, pazar bilgilerine bağlı olarak bir kişinin dört ila altı haftasını alır. Sözleşme ve karar tarihlerini de kapsayacak şekilde onay sürecine ilişkin bir planının geliştirilmesi yararlı olacaktır. Bu olayları bir plana bağlamak suretiyle seçim sürecine dahil olacak kişilerin toplantılara zamanında katılmaları, yaşanabilecek gecikmelerin ve randevu çakışmalarının en aza indirilmesi sağlanabilir. Bu süreç boyunca pek çok veri toplanacağından bunlara da bir şekilde değer biçmek gerekir. Verilerin Excel benzeri bir yazılım içinde tutulması yararlı olacaktır. Bu sayede her satıcının zayıf ve kuvvetli yanları karşılaştırılabilecektir. Aynı zamanda herkesin aynı versiyonu almasına dikkat etmek koşuluyla dağıtımı da kolayca yapılabilecektir.

8.2.1 Aşama 1: ilk liste, kimler varmış bir bakalım

Pazarda kimler var? Kimlerle konuşmalıyım? Pek çok ERP satıcısı bulunmakta. İlk aşamada amaç ilgi alanına girebilecek firmaların ön listesini oluşturmaktır. Ticari yayınları tarayarak, web sitelerinde aramalar yaparak ERP çözümü sunan 40-50 firma bulunabilir. Bu

83

görece hızlı bir çalışmadır. Ancak bu aşamada anlamlı bir çözüm bulunup bulunmadığı bilinmez. Yalnızca bulunan satıcılar, sistematik bir şekilde değerlendirilerek gereksinimleri karşılama yetenekleri belirlenebilir. Sonraki aşama 10-15 satıcıdan oluşan ilk eleme listesini üretmektir.

8.2.2 Potansiyel satıcı firmalar

Bu aşamanın amacı, gereksinimleri karşılama potansiyeli bulunan 10-15 satıcıyı saptamaktır. Çok özel gereksinimler bulunmaktaysa, bu liste iki veya üçe indirilerek bir sonraki aşamaya atlanır. Eleme listesi ilk listedeki her satıcının sınırlı sayıdaki (5…10 ) temel kritere göre performansının değerlendirilmesi ile hazırlanır. Bu yaklaşım ağırlıklı olarak masa başında, sektör dergilerinden, fuarlardan, yakın çevreden, internet’ten, aday firmalarla yapılan ilk görüşmelerden derlenerek yapılan bir çalışmadır. Temel kriterler, aşağıdaki başlıkları içerebilir:

• Satıcıların bulundukları yer. Pek çok satıcı yurtdışı kökenli olup kendi ülkelerinin dışında bulunmamaktadırlar. Sizin coğrafi bölgenizde bulunmayan firmalar, hemen elenirler. Ancak temsilci veya partner bulundurup bulundurmadıklarına dikkat etmek gerekir. Eğer varsa bu firmaların tanımlanması gerekecektir.

• Yazılımın yönü. Eğer yazılım ürünü, proses endüstrisine yönelik hazırlanmışsa; montaj gereksinimleri ile ilgili olmayacaktır. Pek çok satıcının kökleri özel endüstriyel sektörlere ve spesifik fonksiyonlara dayandığından ürünleri bazı uygulamalara diğerlerinden daha uygundur. Benzer şekilde destek kadrolarının sahip oldukları deneyim yazılımın yönünü yansıtıcı bir etki yapar.

• Özel fonksiyonel gereksinimler. Genel çözümler içinde bulunulmayacağı düşünülen özel fonksiyonel gereksinimler, örneğin çoklu fiyatlandırma, çok sayıda ülkenin katma değer vergisi oranları vb., yazılım seçeneklerinin elenmesi için uygun bir kriter olurlar. Benzer şekilde özel donanım veya veritabanı gereksinimleri de elek görevi yapabilirler.

• Tamamlanmış kurulum sayısı. Hedef sektörde son üç/beş yıl içinde tamamlanmış olan kurulum sayısı, temel kriterler içinde yer alır. Eğer benzer firmalarda kurulum yapmamışsa satıcı firmadan ürününün gereksinimlere olan uygunluğunu kanıtlaması istenir. Bu durumda değerlendirme, pek çok hayali çalışma yapılmasını gerektireceğinden daha zor

84

olacaktır. Dahası satıcı firmanın sektörünüzde çok az deneyimi var ise ondan fazlaca bir yarar sağlanamayacaktır.

• Maliyet. İmalat ve finansal işlevlerin tümünün (veya hangi temel işlevler gerekiyorsa) kurulması ve belli kullanıcı sayısı için maliyet tahmini de yine temel kriterler arasında yer almaktadır. Burada niyet kuruluma ilişkin olası maliyet konusunda ön fikir edinmek ve bunu bütçe içinde konumlandırmaktır.

• Satıcı firmanın büyüklüğü. Gelir ve kullanıcı sayısı bu konudaki göstergelerdir. Satıcı firma, sürekli ürün geliştirme yapabilecek gelire sahip midir? Eşzamanlı çalışmakta olan müşterilerine tahsis edebileceği yeterli kaynaklara sahip midir?

• Karlılık/hisse senedi fiyatı hareketleri. Satıcı firma, yeterli kazanç sağlayamamak nedeniyle kırılgan bir yapıda mıdır? Hisse senedi fiyatlarının düşüklüğü, kendisini ele geçirilmeye aday bir firma haline getirmekte midir? Buradaki esas mesele, sözleşme sonrasında yazılımın ne kadar destekleneceği, ne süreyle satış sonrası destek alınabileceği ile ilgilidir. Şirketin el değiştirmesi ürünün değerinin düşmesine yol açabilir. Ele geçirme sonrasında mevcut versiyon korunmakla birlikte geliştirilmesine son verilebilir, yeni modüller üretilmeyebilir.

• İlk etki. Kararlarımızı etkileyen en önemli faktörlerdendir. Gözlemlerimize dayanan içgüdüsel bir duygu da olsa ilk temas sırasında satıcı firmanın bir tutumundan da kaynaklansa bu sübjektif kriter, bazı satıcıların listeden silinmesine yol açabilir.

Sonuçta bir sonraki aşamada görüşülecek satıcıların yer aldığı kısa liste ortaya çıkar. Katma değeri oluşturan satıcılarla39 partnerlik yapan firmalarla nasıl çalışılacağı konusunda kısım 5.3 içinde bazı referanslar verilmişti. İşbirliği yaparak katma değer sunan VAR’lar, yazılım satıcısı firma adına kurulum desteği sunarlar. VAR’ın tüm müşteri gereksinimleri konusunda yetkin olması nedeniyle satıcı firma ile herhangi bir temas meydana gelmez. Böylesi bir çalışma durumu söz konusuysa bile değerlendirme sürecinde herhangi bir değişiklik olması gerekmez. Her iki firma da, hem satıcı ve hem de VAR’ın kendisi de tek bir kimlik olarak değerlendirilirler. Mamafih satıcı ile VAR arasındaki ilişkiyi değerlendirmek için ek kriterlere gereksinim 39 VAR - Value Added Reseller

85

duyulabilir. Amaç VAR’ın kurulumu gerçekleştirecek yeterli beceriye ve ürün bilgisine sahip olup olmadığını anlamaktır. Diğer bir amaç da: VAR ile asıl satıcı firma arasındaki işbirliğinin gücünü anlamaktır. Teknik problemlerin çözümünde VAR, bugün ve gelecekte ne kadar etkili olacaktır? VAR gelecekteki ürün yükseltimleri içinde destek verme pozisyonunda mıdır? 8.2.3 Aşama 3: Listeyi kısaltmak

Firma sayısını üç ya da dörde indirmek amacıyla yapılan daha detaylı bir analizdir. Satıcıların daha iyi değerlendirilebilmesi için kriter sayısı daha da artırılır. Tablo 8.1 kullanılabilecek kriterleri ana hatlarıyla göstermektedir. Amaç görece güçlü ve zayıf taraflarının değerlendirilebilmesi için satıcıların profillerini yeterli hassaslık derecesinde belirlemektir. Bu aşamada yaratılan seçim kriterleri sonraki safhada daha derinleştirilebilir. Ana mekanizma satıcı demoları, sunumlar, referans ziyaretleri ve üçüncü taraf olan firmaların raporlarıdır. KRİTERLER NİÇİN? PARAMETRELER FONKSİYONALİTE YAZILIM KENDİNDEN

BEKLENEN İŞLEVLERİ YERİNE GETİRİYOR MU? EK ARAÇLAR NELERDİR?

TEMEL FONKSİYONALİTE /MODÜLLER/ARAYÜZLER/ODBC UYUMLULUĞU/EK ARAÇLAR/ VERİTABANI/ PLATFORM

KURULUM YAKLAŞIMI KURULUM BAŞARISIZLIK OLASIĞINI MİNİMİZE EDECEK BAKIŞ AÇIYLA MI YAPILANDIRILMIŞTIR?

SATICI/DEĞER KATAN SATICI VEYA DANIŞMAN/ YÖNTEM/ SÜRE/YENİ VERSİYONA GEÇİŞ POLİTİKASI

MALİYETLER KABUL EDİLEBİLİR Mİ? YARARLAR MALİYETLERDEN FAZLA MI?

DONANIM/YAZILIM/UYGULAMA (SAYILARI BELİRLİ EŞZAMANLI KULLANICILAR İÇİN)/ KURULUM DESTEĞİ/ EĞİTİM/BAKIM/EK ARAÇLAR

ÖRGÜTSEL KABUL/ BENİMSENME

ŞİRKET YAZILIMIN KURULUMUNDAN SONRAKİ POTANSİYEL ÖMRÜ BOYUNCA AYNI İŞTE KALACAK MIDIR?

ORİJİN/TARİHÇE/ CİRO/ÇALIŞANLAR/ HİSSE SENEDİ FİYAT HAREKETLERİ

HEDEF SEKTÖRDEKİ KURULUM DENEYİİ

UYGULAMA GEREK DUYULAN BENZER ORTAMDA DAHA ÖNCE BAŞARIYLA KURULMUŞ MUDUR? SATICI HEDEF SEKTÖR İÇİN YARAR SAĞLANABİLECEK DENEYİM SAĞLAYABİLMEKTE MİDİR?

KURULUM İSTATİSTİKLERİ/HEDEF SEKTÖR/ MÜŞTERİLER/ REFERANS ZİYARETLERİ

DESTEK(KURULUM SIRASINDA VE

GEREKTİĞİNDE DOĞRU UZMANLIK ALINABİLECEK

DESTEĞİN DOĞASI, ÖZEL-LİKLE YEREL DESTEK VE TELEFON

86

SONRASINDA) MİDİR? DESTEĞİ

ŞÖHRET MÜŞTERİLER, ÜÇÜNCÜ TARAFLAR, BASIN…)

SATICI HAKKINDA BAŞKALARINDAN NELER ÖĞRENİLEBİLİR?

YANIT VERME TARZI SÖZLEŞME İMZLANDIKTAN SONRAKİ DAVRANIŞLARI İÇİN SATICIYA İLİŞKİN İPUÇLARI NELERDİR?

PEŞİNE DÜŞÜLEN Mİ, PEŞİMİZE DÜŞEN Mİ?

YÖN (BEŞ YILLIK STRATEJİ)

TEKNOLOJİYE/ŞİRKETE İLİŞKİN BEŞ YILLIK SÜRE İÇİN VİZYON VAR MIDIR, VARSA NASIL DESTEKLENMEKTEDİR?

YÖN/ÜRÜN GELİŞTİRME STRATEJİSİ/ YAZILIM AR-GE BÜTÇESİ

Tablo 8.1 Seçim Kriterleri

GELECEĞE BAKIŞ

BUGÜN BAŞARILI, GENİŞ SEKTÖRLERİ KAPSAYABİLİR, ANCAK PAZARIN NEREYE GİTTİĞİNİ ANLAMIŞ DEĞİL

HEM BUGÜN ÇOK İYİ, HEM GELECEĞE ÇOK İYİ HAZIRLANIYOR

YA DAR ALANLARA ODAKLANIYOR VE BAŞARILI, YA BELİRLİ BİR HEDEFİ YOK, BULUŞ YAPAMIYOR, DİĞERLERİ KADAR BAŞARILI DEĞİL

PAZARIN NEREYE GİTTİĞİNİ KAVRAMIŞ VEYA DEĞİŞEN PAZAR KOŞULLARINA İLİŞKİN VİZYONU VAR, AMA BUGÜN İÇİN İYİ DEĞİL

VİZYON (TEKNOLOJİ, BENİMSENME, HİZMET, ÖZELLİKLER)

Figür 8.1 Sihirli Kadran

NOT 1. GARTNER’IN SİHİRLİ KADRANI GARTNER’ın sihirli kadranı bir örgütün satıcıyı veya ürünü değerlendirirken dikkate alması gereken etmenlerden yalnızca bir tanesini sunmaktadır. Değerlendirme sürecini tamamlamak için şirketler ürünleri canlı olarak kullanmakta olan başka müşterileri de ziyaret ederek bilgi almalı ve incelenen satıcıyı finansal değerlendirmeye de tabi tutmalıdır. NOT 2. GARTNER’IN PAZAR TANIMI Bir pazar ya da pazar segmenti aynı gereksinim veya istekleri karşılayan ve karar verirken birbirlerini refere eden ürün ya da hizmetlerin fiili veya potansiyel kullanıcılarının oluşturduğu kümedir. Pazar ya da pazar dilimi tanımı değişebilir. Örneğin otomobiller için pazar tanımı yararlı değildir. Hem müşteriler, hem satıcılar için çok daha fazla anlam ifade eden pek çok alt pazar (örneğin; spor, lüks, standart aile vs..) bulunmaktadır. Her birinin gerçek ya da duygusal gereksinimlerle hareket eden alıcı kümesi ve bunlara karşılık veren satıcılar bulunmaktadır.

87

Üçüncü tarafta bulunan firmalar grubunda yer alan Gartner Inc., pazardaki gelişmeler konusunda periyodik raporlar yayınlamaktadır. Raporlarda yer alan ilginç özellikler arasında firmaların bugünkü durumları ile gelecekte ulaşacakları düzey, teknolojileri, hizmetleri, ürün fonksiyonları, vizyonları ve bu vizyonlarına ulaşma gücü hakkında yorumlar bulunmaktadır. Bunun yanında hangi ölçekteki şirketlere ve beş segmentten hangisine (dağıtım yoğun, kesikli imalat, sürekli imalat, ekipman yoğun ve hizmet yoğun) odaklandıkları da raporda yer almaktadır. Değerlendirmelere alınabilmeleri için satıcı firmaların kabul kriterlerini tutturmaları gerekmektedir. Hedeflenen sektöre ilişkin bulgular sihirli kadran denilen basit bir matris üzerinde gösterilmektedir (figür 8.1). Sihirli kadranın yararlarından biri de alıcı firmanın kendi yaptığı değerlendirme konusunda güvenilir bir karşılaştırma olanağı sunmasıdır. Sihirli kadrandaki nitelemelerin bir görüş olduğunu ve hata içerme olasılığı taşıyabileceğini de hatırda tutmakta yarar bulunmaktadır. Seçim sürecinin bu aşaması spesifik gereksinimlerin (Bölüm 7) tedarikçi firmalara bildirilmesi, böylelikle onların ilk reaksiyonlarının alınması konusunu da kapsamaktadır. Müşteriler, problem alanlarına odaklanmakta, bazen de özel gereksinimlerine ilişkin taleplerini abartabilmektedirler. Ancak kritik fonksiyonel alanlar için satıcı firmaların demo yoluyla gereksinimleri nasıl karşıladıklarını ister bu aşamada, isterse sonraki aşamada ispat etmeleri gerekmektedir. Kısım 8.1’de bahsedildiği gibi satıcının seçilmesi sürecine katılan kişilerin bu sunumlarda, demolarda bulunmaları zorunludur. Katılım formatı enformel ve açık gündemlidir. Bu oturumlarda fonksiyonel gereksinimler sorgulanır. Amaç, müşterinin satıcı firmanın kendisi, sunduğu ürün ve hizmetler hakkında bilgi sahibi olmasıdır. Oturumlar listede yer alan kriterlere yanıt aranması şeklinde geçer. Her satıcının sunduğu enformasyonun çok fazla miktarda olması nedeniyle detayların sistematik biçimde kayıt altına alınması önemlidir. Bu husus yüksek olasılıkla yanılmalara yol açması, hangi uygulamanın ne yaptığının diğerleriyle karıştırılabilmesi nedeniyle özellikle fonksiyonalite açısından önem taşımaktadır. Dikkat edilmesi gereken diğer bir konu da satıcının sorgulamalara hangi yolla yanıt verdiğidir. Bu konu büyük olasılıkla kurulum sırasındaki ilişkilere ışık tutacaktır. “Niçin sizinle işbirliği yapalım?” sorusuna

88

alınacak yanıt da satıcının kendisini ne şekilde algıladığını ve gelecekteki ilişkinin nasıl olacağı hakkında fikir verecektir.

Bu aşama üç veya dört satıcının daha detaylı incelenmesi amacıyla belirlenmesi ile tamamlanır. 8.2.4 Aşama 4: Son seçim

Son aşama, satıcıyı seçmeyi hedefler. Bu aşamayı iki özellik karakterize eder: detay ve çalışanların konuya dahil olması. Bu aşama, satıcıların hem kendi ve hem de ürünleri ve hizmetleri hakkındaki her şeyi öğrenme zamanıdır. Onların zaaflarını bu aşamada öğrenmek seçim yaptıktan sonra öğrenmekten çok daha iyi olacaktır. Yine bu aşama diğer çalışanların da çalışmalara aktif biçimde dahil edilmeleri gereken aşamadır. Sistemi kuracak ve kullanacak kişilerde sahiplenme duygusu yaratmak gerekmektedir. Sonraki tarihlerde problemler ortaya çıkarsa çalışmalara dahil edilmiş kişiler “ben olsaydım bu yazılımı seçmezdim” cümlesini sarf edecek pozisyonda olamazlar. Dahası bu kişiler kendi çalışma alanlarıyla ilgili fonksiyonlar konusunda sorular da sorarlar. Bu aşamanın faaliyetleri arasında teklif mektubu göndermek, sunum ve demoları organize etmek, görüş ve izlenimleri derlemek ile karar verme sürecini yönetmek yer alır. Demolara katılan kişilerin anahtar rolü yazılımın işlevselliğini değerlendirmektir. Bu işin farklı yazılım paketlerinin farklarını ortaya çıkarıp kıyaslama yapabilecek şekilde gerçekleştirilmesi gerekmektedir. Bir öneri müşterinin sabit bir gündem ile satıcı demoları alması yönündedir. Bu gündem tüm satıcı firmalara dağıtılır. Amaç her satıcıya aynı spesifik işleri yaptırarak ürününün performansını kıyaslamaktır. Temel fonksiyonel konular nelerin demolarının alınacağını tanımlarlar. Bu konular her uygulamada bulunan standart rutin işlemler değildirler. Bunun yerine bir işletmeyi diğerinden ayıran farklı özel işlemlerdir. Örnekler arasında vardiya değişiklikleri, çoklu fiyat uygulamaları, farklı departmanlarda standart maliyetlendirme ile faaliyet tabanlı maliyetlendirme uygulamaları, müşterilere konsolide fatura gönderme vs. bulunabilir. Gündem satıcı firmalara gönderildikten sonra demolarını müşteri firma verilerine göre hazırlamalarına fırsat vermek için kendilerine yeterli süre tanınır. Veriler firmalara elektronik formatta gönderilir. Bu yolla satıcılar firmaya özgü konulara daha hakim hale gelirler. Demonstrasyon gününde oturuma katılan herkesin önünde görüşlerini not edebileceği bir

89

kayıt formu bulunmalıdır. Bu sayede yazılımlara ilişkin değerlendirmeler zihinsel karışıklıklara yol vermeden kayıt altına alınır. Tüm demolar tamamlandığında bu formlar bir araya getirilerek fişlevler açısından yazılımların görece üstün yanları ortaya çıkarılır. Bunun için bir grup tartışması yapılabilir veya ayrı bir analiz yapılarak elde edilen bulgular bir raporla dağıtılır. Son işlem, hangi satıcının çalışma ortağı olacağı kararını vermektir. Bu kararın nasıl verildiği organizasyonun doğasını yansıtır. Kısım 8.1’de tartışıldığı gibi bu karar tek kişi veya grup tarafından verilebilir. Hatırlanması gereken nokta seçim kararını kimin sahiplendiği ile bunun daha sonra başka kişileri, kullanıcıları, sistemi sahiplenecek kişileri nasıl etkileyeceğidir. Bu karar verilirken dikkatler seçim kriterleri üzerinde toplanır. Tablo 8.1’de verilen seçim kriterleri alt kısımlarda daha detaylı olarak incelenmiştir. 8.2.4.1 İşlevsellik/fonksiyonalite

Yazılım kendinden talep edilen her şeyi yapmakta mıdır? Belki de bu kriter seti iş süreçlerini kapsaması nedeniyle en karmaşık alandır. Her ne kadar ERP sistemleri, işlevsellik/fonksiyonalite açısından evrim geçirmişlerse de her iyi sistemin tüm rutin fonksiyonları yerine getirdiğini varsayılması önerilmemektedir. Bu konu, elbette hangi sistemin iyi olduğu sorusunu da beraberinde getirmektedir. Bu soruya yanıt aramak yerine tedbirli olmak önerilmektedir. Sistemin kendinden beklenenleri yaptığı kanıtlanmalıdır. Dahası bu karmaşıklık düzeyi kısım 3.1 ve 3.3’te belirtilen diğer ilgili konuların firma tarafından ne ölçüde sunulduğunun araştırılması nedeniyle daha da yükselir. Anılan ilgili konular aşağıdadır: Altyapı teknolojisi

• veritabanı • platform • bakım, performans ve güvenlik yönetimi • ölçeklenebilirlik • çok sayıdaki tesisin birlikte çalışması

Kurulum teknolojisi

• işletme modelleme araçları • sistem konfigürasyon araçları • doküman yönetim araçları

90

On-line teknolojisi

• ek alanlar • ODBC bağlanabilirliği • CAD ara yüzleri • .xls, .txt formatlarında yükleme yeteneği • veri toplama esnekliği • grafik kullanıcı ara yüz ekranları • kullanıcı dostu olma • web olanaklı ekranlar • ekran tasarım yeteneği • bütünleşik raporlama araçları • OLAP araçları • İş akışları • Uyarlama kolaylığı • Ön baskılı doküman veya on-line bağlantılı doküman

kullanabilme Uyum

• CD ROM ile interaktif öğrenme • On-line yardım • On-line veri arama • Kapsamlı fonksiyonalite dokümantasyonu • Yeni versiyonlara geçiş kolaylığı.

Yukarıdaki konuların pek çoğu açık bir şekilde tanımlanıp değerlendirilebilir. Yukardakilere dosya transferleri, e-ticarete uygunluk, bilgi güvenliği vb. gibi internetin sağladığı olanaklar üzerinden de birçok işlev yüklemek mümkündür. Daha sonraki aşamalarda hayal kırıklığı yaşatmaya özellikle açık konular kayıt yapma ile operasyon planlama ve kontroldür. Kullanıcı gereksinimlerinin tanımlanmasına karşın (Bölüm 7) kritik önemdeki detaylar gözden kaçırılabilmektedir. Bu detaylar, büyük olasılıkla spesifikasyonlar arasına dahil edilmezler ve yazılım içinde olup olmadıkları araştırılmaz. Yetersiz detay ile aşırı detay arasında bir çizgi bulunmaktadır. Fonksiyonaliteye ilişkin başka bir konu prototipleme konusunda bir defa daha ele alacağımız gibi fonksiyonun beklendiği şekilde olmaması veya hiç olmamasıdır. Bu konu süreçlerin zaman içinde nasıl değişeceğinden ve gelecekteki gereksinimlerin neler olacağı ikileminde tamamen ayrıdır. Bu yetersizlikler uyarlama ile giderilirler (kısım 12.3.2), ama bu da maliyettir.

91

Diğer bir değerlendirme konusu teknoloji değişim hızıdır. Yeni teknolojik gelişmeler dikkatleri dağıtabilir veya son gelişmeler kişileri cezbedebilir. Bu konuda çeşitli riskler bulunmaktadır. Yeni teknolojik gelişmelerin ilk uygulandığı yer olmak problemlerin giderilmeleri için uzun zaman alan gecikmelere yol açabilir. Yine de bu durum riskten kaçınmayan kişiler için bir fırsat olarak görülüp uygulanabilir. Buna karşılık şu anda neler çalışıyor sorusuna yanıt aranacak ise yeni gelişmelerin getireceği fırsatlar kaybolur ama teknoloji ilişkin problemlerden ve buna bağlı gecikmelerden korunmuş olunur. 8.2.4.2 Kurulum yaklaşımı

Metodoloji kanıtlanmış ve yapısal bir yaklaşım mıdır? Kurulumun farklı aşamaları tanımlanmış olup, açıkça belirlenmiş faaliyetler halinde ve ilgililerin kimler olduğu anlaşılacak şekilde belirlenmiş midir? Sonraki faaliyetler kümesine geçmeden işlemlerin tamamlanmasını garanti edecek açık transfer noktaları bulunmakta mıdır? Satıcı firma önerdiği metodolojiye sıkı sıkıya bağlı kalmaya zorlamakta mıdır?

Amaç kurulumun bocalaması olasılığını azaltmaktır. Eğer metodoloji yapısal bir biçimde ise olayların mantıksal sırasını sunarak gözden kaçırmaların ve konularla yanlış zamanda ilgilenmenin önüne geçecektir. Akıllıca kullanıldığında metodoloji mevcut durumu yansıtacak şekilde uyarlanacak, böylelikle firma bir deli gömleği giymemiş olacaktır. Metodoloji bir proje yönetim ortamında ele alınmalıdır. Bu yolla sorumluluklar ve zaman çizgileri tanımlanacak, kaynaklar, maliyet kontrolü ve ilerlemeler izlenebilecektir.

Metodolojinin gözden kaçırma eğilimi olan bir diğer yüzü etkin kurulumun şirket içi koşullar uygun olduğunda yapılabileceği varsayımına dayanmaktadır. Başarısız olmuş kurulumlar, çoğunlukla yazılımla ilgili konulardan çok örgütsel ve insani nedenlere (kısım 10.1) bağlanmaktadır. Şirket müdürü (yada genel müdür) destek vermekte midir? Projeye doğru insanlar mı dahil edilmiştir? Proje müdürünün verimli olmasının önüne geçen örgütsel konular mı vardır? Yeni sistemin kullanıcılar yeni sistemi kabul etmeye istekli midirler? Satıcının hem başarılı, hem başarısız kurulumlar konusunda deneyim sahibi olduğu varsayılabilir. Satıcının referansı ne kadar çoksa, kurulumu destekleyen faktörleri o kadar bileceği varsayılabilir. Sonuçta satıcı kurulum sırasında işlerin düzgün gitmediğine ilişkin uyarı sinyallerini alabilmekte, bu

92

nedenle de proje müdürü ile müşterinin diğer yöneticilerine destek verme pozisyonunda bulunmaktadırlar. Bu noktada satıcı firmanın şirket içi koşulları başarılı kurulum lehinde oluşturmaya ne kadar yardım etmesi gerektiği sorusu ortaya çıkmaktadır. Satıcı firmadan kim bu işi yapabilecek yeteneğe ve üst yönetimi etkileyebilecek kredibiliteye sahiptir?

ERP çözümünün kurulum süresini azaltmak amacıyla bazı satıcılar, hızlı takip programları sunmaktadırlar. Bu yaklaşım önceden konfigüre edilmiş endüstri özgün yazılımların benimsenmesi şeklinde uygulanmaktadır. Buna rağmen bu yaklaşımın müşteri firmanın süreçlerine tam olarak uyması olasılığı yoktur. Zaman kazancı firma için ideal olmayan proseslere kilitlenmemekten kaynaklanmaktadır. Ancak uyumsuzluk bu yararı yok edecek zararlar da üretebilir. Bu neden önceden konfigüre edilmiş seçeneğin dikkatle değerlendirilmesini ve süreç farklarına özel önem verilmesini gerekli kılar. 8.2.4.3 Destek (kurulum sırasında ve sonrasında)

Bir kişinin bir yazılım uygulaması satın alması ve bunu satıcı firmanın veya onun temsilcisinin yardımı olmadan kurmaya kalkması kesinlikle olanaksız bir durumdur. Bunun yerine satıcı tarafından destek verilir ve bu destek uygulama hakkında bilgi transferini, kurulum kılavuzluğunu ve problem çözüm know-how’ını içerir. Satıcıya olan bu bağımlılık müşterinin kuracağı ilişkinin tarzına ve doğasına ilişkin çeşitli konuların doğmasına neden olur. Gereksinim duyulduğunda satıcının belirlemiş olduğu kişilere ulaşılabilmelidir. Bu kapsamda dikkate alınması gereken konular şöyledir:

• En yakın ofis nerededir? Danışmanlar tahakkuk ettirecekleri ulaşım giderlerini evlerinden mi, yoksa bu ofisten itibaren mi hesaplayacaklardır? Seyahat süresi ne kadar olacaktır? Problem doğduğunda çok kısa zaman içinde destek verebilecek yerel bir destek havuzu var mıdır?

• Danışman ve proje müdürü olarak kimler atanmıştır? Bunların yazılım ve uygulama deneyimleri ne kadardır? Müşteriler yazılım ve uygulama üzerindeki deneyimsizliği nedeniyle hatalara yol açabilecek bir danışman ile çalışmak istemeyecektir?

• Telefon yardım masasına başvuru saatleri nelerdir? Bu kapsamda hangi konular ele alınabilmektedir? Bu yardımın

93

verilemediği saatler için başka bir yardım yolu oluşturulmuş mudur?

• Satıcıdan müşteride yüklü yazılıma telefonla erişim olanağı var mıdır?

• Çözülemeyen problemler daha üst mercilere hangi yolla taşınacaktır?

• Sonraki versiyonlar için politika nedir, bunların yüklenme süreci nasıldır? Bu süreç nasıl desteklenmektedir?

• Diğer müşterilerin satıcıdan aldıkları destek konusundaki görüş ve tatminleri ne düzeydedir?

8.2.4.4 Bir kez daha maliyetler

Maliyet konusu kısım 6.2’de anlatılmış, ancak orada yatırım kararının verilmesi ve yararlarla karşılaştırılması açısından ele alınmıştı. Bu aşamada temel soru müşterinin bu yatırımı yapıp yapmaması değil, ödeyeceği maliyet karşısında ne elde edeceğidir? Satıcı firma ile yapılan ilk görüşmeler maliyetlere ilişkin ilk resimlerin oluştuğu dönemdir. Seçim sürecinin bu son aşaması sırasında maliyetlere ilişkin daha fazla detay elde edilir. Böylelikle gereksinimlere ve onların nasıl karşılanacaklarına ilişkin net bir tablo ortaya konabilir. Her şeyi benzerleriyle birebir karşılaştırmak için özen gösterilmesi gerekir. Kısım 6.2’de sunulduğu gibi aşağıdaki çerçevenin toplanan enformasyonu kategorize etmede kullanılması yerinde olacaktır:

• donanım • işletim sistemi • veri tabanı lisans bedeli • çekirdek yazılım lisans bedeli • ek modül lisans bedeli • üçüncü taraf yazılım lisans bedeli • üçüncü taraf yazılımların entegrasyonu • yazılım uyarlamaları • canlı kullanım için veri dönüşümleri • proje yönetimi • danışmanlık • eğitim • ulaşım ve konaklama giderleri (ulaşım zamanı dahil) • yeni versiyonlar (terfiler)

Son listeye dahil olan tedarikçi firmaların maliyetleri arasında çok küçük farklar olması normal olacaktır.

94

Dikkat çekilmesi gereken özel noktalar da şöyledir: belirlenen kullanıcı sayısından başka eş zamanlı kullanıcı sayısı için de verilen bir lisans bedeli seçeneği bulunmalıdır. Bu seçenek çoğunlukla daha ucuz ve daha esnek olacaktır. Eğitimlere ayrılan paylarda tutucu yaklaşımlar görülme eğilimi bulunmaktadır. Kurulumun başarısızlık nedenleri arasında eğitim yetersizliği ön planda gelmesi nedeniyle eğitime ayrılan payın bilinmeyenler dikkate alınarak yapılması uygun olacaktır. Yardım masasını ve yeni versiyonların yüklenmesini (yükseltme işini üstlenen personel giderleri de dahil olacak şekilde) kapsayan yıllık bakım giderleri unutulmamalıdır. Ödemelerin projenin kilometre taşlarına göre yapılması müzakere edilmelidir. Sabit ödemeler şeklinde yapılan antlaşmalar çoğunlukla daha pahalıya gelmekte, ancak kurulumu garanti altına almaktadır. Eğer şirkette IT departmanı bulunmuyorsa bu faaliyetin dış kaynak kullanımı yoluyla çözümlenmesi dikkate alınabilir. Ancak bu yol beraberinde bazı problemler de getirebilir. Bu problemlerin üstesinden gelmenin bir yolu olarak son zamanlarda kiralama yöntemi geliştirilmiştir. Bu sayede çok pahalı yazılımlar cazip hale gelmekte ancak görünmeyen maliyetler nedeniyle bu seçenek uzun dönemde daha pahalı hale gelebilmektedir. Bu nedenle seçeneğin enine boyuna etüt edilmesi gerekmektedir. Veri toplama donanım ve yazılımı gerekiyorsa getireceği ek maliyetler hesaba katılmalıdır. 8.2.4.5 Örgütsel Kredibilite/Varlığı sürdürebilme

Bu konu iki perspektiften ele alınabilir. İlki satıcının profilidir. Şirketi ne kadar büyüktür? Nerede bulunmaktadır? Ne zaman kurulmuştur? Karlı mıdır? Yeni lisans gelirlerinin bakım gelirlerine oranı nedir? Ar-Ge harcamaları ne düzeydedir? Web sitesi ne kadar güzeldir? Bunlar satıcı ilk duyguların oluşması için sorulan bazı sorulardır. Amaç satıcının sizin çalışmak isteyeceğiniz bir firma olup olmadığını anlamanızdır. Aradığınız küçük bir şirket yerine size konfor sağlayacak büyük bir firma olabilir. Tersine küçük bir şirketten daha iyi destek alabileceğinizi düşünüyor da olabilirsiniz. Yüksek Ar-Ge harcamalarını kullanacağınız ürünün gelecekte yeni özellikler taşıyacağının garantisi olarak görebilirsiniz. Bu şekilde bir profil belirleyerek şirketlerin göreli üstünlüklerini kıyaslayabilirsiniz. İkinci perspektif satıcının önümüzdeki bir yıl içinde iş hayatında olup olmayacağı sorusudur. Yanıt olumsuzsa, yazılım desteği nereden sağlanacaktır? ERP pazarının kararsız yapısı büyük küçük ayrımı gözetmeden yazılım satıcılarına da yansımakta,

95

firmalar finansal kayıpların sıkıntılarını çekmekte, borsa değerleri baş aşağı düşmekte ve ele geçirmeler yaşanmaktadır. Yüksek Ar-Ge harcamaları tüm firmaları zorlamaktadır. Nitekim beklenmeyen olmuş ve BAAN şirketi büyük düşüş yaşamıştır. BAAN 1978 yılında kurulmuş ve 1998 yılında gelir açısından en büyük beş firma arasına girmiştir. Bu yıldan sonra karlılığın tersine dönmesi ile 55 $ olan hisse senedi değeri, altı aylık süre içinde 10 $ düşmüştür. 2000 yılında durum daha kötüye gitmiş ve Invensys firması tarafından satın alınmıştır. Neyse ki Invensys çekirdek ürünü korumuş ve kullanıcıların mağdur olmasını kısmen önlemiştir. Tablo 5.1’in gösterdiği gibi bu izole edilmiş bir olay olmayıp müşteriler için uyanık olma ihtarı anlamındadır. Beş yıllık süre içindeki hisse senedi fiyat trendi pek çok firma için Internet’ten erişilebilir durumdadır. Büyük ve hızlı düşüşler belki de gelecekteki olayların habercisidir. 8.2.4.6 Müşteri firmanın sektöründeki deneyim

Müşterinin kendi sektörüne ilişkin deneyim aramasının çeşitli sebepleri bulunmaktadır. İlk önce müşterinin sektöründe kullanılıyor olması benzer ortamda yazılımın çalıştığının kanıtıdır. Böylelikle pek çok fonksiyonel gereksinim karşılanabilecektir. Bu mantık yürütme sektörün diğer şirketlerinde benzer süreçlerin işlemesi, tedarikçi ve müşteri benzerliklerinin varlığı ve onlarla çalışılacak olunması halinde geçerlidir. Ancak bu mantık garanti olarak görülmemelidir. Referans ziyareti ihmal edilmemelidir. Dahası kısım 8.2.4.1’de değinildiği gibi işlevselliğe ilişkin hiçbir veri sorgulanmadan, körü körüne kabul edilmemelidir. Kurulumun amaçlarından bir tanesi de en iyi uygulamaları edinmektir. Buradaki mantık da yeni yazılımı kullanan sağlayacakları yararlar öncekilerin re-engineering yapmış olmalarına dayanmaktadır. Yazılım yeni pratikler için bir olanak sağlayıcıdır. Bunun bir yolu satıcının danışmanlarının deneyimlerinden yararlanmaktır. Danışmanın müşteri firmanın sektörüne özgü deneyiminin gerekli olup olmadığı tartışılabilir. Bu deneyimin var olmasının avantajı danışmanın temel konulara aşina olmasıdır. Ancak farklı sektör deneyimleri yeni uygulamalara yönelik taze bakış açıları getirebilir, böylelikle en iyi pratikleri yaratabilir. 8.2.4.7 Şöhret

Satıcıları değerlendirmenin tamamlayıcı unsurlarından biri de üçüncü taraf kaynaklara yönelmektir. Bu taraflar arasında AMR

96

Research, Gartner Inc. gibi çok yüksek profilli bağımsız yorumcular da bulunabilir. Bu kurumlar pazarın durumu, satıcıların pazardaki durumu (şekil 8.1 sihirli kadran) ve gelecekteki trendler gibi konularda raporlar üretmektedirler. Sektörel basın, diğer bir kaynak olarak yine pazar ve firma durumları ile başarısızlıklara dahil olmak, üzücü kurulum hikayeleri içerirler. Referans ziyaretleri birinci elden bilgilerin alınmasını sağlar. Bu ziyaretler satıcının neden seçildiğini, karşılaşılan sorunları ve bunların nasıl ele alındığını, zaman tersine dönse firmanın nasıl davranacağını öğrenmek olanaklı olur. Ayrıca tedarikçi firmanın personeline ilişkin izlenimler edinilebilir, satıcı danışmanları müzakere edilirken konuları açılabilir. 8.2.4.8 Araştırmaları ele alma tarzı

İlk izlenimin karar vermede önemli olduğu, ilişkinin yürüyüp yürümeyeceği hakkında fikir verdiği gerçeği göz ardı edilmemelidir. İlk temaslar sonrasında nelerin geleceğinin göstergesi olabilir. Satış öncesi görüşmeleri yürüttüğünüz ekibin sorularınıza verdiği yanıtlar ya da bu yanıtları üretme çabası satış ekibi hakkında pek çok bilgi verir. Aynı zamanda şirketin kültürünü de yansıtır, bu nedenle kurulum ekibinin aynı şekilde davranacağını düşünmek pek yanlış çıkmaz. Eğer bu aşamadaki durum pozitif ise kurulum sorunlarının kolayca üstesinden gelineceği, bu dönemin konforlu geçeceği duygularını yaşayabilirsiniz. Satış ekibinin yapısını test etmenin en iyi yollarından bir sunum sırasında onlara sorular sormaktır. Satış ekibi sorulan sorular karşısında kendi gündemlerini mi izlemektedirler, yoksa kendilerini müşteri gereksinimlerini karşılamak üzere uyarlamakta mıdırlar? Satıcının ne kadar müşteri odaklı olduğu satış ekibinden anlaşılabilir. Eğer müşteri odaklılık onlarda yoksa başka bir firmada bulunacaktır. 8.2.4.9 Yön – Beş yıllık strateji

Bu kısımdaki soruların yanıtları büyük olasılıkla satıcı profili ve varlığını sürdürmesi konusunda (kısım 8.2.4.5) ortaya çıkmıştır. Misyon tanımı, yıllık rapordaki yönetim kurulu başkanının hitabı, Ar-Ge bütçesi, çeşitli yerlerde yayınlanan makaleler, ürün üzerindeki gelişmeler şirketin gideceği yön hakkında bilgiler verir. Yeni ürün ve teknoloji olarak çok çalışma yapılmışsa uzun dönemde şirketin rekabetçi gücünün artacağı düşünülebilir. Yeni coğrafi alanlara yayılım kısa dönemli stratejilerin uygulandığı ve yeni pazar gelirleri yaratmanın amaçlandığı akla gelir. Bir satıcının faaliyetlerine ilişkin çok sayıda yazı okunabilse de ana konu onun uzun döneme

97

odaklanıp odaklanmadığını anlamaktır. Bunun göstergesi ürün geliştirmedir. Yeni versiyon zamanı geldiğinde ürün çok ilerlemiş midir? Geliştirme stratejisi nedir? İçsel çalışmalarla mı, yoksa şirket ele geçirmeleriyle mi olmuştur? İkinci yol ürün portföyünü ilkinden daha çabuk geliştirmiş olsa da ürün entegrasyonun nasıl sağlanacağı ve firma ele geçirmenin finansal pozisyonu bozup bozmadığı sorularının yanıtlarının araştırılmasını gerekli kılar. Üçüncü bir gelişme stratejisi işbirliği ve teknolojik birikimin paylaşılmasıdır. Partnerlik yapay ve paylaşılan bilgiler sınırlı ise antlaşma kolayca bozulabilir. Belki de daha önemlisi gelecekte gelişme olacağına ilişkin gösterge yokluğudur. Bu müşteri için alarmdır. Satıcı firma ileri gitmiyorsa gelecekte rekabet edebilecek midir? Rekabet edemeyecekse sektör içinde nasıl kalacaktır? Faaliyetlerini durdurmak zorunda kalacak veya başka bir firma tarafından yutulacaktır. Satıcının nasıl seçileceği kararı her kriterin karşılıklı değerlendirilmesine dayandırılır. Bir yaklaşım puanlama sistemi kullanmaktır. Her kritere her satıcı için bir puan verilir. Her kritere göreli önemlerine göre farklı ağırlıklar atanır. İşlevsellik en ağır; yön en hafif; diğerleri de aralarda bir yerlerde olmak üzere ağırlık dağılımı yapılabilir. Ağırlıklar kişisel görüş konusu olduklarından burada herhangi bir öneride bulunulmayacaktır. Nihai skor her puanı ağırlığıyla çarparak bulunur. Nihai puanlar toplanarak her satıcının çekiciliği hesaplanır. En yüksek puanı kazanan firma seçimi de kazanır. Satıcı seçiminde kısa liste yaklaşımını kullanma sonucunda müşteriye en fazla değer sunan satıcının seçilmesine yol açar. Bu noktada karar vericilerin kararlarını imzalamaları, sonradan çıkabilecek problemlerde katılımlarının onlara hatırlatılması gerekir. Kurulumun başlamasından önceki son faaliyet sözleşme görüşmelerinin yapılmasıdır.

98

9 Antlaşmayı Sonuçlandırmak 9.1 Sözleşme müzakereleri

Müzakere ve sözleşme konularının derinlemesine incelemesi, bu notların kapsamı dışındadır. Bu alanda iki önemli yön bulunmaktadır; nasıl müzakere edileceği ve müzakerenin içeriğinde neler olacağı. İlk yönle ilgili çok kaynak bulabilirsiniz… Müzakerelerin içeriğiyle ilgili göze çarpan birkaç nokta vardır. Müzakereleri destekleyen iki faaliyet vardır. İlk olarak tam, eksiksiz bir hazırlık yapmak gerekir. Bu şekilde önemli konuların gözden kaçırılması olasılığı azaltılmış olur. İkinci konu satıcıyı tanımaktır. Pek çok soru sorun. Satış konusundaki abartılmış söylenceler ile gerçekleri birbirinden ayırın. Özel bir tedarikçi ile ilgili karar verileceği zaman satıcı hakkında olabildiğince çok şey bilinmesi gerekir; onunla nasıl çalışacağınız, olası zayıflıklarının neler olduğu gibi. Tedarikçi ile süren görüşmeler boyunca sözleşmenin detaylarına ve ifadelerine dikkat etmek gerekir. Sözleşme müzakerelerinin detaylara dikkat etmenin zaman alıcı bir iş olması nedeniyle beklenenden daha uzun sürebileceğini bilmek gerekir. Satış görüşmeleri sürecinde pek çok gönüllü taviz alınır, şimdi bunların yapılandırılıp geliştirilerek sözleşmeye monte edilmesi zamanıdır. Sözleşmenin ilk hazırlık aşaması, satıcı şirketin standart sözleşmesini sunması ile başlayabilir. Bu sözleşmeyi okurken satıcı lehine yorumlarla karşılaşmak sürpriz olmamalıdır. Hukukçulardan görüş alınması yerinde olacaktır. Sözleşmenin yapısı, satıcıdan satıcıya değişmekle birlikte her biri aşağıdaki başlıkları içerir; • tanımlar • fiyat/ödeme • teslim • eğitim • telif hakkı/sahiplik • yazılım lisansı • üçüncü taraf yazılımlar • sorumluluk

99

• işletim sistemi • donanım • garanti • yazılım hataları • yazılım desteği • yeni sürümler • lisans iptalleri

Açık bir şekilde içeriğin gözden geçirilmesi, düzeltmelerin ve eklemelerin yapılması gerektiği görülmektedir. Kullanılan kelimelerin anlamlarına özel dikkat sarf edilmesi, özellikle spesifik kelimelerin güç fark edilen anlam farklarının üzerinde durulması gerekir. Gereksinimlerin tanımı ve sonraki düzeltmelerin de dahil edilmesi gerekir. Hem yazılım kurulumunun hem de lisansının, alınacak ürün ve hizmetin yaşam süresi boyunca tüm olasılıkları dikkate alması gerekir. Gözlenmesi gereken başlıklar şunlardır:

• ödeme profilini, uygun bir vade ile tarihleri ve taksitleri belirlemek, ödemeleri de buna göre çizelgelemektir.

• lisans ödemeleri, toplam kullanıcı sayısı veya eş zamanlı olarak kullanılacak sayıya göre yapılabilir.

• bir yazılım kusuru özel bir fonksiyon setinin kurulumunu engellediğinde ve bu kusurun giderilmesi sonraki bir tarihte bir sonraki versiyonda ortaya çıkacaksa ne yapılacağı düşünülmelidir.

• Yazılım değişikliklerini kontrol etme, test etme süreci, nasıl işleyecektir, garanti süresi ne olacaktır?

• Yazılım değişikliklerini kim sahiplenecek, ilgili entelektüel haklar kimin olacaktır?

• Yeni donanımın temini kimin sorumluluğundadır, aynı donanım başka yerde daha ucuza bulunursa ne olacaktır?

• Yazılımın eski donanımdan yeni donanıma transfer cezaları nedir?

• Yazılımı kimlerin kullanabileceği konusundaki kısıtlamalar, örneğin uydu iletiminden yararlanılarak yapılacak işlemler…

• Ek hizmetlerin tanımlanması… • Üst mercilere çıkarılması gereken problemlerle ilgili yanıt

prosedürleri… • Garantör düzenlemeleri nasıl olacak, satıcı kaynak kodları

üçüncü kurumlara teslim edecek midir?

100

Bunlar yalnızca bazı başlıklardır. Yatırımın büyüklüğüne bakıldığında en emin yolun yasal uzmanlığa başvurmak olduğu görülür. Görüşmelerin yarıda kalmaması için satıcı firmaya ikinci bir şans vermek mantıklı olacaktır. 9.2 Yankılar

Burada sunulan yaklaşım, satıcı firma seçmek için tek yol değildir. Kısım 8.1’de açıklandığı gibi aynı sonuca varan farklı yollar bulunmaktadır. Hangi yaklaşımın benimseneceği tamamen müşteriye kalmıştır. Kısa liste yöntemi benimsense bile nasıl uygulanacağına ilişkin çeşitli varyantlar bulunur. Tek tedarikçi içeren eleme listesi (kısa liste) yönteminde yalnızca 1, 2 ve 4 numaralı aşamalar izlenmesi bile söz konusu olabilir. Hangi yaklaşım benimsenirse benimsensin; sonuçta seçilecek tedarikçi ile uzun yıllar devam edecek bir ilişki söz konusu olacaktır. Her iki tarafın da engellemek isteyeceği fırtınalı bir ilişki yaşanmaması için, tarafların ev ödevlerini yapmaları gerekmektedir. Bu durumda dahi ilişkinin bozulmamasının garantisi yoktur.

101

10 Kuruluma Giriş 1970’ler ve 1980’lerde MRP/MRP II kurulumlarında görülen hızlı artış pek çok başarısızlığı da beraberinde getirdi. Daha fazla yapılan artış ve deneylere karşın bu durum 1990’larda da devam etti. Benchmark Research Ltd. tarafından 1994 yılında MRP kullanan ve 200’den fazla çalışanı bulunan İngiliz mühendislik firmaları üzerinde yapılan bir araştırma şu bulguları ortaya çıkardı:

• firmaların %28’inde beklenen yararlar konusunda kurulum öncesi dönemde herhangi bir ölçüt oluşturulmamıştı,

• ölçüt oluşturan firmaların dörtte biri bekledikleri yararlara erişemediklerini belirtmişlerdi,

• firmaların %51’inde kurulum, planlanandan daha uzun sürmüş,

• firmaların %28’inde kurulum bütçeleri aşılmış, • yazılım paketlerinin %68’inde kurulum sırasında uyarlama

yapılmış, • firmaların %56’sı canlı kullanıma geçmeden önce yeterli

eğitimi alamamışlar.

Aynı firmalar üzerinde 1999 yılında yapılan enstantane bir araştırmada ortaya çıkan bulgular da şu şekilde:

• müşteriler yazılım paketinin performansı konusunda tatmin olmuş görünmekteler, bu konu çok seyrek olarak problem olmakta, son yıllarda yazılım geliştirmede yaşanan hızlı ilerlemeler göz önüne alınırsa bu bir sürpriz sayılamamalı,

• araştırmaya yanıt veren firmaların onda altı ila onda yedisi yeni sistemin kurulumu ile ilgili ana tatminsizliğin eğitim konusunda olduğunu ifade etmekteler,

• sistem kurulumu beklenenden daha uzun sürmekte; büyük sistemlerde %20 daha uzun (ortalama 12 ay), küçük sistemlerde ise 51’i daha uzun (ortalama 9 ay) sürmekte.

• Kurulum maliyetinin yaklaşık %55’i yazılım ve donanıma gitmekte, eğitim maliyetleri bütçe aşımlarına neden olmakta,

• Yanıt verenlerin %25’i yeterli eğitimi almadıklarını ifade etmişler,

102

• Firmaların %52’sinde yazılım üzerinde uyarlama yapılmış, uyarlamalar büyüdükçe sonuçlardan duyulan memnuniyetsizlik de artmış.

Ortaya çıkan tablo daha fazla kurulumun başarılı olduğu yönünde, bu bulgu özellikle uygun eğitim bütçelerinin yapıldığı ve eğitimin alındığı firmalar için daha geçerli. Dahası yazılım ile ondan beklenen gereksinimler ne kadar örtüşürse başarı da o kadar büyük olmakta, aradaki boşlukların uyarlama yapılarak doldurulmaya çalışılması aynı başarıyı getirmemekte. Bu da doğru yazılımın seçimi konusunun önemini vurgulamakta. Bununla beraber başarının ne olduğunun kişiden kişiye, kurumdan kuruma değiştiğinin de farkında olunmalı. Bir organizasyon için başarı canlı kullanım aşamasına geçiş olurken, diğeri için ölçülebilir iş hedeflerine erişmek şeklini alabilir. Hangi başarı ölçüsü kabul edilirse edilsin ana sorunlar zaman ve maliyet olarak karşımıza çıkmakta. Peki başarıya ek zaman ve harcama yapılarak ulaşılırsa kurulum yine başarılı sayılacak mıdır? Başarının ne olduğu konusunda hangi görüş kabul edilirse edilsin, kurulum, geçmişten ne öğrenilmiş olursa olsun pek çok şeyin yanlış gidebileceği zor bir süreçtir. 10.1 Tarihten dersler

Başarısız kurulumlara ilişkin problemlerden pek çok şey öğrenilebilir. Ancak başarısız kurulumları nelerin oluşturduğu konusunda anlaşmazlıklar söz konusudur. Zamanında canlıya geçilen, bütçe sınırları içinde kalınan bir kurulum proje yöneticisinin bakış açısıyla başarılı olarak yorumlanırken, yararların gerçekleşmemesi, sonradan bir takım problemlerin ortaya çıkması durumunda işletme yöneticisinin gözünde başarısız olmuş bir kurulumdur. Projenin başarısızlığının, ne olduğu konusundaki tartışmaları bir kenara bırakırsak, pek çok yorumcu kurulumların hangi nedenlerden ötürü başarısız olduğuna ilişkin yorum yapan pek çok uzman problemlerin teknoloji değil insan kaynaklı olduğunda görüş birliğine varmış bulunmaktadırlar. Problemlerin ortak nedenlerine ilişkin en sık yapılan önermeler aşağıdadır:

• üst yönetimin anlayış, katılım ve vizyon yokluğu, • bağlılık ve üstlenme yokluğu, • deneyimsiz proje müdürleri, • kaynak ayırma isteksizliği,

103

• geliştirme ekibinde yanlış kişilerin yer alması, • politikalar, • iletişim kopuklukları, • sahiplenme yokluğu, • son kullanıcı katılımının olmaması, • olmayan veya uygun olmayan eğitim, • acele edilen son teslim tarihleri, • uygun tanımları yapılmayan gereksinimler, • zayıf tanımlanan iş süreçleri, • satıcı tarafından sistem entegratörü olarak atanan personelin

deneyimsiz olması, • satıcı tarafından sistem entegratörü olarak atanan personelin

konsantre olmaması.

Bu insan, ağırlıklı problemlerin örgüte hakim olan kültür tipinin ve değişimi ne şekilde ele aldığının göstergesi olabilir. Eğer durum bu şekilde ise hangi kültürün başarıya götüreceği, hangi kültürün başarıdan uzaklaştıracağı sorusunun sorulması gerekir. Bu soruya doğrudan yanıt vermek yerine bir ERP kurulumu için neler gerektiğine derinlemesine bakarak yanıtın ortaya çıkmasını sağlamak daha doğru olacaktır.

104

11 Kurulum Metodolojisi

11.1 Genel yaklaşım

Yaklaşım genel olarak uygulayıcılar tarafından şu şekilde sunulmaktadır:

• şimdi ne yaptığınızı anlamak • yazılımın nasıl çalıştığını anlamak • süreçlerin prototiplerini yapmak: işlerin gelecekte nasıl

yapılacağını belirlemek (gerekiyorsa yeniden yapılanma yapmak)

• süreçlerin pilotunu yapmak: süreçlerin çalıştıklarını kanıtlamak

• dokümantasyonu tamamlamak ve eğitimi yürütmek • Canlı kullanıma geçmek • Gözden geçirmek.

Bu yaklaşımı desteklemek, yazılımın ve iş süreçlerinin birlikte nasıl çalışacaklarını belirlemektir. Bu yaklaşım bir proje ortamında yürütülür, net bir örgütsel yapısı bulunur, takım ruhu oluşturulur ve olayların sıraları planlanır. Bu yaklaşımın varyantları bulunur. Bazı büyük satıcı firmalar uygulama sürecini hızlandırmayı amaçlayan “hızlı kurulum” önerirler. Normal uygulamalarda yazılım konfigürasyon gerektirirken, hızlı kurulumda yazılım müşterinin çalıştığı sektör ile ilgili bir iş modeline önceden konfigüre edilmiş olarak satılır. Bu durumda müşterinin süreçleri yazılımın içindeki iş modeline uyması için değiştirilir. Hızlı uygulama kısa yollar ile çelişir. Kısa yollar projenin kontrolünü elden kaçırma potansiyeli taşıdığı için tehlikelidir. Açıkgöz olmayan kişiler tarafından yapılan kısa yollar geriye dönük izleme gerektirecek durumlar yaratabilir. Bunun da maliyet ve zaman etkileri olabilir, projenin saygınlığını, kullanıcıların kabulünü etkileyebilir ve aynı zamanda müşteriler ve tedarikçilerle olan ilişkilere hasar verebilir. Test edilmemiş bir sürecin canlı döneminde kullandığını düşünelim. Canlı kullanım sırasında ortaya çıkan problemlerin bileşkesi sürecin askıya alınmasını ve işi bir şekilde idare etmeyi sağlayacak idareten bir çarenin, geçici olarak kullanılmasını gerektirebilir. Bu arada da süreç yeniden incelenir ve yeniden geliştirilir. Eğer sürecin arzulanan görevleri yapar hale

105

getirilmesi sekiz hafta alırsa çoğunlukla davranışların değişmesi için de bir sekiz hafta gerekir. Eğer çok sayıda süreç etkilenirse zarar katlanarak büyür. Kısa yol seçilmesi halinde bu sonuçlar doğabileceğinden uygun değerlendirme yapılmalıdır. 11.2 Projenin yönetilmesi

Uygulamanın doğası öyledir ki; konu en iyi yolun proje yönetim yaklaşımı ile ele alınır. Uygulamanın içerdiği faaliyetler normal iş olayları ile doğal olarak uyum göstermez. Bu faaliyetler sonlu zaman içinde yapılırlar. Bir son noktaları bulunur, bundan sonra yapılan daha fazla iş faaliyetler tarafından emilmelidir. Bu faaliyetler aynı zamanda kendilerine tahsis edilmiş kaynaklara ve geliştirilmesi gereken özel yeteneklere de gereksinim duyarlar. Çok disiplinli ve takım yönelimli bir çalışmadır. Karmaşıklık giderek artan sayıda insanın normal faaliyetlerini bırakıp, konuya dahil edilmeleriyle iyice artar. Böylelikle çalışma klasik departman yönelimli tarzdan uzaklaşmış olur. Proje yönetiminin etkin olabilmesi için doğru ortama gereksinim bulunur. PA danışmanlık grubu etkin yetenekli bireyler ile “destekleyici proje kültürü” konularını birbirlerinden ayırt etmektedir. Onlara göre başarısız projelerin nedenlerinden bir tanesi “yanlış ortam”dır. Bu verimlilik karşıtı organizasyonel kültür şeklini alabilir veya uygun olmayan kurum katılımı veya kurum içi sponsorluk şekline dönüşebilir. Bu önceki ifadelerde yer alan belli kültürlerin diğerlerinden daha iyi başarıya götürdüklerine olan inancı artırır. Bu tür kültürlerin doğasını daha iyi kavrayabilmek sıklıkla uygulamayla iç içe girmiş, önerilen bir örgüt yapısını incelemekle olanaklı hale gelir. 11.2.1 Organizasyon

Tavsiye edilen organizasyonun formatı takip eden cümlelerde verilmektedir. İmplementasyonu yöneten kişi proje müdürüdür. Proje müdürü, gelişmeleri gözden geçiren ve politika ya da kaynaklar konularındaki sorunları çözen yönlendirme komitesine rapor verir. Başkan) veya Genel Müdür (ya da işletme yöneticisi) yönlendirici komitenin lideridir ve projenin sponsorluğunu yapar. Proje yöneticisi için çalışanlar proje ekibinin üyeleridirler ve yeni yazılım kullanılarak yürütülecek süreçleri geliştirirler. Ekip üyeleri yeni süreçleri canlı kullanım gününe kadar hazır ederler, dokümantasyon hazırlarlar ve kullanıcılar eğitirler. Satıcı firma danışmanlarından birini proje yöneticisine destek vermesi ve diğer

106

satıcı kaynaklarının koordine edilmesi için atar. Satıcı danışmanları en iyi iş pratikleri, yazılım fonksiyonalitesi ve teknik konularda yardımcı olurlar. Projene ekibine ilk eğitimi satıcı firma, danışmanları veya uzman eğitimcileri aracılığıyla verir. Proje ekibi işleri yeni yapma yollarını geliştirdikten ve bunları kanıtladıktan sonra prosedürlere ilişkin dokümantasyonu hazırlar ve son kullanıcıları eğitir. Sözü edilen kişilerin proje kapsamındaki sorumlulukları tablo 11.1’de verilmiştir.

ROL

SORUMLULUKLAR

GENEL MÜDÜR • VİZYON ŞAMPİYONU, • PROJE SPONSORLUĞU

YÖNLENDİRİCİ KOMİTE

• İMPLEMENTASYON İÇİN UYGUN KOŞULLARI GARANTİ ETMEK

• AMAÇLARI KOYMAK • PROJE ÖLÇEĞİNİ, AMAÇLARI, ORGANİZASYON

PLANINI, METRİKLERİ ONAYLAMAK • KAYNAKLARIN ELDE EDİLEBİLİRLİĞİNİ GARANTİ

ETMEK • PLANLARA GÖRE GELİŞMELERİ İZLEMEK • ÖNLERİNE GETİRİLEN KONULARI ÇÖZÜME

KAVUŞTURMAK • ERİŞİLEBİLİR YARARLARIN MUHASEBESİNİ TUTMAK

PROJE YÖNETİCİSİ

• YÖNLENDİRİCİ KOMİTEYE RAPOR VERMEK • PROJE LİDERLİĞİNİ ÜSTLENMEK • PROJE KAPSAMINI KONTROL ETMEK • PROJE PLANINI YARATMAK, YÖNETMEK,

İLERLEMELERE GÖRE GÜNCELLEŞTİRMEK • PROJE EKİBİNİ KURMAK, GELİŞTİRMEK VE ONA

ÖNDERLİK ETMEK • KAYNAKLARA İLİŞKİN SORUNLARI İZLEMEK VE

ONLARA ÇÖZÜM ARAMAK • PROJE EKİBİ TARAFINDAN ÇÖZÜMLENEMEYEN

SORUNLARI ÇÖZÜMLEMEK VEYA YÖNLENDİRİCİ KOMİTEDEN ÇÖZÜM TALEBİNDE BULUNMAK

• DEĞİŞİMİ KOLAYLAŞTIRMAK • YAZILIM DEĞİŞİKLİKLERİNİ KONTROL ETMEK • İLETİŞİM KURMAK • SATICI FİRMAYI YÖNETMEK

PROJE EKİBİ ÜYELERİ

• YAZILIMIN NASIL İŞLEV GÖRDÜĞÜNÜ ANLAMAK • SÜREÇLERİ TESLİM ETMEK • DOKÜMANTASYONU ÜRETMEK • KULLANICILARI EĞİTMEK

IT MÜDÜRÜ • DONANIMIN, NETWORK VE YAZILIMIN TEKNİK GEREKSİNİMLERİNİ YÖNETMEK

SATICI PROJE MÜDÜRÜ

• İMPLEMENTASYON PROJESİNİNE İLİŞKİN ÖNERİLERDE BULUNMAK

• SATICI KAYNAKLARINI VE ÜÇÜNCÜ PARTİ FAALİYETLERİ YÖNETMEK

• SATICIYA İLİŞKİN SORUNLARI ÇÖZMEK VEYA İLK TEMAS NOKTASI OLARAK KENDİ ŞİRKETİ İÇİNDE

107

DOĞRU YERLERE TAŞIMAK • EĞİTİM GEREKSİNİMLERİNE İLİŞKİN ÖNERİLERDE

BULUNMAK VE EĞİTMİ KOORDİNE ETMEK SATICI DANIŞMANLARI

• YAZILIM FONKSİYONALİTESİNE VE EN İYİ UYGULAMALARA İLİŞKİN ÖNERİLERDE BULUNMAK

• EĞİTİM VERMEK Tablo 11.1 11.2.1.1 CEO/MD

En üst rol CEO (Başkan) / MD (Genel Müdür) olarak adlandırılan genel müdüründür. Bu kişi iki anahtar sorumluluk üstlenmiştir. Bunların ilki değişimi hızlandırma fırsatı sunan kurulumu kullanarak erişilecek olan vizyonun reklamını yapmaktır. Bu vizyonun ne kadar radikal olduğu bu kişiye, diğer yüksek dereceli yöneticilere ve vizyonu paylaşıp ona katkıda bulunan diğer çalışanlara bağımlıdır. Bu vizyon, Michael Hammer’ın görüşüne uzansa bile kurulum kültürel değişimi yönetmek ve organizasyonun maddi olmayan değerlerini açığa çıkarmak için bir fırsattır. Hangi gereksinimlere erişilmesi gerektiğine ilişkin vizyon organizasyonun neyi yapabileceğini de yansıtır. Organizasyonun dağları mı, köstebek tepeciklerini mi yerinden oynatabilme yeteneğine sahip olduğuna bakılmaksızın gelişme üzerine odaklanması gerekir. Ancak hırs ne kadar büyükse o kadar da adanmışlık gerekir. Bu ifade özellikle değişime en fazla direnç gösteren üst ve orta yönetim için geçerlidir. Bu yeteneği değerlendirmek ve uygun biçimde yönlendirmek genel müdürün görevidir. Diğer sorumluluk projenin sponsorluğudur. Bu projenin önemini vurgulayacak, proje yöneticisinin konumunu destekleyecek, aynı görüşte olmayan orta ve üst yöneticileri hakem rolü oynayarak uzlaştıracak ve projenin canlılığını yitirmemesini garanti edecek, gerektiğinde proje yöneticisin değiştirmek de olan diğer faaliyetleri yerine getirmek anlamına gelir. Genel Müdür alay ve eleştirilerin önüne geçmek için konuşma yapmak ve eylemde bulunmak arasındaki dengeleri de çok iyi kurmak zorundadır. 11.2.1.2 Yönlendirici Komite

Yönlendirici komite, üst yönetim takımının ilgisini gösteren bir üst yönetici grubudur. Büyük şirketler haricindeki her şirkette yönetim takımından ayrı bir takım oluşturmak gerçekçi olmayabilir. Bu durumda proje yöneticisi yönetim takımına haftalık iş gözden geçirme toplantılarında, bu yapılmıyorsa özellikle bu proje için

108

düzenlenecek haftalık toplantılarda rapor verir. Yönlendirici komite amaçları tanımlar, gelişmeleri izler ve kendi dikkatine sunulan konuları çözümler. Koşulların kurulum için uygun olmasını garanti eder. Bunun anlamı proje ekibi üyeleri arasında yaşanan uzlaşmazlıkları çözümlemek, proje liderinin kendilerine taşıyabileceği üzerinde eylem yapılacak konuları karara bağlamak, ekstra zaman ve çaba harcayan çalışanları dikkate almak, ilerlemeyi engelleyen, yararların gerçekleşmesinin önüne geçen her türlü bariyeri ortadan kaldırmak da yer alır. Yönlendirici komite, özellikle, proje ekibi örgüt içi deneyime sahip değilse, proje yönetimi ile kendi yönetim stilleri arasındaki olası akort bozukluğundan haberdar olmak ve bunu dengelemek durumundadır. 11.2.1.3 Proje Yöneticisi

Baş rol proje yöneticisinindir. Proje yöneticisi hızlandırıcı rolü üstlenerek işlerin yapılmasını çabuklaştırır. Bir proje yöneticisinin profili şu karakteristikleri içerir: yapabilme becerisi, iletişimci, iş hakkında bilgi, şirket içinde saygınlık, diplomat ve kolaylaştırıcı, kalın derili ve esnek. Proje yöneticisi aynı zamanda lider, projenin ilerlemesine ilişkin kayıtları tutan, proje planını güncelleyen, yazışmaları denetleyen ve faturaları kontrol eden kişidir. Proje yöneticisi yukarıdan görünür destek almazsa etkisiz olabilir. Proje yöneticisi üzerinde otoritesi olmayan kişilere iş yaptırmak gereksinimi duyabilir. Eğer çok sevilen bir kişi ise çalışanları işbirliği yapmaya ikna edebilir. Proje ekibi zamanlarını normal görevleri ile proje arasında böldüklerinden çeşitli sorunlar çıkabilir. Neyin öncelik alacağı konusunda operasyonel gereksinimler ağır basabilir. Benzer şekilde işlere ilişkin kararları her departman diğerinin üstüne atabilir. Bu tür değişiklikler anlamlı olsa da departman müdürlerinin itirazlarıyla karşılaşılabilir. Departman aşırı yüklü olabilir ve çalışan sayısının az geldiği ileri sürülebilir. Sponsorun görevi bunlarla ve diğer zor durumlarla başa çıkmaktır. Bu nedenle proje yöneticisi ile sponsorun görevlerini birbirlerini tamamlar nitelikte olup başarı için esastır. Başlangıçta projenin iyi ilerlediği, ancak proje sponsorunun ayrılmasından sonra duraklamaların oluştuğu örnekler görülmüştür. Günler sürmesi gereken işler proje yöneticisinin sponsorun statüsüne sahip olmaması nedeniyle aylar sürer hale gelmiştir.

109

11.2.1.4 Proje Ekibi

Proje yöneticisi bir ekip oluşturmak zorundadır. Ekibin işi, mevcut süreçleri anlamak, yazılımı nasıl kullanacaklarını öğrenmek ve yeni enformasyon sistemi kullanılarak işlerin nasıl yapılacağını belirlemektir. Şirketin, proje amaçlarının ve yalnızca bir enformasyon sistemi mi isteniyor, yaksa bunun ötesine mi geçiliyor? sorusunun yanıtına bağlı olarak proje ekibi tam veya yarı zamanlı olabilir. Proje yöneticisi düzenli toplantılar yaparak ekip üyelerinin tamamının neler olup bittiği hakkında bilgi sahibi olmalarını sağlamalıdır. Bu toplantılar, ilerlemelerin gözden geçirilmesi, altı çizilmesi gereken konuların belirlenmesi ve problemlerin paylaşılması için de bir fırsattır.

Proje işlerinin doğası ideal proje ekibi üyesi profilinin öğrenme ve düşünme yeteneğini, açık fikirliliği içermesini önerir. Yaratıcılık ve kritik analiz yetenekleri yeni süreçlerin planlanması için arzulanan özelliklerdir. Ekip üyeleri, problem çözme yeteneğine işleri yapma isteklerinin önündeki engelleri aşma gücüne sahip olmalıdırlar. Kendi özel fonksiyonları alanında uzman olmaları gerekmekle birlikte, proje ekibi üyelerinin kendi aşina oldukları konunun dışında ortak çalışma alışkanlığında olmaları çok yaygın olmadığından bu çok da büyük önem taşımamaktadır. Aşina olmamak gereksiz soruların doğmasına yol açabilmektedir. Bu da çeşitli söylentilerin yayılmasına yol açabilmektedir. Üyeler üzerinde çok sayıda iş yükü bulunmaktadır. Yazılımın işlevini nasıl yerine getirdiğine ilişkin detaylı bilgi sahibi olmaları gerekmekte, süreç haritalama, prototipleme, eğitim verme, normalde asla karşılaşmayacakları türden problemleri çözme, daha fazla benimsenecek süreçler üretme gibi yeni beceriler edinmeleri zorunluluk olmaktadır. Bütün bunlar ekip üyeleri üzerinde özgüven kaybı yaratabilir. Proje yöneticisi, bütün bunlardan haberdar olmalı ve ekibini desteklemelidir. İdeal proje ekibini oluşturmada en büyük engel insanların kullanılabilirliğidir. Proje ekibi için en uygun kişiler en yüksek olasılıkla, anahtar pozisyonda olmaları nedeniyle, boş zamanı en az olan kişilerdir. Örgüt ne kadar küçük olursa bu konu da o kadar kritik olur. Kimin seçileceğine ilişkin çok daha az seçenek olur. Seçilen kişilerin üzerinde çok büyük zaman talebi olur. Hem normal görevlerini hem de proje kapsamındaki işlerini yerine getirmeleri için pek çok ay boyunca, hafta sonları da dahil olmak üzere uzun saatler çalışmaları gerekir. Bu süre içinde uygulamanın kritik aşamalarına denk gelebileceği için izinlerinin sınırlanması

110

gerekebilir. Boş zamanlarını bu şekilde sürekli ihlal etmek aile yaşamlarını olumsuz etkileyebilir ve zaman zaman şirkette yatmaları daha iyi olabileceğinden bunun önleminin alınması gerekir. Bu nedenle ekip üyelerinin gözden geçirilmesi ve tatillerde yaptıkları çalışmalar için ödemeler yapılması haksızlık olmaz. Bunun yanında, özellikle alışılagelmedik işler söz konusu olduğunda, herkesin ayrı bir öğrenme stili olduğu, farklı iş yapma potansiyelleri taşıdıkları dikkate alınmalıdır. Zaman geçtikçe takım üyelerinin ilgi kaybı yaşayıp yaşamadıkları, küskünlüğe kapılıp kapılmadıkları, bıkıp bıkmadıkları dikkatle gözlenmelidir. Takım üyeleri şirketi terk ederlerse yerlerine yenilerini koymak gecikmelere neden olacaktır. Takımın çalışma ortamın da önem verilmesi gerekir. İdeal olanı insanların rahatsız edilmeden çalışabilecekleri özel bir oda hazırlamaktır. Bu oda şekil ve çizimlerin asılmalarına olanak verecek şekilde çok geniş duvar yüzeylerine sahip olmalıdır. Odada birbirlerine bağlanmış PC’ler, masalar, dokümanların konabileceği raflar bulunmalıdır. Ayrıca danışmanların kendi taşınabilir bilgisayarlarını şebekeye bağlayabilecekleri uçlar da hazır olmalıdır. Bu oda projenin sinir sistemi merkezi olarak görev yapacaktır. Oda iş çalışma ortamı olmanın yanı sıra proje toplantılarının yapılacağı yer ve eğitim salonu olarak da hizmet verecektir. Oda canlı kullanıma geçildikten sonra sürekli iyileştirme takımlarının çalışma yeri olacağı ve şirkete yeni giren kişilere eğitim verme amacıyla kullanılacağı, kendilerini geliştirmek, yeteneklerini ilerletmek isteyenlerin yararlanmaları, yeniden düzenlenen süreçlerin test edilebilmeleri için terk edilmemelidir. 11.2.1.5 IT Uzmanı

Takımın içinde teknik konularla ilgilenen bir IT uzmanı da bulunur. Bu kişi donanımın, yazılımın kurulumu ve devreye alınması, sistem bakımının yapılması, güvenliğin oluşturulması gibi konulardan sorumludur (kısım 11.3). Fonksiyonalitenin nasıl gerçekleştiğine ilişkin sınırlı bilgisi olsa da zaman içinde bunu artırarak destek sağlayabilir duruma gelebilecektir. 11.2.1.6 Satıcı Personeli

Gözden kaçırılmaması gereken bir kişi de satıcı personelidir. Satıcı danışmanlarından birini proje yöneticisi olarak atar (kısım 11.2.8). Bu kişinin kılavuzluk edebilmesi ve proje ekibinin tüm üyelerini destekleyebilmesi için yazılım ve implementasyon üzerinde

111

deneyimli olması gerekir. Normalde bu kişi satıcı firmanın ilk temas noktasıdır ve satıcı firmanın farklı çalışanlarında toplanmış olan bilgileri bu kişinin üzerinde akar. Bu farklı çalışanlar danışmanlar, teknik danışmanlar, eğitimciler ve programcılardır. Yukarıda tasvir edilen Organizasyonel yapı implementasyonun çok sayıda kişiyi içeren ve uzun zaman alan karmaşık bir faaliyet olduğunu yansıtır. Bu organizasyonel yapı takım üyelerinin günlük işlerini aksatmadan yapmalarına olanak vermeli, bunun yanında konuların kolayca ele alınıp çözümlenmesini sağlayacak şekilde bir raporlama sistemi de içermelidir. Herkesin sorumlulukları açık ve net olmalıdır. İletişim en önemli konudur. Farklı şirketlerde ölçeğe, sponsora, yönlendirici komiteye, proje yöneticisine, başarı için esas teşkil eden geliştirme takımına bağlı olarak bu organizasyonel yapının varyantları ortaya çıkar. Bu yapının sürekli iyileştirme programlarını uygulamayı benimsemiş şirketlerdeki yapıdan farklı olmadığını belirtmek enteresan olacaktır (kısım 14.1). İmplementasyonun başarısızlığa uğradığı veya öyle sanıldığı durumlarda organizasyonel konulardaki başarısızlıkla ilgili çok sayıda neden ileri sürülür (kısım 10.1) 11.2.2 Ölçek/Faaliyet alanı

Anahtar kararlardan biri implementasyonun faaliyet alanıdır. Bir seçenek büyük patlama (Big bang) olarak adlandırılan eski sistemden yeni sistem komple geçiş yapmaktır. Diğer seçenek yazılımı aşamalar şeklinde devreye almak; temel yetenekleri önce, ek fonksiyonaliteyi ardışık aşamalarla kullanıma geçirmektir. Her iki durumda da hem eski hem yeni sistemin paralel çalışmaları seçeneği de bulunur. Dikkate alınmaları gereken seçenekler arasında çok sayıda etmen bulunur:

• İmplementasyonun hızı veya aciliyeti • İmplementasyon işlerini üstlenecek kişilerin sayısı • Tüm kullanıcıları eğitmek için kullanılabilecek zaman • Maliyet • Yeni sisteme duyulan güven • İşlemlerin kesintiye uğraması • Toplam süre

Hangi seçenekte karar kılınırsa kılınsın implementasyona dahil olacak kişilerin normal zamanda günlük işlere ayıracakları zamanların büyük kısmının geliştirme çalışmalarına sarf edilmesi gerekecektir. Soru günlük işlerin nasıl yerine getirileceğidir. Bir

112

seçenek normal işleri yapacak kişileri geçici olarak işe almaktır. Buradaki varsayım gerekli kişilerin bulunabileceğidir. 11.2.3 Proje Planı

Proje planı, proje ile ilgili kim, ne, niçin, nerede, ne zaman ve nasıl sorularına yanıt verir. Bu çalışmadan etkilenen kişilerle yapılan görüşmelerin, kaynaklar üzerindeki müzakerelerin, zaman ve üzerinde uzlaşılan maliyetlerin bir çıktısıdır. Planın gerçekçi olması gerekir, aksi halde, örneğin zaman çok kısa ise planın bozulma olasılığı doğar, eğer zaman çok uzun olursa projenin momentumu kaybolur. Plan proje için bir kılavuz görevi görür ve ilerlemeleri izlemede kullanılır. Çalışanların birbirleriyle bağlantılı işleri koordineli biçimde yerine getirmelerine olanak sağlar. Kötüye gidişler fark edilir ve tedavi edici önlemler alınır. Gerekirse tarihler yeniden düzenlenir. Planın proje ile ilgili konuları bilmeleri gereken herkese gösterilmesi, onların ilerlemelerden ve değişikliklerden haberdar edilmesi önem taşır. En temel plan tüm faaliyetleri kimin, hangi zaman aralığı içinde yapacaklarını gösterir. Proje planı elle yazılmış veya bilgisayar programı çıktısı şeklinde olabilir. Spreadsheet basitlik ve her yerde bulunabilirlik sunar. Dahası PC’lerde standart bir araç olarak bulunduğundan rahatlıkla diğer çalışanlara dağıtılabilir. Alternatif olarak uzmanlık paketleri içinde Microsoft Project de kolayca erişilebilir bir yazılımdır. Projeyle ilgili çok sayıda detayın toplanması kritik yolun görülmesi, maliyet, kaynak kullanımı, genel giderler benzeri farklı konuların kolayca raporlanabilmesi gibi çeşitli avantajlar yaratır. Temel konu karmaşıklığın düzenlenmesi, güncellenmesi ve yönetilmesidir. Bu da gerekli detay miktarının bir fonksiyonudur. Dolayısıyla hangi detayın yararlı olacağı sorusunun sorulması gerekmektedir. Diğer bir konu da planın nasıl dağıtılacağı ile ilgilidir. Uzman bir proje yazılım paketi hazırlanmış planlar tüm alıcılarda bu yazılım bulunamayabileceği için ne nasıl dağıtılacak sorusunu gündeme getirirler. Varsayılan proje planı içeriği spreadsheet formatında şekil 11.1’de verilmiştir. İmplementasyon zamanı 12 ay, başlangıç 1 Ocak, canlı kullanıma geçiş Ekim sonudur. Canlı kullanıma geçiş tarihi hafta sonuna denk gelmekte, böylelikle ana-verisi olmayan dinamik verilerin toplanıp sisteme yüklenmesi olanağı bulunmaktadır. Şubattan Ağustosa kadar proje ekibi yeni süreçleri kurmakla ilgili işleri yürütmektedirler. Şirketin yıl sonu Haziran sonu olduğundan bu dönemde operasyonel görev yapmakta olanlara projeden en az

113

iş yükü düşecek şekilde bir ayarlama yapılmış bulunmaktadır. İş yükleri gerçekte Eylül ayında yeni süreçlerin yayılması ve kullanıcıların eğitilmesi ile artmaktadır. Canlı kullanıma yaklaştıkça veri aktarımları hız kazanmakta canlı kullanımdan hemen önceki günlerde dinamik verilerin yüklenmesiyle doruğa ulaşmaktadır. Sonraki iki ay boyunca olaylar izlenmekte ve çıkan sorunlarla uğraşılmaktadır. Bu dönemin sonunda formel proje fazı projenin gözden geçirilmesi ile son bulmaktadır. Burada öğrenilenler sonraki safhalarda işe yarayacaktır. Canlı kullanıma geçirilen fonksiyonlar sürekli iyileştirme mantığı perspektifinden dikkate alınacaktır. Pratikte bir proje planı şekilde verilmiş olan ay bazındaki incelemeden daha çok haftalar bazında ve çok daha fazla detay içerecek şekilde ele alınır. Başlangıç, bitiş tarihlerini, saat olarak iş miktarını, tamamlanma yüzdelerine ilişkin tahminleri, gecikmeleri, maliyetleri ve ilgili diğer konuları tanımlayacak ek sütunlar kullanılabilir. Bazı işler diğerlerinin tamamlanmasına bağlı olacakken, diğerleri paralel yürüyebilecektir. İşlere ayrılacak zamanların gerçekçi olması gerekir. Aşırı iyimser zamanlar kısa süre içinde içinde bir daha yakalanamayacak şekilde gecikmiş duruma düşecektir. Bunun ekip üyelerinin morallerini bozucu etkisi bulunur. Benzer şekilde eğer ayrılan zamanlar çok uzun olursa ivmelenme asla sağlanamayacak ve ataletten oluşacak gecikmeler yaşanacaktır. Plan oluşturulduktan sonra planların gelişmelere göre güncelleştirilmesi, gerekirse revize edilmesi yararlı olacaktır. Problemlerin çıkması gecikme olasılığının doğması demektir. Gerçekleri saklamaktansa günleri biraz ötelemenin daha olumlu sonuç vereceği ileri sürülebilir.

114

11.2.4 Bütçe

Tanımlanan maliyetlerle bir bütçe hazırlanabilir. Problemler ve öngörülemeyen konular nedeniyle ek harcamaların çıkması da

Fig

ür

11.1

Bir

pro

je p

lanı

örn

eği

115

beklenmelidir. Bunlar için bir ödenek ayrılıp ayrılmayacağı finans departmanın vereceği bir karardır. Proje süresince yapılacak harcamalar bütçedeki paylar ile karşılaştırmalı olarak izlenir. Oluşabilecek sapmalarda yüksek pay projenin başlangıç aşamasında danışmanlık giderleri, düşük pay da projenin sonlarına doğru eğitim harcamaları konularında gerçekleşir. Danışmanlık giderlerinin detaylarının daha seçim sürecindeyken belirlenmesi ve aşırı harcamaların engellenmesi için de izlenmesi gerekir. Seçim aşamasından implementasyonun sonuna kadar proje niteliğinde herhangi bir değişiklik olmadığı takdirde tahmin edilmiş olan bu harcama değeri kabaca nelerin öngörülmüş olduğunu yansıtır. Burada anlamlı bir sapma oluşursa elbette nedenlerin soruşturulması gerekir. İzlenmesi gereken diğer maliyet kalemi eğitimdir. Bütçede aşırı harcamalar olacağına ilişkin bir gösterge ortaya çıkarsa önce eğitim harcamalarından kısıntı yapılır. Oysa projelerin gidişatını belirten rapor-larda en sık eleştirilen konu eğitimlerin uygunsuzluğudur (Bölüm 10). 11.2.5 Problem çözümü

Kurulum sürecinde çözüm gerektiren pek çok konu ortaya çıkar. Burada tehlike bazı konuların farkına varılıp tanımlanmalarına karşın unutulmalarıdır. Bunlar sonradan, belki de canlı kullanım sırasında, yeniden su üstüne çıkarlar. Bu nedenle problemlerin kaydedilmesi ve çözülmeleri için üzerinde uzlaşılmış bir prosedür seti oluşturmak arzulanır. Bu ister bir tablo, ister daha gelişmiş bir süreç olsun pratikte kabul edilmiş olması, diğer deyişle uygulamanın benimsenmesi önemlidir. Basit bir yaklaşımla çözümlenememiş konular kayıt altına alınır. Böylelikle zaman içinde sorunların unutulmasının önüne geçilir. Bu aynı zamanda ek destek gerektiren, satıcı firmanın veya üst yönetimin kararlarına bağlı olan konuların atlanmasını önler. Bu şekilde problemlerin izlerinin sürülmesi ileriki tarihlerde hoş olmayan olaylarla karşılaşma olasılığı azaltılmış olur. 11.2.6 Risk değerlendirme

“Bir şeyin kötü gitme olasılığı varsa, kötü gidecektir” deyişini hiçbir zaman göz ardı etmemelidir. Bir takım konuların beklenmemesi ve önlem alınmaması nedeniyle nice detaylı projenin çöpe gittiği çok görülmüştür. Bunun olmaması için tedbirli davranmak; risk değerlendirmeleri yapmak gerekmektedir. Bunu yapmaktaki amaç olası problemleri beklemek, ortaya çıkma olasılıklarını ve etkilerinin

116

şiddetlerini değerlendirmek ile nihai olarak nasıl önlenebilecekleri veya önleme olanağı yoksa nasıl ele alınmaları gerektiği konularını karara bağlamaktır. Risk değerlendirme konularında çok sayıda iyi çalışma bulunmaktadır, örneğin Remenyi bunlardan biridir. Pek çok kişi riskin ön koşullarını anlamak yerine, “burada daha önce böyle bir şey olmadı” cümlesini kullanmayı yeğler. Konuyu basit kılmak için temel yaklaşım kullanılmalıdır. Hareket noktası projenin başarısız olma potansiyelidir. Zihinlerde oluşması gereken soru şudur… Niçin? İlk iş kapsamda nelerin olduğunu anlamaktır. Risk üzerindeki bu söylev “Kurulum” bölümünde sunulmuş olmakla birlikte kurulum sürecinde ortaya çıkan sorunların seçim sürecinin başlangıç aşamalarında yapılan dikkatsizlikler nedeniyle oluşabildiği de hatırda tutulmalıdır. Ancak buradaki varsayım değerlendirme yapan kişi(ler)in ERP seçimi ve kurulumu sürecine aşina oldukları veya bu kitabı okudukları varsayımıdır. Ancak çoğu kişi için bu yeni bir deneyimdir ve projeye ilişkin yönetsel konular öğretilinceye, proje planı hazırlanıncaya ve bizzat kurulum başlayıncaya kadar bu konuda yeterli bir kavrayış gelişmez. Her halde risk değerlendirme yapmak geç kalmış olmaz, uykudaki bazı problemler için de koşullar önceden hazırlanmış olur. Nelerin kapsam dahilinde olduğunun anlaşılması potansiyel risklerin belirlenmesine yardımcı olur. Potansiyel risklerin kavraması başkalarının karşılaşmış olduğu problemlerin gözden geçirilmesi yolu ile olur (kısım 10.1). Bunların çoğu insanla ilişkilidir. Teknolojik ve metodolojik konular daha az önemdedir. Sonuç hantal ve uzun bir listedir. Bundan sonra hangi risklerin daha önemli olduğu ve üzerlerine odaklanılması gerektiği saptanır. Her risk proje ve şirket üzerinde ne kadar etki yapabileceği, ortaya çıkma olasılığının ne olduğu açılarından değerlendirilir. Bu sübjektif bir süreçtir ve çeşitli kişilerin görüşleri bu değerlendirmeye yardım eder. Eğer bir riskin hem yaratabileceği zarar, hem de oluşma olasılığı yüksekse derhal ele alınması gerekir. Benzer şekilde düşük zarar getirebilecek, ancak oluşma olasılığı yüksek riskler de dikkate alınmak zorundadır. Düşük değerli riskler bir kenara bırakılabilir, ancak asla yok farz edilmezler. Bu çalışma yalnızca riskleri önceliklendiren ve onlara dikkat çeken bir sonuç üretir. Sonuç kötüye gitme olasılığı olan olayların azalmasıdır. Bununla beraber risk değerlendirme projenin başında bir kez yapılmış olduğu için bir daha yapılmaması gereken bir faaliyet olmayıp düzenli olarak yeniden gözden geçirilir. Süreç geliştirme ve

117

yaşanan değişimler önceleri ihmal edilebilir kategorisine giren risklerin profilini yükseltir. 11.2.7 Performans

Performans konusu kontrol ve hedef konseptleriyle ilişkilidir. Şimdiye kadar üç performans ilişkili ölçüte değinildi; maliyetler (kısım 11.2.4; bütçe), zaman (kısım 11.2.3; proje planı), yararlar (kısım 6.3; maliyet-yarar). Ancak ERP kurulum projeleri bütçelerin aşıldığı, gecikmelerin yaşandığı ve yararların elde edilemediği projeler olarak şöhret salmış projelerdir. Dahası proje süresi çok uzun olduğundan, tüm fonksiyonların niyet edildiği şekilde çalışacağından canlı kullanıma geçinceye kadar emin olmamak doğru değildir. Proje planı hangi işlerin yapılmaları gerektiğini tanımlar. Amaç bu işleri yapmaktır. Bu işlerin gerektiğine ve niyetlenildiği gibi yerine getirildiğine ilişkin bazı göstergelerin bulunması arzulanır. Varsayım bir işin yapılması ile bir amaca ulaşıldığıdır. Bu sayede, örneğin bir kullanıcının eğitilmesi sonucunda kullanıcı özel bir fonksiyon kümesini kullanabilir hale gelmelidir. Benzer şekilde bir sürecin prototipi detaylı özellikleri belirtilmiş, ama test edilmemiş sürecin ön tanımları yapılmış gereksinimleri karşılaması gerekir. Kurulumun her adımı veya adım serisi için amaçların tanımlanması ve bunlara erişilmese ilerlemelerin gösterilmesi gerekir. Amaçlara erişildiği takdirde problemlerin önceki aşamalar nedeniyle ortaya çıkma olasılığı düşük olacaktır. Ters şekilde bu amaçlara erişilemediği durumlarda sonraki aşamalarda problem yaratma potansiyeli yükselecektir. Dahası ilerlemeler metodik biçimde izlenir olacaktır. Her görev veya görevler bütünü başarıyla tamamlanıp tamamlanmadıklarına göre, örneğin eğitim verimli mi, dokümantasyon tamamlandı mı, yeni süreç amaca uygun mu, şeklindeki sorularla değerlendirilecektir. Maliyetler (kısım 11.2.4; bütçe), zaman (kısım 11.2.3; proje planı), yararlar (kısım 6.3; maliyet-yarar) ve son olarak belirtilen göstergelerden oluşan bu dört ölçüt hep birlikte kurulumun başarısının ölçülmesi için farklı boyutları oluştururlar. Sıklıkla maliyet ve zaman ölçütleri izlenir. Anlaşılabilir bir şekilde bunların finans ve işlemler üzerinde gözle görülür etkileri vardır. Seyrek olarak yararlar değerlendirilir. Yararların sonradan anlaşılabileceği iddia edilebilirse de, bunun yararı nedir? Ancak yararlara erişilip erişilmediği değerlendirilir ve nedenler irdelenirse olaylardan ders çıkarma ve öğrenme fırsatı kullanılmış olur. Bu dersler kurulumun ileriki aşamalarında işe yararlar.

118

Performansla ilgili göstergelerin kullanılması yapılan işlerin etkinliğinin, verimliliğinin değerlendirilmesi olanağı sağlar. Ancak bu potansiyel sürtüşmelerin de kaynağıdır. Bir işin usulüne uygun şekilde yapılarak tamamlanmasının istenmesi bir anda çok yüksek iş yüklerinin doğmasına ve buna bağlı olarak gecikmelere yol açabilir. Bahsedilen göstergelerin tutturulması diğer iki ölçütün kötüye gitmesi pahasına sağlanır: maliyet ve zaman. Dolayısıyla bir projenin başarılı olup olmadığını belirlemek için hangi göstergelerin kullanılması gerektiği sorusunu ortaya çıkarır. Bu ikilem göstergelerin ve hedeflerin birilerini suçlamada veya onlara üstünlük taslamada kullanılması ile iyice şiddetlenir. Her ne kadar göstergeler ilerlemenin ve hedeflere erişimin anlaşılması için araçlar sunsalar da kendi başlarına projenin başarısını belirlemezler. Onlar yalnızca sonraki eylemler için referans noktalarıdır. İnsanların ellerinden gelenin en iyisini yapmaları için onların yönetilmeleri konusuna alternatif oluşturmazlar. 11.2.8 Tedarikçi firmanın yönetimi

Sözleşme değiş tokuş edildikten sonra satıcı, proje yöneticisi ve ekibi yazılımın kullanılması aracılığı ile şirkete kılavuzluk etmeye başlar. Proje yöneticisi her şeyin hedeflendiği şekilde ilerleyebilmesi için diğer tüm kaynaklar gibi satıcı firmayı da yönetmek durumundadır. Aslında bu ilişkide satıcı firmanın eli potansiyel olarak alıcıdan daha güçlü konumdadır. Alıcı imzaladığı sözleşme ve belki de yapmış olduğu ön ödeme nedeniyle satıcı vaatlerini yerine getiremezse bile ilişkiyi sona erdirme konusunda isteksizdir. Danışmanlar diğer görevler nedeniyle her zaman ortalıkta olamayabilirler. Yazılım hataları gereken süreler içinde çözüme kavuşturulamayabilir. Yazılım linkleri çalışmayabilir. Bütün bunlar gecikmelere yol açar. Proje yöneticinin görevi tüm bunları yönetmektir. Büyük olasılıkla satıcı firma tek bir temas noktası atar; satıcının proje yöneticisi. Bu kişinin görevi proje yöneticine destek vermek, proje planı üzerinde önerilerde bulunmak ve plan üzerinde mutabık kalmak, müşteriyi yönetmek ve satıcı tarafından sağlanan kaynakları koordine etmektir. Her iki proje yöneticisi arasında satıcının görevlerini nasıl yapacağı ve bu görevler için müşteri firmadan nasıl izin alacağı bir prosedüre bağlanır. Bu sayede planlanmamış ziyaretler, yazılım üzerinde kullanıcılardan kaynaklanan değişiklik talepleri gibi izin verilmeyen olayların önüne geçilir. Satıcı firmanın atadığı proje yöneticisi, ister teknik, ister en

119

iyi uygulamalar, isterse satıcı firmanın göndereceği faturalarla ilgili olsun, problemlerin çözümü için ilk temas noktasıdır. Sözleşme içinde problemlerin ne şekilde ve hangi süreler içinde ele alınacağına ilişkin bir madde olmalıdır. Problemler çözülemediği takdirde nasıl bir yol izlenerek hangi mercilere çıkarılacağı bu madde içinde yer almalıdır. İletişim mutlaka yazılı olarak da yapılmalıdır. Böylelikle yanlış anlaşılmaların büyük ölçüde önüne geçilir. Proje yöneticisi organizasyonu ziyaretlerin zamanında ve verimli olması için yönetmek zorundadır. Bunun içinde gidilen tesisteki ilgili personelin zamanını bu işe ayırması da bulunmaktadır. Satıcının bir tesise gidip neler yapıldığını ve problemlerin neler olduğunu yazdığı raporlar hiç de az değildir. Bu ziyaretlerin verimliliği ile ilgili bir sıkıntı söz konusuysa daha formel mekanizmaların kurulması gerekecektir. Bu mekanizmalar satıcı firma tarafından ziyaret edilen tesiste görüşülmesi gereken kişilerin toplantılara katılıp katılmadığı bilgisini taşıyan yoklama raporlarının oluşturulmasını da kapsar. Amaç toplantının ne için düzenlendiği, amacına ulaşıp ulaşmadığı ve sonraki eylemlerin ne olduğu konularını açıklığa kavuşturmaktır. Bütün bunlar bürokratik olsa bile insan konularında sorunların olduğuna işaret etmekte, bir sonraki toplantıya kadar nelerin düzeltilmesi gerektiğini ortaya koymaktadır. Diğer işler maliyetlerin izlenmesini ve kontrolünü içerir. Satıcı firmanın personelinin tesiste bulunduğu zamanları izlemek ile danışmanlık maliyetleri, aşırı harcama potansiyeli bulunan bir alan (bakınız bütçe, kısım 11.2.4) izlenebilir. Elbette hatalar da yapılabilir ve satıcının gönderdiği faturanın kontrol edilmesi gerekir. Hatalara rastlanırsa sorgulama sonuçları çözüme kavuşturulması için satıcı firmaya gönderilir, sözleşmeye dayanarak gelen faturaların askıya alınması için gerekçe oluşturulur. Son olarak proje yöneticisi satıcının faturalarının zamanında ödenmesini sağlamaktan sorumludur. 11.3 Sistem konuları

Her ne kadar kurulumun fonksiyonel konularına odaklanılmış görüntüsü verilse de geri planda teknik konularla ilgili pek çok faaliyetin de yerine getirilmesi gerekir. Bu faaliyetler içinde donanımın ve yazılımın kurulumunu ve devreye alınmasını içerir. Bu kapsamdaki işlerin de proje planında tanımlanması gerekir ancak sorumlular enformasyon teknolojisi personelidir. Gerektiğinde satıcı firmadan teknik destek de alınacaktır. Konuya

120

ERP perspektifinden baktığımızda gözden kaçırılmaması gereken çeşitli sorular bulunur;

• ERP uygulaması yoğun kullanım altındayken sistem nasıl bir performansı gösterecektir?

• Sistem canlı kullanımdayken depolama hacmi ne hızla tüketilecektir? Yedekleme prosedürü nedir?

• Canlı kullanıma geçtikten sonra, yeni bir süreç geliştirme işi gerektiğinde, canlı kullanım ortamı üzerinde olumsuz bir etki yaratmadan başka bir ortam kullanılabilecek midir? Kaç adet alternatif ortam yaratılabilir? Diğer ortamda yaratılan yeni sürecin transferi ne kadar süre alacaktır?

• Aynı veriye iki kişi aynı anda erişmek istese ne olacaktır? Sistem kilitlenecek midir, kilit sonra nasıl açılacaktır?

• Bilgisayarların ve yazıcıların yerlerinin değişmeleri gerekmekte midir?

• Antetli kağıtların kullanımı yeğlenirse özel yazıcılar kullanılabilecek midir, kullanılabilecekse bunu yapmanın en uygun zamanı nedir?

• Sistem ne kadar güvenlidir? Kişilere göre kullanıcı erişimi kısıtlaması nasıldır? Ekran ile mi yoksa veri alanı ile mi yapılmaktadır? Şifreler nasıl yönetilmektedir? Hangi kullanıcı mönülerinin yaratılması gerekmektedir, bunlar nasıl yönetilecektir?

• Bir kullanıcı sisteme bağlanıp belli bir süre işlem yapmadığı takdirde otomatik olarak bağlantı kesilmekte midir?

• Felaket telafi prosedürü nedir?

Bu liste detaylı olmamakla birlikte çalışılması gereken konuların çeşitliliğini ortaya koymaktadır. Bu konular ne kadar erken tanımlanırsa üzerlerinde uğraşmak için o kadar fazla zaman olacaktır. Antetli kağıtlar için özel yazıcı gibi küçük bir detay gözden kaçırılırsa yazıcı konfigürasyonu zamanında yapılmayabilir ve örneğin satın alma siparişleri doğru bastırılamaz. Canlı kullanım durumunda satın alma siparişlerinin nasıl bastırılacağı sorununa çözüm aramak hammadde yokluğundan imalatın durması noktasına kadar gidebilir. Benzer şekilde kullanıcılar sisteme bağlanma prosedürü konusunda eğitim görüp, şifre almak zorundadırlar. Kullanıcılardan biri şifresini unutursa ne olacaktır? 11.4 Eğitim ve eğitim stratejisine gereksinim

121

Eğitim belki de kurulum fazının en yanlış yargılanan faaliyetidir. Başlıca şikayet yeterli eğitimin yapılmadığıdır (Bölüm 10). Her ne kadar eğitim bir proje yönetim faaliyeti ise de çoklukla ihmal edilen veya tutarlılık göstermeyen bir faaliyet olarak dikkat çekmektedir. Dahası eğitimin büyük kısmının kurulumun sonlarına doğru olması nedeniyle, maliyet bütçelerinin aşıldığı durumlarda ilk kısıntı yapılan kalem olmaktadır. Önemini vurgulamak için proje yönetim kısmında (kısım 11.2) ayrı bir başlık olarak işlenmiştir. Bu konuya ayrılan yer bu önemli faaliyeti ele alırken hangi başlıkların üzerinde durulması gerektiği hakkında genel bir görüş vermektedir. Eğitim ile ilgili çok şey yazılmış olduğunda daha detaylı incelemeler pek yerde bulunabilir. Bunlara ilişkin kısa bir metin seçilmiş okuma listesi içinde, kitabın sonunda sunulmuştur.

Eğitimi enformel bir yaklaşımla ele almak, çoğu kişinin bilgi ve yeteneği kendi yollarıyla edindikleri gerçeğini dikkate aldığımızda uygun olacakmış gibi görünse de “başarılı öğrenme çıktısı” açısından bakıldığında öngörülemez bir durum yaratacaktır. Eğitim konusunda daha formel bir yaklaşım altı aşamadan oluşan bir seri meydana getirecektir:

• Öğrenme amaçlarını tanımla-öğrenici eğitim sonucunda ne yapabilir olacaktır?

• İçeriği belirle-hangi yetenek ve bilgiler geliştirilecektir? • Plan-eğitim ne zaman ve nasıl verilecektir? Hangi kaynaklar,

materyaller, tesisler gereklidir? İçerik nasıl yapılandırılacaktır?

• Teslim-öğrenicinin deneyimi • Öğreniciyi değerlendirmek-öğrenici amaçlara erişmiş midir? • Eğitim oturumunun etkinliğini gözden geçirme-ne yanlış gitti?

Daha iyi nasıl olabilir?

Hazırlık vurgulanmaktadır. Eğitimin sonucunda alınması gerekenler başlangıçta proje ekibi üyelerinin ve sistem yöneticilerinin, daha sonra da son kullanıcıların ve yöneticilerindir. Diğerleri tanımlanabilir. Her öğrenici grubunun farklı gereksinimleri olacaktır. Böylelikle eğitimin doğası her başka öğrenici grubuna göre farklı olacaktır. Eğitim programının ana hatlarını ve eğitim politikasını tanımlayan bir eğitim stratejisi geliştirilebilir. Eğitim alacak her grup tanımlanır ve önceden belirtmiş olduğumuz altı aşamaya göre oluşturulan bir eğitim programı hazırlanır. Strateji eğitim amaçlarına ilişkin genel hatları belirler ve katılımcıların kimler olduklarını, farklı katılımcı gruplarını,

122

her grubun alacağı eğitim içeriğini kurslar ve oturumlar şeklinde düzenler. Bir plan eğitimin nerede, nasıl ve ne zaman yapılacağını ana hatlarıyla gösterir. Öncelikle öğrenicilerin değerlendirilmesine dikkat edilir. Onların bilgi ve yetenekleri nasıl değerlendirilecektir? Dahası eğitimin etkenliği ne olmalıdır ve bu nasıl değerlendirilecektir? Son olarak öngörülen maliyetlerin hesaplanması gerekir. Bu maliyetler daha sonra bütçe oluştururken kullanılacaktır. Sonuçta ortaya çıkacak strateji eğitim faaliyetleri ile ilgili bir çerçeve oluşturacaktır. Strateji şirket tarafından kabul edildiği takdirde uygulanabilir. Kabul edilmediği takdirde stratejinin gözden geçirilmesi gerekir. Temel konu şirketin kendini eğitime adamasıdır. Doğru denge doğru eğitim ile eğitimin maliyet etkin olması arasında kurulur. Bundan sonraki kısımlarda çoğu kurulum düzeyi ile ilişkili olan, eğitim stratejisi ile ilgili konulara değinilecektir. 11.4.1 Öğrenme amaçlarını tanımlama

Eğitim stratejini desteklemenin iki amacı bulunur. Önce satıcının personelinde müşterinin anahtar personeline bilgi transferi yapma söz konusudur. İkinci olarak sıra bu bilginin tüm organizasyona dağıtımına gelir. Daha kesin ifade ile öğrenme amaçları öğrenicinin eğitim sonucunda hedeflenen beceriye ne zaman erişeceğini saptar. Bilgi özellikle uygulamaya yönelik konularla ilgiliyse özellikle aranır. Bu bilginin şirket içinde nasıl kullanılabileceği de sorgulanabilir. Ancak eğitim kapsamında ağırlıklı olarak yazılım fonksiyonalitesinin kullanımına ilişkin yeteneklerin geliştirilmesi üzerinde durmak daha sık görülen davranışlardandır. Yönlendirici komitenin kurulum projesi kapsamındaki konulara ilişkin yeterli kavrayışa sahip olması, böylelikle potansiyel problemleri anlaması ve bu problemlere uygun katkıyı ve desteği vermesi gereklidir. Bu ifade özellikle proje sponsoru için doğrudur. Onun konuları yeterince anlamaması kurulumu normal bir proje gibi görmesine ve kendisini konunun içinden çekmesine yol açabilir. Tüm katılımcıların rol ve sorumluluklarına ilişkin yeterli bilgisi gelişmeyebilir ve problemler ortaya çıktığında kendi yapabileceklerine gereksinim olduğunu fark edemeyebilir. Canlı dönemde işlevselliğin en iyi şekilde kullanılması ve sonrasında kullanım düzeyinin iyileştirilmesi için proje takımı üyelerinin bu bilgi ve yetenekleri geliştirmeleri gerekmektedir. Ayrıca prosedürler geliştirmek için de özel yetenek sahibi olmaları gerekmektedir. Her biri çabalarıyla kendi alanlarında uzman haline gelecek, sonrasında da son kullanıcıların eğitmenleri olacaklardır.

123

Dolayısıyla bir eğitim vermek ve formüle etmek için de yetenek geliştirmek zorundadırlar.

Kullanıcılar kendi rolleriyle ilgili işlevselliği kullanabilecek yeteneğe gerek duyacaklardır. Bu her ne kadar başlangıçta eğitmenlerden aldıkları detay düzeyinde olmayacaksa da zaman içinde bireyler yazılım ile daha yakın olmayı ve bunu geliştirmeyi arzu duyabilirler. Diğer eğitim gereksinimi duyacak kişilerden yöneticilerin, en azından sistemin ne yaptığı hakkında bir anlayışa sahip olmaları gerekir. İdeal olarak proje yöneticisinin yazılımın her yönü ile ilgili iyi bir anlayışa sahip olması ve ortaya çıkan konularda etkili olması beklenir. Bazı seçilmiş kişiler ekran tasarımı yaptıklarından, rapor ürettiklerinden ve veritabanları üzerinde özel ve bir defalık (ad hoc) sorgulamalar yaptıklarında spesifik teknik eğitimler almaları gerekir. Sistem yöneticileri sistemi kurmak ve bakımını yapmak durumundadırlar. Sistem güvenliğini nasıl yöneteceklerine ve teknik problemlerle nasıl başa çıkacaklarına ilişkin bilgilere gerek duyarlar. Canlı kullanıma geçtikten ve proje ekibi dağıldıktan sonra işlevsellik konusunda çıkacak problemlerle baş edebilmeleri için işlevsellik konusunda belli bir düzeyde bilgi sahibi olmaları gerekmektedir. 11.4.2 İçeriği belirlemek

Eğitimin içeriği farklı elemanlara bölünebilir:

• Sisteme genel bakış: hem yazılımın bütünleşik bir paket olarak nasıl çalıştığını anlamak hem de sistem içinde rahatça dolaşabilmek için dikkatler uygulamanın yapısı üzerinde toplanır.

• Fonksiyonel detay: yazılımın özel bileşenleri üzerine odaklanılır; böylelikle farklı seçeneklere ilişkin deneyler yapılabilir ve en iyi uygulamalara erişilebilir. Buna yazılımı kullananlar açısından baktığımızda var olan fonksiyonlar nedir ve nasıl çalışmaktadır sorularını sormak anlamına gelir. Son kullanıcının işlevselliğin süreci nasıl desteklediğini anlaması için süreç odaklı olması da gerekir.

• Teknik: bu başlıktaki içerik donanımın, yazılımın kurulumu, devreye alınması ve yönetimidir. Kimin hangi verilere erişeceğinin belirlenmesi gibi güvenlik konuları da bu kapsamdadır. Sistemin korsanlardan ve virüslerden korunması da bu kapsamdadır. Diğer başlıklar veritabanı bakımı ve

124

yedeklenmesi, ekran tasarımı ve rapor üretimi, yazdırma ve web üzerinden erişim konularıdır.

• Sorgulama: konu neler olup bittiğine ilişkin verilerin nasıl bulunacağıdır. Farklı yaklaşımlar arasında standart hazır raporlar, özel raporlar, bir defalık sorgulamalar ve belirsiz bir ifade olan iş zekası (BI) bulunur. Standart raporların oluşturulmasındaki amaç ne tür bilgilerin erişilebilir olduğu ve nerede bulundukları konusunda kullanıcılarda bilinç yaratmaktır. Bu bizzat kullanıcının rapor yazma, sorgulama (query) ve iş zekası araçları ile sistemi sorguya çekme gereksinimi ile çelişir. Bunlar yazılım dili, teknikler ve sorgulama araçları ilgili konular olduğundan öğrenici üzerinde daha fazla yük oluşturur.

• Göz ardı edilmemesi gereken bir konu da proje ekibinin eğitim yetenekleri geliştirmesi gerektiğidir. Onlar son kullanıcıların eğitmenleridirler. Bu nedenle eğitimlerinde başarılı olabilmek amacıyla bazı temel yetenekler geliştirmeleri gerekmektedir.

Bu kesin bir liste değildir, ama hakim alanların belirlenmesine ışık tutmaktadır. Bu konular içinde özel temalar tanımlanarak kurs olarak geliştirilebilir. Her kursun kapsadığı konular olur. İçeriği belirlerken nelerin öğrenilmesinin zorunlu olduğu ile nelerin öğrenilmesi gerektiği ve öğrenilebileceğini birbirlerinden ayırmak gerekir. Bir zaman kısıtı olduğunda öğrenilmesi zorunlu olan anahtar içerik üzerine odaklanılır. 11.4.3 Plan

Plan eğitimin nasıl yapılacağını saptar. Kapsamında çok sayıda başlık yer alır.

• Organizasyonun tamamı: eğitimin birbirinden ayrık iki fazı vardır. Birincisi dik bir öğrenme eğrisi göstermesi ve çok sayıda materyali hazmetmesi gereken proje takımı ile ilgilidir. Buna paralel olarak sistem yöneticilerinin eğitimi verilir. İkinci faz son kullanıcıları ve yöneticileri ilgilendirir.

• Eğitimci: eğitimi kimler alacaktır? Özel gereksinimleri var mıdır? Bilgi ve yetenek düzeyleri nedir? Öğrenme becerileri ne kadardır? İlk fazda dinleyiciler proje ekibi üyeleri iken ikinci fazda kullanıcılar ve yöneticilerdir. Ana konulardan biri bilgi transferinin etkinliği, özellikle satıcı firmanın personeli ile proje ekibinin üyeleri arasındaki etkinliktir.

• Yer: eğitimin yapılacağı yer neresidir? Yerinde yapılan eğitimler dikkatin toparlanamaması sorunu doğurur. Eğitim yeri ile iş yeri

125

arasında sıklıkla gidip gelme eğilimi hemen kendini gösterir. Eğer eğitim yeri olarak uzak bir mekan seçilirse yol harcamaları, hatta konaklama giderleri için de pay ayrılması gerekebilir.

• Tesisler: eldeki ekipmanın dışında ne gibi ekipman gereksinimi vardır? Hangi odalara gerek duyulacaktır? Odalarda bilgisayar, yazı tahtası, tepegöz, smartboard var mıdır? Gözden kaçırılmaması gereken konulardan biri de oturma olanaklarıdır. Sandalyelerin verilecek eğitime en uygun şekilde yerleştirilmesi gerekir. Planlama sürecinde tüm bu konuların üzerinden geçilerek yetersizlikler saptanır ve giderilmeye çalışılır. Eğitimin hemen arifesinde oda ekipman açısından kontrol edilir.

• Kursun yapısı: hangi kurslar gerekmektedir ve bu kursların içeriği nasıl olacaktır? Burada üzerine odaklanılan konu kurulumun hazırlık aşamasında belirlenmiş olan içeriğin detayları olmayıp, konuların sırasının belirlenmesi ve temalara ve her bir oturuma göre organize edilmesidir. Her oturumun kendine özgü yapısı, yani girişi, ortası ve sonu bulunur. Giriş kısmında konu tanıtılır ve nelerin anlatılacağı açıklanır. Bu kısmın ilgi uyandırması gerekir. Orta kısımda konu akıcı bir düzenleme ile anlamlı bir şekilde aktarılır. Sonuç kısmında anlatılan konunun anahtar noktaları özetlenir ve bir sonraki eğitim konusuna değinilir.

• Zaman: ne kadar zamana gereksinim bulunmaktadır? Ne kadar zaman vardır? Eğitimin gerçekçi olmayan kısa süreler içine sıkıştırılmaması arzulanır.

• Metot: bu amaca en iyi uyacağı düşünülen yaklaşımdır. Vurgulanan konu bilgisayar yeteneklerinin geliştirilmesi olduğundan yaklaşımın bilgisayar başında pratik biçimde yürütülmesi gerekir. Ancak bu yaklaşımın sunum yapma, demo yapma, egzersiz verme, test çözme, grup tartışmaları, rol oynama ve oyun gibi başka yöntemlerle tamamlanması gerekir. Göz ardı edilmemesi gereken konu uygun materyaller ile kişisel çalışmalar yapma zorunluluğudur. İnsanların tek başlarına mı, gruplar halinde mi daha iyi çalıştıklarının da gözlenmesi gerekir.

• Kaynaklar/materyaller: kullanılabilecek çok sayıda materyal vardır. Bunlar tepegöz yansıları, küçük dosya ve kağıtlar, kitaplar, bilgisayar üzerinde yapılacak eksersizlere ilişkin formlar ve bireysel çalışma için CD ROM’lardır. Eğitimin büyük kısmının iş süreçleri olduğu hatırlanırsa (kısım 12.2.2) ekran çıktıları ve prosedürlerin toplandığı klasörlerin de (kısım 12.6.1) konuyla ilgili olduğu görülür.

126

Sonuçta ortaya çıkan plan şirketteki herkesi bilgilendirmeye ve kılavuzluk etmeye yarar. Aynı zamanda eğitim için kişilerden, ne beklendiği konusunda farkındalık uyandırarak, onların yeterli zaman öncesinde hazırlık yapmalarına yardımcı olur. 11.4.4 Değerlendirme

Verildikten sonra eğitimin amacına erişip erişmediğini saptamak gereklidir. Öğreniciler kendilerinden bekleneni öğrenmişler midir? Sistemin yetenekli kullanıcıları haline gelmişler midir? Yalnızca ne yaptıklarını değil, aynı zamanda niçin yaptıklarını da bilmekte midirler? Her durum için özel tasarımlanmış değerlendirme formlarına gerek bulunur. Strateji bu işin nasıl yapılacağını tanımlamak zorundadır.

Bir seçenek işle ilgili bir test hazırlamaktır. Daha çok kullanılan yaklaşım bir faaliyetin çeşitli yönlerine ilişkin detaylı soruların sorulduğu sınav yapmaktır. Her ardışık sınav giderek artan detay düzeylerinde olur, böylelikle erişilmiş olan yetenek düzeyleri hakkında yeterli bulgular toplanabilir. Bütün bunlar ikinci fazdaki son kullanıcılar için görece kolay bir konu iken, birinci fazdaki proje ekibi için daha zor geçer. Gerçekçi olursak, soruların yazılım seçimi aşamasında satıcı firmaya sorulması gerekir. Burada amaç satıcı firmayı yeterli ölçüde değerlendirebilecek bilgi birikimi geliştirmektir. Yazılım ile ilgili bilgi transferinin etkinliği prototip oluşturma faaliyetini satıcı firmanın personeli gerçekleştirdiği takdirde anlamak güç olabilir. En kötü halde ekip üyeleri kendilerine tanımlanan bir süreci süreç fonksiyonlarını veya seçenekleri anlamasalar da, aynen kopya edebilmelidirler. Bu durum ortaya çıktığında prototip tamamlanmış ve proje danışmanlık bedelleri bütçeyi aşmış olabilir. Öğrenme fırsatı kaçırılmış ve müşteri uygulamaya ilişkin bilgi eksikliği ile baş başa kalmıştır. Daha önemlisi proje ekibi üyeleri son kullanıcılara eğitim veremeyecek durumdadırlar. 11.4.5 Gözden geçirme

Eğitim döngüsünün son aşaması eğitim programının gözden geçirilmesidir. Amaç nelerin yapıldığını ve nelerin daha iyi yapılabilecek olduğunu anlamaktır. Problemler incelenir ve önlemler alınır. Gözden geçirmenin en sona bırakılması değil sürekli şekilde yapılması uygun olacaktır. Edinilen dersler sonraki eğitimlerin iyileştirilmesinde kullanılacaktır. Programın sonunda yapılacak nihai gözden geçirme toplantısında hep birlikte yaşanan deneyimler

127

üzerinde tartışılır ve daha sonraki eğitim programlarında kullanılmak üzere saklanır. 11.4.6 Maliyet/Bütçe

Eğitimin maliyetinin gözden kaçırılmaması gerekir. Maliyetler şu başlıklarla ilgilidir:

• eğiticinin hazırlanma zamanı, verilmesi, gözden geçirilmesi, puanlanması ve sunulması

• öğrenicilerin görevlerinden uzakta kaldıkları zaman • kaynaklar/materyaller, örneğin kitaplar, defterler vs. • tesisler; oda kiraları, ekipmanlar, meşrubatlar

Dışarıda verilen eğitim kursun maliyetinin yanı sıra elbette yol ve konaklama harcamalarını da kapsar. Gartner şirketi 39 eğitim bütçesinin toplam bütçenin %10’u kadar olmasını şart koşmaktadır. Bu formülü kullanarak $400.000 tutan bir projenin $40.000’ının eğitim gideri olarak tahsis edilmesi gerekir. Proje ekibinden beş kişinin üç ay boyunca bir danışman tarafından verildiğini, arada beş gün sistem yöneticisi için beş gün dışarıda eğitim verildiğini düşündüğümüzde bu tutarın çok fazla olmadığı görülür. Buna son kullanıcı eğitimlerini eklediğimizde maliyetler hızla yükselir. Mamafih eğitim pek hakkı verilemeden yapılan bir faaliyet olma (Bölüm 10) eğilimindedir. Planlanan tüm eğitim için bir maliyet profili çıkartılabilir. Detaylı plan iç kaynak kullanım bilgileri vermelidir. Çıkarılan profil daha bir bütçeye oturtulur. Fiili maliyetler oluştukça bütçe ile kıyaslanır ve sapmalar izlenir. Eğer harcamalar bütçenin altında kalmaktaysa eğitimin uygun olup olmadığını, hedefine ulaşıp ulaşmadığını sorgulamak gerekir. Tersine harcamaların bütçeyi aşması başlangıç hesaplarının yanlış olabileceği olasılığını veya eğitimin verimsiz olduğunu akla getirir. Bütçenin sürekli izlenmesi gerekir. Birinci aşama maliyetlerinin eğitim ile danışmanlık faaliyetlerinin iç içe girmiş olmaları yüzünden saptanması zorluk gösterebilir. Son kullanıcı eğitimleri ile ilgili olan ikinci aşamada maliyetler daha açık tanımlanabilir. Ancak başka bir alanda aşırı harcama yapıp bunları eğitim bütçesini tırpanlayarak telafi etme tuzağına düşülmemelidir. Tarih, bunun yanlış bir ekonomik tutum olduğunu söylemektedir.

128

12 Uygulama Uygulama, proje takımının görevlerini yapabilir hale gelmesi için eğitilmeleriyle başlar. Bunu yeni süreçlerin tanımına ve tasarımına yönelik faaliyetler izler. Daha sonra sırasıyla, olması gerekmese de, test, dokümantasyon, veri hazırlama, son kullanıcı eğitimleri gelir. Bu yolculuk, proje yönetimine ilişkin konuların, özellikle örgütsel, planlama ve eğitimle ilgili olanların, gerektiği biçimde dikkate alınmasını gerektirir. Böyle yapıldığı takdirde uygulamanın görece düzgün bir şekilde ilerlemesi için gereken koşullar yaratılmış olur. Bu yolculuk görünürde her ne kadar sade ve düzgün ise de gerçek her zaman farklıdır. 12.1 Eğitim Stratejisinin Uygulanması – 1. faz

Eğitim stratejisinin ilk fazının uygulanması proje takım üyelerinin ve sistem yöneticisinin eğitilmesi faaliyetleriyle ilgilidir. Proje ekibine verilecek eğitimin odağı yazılımın fonksiyonalitesini kavratmaya yöneliktir. En iyi uygulamalar, süreç haritalama vb. konulardaki eğitim ve ilgili dokümantasyon prensip olarak satıcı firma tarafından verilirse de uygulama firmadan firmaya değişir. Yerel bir eğitim kurumu veya özel bir danışmanlık firması konuyu üstlenebilir. Sistem yöneticilerinin eğitimi sistem kurulumunun, bakımının teknik yönlerine ilişkin olur ve rapor yazma ile bazı özel konuları da kapsayabilir. Eğitimin amacı uygulamaya, uygulama pratiklerine, en iyi operasyonel uygulamalarına ilişkin bilgi ve yeteneklerin dış eğitimciler tarafından iç personele aktarılmasıdır. Bunların çok büyük kısmı formel prosedürlerle yapılırken yazılım işlevselliğine ilişkin konular çok daha enformel şekilde yürütülür. Ancak bunu çok etkin olması gereklidir ve yakından takibi zorunlu kılar. 12.1.1 İçerik – Uygulama işlevselliğini kavramak

Takım üyelerinin uygulama işlevselliğini (foksiyonalite) kavramaları yeni süreçlerin etkin biçimde geliştirilmesi ve kullanıma alınması için kritik öneme sahiptir. Bu olmaksızın pahalı ERP yatırımının pek çok aşaması gerçekleştirilemez. Ön satış demolarında yazılımın fonksiyonalitesine ilişkin pek çok pozitif şey söylenmişken bu aşamada yetersizlikler fark edilmeye başlanır.

129

Yazılımın gerçek görünümü gereksinimleri karşılayacak fonksiyonlar konuşulmaya başlandığında ortaya çıkar. Yazılımı kullanarak proje ekibinin iş süreçleri geliştirmesi için gereken bilgi ve yeteneklerin çeşitli düzeyleri bulunur. Her takım üyesi şu konularda bilgiye sahip olmak zorundadır:

• sistem içinde nasıl yol alınacağı, ilerleneceği, • fonksiyonların detayları.

Her takım üyesi şirket için en iyisini bulabilmek amacıyla fonksiyonel işlemlerin farklı yollarla değerlendirilebilmesine ilişkin yetenekler geliştirmeye gerek duyar. İlk problem navigasyon olarak adlandırılan sistem içinde nasıl ilerleneceğidir. İlk bakışta menüler yıldırıcı bir etki yapar. Ancak bu konunun üstesinden fonksiyonlar setini ne olduğu ve birbirleriyle nasıl birleştikleri konularında genel bir farkındalık oluştuğunda gelinmiş olur. Eğer menüler üzerlerinde düşünülerek tasarımlanmış ve işletme içindeki süreçlerin akışını yansıtacak şekilde sıralandırılmış ise sistem içi ilerleme kolayca gerçekleşir. Sıklıkla yaşanan ise konunun formel grup toplantılarıyla uygulamalı olarak ele alınmasıdır. Dikkat edilen konular arasında işletmeye ilişkin süreçlere uyarlanmış ve doğru detay düzeyindeki sunumlar hazırlamak da bulunmaktadır. Sonraki problem özel fonksiyonlarla ilgilidir. Çalıştığı nasıl anlaşılacaktır? Satıcı firmanın danışmanları yazılımın fonksiyonlarının uzmanı olabilirler. Bu uzmanların tek tek takım üyeleriyle birlikte oturup ekranların, veri alanlarının önünde oturup çalışacakları umulabilir. Bu eğitim modu pek yaygın değildir. Ama bu takım üyelerinin öğrenmeleri için ideal öğrenme fırsatıdır. Tabii öğrenme yetenekleri varsa! Dinleyebilirler, hatırlamaya çalışırlar, ama not almazlar. Sonraki bir tarihte oturum açtıklarında hatırlamalarının olanaksız olduğunu görürler. Basit not tutma tekniği bu tür sorunların üstesinden gelmek için en geçerli yoldur. Ekran görüntüleri yararlı enformasyonu yakalamak için iyi bir yoldur. Basılı ekran görüntüleri üzerine not almak gelecekteki kullanım için mükemmel referanstır. Detaylara dikkat edilmesi gerekir, özellikle değişik durumların dokümante edilmeleri gerekir. Gerçekte dokümantasyon ister on-line olsun, ister kağıt, faydasız olabilir. İçeriği eksik ya da anlaşılmaz olabilir. İyice aşina oluncaya kadar aynı konulara tekrar tekrar dönülmesi iyi olabilir. Zaman içinde herkes uygulamanın çeşitli taraflarına ilişkin iyi bir kavrayış geliştirmelidir. Amaçları yazılımı farklı yollarla kullanma deneyimi kazanmak ve bunu diğerlerine transfer etmek

130

olmalıdır. Anahtar kullanıcılar fonksiyonaliteye ilişkin olabildiğince çok şey öğrenmek çok şey öğrenmekten sorumludurlar.

Şekil 12.1 Bir dönüşümün kara kutu görünümü Proje takım üyelerinin gerekli bilgi ve yetenekleri geliştirme gibi düşünceleri varsa bunu değerlendirmeleri de arzu edilir. Bunun nasıl yapılacağı satıcı firmanın uzmanlarının da olduğu bir ortamda belirlenmelidir. Bir kişinin bilgi ve yeteneklerindeki açıklar uygulamayı kendi başına denemeye çalıştığında hemen belirecektir. Kişinin boşluklarını en erken fırsatları kullanarak doldurmayı denemesi beklenir. 12.1.2 Planlama

Bu tarz eğitimin enformel doğasına karşın her şey planlanabilir. Tarihler saptanabilir, insanlar ve yerler organize edilebilir. Bu fazın vurgusu eğitimin organize edilmesi ve planlanmasıdır. İşler dış eğitimciler tarafından yürütülür. Eğitim grup ortamında formel bilgi aktarımı ile bireysel enformel oturumların uygun bir karışımına benzer. Eğitimin çok büyük kısmı müşteri firmanın tesisinde bulunan proje odasında geçer. Ancak kaçınılmaz biçimde bazı eğitim firma dışında satıcı firma tarafından belirlenen halka açık sınıflarda gerçekleşir. Bunların saptanmış tarihleri vardır, popüler iseler kayıtlar hemen dolar. Bu nedenle biran önce en uygun tarihlerde yer ayırtmak gereklidir. Maalesef yer bulunamaz ise sonraki kurs üç ay sonraki kesinleşmemiş tarihte açılacak, bu yüzden de bazı görevler yerine getirilemeyecektir. Bazen tarihler üzerinde görüşmek olanaklı olur. Alternatif olarak özel bir kurs açılabilir, elbette bu daha pahalıdır, hele yalnızca bir kişi eğitim alacaksa.

131

Plan içinde üzerinde durulması gereken bir özel alan da rapor yazma, sorgulama dili ve üçüncü firmalara ilişkin İş Zekası araçları konularındaki teknik eğitimdir. Bunların zamanlaması kullanım beklentilerini yansıtır. Her ne kadar uygulama sırasında rapor yazma ve sorgulama yeteneklerine ilişkin yeteneklere gereksinim duyulacaksa da İş zekası araçlarının kullanımı canlıya geçtikten bir süre sonra gündeme gelecektir. Birinin eğitim alıp kullanmaması sonradan unutma tehlikesi içermektedir. Birkaç kişinin yetenek geliştirmesine olanak tanımak bir kişiye olan bağımsızlığı azaltacak ve kişide doğacak tıkanmaların projede gecikmeler yaratmasının önüne geçecektir. Tamamlandığında eğitim planı proje uygulama planının bir parçası olacak ve uygun biçimde izlenecektir. 12.2 Süreçlerin Tanımlanması

Temel uygulama faaliyetlerinden biri yeni süreçlerin geliştirilmesi ve tanımlanmasıdır. Bu yaratıcı bir aşamadır ve mevcut uygulamalar, en iyi uygulamalar ve ERP yazılımının işlevleri konusunda bilgiler gerektirir. Gerek duyulan bir yetenek de pratiklerin izole edilmiş faaliyetler şeklinde değil süreçler içinde görülmesidir. Süreç yaklaşımı birbirleriyle etkileşimli faaliyetler arasındaki akışı iyileştirecek ve üzerinde durulmayan konu kalmayacaktır. Ancak süreç terimleriyle düşünebilmek için sürecin ne olduğuna ilişkin belli bir bilgi gerekmektedir.

Figür 12.2 Bir sürecin elemanları 12.2.1 Teorik İskelet

Bir işletmedeki süreçleri düşünmenin farklı yolları vardır. Bu notlarda benimsenmiş olan kavramsal iskelet, S. Harwood (1996) tarafından geliştirilmiştir.

Dönüşüm

Teknoloji

Bireyler

Etkileşim

132

Bu iskelet işletmeyi düzenlenmiş bir süreç olarak görmekle başlar. Bu süreç amaç yönelimli faaliyetler olarak tanımlanabilir. Girdilerin (kaynaklar) çıktılara (ürün ve hizmetler) dönüştürülmesi ile ilgilidir. Sürecin düzenlenmesi istenmeyen çıktıların üretilme olasılığını düşürür, böylelikle arzulanan çıktıların üretilme olasılıklarını yükseltir. Ancak dış bozucular bu düzenlenmiş sürecin etkinliğini sekteye uğratabilirler. Bu basit model şekil 12.1’de gösterilmiştir. Bir sürecin incelenmesi dört elemanın; (şekil 12.2) dönüştürme, etkileşimler, bireyler ve teknolojinin açığa çıkarılmasını sağlar. Etkileşimli dönüşümler şebekesi işletme yapısını tanımlar. Ancak çalışanlar bu yapıyı farklı şekilde algılarlar. Gerçekleşen tüm dönüşümleri ve etkileşimleri görmezler ve takdir etmezler. Farklı yapılar güçlükle ayırt edilebilir: raporlama yapıları, süreç yapıları ve enformel şebekeler. İşletmenin amacı sorgulandığında bu konular kesinleşmemiş bir olgu sunar. Bu amacın altında yatan çekirdek dönüşümler nelerdir? Bir üretim direktörü mühendislik fonksiyonunu üretimi destekleyen bir rolde görebilir. Mühendislik müdürü tersi görüşle üretimin gerektiğinde dışarıya yaptırılabileceğini düşünebilir. Süreç kavramının içinde bireyin rolü bulunur. Birey dönüşümü ve etkileşimleri doğrudan ya da uzaktan olanaklı kılabilir. Birey dönüşüm ve etkileşimlere insan olmanın kalitesini getirir. Tatil günleri olan bir kişi pek çok hata yapabilir, bunlar müşterilere yanlış teslimler yapmakla sonuçlanabilir. Bir kişi hastalanıp işe gelmediğinde süreç bölünür, ilgili işlem yerine getirilemez. Takım ise birbirlerini yedekleyen kişilerden oluştuğundan bireysel eksiklikler sistem için sorun haline gelmez. Bireyler dönüşümler ve etkileşimler için görüşler oluşturur. Birey sürecin amacının ne olduğunu bilirse dönüşüm ve etkileşimlerle ilgili sorular sorabilir. Doğru dönüşüm ve etkileşimlerin uygulanıp uygulanmadığı üzerinde iyice düşünüp taşınabilir. Doğru işler yapılmış mıdır? Dikkat yapılanların doğru olup olmadığı üzerine odaklanır. Eğer bu sağlanabilirse şirketin banka hesabından bireyin banka hesabına transfer olan fonlar yerini bulmuş demektir, aksi halde konu hırsızlık şeklinde bile düşünülebilir. Çoğunlukla dikkatler, yapılanların kabul edilir olup olmadığı üzerinde toplanır. Sorun dönüşümle sağlanan çıktıların kabul edilebilirliği, dönüşümün performansıdır. Sıklıkla performans ve davranışlar yalıtılmış bir şekilde düşünülür. Oysa böyle olmamalıdır. Amaç, davranış, performans ve bunların altyapısı arasında karşılıklı etkileşim bulunur. Bu da işletme yapısı ile stratejinin birbirlerine

133

bağımlı olmalarını önerir. Her birini ya diğerini kısıtlar yada destekler. Son olarak teknolojinin rolünün farkına varılması gerekir. Bu da bireyin dönüşümle ve etkileşimlerle ilgili yapabileceklerinin kapsamına kadar uzanır. Genellikle süreçlerin otomatikleştirilmesinin herhangi bir yolla üretim çıktılarını iyileştirmesi beklenir. Enformasyon teknolojilerinin geliştirilmesi verilerin toplamalarını, işlenmelerini ve analiz edilmelerini kolaylaştırır. Telekomünikasyondaki gelişmeler insanlar arası etkileşimlerde mekana olan bağımlılık kısıtını giderir. Geliştirme perspektifinden bakınca felsefi soru teknolojinin mi yapıya, yapının mı teknolojiye uydurulacağıdır. Çoğunlukla teknoloji işlerin nasıl yapılacağını dikte eder. Teknoloji büyük bir olanak sağlayıcı olmakla beraber kendi başına her derde deva değildir. Teknoloji kendini kullanacak bir insana gerek duyar, kullanımından yarar sağlayacak bir kişiye. Her ne kadar teknoloji uzun bir süre uzaktan kullanılabilse de kullanımını başlatacak birine her zaman gerek bulunur. İş süreçlerine ilişkin yeni görüş onun dört elemanı (dönüşüm, etkileşimler, birey ve teknoloji) ve dört perspektif (amaç, yapı, davranış ve performans) kapsadığı şeklindedir. Her biri arasında etkileşim bulunur. Bu durum şekil 12.3’te gösterilmiştir. Merkezde birey bulunur. Birey bir sürece dahil edildiğinde belli bir amaca yönelik davranışlar içine girer. Bu amaç bazen açık biçimde belirlenmiş olur, bazen de faaliyetler içine gizlenir. Amaca erişmek için sürecin yapısını tanımlayan bazı dönüşümlerin ve etkileşimlerin yapılması gerekir. Birey bu faaliyetlerin yerine getirilmesini güçlendirecek şekilde teknolojiyi kullanabilir, böylelikle süreci insansız kılabilir. Bireyin süreci değerlendirmesi davranışlar ve performans terimleriyle olur. Bu teorik modelin değeri mevcut ve yeni süreçlerin haritalarının çıkarılması için uygun bir şablon sunmasıyla ilintilidir. Süreçlerin haritalanması değişmez şekilde sürecin içinde yürümek ve detayları toplamakla oluşur. Bu işi yapacak kişi insanları, dokümanları, bilgisayar ekranlarını, nesneleri, ekipmanları, fiili dönüşümleri ve etkileşimleri tanımlayabilmelidir. Karşı karşıya kalınan problem bütün bu parçaların yararlı bir süreç modeli oluşturacak şekilde nasıl birleştirileceğidir. Çözüm her özelliğin girdi, çıktı, dönüşüm ve etkileşim terimleriyle nasıl yorumlanacağıdır. Her parça herhangi bir görev unvanı olan kişinin yaptığı dönüşüm faaliyetinin ürünüdür. Bu herhangi bir şekilde başka bir dönüşüm sürecine aktarılır. Bu çok fazla iş yükü getirse de sonuçta süreç haritası elde edilir. Bu

134

toparlama sırasında karşılaşılan karmaşıklığın üstesinden gelmek için sade yaklaşımlar bulunabilir. 12.2.2 Toparlama

Bir süreci anlama çabaları sırasında karmaşıklığın içinde kaybolmak seyrek karşılaşılan bir durum değildir. Karmaşıklıkla baş etmede görece verimli bir yaklaşım “Toparlama”dır. İki ön koşul bulunur. Bunların ilki duvar yüzeyidir. İdeal olarak proje takımı odası (kısım 11.2.1) buna sahiptir. İkincisi ise duvara asılması kolay, geniş boş kağıtlardır. Bu kağıtlar kolayca ve hızlıca hazırlanırlar. Bunlar toparlamanın tuvalini oluştururlar. Toparlama şu örneklerden toplanmasını gerektirir:

• tüm dokümantasyon; raporların, formların başlık ve içeriklerini kapsayacak şekilde,

• kullanılan tüm bilgisayar ekran çıktıları, • etiket, pusula ve her türlü iletişim not formları,

En iyi yaklaşım her sürecin içine günlük faaliyetlerin tümünü kapsayacak detayda içine girmektir. Gerek rutin, gerekse bir defalık süreçler inceleme kapsamına alınmalıdır. Eğer bir süreç içinde bir doküman üzerinde düzeltmeler yapılıyorsa, düzeltmelerin her aşaması örneklenerek kaydedilmelidir. Her parça bir dönüşümden diğerine aktarılan bir şeyi simgeler. Her parçaya ilişkin detaylar; kimin ürettiği, nasıl üretildiği, ne sıklıkla üretildiği, kimin aldığı, nasıl ve ne sıklıkla kullanıldığı vs. saptanmalıdır. Bu aşamada pek çok sorunun yanıtlanamaması nedeniyle bazı boşlukların doğması normaldir. Ancak yanıtlar sonraki aşamalarda verilecektir. Bunlar girdi ve çıktılar olduklarından her parçanın oluşma sıraları önemlidir. Toplanan veriler duvar üzerindeki tuvale düzenli biçimde işlenir. Gerektiğinde notasyon da kullanılabilir. Amaç kullanılacak her parçanın sırasını haritalamaktır. Tuvalin fiziksel kısıtlarından dolayı çok sayıda levha kullanılması gerekebilir. Herhangi bir zarar olasılığına karşı önlem olmak üzere her parçadan iki kopya hazırlanabilir. Başlangıç toparlaması tamamlandığında pek çok başıboş bitim noktasıyla karşılaşılabilir. Ancak her girdinin bir başlangıç kaynağı ve her çıktının da gideceği en az bir yer bulunur. İş süreci kapalı bir faaliyetler şebekesidir. Bu nedenle sonraki iş her başıboş sonucu araştırmaktır. Bunun için süreçle ilgili herkesi bir araya getirmek ve konuşturmak gereklidir. Bazen örneğin bir doküman izole bir şekilde, tek başınaymış gibi görünür. Ancak her şekilde o bir

135

faaliyetin çıktısıdır, başka bir sürecin içindeki bir olayla tetiklenebilir. Önemli olan bu bağlantıları kurmaktır. Her başıboş sonuç uygun biçimde çözülmeyebilir veya tekrarlara işaret edebilir. Sonuçta tüm iş süreçlerine ilişkin pek çok detayın bulunduğu bir tuvaller kümesi ortaya çıkar. İster fiili faaliyetleri kaydetmek için, isterse hipotetik bir süreci tasarımlamak için kullanılsın bu tekniğin çok sayıda yararı bulunur.

• odaklanılan konu girdiler ve çıktılar olduğu için, özellikle farklı isimlerin kullanıldığı veya ekipmanların, bilgisayarların içinde gizli kalmış dönüşümleri tanımlama sıkıntısı aşılır.

• Bir süreci hem tüm karmaşıklığıyla hızlı ve kolay biçimde göstermek, hem de bileşenlerinin detaylarına erişme olanağı bulunur.

• Toparlama sırasında elde edilen verilerle sürece ilişkin konularda görüş alışverişi yapmak için referans noktası oluşur. Görüş alışverişleri süreçlere ilişkin mitleri ortadan kaldırır. Bazı görevlerin yapıldığı, dokümanlar ve ekranlar üzerinde bulunan farklı veri alanlarının anlamı ve her aşamanın değeri ortaya çıkar.

• Kalite yönetim sistemi için önemli olan süreç dokümantasyonun, süreç dokümantasyonunun geçerliliğinin anlaşılması için bir baz ortaya koyar.

• Eğitim malzemesi olarak kullanılır. • Saklandığı takdirde, sonraları, sürecin gözden geçirilmesine,

işlerin neden o şekilde yerine getirildiğine ilişkin referans noktası oluşturur.

Tam anlamıyla işletildiğinde “Toparlama” çok yararlı bir yaklaşımdır. 12.2.3 Şimdi ne yapıldığını anlamak

Hani çokça edilen bir söz vardır: “gitmek istediğin yeri belirlemek için, önce nerede olduğunu bilmelisin!”; bu iyi tavsiye önümüzdeki görevde değerini bulacaktır. Şu anda ne yapıldığını anlamak, hem etrafı kuşatan mitleri ve hataları ortaya çıkaracak; hem de ne yapılması gerektiği konusunda bir referans noktası oluşturacaktır. Yeniden tasarımlanacak sürecin var olanla bir benzerlik taşımaması olasılığı bulunmakla beraber bu çalışmanın değeri yeniden tasarım aşamasında üzerine gidilecek konuları ortaya çıkaracak olmasından kaynaklanmaktadır.

Bu özellikle hızlı değişen ortamlarla ilgilidir. Bir şirket içinde hızla büyümekte olan küçük bir operasyonu örnek alalım. Satıcı seçim

136

aşamasında (Bölüm 7) süreci anlamak için yapılan her çalışma operasyondaki manüel sistemleri ortaya döker. Prototip başladıktan birkaç ay sonra büyümenin etkisi personel sayısındaki artışla birlikte operasyonun parçalara ayrılması ve yeni raporlama mekanizmalarının doğması şeklinde görülebilir. Yeni müşterilerin gereksinimleri yeni teslimat ve faturalama prosedürlerini doğurabilir. Mevcut tedarikçilerin talebi karşılamadaki yetersizlikleri nedeniyle seçilen yeni tedarikçiler arz zinciri içinde yeni süreç iyileştirme fırsatları sunabilirler. Ancak süreçleri etkileyen çeşitli konular henüz çözümlenmemiş olabilir. Problem sürekli değişim altındaki bir sürecin nasıl tasarımlanacağıdır.

Bir noktada sürecin dondurulması gerekmektedir. Bu noktada nelerin olup bittiğinin ve evrim geçirme veya ortaya çıkma olasılığı olan konuların kavranması gereklidir. Prototip süresince gelişmeler bütünleştirebilir. Süreçler gerektikçe evrim geçirirler. Canlıya geçiş zamanına ulaşıldığında süreçler başlangıçtaki görüntüye çok az benzerler. Nelerin yapılmakta olduğuna ilişkin çıktılar, bir dokümanlar ve diyagramlar kümesi şeklindedir. Ofisin duvarları toparlamalarla dekore edilmiştir. Bunlar tüm süreçlerin detaylı haritalarıdırlar. Eğer bu görev detaylara dikkat edilerek tamamlanmışsa yalnızca sürecin temel özellikleri yakalanmış olmakla kalınmaz, bunun yanında normal uygulamalardan sapmalar da ele alınmış olur. Bu harita gökyüzünden çekilen, aynı ve farklı yerleri kapsayan fotoğrafların masa üzerine yayılıp bölgenin tek fotoğraf oluşturmaya benzetilebilir. Yakından inceleme tüm detayları ve hakim özellikleri ortaya çıkaracaktır. Bu haritanın üst düzey görüntüsü şekil 12.4’te verilene benzer. Şekil iş süreçlerinin genel akışını temel dönüşüm, girdi ve çıktı terimleriyle ortaya koymaktadır. Aynı zamanda başlıca veri tabanlarını, müşterilere, tedarikçilere ve stoktaki mallara ilişkin, ortaya çıkarır. Her detayı göstermek amaçlanmaz, bu amaç başka bir destek dokümantasyonunun konusudur. Yapılması için açık neden görülmeyen faaliyetleri ortaya çıkarır, zaman içinden gelen mirasları gösterir. Ancak bunların dikkatle ele alınması gerekir. Önlenmek istenen sorunlarla ilgili sorular sorulmalıdır. 12.2.4 Hızlı Onarımlar

Mevcut süreçlerin hızla değerlendirilmesi, işleri daha kolay yapacak küçük değişikliklerin görülmesi fırsatını sunar. Her ne kadar süreçler uygulama sonucunda değişeceklerse de mevcutları

137

minimum çabayla iyileştirilmesi kısa dönemli kazançlar getirir. Bu küçük onarımlar gereksiz işlerin durdurulması veya esas görevler üzerinde küçük değişiklikler yapılmasından kaynaklanır. Öte yandan değerlendirme bazı süreçlerin tamamen mevcut durumla uyumsuz olduğunu ortaya çıkarabilir. Dahası prototip aşamasında değişiklik için çok büyük çaba gerekebilir. Değişimin doğası, sürecin yeniden yapılanmasını içerir. Böyle bir durum bir ikilemle karşı karşıya kalmak anlamına gelir ve bir şey yapmanın doğru olup olmadığına karar verilmesi gerekir. Yararlar çabaları karşılayacak mıdır, yoksa zarar mı getirecektir? 12.2.5. İş süreçlerinde yeniden yapılanma

İş süreçlerinin yeniden yapılanması40 kavramı 1990 yılında Michael Hammer’ın bir makalesiyle tanındı. Makalede Türkçe’ye değişim mühendisliği olarak geçmiş yeniden yapılanmada, nasıl organize olduğumuza ve işleri yürüttüğümüze ilişkin kuralların bir tarafa bırakılması gerektiği anlatılmaktaydı. Aynı tarihte Davenport ve Short da enformasyon teknolojilerinin iş süreçlerinin yeniden tasarımında güçlü bir rol oynayabilecekleri savını ileri sürmüşlerdi. Bunun altında da mevcut uygulamaların yeniden tasarımının işlerin yapılma şeklini sorgulamaması gerektiği ilkesi yatmaktaydı. Bu yapılmazsa teknolojinin yararları kaybolmayacaktı. Değişim mühendisliği, yaklaşımı işlerin nasıl yapıldığı görüşü ile ilişkili olmak eğilimindedir. Beyaz bir sayfa ile başlanır ve sürecin amaçları tanımlanır. Sonra da bu amaçlara en iyi erişme yolu belirlenir. Hem şirket içindeki hem dışarıdan, sektördeki en iyi uygulamalardan fikirler esinlenilir. Bu fikirler yeni sürecin oluşturulmasında kullanılır. Kavramsal olarak basit görünse de bütün bunları fiilen yapmak zor olabilir. İlkönce yönetimin değişime katılımı ve değişimin yararları konusunda bir vizyona gereksinimi vardır. Sonrasında iş-görenlerin göstereceği direncin üstesinden gelinmesi gerekecektir. Kullanıcıların değişime hem gereksinimleri olması, hem de onu arzulamaları zorunluluğu bulunmaktadır. Nihai olarak da bizzat değişimin yönetilmesi gerekmektedir. Hiç de şaşırtıcı olmayan bir şekilde pek çok konu bir ERP sisteminin uygulanmasına benzemez değildir. Gerçekte birbirleri arasındaki tek anlamlı fark, ERP sisteminin rolünün bir olanak sağlayıcı olmasıdır. Böylece bir önceki kısımda anlatılan durumla karşılaşıldığında, uygun olmayan bir sürecin yeniden yapılandırılıp 40 Re-engineering

138

yapılandırılamayacağı kararını verirken iki seçenek söz konusudur. Bunlardan birincisi önce süreci arzu edilen formata yeniden yapılandırmak, sonrasında da ERP işlevselliğini uygulamaktır. İkinci seçenek de süreci mevcut ERP işlevselliği kısıtları altında yeniden yapılandırmaktır. İlk yaklaşımın lehindeki kanıt, potansiyel olarak en iyi çözümü sunmasıdır. Buradaki varsayım, yazılım fonksiyonalitesine gerek duyulan her şeyi yaptırabilme yeteneğinin varlığıdır. Bu yarar, yeni süreci geliştirmede ve sonrasındaki bilgisayarlaştırma çalışmalarında yaşanacak gecikmelerle dengelenir. İkinci yaklaşım, her iki adımı birleştirir; dolayısıyla teoride daha hızlı olması gerekir. En iyi uygulamanın yazılımın dikte ettiği il uzlaşmak olduğu iddia edilebilir. Gerçek ise yararların ve kayıp fırsatların sürecinin doğasının ve değişimi gerçekleştirme etkinliğinin fonksiyonu olduğudur. Hangi yolun benimseneceğine karar verirken her durumun göreli avantajlarının dikkate alınması gerekir. Bazı süreçler yalnızca ERP işlevselliğinin olanak sağlayıcı özellikleriyle yakalanabilirken; diğerleri, buna daha az bağımlıdır. Teknoloji ile olanaklı kılınan süreçler için süreç değişiminin pek çok yararı canlı uygulamaya geçmeden su yüzüne çıkmaz. Hatta yararların çoğunun canlı uygulamaya geçtikten sonra sürekli iyileştirme ortamında kendilerini göstermeleri de beklenmelidir. Canlı uygulama sonrasındaki periyotta tasarımın zayıflıkları ve sistemin gücü giderek artan bir şekilde fark edilir. Hangi yol benimsenirse benimsensin proses tanımları gelecek için yapılmalıdır. 12.3 Prototip

Prototip faaliyeti uygulamanın çekirdek yeteneklerindendir. Yeni yazılım kullanılarak işlerin nasıl yapılacağı bu faaliyet ile saptanır. Gerektiğinde süreçler yeniden yapılandırılır. Bu aşamadaki amaç, en iyi çalışma yolunu üretmek değildir. Böyle bir amaç yalnızca aşırı hırslı olmakla kalmaz, aynı zamanda kısa veya orta vadede gerçekleşmesinin pek de olanağı bulunmaz. Sürecin sürekli değişim altında olduğu dinamik bir ortamda böyle bir şey asla gerçekleşmez. Gerçekçi olursak, süreçler, en iyi uygulamaları benimseyecek şekilde tanımlanırlar. Sonrasında sürecin kendisinden ne yapması isteniyorsa onu yapacağı operasyonel pratiklere dönüştürülür. Geliştirme aşaması boyunca ortaya çıkan konularla uğraşılır ve sonuca bağlanır. Canlıya geçildiğinde de farklı konular doğar. Bunlarla sürekli iyileştirme programı ile (kısım 14) mücadele edilir ve süreç iyileştirilir.

139

Süreç tasarım faaliyeti boyunca çok sayıda soruya sürekli yanıt bulunması gerekir:

• Ne yapmaya çabalıyoruz? • Bunu yapmanın en iyi yolu nedir? • İşleri şimdiye kadar yapa geldiğimiz yolla yapmaya devam

etmeyi istiyor muyuz? • Bunları yapmak için alternatif yollar nelerdir? • Yapmak istediğim yolla neden yapamıyorum?

Yanıtlar hazır olabilir, ancak zaman içinde paydaşlar tarafından kabul edilebilecek süreçler doğar. Proses tasarımında temel kural “sade olmak” temellidir.

Prototip egzersizi boyunca yeni süreç kısmen danışman firma tarafından, kısmen de deneyimlerle gözler önüne serilir. Süreç ne kadar karmaşıksa, gelişmelerin izlerini tutmaya da o kadar gerek duyulur. Süreçle birlikte yürütülen toparlama çalışmaları sürecin gevşek ve daha fazla sorgulanması gereken kısımlarını gözler önüne serer. Özellikle son kullanıcılar açısından süreç üzerinde konuşma olanağı yaratır. Proses gözler önüne serildikçe çok sayıda konu hakkında karar verilir. Bunlar da nihai sistem konfigürasyonunu oluşturur. Bu aşamada sonradan değişiklik yapmanın olanaklı olmadığı konular hakkında karar verirken dikkatli olunmalıdır. Hesap kod yapısı gibi bazı noktalar temel iş kararlarıyla ilişkilidir. Bu tasarım aşamasında elbette kötü karar verme riski de bulunmaktadır.

Figür 12.3 Bir süreç modeli

Amaç

Performans

Yapı

Birey

Davranış

Dönüşüm Etkileşim

Teknoloji

140

Fonksiyonaliteyi denerken yazılım “hataları41” ortaya çıkabilir. Bunların kaydedilmesi ve üzerinde eylem yapılması gerekir. Bunların gelişmelere engel olmadan kısa süre içinde üstesinden gelinmesi önemlidir. Bazı vakalarda hızlı çözüm mümkün olmaz, hatta çözüme bile varılamaz. Kalan tek yol, başkalarına başvurmaktır. Bu istenen bir durum olmamakla birlikte arzulanan çözümü getirebilir. Ancak yazılım hatası, büyük bir teknik problem ise, olduğu gibi de kalabilir. Prototip işletmenin gelecekte nasıl çalışacağını şekillendirmek için çok keyifli bir fazdır. Pek çok önemli karar ilgili kişilerin katılımıyla alınır. Bazıları müşterilerin ve tedarikçilerin denetimini gerektirse de pek çok konu karara bağlanır. Karşılaşılan pek çok soruna çözüm bulunur. Ancak bu fırsatın kullanılma derecesi üst yönetimin vizyonuna, tüm çalışanların katılımına ve başarılı olma arzularına bağlıdır. 12.3.1. Konular listesi

Problemler, ortaya çıktığında konularına göre derlenmeleri gerekir. Takım üyelerinin doğan problemleri konularına göre listeleme disiplini kazanmaları gerekir. Bunları yapma beceriksizliği unutulmalarına ya da elverişsiz bir zamanda yeniden ortaya çıkmalarına yol açar. Bu çalışma problem çözümü için bir ajanda oluşturur. Her konuya birinin atanması ve bu kişinin de konunun çözümüne ne kadar zaman ayrılacağını belirlemesi gerekir. Sorunların çözümü kolay olabilir ama herhangi bir nedenden ötürü bunlarla uğraşılamayabilir de. Ya da ilk bakışta basit gibi görünen fiiliyatta çok zor olabilir. Çözüm danışman firmanın uzmanlığını veya yazılımın modifikasyonu gerektirebilir ya da yazılım çözümü bulunmayabilir. Konuların ele alınmasını ve çözümlenmesini garanti etmek amacıyla listenin proje yöneticisi tarafından düzenli olarak incelenmesi gerekir. 12.3.2. Yazılımın modifikasyonu - süreç ile yazılım

fonksiyonlarını uzlaştırmak

ERP uygulamalarında görev üstlenen kişiler, Ortodoksça düşünmelerine rağmen, olası değişikliklerin daha çok işlevsellik kazandırmasına rağmen, yazılımda değişiklik yapılmasını arzu etmezler. Asıl amaç temiz yemek yemek, diğer deyişle çok müdahale edilmemiş (adeta tecavüze uğramamış) versiyon içinde

41 Bug (kullanıcıdan kaynaklı olmayan ortam dolayısıyla oluşan hatalar kastedilmektedir)

141

kalmaktır. Değişiklik yapmanın maliyetlerinin dışında, upgrade’ler gerçekleştiğinde değişikliklerin yeniden yapılması gerekebilir. Alternatif görüş, yazılımın ne isteniyorsa yapması gerektiğidir. Her iki halde de ikilem yaşanır. Temiz yemek yaklaşımı, yazılımın kendisinin süreçlerin nasıl çalışacağını dikte etmesiyle sonuçlanır. Öbür yaklaşım da yazılımın yapamayacağı fonksiyonları dikte edebilir. Gereksinimlerin tanımlarının etkinliğine bakmaksızın (bölüm 7) detaylar üstünde durmamak gerekir. Bunun yanında o ana kadar düşünülmeyen süreçler de ortaya çıkabilirler. Çoğunlukla arzulanan ile yazılımın yeteneği arasında uyumsuzluk görülür.

142

Arzu edilen yalnızca minör sorunların çıkmasıdır. Ancak başlıca fonksiyonlar, kabaca incelenmişse; temel süreçlerin arzulanan şekilde çalıştırılamaması olasılığı bulunur. Arzu edilmeyen sonuçlar doğabilir. Bir seçenek sürecin yazılımın işlevselliği tarafından dikte edilmesidir. Alternatif yol olarak yazılım değişikliği gerçekleştirilir ama bu pahalıya gelebilir. Eğer her iki seçenek de hoş bulunmaz ise üçüncü bir çözüm yazılımdan bağımsız olarak bir şeyler yapmak, örneğin; manüel bir sistem geliştirmek veya işi yapmak için özel bir yazılım paketi edinmek yoluna gidilebilir. Ancak bu durumda entegrasyonun avantajı kaybolabilir ve çözümün niteliğine göre başka sorunlar çıkabilir. Bu konuyu çözerken dikkatler en iyi pratikler ile aradaki boşluğa çevrilmeli, sistemin neleri yapıp neleri yapması gerektiğine bakılmalıdır. Farklı seçeneklerin sunduğu fırsatlar dikkate alınmalıdır. Üzerine değişiklik yapmaya karar verilen konular üzerinde uzlaşıldığı görülmemiş konulardan değildir. Ancak bunun için kontrollü bir değişiklik prosedürüne gerek bulunmaktadır. Değişiklikler mutlak gerekli olduğunda, sık ve rutin işlerden zaman kazancı gibi açık yararlar sağlanacaksa yapılmalıdır. Bu prosedür şu konuları içerir:

• değişimin doğası, • değişimin sağlaması, • değişimi kimin istediği ve kimin izin verdiği (iki farklı kişi), • değişimin maliyeti, • değişimin beklenen yararı, • değişimi gerçekleştirmek için gereken zaman.

Değişimlerin sağlamasının yapılması gerekir. Değişimler kontrol edilmezlerse bazılarının kaprisleri sonucunda ortaya çıkmaya başlar ve sayıları da hızla çoğalır. Bununla bağlantılı olarak ancak sonradan anlaşılacak şekilde maliyetler hızla yükselir. Bu sürecin bir parçası imzalamadır. İmzalama değişikliğe izin verme aşamasının yanı sıra değişikliğin arzulanan işi gerçekleştirip gerçekleştirmediğine ilişkin testin yapılması aşamasında da karşımıza çıkar.

Değişikliklerin sistemin terfisi sırasında daha fazla maliyetli olarak yeniden uygulanması gerekeceği hatırda tutulmalıdır. 12.3.3 Kullanılabilirlik

143

Çamaşır makinesi, mikrodalga fırın, video benzeri ev aletlerinin harika fonksiyonlar içermesi hiç de az karşılaşılan bir şey değildir. Tek problem çoğu kişinin bunların yalnızca çok azına gerek duymalarıdır. Dahası içerdikleri karmaşıkla çoğu kişi bu fonksiyonları denemekte zorlanmaktadır. Sonuçta bu kişiler bu cihazlardan vazgeçmekte ve daha sade alternatifler aramaktadırlar. Bu durum yazılım uygulamalarında da yaygındır. Örneğin masaüstü bilgisayar tarafından şaşırtıcı derecede çok sayıda işlevsellik sunulmakta ancak bunların çok azı kullanılmaktadır. Bir ERP uygulaması da karmaşıklığı nedeniyle çok yüksek miktarda işlevsellik içerir. Bu fonksiyonalitenin kullanıcı dostu bir şekilde sunulması bir satıcıdan diğerine değişiklik gösterir. Genel kullanıcı, bu fonksiyonlardan sınırlı sayıda kullanma eğilimi gösterir. Bu güvenlik nedeniyle kısıtlanan bazı fonksiyonların, örneğin muhasebe işlemlerinin dışında bir konudur. Dolayısıyla menü ve ekranları kullanıcıyı caydırmayacak şekilde biçimlendirmek ve yasak alanlara erişmesini de önlemek gerekir. Ancak hayli zaman gerektiren bu işin ekonomik biçimde yapılması gerekir, bu arada da çok sayıda kullanıcı olabilir. Bir yaklaşım kullanıcıları gruplar halinde toplamak ve her grup için bir mönü yapısı oluşturmak olabilir. Ekran düzeyinde ise, çok sayıda ekran sık ve rutin biçimde kullanılıyorsa, tek bir ekran tasarımlanabilir. Güvenlik gereksinimlerini karşılamak için de kullanıcı bilgilerini alma özelliği artırılabilir. Ancak bütün bunların süreçlerin gelecekte değişecekleri dikkate alınarak yapılması gerekir. 12.4 Pilot

Pilot, simüle edilen gerçeğe çok yakın hale gelmiş sürecin son versiyonunun test edilmesi fırsatı verir. Gerçek dünya olaylarının simülasyonudur. Amaç sürecin doğruluğunu test etmek ve uygulama öncesi zayıflıklarını ortaya çıkartmaktır. Canlıya geçildiğinde herhangi bir problemle karşı karşıya kalınmaması için konularla uğraşma fırsatı verir. 12.4.1 Hazırlık

Hazırlık, denemenin başarıya ulaşabilmesi için esastır. Proje ekibi üyelerinin ve çalışma ortamı hakkında bilgisi olan çoğu son kullanıcının katkılarıyla oluşturulan bir simülasyon senaryosudur. Senaryo, normal bir işlemle başlar. Beklenen oluşumların gerçekleşeceğinden emin olmak için işlemin diğer süreçler

144

üzerindeki etkileri incelenir. Sonrasında sürecin normal fonksiyondan sapmaları test edilir. Bir örnek satın alma siparişlerinin malzeme gereksinimleri planlaması üzerindeki etkileridir. Satın alma siparişi verildiğinde açık satın alma sipariş raporu ve diğer ilişkili raporlar üzerinde neler olup bittiği gözlenir. Siparişi verilen mallar teslim alındığında kayıtlara geçirilir: mal tesellüm verileri sisteme detaylı biçimde girilir ve satın alma siparişlerine göre kaydedilir, mallar stok lokasyonlarına konur, malın muayene koşulu varsa önce muayene alanına alınır. Stok kayıtları, MRP ve borç hesapları üzerindeki etkileri incelenir. Bazı stokların depoya alınması, bazılarının iadesi, bazılarının karantinaya konması, böylelikle hammadde gözden geçirme komitesi tarafından ne yapılacağına karar verilmesi işleminin uygulanması gibi farklı simülasyonlar sınanır. Yeniden stok kayıtları, MRP ve Borçlar hesabı üzerindeki etkiler incelenir. Tedarikçinin yolladığı fatura geldiğinde irsaliye ve sipariş bilgileri ile karşılaştırılır, her şey uygunsa önce sisteme girilir, sonra büyük deftere kayıt yapılır. Benzer kontroller satıcıya yapılacak ödeme sırasında da yinelenir. Her bir aşama ile ilgili problemler tanımlanır ve simülasyon senaryoları üzerine kaydedilir. Örneğin yollanan miktar sipariş edilenden az olursa ne olacaktır? Satın alma siparişi ile irsaliye tutmadığı takdirde ne yapılacaktır? Ödemelerde döviz kullanılması söz konusuysa bu konuda neler yapılacak, döviz kurları muhasebe kayıtlarına ne şekilde geçecektir? Bu örnek basit bir sürecin bile ne kadar çok karmaşıklık içerdiğini göstermektedir. Karmaşıklık normal çalışma tarzından sapmalar yaşandıkça artar. Amaç bu tür sapmalarla sistemin başa çıkabileceğinden emin olmaktır. Bunun anlamı her sapmanın tanımlanması –ideal olarak bu iş prototip fazında yapılır- ve simüle edilmesidir. Bu çalışma günlük işlerle ilgili kişilerin katılımını gerektirmektedir. Sonuçta sürecin pilotu yapıldığında her sapmaya karşı bir önlem bulunmalıdır. Dahası başka bir yerde gerçekleşen sistem yanıtının etkileri de kabul edilebilirdir. Test işlemleri sırasında süreçle ilgili problemler çıkması canlıya geçmeden önce uygun yanıtların geliştirilmesi fırsatı verir. Yazılım değişiklikleriyle ilgili her konuya özel dikkat sarf edilmelidir. Değişiklik amaçlanan sonucu vermekte midir? Daha da önemlisi sistemin diğer parçalarını gerektiği gibi etkilemekte midir? Pilotun kalitesi test işleminde kullanılan süreç verilerinin kalitesinden etkilenir. Dolayısıyla hazırlık işlemlerinin önemli bir kısmı sisteme uygun verilerin beslenmesi için çalışmalar yapılması ve boşlukların tanımlanıp verilerin bu boşlukları doldurması ile

145

ilgilidir. İçinde hatalar olan bir veri kümesi, geçersiz girişler yapılarak veri kalitesinin bozulması pilotun kalitesini etkiler. Hatalar sayıların yorumlanmasında zihin karışıklıklarına neden olabilir. Dolayısıyla veri kümesinin pilot için özellikle hazırlanması gerekir. Proje yöneticisi için üçüncü iş pilot programını geliştirmektir. Program senaryoların sırasını, ne zaman çalıştırılacaklarını, ne kadar süreceklerini özetleyecektir. Her senaryoya kimlerin katılacağını ve gerektiğinde hangi kişi ve tesislerin çalıştırılacağını da yine bu program gösterecektir.

Senaryolar hazırlanıp veri kümesi oluşturulduğunda program da bitmiş olur. Şimdi pilot zamanıdır. 12.4.2 Simülasyon

İdeal olarak simülasyon bir odada bulunan birbirlerine bağlanarak network oluşturulmuş ve böylelikle insanların birbirleriyle yüz yüze iletişimlerine olanak veren bir ortamda gerçekleştirilir. Herkeste senaryonun bir kopyası bulunur. Proje müdürü, simülasyonun koordinatörü görevini üstlenerek ilerlemelerin fazla gecikmeler yaşanmaksın gerçekleşmesini ve ortaya çıkan sorunların kayıt altına alınmasını sağlar. Hiçbir şeyin gözden kaçırılmaması için kaydedilmesi gerekmektedir. Sonuçta takip edilmesi gereken gündemin yazılı olduğu bir doküman (Kısım 12.3.1)elde edilir. Tüm kontrollerin yapılabilmesi için gereken zaman verilmelidir. Bir adımdan diğerine yalnızca o adım için gereken tüm kontroller yapıldığından emin olunduktan sonra geçilmelidir. Bu yolla bir adımın etkileri diğer adımların etkileriyle karıştırılmaz. Böyle davranılması pilotun yavaşlamasına yol açabilir. Ancak bu aşamanın sistemin yapması gerekenleri yapıp yapmadığının testi için ideal zaman olduğunu hatırlatmakta fayda vardır. Test aşamasında süreçle ilgili sorunlar doğması canlıya geçmeden önce uygun yanıtların geliştirilmesi fırsatı sunar. Pilotun sunduğu fırsatlardan biri de sistem yöneticisinin yazılımın çalışmasının sistem performansı, örneğin disk alanı, diğer uygulama yazılımlarının etkileri, network trafiği vs., üzerindeki etkilerine ilk defa göz atması olanağıdır. Bunlar her ne kadar içsel gözlemler ise de teknolojik engellerin olup olmadığını anlamak açısından yeterlidir. 12.4.3 Takip

Simülasyonun takibi ortaya çıkan konuların çözümü çalışmalarıdır. Konular listesi (kısım 12.3.1) sonraki çalışmaların gündemini

146

oluşturur. Konular için çözümler geliştirildikten sonra pilot tekrar edilir. Konuların tanımlanması, çözülmesi şeklindeki pilot çalışmanın bu döngüsü tüm konular tamamlanıncaya kadar devam eder. Gerekli süreç fonksiyonları konusunda herkes tatmin olduğunda proje takımının, proje liderinin ve sürecin sahibinin imzalarıyla süreç kabul edilir. Böylelikle canlı uygulama sırasında bir hatayla karşılaşıldığında herhangi bir suçlamaya yer bırakılmamış olur. 12.5 Sorumluluklar

Şirket politikalarını savunmasız bırakmanın en hızlı yolu tüm görevler için sorumlu atamalarında başarısızlığa düşmektir. Canlı çalışma sırasında özel önem verilmesine karşın bir sorumlunun atanmış olmaması en azından ağız dalaşlarına yol açar. Bir sorumlu atandığında da ilgili dokümanların bu bilgiyi içerecek şekilde güncellenmesi gerekir. Rutin süreçler açık bir şekilde sorumlulara bağlanırken ay sonu işlemleri gibi daha az rutin süreçlerin sorumlularının belirlenmesinin gözden kaçırılması tehlikesi her zaman vardır. Daha kolaylıkla gözden kaçırılan ise veri hazırlama sorumluluklarıdır. Yeni bir tedarikçinin sisteme eklenmesi durumunda tedarikçiye ödeme için gereken banka detaylarını dahi unutmadan tüm verilerin hazırlanmasından kim sorumlu olacaktır? Böyle bir durumda farklı parametreler satın alma ve muhasebe arasında bölünebilir.; satın alma muhasebenin yapması istenen hesaplarla ilgili banka ve ödeme terimleri dışında kalan her türlü veriyle ilgili çalışmaları yapmakla yükümlü kılınır. Emniyetli görev iki liste derlemektir. İlk liste tüm ayrı süreçleri tanımlar. İkinci liste tüm ayrı veri hazırlık kategorilerini, örneğin; tedarikçi detaylarını, rotaları, fiyat listelerini, hesap güncelleme tablolarını tanımlar. Her iki liste de oynanacak rollerin tanımlarını, atanmış sorumlulukları ve onayları içerir. Belirtmek gerekir ki verileri toplamakla sorumlu kişiler verileri sisteme girecek kişilerden farklı olmalıdırlar. Sorumluların atanması için belki de en iyi zaman süreçlerin kesinleştirilmesinden önceki zamandır, böylelikle sorumluların süreç geliştirmenin nihai fazına dahil olmaları garanti edilmiş olur. 12.6 Dokümantasyon

Dokümantasyon süreç geliştirmenin nihai aşamasıdır. Dokümantasyon tüm prosedürleri, talimatları ve sürece ilişkin tüm şablonları içerir. Prosedürler ve talimatlar kişileri işleri nasıl

147

yapacakları konularında bilgilendirir ve nelerin yapıldığını yansıtmalıdır. Şablonlar bilgisayar ile toplanamayacak verilerin toplanması için gerekli olabilirler. Dokümantasyon, aynı zamanda sürecin yeniden yapılandırılması çalışmaları sırasında değişmiş olabileceği için iş tanımlarını da içerir. Gözden kaçırılmaması gereken konulardan biri, raporlar ve bürokrasidir. Her ne kadar kağıtsız ofis konusunda bazı kişilerin gemlenemez hırsı bulunsa da gerçek dokümanların temel olduğu şeklindedir. Eğer örgüt uluslararası ISO 9000 kalite sistemi standardına sahip ise bazı dokümanlara gereksinim bulunur. Eğer yeniden tanımlanan süreçler için destek dokümantasyonu bulunmuyorsa kalite standardının yasalarını çiğniyor demektir. Prosedürlere ilişkin dokümantasyon kalite yönetim sistemiyle ilişkili olup olmadıklarına bakılmaksızın doküman kontrol prosedürüne tabidirler. Bu prosedür dokümantasyonun onayı, yayınlanması, değişikliği ve geri çekilmesi için standart bir format ve işlemler sırası öngörür. Bir süreç değiştiğinde dokümantasyonu da kontrollü biçimde değiştirilir. Dokümantasyonu yoksa süreç tüm süreçlerin dokümante edilmesi felsefesi ve uygulamasıyla uyum sağlamaz. Bu durumda izlenecek bir yol proses kontrol amirinden sürecin bu şekilde yönetilmesi için imtiyaz talep etmektir. Ancak bu uygulama tarzı eğitim malzemelerinin geliştirilmesini sekteye uğratır. Dokümantasyon kişilerin süreçler üzerinde çalışmaları için temel materyalleri oluşturur ve eğitim zamanı hazır bulunması gerekir. 12.6.1 Prosedürler ve iş talimatları

Prosedürler ve iş talimatları, işlerin nasıl yapılacağını tasvir ederler, iş talimatları bunu daha detaylı biçimde yerine getirir. Bu dokümanların üretilmesi tek bir kişinin işi olmayıp süreci tanımlayan herkesin görevidir. Bu dokümantasyonun üretilmesi süreci prototip döneminde başlar, pilot süresince gelişir, final aşamasında son bulur. Yararlı bir yaklaşım gerekli ekranları sırasıyla MS Word’e veya eşdeğer bir programa yapıştırmaktır. Bu doküman edit edilerek gelecekteki gereksinimler için düzenlenir. Uygun olduğunda uygulama el kitaplarından veya kullanılan on-line yardım dosyalarından yararlanılır. Burada dikkat edilmesi gereken husus kullanılan dilin çok açık ve net hale getirilmesi gerektiğidir. Bu çalışmadan şirketin pek çok süreci etkileneceğinden konuyu şirketin tüm dokümantasyon formatını gözden geçirme fırsatı olarak değerlendirmekte fayda vardır. Doküman başlıkları şu konuları içerebilir:

• süreç adı,

148

• sürecin amacı, • sürecin tanımı, • süreç operasyonu ve bakımı ile ilgili sorumluluklar, • sürecin akışı, • detaylı talimatlar, • ilgili dokümantasyonun detayları.

Her dokümanın bir yayınlanma numarası, yazar adı ve tarihi bulunmalıdır. Proje yöneticisi tüm dokümanların bir listesinin yayınlanmasını yararlı bulabilir ve tamamlanan dokümanları izlemek için bu listeyi kullanabilir. Sorumlulukların atanması için daha önceden bir süreç listesi hazırlanmış ise (kısım 12.5) bu liste ilgili doküman gereksinimlerinin tanımlanmasında kullanılabilir. Dokümantasyon oluşturma çalışmaları eğitim çalışmalarını tehlikeye düşürmemek ve daha önemlisi canlı kullanım sırasında sorunlarla karşılaşmamak için son dakikaya bırakılmamalıdır. 12.6.2 İş tanımları

Yeni süreçlerin geliştirilmesi yeni iş tanımlarının doğmasıyla sonuçlanır. Manüel işlerin otomasyonu ve yeni görevlerin yaratılması kaçınılmazdır. Ancak insanlar değişime direnç gösterme eğilimindedirler. Bu nedenle insan kaynakları departmanı personeli uygulamaya en erken aşamadan başlayarak dahil edilmelidir. İş tanımlarındaki değişikliklere ilişkin konular arkadaşça ve hoş tarzda ele alınmalıdır. Sendikaların bilgilendirilmesi de unutulmamalıdır. Tüm çalışmalar boyunca yararların peşinden koşarken etkilenen herkesin durumunun iyi olmasına ve gelişmesine de yardımcı olmak gerekmektedir. Değişimin hayatın içine nüfuz ettiği şirketlerde böyle bir problem olmaz. Değişimin ne olduğunun bilinmediği organizasyonlarda ise bu konunun büyük bir sorun olma potansiyeli bulunmaktadır. Dikkatle ele alındığı takdirde herkesin yüzü gülümsemelerle dolacaktır. 12.6.3 Raporlar

Prosedürler insanları sisteme nasıl veri girecekleri konusunda bilgilendirirken veriler de insanları neler olup bittiği hakkında bilgilendirmede kullanılır. Bu çeşitli yollarla yapılabilir. Özel enformasyona veri giriş ekranları kullanılarak erişilebilir. Bunu yaparken kazaen veri girişi yapmamaya, veri silmemeye ve değiştirmemeye özen göstermek gerekir. Başka bir seçenek olarak

149

standart hazır raporları, kah ekran üzerinden soft kopya olarak, kah yazıcıdan bastırarak alınmış hard kopya olarak kullanmak yoluna gidilebilir. Proje ekibinin bir görevi de mevcut raporları tanımlamak, sonrasında da kullanıcıların ve yöneticilerin bu konuda bilgi sahibi olmalarını ve istediklerini nasıl elde edeceklerini sağlamaktır. Eğer standart raporlar istenen enformasyonu vermede yetersiz kalırsa alternatiflerin incelenmesi gerekir. Tek defalık42 sorgulamalar için belki yazılım ile verilen, bir sorgulama aracı verilere erişimi sağlayabilir. Ancak kısım 3.1’de belirtildiği gibi böylesi araçların yetkin olmayan kişiler tarafından dikkatle kullanılması gerekir. İş zekası araçları verilerin çok gelişmiş analizlerine olanak sunmakla birlikte çoğunlukla üçüncü taraf uygulamalar olduklarından her şirket tarafından satın alınmazlar ve iyi kullanım için gereken uzmanlığa da kolaylıkla erişilemez. Her iki halde de kullanıcılar bu yaklaşımların kullanımında kompetan hale gelmek için yüksek düzeyde teknik eğitime muhtaçtırlar. Bu ayrıca zaman da alacaktır. Diğer yaklaşım gereksinimler için özel raporlar geliştirmektir. Bu da bir eğitim gerektirmekle birlikte kısa vadede enformasyon gereksinimlerini karşılamak için hızlı bir seçenektir. Sınırlı sayıda kişi rapor yazma yeteneklerinin geliştirilmesi için seçilir. Seçim yüksek olasılıkla sistem yöneticisi ve takım üyeleri arasından yapılır. Eğer bu yetenekleri tek bir kişi öğrenir ve sonradan raporlara olan talep yüksek düzeylere çıkarsa veya herhangi bir nedenle bu kişi devamsızlık gösterirse şirkette bu alanda bir darboğaz oluşur. Bu raporların ne zaman üretileceğine de dikkat etmek gerekir. Eğer bu raporlar implementasyon sırasında yaratılırsa, tahmin edilen gereksinimleri karşılayacak şekilde tasarımlanmış olur. Oysa gereksinimler canlı kullanım dönemine geçildiğinde değişebilir ve daha iyi kavranabilir. Bu da ek işler yapılmasını, belki de tüm raporun yeniden tasarımını zorunlu kılar. Alternatif olarak gereksinimler canlı kullanım sonrasına kadar bekler. Bu durumda kullanıcılar deneyimlerine dayanarak gereksinimlerini daha iyi fark ederler ve daha özel rapor tarifleri yaparlar. Ancak bu yaklaşım sistemin bilgilendirici değerine gecikmeli bir erişim getirir. Bazı raporların implementasyon sürecinde bazılarının da canlı kullanım sırasında yaratılması şeklinde bir uzlaşıya da gidilebilir. Özel rapor yaratmanın fiili süreci proje yöneticisi tarafından koordine edilen kontrollü bir prosedürü izlemelidir. Bir tarif name

42 Ad hoc

150

talebe eşlik etmelidir. Bu tarif name talepte bulunan kişi, raporun amacı, sütun başlıkları, seçim kriterleri, hesaplama benzeri her tür özel gereksinimleri içermelidir. Raporu yazacak kişiler raporu yazma yeteneklerine sahip olup olmadıklarını veya satıcı firmadan destek almak zorunda olup olmadıklarını değerlendirmek durumundadırlar. Dış destek gerektiği takdirde fiyat ve zaman tahminleri oluşturularak bu ek harcamaların değerlendirmesi yapılmalıdır. Özel enformasyon gereksinimlerinin karşılanması için alternatif yollar da bulunabilir. Kontrollü bir rapor üretme prosedürünün varlığı raporların makul süreler içinde üretilmesini garanti edecektir. Aynı zamanda son kullanıcının ne istediğine ilişkin karar verememiş olması durumunun yaratacağı sakıncaları da ortadan kaldıracaktır. 12.6.4 Kırtasiyecilik

Müşterilere ve tedarikçilere gönderilen dokümanların ön baskılı kağıtlar üzerine yapıldığı varsayılabilir. Bu dokümantasyon şirketin imajını gösterir. Dahası ön baskılı kağıtlar pahalı ve kullanılan baskı teknolojisi demode olabilir. İmplementasyon hem bu imajı gözden geçirme hem de dokümantasyon üretimini azaltma fırsatı verir. Var olan iki seçenek (Kısım 3.1) ön baskılı belgeleri kullanmaya devam etmek ile arzu edilen doküman formatlarını print komutu içine gömmek ve özel yazıcılarla bastırmak şeklindedir. Burada ön baskılı belgelerden kurtulma ve maliyet tasarrufu yapma seçeneği bulunmaktadır. Eğer ön baskılı belge kullanmak yönünde karar alınmışsa yapılacak iş basit bir şekilde yazıcıları verileri yeni yazılımdan alacak şekilde konfigüre etmektir. Ancak yazıları teknolojik olarak konfigüre etmek olanaklı olmayabilir. Bu durumda ne yapılacaktır? Yeni ön baskılı belgeler mi kullanılacaktır? Yeni yazıcılar mı satın alınacaktır? Alternatif olarak dokümanları baskı anında formatlanmasına da karar verilebilir. Hangi yol benimsenirse benimsensin tüm dokümanların tanımlanması gereklidir. Bu amaçla hazırlanacak bir liste şunları içerebilir:

- satış siparişleri, - satış siparişi alındı bilgileri, - satış faturaları, - teslim makbuzları, - alacaklar, - borçlar, - satın alma siparişleri, - müşteri hesapları,

151

- bar kod etiketleri.

Eğer dokümanlar yeniden tasarımlanacaksa, ön baskılar yapılacaksa her doküman tipine göre gereksinimlerin saptanması gerekir. Sayfa tasarımının dışında her dokümanla ilgili pek çok sorunun yanıtlanması gerekir. Soruların bazıları şöyledir:

- logo olacak mıdır? - Renkler kullanılacak mıdır? - Veri alanları nelerdir, bunlar sistem haritası içinde nasıl

yayılacaktır? - Hangi enformasyonun bulunması zorunludur? Örneğin ticari

sicil numarası. - Yararlı olabilecek hangi ek enformasyon gösterilmelidir?

Örneğin irtibat isimleri, direkt telefon numaraları, dokümanı yaratan kişi ismi.

- Hangi başlıklara gereksinim bulunmaktadır? - Ölçü birimleri nedir, bunlar nasıl gösterilecektir? - Yabancı dil ve dövizler nasıl gösterilecektir? - Ek semboller gerekli midir? - Koşullar ve vade nasıl gösterilecektir?

Kararlar tüm süreç içinde yer almış olan pek çok kişinin katılımıyla alınmasını gerektirebilir. Her tasarım sürecinde olduğu gibi bir format üzerinde karar kılındıktan kısa bir zaman sonra birisi değişiklik önerisiyle ortaya çıkabilir. Bu tür davranışların gecikme ve bıkkınlık yaratması nedeniyle kontrol altına alınması gerekir. Her doküman bir kişinin sahipliğine verilmelidir. Bu kişiler kabul ettikleri son versiyonu imzalamalıdırlar. Bu aynı zamanda yayınlanmadan önce dokümanın kontrol edilmiş olduğunu gösterir. Yayınlanmadan sonra hatalar bulunursa düzeltilmesi pahalıya patlar. Ön baskılı belgeler üzerinde hatalar görülürse ne yapılacaktır? Hatayı gömülü format ile düzeltmek bir programcı ile ne kadar hızlı olabilecektir? Belki de muhasebeciler bu ek maliyetler kimin bütçesinden çıkacak sorusunu kalplerinden geçirirler! Doküman formatı basılma sırasında oluşturulacaksa dokümantasyonun nasıl geliştirileceği sorusu ortaya çıkar. Bunu yanıtlamak için dikkate alınması gereken çok sayıda konu bulunmaktadır. Bu dokümanı geliştirmek için gereken araç ve yetenek seti şirketi aşabilir v bunların dışarıdan temini gerekebilir. Bu yeteneklerin kurum içinde geliştirilmesinin maliyet etkin bir yol olup olmadığı araştırılabilir. Birini eğitmek zaman alabilir. Başlangıç doküman seti bir defa oluşturulduktan sonra değişiklikler o kadar seyrek olabilir ki dışarıdan alınacak destekle işi yürütmek maliyet

152

etkin hale gelebilir. Ancak dış desteğin niteliği ne olacaktır? Bu üçüncü taraf bir destek midir, yoksa satıcı firmadan mı alınmaktadır? Bir değişiklik talebi doğduğunda veya sorun çıktığında destek ne kadar hızlı gelecektir? Bir programcının serbest hale gelebilmesi ve konuya ele atabilmesi için iki ay mı beklenecektir? Değişikliklerin modem aracılığıyla uzaktan yerine getirilmesi olanaklı olabilir. Böyle bir durum varsa konuyu telefonla aktarmak yeterli olabilecektir. ERP implementasyonun her aşamasında olduğu gibi burada da planlama proje yönetimi ve dokümantasyon olmazsa olmaz konulardır. 12.7 Eğitim Stratejinin Uygulanması – 2. faz

Eğitimin bu fazı, son kullanıcının ve yöneticilerin eğitimidir. Amaç yeni uygulama ve yeni süreçlerle konularında proje ekibinin sahip olduğu bilgileri ve yetenekleri tüm örgüte yaymaktır. Beklenen çıktı eğitilenlerin sistemi kullanabilir hale gelmeleridir. 12.7.1 Program

Bu faz için tüm gerekli alanları kapsayan bir program geliştirilebilir. Farklı dinleyici gruplarını ve farklı konuları yansıtacak şekilde değişik temalardan oluşan bir düzenleme yapmak uygun olacaktır. Genel bir bakış herkese, uzmanlık alanları da sınırlı sayıda kişiye hitap edecektir. Herkesle ilgili olan bir konu sisteme girmek ve kullanıcı güvenliğidir. Hiç klavye yeteneği bulunmayan kullanıcıların bulunabileceği gerçeği gözden kaçırılmamalıdır. Gerekiyorsa temel klavye yetenekleri kursu da açılmalıdır. İki kullanıcı grubunun ayrıştırılması yerinde olacaktır: son kullanıcılar ve yöneticiler. Birinci grup sistemin nasıl kullanılacağıyla ilgiliyken yöneticiler daha çok sistem hakkında enformasyon alacaklarıyla ilgilidirler. Kullanıcılar kendi aralarında tesadüfi kullanıcılar, normal kullanıcılar ve düşünen kullanıcılar olmak üzere üç gruba ayrılırlar. Tesadüfi kullanıcıların ilgisi kendilerinden istenen bazı işleri yapabilir durumda olmakla sınırlıdır. Normal kullanıcılar özel fonksiyonlar kümesinin düzenli kullanıcılarıdırlar. Ana ilgileri işlerini yapmak için sistemi kullanmaktır. Düşünen kullanıcılar sistemin nasıl çalıştığını derinlemesine anlamayı, böylelikle problemleri çözmeyi ve iyileştirmeler yapmayı isterler. Dolayısıyla eğitimleri, iki düzeyli olarak ayırmak uygun olacaktır: işleri yapmak için temel eğitim ve sistemin ince noktalarını detaylı biçimde anlatan eğitim.

153

Bu eğitim PC üzerinde uygulamalı olarak gerçekleştirilen yapısal bir format olma eğilimindedir. İdeal olarak canlı uygulama verileri kullanılmalı, böylelikle gerçek yaşam simüle edilmelidir. Bu çalışma tarzı veri hazırlama işlemini tamamlamayı gerektirmektedir. Eğitim malzemeleri iş yönelimli olmakla birlikte işlerin neden o şekilde yapıldıklarını açıklayacak şekilde kullanılmalı, böylelikle eğitilmekte olan kişiler tarafından takdir edilmelidir. Proje takımı odası eğitim alan kişilerin pratik yapmaları ve eğitim sonrası çalışmaları için kullanılabilir olmalıdır. Eğitim veren kişiler proje takımı üyelerinin yeni uzmanları içinden seçilmelidir. Eğitimin birinci fazı nasıl eğitim verileceğine ilişkin eğitimi de içermelidir. Eğitimin zamanlaması, eğitim alma ile uygulama yazılımını kullanma arasında uzun bir süre bırakmayacak şekilde olmalıdır. Duruma göre tazeleyici bir eğitim tekrarı da olabilir. Eğitimin maliyeti bütçede yer alan değer ile kıyaslanmalıdır. 12.7.2 Plan

Her oturum ayrıntılı bir planla desteklenmeli olup, şu konuları içermelidir;

• amaçlar, • eğitimci, • dinleyiciler, • zaman, • yer, • yetenek, • içerik ve içerik yapısı, • metot, • kaynaklar/malzemeler, • maliyet.

Bu konuların pek çoğu kısım 11.4.3 içinde yer almıştır. Basit bir şablon (şekil 12.5) gözden bir şey kaçırma olasılığını azaltacaktır.

154

Eğitim Planı Genel bilgiler

Tarih: Yer: Konu: Süre: Amaç: Katılımcılar:

Hedefler: Giriş

Süre Temel içerik Metot Kaynaklar Değerlendirme

Gelişme

Süre Temel içerik Metot Kaynaklar Değerlendirme

Sonuç

Süre Temel içerik Metot Kaynaklar Değerlendirme

Gözden geçirme

Figür 12.5 Eğitim Planı Şablonu 12.7.3 Eğitimin tamamlanması ve değerlendirme

Eğitimin tamamlanması ancak yapılan değerlendirmenin başarılı sonuç vermesi iledir. Eğitim sırasında eğitici değişik davranış ve beklentilerle karşı karşıya gelecektir. Bazıları pozitif bir bakış açılarına sahipken bazıları da durumu negatif bir yaklaşımla göreceklerdir. Benzer şekilde bazıları eğitimin kalitesine ilişkin yüksek beklentilere sahipken bazıları da eğiticilerin deneyimsizliklerini fark etmeyeceklerdir. Bu nedenle eğiticiler nelerin iyi kavranmadığını anlayıp ona uygun davranışları göstermek zorundadırlar. Bu husus bir defa daha eğiticilerin eğitiminin öneminin altını çizmektedir.

155

Eğitim eğitilenlerin başta düşünülen yetenekleri geliştirmesi sonucunda tamamlanır. Bunun gerçekleşip gerçekleşmediğini kesin olarak anlamak için herhangi bir şekilde değerlendirme yapılması gerekir. Daha önce, kısım 11.4.5 içinde açıklandığı gibi, hangi yetenek veya bilgi düzeyine erişildiğinin değerlendirilmesine önem verilmesi gerekir. Bununla beraber eğitim gören kişilerin bu bilgi ya da becerileri kendilerinde saklama olasılığı öğrenmeleri ile kullanmaları arasında uzun zaman geçerse azalır. Dolayısıyla değerlendirme yapılması kişinin özel bir işlemi yapma becerisine işaret etmekten çok, erişebileceği yetenek düzeyini ortaya çıkarabilir. Canlı kullanıma yaklaşıldığında tazeleme kurslarının yapılması gerekebilir. 12.7.4 Gözden geçirme

Her oturumun tamamlanmasından sonra problemlerin ortaya çıkarılması için ve nelerin yapılıp nelerin daha iyi yapılabileceğinin anlaşılması için gözden geçirmelerin yapılması gerekir. Üzerinde konuşulması gereken konular arasında kullanılan eğitim materyali başta gelir. Bundan başka eğitilenlere ilişkin konular ve onların daha iyi yönetilmeleri için stratejiler de ele alınabilir. Farklı olan her durum ayrı bir deneyim anlamına geldiğinden bunların düzenli ve sürekli bir şekilde dikkate alınması sonraki eğitim oturumlarının daha başarılı geçmesini sağlayacak şekilde eğiticilere katkıda bulunacaktır. 12.8 Veri hazırlama

Veriler işletme içindeki her olay için temeldir. Veriler her yerdedirler; hard diskte depolanmış, kara tahtaya yazılmış veya kağıt üzerine karalanmış olabilirler. Verilerin değerleri bilgilendirmeleridir. Eğer doğru değillerse bizler de doğru bilgilenmiş olmayız ve kararlarımız da yanlış olur. Bu kararlardan doğan eylemler de duruma uygun olmazlar. Bütün bunlar işleri yoluna koymak için zaman ve çaba harcamak, belki kaybedilen müşteriler, canı sıkkın çalışanlar, güvenini kaybetmiş müşteriler gibi sonuçlar doğurabilir. Elbette maliyetler de yükselir. Yeni uygulama için verilerin temiz, diğer deyişle hatasız olmasını garantilemek fırsatı vardır. Buna verilen önemi yansıtan şey verilerin doğruluğu uğrunda gösterilen çabalardır. Bazı kişiler verilerin hatalarla dolu olmasını ve o şekilde yaşamayı kabul ederler. Hataların bulunması o kişiler için önemli değildir. Hatalı veriler herhangi bir şeydir. Hatta bazıları veriler temizlense bile

156

canlı kullanım sırasında kullanıcıların hatalı veriler girmeleri nedeniyle yeniden kirleneceğini ileri süreler ve dolayısıyla niye uğraşalım derler. Temel unsur sistemin doğruluğunun ister hazırlık zamanında ister canlı kullanımda oluşan veri hatalarıyla uzlaşmasıdır. Bu durum enformasyon sistemin fonksiyonlarının verimliliğini etkiler. Dahası entegrasyon ERP sisteminin karakteristiği olduğundan hatalar başka yerler de taşınır, belki onları ortaya çıkaracak ay sonu kapanışı gibi işlemler yapılıncaya dek gizli kalırlar. Veri hataları sisteme duyulan güveni azaltır ve aynı verilerle daha doğru olduğu ileri sürülen spreadsheet kullanımının baş göstermesine yol açar. Tedarikçilerin ve müşterilerin veri tabanına sınırlı erişim yeteneği edinmeleri gördükleri verilerin doğruluğuna bakarak güven duyup duymamalarına yol açar. Dolayısıyla yalnızca sistem canlı kullanıma geçerken değil sürekli kullanım sırasında da verilerin temiz olması arzu edilir. Elbette ilk temizlik verilerin sisteme yüklenmesi sırasında yapılır. 12.8.1 Veri göçü

Verilerin sisteme aktarılması için iki temel yol vardır. Veriler elle girilir veya elektronik yolla transfer edilir. Birinci yol emek yoğun olması nedeniyle açık bir şekilde yavaş ve maliyetlidir. Girilmeden önce verilerin hatadan arınmış olup olmadıkları kontrol edilmekle birlikte elle giriş yapmak hatasız veriler için garanti değildir. Prensipte elektronik veri transferi, özellikte çok miktardaki veriler için, daha hızlı ve daha temizdir. Ancak dikkate alınması gereken farklı konular bulunur. İlk önce eski sistemde üretilmiş olan verilerin erişilebilir bir formatta oldukları varsayımı bulunur. İkinci olarak verilere eriştikten sonra yeni sisteme yerleştirilebilmesi için ek verilere gereksinim bulunabilir. Ek veri alanlarının bulunduğu yerlerde yükleme yapmak için böyle bir durum ortaya çıkabilir. Verilerin dönüştürülmesi veya yeniden formatlanması gerekebilir. Verileri temizleme zamanı eski sistemden alıp yeni sisteme yüklemeden önceki ara aşama olabilir. Elektronik yükleme yazılım satıcısının teknik uzmanlığını gerektirebilir. Veri göçü karmaşık bir süreçtir. Her iki yaklaşımdan hangisi benimsenirse benimsensin; zamanında tamamlanması için yeni sisteme yapılacak taşımanın uygulamanın yeteri kadar erken bir noktasında olabildiğince detaylı biçimde planlanması gerekir. Bu konuyla ilgili yanıt bulunması gereken sorular şunlardır:

• Yeni sistem için gereken veriler nelerdir?

157

• Bu veriler eski sistemden transfer edilebilir mi? • Eski sistemde olmayan hangi verilere gereksinim vardır? • Bu son veriler herhangi bir yerde bulunmakta mıdır, en iyi

yüklenmeleri ne şekilde yapılabilir? • Veriler nasıl temizlenecektir? • Hangi statik veriler canlı kullanım öncesi transfer edilebilir ve

hangi dinamik veriler yalnızca eski sistemin son kullanılışından sonra transfer edilebilir?

• Verileri kim, ne zaman kontrol edecektir? • Verileri kim, ne zaman sisteme girecektir? • Veri giriş süreci nasıl yönetilecektir? • Girilmiş olan verilerin doğruluğunun sağlaması nasıl

yapılacaktır?

Statik veriler bir periyot içinde girilebilir. Dinamik veriler, zaman içinde değiştiklerinden yalnızca eski sistemin üzerinde yapılan en son işlemden sonra transfer edilebilirler. Dinamik verilere örnek olarak satın alma siparişleri, satış siparişleri ve stok detayları verilebilir. Dinamik verilerin göçü birkaç gün gerektirir, dolayısıyla da canlı kullanıma geçiş tarihinin uzun bir hafta sonu olması sık yaşanan olaylardandır. Bu davranış veri göçünün tamamlanması için daha fazla zaman bırakır ve enformasyon sisteminin yokluğundan kaynaklanacak çalışma günü kayıpları olasılığını azaltır. 12.9 Son dakika kontrolü

Zaman geldi, kullanıcılar eğitildi, süreçler test edildi, dokümanlar dağıtıldı ve veriler sisteme girildi. Donanım kontrol edildi, yazıcılar fonksiyonlarını yerine getirir durumdalar. Gözden kaçırılan bir şey var mı? Bu soruyu sormaya değer, çünkü yalnızca küçük bir detay veya hiç kimsenin üstünde düşünmemiş olduğu bir şey bulunabilir. Bu açık uçlu bir sorudur ve herkes yanıt vermeye davetlidir.

158

13 Canlıya Geçiş/Gözden Geçirme İdeal olarak yeni sistem canlıya geçtiğinde, insanların eski uygulamalarından yeni sistemin gerektirdiklerine geçmeleri gerekir. Eğer herkes uygun eğitimi almışsa herkes canlıya geçiş gününde ne yapacağını bilir. Süreçler uygun biçimde test edilmişse işlemler de sorunsuz bir şekilde gerçekleşir. Veri bakımları uygun şekilde yapılmışsa veriler kullananlar için anlam ifade eder. Canlıya geçiş gününün başarısı sorun sayısının azlığı ile ölçülür. İşin tamamlandığına ilişkin güçlü kanı duygusu uygulamanın kilometre taşlarından biridir. Ancak uygulama henüz bitmemiştir. Sıra yeni sistemin yararlarını kavrama ve gerçekleştirme çalışmalarındadır. Ancak canlıya geçişte ve sonrasında problemler yaşanabileceğinden bunlarla mücadele gerekecek mekanizmaların hazırda tutulması gerekir. 13.1 Problemler ve problem çözümleri

Problemler oluştuğunda herkesin haberdar olduğu bir problemlerle mücadele mekanizmasının hazır olması gerekir. Bu mekanizma basit olmalı ve problem çözümünde sağlanan ilerlemeleri izleme olanağı vermelidir. Bir problem tanımlandığında problem çözümünden ve koordinasyonundan sorumlu ilgiliye haber verilmesi gerekir. Bu kişi proje yöneticisi olabilir. Başlangıç soruşturmaları, problemin daha önce çözülüp çözülmediği veya satıcı firmaya aktarılmasının gerekip gerekmediğine ilişkin olabilir. Problemin detaylarına da gerek duyulur. Bu da problemin çıktığı anda nelerin yapılmakta olduğunun tanımlaması ile başlayabilir. Probleme ilişkin kanıtlar ilgili ekran görüntüleri ve dokümantasyonu da kapsayacak şekilde toplanır. Problem koordinatörü problemle kimin ilgileneceğini, çözüme ilişkin gelişmelerin kimin tarafından izlenip kaydedileceğini belirler. Benzerleri önceden çözülmüş problemlerin nüksetmesi halinde kolayca üstelerinden gelebilmek için arşivlenmeleri gerekir. Bazı problemler kritik etkiler yapabildiklerinden, örneğin ay sonu kapanışları gibi, uygulanan çözümler sonrasında konu kapatılamaz, çözümün ne gibi sonuçlar vermekte olduğunun bir süre izlenmesi gerekir. Problemler satıcı firmaya bildirilip çözüm talebinde bulunulduğunda geliştirilmiş olan yardım masalarına başvurulur.

159

13.1.1 Kullanıcı yardım masası

Kullanıcı yardım masası tedarikçi firmanın geliştirdiği, müşterilerin çözemedikleri problemlerin halledilmesi için yararlanılan bir çağrı merkezi uygulamasıdır. Erişim normal çalışma saatleri içinde olabileceği gibi uygulama satıcı firmaya göre değişmektedir. Tipik bir olay şu döngü ile gelişir: Bir problem geldiğinde kaydı yapılır, ilgili enformasyon ve önem derecesi ile birlikte raporlanır. Satıcı firma probleme özel bir kimlik numarası verir. Sonraki bir anda bir programcı sisteme (internet üzerinden) bağlanma izni talep eder. Bu izin verilirse bağlanarak sorunu gidermeye çalışır. Sorun çözüldüğü takdirde konu tamamlanır. Aksi takdirde daha fazla araştırma yapılır. Böyle bir gereksinim olduğunda müşteri firmanın tüm süreci gözler önüne sermesi istenir. Bazı durumlarda problem çözülemez ve ekip çalışmasına geçilir. Bu olanaklı olmadığında problem bir süreliğine ertelenerek satıcı firmanın iç çalışmalarıyla teşhis ve düzeltici önlem geliştirme çalışmaları yürütülür. Zaman içinde tüm problemlerin üstesinden gelinir. Her ne kadar bu servis, bakım antlaşmasının bir parçası ise de teknik problemlerle kullanıcı dikkatsizliğinden kaynaklanan problemleri birbirlerinden ayırt etmek gerekir. İkinci türlerin tekrarı halinde müşteriye fatura kesilebilir. Problem koordinasyon bakış açısından müşteri firmaya yalnızca müşteri destek hattından erişilmesi pratik ve yararlıdır. Böylelikle problemler raporlandığında diğer problemlerle aynı arşivde yer alır. Tüm problemlerin kimin çözdüğünden bağımsız olarak aynı arşiv içinde yer alması kabul edilebilir bir şekilde ve zamanında çözülüp çözülmediğinin izlenmesi için önem taşır. 13.1.2 İlk ayın sonu

Ay sonu süreci açık bir şekilde ifade edilen bir prosedür kapsamında tüm işlemlerin listelendiği ve sorumluların tanımlandığı bir tarzda tamamlanır. İlk ay sonu süreci potansiyel olarak doğası gereği gizli kalmış problemlerin ortaya çıkması nedeniyle tırnak yeme dönemidir. Operasyonel problemler ortaya çıkar. Ancak operasyonel konular muhasebe rakamlarına dönüşürler. Günlük işlemlerin akışında özellikle dikkat edilmediği takdirde anormal değerler gözden kaçarak sisteme girmiş olabilir. Bu ilk dönemde düzensizlikleri temizlemek amacıyla belli periyotlarla mizan’ı çalıştırmak yararlı

160

olur. Böylelikle biraz daha belirgin problemler halledilmiş olur. Ancak muhasebe rakamlarının ilk kapsamlı resmi, anlamlı olup olmadıkları aynı sonu sürecinde ortaya çıkar. Rakamların incelenmesi anormalliklerin görülmesini sağlar. Yanlış veya eksik muhasebe kodları sorunların nedeni olabilir. Benzer şekilde yıl sonu süreci kendine özgüdür. Ancak ay sonu süreçleri problemsiz kapanmışsa, ERP uygulaması açısından yıl sonunun da problemsiz olması beklenir. Ancak her zaman beklenmeyenler gerçekleşebilir. 13.2 Gözden Geçirme

Canlıya geçişin sonrasında uygulamanın nasıl ilerlemiş olduğunu gözden geçirmek yararlı olur. Bunun için altı hafta, hem ay sonu kapanışının yaşanmış olması, hem de diğer pratiklerin pek çoğunun tamamlanmış olması nedeniyle uygun bir süredir. Gözden geçirme uygulamaya ilişkin aşağıdaki konuların öğrenilmesini sağlar:

- Yazılım kendinden bekleneni yapmakta mıdır? Ortaya çıkan, bekleyen konular nelerdir?

- Uygulamadan ne öğrenilmiştir? Neler daha iyi yapılabilirdi? Gelecekte bu konu nasıl kullanılabilir?

- Tamamlanamamış konular için ne kadar bir süreye ve bütçeye gereksinim vardır?

- Proje başarılı mıdır? (başarının kısa tanımı için kısım 11.2.7 deki tartışmayı okuyunuz)

Gözden geçirme, özellikle ek fonksiyonalite dahil etmek için ardışık fazlar varsa, çok değerlidir. Kullanıcılardan ve yönetimden gelen geri beslemeler içermelidir. Bu geri beslemeler ek eğitim gereksinimlerinin farkına varılmasını sağlar. Gözden geçirme uygulamanın sonu değildir, yalnızca ERP uygulama döngüsünün sonraki büyük fazına geçilmekte olduğunun göstergesidir.

161

14 Kullanıma Devam Uygulama, asla gerçekten durmaz. Başlangıçta beklenen yararlar süreçlere daha fazla dikkat edilmedikçe oluşmaz, prototip süreçler çok düşük olasılıkla optimum çözümleri oluştururlar. Özel bir proses canlıya geçip te oturmak için gerekli zamanı bulduğunda iyileştirme için bazı noktalar sunar. Dahası ERP’nin yalnızca bir işletme içindeki faaliyetleri iyileştirici bir araç olduğu hatırlanmalıdır. Böylece süreçte iyileştirme olduğunda bunun doğrudan ERP üzerine aktarılması gerekmektedir. ERP sisteminin kullanımındaki iyileştirmeler süreçlerdeki iyileştirmelerin sonuçlarıdır. Bu iyileştirmeler, enformel olarak iyileştirmelerin kültürün bir parçası olduğu ortamlarda duyulan gereksinimlerle ortaya çıkarlar. Bu iyileştirmeler kültürün parçası olduğu yerlerde Toplam Kalite Yönetimi, Sürekli İyileştirme gibi pankartlar altında yer alırlar. Dahası kültürün anahtar görünüşü 1990’larda ortaya atılan bir ifade ile tanımlanmaktadır: “Öğrenen Organizasyonlar”. Bunlar birlikte rekabet gücünü belirleyen etmenlerden biri olan stratejik bir silahın bakımı ve sürdürülmesi için değişim yönetimi aracı oluştururlar. Zaman içinde bir araç olarak ERP sistemine erişildiğinde, diğer deyişle uygulama döngüsü tamamlandığında bir olanak sağlayıcıdan çok bir engel olarak görülür. Soru “ERP’nin son versiyonuna mı geçmeli, yoksa onu yeni bir sistemle mi değiştirmeli?” şeklinde belirir. Karar hangisi olursa olsun sonuç döngüye yeniden başlamaktır. Bu bölüm döngüyü kapatan, yeni versiyona geçiş-yeni sistem tartışmasından çok iyileştirme ile ilgili konularda kısa bir giriş sunmaktadır. 14.1 Sürekli iyileştirme

Sürekli iyileştirme, özellikle ilk ortaya çıktığı 1980’lerden beri çok ilgi gören gözde bir konu olmuştur. Konunun altında yatan prensip işleri daha iyi yapmanın yollarını sürekli aramaktır. Bir şirket felsefesi olarak benimsendiğinde herkesi kapsar. Yaklaşım genelde şirket genelindeki bir program etrafında organize edilen faaliyetler şeklindedir. Bu program sıklıkla “Toplam Kalite Yönetimi”dir ve kalitenin ülkesi olarak görülür. Sürekli İyileştirme programının özellikler tablo 14.1.’de sunulmuştur. Bir ERP uygulaması ile her ikisinin odağının da değişim yönetimi olması nedeniyle belki de çok sürpriz gelmeyen, güçlü benzerlikleri

162

bulunmaktadır. Farklar daha belirgindir. ERP uygulaması başı ve sonu olması nedeniyle proje odaklı olmak eğilimindedir. Sürekli iyileştirmeye günlük iş faaliyetleri içinde zaman ayrılır. ERP içindeki takım yaklaşımı ağırlıklı olarak proje takımı şeklindedir. Bu daha çok işin başkalarının Amaç Daha rekabetçi olmak Daha düşük maliyetler Müşteri tatminini iyileştirmek

Yaklaşım Şirket genelindeki sürekli iyileştirme programıyla tüm

faaliyetlerdeki uygunsuzlukları azaltmak. Bu amaçla: - işi, işletme içi prosesleri ve değişimle ilişkili etkileri

anlamak, - çalışanlara odaklanmak, - planlama, uygulama, kontrol, - çalışanların (yönetim kadroları dahil) eğitimi

Katılımcılar Tüm çalışanlar - bireysel kavrama ve farkındalık (etkin iletişim ile) ile

eylem sorumluluğu, - başarının kavranması, - katılımcı yönetim ve liderlik… özellikle üst yönetim -

Notlar

1. Gerekli süreçlerin açık anlaşımı, 2. Tüm süreçlerin sahiplerinin oluşturulması, 3. Sürekli iyileştirme şirketi yönlendirici komite ve takımlar kurma (kalite

çemberleri, görev güçleri) eğilimindedir. Yönlendirici komite stratejik konuları, takımlar operasyonel konuları ele alır.

4. Performans ölçüleri (kritik başarı faktörleri, kritik performans indeksleri, istatistiksel proses kontrol uygulamaları) ile gelişmeler izlenir.

5. Finansal temelli olmasa da tanımlama önemlidir. Amaç insanları birbirleriyle rekabet eder şekilde değil takım halinde çalıştırmaktır.

danışmanlığında çalışan bireyler tarafından yapıldığı gerçeğini yansıtır. Sürekli iyileştirme takımları özgül konularla veya konu kümeleriyle uğraşırlar ve inceleme tamamlandığında dağılırlar. Alternatif olarak takım bir süreç odağı olabilir, bu şekilde özel süreçlere ve iyileştirme yapmak için özel yollara bakabilirler. Herhangi bir zamanda çok sayıda takım olabilir, üyeler de konuya anlık ilgi duyan kişilerden oluşur. Herkesin en az bir takıma üye olduğu durumlara da rastlanır. Sürekli iyileştirmeye bir yaklaşım kontrol dışı durumdan mükemmellik yoluna dönüşüm çalışmalarını kapsamayı öngören

163

aşamalar serisi şeklindedir. Başlangıç varsayımı süreçlerin kontrol dışı olduğudur. İlk adım kontrol durumuna erişmektir. Kalite literatürü bir sürecin ne zaman kontrol altında olduğuna ilişkin, istatistiksel yaklaşımlarla süreç değerlendirmelerinin yapıldığı hassas tanımlar sunar. Daha genel bir görüş ise süreçlerin kabul edilebilir çıktılar sunduğu durumlarda kontrol altında olduğudur. Diğer deyişle kabul edilmeyen çıktılar çok seyrektir. Kontrol kurmak için basitçe yaklaşım problemleri tanımlamak ve onları yok etmek için sistematik biçimde çalışmaktır. Kabul edilmeyen çıktıların frekansı çok seyrek hale azaltıldığında sürecin gevşek olarak kontrol altında olduğu söylenebilir. Sonraki aşama iyileştirme durumuna doğru yol almaktır. Dikkatler kabul edilebilir çıktıların nasıl daha verimli şekilde üretilebileceğine yöneltilmiştir. İşleri daha iyi yapmanın yolları var mıdır? İşleri en iyi şekilde yapma yolunun kurulması beklenebilir. Aksine uygulama işleri daha iyi yapmanın yolunun kurulması şeklindedir. Bazı uç örneklerde işleri daha iyi yapma yolu seçilmez. Çeşitli nedenlerle tamamen farklı bir yaklaşıma dönüşümün zamanının uygun olmadığına karar verilir ve o aşamada uygulama sonraki bir tarihe ertelenir. Buna bir örnek olarak kanban sistemine geçiş gösterilebilir. Bu hipotetik örnekte sürekli iyileştirme ortamında iyileştirme ekipleri aracılığıyla kullanıcıların konuya dahil edilmelerinin uygulama ortamına kıyasla başarıya götürmede daha etkili olacağı düşünülmüştür. Genellikle en iyi uygulamalar şablonunun uygulama prototipi hazırlama süreci içinde kendi kendine oluşumunun sağlanmasıdır. Yeni uygulamaların zaman içinde test edilmesi ile zayıf yanlar fark edilir, fırsatlar hissedilir, analiz edilir, geliştirilir. Üçüncü aşama mükemmellik yolculuğuna çıkmaktır. Odak en iyi uygulamadır ve benimsenme eğilimi görülen yaklaşım da kıyaslamadır. Kıyaslama43 en iyi pratiklerin aranması ve bir firmanın bu sürecinin transfer edilebilir elemanlarının şirkete kazandırılmasıdır. Bu pratikler örgüt içinde başka yerlerde bulunabilir, rakip firmalarda veya tamamen farklı endüstrilerde olabilir. Arama yaygınlaştıkça yeni kavrayışlar da artar. Bu yaklaşım optimal performans seviyelerinde anlamlı iyileştirme fırsatları sunar. Bunu yaparken süreç iyileştirme durumundan mükemmellik durumuna ilerler. Ancak dikkatsiz bir şekilde şirket için uygun olmayan en iyi uygulamaların benimsenmesi tehlikesi de bulunur.

43 Benchmarking

164

Bu üç aşamalı süreç sürekli iyileştirme çabaları için basit bir çerçeve görevi sunar. İkinci ve üçüncü aşamalar yerine süreç iyileştirme yaklaşımı olarak Kıyaslama yaklaşımını benimsemek uygun olabilir. Ama birinci aşamayı atlamak istenmeyen çıktıların nedenlerini kavramama sonucunu doğurur. Bu da istenmeyen çıktılara yol açan özelliklerin transfer edilmesine yol açabilir. Sürekli iyileştirme uygulama sürecinin mantıksal uzantısıdır. Proje takımının yapay ortamlarda geliştirdiği pratiklerin değişimi en iyi etkileme durumunda olan kişilerin; işi yapanların günlük operasyonlar ışığında ince ayar yapmalarını olanaklı kılar. Şirket genelinde katılımın sağlanması ve planlama için zaman gerektirse de herhangi bir anda başlatılabilir. Proje takımının sürekli iyileştirme takımına dönüştürülmesi zaman aldığından önceden planlanmalıdır. Sürekli iyileştirme çıktısı ERP uygulamalarının sağlama olasılığı taşıyan (kısım 6.3.) yararlarının potansiyelden gerçeğe dönüşmesidir. Sürekli iyileştirme konusundaki bu kısa giriş konuyla ilgili pek çok kitapta geniş biçimde yer almaktadır. İlişkin liste kitabın sonundaki seçilmiş okunacaklar başlığı altında sunulmuştur. Gerekli sürekli iyileştirme koşulları burada anlatılmış olmakla beraber bireysel pratikler daha farklıdır. Başarılı olanlar örgütsel kültüre birlikte en iyi şekilde örülenlerdir. 14.1.1 Kültürel boyut

Örgütsel değişim konusuna ilişkin makaleler, sıklıkla açık ve net olmayan bir kavramdan; kültürden söz ederler. Pek çok kişinin birlikte çalıştıkları bir ortamda rekabete kıyasla kültür değişimi çok daha başarılı bir şekilde etkiler. Bununla verilen mesaj bazı kültürlerin diğerlerine kıyasla değişime daha çabuk getirecekleridir. Bu mesajı destekleyen gerçek örgütü oluşturan insanlar grubunun içinde özel bir takım bir şeyler olduğudur. Bu özel şeyler görülmezler, ama çalışanların birlikte işlevlerini nasıl yaptıkları konusunda önemli etkileri vardır. Bu özel şey ya da kültür pek çok tartışmaya konu olmuştur. Kültürü yararlı biçimde tanımlayan bir tanım onun tüm toplumu ördüğü paylaşılan felsefeler, ideolojiler, değerler, varsayımlar, tutumlar ve normlardır. Başka şekilde tanımlarsak bu bizlerin iş yapma yoludur. Ancak kültür durağan değildir; zaman içinde evrim geçirir. Şirkette uzun süre çalışan insanların ayrılması, işe yeni gelenler, daha talepkar müşteriler veya yasal gereksinimler hüküm sürmekte olan kültürü etkileyen unsurların bazılarıdır. Eğer bir kültür değişebilecekse sorulması gereken soru onun daha arzu edilen bir

165

duruma doğru şekillendirilip şekillendirilemeyeceğidir. Bir kültürü değiştirmek için ne yapılmalıdır? Değişime daha fazla olanak sağlayan bir hale nasıl getirmelidir? Bu sorular özellikle Toplam Kalite Yönetimi ve sürekli iyileştirme konuları kapsamında çok tartışılmıştır. Kolay yanıtları da bulunmamıştır. Bir kültürü etkileyecek başarılı çabalar pek çok faaliyetle ilişkilidir. Üst yönetim nelerin ortaya çıkmasından hoşlanacağına ilişkin bir vizyon ortaya koyar. Bu mesaj bazı olaylarla güçlendirilir. Tüm işgücü üzerine de odaklanılır. Olaylar pek çok görünüşe bürünebilir. Bazı semboller kullanılabileceği gibi yalın davranışlar da yapılabilir. Sembollere ilişkin şu birkaç örnek verilebilir; yönetimin araba/park tahsisleri, açık ofis uygulamaları, tertip ve düzen, ödüller ve ücretler, üniformalar vs… Bu sembollerin ve olayların verilen mesajlar ile uyumlu ve tutarlı olmasına büyük özen gösterilmesi gerekir. Muhafazakarlığı hedeflediğini ileri süren bir şirketin frapan giyinen çekici kadınları işe alması çalışanların yönetimin söylediklerini ciddiye almamalarına yol açar. Kültür değişimi problemlerle doludur. İyice yerleşmiş alışkanlıkların değişmesi zor olur. Uzun dönemli gelenekler terk edilmeye direnirler. Niyetlenilmeyen, arzu edilemeyen yan etkiler ortaya çıkar. İyi niyetli uygulamalar etkiledikleri kişiler üzerinde kötü duygular uyandırabilirler. Kültürel değişimi gerçekleştirmek zor olabilir. Kültürel değişimi sağlayabilecek bir formül henüz ortada yoktur. Bunun yerine kültürel değişim neredeyse gözle hiç görülemeyen şekilde bir takım olaylar bileşiminin oluşturduğu, yalnızca o şirkete özgü bir süreç biçiminde ilerleyen bir süreç olarak yaşanır. Kültürün bu kavramı hem takdir edilmesi, hem de üzerine gidilmesi gereken önemli bir konudur. ERP perspektifinden bakıldığında başarılı bir uygulama için değişimi kucaklayan bir kültür arzu edilir. Değişimi kolaylaştıran koşulları oluşturur. Bununla beraber ERP uygulamasına proje yönetim ilkeleri ile yaklaşmak ve bunu üst yönetim desteği ile güçlendirmek oluşumu güçlendirir. Yeni pratikler çalışanlara empoze edilebilir. Ancak bu pratikler ya da yeni iş yapma yolları mekanik olarak yürütülür ve işleri daha iyi yapma şevki henüz yoktur. Uygulamanın sürekli iyileştirmesi fazı yüksek olasılıkla gerçekleşmez. Sistem çalışmaya başladığında işler normale döner. 14.1.2 Örgütsel öğrenme ve Öğrenen örgüt

ERP uygulamasına dahil olan pek çok kişi için tüm döngü bir öğrenme deneyimidir. Proje ekibi üyeleri yeni bilgiler edinmektedirler. Son kullanıcılar yeni yetenekler edinmişlerdir.

166

Yöneticiler neler olup bittiğini anlamak için yeni yaklaşımlar öğrenmektedirler. Gerçekte örgütteki pek çok kişinin ortak öğrenmeye dahil olduğu, daha yaygın tanımla örgütsel öğrenme süreci içinde bulunduğudur. Son yıllardaki yaygın kullanımına kıyasla örgütsel öğrenme kavramı yeni değildir. Shrivastava isimli bir toplum mühendisi zat, 1983 yılında örgütsel öğrenme konusundaki çok sayıda farklı teoriyi derlemiştir. Bunlar içinde örgütsel stratejilerin formulasyonu ve daha kapsamlı örgütsel değişim için örgütsel öğrenmenin gerekliliğinin altını çizmiştir. Bireysel öğrenme ile bireylerin bilgi ve uzmanlıklarını paylaşmalarını birbirlerinden ayrıştırmıştır. Öğrenmeyi destekleyen sistemler enformel şebekelerden formel mekanizmalara kadar uzarlar. Bazı sistemler kendi kendilerine doğarken diğerleri tasarımlanır. En formel mekanizmalar kesin düzenlemeler içeren bürokrasidir. Örgütsel öğrenmenin pek çok yolu vardır. Bunu destekleyen unsurlardan biri kurum içindeki öğrenme süreçlerini anlama girişimidir. Bu öğrenen örgüt kavramından farklıdır. Ve ideal organizasyon, maksimum öğrenen örgüt olduğu savı pekçok çevreden destek görmektedir. Bu konuyla en fazla ilgili kişi Beşinci Disiplin kitabı nedeniyle Peter Senge’dir. Ancak belki de öğrenen örgüt yaratma çabaları öğrenen örgütün bir durum olmaktan çok peşinde koşulan bir amaç olması nedeniyle, pratik bir uygulama değil arzulanan bir düzeydir. Öğrenmenin örgüt içindeki rolünün yalnızca ideolojik bir görüntü vermekle sonuçlanması dışındaki gerçek kurum içinde veri yakalayan, kullanan, paylaşan, yetenekleri geliştiren, bilgiyi, entelektüel sermayeyi, yaratıcılığı teşvik eden bir sistemler kümesinin yaratılabileceğidir. Peter King bu konuya ilişkin altı strateji önermektedir. Bu stratejilerin uygulanması en geniş anlamlarıyla öğrenmeyi ve örgütsel öğrenmeyi destekleyen süreçlere veya mekanizmalara odaklanmaktan geçmektedir. Bu örgütün kültürünün açık bir etkisidir. Öğrenme de yaşamın parçası olarak kabul edilmektedir. ERP değişimle ilgilidir ve değişimin başarıyla gelmesi için çalışanlar kolektif biçimde ortamlarını anlamalılar, geleceğe ilişkin olanakları öğrenmeliler ve bunları hayata geçirme becerisi edinmelidirler. Bu amaç için örgüt ERP uygulaması yaparken kendisini öğrenen örgüt konumunda düşünmeli ve öğrenmenin çeşitli yöntemlerini deneyerek ilgili pratikleri benimsemelidir. Bu benimseme sonrasında örgütsel öğrenme üzerinde başarılı ERP uygulaması getirecek bir değişim yaratacak şekilde etki yapacaktır.

167

14.2 Yeni yazılıma karşı Terfi/Upgrade

Zaman içinde mevcut sistemin amacına hizmet ettiği ve gelişmeye olanak sağlamadan çok engel teşkil ettiği noktasına gelinir. Zaman içinde ne yapılacağı kararı sürekli bir kenara koyulur. Yeni bir sisteme geçmenin veya var olanı upgrade etmenin yararlarının aranması konusu potansiyel maliyetler ve gereken çabalar yüzünden boş verilebilir. Her ne kadar değişim maliyetlerinin etkisi varsa da artan işlevsellik, bu maliyetleri bertaraf etmeye yetecektir. Sonuçta bir şeyler yapmaya karar verildiğinde üç seçenekle karşı karşıya kalınır: upgrade, yenileme veya değiştirme. Her seçeneğin sunduğu avantajlar, maliyetler, test edilmemiş, hata içerme olasılığı bulunan yeni bir yazılım kullanmanın riskinin üstesinden nasıl gelineceği gibi konular dikkate alınır. Upgrade’in insanların hem yazılımı hem firmayı tanıması gibi avantajı bulunur. Aynı zamanda upgrade değiştirmeye kıyasla daha çabuk gerçekleştirilir. Satıcının upgrade deneyimi olması yumuşak geçişi kolaylaştırır. Kullanıcı grubunun varlığı satıcı firmanın fonksiyonel gelişme yolunu çizmesinde etkili olur, sonuçta modüller özel gereksinimlere yanıt verebilir hale gelirler ve tanımlanabilir yararları bulunur. Mevcut lisanslı versiyon ile son versiyon arasında büyük farklar varsa görünüm ve kullanım çok farklı olabilir. Geri plandaki kodlar 3GL yerine 4GL kullanılarak tamamen yeniden yazılmış olabilir. Bu da mevcut versiyonu basit şekilde ikame edecek bir upgrade fazı yerine ek fonksiyonaliteyi de içeren daha geniş bir çalışma gerekebilir. Komple uygulama gerekebilir. İlginç bir şekilde burada bahsedilmekte olan görüş yazılımların bileşen tabanlı yapıya geçirilmesiyle demode kalabilir. Yeni konsept içinde gerek duyulan bileşen satıcı firmanın sitesinden yüklenebilir ve çalıştırılabilir. Dikkatler yalnızca bileşene ilişkin faaliyetlere yöneltilir. Böylelikle upgrade süreci basitleşir, daha yönetilebilir hale gelir ve gereksinimler bazında gerçekleştirilir. Ancak ticari dürtüler gerçeği farklı kılabilir. Bir bileşen işlev görmek için diğer bileşenlerin yüklenmesini gerektirebilir. Sonuçta yeni sistemle yapılan upgrade de bir bileşenler kümesi yüklemeye dönüşebilir ve geleneksel upgrade kadar çaba gerektirebilir. Mevcut uygulamanın iyileştirilmesi yeni gereksinimlere yönelik uyarlamalar gerektirir. Eğer uygulamaya o ana kadar yüksek tutarlarda uyarlama yatırımları yapılmışsa bu kabul edilebilir bir seçenektir. Ancak şu farklı konuların dikkate alınması gerekir: yazılımın yaşı, ek gereksinimlerin ölçeği, kodlara kimin erişeceği, kodlarla ilgili sözleşme konuları, modifikasyonları kimin yapacağı,

168

kodlarla ne kadar haşır neşir oldukları, çözümün ne kadar hızlı biçimde yapılması gerektiği, modifikasyonların satıcı firma desteğini ne şekilde etkileyeceği, işlevselliğin uygulamaya özgü olup olmadığı vs. Bu kadar çok sayıda dikkat edilmesi gereken konunun üstesinden büyük kurumların gelebileceği aşikardır. Son olarak sunduğu fırsat ve meydan okumalarla mevcut sistemi yeni bir sistemle değiştirme seçeneği söz konusudur. Hangi seçenek üzerine karar verilirse verilsin, uygulama döngüsü yeniden başlangıç noktasına gelir. Döngü yeniden gereksinimlerin tanımlanması ve nasıl karşılanacağı sorularıyla başlar.

169

15.ERP Projelerinde Yapılan Temel Hatalar Günümüzde ERP projesine hissedilen ihtiyaç, her geçen gün artış göstermektedir. Çünkü rakipler, ERP projelerini çok efektif kullanamasalar dahi, ERP ile bir adım öne geçmişlerdir. İşletme sahipleri, ERP projelerinin gereğine inanıyorlar ama tüm sektörlerde özellikle KOBİ’lerde, neredeyse yeniden yapılanma projelereine giren de pişman, girmeyen de pişman. Başarının gerekleri olduğu gibi başarısızlığın da nedenleri çok. Başarısız bir projede belki yüzlerce neden sayabiliriz ancak en önemlilerini sıralamak gerekirse: aşağıdakileri belirtmek gerekecektir.

1. Yetersiz İhtiyaç Analizi; Yazılım projeleri genellikle birebir görüşmelerde güven üzerine pazarlanır, satışı yapılır. İşletmenin ihtiyacı, patronun, genellikle tek olan hedefi ile bir tutulur. Bu durum da, projede neyin yapılacağını belirsiz yapar. Yanlış ERP ürünü seçilmesine neden olabilir. Sağlıklı beklenti çizelgesinin yapılamaması.

2. Yetersiz Teknik Kadro; Her işletme en iyi kadronun kendinde olduğunu zanneder. Kadronun böyle bir projeyi kaldırıp kaldıramayacağını fark edememek projenin hazin sonunu hazırlar.

3. Yanlış Yönetici; Projeyi yönetmek projenin başarısı için önemlidir. Genellikle proje yöneticisi olarak seçilen zat, projenin başında isteklidir, sonra ortadan kaybolur, projenin sonuna doğru tekrar ortaya çıkar ve durum hakkında bilgi alır.

4. Proje Maliyetindeki Öngörülemeyenler; Genellikle projenin maliyeti yazılıma verilecek değer ile sınırlandırılır. Oysa yerelleştirme maliyetleri, yetersiz ve noksan bilgisayar, yetersiz ağ altyapısı, ek eğitim ihtiyacı ve personel için ek maliyetler proje maliyetlerini hep arttırmıştır. Bu durum kurumun para işlerinden sorumlu yöneticisini demoralize eder.

5. Projeye Ayrılamayan Zaman; ERP Projesi asli iş midir? Yoksa artan zamanın kullanılacağı bir iş midir? Proje çalışması sırasında, proje ekibindeki en çalışkan adamınızın "Bir dakika müşteri bekliyor..." diye ikide bir başka yere yönlendiğini düşünün.

170

6. Yanlış (Örtüşemeyen) Model; ERP iş akışındaki kavramlar, işletmedeki geleneksel iş akışları ile ters düşebilir. Hangisinden vaz geçilmelidir? Mevcut iş devam mı edecek, yoksa tanımladığınız yeni iş süreci mi sekteye uğrayacak?

7. Sınırsız İstekler; ERP projeleri AR-GE projeleri değildir. Bir ürün üzerinde istenen değişiklik ve eklemeler makul olmalıdır. Asimtotik istekler, sizi hiçbir zaman tatmin eğrisiyle kesiştiremez.

8. Temel Kodlar (Stok Kodları, Kaynak Kodları gibi) İçin Yetersiz Çalışma; Projenin üzerine oturduğu kodlama yapısının dar zamanda, alelacele kurulması.

9. Yanlış Risk Yönetimi ya da riski yönetememe: Zira proje esnasında beklenmedik durumlarla karşılaşılabilir. Yüzlerce proje de yapsanız her projenin kendine has koşulları vardır. Bu özel durumların her biri, birer risktir. Bunların önceden tespiti ve proje ekibiyle paylaşılması konusunda yapılacak hatalar projenin kırılma noktaları olabilir.

10. Geçiş Aşamalarındaki Yanlış Seçimler; Aslında tüm modüller, tüm detaylarıyla birlikte aynı anda devreye alınabilse keşke! Bunu yapmak zor elbette. Projeyi parçalara bölüp devreye alma fikri kulağa hoş gelir. Ancak yanlış aşama kararları kullanıcıda ciddi tatminsizlik oluşturmakla birlikte kullanıcıya ek iş yükü de getirir. Sonuç: isteksiz veri girişi, süreçlerde tıkanıklık ve başarısız proje.

Bir ERP projesinin başarısızlığını yukarıdaki temel hatalarla açıklamak mümkün. Bu hataları biraz daha açmak gerekirse: ERP uygulamaları başarıya ulaşsa bile her zaman içinde potansiyel sıkıntılar barındırır. Genellikle yeniden kurulması istenen ERP projesi için mevcut sistem ağır biçimde suçlanır ve kurulması istenen sistemden büyük beklentilerin doğmasına yol açılır. ERP sisteminin oturtulması, eski firmalarda aslında bir yeniden yapılanma çalışmasıdır. Bilindiği gibi yeniden yapılanma oldukça maliyetli bir çalışmadır. Hemen her zaman yeni başlayan projelerin maliyetlerini aslında mevcut sistem öder. Ve elbette bu maliyeti çıkartabiliyorsa mevcut sistem, o kadar da kötü olamaz. Yeniden yapılanmaya geçilirken mevcut sistemin iyi işleyen yanları iyi anlaşılmalı ve korunmalıdır. Yeniden yapılanma projesinin de aslında başlangıç aşaması,

171

mevcut sistemin iyi ve doğru bir analizi ile başlayacaktır. Bu analiz çalışması için her süreç, bütün girdi ve çıktıları ile birlikte tüm detayları ile iş akış şemaları üzerinde gösterilmelidir. Bu analiz çalışması, iş akış diyagramları hazırlanarak, öykü tahtaları ya da sürecin içinde yürüme teknikleri kullanılarak yapılabilir. Akıldan çıkartılmaması gereken önemli hususlardan biri, mevcut işleyen sistemi hiçbir zaman tamamen başarısız, yararsız saymamak ve onun yerine önerilen yeni yapılanmaya mümkün olmayan beklentilerin oluşmasına meydan vermemek gerekir. Yapılacak çalışmanın en önemli çıkış adımı, mevcut sistemin doğru işleyen taraflarını korumayı ama işlemeyen, eksik kalan kısımların ise yenilemeyi gözettiğini tüm çalışanları ikna ederek başlatılmasıdır. ERP yazılımları her zaman çok işlevsel olarak planlanırlar. Ama her işletmede planlanan tüm bu işlevlerin hepsi birden kullanılmaz. Başarıya yürümek için fonksiyelite kadar, işlevlerin de olabildiğince sadeleştirilmesi, basitleştirilmesi yoluyla olur. Kurulacak sistem mümkün mertebe her insanın anlayabileceği kadar yalın ve kolay, karmaşadan uzak olmalıdır. Bir ERP projesine başlamak demek, iş sisteminde çok ciddi değişimlerin yapılacağı anlamına gelir. ERP ile kurulacak yeni sistem belki de son kez böylesine köklü değişimler yaşayacaktır; sonraki değişimler daha ziyade sistem üzerinde iyileştirmeler, terfiler şeklinde olacaktır. Yani aslında yaptığınız yeniden yapılanma, firmanıza yeni yetenekler kazandırmasına karşın aynı zamanda firmanızı sınırlandıracaktır da. Dolayısıyla tüm başından sonuna kadar tüm firma çalışanları projenin önemine inanması, ikna olması önemlidir. Proje muhakkak, en üst yönetim tarafından sahiplenilmeli, tüm çalışanların değişikliklere destek vermesi sağlanmalıdır. Bir çok ERP projesinde, yeniden yapılanma çalışması içinde doğru insanların yer almaması nedeniyle başarısızlık hikayeleri vardır. Ekibin içinde yeralan, ekibi yönlendirenlerin seçiminde, firmada etkin, tecrübeli, diğer çalışanlar tarafından sevilen, problem çıktığında çözüm odaklı, yaratıcı kişiliklere yer verilmelidir. Yetkileri doğru tanımlanmalı ve üst yönetim tarafından daima arkasında durulmalıdır. ERP projesinin uygulanması süreci aynı zamanda

172

yeni iş süreçlerinin tanımlanması, geliştirilmesi için de bir fırsat olduğu unutulmamalıdır. İnsan tabiatı gereği değişimlere kolay alışamaz. Çalışanlar, organizasyon biçimlerinin, iş yapma anlayışlarının değişeceğine dair inanç ve istekte olmayabilirler, değişimi ciddiye almayabilirler. Bu yeniden yapılanmanın, gelip geçici bir heves olarak görebilirler. Yeniden yapılanmanın belki de en önemli tarafı budur: çalışanlar, yeni koşullara daha hazır, istekli ve yeterli olmaları sağlanacaktır. Dolayısıyla çalışanları bu değişime karşı dirençleri dikkate alınmalı ve bu dirence karşı etkin yönetim kuralları uygulanmalıdır. Proje takımının ve ekip liderinin firma çalışanları açısında algılanmasına dikkat edilmelidir. Saygın ilişkiler içindekiler seçilmeli ve bu saygınlığa gölge düşürülmemelidir. ERP projesi boyunca, firma içinde bir kısım insan değişimi sonuna kadar desteklerken, bazıları sonuna kadar karşı çıkan bir tavır göstereceklerdir. Asıl önem verilmesi gereken, her iki uçta da olmayan, değişimi izleyen çoğunluktur. Bu insanların değişime kazanılması esastır. ERP projeleri hep detaylı tanımlarla başlatılır. Ama bir süre sonra bu detaylar unutulur. Maliyetlendirme, zamanlama, süreçlerin tanımları ve daha bir çok konuda raporlar düzenlenir ama asıl amaç, yaratılmak istenen fayda hep unutulur. İş süreçleri, tüm proje aşamaları boyunca sürekli olarak sorgulanmalıdır. Daima maliyet ve zaman kısıtları dikkate alınmalı ama hiçbir zaman ulaşılması gereken fayda unutulmamalıdır. Projenin her aşamasında o ana kadar edinilen fayda ile gelecekte beklenen fayda, sürekli olarak gözden geçirilmelidir. Bir ERP projesinde öngörülen süre ve bütçeye uygunluk en önemli başarı ölçütü olamaz. Asıl başarı ölçütü, yeniden yapılanma sonucunda hedeflenen faydaya ulaşılıp ulaşılamadığıdır. Organizasyon yapılması istenen ERP çalışması için istekli ve açık olmayacaktır. Bu, verimlilik sağlaması beklenen projenin tamamıyla verimsizlik üreten bir yapıya dönmesini de sağlayabilir. Gösterilen direnç ve isteksizliğin temelinde mevcut güç ya da etki merkezlerinde çalışanların kendi mevcut rollerini kaybetme (hatta mevcut işlerini kaybetme) kaygılarından kaynaklanabilir. Bu sorunu aşmak için tüm çalışanlara değişimle elde edilecek yeni faydaların

173

bilincine varmalarını sağlayacak eğitimler verilmesi ve ikna süreçlerinin işletilmesi gerekebilir. Kaynakların etkin kullanımına dönük yeniden yapılanma projesinin sonlu bir proje olduğu, bir süreci kapsadığı unutulmamalıdır. Önemli olanın proje tamamlandıktan sonraki süreç olduğu ve o süreçteki hedeflerin öngörülmesi gerektiği, planlamanın bu olduğu unutulmamalıdır.

174

16 ERP Yazılım Tedarikçileri

Dünya pazarlarında kullanılan birçok ERP sistemi mevcuttur. Burada Türkiye'de faaliyette olanlara ağırlık verilmiştir. Alttaki listenin sonlarında ise Türk yatırımcılar tarafından kurulan ERP Yazılım tedarikçileri listelenmiştir.

SAP

Almanya menşeli firma, ERP sektörünün en köklü firmasıdır. 1972 yılında kurulmuştur ve % 25 lik pazar payıyla ERP pazarının dünya lideri durumundadır. SAP, Türk pazarının da lideridir. Bu pazardaki payı % 35 civarındadır ve kullanıcı sayısı 15.000’dir. Yaklaşık 250 firma tarafından tercih edilmiş durumdadır. Türkiye'nin ilk 500 firmasında ERP olarak büyük oranda SAP tercih edilmiş durumdadır.

ORACLE

Yaygın olarak veritabanı çözümleri ile tanınan ORACLE'ın "Oracle E-Business Suit" olarak tanımlanan ERP paketi de mevcuttur. Oracle, ERP pazarının dünya çapında ikincisi konumundayken, üçüncü konumda bulunan Peoplesoft (JD Edwards) firma ve yazılımını satın alarak, SAP’a karşı ciddi bir atak yapmıştır. Oracle ve Peoplesoft yazılımları birleştirme çalışmaları yeni yeni bitmektedir. Türkiye' de yaklaşık 200 kurulumu bulunmaktadır.

Microsoft MBS (Microsoft Dynamics)

Yazılım devi Microsoft, şirket satınalma stratejisi ile son dönemde ERP pazarında yer almış ve dünya çapında yaklaşık %5 pazar payı elde etmiştir. Türkiye'de aktif olan paketler Microsoft Dynamics başlığı altında Axapta ve Navision'dır. Pazar olarak SMB44 Kobi pazarını hedeflemektedir. Türkiye’de ki çözümleri, çözüm ortağı olarak yerli birçok firma uygulamaktadır.

44 SMB: Small and Medium Size Business

175

IFS (Industrial and Financial Systems)

IFS, büyüyen işletmelerin verimlilik sorunlarını çözmeye yardımcı ERP çözümleri geliştiren global bir yazılım firmasıdır. IFS, 1983 yılında kurulmuştur ve dünya genelinde 54 ülkede faaliyet göstermektedir.

IFS Uygulamaları (IFS Applications), SOA (Servis Odaklı Mimari) tabanlı ERP uygulamalarının öncüsü olarak gösterilmektedir. IFS ERP Uygulamaları sahip olduğu geniş fonksiyonalite, esnek mimari altyapısı ve kolay kullanımı ile her ölçekteki işletmelerin ihtiyacını karşılayacak şekilde tasarlanmıştır. IFS ERP uygulamalarının bileşen tabanlı yapısı işletmelere adım-adım kurulup devreye alınma imkanı vermektedir.

Günümüzde aralarında BMW, Volvo, Saab, Lockheed Martin, US Army, Jotun, Franke, Absolut gibi firmaların bulunduğu 3000 den fazla şirket 700.000 den fazla kullanıcı işlerini IFS uygulamaları ile yönetmektedir. IFS ERP Uygulamaları 23 dilde kullanılabilmekte ve çoklu şirket, çoklu döviz ve uluslararası muhasebe sistemlerine yapısına tam destek sağlamaktadır.

IFS Türkiye ofisi 2004 yılında kurulmuştur ve bu tarihten itibaren hızlı bir büyüme göstererek farklı sektörlerde 100’ün üzerinde müşteri, 300’ün üzerinde kurulum ve 7000’in üzerinde kullanıcıya ulaşmıştır. Pazar payı % 10’lar civarındadır.

IAS (Industrial Application Software)

IAS (Industrial Application Software), firmalara iş süreçlerini optimize etmeleri ve hızlandırmalarını sağlayan kurumsal yazılım çözümleri üretip, yazılımın danışmanlığını ve eğitim hizmetlerini vermek üzere 1989 yılında Almanya'da kurulmuştur. 1994 yılında Türkiye ofisini açarak yazılım geliştirme ve Ar-Ge faaliyetlerine hız vermiştir. Bugün itibari ile global operasyonlarını yürüttüğü Türkiye (İstanbul, İzmir), Almanya, Çin ve Dubai ofislerinde yazılım geliştirme, Ar-Ge, danışmanlık, satış ve eğitim faaliyetlerini sürdürmektedir.

Son ürünü CANIAS ERP, bütünleşik, sektör bağımsız, farklı yapılardaki firmalara uygun, gelişmiş teknoloji ürünü olan ve uzun

176

yılların tecrübesi ile geliştirdiği kapsamlı ve dünya ölçeğinde bir kurumsal kaynak planlama (ERP) çözümüdür. CANIAS ERP bugün Almanya, Türkiye, İrlanda, Fransa, Avusturya, Macaristan, Polonya, Çin, Dubai ve Tayvan başta olmak üzere 19 ülkede 11 farklı dilde kullanılmaktadır.

TÜBİTAK destekli olarak, Türk mühendisleri tarafından geliştirilen, %100 web tabanlı, platform ve sektör bağımsız, modüler ve bütünleşik yapıya sahip kurumsal kaynak planlama ürünü CANIAS ERP, TROIA adını taşıyan kendine özgü geliştirme dili ile dünya ERP pazarında önemli bir rekabet avantajı elde etmiştir.

ABAS SW

Dünya’da 2.800′ün üzerinde firmanın tercih ettiği ABAS, 1980 yılında Almanya’da kurulmuştur. Kuruluşundan itibaren ERP ve e-Business yazılımları geliştirmek ana faaliyet konusudur. ABAS Türkiye’nin de aralarında bulunduğu 50′nin üzerindeki global iş ortakları aracılığıyla yazılım yerelleştirilmesi, implementasyonu ve çok uluslu projeler konularında uzmanlaşmıştır.

ABAS ERP; İşletmelerin işlerindeki süreçleri optimize eden esnek bir ERP (Kurumsal Kaynak Planlama) yazılımıdır.

ABAS ERP kurumsal kaynak planlama yazılımı dünya çapında 2.800’ün üzerinde, farklı sektörlerde yer alan işletme tarafından kullanılmaktadır. Türkiye’nin de dahil olduğu Global ERP araştırmalarında kullanıcı memnuniyeti, kısa uyarlama süresi, mükemmel fiyat/performans oranı gibi kriterlerde üst sıralarda yer alan ABAS ERP, tamamen ücretsiz sunulan 28 farklı dilde kullanımı, platform bağımsız özelliği ve üç katmanlı mimarisi ile global anlamda pek çok farklı sektörden, farklı ölçekteki firmaların tercihi haline gelmiş, esnek bir yazılımdır.

Şu an 35 ülkede, 50’den fazla iş ortağı ve 900’ün üzerinde çalışanı ile müşterilerine hizmet veren ABAS şirketler grubunun iş ortakları ağı günden güne sürekli gelişmektedir.

NETSIS

2013’de Türk yerli yazılım üreticilerinin en büyüklerinden biri olan Logo tarafından satın alınmıştır. Başarılı projeleri hızla artan, sektörün önde gelen ERP üreticilerindendir. Merkezi İzmir'de olan yerli yazılım firması, çağdaş ve uluslararası kriterlere uygun

177

çözümler geliştirerek, bugün 40 çözüm ortağı ile birlikte hizmet vermektedir. Türkiye'den dünyaya yazılım ihraç etme misyonu ile Urla'daki ar-ge üslerinde geliştirdikleri yazılım teknolojilerini, bugün için Azerbaycan, Mısır, Ukrayna ve İran ofislerinde pazarlamaktadır.

LOGO

Türk yazılım sektörünün lider firması Logo, kurulduğu 1984 yılından bu yana pazarda muhasebe paketi ile kazandığı yaygınlığı, ERP alanında ürettiği ürün Unity ile devam ettirmektedir. Yurt dışına da yazılım ihraç eden Logo, son dönemde Java destekli "Unity on Demand" ürününü piyasaya sürmüştür. Önemli bir yazılım ihracatçısı olan Logo, halen 17 ülkede faaliyet göstermektedir.

UYUMSOFT

Ülkemizdeki önde gelen ERP firmalarından biri de Uyumsoft’tur. Ülkemizdeki ilk 500 de yer alan birçok firmaya çözüm sunan Uyumsoft, yönünü Avrupa'ya da çevirerek; İngiltere, Azerbeycan, Arnavutluk ve İran pazarlarına yazılım ihracatı yapmaktadır.

WORKCUBE

WorkCube; şirketlerin çalışanlarını, müşterilerini ve tedarikçiden servise kadar tüm iş ortaklarını tek ve sağlam bir platformda iş yapabilir hale getiren kapsamlı bir e-business uygulama yazılımıdır. Tamamen Web tabanlı bir kurumsal yazılım olan WorkCube kurumlara A'dan Z'ye ortak bir veri tabanı üzerinden tüm iş, işbirliği ve iletişim faaliyetlerini yürütebilecekleri bir platform sunar. Workcube geçmişte ve günümüzde farklı kategori ve tanımlarla ifade edilen kurumsal yazılım çözümlerinin komple bir bileşkesi olarak düşünülebilir. Bu açıdan WorkCube ERP, MRP, CRM,HR, SCM, CMS, LMS, B2B, B2C, Project Management v.b. çözümlerdeki tüm fonksiyonları kapsamakta ve birbiriyle birebir entegre bir biçimde kurumların kullanımına sunmaktadır. Workcube E-İş Sistemleri A.Ş. tarafından geliştirilen ve pazara sunulan Workcube, bugüne kadar ortak veri tabanı üzerinde en cok fonksiyon sunan Web tabanlı tek yazılımdır.

178

Minerva - Plantumweb

Minerva, 1987 yılından beri Türk Yazılım sektöründe faaliyet gösteren, geliştirdiği sistemler ve yaptığı çok sayıdaki projeler ile iş yönetimi yazılımları ve çözümleri konusuna odaklanmış bir yazılım şirketidir. Şirketin temel amacı, müşterilerine, bulundukları sektörlerde gerçek anlamda rekabet avantajı yaratacak iş yönetimi yazılımlarını sunmak ve gerekli hizmetleri vermektir.

Minerva, iş dünyasının hemen hemen bütün sektörlerinin ihtiyaç duyduğu uygulama yazılımlarını geliştirmekte, satış ve satış sonrası hizmetlerini vermektedir.

Minerva'nın, İşletme Yönetimi konusundaki güncel çözümü olan Plantum, uluslararası danışmanlık şirketleri ve müşterileri ile uzun yıllara dayanan ortak çalışmanın ürünü olup, çok güçlü bir yönetim felsefesi üzerine inşa edilmiştir. Web teknolojileri ile geliştirilmiş olan ürün yeni jenerasyon gerçek bir E-İş ortamı sunmaktadır.

Minerva, 23 yıllık deneyimi ve bilgisayar sektörüne adanmış kadrosu ile Türkiye'nin en önde gelen yüksek teknoloji şirketlerinden birisidir.

Set Yazılım

Set Yazılım, 1993 yılından beri, orta ve orta üzeri büyüklükteki yerel kuruluşlar ile yabancı sermayeli kurum ve kuruluşların ERP, CRM, MRP, IFRS, Finansal yazılım ihtiyaçları konusunda faaliyet göstermekte olan sektöründeki lider kuruluştur. Proje bazında %100 kuruma özgün çözümler üreten bir yazılım firması olarak ana ürün SET.B’LACK ERP yazılımı bir çok değişik sektörde başarıyla kullanılmaktadır.

TEKNOSOL – Visual Era

Ülkemizin önde gelen ERP yazılım firmalarındandır. Projeleri V-Era ERP ile ilaçtan kozmetiğe, tekstilden boya sektörüne, ambalaj sanayisinden otomotive, cam ve porselene kadar uzanan seçkin müşteri portföyüne çözümler sunmaktadır. Teknosol farklı hizmet anlayışı doğrultusunda proje öncesi, proje uygulaması ve sonrasında, verdiği hizmetlerle, V-Era ERP, sektörde en çok tercih edilen projeler arasında yerini sağlamlaştırmıştır.

179

SENKRON

1996 yılında yazılımevi olarak kurulan Senkron Bilgi Teknolojileri, dikey pazarlara yönelik geliştirdiği yazılımlarla sektörlerin çözüm noktası haline gelmiştir. Kablo firmalarına yönelik Prometrik; SPA, wellness ve fitness işletmelerine yönelik Lapis; yemek üretim kuruluşlarına yönelik Lesis yazılımlarıyla, çözümlerinin uygulanabilir, kullanılabilir, karşılanabilir ve yönetilebilir olmasına dikkat etmektedir.

AVAKOZA ERP (YazEvi Yazılım)

100’ü aşkın projeyle AVAKOZA ERP çözümünü sunan YazEvi Yazılım 1995 yılında kurulmuştur. 30 kişilik tecrübeli bir kadroya sahiptir. Kurumsal İş Çözümleri üzerinde uzmanlaşmıştır. Aynı zamanda ARGE faaliyetleri de yürütmektedir. İlk 500 ve ikinci 500’de bulunan müşterileri vardır. Türkiye dışında Mısır ve Yunanistan’da müşterileri bulunmaktadır.

AVAKOZA ERP; bir kurumun tüm iş süreçlerini yöneten çözümün adıdır.

AVAX BDS; YazEvi ürünlerini geliştirdiği ortamın (FrameWork) adıdır. AVAX da bir üründür. AVAX müşterileri, daha çok yazılım firmaları ile büyük ölçekli kurumların yazılım bölümleridir.

REPX; Kullanıcı seviyesinde web tabanlı rapor oluşturma aracıdır.

180