A Guide to Choosing an IT Consultant for MSME Digitalization in Yogyakarta (DIY)

A primary clinic in Sleman with three polyclinics and 120 patients per day usually starts looking for an IT consultant after two things happen: BPJS queues run 40 minutes late, and pharmacy drug stock reports are off by Rp8–12 million per month. At that point, small vendors offer an all-in-one clinic application for Rp4.5 million, while enterprise vendors offer Rp180 million. Both sound equally reasonable — and that is precisely the problem. Choosing an IT consultant is not about finding the cheapest price or the largest portfolio, but matching the vendor’s technical capacity with real workflows in the field, while ensuring you are not locked into a system that cannot be integrated with BPJS or SATUSEHAT. This guide provides a framework you can use immediately: needs audit, due diligence, technical testing, through contract negotiation.

Audit Needs First, Then Find a Vendor

The most expensive mistake is drafting an RFP based on a competitor’s feature list. Start with the five business processes that consumed the most time and money in the last 30 days. A real example: a two-shift clinic with 120 patients/day spends an average of 6–8 minutes per manual medical record entry, meaning about 30 staff work hours per month just for data entry that should be automated. This number is far more persuasive when you discuss with vendors than the sentence “we need a complete system.”

Quantify the baseline. For a pharmacy with 2,000 SKUs, record the monthly stock discrepancy (e.g., Rp8–12 million), stock opname duration (2 days), and the number of prescriptions that must be re-entered (60–80 per day). After the new system has been running for three months, target a stock discrepancy below Rp1 million, opname completed within 3 hours, and zero double entry. This baseline is what is used to calculate the vendor’s ROI, not their brochure.

Only after that determine the system category: SIMRS/SIM Klinik for registration, queues, pharmacy, and cashier; ERP for manufacturing or layer poultry farming; POS for pharmacies, retail, and restaurants; BPJS/SATUSEHAT bridging integration based on FHIR R4; and a website for publication and online registration channels. A vendor strong in retail POS may not necessarily understand BPJS claim flows. Do not judge one domain by a vendor’s achievements in another domain.

Also pay attention to geographic context. MSMEs in Bantul, Sleman, Gunungkidul, and Magelang generally need onsite assistance during go-live, not just Zoom meetings. The distance from Yogyakarta to Magelang is about 40 km or 1.5 hours by car; a consultant based in DIY and Central Java can be present on the first operational day, the moment when 80% of problems appear.

Eight Due Diligence Criteria Clients Rarely Ask About

Due diligence is not merely checking PT legality and testimonials. Ask questions that force vendors to show technical and operational evidence, not promises.

• Similar portfolio — at least two implementations with scale and complexity close to yours, complete with contactable client names.
• Core team — who the analyst, developer, and QA are; whether there are permanent staff or all are freelancers.
• Work method — waterfall, agile, or hybrid; ask for examples of a sprint backlog and UAT documents.
• API documentation — availability of OpenAPI/Swagger, sandbox, and version changelog.
• Data strategy — legacy data migration scheme, export format, and database ownership.
• Security — encryption at-rest and in-transit, role management, audit log, and readiness for UU PDP No. 27/2022.
• Post-go-live support — service hours, escalation channels, and availability of onsite technicians.
• Exit plan — how you take over the system if the partnership ends.

After passing selection, lock everything into a written SLA. 99.5% uptime sounds high, but it means there is still a downtime tolerance of about 3.6 hours per month; 99.9% equals 43 minutes. Agree on incident classification: P1 (system unusable) must be responded to ≤30 minutes, P2 ≤4 business hours. For healthcare services, downtime during morning practice hours is a direct loss, not a cosmetic disruption.

From a compliance perspective, ensure the vendor understands Permenkes No. 24/2022 on Electronic Medical Records and the SATUSEHAT interoperability scheme. A vendor that cannot explain FHIR resource mapping (Patient, Encounter, Observation) simply will usually make things difficult for you during second-year integration.

Technical Testing with Your Own Data, Not Demo Data

Request a demo using your data: 50–100 anonymized patient or transaction records. What is assessed is not the appearance, but whether the registration-to-payment flow completes in under 90 seconds, and whether the system rejects duplicate input with a clear error message. A confident vendor will open an API sandbox, not just screenshots.

If the system provides an API, perform a simple latency test from your laptop to the demo endpoint. The Python 3.11 script below measures p50, p95, and the error rate from 30 sequential requests — enough to screen out vendors whose endpoint is consistently above 1 second.

import time, statistics, requests

URL = 'https://demo.klinikanda.id/api/v1/antrean/poli'
lat, gagal = [], 0
for _ in range(30):
    t0 = time.perf_counter()
    try:
        r = requests.get(URL, timeout=3)
        gagal += r.status_code >= 500
    except requests.RequestException:
        gagal += 1
    lat.append((time.perf_counter() - t0) * 1000)

print(f'p50={statistics.median(lat):.0f}ms p95={sorted(lat)[28]:.0f}ms error={gagal/30:.0%}')

Interpretation: p95 below 500 ms and 0% errors is a good signal for internal APIs; p95 above 1,500 ms is a sign of architectural problems. Also ask about the backup schedule (must be daily with at least 30 days' retention), written RTO/RPO, and whether a staging environment is available that you can access for UAT. Vendors without staging usually use the production server as a testing ground — a risk you should not bear.

Best Practices

1. Always request a demo using 50–100 of your own anonymized real data records, and record the completion time of each workflow with a stopwatch.
2. Establish a written SLA: uptime of at least 99.5%, P1 response ≤30 minutes, plus service credit compensation if breached.
3. Obtain full access rights to the database and source code (or an escrow agreement) so you are not held hostage when changing vendors.
4. Calculate the total cost of ownership over 3 years — licensing, customization, training, servers, and maintenance — not just the initial project price.
5. Appoint one internal super user per unit and involve them from UAT onward; system adoption is determined by its owners in the field, not by the vendor's trainer.

FAQ

What is a reasonable budget for digitizing a small clinic in Yogyakarta?

For a Clinic Information System (SIM Klinik) with registration, queue, medical records, pharmacy, and cashier modules, the current market range is IDR 35–90 million for implementation, plus 15–20% annual maintenance. BPJS and SATUSEHAT integration is usually priced separately at IDR 15–40 million depending on complexity. Compare those figures with the stock leakage and manual work hours you have already calculated in the audit.

Must an IT consultant be based in DIY or Magelang?

Not required, but very helpful. At least 70% of the work can be done remotely; the rest — workflow surveys, training, and go-live support — requires physical presence. A consultant based in Yogyakarta or Magelang can be on site within 1–3 hours during a critical incident, while an off-island vendor needs 1–2 days.

How can you ensure that a vendor can truly integrate with SATUSEHAT and BPJS?

Ask for concrete evidence: FHIR mapping documentation, screenshots of successful bridging transaction logs, and contactable client references. If the vendor only answers “can do,” ask them to test sending one Patient resource to the SATUSEHAT sandbox in front of you. Failure at this stage saves tens of millions of rupiah later.

What clauses must be included in the contract?

At least four: (1) a definition of scope and measurable UAT criteria, (2) the SLA and its compensation, (3) data and source code ownership, and (4) a termination clause requiring handover of data in an open format (SQL dump or CSV) within a maximum of 14 business days after the contract ends.

MSME digitalization does not fail because the technology is not advanced enough, but because partner selection is based on assumptions, not evidence. From a baseline audit with numbers, due diligence across eight criteria, a demo with your own data, to SLAs and data ownership clauses — you can run all of this in 2–3 weeks before signing anything. If you manage a clinic, hospital, pharmacy, or retail and livestock business in Yogyakarta, DIY, or Magelang and need support in selecting and building a SIMRS, SIM Klinik, ERP, POS, or website, please schedule a consultation session to analyze your needs and develop a realistic technical plan.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: PilarPOS BPJS & SatuSehat Integration. Need a free consultation?