Most people we speak to are not worried about the software. They are worried about the switch — the opening balances, the stock figures nobody trusts, the staff who have used the same screen for nine years, and going live in the middle of a trading month.
This is the process we run, and what we need from you at each stage.
The order matters more than the speed. Almost every failed implementation we have been asked to rescue skipped configuration or migration to hit a date.
We map your outlets, books, stock locations and statutory obligations, and agree what go-live means.
Chart of accounts, tax and bill terms, document numbering, godowns, roles and payment providers, all checked against the setup gates before anything posts.
Masters, opening balances and opening trial imported and reconciled against your closing figures.
Role-based sessions for owners, cashiers, front desk, kitchen, storekeepers and accounts, using your own data.
One full test cycle end to end, then supervised go-live with a support engineer on hand.
Ongoing support, statutory updates, new-release rollout and periodic health checks.
Being clear about this early prevents the most common disappointment in an ERP rollout: an expectation that a decade of transaction history will arrive intact.
Possible, but it is a project decision with a cost. Usually the right answer is to keep the old system readable for reference instead.
Migrating a number nobody believes just moves the problem into a new system, where it is harder to explain.
Reconciliation is the gate, not a formality. The opening trial balance in Penahak has to agree with your closing trial balance in the old system before you trade on it. If it does not agree, we find out why first — because every report you produce for the next several years sits on top of that figure.
Implementations run late for one of two reasons: data that was not ready, or decisions nobody was empowered to make. Both are solvable at the start and expensive in the middle.
One long session covering everything, for everyone, is how staff end up avoiding a new system. Each role learns the sequence it runs, and nothing else.
The dashboards and reports that answer your questions, plus how to read the audit trail and see who did what.
Posting, corrections and reversals, tax terms, reconciliation, the statutory pack and period close.
Opening a shift, selling, split payments, returns, price and discount rules, and cash handover at close.
Receiving, transfers, counts, adjustments, and what a stock movement does to the accounts.
Taking orders, routing tickets to the right station, split bills, charging to a room, and what to do when a printer fails mid-service.
Reservations, check-in and KYC, deposits, the folio, night audit and checkout.
Employee setup, attendance, leave and overtime, advances, running the pay cycle and posting the salary journal.
Users, roles and permissions, access restrictions, branch configuration, backups and restore.
We do not publish a number, and you should be wary of anyone who does without seeing your data. A single outlet with clean books and a recent stock count is a very different project from a group of eleven branches with three charts of accounts between them.
What we will do is scope it properly, tell you which of the factors on the right apply to you, and give you a plan with dates we both believe. If a date is not achievable we will say so before you commit to it.
Tell us how many branches and companies you run, what you are moving from, and what shape your opening balances are in. We will come back with a scoped plan rather than a generic timeline.
Scoping calls are done by the people who will run your implementation.
