Follow You

Vocalist Oli Sykes shared in a track-by-track commentary with Spotify that he and Jordan Fish wrote “Follow You” while they were writing “Drown”. He also shared:

And when it got to that certain point like “this fucking sucks and I don’t really want to do this anymore,” that’s when you have that realizations. I realized no matter how bad being together can sometimes get, the alternative is so much worse.

Lyrically, it comes from me and my other half were going through a particular rough patch where things weren’t looking too good and it gets to a certain point. And when it got to that certain point like “this fucking sucks and I don’t really want to do this anymore,” that’s when you have that realizations. I realized no matter how bad being together can sometimes get, the alternative is so much worse. It’s one of those beautiful realizations that can only come from something really ugly.

Source: http://genius.com/Bring-me-the-horizon-follow-you-lyrics

Apa itu High Availability?

Selama ini gw pikir High Availability (HA) semata-mata hanya mempersiapkan cadangan kalau bencana (disaster) muncul. Mempersiapkan cadangan dalam artian data backup. Ternyata pemahaman tersebut tidak sepenuhnya benar. Hal ini baru gw sadari setelah diberikan pekerjaan untuk membuat solusi kalau sampai layanan telekomunikasi yang digunakan tim Customer Service (CS) kena bencana.

Hasil akhir yang diharapkan — ingat selalu untuk berpikir dari hasil akhir yang diharapkan — adalah: tim CS harus selalu dapat menggunakan layanan telekomunikasi. Mereka tidak peduli dan tidak perlu tahu* kalau ada bencana terjadi. Yang mereka pedulikan adalah mereka datang ke kantor dan melakukan pekerjaan mereka: menghubungi dan dihubungi pelanggan.

Untuk itu harus ada minimal 2 (dua) layanan telekomunikasi yang berfungsi dalam waktu bersamaan. Namun hanya ada 1 (satu) layanan yang aktif digunakan dalam satu waktu*. Katakanlah ada layanan utama dan layanan cadangan.

Ketika bencana terjadi (pasti terjadi, hanya masalah waktu) dan mengakibatkan layanan utama gagal beroperasi, maka saatnya layanan cadangan yang aktif. Istilah yang digunakan untuk mewakili proses ini adalah failover.

Ketika bencana berakhir dan layanan utama kembali normal. Maka layanan utama harus kembali aktif, menggantikan layanan cadangan. Proses mengembalikan penggunaan dari layanan cadangan ke layanan utama disebut fallback.

Hubungan failover dan fallback bisa dilihat pada gambar berikut ini. Gambar ini gw dapat dari dokumentasi “Building Elastix-2.4 High Availability Clusters with DRBD and Heartbeat (using a single NIC)“. Sumber: http://www.theserverexpert.com/elastix_2.4_ha_cluster-updated.pdf

Failover and fallback.

Beberapa pertanyaan yang harus dijawab adalah:

  1. layanan-layanan apa saja yang vital dan harus selalu tersedia?
  2. apakah layanan-layanan tersebut dapat dibuat duplikasinya? hal ini harus menjawab pertanyaan lain, yaitu:
    • apa saja kebutuhan layanan-layanan tersebut?
    • bagaimana membuat duplikasi kebutuhan-kebutuhan tersebut?
    • seberapa mudah membuat duplikasi layanan tersebut?
  3. data apa saja yang harus tersedia?

Sejauh ini baru itu saja yang terpikirkan. Seharusnya ada beberapa lagi, tapi gw belum sampai di sana.

Pertanyaan tadi keluar dari pengalaman ketika berusaha membuat duplikasi layanan telekomunikasi berbasis Asterisk. Asterisk dikelola dengan FreePBX, dan diberi nilai tambah oleh produk bernama Elastix. Elastix merupakan sekumpulan alat bantu yang dikembangkan di atas sistem operasi CentOS.

Asterisk memiliki modul bernama CDR (Call Detail Recording) yang berfungsi untuk menyimpan metadata komunikasi telepon yang dilakukan melalui sistem.  Terdapat juga modul lain yang merekam semua pembicaraan. Oleh karena itu, data tadi harus selalu tersedia.

Elastix menggunakan SQLite sebagai penyimpanan data konfigurasi. FreePBX sebagai antarmuka Asterisk sepertinya tidak membutuhkan penyimpanan data apapun, namun memiliki beberapa modul tambahan yang mungkin saja membutuhkan penyimpanan data untuk menyimpan konfigurasi*.

Yang ingin gw sampaikan adalah pentingnya identifikasi detail kebutuhan tiap layanan karena menentukan apa yang harus diduplikasi dan caranya.

Apa yang dimaksud dengan kebutuhan tiap layanan?

Di atas sudah gw jelaskan bahwa modul Asterisk bernama CDR membutuhkan MySQL untuk penyimpanan data. Hal ini memaksa untuk mencari tahu apakah MySQL memiliki fitur untuk melakukan duplikasi layanan. Setelah dicari tahu ternyata MySQL memiliki fitur replikasi. Lalu muncul pertanyaan selanjutnya, MySQL versi berapa yang digunakan? Apakah versi tersebut sudah mendukung skenario replikasi yang kita butuhkan? Intinya adalah pemahaman tools yang digunakan, layanan yang ditawarkan tool tersebut, serta kompleksitasnya.

Kesimpulan

High Availability (HA) sulit dan kompleks sekali. Karena harus dipikirkan secara matang dan dilakukan oleh mereka yang paham dan kenal betul karakteristik penggunaan layanan, karakteristik layanan itu sendiri, karakteristik kebutuhan layanan, dan sebagainya.

Tulisan ini gw buat semata-mata untuk mengeluarkan isi pikiran saja. Mungkin saja berguna buat orang lain.

The Revenue Cycle

Week #5, 12 Oktober 2014

The Revenue Cycle

Tujuan: bisa membuat struktur serta desain DFD dan system flowchart dari revenue cycle (revenue), expenditure cycle (expenditure), production cycle (production), HRD cycle, dan general ledger (jurnal umum) dan laporan finansial menggunakan model REA.

Materi:

  1. pembahasan Revenue Cycle serta tujuan utamanya ngapain aja sih
  2. REA Revenue Cycle
  3. DFD Revenue Cycle
  4. System Flowchart of Revenue Cycle

Pertama, apa itu Revenue Cycle? Baca lagi catatan “Business Process Model” (minggu ke-2).

Berdasarkan transaksi yang berdampak pada aset dan modal perusahaan, Brett menyatakan ada tiga macam siklus:

  • Expenditure cycle (pengeluaran)
  • Conversion cycle (konversi/produksi)
  • Revenue cycle (penjualan/pembayaran)

Nah, minggu ini secara spesifik fokus pada Revenue Cycle. Kita akan memodelkan siklus pendapatan.

Siklus pendapatan dimulai ketika pelanggan menunjukkan keinginan untuk membeli suatu barang atau jasa dan berakhir ketika pembayaran diterima.

Selama proses, penjualan harus diotorisasi dan direkam dengan benar, barang harus dikemas dan dikirim kepada pelanggan secara tepat waktu dan benar.

Penagihan kepada pelanggan harus dilakukan dengan jumlah tagihan yang tepat, dalam waktu yang tepat, dan sesuai dengan barang dan/atau jasa yang diterima pelanggan.

Kegiatan diakhiri dengan penerimaan pembayaran dari pelanggan, yang tentunya harus cepat dan akurat pula.

Jadi siklus pendapatan terdiri dari proses bisnis penjualan dan proses bisnis pembayaran tagihan.

Secara keseluruhan proses ini terdiri dari event-event operasional yang berkaitan dengan:

  • bagaimana menarik pelanggan
  • membantu pelanggan memilih barang dan jasa
  • menyerahkan atau mengirim barang dan jasa yang dibeli pelanggan
  • menerima pembayaran dari pelanggan

Proses harus dilakukan dengan:

  • meminimalkan waktu layanan mulai dari pemilihan produk dan jasa sampai dengan pembayaran
  • meminimalkan jumlah uang tunai yang tidak tertagih, atau
  • memastikan pembayaran untuk barang dan jasa dengan benar diterima, dan
  • menetapkan harga yang seimbang dengan kualitas barang dan jasa dan seimbang antara kepentingan pelanggan dan keuntungan perusahaan

Proses penjualan merupakan proses melayani pelanggan dan terjadinya transaksi penjualan, sehingga proses ini harus dilakukan secara efektif dalam melakukan, merekam dan memantau penjualan barang dan jasa, serta mengatur pasokan cepat barang dan jasa.

REA Siklus Pendapatan (Revenue Cycle REA)

REA is all about operational events (lihat lagi catatan di minggu ke-2 Business Process Model). Dalam penyusunan REA, terlebih dahulu perlu dilakukan identifikasi event operasional.

Mengacu pada konsep dokumentasi dari siklus pendapatan yang yang digambarkan oleh Brett et.al. (2010, page 400), yang terlihat pada gambar di bawah, dapat diturunkan bahwa event operasional dari siklus pendapatan adalah:

  • menerima pesanan (receive sales order)
  • memilih
  • mengemas dan mengirim barang (pick, pack, and ship the goods)
  • menagih (bill the customer), dan
  • menerima pembayaran (receive payment)

Pada bahasan ini, payment record termasuk kategori event proses informasi, sehingga tidak digambarkan dalam REA.

 

revenue cycle diagram

Resources yang terkait adalah

  • goods or services (inventory)
  • cash

Agents yang terlibat adalah

  • customers
  • sales personnel
  • courier
  • warehouse personnel (gudang)
  • treasury personnel (bendahara)

Gambar 02 berikut ini adalah REA model Siklus Pendapatan.

Pada diagram REA diatas, terdapat dua pasang entitas yang mempunyai kardinalitas M:M, sehingga untuk penyusunan database diperlukan entitas link order-good dan, entitas link ship-good.

Gambar 03 berikut adalah Revisi REA Model Siklus Pendapatan.

Yeah, at some point I event make notes in this blog. My workflow usually was: translating text I read from referenced book, and re-read my translations several times until I fully grasped the idea (I am not a genius). This note is one of those translations written in October 12nd, 2014. Many of my notes is just a plain text files backed up in Dropbox.

Never actually happened, was it?

you know what?

what?

i wonder what will you say to your next girlfriend regarding to what happened to your last relationship?

umm…
i dont know. i *really* dislike being pissed-off.
i’d rather be alone than be pissed-off.

oh. wow. okay.

what?

nothing.


Decided to post this draft made on November 24th 2014. Again, unable to recall the reason why I wrote it back then.