ALOKASI SUMBER DAYAwa ode rizkylla | 14412039

OVERVIEWSetelah 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.

METODE CRITICAL PATHSaat 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.

9.1

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 l ihat memungk inkan d i lakukanpun mustah i l da lam 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-d-dummy (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 all-normal 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.

MASALAH ALOKASI SUMBER DAYAKesalahan 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.

9.2

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.

LOADING SUMBER DAYALoading 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.

9.3

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

LEVELING SUMBER DAYAPada 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

9.4

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 “just-in-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 buruh untuk menghindar i perekrutan 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 PASTIANGambar 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.

PENJADWALAN CONSTRAINED RESOURCEKadang 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

9.5

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.

METODE HEURISTIK

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 criticalAs 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.

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.

METODE OPTIMAL

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.

9.6

Terdapat 3 parameter yang mempengaruhi proyek:1. Jadwal tertinggal2. Utilisasi sumber daya3. 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.

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:

TEKNIK HEURISTIK

• 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.

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:

PENJADWALAN HEURISTIC MULTIPROYEK

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 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.

Setiap proyek ditunjukkan oleh network dari tugas-tugas. 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 urutan ser ta resource constraint 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.

GOLDRATT’S CRITICAL CHAINPenyelesaian yang diketahui terbaik dalam masalah penjadwalan constrained resource adalah dengan Goldratt’s 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.

9.7

• 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.

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.

DO EARLY FINISH AND LATE FINISH CANCEL OUT? SO WHAT?

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.

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.

CRITICAL CHAIN

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, A2 membutuhkan 5 har i, B membutuhkan 10 har i, 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 A2-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