Çarşamba, Aralık 28, 2005

Çoklu Projelerin Yönetimi

Çoklu Projelerin Yönetimi
(Program Yönetimi)

Eğitim ve danışmanlık yaptığım firmalarda karşılaştığım en önemli sorulardan bir tanesi
de şudur:

Şirket bünyesinde birden fazla yürüyen projelerin birarada yönetilmesinde/koordinasyonunda uygulanabilecek özel bir yöntem var mı?

Bu sorunun cevabının, Proje Yönetimi disiplini altında yattığını her zaman söylemişimdir.
Proje Yönetimi disiplinin altındaki metodolojik yapılanmayı (tanımla - planla - uygula -
kontrol et) tek bir projeye uygulamakla, birden fazla projeye uygulamak açısından teoride
hicbir fark yoktur. (Fakat anlaşılan pratikte sorunlar bir hayli fazla)
Birden fazla projenin, sınırlı sayıda kaynakla eş zamanlı yürütülmesi ve üst yönetimin de
her bir projeye ayrı ayrı önem veriyor olması, özellikle Proje Yöneticileri üzerinde ağır
baskı yaratır. Proje Yöneticileri ise bu baskıyı ortak kullandıkları proje ekibine
yansıttıklarında, iş yeri, iş yeri olmaktan çıkar ve saatli bir bombaya dönüşebilir. Bütün
bireyler üzerinde stres yükselmiş, iş amaçlı tartışmalar, bireysel çatışmalara dönmüş,
ortak bir hedef güdülmediğinden grup sinerjisi yok olmuş ve motivasyon azalmış olabilir.
Yukarıdaki manzaranın ortaya çıkmasına sebep olan en önemli etkenin Üst Yönetim
olduğu aslında bir gerçektir. Öncelikli projeleri, Proje Yöneticilerinin sorumluluklarını ve
tabii ki yetkilerini tanımlamayan bir üst yönetimin yukaridaki manzarayla karşılaşması
çok doğaldır. Fakat bu manzarayı pek görmezler. (Ama bence çözümü bilmedikleri için
görmezlikten gelirler.) Halbuki bu problemle karşılaşan dünyada o kadar çok üst yönetici,
proje yöneticisi ve proje takımı üyeleri var ki, bilim adamları bu konuyu bilimsel alanlarda
tartışma, yeni alternatifler yaratma ihtiyacı duymuşlardır.
Program Yönetimi, yukarıda dile getirdiğim sorunları alt edebilmek amacıyla literatüre
giren Çoklu Projelerin Yönetimi sürecidir. Burada amaç, şirket bünyesinde
gerçekleştirilecek olan projelerin bir merkezden (Program Yönetimi Ofisi - PMO)
planlanması, kontrol edilmesi ve düzenli raporların üretilerek, tamamlanan projelerin de
kapatılmasını sağlamaktır.

PMO, organizasyonel yapıda değişiklikler gerektirebilir. Özellikle proje yöneticilerinin bağlı
olduğu ve koordine edildiği bir merkez oluşturulacaktır.
PMO'ya verilecek sorumlulukların ve yetkilerin arasında şunlar olabilir;

• Uygulamaya alınacak tüm projelerin tanımlama - planlama - uygulama - kontrol
etme süreçlerindeki koordinasyonu sağlama
• Yeni gelen bir projenin, mevcut projeler arasındaki önem seviyesini belirlemek, bu
projenin var olan plana dahil olması gerektiğinde, bundan etkilenecek olan diğer
projelerin etkilenme miktarlarını belirleme ve raporlama
• Planlanan ve gerçekleşen kaynak kullanım miktarlarının raporlanması (gerekirse
müdahalesi)
• Projelerde yaşanan sorunların çözümü için alternatif yaratarak üst yönetime
bildirme
• Risk tanımlama, Satınalma, Kalite Yönetimi, İletişim Yönetimi gibi süreçlerin
dökümanlarını üretme ve arşivleme
PMO'lar proje planlama ve yönetme sorumluluğunu üstleneceklerinden, şirket bünyesinde
devam eden projelerin hangi aşamada olduğu tek bir merkezden görülebilir. Takım
üyelerinin ve hatta proje yöneticilerinin dahi planlama için fazla bir efor harcamalarına
gerek kalmaz.

PMO yapıları, sipariş üzerine çalışan üretim firmalarından, her an yeni ürün geliştirmek
zorunda olan IT firmalarına kadar pek çok firmada veya departmanlarda uygulanabilir.
Yeni geliştirilen Proje Yönetimi yazılımları da (MS Project 2000/Central -MS Project 2002,
Project Gateway gibi) firmada PMO yapısının varolduğu varsayımı üzerine hazırlanmıştır.
Merkezi bir ofisten tüm insan, makine, malzeme ve para kaynağını değişen önceliklere
göre yönlendirebilen yazılımlar, PMO'ları çoklu proje uygulayan firmalar için zorunlu hale
getirmektedir.

Yazan: Gökrem TEKİR

Pazartesi, Aralık 26, 2005

Süreçler Üzerine Görüşler

Süreçler Üzerine
Görüşler


Şirketin Değeri ve Süreçler

• Günümüzde bir şirkete en çok değer kazandıran şey emsalsiz iş süreçlerine sahip
olmasıdır.
• Bir ülkede farklılaşma şirket değerini katlar, dünya’da farklılaşma şirket değerini
uçurur.
• Rakiplerden daha yüksek performansla yürütülen süreçler bir şirketi farklılaştırır.
• Şirketinizin değerini gelecek beş yılın risklerinden korumak için hiç değilse bir süreçte üstünlük yaratın ve farklılaşın.
• Müşteri portföyünüzün şirket değerine bir katkısı olması için müşterilerle ilişki
süreçleriniz sizi farklılaştıracak kadar güçlü olmalıdır..
• Şirketinizi farklılaştırmaya hangi süreçlerde hangi işleri tam zamanında yapacağınıza karar vererek başlayın
• Eğer dünya çapında üstün süreçlere sahip olursanız, dünya çapında şirket değeri elde edersiniz.
Süreç Yönetimi

• Bir şirketi bölümler değil, süreçler oluşturur.
• Bir süreçten beklenen toplam yararın % 80’i süreç kapsamında yapılan işlerin sadece %20’si ile ilişkilidir.
• Bir süreçte yapılan toplam işlerin % 80’i süreç için harcanan toplam zamanın %20’si ile gerçekleştirilir.
• Bir süreçte sorun çözmek için harcanan toplam zamanın %80’i sorunların % 20’si ile
ilişkilidir.
• Süreç mühendisliği süreç katılımcıları ile süreç yöneticileri arasında kritik durumlarda gerçek zamanlı ilişki kurulmasını sağlamalıdır.
• Süreç mühendisliğinin başarısı başta çok abartılı görünen hedeflere ulaşılmasını
sağlayan yaratıcı çözümlerde yatar.
• Süreçler birbiri ile ilişkili işlerden, işler birbirine bağlı işlemlerden oluşur. İşlemlerin doğru olup olmaması ise o an, o noktadaki bilginin yeterli olup olmamasına bağlıdır.
• Gerekli anlık bilgi akışının olmadığı yerde süreçler yönetilemez.Süreç Yönetimi
• Süreç Yönetimi doğru ürün ve hizmeti, müşterinin kapısına doğru zamanda, doğru
miktarda ve doğru fiyatla koymaktır.
• Önemli olan herkesin üstüne düşen işi “ iyi” yapması değil, hasıl olan sonuçlardan tüm müşterilerin memnun kalmasıdır.
• Kalıcı olan kişilerin değil, süreçlerin başarısıdır.
• İlk kez satış yaptığınız müşterilerin yüzde yüzü sürekli müşteriniz olmuyorsa süreçlerinizi gözden geçirmeniz gerekir.
• Herkesin işini “doğru ve iyi” yapıyor olması şirketinizi sektörde süreç maliyeti en düşük olan şirket yapmaz.
• Herkes işini “doğru” yapmaya çalışırken, kaçırdığımız müşteriler oluyorsa bazı şeyleri “yanlış” yapıyorsunuz demektir.
• Müşterilerinize ayrılan zamanı maksimize etmek için katma değer üretilmeyen zamanları minimize etmeniz gerekir.
• Şirket ölümleri tekleyen süreçlerle başlar.

Süreç Optimizasyonu

• Süreç Optimizasyonu asla bir tesadüf değil, daima akıllı gayretlerin sonucudur.
• Yüksek kalite ve düşük maliyet bir arada ancak Süreç Optimizasyonu sayesinde
başarılabilir.
• Süreç Optimizasyonu sektörünüzde en hızlı tamamlanan süreç bir önceki süreciniz olana kadar devam eder.
• Olması gereken süreç performansını müşteri tanımlar.
• İddialı süreç hedefleri yaratıcılığı körükler.
• Süreç Optimizasyonu bir işe ayrılan zamanı minimize etmek için aynı işi daha kısa sürede mi yapmalı yoksa gerekli işlem sayısını mı azaltmalı sorusuna cevaptır.
• Süreç performansı ayrıntılarda gizlidir.
• Sıra dışı durumlar süreç performansını negatif yönde zorluyorsa süreç mühendisine
ihtiyacınız var demektir.
• Süreçlerin iyi tasarlanıp tasarlanmadığı sıra dışı durumlarda belli olur.
• Süreç Optimizasyonu bizim şirkette maliyet tasarrufu sağlar mı diye düşünmeyin,
hedefleyin ve yapın.

Süreçler ve Sürekli İyileştirme Sistemi (Kaizen)

• Kaiden herkesin katılımı ile sonu gelmez görüş alış verişlerini değil, herkesin katılımıyla iş süreçlerinin küçük, ama sürekli gelişmeye tabi tutulmasını öngörür.
• Süreçler azar azar, ama sürekli iyileşirse, maliyetler hızla azalır.
• Durumu idare eden süreçler, kulağı keskin olanlar için çalan tehlike çanlarıdır.
• ISO ve Kalite çalışmalarınız ölçülebilir, kalıcı kazanımlar sağlamıyorsa süreçlerinizi gerçekten iyileştirmeyi unutmuş olabilir misiniz?
• Süreç İyileştirme hem bireysel, hem de grupsal çalışma ruhunu geliştirir.
• Sektör ortalamasının üstünde bir maliyetle yaptığınız işleri hiç yapmamayı deneyin, yani outsource edin.
• Süreç İyileştirme herkesin işidir, nasıl yapılacağı öğretilirse!
• Hangi durumlarda nasıl ilerlediği herkes tarafından bilinmeyen süreçlerde işlem
sorumlularının kendilerinden bekleneni bilmeleri zorlaşır., Söyleneni unutabilirler. Süreci bilmek ne zaman ne yapmaları gerektiğini anlamalarını sağlar.

Tedarik Zinciri Yönetimi

• Müşterileriniz açısından önem taşıyan süreçlerde süreç performansı rakiplerinizin
üstünde mi?
• Tedarik Zinciri’nde ortaya çıkan beklenmedik durumlar en basit bir işlem için harcanan zamanı en az 5 kat artırır.
• Sadece insan kapasitesine dayalı süreçler ekonomik olabilirler ama, müşterileriniz
açısından güvenilir olmazlar.
• Tam zamanında satın alma ve teslimat yapmayı nasıl sağlayabilirsiniz?
• Kaliteli süreçler müşterilere ve tedarikçilere doğru, kalitesiz süreçler ise hukuk
bürolarına doğru ilerler.
• Tedarik Zincirinde Süreç Optimizasyonu alınan sipariş adedi 3 katına çıkınca teslimat sürecinde kaos yaşamamaktır.


Kaynak : www.tepum.com.tr

Cumartesi, Aralık 24, 2005

TAKIM OLUŞTURMA VE PROJE YÖNETİCİSİNİN ROLLERİ

TAKIM OLUŞTURMA VE PROJE YÖNETİCİSİNİN ROLLERİ


Proje uygulamalarında genel kabul, Proje Yöneticisinin projenin tüm ilerleyişinden, klavuzluğundan,
kaynakların motivasyonundan ve kontrolünden tek başına sorumlu olduğu yönündedir. Bu durumda aşağıdaki
roller Proje Yöneticisine yüklenmektedir.

• Liderlik
• Projenin Teknik Direktörlüğü
• Proje – Sistem Entegrasyon Sorumluluğu
• Proje Planlayıcısı
• Proje Yürütücüsü
• Takım içi İletişim Sorumlusu

Bu rolleri üstlenmek bir Proje Yöneticisinin insan üstü güçleri olması gerektiğini düşündürebilir. Fakat bir
projeye başlandığında projeye katılımcı olan kaynaklar kendi sorumluluklarını ve rollerini belirleme arayışına
girerler. Bu noktada Proje Yöneticisinin kararlı ve tutarlı davranış sergilemesi çok önemlidir. Ancak bu sayede
Proje Yöneticisi yukarıda başlıklar halinde belirlediğimiz rolleri doğal olarak üstenmiş olacaktır.
Proje Takım Üyeleri, Proje Yöneticisinin performansını sürekli takip ederler. Çoğu zaman, Proje Yöneticisi
güvenilir olduğunu ispatlayana kadar takımın bazı üyelerinden tepkiler alabilir. İnsanların ortaya koyduğu bu
tepkiler psikoloji ve sosyoloji bilimi çerçevesinde incelenmektedir. Tepkilerin birkaç sebebi şu şekilde
sıralanabilir:

• Mevki beklentisi olan kişilerin tepkileri (Proje Yöneticiliği bekleyen kişilerin tepkileri)
• Bir sınıfa ait olan kişilerin (aynı okul mezunu olmak) farklı bir sınıfın üyesine gösterdiği tepkiler
• Yönetici değişimiyle takımın iş yapma alışkanlıklarının değişmesinden dolayı ortaya çıkan tepkiler
• Proje Yöneticisinin haketmediği halde o mevkiye atandığına inanan kişilerin gösterdiği tepkiler
• Takımın Proje Yöneticisine karşı güvenini kaybetmesiyle oluşan tepkiler
Proje Yöneticisi proje takımını kurarken dikkat etmesi gereken bazı noktalar şu şekilde sıralanabilir.
Takım kurmanın planlanması gerekir; Proje Yöneticisi projede yapılacak faaliyetlere göre hangi birimlerden ne
kadar kaynağa ve ne zaman ihtiyacı olacağını belirlemelidir.
Takım Üyeleriyle Mülakat: Proje Yöneticisi projeye dahil edeceği kişilerle önceden mülakat yapması önemli bir
uygulamadır.
Takımın Organize Edilmesi: Proje takımı üyelerinin projenin zaman planına göre programlanmasıdır.
Kick-off Meeting Düzenleyin: Proje takımı üyelerinin birbirlerini daha iyi tanışmaları ve ortak hedefleri
anlayabilmeleri için proje başlangıcında toplantı yapılması projenin başarısı için hayati önem taşır.
Takım Geliştirme Uygulamalarına Proje Boyunca Devam Edin: Gerek iş ortamında gerek iş dışı eğitimlerle veya
sosyal faaliyetlerle takımın geliştirilmesi için zaman ve kaynak ayrılmalıdır. Takım geliştirme çalışmaları proje
ekibinin motivasyonunu yükseltmeyi, stresin azalmasını, bireyler arasındaki iletişimin artmasına yönelik
olmalıdır.


Kaynak :
www.projeyonetimi.com' dan alınmıştır.

Pazar, Aralık 11, 2005

SÜREÇLERLE YÖNETİM VE SÜREÇ İYİLEŞTİRME –1

SÜREÇLERLE YÖNETİM VE SÜREÇ İYİLEŞTİRME –1


Yazarın notu: Günümüzde süreçlerle yönetim ve süreç iyileştirme kavramları, Kalite Yönetimi ve Proje Yönetimi gibi uluslararası standartlara ve kurumsal altyapılara sahip disiplinlerde önemli mevkiler edinmekte ve etki alanları giderek artmaktadır. Bu amaçla konu hakkında farklı açılardan değişik yazılarla karşınıza çıkarak, genel bilgi bütünlüğünü sağlamayı hedeflemekteyiz.“



Süreç, amaçlanan bir çıktıyı elde edebilmek için, kullanılan çeşitli girdiler üzerinde katma değer yaratan faaliyetlerdir.

Süreç, insan, makina, malzeme gibi kaynakları işleyip değer katarak müşteri isteklerini karşılayacak çıktıları üreten işlem veya işlemler dizisidir.



Katma değer sağlayan faaliyetler ikiye ayrılır:

Müşteri ihtiyaçlarına katkısı olan faaliyete “gerçek” katma değer denilir. Örnek: müşteri siparişinin hızlı ve doğru bir şekilde kabulü.
Kuruluş ihtiyaçlarına katkısı olan faaliyete “iç” katma değer denilir. Örnek satınalma siparişinin hızlı ve doğru bir şekilde açılması.

Bu iki sınıf dışında yapılan işler değer katmaz ve ortadan kaldırılmaları hedeflenir. Örnek: yeniden işleme.



Süreç girdi, proses ve çıktıdan oluşur:

Sürecin girdileri hammadde, bilgi ya da talep olabilir.
Sürecin girdileri, sürecin içerisinde işleme tabi olurlar.
Sürecin çıktıları, prosesin sonucunda ortaya çıkan ürün ya da servis olabilir.

Süreçler iki şekilde sınıflandırılabilir:

Operasyonel (Understand Markets & Customers, Develop Vision & Strategy, Design Products & Services, Market & Sell, Produce & Deliver for Manufacturing Organization, Produce & Deliver for Service Organization, Invoice & Service Customers)
Yönetimsel (Develope and Manage Human Resources, Manage Information, Manage Financial and Physical Resources, Execute Environmental Management Program, Manage External Relationships, Manage Improvement and Change)


Doğru bir süreç aşağıdaki özelliklere sahiptir:

Süreç sahipliği vardır.
Tanımlanmış ölçütleri vardır.
Tanımlanmış öncelikleri vardır.
İç-dış müşteri tanımlarına sahiptir.
Müşteri odaklıdır.
Değer katar.
Herkes tarafından anlaşılmıştır.
Ölçülebilir.
Sürekli iyileştirilir.


Süreç performansının izlenebilmesi için ölçülmesi zorunludur.

Süreç ölçümleri doğrudan ya da dolaylı olarak yapılabilir.

1. İç ölçümler sürecin performansını gösterir.

2. Çıktı ölçümleri sürecin çıktısının performansını gösterir.

3. Müşteri memnuniyeti ölçümleri, sürecin performansını müşterinin nasıl algıladığını gösterir.



Çok çeşitli süreç ölçütleri (leading-lagging) saptanabilir (Kalite ve hata oranı, çevrim zamanı, müşteri memnuniyeti, etkinlik vd.). Bir diğer ayırım da finansal olan ve finansal olmayan süreç ölçütleri ayırımıdır.



Süreç hiyerarşisi genel olarak üçe ayrılır:

Temel iş süreçleri
Alt süreçler
Detay süreçler



Devam edecek…



Memet Özkan

memeto@hotmail.com

SÜREÇLERLE YÖNETİM VE SÜREÇ İYİLEŞTİRME –2

SÜREÇLERLE YÖNETİM VE SÜREÇ İYİLEŞTİRME –2

Kritik süreçler:

Kritik başarı faktörleri, kuruluşu müşteri gözünde rakiplerinden farklı kılacak, pazarda rakibe göre üstünlük sağlamasına imkan verecek, güçlendirilmesi ve odaklanması gereken yönlerdir.

Kritik başarı faktörleri üzerinde önemli etkisi olan ve öncelikle iyileştirilmesi gerekli olan süreçlere kritik süreçler denilmektedir.

Kritik süreçler, kuruluşların öncelikle ele alması, iyileştirmesi gereken süreçleridir.

Üst va ana süreçlerin, kritik başarı faktörlerine bağlı olma koşuluyla toplam etkileri hesaplanarak, kritik süreçler belirlenir.

Kritik süreçlerde mevcut durum ve hedef arasındaki farklar, karar matriksinde kritik süreç bölgesini oluşturur.

Kritik süreçlerin gerekçeleri, işe etkileri, işlem planları ve hedefleri iyi tesbit edilmelidir.



Süreçlerle yönetim:

Süreçlerin analiz edilmesi için önce akış şemaları hazırlanmalı, mevcut performansı belirlemek için ölçümler yapılmalıdır. Farklı boyutlarda süreç akış şemaları düzenlenebilir (sıralı akış şeması, sorumluluk akış şeması, bilgi akış şeması vd.)

Süreçlerin sürekli olarak iyileştirilmesi, sürecin anlaşılması ile başlar. Süreç yönetimi, süreçlerin tanımlanması, ölçülmesi, kontrol edilebilir ve rekabet edebilir olması için uygulanır.

Süreçlerin yeniden düzenlenmesi, süreçlerden değer katmayan aktiviteleri atarak ve değer katanları düzenleyip, basitleştirerek, sürekli iyileştirmeyi sağlayan bir tekniktir.


Süreç değişikliğinin hayata geçirilmesi için 7 aşama vardır:

Süreçten etkilenenleri bilgilendirmek
Pilot uygulamaya geçiş
Sonuçların değerlendirilmesi
Standartlaşma
Eğitim
Yaygınlaştırma
Etkinliğin izlenmesi ve denetlenmesi


Süreç iyileştirilirken aşağıdaki prensipler dikkate alınır:

Sadeleştirme

Yalnızca katma değer yaratan adımların ele alınması
Kontrol ve karar adımlarının azaltılması
Daha az sayıda ve daha nitelikli personel kullanımı
Yeniden işleme adımlarını ortadan kaldırmak için önleyici ve denetleyici sistemlerin kurulması
Tekrar eden faaliyetlerin yok edilmesi




Basitleştirme

Erken karar noktalarının oluşturulması
Çok hatlılık, işlerin paralel gerçekleştirilmesi ve mümkün olan en kısa zamanda başlatılması, ara hedeflerin belirlenmesi
Çok yeteneklilik, ekip odaklı çalışmak, yetki ve sorumluluğun artırılması, imzaların azaltılması, matriks organizasyon
Teknolojiyi girdi olarak kullanmak, otomasyon, bilgi erişimi ve işleme, uzman sistemleri kullanmak


Devam edecek…



Memet Özkan

memeto@hotmail.com

Cumartesi, Aralık 10, 2005

PAZARLAMA YÖNETİMİ SÜRECİ: NEREDEN BAŞLAMALI?

PAZARLAMA YÖNETİMİ SÜRECİ: NEREDEN BAŞLAMALI?


Etkin pazarlama araştırmayla başlar.

Philip Kotler

“Hedef tüketici, müşteri ve toplumun istek ve geresinimlerini tatmin ederek kar sağlayacak pazarlama bileşenlerinin (ürün / hüzmet, fiyat, dağıtım ve tutundurma) planlanması, yönetimi ve denetimi çabaları” olarak tanımlanan pazarlama, bir çok unsurun birleşmesiyle oluşan geniş bir süreçtir.

Pazarlama konusunda günümüzün en etkin kişilerinden biri olan Kotler, pazarlama yönetimi sürecinin 5 ana kademeden meydana geldiğini ifade etmektedir. Kotler’e göre bu süreç aşağıda belirtilmiştir.


Burada ;

R (Researche): Araştırma

STP (Segmentation, Targeting, Position): Kesimlere Ayırma, Hedef Belirleme, Konumlandırma – Stratejik Pazarlama

MM (Marketing Mix): Pazarlama Karışımı (4P) – Taktik Pazarlama

I (Implementation): Yürürlüğe Koyma

C (Control): Kontrol

anlamına gelmektedir. Şimdi bu kavramları tek tek inceliyelim.


1. Araştırma

Araştırma, pazarlamanın başlangıç noktasıdır. Pazarlamanın tanımında olduğu gibi tüketicilerin yeni gereksinimlerinin belirlenmesi ve bu gereksinimlerin hangi noktada karşılanacağının belirlenmesi aşamasında devreye, araştırma girer. Araştırma, bir noktada pazarlama faaliyetinin ortaya çıkmasına olanak veren birinci basamaktır.

Zet Araştırma’nın kurucusu Vural Çakır’ın belirttiği gibi; “Araştırma, doğru pazarlama kararlarının birinci basamağıdır, kaynakların rasyonel ve tüketiciler yararına dağılımını sağlayacak bir toplumsal araçtır”

Araştırma, bir şirketi, herhangi bir pazarda alıcıların gereksinimleri, anlayışları ve tercihleri bakımından farklılık gösterdiklerini ortaya koyarak, pazarlama yönetimi sürecinin bir anlamda başlamasını sağlayacak önemli bir süreçtir.

2. Kesimlere Ayırma, Hedef Belirleme ve Konumlandırma(1) – Stratejik Pazarlama

Araştırma sürecinden sonra yönetim, hangi kesimlere ağırlık vereceğini belirlemek zorundadır. Bu yüzden öncelikle pazarı bölümlere ayırmalı ve bu bölümlerden bir veya daha fazlasını kendisine hedef pazar olarak seçmelidir. Yani hedef kitlesini belirlemek durumundadır. Bu işlem yapılırken ürün / hizmetin üstün yanlarının en verimli şekilde etki edeceği kesim / kesimler hedeflenmelidir.

Ürün / hizmetin hangi kesimleri (gençler, çalışan kadınlar vb.) hedef alacağının belirlenmesi pazarlama yönetimi açısından verilmesi gereken önemli bir karardır. Bu karar doğrultusunda pazarlama stratejisi oluşturulacak ve bu kesimlere uygun hedefler doğrultusunda herekete geçilecektir.

Hedef kitle ile hedeflerin belirlenmesinden sonra, şirket piyasaya sunduğu ürün ya da hizmetin kapsadığı temel üstünlüğü / üstünlükleri, hedef kitlenin bilmesini konumlandırmalıdır. Konumlandırma, şirketin piyasaya sürdüğü ürün veya hizmetin anahtar avantajlarını ve farklılıklarını müşterilerin zihnine sokma çabasıdır.

Kesimlere ayırma, hedef belirleme ve konumlandırma, pazarlama yönetiminin stratejik pazarlama ayağını oluşturmaktadır. Bu aşamada yapılan çalışmalar pazarlamanın stratejik olarak planlanmasını içermektedir.


3. Pazarlama Karışımı – Taktik Pazarlama

Stratejik pazarlama belirlendikten sonra taktik pazarlama aşamasına geçilir, ürün veya hizmetin konumlandırmasını destekleyen bir dizi pazarlama karışımı aracı belirlenir. 4P olarak nitelenen bu araçlar şunlardır:

Ürün (Product): Pazara sunulan teklifin kendisidir. Müşterinin satın almasıyla elde edeceği tatmin ve hizmet bütünüdür. Marka, ambalaj, kalite, boyutlar, tasarım ve garantiler, ürünü oluşturan unsurlardan bazılarıdır.
Fiyat (Price): Ürüne ödenen bedeldir. Teslimat, garanti ve buna benzer ödemeler bütünüdür. Fiyat belirlenirken pazarlama karışımındaki diğer unsurlar ve hedef kitle göz önünde bulundurulmalıdır.
Yer / Dağıtım (Place): Hedeflenen pazarda ürünün kolaylıkla bulabileceği ve kolaylıkla ulaşabilecek gerekli düzenlemeler bütünüdür.
Tutundurma (Promotion): Ürünün piyasada bulunurluğu ve üstünlükleri hakkında hedef kitleyi bilgilendirmek, hatırlatmak ve hedef kitleyi bunlar konusunda ikna etmek amacıyla uygulanan bütün iletişim çalışmalarıdır.
Reklam, halkla ilişkiler, doğrudan satış, satış promosyonu ve satış ekibi tutundurmayı oluşturan unsurlardır.


4. Yürürlüğe Koyma

Stratejik ve taktik pazarlama belirlendikten sonra artık belirlenmiş olan ürün üretilmeli, fiyatlandırılmalı, dağıtımı yapılmalı ve satış artışı sağlamak için çalışılmalıdır. Buna yürürlüğe koyma denir.

Yürürlüğe koyma aşamasında şirketin tüm bölümleri harekete geçer: Ar&Ge, satınalma, imalat, pazarlama ve satış, insan kaynakları, finans ve muhasebe.

Pazarlama yönetiminde en çok sorun yürürlüğe koyma aşamasında yaşanmaktadır. Çoğu şirket pazarlama stratejilerini çok iyi yapmalarına rağmen, yürürlüğe koymada sorunlar yaşamaktadır. Bunu gidermek için tüm birimler arasında yeterli koordinasyonun ve iletişimin sağlanması gerekmektedir.


5. Kontrol

Pazarlama sürecindeki son aşama kontrol aşamasıdır. Bu aşamada geri besleme yoluyla bilgi toplanır, sonuçlar takip edilir ve değerlendirilir ve pazarlama başarısının artırılması için düzeltmeler yapılır.

Etkili pazarlama organizasyonu sağlayabilmek için, pazarlama değerlendirme ve denetleme işlemlerinin sağlıklı bir şekilde gerçekleştirilmesi gerekmektedir.


Sonuç:

Pazarlama sürecinin nasıl işlediğine genel olarak bakmaya çalıştık, genel olarak bakıldığında pazarlama yönetimi; araştırma, planlama (stratejik ve taktik), uygulama ve değerlendirme olmak üzere 4 süreçten oluşmaktadır. Ancak, önemli olan planlamanın 4 veya 5 süreçten oluşmasından çok pazarlama yönetiminin çok boyutlu bir çalışma gerektirdiğinin unutulmamasıdır.

YARARLANILAN KAYNAKLAR

1.Çakır, Vural (2001), Geleceğe Bir Dokunuş, Mediacat Yayınları, Ankara.

2.Göksel, Bülent, Kocabaş, Füsün ve Elden, Müge (1997), Pazarlama İletişimi Açısından Halkla İlişkiler ve Reklam, Yayınevi Yayıncılık, İstanbul.

3.Kotler, Philip (2000), Kotler ve Pazarlama, Sistem Yayınları, İstanbul.

4.Kotler, Philip (1999), Pazarlama Yönetimi, Beta Basım Yayım, İstanbul.


DİPNOTLAR:

(1) Kesimlere ayırma, Hedef belirleme ve Konumlandırma, bazı kaynaklarda “Hedef Kitle” başlığı altında ele alınmaktadır. Ancak ifade biçimi dışında anlam farklılığı bulunmamaktadır


Mustafa Duran

mustafa.duran@ttnet.net.tr

(Yazar hakkında: İstanbul Üniversitesi İletişim Fakültesi Halkla İlişkiler Bölümü, 1998 mezunudur. Halkla İlişkiler ve Tanıtım Yüksek Lisansına devam etmektedir. 1995 yılından itibaren sayısız pazarlama ve kamuoyu araştırmasında görev almıştır. Şu anda serbest olarak araştırma hizmeti vermekte ve pazarlama iletişimi, pazarlama araştırmaları, müşteri memnuniyeti yönetimi ve müşteri memnuniyeti araştırmaları konularında bireysel çalışmalar gerçekleştirmektedir.)

KATILIMLI YÖNTEM UYGULAMASI

KATILIMLI YÖNTEM UYGULAMASI

Süreç bazlı yönetimin temelini oluşturan stratejik planlama çalışmalarına, metod açısından katkıda bulunmak amacıyla, uygulamada yer alan “katılımlı yöntem”in iş akışı hakkında kısa bilgiyi aşağıda veriyoruz.

“Katılımlı yöntem”in amacı değişik tarafların bakış açılarından beslenerek ortak aklı oluşturduktan sonra karar verme sürecindeki ölçütleri belirlemektir.


ÖN HAZIRLIKLAR

Bu aşamada çalışılacak konu, konu sahipleri, konu sahiplerinin temsil oranları ve katılımcılar belirlenir.

Yürütme kurulu ve gerekirse taraflar tarafından genişletilmiş bir yapı sorumluluğunda yürütülür.


ARAMA KONFERANSI

Bu aşamada vizyon belirlenir ve analitik sıralama yöntemi modeli için veri tabanı oluşturulur.

Konu sahipleri ve gözlemci statüsünde yürütme kurulu üyeleri sorumluluğunda yürütülür.



VİZYON VE ARA RAPOR

Katılımcı yöntem uygulayıcıları sorumluluğunda yürütülür.


ANALİTİK SIRALAMA YÖNTEMİ MODELİ

Bu aşamada karar konferansında kullanılacak hiyerarşik model oluşturulur.

Yürütme kurulu ve katılımlı yöntem uygulayıcıları sorumluluğunda yürütülür.


AKIL HARİTASI

Bu aşamada konu sahipleri ve temsil oranlarının gözden geçirilir, katılımcılar belirlenir.

Yürütme kurulu ve gerekirse taraflar tarafından genişletilmiş bir yapı sorumluluğunda yürütülür.

SIRALAMA KARAR KONFERANSI

Bu aşamada model katmanlarının öğelerinin öncelik sıralamaları ve duyarlılık analizi yapılır, ayrıca uygulama planlarını yönlendirecek strateji belirlenir.

Konu sahipleri ve gözlemci statüsünde yürütme kurulu üyeleri sorumluluğunda yürütülür.


TÜMLEŞTİRME VE RAPOR

Katılımcı yöntem uygulayıcıları sorumluluğunda yürütülür.


DİYALOG KONFERANSI

Bu aşamada karar konferansı sıralamasında elde edilen etkinliklerin hayata geçirilebilmelerine yönelik somut işbirlikleri modelleri oluşturulur.

Konu sahipleri ve gözlemci statüsünde yürütme kurulu üyeleri sorumluluğunda yürütülür.


SON RAPOR

Katılımcı yöntem uygulayıcıları sorumluluğunda yürütülür.



Derleyen: Memet Özkan

bilgi@danismend.com

Yararlanılan kaynak: Anahtar Dergisi, Sayı 10/112, sayfa 8

Perşembe, Aralık 08, 2005

SÜREÇ YÖNETİMİ ve İYİLEŞTİRİLMESİ

SÜREÇ YÖNETİMİ ve İYİLEŞTİRİLMESİ


Süreç, bir girdiyle başlayan (iç veya dış müşteriden gelen bir talep, bilgi veya hammadde) ve bu girdiye katma değer katılarak belirli bir çıktı üreten birbiriyle bağlantılı adımlar, işlemler dizisidir.

Giderek küreselleşen ve rekabetin her alanda çok yoğun olduğu dünyamızda, müşteri memnuniyetini sağlamanın ve sadık müşteriler yaratmanın önemi herkesce bilinmektedir. Müşteriye sunulan her mal veya hizmet bir sürecin çıktısı olduğuna göre, bu ürün veya hizmeti müşteri istek ve beklentilerine uygun ve firma için az maliyetli şekilde çalıştırmak için, süreci incelemek gerekmektedir.

İkinci Dünya Savaşı sonrasında Japonya’da başlayan ‘KAİZEN’ (sürekli iyileştirme) kavramıyla başlayan ve giderek dünyada ve Türkiye’de yaygınlaşmaya başlayan ‘kalite’ çalışmalarının özünde bugün, süreç mantığı vardır. Toplam Kalite EFQM Mükemmellik modeline göre bir sistem kurmak veya son yıllarda popülerlik kazanan CRM – Müşteri İlişkileri Yönetimi’ne geçmek isteyen veya ISO 9000 belgesi almak isteyen firmalar için Süreç Yönetimi hayatidir. ISO 9000 standardının 1994 versiyonunda yer almayan ‘süreç yönetimi, süreç göstergelerinin izlenmesi ve sürekli iyileştirme’ kavramları ISO 9000 :2000 revizyonunda artık yer almaktadır.

Ancak, bir firmanın süreç yönetimine başlaması ve sürekli iyileştirme çalışmalarını benimsemesi için mutlaka ISO 9000, Toplam Kalite veya CRM çalışmaları içinde olması gerekmemektedir.

Süreç-odaklılık, bir firmada, genel müdür ve üst yönetimin kararı, kararlılığı ve kaynak ayırması olmadan gerçekleşemez. Ayrıca süreç-odaklılık firmada kültür değişimi gerektirir; çünkü işler alışılagelenden biraz veya çok daha farklı biçimde yapılmaya başlanacaktır:


Süreçlere atanmış “sahip”ler (süreç sahibi = process owner) sorumlu oldukları süreci sürekli izleyerek denetim altında tutacaklar ve hedeflenenden sapma veya aksamalar gördüklerinde veya müşteri beklentileri değiştiğinde, iyileştirme ekipleri kurarak iyileştirme çalışmalarını başlatacaklardır.

İyileştirme ekiplerini her zaman süreç sahibinin farkedip oluşturması şart değildir. Çalışanların farkettikleri bir sorunu veya değiştirilmesi daha verimli olacak bir adım veya işlemi düzeltmek üzere gönüllü olarak birkaç kişi bir araya gelmeleri, sürekli gelişme için önemlidir ve bunu özendirecek sistem ve araçlar oluşturulmalıdır; iyi yönetilen bir Öneri Sisteminin kurulması, öneri sayısının performans değerlendirmesinde dikkate alınması, Toplam Kalite ve/veya Süreç Yönetimi için tüm çalışanların katılımı esastır.

Çalışanların süreci hızlı çalıştırabilmek (örneğin müşteri isteklerine başkasına sormadan hızlı yanıt verebilmeleri için yetkelendirilmiş (‘empowered’) olmaları önemlidir.

Süreç performansını izlemek için ölçümleme sistemi oluşturulacak ve ölçümlerdeki sapmalar incelenecektir.


SÜREÇ YÖNETİMİ NE DEĞİLDİR?

Süreç yönetimi ve süreç iyileştirme bir kerede yapılıp bitirilecek bir proje değildir. Yukarda da bahsedildiği gibi ‘sürekli iyileştirme’ kavramı süreç yönetiminin ayrılmaz bir parçasıdır. Bu nedenle, firmada Süreç İyileştirme düşünülüyorsa bunun tek seferlik bir çalışma olmadığı, firmadaki herkesin katılımını gerektiren ve devamlılık arzeden bir çalışma, ya da bir çalışma biçimi olduğu hatırlanmalıdır.

Süreç İyileştirme bazı firmalarda çalışanlara ne yapılmak istendiğinin tam olarak ve şeffaflıkla anlatılmaması durumunda çalışanlarda, ‘eleman azaltmaya’ gidildiği yolunda bir endişe ve iyileştirme çalışmalarına katılmada kararsızlık, hatta direnç oluşturabilir. Süreç İyileştirme, eleman azaltma çalışması değildir. Ancak , verimsiz iş ve adımlar azaltıldıkça görev tanımları değişebilir ya da yeni görevlere gereksinim duyulabilir. Bu da çalışanların görevlerinde değişiklikler olabileceği anlamına gelecektir. Bu konular, süreç odaklılığa geçme kararı çalışanlara duyurulurken anlatılmalıdır. Eleman azaltılması kaçınılmaz olarak gündeme gelecekse, bu kişiler için ne gibi mekanizmalar yaratılacağı baştan düşünülmelidir.



SÜREÇ YÖNETİMİN GETİRİLERİ:

Süreç yönetimi, müşteriye odaklanmayı sağlar. Organizasyonlar dikey olarak oluşturulmuş, hiyerarşik yapılardır. Süreçler ise genellikle birden fazla departmandan kişilerin katılımıyla çalışan yatay bir oluşumdur. Sadece bir departman içinde başlayıp biten süreçler de olmakla beraber, süreçler – özellikle firmanın ana süreçleri – fonksiyonlar arasıdır. Dikey organizasyonlar üzerinde, başı, sonu, adımları, departmandan departmana geçişleri net olarak tarif ve dokümante edilmemiş yatay süreçler çalıştığında ve süreçte yer alan her bir departman sadece kendi yaptığı kısımdan sorumlu olduğu; yani sürecin tümünü izleyen, gözleyen, denetleyen birinin (süreç sahibi) olmadığı durumlarda, süreçlerde aksamalar olması son derece doğaldır ve olmaktadır. Ve çoğu kez asıl önemli olanın müşteriye hizmet olduğu gözden kaçırılır.


Çok temel süreç sorunları: mükerrer veya hatalı veya katma değeri olmayan işlerin yapılması, çevrim ve/ya işlem zamanının uzaması, hatalı çıktılar, vb. gibidir. Bunlar, müşteri memnuniyetsizliği yaratır. Bu da giderek azalan gelir, kar ve pazar payıdır (orta ve uzun vadede).

Süreçlerin iyi yönetilmesi bu aksamaları engeller. Çünkü amaç, süreçlerin etkili (‘effective’ – beklentiyi karşılayan, doğru) ve verimli (‘efficient’ – maliyeti düşük) çalışmasını sağlamaktır.

Ayrıca, süreç bazında çalışma, çalışanların fikir ve önerilerine gereksinim duyduğundan, çalışanlar fikir ve önerilerine değer verilmesi nedeniyle daha motive çalışırlar ve işlerini benimserler.

Bu yönetim tarzı, geleneksel Taylor yönetim modelinde olduğu gibi bir aksama olduğunda kişileri sorumlu tutmamaktadır. Bu yaklaşıma göre, aksaklıkların (gecikme, hata, vb) nedeni süreçler veya sistemlerdir. (Gerçekten de bir kuruluşta veya havalanında kuyrukta geçirdiğiniz uzun süre, oradaki memurun yavaş çalışması yüzünden değil, sürecin tasarımından dolayıdır).

İnsana önem veren bu yönetim biçiminde kişiler gerekli eğitimleri alarak kendilerini geliştirme veya becerilerine, daha uygun görevlere gelme olanağına sahiptirler. Bunlar, şirkete bağlılığı artıran unsurlardır.

Diğer getiriler: açıkca tanımlanmış beklenti ve hedefler, basitleştirilmiş prosedürler, açık, net iş tanımları, bireysel otoritenin artması, beceri gelişimidir.



SÜREÇ YÖNETİMİNE GEÇME KONUSUNDA ÜST YÖNETİM KARARLILIĞI VARSA ŞU ADIMLAR İZLENMELİDİR:


1.GM ve üst yönetime, İş Süreçlerinin Yönetimi ve İyileştirilmeleri konusunda eğitim verilmesi.

2.Üst yönetimin bir araya gelerek firmanın ana süreçlerini, bu süreçlerin sahiplerini ve öncelikle ele alınacak süreçleri belirlemesi ve ele alınacak süreçler için Süreç İyileştirme Ekiplerini oluşturması (Aynı anda en fazla iki sürecin ele alınması uygun olur).

3.GM’in tüm firmaya uygun iletişim yollarıyla “süreç-odaklı” çalışmaya başlandığını, sürecin ne olduğunu , firmanın süreçlerini, süreç sahiplerini, öncelikle iyileştirilecek süreçler için oluşturulmuş iyileştirme ekiplerini duyurması; süreç-odaklılığın güncel bir yönetim biçimi olduğunu ve süreç iyileştirmenin şirket verimliliğini artırmaya yönelik olduğunu ve her bir çalışanın katkısının beklendiğini vurgulaması.

4.Firma içinden bu projeyi yönetecek bir Proje Lideri’nin görevlendirilmesi.

5.Proje Lideri ve İyileştirme ekiplerinin İş Süreçleri Yönetimi ve İyileştirilmeleri eğitimi almaları.

6.Ekiplerin çalışmaları boyunca danışabilecekleri, çalışmanın çıktılarını denetleyecek bir danışmanla anlaşılması – firmada bu görevi yürütecek birikime sahip bir kişi yoksa.

7.Proje Lideri ve Danışmanın proje planını oluşturması ve ekiplerin çalışmaya başlaması.



METODOLOJİ

Literatürde değişik sayıda adımlar içeren BPM / BPI (Business Process Management / Business Process Improvement) metodolojileri mevcuttur ancak bunlar incelendiğinde hepsinin aynı veya benzer adımları içerdiği görülür.


0. Süreçlerin saptanması, sahiplerin atanması, iyileştirilecek süreçlere karar verilmesi.

1. Ekiplerin oluşturulması - sürecin mevcut durumunun saptanması.

2. Sorunların kökenlerinin tespiti - iyileştirme seçeneklerini belirleme – seçenekler arasında seçim yapma.

3.İyileştirmenin uygulanması.



Filiz Eyüboğlu

filiz.eyuboglu@isbank.net.tr

SÜREÇLERLE İLGİLİ BAZI KAVRAM VE YAKLAŞIMLAR (BPM / BPI / BPR NEDİR?)

SÜREÇLERLE İLGİLİ BAZI KAVRAM VE YAKLAŞIMLAR HAKKINDA BİLGİ
BPM / BPI / BPR NEDİR?



Süreç yönetimiyle ilgili kitap ve makalelerde karşımızda değişik kavramlar ve bunların kısaltmaları çıkmaktadır.

“BPM – Business Process Management” – İş Süreçlerinin Yönetimi, “BPI – Business Process Improvement” – İş Süreçlerinin İyileştirilmesi, “BPR – Business Process Re-emgineering” – İş Süreçlerinin Yeniden Tasarımı, “Process Redesign”, “Process Innovation”, Değişim Mühendisiliği,vb.

Bu yazıda, bu kısaltma ve kavramlarla, “Sürekli İyileştirme”, “Toplam Kalite Yönetimi” hakkında birkaç konuya açıklık getirilecektir.

Öncelikle şunu açıklamak gerekir. Daha önce bu sitede yayımlanmış olan Süreç Yönetimi ve İyileştirilmesi başlıklı yazıda bahsedilen Süreç Yönetimi , İş Süreçlerinin Yönetimi’dir. (BPM – Business Process Management).

Türkçe kaynaklarda çoğunlukla ve nedense “İş” kelimesi pek kullanılmadığından ben de bu sözcüğü zaman zaman kullanmıyorum. Ancak bilinmelidir ki bu konular kapsamında ele alacağımız süreçler “iş” süreçleridir; “üretim” süreçleri değil.

Bir organizasyonun iş süreçlerinin belirlenmesi, tanımlanması, sahip atanması, sürekli izlenmesi “süreç yönetimi” (BPM) olarak adlandırılabilir. Fakat çok önemli nokta şudur: Süreç yönetimi, içinde “iyileştirme “ barındırmıyorsa, ona “süreç yönetimi” denemez.

Benzer biçimde sadece Süreç İyileştirme (BPI – Business Process Improvement) kavramı da “süreç yönetimini” içerecektir; çünkü yönetilmeyen bir şey iyileştirilemez.

Bu bakımdan, süreçlerin belirlenmesi, tanımlanması, izlenmesi, iyileştirilmesi stratejik yaklaşımına, “Süreç Yönetimi” (BPM) veya “Süreç İyileşleştirme” (BPI) adı verilebilir. Bu bakımdan, BPM ve BPI aynı şeyi ifade eder.

“Yönetim” ve “İyileştirme” kavram ve sözcüklerini ayrı kullanma eğiliminde olan kişilerin yanlış anlamalarına meydan vermemek için ben bu konularda konuşurken ve yazarken, “Süreç Yönetimi ve İyileştirmesi” diyorum. Hatta başında “iş” sözcüğünü de ekleyerek “İş Süreçlerinin Yönetimi ve İyileştirilmesi” demek en açıklayıcı olanı gibi görünüyor (İngilizce kısaltmalarla: BPM/BPI).

Bir de bilindiği gibi, “İş Süreçlerinin Yeniden Tasarımı – BPR Business Process Reengineering” kavramı var. Bu kavram için “Process Redesign” veya “Process Innovation” sözcükleri de kullanılmaktadır. Süreçte çok büyük, radikal değişiklikler yapılmasını; neredeyse mevcut sürecin sil baştan yapılıp, “bu süreci ilk defa şimdi ve hiç bir koşullanma, kısıtlama olmadan tasarlıyor olsak nasıl tasarlarız yaklaşımıyla” yeni baştan tasarlanması yaklaşımı…

Konuyla ilgilenen bazı kişilere göre, ’Süreç İyileştirme’deki iyileştirme sözcüğü , süreçte yapılan veya yapılacak küçük, adım adım, yani kademeli iyileştirmeleri ifade etmekte.

1993’de Davenport ‘iyileştirme’ ile ‘yeniden tasarımı’ kavramlarını, bunların getirdikleri değişim, nereden başladıkları, riskleri, gerektirdikleri zaman vb ölçütlerle karşılaştırmıştır.

BPI ile BPR arasındaki bu keskin ayrım, ancak yol göstermesi bakımından belki yararlı bulunabilir; çünkü biraz aşağıda açıklanacağı gibi BPI ya da BPR yapılacağı sürekli iyileştirme döngüsü içinde kararlaştırılmaktadır; bir firma, süreç yönetimi çalışmasının – özellikle en başında – bunlardan birini seçme durumunda değildir.

Ayrıca, Davenport’un bu listesinde ‘iyileştirme’ yerine TKY - Toplam Kalite Yönetimi demektedir ki bunu da doğru bulmak mümkün değil. Davenport gibi sayıları çok da azımsanmayacak kişi de TKY’nin ‘küçük iyileştirmeler’ anlamına geldiğini söylemektedir. İnanmak çok güç gibi gözükse de bu sav sanki bir bilgi eksikliğinden ya da yanlış bilgilenmekten kaynaklanmaktadır. Yıllardır Avrupa’da ve Türkiye’de kullanılan TKY EFQM Mükemmelik Modeli (Excellence Model) özellikle “Süreç Yönetimi” kriterinde, kuruluştaki kademeli ve sıçramalı iyileştirme olanaklarının nasıl belirlendiğini ve nasıl hayata geçirildiğini sorgulamaktadır. TKY’nin sadece kademeli iyileştirmeler anlamına geldiğini iddia etmek konuyu eksik bilmektir. Ayrıca, bilindiği gibi, Mükemmelik modeli sadece süreçlerdeki değişiklikleri değil, liderlikten çalışan yönetimine, strateji politika belirlemekten, tüm kaynakların yönetimine (bilgi, teknoloji, tedarikçiler, malzemeler, binalar, vb) kadar bir kuruluşun tüm işlevlerini sorgulayan ve her alanda yaratılan sonuçları izleyen/inceleyen ve bunu yaparken de sektörün ve/ya dünyanın en iyi kuruluşlarının süreç ve sonuçlarını da inceleyen bir yönetim felsefesidir. Bu kadar büyük ve kapsamlı bir konunun “sadece küçük iyileştirmeleri kapsaması” mümkün olabilir mi?

BPI – BPR konusuna devam edecek olursak:

BPI ve BPR’ın farkları hakkında listeler yapılmasını, bunların çok farklı şeyler gibi makale ve kitaplarda ele alınmasını kafa karıştırıcı bir yaklaşım olarak görüyoruz.

Çünkü:

Herşeyden önce, bir kuruluş süreç konusuna belki de ilk girişinde en baştan BPI veya BPR yapacağım diye karar vermek; birinden birini seçmek durumunda değildir. Süreçte, kademeli veya sıçramalı iyileştirmeler yapılacağı, sürecin durumuna, müşteri beklentisine, bilgi teknolojisi olanaklarına ve herşeyden evvel strateji ve hedeflere bağlıdır.

Süreçlerini belirlemiş ve yönetmeye başlamış bir kuruluşta, sürekli iyileştirme döngüsü içinde ele alınan süreçle ilgili olarak ilk yapılacak şey, sürecin mevcut durumunun incelenmesidir. Sürecin baştan mı tasarlanacağı, yoksa mevcut süreç içinde küçük değişiklikler mi yapılacağına sonra karar verilir. Ayrıca, küçük ya da büyük değişiklik kavramı da herkese göre değişebilir. 13 adımlık bir süreci sil baştan yapmadan adım sayısını 5’e indiriyorsanız, bu, küçük bir değişiklik midir yoksa baştan tasarım (radikal değişim) midir?

Dolayısıyla, iyileştirmek üzere ele alınacak süreç bir “Süreç İyileştirme Ekibi” oluşturulup, mevcut süreç incelenmeden ve sonra iyileştirme seçenekleri tartışılmadan, yapılacak değişikliğin (iyileşmenin) küçük mü büyük mü olacağını söylemek pek mümkün ve gerçekçi olamaz.

BPI konusunda çok değerli kitaplar vermiş ve sayısız kuruluşa katkıda bulunmuş James Harrington’un ve başka bazı yazarların da söylediklerine koşut olarak bizim de savunduğumuz yaklaşıma göre:

BPI yani İş Süreçlerinin İyileştirilmesi, sürecin mevcut durumunun incelenmesinden sonra üç değişik yaklaşıma yol açabilir:

süreç adımlarında veya adımlar içindeki işlemlerde değişiklikler yaparak,
katma değeri olmayan adımları ve bürokrasiyi atarak veya azaltarak, veya salt süreç katılımcılarının eğitim ve çalışma koşullarında iyileştirmeler yaparak süreçte iyileşmeler yapmak


Sürecin sil baştan yapılarak baştan tasarlanması (yani BPR – yeniden tasarım)

Kıyaslama (“benchmark”) sonucu seçilen bir sürecin aynen uygulanması


Kıyaslama sonucu alınan süreç, eski sürece ufak değişiklikler getiriyor veya sil baştan yapıyor olabilir ve bu yüzden onu birinci veya ikinci seçenek içinde değerlendirebiliriz.

Süreçlerin nasıl belirleneceğine ve iyileştirme metodolojisine daha sonraki yazılarımızda yer vereceğimiz için bu yazıda kısaca ve BPM/BPI ve BPR farkını dikkate alarak değinmek istediğim son birkaç nokta şudur:

Bir süreç, üst yönetim veya üst yönetimden kişilerin oluşturduğu Süreç İzleme Komitesi adını verebileceğimiz bir grup tarafından iyileştirilmek üzere seçilirken bile sürecin durumu az çok bilinmektedir (İyileştirilecek sürecin seçimi konusunda bu sitede daha önce yayımlanmış Sn. Memet Özkan’ın “Süreç Yönetimine Giriş” başlıklı yazısına bakınız).

Oluşturulan Süreç İyileştirme Ekibi, sürecin mevcut durumunu incelerken (haritanın çıkarılması, müşterilerle ve süreçte çalışanlarla görüşmeler yapılarak istek, beklenti, aksaklıkların öğrenilmesi, önerilerin alınması, engelleyicilerin öğrenilmesi, mevcut ölçümlerin kaydedilmesi, ölçüm yapılmıyorsa yapılması) durum daha netlikle ortaya çıkar. Küçük veya radikal değişiklikler yapılma ihtiyacı görünür hale gelir.

Küçük değişiklikler yapılacak ise,

sorunların kökeninin incelenmesi
iyileştirme çözüm seçeneklerinin tartışılması
seçeneklerden birine karar verilmesi
pilot uygulama ve pilottaki sonuçların incelenmesinden sonra
uygulamanın yaygınlaştırılması

izlenecek adımlardır.

Mevcut durum incelemesi süreçte büyük değişiklikler yapılacağını gösteriyor ise; ayrıntılı biçimde sorunların kökenini tespit etmeye gerek yoktur; bunlar zaten aşikar biçimde görünmekte ve biline gelmektedir. Bu durumda

Yaratıcılık ve yenilikçilik kullanılarak
Kıyaslama yoluyla en iyi uygulama araştırılarak
ve çoğunlukla yeni ve son bilgi teknolojisi olanakları kullanılarak
süreç yeni baştan tasarlanır. (Otomatik para çekme makineleri icat edilmemiş olsa ‘para çekme’ süreçleri değişmemiş olacaktı. Ancak teknoloji kullanmadan da süreç baştan tasarlanabilir.

ÖZET

Konuyu kısaca özetleyerek sonlandıracak olursak,

Süreç Yönetimi ‘iyileştirme’yi, Süreç İyileştirme, ‘süreçlerin yönetilmesini’ içerir.

Bir kuruluş süreç çalışmasına başlarken veya bir süreci incelemek üzere ele aldığında – daha incelemeden - iyileştirme ya da yeniden tasarım yapacağına karar veremez (ancak tüm rakipleriniz belirli bir işi artık belirli bir tarzda ve belli bir teknolojiyle yapıyorsa ve siz hala geçmişte kaldıysanız sürecinizi uzun uzun incelemenize gerek yoktur. Örneğin, bankaysanız ve hala tek vezne ile çalışıyorsanız veya para yatırma/çekme süreciniz de otomatik para makinesi ATM kullanma seçeneği yoksa, konuyla ilgili mevcut süreçlerinizi uzun uzun inceleyip değişikliğin türüne karar vermeye çalışmaya gerek yoktur kanımca).

Süreç incelenirken / incelendikten sonra iyileştirmenin büyük (radikal – sıçramalı) ya da küçük (kademeli) olacağı ortaya çıkar (yukardaki örneklere benzer durumlar hariç)

BPI denen İş Süreçlerinin İyileştirilmesi kavramı

* İş Süreçlerinin Yönetilmesini,
* Sürekli iyileştirmeyi

içerir.



Sürekli iyileştirme

süreç performanslarının sürekli izlenmesi ve gerektiğinde iyileştirme yapılması anlamına gelir.
İyileştirme kademeli (küçük) veya sıçramalı (radikal) olabilir.
Sürekli iyileştirme, süreç sürekli olarak küçük küçük iyileştirilecek anlamına gelmez.
Toplam Kalite Yönetimi kademeli ve sıçramalı değişikleri sorgular. TKY sadece kademeli değişiklikler anlamına gelmez.

Sıçramalı iyileşmeyi sağlayan yeniden tasarım, mutlaka yeni bir teknoloji kullanılmasını gerektirmez. Pek çok kaynakta “BPR'ı başlatan, BPR’a yol açan, teknoloji’dir” denmektedir. Çoğunlukjla ve genellikle bu böyle olsa da, teknoloji kullanmadan da süreçte öyle radikal değişiklikler yapılabilir ki müşteri memnuniyeti ve/veya süreç performansı sıçramalı biçimde artabilir.




Filiz Eyüboğlu

filiz.eyuboglu@isbank.net.tr

Pazartesi, Aralık 05, 2005

Başarılı Projelerin Ortak Özellikleri

Başarılı Projelerin Ortak Özellikleri


Harvard Business School tarafından yapılan ve yaklaşık 2 yıl süren bir araştırma [MacCormack01] sonucu başarılı yazılım projelerinin aşağıdaki 4 özelliğe sahip oldukları görülmüştür.

1)Başarılı projeler yinelemeli (iterative) şekilde yazılım geliştirirler. Yazılımın müşteri için anlamlı bir parçası erken bir yayımla(release) teslim edilir ve yazılım teslimi diğer yinelemeler(iterations) ile devam eder. Müşteriden yayımlar(release) sonrası sürekli geri beslenim alınır. Yazılım bir evrim süreci sonucunda oluşur.
2)Yapılan değişiklikler sonrası günlük tümleştirme (daily integration) yapılır. Tümleştirme sonucu yazılımın durumu hakkında bağlanım(regression) testleri sayesinde hızlı bir şekilde geri beslenim alınır.
3)Yazılım geliştirme ekibi deneyimlidir.
4)Projenin başından itibaren yazılım mimarisine ve sistemin birbirinden bağımsız bileşenlerden oluşturulmasına dikkat edilir.

Buna benzer bir araştırmada Bell Labs tarafından yapılmış ve aşağıdaki özellikler saptanmıştır.

1)Yinelemeli(iterative) yazılım geliştirme ve yinelemelerin sonunda müşterinin geri beslenimi.
2)Basit organizasyon yapısı, rol tanımlarının gereksizce çoğaltılmaması.
3)Ekip içi iletişim.

Gördüğünüz gibi bu özellikler yinelemeli (iterative) yazılım süreçlerinin özelliklerine uyuyor. Özellikle çevik yazım süreçlerinin prensipleri ile birebir uygunluk sözkonuşu.

İlk araştırma sonuçlarının birinci maddesinde yinelemeli(iterative) şekilde yazılım geliştirmeden ve yazılımın çalışan bir parçasını erken teslim etmenin(early release) yararından bahsediliyor. Yazılımda çıkan hatalara hangi faktörlerin etki ettiği konusunda yapılan başka bir araştırmada birinci maddeyi doğrular nitelikte. Sonuçlara göre yazılımın %20 lik bölümünü erken teslim eden projenin ,yazılımın %40 'lık bölümünü daha geç teslim eden projeye oranla 10 faktör az hata içerdiği ortaya çıkıyor.

İkinci maddede günlük tümleştirme(daily integration) ve bağlanım(regression) testlerinden bahsediliyor. Hata faktörleri için yapılan araştırma bu pratiğin hataları 13 faktör azalttığını gösteriyor. 1 ve 2 numaralı özelliklerin projelere yüzde 50 ye yakın verimlilik kazandırdığı aynı araştırmada belirtiliyor.

Üçüncü madde ise insan kaynağının önemini vurguluyor. Çevik yazılım süreçleri bireyler ve ekip hayatına verdiği önemle bu özelliğe sahip durumda...

Dördüncü madde ise XP deki yüksek kalite hedefini ve tekrar tasarım(refactoring) ile yazılım tasarımının sürekli iyileştirilmesi pratiğini akla getiririyor

Burada yinelemeli(iteratıve) yazılım süreçlerinin başarılı olmasının nedenlerini kısaca bakalım.

1)Yinelemeli(iterative ) yazılım geliştirme süreçlerini kullanmak daha az risklidir.
2)Riskler önceden tespit edilebilir ve çözülebilir.
3)Proje süresince meydana gelebilecek değişikliklere çabuk tepki verebilir.
4)Projenin durumu hakkında daha fazla bilgi sağlar ve tekrarlar arttıkça tahminler
daha sağlıklı, kesin hale gelir.
5)Hatalar daha çabuk bulunur, kalite seviyesi yüksektir.
6)Sonuçta üretilen yazılım müşteri isteklerini daha iyi şekilde karşılar.
7)Erken ve sürekli süreç iyileştirmesine olanak verir.
8)İletişim ve koordinasyonu zorunlu kılar.
9)"Gördüğüm zaman anlarım" anlayışına ters düşmez.
Müşteriler ne istediklerini anlamak için bazen yazılımı görmeleri gerekir.
10)Tekrar kullanılabilirlik (reuse) için elverişli ortam yaratır.
11)Proje yöneticileri yerinde taktik kararlar alabilirler, insan kaynağı daha yerinde kullanılır.
12)Ekip üyeleri tekrarlar boyunca hatalarından dersler alır ve kendilerini geliştirir.

Standish grubunun 1998 de 23000 projeyi kapsayan yaptığı bir araştırmada [Standish98] projelerin başarısının en çok aşağıdaki 5 faktöre bağlı olduğu sonucuna varıyor. Faktörlerin ne kadar etkili olduğu yanlarında verilmiştir.

Kullanıcı/müşteri katılımı 20
Üst Yönetici desteği 15
Açık iş hedefleri(business objectives) 15
Deneyimli proje yöneticisi 15
Kısa aralıklı kilometre taşları 15

Bu faktörlerle çevik yazılım süreçleri arasında paralellik kurmak gene mümkün. Çevik yazılım süreçlerinde kullanıcı/müşteri yazılım geliştirme ekibinin aktif bir üyesi olarak çalışıyor ve sürekli geri beslenim sağlıyor. Yapılan kısa aralıklı teslimler ve demolar sayesinde üst yönetici desteği yüksek seviyede tutuluyor. Her yineleme plani(iteration plan) ve değişen öncelikler projenin gidişatının iş hedefleri doğrultusunda ilerlemesini sağlıyor. Son olarak kısa aralıklı yayımlar(release) ve sabit süreli yinelemeler(timeboxed iteration) kısa aralıklı kilometre taşları hedefini gerçekleştiriyor.

Kaynak Site: İsmail KIRBAŞ ile Web Sitesi Tasarımı http://www.kirbas.com

Pazar, Aralık 04, 2005

Proje Yönetiminde Kültür Özellikleri

Patron Tipi Yönetim Biçiminin Özellikleri
Aşağıda bu yönetim biçiminin özellikleri görülmektedir. Bu yönetim biçiminde :


aile kültürü egemendir.
egemenlik tek kişinin veya bir ailenin tekelindedir.
organizasyon tek bir kişiye hizmet etmektedir.
güç, merkezdedir.
hedef, güç kazanmaktır.
her fikir ve çözüm sırasıyla denendikten sonra kişisel çözüm bulunmaktadır.
kesin kuralların geçerliği yoktur.
açık önerilere dayanan hızlı karar alma önem taşımaktadır.
herkes tek merkez için çalışmaktadır.
bütün kararlar merkezden verilmektedir.
deneyim, kazananların kaybedenleri yok etmesi ile elde edilmektedir.
teknik ve kuralların varlığı önemli değildir.
sezgilerle ve bütünsel düşünülmektedir.
olası bir çözüme doğru hızla hareket edilerek, uygun olmaması durumunda hemen bir diğerine geçilmektedir (el yordamı).
mantıklı ve adım adım sistematik analizler yapılmamaktadır.
yönetici çabuk sıkılmaktadır.
olaylara bütünsel bakılarak sonuçlar düşünülmektedir.
yazılı iletişim yerine sözlü iletişim yeğlenmektedir.
analitik girdiler, raporlar, dokümanlar ve bütçelerin kullanılarak analiz yapılması yerine tahminler, söylenti ve dedikodular yaygındır.
yönetici, organizasyondaki en bilgili ve her şeyden haberdar kişi olup bunları organizasyonun diğer üyeleri ile paylaşmaz.
ani, deneysel ve planlanmamış çalışma biçimleri vardır.
direkt olarak çözüme ulaşmak istenmektedir.
deneme - yanılma ve modelleme tercih edilmektedir.
otorite sadece yöneticinindir.
değişiklik, kişileri değiştirerek sağlanmaktadır.
kişiler bağlantı elemanlarıdır. Herhangi bir bağlantıda sorun varsa kişiler değiştirilmektedir.
patronun araştırmaya dayalı raporlarla bir işin alınıp alınamayacağına karar vermesi yerine, kendisinin telefonda konuştuğu dostunun fikirleri daha ağır basmaktadır.
yöneticiler sonucun sadece kendi başarıları olduğunu görmek istemektedirler.
karizmatik kişilik sahibi olanlar ve kaynakları yönlendirenler önemlidir..
para, fazlasıyla bir değer olup sonuçların göstergesidir. Başka bir deyişle “her şey para ile ölçülür”.

Bürokratik (Klasik) Tip Yönetim Biçiminin Özellikleri

Aşağıda bürokratik tip yönetim biçiminin özellikleri sıralanmıştır
Burada emir ve kurallar egemendir.
Rol kültürüdür (Organizasyonda herkesin bir rolü vardır).
Egemenlik tepededir. Herkes kendi görev ve sorumluluklarını yerine getirir.
Organizasyonda astlar üstlerine hizmet eder.
Güç, en tepede toplanmıştır.
Gerekçeli önerilere dayanan daha iyi kararlar önemlidir. İnsanın organizasyonda bulunduğu noktaya göre görev ve sorumlulukları vardır. Yaklaşım, rol ve meslek tanımı temeline dayanmakta olup, yönetici otoritenin egemenliğindedir. (Sistem önemsenir)
Kişiler organizasyondan alınan otoriteye göre birbirlerine emir verir ve bulundukları pozisyonun gerektirdiği raporları hazırlarlar.
Kural ve prosedürler geçmişi araştırarak geliştirilir. Her çözüm bu kitaba uydurulur.
Sistemin değişmesi için kuralların ve sorumlulukların yenilenmesi gerekir.
İnsan akıllı sayılır ve her şeyin mantıksal yolla çözülebileceğine inanılır.
Bu yöntem, yaşamın önceden bilindiği durumlarda verimlidir. Bu nedenle yarının dün gibi olacağı kabul edilir (Statik anlayış).
Buradaki düşünce analitik, mantıksal ve sıralıdır (sistemlidir).
İnsan, planlanabilen, zaman ayarı yapılabilen fiziksel bir kaynaktır (“insan kaynağı” deyimi bu kültüre aittir).
Yönetim, karar vermek anlamına gelmez. (Uygulama ve prosedürlere uymak esastır.)
Bu kültürün insanları düzenlidirler ve buna önem verirler.

Proje (Ekip) Tipi Yönetim Biçiminin Özellikleri

Aşağıda proje (ekip) tipi yönetim biçiminin özellikleri görülmektedir
Egemenlik ekiptedir. Bu kültürde ekip çalışması ve yaratıcılık ön plandadır.
Organizasyon, ekip çalışması ile amacına yani sorunun çözümüne yönelik hizmet vermektedir.
Güç, organizasyon bölümlerinin kesişme noktalarında odaklanmaktadır.
Yönetim temel olarak, sorunların çözümündeki süreklilik ve başarı ile ilgilenmektedir.
Yeni fikirler, teknikler ve yaklaşımlar üretilmektedir. Yaratıcılık esastır.
Kaynaklar çözüme uygun biçimde paylaştırılmakta ve harcanmaktadır.
Çözüm için iş gücü, makine ve para sağlanmakta, sonuçlar ve çözümlenen sorunlar karşısında performans yargılanmaktadır.
Ekip çalışması ile sorunlara ve ortak görevlere odaklanılmaktadır.
Patron kültürlü insanları şanslı; bürokratik kültüre sahip insanları ise gerekli ama sıkıcı bulurlar. Bu grubun örnekleri pazarlama elemanları, planlanmacılar ve üretim sorumlularıdır.
Bu kültür problem çözücü ve yaratıcıdır. Dolayısıyla sorunlar en iyi şekilde çözümlenmektedir.
Sorun çözme becerisi işbirliği ve ekip çalışmasına dayanmaktadır.
Kişisel gelişim özendirilmektedir.
Kurallara uymak, karşılıklı anlaşmaya dönüşmektedir.
Konuşma, tartışma ve görüş alışverişi vardır.
Problem çözme, problemin tanımlanması ile başlamaktadır.
Farklılık yaratmaktan çok sorun çözmek esastır.
İnsanı kaynak değil, kaynak yaratan sayar.
İnsanın geleceğini yarattığını kabul eder.
İnsan ekibi, ekip insanı seçer (kabul eder).
Bilgi ve uzmanlığa saygı duyarlar.
Bu kültürde yönetmek için yönetilenin saygısını kazanmak, emir vermek için ikna etmek gerekir. Görüşme, tartışma, gerekçe, tutanak, rapor vardır ve yazılanın okunacağı düşünülür.
Kazanmak için ikna etmek (güçlü gerekçe) gerekir. Önce sorun tanımlanmalı, grup bu tanımı ve sorunun önceliğini kabul etmelidir.
Bu kültürde, heterojen bir grup ortak neden, görev veya sorun ile bütünleşerek homojen hale gelmelidir.
Sorunu gruba kabul ettirmek (mal etmek) için önce grubun saygısını kazanmak gerekir.
Bu gruptakilere göre saygınlık gruba ithal edilir : Başka yerde oluşturulur ve uzmanlık gezicidir. İnsan bir örgütün değil dünyanındır.
Burada karizma değil, uzmanın kredibilitesi önemlidir.
Sorunu belirlemek için örgüt şemasına onun adıyla bir yer (kutu) açılır, buna kaynak verilir.
İstikrar ve kesinlik bu kültür sahibini sıkar. Sorun çözücüdürler.
Patron kültürünün dinamizmine akıl olurlar, uzmanlık ve profesyonelizme saygı duyarlar; profesyonel açıdan (hiyerarşi değil) kendilerini geliştirmeye dönüktürler, krizlerde kararsız kalırlar. Bu nokta çalışanın ücret taleplerini azaltıcı etki yapmaktadır.
Görev değil, amaç tanımıyla ilgilenirler.
Kendisini aldığı sonuçlarla değerlendirir. Patron Kültüründe ise roldeki performansa bakılır ve başarısının kişilerle ilişkisi kurulmaz.
Sonuca göre ödeme, ekip görevi, belirli durum ve sorun çözümü gibi konulara duyarlıdır.
Çalışma alanları : Danışmanlık, AG ekipleri, medya kuruluşları ve artarak çok büyük şirketlerin dorukları


Bireyci Tip Yönetim Biçiminin Özellikleri

Aşağıda bireyci tip yönetim biçiminin özellikleri sıralanmıştır

Egemenlik bireydedir. Herkes kendi yaşamından sorumludur. Organizasyonlar bireye hizmet eder.
Güç bireydedir.
Bu kültür anlayışındaki insanlar profesyonellerdir.
Bu kültürde kişisel etkinlikle çözüm bulunur; kurallar egemen değildir.
Bu yönetim kendisini tüm genellemelerin dışında tutar.
Bu kültürü sınıf olarak tanımlamak zor ve yanlıştır.
Bu kültüre sahip olanların kimseden öğrenecek bir şeyleri yoktur; onlara sadece hayatın kendisi bir şeyler öğretebilir.
Deneyimlere dayalı öğrenme yeğlenir.
Bir konuda öğrenecek bir şeyin kalmaması halinde projenin idarecisi bile işi bırakır.
Bu kültüre sahip insanlar kendilerini organizasyonun parçası olarak görmezler.
Bu özellikle bireyci kültür, kişisel özgürlüğü ön plana çıkarır. Burada İnsanlara saygı vardır
Yönetilmesi zor insanlardır.
Kişisel olarak değişiklik yapmak isterler.
Kişisel bağımsızlığa önem verirler.
Bu kişilerin motivasyonları, amaçları doğrultusunda sağlanır.


Proje Yönetim Sistemi ve ekip kültürünün özellikleri aşağıda sıralanmıştır

Her aşamada ekip çalışması vardır.
Organizasyon, proje hedefleri doğrultusunda çalışmaktadır.
Güç, organizasyon bölümlerinin kesişme noktalarında odaklanmaktadır.
Yeni fikirler, teknikler ve yaklaşımlar üretilirken ön tasarım ve tasarım aşamalarında yaratıcılık çok ağır basmaktadır.
Çözüm için kaynaklar, proje çalışanları arasında paylaştırılmaktadır.
Tasarım ve karar verilen tasarım alternatifi doğrultusunda kaynaklar sağlanmakta, veri analizleri ve stratejiler belirlenerek uygulanmakta ve sonuçlar üzerinde verim analizleri yapılmaktadır.
Sistemin ihtiyacı, deneyimli ve bilgili ekip elemanları ile ileri teknoloji ekipmanları olduğundan, sistem pahalı, hatta lüks niteliktedir.
Sorun çözümü yaratıcı düşünce ve optimum sonuçlara ulaşmayı gerektirmektedir.
Organizasyon kademelerinde, üst yönetim, astların düşünce ve çözüm önerilerine açıktır.
Kurallar, uyulması gereken zorunluklar değil, çözüme ulaşmak için karşılıklı anlaşma sağlayan düzenlemelerdir.
Proje hedeflerine ulaşmak için önce projenin ve proje evrelerinin tanımlanması gerekmektedir.
Proje çözümleri ile ilgili alternatifler, projenin her evresinde güncellenmekte ve karşılaştırmalı analizler yapılmaktadır.
Projede çözüm seçenekleri kullanılmasının amacı, hedefe ulaşmayı karmaşıklaştırmak değil, optimum çözümü bulmaktır.
· Çalışanların sabit görevleri yoktur. Görevler, proje özelliklerine, çözüm yollarına ve hedeflere göre tanımlanmaktadır.


Bu Çalışma Prof.Dr. D.Sorguç-Dr. M.Kuruoğlu tarafından yazılan , “İnşaat İşletmelerinde Çağdaş yönetim ve değişim Modeli” isimli İstanbul Ticaret Odası 2001-37 sayılı yayınından alınmıştır.

Yazılım Projelerinde Rol Dağılımı

Yazılım Projelerinde Rol Dağılımı


Bu yazımda küçük-orta ölçekli bir proje ekibindeki rollere ve bu rollerin sorumluluk alanlarına değinmeye çalışacağım.

Rolleri aşağıdaki şekilde kısaca özetleyebiliriz.

1) Proje yöneticisi
2) Analist/Çözümleyici
3) Mimar- teknik lider
4) Yazılım geliştirici
5) Test/Kalite Kontrol

1) Proje yöneticisi

Proje yöneticisinin görevi projenin önüne çıkan engelleri ortadan kaldırmak ve ekibin verimli çalışması, projenin zamanında teslimi için gerekli ortamı sağlamak, önlemleri almaktır. Örneğin teknik bir konuda ekibe dışardan yardım gerekiyorsa bu yardımı sağlamak, bir danışman tutmak proje yöneticisinin işidir. Ekibin kullandığı bilgisayar, yazılım geliştirme ortamındaki sorunların hızlı şekilde çözülmesini saglamak gene proje yöneticisinin işlevine örnek gösterilebilir. Proje yöneticisi aynı zamanda kritik kararları almakta da öncu rol oynar. Yazılımda kritik bir hata varsa yayım(release) tarihinin ertelenmesi buna örnek gösterilebilir. Bu örneklerden anlaşılabileceği üzere herşeyin yolunda gittiği bir projede proje yöneticisinin işlevi çok görünür değildir.

Proje yöneticisinin görevi yapılacak işleri küçük parçalara ayırıp daha sonra bunların zamanında bitirildiğini takip etmek değildir(Micromanagement). Bu tür yönetim tarzının günümüzde artık yeri yoktur. Yönetici ekibine güvenmeli, ekipe kararlar alabilmesi ve durumlara adapte olabilmesi için gerekli yetkiyi tanımalıdır (Empowerement of the team).


2) Analist/Çözümleyici

Çözümleyicinin görevi kullanıcı/müşteri grubuyla görüşerek iş gereksinimlerini (business requirements) i almaktır. Çözümleyiciler kullanıcı/müşteri ile ekibin diğer rolleri arasında(proxy) görev yapar. Ekip içinde müşteriyi çözümleyiciler temsil eder. Çözümleyici müşteri ile iletişim içindedir yazılım geliştiricilerin gereksinimler hakkında sordukları soruları en hızlı şekilde cevaplamaya çalışır. Cevaplayamadığı soruların cevabını müşteriye giderek bulur. Müşteriden aldığı bilgileri yazılım geliştiricilerin anlayabileceği formata çevirmek gene çözümleyicinin işidir. Çözümleyicinin kullandığı format kullanılan sürece bağlı olarak değişebilir. Örneğin XP de bu format hikaye kartları, RUP gibi bir süreçte kullanım senaryosu(use case dokümani) , Şelale gibi bir süreçte ise uzun bir doküman şeklinde olabilir.

Günümüzde Çözümleyici/ tasarımcı (Analist/Tasarımcı) gibi tanımlamalara rastlamak mümkün. Böyle bir rol tanımı bence çok büyük bir hata olur. Çözümleyiciler yapılan işin alan(domain) bilgisine sahip olmalidir ve yapılan projeyi kullanıcı/müşteri bakış açısından görebilen bir kafa yapısı ve yetenek gerektirir. Tasarım ise uygulamaya , yazılan koda yakın olmayı ve yuksek teknik bilgi seviyesi gerektirir. Uygulamanın tasarımından çözümleyici rolü sorumlu olmamalıdır.

Çözümleyici grubu proje ekibi küçükse QA/Test, Proje yöneticisi gibi rolleri de üstüne alabilir fakat Tasarım,Teknik liderlik, Yazılım geliştirici gibi roller başka ekip uyeleri tarafından yerine getirilmelidir.

3) Mimar- teknik lider

Yazılım mimarisi kısaca yazılımı oluşturan önemli/büyük bileşenler ve bunların organizasyonu, birbirleri ile iletişimleri ile ilgilidir. Bu mimari üzerine yazılım iş gereksinimleri tatmin edecek şekilde bina edilir. Mimarı aynı zamanda operasyonel performans gibi gereksinimleri de tatmin etmelidir. Mimar/teknik lider tıpkı diğer yazılım geliştiriciler gibi kod yazar fakat ayni zamanda genel mimarı ile ilgili kararları almaktan, tasarım çalışmalarında liderlik yapmaktan sorumludur. Mimar/teknik lider teknik işlerin zamanında ilerlemesinden proje yöneticisine karşı sorumludur. Bu açılardan değerlendirildiğinde mimar/teknik lideri diğer yazılım geliştiriclere göre yüksek teknik bilgiye sahip ve bu işlerden yöneticiye karşı sorumlu bir rol olarak görmek mümkündür.

4)Yazılım geliştirici

Yazılım geliştirici kodun tasarlanması ve yazılmasından sorumludur. Burada dikkat edileceği üzere tasarım ve kodun yazılmasını birbirinden ayırıp ayrı rollere yüklemedim. Bunun nedeni kodun tasarımı hazırlayan insan tarafından yazılması gerektiğine inanmamdan kaynaklanıyor. Günümüzde her ne kadar modelleme dilleri geçerlilik kazanmış olursa olsun, kodun yazımı sırasında her zaman tasarımda öngörülemeyen noktalar ortaya çıkacaktir. Diğer bir deyişle kodlama tasarımı etkileyecektir. Tasarım yazılım geliştiricilerin ve mimarın içinde bulunduğu bir ekip aktivitesi haline getirilebilir fakat tasarımcı , programcı gibi bir ayrıma gidilmemelidir.
Bu tür ayrımlara gidilmesinin kaynağında programcılığı ucuz bir kaynak haline getirme çabaları olduğunu düşünüyorum. Tasarımcı ile programcının ayrı rollere bölündüğü durumlarda iyi bir tasarım olduktan sonra düşük seviyede bir programcıda olsa bu tasarımı koda çevirmek kolay gibi çok ama çok yanlış bir mantığa rastlamak mümkün Diğer bir nokta tasarımcılarla ilgili. Tasarım yapılırken yüksek teknik bilgiye sahip olmak gerekli fakat tasarımcı ile programcı rolleri birbirinden ayrılırsa tasarımcı zamanla teknik bilgi seviyesini kaybedecek ve kaliteli tasarımlar üretmekten uzaklaşacaktir.

Projenin gereksinimlerine bağlı olarak yazılım geliştiriciler UI, Veritabani, Uygulama,Rapor geliştiricisi gibi rollere ayrılabilir.

5)Test/Kalite Kontrol

Test/Kalite Kontrol rolü kullanıcının bakış açısıyla yazılımı test etmekten sorumludur. Küçük projelerde bu rolü Analistler üstlenebilir fakat Test/Kalite Kontrol rolü hiçbir şekilde yazılımı geliştiren insanlara yaptırılmamalıdır. Kodun o kodu yazan insan tarafından test edilmemesi ve kullanıcı bakış açısıyla test edilmesi çok önemlidir. Yazılım geliştirici
yazılımı bu bakış açısından görmekte zorlanacaktir. Test/Kalite Kontrol test senaryolarını hazırlar gerekirse Rational Robot, Fit gibi programlar yardımıyla bizzat kod yazarak otomatik fonksiyonel testleri gerçekleştirir. Kullanici kabul testlerini koordine eder.

Türkiye de çoğu projede QA/Test rolünün es geçildiğini söylemek yalan olmaz. Bu testleri son kullanıcıya yaptırmak sanırım en çok rastlanılan durumlardan biri. Bir diğer problemde zaman darlığına giren projelerin çoğunun test aşamalarından zaman kısmaları. Sonuç olarak hatalarla dolu yazılımlarla karşılaşıyoruz.

Test/Kalite Kontrol rolünü kısmen teknik bilgi gerektiren(programcının yapabileceği hataları tahmin etmek açısından faydalı olacaktir) ve iş gereksinimleri anlayan, kullanıcı/müşteri gibi düşünebilen bir rol olarak görüyorum ve en az yazılım geliştiriciler kadar önemli olduğunu düşünüyorum. Umarım verilen iş ilanlarında gelecekte Test/Kalite Kontrol gibi ayrımları daha fazla görebiliriz.

Bu yazımda küçük/orta ölçekli bir projede çekirdek rol tanımları nasıl olmalı açıklamaya çalıştım. Proje büyüdükçe roller özelleşecektir ve yeni rol tanımları gerekecektir. Bunlara örnek vermek gerekirse

Kullanıcı arayüzü(UI) tasarımcısı ,
Kullanılabilirlik (usability) testcisi
Teknik yazar (dokümantasyon, yardım dosyaları),

Kurulum/Yayım mühendisı( kurulum işlemleri, konfigürasyon/versiyon yönetimi)
Rapor tasarımcısı
Sistem mimarı (hardware mimarisi)

gibi yeni roller eklenebilir.

Yorum ve eleştirilerinizi lütfen bana iletiniz.

Yazar:

Cenk Civici
Yazılım mühendisı

Kaynak Site: İsmail KIRBAŞ ile Web Sitesi Tasarımı Sitesi

Perşembe, Aralık 01, 2005

Projeniz Alabora Olmasın!!

Projeniz Alabora Olmasin !


TARIHDEN DERS ALMAK
Tarihde birçok tasarım ve proje işleyiş hatasına rastlamak mümkün. Bunlardan bir tanesi hakkında bir yazı yazmıştım. Yazım SA80 tüfekleri ile ilgili idi. Başka örnekler de var ders alabileceğimiz: C5 arabaları, Milenyum Köprüsü, Denver Uluslararası Havalimani, Challenger Uzak Gemisi, Zeplin Balonları v.b. Bütün bu tarihi, gerçek olaylar, inanılmaz dersleri saklıyor içinde. Maalesef bu derslerden birçoğumuz payımızı alamadık çünkü halen birçok projede, bu hataları tekrar ediyoruz. Hani şu "Eğer tarihden ders alınsa idi..." hikayesi.

Bu tarihsel tasarım hataları içinde beni en çok etkileyen ve benim en çok örneğini verdiğim olay ise Vasa Savaş Gemisi. İki hafta önceki yazımda bu konuyu yazacağıma dair söz vermiştim, işte size Vasa Savaş Gemisı:

VASA'NIN ACIKLI HİKAYESİ
İsveç'de bir yıl içinde 17 tane "bayrak günü" vardır. Bayrak günleri, tatil değildir fakat eskiden, bayrak günlerinde, İsveç bayrağı sallandırmayanlar, cezaya çarptırılıyormus. Artık böyle bir ceza uygulaması olmamasına rağmen, yine de "bayrak günlerinde" İsveçliler, bayraklarını evlerinin balkonlarından, işyerlerindeki bayrak direklerinden sallandırıyorlar. İşte bu bayrak günlerinden biri de 6 Kasım. Bu güne "Yüce Gustav Adolf Günü" deniliyor.

Gustav Adolf, "yüce" ünvanına ulaşmış tek kral İsveç tarihinde. Bu kralin yüceliği, yaptığı/kazandığı savaşlardan ve savaşlardaki akılcı tatiklerinden geliyor. O zamana kadar geleneksel tatikleri yürüten İsveç krallarından farkı, savaş meydanlarına mobiliteyi yani taşınabilirliği getirmesi. Mobiliteyi yanlızca karada görmemiş Adolf. Aynı zamanda denizlerde de üstünlük sağlamak istemis. Zaten bu nedenle de, İsveç tarihinin en büyük ve en pahalı gemicilik projesini başlatmış 1625’de. Bu projenin adı VASA


İNSAAT BAŞLIYOR
Gustav Adolf, 16 Ocak 1625'de, gemicilik konusunda ustalıkları ile ünlü Hollandalı gemi mühendisleri Henrik ve Arend Hybertsson ile 4 adet gemi yapımı için bir sözleşme imzalar. Bu sözleşmeye göre, Hybertsson kardeşler, 4 yıl içinde ikisi 33 metre ve diğer ikisi 41 metre olan 4 tane gemiyi Kral Adolf'a teslim edeceklerdi.

O dönemde gemiyi inşa eden atölyeler, kendi finansmanını kendi sağlamak zorundalardı. Para, ürün teslimatı sırasında alınıyordu. Bu iş, bir kral için bile olsa, finansman bulmak tamamen atölyeye kalmıştı. Hybertsson kardeşler, bu proje için finansman bulmakta zorlandırlar. Gustav Adolf ve üst düzey yetkililerine ulaşmakta neredeyse imkansızdı çünkü Gustav, bir savaş meydanından diğerine koşuyordu. Hybertsson kardeşler, finansman işini neredeyse bir yıl sonra tamamlayabildiler.

1625 yılının Eylül ayında Kral Adolf, 10 tane savaş gemisini, şiddetli bir fırtınada kaybetmesi sonuçu, Hybertsson kardeşler ile temasa geçip, iki küçük (33 metre) geminin ilk etapda tamamlanmasını ve kaybedilen gemilerin yerine geçmesini istedi. Bu zaten çok dar olan proje bitiş sürecini zorlaştırmış oldu.

1626 yılının ilk aylarında, gemi inşaatı başladı. Hybertsson kardeşler, ilk önce küçük 33 metrelik geminin inşaatına başladı. İlk yapılan işlem, 33 metrelik bir ağaç bulup, kesmekti. Proje basit ve geleneksel bir gemi projesi idi. O dönemde, savaş gemileri, düz tabanlı, bir açık bir tane de kapalı silah güvertesinden oluşuyordu. İşlem, neredeyse gunumuzun fabrikasyon uretimi gibiydi. Hemen hemen bütün gemiler birbirinin kopyasiydi ve bu nedenle birçok gemi yapımcısı, plan, çizim gibi araçlara gerek duymuyorlardı. Tek güvendikleri, yillarin onlara verdigi "tecrübe" idi.

KRAL'IN SONU GELMEZ İSTEKLERİ


Fakat bu proje herhangi bir proje değildi. Tecrübe, bu işi bitirmek için yetmeyecekti çünkü Kral, gönderdiği bir başka mektupta, küçük geminin 33 metre değil 36.5 metre olmasını istedi. O dönemde, kesilen ağaçlar, geminin boyuna uygun olarak kesiliyordu. Kral'in bu emri, gemi projesinde çalışanların tepkisine neden oldu. Halbuki, bu ikinci mektup, yalnızca gelecekteki isteklerin bir işareti idi çünkü Kral, o dönemde Danimarkalıların 2 kapalı, 1 açık silah güverteli çok büyük bir gemi yaptıklarına dair bir dedikodu üzerine Hybertsson kardeşlere yeni bir mektup gönderdi. Bu mektupda Kral, yapılacak geminin 42 metre olmasını ve ikinci kapalı silah güvertesinin eklenmesini istedi.

O döneme kadar, 2 kapalı, 1 açık silah güvertesi duyulmuş ya da yapılmış bir şey değildi. Birinci 36.5 metre isteği üzerine eklenen yamalar ile birlikte yeni istek ile birlikte tabana 4. yama eklendi. Projede çalışan hiç kimsenin Kral'a "hayır, olmaz" deme gibi bir cesareti yoktu.

İstekler bu kadar ile sona ermedi. Kral'in uzunluk ile ilgili isteklerine, gemide bulunacak gülle, top ve küçük silah sayısındaki artışlar da eklendi. Kral, orjinal planda yer alan büyük silahların sayısını iki katına çıkardı. 30 olan sayı, 60'a çıktı. Bu silahların her birinin ağırlığı 1.5 ton idi ve bunun üzerine birçok orta ve küçük silah ve ayrıca yine o dönemde yeni bir teknoloji olan kiremit fırın eklenince, geminin ağırlığı, geminin iskeletinin kaldırabileceğinden daha ağır bir hale geldi.

Bütün bunların üzerine Kral, geminin dış görünümünün şaşalı olmasını da istedi. İşlemeler, figürler, kabartmalar ve kaplamalar. Zaten çok pahalı bir proje haline gelen Vasa projesi bütçesine, yeni bir yük daha katılmış oldu.

MİMARIN VEFATI
Bütün bunlar gelişme gösterirken, bir anda hic beklenmeyen gerçekleşti. Proje müdürü ve baş mimar Henrik Hybertsson, uzun süreli hastalığının sonucunda hayatını kaybetti. Bu proje için yazılmış ya da çizilmiş hiçbir planın olmaması, birçok fikrin ve fonksiyon tanımlarının Henrik'in beyninin, düşüncelerinin içinde saklı olması, Henrik'in ölümü ile birlikte, projeyi kaos içine sürükledi.

Temmuz 1628'in başlarında, gemi tamamlandı. Geminin denize sürülmeden önce test edilmesi gerektiği düşünüldü. Bu testleri seyretmeleri için İsveç Ordu Amiral'i ve ayrica geminin kaptanı davet edildi. Yapılan test kısa ve çok basitti. Geminin güvertesine 30 kişi çıktı ve bir uçtan diğer uca, bir kenardan diğer kenara 15-20 dakika boyunca koşmaya başladılar. Test sonucu iç karartıcı idi. 30 kişinin çılgınca koşmaları sonucu, gemi neredeyse alabora olmak üzere iken, Amiral, testlerin durdurulmasını ve geminin bir an önce denize indirilmesini emir verdi. Test sonuçlarından Kral Adolf'un haberi bile olmadı.

İLK VE SON YOLCULUK
10 Ağustos 1628 günü, Majesteleri İsveç Deniz Harp Ordusunun yepyeni gemisi olan Vasa, hayatının ilk seferini yapması için denize indirildi. Yüzlerce kisi, limanda sevinç çığlıkları ile uğurladı gemiyi. Aynı sevinç çığlıkları, gemi güvertesindeki 150 kişiden de geliyordu. Gemi, 1.5 kilometre kadar yol aldı ve küçük bir rüzgar yardımı ile alabora oldu. Bu, yalnızca, İsveç tarihinin o zamana kadar ki en pahalı savaş gemisinin değil aynı zamanda güvertede bulunan 50 kişinin de son yolculuğu oldu.

NE OLDU? VE ALINACAK DERSLER!
Bütün bu yazdıklarımın bizimle ne alakası var? Eğer yazdıklarımı günlük iş hayatınızdaki projelerle ilişkisini kurabiliyorsanız, göreceksiniz ki 1600'lu yıllarda yapılmış olan proje hataları, günümüzdeki projelerde yapılan hatalardan çok farklı değil.

İşte VASA'da ve bizim gorev aldığımız projelerde ortaya çıkan ortak sorunlar:

1- Proje süresindeki baskı

Kral, fırtınada kaybettiği gemilerin yerini alması için yaptığı baskı, günümüzdeki projelerde rastladığımız müşterileri baskılarından çok farklı mı sizce? Birçok proje, plansız bir şekilde başladığından, proje süreç seması çıkarılmadığından, müşterinin baskıları ile tamamen test edilmeden, fonksiyonlar tamamen işlevsel olmadan bitmek ya da teslim edilmek zorunda kalmıyor mu? Halbuki bu sorunu, proje süreç şeması, proje planı ile çözmek gerekiyor.

2- Projenin özelliklerinde değişim

Müşteriler, size verdikleri projenin ana nedenini tamamen belirlememesi, rakip şirketin ürünleri, teknolojideki değişiklikler, kullanıcı gereksinimindeki değişiklikler ve sırf "iyi olur" inancı ile oluşan yeni istekler nedeniyle belirli özelliklerle başlayan projenin boyutları değişmekte. Bütün bunlar hem projenin gelişimine hem de sonuca etki etmektedir. Bütün bunların üstesinden gelebilmek için projenin başlangıç aşamasında iyi şekilde planlanması ve plana sağdık kalınması gerekmektedir. Sırf "iyi olur" diye, ürün üzerine fonksiyon eklemek hem ürün için hem de projenin gidisadi için tehlike oluşturmaktadır. Ürüne eklenecek her yeni özellik, yeni bir proje olarak değerlendirilmeli, gerektiğinde müşteriye "Hayır" denebilmesi gereklidir. Eğer özellikler değişebiliyorsa, planda değişebilir. Bunu unutmamak gerekiyor.

3- Detaylı Plan Eksikliği

Vasa projesinin başlangıcı, Hybertsson kardeşler için herhangi, alışagelmiş, geleneksel bir projenin ötesinde değildi. Bu nedenle, plan yapılmadı ve proje karmaşık bir hale gelince, proje plan eksikliğinin yarattığı sorunlar yaşanmaya başladı. Aldığınız proje, çok basit bir proje olsa bile, plan yapmalısınız. Bu plan içinde en önemli kişim özelliklerin, sürecin ve yükümlülüklerin belirlenmesi olmalıdır. Ayrıca, proje plani, proje çalışanlarından birinin değişmesi sonucunda çıkabilecek herhangi bir problemi, sorunsuz bir şekilde çözmenizi sağlayacaktir.

4- Teknolojinin Sınırlarını Bilmemek

Birçok proje, teknolojinin sınırlarını ve seviyesini iyi tespit edemeyen proje müdürleri ve müşteriler yüzünden başarısızlığa uğramaktadır. Bu tip problemleri önlemenin tek yolu, kullandığımız teknolojinin anlamını kavrayabilmek ve sınırlarını tespit edebilmekten geçmektedir. Ayrıca, bütün bunları müşteriye iletilmesi bizim görevimizdir.

5- Kullanılabilirlik Testlerinin Yetersizliği

Bir proje, test edilmeden piyasaya arz edilirse, çıkacak sorunlar, projenin kendisinden bile büyük olabilir. Yapılan bir araştırmaya göre, bir projenin bütçesinin yüzde 80’i, ürün piyasaya çıktıktan sonra, yapılan hataların tamiri için harcanmakta. Halbuki yapılacak kullanılabilirlik testleri, ileride ortaya çıkabilecek problemlerin, daha önceden tespitini sağlar ki bu hem bizim iyi bir ürün çıkarmamızı hem de bu ürünü kullanıcak kişilerin, ürünü beğenip, tercih etmelerini sağlayacaktir.

Birçok tarihi projenin aşamaları, bizim bugün uyguladığımız projelerdeki aşamalarından çok farklı değil. Amac, tarihde yapılan hataların tekrarlanmaması.

Kaynak : http://www.unbf.ca/altiustu/arsiv/2005/06/projeniz_alabor.php sayfasından alınarak yayınlanıştır.


İş Hayatında Entegrasyon Kavramı

Yasin Altaş
Tekofaks
yasinaltas@yahoo.com
http://www.tekofaks.com.tr



İş Hayatında Entegrasyon Kavramı


Organizasyon açısından entegrasyon, prosesler arasında daha sıkı bir koordinasyon yapısı kurarak işletme fonksiyonlarını biraraya getiren ve bilgi araçlarının etkin kullanımını sağlayan bir kavramdır. Bu sadece bir parçanın değil, satınalmadan stok kontrole, talep tahminlerinden, muhasebe kayıtlarını oluşturmaya kadar tüm işletme fonksiyonları arasında elektronik bir bağ kurulması anlamındadır. Temel hedef, tüm kullanıcıların ulaşabileceği tüm işletme süreçlerinin ve karar süreçlerinin üzerinde bulunduğu bir veritabanı oluşturabilmektir. Eğer organizasyon birbirinden bağımsız ve kendi stratejileri ile performans ölçütleri olan fonksiyonlar olmaktan öteye gidemiyorsa entegrasyondan söz etmek mümkün olmayacaktır.

Günümüzde entegrasyonu zorunlu kılan nedenler şu şekilde sıralanabilir:

Global Pazarlar

Global pazarlara ulaşabilmek için uluslararası firmalar bölgesel veya lider firmalarla işbirliği yapmaktadırlar. Entegrasyon, coğrafi engellerin etkisini azaltarak operasyonların etkinliğini arttırır.

Ürün ve Arz Zincirinin Kompleks Yapısı

Günümüzde mal ve hizmetler online ortamda işlem görebilmektedir, bu ise yüksek derecede otomasyon ve entegrasyon gereksinimi yaratmaktadır.

Ayni zamanda arz zinciri yapısının karmaşıklığı ve sinerji olanakları yaratabilme şansı organizasyon sınırları dışında entegrasyon gereksinimini güçlendirmektedir.

Dış Kaynak Kullanımının Artışı

Günümüzde çoğu firma özellikle maliyetlerini düşürmek için dış kaynak kullanımı yolunu seçmektedirler. Bu aşamada dış kaynak kullanımında hizmet sağlayıcı etkili bir biçimde kontrol etmek entegre bir süreç gerektirir.

Pazara Ulaşma Hızı

Şirketler ürün ve hizmetlerini pazara rakiplerinden daha hızlı sunabilmek için özellikle tedarikçileriyle işbirliğini geliştirmelidir. Entegrasyon bu alanda işbirliğinin temelini oluşturur.

Stok Seviyelerini Azaltma

Geleneksel iş modelleri gerçek arz ve talebi tahmin etmekte yetersiz kaldığından, şirketler önemli miktarda güvenlik stoku tutmak zorunda kalmaktaydı. Şirketler hizmet seviyelerini geliştirirken stoklarını azaltmak için partnerleriyle işbirliğini geliştirmeli ve enformasyon akışını koordine etmelidir.

İşletme süreçlerinin bütünleştirilmesi sonucu organizasyon içerisindeki bilgilerin işlenme ve kullanılma yöntemleri değiştiğinden, süreçlerin hızlanması ve daha güvenilir hale gelmesi sözkonusu olacaktır. Bu durum rekabet avantajı sağlayacağından bütünleşik sisteme geçme kararı yöneticiler açısından stratejik öneme sahip bir yatırım kararıdır.

Tümü ile entegre bir işletim sisteminin faydalarından biri de, yazılımın yeteneğine bağlı olarak işletmeye kayıpları ve atıl kaynakları azaltabilme ve verimliliği arttırma olanağı sunabilmesidir. Entegre bir işletme sistemi, sadece homojen iş fonksiyonları içerisinde bağ kurmakla kalmaz ayni zamanda birbirinden bağıŭsız fonksiyonları da birbirine bağlar. Bunun sonucu olarak, her bir bağımsız fonksiyon tarafından üretilen bilgiler tüm kullanıcılar tarafından sistemde rahatlıkla bulunabilir ve kullanılabilir. Bu da işletmeyi bir bütün olarak daha üst düzey bir koordinasyon, hizmet kalitesi ve performans ölçülerine taşır.

Ancak bu faydalarına karşın işletmelerde entegrasyonu zorlaştıran etmenler de vardır. Bunlar:

1.Organizasyonel Yapı

Günümüzde çoğu organizasyonel yapı, fonksiyonel bölümlere göre yapılandırılmış yetki ve sorumluluklar içermektedir. Bu geleneksel yapı, çalışanları da kendi fonksiyonel yapısının özgül iş ve sorumlulukları ile ilgili kılar. Sonuç olarak; her bölüm kendi fonksiyonel başarısını hedefler.

Başarılı bir entegrasyon ise bundan daha fazlasını gerektirir, yöneticilerin ve çalışanların fonksiyonel sınırlarının ötesine bakabilmelerini ve değerlendirebilmelerini.

2.Enformasyon Teknolojisi

Enformasyon teknolojisi başarılı bir entegrasyon için anahtar faktördür. Ancak organizasyonlarda enformasyon teknolojisi uygulamaları organizasyonel düzene göre düzenlenmiştir. Çoğu veritabanı sistemi departmanların özgül fonksiyonları için yapılandırılmıştır. Veri paylaşımı gereksinimi organizasyonlarda varolan enformasyon teknolojilerinin yeniden gözden geçirilmesini gerekli kılar.

3.Ölçüm ve Değerlendirme Sistemleri

Enformasyon teknolojisine benzer olarak geleneksel ölçüm ve değerlendirme sistemleri de fonksiyonel yapıyı temel almaktadır. Ölçüm ve değerlendirme sistemlerinin büyük bölümü organizasyonel yapının aynasıdır. Entegre bir yapının oluşturulması yeni bir performans değerlendirme sisteminin oluşturulmasını zorunlu kılar. Oluşturulacak performans yönetim sistemi, yöneticilerin fonksiyonel bakış açısı yerine prosese odaklanmalarını sağlayacak nitelikte olmalıdır.