Get documents about "Gambar Template Pabrik Seminar Nasional Aplikasi
W
Description
Gambar Template Pabrik document sample
Document Sample
Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022
Yogyakarta, 19 Juni 2010
PENERAPAN FRAMEWORK ZACHMAN PADA ARSITEKTUR
PENGELOLAAN DATA OPERASIONAL
(STUDI KASUS SBU AIRCRAFT SERVICES, PT. DIRGANTARA INDONESIA)
Falahah1), Dewi Rosmala2)
1)
Prodi Teknik Informatika, Fakultas Teknik, Universitas Widyatama
Jl. Cikutra 204A Bandung
falahah@widyatama.ac.id
2)
Jurusan Teknik Informatika, Fakultas Teknik Industri
Institut Teknologi Nasional
d_rosmala@itenas.ac.id
ABSTRAKS
Framework Zachman merupakan salah satu kerangka kerja yang populer dalam memetakan artifak
arsitektur informasi di sebuah organisasi. Penerapan framework Zachman sangat variatif dan mampu
memberikan gambaran yang representative atas elemen-elemen informasi di sebuah organisasi. Pada makalah
ini akan membahas kasus penerapan framework Zachman pada usulan pengembangan arsitektur pengelolaan
data untuk kasus SBU Aircraft Services (ACS) yang menghadapi masalah dalam eksekusi berbagai aplikasi yang
tidak saling terintegrasi.
ACS pada saat ini menjalankan berbagai jenis aplikasi yang dengan berbagai kendala dan kondisi juga
harus tetap meningkatkan kinerja bisnis dan berinteraksi dengan para mitra dan konsumennya. Skala bisnis
yang luas menyebabkan ACS harus dapat saling bertukar data dengan mitra dan konsumennya. Hal ini tidak
dapat dilaksanakan dengan mudah karena ACS tidak memiliki konsep arsitektur pengelolaan data yang baik dan
semua aplikasi dibiarkan berjalan dan informasi yang mengalir di antara aplikasi ditangani apa adanya.
Untuk dapat memodelkan arsitektur pengelolaan data yang harus disiapkan maka dicoba digunakan
framework Zachman yang difokuskan untuk sudut pandang data skala enterprise dan diterapkan pada
pengelolaan data operasional. Hasil pemodelan arsitektur data dengan menggunakan pendekatan Framework
Zachman dapat memberikan masukan yang signifikan bagi para manajemen untuk penyiapan integrasi data di
masa mendatang.
Kata Kunci: Framework Zachman, pengelolaan data operasional, studi kasus, Aircraft Services.
1. PENDAHULUAN menempati kolom pertama, dan arsitektur data
Pentingnya integrasi data di satu perusahaan skala enterprise menempati 2 baris teratas dari
berskala besar atau lazim disebut dengan enterprise kolom tersebut. Arsitektur data terdiri atas entitas
sudah banyak dibahas di berbagai referensi. data yang dilengkapi dengan atribut dan relasi antar
Ketersediaan data yang terformat baik, dalam satu entitas [4].
sumber data yang terkelola dengan baik juga
merupakaan dambaan banyak organisasi. Untuk 2. TINJAUAN LITERATUR
mewujudkan hal tersebut diperlukan pemilihan 2.1 Framework Zachman
strategi dan perencanaan yang akurat. Framework Zachman adalah framework
Pada kasus data-data yang dikelola secara Arsitektur Enterprise yang menyediakan cara untuk
terpisah (silo), diperlukan satu kerangka kerja yang memandang dan mendefinisikan sebuah enterprise
jelas untuk menganalisis data-data tersebut secara formal dan terstruktur dengan baik.
berdasarkan fungsional organisasi dan pemanfaatan Framework ini terdiri atas matriks klasifikasi dua
data tersebut di berbagai fungsi terkait. Kerangka dimensi yang dibangun dari kombinasi beberapa
kerja ini minimal harus dapat menyediakan sudut pertanyaan umum yaitu What, Where, When, Why,
pandang terintegrasi terhadap ruang lingkup Who dan How. [4]
pengelolaan data. Dalam konteks ini, diperlukan Framework Zachman bukan sebuah metologi
satu arsitektur skala enterprise yang diterapkan karena framework ini tidak menyebutkan metoda
secara spesifik pada ruang lingkup pengelolaan dan proses spesifik untuk mengumpulkan,
data. mengelola dan menggunakan informasi yang
Enterprise Architecture atau arsitektur skala dituliskan pada framework tersebut. Framework ini
enterprise mencakup tiga hal yaitu arsitektur data, pertamakali dipublikasikan oleh John Zahman
arsitektur aplikasi dan arsitektur teknologi. dengan rilis konsep pertama sekitar tahun 1980 an,
Arsitektur data mengidentifikasi dan dan sejak itu terus berevolusi dan mengalami
mendefinisikan jenis data umum yang mendukung beberapa kali penyempurnaan[1].
fungsi bisnis yang didefinisikan oleh model Framework Zachman lebih tepat digunakan
bisnis [5]. Pada framework Zachman, data sebagai sebuah alat untuk melakukan taksonomi
A-96
Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022
Yogyakarta, 19 Juni 2010
pada pengelolaan artifak arsitektur (dokumen Komponen utama arsitektur pengelolaan data
perancangan, spesifikasi dan model) yang mampu skala enterprise adalah [3]:
menunjukan siapa target artifak tersebut (misalnya • Source Systems (sistem–sistem sumber),
pemilik bisnis, pengembang, dan lain-lain), dan isu biasanya dilakukan oleh Aplikasi-aplikasi
utama apa yang terdapat pada artifak tersebut. OLTP (online Transaction Processing) yang
Beberapa sumber literatur memperkenalkan mendukung akitivitas bisnis operasional dari
implementasi Framework Zachman dalam berbagai enterprise, untuk menyimpan data-data yang
hal, misalnya: ada dan data-data eksternal .
• Framework untuk mengorganisasi dan • Operational Data Store (penyimpanan data
menganalisis data. operasional) mewakili jembatan antara
• Framework untuk arsitektur enterprise lingkungan OLTP (online Transaction
• Sistem klasifikasi atau skema klasifikasi Processing) dan OLAP (online Analitical
• Matriks dalam bentuk 6x6. Processing). Struktur data sama dengan sistem-
• Model dua dimensi atau model analitis sistem transaksional, tapi standarisasi (basic
cleansing) dan pengintegrasian proses
Baris-baris pada Framework mewakili tingkat dilakukan data yang diisikan. Penyimpanan
abstraksi yang digunakan untuk melakukan analisis data operasional mencakup aspek berikut:
sistem.[2] a. Terintegrasi ,
• Scope (ruang lingkup): lapisan abstraksi paling b. Berorientasi subyek:
tinggi, diwakili dari ide-ide dan konsep-konsep c. Volatile, Current valued:
idealistis.
d. Berorientasi detail:
• Model enterprise menggambarkan tingkat
• Data Warehouse Enterprise, merupakan
konseptualitas, dimana pemodelan awal
konsep yang sangat penting dalam arsitektur
dilakukan untuk mendefinisikan konsep bisnis
Corporate Information Factory, didesaian
yang mengimplementasikan ruang lingkup.
khusus untuk integrasi data dari suatu
• Model sistem adalah tingkat dimana obyek-
enterprise secara detail, summary dan secara
obyek yang konseptual dirubah menjadi
struktur-struktur logik . historis. Hal ini untuk memberikan prespektif
• Model Teknologi mendefinisikan obyek secara enterprise untuk manajemen eksekutif dan
fisik yang akan mewakili struk-struktur logik . strategis. Data Warehouse Enterprise memiliki
• Representasi detail, lapisan ini terdiri dari karakteristik:
implementasi-implementasi penuh dari a. Terintegrasi:
spesifikasi secara fisik untuk setiap kategori . b. Berorientasi subyek
c. Non –Volatile,
Aktivitas utama pengelolaan data skala d. Variansi waktu
enterprise yang terdapat pada kolom-kolom • Sistem klien, diwujudkan dalam Data Marts
framework adalah: departemen, sistem Informasi Enterprise (web
• Data merupakan perwujudan dari informasi. Portal) atau sistem-sistem laporan lokal
• Function sebagai komponen OLAP seperti DSS
• Hardware (Decision Support System atau MOLAP.
• People Sistem-sistem klien dapat mengolah data dari
• Time penyimpanan data operasional, Data
• Motivation Warehouse atau kedua-duanya. Tingkat
integrasi dan kedetailan sumber data untuk
Setiap sel yang didefinisikan oleh interaksi dari sistem klien nya ditentukan oleh kebutuhan
tingkat abstraksi dengan lapisan aktivitas aplikasi sistem klien tersebut.
Enterprise, akan memiliki berbagai arti dan isi • Sistem pengelolaan metadata, lapisan semantik
berdasarkan subyek framework yang digunakan. dan logik dari pengertian dan pemahaman
informasi yang disimpan oleh berbagai macam
2.2. Konsep Pengelolaan Data Skala Enterprise sistem. Kompleksitas informasi berkenaan
Salah satu konsep pengelolaan data secara dengan lingkungan menyeluruh dari enterprise
enterprise diajukan oleh George Jucan [3] dalam biasanya distrukturisasi sebagai:
bentuk arsitektur Corporate Information Factory. 1. Metadata bisnis
Data harus dikumpulkan dan dilepaskan dari 2. Metadata teknis yang dapat dibagi menjadi
keterikatannya dengan proses bisnis dan aplikasi metadata statik dan metadata dinamik.
yang berjalan. Data dibuatkan struktur dasarnya
atau metadata dan dikumpulkan dalam sebuah
repositori. Adanya metadata yang standard ini dapat
dijadikan basis bagi integrasi sistem dalam
tingkatan aplikasi secara enterprise (application
architecture).
A-97
Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022
Yogyakarta, 19 Juni 2010
Gambar 1. Framework Zachman [4]
2.2 Mendefinisikan ODS (Operational Data komprehensif bagi manajemen tentang ruang
Storage) lingkup pengelolaan data dan artifak-artifak apa
Langkah pertama dalam membangun yang harus diperhatikan dalam pengelolaan
pengelolaan data skala enterprise aadalah tersebut.
membangun Penyimpanan Data Operasional. ACS merupakan salah satu unit bisnis
Biayanya biasanya lebih murah dari pada Data strategis di PT.Dirgantara Indonesia yang melayani
Warehouse, karena menyediakan penggabungan jasa purna jual pesawat terbang. dengan kegiatan
data yang cukup memadai untuk skala enterprise . usaha utama sebagai berikut [6]:
Biarpun strukturnya masih mencerminkan desain 1. Melakukan pemeliharaan dan perbaikan
sistem Transaksional , tapi memiliki kemampuan pesawat terbang dan helikopter.
untuk melaporkan kehilangan dari aplikasi- aplikasi 2. Melakukan perawatan dan perbaikan komponen
individual. pesawat.
Salah satu pendekatan untuk mendefiisikan 3. Melakukan kegiatan penjualan suku cadang dan
ODS adalah melakukan analisis tingkat enterprise engineering services sebagai penunjang
pada tahap awal proyek integrasi mulai dikejrakan. terhadap kedua kegiatan di atas.
Pendekatan ini mendefinisikan suatu rancangan
dimana setiap puzzle dapat cocok . Karena setiap 3.1. Gambaran Sistem yang Sedang Berjalan
sistem akan dianalisa dengan sudut pandang ACS sudah memiliki beberapa sistem yang
Enterprise, maka hampir tidak ada beda , dalam konsep awalnya adalah terintegrasi, tetapi dalam
urutan penggabungan aplikasi –aplikasi yang ada , pelaksanaannya belum terintegrasi.
selama data master digabungkan sebelum data Pada saat penelitian ini dilakukan, di ACS telah
transaksional . digunakan berbagai aplikasi seperti berikut [7]:
Tabel I memperlihatkan penerapan Framework a. Pendukung Laporan keuangan dengan
Zachman yang digunakan dalam mendefinisikan perusahaan induk: CAS (cost Accounting
Penyimpanan Data Opersional dalam perspektif System)
korporat . Baris dan kolom memiliki makna yang b. Pendukung Administrasi internal ACS ( CICS
sama yaitu sebagai template konsep Arsitektur. Sel 2000) dengan modul sebagai berikut:
mencerminkan tindakan yang dilakukan dan • Technical Engineering(TEN)
beberapa contoh dari apa yang dicari. Template • Customer Order Management (COM)
dapat dengan mudah digunakan pada tingkat • Quality Assurance(QAS)
korporat dan setiap sistem yang dimasukkan • Inventory Management (INV)
kedalam analisis ODS. • Maintenance Overhaul and Repair
(MOR)
3. PENDEKATAN FRAMEWORK • Human Resource and Facility(HRF
ZACHMAN UNTUK MEMBANGUN • Finance Management (FIN)
KERANGKA INTEGRASI DATA c. Pendukung integrasi dengan system informasi
Pendekatan Framework Zachman yang spesifik perusahaan induk: SIA, dengan beberapa
pada pengelolaan data skala enterprise tersebut modul yang diimplementasi bertahap
kemudian dicoba diterapkan untuk membangun diantaranya Procurement dan IRP.
kerangka kerja integrasi data pada sub unit Aircraft
Services (ACS) PT.Dirgantara Indonesia. Ujicoba
ini dilakukan untuk memberikan gambaran yang
A-96
Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022
Yogyakarta, 19 Juni 2010
Tabel 1. Framework Pendefinisian Penyimpanan Data Operasional [3]
Data Function Place People Time Motivation
Business Daftar dari data Daftar dari kelas-kelas Daftar Area Daftar dari Daftar dari Pernyataan
Environment bisnis umum proses yang umum, data bisnis : unit-unit bisnis Event ruang lingkup
seperti, transfer, laporan , ekstrak negara , organisasi yang kerja
data provinsi dari yang utama , berhubungan
operasi
Enterprise Identifikasi sistem Mendefinisikan proses Daftar lokasi Daftar unit Definsi
Model referensi: utama pada data misalnya utama: organiasai kebutuhan
Data Master Transfer: Reporting internal utama
Data Extract : DW, DSS,
Transaksional NOLAP
System Identifikasi relasi Menentukan sumber Mendefinisik Daftar struktur Mendefinisikan
Model data : proses detil seperti an struktur organisasi unit kendala
RDBMS, sistem lama, flat umum terhadap waktu
file
Teknologi Penggabungan Menciptakan spesifikasi Nama dan Mengklasifika Mendefinisikan Mendefinisika
Model atribut-atribut proses yang detail definisi sikan unit-unit mekanisme n tujuan
entitas karakteristik kontrol dan kelompok
sistem penjadwalan
Detailed Penggabungan Implementasi proses Setting Identifikasi Mendefinisikan Mendefinisika
representation spesifikasi- hardware user-user: waktu dan n pencapaian
spesifikasi kolom yang spesifikasi individu
diterapkan terjadinya
interaksi
dengan sumber
data.
What How Where Who When Why
Salah satu aspek yang penting dalam kasus ACS data umum yang terlibat dalam proses bisnis utama
adalah banyaknya data dalam berbagai versi yang yaitu:
harus dipelihara, diakses dan disajikan secara cepat • Customer
baik untuk kebutuhan penunjang proses bisnis • Supplier
internal maupun interaksi dengan para mitra bisnis • Part
dan konsumennya. Keinginan ACS untuk dapat • Aircraft
menerima sertifikasi dari beberapa pabrik pembuat • Maintenance
pesawat skala internasional seperti Boeing dan • People
Airbus [6] yang diikuti adanya kebutuhan pertukaran
data dengan pihak-pihak tersebut membuat ACS Enterprise model:
harus memikirkan cara pengelolaan data di antara • Model enterprise (baris kedua) yang menyatakan
aplikasi yang ada dan bagaimana data tersebut dapat keterkaitan dari tipe data umum di atas dapat
dipertukarkan. dilihat pada gambar 2.
Hal ini menimbulkan pemikiran bahwa salah satu
hal penting yang harus diselesaikan adalah
bagaimana menyediakan arsitektur data skala
enterprise untuk ACS dan bagaimana mewujudkan
bentuk pengelolaan data yang dapat memenuhi
berbagai kebutuhan tersebut. Untuk mencarikan
solusi bagi ACS maka pada makalah ini dilakukan
pendekatan dari framework Zachman dalam hal
identifikasi arsitektur data skala enterprise dan
identifikasi bentuk pengelolaan data skala enterprise
yang independen terhadap aplikasi tetapi dapat
memenuhi berbagai kebutuhan. Gambar 2. Model Data di ACS
3.2. Implementasi pada Kolom DATA (What) Dari model enterprise tadi kemudian diturunkan
untuk kasus ACS. model data dari sudut pandang entitas bisnis (baris
Dengan mengadopsi pendekatan framework kedua) yang dapat diuraikan seperti pada tabel 2.
Zachman maka akan dilakukan identifikasi secara
umum terhadap koordinat kolom data yaitu : System Model:
Scope: Berdasarkan deskripsi dan definisi pada model
Ruang lingkup data adalah tipe data umum bisnis entitas data di atas, kemudian dibuat model
secara bisnis (baris pertama). Dari uraian tentang data dari sudut pandang sistem (baris ketiga) seperti
proses bisnis di ACS maka dapat diidentifikasi tipe pada tabel 3.
Tabel 2. Daftar Entitas Bisnis di ACS
A-96
Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022
Yogyakarta, 19 Juni 2010
General Business Example attribut dengan benar. Aplikasi yang masih bersifat silo
Entities entities application, dalam integrasi datanya masih ditangani
Supplier Supplier Name, address
Vendor Pricelist Part Name, price secara manual dan darurat, yaitu dengan
Term of Service Name, contract membuatkan aplikasi perantara/ middleware yang
agreement pelaksanannya hanya bersifat sebagai pendukung
Customer Customer Name, address dari aplikasi yang ada. Idealnya ACS sebaiknya
Customer Name, kind of request
request Name, address
memiliki sistem pengelolaan data yang terintegrasi,
Potential yang diimplementasikan bertahap tanpa harus
customer mengganggu aplikasi yang sudah berjalan. Sistem
Aircraft Type Aircraft name, serial ini sangat diperlukan mengingat ACS selain harus
Configuration number
Manual List of configuration part,
menghadapi tekanan dari perusahaan induk agar
Operation configuration definition menggunakan sistem aplikasi tertentu, tetapi juga
Manual operation and harus tetap dapat berinteraksi dengan konsumen dan
maintenance mitra bisnisnya untuk mendukung strategi bisnis
Maintenance Maintenance Aircraft type, customer yang telah ditetapkan. Untuk itu maka diusulkan
Program name
Schedule Start – end schedule adanya semacam arsitektur pengelolaan data terpusat
Progress List of maintenance work, yang dapat digunakan untuk mengelola data meliputi
Condition list of part and resource pengumpulan dan akses data terlepas dari jenis
Part Part Master Part number, part name, aplikasi apa yang akan mengakses data tersebut.
Pricelist description.
Part number, ACS Kebutuhan ini sangat berkorelasi dengan
pricelist meningkatnya kecenderungan untuk
People Sales Name, kind of project to mengembangkan aplikasi bisnis intelijen sebagai alat
Technician handle pendukung pada kebutuhan strategi perusahaan,
Quality control Name, specific skill,
certified
disamping kebutuhan operasional untuk aktivitas
Name, specific skill perusahaan. Implementasinya dapat dikembangkan
menjadi semacam sebuah Data Warehouse, Data
Tabel 3. Daftar Entitas Data tingkatan sistem di ACS Marts, Desicion Support Systems, dan data-data
Business entities Data Entities yang mendukung proses bisnis perusahaan secara
Supplier Supplier keseluruhan.
Vendor Pricelist Vendor Pricelist Penerapan template Framework pengelolaan data
Term of Service Contract Agreement
Customer Customer operasional untuk kasus ACS dapat dilihat pada
Customer request Order Fullfilment tabel 4.
Potential customer Market Research Idealnya setelah dibuat kerangka referensi
Type Configuration Management penerapan pengelolaan data operasional seperti di
Configuration Standard Manual Operation
Manual Operation Service Bulletin
atas sebaiknya diikuti dengan langkah-langkah
Maintenance Program Order Management strategis implementasi.
Schedule Scheduling
Progress Condition Maintenance system 4. KESIMPULAN
Part Master Part Master Pada makalah ini, dicoba dilakukan eksplorasi
Pricelist Pricelist
Inventory Management Framework Zachman pada pemetaan arsitektur
Sales Personal Database pengelolaan data, khususnya data transaksi dengan
Technician studi kasus di ACS. Bahasan difokuskan pada
Quality control bagaimana pentingnya sebuah pengelolaan data yang
independen dan terintegrasi untuk kasus ACS, yang
Semua bentuk data pada tabel tersebut, dalam pada kenyataannya harus menjalankan berbagai
implementasinya sebetulnya sudah tersedia, tetapi macam sistem yang saling tidak terintegrasi tetapi
tersebar di berbagai jenis aplikasi dan tidak saling juga harus tetap mengemban misi strategi
terintegrasi. Untuk membuat data-data tersebut perusahaan.
terkumpul di satu tempat dan transparant bagi semua Ujicoba penerapan template Framework
aplikasi maka diperlukan pemikiran bagaimana kita Zachman pada pengeloalan data operasional
harus menyediakan media bagi data-data tersebut diharapkan dapat memberikan semacam usulan
tanpa harus mengganggu aplikasi yang sedang inisiatif terhadap perlunya arsitektur pengelolaan
berjalan. data bagi ACS, yang kemudian dapat diikuti dengan
langkah-langkah pendefinisian aspek arsitektur
3.3. Arsitektur Pengelolaan Data skala enterprise lainnya seperti arsitektur aplikasi dan
Enterprise arsitektur teknologi.
Jika diamati kondisi yang terjadi saat makalah ini Dari ujicoba ini apat disimpulkan bahwa
dibuat, maka tahapan pengembangan arsitektur framework Zachman ternyata dapat diterapkan
informasi yang ada di ACS barulah sampai level dalam berbagai kasus dan berbagai sudut pandang.
optimalisasi fungsional dan itupun belum berjalan
A-97
Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022
Yogyakarta, 19 Juni 2010
Hal-hal yang perlu diperhatikan ketika menerapkan sistem-sistem yang sedang berjalan dan kemudian
framework Zachman adalah : memetakan hasilnya pada framework Zachman.
1. Sudut pandang terhadap obyek, karena kita tidak
mungkin menuliskan semua hal tentang DAFTAR PUSTAKA
enterprise dalam satu framework Zachman. [1] “Zachman Framework”, situs Wikipedia,
2. Pengisian terhadap setiap sel, yang harus http://en.wikipedia.org/wiki/Zachman_Framew
konsisten dengan sudut pandang, sebab jika tidak ork#cite_note-VA01-23
konsisten maka framework Zachman akan [2] Hokel, Thomas A, “The Zachman Framework
menghasilkan pandangan yang bias terhadap for Enterprise Architecture, an Overview”,
kondisi di suatu perusahaan. www.frameworksoft.com
[3] Jucan, George, 2001“Designing a Corporate
Untuk kasus ACS, penerapan framework Information Factory using the Zachman
Zachman pada arsitektur pengelolaan data skala Architecture Framework”, Open Data System,
enterprise dapat menjadi kerangka bagi
http://www.opendatasys.com/cif_zf.html
implementasi arsitektur itu sendiri. Dari hasil
[4] Zachman, John A, “Zachman on the
penerapan tersebut ternyata banyak hal yang harus
Framework”, www.zifa.com
dieksplorasi dan diturunkan deskripsi detilnya,
khususnya untuk sel 3 baris pertama dan 2 kolom [5] Spewak, Steven H, 1992“
pertama. Adanya sistem berjalan yang kompleks Enterprise Architecture Planning”, John
dan menggunakan berbagai sumber data serta Willey & Sons. 1992.
biasnya pemahaman data antara satu sistem dengan [6] Dokumen internal SBU ACS, PT. Dirgantara
sistem yang lain mengakibatkan implementasi Indonesia (1998-2005)
pengelolaan data untuk tingkat data operasional [7] CSIS 2000 Functional Specification, SBU
cukup sulit, apalagi untuk tingkatan data warehouse. ACS, 2000.
Langkah awal yang harus dilakukan adalah
mengerjakan standarisasi data dan metadata untuk
Tabel 4. Framework Pengelolaan Data Operasional ACS
Data Function Place People Time Motivation
Business Customer, supplier, Find data, Internal ACS Head Customer Data
Environme Aircraft, Transfer, External with office, deadline, integration,
nt Maintenance, Report, supplier and customer availability
Part, Calculate, customer location of current
People extract information
Enterprise Data Master: Transfer: source extract, Bandung.
Model Customer, transport, load All customer
Supplier, Reporting, batch report, location
Part, web access, ad-hoc data (remote offices)
People mining
Data Transaksional sales, Extract
order,invoice,
Financials, maintenance
request, part request
System Customer request Sumber data: RDBMS, Internal Sales
Model maintenance. Maintenance customer/supplier connection: Marketing,
needs part and people. document, customer network, and Material
Mainenance need to trace database, aircraft intranet support,
and progress condition manufacture database application. Maintenan
needs to reported External: Web ce staff.
access
A-98
