The six phases between signing and go-live, what your own team has to do in each of them, and the decisions you will not be able to undo afterwards.
The same sequence runs whether you are replacing a system or starting without one. What changes is the size of phase three.
Before anything is configured, the implementer works through how your company actually runs — the documents you raise, who approves them, how you cost things, and which of your rules are genuinely yours rather than habits inherited from the last system.
Your side Give the implementer access to the people who do the work, not only to the people who manage it. The detail that breaks a rollout is almost always in a step nobody senior knew was happening.
The system is installed and the structures everything else hangs off are defined. The financial foundation has a documented order — calendar, chart type, ledger, fiscal year and periods, then the legal entity that binds them — and it is enforced rather than advised.
Your side Decide your reporting structure now. Nama carries five dimensions — legal entity, branch, sector, department and analysis set — and any of them can be switched off; turning one off later strands the values already recorded against it.
Opening balances and master files come across from whatever you run now. Nama's own answer here is deliberately unglamorous: if your current system can export to Excel, that is all that is needed. The docs are blunt about the risk — a partial import cannot be rolled back, so imports are staged and checked rather than fired at a live database.
Your side Produce the export, then check it. Nobody at Nama can tell you a customer balance is wrong; only your team can. Inventory has a published cutover order — count, value, load, reconcile against the accounts, then go live — and the reconciliation step is yours.
Screens, fields, validation rules, approval routes and automated actions are changed to match how you work — from inside the product, by the implementer, without a new build. The architecture documentation puts it plainly: a typical implementation involves a great deal of configuration and no changes to the shipped application at all.
Your side Raise what you need changed while it is still phase four. A rule raised now is a setting; the same rule after go-live is a change to live data. This is also why upgrades are not re-merged for you: every installation runs the same build.
Training is delivered by Nama's own customer support team, or by an authorised training centre or dealer, against a planned schedule — and it is inside the price of the system rather than a line item on top of it.
Your side Name the people who will be trained and protect their time. They become the ones the rest of the company asks after go-live.
Your team runs its own transactions through the configured system and signs them off before anything is live. Nama supports the testing and the cutover itself.
Your side Test with your own real documents — a month you have already closed, so you know what the answer should be. Acceptance testing on invented data proves nothing. A test environment costs nothing to keep: the free edition of SQL Server plus last night's backup is the documented practice.
Most of what gets set up during an implementation can be changed later. A handful cannot, because the system itself blocks or discourages it once real transactions exist. These are worth arguing about in week one rather than month six — and they are the reason phases one and two are not a formality.
Fixed once a legal entity is attached to the ledger. Changing them afterwards would corrupt the history behind them.
Documented as an implementation-time decision; the system blocks or discourages changing it once stock transactions exist.
Switching a dimension off after records already carry values leaves that data stranded.
Nama does not publish a standard implementation duration, and this page is not going to invent one — there is no such figure in the product documentation either. What the site can show you is what three named people said about their own projects, in interviews published here in full.
The schedule was excellent — we went live in less than a month.
Abdelhameed Kamal Chief Financial Officer, Elbassioni
Was already running an older system before the move.
We take four months, but that is the maximum; in implementation we do not reach four months.
Ashraf Hagar Egyptian CPAs, an implementation partner
Describing his own firm's implementations as a partner, not Nama's delivery team.
I took up the challenge, we identified every problem it had, and it was brought into operation within six months.
Wael Fouad Group CFO, The Engineering Group — Kenan Holding
Not a new implementation: the system was already in place and only partly working when he joined.
Read them as three situations rather than a range. The shortest was a company already running an older system, which its finance director said made the staff quicker to learn. The longest was not a fresh implementation at all. Ask for an estimate against your own scope, and ask what it assumes about your data.
Installation, implementation and training are inside the price of the system. Nama's published answer commits to implementing the system to meet the customer's requirements and to training the customer's staff against a planned schedule. Training asked for later — when you hire people after go-live — is arranged through your nearest office and quoted separately.
Most of it is not a development question. Nama's own answer is that this is a customisable ready-made application, so an implementer meets most requirements through options already in the product. Where something genuinely is not supported it becomes an enhancement request, weighed against what other customers need, and it may arrive in a later release. That is the honest shape of it, and it is better known before you sign than after.
Every system is supported while it is under warranty. When that period ends you can move to a service agreement, which keeps both technical support and access to new releases in place. Releases carry fixes for reported defects and the enhancements customers have asked for, and they have been documented monthly since 2016.
No. The price of the system includes installation, implementation and training. Nama commits to implementing the system to meet your requirements and to training your staff against a planned schedule. Training requested later, for staff hired after go-live, is quoted separately by your nearest office.
Yes, provided your current system can export to Excel. The import runs from the spreadsheet and technical support works through it with you. A partial import cannot be rolled back, so imports are staged and checked before they are committed.
Most requirements are met through options already in the product, and the implementer configures them without a new build. Anything genuinely unsupported becomes an enhancement request, considered against other customers' needs, and may be delivered in a later release.
You can request a service agreement, which keeps technical support and access to new releases in place after the warranty has expired.
Nama does not publish a standard duration, because it depends on how many of your processes have to be configured and how clean the data you are bringing across is. Customers have described their own projects publicly: one went live in under a month, and an implementation partner describes four months as his maximum. Ask for an estimate against your own scope.
Namasoft requires no posting run at all, and that is a very strong point. With the previous system that used to cost me a great deal of time and effort just to reach the information I needed — balances and so on — before I could produce a sound balance-sheet report. With Namasoft it costs us no time whatsoever.
Tell us how your business runs and we will show you how Nama ERP fits it — in your language, on your infrastructure.
