Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis

## Analisis Requirement Engineering pada Integrasi Pasca-Merger Sistem Biller Message Switching dan Aggregator
Fakhira Devina a , Teguh Raharjo b , Gladhi Guarddin c , Darell Hendry d , Oristania Wahyu Nabasya e a Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia, fakhira.devina11@ui.ac.id
b Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia, teguhr2000@gmail.com
c Ilmu Komputer, Fakultas Ilmu Komputer, Universitas Indonesia, adin@cs.ui.ac.id
d Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia, darell.hendry11@ui.ac.id
e Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia, oristania.wahyu11@ui.ac.id
Submitted: 24-11-2023, Reviewed: 05-12-2023, Accepted 02-01-2024 https://doi.org/10.47233/jteksis.v6i1.1119

## Abstract
Information  system  integration  is  one  of  the  crucial  activities  in  Post-Merger  Integration  (PMI).  Information  system integration must be carried out with careful planning so that the objectives of mergers and acquisitions can be achieved. Therefore, it is necessary to collect needs from each stakeholder to define the scope and approach of the integration that will  be  carried  out.  This  research  aims  to  understand  the  phenomenon  of  integration  project  management  of  the  Biller Message  Switching  and  Aggregator  system  happened  on  the  XYZ  Financial  Institution's  Post-Merger  Integration  (PMI) activity. The research method is analysis descriptive using the Post-merger Integration Specific Requirements Engineering model  to  describe  the  integration  process  in  3  phases,  namely  the  initial  assessment  phase,  decision  and  planning,  and execution. The research results show that all three entities’ systems have different system specifications and architecture. New system architecture decisions are determined from dependencies on the existing system and the number of billers served. The implementation of the new system is carried out based on the results of previous planning and involves billers to socialize the migration system services. This research provides input for the information systems integration process in the company's merger and acquisition process so that it is carried out systematically and structured. Future research can examine other factors that also influence the success of information system integration in post-merger integration activities. Keywords: Financial Service, Project Management, Billing System, Post-Merger Integration, Requirement Engineering

## Abstrak
Integrasi  sistem  informasi  adalah  salah  satu  aktivitas  krusial  dalam Post-Merger  Integration (PMI).  Integrasi  sistem informasi  harus  dilakukan  dengan  manajemen  proyek  yang  matang  agar  tujuan  merger  dan  akuisisi  dapat  dicapai.  Oleh karena itu, perlu dilakukan identifikasi requirement dari masing-masing stakeholder untuk menjelaskan scope dan approach integrasi  sistem  informasi  yang  akan  dilakukan.  Penelitian  ini bertujuan  untuk  memahami  fenomena  manajemen  proyek integrasi sistem Biller Message Switching dan Aggregator pada aktivitas Post-Merger Integration (PMI) Institusi Keuangan XYZ. Metode penelitian yang digunakan adalah analisis deskriptif  dengan menggunakan model Post-merger Integration Specific Requirements Engineering untuk memetakan proses integrasi dalam 3 fase yaitu fase initial assessment , decision and planning , dan execution . Hasil penelitian menunjukkan bahwa ketiga entitas merger memiliki spesifikasi dan arsitektur sistem yang berbeda. Keputusan arsitektur sistem baru ditentukan dari dependensi terhadap sistem as-is dan jumlah biller yang  dilayani.  Eksekusi  implementasi  sistem  baru  dilakukan  berdasarkan  hasil  perencanaan  sebelumnya  dan  melibatkan biller untuk sosialisasi migrasi sistem layanan. Penelitian ini memberikan masukan untuk proses integrasi sistem informasi dalam proses merger dan akuisisi perusahaan agar dilakukan secara sistematis dan terstruktur. Penelitian selanjutnya dapat meneliti faktor-faktor lainnya yang juga berpengaruh pada kesuksesan integrasi sistem informasi pada aktivitas post-merger integration Keywords: Layanan Keuangan , Manajemen Proyek , Billing System, Post-Merger Integration, Requirement Engineering
This work is licensed under Creative Commons Attribution License 4.0 CC-BY International license

## PENDAHULUAN
Merger  dan  akuisisi  merupakan  praktik  yang bertujuan untuk menggabungkan serta meningkatkan  jumlah  konsumen,  memperluas proses  bisnis,  mengefisiensi  sumber  daya,  dan mengurangi  persaingan  [1]  [2]. Pada  sektor keuangan di Indonesia, merger dan akuisisi pernah dilakukan  oleh  Bank  Mandiri  yang  dibentuk  atas restrukturisasi  empat  bank  nasional  yaitu  Bank
Bumi  Daya,  Bank  Dagang  Negara,  Bank  Ekspor Impor Indonesia dan Bank Pembangunan Indonesia. Merger empat bank nasional ini didorong oleh krisis moneter  yang  terjadi  pada  tahun  1997-1998  dan dilakukan  sebagai  cara  untuk  menstabilisasikan ekonomi negara [3].
Merger  dan  akuisisi  merupakan  kegiatan  yang kompleks [4]. Hal ini didukung dengan fakta bahwa proses merger Bank Mandiri pada saat itu berjalan
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
lambat  dan  mengeluarkan  biaya  yang  tidak  sedikit [5]. Secara umum, diketahui bahwa 70% merger dan akuisisi yang dilakukan perusahaan gagal mencapai tujuannya [6]. Salah satu tantangannya adalah Post-
Merger
Integration
(PMI), yaitu proses
mengintegrasikan  entitas-entitas  merger  dari  segi organisasional, kultural, operasional bisnis, pengukuran  performa,  maupun  standar  dan  sistem IS/IT.
Salah  satu  aspek  yang  perlu  diperhatikan  pada PMI  adalah  pengintegrasian  sistem  informasi entitas-entitas  yang  terlibat  pada  merger.  Dalam mengelola  proyek  TI,  perlu  dilakukan  identifikasi requirement proyek  dan  mengakomodir  kebutuhan tiap stakeholder untuk  mengetahui  scope  dan approach integrasi sistem yang perlu dilakukan  [4]
[7]  [8].  Besarnya  perbedaan  standar  antar  sistem informasi  berdampak  pada  besarnya  kompleksitas kegiatan PMI. Jika perbedaan standar tersebut tidak diakomodir  dengan  baik,  maka  dapat berimplikasi pada kegagalan merger [4] [8] [9]. Oleh karena itu, proses  PMI  harus  dilakukan  dengan project management yang  baik  agar  tujuan  merger  dan akuisisi dapat dicapai dan meminimalkan perubahan scope,  yang  dapat  menyebabkan  pembengkakan biaya dan keterlambatan integrasi [4] [8] [10]. Penelitian sebelumnya telah membahas mengenai pentingnya  proses  identifikasi requirement pada proses  integrasi  sistem  informasi.  Penelitian  [11] menjelaskan pentingnya proses requirement engineering sistem  informasi  pada  aktivitas  PMI. Requirements  engineering dapat  membantu  proses PMI yang kompleks dengan menyediakan pendekatan  yang  sistematis  dan  terstruktur  untuk mengidentifikasi, menganalisis, mendokumentasikan,  memvalidasi,  dan  mengelola requirement PMI.  Penelitian  ini  berhasil  membuat model Post-merger Integration Specific
Requirements Engineering yang berfokus pada fase requirement  gathering pada  aktivitas  integrasi sistem  informasi  organisasi  dalam  PMI.  Model  ini juga menekankan pentingnya knowledge management dalam  PMI  agar  seluruh  pihak  yang terlibat  dalam  PMI  dapat  mengakses  dan menggunakannya untuk pengambilan keputusan [8] [11][12].  Hal  ini  membantu  dalam  pembuatan rencana integrasi yang didasarkan pada pemahaman yang  jelas  mengenai  requirement,  sehingga mengurangi resiko dan kegagalan pada PMI.
Model  ini  terdiri  dari  3  fase  yaitu initial assessment , decision  and  planning ,  dan execution . Initial assessment berfokus pada identifikasi tujuan PMI dan pengumpulan informasi mengenai masing- masing entitas yang terlibat merger. Informasi yang dikumpulkan  pada  fase  ini  termasuk  proses  bisnis,
konsumen, kompetitor, kekuatan, kelemahan maupun  sistem  informasi  yang  digunakan  masing- masing  entitas.  Informasi  tersebut  kemudian didokumentasikan  dan integration  scope dapat ditentukan  dengan  menentukan  aktivitas-aktivitas yang perlu dilakukan dalam proses integrasi. Hasil akhir  dari  fase  ini  adalah  dokumentasi  seluruh informasi  untuk  digunakan  pada  fase  berikutnya. Fase decision  and  plan berfokus  pada  pembuatan PMI decision berdasarkan  analisis  dokumentasi informasi  sehingga  dihasilkan  rancangan  arsitektur sistem  informasi to-be .  Fase execution berfokus pada  eksekusi  PMI decision yang  dibuat  pada  fase sebelumnya. Rancangan arsitektur kemudian didefinisikan kembali pada change plan dan sistem informasi  diimplementasi  sesuai change  plan tersebut.  Proses  eksekusi,  evaluasi,  maupun perubahan change  plan selama  implementasi  juga didokumentasikan.
Penelitian ini bertujuan untuk melakukan analisis keberhasilan  manajemen  proyek  integrasi  sistem informasi  pada Post  Merger  Integration institusi keuangan yaitu sistem Biller Message Switching dan Aggregator . Subjek case study merupakan institusi keuangan  yang  dibentuk  dari  hasil  merger  tiga layanan  keuangan.  Analisis  dilakukan  dengan mengacu  pada  model Post-merger  Integration Specific  Requirements  Engineering yang  berfokus pada  fase  pengumpulan requirement pada  sistem organisasi hasil merger.
Biller  Switching  Message  and  Aggregator ,  atau yang  lebih  banyak  dikenal  dengan billing  system , adalah sistem yang digunakan perusahaan, atau yang disebut biller ,  untuk  membuat  tagihan  atau  faktur untuk  produk  atau  layanan  yang  telah  digunakan oleh  pelanggan.  Sistem  ini  dapat  digunakan  oleh biller untuk menghitung jumlah tagihan, mengirimkan tagihan ke pelanggan, dan mengelola pembayaran  dari  pelanggan  [13]. Billing  system dapat  memberikan  meningkatkan  efisiensi  serta objektivitas bagi perusahaan dalam proses penagihan,  seperti  efisiensi  alokasi  sumber  daya karena  sistem  penagihan  dapat  mengotomatiskan sebagian besar tugas penagihan, seperti pembuatan dan pengiriman tagihan, serta pengelolaan pembayaran [14] [15] .

## METODE PENELITIAN
Pada   bagian   ini   akan   dijelaskan   mengenai metode   yang digunakan dalam penelitian.  Bagian ini  akan  dibagi  menjadi  jenis  penelitian,  subjek penelitian,  teknik  pengumpulan  data,  dan  teknik analisis data.
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
2.1. Jenis Penelitian Jenis  penelitian  yang  digunakan  dalam penelitian  ini  adalah  penelitian case  study . Penelitian case  study digunakan  untuk  melakukan evaluasi  pada  fenomena  merger  yang  telah  terjadi sehingga  dapat  diketahui  strategi  selama  proses initial  assessment , decision  and  planning ,  serta execution .
2.2 Subjek Penelitian Penelitian  ini  dilaksanakan  pada  salah  satu proyek merger sistem Institusi Keuangan XYZ yang merupakan institusi keuangan hasil merger layanan keuangan  A,  layanan  keuangan  B,  dan  layanan keuangan  C  yang  terjadi  di  Indonesia.  Pemilihan subjek  didasarkan  karena  keberhasilan  pihak developer , dalam studi kasus ini adalah third party penyedia  sistem biller  message  switching dan aggregator ,  dalam  melakukan  integrasi  sistem Institusi  Keuangan  XYZ  yang  merupakan  hasil integrasi dari  sistem Biller Message Switching  and Agregator layanan  keuangan  A,  layanan  keuangan B, dan layanan keuangan C.
2.3 Teknik Pengumpulan Data Data  penelitian  diperoleh  dengan  melakukan semi-structured interview kepada ketua vendor tim pengembang dan salah satu anggota tim pengembang  sistem biller  message  switching dan
aggregator untuk  mendapatkan  detail  dari  proses pada fase initial assessment , decision and planning , execution integrasi sistem biller message switching dan aggregator .  Pertanyaan interview disusun berdasarkan model Post-merger Integration Specific Requirements  Engineering untuk  mendapatkan detail output tiap  fase  PMI  serta  aktivitas  apa  saja yang  dilakukan  pada  tiap  fasenya.  Selain menggunakan semi-structured  interview ,  penulis juga  mempelajari  dokumen  terkait  pengembangan sistem biller  message  switching dan aggregator untuk memahami kompleksitas integrasi sistem dan bagaimana  tim  vendor  pengembang  membangun sistem baru yang dapat mengintegrasikan tiga sistem existing dari masing-masing layanan keuangan yang terlibat merger.
2.4 Teknik Analisis Data Analisis data dilakukan menggunakan metode deskriptif  kualitatif.  Penelitian  deskriptif  kualitatif merupakan  jenis  desain  penelitian  kualitatif  yang bertujuan untuk memberikan rangkuman menyeluruh  mengenai  peristiwa-peristiwa  tertentu yang  dialami  oleh  individu  atau  kelompok  [16]. Pembahasan  analisis  akan  menjelaskan  proses requirement engineering PMI seperti pada Gambar 1 sesuai dengan 3 fase pada penelitian [11] yaitu fase initial assessment , decision  and  planning ,  serta execution .
Gambar 1. Model Post-merger Integration Specific Requirements Engineering Sumber: [11]

## HASIL DAN PEMBAHASAN
Bagian pembahasan akan membahas mengenai cakupan  manajemen  proyek  integrasi  sistem biller message  switching dan aggregator pada  merger Institusi Keuangan XYZ. Bagian ini akan membahas mengenai  manajemen  proyek  secara  general, kemudian  membahas  detail  jalannya  proyek  studi kasus dalam tiga bagian sesuai dengan model Post- merger Integration Specific Requirements
Engineering yaitu initial  assessment , decision  and planning , dan execution.

## 3.1 Manajemen Proyek
Manajemen proyek adalah penerapan pengetahuan,  keterampilan,  alat,  dan  teknik  pada aktivitas  proyek  untuk  memenuhi  persyaratan proyek  [8].  Dalam  manajemen  proyek,  digunakan pedoman  yang  merujuk  pada The  Project Management  Body  of  Knowledge  (PMBOK) .
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
PMBOK berfungsi sebagai panduan dasar di bidang manajemen proyek, mencakup berbagai proses dan praktik  yang  dianggap  penting  untuk  jalannya proyek  yang  efektif  [8].  PMBOK  memberikan pendekatan  komprehensif  dalam  mengintegrasikan berbagai aspek manajemen proyek dengan mendefinisikan  lima process  group dan  sepuluh knowledge area yang dapat dilihat pada Gambar 2.
Process  group yang  didefinisikan  pada  PMBOK meliputi Initiating, Planning, Executing, Monitoring and Controlling, dan Closing .
Knowledge  area yang  dibahas  pada  PMBOK meliputi Integration,  Scope,  Schedule,  Cost,
Quality, Resource, Communications, Risk,
Procurement,  dan  Stakeholder  Management [8]. Standar ini merupakan metodologi yang menekankan  pentingnya  menyeimbangkan  proyek dari segi scope , kualitas, jadwal, anggaran, sumber daya, dan risiko [8].
Gambar 2. Keterkaitan Komponen-Komponen PMBOK dalam Proyek
Sumber: [8]
Analisis requirement merupakan aktivitas yang tidak dapat dipisahkan dari manajemen proyek. Hal ini  terbukti  dari  keterkaitan  antara knowledge  area PMBOK dengan kegiatan requirement engineering . Dalam Project  Integration  Management ,  dibuat project  charter dan  rencana  manajemen  proyek untuk  memastikan  tujuan  proyek  selaras  dengan ekspektasi stakeholder [8].  Keduanya  merupakan dasar  dari  jalannya  proyek  dan  meliputi  aktivitas requirement engineering untuk  melakukan  analisis requirement yang  efektif.  Pada Project  Scope Management dilakukan requirement  gathering dan scope  definition untuk  mendapatkan  tujuan  proyek yang  jelas  dan  dapat  dicapai  [8].  Pengumpulan requirement yang  akurat  dan  pendefinisian scope proyek sangat penting dalam membentuk trajektori proyek  dan  memastikan  proyek  memiliki outcome yang  sesuai  [8]. Project  Stakeholder  Management merupakan knowledge area yang meliputi
identifikasi  dan  keterlibatan stakeholder untuk mengetahui kebutuhan dan harapan masing-masing stakeholder [8].  Kebutuhan  dan  harapan  tersebut kemudian menjadi pertimbangan dalam merancang requirement [8].  Keterlibatan  berkelanjutan  dan komunikasi yang efektif dengan stakeholder proyek memastikan  bahwa requirement proyek  sesuai dengan kebutuhan dan harapan mereka [8]. Project Quality  Management dalam  panduan  PMBOK memastikan  bahwa  proyek  memenuhi  standar kualitas  yang  diperlukan  [8]. Project  Quality Management memastikan bahwa  requirement yang dibuat  berkualitas  tinggi,  lengkap,  dan  tepat mencerminkan  kebutuhan stakeholder [8]. Project Risk  Management adalah knowledge  area yang melibatkan  identifikasi  dan  analisis  risiko  yang dapat  terjadi  [8].  Dengan  identifikasi  risiko, pengembangan rencana proyek dapat lebih kuat dan realistis dan mengurangi masalah yang dapat terjadi selama  project  dijalankan  maupun  setelah  system selesai  dibuat.  Komunikasi  yang  efektif,  seperti yang  dijelaskan  pada knowledge  area Project Communication Management , sangat penting dalam requirement engineering [8]. Komunikasi yang jelas dan  efisien  membantu  dalam  mengumpulkan  dan memvalidasi requirement dengan  tepat,  dan memastikan semua pemangku kepentingan memiliki pemahaman yang sama mengenai  proyek yang dilaksanakan [8].

## 3.2 Initial Assessment
Institusi  keuangan  XYZ  dibentuk  dari  hasil merger  Layanan  Keuangan  A,  Layanan  Keuangan B,  dan  Layanan  Keuangan  C.  Sebelumnya,  ketiga layanan  keuangan  tersebut  hanya  bagian  dari institusi  keuangan  yang  lebih  besar.  Karena  ketiga layanan  keuangan  tersebut  hanya  berfokus  pada spesifik  target  konsumen,  sehingga  tujuan  dari merger  institusi  keuangan  XYZ  adalah  untuk meningkatkan  kekuatan  saing  institusi  keuangan yang  berfokus  pada  target  konsumen  tersebut. Integrasi  sistem  perlu  dilakukan  karena  pada awalnya masing-masing institusi keuangan memiliki  sistem Biller  Message  Switching dan Aggregator masing-masing  dengan  spesifikasi  dan biller yang  berbeda-beda.  Tujuan  merger  sistem Biller  Message  Switching dan Aggregator pada proses post-merger  integration Institusi  Keuangan XYZ  adalah  untuk  menyatukan  sistem  yang awalnya  berdiri  masing-masing  pada  Layanan Keuangan  A,  Layanan  Keuangan  B,  dan  Layanan Keuangan  C  tanpa  mengurangi  kapabilitas  dari masing-masing sistem.
Pada  Layanan  Keuangan  A,  sistem Biller Message Switching dan Aggregator yang digunakan
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
adalah  sistem  yang  dibeli  dari third-party secara whitelabel .  Penyedia  sistem  tidak  hanya  menjual sistemnya tetapi juga memberikan layanan bantuan untuk  penggunaan  sistem  tersebut.  Sistem Biller Message  Switching dan Aggregator milik  Layanan Keuangan A menyediakan web portal dan juga API yang dapat dimanfaatkan oleh para biller . Terdapat 37  fitur  yang  disediakan  oleh Biller  Message Switching dan Aggregator layanan  keuangan  A. Untuk biller yang tidak memiliki sistem atau sumber daya IT sendiri, layanan keuangan A menyediakan web  portal yang  dapat  diakses  para biller tanpa harus membangun sistem IT nya sendiri. Web portal Biller  Message  Switching dan Aggregator layanan keuangan A terkoneksi dengan 37 fitur yang tersedia pada  API.  Gambar  3  menggambarkan  arsitektur sistem Biller  Message  Switching dan Aggregator milik Layanan Keuangan A.

## Gambar 3. Arsitektur Sistem Layanan Keuangan A
Layanan  Keuangan  B  menggunakan  sistem Biller  Message  Switching dan Aggregator yang terintegrasi  dengan  keseluruhan  institusi  keuangan yang  membawahinya.  Sistem Biller  Message Switching dan Aggregator Institusi  Keuangan  B adalah  sistem  yang  dibeli  dari  tim  pengembang eksternal  yang  kemudian  di- whitelabel menjadi milik  Institusi  Keuangan  B.  Sistem  memiliki  4 fungsi  general  yang  dapat  digunakan  oleh  para biller .  Layanan  Keuangan  C  menggunakan  sistem informasi  internal  yang  diimplementasi  oleh pengembang internal  Institusi Keuangan C. Sistem informasi Layanan Keuangan C terintegrasi dengan keseluruhan institusi
keuangan
yang
membawahinya.  Sistem Biller  Message  Switching dan  Aggregator melayani  fungsi  general  pada switching system dan melayani beberapa kustomisasi  yang  diminta  oleh  para biller .  Dengan menggunakan  sistem  yang  dibangun  oleh  pegawai internal,  Layanan  Keuangan  C  dapat  memberikan biaya transaksi yang lebih terjangkau. Gambar 4 dan
Gambar  5  menggambarkan  arsitektur  sistem Biller Message  Switching dan Aggregator milik  Institusi Keuangan B dan Institusi Keuangan C.
Gambar 4. Arsitektur Sistem Institusi Keuangan B
Gambar 5. Arsitektur Sistem Institusi Keuangan C
Pada  fase initial  assessment ,  ketiga  layanan keuangan  memberikan  dokumentasi  sistem Biller Message Switching dan Aggregator untuk dijadikan pertimbangan dalam integrasi sistem Biller Message Switching dan Aggregator institusi keuangan XYZ. Terdapat total 1200 biller yang harus dilayani oleh sistem Biller  Message  Switching dan Aggregator Institusi  Keuangan  XYZ.  Dari  jumlah biller tersebut,  41% biller dilayani  oleh  Layanan Keuangan  A,  34% biller dilayani  oleh  Layanan Keuangan  B,  dan  25% biller lainnya  dilayani  oleh Layanan  Keuangan  C.  Tabel  1  menjelaskan kelebihan  dan  kekurangan  masing-masing Biller Message  Switching dan Aggregator layanan keuangan yang terlibat merger.
Tabel 1. Kelebihan dan Kekurangan
Layanan Keuangan A Layanan Keuangan B Layanan Keuangan C Persentase Biller 41% 34% 25%
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
Layanan Keuangan A Layanan Keuangan B Layanan Keuangan C Kelebihan Memiliki 37 fungsi API yang general - Biaya transaksi 0 Kekurangan  Tidak dapat mengakomodir tingkat kustomisasi Layanan keuangan C Hanya memiliki 4 fungsi, tidak dapat mengakomodir Layanan keuangan C & Layanan keuangan A Terlalu banyak kustomisasi, sulit untuk dilakukan integrasi

## 3.3 Decision and Planning
Dari  informasi  yang  sudah  didapatkan  dari masing-masing layanan keuangan, dibuat perencanaan  arsitektur  dari  sistem  yang  baru. Terdapat  2  pilihan  arsitektur  untuk  institusi keuangan  XYZ.  Pilihan  pertama  adalah  untuk duplikasi  masing-masing  sistem Biller  Message Switching dan Aggregator Layanan  Keuangan  A, Layanan Keuangan B, dan Layanan Keuangan C ke sistem  Institusi  Keuangan  XYZ.  Pilihan  ini  secara teknis  lebih  mudah  diimplementasikan  karena integrasi sistem hanya membutuhkan duplikasi dari
sistem  yang  sudah  ada.  Dari  sisi  lain,  pilihan arsitektur  ini  sulit  dilakukan  karena  sistem Biller Message  Switching dan Aggregator Layanan
Keuangan  B  Layanan  Keuangan  C  terikat  ke keseluruhan institusi keuangan sebelumnya. Sehingga,  dipilih  pilihan  arsitektur  kedua  yaitu dengan melakukan implementasi direct .
Implementasi direct
dilakukan dengan menggunakan web  portal dan  API  milik  sistem Layanan Keuangan A dan melakukan implementasi tambahan  untuk  menyesuaikan  spesifikasi  sistem Biller Message Switching dan Aggregator Layanan Keuangan  B  dan  Layanan  Keuangan  C.  Sistem Layanan  Keuangan  A  dipilih  karena  Layanan Keuangan A memiliki biller yang lebih banyak dari Layanan Keuangan B dan C, Sistem Biller Message Switching  dan  Aggregator tidak  terikat  oleh keseluruhan institusi keuangan, lebih ekonomis dari sisi biller ,  serta  pihak third  party menyanggupi untuk  melakukan  integrasi  sistem.  Gambar  6 merupakan  hasil  akhir  arsitektur  sistem Biller Message  Switching dan Aggregator institusi keuangan XYZ. Fungsi Layanan Keuangan B yang diimplementasi  pada  API  milik  sistem  Layanan Keuangan  A  dikategorikan  sebagai  Tipe  2,  dan fungsi  yang  dimiliki  Layanan  Keuangan  C dikategorikan  sebagai  Tipe  3.  Pemisahan  tipe  ini dilakukan agar perubahan yang perlu dilakukan dari sisi biller dapat diminimalisir.
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
Gambar 6. Final Arsitektur to-be

## 3.4 Execution
Eksekusi integrasi dan migrasi sistem ditargetkan selesai dalam waktu tujuh bulan. Target tersebut  didasarkan  oleh  waktu  tutup  sistem Layanan  Keuangan  B  dan  sistem  Layanan Keuangan  C  yang  telah  disepakati  sebelumnya. Eksekusi  integrasi  dimulai  dari  menyiapkan environment development untuk  implementasi fungsi  Tipe  2  dan  Tipe  3.  Setelah  implementasi fungsi Tipe 2 dan Tipe 3 selesai, dilakukan testing internal untuk  memastikan  hasil  implementasi sudah  sesuai.  Fase  integrasi  kemudian  dilanjutkan dengan  fase  migrasi  data  dan environment .  Fase migrasi  dilakukan  dengan  melibatkan  sekitar  20% dari total biller yang terkoneksi secara point-to-host (P2H)  untuk  mengikuti training migrasi  sistem. Training dilakukan dengan pihak biller satu persatu dengan satu orang dari tim developer migrasi sistem. Training migrasi sistem bertujuan untuk menginformasikan perubahan yang perlu dilakukan dari sisi biller . Banyaknya jumlah biller yang perlu dihubungi membuat proses migrasi lebih kompleks dan resiko yang lebih tinggi. Hal ini membuat target migrasi  sistem  dimajukan  satu  bulan  untuk menjamin  segala  bentuk  kesalahan  maupun error
dapat dideteksi dan ditangani sebelum waktu tutup sistem Layanan Keuangan B dan C.
Eksekusi  migrasi  dilakukan  dengan membuat timeplan dan standard  operational procedure untuk  menghubungi  pihak biller . Eksekusi migrasi dilakukan selama kurang dari 3 bulan  oleh  5 trainer .  Setiap trainer memiliki tanggung jawab untuk melakukan training kepada 10  biller  per  minggu.  Gambar  7  merupakan timeplan yang  digunakan  tim  operasional  dalam menghubungi  para biller .  Pihak  perwakilan Layanan  Keuangan  A  membuat  grup  WhatsApp dengan biller yang  akan  mengikuti training maksimal  7  hari  sebelum  waktu training yang sudah  ditentukan.  Pihak trainer dari  tim operasional akan mengkonfirmasi kembali kesediaan  tim biller untuk  mengikuti training 7 hari sebelum waktu training yang ditentukan. Jika pihak biller sudah  mengkonfirmasi  dapat mengikuti training ,  maka  tim trainer akan memberikan bahan materi training , video tutorial , username ,  dan password yang  dapat  digunakan untuk  sesi tutorial dalam training .  Jika  pihak biller tidak  dapat  dihubungi  atau  tidak  dapat mengikuti training pada jadwal yang ditentukan, maka akan dilakukan reschedule jadwal training dan menghubungi biller lainnya untuk
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
menanyakan kesediaan memajukan jadwal training .  Dua  hari  sebelum training dilakukan, pihak trainer akan  memberikan  link Zoom Meeting yang akan digunakan, serta mengkonfirmasi  ke developer untuk  melakukan whitelist pihak biller di environment  live sistem Biller  Message  Switching dan Aggregator .  Pada hari  H training ,  pihak trainer akan  menjelaskan cara  menggunakan  dan  migrasi  ke  sistem Biller Message  Switching  dan  Aggregator yang  baru. Training juga  mencakup  sesi tutorial dengan menggunakan  data dummy untuk  mencoba
menggunakan  sistem Biller  Message  Switching dan Aggregator .
Gambar 7. Timeplan migrasi sistem SIMPULAN Proses  merger  sistem Biller  Message Switching dan Aggregator institusi keuangan XYZ dilakukan  dengan  mengumpulkan  dokumentasi dan  memahami  sistem  dari  masing-masing layanan keuangan yang terlibat merger. Hasil dari analisis  masing-masing  sistem  tersebut  menjadi dasar dalam pembuatan proposal arsitektur to-be yang  akan  dibuat  untuk  institusi  keuangan  XYZ hasil  merger  dan  menjadi  dasar  pemilihan proposal  arsitektur  yang  akan  dikembangkan. Eksekusi  merger  sistem  dilakukan  dengan mempertimbangkan waktu yang telah ditentukan oleh pihak layanan keuangan dan resiko kesalahan yang  dapat  terjadi  sebelum  waktu  target live sistem.  Migrasi  sistem  dilakukan  dengan keterlibatan biller untuk memberikan pengarahan mengenai perubahan sistem dan cara penggunaannya.  Penelitian  selanjutnya  dapat meneliti faktor-faktor lainnya yang juga berpengaruh  pada  kesuksesan  integrasi  sistem informasi pada aktivitas post-merger integration .

## DAFTAR PUSTAKA
[1] L. Renneboog and C. Vansteenkiste, "Failure and success in  mergers  and  acquisitions," Journal  of  Corporate Finance, no. 58, pp. 650-699, 2019.
[2]   A.-S. Thelisson, "Managing failure in the merger process: evidence from a case study," Journal of Business Strategy, 2019.
[3]   A.  J.  Hatta,  S.  P.  Emilia  and  Junaidi,  "ANALYSIS  OF THE  EFFECT  OF  BANK  SOUNDNESS  AND MACROECONOMICS ON FINANCIAL DISTRESS IN CONVENTIONAL COMMERCIAL BANKS," International Journal of Business, Education, Humanitiesand SocialSciences, vol. 3, pp. 27-32, 2020.
[4]   K. Lace and M. Kirikova, "Importance of IS in Mergers and Acquisitions," PoEM Workshops, pp. 127-132, 2020.
[5]   H. Alamsyah, "Restrukturisasi Perbankan Dan Dampaknya Terhadap Pemulihan Kegiatan Ekonomi Dan Pengendalian  Moneter," Buletin  Ekonomi  Moneter  dan Perbankan, vol. 1, no. 3, pp. 121-145, 1998.
[6]   J. Bodner and L. Capron, "Post-merger integration," Journal of Organization Design, vol. 7, no. 3, 2018.
[7]   L. Hernando, "PERANCANGAN SISTEM INFORMASI KEUANGAN  PADA  UNIT  KOPERASI  SIMPAN PINJAM," Jurnal Teknologi Dan Sistem Informasi Bisnis (Jteksis) , vol. 2, no. 1, pp. 22-32, 2020.
Jurnal Teknologi Dan Sistem Informasi Bisnis Vol. 6 No. 1 Januari 2024 Hal. 135-143 http://jurnal.unidha.ac.id/index.php/jteksis
[8]   Project Management Institute, A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project
Management, Project Management Institute, 2021.
[9]   J.  H.  Oh  and  W.  J.  Johnston,  "How  post-merger integration duration affects merger outcomes," Journal of Business & Industrial Marketing, vol. 36, no. 5, pp. 807- 820, 2021.
[10]  R. D. Asworowati, A. Wuryanto, D. Mustomi and R. P. Simangunsong, "Perancangan Sistem Informasi
Kepegawaian  Berbasis  Web  Pada  Desa  Muktiwari," Jurnal Teknologi Dan Sistem Informasi Bisnis, vol. 5, no. 2, pp. 120-125, 2023.
[11]  K.  Lace  and  M.  Kirikova,  "Post-merger  Integration Specific Requirements Engineering Model," in Perspectives  in  Business  Informatics  Research:  20th International  Conference  on  Business  Informatics Research, BIR 2021 , Vienna, Austria, 2021.
[12]  Adriyendi and Y. Melia, "KNOWLEDGE MANAGEMENT PADADIGITAL NOMADISM
UNTUKPENINGKATAN  GIG  ECONOMY," Jurnal Teknologi Dan Sistem Informasi Bisnis, vol. 4, no. 2, pp.
276-284, 2022.
[13]  B. Ayyoub, B. Zahran, M. A. Nisirat, F. M. S. Al-Taweel and  M.  A.  Khawaldah,  "A  proposed  cloud-based  billers hub  using  secured  e-payments  system," TELKOMNIKA (Telecommunication Computing Electronics and Control), vol. 1, no. 19, pp. 339-348, 2021.
[14]  H. A. Ibrahim, B. M. Nossier and M. G. Darwish, "Billing system  for  Internet  service  provider  (ISP)," 11th  IEEE Mediterranean  Electrotechnical  Conference  (IEEE  Cat. No.02CH37379), pp. 260-268a, 2002.
[15]  K.  W.  Park,  S.  K.  Park,  J.  S.  Han  and  K.  H.  Park,
"THEMIS:  Towards  Mutually  Verifiable  Billing Transactions  in  the  Cloud  Computing  Environment,"  in 2010  IEEE  3rd  International  Conference  on  Cloud
Computing , 2010.
[16]  V.  A.  Lambert  and  C.  E.  Lambert,  "Qualitative Descriptive  Research:  An  Acceptable  Design," Pacific Rim international journal of nursing research, vol. 4, no. 16, pp. 255-256, 2012.
[17]  J. Hedman and S. Sarker, "Information system integration in  mergers  and  acquisitions:  research  ahead," European Journal of  Information  Systems, vol. 24, no. 2,  pp. 117- 120, 2015.
[18]  Y.  Huang  and  B.  Wang,  "Central  Billing  System  for Personal  Bills," International  journal  of  innovation, management and technology, 2014.
[19]  S. Maitra, "Embedded Energy Meter- A New Concept To Measure The Energy Consumed By A Consumer And To Pay The Bill," in 2008 Joint International Conference on Power  System  Technology  and  IEEE  Power  India Conference , India, 2008.
[20]  W.  Angko,  "Innovation  in  Bank  Payment  Systems  and Related  Services  among  Selected  Commercial  Bank Branches  in  Wa  Municipality," Information  and Knowledge Management , vol. 3, no. 9, pp. 40-55, 2013.
[21]  C. Rey-Moreno, M. J. Ufitamahoro, I. Venter and W. D. Tucker,  "Co-designing  a  Billing  System  for  Voice Services  in  RuralSouth  Africa:  Lessons  Learned,"  in
Proceedings of the Fifth ACM Symposium on Computing for Development , 2014.