When enterprise and government organisations develop their own applications it is usually in response to a lack of an off-the-shelf product to meet a business need. Investigation management is a specialised requirement which can lead to many types of custom processes and software – from spreadsheets to Web applications.

In this blog we will take a look at the challenges and risks of going it alone for your investigation management needs.

Starting small looks promising

A typical approach organisations take when it comes to developing in-house investigation applications involves finding someone known, the “spotty nephew”, and asking them how much it would cost to build a simple system to manage investigations.

The developer then finds a database, or existing app, which looks simple to manipulate and starts adding fields and linking them to other pages with more fields. And in the end you’ve got a case management system.

But cobbling together different systems (client system, CRM, projects, etc) and calling it an investigation management system involves a lot of custom code or custom integrations, which is problematic, even in the immediate term.

This is typical of the mid-market where there is often a mature IT team. Their challenge will not be what is required to build an investigations management system, but to prioritise that above the core requirements of the business they service.

The developers could write a great case management system, but if they are supporting the day to day business of an enterprise they will have constant conflict between the project and their core business. When they need to ask “what do we do?” the focus will always be drawn to the main business.

DIY carries challenges and risks

Many organisations have had no end of trouble with custom-developed software and a DIY investigation management system is even more of a challenge.

Some of the challenges and risks of a DIY approach organisations might not consider include:

  • Total cost. It is easy to underestimate the TCO of a custom app, including the initial development cost and support. Including time spent finding the right technology platform that will actually work.
  • Maintenance. The maintainability of the code or system must be considered. For example, what happens when something needs to be upgraded or reaches end of life?
  • Skills. You need to hire the best people to continue to develop and maintain it and good people are hard to find and keep.
  • Security. There is also ongoing effort for security maintenance, including the security implications of poor practice, vulnerabilities, and compromises. You also need to ensure regular penetration tests and certifications are maintained.
  • Compliance. Underestimating the depth and breadth of what is required for compliance with regulations like the General Insurance Code of Practice. Can DIY keep up with a constantly changing regulatory environment? Yes, but it’s very hard and it is continuous.
  • Emerging tech. DIY requires you to update the platform over the years as technology is always changing. The system will need to keep up with emerging technologies, including mobile, IoT and cloud.
  • Knowledge management. Investigators have a wealth of knowledge, but is this being translated into the DIY product? You need to have everyone involved in the process on board with the product at all times.
  • Data integration. A good investigations management system will collate data from multiple sources and this needs to be factored into a DIY app. See this blog for more on Polonious’ integrations journey.
  • Usability and acceptance. You also need to ensure staff are able to use the product and get business value out of it.

Replace customisation with configuration

Polonious helps organisations that might need a customised app or process for a unique requirement by enabling configuration throughout our application.

We avoid code level “customisation” and focus on configuration, which is the ideal middle ground. If you have custom requirements then you can configure Polonious to meet the need without time consuming and expensive code changes.

Polonious has a common code base that services all customers, from which many customers have configured Polonious to meet their specific business requirements. However, Polonious is constantly adding new features, with further configurability, in response to customer demand and can also deploy new code as required.

For example, Polonious uses the SAME methodology to build out the business requirements of each customer, whether it is for insurance, banking, fraud or complaints. All of the processes are broken down into their basic elements and built up to be compliant with the appropriate regulation.

We enable customers to immediately focus on the desired product, whether it’s case reports, briefs of evidence, end of month or year reporting, and ensure that the data required is collected as part of the business process.

In summary, it is not a question of if an organisation can or cannot develop their own investigations system, but the time and materials required and ongoing investment often far outweighs any benefit. Failing to keep up with regulatory requirements is also a continual risk.