{"id":4637,"date":"2021-03-02T13:08:49","date_gmt":"2021-03-02T16:08:49","guid":{"rendered":"http:\/\/localhost\/britech-old\/?p=4637"},"modified":"2022-02-07T13:20:18","modified_gmt":"2022-02-07T16:20:18","slug":"areas-to-consider-when-implementing-new-solutions","status":"publish","type":"post","link":"https:\/\/britech.global\/en\/blog-en\/areas-to-consider-when-implementing-new-solutions\/","title":{"rendered":"Areas to consider when implementing new solutions"},"content":{"rendered":"

Part I.<\/strong><\/p>\n

In this paper we are going to highlight what it involves when implementing new systems from software providers that offer packaged software products developed as a general end-to-end solution for a specific sector, the so-called software \u2018as is\u2019.<\/p>\n

Implementing software \u2018as is\u2019 on premise or in the cloud can be a relatively easy task, since the software requires configuration based on standard templates. By parametrising the templates, the new solution becomes your environment with your company attributes and look and feel. This is a very important assumption to consider since the very reason why an Investment Management organisation has decided to acquire a well-designed, ready-to-use, out of the box software was to avoid a costly and lengthy customisation and development project.<\/p>\n

However, in almost any situation, there is indeed a need for customisation and development.<\/p>\n

The reason for this is to be found in the peculiarities of each Investment Management organisation, its history and its specific unique proposition to its market place that will undoubtedly require adjustments and additional features in order to cover all special aspects required by the organisation for providing its services.<\/p>\n

Also, it might be that the organisation is serving in a specific jurisdiction that is not provided by the software package.<\/p>\n

There are additional aspects to take into consideration, for example:<\/p>\n

The connectivity with custodians and brokers needed to automate the new environment and which may not be readily available within the software package.<\/p>\n

The historical data that needs to be migrated from legacy system(s) and which need to be made available somehow in the new software solution in order to provide reporting to clients.<\/p>\n

Last, but not least, organisations may have additional requirements which are critical and a must to have to operate the business and that require software development.<\/p>\n

Therefore, it is very unlikely that an organisation can implement the software solution \u2018as is\u2019 without requiring any adjustments, customisation and some development. Especially in Europe where many jurisdictions, regions do have their own way of operating, managing customers, deal with local regulations and customs, even though the majority of the countries have complied with EU directives and EU regulations.<\/p>\n

Mr. Pablo Garc\u00eda-Drake from Varianza, one of our customers in Spain, is sharing his experience in implementing our solution as highlighted in the comments below;<\/p>\n

 <\/p>\n

Pivolt implementation: Varianza\u2019s experience<\/strong><\/p>\n

\u201cRight after deciding that Pivolt would become our new portfolio management solution, we had to consider some other points that would affect and define the implementation process.<\/p>\n

Firstly, we decided that we would bring to Pivolt all the historical data that we had in our former database, instead of cutting the data at a given date and upload into Pivolt only the current positions at that time. The main reasons to migrate all the data were to provide our clients access to their historical portfolio data and, of course, this migration should not be disruptive to them and on the other hand we did not have a \u00a0very long history in our records (our portfolios had 4 years of activity).<\/p>\n

Secondly, we knew that the implementation would be smoother than usual due to the number of templates that Pivolt offers by default and their dedicated team that gives support to the whole process.<\/p>\n

We then divided the implementation in two phases: static data migration (client data, asset data and categorization, prices) and portfolio history (transactions, events). This way we would ensure the readiness of the system and avoid rejections when importing data. In our opinion, it is key to spend sufficient time gathering the data from the former software and understanding the format of the templates before uploading anything into the new system. We worked on this while the team were working on the pre-implementation developments (some specific features needed to run Varianza\u2019s daily business).<\/p>\n

During the implementation itself, although we had no choice, we would suggest that the number of people involved is kept to the minimum. This will help to have a clear picture of the template versions that are exchanged between the two organizations and avoid duplications and\/or missing data in the migration.<\/p>\n

Last, but not least, before going live we performed a monthly reconciliation for every portfolio and the data we migrated, leading to only a few corrections. Also, we ran the two systems in parallel for almost three months, which required some more work during that time but provided enough comfort to go live.<\/p>\n

In Part II of this article we will dive into the challenges regarding:<\/p>\n