BAB II TINJAUAN PUSTAKA. lingkungannya, serta prinsip-prinsip yang digunakan sebagai petunjuk dalam

Teks penuh

(1)

BAB II

TINJAUAN PUSTAKA

2.1 Arsitektur Enterprise

Menurut Surendro (2009) sesuai dengan IEEE (1471-2000), arsitektur adalah pengorganisasian yang fundamental dari suatu sistem yang terdiri dari beberapa komponen, relasi yang terjadi antara komponen dan beberapa lingkungannya, serta prinsip-prinsip yang digunakan sebagai petunjuk dalam desain dan evolusinya.

Menurut Spewak (1992), definisi dari enterprise adalah organisasi (atau badan lintas organisasi) yang mendukung lingkup bisnis dan misi yang telah ditetapkan. Definisi enterprise dapat berarti suatu daerah aktivitas umum dan tujuan dalam sebuah organisasi atau antara beberapa organisasi, dimana informasi dan sumber daya lainnya dipertukarkan (Bernard dalam Sanny, dkk., 2012).

Arsitektur enterprise adalah kumpulan prinsip, metode dan model yang bersifat masuk akal yang digunakan untuk mendesain dan merealisasikan sebuah struktur organisasi enterprise, proses bisnis, sistem informasi dan infrastrukturnya (Surendro, 2009). Arsitektur enterprise memiliki empat komponen utama (Setiawan, 2009), yaitu arsitektur bisnis, arsitektur informasi (data), arsitektur teknologi dan arsitektur aplikasi.

Luaran yang dapat dicapai dari rancangan arsitektur enterprise tersebut adalah menghasilkan model dan kerangka dasar (blueprint) dalam mengembangkan sistem informasi yang terintegrasi untuk mendukung kebutuhan organisasi (Yunis dan Surendro, 2009).

(2)

2.2 Arsitektur Bisnis

Menurut Surendro (2009), arsitektur bisnis menggambarkan strategis, maksud, fungsi, proses informasi dan aset bisnis yang penting untuk memberikan layanan bagi masyarakat, bisnis, pemerintah dan sebagainya. Kerangka arsitektur bisnis memberikan struktur untuk pengumpulan detail mengenai motivasi, organisasi, lokasi, kejadian, fungsi dan aset yang menentukan arah perusahaan dari sudut pandang bisnis. Rincian yang terdapat dalam arsitektur bisnis mendukung pengambilan keputusan bisnis dengan menyediakan dokumentasi tentang dimana posisi perusahaan berada saat ini dan di mana perusahaan ingin berada di suatu waktu di masa depan.

Arsitektur bisnis juga menunjukkan relasi atau hubungan antara aktivitas, kemampuan, fungsi, proses, waktu, urutan proses, sumber daya, orang, ketergantungan, kebutuhan, kolaborasi, organisasi, lokasi, batasan, data, sistem, peralatan, biaya, kontrol, keputusan, rules, keputusan, alur bisnis, aktivitas manual & otomatis, transaksi, perbedaan, dan kemungkinan (Yunis, dkk., 2010).

2.3 Perencanaan Arsitektur Enterprise

Perencanaan Arsitektur Enterprise (selanjutnya disebut PAE) merupakan pendekatan yang dibuat oleh Spewak (1992) untuk membangun arsitektur

enterprise dengan berdasarkan dorongan data dan dorongan bisnis. Arsitektur

enterprise berkaitan dengan bagaimana komunikasi dibuat atau dibangun dari

proses bisnis tingkat tinggi dan dari kebutuhan IT suatu operating

model perusahaan. Arsitektur enterprise direpresentasikan dalam bentuk

(3)

dituangkan dalam sebuah gambar berbentuk diagram yang dapat mewakili ketiga komponen (bisnis, data, dan teknologi).

Menurut Surendro (2009), perencanaan arsitektur enterprise merupakan proses mendefinisikan arsitektur-arsitektur untuk penggunaan informasi yang mendukung bisnis dan juga mencakup rencana untuk mengimplementasikan arsitektur tersebut.

2.4 Kerangka Kerja Perencanaan Arsitektur Enterprise

Kerangka kerja arsitektur enterprise mengidentifikasikan jenis informasi yang dibutuhkan untuk mendeskripsikan arsitektur enterprise, mengorganisasikan jenis informasi dalam struktur logis, dan mendeskripsikan hubungan antara jenis informasi tersebut. Informasi dalam arsitektur enterprise sering dikategorikan dalam model-model atau sudut pandang arsitektural (Setiawan, 2009).

Ada beberapa kerangka kerja dalam perencanaan arsitektur enterprise yang dapat digunakan, meliputi : (Minoli, 2008)

a. The Open Group Architecture Framework (TOGAF) b. Zachman Enterprise Architecture Framework

c. Extended Enterprise Architecture Framework (E2AF) d. Enterprise Architecture Planning (EAP)

e. Federal Enterprise Architecture Framework (FEAF) f. Treasury Enterprise Architecture Framework (TEAF) g. Capgemini‘s Integrated Architecture Framework (IAF) h. Joint Technical Architecture (JTA)

(4)

i. Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) and DoDAF

j. Department of Defense Technical Reference Model (DoD TRM)

k. Technical Architecture Framework for Information Management (TAFIM) l. Computer Integrated Manufacturing Open System Architecture (CIMOSA) m. Purdue Enterprise Reference Architecture (PERA)

n. Standards and Architecture for eGovernment Applications (SAGA) o. European Union—IDABC & European Interoperability Framework

ISO/IEC 14252 (IEEE Std 1003.0)

p. IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description

Dari sekian banyak kerangka kerja dalam Enterprise Architecture

Planning, hanya beberapa yang populer digunakan dikalangan perancang sistem

informasi. Hal ini dikuatkan berdasarkan survei ―Trends in Enterprise

Architecture 2005‖ bahwa berdasarkan hasil survei mengenai perkembangan

penggunaan enterprise architecture framework (EAF) di dunia yang paling stabil digunakan oleh perusahaan dalam kurun waktu tiga tahun adalah The Zachman

Framework for Enterprise Architecture dan TOGAF (Schekkermen, 2005 dalam

Supriyana, 2010).

Berdasarkan hasil survei di atas, maka akan diulas lebih dalam, dua

framework yang lebih banyak digunakan dan populer yaitu Zachman Framework

(5)

2.4.1 Zachman framework

Kerangka kerja Zachman merupakan suatu skema untuk melakukan klasifikasi dalam melakukan pengorganisasian artifak enterprise yang diperkenalkan pertama kali oleh Zachman pada tahun 1987, kemudian diperluas dan diformulasikan oleh Sowa dan Zachman pada tahun 1992. Kerangka kerja Zachman merupakan kerangka kerja untuk memetakan hubungan antara komponen enterprise terhadap level arsitektur yang menjadi perhatian pihak-pihak yang berkepentingan dengan arsitektur enterprise. Tujuan dari framework ini adalah menyediakan struktur dasar yang menunjang organisasi, akses, integrasi, interpretasi, pengembangan, manajemen serta perubahan representasi arsitektur dari sistem informasi organisasi. Setiap obyek/deskripsi dari representasi arsitektur direferensikan sebagai artifact (Widodo, 2010).

Zachman framework bukanlah merupakan metode untuk mengembangkan arsitektur sistem informasi, tetapi Zachman framework hanyalah merupakan sebuah kerangka kerja untuk mengkategorikan artifact arsitektur sistem informasi atau dengan kata lain, Zachman framework memberikan gambaran hasil dari arsitektur sistem informasi.

Dalam gambar 2.1 dapat dijelaskan secara umum tiap kolom merepresentasikan fokus, abstraksi, atau topik arsitektur enterprise, yaitu:

1. What (data) : menggambarkan kesatuan yang dianggap penting dalam bisnis. Kesatuan tersebut adalah hal –hal yang informasinya perlu dipelihara.

2. How (functions) : mendefinisikan fungsi atau aktifitas. Input dan output juga dipertimbangkan di kolom ini.

(6)

3. Where (networks) : menunjukkan lokasi geografis dan hubungan antara aktifitas dalam organisasi, meliputi lokasi geografis bisnis yang utama.

4. Who (people) : mewakili manusia dalam organisasi dan metrik untuk mengukur kemampuan dan kinerjanya. Kolom ini juga berhubungan dengan antar muka pengguna dan hubungan antara manusia dan pekerjaan yang menjadi tanggung jawabnya.

Gambar 2.1 Zachman Framework

5. When (time) : mewakili waktu atau kegiatan yang menunjukkan kriteria kinerja. Kolom ini berguna untuk mendesain jadwal dan memproses arsitektur.

6. Why (motivation) : menjelaskan motivasi dari organisasi dan pekerjanya. Disini terlihat tujuan, sasaran, rencana bisnis, arsitektur pengetahuan, alasan pikiran, dan pengambilan keputusan dalam organisasi.

(7)

2.4.2 TOGAF (The Open Group Architecture Framework)

TOGAF merupakan kerangka kerja dan metode yang diterima luas dalam pengembangan arsitektur perusahaan. Spesifikasi pertama TOGAF diperkenalkan pada tahun 1995. TOGAF merupakan hasil pengembangan forum Open Group yang merupakan forum kerja sama antara vendor dan pengguna.

Berikut ini adalah struktur dan komponen dari TOGAF : (Open Group dalam Mutyarini, 2006)

1. Architecture Development Method

TOGAF (The Open Group Architecture Framework) memberikan metode yang detail mengenai bagaimana membangun, mengelola, dan mengimplementasikan arsitektur enterprise dalam sistem informasi yang disebut dengan Architecture Development Method (ADM), dimana ADM merupakan hasil dari kerjasama praktisi arsitektur dalam Open Group Architecture Forum. Elemen kunci dari TOGAF adalah Architecture Development Method (ADM) yang memberikan gambaran spesifik untuk proses pengembangan arsitektur enterprise (Lise dalam Somantri, 2011). ADM merupakan metode generik yang berisikan sekumpulan aktifitas yang mempresentasikan progresi dari setiap fase ADM dan model arsitektur yang digunakan dan dibuat selama tahap pengembangan Arsitektur Enterprise (Surendro, 2009).

ADM adalah fitur penting yang memungkinkan perusahaan mendefinisikan kebutuhan bisnis dan membangun arsitektur spesifik untuk memenuhi kebutuhan itu. ADM terdiri dari tahapan-tahapan yang dibutuhkan dalam membangun arsitektur enterprise seperti ditunjukkan gambar 2.2.

(8)

Gambar 2.2 Tahapan TOGAF ADM

Tahapan dari TOGAF ADM bisa dijelaskan sebagai berikut (Open Group dalam Somantri, 2011) :

a. Preliminary Framework and Priciple (Tahapan A)

Tahapan persiapan (Preliminary Stage) merupakan tahapan untuk menentukan ruang lingkup Enterprise Architecture (EA) yang akan dikembangkan serta menentukan komitmen dengan manajemen dalam pengembangan EA.

b. Architecture Vision (Tahapan B)

Tahap architecture vision menciptakan keseragaman pandangan mengenai pentingnya arsitektur enterprise untuk mencapai tujuan organisasi yang dirumuskan dalam bentuk strategi serta menentukan lingkup dari arsitektur yang akan dikembangkan. Pada tahapan ini berisikan

(9)

kebutuhan-kebutuhan berkenaan dengan perancangan arsitektur sistem informasi yaitu profil organisasi, pendefinisian visi dan misi, tujuan organisasi, sasaran organisasi, proses bisnis organisasi, unit organisasi dan kondisi arsitektur saat ini.

c. Business Architecture (Tahapan C)

Tahap business architecture mendefinisikan kondisi awal arsitektur bisnis, menentukan model bisnis atau aktivitas bisnis yang diinginkan berdasarkan skenario bisnis. Pada tahap ini tools dan method umum untuk pemodelan seperti: Integration DEFinition (IDEF), Unified Modeling

Language (UML) dan BPMN (Business Process Modelling Notation) bisa

digunakan untuk membangun model yang diperlukan. d. Information System Architecture (Tahapan D)

Pada tahap information system architecture lebih menekankan pada aktivitas bagaimana arsitektur sistem informasi dikembangkan. Pendefinisian arsitektur sistem informasi dalam tahapan ini meliputi arsitektur data dan arsitektur aplikasi yang akan digunakan oleh organisasi. Arsitektur data lebih memfokuskan pada bagaimana data digunakan untuk kebutuhan fungsi bisnis, proses dan layanan. Teknik yang bisa digunakan dengan yaitu: ER-Diagram, Class Diagram, dan Object Diagram.

e. Technology Architecture (Tahapan E)

Tahap technology architecture membangun arsitektur teknologi yang diinginkan, dimulai dari penentuan jenis kandidat teknologi yang diperlukan dengan menggunakan Technology Portfolio Catalog yang meliputi perangkat lunak dan perangkat keras.

(10)

f. Opportunities and Solution (Tahapan F)

Tahap opportunities and solution lebih menekan pada manfaat yang diperoleh dari arsitektur enterprise yang meliputi arsitektur bisnis, arsitektur data, arsitektur aplikasi dan arsitektur teknologi, sehingga menjadi dasar bagi stakeholder untuk memilih dan menentukan arsitektur yang akan diimplementasikan.

g. Migration Planning (Tahapan G)

Tahap migration planning akan dilakukan penilaian dalam menentukan rencana migrasi dari suatu sistem informasi. Biasanya pada tahapan ini untuk pemodelannya menggunakaan matrik penilaian dan keputusan terhadap kebutuhan utama dan pendukung dalam organisasi terhadap implementasi sistem informasi.

h. Implementation Governance (Tahapan H)

Tahap implementation governance merupakan tahap penyusunan rekomendasi untuk pelaksanaan tatakelola implementasi yang sudah dilakukan, tatakelola yang dilakukan meliputi tatakelola organisasi, tatakelola teknologi informasi, dan tatakelola arsitektur.

i. Architecture Change Management (Tahapan I)

Tahap architecture change management menetapkan rencana manajemen arsitektur dari sistem yang baru dengan cara melakukan pengawasan terhadap perkembangan teknologi dan perubahan lingkungan organisasi, baik internal maupun eksternal serta menentukan apakah akan dilakukan siklus pengembangan arsitektur enterprise berikutnya.

(11)

2. Foundation Architecture (Enterprise Continuum)

Foundation Architecture merupakan sebuah ―framework-within-a-framework‖

yang menyediakan hubungan bagi pengumpulan aset bantuan petunjuk pada saat terjadinya perpindahan abstraksi level yang berbeda. Foundation

Architecture terdiri dari :

a. Technical Reference Model – menyediakan sebuah platform dan klasifikasi dari platform generik.

b. Standard Information Base – menyediakan standar-standar dasar dari informasi.

c. Building Block Information Base – menyediakan blok-blok dasar informasi di masa yang akan datang.

3. Resource Base

Bagian ini memberikan sumber-sumber informasi berupa guidelines,

templates, checklist, latar belakang informasi dan detail material pendukung

yang membantu arsitek di dalam penggunaan Architecture Development

Method (ADM).

TOGAF memandang enterprise architecture ke dalam empat kategori. Keempat kategori tersebut adalah (Setiawan, 2009) :

a. Business Architecture

Business Architecture mendeskripsikan tentang bagaimana proses bisnis untuk

mencapai tujuan arsitektur. b. Application Architecture

Application Architecture merupakan pendeskripsian bagaimana aplikasi

(12)

c. Data Architecture

Data Architecture adalah penggambaran bagaimana penyimpanan pengelolaan

dan pengaksesan data pada perusahaan. d. Technical Architecture

Technical Architecture merupakan gambaran mengenai infrastruktur

hardware dan software yang mendukung aplikasi dan bagaimana interaksinya.

2.5 Pemilihan kerangka kerja arsitektur enterprise

Proses pemiilihan sebuah kerangka kerja arsitektur enterprise tidak bisa dilakukan tanpa memiliki landasan tertentu, akan tetapi terdapat kriteria yang berbeda yang bisa dijadikan sebagai acuan (Setiawan, 2009), yaitu :

a. Tujuan dari arsitektur enterprise dengan melihat bagaimana definisi arsitektur dan pemahamannya, proses arsitektur yang telah ditentukan sehingga mudah untuk diikuti, dukungan terhadap evolusi arsitektur.

b. Input untuk aktivitas arsitektur enterprise seperti pendorong bisnis dan input teknologi.

c. Output dari aktivitas arsitektur enterprise seperti model bisnis dan desain transisional utnuk evolusi dan perubahan Framework.

Framework merupakan sebuah bagian penting dalam pendesainan

arsitektur enterprise yang seharusnya memiliki kriteria : a. Reasoned

Framework yang masuk akal yang dapat memungkinkan pembuatan arsitektur

(13)

integritasnya walaupun menghadapi perubahan bisnis dan teknologi serta

demand yang tak terduga.

b. Cohesive

Framework yang kohesif memiliki sekumpulan perilaku yang akan seimbang

dalam cara pandang dan ruang lingkupnya. c. Adaptable

Framework seharusnya bisa beradaptasi terhadap perubahan yang mungkin

sangat sering terjadi dalam organisasi. d. Vendor-independent

Framework seharusnya tidak tergantung pada vendor tertentu untuk

benar-benar memaksimalkan benefit bagi organisasi. e. Technology-independent

Framework seharusnya tidak tergantung pada teknologi yang ada saat ini, tapi

dapat menyesuaikan dengan teknologi baru. f. Domain-neutral

Domain-neutral merupakan atribut penting bagi framework agar memiliki

peranan dalam pemeliharaan tujuan organisasi. g. Scalale

Framework seharusnya beroperasi secara efektif pada level departemen, unit

bisnis, pemerintahan dan level korporat tanpa kehilangan fokus dan kemampuan untuk dapat diaplikasikan.

Menurut Sessions dalam Supriyana (2010), bahwa Zachman framework adalah sebuah taxonomy, TOGAF merupakan sebuah proses. Hasil pembandingan yang dilakukan oleh Setiawan (2009) dengan cara memetakan Zachman

(14)

framework dan TOGAF sesuai dengan kriteria kedalam sebuah tabel sebagai bahan pertimbangan dalam pemilihan EA Framework dapat dilihat dalam Tabel 2.1 (Setiawan, 2009).

Tabel 2.1 Perbandingan EA Framework

Kriteria Zachman TOGAF

Definisi arsitektur dan pemahamannya

Parsial Ya, Pada fase preliminary Proses Arsitektur yang detail ya Ya, ADM dengan 9 fase yang

detail Support terhadap evolusi

Arsitektur

tidak Ya, Ada fase migration planning Standarisasi Tidak Ya, Menyediakan TRM, standards

Information Architecture Knowledge

Base

Tidak Ya Pendorong bisnis Parsial Ya Input Teknologi Tidak Ya

Model bisnis Ya Ya

Desain transisional Tidak Ya, Hasil fase migration planning

Neutrality Ya Ya

Menyediakan Prinsip arsitektur Tidak Ya

2.6 Pemodelan Proses Bisnis

2.6.1 Unified Modelling Language (UML)

Unified Modelling Language (UML) adalah bahasa standart yang

digunakan untuk menentukan, visualisasi, membangun dan mendokumentasikan

(15)

UML bukanlah sebuah metoda tapi notasi dan tidak memiliki sebuah tahapan proses (Barclay dan Savage dalam Somantri 2011). Hal terpenting dari UML adalah pemodelan dalam bentuk diagram yang memiliki peranan terpenting dalam pengembangan perangkat lunak berbasis objek. Tujuan utama dalam perancangan UML adalah memberikan dasar formal untuk memahami pemodelan bahasa.

Bentuk diagram UML yang akan dijelaskan adalah sebagai berikut : 1. Use Case Diagram

Diagram use case merupakan salah satu diagram untuk memodelkan perilaku sistem dan merupakan pusat pemodelan perilaku sistem, subsistem dan kelas. Masing-masing diagram use case menunjukkan sekumpulan use case, actor dan hubungannya (Bambang dalam Somantri 2011). Use case adalah sekumpulan scenario yang akan menjelaskan interaksi antara user dan sistem (IBM dalam Somantri 2011).

Tujuan utama pemodelan use case adalah (Bambang dalam Somantri 2011) :

a. Memutuskan dan mendeskripsikan kebutuhan-kebutuhan fungsional sistem. b. Memberikan deskripsi jelas dan konsisten dari apa yang seharusnya dilakukan,

sehingga model use case digunakan diseluruh proses pengembangan untuk mengacu sistem harus memberikan fungsionalitas yang dimodelkan pada use case.

c. Menyediakan basis untuk melakukan pengujian sistem yang memverifikasi sistem.

(16)

Diagram use case memiliki dua komponen penting, yaitu actor dan use case. Gambar 2.3 merepresentasikan notasi dari dua komponen diagram use case tersebut. Aktor merepresentasikan user atau sistem lain yang berinteraksi dengan sistem yang akan dimodelkan. Uses case merupakan pandangan luar sistem yang merepresentasikan sebuah aksi user.

Gambar 2.3 Dua komponen diagram use case actor dan use case 2. Activity Diagram

Activity Diagram merupakan diagram yang merepresentasikan

fungsionalitas dari sistem untuk menjelaskan aktivitas sistem. Activity Diagram berupa operasi-operasi dan aktivitas di use case, diagram ini dapat digunakan untuk menjelaskan mekanisme dari aliran kerja bisnis, aksi pemrosesan dan aliran eksekusi dari use case.

Gambar 2.4 Notasi komponen dalam activity diagram.

Gambar 2.4 merepresentasikan beberapa komponen yang digunakan dalam

(17)

merepresentasikan aktivitas sistem atau user, join flow merepresentasikan aktivitas paralel.

2.6.2 Business Process Modelling Notation (BPMN)

Business Process Modelling Notation (BPMN) adalah sebuah grafik notasi

yang menggambarkan logika dari langkah-langkah dalam sebuah alur proses bisnis. Notasi tersebut digunakan untuk mengkoordinasikan rangkaian proses dan pesan-pesan yang terjadi antara partisipan/role di dalam aktivitas yang berbeda. BPMN digunakan untuk mempermudah dan memperjelas aktifitas dalam suatu proses bisnis.

BPMN sendiri adalah sebuah standar notasi grafik untuk menggambarkan proses bisnis dalam sebuah workflow. Terdapat 4 kategori dari elemen-elemen dalam BPMN, yaitu : (http://elib.unikom.ac.id/download.php?id=80727)

1. Flow Objects

a. Events, sebuah event direpresentasikan dengan lingkaran. Events dapat berupa Start, Intermediate, atau End.

Gambar 2.5 Flow Object

b. Activities, sebuah aktivitas direpresentasikan dengan persegi dengan sudut melingkar dan memperlihatkan pekerjaan yang harus dilakukan.

(18)

c. Gateways, sebuah gateway direpresentasikan dengan belah ketupat dan memperlihatkan pilihan yang berbeda. Gateway juga menjelaskan mengenai percabangan dan penggabungan dari path yang ada.

Gambar 2.7 Gateways 2. Connecting Objects

a. Sequence Flow, sequence flow direpresentasikan dengan garis lurus dengan panah tertutup dan menjelaskan mengenai urutan aktivitas yang akan dijalankan.

Gambar 2.8 Sequence Flow

b. Message Flow, message flow direpresentasikan dengan garis putus-putus dan panah terbuka. Message flow menjelaskan pertukaran pesan yang sedang terjadi.

Gambar 2.9 Message Flow

c. Association, association direpresentasikan dengan garis putus-putus.

Association digunakan untuk mengasosiasikan sebah artifak, data, maupun

flow object.

(19)

3. Swimlanes

a. Pool, pool direpresentasikan dengan persegi besar yang didalamnya dapat berisi flow objects, connecting object, maupun artifak.

b. Lane, lane merupakan bagian lebih mendetail dari pool.

Gambar 2.11 Swimlanes 4. Artifacts

a. Data Objects, data object digunakan untuk menjelaskan mengenai data yang dibutuhkan atau dihasilkan dari sebuah aktivitas.

Gambar 2.12 Artifacts

b. Group, group direpresentasikan dalam persegi dengan sudut melingkar dan garis luar putus-putus. Group untuk melakukan grouping aktivitas.

Gambar 2.13 Group

(20)

Gambar 2.14 Annotation

2.6.3 Metodologi perbaikan proses bisnis

Peppard & Rowland mengklasifikasikan pendekatan- pendekatan yang berbeda terhadap perbaikan proses bisnis yaitu perancangan ulang secara sistematis. Perancangan ulang secara sistematis yaitu mengidentifikasi dan memahami proses-proses yang ada dan kemudian mengolah proses tersebut secara sistematis untuk menciptakan proses - proses baru guna memberikan hasil yang diinginkan (Hadisaputra dan Tjoeng, 2009).

Saat merancang ulang proses yang sudah ada, penekanannya adalah pada eliminasi semua kegiatan yang tak bernilai tambah dan merampingkan kegiatan yang bernilai tambah. Peraturan dalam melakukan ini dapat diringkas sebagai ESIA (Hadisaputra dan Tjoeng, 2009):

a. Mengeliminasi (Eliminate).

Semua tahap yang tidak bernilai tambah dalam proses harus dieliminasi, berikut ini contoh-contoh kegiatan yang sering ada dalam perusahaan yang cenderung tidak bernilai tambah sehingga mempunyai potensi untuk dieliminasi:

1. Produk berlebihan, memproduksi lebih daripada yang dibutuhkan pada waktu tertentu adalah sumber utama pemborosan. Semua produksi berlebihan akan menyebabkan penumpukkan persediaan dan berpotensi menimbulkan masalah.

(21)

harus menunggu sesuatu. Pekerjaan akan terhambat atau terhenti karena harus menunggu material tersebut tiba, menunggu, keputus-asaan dan sebagainya, sebagaimana kita ketahui waktu adalah uang.

3. Transportasi, pemindahan, dan gerakan, setiap kali orang, material dan kertas berpindah itu membutuhkan biaya. Sesuatu atau seseorang harus memindahkan material atau kertas dan waktu yang dihabiskannya adalah waktu yang digunakan untuk menambah nilainya. Perpindahan orang juga tidak murah- mengapa mereka berpindah, nilai apa yang mereka tambahkan dan apakah waktunya tidak lebih baik dihabiskan untuk mengerjakan potongan materi atau kertas berikutnya, atau bahkan dengan pelanggan yang lain.

4. Pemrosesan, apakah proses tersebut menambah nilai? Jika tidak, mengapa proses tersebut dilakukan? Jika ya, apakah proses tersebut efisien? Apa mungkin proses tersebut yang bernilai tambah tadi lebih dikembangkan dengan mengeliminasi penyebab variabilitasnya atau dengan meningkatkan kepastian hasil proses.

5. Persediaan dan paperwork, mengapa persediaan dan paperwork dibutuhkan? Apakah benar-benar perlu untuk memastikan kepuasan pelanggan? Mungkin paperwork diperlukan untuk bagian lain dari rangkaian proses atau tugas tersebut. Persediaan yang berlebih akan merupakan masalah besar bagi pabrik-pabrik. Demikian pula halnya, paperwork dan formulir yang berlebihan cenderung menghasilkan ketidak-efisienan proses karena menambah birokrasi dan biasanya hanya sedikit kontribusinya yang secara aktual akan bermanfaat bagi pelanggan.

(22)

6. Produk cacat, rusak dan pengerjaan ulang – sasaran perusahaan seharusnya adalah melakukan segala sesuatu secara benar dari awal dan menghindari biaya tenaga, biaya material, gangguan serta biaya kesempatan yang dibutuhkan untuk meralat atau mengatasi masalah karena kesalahan proses awal. Hal yang penting disini adalah bahwa yang harus dieliminasi adalah penyebab kegagalan yang merupakan masalah proses.

7. Duplikasi tugas, setiap tugas yang dilakukan harus memberikan nilai tambah dengan cara-cara tertentu. Jika sebuah tugas diulang, ini tidak menambah nilai, tetapi hanya menambah biaya. Bertambahnya paperwork dan pemasukkan data ke dalam sistem komputer sering ditemukan berulang-ulang terjadi dalam kebanyakan perusahaan. Akibat duplikasi tugas ini adalah timbulnya kemungkinan kesalahan dan ketidaksesuaian antara pengerjaan pertama dan pengerjaan selanjutnya.

8. Format ulang atau transfer informasi, hal ini merupakan bentuk lain dari duplikasi. Cukup sering data ditransfer dari satu bentuk ke bentuk lain atau dicetak dari suatu sistem komputer untuk diinput kembali secara manual ke sistem yang lain. Ini sering terjadi jika informasi bergerak melalui batasan organisasional.

9. Inspeksi, pemantauan, pengendalian, meskipun dapat saja hal ini muncul karena alasan justifikasi, banyak diantaranya yang muncul karena alasan historis dan menjadi tradisi pekerjaan dan lapisan manajemen. Seringkali pemantauan dan pengendalian dilakukan apabila proses melalui batasan departemental. Seiring dengan makin dipertanyakannya bentuk-bentuk struktur organisasi, semakin banyak pula pemantauan dan pengendalian

(23)

yang dipandang tidak relevan. Ada baiknya membuat pembedaan yang nyata antara bermacam-macam jenis pemantauan dan pengendalian, karena ini harus dibuat pendekatan tujuan yang berbeda yang memang benarbenar perlu untuk melakukan pengendalian atau inspeksi.

10. Jelas bahwa organisasi harus menyesuaikan diri dengan tuntutan peraturan dan mungkin ada alasan untuk setiap tindakan tersebut, seperti pemeriksaan kesehatan dan keamanan. Organisasi mungkin memang harus mempunyai ‗bahan pengawas‘, tetapi harus tetap ada keleluasaan dalam kendali-kendali atau sasaran/target yang diterapkan untuk dirinya sendiri. Organisasi harus memahami secara jelas keperluan setiap pihak, demi kepentingan jaminan atau produktivitas/kesehatan finansial.

11. Rekonsiliasi, serupa dengan pemantauan dan pengendalian serta birokrasi kalsik masa lalu. Meskipun perlu untuk memastikan bahwa segala sesuatu cocok/sesuai, realisasi proses secara keseluruhan juga tidak kalah penting. Eliminasi hal ini dapat merupakan sumber peningkatan efisiensi yang signifikan dan kemudian otomatisasi terhadap jumlah rincian yang harus dicocokkan.

Pada setiap titik dalam proses, hal ini yang harus diperhatikan dan dipertimbangkan adalah konstribusi apa yang diberikan bagi tugas pelayanan pelanggan. Kegiatan-kegiatan yang tidak bernilai tambah ini merupakan target pertama bagi setiap inisiatif perancangan ulang proses secara sistematis. Selanjutnya bagaimana cara mengeliminasi atau meminimalkan aktivitas tersebut tanpa berdampak negatif terhadap proses bersangkutan.

(24)

Seringkali mengeliminasi sebanyak mungkin tugas yang tidak diperlukan, selanjutnya tugas tersisa perlu disederhanakan. Biasanya hal-hal berikut yang berpotensi untuk disederhanakan atau untuk membantu menyederhanakan proses:

1. Prosedur, seringkali prosedur-prosedur yang ada terlalu rumit dan sulit dipahami.

2. Komunikasi, baik dengan pelanggan maupun antar karyawan harus jelas dan dapat dipahami oleh semua pihak. ‗Bahasa‘ yang digunakan harus jelas dan sederhana.

3. Teknologi – teknologi yang diterapkan perlu diperhatikan kesesuaiannya dengan tugas yang sedang dilaksanakan, solusi teknologi tinggi untuk mengatasi tugas yang tidak dapat diatasi oleh teknologi rendah.

4. Aliran – urutan tugas dapat diubah untuk menyederhanakan aliran material atau paperwork dan membuat pekerjaan berikutnya lebih mudah.

5. Proses – dapat juga disederhanakan dan dirampingkan dengan mengetahui kapan proses tersebut melayani produk atau pasar berbeda. Dengan memecah proses dan mengidentifikasi kegiatan yang paling tepat ditujukan bagi segmen pelanggan tertentu, proses tersebut dapat dibuat lebih sederhana. Kadangkala proses yang sama mencoba memuaskan pelanggan dengan kebutuhan yang cukup berbeda. Proses itu tidak cukup memadai untuk melayani segmen-segmen yang berbeda tersebut dan yang sering terjadi adalah penekanan pada salah satu segmen tertentu saja.

c. Mengintegrasikan (Integrate)

(25)

menghasilkan aliran yang lancar dalam penyampaian kebutuhan pelanggan dan tugas pelayanan pelanggan.

1. Pekerjaan – dimungkinkan untuk menggabungkan pekerjaan menjadi satu. Melalui pemberdayaan seorang pekerja untuk menyelesaikan rangkaian tugas yang telah disederhanakan sehingga aliran material atau informasi dalam organisasi akan menjadi lebih cepat. Apabila pekerjaan harus dikerjakan antar individu, terdapat peluang terjadinya kesalahan akan lebih besar dan harus ada sesuatu yang memfasilitaskan transfer kerja tersebut, cara lain pengintegralan pekerjaan adalah dengan menugaskan sesorang yang bertanggung jawab atas pemrosesan produk atau jasa secara keseluruhan mulai dari pesanan sampai pengiriman. Orang ini disebut ‗pekerja kasus‘ (case worker) atau ‗manajer kasus (case manager). Orang ini bertindak sebagai ‗titik kontak tunggal‘ bagi pelanggan

2. Tim – perluasan logis dari tugas-tugas yang disatukan adalah penggabungan para ahli ke dalam tim-tim, dimana tidak mungkin bagi seseorang secara sendiri dapat melakukan seluruh rangkaian kegiatan. Meskipun tim mungkin mempertahankan beberapa jalur pelaporan/tanggung jawab, misalnya untuk penjualan dan operasi, mereka bergabung sebagai sebuah tim pelaksanaan proses tunggal sebagai sebuah tim pelaksana proses tunggal untuk pekerjaan sehari-sehari, kedekatan secara fisik tersebut dapat mengurangi munculnya masalah-masalah akibat pemecahan tugas atau pekerjaan atas spesialisasi-spesialisasi pekerjaan dan bila muncul masalah mereka dapat segera mengatasinya. Teknologi informasi memungkinkan secara fisik berjauhan, dapat saling bekerja sama, walaupun cara ini dapat menggantikan hubungan

(26)

akrab secara fisik. Meskipun demikian diusahakan agar suatu tim ditempatkan bersama-sama saling berdekatan secara fisik untuk menimalkan jarak yang harus ditempuh material, informasi dan paperwork serta meningkatkan komunikasi antar setiap orang yang bekerja dalam proses tersebut.

d. Mengotomatisasi (Automate)

Sebagai mana telah diuraikan sebelumnya, teknologi informasi dapat menjadi alat yang kuat untuk mempercepat proses dan memberikan layanan pelanggan yang lebih bermutu jika diterapkan pada proses yang tepat/logis. Jika proses tersebut bermasalah maka otomatis akan dapat memperparah situasi. Oleh karena itu otomatis diterapkan setelah mengeliminasi, setelah tahapan otomatisasi, dimungkinkan untuk kembali pada tahap yaitu pengeliminasian, penyederhanaan, dan pengintegrasian tugas- tugas. Dalam beberapa kasus, sejak permulaan dapat diramalkan perlunya otomatisasi aspek- aspek tertentu dari proses. Beberapa kondisi proses yang dapat dipertimbangkan untuk di otomatisasi adalah sebagai berikut:

1. Tugas yang berulang merupakan calon yang paling baik untuk diotomatisasi. Tugas- tugas ini dapat berupa tugas shop floor, tugas- tugas klerikal seperti tugas mencocokan item- item dalam formulir dan sebagainya.

2. Pengumpulan data jika dilakukan dengan mesin, waktu proses lebih cepat dan akurasinya akurat. Contoh teknologi ini adalah bar code reader di toko- toko grosir.

(27)

satu orang keorang lain atau satu sistem ke sistem lain, jika memang harus dilakukan atau tidak dapat dihilangkan merupakan calon utama yang lain untuk diotomatisasi.

Otomatisasi seharusnya hanya diterapkan pada proses-proses yang terkendali atau dikendalikan. Intervensi manual dari sumber daya manusia yang berkaitan dengan fleksibilitas dan kecerdasannya tetap akan diperlukan. Otomatisasi paling cocok diterapkan untuk tugas -tugas yang sifatnya rutin dan repetitive atau untuk pemodelan yang sangat kompleks.

Figur

Gambar 2.1 Zachman Framework

Gambar 2.1

Zachman Framework p.6
Gambar 2.2 Tahapan TOGAF ADM

Gambar 2.2

Tahapan TOGAF ADM p.8
Tabel 2.1 Perbandingan EA Framework

Tabel 2.1

Perbandingan EA Framework p.14
Diagram  use  case  memiliki  dua  komponen  penting,  yaitu  actor  dan  use  case . Gambar 2.3 merepresentasikan notasi dari dua komponen diagram use case  tersebut

Diagram use

case memiliki dua komponen penting, yaitu actor dan use case . Gambar 2.3 merepresentasikan notasi dari dua komponen diagram use case tersebut p.16
Gambar 2.3 Dua komponen diagram use case actor dan use case    2.  Activity Diagram

Gambar 2.3

Dua komponen diagram use case actor dan use case 2. Activity Diagram p.16
Gambar 2.7 Gateways  2.  Connecting Objects

Gambar 2.7

Gateways 2. Connecting Objects p.18
Gambar 2.11 Swimlanes  4.  Artifacts

Gambar 2.11

Swimlanes 4. Artifacts p.19

Referensi

Memperbarui...

Related subjects :