ALOKASI SUMBER DAYA

wa ode rizkylla | 14412039

OVERVIEW
Setelah melakukan scheduling di bab sebelumnya, maka tahap selanjutnya
adalah alokasi dari sumber daya fisik. Topik pada bab ini berhubungan
langsung dengan topik scheduling, karena mengubah schedule maka juga
mengubah kebutuhan sumber daya serta mengubah timing dari
kebutuhan sumber daya tersebut. Pada waktu yang telah ditentukan,
perusahaan memiliki tingkat tertentu dari sumber daya yang tersedia
untuk proyek. Sumber daya ini mencakup waktu kerja dari beberapa jenis
keahlian khusus atau servis teknikal, machine-hours dari beberapa jenis
mesin dan instrumentasi, computing time, lokasi khusus, dan sumber daya
langka yang sama yang dibutuhkan untuk menyelesaikan tugas proyek.

Bab ini membahas tentang situasi dimana terjadi masalah-masalah yang

berkaitan dengan sumber daya. Pembahasan ini termasuk trade-off,
perbedaan antara alokasi pada satu proyek dan alokasi pada
multiproyek, hubungan antara loading dan leveling sumber daya, dan
beberapa pendekatan dalam mengalokasikan masalah termasuk juga
CPM, rantai kritis Goldratt, dan beberapa pendekatan lain mengenai
permasalahan sumber daya dalam kondisi langka.
Pertama-tama akan dibahas mengenai alokasi pada satu proyek,
kemudian pada kasus multiproyek. Walaupun CPM bukan metode
untuk mengalokasi sumber daya namun waktu dianggap sebagai
sumber daya dan tradeoff antar waktu dan sumber daya merupakan
permasalahan yang utama dalam manajemen sumber daya. Terakhir,
dampak besar dari software manajemen proyek menguji kemampuan
PM dalam melakukan loading dan leveling sumber daya.

9.1

METODE CRITICAL PATH

Saat pertama dikembangkan di tahun 1958, CPM menggunakan notasi
AON dan membuat cara dalam menghubungkan jadwal proyek kepada
level dimana sumber daya fisik dialokasikan pada proyek. Hal ini membuat
PM melakukan trade atas waktu terhadap ongkos dan sebaliknya. Pada
CPM , dua waktu aktivitas dan dua ongkos kadang ditentukan untuk tiap
aktivitas. Kombinasi waktu/ongkos disebut normal dan yang kedua disebut
crash. Waktu normal adalah normal dalam pengartian yang sama dengan
estimasi waktu m dari tiga waktu yang digunakan dalam PERT. Waktu crash
merupakan hasil dari percobaan untuk mempercepat aktivitas dengan
aplikasi dari sumber daya tambahan seperti overtime, peralatan khusus dan
staff dan material tambahan.

Pada praktik standarnya AOA dan AON mengestimasi waktu

aktivitas pada kondisi loading sumber daya yang normal, karena
mustahil untuk mengestimasi waktu tanpa tahu mengenai level
sumber daya yang disediakan untuk proyek. Penggunaan rule of
thumb dapat digunakan untuk mengestimasi sumber daya apa yang
akan disediakan pada tiap tugas proyek. Apabila diperlukan
percepatan dalam menyelesaikan proyek maka masalah mengenai
alokasi perlu dipertimbangkan secara matang. Perlu diketahui
sumber daya tambahan apa yang akan diperlukan untuk
mempercepat waktu penyelesaian untuk beberapa aktivitas pada
proyek. Rule of thumb ini tidak berlaku pada proyek yang
dipercepat, karena memerlukan perencanaan kritis. Crash plan yang
ter lihat memungkinkan dilakukanpun mustahil dalam
memperkirakan ketersediaan sumber daya.

Pada proyek, apabila estimasi waktu deterministik digunakan, dan

deadline telah ditetapkan, terdapat kemungkinan besar bahwa
beberapa aktivitas terakhir akan gagal dilakukan. Penggunaan dari
tiga waktu aktivitas probabilistik dapat mengurangi kemungkinan
diperlukannya menggagalkan aktivitas terakhir karena dengan
penggunaan waktu jenis ini mencakup identifikasi dan estimasi
risiko dan ketidakpastian yang kadang terlupakan saat membuat
estimasi waktu deterministik. Namun crashing ini dapat terjadi
kapanpun, contohnya saat terdapat perubahan dalam spesifikasi
yang diberikan client.

Mengacu pada tabel 9-1, pertama-tama hitung slope ongkos/

waktu untuk tiap aktivitas yang dapat dipercepat:

Apabila slope negatif maka waktu yang dibutuhkan berkurang

dan ongkos naik. Hasil perhitungan tabel 9-1 disajikan dalam tabel
9-2 berikut:

Proyek crashing dapat menyebabkan perubahan teknologi atau

dengan bahasa ekonomi yaitu mengubah fungsi produksi.
Sebagai contoh pada sebuah proyek menggali tanah, apabila
pekerjaan ingin diselesaikan lebih cepat maka penambahan SDM
dan cangkul dapat dilakukan, di sisi lain juga dapat menggunakan
alat otomatis Ditch Witch. Berbeda dengan penambahan SDM
dan cangkul, dimana pekerjaan dapat diselesaikan dengan range
durasi 1 hingga 3 hari, namun dengan penggunaan alat otomatis
Ditch Witch, hanya terdapat satu pilihan waktu penyelesaian yaitu
3 jam. Perlu diingat bahwa saat kita mengganti teknologi maka
risiko yang dihadapi juga juga dapat berubah.

Pada proyek crashing, hal pertama yang dilakukan adalah

mengembangkan tabel atau grafik dari ongkos proyek sebagai
fungsi dari beberapa tanggal penyelesaian proyek. Dimulai dari
jadwal normal dari semua aktivitas proyek, crash beberapa
aktivitas yang dipilih secara simultan untuk menurunkan durasi
proyek di penambahan ongkos yang minimum. Dalam proyek
crashing terdapat dua prinsip sederhana: Pertama, fokus pada
critical path saat mempersingkat durasi proyek, crashing pada
noncritical path tidk akan mempengaruhi durasi proyek. Kedua
saat mempersingkat durasi proyek gunakan cara yang semurah
mungkin.

Network AOA diatas adalah berdasarkan tabel 9-1 di slide

sebelumnya. Lebih mudah memgambarkan dampak dari crashing
dengan network AOA dibandingkan dengan network AON.
Digunakan aktivitas dummy untuk memperlihatkan waktu durasi
dan slack. Seperti yang diindikasikan, aktivitas d dapat secara parsial
di-crash, tapi pada aktivitas e terdapat diskontinuitas teknologi dan
membutuhkan waktu tiga hari dengan ongkos $10 dan satu hari
dengan $80.

Secara umum, dampak dari adanya diskontinuitas teknologi

adalah bahwa solusi terbaik untuk crashing n hari bisa saja bukan
bagian dari solusi terbaik dalam crashing n + 1 hari. Namun, bisa
saja baik untuk crash aktivitas lain yang dapat di-crash dalam n
hari. Untuk lebih jelasnya, dijelaskan sebagai berikut.
Critical path untuk network AON a adalah a-b-e, durasi proyek
adalah 8 hari dan total ongkos normal adalah $120.

Keputusan mengenai aktivitas mana yang akan di-crash bergantung

pada sebutuh apa kita dalam mempersingkat durasi proyek. Untuk
mempersingkat durasi total network sebanyak 1 hari maka kita harus
memangkas waktu yang dibutuhkan oleh salah satu aktivitas
sepanjang critical path. Dengan melihat tabel 9-2 pada slide
sebelumnya, dapat dilihat critical aktivitas mana yang dapat dipangkas
hingga dengan ongkos terkecil, yaitu aktivitas a yang menambah $40
pada ongkos proyek aktual. Aktivitas b dapat dicrash pada ongkos
$60 atau bahkan kita dapat crash aktivitas e sebanyak 2 hari pada
ongkos dimana e dipangkas. Tentu saja, dengan mengcrashing e maka
akan mempersingkat durasi proyek sebanyak sehari karena apabila e
dipangkas maka path a-d-dummy akan menjadi critical path dan
tidak mungkin membuat proyek dipangkas hingga menjadi 6 hari.

Dari ketiga option sebelumnya, crashing a adalah yang termurah

dan cenderung lebih disukai; lihat gambar 9-1b dibawah.
Perhatikan bahwa crashing a maka akan memangkas a-d-dummy
dan a-c-dummy

Misal proyek harus dicrash sebanyak 2 hari, apa saja option nya?
Dengan mempertimbangkan lagi tabel 9-2 di slide sebelumnya
dan network pada 9-1a, kita dapat melihat bahwa kita dapat
crash aktivitas e sebanyak 2 hari ($70), namun path dummy a-ddummy (durasi 7 hari) juga harus di crash sedikitnya sehari. Kita
memilih d ($30) karena d lebih murah dari a ($40). Ongkos
untuk crashing adalah $100 dan total ongkos proyek adalah $120
+ $100 = $220. Alternatif lain yang dapat digunakan adalah kita
dapat crash a dan b, juga pada ongkos $120 + $100 = $220.
Kemudian misal kita ingin crash proyek sebanyak 3 hari, dari
aslinya 8 hari menjadi 5 hari. Maka jelas e harus di crash sebanyak
2 hari, dengan ongkos $70, dan a atau b sebanyak sehari. Kita pilih
a, yang termurah, dengan tambahan $40.

Ini membuat d di crash sebanyak sehari untuk ongkos $30 lagi,

menyebabkan ongkos total crash sebanyak $140 dan ongkos
proyek $120 + $140 = $260 (lihat gambar 9-1d)

Perlu diingat bahwa kita tidak crash b kali ini seperti yang
dilakukan untuk 6 hari. Hal ini dikarenakan diskontinuitas pada
aktivitas e

Terakhir, mari mempertimbangkan crashing proyek sebanyak 4

hari hingga membuat durasi proyek menjadi 4 hari. Karena kita
crash e, diskontinuitas teknologi, dalam mencapai durasi 5 hari,
semua aktivitas yang tersisa dapat di crash secara inkremental.
Sehingga kita dapat dengan mudah melihat 9-1d untuk melihat
siapa lagi yang membutuhkan crash secara inkremental untuk
mempersingkas proyek. Perhatikan network 9-1d bahwa a-b-e
dan a-d-dummy keduanya adalah critical path. Hanya b dan d
yang dapat dicrash, sehingga kita crash masing-masing sebanyak
sehari dengan tambahan ongkos melebihi schedule 5 hari seperti
pada network 9-1e di slide berikutnya

Perlu diingat bahwa c sekarang menjadi critical sehingga semua

aktivitas adalah critical. Karena path a-b-e dan a-c sepenuhnya di
crash maka proyek durasi tidak dapat dipersingkat lebih jauh,
walaupun aktivitas d dapat dicrash lagi. Sehingga network 9-1e
diatas bukanlah network all-crash, walaupun network tersebut
sama dengan jadwal waktu all-crash untuk 4 hari.

Pendekatan lain untuk CPM dimulai dengan

schedule all-crash dengan ongkos $380 dan
melonggarkan aktivitas satu persatu. Tentu saja
aktivitas yang dilonggarkan pertama sebaiknya
adalah yang tidak mengulur tanggal penyelesaian
proyek. Pada contoh yang diberikan, ini mungkin
dilakukan karena d tidak harus berada pada satu
hari sehingga dapat diulur sebanyak sehari di
penghematan ongkos sebanyak $30 tanpa
mengubah tanggal penyelesaian proyek.

Dapat dilihat di network 9-1e dimana

aktivitas d memakan waktu 2 hari dan pada
ongkos $350. Lanjut menggunakan cara ini
dan melonggarkan aktivitas yang paling mahal
pertama akan menghasilkan schedule allnormal 8 hari dan ongkos $120 seperti yang
diperlihatkan pada network 9-1a di slide
sebelumnya.

Perkara mengenai apakah crashing ini berguna apa tidak

merupakan masalah lain. Pada sisi ongkos, gambar 9-2 dibawah
menggambarkan hubungan ongkos/waktu dari proyek crashing:

Kelebehinnya beberapa proyek memiliki penalti klausul

yang menyebabkan organisasi induk mungkin untuk
mengalami keterlambatan delivery.
Mulai dari sisi all-normal di sebelah paling kanan gambar
9-2 dari slide sebelumnya, ongkos akang semakin naik saat
time-out proyek semakin dipersingkat. Diagram seperti
pada gambar 9-2 berguna untuk PM dalam mengontrol
durasi dan ongkos proyek. Diagram tersebut juga berguna
dalam menghadapi manajer senior, yang mungkin akan
berselisih paham mengenai penyelesaian proyek lebih awal
dengan pemahaman sedikit mengenai ongkos yang
digunakan.

Data tersebut memiliki kelebihan saat client meminta

delivery lebih awal, maka akan terdapat dua pilihan yaitu
client menyanggupi membayar ongkos crashing, atau
perusahaan bersedia menyubsidi client.

Beberapa organisasi memiliki lebih dari satu level crashing. Tabel

9-3 berikut menggambarkan kasus tersebut:

Pada contoh ini, perusahaan memiliki dua level berbeda dalam

mempercepat suatu proyek: rush dan blitz. Perbedaan dari
hubungan pendahulu antara tugas-tugas tertulis dalam tabel 9-3
sebagai perbedaan dalam komitmen sumber daya. Dua baris
terakhir dalam tabel memperlihatkan perubahan yang diharapkan
dalam ongkos dan waktu apabila proyek dipercepat.

FAST-TRACKING
Cara lain dalam mempercepat sebuah proyek adalah dengan fast-tracking.
Istilah ini telah digunakan kebanyakan pada proyek-proyek konstruksi, tetapi
teknisnya dapat digunakan pada banyak proyek jenis lain, yaitu overlapping
fase perancangan dan fase pembangunan dari proyek. Karena tahap
perancangan selalu diselesaikan sebelum tahap kosntruksi dimulai, overlap
kedua tahap akan mempersingkat durasi proyek. Namun memulai
pembangunan sebelum perancangan selesai dapat mengakibatkan tingginya
tingkat perubahan, kehilangan produktivitas, naiknya ongkos, dan kehilangan
waktu. Namun cara fast-tracking layak dalam mempercepat suatu proyek
konstruksi, dan jenis proyek lain dimana tahap build dan carry out
merupakan tahap yang rutin dan dipahami dengan baik. Cara fast-tracking ini
adalah penggunaan parsial dari konsep dasar manajemen proyek phase-gate.

9.2

MASALAH ALOKASI SUMBER DAYA

Kesalahan dalam mengikuti prosedur schedule yang dibahas pada chapter
sebelumnya adalah bahwa tidak dibahas isu mengenai utilisasi dan
ketersediaan sumber daya. Fokus pada chapter sebelumnya adalah pada
waktu, bukan sumber daya fisik. Pada diskusi setelah ini tidak layak
menyebut penggunaan sumber daya sebagai ongkos, namun harus disebut
dengan buruh, fasilitas spesifik, jenis material, bagian-bagian dari alat, dan
input diskret yang relevan terhadap proyek namun terbatas
ketersediaannya. Selanjutnya, kita perlu mempertimbangkan dua jenis
sumber daya yaitu: (1) Yang membutuhkan jumlah tertentu dari aktivitas (2
machine hours, 12 hari kerja, dsb), dan (2) Yang dibutuhkan dalam
mendampingi buruh selama buruh bekerja, seperti mesin.

Chapter ini akan menjelaskan jenis sumber daya mana dari dua sumber
daya yang disebutkan pada slide sebelumnya yang dibutuhkan pada suatu
waktu. Terakhir, kita tidak boleh melupakan bahwa waktu itu sendiri
merupakan suber daya critical pada manajemen proyek dan berbeda
dari sumber daya lainnya karena tidak dapat di simpan dalam inventori
atau diperbaharui.
Seseorang tidak dapat menyimpan waktu- seseorang hanya bisa
menghabiskan waktu sedikit atau banyak.
Hubungan antara progress, waktu dan ketersediaan/penggunaan sumber
daya merupakan fokus utama dari chapter ini. Schedule sebaiknya
dievaluasi bukan dalam rangka mencapai milestone proyek, namun juga
dalam rangka timing dan penggunaan sumber daya yang langka. Dalam
mengukur keberhasilan PM dalam manajemen proyek adalah skill nya
dimana trade-off antar scope, waktu dan ongkos dikelola.

Dalam beberapa kesempatan, tambahan sumber daya yang berguna

dapat diberikan dengan ongkos kecil atau tidak sama sekali pada
sebuah proyek saat periode krisis. Di lain waktu, beberapa sumber
daya yang melimpah dapat ditukar dengan yang langka. Seringkali,
penukaran ini diikuti dengan tambahan ongkos pada perusahaan,
sehingga tanggung jawab utama PM adalah untuk mewujudkannya.
Poin ekstrem dalam hubungan antara waktu dan sumber daya yang
digunakan adalah:
1. Waktu terbatas
Proyek harus diselesaikan pada waktu tertentu menggunakan sesedikit mungkin
sumber daya.

2. Sumber daya terbatas

Proyek harus diselesaikan secepat mungkin tapi tanpa keluar dari level spesifik
dari penggunaan sumber daya atau contraint umum sumber daya

Pada beberapa kesempatan, kedua waktu dan sumber daya dapat bersifat
terbatas, namun pada kasus ini, spesifikasi tidak dapat diubah. Apabila tiga
variabel - waktu, ongkos dan spesifikasi- sudah ditentukan maka sistem
akan overdetermine, PM akan kehilangan fleksibilitas dalam melakukan
trade-off yang penting untuk keberhasilan penyelesaian proyek. Namun
masih mungkin, walaupun kecil, 3 variabel ditentukan pada level dimana
PM dapat banyak melakukan manuver.
Terkadang ada satu atau beberapa tugas bersifat system-constrained.
Sebuah tugas yang system-constrained membutuhkan waktu dan sumber
daya yang pasti. Beberapa proses industri bersifat system-constrained.
Material harus diproses dalam waktu yang telah ditentukan, tidak boleh
kurang dan juga tidak boleh lebih sehingga tidak ada trade-off yang
memungkinkan, maka dari itu hal yang difokuskan pada proses yang
system-constrained adalah memastikan bahwa sumber daya tersedia saat
diperlukan.

9.3

LOADING SUMBER DAYA

Loading sumber daya adalah jumlah dari sumber daya individual yang
dibutuhkan dalam periode waktu tertentu. Loading sumber daya
memberikan pemahaman umum mengenai permintaan proyek pada
sumber daya perusahaan. Loading sumber daya membantu dalam
mengurangi permintaan yang berlebihan atas sumber daya tertentu. PM
harus menyadari bahwa penggunaan sumber daya pada proyek
terkadang tidak linear dan banyak software manajemen proyek tidak
mengetahui hal ini.
Apabila sumber daya dinaikkan sebesar X persen maka output tidak naik
sebesar X persen dan waktunya pun tidak berkurang sebesar X persen.

Gambar pada slide sebelumnya memperlihatkan sebagian dari

action plan pada Career Day. Bagian dari plan itu
memperlihatkan SDM yang dibutuhkan pada tiap aktivitas. Dalam
memanfaatkan plan tersebut maka dibuat kalender penggunaan
sumber daya pada slide berikut:

Setiap SDM yang digunakan pada proyek ditulis dan

diikuti dengan penamaan aktivitas dimana sumber
daya digunakan. Total jam pekerjaan dari tiap sumber
daya ditulis bersamaan dengan jumlah perencanaan
pada tiap aktivitas. Jadwal untuk loading sumber daya
diperoleh dan loading kemudian diperlihatkan untuk
tiap sumber daya perminggu.
Mengacu pada action plan gambar 9-3, sekretaris
overload selama Mei dan Juni awal. Diasumsikan
bahwa hanya terdapat satu sekretaris pada 30 Mei
atau dia harus bekerja 17 jam sehari dari 5 hari kerja
seminggu

Graduate assitant dianggap budak oleh faculty master,

namun hanya dipekerjakan 20 jam seminggu. Apabila
terdapat kurang dari 4 graduate assistant, maka proyek
akan mengalami masalah dan merupakan tanggung
jawab PM dalam mengatasinya, yaitu dengan cara
menambah SDM atau dengan mengubah jadwal
sehingga permintaan sumber daya tidak melebihi
kapasitas sumber daya. Karena sebuah action plan
proyek adalah sumber informasi dari aktivitas utama,
durasi, kebutuhan sumber daya dan input utama untuk
jadwal proyek dan anggarannya. Action plan
menghubungkan jadwal langsung kepada permintaan
khusus atas sumber daya.

Sehingga teknik network AOA dapat dimodifikasi untuk

mengembangkan kebutuhan time-phase sumber daya. Diagram
Gantt dapat digunakan, namun diagram AOA akan berguna pada
analisis yang digunakan pada leveling sumber daya. Kemudian
mari kita menggambarkan network AON yang digunakan sebagai
contoh pada chapter sebelumnya, tapi diubah dalam diagram
AOA. Network AOA diberikan pada gambar 9-4 dan
penggunaan sumber daya diberikan dengan 2 sumber daya
hipotesis, A dan B pada busur. Aktivitas yang diekspektasi
ditunjukkan diatas busur, pengunaan sumber daya ditunjukkan
pada bracket dibawah busur berarti bahwa 5 buah A dan 3 buah
B akan digunakan pada aktivitas yang ditunjukkan busur. Gambar
9-5 menunjukkan clendarized diagram AOA, Permintaan
sumber daya kemudian dapat dihitung dengan periode waktu
pada seluruh aktivitas

Gambar 9-4

Gambar 9-5

Diagram loading untuk sumber daya A ditunjukkan pada gambar

9-6a dan sumber daya B pada figur 9-6b. Load bersifat tak
menentu dan bervariasi selama durasi proyek. Sumber daya A,
digunakan dalam tugas a, b dan c, memiliki permintaan awal yang
tinggi yang turun di tengah-tengah proyek dan kemudian naik lagi.
Sumber daya B, di lain hal, memiliki penggunaan awal yang rendah
namun naik saat proyek dikembangkan. PM harus paham
mengenai pasang surut penggunaan dari tiap input sumber daya
selama hidup proyek. PM bertanggung jawab dalam memastikan
sumber daya yang dibutuhkan, pada jumlah yang dibutuhkan dan
tersedia disaat dan dimanapun dibutuhkan.

Tabel 9-6a

Tabel 9-6b

9.4

LEVELING SUMBER DAYA

Pada contoh di awal, dapat dilihat bahwa proyek dimulai dengan
penggunaan sumber daya A yang banyak, menggunakan jumlah yang
lebih sedikit di tengah-tegah proyek, dan kemudian lanjut dengan
naiknya penggunaan pada tahap setelahnya. Penggunaan B dimulai dari
sedikit dan naik selama hidup proyek. Fluktuasi tinggi pada load yang
diperlikan untuk beberapa sumber daya merupakan hal yang normal.
Leveling sumber daya dimaksudkan untuk meminimalisir variasi
periode-per-periode dalam loading sumber daya dengan menggeser
tugas dalam range waktu slacknya. Tujuannya adalah untuk membuat
distribusi yang lebih halus atas penggunaan sumber daya

Terdapat beberapa kelebihan dalam penggunaan

sumber daya. Pertama, manajemen hands-on
diperlukan apabila penggunaan sumber daya yang
diberikan hampir konstan selama periode
penggunaan. PM dapat mengatur untuk
mendapatkan sumber daya yang tersedia saat
dibutuhkan, dan mendapatkan jumlah konstan dari
furnish supplier, serta mengatur backup supplier.
Kedua, apabila penggunaan sumber daya rata maka
PM dapat menggunakan kebijakan inventori justin-time tanpa khawatir jumlah yang dideliver akan
salah.

Apabila sumber daya yang rata adalah SDM, maka

leveling dapat meningkatkan moral dan menghasikan
lebih sedikit masalah antar SDM dan lebih sedikit gaji
yang dibayarkan karena meningkatnya ser ta
menurunnya level buruh.
Terdapat juga implikasi ongkos pada leveling sumber
daya ini. Leveling karyawan merupakan hal paling
penting dalam perspektif ongkos. Terkadang akan
lebih murah untuk melakukan leveling kebutuhan
bur uh untuk menghindar i perekr utan dan
pemberhentian, walaupun gaji tambahan harus
dibayarkan pada mereka.

Prosedur dasar dalam leveling sumber daya adalah hal

yang mudah. Sebagai contoh, perhatikan network AOA
yang diperlihatkan pada gambar 9-7a diatas, waktu
aktivitas yang ditunjukkan diatas busur dan penggunaan
sumber daya ditunjukkan dalam kurung dibawah busur.

Aktivitas a membutuhkan 2 SDM dan memerlukan 2

hari, b membutuhkan 2 SDM dan memerlukan 3
hari, dan c membutuhkan 4 SDM dan memerlukan 5
hari. Apabila tugas-tugas ini dimulai pada tanggal ES
nya, maka loading sumber daya ditunjukkan pada
gambar 9-7b, langkah dalam menurunkan permintaan
buruh bervariasi dari 8 pekerja hingga 4 pekerja.
Apabila tugas b diundur hingga 2 hari maka akan
ditunjukkan pada gambar 9-7c. Hasil yang sama akan
terjadi bila b dimulai sedini mungkin dan tugas a
diundur hingga hari ke-3.

Gambar 9-7b

Gambar 9-7c

Perhatikan kembali load diagram pada gambar

9-6a dan 9-6b. Diasumsikan bahwa kita ingin
memuluskan loading sumber daya B. Kedua
aktivitas e dab f dapat diundur (e mimiliki slack 5
hari dan f memiliki slack 9 hari). Apabila kita
menunda keduanya sebanyak sehari maka kita
menghilangkan peak pada hari ke 20 tanpa
meningkatkan peak lainnya seper ti yang
ditunjukkan pada gambar 9-8b. Apabila dilakukan
maka akan mengumbah penggunaan sumber daya
A dan memperdalam jurang pada hari ke-20
seperti yang ditunjukkan pada gambar 9-8a.

Apabila kita menunda lebih jauh f sebanyak 7 hari

dalam meratakan penggunaan A hingga akhir
proyek, maka kita akan memperdalam jurang
antara hari ke-20 dan ke-24 dan penggunaan A
seperti yang ditunjukkan oleh garis putus-putus
pada gambar 9-8a. Aktivitas f akan dimulai pada hari
ke-28. Pengaruh dari penggunaan B dapat dilihat
pada gambar 9-8b. Perubahan akan menurunkan
penggunaan sebanyak 1 unit dimulai dari hari ke-21
serta meningkatkan penggunaan sebanyak 1 unit
pada hari ke-35 hingga akhir proyek. Tindakan ini
meningkatkan peak penggunaan B dari 9 ke 10 unit.

Gambar 9-8a

Gambar 9-6b

LOADING/LEVELING SUMBER DAYA

DAN KETIDAK PASTIAN
Gambar 9-9 dibawah ini merupakan diagram loading sumber
daya untuk grup software engineering pada perusahaan besar
yang dibuat dengan memindahkan informasi loading sumber daya
MSP ke dalam lebar Excel dan kemudian ditunjukkan secara
grafis.

Dalam grup terdapat 21 engineer dengan jam kerja sebanyak 40

jam seminggu, sehingga memiliki kapasitas mingguan sebanyak
21 x 40 = 840 jam kerja tiap minggu
Terdapat 34 minggu dalam gambar 9-9 sehingga total kapasitas
engineering dalam periode tersebut adalah
34 x 840 = 28,560 jam kerja
Apabila melihat dari gambar 9-9, jam kerja yang dibutuhkan
adalah sebanyak 28,282 sehingga terdapat sisa jam kerja. Namun
dapat dilihat bahwa distribusi kebutuhan engineer tidak merata,
ada beberapa waktu dimana terdapat peak akan kebutuhan
engineer.
Terdapat beberapa alternatif dalam yang dapat digunakan pada
situasi seperti ini. Pertama adalah dengan leveling permintaan
sesuai dengan fleksibilitas dari pada lingkungan produksi.

Kedua dengan mengubah suplai engineer hours, melakukan

tradeoff waktu antara periode overcapacity dan periode
undercapacity.
Dalam menghitung perlu dilakukan pertimbangan-pertimbangan
waktu libur serta cuti sakit. Akan terdapat delay-delay yang tidak
diekspektasi sebelumnya sehingga perlu diingat untuk tidak
membuat jadwal sumber daya lebih dari 85-90 persen dari
kapasitasnya. Juga pekerja akan diberikan waktu kerja overtime,
dimana kadang mereka tidak dibayar. Pada realitasnya seorang
engineer bekerja dari 50 hingga 60 jam seminggu. Sehingga dapat
dikatakan kapasitas pada periode tersebut yaitu:
55 jam x 21 engineers x 34 minggu x 85% = 33,379 jam waktu kerja

Waktu kerja tersebut sudah lebih dari yang dibutuhkan yaitu

sebanyak 22,282 jam waktu kerja.

9.5

PENJADWALAN CONSTRAINED RESOURCE

Kadang PM terkejut dengan terbatasnya sumber daya. Hal ini disebabkan
karena kegagalan dalam memasukkan ketersediaan sumber daya pada saat
identifikasi risiko. Ada banyak penyebabnya, antara lain adalah kegagalan
supplier dalam memproduksi dan mengantar sumber daya, pengalihan
sumber daya pada aktivitas lain dan kehilangan atau pencurian sumber daya.
Terdapat dua pendekatan dalam menyelesaikan masalah alokasi sumber daya:

Model Heuristik, yaitu menggunakan rule of thumb yang telah diketahui

berjalan dengan baik di situasi yang sama

Model Optimal, yaitu dengan mencari solusi terbaik jauh lebih terbatas
dalam kemampuannya menghadapi situasi kompleks

METODE HEURISTIK
Penggunaan pada netode heuristik ini adalah:
1. Hanya layak dalam menyelesaikan masalah yang besar,
nonlinear dan kompleks yang cenderung terjadi pada
proyek nyata.
2. Walaupun jadwal yang dikembangkan oleh metode ini
tidak optimal namun masih cukup bagus untuk banyak
kegunaan
3. PM dapat mengembangkan banyak jadwal yang berbeda
dengan cepat dan menentukan mana yang lebih baik dari
yang digunakan saat ini.

Kebanyakan metode heuristik dimulai dengan jadwal PERT/CPM dan

menganalisis penggunaan sumber daya per periode dan per sumber daya.
Perbedaan besar antara metode heuristik adalah aturan prioritas yang
digunakan. Perlu diingat bahwa kebutuhan teknologi selalu diutamakan.
Beberapa aturan prioritas yang paling sering ditemui adalah:
As Soon as Possible, merupakan aturan default pada penjadwalan
yang menawarkan solusi umum unutk path dan waktu critical
As Late as Possible, semua aktivitas dijadwalkan setelat mungkin
tanpa menunda proyek. Tujuannya adalah untuk menunda dana
keluar selama mungkin
Shortest Task First, tugas diatur berdasarkan durasi yaitu dengan
yang paling cepat pertama. Secara umum, aturan ini akan
memaksimalkan jumlah tugas yang dapat diselesaikan oleh sistem
dalam periode waktu.

Most Resource First, aktivitas diatur oleh penggunaan sumber

daya tertentu dengan yang paling besar adalah pertama. Asumsi
dari aturan ini adalah makin penting suatu tugas biasanya akan
memiliki permintaan yang lebih tinggi terhadap sumber daya langka

Minimum Slack First, aktivitas diatur oleh jumlah slack, slack yang
paling sedikit maka akan jalan duluan

Most Critical Followers, tugas diatur oleh jumlah aktivitas critical

yang mengikutinya. Yang paling banyak memiliki critical follower
maka jalan lebih dulu.

Most Successors, sama dengan aturan sebelum, kecuali bahwa

followernya dihitung

Arbitrary, prioritas ditugaskan pada aktivitas berdasarkan aturan

yang tidak berhubungan dengan panjang tugas, slack dan kebutuhan
yang dibutuhkan.

METODE OPTIMAL
Dalam beberapa tahun terakhir ini ada banyak cara yang dilakukan
dalam menyelesaikan permasalahan mengenai alokasi sumber
daya dan penjadwalan constrained resource Beberapa cara ini
bergantung pada tools grafis dan matematis. Terdapat dua metode
dalam mencari solusi optimal untuk masalah penjadwalan
constrained resource yaitu pemrograman matematika dan
enumerasi. Pada akhir tahun 1960 dan awal 1970an, teknik
enumerasi terbatas berhasil diaplikasikan pada permasalahan
sumber daya terbatas. Kemajuan dalam teknik pemrograman
linear (LP) menyebabkan penggunaan LP pada masalah
penjadwalan constrained resource yang besar. Pendekatan lainnya
mengkombinasi metode pemrograman dan enumerasi.

9.6

PENJADWALAN MULTIPROYEK DAN ALOKASI

SUMBER DAYA
Penjadwalan dan alokasi sumber daya pada multiproyek jauh lebih kompleks
bila dibandingkan dengan single proyek. Pendekatan yang paling sering
dilakukan adalah dengan menganggap bahwa tiap proyek adalah elemen yang
berbeda dari satu proyek besar. Pendekatan lainnya adalah dengan cara
menganggap bahwa tiap proyek benar-benar berbeda. Kedua pendekatan
tersebut membawa ini kepada hasil penjadwalan dan alokasi yang berbeda.
Biasanya permasalahan multiproyek termasuk menentukan bagaimana
mengalokasi sumber daya dan menentukan tanggal penyelesaian pada proyek
baru yang ditambahkan pada proyek yang sedang berlangsung. Sehingga ini
memerlukan pengembangan sistem penjadwalan multiproyek yang efisien dan
dinamis.

Terdapat 3 parameter yang mempengaruhi proyek:

1. Jadwal tertinggal
2. Utilisasi sumber daya
3. Inventori in-process
Tertinggalnya jadwal yaitu waktu yang melewati batas proyek
kadang menjadi kriteria paling penting. Ketertinggalan akan
menghasilkan ongkos penalty yang menurunkan keuntungan.
Ketertinggalan pada proyek juga akan menghasilkan efek domino,
menyebabkan proyek lain tertinggal juga.
Walaupun relatif mudah untuk mengukur ongkos dari kelebihan
utilisasi sumber daya yang disebabkan oleh kurang optimalnya
penjadwalan, namun ongkos pada penjadwalan multiproyek yang
tidak terkoordinasi akan tinggi juga.

Standar ketiga dari efektivitas adalah jumlah inventori in-process,

mengenai jumlah pekerjaan yang menunggu untuk diproses
karena terdapat kekurangan pada sumber daya. Dalam
menyelesaikannya yaitu mencakup tradeoff antara ongkos
inventori in-process dan ongkos sumber daya.
Ketiga kriteria sebelumnya tidak dapat dioptimalkan dalam waktu
yang sama. Seperti biasa akan terjadi tradeoff, yaitu perusahaan
harus memutuskan kriteria apa yang paling mungkin diaplikasikan
dan menggunakan kriteria tersebut unutk mengevaluasi berbagai
pilihan-pilihan alokasi sumber daya dan penjadwalan.
Seperti yang telah disebutkan, aturan minimum slack first
merupakan aturan prioritas keseluruhan yang paling baik dan
secara umum menghasilkan ketertinggalan proyek yang minimum.

TEKNIK HEURISTIK
Karena kesulitan dalam perumusan analisis dari masalah realistik,
maka cara utama dalam menyelesaikan masalah penjadwalan
constrained resource adalah dengan teknik heuristik.
Aturan yang paling sering digunakan adalah yang telah dijelaskan
pada bab 9.5. Basis logika dari aturan ini adalah mendahulukan
AOA dan AON. AOA dan AON menunjukkan lanjutan yang
lebih simpel dari pendekatan yang telah diketahui dan
penjadwalan job-shop. Beberapa tambahan heuristik untuk
alokasi sumber daya dikembangkan dan ditambahkan langsung
pada AOA dan AON. Metode berikut telah secara komersial
tersedia dari beberapa vendor software dalam versi yang
berbeda:

Metode Penjadwalan Sumber Daya, dalam menghitung prioritas

aktivitas/prioritas maka berikan pendahuluan yang menyebabkan
kenaikan minimum pada durasi proyek. Perbandingannya dibuat
dengan berpasangan antar aktivitas/proyek dalam set konflik.

Waktu Selesai Akhir Minimum, aturan ini menambahkan prioritas

pada aktivitas/proyek pada basis dari waktu penyelesaian seperti
yang ditentukan AOA atau AON. Aktivitas/proyek yang telat selesai
paling awal maka dijadwalkan pertama.

Permintaan Sumber Daya Paling Besar, metode ini

menambahkan prioritas pada basis total sumber daya yang
dibutuhkan dengan prioritas yang lebih tinggi diberikan pada
permintaan sumber daya yang lebih besar. Heuristik ini berdasarkan
usaha dalam memberikan prioritas kepada potensi hambatan
sumber daya.

Utilisasi Sumber Daya Paling Besar, aturan ini memberikan

prioritas pada kombinasi aktivitas yang menyebabkan utilisasi
sumber daya secara maksimum selama periode penjadwalan.
Aturan ini ternyata sama efektifnya dengan aturan minumum
slack untuk penjadwalan multiproyek, dimana kriteria yang
digunakan adalah project slippage.

Pekerjaan Paling Mungkin, prioritas diberikan pada set

aktivitas yang menyebabkan paling banyak aktivitas yang
dijadwalkan pada periode manapun.

PENJADWALAN HEURISTIC MULTIPROYEK

Dalam menyelesaikan permasalahan ini maka ingat kembali
pendekatan hierarkikal yang dilakukan pada chapter 6. Sebuah
aktivitas yang ditunjukkan dengan panah di agregasi tingkat tinggi
dapat menunjukkan keseluruhan network dari aktivitas di level
yang lebih rendah seperti yang ditunjukkan pada gambar 9-13
berikut:

Level lain dari perencanaan hierarki ditunjukkan pada Gantt chart

di gambar 9-14 berikut:

Apabila seluruh network didekomposisi kedalam subnetwork

maka kita akan mendapatkan permasalahan yang setara dengan
permasalahan multiproyek dimana tiap proyek dihubungkan pada
predecessor dan successor. Pada kasus ini hubungan predecessor/
successor bergantung pada teknologi yang dimiliki oleh proyek
induk.
Dengan model konseptual ini diasumsikan bahwa kita memiliki
beberapa proyek. Setiap proyek ditunjukkan oleh network dari
tugas-tugas. Kita dapat membentuk satu network dari proyekproyek tersebut dengan menghubungkannya dengan aktivitas
dummy. Kedua dummy dan aktivitas semu menunjukkan
hubungan ketergantungan, namun ketergantungan tersebut dapat
bersifat teknologikal dan berubah-ubah.

Setiap proyek ditunjukkan oleh network dari tugastugas. Kita dapat membentuk satu network dari
proyek-proyek tersebut dengan menghubungkannya
dengan aktivitas dummy. Kedua dummy dan aktivitas
semu menunjukkan hubungan ketergantungan, namun
ketergantungan tersebut dapat bersifat teknologikal
dan berubah-ubah.
Seperti biasa setiap tugas (kecuali dummy dan
aktivitas semu) membutuhkan sumber daya dan
waktu. Banyaknya waktu yang dibutuhkan dapat
berbeda dengan banyaknya kebutuhan sumber daya.

Masalah muncul saat kita merancang jadwal yang cocok

dengan ur utan ser ta resource constr aint dan
meminimalisir durasi secara keseluruhan pada network.
Jadwal yang dihasilkan harus menunjukkan kapan waktu
untuk memulai aktivitas dan pada level mana sumber daya
harus dijaga sementara sumber daya tersebut digunakan.
Heuristik versi Weist mengalokasikan sumber daya pada
aktivitas dalam urutan dari waktu mulai yang paling awal.
Pada periode awal dicatat semua tugas yang tersedia dan
urutkan dari slacknya dari yang paling kecil hingga yang
paling besar.

Aktivitas dipilih untuk sebagai pendukung dan

penjadwalan satu per satu sesuai urutan. Saat aktivitas
paling atas dari list didukung, stok sumber daya yang
relevan didebet. Tugas dijadwalkan secara berurutan
hingga daftar dari pekerjaan yang tersedia habis.
Dengan demikian sumber daya yang digunakan dalam
aktivitas hingga suplai dari sumber daya yang tersedia
habis. Apabila kita menghabiskan sebelum semua
aktivitas critical dijadwalkan maka kita dapat
menggunakan satu dari dua subheuristik.

Pertama kita dapat meminjam sumber daya

dari proyek yang sedang aktif namun bukan
tugas critical. Kedua kita dapat deschedule
tugas noncritical dan yang aktif.
Keputusan mengenai langkah mana yang
diambil, meminjam atau descheduling dapat
dibuat dengan menggunakan logika yang
sama yang digunakan pada chapter 7.

Namun keputusan untuk meminjam atau deschedule tergantung dari

estimasi dari dampak. Gambar 9-15 memperlihatkan 2 versi berbeda
dari siklus hidup yang telah dibahas pada chapter 7 proyek atau tugas.

Apabila tugas adalah Type 1 maka meminjam dapat meminimalkan

kerugian pada tugas, kecuali apabila tugas tersebut sudah hapir selesai
dan kita bersedia menerima hasilnya dalam tahap ini, dimana dapat
kita deschedule. Apabila tugasnya adalah Type 2 maka meminjam
dapat menyebabkan efek buruk pada tugas dan kita harus deschedule
atau menolaknaya sebagai sumber dari sumber daya.

9.7

GOLDRATTS CRITICAL CHAIN

Penyelesaian yang diketahui terbaik dalam masalah penjadwalan
constrained resource adalah dengan Goldratts Critical Chain (1997)
atau Rantai Kritis Goldratt.
Terdapat beberapa isu mengenai masalah yang dihadapi PM setiap hari:

Manajemen senior mengubah scope proyek tanpa konsultasi, tanpa

pemberitahuan, dan tanpa mengubah anggaran dan jadwal

Batas tanggal proyek ditentukan dengan perhatian kecil mengenai

ketersediaan sumber daya

Tidak ada jalan dalam menyelesaikan proyek tanpa melebihkan

anggaran.

Beban kerja proyek dan batas waktu ditentukan oleh tim

sales, bukan oleh jenis proyek dan tingkat sumber daya yang
dibutuhkan

Batas waktu proyek ditentukan secara tidak realistis sebagai

insentif agar SDM bekerja lebih keras dan lebih cepat.

Dalam menghadapi optimis bias yang kuat dalam banyak jadwal

proyek maka perlu mempertimbangkan beberapa hal:

Optimisme yang tidak bijaksana PM dengan keharusannya

dalam menolak keterlambatan adalah salah mereka, menghadapi
semua permasalahan yang dihadapi oleh proyeknya sebagai
pengecualian yang ketat, tindakan yang tidak dapat diramalkan
sehingga tidak memerlukan perencanaan subjek. Individual
seperti ini cenderung tidak menghiraukan manajemen risiko.

Kapasitas sebaiknya ditentukan sama dengan permintaan

Beberapa manajer senior tidak menyadari bahwa proyek bukanlah
sebuah perakitan dan bukan metode baris manajemen operasi
keseimbangan.

Student Syndrome
Istilah ini digunakan Goldratt pada
pandangannya bahwa mahasiswa selalu menginginkan waktu lebih
untuk menyelesaikan proyek. Apabila diberikan waktu lebih, mereka
akan menunda mulainya proyek hingga saat-saat terakhir. Hal ini
berhubungan dengan aktivitas dengan slack yang tinggi yang ditunda
hingga slack habis.

Multitasking untuk mengurangi idle time Misal terdapat situasi

dimana ada dua proyek, A dan B, masing-masing dengn aktivitas
berurutan dan anda sebagai sumber daya satu-satunya yang
dibutuhkan oleh kedua proyek.

Tiap aktivitas membutuhkan waktu 10 hari. Pada gambar 9-16

dapat dilihat bahwa ada dua Gantt chart unutk mengurutkan
aktivitas pada dua proyek:

Pertama, pindah dari proyek A ke proyek B untuk masing-masing

dari tiga aktivitas, yaitu melaksanakan Activity 1 untuk proyek A,
kemudian Activity 1 untuk proyek B, kemudian Activity 2 untuk
proyek A, dan seterusnya. Pada urutan kedua, selesaikan proyek A
sebelum memulai proyek B. Pada kedua kasus total waktu yang
dibutuhkan yaitu 60 hari. Kedua, perlu diingat bahwa proyek A
diselesaikan setelah 30 hari dan B setelah 60 hari. Pada diagram
pertama proyek A akan diselesaikan setelah 50 hari dan B setelah
60 hari. Sementara total waktu yang dibutuhkan sama, proyek A
telah diundur hingga 20 hari oleh pekerjaan multitasking ini. Hal
ini juga tidak menghiraukan bahwa beralih maju dan mundur
antar tugas menyebabkan ketidakefisienan dan ketidakefektifan
dalam menyelesaikan dua pekerjaan yang berbeda

Kompleksitas dari network tidak memberikan perbedaan

Misal terdapat dua proyek seperti yang dapat dilihat di gambar
9-17

Diasumsikan bahwa tiap aktivitas membutuhkan 10 hari dan

diketahui dengan pasti. Jelas bahwa proyek diselesaikan dalam 40
hari walaupun lebih kompleks dari proyek lain. Asumsi bahwa tiap
aktivitas bersifat stokastik dengan waktu yang terdistribusi normal.

Waktu rata-rata adalah 10 hari dan deviasi standar adalah 3 hari.

Apabila kita mensimulasikan proyek sebanyak 500 kali maka kita
akan mendapatkan hasilnya seperti pada tabel 9-4 dan 9-5
dibawah
tabel 9-4

tabel 9-5

Tabel 9-4 menjelaskan simulasi dari network sederhana dan

memperlihatkan rata-rata penyelesaian proyek yaitu 40 hari. Tabel
9-5 menjelaskan simulasi dari network kompleks dan rata-rata
penyelesaian kurang lebih 46 hari.

Manusia memerlukan alasan untuk bekerja keras

Seorang manajer senior berselisih paham mengenai pekerja
proyek yang selalu memiliki banyak waktu slack sehingga
membuat manajer memotong waktu lowongnya. Hal tersebut,
bagaimanapun, diketahui ditujukan untuk orang yang memiliki
kebutuhan tinggi akan pencapaian, tingkat motivasi diasosiasikan
dengan tingkat kegagalan.

Game playing Manajer senior dalam menjamin keberhasilan

proyeknya secara rutin meng-cut jadwal dan anggaran. Hal ini
menimbulkan ketidakpercayaan antar sesama.

DO EARLY FINISH AND LATE FINISH CANCEL

OUT? SO WHAT?
Salah

satu dari asumsi pada probabilistik network

adalah apabila aktivitas predecessor telat maka
akan secara langsung mempengaruhi aktivitas
setelahnya. Namun tidak berlaku sebaliknya, apabila
aktivitas predecessor diselesaikan lebih cepat dari
durasi yang diekspektasi maka tidak menjamin
aktivitas B dimulai pada waktu yang diharapkan.

Saat jadwal aktivitas ditentukan, dianggap bahwa

aktivitas akan dimulai segera setelah tanggal
penyelesaian dari aktivitas predecessor, namun
terkadang sumber daya belum tersedia sehingga
hal itu tidak terjadi. Pekerja proyek pun juga tidak
akan melaporkan bahwa proyek selesai sebelum
waktunya. Sumber daya yang belum tersedia pada
aktivitas successor saat aktivitas predecessor selesai
lebih awal karena manajer cenderung menunda
sumber daya pada proyek selama mungkin.

Apabila kita sepakat untuk memulai proyek segera

setalah aktivitaa predecessor selesai maka kita harus
memikirkan dengan matang mengenai ketersediaan
sumber daya dan menunggu dengan sabar sebelum
aktivitas dimulai. Sumber daya yang tidak digunakan,
bagaimanapun juga, tidak dapat diterima manajer yang
memiliki pandangan just-in-time.

CRITICAL CHAIN
Penjadwalan yang benar membantu menyelesaikan masalah yang
disebabkan oleh multitasking yang buruk, namun tidak menggiring
ke estimasi durasi proyek yang realistis.
Goldratt membantah bahwa dua aktivitas yang dijadwalkan
dilakukan secara paralel dan menggunakan sumber daya langka
yang sama tidak independen seperti yang disumsikan teori
konvensional. Apabila pasokan sumber daya dari sumber daya
langka tidak mencukupi maka yang manapun dari keduanya yang
diberikan prioritas dapat memanjangkan path aktivitas lainnya
namun tidak pada durasi aktualnya.

Diasumsikan terdapat dua path paralel, A1-B dan A2-C. A1 dan A2

membutuhkan sumber daya langka yang sama. B dan C
menggunakan dua sumber daya berlainan. A1 membutuhkan 7 hari,
A 2 membutuhkan 5 hari, B membutuhkan 10 hari, C
membutuhkan 6 hari, sehingga path A1-B berlangsung 17 hari dan
path A2-C berlangsung 11 hari. Apabila tidak terdapat sumber daya
langka yang cukup maka harus dikerjakan berurutan. Apabila A1
dikerjakan pertama maka A2 tidak dapat dikerjakan hingga A1
selesai, sehingga menambahkan 7 hari pada path A 2 -C,
membuatnya menjadi berlangsung 18 hari dan mengundur tanggal
penyelesaian sebanyak 1 hari. Bila A2 dikerjakan pertama maka
akan menambahkan 5 hari pada A1 membuatnya jadi berlangsung
22 hari.
.

Path terpanjang dari aktivitas time-dependent secara berurutan disebut critical

chain atau rantai kritis. Sebuah proyek dibuat dari critical chan dan noncritical
chain seperti yang digambarkan oleh gambar 9-18 berikut:

Terdapat dua sumber delay dari proyek yang disebabkan oleh delay dari satu
atau lebih aktivitas dalam critical chain dan delay dari aktivitas dalam noncritical
chain. Project buffer melindungi critical chain dan feedeng buffer melindungi
feeder path. Sumber daya yang digunakan oleh aktivitas pada critical chain
diberikan prioritas sehingga mereka dapat tersedia saat dibutuhkan.

SELESAI