e-Business (Bagian 1: Pengantar)

e-Business Models

Pengantar: saya tertarik mulai menulis tentang e-business. Sebagai bekas mahasiswa, saya memang pernah mengikuti kuliah tentang e-Business di Fakultas Ilmu Komputer - Magister Teknologi Informasi. Selain itu, saya juga sering ditugaskan untuk mengampu mata kuliah Aplikasi Sistem Enterprise dan e-Business. Pengalaman sebagai seorang praktisi e-Business juga akan turut mewarnai tulisan-tulisan saya ini. Semoga bermanfaat.

Pengertian Dasar

Banyak yang telah mencoba mengartikan e-business. Tapi, secara sederhana kita dapat memahami e-business sebagai ä company that has an online presence. Entitas bisnis yang hadir secara online, dan dapat melakukan aktivitas selling (menjual), trade (berdagang), barter (bertukar-jasa) atau melakukan transaksi disebut sebagai e-commerce. Tentu saja pengertian ini dapat diperdebatkan, tapi saya melihatnya dari sudut pandang seorang praktisi.

Bahasan saya tentang e-Business, saya awali dengan Model e-Business. e-Business Model sebenarnya merupakan kombinasi dari policy, operasionalisasi, teknologi dan ideologi yang dianut oleh entitas bisnis online. Jadi, secara singkat dapat dikatakan bahwa e-Business tidak hanya "melulu" tentang teknologi (dalam hal ini teknologi Web 2.0), tapi juga berhubungan dengan proses yang ada, dan terutama budaya organisasi itu sendiri.

Secara teori, maka model e-business dibedakan menjadi:

1). Storefront Model; dimana teknologi yang digunakan dibedakan menjadi Shopping-cart Technology dan Online Shopping Malls

2). Auction Model

3). Portal Model

4). Dynamic Pricing Models

Storefront model merupakan tipe e-business yang paling populer di kalangan penggiat dunia maya. Bahkan jika masyarakat awam "bercerita" tentang pengalaman melakukan bisnis secara online, maka sebenarnya, mereka "berbisnis"secara "storefront". Model storefront mengkombinasikan transaction processing, security, online payment, dan information storage, sehingga memungkinkan penyedia menampilkan dan menjual produknya pada platform Web 2.0. Model storefront sebenarnya adalah bentuk dasar e-commerce. Storefront mempertemukan buyer dan seller secara langsung.

Teknis proses bisnisnya adalah seperti ini:

1) Untuk melakukan storefront maka diperlukan katalog online, dimana setiap produk yang akan dijual diorganisasikan pada katalog online tersebut.

2) order pemesanan dilakukan menurut official website

3) proses pembayaran pesanan dilakukan pada lingkungan yang secure (dan konfirmasi)

4) proses pengiriman barang yang dipesan kepada pelanggan (dan konfirmasi)

5) proses mengelola data pelanggan

Tren yang berkembang sekarang ini adalah proses yang ke-6, yakni "menghadirkan"official website penjual kepada pembeli. Jadi, dalam platform Web 2.0, pembeli "tidak diharuskan" untuk mendatangi toko, melainkan informasi tentang barang yang dijual yang harus mendatangi calon pembeli.

Beberapa contoh mengenai storefront model adalah More.com dan Ticketmaster.com. More.com adalah sebuah "toko online" yang memfokuskan diri pada produk-produk kesehatan dan kecantikan. Sedangkan Ticketmaster.com menjual ticket untuk konser, olahraga, seni, dll. Kedua toko online ini benar-benar melakukan bisnis online dengan model storefront.

Freemium

Pengantar:

Sebelum membaca bagian ini, para pembaca diharapkan telah membaca tulisan yang dirujuk pada link berikut ini:

http://www.wired.com/techbiz/it/magazine/16-03/ff_free?currentPage=all

Saya kira, tidak ada sebuah business model yang benar-benar baru, selain yang dilahirkan oleh abad Web 2.0. Tentu saja kita harus memahami apa yang dimaksud dengan Web 2.0 tersebut. Silahkan untuk membaca tulisan saya tentang Paradigma Web 2.0 disini. Atau untuk tentang Perspektif Teknologi Informasi. Pemahaman pembaca tentang Web 2.0 serta akibat-akibat yang ditimbulkan dari digunakannya teknologi Web 2.0 tersebut sangat penting untuk dipahami.

Chris Anderson (canderson@wired.com) yang merupakan editor in chief of  Wired Magazine; memaparkan mengenai Taxonomy of FREE sebagai berikut:

 1) Freemium

What's free: Web software and services, some content. 

Free to whom: users of the basic version.

This term, coined by venture capitalist Fred Wilson, is the basis of the subscription model of media and is one of the most common Web business models. It can take a range of forms: varying tiers of content, from free to expensive, or a premium "pro" version of some site or software with more features than the free version (think Flickr and the $25-a-year Flickr Pro).

2) Advertising
What's free: content, services, software, and more. 

Free to whom: everyone.

Layanan "menampilkan" iklan yang dilakukan mesin google, adalah sebuah contoh nyata bahwa dalam dunia Web 2.0, advertising sudah menjadi FREE. Lihatlah yang dilakukan oleh Amazon.com, dengan menampilkan fitur "buku yang disarankan".

3)  Cross-subsidies
What's free: any product that entices you to pay for something else. 

Free to whom: everyone willing to pay eventually, one way or another.

4) Zero marginal cost
What's free: things that can be distributed without an appreciable cost to anyone. 

Free to whom: everyone.
5) Labor exchange
What's free: Web sites and services. 

Free to whom: all users, since the act of using these sites and services actually creates something of value.
6) Gift economy
What's free: the whole enchilada, be it open source software or user-generated content. 

Free to whom: everyone.

Untuk studi kasus yang dirujuk Chris Anderson; beliau merujuk pada link-link dibawah ini:

Tentang Webmail bisa dilihat disini: 

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_webmail

Tentang  Air Travel bisa dilihat disini: 

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_air

Tentang CD dan DVD bisa dilihat disini:

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_prince

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_dvr

Tentang Direktori Help bisa dilihat disini:

http://www.wired.com/techbiz/it/magazine/16-03/ff_free_411

Saya memilih dua buah studi kasus untuk bahasan kita tentang FREEMIUM:

1) tentang Toko Online Manadokota http://www.manadokota.com/index.php

2) tentang Komunitas Blogger Sulawesi Utara http://www.kawanuablogger.com/

Setiap mahasiswa dipersilahkan untuk mempelajari studi kasus yang dipaparkan oleh Chris A derson tersebut diatas, dan memberi komentar dibagian bawah tulisan ini.

Sedangkan untuk kedua studi kasus yang saya pilihkan, silahkan memberi tanggapan di twitter dengan menggunakan hashtag #MITI dan mencantumkan nama akun @stanlysk, @manadokota dan @bloggermanado.

Selengkapnya bisa ditanyakan saat pertemuan tatap muka.
 

Fase Design

Pada phase disain tim pengembang perangkat lunak melakukan aktivitas untuk menjawab pertanyaan "how to build the system". Tim pengembang akan membuat "system requirements". System requirements menjelaskan aspek-aspek teknik untuk membangun perangkat lunak. Sudah tentu, system requirements ini sangat erat kaitannya dengan functional requirements dan user requirements (yang telah dimodelkan sebelumnya pada fase modelling). Selain melakukan aktivitas yang berhubungan dengan system requirements, maka tim pengembang juga menghasilkan apa yang disebut system specification. Yakni berupa artifak yang terkait dengan pembangunan aplikasi/sistem informasi. 

Beberapa aktivitas umum yang dilakukan di fase disain diantaranya adalah:

1) Menentukan alternatif pilihan apakah akan membuat sendiri, membeli aplikasi jadi atau di-outsource

2) Menerjemahkan model logical (yang telah dibuat pada fase modelling) menjadi physical models.

3) Mendisain "the architecture" dari sistem aplikasi 

4) Menentukan lingkunga implementasi hardware dan software

5) Mendisain sistem masukan dan keluaran, yakni antar-muka penggunanya.

6) Mendisain basis data

7) Mendisain struktur program

8) Membuat laporan dokumentasi (misalnya dokumen SRS)

Saat fase disain berlangsung, biasanya ada beberapa "masalah" yang harus diwaspadai oleh Tim Pengembang, diantaranya adalah ...

1) Feature Creep
ini adalah masalah yang sering terjadi, yakni bertambahnya fitur yang menjadi requirement fungsional dari aplikasi.

2) Silver bullet syndrome
Penjelasan mengenai hal ini sudah saya kupas tuntas disini.

Pengalaman saya dalam mengembangkan aplikasi dan sistem informasi selama ini, menunjukkan bahwa feature creep dan silver bullet syndrome adalah "masalah" yang SELALU terjadi saat fase disain berlangsung. Hal ini tentu saja, harus menjadi perhatian serius dari Tim Pengembang.

Beberapa catatan saya yang terkait pembahasan kuliah Pengantar Fase Disain dapat diklik disini:
1) Tentang Silver Bullet Syndrome
2) Tentang Mengerjakan Proyek Perangkat Lunak
3) Tentang e-Journal Universitas Sam Ratulangi

Catatan:

Slide Kuliah tentang Pengantar Fase Design dapat diunduh disini. 
Pertanyaan dapat diposting sebagai komentar dibawah tulisan ini.

Business Use-case Model

Menggambar Business Use-case Model
 

Business Use-case Model merupakan model yang menggambarkan proses bisnis dari sebuah bisnis atau organisasi dan interaksi proses tersebut dengan pihak luar, seperti para customer dan partner. Model ini diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat (kadang bersifat optional, dimana dapat diilustrasikan dalam satu atau beberapa business use-case diagram).

Dalam prakteknya Business Use-case Model digunakan bersamaan dengan UML Activity Diagram untuk menggambarkan proses bisnis. Menggunakan model Business Use-case sebenarnya dapat mempertajam pemahaman tim pengembang dan user terkait model bisnis sistem informasi yang akan dikembangkan.
 

Business use-case model dibangun dengan elemen-elemen: Business Actor, Business Use-case, dan Activity Diagram untuk menjelaskan model business use-case
 

Business Actor:
Business actor (aktor bisnis) mengambarkan peran yang dimainkan oleh seorang atau sesuatu yang berinteraksi dengan bisnis. Sebuah business actor mengambarkan seorang customer , partner bisnis, atau sebuah sistem informasi yang berhubungan dengan bisnis kita

Gambar dari Business Actor

 

Business Use-case
Business use-case merupakan urutan tindakan yang dimainkan suatu bisnis yang menghasilkan sebuah nilai yang dapat dilihat dan ditunjukan untuk suatu business actor tertentu. Satu business use-case mewakili satu proses bisnis

Gambar dari Business Use-case

Berikut adalah sebuh Contoh Gambar Business use-case Model dari studi kasus sebelumnya disini

UML Use-case Diagram

Menggambar UML Use-case Diagram 

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Berikut adalah Gambar Notasi Use Case

Berikut adalah cara menggambar use-case diagram:

Catatan:

Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.

1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.

2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.

3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula. 

Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend.
Dependency include:
Sebuah Use-case dapat meng-include fungsionalitas Use-case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa Use-case yang di-include akan dipanggil setiap kali Use-case yang meng-include dieksekusi secara normal. Sebuah Use-case dapat di-include oleh lebih dari satu Use-case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Contoh Use-case (include)

 

Ket:
Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case “Make Appointment” meng-include fungsionalitas dari Use-case “Get Treatment” sebagai bagian dari proses saat dieksekusi.

Dependency extend:
Sebuah Use-case juga dapat meng-extend Use-case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar Use-case menunjukkan bahwa Use-case yang satu merupakan spesialisasi dari yang lain.

Contoh Use-case (extend):

Ket:
Setelah pasien membuat temu janji dengan dokter, pasien ini  tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana “Make Appointment” adalah base Use-case dan “Cancel Appointment” merupakan extended Use-case.

Gambar  Contoh Interaksi Antara Aktor dan Sistem (Use-case)

Berikut adalah Contoh Use-case description

Keterangan

Normal course:         

Rangkaian kejadian yang terjadi sesuai harapan
Alternate course:    

Mendokumentasikan kelakuan Use-case jika terjadi exception
Pre-condition:    

Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case.
Post-condition:    

Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case.

Sebuah Video Tutorial tentang UML Use Case Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=Zk-580BqSNY&feature=relmfu