Front Office and Back Office Fund Management Software–To Integrate, or not to Integrate?
In our industry, we certainly encourage fund managers to adopt technology that makes them more efficient and that streamlines their processes. When managers contemplate integrating front office and back office systems, however, efficiency shouldn’t be the only goal and a good case can sometimes be made for looser integration, slightly more time-consuming processes, and added security measures.
There are a number of reasons that you wouldn’t want to have front and back office systems in the same application or even in tightly integrated applications. Back office systems need to perform a different function than their front-office counterparts so they need to be more rigid in terms of how information is entered, who has access to the data, and who can edit the data. If you aspire to have front and back office functionality in the same system, enforcing that rigidity should be a primary concern.
I think in general the fund management software industry–and specifically our company App-X–is moving towards having front and back office functionality in the same application, albeit with very stringent controls. Until that time, having separate front and back office systems that coexist efficiently but are not part of the same application can be an effective way to draw a line in the sand. With separate systems, there’s an opportunity for the front office to prepare information and have information organized in a way that makes it easier for the back office to get data in the system. For instance, if you’re tracking fundraising progress using a front office system, you are likely tracking conversations and other communications with LPs and you can gather all of that information in a front office system right up to the point of the execution of an LP agreement in an organized fashion. Then that LP’s information can be more structured and can provide for an easier handoff to the accounting system. I don’t think fund managers would necessarily want that fundraising data to go directly into the accounting system without a system of checks and a balances so it’s important to allow a CFO or someone in a similar role to at least be able to approve the data that’s getting pulled in.
Going the other way, there may be advantages on the investing side to taking data out of the accounting system and feeding it directly into a front office system at a summary level. Data on cash flows and actual dollars invested, for example, at a summary level can be pulled into a front office system and provide meaningful information without running the risk of the data being changed or accidentally deleted. Additionally, providing summary level data is likely to require less in licensing costs than providing more granular access to a user who only needs to see summary level data.
So then the question becomes how to move data from one system to the other. It really depends on the capabilities of the two systems–some systems require you to use excel as a conduit for moving information between systems; some systems will allow you to schedule a report to run and be imported automatically. What we usually tell our clients when it comes to automating data transfers between systems is to walk before you run. In other words, don’t try to automate something until there is a real business case for doing so. If you’re moving monthly or quarterly numbers, it’s not likely to take one employee more than an hour or so once a month. Compare that to the number of hours it would take to set up the integration and the reasons for integrating become less compelling.