A proof of concept (PoC) means trying an ERP with your own data before you decide. The seller takes a sample of your data, loads it into the software and shows your work with it. What you learn from the trial depends largely on your own preparation. A PoC you walk into unprepared turns into a slightly longer demo.
The preparation falls under five headings.
Decide first what you want to see
Scenarios come before data. If the trial starts with "let's have a look at the software", the seller shows the flow they know best. If you hand over what you want to see in writing, the trial runs on your own work.
Ask each department for one job. Have the people responsible for sales, purchasing, the warehouse and accounting each write down a job they do every day and cannot work without. Four or five scenarios are enough. Examples:
- A quote becomes an order, the order ships in two parts and each shipment is invoiced.
- A purchase invoice in foreign currency is paid at a different exchange rate.
- A stock count comes up short, and the difference is recorded in stock and in the books.
- Overdue receivables are listed by customer.
Pick the scenario from real work. Write down the order that gave you trouble last month, the invoice with a return, the account that would not close.
For a Turkish subsidiary, add one scenario that head office cares about: for example, how a local transaction ends up in the group reporting currency.
Which data should you prepare?
The data needed for the scenarios is much the same in most businesses:
- Customer and supplier list, with tax numbers and addresses.
- Product and stock list: code, name, unit, barcode if you have one, and quantity by warehouse.
- Open invoices and account balances, so that receivables and payables can be followed in the trial.
- Bills of materials and price lists, if you have them.
- The real documents in your scenarios: the order, the invoice, the count sheet themselves.
You do not need to send all of your data. A part that represents your business is enough. What matters is that it does represent it. If you pick only the trouble-free records, the trial will be trouble-free too and will teach you nothing.
So do not clean the data before you send it. Leave in the product with the wrong unit, the customer opened twice and the account with no tax number. These are the problems you will meet in the transition, and the most useful part of the trial is seeing what happens to those records.
In what format do you hand over the data?
An Excel file or an export from the software you use today is enough. Do not rename or reorder the columns. How the data gets into the software is the seller's job, and how smoothly that goes is itself a result of the trial.
During the import the seller will ask you questions: "What does this column mean?", "What is the conversion factor between these two units?" Decide in advance who will answer. It is usually the accounting lead or the person who knows the warehouse best.
What should you do about personal data?
Customer and staff lists contain personal data: phone numbers, e-mail addresses and, for sole traders, ID numbers. The trial does not need them. Before you send anything:
- Delete or change the phone, e-mail and ID number columns.
- If staff data is needed, change the names and round the salaries.
- Ask the seller in writing where the data will be kept, who will see it and what happens to it when the trial ends.
- Sign a confidentiality agreement before sending the data if you see the need.
In Türkiye this is also a KVKK question, and for a group with EU entities a GDPR one. Do not give your real data to a seller who cannot answer these questions clearly.
Who should be in the meeting?
If only the decision-maker attends the trial meeting, it falls short. Whether a screen is easy or hard is seen best by the person who will use it every day.
Have these people in the room:
- The department leads who wrote the scenarios.
- One or two of the staff who will use the software every day.
- Your CPA (SMMM) or accounting lead.
- The person who will make the decision.
After the seller shows a flow, ask for one of your own staff to do the same job. A task the seller finishes in a minute may take your employee much longer. For a job done a hundred times a day, that difference matters.
Decide in advance how you will record the result
Before the meeting, prepare a simple table. One row per scenario, and one of three results against each: worked, needs adapting, did not work. Where something needs adapting, note what the seller says will be done.
When the meeting ends you should have that table, not an impression. We explain how to make the decision in the article on what to do after the PoC.
How does preparation work at Birasyo?
At Birasyo we do not show a canned demo. We show the software with your data. In the first call we choose the scenarios together. We take your data as Excel files or as an export from the software you use, and we do the import. The data sits in an environment set aside for you, is used only for this trial and is deleted if you do not go ahead. If you wish, we sign a confidentiality agreement first.
To start, fill in the form on the proof of concept page.
Related reads
Share this post on LinkedIn
The title, summary and hashtags are copied to your clipboard and the sharing window opens. Paste (Cmd/Ctrl+V) and post.
