Sistem berikut sebenarnya tidak benar-benar diImplementasikan di sebuah manufaktur tertentu, project ini hanya tuk bantu teman yang kebetulan bekerja di manufaktur tersebut; tepatnya di bagian Quality Assurance. Sangat tidak mungkin jika manufaktur sekelas itu menggunakan program se-sederhana ini, dan terbukti; bahwa katanya akhirnya mereka memiliki kontrak kerjasama dengan perusahaan penyedia database ternama: Oracle.
Konon menurut cerita dari temen ini, perusahaan sekelas Oracle juga membutuhkan waktu untuk analisa sistem berjalan di sana kurang lebih 1 (satu) tahun. Waktu yang cukup panjang bukan? Perusahaan se-kelas Oracle yang memiliki bank FrameWork yang notabene modular dan customizeAble aja menghabiskan waktu segitu! Oleh karena itu, amat sangat tidak mungkin jika sebuah sistem diImplementasikan dalam waktu singkat, kecuali perusahaan kecil ya tentunya.. =D
Tapi, kalo dirunut dari awal bisnis proses di manufaktur itu; katakan dari mulai proses Purchasing material, kemudian Perencanaan Produksi, Produksi itu sendiri hingga Finishing, pengecekan Quality hingga akhirnya sampai ke bagian Keuangan; percaya si kalo menghabiskan waktu segitu. Kebayang tuh kasus ngJelimet! Jadi kalo di topik berikut: ya, ga ada apa-apanya. Cuma proses yang numpang lewat! =D
Awalnya teman bilang: bahwa bagiannya sebelum adanya kegiatan otomasi sistem ini memang masih menggunakan sistem berjalan manual, dengan menggunakan program se-sederhana excel untuk mengImpelementasikan kebutuhan administrasi bagian quality ini. Karena sudah cukup lama ia bekerja di sana, dan kuliah di salah satu universitas swasta di bilangan Bekasi; maka tema yang dipilih dan diangkat untuk dijadikan bahan tugas akhirnya ya: tema ini.
Seorang Programmer itu sebenarnya (mnurut kacamata gue aja ya?) itu ga lebih dari tukang, ia tetap membutuhkan sang arsitek untuk membantu pekerjaannya membangun sebuah rumah katakan; dan yang tidak kalah penting: sang pemilik rumah yang punya dana untuk membiayai pembangunan ini. Semuanya: harus saling berkomunikasi untuk memperoleh apa yang diinginkan, sang pemilik harus mampu menjelaskan kebutuhan, dan tentu saja mendanai; kemudian diterjemahkan oleh si arsitek. Dan akhirnya: si Programmer lah yang kemudian membangun dan meRealisasikan bangunan yang diCita-citakan ini.
Berikut adalah salah 1 (satu) contoh kebutuhan yang diInginkan oleh perusahaan:
Tanggung jawab Bagian Quality adalah: dapat mengIdentifikasi jumlah kerusakan pada produk atau produk cacat katakan; yang dapat menentukan kinerja bagian lainnya dan menjaga produk akhir untuk bebas dari cacat atau kerusakan tadi. Nah, tinggal pengukurannya ini diKlasifikasikan; apakah: by Customer, by Mesin yang digunakan atau kriteria tertentu yang diInginkan agar problem dapat diCari solusinya.
Berikut kalo diliat dari layout report, yang tadi kan versi graphical-nya. Layout memiliki kekurangan dan kelebihan masing-masing, untuk keperluan HardCopy tentu saja yang lebih dibutuhkan adalah versi cetak ini. Ada bagian tertentu (tmen bilang) yang memang bertugas melakukan filtrasi klasifikasi ini secara periodik, nanti akan kita kupas dalam sesi selanjutnya.
Februari, tanggal 1 2013
Lanjut lagi ya? Item yang diProduksi di sana itu berupa sheet (lembaran) dari bahan mica, jadi cairan yang dibekukan untuk dibentuk menjadi lembaran yang dapat digunakan, misalnya: untuk board iklan. Nah, waktu diProduksi kan ga smuanya finished good; untuk itu identifikasi ini diperlukan.
Defect atau cacatnya suatu item harus dapat diIdentifikasi seperti yang pernah dijelaskan sebelumnya, dan relasi entitas yang mungkin terjadi dapat dilihat pada ilustrasi di atas, mulai dari siapa yang order produk, diProduksi pada mesin mana, hingga siapa yang melakukan identifikasi itu.
Kalo diIlustrasikan dengan class diagram kurang lebih sama ya? Relasi antar class-nya dah jelas, jadi perancangan transaksi menggunakan class diagaram memang benar-benar membantu mind mapping kita.
Dan untuk SubMenu transaksinya: ya Identifikasi itu sendiri. Sisanya SubMenu untuk keperluan Pelaporan dan satu untuk Informasi lainnya.
Sekarang kalo diliat secara keseluruhan melalui agregasi ini.
Kenapa ngopi itu dilarang? Jangan kebanyakan ngopi! Mungkin karena: kalo udah ngopi jadi males bangun gue rasa! =D
Kaya sekarang aja nih, inspirasi gi keluar smua, jari dah kaya mo jalan sendiri. Jadi biarin aja dia mo ngetik apa lah.. Ditambah, sesajennya lengkap. Liat kan? =)
Oh ya, di luar ujan tuh.
Kita membutuhkan ini untuk tahapan Design, kalo class dalam bentuk Entity kan masih di tahapan analisa. Beberapa contoh diagram yang membutuhkan ini di antaranya: Activity, Sequence dan Communication. Interaksi antara actor, class itu sendiri dan control ini.
ngantuk juga euy.. =(
lanjut lagi ntar deh.
gini ni resiko-nya jadi vampire,
bgadang mulu! =D
Dah jam 09.30 pagi nih..
Masih di Februari tapi tanggal 2 2013.
Berikut adalah sistem berjalan sebelum otomasi di lakukan pada Bagian Quality ini, proses berjalan semi-otomasi. Maksudnya, sebenarnya sudah menggunakan program office excel untuk melakukan pendataan.
Ga kerasa, dah 03 Februari 2013.
Hm.. Ini kayanya mo bikin activity cuma masih blom dapet inspirasi, cari diagram yang laen dulu aja lah! Sequence enak kayanya nih. =D
Lumayan dah ktemu 1 (satu) kan? Rada-rada nyRempet dikit kayanya tuh! =D
Sbnernya dari dulu mo bikin functional modeling ga jadi-jadi, pengen punya pattern yang full gitu. Jadi supaya bisa dipake berUlang-ulang. Write once, use anytime!
Tapi kalo ga dimulai ya ga kelar-kelar? Harus dipancing dulu, biasa.. Kaya class, trus use-case, itu dah ada sbagian yang dah bisa diPake kapan aja. Makanya lagi mikirin pattern untuk funcional: activity, sequence, communication (kalo di UML versi 1 namanya collaboration). Hm.. Deployment juga blom ada tuh, ada si sbagian.
Ternyata, si objek kalo kita deskripsikan classifier-nya itu bisa jadi simbol iconic! Baru ktemu caranya, pantes dari kmaren nyari gimana si cara supaya objeknya itu jadi gambar orang, kirain masalah pake rational rose ato starUML; ternyata bukan!
Kebayang nih kalo alternate: mode baru, ubah dan hapus diTumpuk jadi satu? Pasti pusing ngLiatnya! Tapi kalo diPisah per frame khawatir pesan yang mo disampaikan ga nyampe? Misalkan lifeTime dari object, kapan dia created dan kapan dia destroyed? Kita coba gabung aja deh smuanya, kita liat hasilnya nanti..
Liat nih kalo dah full? diJamin pusink!
Tapi Object LifeTime-nya kliatan ya? =)
Kayanya mesti break dulu nih..
Konon menurut cerita dari temen ini, perusahaan sekelas Oracle juga membutuhkan waktu untuk analisa sistem berjalan di sana kurang lebih 1 (satu) tahun. Waktu yang cukup panjang bukan? Perusahaan se-kelas Oracle yang memiliki bank FrameWork yang notabene modular dan customizeAble aja menghabiskan waktu segitu! Oleh karena itu, amat sangat tidak mungkin jika sebuah sistem diImplementasikan dalam waktu singkat, kecuali perusahaan kecil ya tentunya.. =D
Tapi, kalo dirunut dari awal bisnis proses di manufaktur itu; katakan dari mulai proses Purchasing material, kemudian Perencanaan Produksi, Produksi itu sendiri hingga Finishing, pengecekan Quality hingga akhirnya sampai ke bagian Keuangan; percaya si kalo menghabiskan waktu segitu. Kebayang tuh kasus ngJelimet! Jadi kalo di topik berikut: ya, ga ada apa-apanya. Cuma proses yang numpang lewat! =D
Awalnya teman bilang: bahwa bagiannya sebelum adanya kegiatan otomasi sistem ini memang masih menggunakan sistem berjalan manual, dengan menggunakan program se-sederhana excel untuk mengImpelementasikan kebutuhan administrasi bagian quality ini. Karena sudah cukup lama ia bekerja di sana, dan kuliah di salah satu universitas swasta di bilangan Bekasi; maka tema yang dipilih dan diangkat untuk dijadikan bahan tugas akhirnya ya: tema ini.
Seorang Programmer itu sebenarnya (mnurut kacamata gue aja ya?) itu ga lebih dari tukang, ia tetap membutuhkan sang arsitek untuk membantu pekerjaannya membangun sebuah rumah katakan; dan yang tidak kalah penting: sang pemilik rumah yang punya dana untuk membiayai pembangunan ini. Semuanya: harus saling berkomunikasi untuk memperoleh apa yang diinginkan, sang pemilik harus mampu menjelaskan kebutuhan, dan tentu saja mendanai; kemudian diterjemahkan oleh si arsitek. Dan akhirnya: si Programmer lah yang kemudian membangun dan meRealisasikan bangunan yang diCita-citakan ini.
Berikut adalah salah 1 (satu) contoh kebutuhan yang diInginkan oleh perusahaan:
Tanggung jawab Bagian Quality adalah: dapat mengIdentifikasi jumlah kerusakan pada produk atau produk cacat katakan; yang dapat menentukan kinerja bagian lainnya dan menjaga produk akhir untuk bebas dari cacat atau kerusakan tadi. Nah, tinggal pengukurannya ini diKlasifikasikan; apakah: by Customer, by Mesin yang digunakan atau kriteria tertentu yang diInginkan agar problem dapat diCari solusinya.
Berikut kalo diliat dari layout report, yang tadi kan versi graphical-nya. Layout memiliki kekurangan dan kelebihan masing-masing, untuk keperluan HardCopy tentu saja yang lebih dibutuhkan adalah versi cetak ini. Ada bagian tertentu (tmen bilang) yang memang bertugas melakukan filtrasi klasifikasi ini secara periodik, nanti akan kita kupas dalam sesi selanjutnya.
Februari, tanggal 1 2013
Lanjut lagi ya? Item yang diProduksi di sana itu berupa sheet (lembaran) dari bahan mica, jadi cairan yang dibekukan untuk dibentuk menjadi lembaran yang dapat digunakan, misalnya: untuk board iklan. Nah, waktu diProduksi kan ga smuanya finished good; untuk itu identifikasi ini diperlukan.
Defect atau cacatnya suatu item harus dapat diIdentifikasi seperti yang pernah dijelaskan sebelumnya, dan relasi entitas yang mungkin terjadi dapat dilihat pada ilustrasi di atas, mulai dari siapa yang order produk, diProduksi pada mesin mana, hingga siapa yang melakukan identifikasi itu.
Kalo diIlustrasikan dengan class diagram kurang lebih sama ya? Relasi antar class-nya dah jelas, jadi perancangan transaksi menggunakan class diagaram memang benar-benar membantu mind mapping kita.
Tapi selain keperluan identifikasi, di sistem ini sendiri juga ada kebutuhan lain agar sistem dapat berjalan dengan semestinya. Terlihat di ilustrasi, bahwa kebutuhan bergantung dari peran si actor itu sendiri:
- Jika ia berperan sebagai Administrator: ia dapat mengKonfigurasi sistem,
- Sebagai Operator: ia melakukan rutinitas identifikasi, dan terakhir
- Masih sebagai Operator: kebutuhan pelaporan kegiatan identifikasi.
Berikut beberapa pengaturan yang harus dilakukan di sistem agar integrasi dapat diLakukan sebagaimana mestinya:
- Customer,
- Bagian,
- Karyawan,
- Mesin,
- Jenis Defect,
- Defect,
- Jenis Produk,
- Produk, dan terakhir
- Pengguna Sistem.
Oh iya, dulu pernah ngupas juga kan tentang Pattern di Master Data kan:
Jadi untuk konfigurasi pattern master data dah ga perlu dibahas lagi ya? Toh prinsipnya sama untuk semua data master. Untuk lebih jelas dapat merujuk ke link di atas. Cuma, untuk kasus ini ada ekstensi menampilkan proses seleksi data dalam bentuk graphical.
Ini kalo mo liat contohnya, sebenarnya seleksi data juga:
Sekilas tentang produk:
Di sini ada yang menarik, yaitu mengenai measurement. Karena item yang diukur itu bidang luas, maka item tidak dapat diukur dengan satuan. Artinya: 1 item berbeda luasnya dengan yang lain, perhatikan ilustrasi di bawah ukuran dari produk yang terdiri dari berbagai pilihan:
Kalo kita kalikan jumlah panjang dengan lebarnya, sudah tentu tiap produk berbeda kan? Nah, di situ diperlukan bahwa harus ada pengukuran yang dapat dijadikan referensi. Untuk itu kita perlu konversi ke ukuran yang paling kecil, dalam hal ini: 3 x 6 = 18 cm2. Jadi, 1 unit itu ditentukan dengan luas ini..
Kita ambil contoh ukuran 4 x 8 = 32 cm2, berbeda kan dengan yang 3 x 6. Makanya ga bisa kalo dihitung dengan satuan! Sekarang bidang dengan luas 32 cm2 ini kita kita bagi dengan satuan terkecil tadi: 18 dan diperoleh hasil 32 / 18 = 1,777777777777778. Kita bulatkan menjadi: 1,8 unit.
Jadi produk dengan ukuran 4 x 8 kita anggap sebagai 1,8 unit. Bisa dimengerti ya? =D
Kasus ini mirip dengan content, katakan:
Harus ada konversi ke satuan terkecil!
Enak ya, kalo ngDevelop program sederhana; menu-nya cuma ada (hm..) paling banyak 4 s.d 5 lah. Ga terlalu pusink! =D
Di sini ada yang menarik, yaitu mengenai measurement. Karena item yang diukur itu bidang luas, maka item tidak dapat diukur dengan satuan. Artinya: 1 item berbeda luasnya dengan yang lain, perhatikan ilustrasi di bawah ukuran dari produk yang terdiri dari berbagai pilihan:
Kalo kita kalikan jumlah panjang dengan lebarnya, sudah tentu tiap produk berbeda kan? Nah, di situ diperlukan bahwa harus ada pengukuran yang dapat dijadikan referensi. Untuk itu kita perlu konversi ke ukuran yang paling kecil, dalam hal ini: 3 x 6 = 18 cm2. Jadi, 1 unit itu ditentukan dengan luas ini..
Kita ambil contoh ukuran 4 x 8 = 32 cm2, berbeda kan dengan yang 3 x 6. Makanya ga bisa kalo dihitung dengan satuan! Sekarang bidang dengan luas 32 cm2 ini kita kita bagi dengan satuan terkecil tadi: 18 dan diperoleh hasil 32 / 18 = 1,777777777777778. Kita bulatkan menjadi: 1,8 unit.
Jadi produk dengan ukuran 4 x 8 kita anggap sebagai 1,8 unit. Bisa dimengerti ya? =D
Kasus ini mirip dengan content, katakan:
- 1 dus @ 12 pack, dan
- 1 pack @ 20 batang, jadi:
- 1 dus = 240 batang.
Harus ada konversi ke satuan terkecil!
Enak ya, kalo ngDevelop program sederhana; menu-nya cuma ada (hm..) paling banyak 4 s.d 5 lah. Ga terlalu pusink! =D
Sekarang kalo diliat secara keseluruhan melalui agregasi ini.
Kenapa ngopi itu dilarang? Jangan kebanyakan ngopi! Mungkin karena: kalo udah ngopi jadi males bangun gue rasa! =D
Kaya sekarang aja nih, inspirasi gi keluar smua, jari dah kaya mo jalan sendiri. Jadi biarin aja dia mo ngetik apa lah.. Ditambah, sesajennya lengkap. Liat kan? =)
Oh ya, di luar ujan tuh.
Oh ya, 1 (satu) lagi nih: kebutuhan Pelaporan. Seperti biasa, dapat secara periodik; dan seperti yang dijelaskan di awal, untuk peran tertentu menganalisa klasifikasi melalui:
- Customer,
- Mesin dan
- Produk.
Kita membutuhkan ini untuk tahapan Design, kalo class dalam bentuk Entity kan masih di tahapan analisa. Beberapa contoh diagram yang membutuhkan ini di antaranya: Activity, Sequence dan Communication. Interaksi antara actor, class itu sendiri dan control ini.
ngantuk juga euy.. =(
lanjut lagi ntar deh.
gini ni resiko-nya jadi vampire,
bgadang mulu! =D
Dah jam 09.30 pagi nih..
Masih di Februari tapi tanggal 2 2013.
Berikut adalah sistem berjalan sebelum otomasi di lakukan pada Bagian Quality ini, proses berjalan semi-otomasi. Maksudnya, sebenarnya sudah menggunakan program office excel untuk melakukan pendataan.
Ga kerasa, dah 03 Februari 2013.
Hm.. Ini kayanya mo bikin activity cuma masih blom dapet inspirasi, cari diagram yang laen dulu aja lah! Sequence enak kayanya nih. =D
Lumayan dah ktemu 1 (satu) kan? Rada-rada nyRempet dikit kayanya tuh! =D
Sbnernya dari dulu mo bikin functional modeling ga jadi-jadi, pengen punya pattern yang full gitu. Jadi supaya bisa dipake berUlang-ulang. Write once, use anytime!
Tapi kalo ga dimulai ya ga kelar-kelar? Harus dipancing dulu, biasa.. Kaya class, trus use-case, itu dah ada sbagian yang dah bisa diPake kapan aja. Makanya lagi mikirin pattern untuk funcional: activity, sequence, communication (kalo di UML versi 1 namanya collaboration). Hm.. Deployment juga blom ada tuh, ada si sbagian.
Ternyata, si objek kalo kita deskripsikan classifier-nya itu bisa jadi simbol iconic! Baru ktemu caranya, pantes dari kmaren nyari gimana si cara supaya objeknya itu jadi gambar orang, kirain masalah pake rational rose ato starUML; ternyata bukan!
Kebayang nih kalo alternate: mode baru, ubah dan hapus diTumpuk jadi satu? Pasti pusing ngLiatnya! Tapi kalo diPisah per frame khawatir pesan yang mo disampaikan ga nyampe? Misalkan lifeTime dari object, kapan dia created dan kapan dia destroyed? Kita coba gabung aja deh smuanya, kita liat hasilnya nanti..
Liat nih kalo dah full? diJamin pusink!
Tapi Object LifeTime-nya kliatan ya? =)
Kayanya mesti break dulu nih..
Comments
Post a Comment