Baseline KPI Proyek Software: Mengukur Kondisi Before Sebelum Menentukan Solusi

Banyak proyek software enterprise memiliki target yang terdengar benar tetapi sulit dibuktikan: meningkatkan efisiensi, mempercepat proses, mengurangi pekerjaan manual, meningkatkan visibility, menurunkan human error, atau membuat operasional lebih terintegrasi. Problemnya bukan pada objective tersebut, melainkan pada kondisi awal yang sering tidak pernah didefinisikan secara jelas. Jika perusahaan tidak mengetahui berapa lama proses berlangsung sebelum sistem dibangun, berapa banyak pekerjaan manual yang terjadi, seberapa sering error muncul, atau berapa besar kapasitas yang saat ini digunakan untuk menangani sebuah workflow, perusahaan akan kesulitan menjawab pertanyaan paling mendasar setelah implementasi: apakah software benar-benar membuat bisnis menjadi lebih baik?

Karena itu, dalam pendekatan business-impact-oriented, diskusi mengenai teknologi seharusnya tidak langsung dimulai dari fitur atau solusi. Perusahaan terlebih dahulu membutuhkan baseline KPI, yaitu gambaran terukur mengenai kondisi Before yang ingin diperbaiki. Baseline menjadi titik pembanding bagi kondisi After, sehingga dampak software tidak hanya dijelaskan melalui persepsi seperti “sekarang lebih cepat” atau “proses lebih mudah”, tetapi dapat ditelusuri terhadap perubahan pada metric yang memang relevan terhadap bisnis. DORA menggunakan logika serupa dalam continuous improvement: tim dianjurkan menetapkan baseline performa aplikasi terlebih dahulu, mengidentifikasi friction dan bottleneck, melakukan improvement, lalu mengukur kembali hasilnya. Dora DORA Software Delivery Performance Metrics

Baseline tidak berarti setiap proyek harus memiliki perhitungan finansial yang kompleks sebelum development dimulai. Yang lebih penting adalah perusahaan mengetahui apa yang sedang tidak bekerja dengan baik, bagaimana kondisi tersebut diukur, dan metric apa yang seharusnya berubah jika intervention berhasil. Dengan disiplin tersebut, software tidak lagi dimulai dari “apa yang ingin kita buat?”, tetapi dari “apa yang ingin kita ubah, dan bagaimana kita mengetahui bahwa perubahan itu benar-benar terjadi?”

Apa Itu Baseline KPI dalam Proyek Software?

Baseline KPI adalah nilai awal dari metric yang digunakan untuk menggambarkan performa suatu proses, capability, atau business outcome sebelum perubahan teknologi dilakukan. Baseline dapat berupa waktu, volume, biaya, error, throughput, conversion, backlog, downtime, kapasitas, atau ukuran lain yang memiliki hubungan langsung dengan masalah yang sedang diselesaikan. Jika perusahaan ingin mempercepat approval, misalnya, baseline yang relevan bukan jumlah screen pada aplikasi existing, melainkan average atau median approval cycle time, waiting time di setiap tahap, volume request, dan jumlah exception yang membuat approval tertunda.

Perbedaan ini penting karena software feature merupakan intervention, sementara baseline menggambarkan masalah yang hendak diintervensi. Dashboard approval mungkin merupakan feature. Automatic routing mungkin merupakan feature. Mobile approval juga merupakan feature. Namun baseline yang menjelaskan kebutuhan bisnis berada pada level berbeda: approval membutuhkan terlalu banyak waktu, menyebabkan procurement tertunda, atau menciptakan backlog yang semakin besar. Selama perusahaan belum memahami kondisi tersebut, keputusan tentang feature masih didasarkan pada asumsi mengenai solusi, bukan evidence mengenai problem.

Gartner pada 2026 menyoroti tantangan CIO dalam menunjukkan business value ketika technology metric tidak terhubung dengan outcome yang dipahami CEO, CFO, maupun COO. Guidance mereka mendorong IT leaders menghubungkan technology investment dengan metric yang mencerminkan outcome bisnis, bukan hanya indikator operasional teknologi. Gartner Gartner: Metrics That Reflect Business Value of Technology Investment Karena itu, baseline KPI bukan hanya alat project management. Ia menjadi bahasa bersama antara business dan technology untuk menjelaskan mengapa investasi perlu dilakukan dan perubahan apa yang diharapkan darinya.

Mengapa Baseline Harus Dibuat Sebelum Solusi Ditentukan?

Ada kecenderungan untuk mengukur impact setelah sistem selesai dibangun. Pada saat itu, tim baru bertanya: metric apa yang dapat kita gunakan untuk membuktikan project ini berhasil? Pendekatan tersebut memiliki risiko karena measurement kemudian dibentuk berdasarkan solution yang sudah dibuat. Organisasi dapat berakhir memilih metric yang mudah menunjukkan progress, bukan metric yang sejak awal menunjukkan problem bisnis.

Sebagai contoh, sebuah perusahaan membangun portal baru untuk mempercepat customer onboarding. Setelah go-live, tim melaporkan jumlah user yang login, jumlah form yang berhasil di-submit, dan jumlah account yang menggunakan portal. Semua angka tersebut berguna untuk menunjukkan adoption, tetapi belum membuktikan bahwa onboarding menjadi lebih cepat. Jika tujuan bisnis sebenarnya adalah mengurangi waktu dari customer submission sampai account activation, baseline seharusnya sudah mencatat onboarding cycle time sebelum portal dibangun. Setelah go-live, perusahaan kemudian dapat membandingkan kondisi sebelum dan sesudah dengan definisi metric yang konsisten.

Inilah alasan baseline sebaiknya dibentuk sebelum intervention diputuskan. Ketika problem dan metric sudah jelas, tim dapat mengevaluasi apakah teknologi yang sedang dipertimbangkan memang berpotensi menggerakkan metric tersebut. Jika tidak, solution dapat ditinjau kembali sebelum biaya development dikeluarkan. Prinsip ini melanjutkan pendekatan pada artikel Impact-Driven Software Development: teknologi ditempatkan setelah business problem dan target impact, bukan digunakan sebagai titik awal.

Crocodic Baseline-to-Impact Framework

Untuk menghubungkan kondisi bisnis dengan keputusan teknologi, Crocodic dapat menggunakan alur Business Goal → Problem Metric → Baseline → Target → Bottleneck → Technology Intervention → Measured Outcome. Business Goal menjelaskan arah yang bernilai bagi perusahaan, seperti meningkatkan operational capacity atau mempercepat customer response. Problem Metric menerjemahkan objective tersebut menjadi sesuatu yang dapat diamati. Baseline menunjukkan kondisi aktual sebelum perubahan. Target menentukan kondisi yang ingin dicapai. Bottleneck menjelaskan penyebab gap antara baseline dan target, kemudian Technology Intervention dipilih berdasarkan akar masalah tersebut. Setelah sistem digunakan, Measured Outcome dibandingkan terhadap baseline untuk melihat apakah hypothesis awal benar-benar terbukti.

Framework ini mencegah perusahaan melompat terlalu cepat dari problem ke software. Misalnya objective perusahaan adalah mempercepat order fulfillment. Baseline menunjukkan fulfillment cycle yang panjang, tetapi analysis kemudian menemukan sebagian besar delay terjadi bukan di warehouse application, melainkan pada approval dan sinkronisasi inventory. Dalam situasi tersebut, menambah feature warehouse belum tentu memberikan contribution terbesar. Intervention yang lebih tepat mungkin integration, automation, atau perubahan workflow.

Hubungan tersebut dapat diringkas sebagai sebuah hypothesis: “Jika bottleneck ini diperbaiki melalui intervention ini, metric tersebut seharusnya bergerak dari baseline menuju target.” Software project kemudian memiliki alasan keberadaan yang jauh lebih kuat daripada sekadar daftar requirement.

Baseline yang Baik Dimulai dari Business Problem, Bukan dari Data yang Paling Mudah Diambil

Kesalahan yang cukup umum adalah memilih KPI karena datanya sudah tersedia. Jika aplikasi memiliki dashboard jumlah transaction, jumlah transaction kemudian digunakan sebagai ukuran keberhasilan meskipun problem utamanya mungkin response time atau error. Jika system mencatat jumlah ticket, volume ticket kemudian menjadi KPI meskipun objective sebenarnya adalah mempercepat resolution.

Baseline sebaiknya berjalan dari arah sebaliknya. Organisasi menentukan problem terlebih dahulu, kemudian bertanya metric apa yang paling dekat dengan problem tersebut. Jika data belum tersedia, perusahaan perlu memutuskan bagaimana metric tersebut dapat diukur. Pendekatan ini mungkin membutuhkan effort tambahan di awal, tetapi menghasilkan measurement yang jauh lebih berguna daripada sekadar mengambil angka yang sudah tersedia.

Deloitte menekankan perlunya clear objectives and key results yang membangun line of sight antara aktivitas product team dan business-critical outcomes. Dalam product operating model, pekerjaan teknologi seharusnya dapat ditelusuri kembali ke tujuan organisasi, bukan hanya dinilai dari output tim. Deloitte Deloitte: Product Operating Model Framework Logika tersebut dapat diterapkan langsung pada baseline: ukur sesuatu karena metric itu menjelaskan business problem, bukan hanya karena sistem kebetulan dapat mengukurnya.

Pilih KPI Sedekat Mungkin dengan Masalah yang Ingin Diubah

KPI yang terlalu jauh dari intervention membuat hubungan sebab-akibat sulit dibuktikan. Misalnya sebuah perusahaan membangun workflow automation pada procurement lalu menggunakan total company revenue sebagai KPI utama. Revenue tentu penting, tetapi terlalu banyak faktor lain yang memengaruhi revenue sehingga contribution automation procurement menjadi sulit dipisahkan.

Metric yang lebih dekat mungkin procurement approval cycle time, purchase-order processing time, manual handling hours, number of exceptions, atau cost per transaction. Setelah process metric tersebut berubah, perusahaan dapat menelusuri bagaimana perubahannya berkontribusi pada outcome yang lebih tinggi seperti faster purchasing, reduced downtime, atau working-capital improvement.

Dengan demikian, measurement dapat menggunakan hierarchy Feature/Intervention → Process KPI → Business Outcome. Tidak setiap software feature harus langsung membuktikan perubahan revenue. Yang dibutuhkan adalah causal chain yang cukup masuk akal antara perubahan teknologi dan business outcome yang ingin dicapai.

Jenis Baseline KPI yang Relevan untuk Proyek Enterprise

Baseline tidak harus selalu berbentuk financial metric. Jenis metric perlu mengikuti problem yang sedang dihadapi. Beberapa kategori berikut dapat membantu perusahaan menentukan apa yang perlu diukur sebelum solution dipilih.

Kategori tersebut bukan checklist wajib. Enterprise sebaiknya menggunakan sesedikit mungkin metric yang benar-benar menjelaskan problem. Terlalu banyak KPI dapat membuat project kehilangan fokus karena setiap stakeholder mencoba membawa ukuran keberhasilannya sendiri.

Baseline Tidak Sama dengan Target

Baseline menjelaskan di mana kita berada, sedangkan target menjelaskan ke mana kita ingin bergerak. Perbedaan ini terlihat sederhana, tetapi project sering mencampurkan keduanya. Pernyataan seperti “target kita adalah proses lebih cepat” belum memiliki baseline maupun target yang cukup jelas. Perusahaan membutuhkan kondisi aktual dan kondisi yang diinginkan agar gap dapat dihitung.

Namun target juga tidak seharusnya dibuat secara arbitrer. Menurunkan cycle time 50% terdengar ambisius, tetapi pertanyaannya adalah apakah angka tersebut mengikuti business need atau sekadar angka yang terlihat menarik. Target idealnya berasal dari kebutuhan operasi, customer expectation, capacity constraint, regulatory requirement, service level, atau economic threshold tertentu. Jika bisnis membutuhkan approval maksimal tiga jam agar proses berikutnya tidak tertunda, maka tiga jam memiliki alasan operasional. Jika perusahaan hanya mengatakan ingin 50% lebih cepat karena terdengar bagus, target tersebut memiliki dasar yang jauh lebih lemah.

Baseline dan target bersama-sama menghasilkan impact gap. Technology initiative kemudian diuji berdasarkan kemampuannya menutup gap tersebut.

Jangan Gunakan Average Tanpa Memahami Distribusinya

KPI juga perlu didefinisikan secara cukup presisi agar perbandingan Before dan After adil. Average process time, misalnya, dapat menyembunyikan kondisi di mana mayoritas transaksi cepat tetapi sebagian kecil membutuhkan waktu sangat lama. Dalam situasi semacam itu, perusahaan dapat mempertimbangkan median, percentile, exception rate, atau segmentasi berdasarkan jenis transaksi.

Hal yang sama berlaku pada error. Pernyataan “error rate 4%” perlu menjelaskan denominator: 4% dari transaction, document, customer, atau workflow? Apakah seluruh error memiliki consequence yang sama? Apakah error ringan dan critical error digabungkan? Tanpa definisi yang konsisten, baseline dapat berubah arti ketika project berjalan.

Karena itu, setiap KPI idealnya memiliki definisi minimum: metric yang diukur, scope, population, timeframe, data source, dan owner. Tujuannya bukan membuat project menjadi terlalu akademis, tetapi memastikan angka Before dan After benar-benar dapat dibandingkan.

Baseline Harus Menggunakan Periode yang Representatif

Pengukuran sebelum implementation juga perlu memperhatikan variasi bisnis. Mengambil data selama satu hari ketika volume rendah dapat menghasilkan baseline yang terlalu optimistis. Sebaliknya, menggunakan satu hari ketika terjadi incident besar dapat membuat kondisi awal terlihat lebih buruk daripada normal.

Perusahaan perlu memilih periode yang cukup merepresentasikan cara operasi sebenarnya. Untuk business yang memiliki seasonality, baseline mungkin perlu dibandingkan dengan periode serupa. Untuk proses dengan volume rendah, periode pengamatan mungkin perlu lebih panjang. Jika data historis tidak tersedia, perusahaan dapat menggunakan time study atau sample sementara dan menyatakan limitation-nya secara eksplisit.

Tujuannya bukan memperoleh angka dengan presisi semu. Tujuannya adalah menciptakan reference point yang cukup kredibel untuk mengambil keputusan.

Bagaimana Jika Perusahaan Belum Memiliki Data Baseline?

Tidak adanya data baseline cukup umum, terutama ketika process masih berjalan melalui spreadsheet, email, WhatsApp, atau koordinasi manual. Namun ketiadaan data tidak berarti impact tidak dapat diukur. Perusahaan dapat membangun baseline secara bertahap menggunakan manual sampling, observation, interview, timestamp pada beberapa tahap process, temporary logging, atau proxy metric yang paling dekat dengan problem.

Misalnya organisasi belum mengetahui berapa jam yang digunakan team untuk reconciliation setiap bulan. Selama satu atau dua minggu, perusahaan dapat meminta beberapa user mencatat handling time dan jenis exception yang ditemui. Sample tersebut mungkin belum sempurna, tetapi lebih berguna daripada asumsi bahwa “reconciliation membutuhkan banyak waktu”. Setelah system baru berjalan, measurement dapat menjadi lebih otomatis dan akurat.

Baseline yang baik tidak harus selalu kompleks. Ia hanya perlu cukup jelas untuk membedakan problem yang dirasakan dari problem yang dapat diamati.

Bedakan Baseline Business dengan Baseline Technology

Dalam enterprise software initiative, sering kali terdapat dua baseline yang sama-sama penting. Baseline pertama menggambarkan business process, sedangkan baseline kedua menggambarkan kemampuan technology environment yang mendukungnya.

Misalnya business problem adalah perusahaan terlalu lambat merespons perubahan pricing. Business baseline dapat berupa waktu sejak pricing policy disetujui hingga harga baru aktif di seluruh channel. Technology baseline dapat berupa change lead time, deployment frequency, failure rate, atau jumlah system yang perlu diubah secara manual.

DORA secara khusus memisahkan throughput dan instability untuk mengukur software delivery performance serta merekomendasikan baseline sebagai titik awal improvement. Dora Jika business membutuhkan perubahan lebih cepat tetapi technology delivery memerlukan beberapa minggu untuk setiap perubahan kecil, architecture atau software delivery process dapat menjadi bagian dari bottleneck.

Dalam kasus seperti ini, [Enterprise System Upgrade] Enterprise System Upgrade mungkin lebih relevan daripada hanya menambahkan feature pada system lama. Baseline membantu organization melihat apakah problem berasal dari missing functionality atau dari kemampuan system untuk berubah.

Baseline Membantu Menentukan Apakah Software Baru Benar-Benar Dibutuhkan

Salah satu manfaat terbesar baseline adalah kemampuannya mencegah perusahaan langsung menganggap setiap business problem sebagai software problem. Setelah process diukur, organisasi dapat menemukan bahwa bottleneck sebenarnya berasal dari policy, unclear ownership, duplicate approval, poor data quality, atau aktivitas yang tidak lagi diperlukan.

Misalnya user meminta aplikasi approval baru karena process berjalan lambat. Baseline menunjukkan bahwa system hanya membutuhkan beberapa menit untuk memproses request, sedangkan mayoritas waktu terbuang karena request menunggu manusia selama berjam-jam. Analysis berikutnya menemukan adanya beberapa approval layer yang memiliki decision criteria hampir sama. Dalam kondisi tersebut, membangun interface baru tanpa process redesign mungkin hanya membuat waiting time terlihat lebih modern.

Prinsip yang sama berlaku untuk automation. Sebelum mengotomatisasi workflow, perusahaan perlu memahami process mana yang memang memberikan enough value untuk diubah. Crocodic membahas keputusan ini lebih jauh dalam Business Process Automation Enterprise: Mana yang Layak Diotomasi? Business Process Automation Enterprise Baseline menjadi evidence awal untuk menentukan apakah opportunity tersebut cukup bernilai.

Baseline Tetap Penting Ketika Feature List Sudah Final

Dalam enterprise project, requirement tidak selalu dapat diubah. Klien mungkin sudah memiliki draft fitur final dari tender, internal assessment, regulator, atau keputusan management. Pada kondisi tersebut, pendekatan business-impact-oriented tetap dapat digunakan tanpa harus mempertanyakan seluruh scope.

Baseline berfungsi untuk menghubungkan feature yang sudah fixed dengan target hasil. Jika sebuah sistem sudah pasti harus memiliki work order, dashboard, notification, inventory integration, dan analytics, organisasi masih dapat menentukan kondisi Before untuk setiap business goal. Feature kemudian dipetakan terhadap metric yang ingin diperbaiki dan sequencing dapat mengikuti contribution terhadap impact.

Hal ini mengubah conversation. Technology partner tidak perlu mengatakan “feature tersebut tidak perlu”. Sebaliknya, partner dapat membantu menjawab: feature mana yang paling dekat dengan target impact, metric apa yang harus diamati, dan setelah implementation bagaimana kita mengetahui feature tersebut benar-benar bekerja untuk bisnis?

Dengan kata lain, baseline bukan hanya alat untuk memilih feature. Ia juga menjadi alat untuk membuktikan value dari feature yang memang sudah diputuskan untuk dibangun.

Baseline Membuat Prioritas Teknologi Lebih Objektif

Enterprise jarang memiliki satu problem saja. Ada operational inefficiency, legacy system, data integration, AI opportunity, security, customer experience, reporting, dan berbagai request lain yang saling bersaing mendapatkan budget. Jika seluruh initiative dipresentasikan dalam bentuk daftar feature atau project, management sulit membandingkan nilainya.

Baseline mengubah pembicaraan menjadi gap. Initiative A mungkin menangani process dengan cycle time tinggi tetapi business consequence rendah. Initiative B mungkin menangani error dengan frekuensi lebih kecil tetapi financial exposure tinggi. Initiative C mungkin meningkatkan capacity pada process yang sudah mendekati limit.

Dengan evidence tersebut, [Digital Transformation Roadmap] Digital Transformation Roadmap dapat dibangun berdasarkan masalah dan potential impact, bukan sekadar siapa yang paling keras meminta aplikasi baru.

McKinsey juga menekankan bahwa business value seharusnya menjadi metric utama dalam product decisions dan menggunakan konsep value realization untuk melihat berapa besar value yang dijanjikan benar-benar dapat dihasilkan. McKinsey & Company McKinsey: What Makes Product Teams Effective? Baseline menjadi bagian penting dari logika tersebut karena realized value sulit dihitung jika committed improvement tidak memiliki titik awal.

Baseline untuk AI dan Automation Harus Dibuat Sebelum AI Masuk

AI dapat membuat problem baseline menjadi lebih penting karena organisasi mudah tertarik pada capability sebelum memiliki business case yang jelas. Sebuah agent dapat membaca dokumen, mengakses ERP, mencocokkan data, atau mengirim communication. Tetapi pertanyaan investment tetap sama: berapa banyak value yang dapat dibuka jika activity tersebut diotomasi atau dipercepat?

Jika Finance ingin menggunakan AI untuk invoice reconciliation, misalnya, baseline perlu melihat volume invoice, manual handling time, exception rate, rework, dan waktu yang dibutuhkan untuk menyelesaikan reconciliation. Dari sana, perusahaan dapat menentukan area mana yang memiliki potential impact terbesar. Jika manual effort ternyata kecil dan exception sangat kompleks, full automation mungkin tidak memberikan value yang cukup. Jika ribuan dokumen membutuhkan pengecekan repetitif dengan pola konsisten, opportunity-nya jauh lebih jelas.

Untuk AI-specific initiative, evaluasi lanjutan dapat menggunakan AI Business Case AI Business Case. Baseline memberikan Before, business case mengevaluasi apakah AI merupakan intervention yang tepat, kemudian setelah implementasi AI Value Realization AI Value Realization membantu melihat apakah impact benar-benar terealisasi.

Jangan Mengganti Business KPI dengan Delivery KPI

Salah satu jebakan yang umum adalah project sukses secara delivery lalu otomatis dianggap sukses secara bisnis. Project selesai sesuai timeline, scope terpenuhi, UAT lolos, defect rendah, dan go-live berjalan lancar. Semua itu penting, tetapi belum menjawab apakah business outcome berubah.

Perusahaan membutuhkan dua scorecard. Delivery Scorecard melihat apakah solution dibangun dengan baik: lead time, stability, defect, security, budget, dan reliability. Impact Scorecard melihat apakah bisnis berubah: cycle time, cost, manual hours, capacity, error, customer outcome, atau risk exposure.

Gartner pada Agustus 2026 juga menekankan bahwa dalam AI software engineering, penggunaan operational engineering metrics saja dapat mengarahkan investasi ke outcome yang salah; outcome-driven metrics dibutuhkan agar software engineering tetap terhubung dengan business value. Gartner Prinsip tersebut berlaku lebih luas pada software enterprise: delivery performance menjelaskan kualitas mesin delivery, sedangkan business KPI menjelaskan apakah investment tersebut layak.

Hindari Vanity KPI yang Terlihat Bagus tetapi Tidak Mengubah Keputusan

Baseline yang buruk tidak selalu berarti data salah. Metric bisa benar tetapi tidak berguna. Jumlah user login, jumlah page views internal, jumlah automated emails, jumlah report yang dibuat, atau jumlah agent executions dapat terlihat impresif tetapi belum tentu memiliki hubungan langsung dengan objective.

Metric tersebut dapat digunakan sebagai adoption atau activity signal, tetapi sebaiknya tidak menggantikan outcome KPI. Jika objective automation adalah mengurangi manual workload, metric yang lebih penting adalah handling hours atau cost per transaction. Jika objective dashboard adalah mempercepat keputusan, metric yang relevan adalah data availability atau decision cycle, bukan jumlah dashboard views.

Gartner menyebut tantangan serupa pada data products: technical indicator saja tidak cukup untuk menunjukkan business impact, sehingga organisasi membutuhkan outcome-driven metrics untuk mengukur realized value dan mengarahkan prioritas investasi. Gartner

Prinsip sederhananya adalah: jika metric meningkat, apakah business leader akan menganggap bisnis benar-benar lebih baik? Jika jawabannya tidak jelas, metric tersebut mungkin hanya supporting metric.

Siapa yang Harus Menentukan Baseline?

Baseline tidak sebaiknya ditentukan IT sendirian karena technology team belum tentu memiliki business context penuh. Sebaliknya, business team juga tidak selalu memahami data source atau technical limitation. Baseline sebaiknya dibangun sebagai joint exercise antara process owner, business sponsor, technology team, dan jika perlu Finance atau Data team.

Business owner menjelaskan outcome dan consequence. Process owner memahami workflow sehari-hari. Data atau technology team memastikan metric dapat diukur secara konsisten. Finance dapat membantu ketika value perlu diterjemahkan ke economic impact.

Model kolaboratif ini juga sejalan dengan product operating model yang menghubungkan business, technology, operations, dan fungsi relevan lain ke dalam team yang bertanggung jawab terhadap outcome. McKinsey menemukan product management practices, backlog prioritization, funding, dan cross-functional ways of working memiliki hubungan kuat dengan business performance. McKinsey & Company

Baseline pada akhirnya bukan “angka milik IT”. Ia merupakan business agreement mengenai kondisi yang ingin diubah.

Setelah Go-Live, Jangan Langsung Menyatakan Impact

Measurement After perlu dilakukan dengan disiplin yang sama seperti Before. System yang baru go-live dapat membutuhkan waktu untuk adoption, user behavior mungkin belum stabil, dan external factor dapat memengaruhi result. Karena itu, perusahaan perlu menentukan kapan outcome realistis untuk diukur.

Beberapa metric dapat berubah langsung, seperti system processing time. Metric lain membutuhkan beberapa minggu atau bulan, seperti employee productivity, customer retention, inventory turnover, atau operational capacity. Perusahaan juga perlu mempertimbangkan apakah volume atau kondisi bisnis berubah secara signifikan sehingga perbandingan sederhana Before dan After menjadi misleading.

Tujuannya bukan membuat impact calculation terlalu kompleks, tetapi menghindari klaim terlalu dini. Go-live membuktikan software delivery. Penggunaan membuktikan adoption. Perubahan workflow membuktikan behavior change. Perubahan KPI dibandingkan baseline barulah mulai membuktikan business impact.

Crocodic Perspective: Jangan Tentukan Fitur Sebelum Mengetahui Apa yang Harus Berubah

Dari perspektif Crocodic, baseline KPI merupakan penghubung antara business problem dan technology investment. Tanpa baseline, requirement mudah berubah menjadi daftar keinginan. Tanpa target, project tidak memiliki definisi yang jelas mengenai kondisi yang ingin dicapai. Tanpa measurement setelah go-live, perusahaan tidak mengetahui apakah investasi tersebut benar-benar menghasilkan value.

Karena itu, alur yang kami gunakan bukan Feature → Development → Go-Live, melainkan Problem → Baseline → Target Impact → Bottleneck → Intervention → Adoption → Measurement. Feature, integration, automation, modernization, dan AI berada pada tahap intervention. Mereka dipilih karena diharapkan mengubah sesuatu yang sudah terlebih dahulu dapat dijelaskan.

Prinsip ini juga relevan ketika perusahaan mempertimbangkan [Custom Enterprise Software] Custom Enterprise Software. Custom software seharusnya bukan dimulai dari pertanyaan seberapa banyak fitur yang dapat dibangun, tetapi dari capability atau bottleneck apa yang sedang membatasi bisnis dan seberapa besar perubahan yang ingin dicapai setelah limitation tersebut dihilangkan.

Dengan demikian, baseline mengubah development conversation dari requirement collection menjadi impact hypothesis. Business dan technology tidak hanya menyepakati apa yang akan dibangun, tetapi juga menyepakati apa yang seharusnya berubah jika solusi tersebut benar.

Kesimpulan

Baseline KPI merupakan salah satu bagian paling sederhana tetapi paling penting dalam software investment. Tanpa kondisi Before, perusahaan sulit membuktikan kondisi After. Tanpa baseline, fitur dapat selesai tetapi impact tidak jelas; automation dapat berjalan tetapi efficiency tidak terbukti; AI dapat digunakan tetapi business value tetap menjadi asumsi.

Baseline tidak harus selalu berupa financial metric yang kompleks. Ia dapat berupa cycle time, manual hours, error rate, capacity, backlog, processing cost, customer response, system change lead time, atau metric lain yang paling dekat dengan problem. Yang penting, metric tersebut didefinisikan sebelum solution dipilih dan cukup konsisten untuk dibandingkan setelah implementation.

DORA menggunakan baseline sebagai titik awal continuous improvement, Deloitte menekankan line of sight antara product activities dan business outcomes, sementara Gartner pada 2026 semakin mendorong outcome-driven metrics agar teknologi dapat dijelaskan melalui value yang relevan bagi executive stakeholders. Dora

Bagi Crocodic, ini memperkuat perubahan dari feature-driven menuju business-impact-oriented development. Kami tidak memulai dengan bertanya berapa fitur yang ingin dibuat. Kami memulai dengan memahami apa yang sedang terjadi pada bisnis hari ini, berapa besar gap-nya, dan perubahan apa yang cukup bernilai untuk dikejar.

Baru setelah Before dipahami, teknologi dapat dipilih dengan alasan yang lebih kuat.

Karena tanpa baseline, perusahaan dapat mengetahui bahwa software sudah selesai dibuat—tetapi belum tentu mengetahui apakah bisnis benar-benar berubah.