GUEST BLOGGER: Nicholas Bull, Systems Developer, Veale Wasbrough Vizards (VWV) offers 7 useful tips for developing with Lexis® Visualfiles™
At Veale Wasbrough Vizards (VWV) our Accounts team recently changed their method of client payment from cheques to BACS. This change then had to be replicated through to our debt recovery system which is driven by Lexis® Visualfiles™. From the outset there was a lot of work involved analysing, identifying and reprogramming the various debt applications. As a result, the process of sending payments has been reduced from 7 days to less than one day with minimal user interaction. As a firm we use a number of case management systems, but none provide the toolset and flexibility of Visualfiles.
All in all, reducing the amount of manual labour involved has freed up our Accounts team and our Lawyers so they can concentrate on other more important tasks. It has also reinforced our core value of putting the client at the centre of the firm, by having a process that enables them to receive money due as quickly as possible.
The overall benefits to VWV
- Speed – the client has their money transferred into their bank account and remittance advice is received the same day. No waiting for cheques to clear.
- Security – sending a BACS payment is less likely to go missing like a cheque.
- Cost – it is a lot less expensive to send a BACS payment than it is to raise a cheque. Also, the cost of paper, envelopes and stamps has been eliminated.
- Time saving – lawyers no longer have to sign hundreds of individual cheque requests, cheques/remittance advice letters no longer have to be printed and envelopes no longer have to be filled.
Here is what I would recommend when re-engineering a process such as the above
- DO spend time planning. A lot of developers develop a minimal prototype and build out. Spending some time brainstorming about all possible eventualities will benefit you in the long run and you will have a more complete model from the word go.
- DO sit in the department and analyse how the users work. Having meetings to discuss working practices is nothing compared to observing and documenting how people actually work (you can even provide a few shortcuts to speed up their working day). Encourage feedback and engage with the matter subject experts from day one.
- Do (when speaking to users) use their language. Don’t speak in ‘IT’ as users disengage quickly and don’t always understand.
- Do document everything. I cannot stress this enough. Most developers think their code is self-documenting. Wrong. By documenting you will save yourself hours of debugging – and it’s not like it’s hard, just type the documentation straight into the script.
- Do analyse the level of risk involved in changing from one working practice to another. Can it be changed in one go? Can you change a number of clients over to test before rolling out to the rest of your clients and therefore prevent the exposure of any major potential bugs?
- Do spend some time thinking about the various Visualfiles commands. Sometimes the use of a different command can save hours of programming.
- DON’T promise the users the moon on a stick. You can only do what you can. Have a clear set of project objectives that you can deliver against. Anything that isn’t on the list can be swept into a second phase or another project.
Once the above guidelines are in place (and you try to adhere to them) you will find that developing any process is a lot less painful. Again, this might not suit every practice but it certainly works for us.