I was recently involved in a discussion about the changing nature of technology in the context of advisory services, particularly IT Risk and Forensic Technology services.
Now I've been in this arena for nigh-on 20 years – and technology is bread & butter to my work so to have a conversation in which one of the first questions I ask is "have you updated to the latest XXX platform", or "What do you think about YYY version", is perfectly normal.
The response I get is often very similar too either "No – we haven't tested it yet" or "Our procedures were written for version KKK".
Innovation in technology risk/forensic services is being stifled by documentation that is becoming ever more detailed and biblical in scale – and users of it are following more "DO THIS, then DO THAT" instruction. Of course, any failure of the output can then justifiably be blamed on the technology (or the computer O/S, random leap-seconds, etc.), not the provider.
But – as a self-confessed technology "mechan-eek" (I apply the solid mechanical principles of wedging disparate tech stuff together to create geeky new solutions) – I see this as a significant enemy to developing faster & more intuitive ways of doing things.
Given that technology is underpinning more and more services, with the expectation that it will save more and more money, using less and less staff time with fewer and fewer errors – surely I can't be alone in thinking "Wow – we've got these fantastic bits of technology – what happens if I ..."
WARNING: Don't try this at work!
Of course a test environment is a must – no-one wants to blow up customer data, especially in the generally already-stressed nature of Risk/Forensic clients.
But many of my contacts across the industry don't have test environments &/or the time & money to invest in it, so they wait patiently for the next release and its patches and follow the instructions whereas I and my team all take time to play around with the new toys.
With a variety of backgrounds and perspectives, we often co-operatively come up with some new approach which is then tested (see above) and verified against the instructional-output standard results; if it works - reliably & more efficiently than before – then it becomes the new standard (and a short explanatory file note gets added, in case we need to justify our approach).
A small investment of time across a group of people yields far more innovation than a dedicated R&D person given the same time-frame.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
