1

GTAG®

Global Teknoloji Denetim Rehberi

UMUÇ – Uygulama Rehberi

Bilgi Teknolojileri (BT)

PROJELERİ

DENETİMİ

IIA – Uluslararası İç Denetçiler

Enstitüsü

2

Global Teknoloji Denetim Rehberi (GTAG)

BT yönetimi, kontrolü ve güvenliği ile ilgili sorunları ele almak amacıyla açık ve basit bir

mesleki dille yazılan GTAG dizileri, hem teknolojiyle ilgili farklı riskler hem de tavsiye

edilen uygulamalar konusunda iç denetim yöneticileri için hazır başvuru kaynağı görevini

görmektedirler.

Bilgi Teknolojisi Kontrolleri:

Tartışılan konular arasında BT

kontrolü kavramları, BT

kontrollerinin önemi, etkin BT

kontrolleri sağlamaya yönelik

kurumsal roller ve sorumluluklar ve

risk analizi ve tekniklerinin izlenmesi

bulunmaktadır.

Bilgi Teknolojisinin Dış Kaynaklardan

Elde Edilmesi: Doğru BT dış kaynak

sağlayıcısının nasıl seçileceğini ve

müşteri ve hizmet sağlayıcısı açısından

kilit dış kaynak kontrol mülahazalarının

nasıl ele alınacağını tartışmaktadır.

Değişiklik ve Yama Yönetimi

Kontrolleri:

Değişiklik kaynaklarını ve bunların

işletme hedefleri üzerindeki olası

etkilerini, ayrıca değişiklik ve yama

yönetimi kontrollerinin BT risklerini

ve masraflarını yönetmeye nasıl

yardımcı olduğunu ve uygulamada

neyin işe yarayıp neyin yaramadığını

tartışmaktadır.

Uygulama Kontrollerinin Denetimi:

Uygulama kontrolü kavramını ve genel

kontrollerle ilişkisini, ayrıca risk-esaslı bir

uygulama kontrolü incelemesinin nasıl ele

alınacağını tartışmaktadır.

Sürekli Denetim: Günümüzün iç

denetim çevresinde sürekli denetimin

rolünü; sürekli denetim, sürekli

izleme ve sürekli güvence arasındaki

ilişkileri ve sürekli denetim

faaliyetinin yürütülmesi ve

uygulanmasını ele almaktadır.

Kimlik ve Erişim Yönetimi: Kimlik ve

erişim yönetimini (IAM) çevreleyen kilit

kavramları, IAM sürecine ilişkin riskleri,

IAM süreçlerinin nasıl denetleneceği

üzerine detaylı bilgiler ve denetçiler için

bir kontrol listesi örneği içermektedir.

BT Denetiminin Yönetimi: BT’yle

ilgili riskleri tartışmakta, ayrıca BT

denetim evrenini ve BT denetim

sürecini nasıl yürütmek ve yönetmek

gerektiğini açıklamaktadır.

İş Sürekliliği Yönetimi: İş sürekliliği

yönetimini (BCM) tanımlamakta, işletme

risklerini tartışmakta, ayrıca BCM

programı gerekliliklerinin ayrıntılı bir

tartışmasına yer vermektedir.

Mahremiyet Risklerinin Yönetimi

ve Denetimi: Global mahremiyet

ilkelerini ve çerçevelerini,

mahremiyet risk modellerini ve

kontrollerini, iç denetçilerin rolünü,

denetim sırasında sorulması gereken

ilk 10 mahremiyet sorusunu

tartışmaktadır.

BT Denetim Planının Geliştirilmesi:

İş sürecini anlamak, BT denetim evrenini

tanımlamak ve bir risk değerlendirmesi

gerçekleştirmekten BT denetim planı

biçimlendirmeye kadar bir BT denetim

planının nasıl geliştirileceği konusunda

basamak-basamak kılavuzluk bilgisi

sağlamaktadır.

3

BT Zafiyetlerinin Yönetimi ve

Denetimi: Diğer konuların yanı sıra,

zafiyet yönetimi yaşam döngüsü,

zafiyet yönetimi denetiminin kapsamı

ve zafiyet yönetimi uygulamalarını

ölçecek ölçütleri tartışmaktadır.

Tüm diziyi bilgisayarınıza indirmek için IIA’nın www.theiia.org/technology adresindeki Web

sitesini ziyaret ediniz.

4

Global Teknoloji Denetim Rehberi

(GTAG®) 12

Bilgi Teknolojileri (BT) Projelerini Denetlemek

Yazarlar

Karine Wegrzynowicz, Lafarge SA

Steven Stein, Hewlett-Packard

Mart 2009

Telif Hakkı © 2007, Uluslararası İç Denetçiler Enstitüsü, 247 Maitland Ave., Altamonte Springs,

FL 32701 – 4201’e aittir. Tüm hakları saklıdır. Amerika Birleşik Devletleri’nde basılmıştır.

Yayımcının ön izni alınmadan, bu dokümanın hiçbir bölümü çoğaltılamaz, herhangi bir bilgi depolama

ve erişim sisteminde saklanamaz ya da hiçbir formatta ve hiçbir kanal yoluyla – elektronik, mekanik,

fotokopi, kayıt altına alma veya başka yollarla - başkasına aktarılamaz.

IIA, bu dokümanı bilgi vermek ve eğitim amacıyla yayımlamaktadır. Bu doküman, bilgi sağlamayı

amaçlamaktadır; ancak hukuk veya muhasebe konularında bir tavsiye yerine kullanılamaz. IIA böyle

bir tavsiyede bulunmaz ve bu dokümanı yayımlamakla, muhasebeyle ilgili veya hukuki sonuçlara

yönelik varılan sonuçların doğruluğu hakkında herhangi bir garanti vermez. Hukuk veya muhasebe

konularında sorunlar ortaya çıktığı takdirde, profesyonel yardıma başvurulmalıdır.

5

İÇİNDEKİLER TABLOSU

IIA BAŞKANI’NDAN MEKTUP……………………………………………………..……..6

1. YÖNETİCİ ÖZETİ……………………………..…………………………………….8

2. GİRİŞ...………………………………………………………………………………10

2.1. BT Projesi Tam Olarak Nedir?........................................................................10

2.2. BT Projesinin Kuruma Etkisini Anlamak………………………………………..10

2.3. Başarısız BT Projeleri Örnekleri…………………………………………………11

2.4. Geçmiş BT Projeleri Başarıları ve Başarısızlıklarına İlişkin İstatistikler….……11

2.5. Projenin Başarısında En Önemli 10 Faktör……………………………………...13

2.6. İç Denetim Biriminin Sürece Katılımının Amacı ve Faydaları………………….13

3. PROJE DENETİMLERİ İÇİN BEŞ KİLİT ODAK NOKTASI…………………14

3.1. İşletme ve BT Arasındaki Uyum…………………………………………………14

3.2. Proje Yönetimi…………………………………………………………………...15

3.3. BT Çözümü için İstekli ve Hazır Olma…………………………………………..21

3.4. Kurumsal Yönetim ve Süreç Değişiklik Yönetimi.……………………………...23

3.5. Uygulama Sonrası Süreç…………………………………………………………25

4. PROJE DENETİMİ PLANLAMA…………………………………………………25

4.1. BT Projeleri ve Yıllık İç Denetim Planı………………………………………….25

4.2. İç Denetim Biriminin Rolü……………………………………………………….26

4.3. Proje Denetimi Tipleri………………………………………………..…………..28

4.4. Dış Denetçilere Yönelik Mülahazalar…………………………………………....31

EK A – PROJE YÖNETİMİ………………………………………………………………..32

A.1. Proje Yönetimi Metodolojileri…………………………………………………..32

A.2. Proje Yönetimi Yaşam Döngüsü………………………………………………...32

EK B – BT PROJE PAYDAŞLARI………………………………………………………..34

EK C – PROJE YÖNETİMİ BİRİMİNİN YAPISI, ROL VE SORUMLULUKLARI…35

EK D – OLGUNLUK MODELLERİ………………………………………………………36 D.1. Kapasite Olgunluk Modeli………………………………………………………36

D.2. Proje Yönetimi Olgunluk Modelleri……………………………………………..36

D.3. Sistem Geliştirme Olgunluk Modelleri………………………………………….36

EK E - GENEL PROJE YÖNETİMİ EN İYİ UYGULAMALARI……………………..37

E.1. PMBOK ve PRINCE2…………………………………………………………...37

E.2. ISO Standartları………………………………………………………………….38

E.3. Proje Yönetimine Uygun COBIT Bölümleri……………………………....39

E.4. VAL IT…………………………………………………………………………..39

EK F – BT PROJESİNİ GÖZDEN GEÇİRME SIRASINDA İÇ DENETÇİNİN

SORMASI GEREKEN SORULAR………………………………………………………..40

YAZARLAR HAKKINDA………………………………………………………………….51

6

IIA Başkanı’ndan Mektup

Benimle aynı kuşaktaki iç denetçilerin çoğu gibi, ben de teknolojinin olağanüstü gelişimine

yakından şahit oldum. Gençlik yıllarımda, 1970’lerde üniversiteyi yeni bitirmiş bir iç denetçi

olarak, genellikle karşıma çıkan en karmaşık teknolojik alet 10 tuşlu bir hesap makinesi

olurdu. Oysa bugün, oldukça farklı bir dünyada yaşıyor ve çalışıyoruz.

İş hayatına atıldığımdan beri hızla artan ve devamlılık arz eden teknolojik gelişmeler

sayesinde, neredeyse karşılaştığımız her şey teknolojiyle harmanlanmıştır. Sektöre veya

kurumun türüne bakılmaksızın, bir rekabet avantajı elde etmek, riskleri yönetmek ve işletme

hedeflerine ulaşmak açısından, BT kritik öneme sahiptir ve dünya çapında, kurumlar, önemli

teknolojik projeler için muazzam kaynaklar ayırmaktadırlar.

BT projeleri ister kurum içinde geliştirilsin isterse üçüncü şahıs hizmet sağlayıcısıyla eş-

kaynak yoluyla sağlansınlar, bu projeler, başarıyı temin etmek için dikkatle düşünülmesi

gereken zorluklarla doludurlar. Yetersiz tanımlanan proje kapsam ve hedefleri, üst yönetici

desteğinin olmaması, yetersiz kullanıcı katılımı, yanlış veya uygunsuz teknoloji seçimleri

veya değişen teknolojiler hakkında bilgi eksikliği gibi sorunlar nedeniyle, istenmeyen

sonuçlar ortaya çıkabilir. Bu ve başka BT zorluklarına yeterince dikkat edilmemesi; para ve

kaynak israfı, güven kaybı ve itibar zedelenmesine yol açacaktır. Bu sayılanların hepsi büyük

risklerdir ve hiçbiri kabul edilemez.

Bilgi teknolojisi, doğası gereği fonksiyonlar-arası bir niteliğe sahiptir. Kurum çapında

insanları ve süreçleri kapsamalıdır ve iç denetçilerin kurum içerisindeki özgün perspektif ve

konumları nedeniyle sürece erken katılmaları, olumlu sonuçların alınmasının ve beraberinde

faydalar sağlamasının garanti altına alınmasına yardımcı olabilir. Münferit işletme birimleri

ile BT birimi arasında bir köprü görevi görebilirler, daha önceden tespit edilmemiş risklere

dikkat çekebilirler ve sonuçları iyileştirmek için kontrol önerilerinde bulunabilirler.

Tüm bu nedenlerden dolayı, IIA’nın GTAG: BT Projelerinin Denetimi başlıklı bu dokümanı

yayımlamasından dolayı özellikle memnunum. Teknolojideki gelişmeler göz önüne

alındığında, tam zamanında yayımlanan bu rehber, suiistimalle ilgili riskleri değerlendirmek

amacıyla ekiplerle ve yönetimle etkin bir şekilde ilişki kurmayla ilgili tekniklerin bir genel

taslağını sunmaktadır. Bu Uygulama Rehberi kapsamında;

Projeyle ilgili riskleri değerlendirmek için bir çerçevenin nasıl oluşturulacağı;

Kilit proje yönetimi riskleri;

İç denetim biriminin bir yandan bağımsızlığını korurken diğer yandan proje

incelemesine aktif olarak nasıl katılacakları;

Bir denetim yaklaşımı geliştirirken iç denetçilerin dikkate alacakları, BT projelerine

ait beş kilit bileşen;

Proje başarısı için en önemli 10 sebep;

Proje denetimleri tipleri ve

BT proje değerlendirmesinde kullanılacak bir önerilen sorular listesiyle birlikte bir

örnek denetim çalışması bulunmaktadır.

Bu uygulama rehberi, gerçekte bir ekip çalışması yoluyla hazırlanmıştır. Konuyu seçtiği ve

rehberi hazırladığı için IIA’nın İleri Teknoloji Komitesi’ne minnettarlık duymaktayız. Bu

rehberin başlıca iki yazarı, Lafarge SA firmasında iç denetim müdürü olan Karine

Wegrzynowicz, CIA ve Hewlett-Packard firmasında global BT denetim yöneticisi olan Steve

7

Stein, CIA’ye bu proje için epey zaman ve çaba harcayarak katkı sağladıklarından dolayı

teşekkürü borç biliriz.

Sizi BT’yle ilgili proje yönetimi konusundaki bilgilerinizi pekiştirmek için bu zorunlu

rehberden faydalanmaya davet ediyorum. Eminim ki, bağlı olduğunuz kurumun gelecekteki

BT çabalarının başarıya ulaşmasına katkı sağlayacaktır.

Saygılarımla,

[İmza]

Richard F. Chambers, CIA

IIA Başkanı

Global Genel Merkezi

8

1. YÖNETİCİ ÖZETİ

Kurumlar; yeni bilgi sistemlerinin uygulanmasına fon sağlamak, yeni pazarlara girmek, yeni

ürünler geliştirmek ve ittifakları ve satınalmaları yönetmek için büyük tutarlarda sermaye

yatırımı yapmaktadırlar. Sıklıkla, bu çalışmaları yönetecek proje ekipleri oluşturulmaktadır.

Bu yatırımlar kuruma bir yandan olumlu değişiklikler sağlarken, diğer yandan kurumu yüksek

risklerle karşı karşıya bırakmaktadırlar. Sonuç olarak bu yatırımların başarılı ya da başarısız

olması, kurumun stratejisi açısından kritik öneme sahip olabilir ve kurumun verimliliği ve

itibarını etkileyebilir.

Birçok proje ve yatırım, bilgi teknolojisi (BT) çevresine odaklanmıştır. Geçmişte, The

Standish Group tarafından yapılan “CHAOS Raporu” gibi çalışmalar, özellikle BT projeleri

için başarısızlık oranının yüzde 50’ye kadar çıkabileceğini göstermektedir.1 Proje başarısızlığı

sıklıkla iki kilit noktaya indirgenmektedir: bir insan perspektifinden bakıldığında çok fazla

iyimserlik veya bir sistem perspektifinden bakıldığında teknoloji bozuklukları. Projelerin

karşı karşıya kaldığı risk düzeyi dikkate alındığında, iç denetim departmanının kurumda

uygulanan projelerden haberdar olması ve projenin kontrol boyutu hakkında yol gösterici

bilgiler vermek veya istenen sonuçlara ulaşıp ulaşılmadığının bağımsız bir değerlendirmesini

yapmak amacıyla hangi aşamada sürece dahil olması gerektiğine karar vermesi elzemdir.

İç denetim departmanı, projeyle ilgili riskleri değerlendirerek BT projelerinin başarısına katkı

sağlayabilir. Denetçiler, güvenlik kontrolleri ve iç kontroller gibi alanlara odaklanabilir ve

genel proje yönetimini değerlendirmek konusunda bir rol oynayabilirler. Proje ekiplerinin

risklere müdahale etmesine yardımcı olarak, iç denetim birimi projenin başarı şansını

artırabilir. GTAG 8: Uygulama Kontrollerin Denetimi başlıklı dokümanda da tartışıldığı gibi,

iç denetim departmanı, hem geleneksel güvence hem de danışmanlık görevleriyle sürece

değer katabilir.2

2002 yılında Internal Auditor’da yayımlanan bir makalede, Richard B. Lanza, “Başarıya

ulaşmak için, iç denetçilerin, bağımsız bir danışmanın sürece katabileceği değeri hem üst

yönetime hem de proje yöneticilerine göstermeleri gerektiğini belirtmiştir. Üst yönetim

denetçilerin projeye erişimini sağlayabilir, ancak denetçiler, proje yöneticileri onların

katılımını benimseyip kabul ettikleri ve onlara daha fazla erişim imkanı sağladığı zaman daha

etkin ve etkili olabilirler.”3

Bu GTAG’nin amacı, BT projeleriyle ilgili riskleri değerlendirmek amacıyla proje ekipleriyle

ve proje yönetimi birimleriyle (PMO’lar) etkin bir şekilde yakın ilişkiler kurmaları için, iç

denetim yöneticilerine (İDY’ler) ve iç denetçilere, kullanılacak tekniklerin genel bir taslağını

sunmaktır. Proje yönetimi alanı oldukça geniş bir alandır, bu nedenle, bu rehberin amacı,

projeyle ilgili riskleri değerlendirmek için bir çerçeve çizmek, yaygın görülen proje yönetimi

risklerine örnekler sunmak ve iç denetim biriminin bir yandan bağımsızlığını muhafaza

ederken diğer yandan projelerin gözden geçirilmesine aktif bir şekilde nasıl katılacağını

tartışmaktır. IIA’nın yayımladığı Uluslararası İç Denetim Mesleki Uygulama Standartları, bu

görevleri yerine getirmek için ilke-odaklı kılavuzluk bilgileri sunmaktadır.

1 “CHAOS Raporu 2007, CHAOS’un 10 Yasası, The Standish Group, 2007”

2 GTAG 8: Uygulama Kontrollerinin Denetimi, s.5

3 “Teknoloji Projeleri: İşletmenin En Riskli Kısımları” Internal Auditor, 15 Mayıs 2002, Richard B. Lanza,

CPA, PMP.

9

Bu GTAG kapsamı dahilinde, BT projelerinin bir denetim yaklaşımı geliştirmek istediğimiz

beş kilit bileşenine odaklanmayı tercih ettik (Bakınız Şekil-1).

1. İşletme ve BT Arasındaki Uyum

2. Proje Yönetimi

3. BT Çözümü için İstekli ve Hazır Olma

4. Kurumsal Yönetim ve Süreç Değişiklik Yönetimi

5. Uygulama Sonrası Süreç

Şekil 1’de, proje yönetiminin tüm bu alanları birbirine bağlayan merkezi bir kavram olduğunu

göstermektedir. Proje denetim yaklaşımını planlarken, iç denetçi, tüm büyük risklerin ele

alındığından emin olmak için bu alanların beşini de dikkate almalıdır. Denetim projeleri,

stratejik risk konusunda güvence sağlamak açısından iç denetim birimi için mükemmel bir

fırsattır. Birkaç çalışma, iç denetim biriminin operasyonel riskleri denetlemek için oldukça

fazla zaman harcadığını, ancak stratejik risklere yeterince vakit ayırmadığını göstermiştir.

Proje denetimleri, risk odağını genişletmek için bir fırsat sunabilir.

Şekil 1: Denetçiler için Beş Kilit Odak Noktası

10

2. Giriş

2.1. BT Projesi Tam Olarak Nedir?

BT Projesi terimi bir yanlış adlandırma sonucu ortaya çıkmıştır. Gerçekte, çoğu sistem

uygulama ve bakım projesi, BT departmanından başka alanları da kapsayan veya etkileyen ve

giderek daha karmaşıklaşan girişimlerdir. Bu nedenle, bir BT projesi olmasının yanı sıra bir iş

projesi olarak düşünülmelidir. En genel anlamıyla, bir proje; program, kapsam ve kaynakların

belirlenen sınırları dahilinde belirli bir amacı gerçekleştirmek için üstlenilen, mantıklı bir

başlangıcı ve sonu olan özgün bir faaliyetler bütünüdür. Bu GTAG’nin teknolojiyle ilgili bir

çözüm içeren projelere odaklamayı amaçladığını, ancak uygulanan ilkelerin diğer proje

türlerine çok benzer olduğunu belirtmekte yarar vardır.

BT’yle ilgili yatırımlar, yıllardır kurumlar için büyük bir masraf kaynağı olmuştur. Dalgalar

halinde gelmektedirler ve dünya çapındaki tüm kurumlar bu yatırımlara cevap vermişlerdir.

Büyük BT projeleri kolaylıkla onlarca milyon dolar masrafa yol açabilir. Son 15 yıldaki BT

sistemiyle ilgili büyük proje dalgaları kapsamında, kurumsal kaynak planlama (ERP)

sistemleri, 2000 Yılı sorununu çözmek, e-ticaret/internet şirketi çözümleri ve müşteri ilişkileri

yönetimi (CRM) bulunmaktadır. Bu projeler dahilinde, yeni bir altyapı oluşturmak, yeni ürün

geliştirme (yaygın olarak araştırma-geliştirme veya Ar-Ge olarak bilinmekte ve

adlandırılmaktadır) ve yeni iş süreçlerinin veya iş dönüşümlerinin uygulanmasını içerebilir.

Bu projelerin değerlendirilmesinde, kilit riskleri anlamak ve farklı aşamalarda projeyi

değerlendirmek için bir kriterler grubu belirlemek önemlidir.

2.2. BT Projesinin Kuruma Etkisini Anlamak

Günümüzde, bir proje başarısının tespiti; geleneksel, zamana ve bütçeye bağlı ölçümlerin

ötesine uzanmaktadır. Projenin ardındaki işletme ihtiyaçlarına bağlı olarak, başarısız olan

veya zorluklarla karşı karşıya kalan projelerin kuruma önemli bir etkisi olabilir. Bu muhtemel

risklere birkaç örnek olarak:

Müşterilere verilen hizmetin aksaması;

Rekabet üstünlüğünün kaybedilmesi;

Düzenleyici kurallara uyulmaması sonucu para cezalarının kesilmesi;

Gelir kaybı;

İtibarın zedelenmesi;

Kritik stratejik girişimler, ürünler ve süreçlerin yayılmasında gecikmeler;

Beklenen yatırım geri dönüşünde kayıplar;

Kritik işler ve BT personeli kaybı;

Tesislerin kapanması veya zarara uğraması ve

Hissedar/yatırımcı kaybı verilebilir.

Birçok araştırmacı ve danışmanlık firması, BT projelerinin sürekli olarak zorluklarla

karşılaştığını veya başarısızlığa uğradığını – bütçeyi aştığını, programın gerisinde kaldığını,

belirlenen hedeflere ulaşamadığını veya bu projelerin iptal edildiklerini – gösteren çalışmalar

yapmışlardır. Sonuç olarak, konu hakkında fikir, makale ve beyaz bültenler yeterli düzeyde

mevcuttur. Veri yorumlarına bakılmaksızın, projelerin önemli güçlüklere yol açtığına yönelik

bulgular mevcuttur. Nihayetinde, projenin başarılı olması ve faydalı sonuçların elde

edilmesini temin etmekten yönetim sorumludur.

11

2.3. Başarısız BT Projeleri Örnekleri

BT projeleri başarısızlıklarının çoğu, hiçbir zaman kamuya duyurulmayacaktır, çünkü

bunların kamuya ifşa edilmesi, kurumun itibarı ve hissedarlar üzerinde olumsuz bir etki

yaratacaktır. Bununla birlikte, aşağıda, rapor edilen önemli başarısızlıklara birkaç örnek

verilmiştir:

2005 yılının Ağustos ayında, CIO Magazine, ABD’de büyük bir resmi kuruluşun

programda gecikmeler, belirlenen bütçenin aşılması ve teknik zorluklar nedeniyle, 170

milyon dolarlık bir sanal dava dosyaları yönetim sistemi projesini rafa kaldırmak

zorunda kaldığını bildirmiştir.4

2004 yılında, dünyada önde gelen telekomünikasyon şirketlerinden birinin projesi bir

CRM sisteminin yükseltilmesi sırasında başarısızlığa uğradı. Bu başarısızlık sonucu

ortaya çıkan sorunlar BT departmanının tamamına yayılarak müşterilere yapılan

kablosuz hizmetlerde aksamalara yol açmıştır. Bu olay üzerine, şirket pek çok müşteri

kaybetmiştir ve şirket gelirinin 100 milyon ABD$ değerinde etkilendiği tahmin

edilmektedir. Hisse fiyatı düşmüştür ve şirket henüz toparlanamadan asıl hisse

bedelinin yarısından daha az bir fiyata bir rakip firmaya satılmıştır.5

1999 yılında, dünyadaki en büyük gıda imalat şirketlerinden biri, önemli bir ERP

uygulama sorunuyla karşı karşıya kalmış; bu da, yılın son çeyreğinde iki kez kâr

uyarısı yapılmasına neden olmuştur. Bu olay, kritik tatil satış sezonu sırasında önemli

dağıtım problemlerine yol açmıştır. Yılsonu itibariyle hisse fiyatlarında yüzde 27’lik

düşüş gözlenmiştir. O dönemlerde piyasadaki canlılık düşünüldüğünde bu düşüş

oldukça azdır.6

2.4. Geçmiş BT Projeleri Başarıları ve Başarısızlıklara İlişkin İstatistikler

Aralarında Gartner Group, Forrester Group, The Standish Group ve KPMG’nin de bulunduğu

pek çok analist ve danışman tarafından, son yirmi yıldan fazla süredir sürekli olarak BT proje

başarısızlıklarına ilişkin istatistikler çıkarılmış ve raporlanmıştır. Bu dokümanda tartışılacak

çok fazla rapor ve istatistik mevcuttur, ancak IDY, BT projeleriyle ilişkili içsel riskleri

anlamak için yapılan araştırmalardan haberdar olmalıdır. Denetçiler, bağlı bulundukları

spesifik kurum ve sektörle ilgili istatistikleri ve başarısızlıkları araştırmalıdırlar. Bu

istatistikler, proje denetimlerine olan ihtiyacı tartışırken yönetime sunulabilir. Aşağıda, proje

başarısızlıklarıyla ilgili araştırmalara birkaç örnek verilmektedir:

The Standish Group’un7 çıkardığı 2007 CHAOS Raporu, kurumun 1998 ile 2006

yılları arasında yaptığı araştırma çalışmalarının özet sonuçlarını sunmaktadır. Veriler,

proje başarısına kesin gözüyle bakılamayacağını göstermektedir. 2006’dan itibaren,

projelerin yüzde 65’i ya başarısız olmuş ya da zorluklarla karşıya kalmıştır; yani

amaçlar, maliyet veya program hedeflerinin tümünü ya da bir kısmını

karşılayamamışlardır.

4 CHAOS Raporu, 2007, “Federal Ajanlar Niçin BT Çalışanları Olmuyorlar?” Allan Holmes, CIO Magazine

Online, 15 Ağustos 2005. 5,6

BT Projeleri Hakkında Yöneticilerin Sorması Gereken 20 Soru, 2007. Kanada Yeminli Mali Müşavirler

Enstitüsü, Toronto, Kanada’nın izniyle uyarlanmıştır. Orijinal materyalde yapılan tüm değişiklikler yayımcının

sorumluluğunun sorumluluğundadır ve CICA tarafından incelenmemiş veya tasdik edilmemiştir.

7 CHAOS Raporu, 2007, 10 CHAOS Yasası, The Standish Group, 2007.

12

Tablo-1: CHAOS Araştırması

CA, Inc., BK ve İrlanda’da 100 BT direktörüne anket uygulaması için Birleşik

Krallık, Loudhouse’ta bulunan bağımsız bir araştırma grubuna sponsorluk yapmıştır.

Çalışma, BT projesi durumuna yeterince dikkat edilmemesi ve yönetimin projeleri

yeterince kontrol etmemesinin BK şirketlerinde her yıl çeyrek milyar pound (350

milyon ABD$) maliyete yol açtığını göstermiştir. Her yıl yapılan projelerin üçte biri,

asıl bütçenin yüzde 10 ilâ yüzde 20’si oranındaki tipik fazla harcamalarla birlikte her

yıl bütçe aşımlarıyla sonuçlanmaktadır. Ayrıca anket, BT projelerinin giderek daha

karmaşık hale geldiğine de vurgu yapmıştır. Tipik bir şirketin aynı anda 29 proje

yürüttüğünü ve ortalama 1 milyon £ ile 5 milyon £’lik (1,4 milyon ABD$ ve 7,03

milyon ABD$) BT bütçesine sahip olduğunu göstermiştir.8

KPMG’nin 2005 yılında yayımladığı Global BT Proje Yönetimi Anketi, anket

katılımcılarının yüzde 49’unun son 12 ay içerisinde en az bir projelerinin başarısız

olduğunu ortaya çıkarmıştır. Ayrıca rapor, kurumların yüzde 59’unun, istenilen

faydayı sağlayacak bir projenin yürütülüp yürütülmediğini değerlendirmek için ya

hiçbir süreç uygulamadıklarını ya da yalnızca resmi olmayan bir süreç uyguladıklarını

göstermiştir.9

Bunlar verilebilecek örneklerin yalnızca birkaçıdır. Bu istatistiklerin doğruluğunu detaylı

olarak tartışmak mümkün olsa da, sürekli olarak çok sayıda proje başarısızlıklarının rapor

edildiği gerçeği değişmeyecektir.

8 Bütçeyi Aşan BT Projeleri UK Plc’ye Her Yıl 256 Milyon £’a Mal Olmaktadır, CA Inc., 12 Eylül 2007.

9 Global BT Proje Yönetimi Anketi. © 2005 KPMG International. KPMG International, KPMG adı altında

faaliyet gösteren bağımsız firmaların oluşturduğu bir ağ için koordine edici bir antite olarak görev yapan bir

İsveç kooperatifidir. KPMG International’a bağlı her bir üye firma hukuken ayrı ve bağımsızdır ve kendisini

öyle nitelendirmektedir. Tüm hakları saklıdır. Hong Kong’da basılmıştır. KPMG adı ve KPMG logosu, bir İsveç

kooperatifi olan KPMG International’ın tescilli markasıdır. Ağustos 2005.

13

2.5. Proje Başarısı İçin En Önemli 10 Faktör

Başarısızlıkları önlemek amacıyla, projelerin başarıya ulaşmak için en iyi fırsatlara sahip

olduğunu temin edecek adımlar hakkında, birçok araştırma grubu fikirler sunmaktadır. The

Standish Group, projelerin niçin başarıya ulaştığına yönelik çalışmasına dayanan bir yıllık

rapor sunmaktadır. Aşağıda sayılan başarı için 10 kural, The Standish Group’un “2007

CHAOS Raporu” adlı en son yıllık raporundan alınmıştır:10

1. Kullanıcı Katılımı – İşletme ve BT kullanıcıları, kilit öneme sahip konsensüs

oluşturma, karar verme ve bilgi toplama süreçlerine katılmaktadırlar.

2. İcrai Yönetimin Desteği – Kilit yöneticiler, işletme stratejisine uyum sağlamanın

yanı sıra finansal, manevi açıdan ve ihtilâfları çözmek konusunda destek

sağlamaktadır.

3. Açık İşletme Hedefleri – Paydaşlar, projenin esas değerini ve işletme stratejisiyle

nasıl uyum içinde olduğunu anlamaktadırlar.

4. Dinamik Optimizasyon – Proje, gereksiz özelliklerden kaçınmak ve kritik

özelliklerin dahil edildiğinden emin olmak için tekrar eden geliştirme ve

optimizasyon süreçleri kullanmaktadır.

5. Duygusal Olgunluk – Proje yöneticisi, proje paydaşlarının duygularını ve

eylemlerini yöneterek, hırs, kibir, cehalet, imtina ve dolandırıcılıktan

kaçınmaktadır.

6. Proje Yönetimi Konusunda Uzmanlık – Kurum, Proje Yönetimi Enstitüsü’nden

sertifikalı Proje Yönetimi Uzmanı (PMI) gibi veya benzeri, temel beceri ve

uygulamaları bilen proje yöneticileriyle çalışmaktadır.

7. Finansal Yönetim - Proje yöneticisi, finansal kaynakları yönetmek, proje

bütçesi/masraflarının hesabını vermek ve projenin değerini kanıtlamak için

gereken kabiliyete sahiptir.

8. Beceri Sahibi Kaynaklar – Personel devri ve personelle ilgili diğer sorunlar

karşısında ilerleyebilmek amacıyla, beceri sahibi personel alınmakta, yönetilmekte,

kurumda tutulmakta ve kontrol edilmektedir.

9. Resmi Metodoloji – Ne zaman, nasıl ve hangi olayların, hangi sırada ortaya

çıkması gerektiğini gösteren bir yol haritası sunan bir grup daha önceden

tanımlanmış süreç-esaslı teknik mevcuttur.

10. Araçlar ve Altyapı – Proje altyapısı; görevler, kaynaklar, koşullar, değişiklikler,

riskler, satıcılar, kullanıcı kabulü ve kalite yönetimi konularının yönetimini

kolaylaştıran araçlarla inşa edilmekte ve yönetilmektedir.

2.6. İç Denetim Biriminin Sürece Katılımının Amacı ve Faydaları

Yukarıda ana hatlarıyla belirtilen tüm başarı faktörleri açıkça yönetimin rolü olmasına

rağmen, iç denetim birimi de risk yönetiminin hem BT hem de BT’yle ilgili projelerin

kurumsal yönleri üzerinde ne kadar etkin olduğunu değerlendirerek sürece önemli düzeyde

değer katabilir. İç denetim birimi, bir kurumun veya birimin daha önceden belirlenen

hedeflerine ulaşıp ulaşmadığını değerlendirecek bir yaklaşım sunmaktadır. Denetçiler,

sorunlara vurgu yapmak ve düzeltici eylemler önermek için iş süreçlerini veya eylemlerini

metodik bir yolla analiz etmektedirler. Yukarıda belirtilen BT’yle ilgili riskler

düşünüldüğünde, iç denetim birimi, başarı olasılığının artmasına yardımcı olmak amacıyla,

projeleri erken aşamalarda gözden geçirmek için sahip oldukları deneyimin ve uyguladıkları

10

CHAOS Raporu, 2007, 10 CHAOS Yasası, The Standish Group, 2007.

14

metodolojinin değerini kuruma sunabilirler. İç denetim biriminin sürece katılımının faydaları

arasında:

Proje süresince bağımsız, sürekli tavsiyeler vermek;

Kilit riskleri veya sorunları erken teşhis etmek, böylece proje ekiplerinin riskleri

hafifletmek için proaktif olarak çalışmasını kolaylaştırmak sayılabilir.

3. Proje Denetimlerinde Beş Kilit Odak Alanı

Araştırmalar, belli başlı riskleri göstermekle kalmamış, aynı zamanda erken müdahalenin

başarı için kilit öneme sahip olduğunu göstermiştir. Giriş bölümünde de belirtildiği gibi, bu

GTAG, bir denetim yaklaşımı geliştirmek için kullanılmasını tavsiye ettiğimiz beş kilit proje

alanına odaklanmaktadır. Aşağıda, çeşitli araştırmalar ve yazarların farklı proje risk

değerlendirme metodolojileri kullanmak konusundaki geçmiş deneyimlerine dayanarak

odaklanılacak mantıklı alanlar olarak seçilen beş kategori bulunmaktadır.

1. İşletme ve BT Arasında Uyum

2. Proje Yönetimi

3. BT Çözümü için İstekli ve Hazır Olma

4. Kurumsal Yönetim ve Süreç Değişim Yönetimi

5. Uygulama Sonrası Süreç

İlerleyen bölümlerde, beş kilit odak alanının her birine yönelik mülahazalar sunulmaktadır.

(Bu odak alanlarının her birine yönelik spesifik riskler ve kontrollerle ilgili denetim soruları

ve örneklerinin önerilen bir listesi için Ek F’ye bakınız.)

3.1. İşletme ve BT Arasında Uyum

Basit anlamıyla uyum, hem işletmenin hem de BT biriminin vizyonunun ve amaçlarının

anlaşılması, birbiriyle uyum ve ahenk içinde olması ve projenin kurum stratejisiyle aynı

doğrultuda olmasıdır. Hemen hemen her projede, kurumun çeşitli farklı düzeyleri ve

fonksiyonları arasında birbirine bağımlılık söz konusudur. Bu, bir proje yaşamı boyunca

uyum sağlamanın ve sürdürmenin önemli bir zorlu görev olduğu anlamına gelmektedir!

Liderlik, zaman ve enerjilerinin tümünü projelere adayan sponsorlar kadar, tüm mevcut

paydaşlarla düzenli toplantılar yapmak ve açık bir iletişim akışı için kanallar oluşturmak da

kritik öneme sahiptir. Bu sponsorluğun yanı sıra, proje ekibinin seçimi de eşit derecede

önemlidir. Doğru tecrübe, beceri ve projeyi destekleme isteğinden yoksun bir proje ekibi,

proje başarısının karşı karşıya kaldığı yaygın bir engeldir. Proje uyumuyla ilişkili pek çok

husus söz konusudur ve birçok kurumda bu hususlar iş vaka etüdüne dâhil edilmektedir.

İş Vaka Etüdünü Değerlendirmek

Bir projenin başlatılması için, yönetimin geleceğe yönelik iyi fikir gibi görünen noktaların

uygulanabilirliğini tespit etmek amacıyla bilgiye ihtiyacı vardır. İş vaka etüdünün

hazırlanması, projeyi yürütüp yürütmemek konusunda bir karar almayı kolaylaştıracak gerekli

bilgileri sağlamak için özel bir ekip tarafından takip edilen bir süreçtir. Nihai karar, proje

yürütme komitesi tarafından veya kurumun daha üst bir düzeyinde alınabilir. Aslında denetim

rehberlerinin tümü, iş vaka etüdünü gözden geçirmek konusunda yazılmışlardır. Bu nedenle,

bu GTAG’nin amaçlarına uygun olarak, yaygın risk alanlarının yalnızca birkaçına

odaklanacağız.

15

İş vaka etüdünün kilit bileşenleri arasında:

Gerçekçi, anlaşılır ve ölçülebilir faydalar;

Mevzuat manzarası ve mimari uyum gibi çevresel kaygılar;

Hangi birimlerden kimlerin sürece dâhil olması gerektiği gibi kurumsal mülahazalar;

Açıkça tanımlanmış bir proje kapsamı;

Süreç ve fonksiyonelliğe yönelik proje çıktıları;

Hem maliyet hem de insanlar bakımından gerekli kaynaklar;

Ortakların ve bayilerin yaşabilirliğiyle ilgili risklerin analizi ve

Başarı şansının ölçülmesi ya da olabilirliği

bulunabilir.

Bir iş vaka etüdü geliştirirken, proje etkisinin yanı sıra proje sponsorluğunun da tesis edilmesi

gerekir. En erken aşamada, proje sponsorlarının projenin tam etkisini anlamaları ve tüm iç ve

dış paydaşların göz önüne alındığından emin olmaları gerekir. Doğrudan paydaşlar arasında,

yeni sistemi kullanacak iç departmanlar veya birimler, sistemle etkileşim kurabilecek dış

müşteriler veya tedarikçiler ve kazanılmış bir hakka sahip olan herkes bulunmaktadır.

Aralarında finans, iç denetim, BT güvenliği, hukuk, satınalma veya mevzuat birimlerinin

bulunabileceği doğrudan paydaşlara da erkenden danışılması önemlidir. Tüm mülahazaların

dikkate alındığından emin olmak için, etkilenen tüm gruplardan – etkilenme oranları

minimum düzeyde olsa bile – geribildirim alınmalıdır.

İş vaka etüdü, tüm mevcut alternatiflerin düşünüldüğünü güvence altına almalıdır. Tipik

faktörler arasında; firma içinde bir çözüm inşa etmek veya kurum dışından bir paket satın

almak, dış kaynak kullanmaya kıyasla iç kaynakları kullanmak ve elbette, projenin bir

mevzuat gereksinimi mi yoksa sadece bir işletme verimlilik çözümü mü olduğunu düşünmek

bulunmaktadır. Alternatiflerin analizinde, güçlü bir iş vaka etüdü, yönetimin en mantıklı

kararı almasına ve düşünülmesi gereken tavizleri anlamasına yardımcı olmaktadır. Son olarak,

bir iş vaka etüdü; kurumun projeyi üstlenme kapasitesini, projenin öncelik düzeyini ve

kurumda projeyi gerçekleştirmek için doğru becerilere sahip insanların olup olmadığını

değerlendirmesi gerekmektedir.

3.2. Proje Yönetimi

Proje Yönetimini Anlamak

Şekil 1’de de gösterildiği gibi, proje yönetimi beş odak alanının merkezinde yer almaktadır. İç

denetim gibi proje yönetimi de, sahip olduğu en iyi uygulamalar, terminoloji ve

standartlarıyla başlı başına bir meslektir. (Meslek olarak proje yönetimi konusunda geniş çaplı

ve geniş kapsamlı kılavuzluk bilgileri mevcut olduğu için, bu GTAG’nin ekleri, proje

yönetimi hakkındaki referans materyaller, en iyi uygulamalar ve standartların bir özetini

sunmak için geliştirilmişlerdir.) Denetçiler, proje yönetimiyle ilgili riskleri tam olarak

anladıklarından emin olmalıdırlar. Güçlü bir BT ve işletme özgeçmişi olan denetçiler bile,

proje yönetimiyle ilgili birçok en iyi uygulamaya aşina olmayabilirler. İç denetçilerin proje

yönetimi süreçlerine ve terminolojisine çalışmaları ve bunları daha iyi anlamaları

gerekmektedir.

Aşağıda verilen terminoloji, proje yönetimi için temel niteliktedir:

16

Proje Portföyü – Bir kurum içerisindeki projeler toplamı. Programlar kapsamında

birkaç proje bulunabilir. Proje ve programları planlamak, bunlar için bir kapsam

oluşturmak ve değerlendirmek için, denetçilerin bağlı bulundukları işletme ve kurum

bağlamında proje yönetimi, proje yönetişimi ve proje yönetim metodolojisi

kavramlarını anlamaları gerekmektedir.

Proje Yönetimi – Projenin belirtilen kapsam, kalite, zaman ve mali sınırlamalar

dâhilinde tanımlanması için kaynakları (örneğin, insanlar ve bütçe) organize etme ve

yönetme disiplini.

Proje Yönetişimi – Projeler ve kurumsal yönetişimin birbiriyle örtüşmesi, proje

yönetiminin kurum düzeyinde yönetişimi. Kurumun doğru projeleri üstlendiğini temin

eder, proje portföyünü kontrol eder, öncelikleri tespit eder, doğru düzeylere yetki tayin

eder ve uygun karar alma süreçleri oluşturur. İyi proje yönetim yönetişimi Şekil-2’de

(Sayfa 8) gösterilen tüm alanlar arasında bağlantı kurar ve bunların etkin ve verimli

işlemesi için gereken desteğe sahip olduğundan emin olur.

Proje Yönetimi Metodolojileri – Projenin planlanması ve yürütülmesine kılavuzluk

etmek için kullanılan geniş kapsamlı entegre politikalar, standartlar, metodolojiler,

yaşam döngüleri, prosedürler, araçlar, teknikler, paydaşlar ve kurumlar toplamı. The

Standish Group, metodolojinin, “proje çevresinin diğer yüzde 90’lık kısmı” olarak

tanımladığı hususları da içerdiğini (örneğin, duygusal tavırlar, kültür, paydaş eğitimi

ve kurumun süreç-dışı/prosedür olgunluğu) belirtmektedir.11

Denetçiler ve Proje Yönetimi Metodolojileri

İki ayrı işletmenin aynı olmadığının doğru olması gibi, iki ayrı proje yönetimi metodolojisinin

de aynı olmadığı doğrudur. Her kurum, farklı metodolojiler, yaşam döngüleri, en iyi

uygulamalar, araçlar vs. birleşimini kullanacaktır. Örneğin, büyük savunma yüklenicileri,

büyük ihaleleri desteklemek amacıyla, kapsamı, programı ve maliyeti birleştirerek proje

gelişimini objektif bir biçimde ölçmek için, bir proje yönetimi tekniği olan kazanılmış değer

yönetimi (EVM) benzeri kompleks bir metodoloji kullanabilir12

. Diğer yandan küçük bir

kurum, proje görevlerini ve statüsünü takip etmek için basit bir proje yönetimi yazılım paketi

veya çalışma tablosu kullanabilir.

Proje denetimlerini gerçekleştirmeye başlamadan önce, İDY’nin ve iç denetim ekibinin,

öncelikle kurumun ekosistem veya yaşam döngüsü olarak da bilinen proje yönetimi

metodolojisini anlamaları gerekmektedir. Ek olarak, hem proje yönetimi hem de sistem

geliştirmeyle ilişkili en iyi uygulamaları, riskleri ve kontrolleri de anlamaları gerekmektedir.

Bu ilişkinin anlaşılmaması halinde, iç denetçinin, BT proje denetimlerini tüm muhtemel

risklere açıklamak getirecek şekilde oluşturmamasına yol açabilir. Şekil-2’de bir metodolojiye

nelerin dâhil olması ve kilit kontrollerin nerede durması gerektiği gösterilmektedir. Ayrıca,

kademeler ve birimlerin birbirine bağımlılığına ve iç denetçinin projenin önemini tam olarak

anlamak için hangi kademeye çıkması gerekebileceğine vurgu yapmaktadır. Kurumun proje

yönetimi metodolojisi, denetçiye denetimi yapması için gereken içeriği sunmaktadır.

Metodoloji, denetimlerin planlanması ve yürütülmesi sırasında, kilit proje yönetişim

gruplarını ve kilit proje yönetimi kontrol noktalarını teşhis etmek ve tanımlamak ve denetim

kıyaslamasına tâbi tutulacak politikaları, standartları ve en iyi uygulamaları tespit etmek

amacıyla denetçilere yardım etmek konusunda bir temel sunmaktadır.

11

Çevrimiçi CHAOS Kayıtları, v14.2.1. Ekosistemin Sözlük Tanımı, The Standish Group, 2008 12

Kazanılmış Değer Yönetimi Uygulama Standardı, Proje Yönetim Enstitüsü, Mart 2005.

17

“Proje Metodoloji Bileşenleri ve Bunların Denetçiler için Değeri” adlı Tablo-2’de, en önemli

metodoloji bileşenleri ve bu bileşenlerin denetçi için değerine vurgu yapılmaktadır.

Şekil-2: Proje Yönetimi Metodolojileri. Sarbanes-Oxley için BT Kontrol Amaçları, İkinci

Baskı’dan uyarlanmış, revize edilmiş ve BT Yönetişimi (ITGI) ©2006 ITGI’nın izniyle

kullanılmıştır. Tüm hakları saklı ve mahfuzdur.

18

Metodoloji Bileşeni Denetçiler için Değeri Örnekler

Kurumsal

Proje Paydaşları Münferit projelerle ilgili münferit riskler ve

sorunlar hakkında denetçilere pek çok

perspektif (işletme, BT, yüklenici vs.) sunar.

İşletme sahibi

BT Sahibi

Proje Yönetimi Ofisleri Yıllık denetim planlama ve kapsam oluşturma,

denetim programları geliştirmeye vs.ye

yardımcı olan tüm proje metodolojilerini ve

ilgili proje çıktı gerekliliklerini tanımlamak ve

gözden geçirmek için merkezi bir lokasyon

sağlar.

Stratejik/Global

Tek Proje

İşletme Birimi

Modeller ve Metotlar

Proje Portföy Yönetimi Tüm projeleri tanımlamak ve gözden geçirmek

için merkezi bir lokasyon sunar, bu da yıllık

denetim planlaması, denetim önceliklendirme

vs. konularında yardımcı olmaktadır.

Stratejik/Global

Tek Proje

Proje Yönetimi Olgunluk

Modelleri

Proje denetimlerini planlamak için bir “ölçme

çubuğu” sunmaktadır. Portföy, Program ve Proje

Yönetimi Olgunluk Modeli

(P3M3)

Kurumsal Proje Yönetimi

Olgunluk Modeli (OPM3)

Sistem Geliştirme

Olgunluk Modelleri

Proje denetimlerini planlamak ve bunların

kapsamını belirlemek için bir “ölçme çubuğu

sunmaktadır”. Denetçiler, gelişmedeki

boşlukları tespit etmek için proje

metodolojilerini ve süreçlerini

değerlendirebilirler.

Gelişim Amaçlı Kapasite

Olgunluk Modeli

Entegrasyonu (CMMI)

Yazılım Süreci Geliştirme

ve Kapasite Belirleme

(SPICE)

Yazılım Geliştirme

Yaşam Döngüsü (SDLC)

Sistem geliştirme süreçlerine bağlılığı

tanımlamak ve değerlendirmek ve belli bir

yaklaşımın kullanılıp kullanılmayacağı

zamanları açıklamak konusunda bir temel

oluşturmaktadır.

Şelale Metodu

Hızlı Uygulama Geliştirme

(RAD)

Proje Yönetimi En İyi

Uygulamalar Rehberleri

Bir denetim yaklaşımı geliştirmek için bir

altyapı ve kurumsal ve proje düzeyindeki

performansları değerlendirmek için bir temel

oluşturmaktadır.

Proje Yönetimi Bilgi

Organı (PMBOK)

Kontrollü Çevrelerdeki

Projeler (PRINCE2)

Otomatik Kontroller Denetim programları; masraflar, kaynak

tahsisi, sorunlar vs.nin gözden geçirilmesini

kolaylaştırır. Portföy yönetimi kontrolleri

kullanıldığı takdirde, bunlar, projeleri bütçelere

ve programlara göre risk öncelik sırasına

koymak amacıyla tüm projeleri listeleyen

raporlar çıkarmak ve “sorunlu projeleri” tespit

etmek için ölçekler kullanmak konusunda

denetçiye kolaylıklar sağlamaktadır.

Program Yönetimi

Kaynak Yönetimi

Sorun Takibi

Tablo-2: Proje Metodolojisi Bileşenleri ve Bunların Denetçiler için Değeri

19

Proje Paydaşları

İç denetçilerin bağlı oldukları kurumun paydaşları nasıl tanımladıkları ve BT projelerine nasıl

dâhil ettiklerini anlamaları gerekmektedir. Paydaşlar, projeyi hayata geçiren kişiler ve

grupların toplamıdır. Uygun paydaşlar bir araya gelerek koordineli bir biçimde çalışmadıkları

takdirde projeler başarıya ulaşamaz. Yönetici paydaşlar, stratejik kılavuzluğun yanı sıra

finansal, politik ve manevi destek sağlamalıdırlar. İşletme ve BT kullanıcıları paydaşları,

koşulların ve nihai ürünün istenilen işletme ihtiyacını karşıladıklarını temin etmektedirler.

Paydaşların sayısı ve türleri kuruma ve projeye göre değişiklik göstermektedir. (Tipik

paydaşların bir listesi için Ek-B’ye bakınız.)

Proje Yönetim Ofisi (PMO) ve İç Denetçi

Kurumun mevcut bir PMO’su, iç denetçinin kurumun proje yönetimi kültürünü,

metodolojisini, standartlarını ve süreçlerini anlaması için kilit bir başlangıç noktası olacaktır.

Birçok firma, kurum çapında proje başarısını yönetmeye ve etkilemeye yardımcı olacak

PMO’lar yürütmektedirler. Proje Yönetimi Enstitüsü’nün yaptığı çalışmalara göre, bir PMO

yürütmenin en önemli nedenleri; proje başarı oranlarını artırmak, uygulamalar için bir

standart oluşturmak ve maliyeti azaltmaktır. Küçük kurumlar PMO olmadan da projeleri etkin

bir şekilde yürütebilmesine karşın, çok sayıda proje yürüten büyük kurumlar PMO’lar

olmadan başarıya ulaşmanın imkansız olduğu düşüneceklerdir.

PMO’nun bir proje yönetimi metodolojisinde oynayabileceği kritik rol nedeniyle, denetçinin

PMO’yla güçlü bir ilişki kurması ve sürdürmesi gerekmektedir. PMO’lar proje denetimlerinde

kilit roller oynayabilirler ve iç denetim birimiyle proje yöneticileri arasında değerli bir

bağlantı görevi görebilirler. Denetçiler, BT proje riski konusundaki görüşlerini PMO’yla

paylaşarak ve iç denetim biriminin PMO’yla ilgili beklentilerini belirleyerek danışmanlık rolü

üstlenebilirler. BT denetim yöneticilerinin:

PMO’nun rolleri ve görevleri;

Proje yönetimi metodolojileri;

BT projesi maliyet ve program performans verileri ve trendleri;

BT projesi başarı/başarısızlık oranları, istatistikleri, ölçekleri ve alınan dersler ve

Tüm denetim projelerinde başarı ya da başarısızlığa neden olan trendleri anlama

arayışına girmeleri gerekmektedir.

Ayrıca, bütçe, risk veya kilit faktörlere göre sınıflandırılan, onaylanan ve fon sağlanan her

yıla ait BT projelerinin bir listesini ve en önemli sistem uygulamalarına yönelik kilometre

taşlarının ve go-live (uygulamaya geçiş) tarihlerinin bir listesini edinme arayışına

girmelidirler.

Proje Portföy Yönetimi

Proje portföy yönetimi (PPM), mantıklı ve bilinçli proje yatırım kararlarının alındığından

emin olmak için projelerin toplu olarak yönetimine atıf yapmaktadır. Kurumlar; daha iyi BT

yatırım kararları almak, işletme gereksinimlerine yeterli yatırım yapılıp yapılmadığından emin

20

olmak ve tüm girişimler ve projelerin değerini kanıtlayarak BT’nin kurumdaki rolünü

artırmak amacıyla PPM’leri kullanmaktadırlar. İç denetçiler, yüksek riskli projeleri ve

kurumun genel önceliklerini tespit etmek için PPM’yi uygulayabilirler.

İç Denetçiler ve Olgunluk Modelleri

Genel anlamıyla olgunluk modelleri, kurumların daha az olgun süreçlerden daha olgun

süreçlere geçiş yapmasına yardımcı olmak için mevcutturlar. Kapasite konusundaki mevcut

zayıflıkları ve boşlukları tespit etmek ve mevcut olgunluk düzeyini belirlemek, ardından, bir

sonraki olgunluk düzeyine çıkmak için bir strateji oluşturmak konularında kuruma yardımcı

olmaktadırlar. Genel fikir; iyi tanımlanmış, sağlam ve tekrarlanabilir süreçler geliştirmektir.

Yazılım geliştirme ve proje yönetimi için spesifik olgunluk modelleri bulunmaktadır

(olgunluk modellerinin bir özeti için Ek-D’ye bakınız.)

Denetçiler, olgunluk modellerini, bir kurumun proje yönetimi ve/veya sistem geliştirme

süreçlerini değerlendirmek için bir temel olarak kullanabilirler. Ancak bu, kurum bir olgunluk

modeli seçtiyse ve süreçlerini modele uygun olarak yapılandırıyorsa bir anlam ifade

etmektedir. Kurum bir olgunluk modeli kullanmayı ilk defa planlıyorsa, iç denetim birimi,

önerilen olgunluk standardı üzerinde bir başlangıç denetimi yapabilir. Bu, olgunluk modelini

kullanmaya başlamadan önce kuruma temel bir fikir sunacaktır.

Denetçiler, kurumun bir olgunluk modeli kullanmasını, kurumda bir BT proje yönetimi

yaklaşımı geliştirmeye yönelik çok olumlu bir adım olarak görmelidirler. Ancak kurumun bir

olgunluk modeli kullanma zorunluluğu yoktur ve maliyetli ve karmaşık olması nedeniyle

birçok kurum tarafından kullanılmamaktadır.

BT Proje Yönetimine Yönelik En İyi Uygulamalar

En iyi uygulamalar, denetçilerin risk değerlendirmeleri ve denetim yaklaşımları için bir

çerçeve oluşturmaları açısından ideal bir başlangıç noktasıdır. En iyi uygulamalar, kaynağını,

hem genel proje yönetimi rehberleri hem de BT geliştirmeye özgü rehberlerden almaktadırlar.

Yaygın olarak kabul gören örneklerden bazıları:

Proje Yönetimi Bilgi Organı (PMBOK).13

Kontrollü Çevrelerde Projeler (PRINCE2).14

Bilgi ve İlgili Teknoloji için Kontrol Amaçları (COBIT).15

Uluslararası Standartlar Kurumu (ISO) Standartları.16

İç denetçiler, kurumların PMBOK, PRINCE2, COBIT veya başka herhangi bir en iyi

uygulamalar grubunu tamamen uygulamalarını beklememelidirler. Bunun yerine, bu

uygulamaların özelleştirilmesini ve kurumun proje yönetimi metodolojisine entegre

edilmelerini beklemelidirler. Ek-E: Genel Proje Yönetimi En İyi Uygulamaları, bu

uygulamaların ve çerçevelerin her biri hakkında daha fazla ayrıntılar sunmaktadır.

13

Proje Yönetimi Bilgi Organı (PMBOK), Proje Yönetimi Enstitüsü, 2008 14

Kontrollü Çevrelerde Projeler (PRINCE2), Birleşik Krallık Hükümet Ticaret Ofisi (OGC), 2008 15

Bilgi ve İlgili Teknoloji için Kontrol Amaçları (COBIT), BT Yönetişim Enstitüsü, 2008 16

Uluslararası Standartlar Enstitüsü (ISO) Standartları, ISO, 2008.

21

Proje Yönetimi Araçları ve Otomasyon

Denetçiler, projelerde, proje yönetimi veya ekip çalışması için çok sayıda otomatik aracın

kullanıldığını görmeyi beklemelidirler. Yüzlerce proje ve/veya münferit proje içeren

portföylerin tümünü yönetmek için yazılımlar kullanılabilir. Denetçiler:

Maliyet, program ve teknik problemler hakkında bilgi;

Proje hakkında karar alma ve sorun takibiyle ilgili görüşler ve

Kaynak kullanımıyla ilgili bilgi

edinmek için bu araçları geliştirebilirler.

Aşağıda, otomasyon ve araçların kullanılabileceği proje alanlarına bazı örnekler

verilmektedir.

Proje Yönetimi

o Program yönetimi

o Maliyet yönetimi

o Gereksinimlerin yönetimi

o Sorunların takibi

o Kaynak yönetimi

o Risk yönetimi

o Kalite yönetimi

o Ekip dayanışması / bilgi paylaşımı

Sistem Geliştirme

o Yazılım arıza takibi

o Yazılım testi

o Kaynak kod yönetimi ve versiyon kontrolü

3.3. BT Çözümü için İstekli ve Hazır Olmak

BT çözümleri, bir yönetim ihtiyacını bir BT sistemine veya uygulamasına dönüştürmek ve

sistemi kontrollü bir biçimde sürdürmek için izlenmesi gereken bir aşamalar dizisini içeren

doğal bir gelişim yaşam döngüsüne sahiptirler. Bu dizi tipik olarak bir yazılım yaşam döngüsü

(SLC) veya yazılım geliştirme yaşam döngüsü (SDLC) olarak anılmaktadır. (Bakınız Şekil-3:

Jenerik Yazılım Geliştirme Yaşam Döngüsü)

Kurumlar, özel yazılım geliştirme için kendi yazılım yaşam döngüsü metodolojilerini veya

danışmanlar veya satıcılar tarafından ürünlerle birlikte kullanılmak üzere sağlanan

metodolojileri kullanabilirler. SDLC’ler, geliştirilen teknolojinin türüne göre değişiklik

gösterebilirler. Aşağıda verilen geliştirme veya uygulama senaryolarının herhangi birine

uyum sağlamak için özelleştirilebilirler:

Şirket-içi kaynaklar kullanarak özel yazılım geliştirmek;

22

Ülke içinden veya dışından (yerel olarak veya yabancı ülkelerden) tamamen veya

kısmen dış kaynak kullanarak özel yazılım geliştirmek;

Satıcı yazılım paketlerini özelleştirmeden olduğu gibi uygulamak veya

Spesifik ihtiyaçları karşılamak için satıcı yazılım paketlerini özelleştirmek.

İyi bilinen SDCL modeli tipleri arasında Şelale Modeli ve Hızlı Uygulama Geliştirme Modeli

bulunmaktadır.

Yine de, iç denetçilerin geliştirme yaşam döngüsü tiplerinden birini görmeyi beklemesi ve

uygun bir biçimde izlenip izlenmediğini tespit etmesi gerekmektedir. Ardından, proje

denetiminin gerçekleştirileceği zamanı ve test için hangi kontrollerin yapılacağını belirlemek

için yaşam döngüsü aşamalarını kullanacaklardır.

Proje uygulama aşaması, sıklıkla, üretim aşamasında sistemin “çalıştırılması” gibi kolay bir

süreç olarak düşünülmektedir. Ancak, proje süresince bir dizi kritik adım ve karar mevcuttur.

Birçok projenin başarısızlığa uğramasının nedeninin, proje ekibinin projede ilerleyebilmek

için bilinçli bir karar almaya yönelik spesifik bir hedef belirlemesi sonucunda proje yönetimi

metodolojisinin bir parçası olarak belirlemesi gereken ara kontrol noktalarının yetersizliği

olduğu savunulmuştur. Girişim kaynak planlama (ERP) sistemi gibi özellikle karmaşık

projelerde, projenin yolunda gittiğinden emin olmak için, önemli proje dönüm noktaları

sonunda spesifik karar noktaları bulunmalıdır.

Dış Danışmanları Değerlendirmek

Özellikle ERP gibi büyük paketlerin uygulanmasında, projenin çözüm veya sistem uygulama

aşamasında, proje yönetim ekibinin bir dış firma veya kaynakla ortaklık kurması oldukça

yaygın görülen bir durumdur. Denetçilerin, özellikle uzun sürecek projelerde, seçilen dış

ortağın ne kadar ortaklık kurabileceğini gözden geçirip geçirilmediğini düşünmesi

gerekmektedir. Ek olarak, öncelikle, tüm tarafların rol ve sorumluluklarının iyi tanımlanması

gerekmektedir, böylece herkes proje çıktılarına yönelik hesap verebilirliğin kimlere ait

olduğunu iyice anlayabilecektir.

Çözüm Tasarımı

Projenin çözüm tasarımı aşamasında, denetçilerin hem iş gerekliliklerinin hem de mevcut ve

gelecekteki iş süreçlerinin dikkate alındığından emin olmaları gerekmektedir. Bu aşamanın

sonunda, proje kapsamının durdurulması ve tüm fonksiyonların sistem başlatma için

gerekenlere göre öncelik sırasına konulması gerekmektedir. Bu önceliklendirme süreci,

genellikle “olması gerekene kıyasla olsa iyi olur” arasında bir karar almak olarak

adlandırılmaktadır. Ayrıca bu aşamada, proje ekibinin çözümü şirket içinde geliştirmek ile

23

şirket-dışı bir paket satın almak arasında bir karar vermesi tipik bir durumdur. Alınan karar ne

olursa olsun, çözüme öncelikle dâhil edilmeleri için hem fonksiyonel hem de güvenlikle ilgili

iç kontrollerin düşünülmesi zorunludur.

Kod, Kurulum ve Veriler

Tasarım aşamasından sonra, sistemin asıl kodlamasını ve kurulumu gözden geçirmek için bir

süreç mevcut olmalıdır. Bir sistemin yaşam döngüsü içerisinde, sistemin takip edebileceği pek

çok farklı şirket-içi kurallar veya rehberler olabilir. Örneğin, sağlam ve güvenli programlama

yöntemlerinin izlenip izlenmediğini tespit etmek için bir kod geliştirme süreci incelemesi

yapılabilir. Sistem kurulumundan sonra yeni ve eski veriler dönüştürülmekte ve/veya

yüklenmektedir, ardından yapılandırma ve yerelleştirme işlemleri yapılmaktadır. Ek olarak,

arayüzler ve kurum içerisindeki diğer sistemlere bağlantılar kurulacaktır. Veri yükleme

mülahazası, özellikle çalışan, müşteri veya satıcı dosyaları gibi her türlü ana verinin

hazırlanması en kritik unsurlardan biridir. Eski bilgilerin devam ettirilebileceğinden emin

olmak önemli olmasına rağmen, yeni sisteme yükleme yapmadan önce açıkça tanımlanmış

verilerden başlamak zorunludur. Diğer bir deyişle, eski sistemde mükerrer veya eski veriler

varsa, dönüştürme işlemi yapmadan önce mümkün olan zamanlarda veriler temizlenmelidir.

Test ve Uygulamaya Geçiş

Bir sonraki kilit adım test aşamasıdır. Testin yalnız son kullanıcıları değil, ayrıca iş akışları,

güvenlik, diğer sistemlere bağlantıları da kapsaması gerekmektedir. Test tamamlanır

tamamlanmaz, uygulamaya geçmeye veya üretime başlamaya hazır olup olunmadığına karar

vermek için bir kontrol noktası olmalıdır. Uygulamaya geçiş yalnızca bir etkinlik olarak

düşünülmemeli; daha çok yeni sistemi, proje ekibinden, son adım olarak sürekli çalıştırmak

ve desteklemekten sorumlu olacak ekibe aktarmak üzere bir aktarma planının mevcut olduğu

bir aşama olarak düşünülmelidir. Bu aşamada, son uygulamayla birlikte ortaya çıkan

öngörülmeyen sorunları hafifletmek amacıyla, projenin beklenmedik durum veya geri kalma

stratejilerini de kapsaması önemlidir. Projenin bu aşamasında, genel olarak, gelişme

göstermek ve projeyi belirlenen zamanda tamamlamak için önemli düzeyde bir baskı vardır

ve sonuç olarak, ayrıntılı planlamanın bazı önemli yönleri görmezden gelinmektedir.

3.4. Kurumsal Yönetim ve Süreç Değişim Yönetimi

Her projede, yönetilmesi gereken en önemli unsur, genellikle kurumsal yönetim ve süreç

değişiklik yönetimidir ve aslında bunlar bir proje için en büyük riski doğurabilmektedirler. En

karmaşık senaryolar arasında, hem bir iş sürecinin hem de ilgili bilgi sistemlerinin

değiştirilmesi bulunmaktadır. Şekil-2’de de gösterildiği gibi iyi proje yönetim yönetişim

süreçleri, etkin değişiklik yönetimini kolaylaştırmaktadır. Değişiklik yönetimi, projenin

kurumu nasıl etkileyeceği ve personelin çalışma şeklini nasıl değiştireceğinin önemini

anlamak da dâhil projenin daha çok yumuşak ya da soyut yönlerini kapsamaktadır. Denetim

perspektifinden bakıldığında, entegre denetim ekibinin operasyonel ve teknik yönlerin

değerlendirildiğini temin etmesi için doğru düzeylerde kullandığı becerilerle birlikte en

gerekli olduğu nokta işte bu burasıdır.

24

İletişimi Yönetmek

Değişiklik yönetiminin en kritik yönlerinden biri; tüm paydaşların projeyi benimsemelerini ve

sahiplenmelerini sağlamak, projenin faydalarını ve gerekçelerini pazarlamak ve son

kullanıcıların beklentilerini yönetmekle başlayarak iletişimi geniş kapsamlı bir biçimde

yönetmektir. Örneğin, yeni sistem hangi süreçleri etkileyecektir ve yapılan değişikliklerin

satıcılar veya müşteriler üzerinde ne gibi etkileri olacaktır? Bu noktaların proje başlangıcında

açıkça belirtilmesi ve uygulama sonrası aşamada iyi yönetilmesi gerekmektedir.

Kurumun Hazır Olması

Kurumun hazır olması için, yeni projeyle birlikte kurumda yapılacak değişikliklerin

değerlendirilmesi ve bu değişikliklere gösterilecek direnç düzeyinin yönetilmesi

gerekmektedir. Bu, özellikle bir ERP uygulamasıyla birleştirilen paylaşımlı hizmet merkezi

gibi, süreçlerin merkezileştirildiği projeler veya dış kaynak kullanılan projelerde doğru bir

savdır. Personelin yeni veya değişen rollere kıyasla sahip oldukları becerileri değerlendirmek

ve kurumun değişiklikleri kabul etmeye hazır olup olmadığını ölçmek amacıyla süreçlerin

veya iş akışlarının açıkça tanımlanıp tanımlanmadığını tespit etmek gerekmektedir.

Eğitim

Tüm yeni sistem uygulamaları için kilit bir başarı faktörü, etkilenecek tüm kullanıcıların

yeterli eğitimi aldıklarından emin olmaktır. Denetim ekibi, eğitimin tam ve zamanında yapılıp

yapılmadığını ve jenerik olmayan kullanıcı rehberlerinin kullanılıp kullanılmadığını

değerlendirmesi gerekmektedir. Ek olarak, BT ekibine ve/veya yardım masası personeline

verilen eğitimin yeni sistemi desteklemek için yeterli olup olmadığını belirlemek amacıyla bu

eğitim gözden geçirilmelidir.

Sistemi Başlatma Sonrası Destek

Denetçilerin hem fonksiyonel hem de teknik konular için bir destek ekibinin kurulmasına

yönelik bir uygulamaya geçiş sonrası destek planının tanımlandığından emin olmaları

gerekmektedir. Destek ekibinin, genellikle normalden çok daha fazla olan uygulamaya geçiş

ve sistemi başlatma sonrası iş yükü için doğru ve yeterli büyüklükte olup olmadığını tespit

etmek amacıyla analiz edilmesi gerekmektedir. Ayrıca, uygulama süresince çıkabilecek bazı

aksiliklere karşı beklenmedik durum planlarının yapılması gerekmektedir.

3.5. Uygulama Sonrası Süreç

Sistemin uygulamaya geçmesinden sonra, bir dengelenme döneminin olması kaçınılmazdır.

Bu süreçte, kullanıcılar sisteme veya yeni fonksiyonlara alışmakta ve önemli sorunlar

çözülmektedir. Bu aşamada, birçoğu değişiklik yönetimi unsurlarıyla ilgili olan birçok riske

dikkat edilmesi gerekmektedir. Diğer bir deyişle, denetçilerin yeni sistemin doğru kullanılıp

kullanılmadığını ve fonksiyonların istenildiği gibi ihtiyaçları karşılayıp karşılamadığını tespit

etmesi gerekmektedir. Yeni bir sistemin uygulanmasının yanı sıra iş süreçlerinde de birçok

değişiklik yapıldığı takdirde, dengelenme süreci oldukça uzun sürebilir. Düşünülecek kilit bir

nokta da, değişikliklere uzun süreli direncin olup olmadığını tespit etmektir. Örneğin, yeni

25

sistem eski sistem kadar kullanıcı dostu olmadığı için kullanıcılar sistemi kullanmaktan

kaçınmakta veya kestirme yollar mı aramaktadırlar? Böyle bir sorun olup olmadığını ortaya

çıkarmak için kullanıcılarla tartışmalar ve görüşmeler yapılabilir.

Uygulama sonrası inceleme için birkaç farklı yaklaşımdan faydalanılabilir. Uygulama sonrası

incelemeler hakkında daha ayrıntılı bilgiler, sayfa 16’daki bölüm 4.3’te bulunabilir.

4. PROJE DENETİMİ PLANLAMA

BT projeleri, sistematik bir süreç kullanılarak yıllık iç denetim planına dâhil edilmelidir.

Şekil-4: Proje Planlama Süreci’nde, hangi projelerin denetleneceğini tespit etmek için

yukarıdan aşağıya bir yaklaşın kullanan bir mantıksal iş akışı ilerleyişi gösterilmektedir.

GTAG 11: BT Denetim Planı’nın Geliştirilmesi’nde açıklanan geniş denetim planlama

süreciyle tutarlıdır.17

İç denetçiler, BT’yle ilgili projelerin hem IT hem de kurumsal yönlerini değerlendirerek

sürece büyük değer katabilir. İç denetçinindüşünmesi gereken kilit sorunlar aşağıdaki gibi

sıralanabilir:

BT proje denetimleri, yıllık denetim planına nasıl dâhil edilmelidir?

İç denetçiler için uygun roller nelerdir?

Hangi, projeler niçin denetlenmelidir?

İç denetçi, hangi tip proje denetimleri yapmalıdır?

4.1. BT Projeleri ve Yıllık İç Denetim Planı

Projeleri yıllık denetim planına veya denetim evrenine dâhil etmek için, iç denetim birimi,

kurumun tüm BT veya teknolojiyle ilgili projelerinin yer aldığı listeye erişebilmelidir. İdeal

olan, denetçilerin proje maliyeti, program, proje riski, proje süresi vs. gibi risk faktörlerini

esas alarak raporlar hazırlayabileceği bir merkezi sistemde tüm projelerin bir listesinin

bulunmasıdır. Böyle bir liste mevcut değilse, BT veya teknolojiyle ilgili projelerle alakalı

sorular, yıllık denetim planlama sırasında hem BT’ye hem de kilit işletme birimlerine

iletilebilir. Ek olarak, denetim evreni ve yıllık denetim planı geliştirdikleri ve münferit

projeler için bir denetim planı hazırladıkları zamanlarda, PMO, denetçilere yardımcı olacak

benzersiz bir bilgi kaynağı olabilir. İç denetçiler, BT proje denetimleri yapmadan önce

kapsam oluşturma ve planlamanın bir parçası olarak PMO’yla yakın ilişkiler kurmalıdırlar.

Aşağıda verilen noktalar, proje riskini kurumsal düzeyde değerlendirirken ve BT’yle ilgili

projelerin yıllık denetim planına nasıl dâhil edileceğine karar verirken denetçilerin

düşünebileceği faydalı olabilecek noktalardır:

Tüm projelerin, riski üst düzeyde değerlendirmek için yeterli destekleyici bilgilerin

olduğu eksiksiz ve doğru bir envanteri bulunmamaktadır.

Firma çapında yayılan pek çok BT projesi bulunmaktadır.

17

GTAG 11: BT Denetim Planını Geliştirmek, sayfa 3.

26

Kurumun; proje yönetişimi için, proje yönetim metodolojileri ve sistem geliştirme

yaşam döngüleri dâhil merkezi metodolojileri ve süreçleri bulunmamaktadır.

Şekil-4: BT Projesi Planlama Süreci, GTAG 11: BT Denetim Planının Geliştirilmesi’nden

uyarlanmıştır.

Üst yönetim, projeleri etkin bir biçimde yürütme kabiliyeti konusunda kendisine

fazlasıyla güvenmektedir, ancak, proje stokları veya merkezileştirilmiş yöntemler

konusunda herhangi bir kanıt sunamamaktadır.

Proje yöneticileri ve üst yönetim, denetçilerin projelere değer katamayacağına ve proje

ekiplerinin kaynak yetersizliği ve yaklaşan proje bitiş tarihleri nedeniyle proje

denetimleriyle ilgilenemeyecek kadar meşgul olduklarına inanmaktadırlar.

4.2. İç Denetim Biriminin Rolü

İç denetim biriminin rolü konusunda akılda tutulması gereken kilit bir nokta, iç denetim

kurumunun doğası ve birimin yalnızca güvenceyle ilgili görevleri yerine getirmek zorunda

olduğu mu, yoksa daha ziyade operasyon veya danışmanlıkla ilgili görevlere de izin verilip

verilmediğidir. IIA tarafından yayımlanan Uluslararası İç Denetim Mesleki Uygulama

Çerçevesi, iç denetim birimine bu görevleri yerine getirmek için gerekli yol gösterici bilgileri

sunmaktadır.

İç denetçiler, sürece erken dâhil olarak ve proje yaşam döngüsü boyunca proje ekibini

destekleyerek projeye anlamlı katkılar sağlayabilir. İç denetçilerden, projeyi, istişari

incelemelerden resmi denetimlere kadar değişen çeşitli farklı kapasiteler konusunda

desteklemesi istenebilir. Bu durum, denetçi bağımsızlığına gelebilecek daha önceden

27

kestirilen zararın ortaya çıkma olasılığını doğurabilir. BT denetçisi, BT çözümündeki

çıkarının (varsa) inceleme tarafsızlığına zarar vermeyeceğini ve sürece katılımının karar

verme aşamasından sorumlu olmadan tavsiye niteliğinde olduğu hakkında makul bir güvence

sağlamalıdır. İç denetçiler, Bilgi Sistemleri Denetim ve Kontrol Derneği’nin (ISACA) Rehber

G17: Denetim-Dışı Rollerin IS Denetçisinin Bağımsızlığına Etkisi başlıklı dokümanını ek bir

kaynak olarak kullanmayı düşünebilirler.18

Denetçi projeye ne kadar erken dâhil olursa o kadar iyi olur. Projenin erken aşamalarında

gerçekleştirilen iç denetimler veya değerlendirmeler çok faydalı ve değerli olabilirler, çünkü

bunlar, sorunları daha erken tespit etmeye ve maliyeti düşürmeye yardımcı olabilirler.

Denetçiler bir sorun tespit ettikleri takdirde, tavsiyeleri sıklıkla otomatik kontrollerin

artırılması veya belki de tasarımda değişiklikler yapılmasını içermektedir. Yazılım geliştirme

çalışmaları sırasında, projenin erken aşamalarında (örneğin, tasarım aşamasında) yapılan

yazılım düzeltmelerinin veya ayarlamalarının, projenin sonraki aşamalarında yapılanlardan

çok daha az maliyetli olduğu tespit edilmiştir. Bir yazılım sorununu yazılım teslim edildikten

sonra bulup düzeltmek, genellikle gereklilikleri belirleme veya tasarım aşamalarında bulup

düzeltmekten 100 kat daha pahalıdır.19

Şekil-5: Proje Yaşam Döngüsü Boyunca Hataları

Düzeltmek İçin Gereken Nispi Maliyet; bir projenin yaşam döngüsü boyunca yazılım

değişikliklerini düzeltmek için gereken çarpıcı nispi maliyeti göstermektedir. Bu, üst yönetimi

iç denetim biriminin sürece erken katılımını desteklemeye ikna etmek için önemli bir unsur

olabilir.

Şekil-5: Proje Yaşam Döngüsü Boyunca Hataları Düzeltmek İçin Gereken Nispi Maliyet.

Uygulayıcılar ve Yöneticiler İçin Yazılım Doğrulama ve Onaylama, İkinci Baskı’dan

uyarlanmıştır. 4.3. Proje Denetimi Tipleri

18

IS Denetim Rehberi: Denetim-Dışı Rollerin IS Denetçisinin Bağımsızlığına Etkisi, Bilgi Sistemleri Denetim ve

Kontrol Derneği, 2003. 19

Steven Rakitin’in izniyle alıntılanmıştır, Yazılım Doğrulama ve Onaylama: Uygulayıcı için Rehber, Norwood,

MA: Artech House Inc., 2001. © 2001 Artech House Inc.

28

İç denetçiler, proje riskine ve kurumun ihtiyaçlarına bağlı olarak çeşitli farklı incelemeler

yapabilirler. Bu GTAG, projeyle ilgili düşünülebilecek en yaygın denetim veya değerlendirme

tiplerinin beşine vurgu yapmaktadır:

Başarı şansını artırmak için proje risk değerlendirmesi;

Kilit aşamalar veya başlatma-öncesi süreçte hazır bulunma değerlendirmesi;

Uygulama sonrası inceleme;

Proje yaşam döngüsü boyunca bir kilit proje aşamasının denetimi ve

Genel proje yönetimi metodoloji değerlendirmesi.

(Her bir maddeye ait örnek denetim mülahazaları, Ek-F’de bulunabilir.)

Tüm iç denetim inceleme tipleri için en önemli mülahaza, görev için doğru becerilere sahip

çalışanlardan oluşan bir kadro oluşturmaktır. Bu aşama, entegre bir iç denetim ekibinin

sağladığı faydaların en belirgin olarak görüldüğü yerdir. Entegre bir ekip kullanmak, projenin

hem fonksiyonel hem de teknik risklerinin inceleme kapsamına alındığını temin etmektedir.

Entegre bir denetim ekibi, hem işletmeyle ilgili hem de teknik becerilere sahip çalışanlardan

oluşmalıdır.

Risk Değerlendirme

Bir risk değerlendirmesi, tipik olarak proje hazırlama aşamasını etkileyecek kilit riskleri tespit

etmek ve tanımlamak ve bu risklerin ne kadar iyi takip edildiğini ve hafifletildiğini belirlemek

amacıyla tüm projelerin tipik olarak gözden geçirilmesini içermektedir. Projenin iyi

ilerlemediğine, maliyetin bütçeyi aştığına veya projede çoktan gecikmelerin olduğuna

yönetimin kanaat getirmesi halinde, bu tip bir gözden geçirme oldukça yaygın olarak

yapılmaktadır.

Hazır Olma Değerlendirmesi

Hazır olma değerlendirmesi; projenin kilit bir aşamasında, genellikle iş vaka etüdü, uyum

aşaması, çözüm tasarımı aşaması veya başlatma öncesi aşamasının tamamlanmasıyla yapılan

bir incelemedir. Bu tip bir incelemenin kilit amacı, her aşamanın tam ve eksiksiz olduğuna

dair güvence vermek ve bir sonraki aşamaya geçmeden önce yeni tespit edilen tüm riskler

veya sorunlardan yönetimin haberdar olduğundan emin olmaktır.

Uygulama-Sonrası İnceleme

Uygulama-sonrası inceleme, yeni sistem uygulamaya konulduktan sonra önceden belirlenmiş

bir noktada yapılmaktadır. Bu tip bir denetim için belirlenen hedef zamanla ilgili düşünülmesi

gereken birçok farklı değişken bulunmaktadır. Bunlar arasında; sistemin dengelenmek için

zamana ihtiyacı olup olmadığı, proje ekibinin hataları düzeltmek için ne kadar süre hazır

bulunacağı, satıcıyla imzalanan sözleşmeyle ilgili mülahazalar ve kullanıcıların dile getirdiği

başlatma-sonrası sorunlar bulunmaktadır.

29

Bir uygulama-sonrası proje incelemesinin yapılmasına yönelik birkaç farklı yaklaşım

mevcuttur. İncelemenin amacı, projenin kurumun proje metodolojisini veya SDLC’yi ne

kadar iyi takip ettiğini değerlendirmek ya da yeni sistemin ne kadar iyi çalıştığını ölçmek

olabilmektedir. Bir uygulama-sonrası incelemesinde entegre bir denetim yaklaşımının

kullanılma ihtimali vardır, çünkü sistemin ve ilgili iş süreçlerinin birlikte incelenmesi

gerekmektedir.

Projeyi başlatma ve iş vaka etüdünün geliştirilmesi sırasında, birçok proje faydası

kaydedilmektedir. Bir fayda gerçekleştirme incelemesi, projenin ulaşılmak istenen faydaları,

tasarrufları veya verimlilik kazançlarını ne kadar iyi gerçekleştirdiğini ölçmeye yönelik

yapılabilecek ve ayarlanabilecek başka tür bir uygulama-sonrası veya proje-sonrası

incelemedir. ISACA’nın G29: Uygulama-Sonrası İnceleme adlı rehberi, bu tip bir inceleme

hakkında spesifik yol gösterici bilgiler sunmaktadır.20

Diğer bir yaklaşım, projenin nihai sonuçlarını aslen belirlenen amaçlarla karşılaştırarak

denetlemek veya proje sonunda çıkarılan derslerin gelecek projelerde kullanılmak üzere tespit

edilmesini sağlamak amacıyla proje sürecinin nasıl yürüdüğünü değerlendirmektir. Ayrıca

denetim ekibi, hem iş süreçlerinin hem de yeni bilgi sistem sisteminin tüm yönlerini veya

fonksiyonlarını kapsamak için bir uçtan uçta süreç incelemesi yapılabilir. Yaklaşım tasarımı

nasıl olursa olsun, sistemi başlattıktan sonra yeterli bir dengelenme periyodu bırakmak

gerekmektedir.

Proje planında ilk olarak dengelenme süresi belirlenmelidir. Dengelenme süresi, sistemin

karmaşıklığına bağlı olarak genellikle ortalama üç ile altı ay arasında sürmektedir. Ayrıca,

denetçilerin, proje ekibinin ne kadar çabuk dağılacağını akılda tutmaları ve proje

dokümantasyonunu ve normal bakım veya sürekli iyileşme aşamasına geçiş sürecini kimlerin

üstleneceğini tespit etmeleri önemlidir. Yeterli dokümantasyon mevcut değilse, proje ekibi

dağıldıktan sonra bir projeyi denetlemek veya bazı kararların niçin alındığını anlamak oldukça

zor olabilir.

Kilit Aşama İncelemesi

Proje sırasında yapılan bir kilit aşama incelemesi, yüksek riskli projelerde sıklıkla kullanılan

proaktif bir yaklaşımdır. Bu inceleme kapsamında, SDLC veya sistem tasarımı incelemeleri

veya örneğin iç denetçinin “kapıda” ya da proje aşamasında sürece katılımının incelemesi

bulunabilir. Kilit amaç, genellikle proje yönetiminin veya SDLC metodolojilerinin ne kadar

yakından takip edildiğini değerlendirmekle ilişkilendirilmektedir. Yukarıda da söz edildiği

gibi, iç denetim birimi, sistem üretim çevresine geçmeden önce, düzelmeler hâlâ kısmen

maliyetli değilken proje ekipleriyle çalışabilir. İç denetim birimi, proje sürecine erken

katılarak projeyi resmi veya resmi olmayan bir şekilde etkileyen sorular veya öneriler

sunabilirler. ISACA’nın bu yapıdaki incelemeleri yürütürken BT denetçisine yol gösterici

20

IS Denetim Rehberi G29: Uygulama-Sonrası İnceleme, Bilgi Sistemleri Denetim ve Kontrol Derneği, 2004.

30

bilgi olarak kaynaklık edebilecek iki adet IS denetim rehberi bulunmaktadır: (1) Rehber G17:

Denetim-Dışı Rollerin IS Denetçisinin Bağımsızlığına Etkisi21

ve (2) Rehber G23: Sistem

Geliştirme Yaşam Döngüsü (SDLC) İncelemesi.22

Proje Yönetimi Değerlendirme Çalışması

Genel proje yönetimi metodolojisini denetlemek, metodolojideki riskleri tespit ederek

zayıflıkları belirleyebilir, bu da kurumun tamamının gelişmesine yardımcı olabilir.

Münferiden denetlenmesi gereken birçok proje olan kurumlarda, bu tip bir incelemede daha

bütüncül bir yaklaşım kullanılmaktadır. Ek olarak, iç denetçi metodolojiyi denetleyerek

münferit projeleri denetlemeye daha hazır olacaktır, çünkü PMO denetimi, kurumun

uygulamalarını anlamak açısından sağlam bir temel sunacaktır.

Denetim proje metodolojilerinin muhtemel amaçları arasında:

Proje yönetim metodolojilerinin yeterliliğini değerlendirmek;

Metodolojinin kurum içerisindeki çok küçükten çok büyüğe kadar tüm BT projelerini

destekleyip desteklemediğini tespit etmek;

PMO tarafından sunulan yönetim düzeyindeki desteğin etkinliğini değerlendirmek (Bu

konu bir PMO yönetmeliğinde veya misyon beyanında açıkça ifade edilebilir).

PMO politikaları, standartları, metodolojileri ve süreçlerinin kurumdaki tüm

projelerde sürekli olarak uygulandığını ve yürütüldüğünü tespit etmek;

PMO’nun istenilen değer düzeyini katma kabiliyetini değerlendirmek;

PMO’da, kurumda yürütülen tüm projelerin eksiksiz bir stokunun bulunup

bulunmadığını tespit etmek ve

PPM süreçlerinin etkin bir şekilde çalışıp çalışmadığını tespit etmek

yer almaktadır.

Proje Denetim Raporları

Bir proje incelemesinden sonra denetim ekibinin hazırladığı rapor, yapılan incelemenin türüne

ve denetim ekibinin sürece dahil olduğu aşamaya bağlı olarak değişebilmektedir. IIA’nın

Uluslararası İç Denetim Mesleki Uygulama Standartları 2400 serileri, sonuçları raporlamak

konusunda yol gösterici bilgiler içermektedir, ancak kurum içerisinde hangi formatın en fazla

işe yaradığını belirlerken inceleme türünün dikkatle düşünülmesi gerekmektedir. Örneğin,

denetim ekibi proje yaşam döngüsü boyunca sürece katılıyorsa, proje yürütme komitesine

iletilen durum güncellemeleri veya bildirilerin formatlarının düşünülmesi gerekebilir. Bir

uygulama sonrası incelemede, özellikle de sistemin tüm fonksiyonları ve temel iş süreçleri

değerlendirildiği takdirde, resmi denetim rapor formatı tercih edilebilir.

21

IS Denetim Rehberi G17: Denetim-Dışı Rollerin IS Denetçisinin Bağımsızlığına Etkisi, Bilgi Sistemleri

Denetim ve Kontrol Derneği, 2003. 22

IS Denetim Rehberi G23: Sistem Geliştirme Yaşam Döngüsü (SDLC) İncelemesi, Bilgi Sistemleri Denetim ve

Kontrol Derneği, 2003.

31

4.4. Dış Denetçi Mülahazaları

BT ve teknolojiyle ilgili projeler kurumun mali durumunu ve operasyonlarını kritik düzeyde

etkileyebileceğinden, dış denetçiler kurumda hangi büyük projelerin yürütülmekte olduğunu

bilmek isteyeceklerdir. Spesifik olarak:

Mali durum raporlaması (örneğin, yeni bir SAP büyük defteri sistemi);

Gelir sağlama (örneğin, sipariş işlemleri);

Stok yönetimi

Mali verileri veya mali veriler sağlayan sistemleri etkileyen büyük işletme veya BT

dönüşümleri veya

2002 ABD Sarbanes-Oxley Kanunu gibi önemli mevzuat koşulları

üzerinde büyük etkileri olan BT projeleriyle ilgileneceklerdir.

İDY, dış denetçilerin BT projeleriyle ilgili riskler konusundaki bakış açılarını anlamak için

onlarla yakın ilişkiler kurmalıdır. Kurumun karşı karşıya kalabileceği büyük risklerden biri,

dış denetçinin büyük projelerden habersiz olması ve yeni sistem çoktan üretime geçtikten

sonra projenin kilit kontrol mülahazalarına vurgu yapmalarıdır. Ancak bu aşamada, mevcut

kontrolleri değiştirmek veya yeni kontroller uygulamak çok daha pahalı olabilmektedir.

Sonuç

Sonuç olarak, Richard B. Lanza, 2002 yılında Internal Auditor dergisinde23

yayımlanan proje

riskleriyle ilgili bir makalesinde, “denetçiler, projeleri, bir yandan etkin risk yönetimi,

masrafların azaltılması ve projelerin kurumsal başarısını temin ederken, diğer yandan yeni

alanlarda temel yetkinliklerinden faydalanılacak fırsatlar olarak düşünmelidirler” şeklinde

belirtmektedir ve bu, bugün için bile hala geçerli bir savdır. Projelerin denetim evrenine dâhil

edilmesi, iç denetim biriminin hem proje yöneticileriyle hem de üst yönetimle işbirliği

kurmasını ve gelecek proje başarısına olumlu şekilde etkilemesini sağlamaktadır.

23

“Teknoloji Projeleri: “İşletmenin En Riskli Alanları”, Internal Auditor, 15 Mayıs 2002, Richard B. Lanza,

CPA, PMP.

32

Ek A – Proje Yönetimi

A.1. Proje Yönetimi Metodolojileri

Bir BT proje yönetimi metodolojisi, proje ekipleri için bir araç takımı gibidir. İyi bir

metodoloji, tüm ilgili proje yönetimi ve kurumsal süreçler arasındaki ilişkileri açıklamaktadır.

Hangi etkinliklerin ne zaman, nasıl ve hangi sırayla yapılması gerektiği hakkında bir yol

haritası sunan tekrarlanabilir süreçleri anlatan geniş kapsamlı bir yapıdır. BT projelerinde ise,

proje yönetimi ve sistem geliştirmeyle ilgili en iyi uygulamaların bir birleşimine

dayanmaktadır. Tipik olarak, belgelenen kilometre taşları, rehberler, teknikler/yöntemler,

şablonlar, örnekler ve rol ve sorumlulukların desteklediği birbiriyle ilişkili aşamalar,

faaliyetler ve görevlerden oluşmaktadır.

Bir metodoloji şunlar için gereklidir:

Bir proje hazırlamak ve yürütmek için kullanılabilecek standart, tekrarlanabilir bir

model yaklaşımı;

Projenin başarı şansını artıracak en iyi uygulamaların kullanılmasını teşvik etmek;

Süreci geliştirebilmek için neler yapıldığını tanımlamak (Yazılım Mühendisliği

Enstitüsü’ne göre (SEI), geliştirilebilmesi veya tekrarlanabilmesi için, öncelikle

sürecin tanımlanması gerekmektedir).

Proje başarı şansını artırmak ve bilinen risk alanlarını azaltmak;

Proje yöneticilerine görevlerini yapabilmeleri için bir yapı sunmak;

En iyi uygulamaların projelerde sistematik olarak kullanıldığını temin etmek;

Proje ürünlerinin etkinliğini değerlendirmek ve çıkarılan derslerle birlikte

metodolojiyi güncellemek için bir yapı sunmak ve

Proje performansını tutarlı bir gereklilikler dizisi ve performans ölçeklerine kıyasla

izlemek için bir yapı sunmak.

Bir metodolojide tipik olarak bulunan bileşen tipleri:

Çerçeveler – aşamalar, faaliyetler ve görevlerden oluşmaktadır.

Rehberler – çıktıları oluşturmak için gereken faaliyetleri tanımlamaktadır.

Teknikler/Yöntemler – Faaliyetlerin nasıl yapılacağına ilişkin yol gösterici bilgiler

sunmaktadır.

Şablonlar ve Örnekler – Tavsiye edilen tekniklerin uygulanmasını

kolaylaştırmaktadır.

Roller – Kimin neyden sorumlu olduğunu belirtmektedir.

Proje Planları - Faaliyetleri proje için hem üst düzeyde hem de ayrıntılı olarak

sıralamaktadır.

A.2. Proje Yönetimi Yaşam Döngüsü

Proje Yönetimi Enstitüsü’ne göre, bir proje yaşam döngüsünde beş aşama bulunmaktadır.

Aşamalar sonucunda üretilen çıktılarla birbirine bağlanmaktadır. Bir aşamanın çıktısı diğeri

için girdi olmaktadır.

33

1. Başlatma – Bir projenin başlatılması için yetki vermek

2. Planlama – Projenin veya aşamanın yapılma amaçlarına ulaşmak için, amaçları

tanımlamak ve düzeltmek ve en iyi alternatif eylem planını seçmek

3. Yürütme – Planı uygulamak için insanları ve diğer kaynakları koordine etmek

4. Kontrol Etme – Planla aralarındaki farkları tespit etmek için, ilerlemeyi düzenli

olarak izleyerek ve ölçerek proje amaçlarına ulaşıldığından emin olunuz. Böylece

gerektiğinde düzeltici eylemler uygulanabilecektir.

5. Kapatma – Projenin veya aşamanın benimsenmesini resmileştirmek ve projeyi

veya aşamayı sistemli bir biçimde sona erdirmek.

Şekil-6: Önemli Süreç Yaşam Döngüsü Süreç Grupları. Kaynak: Proje Yönetim Enstitüsü

Proje Yönetim Bilgi Organı için Bir Rehber (PMBOK® Rehberi) – 2000 Basımı, Proje

Yönetim Enstitüsü, 2000. Telif hakları ve tüm hakları saklıdır. Bu dokümandan alınan veriler

PMI’nin izniyle çoğaltılmıştır.

34

Ek B – BT Proje Paydaşları

Aşağıda, muhtemel paydaşların ve ilgili sorumluluklarının bir listesi verilmiştir. Her projede

bu rollerin hepsi bulunmayacaktır ve bunlar dışında da pek çok muhtemel rol mevcuttur.

Paydaş Sorumluluğu

Yürütme Komitesi (İcrai veya

Teknik)

Yol gösteren ilkeler, strateji ve büyük kararları etkileyen

icrai liderler (işletme ve BT)

Sponsor Projeye finansal kaynaklar veya destek sağlayan kişi

Proje Yöneticisi Genel proje sorumluluğu ve açık otorite ve hesap

verebilirlik çizgileri olan kişi.

Kullanıcı (İşletme, BT vs.) Proje sonunda ortaya çıkan ürünü kullananlar

Proje Ekibi Projeyle ilgili günlük işleri yerine getiren, BT ve işletme

personelinin bir araya gelmesiyle oluşan ekip.

Etkileyenler Projenin kullanılmasıyla doğrudan ilişkili olan, ancak

pozisyonları nedeniyle projeyi olumlu veya olumsuz

etkileyenler.

Proje Yönetim Ofisi Proje yöneticilerini veya diğer ekip üyelerini atayan ofis.

Proje ürününden doğrudan veya dolaylı olarak sorumlu

olabilir.

Uyum Gözden Geçirme

Kurulları

2002 ABD Sarbanes-Oxley Kanunu ve yerel kanunlar gibi,

özel uyum politikalarını veya politika gerekliliklerini

değerlendiren ekip.

BT Güvenliği Nihai sistemin kurumsal güvenlik politikaları veya en iyi

uygulamalara uyacak şekilde BT güvenlik özellikleriyle

tasarlandığını temin eden kişiler.

BT Mimarisi Kurulu Sistemin mevcut veya gelecek altyapıyla uyumlu olduğunu

temin eden ekip.

Danışmanlar ve Satıcılar Geliştirme danışmanları veya uygun sistem satıcıları

(örneğin, SAP, Peoplesoft vs.)

Denetçiler (Finans, BT, İç ve

Dış)

Denetimler gerçekleştiren ve risk konusunda denetçi

perspektifi sunan kişiler.

Tedarik Eden Proje materyallerini ve işgücünü satın alan kişiler.

35

Ek C – PMO’nun Yapısı, Roller ve Sorumluluklar

Proje Yönetim Ofisleri (PMO’lar), tipik bir biçimde organize olmuşlardır ve üç şekilde destek

vermektedirler:

Kurumsal Düzey Verilen Desteğin Türü

Tek Proje 2000 Yılı sorunu gibi tek, çok geniş kapsamlı bir projeyi

veya bir global girişim kaynak planlama sistem

uygulamasını desteklemekte veya tamamen yönetmektedir.

İşletme Birimi Genellikle birçok işletme birimi olan büyük, global bir

kurum içerisinde, tek bir işletme birimi kapsamında birçok

projeyi desteklemektedir.

Stratejik/Global Projenin hangi birime ait olduğuna bakmaksızın bir

kurumdaki bütün projeleri desteklemektedir.

PMO’ların rol ve sorumlulukları kuruma göre değişmektedir ve aşağıda belirtilen unsurların

bazılarını kapsayabilir:

Proje raporlama ve izleme hizmeti sunmaktadır.

İcrai yönetim ve/veya kullanıcıların sürece uyum gösterdiğini temin etmektedir.

Projelerde süreçlerin tutarlı ve tekrarlanabilir olduğunu temin etmektedir.

Projelerde danışmanlık ve akıl hocalığı hizmeti sunmaktadır.

Etkin proje yönetimi için, içinde politikalar, standartlar ve metodolojilerin bulunduğu

bir çerçeve geliştirmekte, uygulamakta ve sürdürmektedir.

Proje yönetimine danışmanlık ve süpervizörlük hizmeti sunmaktadır.

Kuruma, projeleri yönetmek için bir proje yöneticileri havuzu sağlamaktadır.

Çıkarılan dersleri tespit etmek ve dâhil etmek için projelerin son durum incelemelerini

yapmaktadır.

Münferit projelerin denetimlere hazırlanmasına yardımcı olmaktadır.

Proje portföy yönetimi olarak adlandırılabilecek, kurumun tüm projelerinin bulunduğu

koleksiyonun yönetimini desteklemek.

36

Ek D – Olgunluk Modelleri

D.1. Kapasite Olgunluk Modeli

Yaygın olarak kabul edilen ilk olgunluk modeli, Amerika Birleşik Devletleri’nde Carnegie

Mellon Üniversitesi’nde Yazılım Mühendisliği Enstitüsü tarafından geliştirilen Kapasite

Olgunluk Modeli’dir (CMM). Bu model, yazılım geliştirmeye odaklanmıştır.

CMM ve günümüzde birçok başka olgunluk modeli, aşağıdaki olgunluk düzeylerini

kullanmaktadır. Modelin sunduğu fikir, 1. Düzeyden 5. Düzeye doğru hareket etmektir.

1. Düzey: Başlangıç – Birkaç süreç tanımlanmaktadır.

2. Düzey: Tekrarlanabilir – Temel proje yönetim süreçleri belirlenmektedir.

3. Düzey: Tanımlanmış – Projeler, kurumun standart yazılım sürecinin onaylanmış ve

düzenlenmiş bir versiyonunu kullanmaktadır.

4. Düzey: Yönetilmiş – Detaylı ölçümler tanımlanmakta ve kontrol edilmektedir.

5. Düzey: Optimize Etme – Sürekli gelişim sağlanmaktadır.

D.2. Proje Yönetimi Olgunluk Modelleri

Proje yönetimi olgunluk modelleri, güncel proje yönetim kapasitelerini değerlendirmek ve

gelişime yönelik bir strateji geliştirmek için bir süreç ve yapı sunmaktadırlar. Aşağıda, birçok

proje yönetimi olgunluk modellerinden iki örnek verilmektedir:

Olgunluk Modeli Kaynak Tanım

Portföy, Program ve

Proje Yönetim

Olgunluk Modeli

(P3M3)

Birleşik Krallık

Hükümet Ticaret Ofisi

(OGC)

5 standart olgunluk katmanını değerlendirmek ve

bu katmanlar arasında geçiş yapmak için, 32 Kilit

Performans Alanını temel olarak kullanmaktadır.

Kurumsal Proje

Yönetim Olgunluk

Modeli (OPM3)

Proje Yönetim

Enstitüsü (PMI)

Bir kurumun olgunluğunu değerlendirmek için,

birbiriyle kesişen üç unsuru (bilgi, değerlendirme

ve gelişim) esas alarak üst düzeyde yapılanmış bir

yaklaşım kullanmaktadır.

D.3. Sistem Geliştirme Olgunluk Modelleri

Sistem geliştirme olgunluk modelleri, mevcut sistem geliştirme kapasitelerini değerlendirmek

ve gelişime yönelik bir strateji geliştirmek için bir süreç ve yapı sunmaktadır. Aşağıda, birçok

sistem geliştirme olgunluk modellerinden iki örnek verilmektedir:

Olgunluk Modeli Kaynak Tanım

Gelişim Amaçlı Kapasite

Olgunluk Modeli

Entegrasyonu (CMMI)

Yazılım Mühendisliği

Enstitüsü (SEI)

İlk büyük yazılım geliştirme olgunluk modeli

SEI tarafından geliştirilmiştir. CMMI, bu

modelin yeni nesil bir modelidir.

Yazılım Süreci

Geliştirme ve Kapasite

Belirleme (SPICE)

Uluslararası Standartlar

Kurumu (ISO)

ISO 15504 olarak da bilinen bu standart,

yazılım süreçlerinin değerlendirilmesi için bir

çerçeve sunmakta ve bu standardın süreç

kıyaslama için açık bir model ortaya koyması

amaçlanmaktadır.

37

Ek E – Genel Proje Yönetimi En İyi Uygulamaları

E.1. PMBOK ve PRINCE2

Proje yönetimi en iyi uygulamaları, esas olarak aşağıda verilen iki rehberde

düzenlenmektedir.

En İyi Uygulama Kaynak Tanım

Proje Yönetimi Bilgi

Organı (PMBOK)

Proje Yönetimi

Enstitüsü (PMI)

Kurum içerisinde kabul edilen bir standarttır

(IEEE Std 1490-2003). Dünyada en yaygın

olarak kabul edilen proje yönetim

uygulamaları dizisidir.

Kontrollü Çevrelerdeki

Projeler (PRINCE2)

Birleşik Krallık

Hükümet Ticaret Ofisi

(OGC)

Proje yönetimi için önerilen yapılandırılmış

bir yaklaşımdır. Birleşik Krallık’ta ve diğer

Avrupa ülkelerinde fiili olarak kullanılan bir

standarttır.

Bu rehberlerin hiçbiri spesifik olarak BT projelerini hedeflememektedir veya bağımsız proje

yönetimi araçları olmaları istenmemektedir. Bu rehberler, çok sayıda sektör ve departmanda

uygulanabilecek pek çok önemli uygulama ve rehber dizileridirler ve kurumun ihtiyaçlarına

uygun olarak ayarlanmaları ve özelleştirilmeleri istenmektedir. Bunlar, kurum ister bir köprü

kuruyor olsun, ister yeni bir hizmet geliştiriyor olsun, isterse de yeni bir yazılım uygulaması

yürütsün geçerlidir ve kullanılabilmektedir. PMBOK ve PRINCE2 pek çok yönden

farklıdırlar. Ancak her ikisi de, bir BT proje yönetim çerçevesi geliştirmek için eşit düzeyde

kabul edilebilir altyapılar sunmaktadırlar.

PMBOK

PMI’ye göre, PMBOK, proje yönetimi mesleğinde genel olarak kabul gören bilgi özetlerini

açıklamaktadır. “Genel olarak kabul gören”, açıklanan bilgi ve uygulamaların çoğu zaman

çoğu proje için geçerli ve uygulanabilir olması demektir ve bu bilgi ve uygulamaların değeri

ve faydaları konusunda yaygın bir görüş birliği vardır. PMBOK’nin genel amacı, proje

yönetimi mesleği içerisinde ortak bir dil oluşturmak ve proje yönetimi hakkındaki konuşmalar

ve yazılarla ilgili uygulamalar sunmaktır.

PMBOK’nin başlangıç noktası, altı kilit proje bilgi alanıdır:

Entegrasyon Yönetimi

Kapsam Yönetimi

Zaman Yönetimi

Maliyet Yönetimi

Kalite Yönetimi

İnsan Kaynakları Yönetimi

İletişim Yönetimi

Risk Yönetimi

Tedarik Yönetimi

38

Bu bilgi alanları da kendi içlerinde 44 detaylı sürece ayrılarak yeniden düzenlenmektedirler.

PMBOK, ayrıca, proje portföy yönetimi ve proje yönetim ofisleriyle ilgili yol gösterici

bilgiler sunmaktadır.

PMBOK, Uluslararası Standartlar Kurumu (ISO) ve Kapasite Olgunluk Modeli (CMM)

standartlarına da uygundur. PMI, Proje Yönetim Mesleği (PMP) Sertifikasyonu’nu

yönetmektedir. Amerika Birleşik Devletleri ve Birleşik Krallık’taki pek çok kamu kurumu ve

finansal kurum, yöneticilerinin PMP sertifikasına sahip olmasını şart koşmaktadır.

PRINCE2

PRINCE2’nin özgün, özelleştirilebilir ve uçtan uca bir proje yönetim metodolojisi olması

amaçlanmaktadır.

İş Vaka Etüdü

Kurum

Planlar

Kontroller

Risk Yönetimi

Kalite

Yapılandırma Yönetimi

Değişiklik Kontrolü

PRINCE2, her süreci, bir proje süresince uygulanması gereken elzem bileşenlerin oluşturduğu

bir çerçeveye yerleştirmektedir. Projelerin nasıl organize edilmesi, yönetilmesi ve kontrol

edilmesi gerektiğini kapsamaktadır.

E.2. ISO Standartları

ISO Standartları, kalite veya yapı yönetimi gibi süreç alanları veya spesifik sektörler hakkında

proje yönetimi en iyi uygulamalarını bünyesine dâhil etmekte ve ele almaktadır. Ancak,

ISO’nun genel proje yönetimi uygulamalarıyla ilgili bir standardı bulunmamaktadır. Aşağıda,

proje yönetimi uygulamalarını kapsayan üç örnek verilmektedir:

ISO 1006: 2003 proje yönetimi süreçlerinde kaliteyle ilgili yol gösterici bilgiler

sunmaktadır.

ISO 9001: 2005 hizmet ve ürün geliştirme kalitesini ele almaktadır.

ISO 15504 proje yönetimi olgunluğunu ele almaktadır.

Kurumlarda ISO standartlarını kullanan iç denetçilerin, hangi ISO standartlarının bağlı

oldukları sektöre ve kurumla ilgili olduğunu bildiklerinden emin olmaları gerekmektedir. Bu

GTAG kapsamında ele alınması mümkün olmayacak ssyıda fazla ISO standardı

bulunmaktadır.

39

E.3 Proje Yönetimi için Geçerli Olan COBIT Bölümleri

Bilgi ve İlgili Teknoloji için Kontrol Amaçları (COBIT), BT Yönetişim Enstitüsü tarafından

Bilgi Sistemleri Denetim ve Kontrol Derneği’nin katkılarıyla geliştirilmiştir. COBIT, BT

projelerini yönetmek için kullanılabilecek kontrol hedeflerini içeren geniş ve kapsamlı bir BT

yönetişimi çerçevesidir.

Proje denetimlerini planlamak için COBIT’ten faydalanırken iç denetçinin COBIT

kapsamındaki hangi spesifik kontrol hedeflerinin denetim amaçlarını en iyi şekilde

desteklediğini tespit etmesi gerekmektedir. Bir proje incelemesi sırasında projeyle en alakalı

olabilecek dört alan içerisindeki konulara aşağıda vurguladık, ancak diğer konular da projeyle

ilgili olabilmektedir.

Planla ve Organizasyon

o Kurum-Dışı Gerekliliklere Uyum Sağlamak

o Projeleri Yönetmek

o Kaliteyi Yönetmek

Elde Etmek ve Uygulamak

o Otomatik Çözümleri Tespit Etmek

o Uygulama Yazılımlarını Elde Etmek ve Sürdürmek

o Teknoloji Altyapısını Elde Etmek ve Sürdürmek

o Prosedürleri Elde Etmek ve Sürdürmek

o Sistemleri Kurmak ve Onay Vermek

o Değişiklikleri Yönetmek

Temin Etmek ve Desteklemek

o Hizmet Düzeylerini Tanımlamak ve Yönetmek

o Üçüncü Şahıslar Tarafından Tedarik Edilen Hizmetleri Yönetmek

o Performans ve Kapasiteyi Yönetmek

o Sürekli Hizmeti Temin Etmek

o Sistemlerin Güvenliğini Temin Etmek

o Kullanıcıları Yetiştirmek ve Eğitmek

İzlemek ve Değerlendirmek

o BT Performansını İzlemek ve Değerlendirmek

o Kurum-İçi Kontrolü İzlemek ve Değerlendirmek

E.4 VAL IT

BT Yönetişim Enstitüsü’nün Val IT Çerçevesi, bir projenin kurumsal değerini değerlendirmek

konusunda denetçilere güçlü bir araç sunmaktadır. Val IT, yönetimin tüm düzeylerine BT

yatırımlarından değer elde etmeyi optimize etmek konusunda yardımcı olan geniş kapsamlı,

40

tutarlı ve mantıklı bir yaklaşım sunmaktadır.24

Denetçiler, bu çerçeveyi kendi denetim

programlarını yapılandırmak ve bir projenin kurumsal değerini değerlendirmek için bir temel

olarak kullanabilirler.

EK F – İç Denetçinin Bir BT Projesini Gözden Geçirmek Konusundaki Soruları

Aşağıdaki tablo, bu GTAG’nin tüm bölümlerinde vurgulanan beş kilit odak alanının

değerlendirilmesi sırasında kullanılabilecek denetim soruları için önerilen bir listedir. Bu

sorular, Lafarge şirketine ait bir iç denetim çalışma programından uyarlanmıştır.

24

VAL IT, BT Yönetişim Enstitüsü, 2008.

41

İş Vaka Etüdü ve Uyum

Alan Kriterler

1 – İş Vaka Etüdü – Yatırım / Faydanın Gerçekleşme Durumu

1.1 İş Vaka Etüdü

Yönetimi

Proje için üzerinde karara varılmış bir iş vaka etüdü mevcuttur.

Güncellenmektedir ve bilgi elde edildikçe daha küçük ayrıntıları

da kapsamaktadır.

Maliyet ve kazançlar hakkında gerçekçi varsayımlar öne

sürülmektedir.

Varsayımlar belgelenmektedir ve üzerinde anlaşmaya varılmıştır.

Proje ilerledikçe varsayımlar etkin bir şekilde kanıtlanabilir veya

çürütülebilir ve nihayetinde uygun adımlar atılabilir.

1.2 Proje Maliyeti Proje yönetim ekibi tahminler konusunda kendine

güvenmektedir.

Tüm yaygın çalışma bölümleri için standart bir tahmin modeli

kullanılmaktadır.

Modeli kimlerin kabul etmesi ve anlaması gerektiği açıktır.

Yaklaşım, çevre vb. olguları test etmeye olanak tanımak

amacıyla geliştirme projelerini hızlandırmak için ekstra bütçe

tahsis edilmiştir.

Hem personel hem de personel olmayan kişilerden kaynaklanan

masraflar (kurum dışı/kurum içi kaynaklardan alınan

donanım/yazılımlar, geliştirmeler, uçtan uca testler, kalite

güvence, fayda gerçekleştirme takibi, satıcı maliyeti, işletim

maliyeti) için bütçeye tahminler ilave edilmektedir.

Hangi beklenmedik durum eyleminin uygulanacağına ilişkin

tanımlar mevcuttur. Bir sorun ortaya çıktığı takdirde, bu

sorununun nasıl ele alınacağına ilişkin bir plan vardır.

Tahminler, kalifiye bir üçüncü kişi tarafından gözden

geçirilmiştir.

1.3 Geçmiş Orijinal iş vaka etüdünden itibaren proje maliyetinde

değişiklikler yapılmıştır.

Değişiklikler yapıldıysa, bu değişikliklerin nedenini anlayınız.

1.4 Maliyet

Zamanlaması

Maliyet için tahmin edilen zamanlama uygundur. Bazı masrafları

ertelemenin mümkün olup olmadığını inceleyip anlayınız.

Maliyet zamanlamasında değişiklik yapıldıysa, bu değişikliklerin

nedenini anlayınız.

1.5 Fayda Türleri Fayda türleri (örneğin maliyet düşürme, gelir artışı, kalitatif)

açıkça belirtilmiştir.

Faydaların gerçekleştirilmesi dış faktörlere bağlıdır.

Bağımlılıklara nasıl bir yaklaşım sergilemek gerektiği

tanımlanmaktadır.

Faydalar projenin güncel kapsamına uygundur.

42

İş Vaka Etüdü ve Uyum

Alan Kriterler

1.6 Faydaların

Gerçekleştirilmesi

Faydaların nasıl ölçüleceği açıktır (örneğin doğrudan toplam

maliyeti azaltma, personel sayısını azaltma veya yeniden maliyet

dağıtımı)

Faydaları gerçekleştirmek için kimin neyi yapacağına ilişkin

sorumluluklar açıkça tanımlanmıştır.

Sahipler, faydaların makul ve ulaşılabilir olduğunu onaylamıştır.

1.7 Zaman Planı Fayda gerçekleştirme için bir zaman çizelgesi belirlenmiştir.

Zamanlama uygun görünmektedir.

Faydaları daha hızlı gerçekleştirmenin mümkün olup olmadığını

araştırınız.

2 – Proje Planı ve Yaklaşımlar

2.1 Amaç ve Kapsam Projenin kapsamı açıkça tanımlanmıştır ve yeterli düzeyde

ayrıntı içermektedir.

Güncel ve kurumun tümüne bildirilmiş bir proje yönetmeliği

mevcuttur.

Hem iş hem de proje genel olarak iyice anlaşılmıştır.

Proje başlangıcında tasarlanan, kapsamda değişiklik yapmaya

yönelik üzerinde anlaşılmış bir prosedür mevcuttur.

2.2 Tahminler, zaman

çizelgesi ve

kapsam

Güncel tahminler proje grubu, sponsor, proje yürütme grubu ve

proje ofisine açıkça bildirilmiştir.

Tahminlerin zaman içinde değişip değişmediğini ve bunun

nedenini gözden geçiriniz ve anlayınız.

Proje, iş vaka etüdü güncellemelerine göre yeniden

değerlendirildi.

2.3 Kurum Projedeki her rol tanımlanmaktadır.

Proje organizasyonu tanımlanmaktadır.

Projeye katılan herkes rolünü bilmekte ve anlamaktadır.

Proje başarısına ve etkisine ilişkin bir saik olup olmadığını

anlayınız.

2.4 Proje Çıktıları Aşamalardaki her bir proje çıktısının içeriği ve yapısı

belgelenmektedir.

Proje çıktılarının amacı açıkça anlaşılmakta ve belgelenmektedir.

Projeyi imzalayan tüm taraflar gereken proje çıktılarının

onaylanması gerektiğini bilmektedirler.

Proje çıktılarının formatı projeyi imzalayan taraflarla tartışılmış

ve üzerinde anlaşmaya varılmıştır.

Kilit proje çıktıları uygun uzmanlar tarafından gözden

geçirilmiştir.

2.5 Bağımlılıklar Proje dışındaki görevler açıkça dokümante edilmiş ve

anlaşılmıştır. Bu görevlere ait planlar geliştirilmiş ve üzerinde

anlaşmaya varılmıştır.

Kontrol noktalarıyla birlikte proje ürünleri önceden kontrol

edilmektedir.

Planlama varsayımları anlaşılmakta, dokümante edilmekte ve

üzerinde anlaşmaya varılmaktadır.

43

İş Vaka Etüdü ve Uyum

Alan Kriterler

2.6 Zaman planı ve

aktiviteler

Tüm alt-proje planlarını birbirine bağlayan bir genel proje planı

mevcuttur.

Proje kapsamındaki her bir veri akışının gözle görülür kilometre

taşlarına sahip detaylı bir planı vardır. Bunun yalnızca kritik

alanlar için geçerli olup olmadığını kontrol ediniz.

Her alanın son ürün ve son ürüne ulaşmak için neyin gerektiğine

ilişkin açık ve kesin bir görüşü vardır.

Ana iş bölümleri tanımlanmış ve aralarındaki ilişkiler dokümante

edilmiştir.

Her bir iş bölümünün açık ve kesin bir odak noktası ve sahibi

vardır.

Tüm projeler-arası ve dış bağımlılıklar belirlenmiş ve bitiş

tarihleri ile sahipler tanımlanmıştır.

Metodoloji, proje çıktıları, çevre vb. unsurları kanıtlamak için bir

hızlandırılmış veya pilot proje mevcuttur.

Pilot proje çalışması küçük ölçekli, belirli ve temsilidir.

İş bölümleri sahipleri planları kabul edip onaylamışlardır.

Çalışma günleri/haftaları, tatillere/eğitime izin verecek şekilde

planlanmışlardır.

Plan, öğrenme eğrilerini/bilgi transferini yansıtmaktadır.

Plan, her bir ana iş bölümü arasında ve her aşamanın sonunda,

beklenmedik durumlara karşı program uzatmaya izin

vermektedir.

Plan, aşamaya hazırlanma görevleri (örneğin çevre, standartlar

ve prosedürler) için yeterli bir hazırlanma süresini

kapsamaktadır.

Plana uygun gözden geçirmeler ve onay süresi dâhil

edilmektedir.

3 – Proje İletişimi ve Koordinasyonu

3.1 İletişim ve

Değişiklik

Yönetimi

Projede görev alan herkes projenin amacının ve olayların zaman

çizelgesinin farkındadır.

Projede görev alan herkes projenin kendisini nasıl

etkileyeceğinin farkındadır.

3.2 Kurum Kurumdaki her bir rol tanımlanmıştır.

Projede görev alan herkes rolünün bir bütün olarak prosesle ne

şekilde bağlantılı olduğunu bilmektedir.

3.3 Bağımlılıklar Departmanlar-arası ve dış bağımlılıkların tümü belirlenmiş ve

tanımlanmıştır.

Yönetim, proje çalışması için gerekli tüm kaynakları tahsis

etmektedir.

Yönetim, ihtilaf doğurdukları takdirde diğer projeleri/alanları

durdurmaya rıza göstermektedir.

3.4 Paylaşılan

Programlar

Projenin, etkilenen her alandan sponsorları ve temsilcileri vardır.

44

İş Vaka Etüdü ve Uyum

Alan Kriterler

3.5 Güncel Durum Projenin zaman, maliyet ve kapsam açısından güncel durumunu

ve proje tanımından sapmalar olup olmadığını inceleyip

anlayınız.

Durumla ilgili kilit sorun ve kaygıları anlayınız.

Sapmaların niçin ortaya çıktığını anlayınız.

Sapmaların altında yatan nedenler, bu sapmalar ortaya çıkmadan

önce risk olarak tanımlanmıştır.

Sapmalar, riskler ve sorunları ele almak amacıyla düzeltici

eylemlerde bulunulmuştur.

3.6 Çalışma Planı Çalışma planı düzenli olarak güncellenmiştir.

Proje tahminleri doğrudur ve kilit kilometre taşlarına tam

zamanında ulaşılmıştır.

Tamamlanacak kilit görevler tanımlanmakta ve projenin

uygulamaya geçirilmesi için alınacak kritik yol veya gerekenler

listesi belirlenip tanımlanmaktadır.

Ortaya çıkmaları beklendiği takdirde aşırılıkları ele almak için

bir plan geliştirilmiştir.

3.7 Risk Yönetimi Bir risk değerlendirmesi yapılmış, dokümante edilmiş ve

iletilmiştir.

Risk hafifletme eylemlerini/beklenmedik durum planlarını ve

bunlardan sorumlu kişileri kapsamaktadır.

Riskler işletme tarafından anlaşılmıştır.

Riskler ve bu riskleri hafifletecek eylemler proaktif olarak

yönetilmektedir.

Riskler işletmeyle birlikte düzenli olarak gözden geçirilmektedir.

Sorunları çözecek kişiler açıkça belirtilmiştir.

3.8 Diğer

projeler/alanlara

bağımlılıklar

Planda, diğer işletme/sistemlere ait projelerden kaynaklanan

değişikliklerin koordinasyonu için bir mekanizma dâhil

etmektedir.

Destek alanları için hizmet seviyesi sözleşmeleri belirlendi.

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

4 – Proses Tasarımı

4.1 İş Kapsamı İşletme birimleri, lokasyonları ve işletme kuralları bakımından

kapsam tanımlanmakta ve doğrulanmaktadır.

4.2 Proses ve Destek

Tasarımı

Proses tasarımı, iş senaryoları ve iş prosesi tasarım

dokümanlarıyla dokümante edilmektedir.

İş senaryoları dokümante edilmekte, başarıyla test edilmekte ve

işletme temsilcileri tarafından onaylanmaktadır.

5 – Konfigürasyon ve Geliştirmeler

5.1 Çeviri Tüm ekranlar ve özelleştirmeler dokümante edilmektedir.

5.2 Konfigürasyon Kritik tabloların konfigürasyonunun tam olduğunu ve eksiksiz

dokümante edildiğini tespit etmek amacıyla bir inceleme

yapılmaktadır.

45

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

5.3 Programlar Fonksiyonel tasarım tam ve günceldir ve işletmeye

temsilcileriyle üzerinde anlaşmaya varılmıştır.

Teknik tasarım tam ve spesifikasyonlara uygundur, birim testten

başarıyla geçmiştir ve kabulü proje ekibi tarafından test

edilmektedir.

Standartlara göre spesifik programlar geliştirilmektedir.

Spesifik programlar birim testten geçirilmektedirler.

Programlar üretim platformuna veya çevresine taşınmaktadır.

5.4 Arayüzler Arayüzlerin fonksiyonel tasarımları tam ve güncel olup kabul

edilmişlerdir.

Ara yüzlerin teknik tasarımları tam ve günceldirler.

Tasarıma uygun raporlar geliştirilmekte, başarıyla birim-

testinden geçirilmekte ve proje ekibi tarafından kabul

edilmektedir.

Arayüzler üretim platformuyla birlikte “uçtan uca” test

edilmektedirler.

Fonksiyonel hata düzeltme prosesi tanımlanmakta,

geliştirilmekte ve test edilmektedir.

Ara yüzlerle ilgili önemli “acil” veya “büyük” sorunlar

bulunmamaktadır.

6 – Kullanıcı Kabul Testleri

6.1 Kullanıcı Kabul

Testleri

Tüm iş senaryoları başarıyla yapılmış ve onaylanmıştır. Tüm

kullanıcı kabul testleri tamdır ve senaryolar onaylanmıştır.

İşletme, gerçekçi bir test yapıldığından emin olmak için sürece

yeterince katılmaktadır.

6.2 Sorunlar Listesi Sorunlar listesinde belirtilen tüm fonksiyon boşlukları kapatılmış

ve çözümler üzerinde anlaşmaya varılmıştır.

6.3 Yığın Programı Proje ekibi ile teknik ekiple birlikte günlük, haftalık, aylık, üç-

aylık ve yıllık yığın programları tasarlanmakta ve

doğrulanmaktadır.

Görev başarısızlığıyla ilgili talimatlar, fonksiyonel bir

perspektiften açıklanmaktadır (örneğin, görevi atlama, ertesi gün

yeniden yürütme veya programı bekletme).

6.4 Projeyi

uygulamaya geçiş

sırasında

çözülmesi

planlanan

sorunlar

Fonksiyonel ekip liderleri kilit işletme temsilcileriyle birlikte

hangi sorunların projenin uygulamaya başlanmasına kadar

çözülmeyeceğine karar vermiş ve gerekirse geçici çözümler

tanımlanmıştır.

Gerektiğinde geçici çözümler tanımlanmakta ve eğitim ve

yardım masası/destek gruplarına iletilmektedir.

46

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

7 – Veri Dönüştürme ve Cut-Over

7.1 Veri Dönüştürme

Planı

Veri dönüştürme planı ve dönüştürülen verilerin kalitesi,

dönüştürme denemeleri ve çalıştırma denemeleriyle

kanıtlanmıştır.

Dönüştürülen veriler eski sistemlerdeki verilerle uyuşmaktadır.

Çalıştırma denemeleriyle dönüştürülen verilerin kalitesi veri

sahipleri tarafından doğrulanmaktadır.

Dönüştürme plan bağımlılıkları ve kritik yollar test edilmektedir.

Manuel veri yüklemeleri/kontrolü için gereken profiller

mevcuttur ve bunlara gereken erişim sağlanmaktadır.

Çalıştırma denemeleriyle ilgili önemli “acil” veya “büyük”

sorunlar bulunmamaktadır.

7.2 Paralel Veri

Bakımı

Paralel bakımın gerekli olduğu tüm verilere yönelik prosedürler

yazılı olarak mevcuttur.

Paralel bakımın doğru yapıldığından emin olmak için kontroller

mevcuttur.

7.3 Veri Yükleme Projeyi uygulamaya geçiş öncesi tüm veri yüklemeleri

gerçekleştirilmiştir.

Eski yığın programı hazırdır.

Eski erişim profilleri, kullanıcıların yanlışlıkla eski sistemleri

kullanmalarını engellemek amacıyla değiştirilmektedir.

Devam/bırak toplantılarının zamanı ve katılacak kişilere karar

verilmiştir.

Geri kalma planları geliştirilmiş ve üzerinde anlaşmaya

varılmıştır.

7.5 Mutabakat Hesap bakiyeleri ile eski sistemlerin mutabakatı yapılır.

Bakiyeler yüklenir ve bu bakiyelerin eski sistemle mutabakatı

yapılır.

Uyuşmazlıkları açıklamak veya düzeltmek için prosedürler

mevcuttur.

8 – Teknik Altyapı

8.1 Kullanıcı

Arayüzü

Tüm kullanıcı konumları belirlenmiştir.

Her bir bilgisayara kullanıcı arayüzü kurulmuş ve kontrol

edilmiştir.

Oturum açma prosedürleri kontrol edilmiştir.

Tüm güncelleme prosedürleri dokümante edilmekte ve

iletilmektedir.

8.2 Yazıcılar Tüm yazıcı konumları belirlenmiş ve yazıcılar kurulup test

edilmiştir.

Tüm yazıcılar farklı sistemlere kuruludur.

Tüm yazıcılar farklı sistemlerden yazıcı çıktısı alabilmektedir.

8.3 Elektronik

Çıktılar

Tüm faks ve diğer elektronik çıktı formatları test edilmekte ve

üzerinde anlaşmaya varılmaktadır.

Kurum-dışı faks hattı ve elektronik veri değiş tokuşu (EDI)

alıcıları için bir üretim testi tamamlanmaktadır.

47

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

8.4 Yığın Programı Günlük ve aylık yığın programları kontrol edilmektedir.

Ara yüzlere ilişkin tüm sunucu/dizin hedefleri, üretim

sistemlerine işaret edecek şekilde kurulmuşlardır.

Önemli “acil” veya “büyük” bir sorun bulunmamaktadır.

8.5 Hata Düzeltme

Prosedürleri

Hataların günlüğe kaydedildiğini kontrol etmeye ilişkin

prosedürler (yığın arayüzü) mevcuttur.

Yığın kesintisini yeniden başlatma prosedürleri üzerinde

anlaşmaya varılmış ve bunlar test edilmiştir.

Hataların işletmeye iletilmesine ilişkin prosedürler üzerinde

anlaşmaya varılmıştır.

8.6 İletişim

Bağlantıları

Tüm iletişim bağlantıları (örneğin LAN, WAN) test edilmiştir.

Geniş bant, en yüksek veri hacimlerini desteklemektedir.

Geri kalma prosedürleri mevcuttur ve test edilmektedir.

8.7 Sistem

Boyutlandırma

Genel teknik mimarinin bir parçasını oluşturan tüm altyapı

bileşenleri boyutlandırılmakta ve en yoğun aktivite ile tahmin

edilen büyüme hızına uyum sağlayacak şekilde ayarlanıştır.

Donanım, yazılım ve uygulamalar, uygulamaya geçişe uygun

olarak ayarlanmıştır.

8.8 Performans

Testleri

Performans testleri yapılmıştır ve performans kilit iş süreçleri

için uygundur.

8.9 Sistem

Performansı

Uygulamaya geçiş sonrası, çevrim-içi ve yığın performans

izleme ve ayarlama prosedürleri mevcuttur.

8.10 Afetten

Toparlanma

Çalışmama sürelerine ilişkin prosedürler ve bir afetten

toparlanma planı mevcuttur.

Prosedürler başarıyla test edilmektedir.

8.11 Sisteme çevrim-

içi ulaşılabilirlik

ve bakım zaman

dilimleri

Sisteme çevrim-içi ulaşılabilirlik ve bakım zaman dilimleri

konusunda işletmeyle anlaşmaya varılmıştır.

8.12 Güvenlik

Profilleri

BT destek personeli için güvenlik profilleri tanımlanmış ve

uygulamaya konulmuştur.

Üretim çevresinin güvenliği sağlanmıştır.

8.13 Arayüzler Arayüz teknik kurulumu tamdır ve test edilmiştir.

9 – İş Simülasyonu

9.1 Hazırlık Tüm iş senaryoları yazılı olarak mevcuttur (kullanıcı kabul

testlerinden yararlanılmaktadır).

Teknik çevre hazırdır.

Gerekli tüm veriler simülasyon çevresinde dönüştürülmektedir.

Kullanıcılar ve profiller hazırdır.

9.2 Tamamlama “Acil” veya “büyük” sorunlar içeren senaryolar başarıyla

tamamlanmıştır.

İşletme, gerçekçi bir test yapıldığından emin olmak için sürece

yeterince katılmaktadır.

48

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

10 - Uygulamaya Geçiş Sonrası Veri Bakımı

10.1 Kullanıcı

Sahipliği

Veri tipleri sisteme kaydedilmekte ve sahipler üzerinde

anlaşmaya varılmaktadır.

Bakımı yapacak kişiler tayin edilmekte ve eğitilmektedir.

10.2 Veri Bakımı Tüm ekle/güncelle eylem tipleri için prosedürler mevcuttur.

Prosedürler, tüm ilgili karşı-kodlama tablolarının

güncellenmesini kapsamaktadır.

Prosedürler, etkilenen tüm kullanıcılara iletilmiştir.

11 – Roller ve Profiller

10.1 Kullanıcı

Profilleri

Proje ekibi ve işletme temsilcileri profil tasarımı konusunda

anlaşmaya varmışlardır.

Profiller başarıyla geliştirilmekte ve test edilmektedirler.

Profillerle ilgili “acil” veya “önemli” bir sorun

bulunmamaktadır.

11.2 İşletme Riskleri Kilit işletme riskleri, sistem özellikleri ve prosedürleriyle

belirlenmekte ve ortadan kaldırılmaktadır.

Önemli “büyük” sorunlar bulunmamaktadır.

11.3 Sistem Kullanıcı

Erişimi

Tüm profiller üretim ve üretim-dışı çevreler için geliştirilmekte

ve test edilmektedir.

İşletme, kimin neye erişimi olduğunu onaylamaktadır.

İşletme, görev dağılımıyla ilgili onayları kontrol etmektedir.

Dönüştürme ve destek rollerini de kapsayan tüm kullanıcı

profilleri oluşturulmuştur.

11.4 Profil Bakımı Uygulamaya geçişten sonra profillerin bakımına ilişkin

prosedürler geliştirilmiş, onaylanmış ve etkilenen personele

dağıtılmıştır.

12 – Kullanıcının İstekli ve Hazır Olması ve Eğitimi

12.1 Kullanıcıya Etkisi

Tüm kullanıcılar görevlerinin çözümden ne şekilde

etkileneceğini bilmekte ve anlamaktadırlar.

Etkilenen tüm kullanıcılar, görev değişikliği hakkında

bilgilendirilmişlerdir.

12.2 Kullanıcı Eğitimi

ve Yetkinliği

Etkilenen tüm kullanıcılar eğitime katılmıştır.

Eğitim gören kullanıcılar eğitim egzersizlerini tamamlayarak

çözümü kullanma konusundaki yetkinliklerini göstermişlerdir.

Uygulamaya geçişten sonra bu kullanıcılar için ekstra rehberlik

ve destek verilmesine yönelik program yapılmaktadır.

12.3 Arayüz hataları Arayüz hatalarını düzeltmekle yükümlü kullanıcılar belirlenmiş

ve prosedürler konusunda eğitilmişlerdir.

12.4 Destek araçları Kullanıcıların destek araçlarına erişimi vardır.

12.5 Yeni kodlar ve

form taslakları

Müşteriler/tedarikçiler tüm yeni kodlar ve form taslakları

hakkında bilgilendirilmektedirler.

49

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

13 – Kadro Kaynağı Sağlama ve Kilit Roller

13.1 Yetkinlik

Koşulları ve Bu

Koşulların Yerine

Getirilmesi

Gerekli beceriler anlaşılmakta, dokümante edilmekte ve

güncellenmektedir.

Projeye gerekli becerilere sahip kişiler atanmaktadır.

Proje, kilit yetkinlikler/kaynaklar bakımından başka

projeler/girişimlerle rekabet halindedir.

Eksik becerilerin inşası için bir eğitim programı mevcuttur.

13.2 Yetkinliklerin

Yerelleştirilmesi

Kilit kaynakların kullanılması proje tesisiyle sınırlandırılmıştır

ve/veya proje ekibi üyelerinin tümü bir arada bulunmaktadır.

13.3 Kaynak Bileşimi Proje için yeterli tam-zamanlı kaynaklar mevcuttur.

İç kaynağa kıyasla dış kaynak karışımı açıktır. Dış destek yoğun

olduğu takdirde bilgi aktarımı için açık bir süreç mevcuttur.

Dış kaynaklara (örneğin zaman ve materyaller veya

gerçekleştirilen faydalar karşılığında yapılacak ödemeler) ilişkin

anlaşmalar mevcuttur.

13.4 Kilit Roller için

Kadro Oluşturma

Tüm alanlar için kadro oluşturmaya yeterli düzeyde öncelik

verilmekte midir, yoksa beceri sahiplerinden oluşan ekip tek bir

kilit alana mı yerleştirilmiştir?

Bilgi sahibi kaynaklar, projeye azami düzeyde katkı sağlayacak

şekilde yerleştirilmektedirler.

Teknik mimar, veri mimarı, işletme mimarı, fonksiyonel mimar

ve dönüştürme/göç mimarı gibi rollere doğru becerilere sahip

kadro sağlanmaktadır.

14 – İş Alanlarında Proje Uygulaması

14.1 Roller, Projeler/İş

Alanları

İş alanları, projenin her aşamasında rollerini anlamaktadırlar ve

uygulama için hazırlıklıdırlar.

Her iş alanının projede birlikte çalışacağı özel kaynakları vardır.

Karar alma süreci açıkça tanımlanmıştır.

İş alanları, karar alma sürecindeki rollerini anlamaktadırlar.

14.2 Planlar ve

Kaynaklar

Eğitim, yaygınlaştırma, takip ve onaylama süreçleri için

kaynaklar ve planlar mevcuttur.

15 – BT Üretimi ve Bakımı Birimindeki Uygulamalar

15.1 BT üretimi Bilgi aktarımına ilişkin bir plan mevcuttur.

Üretim ekibi, bir yayılım planı üzerinde anlaşmaya varmışlardır.

Kapasiteyi temin etmek için planlar mevcuttur.

15.2 BT Bakımı Bilgi aktarımına ilişkin bir plan mevcuttur.

Bakım birimi, bir yayılım planı kabul etmişlerdir.

Kapasiteyi temin etmek için planlar mevcuttur.

15.3 Uygulama Dönüştürme tarihleri değiştirilmiştir. Değiştirilme nedeni nedir?

16 – Destek Birimine Geçiş

16.1 Destek Stratejisi Genel destek stratejisi üzerinde anlaşmaya varılmıştır.

İlk kademe destek üyeleri belirlenmiş ve gerekli araçlar

konusunda eğitilmişlerdir.

İkinci kademe destek üyeleri belirlenmiş ve gerekli araçlar

konusunda eğitilmişlerdir.

50

BT Çözümü ve Değişiklik Yönetimi

Alan Kriterler

16.2 Değişiklik İstekleri

ve Düzeltme

Prosedürleri

Değişiklik isteklerini değerlendirme ve uygulama süreci üzerinde

anlaşmaya varılmış ve kullanıcılara iletilmiştir (örneğin etki

analizi, fonlama)

Düzeltmeleri ve değişiklik isteklerini uygulama konusunda

anlaşmaya varılmış ve kullanıcılara iletilmiştir.

16.3 Destek Süreçleri ve

İrtibat Kişileri

Bir sorun görüldüğü takdirde destek sağlayacak kişi sayısı ve

konuya ilişkin yol gösterici bilgiler kullanıcılara iletilmiştir.

İşletme, uygulama yerinde bulunan destek irtibat kişileri

hakkında bilgi sahibidir.

16.4 Sistem Kullanımı,

Kontrol Tedbirleri

ve İnceleme

Toplantıları

Sistem kullanım tedbirleri (yani sistem kullanılmakta ve

çalışmaktadır) tanımlanmış ve üzerinde anlaşmaya varılmıştır.

Bilgileri elde etmek ve raporlamak için prosedürler mevcuttur.

Günlük uygulama sonrası inceleme toplantıları

düzenlenmektedir.

17 – İş Süreklilik Planları

17.1 İş Süreklilik

Planları

Sistem kaybı durumunda, proje ve işletme gruplarıyla iş

süreklilik planları geliştirilmiş ve üzerinde anlaşmaya varılmıştır.

Sistem geri geldiğinde, öğelerin iki kez işlenmediğinden ve

finansal işlemlerin güncellendiğinden emin olmak için tüm

prosedürleri ele almak üzere geri kalma planları oluşturulmuştur.

Geri kalmaları desteklemek için gereken manuel formlar/başka

sistemler mevcuttur.

Geri kalma planlarını tetikleyecek süreç (yani kararı kim verir ve

iletişimi kim kurar) tanımlanmakta ve üzerinde anlaşmaya

varılmaktadır.

51

Yazarlar Hakkında

Steve Stein, CIA, PMP, CISA, CISSP, CFE, CGEIT

Steve Stein, Hewlett-Packard şirketinin İç Denetim Departmanında global BT denetim

yöneticisi olarak görev yapmaktadır. Dünya çapında BT birimi fonksiyonunun stratejik

planlaması ve yönetiminden sorumludur. Stein, aralarında ABD Hükümeti, ileri teknoloji ve

ilaç dahil olmak üzere pek çok sektörde BT proje yönetimi, danışmanlığı ve denetimi

alanlarında 20 yıllık bir deneyime sahiptir. SAP R/3 uygulamasının global kuruluşlarda

yürütülmesi ve denetlenmesi ve kazanılan değer proje yönetimi sistemleri konularında geniş

tecrübesi vardır. Stein, önceden KPMG’nin Bilgi Risk Yönetimi grubunda üst yöneticilik

görevini yapmaktaydı. Sertifikalı İç Denetçi sınavında gösterdiği performanstan dolayı

kendisine 2004 yılında Uluslararası İç Denetçiler Enstitüsü William S. Smith Onur Sertifikası

verilmiştir. Eskiden ABD Hava Kuvvetlerinde komutanlık görevi yapmış ve ABD Hava

Kuvvetleri Akademisi’nden mühendislik ve fen bilimleri dereceleriyle mezun olmuştur.

Karine Wegrzynowicz, CIA, CSA

Karine Wegrzynowicz, Lafarge Group Audit şirketinde İç denetim başkanıdır.

Yükümlülükleri arasında, inşaat malzemeleri sektöründe uluslararası bir dünya lideri olan

Paris-merkezli Lafarge şirketi için BT’nin ve diğer operasyonel fonksiyonların gözetimi ve

denetimi yer almaktadır. Wegrzynowicz; havayolları, otomotiv ve finansal hizmet

sektörlerinde iç denetim, BT ve operasyonlar alanlarında 20 yıldan fazla tecrübeye sahiptir.

Hem yerel hem de uluslararası düzeylerde Uluslararası İç Denetçiler Enstitüsü ve Bilgi

Sistemleri Denetim ve Kontrol Derneği’nde görev yapmıştır ve halen IIA Gelişmiş Teknoloji

Komitesi’nin bir üyesidir.

52

Gözden Geçirenler:

IIA, bu rehber hakkında değerli yorumlarda bulunan ve büyük değer katan aşağıdaki kişi ve

kurumlara teşekkürlerini sunar:

Mesleki Uygulamalar Danışmanlık Konseyi:

o Gelişmiş Teknoloji Komitesi

o Mütevelli Heyeti

o Kalite İnceleme Komitesi

o İç Denetim Standartları Kurulu

o Mesleki Sorunlar Komitesi

o Etik Komitesi

IFACI (Unité de recherce informatique), Fransa

IIA İsveç (NIRF) BT Denetim Uzmanlık Grubu (IT nettverket)

İç Denetçiler Enstitüsü – BK ve İrlanda

Ken Askelson, ABD

Clyde Batten, Nedbank Group Limited, Güney Afrika

Lily Bi, İç Denetçiler Enstitüsü, ABD

Anders Blix, EDB İşletme Ortağı, Norveç

Lionel Guillou, Euroclear, Belçika

F.M. Hallinan, Chevron Phillips Chemical Co. LLP, ABD

David Lione, Danışman, ABD

Michael Lynn, AXA Technology Services, ABD

Steve Mar, Resources Global Professionals, ABD

Tom Margosian, Ford Motor Co., ABD

Kurt Milne, BT Süreci Enstitüsü, ABD

Dr. Ulrich Hahn, bağımsız denetim uzmanı, Almanya

Jacques Lourens, Nedbank Group Limited, Güney Afrika

Cesar Martinez, City of El Paso, ABD

Steve Hunt, Crowe Horwath LLP, ABD

James Reinhard, Simon Property Group Inc., ABD

Joe Zhou Xiaowei, General Motors, Çin

53

Esnek BT denetim kadrosu mu arıyorsunuz?

Küçük-ölçekli, dikkatli BT denetim testi ve değerlendirmesine ilişkin

girişimlerden büyük-ölçekli, tam BT denetim eş-kaynak kullanımı

desteğine kadar, kendilerini işine adamış BT denetim uzmanlarından

oluşan ekibimiz, size, günümüzün ekonomik ikliminde her zamankinden

daha önemli olan maliyet etkinliğini başarmanıza yardımcı olmaktadır.

Eş-kaynaklardan sağlanan BT denetim hizmetlerinin tamamı:

Eş-kaynakla sağlanan BT denetimi

Proje Yönetimi/değerlendirmesi

SDLC incelemeleri

SAS 70 denetimi *

BT güvenliği ve kontrolleri değerlendirmesi

Nüfuz testi

İş süreklilik değerlendirmesi

PCI Veri Güvenlik Standardı hizmetleri

Sarbanes-Oxley BT testinden oluşmaktadır.

www.rsmmcgladrey/IT-risk | TRMS@rsmi.com | 800.648.4030

Ölçülebilir.

Entegre.

Objektif.

RSM McGladrey, Amerika PGA’nın resmi muhasebe, vergi ve iş danışmanlık firmasıdır.

* McGladrey & Pullen LLP (ortak sahipli bir CPA firması) tarafından sağlanan denetim ve onay hizmetleri).

RSM McGladrey, McGladrey & Pullen LLP’ye alternatif bir uygulama yapısında faaliyet göstermektedir. Ayrı

ve bağımsız tüzel kişiler olsalar da, müşterilerin ihtiyaçlarını karşılamak için birlikte çalışmaktadırlar. RSM

McGladrey ve McGladrey & Pullen LLP, ayrı ve bağımsız tüzel kişilerin işbirliği yaptığı bir kuruluş olan RSM

International üyesidirler. © 2009 RSM McGradley Inc., Tüm hakları saklıdır.

54

GTAG 12: BT Projelerini Denetlemek

Konu bağlı olduğunuz kurumuzun BT projeleri olunca başarısızlık bir seçenek değildir.

Bütçeyi aşan, programın gerisinde kalan, hedefleri yerine getiremeyen veya tamamen iptal

edilen bir projenin ciddi etkileri olabilir. İç denetçiler kurumun kilit BT projelerinde rol

oynayabilirler, oynamalıdırlar da!

Bu GTAG’nin amacı, BT projeleriyle ilgili riskleri değerlendirmek amacıyla proje ekipleriyle

ve proje yönetim ofisleriyle (PMO’lar) etkili bir biçimde yakın ilişkiler kurmaya yönelik

tekniklerin bir incelemesini sunmaktır. Bu rehberde:

Projeyle ilişkili riskleri değerlendirmek için bir çerçeve taslağının nasıl çizileceği;

Genel proje yönetim risklerine örnekler;

İç denetim biriminin bir yandan bağımsızlığını sürdürürken diğer yandan proje

incelemelerine aktif bir şekilde nasıl katılacağı;

Bir denetim yaklaşımı geliştirmek için iç denetçilerin dikkate alması gereken beş kilit

BT projesi bileşeni;

Proje başarısı için en önemli 10 faktör;

Proje denetimleri türleri yer almaktadır.

Bu rehber, ayrıca, BT projeleri incelemesine ilişkin örnek soruları içermektedir.

Bize geribildirimde bulunun! Bu Uygulama Rehberi’ni oylamak ve yorum yapmak için

www.theiia.org/gtags web sitesindeki GTAG-12 sayfasını ziyaret ediniz.

IIA – Uluslararası İç Denetçiler Enstitüsü

www.theiia.org

ISBN: 978-0-89413-663-4

Sipariş Numarası: 2018.dl

IIA Üyeleri için Ücretsiz

Üye Olmayanlar için 25 USD

GTAG’ler, Uluslararası

Mesleki Uygulama Çerçevesi

kapsamında düzenlenen Uygulama Rehberleridir.