Nama : Alvino Viando Putra

NIM : 181402121
KOM :A
Mata Kuliah : Data Warehouse dan Business Intelegence

Identifikasi dan Pemahaman terhadap business area dan business operation

Amadeus Entertainment adalah online dan offline retailer yang berspesialisasi di bidang music, film,
dan audio book, dengan outlet di 8 negara. Beberapa key people dari case study ini: Grace sebagai
project manager, David sebagai data warehouse arsitek dan projek manajer nya adalah Natalie.
Mereka bertemu manager dan director dari berbagai bagian bisnis dan membahas business
operation dan isu bisnis yang dijumpai manajer. Mereka mengunjungi toko fisik, berbicara ke
manajer toko dan pegawai dan mempelajari detail dari bagaimana bisnis nya berjalan di toko.
Mereka juga toko online dan melihat pada kategori produk dan proses pemesanan penjualan.
Mereka juga membuat beberapa pesanan di WebTower9 (the online store system) dan diikuti
sampai ke backend dari system. Ditemukan lah bisnis challenge dan permasalahan nya:
 Amadeus Entertainment kesulitan menganggregat penjualan global (termasuk keuntungan)
karena toko mereka terdapat di beberapa negara dan menjalankan 3 sistem yang berbeda.
Mereka juga harus menganalisa penjualan berdasarkan produk dan area geografis.
 Perusahaan harus mengevaluasi supplier performance berdasarkan delivery lead time dan
promptness, order volume and quantity, trading dan history payment, dan store stock
fluctuation records, regardless of brand, dan transaction system. Selama ini , aktivitas
tersebut melelahkan.
 Perusahaan ingin agar bisa memilih pelangan berdasarkan demografi atribut, Riwayat
pemesanan, dan komunikasi dan mengirimkan newsletter via e-mails berisikan promosi,
tergantung system yang berjalan, dan mencatat respon customer, seperti pembukaan e-
mails dan mengunjungi website perusahaan.
Mereka lalu menggrupkan masalah ini dan challenges menjadi 3 bisnis area: sales, purchasing dan
CRM.
Grace (bisnis projek manajer) dan David (data warehouse architect) lalu Kembali ke pengguna bisnis
dan diturunkan menjadi beberapa area agar mengetahui bisnis operasi di tiap area. Mereka
mencoba memahami prosesnya, roles, dan issues di tiap area. Secara umum, mereka melihat
business events, status, levels, dan roles.
 Event adalah aktivitas yang terjadi secara terus menerus selama beberapa detik dan menit.
Atau bisa jadi jam dan hari. Contoh, di area pembelian, kami memiliki document Bernama
purchase order. Dokumen ini berisi permintaan ke supplier (perusahaan rekaman
musik,contohnya) untuk menyuplai perusahaan beberapa produk (CD atau lagu MP3, for
example). Tiap minggu Amadeus Entertainment membuat ratusan dari dokumen dan
mengirimkannya ke banyak supplier.
 Status adalah kondisi dari sebuah objek dari suatu waktu. Contoh, sebuah lagu bisa status
menajdi aktif atau nonaktif.
 Level adalah pengukuran kuantitatif dari sebuah objek pada suatu waktu. Seperti account
balance, inventory level, dan jumlah customer.
 Roles adalah siapa, siapa yg berwenang dan apa yang ter involved di sebuah event. Contoh,
roles nya antara lain supplier, account manager, dll.
Identifikasi Kebutuhan Fungsional
Setelah memahami business operation di setiap area, Grace sebagai project manager berdiskusi
dengan pengguna bisnis terkait functional requirements, fitur-fitur dari yang diperlukan dai data
warehouse. Didapatkanlah kebutuhan-kebutuhannya yang di tuliskan di table di bawah ini :

No Kebutuhan Prioritas
1 Pengguna bisnis harus dapat menganalisis "penjualan produk", yang Tinggi
dimaksud penjualan produk disini adalah saat pelanggan membeli
produk daripada berlangganan paket dari waktu ke waktu menurut
wilayah geografis, menurut demografis pelanggan, menurut toko dan
wilayah penjualan,dan menurut hierarki produk. Pengguna juga perlu
mengetahui pendapatan, biaya,
dan mereka
2 Pengguna bisnis harus dapat menganalisis "penjualan langganan", yang Tinggi
dimaksud penjualan produk disini ketika pelanggan berlangganan paket
daripada membeli produk)
3. Pengguna bisnis akan dapat menganalisis "profitabilitas pelanggan," Tinggi
yang dimaksud didefinisikan sebagai pendapatan tahunan yang
diproyeksikan dari pelanggan yang berlangganan dikurangi biaya
tahunan (termasuk biaya tidak langsung proporsional)
4. Pengguna bisnis harus dapat mengalokasikan pelanggan ke "kelas" Medium
tertentu berdasarkan proyeksi pendapatan tahunan pelanggan dan
mengalokasikannya ke "band" berdasarkan profitabilitas. Kelas dan
band digunakan dalam loyalitas program. Kedua atribut ini diperbarui
setiap hari.
5. Pengguna bisnis akan dapat menganalisis “kinerja pemasok”, yaitu Rendah
rata-rata tertimbang dari total yang dikeluarkan, biaya, nilai
pengembalian, nilai penolakan, ketersediaan judul dan format,
kehabisan stok, waktu tunggu, dan ketepatan waktu.
6. Sistem akan memungkinkan pengguna CRM untuk memilih pelanggan Tinggi
berdasarkan komunikasi izin (berlangganan/berhenti berlangganan,
email/telepon/postingan, dan sebagainya)
7. Sistem memungkinkan pengguna CRM untuk menganalisis hasil Medium
kampanye dengan melihat langkah-langkah berikut untuk setiap
kampanye yang dikirim ke pelanggan: jumlah pesan yang dikirim
melalui saluran komunikasi (pesan teks ponsel, email, atau pos), jumlah
pesan yang berhasil dikirim, dan jumlah pesan gagal terkirim (termasuk
alasannya). Untuk pesan email, pengguna perlu menganalisis informasi
tambahan berikut: tarif terbuka, rasio klik-tayang, rasio keluhan, vonis
spam, dan rasio klik jebakan.

8. Untuk tujuan analisis CRM, gudang data akan menyimpan . lama Rendah
pelanggan pekerjaan, pendapatan, alamat, alamat email, dan nomor
telepon, terutama pelanggan (sebagai lawan dari pembeli).
9. Data warehouse akan menyimpan region dan divisi sebelumnya dari Rendah
setiap store. Ada rencana untuk mengatur ulang hierarki toko; yaitu,
saat ini ada hanya lima wilayah di Amerika Serikat, tetapi dalam waktu
beberapa bulan akan ada delapan wilayah. Toko online saat ini berada
di divisi terpisah, tetapi di masa depan mereka akan berada di divisi
yang sama dengan rekan offline mereka. Reorganisasi seperti ini jarang
 terjadi. Ini adalah pertama kalinya terjadi dalam enam tahun sejarah
Amadeus Entertainment. Anda dapat mengharapkan struktur baru
untuk bertahan setidaknya tiga tahun
10. Untuk persyaratan 1 hingga 7, saat data warehouse aktif, dua tahun Medium
data transaksi historis perlu dimuat ke dalam gudang, kecuali
persyaratan 5, yang seharusnya satu tahun

11. Gudang data akan menyimpan data hingga lima tahun online dan lima Rendah
tahun offline. Data offline harus dapat diakses secara online dengan dua
hari.

12. Sistem akan memungkinkan manajer toko untuk melihat data hanya Tinggi
dari mereka sendiri toko. Ini karena setiap manajer toko bertanggung
jawab untuk toko yang berbeda. Ini berlaku untuk pengelola toko
offline dan online.
13. Di tingkat toko, kemampuan untuk melihat data harian dalam beberapa Tinggi
minggu terakhir adalah penting. Sistem harus memungkinkan manajer
toko untuk melihat kenaikan dan penurunan penjualan, biaya, dan
profitabilitas, dan mereka harus mampu menelusuri
setiap hari tertentu untuk memahami penyebab penjualan rendah atau
profitabilitas rendah, yaitu, produk, judul, media, atau pelanggan mana
yang menyebabkan masalah
14. Sistem gudang data akan memungkinkan manajer global untuk Medium
memahami tren global dan memecahnya berdasarkan negara. Mereka
tidak memerlukan data tingkat penyimpanan atau data harian. Jika toko
atau negara tertentu mengalami masalah dengan
media, judul, atau produk tertentu (misalnya ketika mereka mengalami
tren negatif), maka manajer harus dapat mengomunikasikan hal ini
kepada semua toko sedini mungkin.
15. Laporan dan OLAP akan memiliki antarmuka pengguna yang mudah Rendah
digunakan. Selama pengguna antarmuka memungkinkan perusahaan
untuk melakukan analisis dalam tabel ini dan mudah untuk digunakan,
pengguna tidak terlalu peduli dengan detail antarmuka pengguna. NS
angka jauh lebih penting bagi pengguna daripada tata letak. Pengguna
gudang data memahami bahwa tugas mereka adalah memberikan
kinerja bisnis, dan angka-angka ini adalah enabler.
16. Sistem akan dapat menampilkan angka dan grafik dan akan dapat Rendah
mencetak. Pengguna secara bersama-sama setuju bahwa mereka akan
membutuhkan bagan dan grafik, tetapi jika fitur ini tidak tersedia,
mereka dapat mengekspor ke Excel dan membuat grafik di sana.
Mereka akan membutuhkan fitur ekspor ke Excel (atau ke CSV).

Identifikasi Kebutuhan Nonfungsional

Kebutuhan fungsional sebelumnya dijelaskan untuk menentukan apa yang harus dilakukan sistem
(fitur), sedangkan persyaratan nonfungsional tidak menentukan fitur. Sebaliknya, kebutuhan
nonfungsional memberikan panduan dan kendala untuk arsitektur sistem. Beberapa dari mereka
berasal dari standar IT perusahaan, beberapa berasal dari tim arsitektur TI, beberapa dari
pembatasan sistem sumber (permintaan dari sumber sistem DBA dan manajer operasi), dan
beberapa dari kebutuhan pengguna (persyaratan dari pengguna bisnis).
Didapatkan kebutuhan nonfungsional nya sebagai berikut :

No. Kebutuhan
1 Semua pengguna gudang data harus dapat mengakses aplikasi front-end gudang data
(laporan dan OLAP) tanpa login lagi. Mereka hanya perlu masuk sekali ke Windows aktif
PC atau laptop mereka

2 Aplikasi front-end gudang data tidak boleh diakses dari luar

jaringan perusahaan
3. Semua aplikasi front-end idealnya berbasis web, dapat diakses dari mana saja di dalam
jaringan perusahaan.
4. Semua pengguna mengakses aplikasi front-end dari portal pusat. Tata letak antarmuka
pengguna dan desain harus mengikuti standar dan pedoman perusahaan.
5. Beberapa pengguna diizinkan untuk mengakses data dari negara mereka sendiri saja,
tetapi beberapa pengguna diizinkan untuk mengakses data dari negara mana pun
6. Beberapa pengguna "kekuatan" diberikan akses ke penyimpanan dimensi untuk
melakukan SQL langsung pertanyaan.
7. Beberapa “power” user diberikan akses ke penyimpanan dimensi untuk melakukan SQL
langsung pertanyaan.
8 Waktu respons maksimum untuk setiap laporan, kueri, atau tampilan OLAP adalah 30
detik.
9 Spesifikasi minimum standar untuk klien adalah Internet Explorer 6 pada Windows XP
berjalan di PC atau laptop dengan Intel Pentium D 820 (atau setara seluler/AMD) dengan
Memori 512MB dan resolusi SVGA (1024✕768 piksel)

10. Data Warehouse harus tersedia selama 24 jam sehari, 7 hari seminggu. Waktu henti
adalah diharapkan tidak lebih dari satu jam dalam sebulan

11. Unduhanan dari Jupiter hanya dapat terjadi dari jam 4 pagi sampai jam 5 pagi standar
Timur ASwaktu.

12 Lebih baik agar tidak ada perubahan aplikasi atau basis data yang dibuat di WebTower9,
Jupiter, dan sistem Jade, termasuk pemicu atau perubahan skema
13 Sistem data warehouse harus memberi tahu pemilik data yang sesuai dalam waktu 24
jam ketika masalah kualitas data muncul.
14 Preferensi perusahaan adalah menggunakan Microsoft SQL Server untuk membangun
gudang data dari ujung ke ujung, termasuk alat ETL, pelaporan, dan OLAP. Aplikasi BI
front-end khusus dapat digunakan jika diperlukan. Gudang data harus dapat diupgrade
ke SQL Server di masa mendatang versi.

15 Perlu memanfaatkan proyek ini untuk memenuhi kebutuhan integrasi data juga. Seperti
yang kamu tahu, Amadeus Entertainment memiliki aplikasi front-end yang berbeda.
Secara khusus, akan ideal jika ini proyek dapat membuat batu loncatan untuk
manajemen data master
16 Gudang data harus fleksibel sehingga kami dapat meningkatkannya dengan mudah dan
beradaptasi dengan perubahan yang terjadi dalam sistem transaksi. Secara khusus, itu
perlu menyertakan peningkatan seperti membawa potongan data baru ke dalam
gudang, menambahkan laporan/kubus/data baru aturan kualitas, atau memodifikasi
yang sudah ada.
17. “Siapa yang mengakses apa dan kapan” harus dapat diaudit.
18. Semua server harus dapat dipasang di rak, sebaiknya dari favorit Amadeus
 Entertainment pemasok perangkat keras.

19. Data warehouse harus dicadangkan ke media offline setiap hari, dan cadangan harus
diuji setiap enam bulan dengan mengembalikannya dari media. Media yang cukup baru
harus disimpan
di luar lokasi
20. Jika ETL gagal karena kegagalan daya di pusat data, data di gudang data tidak boleh
dirusak atau dikompromikan; itu harus dapat dipulihkan, dan tidak boleh ada kehilangan
data apa pun.
21. Jumlah pengguna diperkirakan antara 300 dan 500. Sekitar 20 persen di antaranya
pengguna diperkirakan pengguna berat dan sering; sisanya sesekali.

22. Untuk melindungi investasi, perlu menggunakan jaringan area penyimpanan (SAN) yang
sama dengan file dan server email daripada membuat SAN baru yang terpisah.

David dan Grace mereview kebutuhan-kebutuhan ini. Mendokumentasikannya dan mendapatkan

hal-hal yang penting. Mereka mereview kebutuhan dari segi kelengkapan, kelayakan dan efeknya
terhadap arsitektur system. Mereka mendokumentasikan persyaratan ini dalam tambahan format
spesifikasi, dengan bagian berikut: kegunaan, keandalan, kinerja, dukungan, batasan desain,
dokumentasi dan bantuan pengguna, antarmuka, dan standar yang berlaku. Pengguna bisnis, grup
arsitektur TI, dan tim operasi meninjau dokumen dan ditandatangani pada mereka.

Melakukan Studi Kelayakan Data

Studi kelayakan data adalah proses untuk mengeksplorasi sistem sumber, untuk memahami data
dengan membuat daftar risiko data utama dan memverifikasinya, dan untuk menentukan apakah
proyeknya sudah sesuai dengan persyaratan (layak). Menjelajahi sistem sumber berarti memeriksa
platform database, memeriksa struktur database, dan menanyakan tabel. Memahami data berarti
mencari tahu di mana data itu berada untuk setiap kebutuhan fungsional dan pemahaman arti dan
kualitas data. Risiko diidentifikasi dengan mencari tahu apakah ada kesenjangan antara persyaratan
dan data, yaitu, apakah untuk setiap kebutuhan data tersedia dan dapat diakses.
Tujuan dilakukannya studi kelayakan data adalah untuk mendapatkan gambaran tentang ada
tidaknya risiko data apa pun yang dapat menggagalkan proyek. Risiko data adalah risiko proyek
yang terkait dengan data ketersediaan dan aksesibilitas data. Risiko ketersediaan data adalah
risiko tidak dapat memenuhi persyaratan karena data tidak tersedia.
Untuk studi kasus Amadeus Entertainment, didapatkan beberapa contoh data risk nya sebagai
berikut.

No. Resiko
1. Tidak memungkinkan untuk melakukan ekstraksi data di Jupiter dalam batasan satu
jam, seperti yang ditentukan dalam persyaratan nonfungsional.
2. Persyaratan fungsional tidak dapat dipenuhi karena tidak memiliki data di sistem
sumber. Cara untuk mengidentifikasi ini adalah melalui persyaratan fungsional dan
query sistem sumber untuk mengetahui apakah kita memiliki data untuk setiap
kebutuhan.
3. Datanya ada, tapi tidak bisadidapatkan. Dengan demikian, cara untuk
mengidentifikasi ini adalah melalui persyaratan fungsional, cari data untuk
persyaratan itu, dan periksa apakah kita dapat men query kan data.
4. Data nya bisa didapatkan, tetapi berantakan dan perlu direstrukturisasi dan
 dibersihkan terlebih dahulu. Di dalam kasus ini, perlu dicari tahu berapa banyak
usaha yang diperlukan untuk membersihkan data.
5. Persyaratan menyatakan bahwa kita perlu menggunakan SAN yang sama dengan
server file dan email daripada membuat SAN baru yang terpisah. Ada risiko di sini
bahwa kita tidak dapat menggunakan yang sama SAN karena jumlah data di data
warehouse melebihi kapasitas maksimum SAN yang ada.
Tentu saja, disk baru perlu dibeli, tetapi ada risiko dimana maksimal jumlah disk
yang dapat ditangani SAN kurang dari yang dibutuhkan. Misalnya, SAN yang ada
mungkin hanya dapat menampung 120 disk dan 50 disk sudah digunakan oleh file
dan server email. Jika gudang data membutuhkan lebih dari 70 disk, maka SAN yang
ada tidak dapat digunakan.
6. Beban tambahan harian dapat memperlambat sistem sumber. Kita dapat
menentukan apakah beban tambahan akan memperlambat sistem sumber dengan
mensimulasikan ekstraksi data berjalan saat sistem sumber sedang digunakan. Ini
sebaiknya dilakukan di lingkungan pengujian.
7. Pengguna mungkin tidak dapat menggunakan aplikasi front-end tanpa masuk ke
data warehouse. Persyaratan nonfungsional pertama menyatakan bahwa semua
pengguna gudang data harus: dapat mengakses aplikasi front-end gudang data
tanpa login lagi. Mereka hanya perlu login sekali ke Windows di PC atau laptop
mereka. Kita perlu menyelidiki apakah kami akan dapat menerapkan keamanan
terintegrasi Windows untuk mengaktifkan ini.
8. Loading data awal bisa memakan waktu lebih lama dari yang diperkirakan, seperti
sebulan, mempengaruhi waktu proyek. Ini bisa terjadi jika kita menggunakan ETL
operasional untuk melakukan inisial beban data, terutama ketika ETL operasional
dalam arsitektur berbasis pesan.

Table Fakta dan Table Dimensional