1. Dr. Yılmaz ÖZMEN Denizli Special Provincial Administration, Deputy Secretary General
2. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
3. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
4.
5. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
6. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
7. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
8.
9.
10. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
11. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
12. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
13. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
14. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
15. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
27.
28. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
29. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
30. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
31. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
32.
33.
34. It is possible to separate the process of estimated costs of development into three steps Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
35. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Project Requirement Work Distribution Tree System Requirement Principle Assumptions Cost Estimate Methods Estimate Model Data Acquisation Point Cost Prediction Deviations Tolerance / Risk Documentation and Confirmation Sharing Updating
36.
37. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
38. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
39. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Relatively Simple Complexity Below Average Complexity Average Very Complex High Level Complexity Low Accept- able High Very High Extremely High
40. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Level of Cost Preparation Description 8-High Cost estimate depends on very sufficient engineering decisions and budget commitments (+/-%5) 7-Above the avarage Cost estimate depends on enough sufficient engineering decisions and budget commitments (+/-%15) 6-Moderate Cost estimate depends on engineering and budget decisions at the end of design evaluation (+/-%15) 5-Below the average Cost estimate depends on initial engineering and budget decisions (+/-%35) 4-Low Cost estimate depends on engineering and budget decisions before starting (+/-%35)
41. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
42. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
43. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
44.
45.
46.
47.
48.
49.
50. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
51. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
52. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
53. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
54.
55.
56. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
57.
58.
59.
60.
61.
62.
63. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
64. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
65. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Value PMhw PMsw P C hw P C sw PD 0.1 Present Present Simple Design Simple Design Independent from other factors 0.3 Low Level Redesign Low Level Redesign Low Level, Complicated Low Level, Complicated Programme is dependent on system, infrastructure and technical staff 0.5 On a large scale, Redesign On a large scale, Redesign Moderate Level, Complicated Moderate Level, Complicated Programme is dependent on system, infrastructure and technical staff 0.7 Complicated Design but technology is available New Software for Current Practices Highly complicated Highly complicated, lots of software blocks Programme depends on new system, infrastructure and technical staff 0.9 State-of-Art, Some of the basic researches completed State-of-Art, Previously undone Highly complicated Highly complicated, Very Big Database and complicated operating system Performance depends on new system, infrastructure and technical staff
66. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
67. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Value Ct Cc Cs 0.1 No effect or very little Budget estimation is impassable, some small budget transfers can be done Effect on the budget may be neglected, it can be compensated by some small budget transfers 0.3 Little decline at technical performance Cost estimations may exceed targeted budget btw. %1-%5 Delay of 2-3 weeks will require sliding some intermediate targets 0.5 Medium decline at technical performance Cost estimations may exceed targeted budget btw. % 5 -% 10 1-3 months delay for the programme 0.7 Significant decline at technical performance Cost estimations may exceed targeted budget btw. % 20 -%5 0 More than 3 months delay for the programme, main system and/or subsystems targets will not be affected 0.9 Technical targets can no be achieved Cost estimations may exceed targeted budget more than %50 A big delay, Subsystem targets will be affected, System targets may be affected
68. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 High Risk Risk Reduction Plan Risk Report Special Working Group Medium Risk Risk Reduction Plan Risk Report Special Monitoring Low Risk Periodic Assesment General Monitoring Define Potential Risk Areas Define Probability and Output Factors Pf Cf Calculate Risk Factors RF>0.7 RF>0.3 N N Y Y
69. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
70. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
71.
72. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Define Work Plan Work Apply Plan Gather Results Measure Performance Analysis Deviations Take Measure of Amendment Define Technical Performance Basis Plan Product Requirements and Quality, and integrate Integrate Risk Management and Plan Measure Product Requirements and Quality
73. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 1. Work Definition (Work Distribution Tree) Performance Measurement Basis 2. Work Plan 3. Budget Allocation TIME T L Contract Budget Limit Management Reserve
74.
75. Contract Budget Limit Management Reserve MONTHS T L BCPW : Budgeted Cost of Planned Work RCRW : Realized Cost of Realized Work CV SV BTC B CRW : Budgeted Cost of Realized Work Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
76. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Question EVM Term How much of the work should have been achieved until now? Budgeted Cost of Planned Work ( BCPW- Performance Measure Value) How much of the work have been achieved? Budgeted Cost of Realized Work ( BCRW – Acquired Value) How much did the executed work cost? Realized Cost of Realized Work ( RCRW ) What is cost variance? ( CV ) CV = RCRW – BCRW (means negative number cost increase) What is schedule variance? ( SV ) SV = BCRW – BCPW (means negative number behind work schedule) What was the expected cost of the whole work? Budgeted Total Cost ( BTC ) What is the expected cost of the whole work now? Estimated Total Cost ( ETC )
77. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
78. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
79. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
80. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
81. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
82. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
83. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
84. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Configuration Management Decision Making Bilateral Operability Schedule Process Dependency System Engineering Product Quality Program Planning Product Tests Demand Management Organizational Management Process Management Relative Impact Rate, %
85. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
86. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
87. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
88. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
89. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
90. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Learning Acting Initiating Starting Diagnosing Establishing Identify Contex Find Sponsor Built infrastruc-ture Characterize current and desired situation Develop proposal Identify priority Improve approach Plan activities Create solution Try solution Finalize solution Realize solution Analyse and validate Propose future activities
91. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Budget Calender Action plan Examination Calender Process Enhancement Plan Up to Date Budget
92. Programs aiming to reach the following output is divided in 4 projects . Quality Standarts Assesment Model Cost Management Strategic Management ISO and Quality Management Standards Baldridge Criterias Activity Based Costing Management Business Management Restructuring Strategic Capital Management Balanced Scorecard 6 Sigma Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
93.
94. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Process Management Manage Processes Managed by Processes Discovery Establishment Transition Transformation Institutionalisation Realisation
95. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
96.
97. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 System test, to commence operations and to start running System, Subsystem development To validate technology, to approve Technology development Feasibility research Basic Research Approved real system with succesful task operation Completed and qualified real system with tests and displays Performance projection achieved prototype system at an operating environment Performance projection achieved prototype system at a suitable/simulated environment Component at the suitable environment and/or show of desktop prototype Component at the Lab and/or show of desktop prototype Critical Function and/or show of analytical or experimental concept for characteristic Formulized Technological Concepts or Applications Observed and Reported Basic Values
98. Level Explanation Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
99. Level Explanation Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
100. Level Explanation Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
101. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
102. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
103.
104. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
105. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 Investment Support and Promotion Agency / Development Agency www.investindenizli.gov.tr www.denizlideyatirim.gov.tr www.cybercitydenizli.gov.tr www.e-denizli.gov.tr e - commerce e - introducing e - tourism e - feasibility
106.
107.
108. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
109. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
110. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
111. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
112. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 MIS Channels Strategic Management Information System Personnel Automation system Project Management System Performance Budget Automation system Management Documentation system Movable Goods Monitoring System Data Quality Control System Total Quality Managment System Internal Audit System Production and Delivery System Strategic Management Database Personnel Database Budget App. Database Movable Goods Database Projects Database Current Accounts Database Work/Task Classification Database Production Database Performance Reports Financial Reports Annually Based Financial Reports Annually Based Work Plan Analysis Quality Reports, Data Gathering Reports Investment Projects Monitoring Reports Domestic/Abroad Project Monitoring Reports Dynamic and Static Reports Administrative / Operational Data Data Tensile, Conversion, Installation Management Information System Data Warehouse Analysis / Reports
113. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
114. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
115. 1. and 2. Buildings 9 pieces 8 pieces Metro Ethernet VPN Directorate of Pamukkale VPN Internet 3 . Buildings Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09 SGM 18 Towns
116. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
117. User Friendly Interface Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
118. Project Subject: Follow-up work received to program by the Special Provincial Administration Investment information will be associated with location information within a short time through the Digital (vector) map. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
119. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
120.
121. AGRICULTURE SERVICES GROUP PRE-DAMAGE DETECTION AND TEMPORARY HOUSING SERVICE GROUP COMMUNICATION SERVICES GROUP BUYING, RENTING AND DISTRAINT SERVICE GROUP SECURITY SERVICES GROUP TRANSPORTATION SERVICES GROUP HEALT H SERVICES GROUP RESCUE AND WRECKAGE LIFTING SERVICES GROUP ELECTIRICITY, WATER AND CHANNEL SERVICE GROUP Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
122. Denizli İl Özel İdaresi, Dr. Y. ÖZMEN, 8-11 December 2009, e-GovsharE09
Notes de l'éditeur
Proje bir sonuca (örneğin bir ürüne) ulaşmak için gösterilen geçici çabalar bütünü. Geçici ifadesi, her projenin kesin bir başlangıcının ve kesin bir sonunun olduğunu gösteriyor. Projede elde edilecek sonuç, tanımlı, belirli ve benzersiz. Diğer bir deyişle projeye özgü. Projenin bu özellikleri, her ikisi de insanlar tarafından sınırlı kaynaklarla gerçekleştirilen, planlanan, yönetilen ve denetlenen faaliyetler olmasına rağmen onu işletme faaliyetlerinden ayırıyor. Projenin zaman değil sonuç odaklı olması onu işletme yönetiminin dönemsellik kıstasından uzaklaştırıyor ve stratejik yönetimin bir uygulama aracı haline dönüştürüyor. Proje yönetiminin önemi, yenilikçilik, ArGe ve yeni ürün geliştirme çalışmalarında artıyor. Çünkü bunlar belirsizliğin ve teknik risklerin çok yüksek olduğu çalışmalar. Bu nedenle bu tür faaliyetleri olan işletmelerde, belirli standartlardaki metodolojilere dayalı proje yönetim süreçlerinin kurulmasının; işletmenin verimliliği, karlılığı ve rekabet gücü üzerinde büyük önemi var . Bu konuda kısa bir bilgi vermeden önce yenilikçilik, ArGe ve yeni ürün geliştirme çalışmalarının genel kabul gören tanımlarını hatırlamakta yarar var.
Yenilikçilik: İşletme içi uygulamalarda, işyeri organizasyonunda veya dış ilişkilerde yeni veya önemli derecede iyileştirilmiş bir ürün (mal veya hizmet), veya süreç, yeni bir pazarlama yöntemi ya da yeni bir organizasyonel yöntemi gerçekleştirebilme becerisidir. Ar-Ge: Araştırma ve deneysel geliştirme (ArGe), insanın, kültürün ve toplumun sahip oldukları da dahil olmak üzere, bilgi birikiminin artırılması ve bu birikimin yeni uygulamalar tasarlamak üzere kullanılması için sistematik bir temelde yürütülen yaratıcı çalışmalardır. ArGe terimi üç faaliyeti kapsamaktadır. Yeni Ürün Geliştirme: Yeni bir ürünün pazara sunulması ile ilgili olan ve keşif/kavram oluşturma, geliştirme ve ticarileştirme aşamasından oluşan süreçte gerçekleştirilen işlerin bütünüdür.
Plan yapın: Kısa geliştirme dönemine sahip projelerde bile ayrıntılı planlama önemlidir. Bir ekibi odaklandıkları özel konuda sürekli hedefe kilitlenmiş durumda tutabilmek üzere çıktıların önem sırasına göre önceliklendirebildiği, erişilebilir proje hedefleri koyun. Bu aşamada ekibi, paydaşları ve sponsorları; her bir hedefin tartışılacağı, projedeki açık noktaların ve tehlikelerin anlaşılmasını sağlayacak şekilde risklerin ve elde edilecek faydaların net olarak açıklanacağı iyi yönetilen oturumlarda bir araya getirin. Bunun yapılmasıyla; herkes gereksiz değişikliklerden projenin nasıl etkileneceğini anladığı için tüm tarafların aynı safta buluşması ve birlikte hareket etmeleri sağlanır Planlamada gerçekçiliği elden bırakmayın: Kısa dönemde (1-3 ay) yapılması zorunlu olanları ve uzun dönem (1-3 yıl) hedeflerini belirleyin. Projede son teslimat tarihine sadık kalmak üzere düzgün akışı sağlanmış ara çıktılar/hedefler planlayın. Yazılımlar için bir site üzerinden düzenli aralıklarla güncellendiği uygulamalar da planlanabilir. Beklentileri karşılayabilmek için bu noktada açık iletişim kritiktir. Proje kapsamındaki kaymaları ya da artışı en aza indirmek üzere paydaşlarla haftalık olarak görüşün. İhtiyaçları değerlendirin: Projenin iş ve kullanım hedeflerini doğru anlamak, doğrusunu bulmak üzere paydaşlarla mülakatlar yapın. Proje ekibinin doğru yöne odaklanabilmesi ve son-kullanıcı beklentilerinin yönetilebilmesi için toplu gözden geçirme oturumları düzenleyin ve prototip oluşturun. Tetkiklerin ve durum yönetiminin merkezi bir yerden yapılmasını sağlayacak şekilde gereksinim yönetim sürecini mümkün olduğunca otomasyona alın. Projenin kilometre taşlarına aşırı yüklenmeyin: Projedeki kilometre taşlarını gerçekleştirilebilir nitelikte ve birbirine yakın zamanlarda (iki kilometre taşı arasında 3 haftadan daha uzun aralık bırakmadan) planlayın. Bununla birlikte üç aydan daha kısa dönemli bir projede kilometre taşları arası 1,5 haftaya düşebilir. Sıkıştırılmış bir dönem içinde kısa aralıklı çıktılara karar verdiyseniz bu kritik bir durum oluşturur. Proje yoldan çıkmaya başlamışsa birbirine yakın dönemlerde planlanan kilometre taşları hızlı tespit ve düzeltme fırsatı yaratır. Planlarınızı genele açın: Projeyle ilgili durum bilgisini düzenli olarak mümkün olan en ulaşılabilir tarzda (e-posta, intranet proje sayfaları veya bir kurumsal proje yönetim aracı üzerinden) paylaşın, dağıtın. Bu bilgiler proje ihtiyaçlarına ve eylem planlarına aşina ne kadar çok sayıda kişiyle paylaşılırsa projede yanlış adım atma olasılığı o kadar düşer. Geniş katılım, proje yöneticisinin gözünden kaçmış olabilecek potansiyel sorun noktalarının yakalanmasını sağlar. Delege etmeyin: Bir proje yöneticisinin asla yapmaması gereken şey görevlerini delege etmektir. Bunun yerine planlama ve icrada mümkün olan her aşamada proje lideri tarafından yönlendirilen ekip yaklaşımı uygulanmalıdır. Örneğin proje yöneticisi idari işlere ve eşgüdüm faaliyetlerine odaklanmışken bir sistem mimarı ve uzman programcı projedeki mimari ve sistem tasarımı aşamalarını yönetebilirler ve proje yöneticisine raporlayabilirler. Tedarikçileri yönetin: Kritik dokümantasyonun ve iletişimin tek noktada toplanması vazgeçilmezdir. Projenin yürütülmesi sırasında tedarikçilerle ilgili herhangi bir konuda tek noktadan teması sağlayacak şekilde proje yöneticisini ya da üst düzey teknik bir kişiyi (tek kaynak olarak) görevlendirin. Tedarikçilerden beklediğiniz raporlama, sipariş yönetimi ve teslimat yaklaşımını; beklentilerinizin karşılanmadığı durumdaki para cezalarını net olarak tanımlayın. Bu tanımları bir anlaşma kapsamında yazılı hale getirin.
Gelişmeleri takip edin: Küçük ekip yaklaşımı proje ekibine esnekliğini koruma ve önemsiz ayrıntılarda boğulmadan ilerleme avantajı sağlar. Projenin ölçeği büyük olsa da küçük ekipler etkin-verimli çalışırlar. Proje ya da ekip liderlerini uzmanlık alanları içinde kalan işleri yönetmeleri konusunda yetkelendirin ve açık iletişimi sürdürecek şekilde yakın çalışın. Haftalık formal gözden geçirme görüşmeleriyle herkesin görevini kesintisiz sürdürmesini sağlayın ve projede belirlenen kilometre taşlarına ulaşma performansınızı ölçün. Ancak olası problemleri en kısa sürede başınızdan atmanızı sağlayacak şekilde günlük informal görüşmeler de yapabilirsiniz. Mümkün olan her yerde otomasyona gidin: Gereksinim yönetimi araçlarıyla kapsam içinde kalan her tür değişikliği izleyin, kritik ek bilginin merkezi olarak saklanmasını sağlayın. Proje yönetimi araçlarıyla ekiplerin zamanı ve çalışmaları izlemesine olanak yaratarak proje yöneticilerinin ve diğer ekip üyelerinin gelişmelerden haberdar olmalarına; hedeflerle ilişkili olarak hatalı iletişimden kaçınmalarına yardımcı olun. İşbirliği, işbirliği, işbirliği: Ekip üyeleri diğerleriyle etkin iletişimde oldukları sürece daha yüksek performans sergilerler. Böylece işler konusunda kişiler arasındaki bağımlılıklar daha açık anlaşılır ve yönetilebilir. Gündemdeki konuları tartışmak ve düzeltici stratejileri hep birlikte üretmek üzere ekipler ile haftalık bilgilendirme oturumları düzenleyin. Ekip coğrafi olarak dağınık düzende çalışıyorsa toplantı yapmak ve bilgi paylaşmak için işbirliği araçlarından yararlanın. Yöntemin, eylem (bir araya gelme, paylaşma, birlikte fikir üretme) kadar önemi yoktur. Herkesin bilgisini güncel tutun. Tetkikler yapın: Projenin sağlığını değerlendirmek üzere iki haftada bir tetkik oturumları düzenleyerek projedeki durumu ve ilerlemeyi kontrol edin. Tetkikleri kısa, konuya ve proje hedeflerine odaklanacak şekilde gerçekleştirin; kişiselleştirmelerden kaçının. Bu tür tetkikler sırasında harcanan işgücüne karşılık gerçekleşen ilerleme, maliyet tahminleri, kapsam kontrolu için gerçekleştirilen gereksinim ölçümleri ve verimliliğe yönelik genel kalite ölçümleri tartışılmaktadır. Ekip proje programını rehber alarak tüm projeyi ölçmek üzere kriterleri belirler. Daha sonra her bir kilometre taşının ölçüm sonuçlarının değerlendirilmesinde belirlenen bu kriterlerin bir alt seti kullanılır. Üretkenliği ölçün: Ölçmeden düzeltme ya da iyileştirme yapamazsınız. Nereyi optimize edeceğinizi ya da nereye daha çok dikkat harcayacağınızı belirlemek üzere ölçüm için toplantı çıktıları, hata bulma, kaynak kullanımı ve iş tekrarları gibi standart kriterler geliştirin. Değişiklik kontrolu uygulayın: Proje boyutundan bağımsız olarak projede değişiklik kontrolu uygulanmıyorsa proje, beklenen çıktıları karşılamayacak ve teslim tarihlerine uyulamayacaktır. Değişiklik sürecini otomatize etmek ve yönetmek üzere yazılım konfigürasyon yönetimi ya da gereksinim yönetimi araçları kullanın. Her değişiklikte riskleri ve değişikliğin uygulanma süresini tahmin etmek üzere en az bir iş uzmanına ya da teknik uzmana danışılmasını sağlayacak bir değerlendirme zinciri oluşturun. Test edin: Projenin beklenen çıktıları ürettiğinden ve üretime hazır olduğundan emin olmak üzere projeyi erken aşamalarda ve sık sık test etmek kritik öneme sahiptir. Kullanıcının gerçekleştireceği kabul testlerine ve beta testlerine mümkün olduğunca çok vakit ayırarak üretim sonrası yaşanabilecek sorunları en aza indirin. Teste ayrılan süre projenin asgari %15’ine karşılık gelmelidir. Teknoloji yeniyse ya da çok sayıda sistemin proje kapsamında tümleştirilmesi gerekiyorsa projenin tüm yaşam dönemi boyunca en az %30 zamanı testler için planlayın. Kalitenin, projenin doğal bir parçası olarak ele alındığını ve sertifikasyon zamanının kısaltıldığını kanıtlayacak şekilde projenin farklı aşamalarında adım adım üzerinden giderek son kullanıcı türü gösterimler, yüz yüze kod incelemeleri, v.b. gerçekleştirin. Kısa ve öz uygulama yönergeleri tasarlayın: Üretim test yönergelerini, kurulum ihtiyaçlarını, problem yönetimine yönelik beklenmedik durum planlarını ve üretim destek adımlarını içerecek şekilde “adım adım uygulama planını” geliştirin. Yönergeleri tamamlayan dokümantasyon, mutlaka bilinen problemler, yüksek düzey test planı ve erişim bilgileri gibi sürüm bilgisini içermelidir.
Otopsi uygulayın: Projenin sonlanması; üretim desteğinin ve bir sonraki proje için sürecin iyileştirilmesini sağlayacak bütün konuların ortaya dökülerek irdelenmesi için çok uygun bir zamandır. Projede herhangi bir gecikmeye ya da proje odağında yeniden yapılanmaya, projede destek problemlerine neden olan her konuya ilişkin bilginin toplandığından emin olun. Tetkikler ya da adım adım gözden geçirmelerde olduğu gibi otopsiler de bireysel eleştirilerin yapıldığı forumlar değildir. Aksine iyileştirilmek üzere yönergelerin analiz edildiği oturumlardır. “ Sıcaklığı” ölçün: Projenin gerçekleştirilmesinden sonra çeşitli aralıklarla projenin beklentileri ne düzeyde karşıladığını ölçerek projenin başarısını değerlendirin. Bu önemli metrik, gelecekteki projelerin gelişimi için temel teşkil eder. Örneğin ölçümleriniz sonucunda yüksek ölçüde ürün desteği ve iş tekrarı gerektiğini görürseniz gereksinimleri ve tasarım süreçlerini elden geçirin. O aşamada kolayca düzeltmenin mümkün olduğu kritik bir noktanın atlanmakta olduğunu fark edebilir ve düzeltme şansı yakalayabilirsiniz.
Tedarik süreç alanı 6 alt süreçten oluşuyor. Bunlar tedarik gereksinimleri geliştirme, ihale ve tedarikçi sözleşmesi geliştirme, tedarik yönetimi, tedarik teknik çözüm, tedarik doğrulama (ing:verification) ve tedarik geçerli kılma (ing:validation) süreçleri.
Kullanıcı ihtiyacının, yazılım, donanım, süreç, bilgi ve insandan oluşan bütünsel bir sistem olarak tanımlayan doküman, tedarik öncesi dönemde sistem mühendisliği sürecinin en önemli çıktısı da olan “Sistem Gereksinimleri Dokümanı”dır . Sistem tasarımına esas olacak bu doküman, aynı zamanda maliyet belirleme çalışmalarının ve teknik şartnamelerin de temelini oluşturur. Dokümanın en önemli özelliği teknik risk kaynaklarının belirlendiği temel doküman olmasıdır. Yetersizliği başlı başına bir risk kaynağıdır. Dolayısı ile doküman kullanıcı ihtiyaçlarını tam olarak yansıtmalı, mevcut donanım, yazılım, süreç ve insan kaynaklarından kaynaklanan gereksinimler dışında sistemin nasıl olması gerektiğini değil ne yapması gerektiğini tanımlamalıdır. Dokümanın en az aşağıdaki sorulara cevap vermesi gerekir:
Kullanıcı ihtiyacının, yazılım, donanım, süreç, bilgi ve insandan oluşan bütünsel bir sistem olarak tanımlayan doküman, tedarik öncesi dönemde sistem mühendisliği sürecinin en önemli çıktısı da olan “Sistem Gereksinimleri Dokümanı”dır . Sistem tasarımına esas olacak bu doküman, aynı zamanda maliyet belirleme çalışmalarının ve teknik şartnamelerin de temelini oluşturur. Dokümanın en önemli özelliği teknik risk kaynaklarının belirlendiği temel doküman olmasıdır. Yetersizliği başlı başına bir risk kaynağıdır. Dolayısı ile doküman kullanıcı ihtiyaçlarını tam olarak yansıtmalı, mevcut donanım, yazılım, süreç ve insan kaynaklarından kaynaklanan gereksinimler dışında sistemin nasıl olması gerektiğini değil ne yapması gerektiğini tanımlamalıdır. Dokümanın en az aşağıdaki sorulara cevap vermesi gerekir:
Kullanıcı ihtiyacının, yazılım, donanım, süreç, bilgi ve insandan oluşan bütünsel bir sistem olarak tanımlayan doküman, tedarik öncesi dönemde sistem mühendisliği sürecinin en önemli çıktısı da olan “Sistem Gereksinimleri Dokümanı”dır . Sistem tasarımına esas olacak bu doküman, aynı zamanda maliyet belirleme çalışmalarının ve teknik şartnamelerin de temelini oluşturur. Dokümanın en önemli özelliği teknik risk kaynaklarının belirlendiği temel doküman olmasıdır. Yetersizliği başlı başına bir risk kaynağıdır. Dolayısı ile doküman kullanıcı ihtiyaçlarını tam olarak yansıtmalı, mevcut donanım, yazılım, süreç ve insan kaynaklarından kaynaklanan gereksinimler dışında sistemin nasıl olması gerektiğini değil ne yapması gerektiğini tanımlamalıdır. Dokümanın en az aşağıdaki sorulara cevap vermesi gerekir:
Kullanıcı ihtiyacının, yazılım, donanım, süreç, bilgi ve insandan oluşan bütünsel bir sistem olarak tanımlayan doküman, tedarik öncesi dönemde sistem mühendisliği sürecinin en önemli çıktısı da olan “Sistem Gereksinimleri Dokümanı”dır . Sistem tasarımına esas olacak bu doküman, aynı zamanda maliyet belirleme çalışmalarının ve teknik şartnamelerin de temelini oluşturur. Dokümanın en önemli özelliği teknik risk kaynaklarının belirlendiği temel doküman olmasıdır. Yetersizliği başlı başına bir risk kaynağıdır. Dolayısı ile doküman kullanıcı ihtiyaçlarını tam olarak yansıtmalı, mevcut donanım, yazılım, süreç ve insan kaynaklarından kaynaklanan gereksinimler dışında sistemin nasıl olması gerektiğini değil ne yapması gerektiğini tanımlamalıdır. Dokümanın en az aşağıdaki sorulara cevap vermesi gerekir:
Bilgi sistemleri projelerinin “geliştirme” yoğun projeler olması, ihtiyaç, bütçe, zaman ve teknik risk değerlendirmelerine göre farklı tedarik stratejilerinin uygulanmasını gerektirir . Bu stratejiler her gereksinimin en baştan şekillendirildiği ve tedariğin tek aşamada yapıldığı şelale modelinden, kullanıcı ihtiyaçlarındaki belirsizlik ya da hızlı değişim nedeniyle sistemin önceden planlı aşamalar halinde geliştirilip, tedarik edildiği ikinci nesil evrimsel tedarik modeline kadar uzanan bir yelpaze içinde ihtiyaca göre şekillendirilebilir . Tedarik makamı mevcut kullanıcı ihtiyaçları ve kaynaklarını değerlendirerek uygun tedarik stratejisini belirleyip, risk kaynaklarını kontrol altına alabilir. Aksi durumda, her zorlama, örneğin yetersiz bütçe içine, bir önceliklendirme yapmadan gereğinden fazla gereksinimin sıkıştırılmaya çalışılması proje başarısını olumsuz etkiler. Genelde karşılaşılan durum, geliştirme süreci üzerinde maliyet baskısı, bunun sonucunda önce kalitede düşme, sonrasında teknik problem ve değişiklik sayısında artış, nihayetinde önceden belirlenerek yönetim altına alınmış olsa bile teknik risklerin teker teker gerçekleşmesi ve projenin hedeflerine ulaşılamamasıdır.
Projenin tedarik döneminde, sistem mühendisliği sürecine, gereksinim yönetimi, risk yönetimi, konfigürasyon yönetimi, teknoloji yönetimi, v.b. uzmanlık süreçleri destek vermelidir. Bu alanlarda kurum içi teşkilat, teknik personel, bilgi ve altyapı yeterli düzeye gelinceye kadar dışarıdan uzmanlık ve eğitim desteği alınabilir.
Bu aşamada, projenin ve gereksinimlerinin anlaşılmış olması, proje kapsamının netleşmesini sağlayacak düzeyde bir “İş Dağılım Ağacı”nın var olması ve sistem gereksinimlerinin tanımlanmış olması gerekir . En az bu bilgilerin var olması durumunda sağlıklı bir maliyet tahmininden söz edilebilir. Ayrıca konumuz “tedarik” projeleri olduğundan, bu aşamada proje kapsamında tedarik edilecek sistem ve bileşenleri ile ilgili kritik teknolojilerin tamamı için teknoloji hazırlık düzeyinin yeterli olması gerekmektedir. Maliyet tahmin sürecinin ikinci aşaması maliyet tahmin sürecinin metodolojisi ile ilgilidir. Bu kapsamda; Maliyet tahminine esas olacak ilke ve varsayımların (zamanlama, mali, idari, lojistik, v.b. hususlar ile ilgili) belirlenmesi, Projeye en uygun maliyet tahmin yöntem(ler)inin (parametrik, benzetim, teknik, v.b.) belirlenmesi, Pojeye en uygun maliyet modelinin (genelde ürün tabanlı açılmış bir iş dağılım ağacına paralel oluşturulan maliyet dağılım ağacı) belirlenmesi gerekir. Maliyet tahminine esas olacak verilerin derlenmesi ve normalize edilmesi de bu kapsamdadır. Bu aşamada hazır temin edilecek (NDI-Non Developmental Item/COTS-Commercial of the Shelf) yazılım, donanım ve hizmetler için yeterli piyasa araştırması ve gerçek ürün/hizmet fiyat bilgileri ile desteklenen, nitelikli maliyet tahminlerinin mevcut olması gerekmektedir. Böylece projenin geliştirme çalışmaları için maliyet tahmininde asıl belirleyici unsurun geliştirme çalışmaları olması ve tahmin sürecinin bu çalışmalara odaklanması sağlanabilir. 3. Maliyet tahmin sürecinin son aşaması; nokta maliyet tahmininin yapılması, sapma toleransı ve risk analizleri ile nokta maliyet tahmininin yeterli rezerve sahip bütçeye dönüştürülmesi, maliyet tahmininin dokümante edilmesi ve onaylanması ile bilginin paylaşılması çalışmalarını kapsar . Maliyet tahmin süreci döngüsü doğal olarak maliyet tahminin, proje izleme süreçleri (örn. değişiklik izleme, kazanılmış değer izleme, v.b.) süreçleri kapsamında izlenmesi, değerlendirilmesi ve güncelleştirilmesi ile kapanır .
Ana maliyet unsurunun kuruluşa özel geliştirme çalışmalarının olduğu bilgi sistemi tedariği projelerinde, bu nedenle “maliyet tahmin kalitesi” çok önemlidir. Yetersiz bütçeleme proje hedeflerinden sapma ve kullanıcı ihtiyacının tam anlamıyla karşılanamaması riskini doğururken, aşırı tedbirli bir bütçe de kaynak israfına neden olur. Özellikle ülkemizde büyük bir bölümü anahtar teslim modeli ile gerçekleştirilen bilgi sistemi tedarik projeleri açısından bu husus önemlidir .
Maliyet tahmin kalitesini belirlemede kullanılabilecek yöntemlerden biri “Maliyet Hazırlık Düzeyi” yaklaşımıdır. Bu yaklaşım kısaca, projenin (ağırlıklı olarak) teknik ve idari boyuttaki karmaşıklığı ile maliyet tahmin yöntem ve sürecinin yeterliliğinin birlikte değerlendirilmesi esasına dayanmaktadır. Değerlendirmede 4 en kötü hazırlık düzeyi, 8 ise en iyi hazırlık düzeyi anlamında kullanılmaktadır. 9. düzey “gerçekleşen maliyet” şeklinde değerlendirilmiş olup, sınıflama dışında tutulmuştur.
Kışın arabanızla şehirlerarası yolculuğa çıkacaksınız. Arabanızın eksik olan bakımını yaptırdınız, lastiklerini kontrol ettiniz; televizyonda hava durumunu dinleyerek, kar yağışı, v.b. hava koşulları ve yolda kalma ihtimaline karşı gerekli malzemenizi yanınıza aldınız; bir şey olursa ne yapacağınızı, kimi arayacağınızı, v.b. sonuçları önceden düşündünüz ve yola çıktınız; hava ve yolun durumuna uygun hızda yolunuza davam ediyorsunuz. Bu yaklaşımınızla araba yolculuğunuzda risk yönetimi uygulamaya başlamışsınız diyebiliriz. Çünkü yapacağınız bir işte sizin sonuca ulaşmanızı engelleyebilecek faktörleri önceden düşündünüz, bunların olma olasılığını ve olduklarında başınıza geleceklerin sizi nasıl etkileyeceğini hesapladınız, bu hesaba uygun olarak risklerinizi azaltacak bir plan yaptınız ve yola koyuldunuz. Eğer bunların hiçbirini yapmadan ve “risk aldım yola çıktım, bir şey olursa düşünürüz” diyerek seyahate başladıysanız önce küçük hatanızı düzeltelim. “Risk aldım yola çıktım, bir şey olursa düşünürüz” cümlenizde “risk” kelimesini yanlış kullanıyorsunuz. Teknik bakış açısıyla o yaptığınız “risk” olarak tanımlanmıyor; yukarıda bahsettiğimiz ince çizginin öbür tarafına düşüyor.
Risk işte bu “temel neden” yüzünden var. Dolayısıyla risk dediğimizde, belirli temel nedenlerle ve bunların gelecekteki etkileriyle ilişkilendirilmiş bir ölçütten bahsediyoruz. Sırası gelmişken proje yönetimi açısından da riskin yanlış anlaşıldığı bir konuyu açıklığa kavuşturalım. Bilindiği gibi mesele veya problem yönetimi (issue management) idari ve teknik proje yönetiminin önemli bir parçası. Ancak problem yönetimi ile risk yönetimi farklı konular. İkisi arasındaki farkı kısaca şöyle ifade edebiliriz: Problem yönetimi, kaynakların geçmişte oluşmuş bir problemi çözmek, bir meseleyi halletmek üzere yönetilmesi. Risk yönetimi ise, kaynakların henüz gerçekleşmemiş, gelecekte gerçekleşme olasılığı olan temel nedenleri ve sonuçlarının etkilerini azaltmak üzere yönetimi demek. Bu nedenle bir proje yönetim planında kesinlikle ayrı ayrı ele alınması gereken konular.
Risk tanımlama temelde, geçmiş tecrübelere, mevcut gelişmelere ve eğilimlere bakarak, teknik ve idari açıdan “ne ters gidebilir?” sorusuna cevap arama çalışması. Risk analizi ise, bu tersliğin gerçekleşme olasılığı ve etkilerinin büyüklüğünün değerlendirilmesi ve sayılarla ifade edilmesi demek. Genelde riskler gerçekleşme olasılıkları ile etkilerinin birlikte gösterildikleri bir risk rapor matrisi ile sınıflandırılıyorlar (Bkz. Örnek şekil). Bu matriste kırmızı ile gösterilen alanlar yüksek, sarı alanlar orta ve yeşil alanlar düşük risk bölgesini tanımlıyor.
Elbette tüm bunların yapılabilmesi için, risk yönetiminin işletme yönetim süreçlerinin doğal bir parçası olması gerekiyor. Risk yönetiminin yapılmadığı işletmelerde yeni ürün geliştirme projeleri, gerek müşteri, gerekse tedarikçi açısından, girişte bahsettiğimiz ince çizginin sağına ve soluna doğru yalpalanılarak yürütülen çalışmalar haline geliyor.
(Daha önceden belirtildiği gibi Pf ve Cf birlikte değerlendirildiklerinde bir anlam ifade eder. Yani kullanıcının ilgili elemandan beklediği performansın kabul edilebilir sınırının aşılması durumunda ortaya çıkan sonuç Cf ise bu durumun ortaya çıkma olasılığı Pf olarak tanımlanır.)
Düşük Dereceli Risk : Riskin açıkça belli olduğu, gerçekleşmesi olasılığının ve gerçekleşmesi durumunda proje programı ve hedefleri üzerindeki etkisinin çok az olduğu koşuldur. Bu tür risk alanları için normal izleme ve denetim çalışmaları dışında bir önleme gerek duyulmaz. Orta Dereceli Risk : Riskin açıkça belli olduğu, gerçekleşmesi durumunda proje programının, hedeflerinin ve maliyetinin etkilendiği ve gerçekleşmesi olasılığının, belirli bir plan içinde izlenmesi ve denetlenmesini gerektirecek derecede yüksek olduğu koşuldur. Bu tür risk alanları için özel izleme ve denetim çalışmaları gerekir. Gerçekleşmesi durumunda projenin geçici bir süre durdurulması ve özel bir risk azaltma planının uygulanması gerekir. Yüksek Dereceli Risk : Gerçekleşme olasılığı yüksek ve gerçekleşmesi durumunda proje hedeflerini hayati derecede etkileyecek olan risk koşuludur. Literatürde bu tür risk alanına giren bir işin ancak tamamen bir araştırma çalışması veya teknoloji gösterimi ise kabul edilebileceği, geliştirme projelerinde bu tür işlerin bulunmaması gerektiği belirtilmektedir. Bu tür risk alanları için özel izleme ve denetim çalışmaları gerekir. Gerçekleşmesi durumunda projenin geçici bir süre durdurulması ve özel bir risk azaltma planının uygulanması söz konusudur.
KDY tekniğinin uygulanabilmesi için öncelikle bir referans performans tabanının oluşturulmuş olması gerekir. Bu, bir iş dağılım ağacına uygun iş tanımlamalarının, zamanlama çizelgesinin yapılmış, bütçe dağıtımının gerçekleştirilmiş, proje yönetimi için performans ölçüm tabanının belirlenmiş olması demektir .
KDY, projelerin kapsamının, bütçesi ve süresiyle ilişkili biçimde tanımlanmasını ve takibini sağlamakta. Bu sayede henüz düzeltmek için vakit varken projede yolunda gitmeyen şeyler olduğuna dair erken uyarı elde edilebilmekte, dolayısıyla proje başarımları üzerinde önemli iyileşme sağlanmakta. Ayrıca bu yöntem ile proje yöneticileri; maliyet ve teknik performansı bir arada ve çalışanlar, üst yönetim ve müşteriler, kısaca tüm paydaşlar tarafından kolay anlaşılabilir biçimde ifade edebilme olanağına kavuşmaktalar.
Burada ilk gözümüze çarpan, ilk yılın sonunda planlanan bütçenin altında kalmamızın hiç de sevinilecek bir durum olmadığı . Çünkü kazanılmış değer analizimizde, her bir prototipin tamamlanması ile toplam işin dörtte birinin tamamlandığını varsaydığımızda (hesaplama kolaylığı açısından böyle alıyoruz; gerçekte farklı kriterler mevcut), ilk yılın sonunda 350 Bin YTL harcamamıza rağmen “Kazanılmış Değer”in yalnızca 250 Bin YTL olduğunu görüyoruz. Daha da vahim bir durum, 1 yılda 2 prototip çıkarmayı planlarken yalnızca 1 prototip çıkarabilmişiz. Bu da bitişte ciddi oranda bir zaman sapması için alarm sinyallerinin çalması için yeterli. Artan maliyete razı olsak bile proje teslimatını büyük bir ihtimalle zamanında yapamayacağız. Bu durum proje yönetiminde “problem/mesele yönetimi” ve “değişiklik yönetimi” gibi yöntemlerin devreye alınmasının tipik nedenlerinden biri. Eğer önlem alınmazsa bu projede bitişteki tahmini toplam maliyetin 1,4 Milyon YTL olması ve teslimatın 48 aya doğru gecikmesi ihtimali var.
Araç/yöntem kullanma bilgisi ve becerisi geliştirilebilecek konulardandır. Amaca ulaşmak için; nerede, hangi yöntemle/araçla neyin daha kolay ve doğru yapılabileceği bilinmediğinde ve yöntem/araç doğru kullanılmadığında yöntem/araç kullanmakla (umulan) fayda yerine zarar görmek de mümkündür. Basit bir benzetmeyle fındık yiyebilmek için kabuğunu kırmak üzere fındık kıracağı yerine çekiç kullanmak hem parmakların yaralanmasına, hem de fındığın ezilerek yenmez hale gelmesine yol açabilir. Bu nedenle yöntemleri/araçları doğru ve yerinde kullanabilmek de en az bu yöntem ve araçları bilmek kadar önemlidir. ABD’de ileri teknoloji projelerinde tedarik hedeflerinin ve teknik performans gereksinimlerinin karşılanmamasına yol açan etmenleri belirlemeye yönelik olarak 4 yılda 50 büyük tedarik programının değerlendirilmesi ile yapılan kapsamlı araştırmanın bulgularına göre “süreç yetenekleri”nin %91 ile ilk sırayı aldığı görülmüş . Programı yürüten ekibin kendi ihtiyaçları doğrultusunda kendi programlarına özgü geliştirme süreçlerini tanımlayamaması, tasarlayamaması, tümleştirememesi veya uygulayamamasının bu duruma yol açtığı belirlenmiş .
İster büyük-orta ya da küçük ölçekli olsun, ister kamuda isterse özel sektörde olsun her organizasyonun işlemesi için süreçlere ihtiyaç duyulmakta. 1980’li yılların ortalarında ivme kazanan kalite hareketi ile kuruluşlardaki süreçler ve süreç iyileştirmeleri konusunda önemli bir ilerleme kaydedildi. TQM, BPR, ISO sertifikasyonu, 6 Sigma gibi kullanılan çok sayıda yöntem ve araç ile kuruluşların süreçleri ve dolayısıyla kuruluşların kalitesi iyileştirilmeye çalışıldı. Ancak bu yöntem ve araçlar, kuruluşlardaki süreçlerin tümleştirilmesiyle ortaya çıkan bütünsel sistem yerine süreçleri yalıtılmış biçimde mercek altına alma eğiliminde olduklarından etkileri sınırlı kalmakta. Kamu ve özel sektörden kuruluşların bir araya gelerek oluşturdukları, otuz yılı aşan bir geçmişe sahip uluslararası CAM-I ( Consortium of Advanced Management, International ) () konsorsiyumu çatısı altında başlatılan “Süreçlere Dayalı Yönetim” ( Process Based Management ) () programı da bu amaçla başlatılmış bir girişim. Stratejik yönetim, kalite yönetimi, mali yönetim ve değerlendirme modellerine yönelik yaklaşımları tümleştirmeyi ve performans yönetiminin bu bütünsel yapı üzerinden gerçekleştirilmesini sağlamayı hedefleyen bu program kapsamında kuruluşların gerçek anlamda ve bütünsel olarak “süreçlere dayalı yönetilir” hale gelmek üzere kullanacakları pratik uygulama çerçevesi geliştiriliyor. Program aşağıdaki çıktılara ulaşmayı hedefleyen 4 projeden oluşmakta.
Önceki model ve standartlarla ulaşılabilen 4. adımda henüz her bir süreç diğerlerinden kopuk olarak ele alınarak yönetilirken (Süreç Yönetimi: Process Management) kuruluşlar bu adımda değişim geçirerek süreçlerin tümleştirilmesiyle oluşan sistemi yönetir duruma gelecekler.
Teknolojide hızlı ve büyük gelişmeler yaşanırken bu gelişmeleri aynı hızda ürünlere yansıtmak mümkün olmuyor. Özellikle savunma, havacılık ve uzay gibi sektörlerde, büyük ölçekli tedarik projelerinde kullanılacak teknolojilerin yeterli olgunluk düzeyinde olmamaları sonucunda ortaya çıkabilecek zaman, para, işgücü kayıplarının büyüklüğü (kimi zaman zararın ölümcül olması), teknoloji değerlendirmede "var/yok" yaklaşımının ötesinde, "hangi düzeyde var?" sorusuna cevap verecek yeni yöntemlerin kullanılmaya başlamasına neden olmuş. Teknolojik Olgunluk Düzeyi'nin ya da Teknoloji Hazırlık Düzeyi'nin değerlendirilmesi bunlardan biri. Teknolojik Hazırlık Düzeyi değerlendirmesi günümüzde başta savunma, havacılık ve uzay olmak üzere, yeni ürün geliştirmeye dayalı kamu tedarik projelerinin yapısına karar verilmeden önce yaşanan bir süreç. Bu tip projelerde, kullanılacak yeni teknolojilerden kaynaklanabilecek riskleri en aza indirgemek amacıyla “teknoloji geliştirme” ve “ürün geliştirme” süreçlerinin birbirinden ayrı iki süreç olarak tanımlanması ve işletilmesi tavsiye ediliyor, hatta zorunlu tutuluyor. Bu iki sürecin iç içe geçmesi durumunda teknoloji, ürünle birlikte geliştirildiğinden henüz yeterince denenmeden ürüne yansıtılmış oluyor. Bu durumun doğuracağı sakıncalardan kaçınmak üzere emniyetin kritik olduğu alanlarda teknoloji olgunluğunun ölçülmesi ve elde edilen sonuca göre davranılması (örneğin bağımsız bir ArGe çalışmasının başlatılması) yoluna gidiliyor.
