Meningkatkan Model Data Portal Pekerjaan Online Kami

Di era persaingan yang ketat ini, portal pekerjaan bukan hanya platform untuk mempublikasikan dan mencari pekerjaan. Mereka memanfaatkan layanan dan fitur canggih untuk membuat pelanggan tetap terlibat. Mari selami beberapa fitur lanjutan dan buat model data yang dapat menanganinya.

Fitur dasar yang diperlukan untuk situs portal pekerjaan sudah saya jelaskan di artikel sebelumnya. Modelnya ditunjukkan di bawah ini. Kami akan mempertimbangkan model ini sebagai basis, yang akan kami ubah untuk memenuhi persyaratan baru. Pertama, mari pertimbangkan persyaratan (atau penyempurnaan) ini.

Apa yang Kami Tambahkan ke Model Data Portal Pekerjaan Online?

Secara singkat, kami akan menambahkan empat penyempurnaan ke model data sebelumnya:

Dasbor Pribadi untuk Pencari Kerja. Ini melacak semua lamaran pekerjaan mereka dan memberikan pembaruan waktu nyata tentang perubahan status apa pun (yaitu, aplikasi berubah dari diterima menjadi ditinjau).
Dasbor Profil. Ini merinci siapa yang mengunjungi profil pencari kerja dan berapa kali resume mereka diunduh dalam satu hari, minggu, atau bulan terakhir.
Pengelolaan Layanan Berbayar. Portal pekerjaan sering kali menawarkan layanan seperti persiapan resume ahli, manajemen profil sosial, konsultasi karir, dll. Fungsi baru kami akan dapat mendukung penawaran berbayar.
Manajemen Formulir Pra-Aplikasi. Saat pelamar mengajukan lamaran pekerjaan, mereka mungkin diminta untuk mengisi kuesioner singkat terkait dengan waktu kerja, lokasi, dan pemeriksaan latar belakang. Kami akan membangun cara agar formulir ini dapat disesuaikan oleh perekrut dan agar pertanyaan serta tanggapan dapat ditangkap oleh sistem.

Peningkatan# 1:Dasbor Pribadi

Pertanyaan untuk Dijawab: Bagaimana status aplikasi yang diajukan saat ini? Apakah itu terpilih untuk wawancara? Apakah sudah pernah dilihat?

Kami dapat melacak lamaran pekerjaan dengan memasukkan job_application_status_id kolom di job_post_activity meja. Kolom ini menyimpan status lamaran pekerjaan saat ini. Kita perlu membuat tabel lain, job_application_status , untuk menampung semua kemungkinan status aplikasi. Beberapa status mungkin 'dikirim', 'dalam peninjauan', 'diarsipkan', 'ditolak', 'dipilih untuk wawancara', 'dalam proses rekrutmen', dan seterusnya.

Tabel baru lainnya, job_post_activity_log , menyimpan informasi mengenai semua tindakan yang dilakukan pada lamaran pekerjaan, siapa yang melakukan tindakan tersebut, dan kapan tindakan tersebut dilakukan. Tabel ini berisi kolom berikut:

id – Kunci utama tabel.
job_post_activity_id – ID aplikasi tempat tindakan dilakukan.
job_post_action_id – ID tindakan yang dilakukan. Ini adalah kunci asing yang tertaut ke job_post_action meja. Jenis tindakan yang mungkin kami simpan di sini termasuk 'dikirim', 'dilihat', 'diwawancarai', 'tes tertulis diambil', 'penawaran dalam proses', 'penawaran dikirim', 'penawaran diterima', dll.
action_date – Tanggal saat tindakan dilakukan.
user_account_id – ID orang yang melakukan tindakan.

Apakah “job_post_action” identik dengan “job_application_status”? Apa perbedaannya?

Mereka tampak identik pada awalnya, tetapi mereka sebenarnya berbeda. Ada alasan yang sah mengapa kami membutuhkan dua bidang serupa:

Seorang kandidat diwawancarai oleh dua orang atau lebih secara terpisah. Dalam hal ini, status lamaran kerja tetap sama (yaitu 'sedang menjalani proses rekrutmen') hingga semua putaran wawancara selesai. Namun, catatan untuk setiap pewawancara individu dimasukkan ke dalam job_post_activity_log meja, dan mereka memiliki tindakan 'diwawancarai'.
Sebuah lamaran dapat dilihat oleh lebih dari satu perekrut di perusahaan yang sama. Dengan menggunakan dua atribut ini, Anda tidak akan kehilangan informasi pelamar.
Membuat penawaran kepada kandidat terpilih harus melalui beberapa persetujuan (yaitu persetujuan dari tim keuangan, persetujuan dari manajer departemen perekrutan, dan sebagainya). Dalam hal ini, status lamaran pekerjaan tetap 'penawaran dalam peninjauan', tetapi database dapat mencatat persetujuan mana yang telah diterima dan mana yang belum melalui job_post_activity_log meja.

Peningkatan# 2:Dasbor Profil

Pertanyaan untuk Dijawab: Siapa yang baru-baru ini menemukan profil saya? Berapa kali dilihat oleh perekrut dalam sebulan, minggu, atau hari terakhir? Apakah perekrut dari perusahaan top melihat profil saya?

Jawaban atas semua pertanyaan ini ada di profile_visit_log meja. Tabel ini menangkap semua data kunjungan profil, termasuk siapa yang mengunjungi profil, kapan profil itu dilihat, dan seterusnya. Kolom dalam tabel ini adalah:

id – Kunci utama tabel.
seeker_profile_id – Profil mana yang dikunjungi.
visit_date – Saat profil diakses.
user_account_id – Siapa yang melihat profilnya.
is_resume_downloaded – Kolom bendera yang menunjukkan jika resume terkait diunduh selama kunjungan. Kolom ini akan membantu kami mengetahui berapa kali resume diunduh oleh perekrut.
is_job_notification_sent – Kolom bendera lainnya, yang ini menyatakan apakah pemberitahuan pekerjaan dikirim ke pemilik profil.

Peningkatan# 3:Manajemen Layanan Berbayar

Pertanyaan untuk Dijawab: Bagaimana portal online dapat memanfaatkan layanan berbayar tambahan?

Selain platform untuk memposting dan mencari pekerjaan, banyak portal online menyediakan layanan lain, seperti pembuatan resume ahli, konsultasi karir, dll. Mereka juga menawarkan produk untuk membantu pencari kerja menemukan pekerjaan impian mereka di kota impian mereka. Misalnya, salah satu situs pekerjaan terkemuka menawarkan produk yang membuat profil Anda berada di urutan teratas daftar perekrut sehingga Anda bisa mendapatkan lebih banyak tawaran wawancara. Sebagian besar produk atau layanan ini tersedia secara berlangganan. Saat pengguna membeli layanan atau produk, mereka membayar selama jangka waktu tertentu (yaitu sebulan, tiga bulan, satu tahun) untuk penggunaan produk atau layanan tersebut.

Saat saya melihat portal pekerjaan ini, saya perhatikan bahwa hampir tidak ada produk atau layanan yang ditawarkan secara tunggal. Sebagian besar, beberapa produk dan layanan digabungkan menjadi satu paket, dan paket ini ditawarkan kepada pencari kerja atau perekrut.

Dengan mempertimbangkan semua poin ini, saya membuat model data berikut untuk memasukkan layanan dan produk berbayar ke situs kerja online kami yang ada:

product tabel menyimpan rincian tentang produk individu. (Kami akan menyebut produk dan layanan sebagai "produk"). Kolom dalam tabel ini adalah:

id – Kunci utama tabel ini, yang memberikan ID unik untuk setiap produk yang ditawarkan di portal kami.
product_name – Menyimpan nama produk.
product_desc – Menyimpan deskripsi singkat tentang produk.
inception_date – Tanggal saat produk diperkenalkan.
is_active – Apakah suatu produk aktif atau tidak.

Karena produk dan layanan dapat disatukan dalam satu bundel dan ditawarkan kepada pelanggan, saya membuat product_bundle tabel untuk menyimpan catatan dari semua bundel tersebut. Atributnya adalah:

id – Kunci utama tabel, yang memberikan ID unik untuk setiap bundel produk.
product_bundle_name – Menyimpan nama bundel.
inception_date – Tanggal saat bundel diperkenalkan.
is_active – Menunjukkan apakah suatu bundel aktif atau tidak.
subscription_cost – Menyimpan harga yang diminta untuk bundel.

Dapatkah satu produk ditawarkan kepada pelanggan?

Ya. Dalam model data ini, satu produk dapat menjadi "bundel" sendiri. Tabel berikut menangani ini dan beberapa fungsi penting lainnya.

product_bundle_map table menyimpan daftar semua produk yang merupakan bagian dari bundel. Atributnya cukup jelas.

Tabel berikutnya, product_subscription , ikut bermain saat pelanggan berlangganan paket produk. Ini mencatat rincian pelanggan mana yang telah menulis ke bundel mana. Kolom dalam tabel ini adalah:

id – Kunci utama tabel.
user_account_id – Pengguna yang membeli bundel.
product_bundle_id – Paket produk yang dibeli oleh pengguna.
purchased_on – Tanggal pembelian.
subscription_start_date – Tanggal saat langganan dimulai. Perhatikan bahwa tanggal pembelian produk dan tanggal mulai berlangganan mungkin berbeda. Jadi, kami memiliki dua kolom berbeda untuk ini.
subscription_end_date – Kapan langganan akan berakhir.

Tabel terakhir, product_offering , terutama digunakan untuk pemasaran. Biasanya portal pekerjaan menganalisis aktivitas terbaru pengguna (baik pencari kerja maupun perekrut) dan kemudian memutuskan produk mana yang akan bermanfaat bagi pengguna mana. Mereka kemudian menggunakan email atau panggilan telepon untuk menghubungi pelanggan dengan penawaran yang dipilih. Kolom untuk tabel ini adalah:

id – Kunci utama tabel.
user_account_id – Pengguna yang ditargetkan oleh portal pekerjaan.
product_bundle_id – Paket produk yang telah dicocokkan oleh pemasar portal dengan pengguna.
is_email_notification_sent – Apakah email tentang penawaran produk telah dikirim.
last_email_sent_date – Kapan terakhir kali pengguna menerima email produk dari tim pemasaran. Sudah umum bagi pemasar untuk mengirim beberapa notifikasi ke pengguna, dan mengirim notifikasi lain secara berkala. Kolom ini menyimpan tanggal saat pemberitahuan terakhir dikirim.
is_call_briefing_done – Apakah pelanggan menerima panggilan telepon yang memberi tahu mereka tentang suatu produk.
last_call_date –Tanggal panggilan telepon terakhir. Mungkin ada beberapa panggilan (panggilan lanjutan) yang dilakukan ke pelanggan.

Peningkatan# 4:Manajemen Formulir Pra-Aplikasi

Pertanyaan untuk Dijawab: Bagaimana perekrut bisa mendapatkan formulir persetujuan khusus yang diisi oleh semua calon karyawan potensial?

Sering kali, pencari kerja menjawab pertanyaan spesifik saat mereka melamar pekerjaan. Ini biasanya mencakup hal-hal seperti menyetujui pemeriksaan latar belakang kriminal. Namun, ada berbagai jenis persetujuan lain yang mungkin diperlukan. Misalnya, pekerjaan di bidang pemasaran mungkin memerlukan banyak perjalanan; pekerjaan di outsourcing proses bisnis (BPO) mungkin mengharuskan karyawan untuk bekerja shift kuburan (yaitu larut malam). Ini dibahas dalam formulir pra-aplikasi.

Itu selalu yang terbaik untuk mendapatkan persetujuan ketika lamaran pekerjaan diajukan. Dengan cara ini, kandidat yang tidak memenuhi persyaratan ini tidak akan melamar pekerjaan tersebut.

Sebelum beralih ke model data, izinkan saya menyoroti beberapa fakta dasar tentang formulir persetujuan:

Sebuah postingan lowongan kerja dapat memiliki lebih dari satu formulir persetujuan.
Setiap formulir persetujuan memiliki berbagai pertanyaan yang terkait dengan berbagai bagian.
Pertanyaan dapat ditetapkan sebagai wajib atau opsional, tergantung pada bagaimana pertanyaan tersebut diberi tag dalam formulir. Sebuah pertanyaan dapat opsional dalam satu bentuk dan wajib dalam bentuk lain.
Setiap pertanyaan dapat dijawab sebagai (1) ya, (2) tidak, atau (3) tidak berlaku.
Semua jawaban akan direkam.

Saya telah menggunakan empat tabel berikut untuk mengelola pertanyaan dan formulir persetujuan. Yang pertama, question meja, berisi daftar pertanyaan. Ini memiliki atribut berikut:

id – Kunci utama tabel, yang memberikan nomor ID unik untuk setiap pertanyaan.
question_text – Menyimpan teks pertanyaan yang sebenarnya.
question_section_id – Bagian tempat pertanyaan muncul. (Misalnya, “Apakah Anda pernah bekerja dalam pengembangan perangkat lunak setidaknya selama lima tahun?” akan muncul di bagian “Pengalaman Kerja”.) Ini adalah kolom kunci asing yang dirujuk dari question_section meja.

question_section tabel menyimpan informasi bagian. Ini adalah cara untuk mengelompokkan pertanyaan yang terkait dengan topik yang sama. Selain id atribut, yang merupakan kunci utama untuk tabel, satu-satunya atribut adalah section_name , yang cukup jelas.

consent_questionnaire tabel memegang nama formulir persetujuan. Kedua atributnya juga cukup jelas.

ques_consent_questionnaire_map tabel adalah inti dari area subjek ini. Semua tabel lain di area subjek ini secara langsung atau tidak langsung terhubung dengannya. Tujuannya adalah untuk menyimpan daftar pertanyaan yang ditandai pada formulir persetujuan. Kolom dalam tabel ini adalah:

id – Kunci utama tabel ini.
consent_questionnaire_id – Nomor ID formulir persetujuan.
question_id – Nomor ID pertanyaan.
is_mandatory_optional – Menandakan apakah pertanyaan itu wajib atau opsional untuk formulir persetujuan yang diberikan. Sebuah pertanyaan dapat menjadi bagian dari beberapa formulir persetujuan, tetapi dapat menjadi wajib di beberapa dan opsional di orang lain. Itulah satu-satunya alasan di balik menyimpan kolom ini di sini daripada memasukkannya ke dalam question meja.

Beberapa tabel berikutnya kita akan membahas formulir persetujuan tag untuk setiap posting pekerjaan dan mencatat jawaban kandidat. Mari kita mulai dengan job_post_questionnaire tabel, yang menyimpan informasi tentang formulir persetujuan yang merupakan bagian dari postingan lowongan. Mungkin ada satu atau lebih formulir persetujuan yang ditandai dengan postingan pekerjaan. Kolom dalam tabel ini adalah:

id – Kunci utama tabel.
job_post_id – Menunjukkan posting pekerjaan mana yang ditandai dengan formulir persetujuan.
consent_questionnaire_id – Formulir persetujuan yang ditandai pada postingan pekerjaan.

Selanjutnya, appl_questionnaire_answer tabel log jawaban individu dari setiap pertanyaan formulir persetujuan yang diisi oleh pelamar. Kolom dalam tabel ini adalah:

job_post_activity_id – Kolom kunci asing yang dirujuk dari job_post_activity meja. Ini menyimpan informasi tentang kandidat yang telah menjawab pertanyaan.
quest_consent_quesnnaire_map_id – Kolom kunci asing lain yang dirujuk dari quest_consent_questionnaire_map meja. Ini menyimpan pertanyaan mana dari formulir persetujuan mana yang akan dijawab.
answer – Jawaban sebenarnya dari pelamar kerja. Saya menyimpannya sebagai kolom CHAR(1) karena semua pertanyaan dalam model kami dapat dijawab sebagai 'Ya' (jawaban ='Y'), 'Tidak' (jawaban ='N') atau 'Tidak Berlaku' (jawaban ='X').

Model Data Portal Pekerjaan Online Baru dan Lebih Baik

Anda dapat melihat model data lengkap di bawah ini.

Apa yang Akan Anda Tambahkan?

Dapatkah Anda memikirkan fitur lain untuk ditambahkan ke portal pekerjaan online kami? Silakan bagikan pandangan Anda di bagian komentar.