More than once, I have been contracted to help implement a system after it has been chosen, and have discovered deficiencies between the client’s expectations and the system’s capabilities. This situation usually arises when the client has not chosen a system before, doesn’t know what to ask, and has made a choice seemingly based on appearance and surface functionality.
If you are involved in evaluating different ERP systems for your company, then you need to ask some searching questions of the suppliers you are talking to, before you sign a contract.
If you do not have the experience necessary to know what to ask, here are ten questions to use as a starting point for your evaluation. While the answers may not change your ultimate decision, at least you will be better informed and prepared for what is to come, and in any event, a more detailed response from a supplier should enable you to hold them to account more effectively.
Remember, the general rules for your Invitation To Tender or Statement Of Requirement document are: be specific; pin them down; hold them to account.
1) User Interface versions for Mac and PC
Salesmen are programmed to say yes. While that may satisfy your immediate need to feel that a question has been answered, it is often not good enough.
Consider the difference between these two:
a) Can your User Interface be used on both Mac and PC?
b) Provide details of the User Interface methods available to both Mac and PC users, the versions of operating system on which your UI is supported, and if browser-based, state which versions of which browsers are supported.
The answer to a) is likely to be “Yes”!
In contrast, the answer to b) should be a detailed list of programs and supported operating systems – and if it isn’t, it is likely that the salesman does not know his product well enough, or is trying to obscure a deficiency.
Can the system contain data for more than one company? Many systems will allow segmentation by Division or some other classification that might be fudged into holding more than one company’s data, but such compromises will inevitably result in problems. If you are ever likely to need to add more than one company, make sure the system can segment data at the level of a truly separate legal entity. And if you think you will only ever need one company, consider a situation where you have the opportunity of signing a large client in the same industry as an existing client, for which you need to set up a conflict agency on a demonstrably separate system.
Can the system handle multiple currencies? The answer to that may be our old friend yes, but what are the details? Can you have more than one exchange rate in operation at the same time – if so, how will it be chosen? Can you have separate sales and purchase rates? Can you fix rates on jobs, and assign specific rates to single jobs or groups of jobs by client? Can you control the rate at a transactional level? If you don’t find this stuff out now, and you do significant trade in more than one currency, you may hobble your future month-end efficiency before you have even implemented.
4) Record-level Access Control
Can I control the access of any user to any record? Some systems allow control of access to data at a record level, and some do not. For example, allowing or denying user access to clients, or jobs belonging to specific clients, or jobs belonging to specific departments, or suppliers across multiple companies. I have not come across an agency yet that does not want to allow or deny record-level access to groups of users for many reasons. If controls exist, how easy is it to add or subtract users or records to and from them?
5) Functionality-level Access Control
Beyond user access control to windows within the system – eg everyone should be able to see timesheets, but creatives won’t need to see job estimates – can I control access to the functionality within it? For example, you may wish to allow account managers write access to draft job invoices, but not allow them access to the invoice posting functionality.
6) Double Entry
What double-entry does the system generate in automated journals? This is usually a complex and configurable area of system setup, but you need to understand what it does and what limitations there are. For example, when it generates and posts revenue recognition journals, what do they look like? Ask for illustrative T-accounts for every type and configuration of journal that the system can create.
7) Import Tools
Does the system have native tools that will create, update, and delete records or individual fields of most tables as an automated process – for example, through importing data from txt or csv files? Many systems will have importing facilities for a few key tables, but not necessarily for every table you will want to import to. Ideally, if you want to implement the system properly, you will want the ability to import to most tables, if not all.
8) Automated Build Tools
Does the system have native tools to run batches of dissimilar import programs under automated control, so that a new database can be built from scratch, or a new company can be added to an existing database, quickly and without operator intervention? You will find these tools essential to an efficient implementation, and even more so in the case of implementing a shared-service system.
9) Key Field control
Can key field values be set by the administrator? Database purists will argue that no meaning should be built into key fields and they should simply be values generated by the database software as rows are added to a table. But this ideal isn’t compatible with the real-world implementation methodology of building, testing, and refining a system model several times before implementing it. In this methodology it is impossible to create a set of build files which can be refined and tweaked to optimum if the key field values cannot be decided in advance.
Can the system produce the reports you need to run your business? Reports are the ultimate product from a system, but companies spend surprisingly little time investigating what reports are native to the systems they choose, leaving it to the implementing team to discover what and where the deficiencies are.
Do not buy a system before you know if it can supply the reports you consider to be essential. Create a specification for every report you want, include them as an annex in your statement of requirement, and ask suppliers for sample output of their equivalent reports for you to evaluate.