24 sebab perniagaan Malaysia menukar vendor perisian

Dari mana senarai ini datang?

Senarai ini menggabungkan apa yang diberitahu pemilik perniagaan kepada Macoin apabila mereka meminta kami menilai aplikasi, laman web atau sistem sedia ada, dengan laporan awam dan peraturan rasmi. Kami tidak menemui sebarang tinjauan di Malaysia yang menyusun sebab syarikat meninggalkan pembangun, jadi 24 tanda ini dikelompokkan mengikut jenis dan tidak disusun mengikut kedudukan.

Penghantaran lambat, susulan lambat dan tiada respons ialah aduan yang paling kerap kami dengar. Pelanggan telah berpindah ke Macoin daripada vendor lain atas sebab-sebab ini, dan pemilik semakin kerap menceritakan projek binaan AI yang ditinggalkan separuh siap. Itu ialah pemerhatian kami sendiri, bukan keputusan tinjauan.

Jika sesuatu tanda mempunyai bukti luar, kami menyebut sumber dan hadnya. Kebanyakan bukti itu bersifat antarabangsa, dan sebahagiannya datang daripada syarikat keselamatan yang menjual perkhidmatan berkaitan. Baca setiap angka sebagai petunjuk risiko, bukan sebagai ukuran projek di Malaysia. Satu minggu yang buruk tidak termasuk dalam senarai ini: setiap tanda menggambarkan corak yang berulang.

Masalah penghantaran apakah yang membuat pemilik meninggalkan vendor?

Pemilik meninggalkan vendor apabila tarikh terus berubah tanpa penjelasan, balasan mengambil masa berhari-hari, dan tiada orang teknikal yang boleh dihubungi. Kosnya jarang datang daripada satu keluaran yang lewat. Kosnya ialah kehilangan sebarang tarikh yang boleh dipercayai untuk merancang kakitangan, pemasaran atau pelancaran. Projek lewat adalah perkara biasa, jadi corak kelewatan tanpa penjelasan ialah tanda amaran.

Penghantaran lewat adalah biasa dalam industri ini. Laporan CHAOS 2020 oleh Standish Group, seperti yang diringkaskan oleh OpenCommons, mengklasifikasikan 31% projek sebagai berjaya, 50% sebagai mencabar dan 19% sebagai gagal. Angka itu bersifat antarabangsa dan meliputi projek semua saiz, jadi ia tidak banyak menggambarkan mana-mana satu vendor. Yang membezakan projek yang sihat ialah sama ada vendor menjelaskan kelewatan sebelum tarikh berlalu dan memberi tarikh baharu yang boleh anda semak.

• 1. Tarikh akhir terus berubahTarikh berubah lebih daripada sekali, dan setiap tarikh baharu datang tanpa sebab atau pelan yang disemak semula.
• 2. Susulan lambatSoalan mudah mengambil masa berhari-hari untuk dijawab, dan anda yang perlu mengejar setiap kali.
• 3. Mesej tidak lagi dibalasBalasan terhenti selepas deposit, atau selepas pelancaran, dan vendor hanya muncul semula apabila invois perlu dibayar.
• 4. Anda hanya boleh menghubungi jualanOrang yang menjual projek tidak dapat menjawab soalan teknikal, dan anda tidak pernah bertemu pembangun.
• 5. Caj muncul di luar sebut hargaKerja yang anda sangka sudah termasuk datang semula sebagai tambahan, kerana skop tidak pernah ditulis dengan jelas.
• 6. Projek kekal hampir siapIa sudah hampir siap selama berbulan-bulan, dan anda masih tidak dapat melihat versi yang berjalan untuk diuji.

Bilakah kualiti yang lemah menjadi sebab untuk bertukar?

Kualiti menjadi sebab untuk bertukar apabila setiap pembaikan mencetuskan kerosakan baharu, penggunaan sebenar merosakkan apa yang ditunjukkan dalam demo, atau perubahan kecil disebut harga seperti membina semula. Ini ialah tanda bahawa sistem sukar diubah dengan selamat. Kosnya kemudian jatuh pada setiap ciri akan datang, bukan hanya pada senarai pepijat semasa.

McKinsey menamakan ini hutang teknologi (tech debt). Dalam tinjauan 2020 terhadap 50 CIO di syarikat perkhidmatan kewangan dan teknologi yang besar, responden menganggarkan hutang teknologi pada 20 hingga 40 peratus daripada nilai aset teknologi mereka. Mereka juga berkata 10 hingga 20 peratus bajet untuk produk baharu dialihkan untuk menyelesaikannya. Perniagaan kecil mempunyai angka yang jauh lebih kecil, tetapi mekanismenya sama: wang yang sepatutnya untuk ciri baharu digunakan untuk mengatasi keputusan lama.

Sistem yang tidak boleh disambungkan kepada sesuatu yang diperlukan perniagaan sering menjadi saat pemilik bertindak. Sambungan e-Invois LHDN, pembayaran dan WhatsApp semuanya bergantung pada backend yang boleh diubah oleh seseorang. Penyemak kesediaan e-Invois kami menerangkan tarikh fasa mengikut perolehan.

• 7. Pepijat lama terus kembaliPembaikan pada satu skrin merosakkan skrin lain, yang biasanya bermakna tiada ujian berulang sebelum keluaran.
• 8. Demo berfungsi, penggunaan sebenar tidakSistem berfungsi dalam mesyuarat tetapi gagal dengan data sebenar, kakitangan sebenar atau apabila ramai orang menggunakannya serentak.
• 9. Ia menjadi perlahan apabila anda berkembangHalaman dan laporan menjadi lebih perlahan apabila pelanggan dan rekod bertambah, dan tiada siapa dapat menerangkan sebabnya.
• 10. Perubahan kecil disebut harga seperti membina semulaMedan atau laporan baharu menelan kos jauh lebih tinggi daripada dijangka, kerana satu perubahan menyentuh terlalu banyak tempat.
• 11. Integrasi baharu ditolakVendor berkata e-Invois, get laluan pembayaran atau sambungan perakaunan tidak boleh ditambah pada apa yang mereka bina.

Masalah pemilikan apakah yang memerangkap perniagaan kepada satu vendor?

Perniagaan terperangkap apabila vendor memegang kod sumber, domain, pengehosan atau akaun kedai aplikasi, dan hanya seorang yang memahami sistem. Untuk keluar, anda perlu membina semula. Baca kontrak anda sebelum menganggap anda memiliki apa-apa, kerana membayar untuk perisian tidak selalu menyelesaikan siapa pemilik kod.

Minta senarai bertulis bagi setiap akaun dan siapa yang mengawalnya: domain, DNS, pengehosan, pangkalan data, repositori kod sumber, Apple Developer, Google Play, get laluan pembayaran dan analitik. Jika jawapan lambat tiba, kelewatan itu sendiri ialah maklumat yang berguna. Untuk aplikasi, panduan serahan kami menyenaraikan apa yang perlu diminta.

Terma Macoin sendiri mengekalkan bahan sebagai milik kami sehingga bayaran akhir. Setelah bayaran penuh, anda menerima kod sumber, dokumentasi dan persediaan penggunaan (deployment), tanpa lesen berulang untuk fungsi teras yang anda bayar kami untuk bina. Minta mana-mana vendor menyatakan pendirian mereka dengan sejelas ini, dan dapatkan nasihat undang-undang jika pertikaian sudah bermula.

• 12. Vendor menyimpan kod sumberAnda membayar untuk sebuah sistem tetapi tidak mempunyai salinan kod, atau kontrak tidak menyebutnya.
• 13. Akaun atas nama vendorDomain, pengehosan atau penyenaraian kedai aplikasi milik vendor, jadi meninggalkan vendor boleh menyebabkan produk anda luar talian.
• 14. Hanya seorang yang memahaminyaTiada dokumentasi, dan sistem bergantung pada seorang pembangun yang terus ada.
• 15. Anda membayar sewa untuk apa yang anda tempahYuran lesen berulang meliputi fungsi yang anda bayar untuk dibina, dan kontrak tiada terma keluar.

Jurang keselamatan manakah yang patut membimbangkan pemilik perniagaan?

Berasa bimbang jika tiada siapa dapat memberitahu anda siapa yang boleh melihat rekod yang mana, sama ada sandaran pernah dipulihkan, atau apa yang berlaku selepas pelanggaran. Di bawah PDPA Malaysia, pengawal data mesti memaklumkan Pesuruhjaya dalam tempoh 72 jam bagi pelanggaran yang perlu dimaklumkan, jadi vendor yang tidak dapat menjawab membiarkan anda terdedah.

Peraturan pemberitahuan pelanggaran berkuat kuasa pada 1 Jun 2025. Ringkasan garis panduan oleh DLA Piper menyatakan Pesuruhjaya mesti dimaklumkan secepat yang praktikal dan dalam tempoh 72 jam, dan individu yang terjejas dalam tempoh tujuh hari selepas pemberitahuan itu, apabila pelanggaran menyebabkan atau berkemungkinan menyebabkan kemudaratan yang ketara. Pengawal juga mesti menghendaki pemprosesnya melalui kontrak untuk melaporkan pelanggaran dengan segera dan membantu. Jika vendor anda menghoskan data pelanggan anda, semak bahawa kontrak anda menyatakan perkara itu.

MyCERT merekodkan 195 laporan pelanggaran data pada suku pertama 2025, meningkat daripada 151 pada suku sebelumnya, seperti yang dilaporkan oleh The Star. Ini ialah maklumat am, bukan nasihat undang-undang. Panduan PDPA kami menerangkan maksud pindaan itu untuk sistem perniagaan.

• 16. Tiada siapa dapat menerangkan hak aksesKakitangan dan pelanggan mungkin dapat melihat rekod yang tidak sepatutnya, dan tiada siapa yang telah menyemaknya.
• 17. Sandaran tidak terbuktiSandaran mungkin wujud, tetapi tiada siapa pernah memulihkannya atau dapat mengatakan berapa banyak data yang akan anda hilang.
• 18. Tiada pelan pelanggaranVendor tidak dapat menyatakan bagaimana ia akan mengesan insiden, memaklumkan anda atau membantu anda memenuhi tarikh akhir PDPA.

Mengapakah aplikasi binaan AI menjadi sebab baharu untuk menukar vendor?

Alat AI membina demo yang berfungsi dengan cepat, tetapi pemilik sering mendapati peringkat akhir tiada: kawalan keselamatan, peraturan data yang betul, ujian dan proses keluaran yang selamat. Risikonya meningkat apabila tiada sesiapa dalam projek yang boleh membaca kod. Vendor yang menggunakan AI tidak mengapa. Vendor yang tidak dapat menyemak outputnya ialah masalahnya.

Tenzai meminta lima ejen pengekodan AI membina tiga aplikasi yang sama, dan SecurityWeek melaporkan 69 kerentanan merentasi 15 hasil, termasuk yang kritikal. Alat itu mengelakkan SQL injection dan cross-site scripting yang boleh dieksploitasi. Ia lemah pada logik kebenaran dan peraturan perniagaan, dan dalam hampir semua kes ia tidak mencuba kawalan keselamatan yang tidak diminta. Tenzai menjual ujian keselamatan, jadi baca ini sebagai satu ujian yang mempunyai kepentingan komersial.

Panduan kami tentang aplikasi binaan AI menerangkan apa yang perlu disemak sebelum pelanggan sebenar menggunakannya.

• 19. Binaan AI terhenti menjelang akhirPrototaip mengagumkan semua orang, tetapi log masuk, pembayaran, peranan atau penggunaan (deployment) tidak pernah disiapkan.
• 20. Kunci atau data terdedahKunci rahsia terletak dalam kod yang dimuat turun oleh pelayar, atau peraturan pangkalan data membenarkan orang luar membaca rekod.
• 21. Setiap pembaikan AI merosakkan sesuatu yang lainSetiap gesaan menyelesaikan satu masalah dan mencetuskan masalah lain, dan tiada siapa dapat menyemak perubahan itu.
• 22. AI boleh mencapai data langsungAlat atau ejen mempunyai akses terus ke pengeluaran, tanpa persekitaran ujian yang berasingan atau pemulihan yang telah diuji.

Apakah yang mendorong pemilik aplikasi mudah alih dan halaman pendaratan untuk bertukar?

Pemilik aplikasi mudah alih bertukar apabila aplikasi ketinggalan daripada peraturan kedai dan vendor sudah senyap. Pemilik halaman pendaratan bertukar apabila halaman dimuat perlahan, borang gagal atau tiada siapa dapat menunjukkan dari mana prospek datang. Kedua-dua masalah boleh tidak kelihatan selama berbulan-bulan, kerana pengguna sedia ada dan telefon pemilik sendiri mungkin tidak menunjukkannya.

Kedai sentiasa berubah. Google Play menyatakan aplikasi baharu dan kemas kini mesti menyasarkan Android 16 (API level 36) mulai 31 Ogos 2026, dan aplikasi sedia ada mesti menyasarkan sekurang-kurangnya Android 15 (API level 35) untuk kekal tersedia kepada pengguna baharu pada versi Android yang lebih baharu. Pengguna sedia ada mengekalkan aplikasi, sebab itu pemilik sering terlepas pandang masalah ini. Apple menyatakan aplikasi yang tidak dikemas kini selama tiga tahun, dengan muat turun yang sangat sedikit sepanjang 12 bulan bergulir, boleh ditandakan untuk dikeluarkan, dengan 90 hari untuk menghantar kemas kini. Aplikasi yang ranap semasa dibuka dikeluarkan serta-merta.

Kelajuan menjejaskan hasil jualan pada halaman pendaratan. Pada halaman kajian kes web.dev Google, Vodafone Itali melaporkan 8% lebih banyak jualan selepas menambah baik Largest Contentful Paint sebanyak 31%. Itu ialah keputusan satu syarikat besar, jadi anggap ia sebagai arah, bukan ramalan. Uji halaman anda sendiri pada telefon kelas pertengahan melalui data mudah alih, dan hantar borang itu sendiri.

• 23. Aplikasi ketinggalan daripada peraturan kedaiTiada siapa mengemas kini aplikasi, dan anda mungkin tidak tahu siapa yang memegang akaun kedai atau kunci penandatanganan.
• 24. Halaman pendaratan kehilangan prospekIa dimuat perlahan pada telefon, borang gagal tanpa makluman atau penjejakan tidak dapat menunjukkan iklan mana yang menghasilkan pertanyaan.

Patutkah anda membaiki hubungan, menukar vendor atau membina semula?

Cuba baiki hubungan dahulu jika kod itu milik anda dan vendor masih membalas. Tukar vendor jika balasan sudah terhenti atau kepercayaan sudah hilang. Bina semula hanya selepas penilaian menunjukkan sistem sedia ada tidak dapat menyokong keperluan perniagaan. Menulis semula adalah mahal, dan ia boleh menghilangkan peraturan yang dikendalikan dengan betul oleh sistem lama.

Hantar satu mesej bertulis yang menyenaraikan masalah, apa yang anda perlukan dan satu tarikh. Vendor yang patut dikekalkan akan membalas dengan pelan. Banyak hubungan pulih pada peringkat ini, dan pemulihan menelan kos lebih rendah daripada sebarang perpindahan.

Jika anda berpindah, kekalkan ciri yang berfungsi jika ia kukuh. Pilihan yang biasa ialah menstabilkan dan meneruskan, menggantikan satu modul pada satu masa, atau membina semula. Minta penilaian yang menerangkan risiko setiap satu, dan berhati-hati dengan mana-mana vendor baharu yang mengesyorkan pembinaan semula sebelum membaca kod.

Bagaimanakah anda menukar vendor perisian tanpa kehilangan sistem anda?

Dapatkan akses dahulu, kemudian bawa masuk pasukan baharu. Kumpulkan kod, akaun dan sandaran penuh sebelum anda mengumumkan apa-apa, dan teruskan membayar pengehosan. Kemudian dapatkan penilaian teknikal, persetujui skop bertulis, dan uji satu keluaran sebelum akses vendor yang keluar dibuang. Urutan penting, kerana akses yang hilang sukar dipulihkan.

Lakukan langkah-langkah ini mengikut urutan. Buang akses vendor lama hanya selepas pasukan baharu berjaya melakukan penggunaan (deployment), dan tukar setiap kata laluan dan kunci API sebaik sahaja mereka telah pergi. Semak kontrak anda dan sebarang wang yang masih terhutang terlebih dahulu, kerana pertikaian bayaran ialah sebab paling biasa serahan terhenti.

• Langkah 1: Baca kontrakSemak pemilikan, tempoh notis, bayaran tertunggak dan apa yang mesti diserahkan oleh vendor.
• Langkah 2: Senaraikan setiap akaunDomain, pengehosan, pangkalan data, repositori kod, kedai aplikasi, get laluan pembayaran dan perkhidmatan e-mel.
• Langkah 3: Dapatkan satu salinanDapatkan kod semasa dan sandaran pangkalan data, dan sahkan bahawa sandaran itu boleh dipulihkan.
• Langkah 4: Dapatkan penilaianMinta pasukan baharu membina dan menjalankan sistem daripada apa yang anda pegang, kemudian melaporkan risikonya.
• Langkah 5: Persetujui skop bertulisAsingkan pembaikan segera, penyelenggaraan dan ciri baharu, dengan semakan penerimaan untuk setiap satu.
• Langkah 6: Keluarkan sekali, kemudian tutup aksesSelepas satu keluaran yang diuji, buang akses vendor lama dan tukar semua kelayakan.

Mengapakah perniagaan di Puchong berpindah ke Macoin?

Macoin ialah syarikat perisian Malaysia yang berdaftar dengan pejabat di Bandar Puteri, Puchong, tempat pemilik boleh bertemu pasukan kami. Kami membalas pertanyaan dalam satu hari bekerja, menyebut harga berdasarkan skop bertulis dan menyerahkan kod sumber setelah bayaran penuh. Kami meletakkan harga untuk perniagaan Malaysia dan membina sistem untuk kegunaan komersial harian.

Kami tidak boleh menamakan pelanggan yang berpindah kepada kami, tetapi anda boleh menyemak apa yang bersifat awam: pendaftaran SSM kami (1545756-H), halaman pasukan kami, dan produk langsung seperti aplikasi Jian Pilates di App Store dan Google Play.

Kami mengambil alih sistem sedia ada selepas menilai kod dan persediaannya, dan kami tidak berjanji bahawa setiap pangkalan kod boleh disokong. WhatsApp kami apa yang anda ada dan apa yang tidak kena. Buang kata laluan dan data pelanggan daripada apa sahaja yang anda hantar. Jika vendor semasa anda masih pilihan yang lebih baik, kami akan memberitahu anda.