What to consider when changing OMS / EMS

Our 10 suggestions

#1: Ensure workflow coverage

Take the time to document your workflows in all regions (including the error processes) and go through these in detail with the shortlisted providers. It is likely that vendors may cover workflows differently (or not at all), so it is imperative you understand the impact this will have upon your desk. A common mistake here is to forget about the middle & back office - these need to be included. You should also factor in any plans you have to merge desks or workflows, and ensure the system will give you the flexibility to do this.

#2: Prioritize connectivity

As the main touchpoint with your clients, it is essential to choose the right connectivity partner. The right vendor in this area will ensure a smoother migration process, as well as flexibility for your clients in the longer-term.

#3: Ease of integration

A vendor should provide an extensive and flexible integration option so that they can quickly plug into your other applications eg. reference data, pricing sources etc. You should fully document all the applications you would not be migrating, and understand how the vendor would integrate with them, as well as the various checks which will be required to ensure integrity of data.

#4: Regulation

Given the ever-increasing complexity in this area, you need a vendor who has proven expertise both in the regulations themselves, and in their impact upon global workflows. They should be able to describe in detail how they have handled recent key regulatory regime changes, including the level of support they give firms through such an implementation.

#5: Expertise

Most firms are looking for a true partnership when choosing their vendor, as opposed to an outsourced IT arrangement. For this to be the case, you need a vendor team with a deep bench of experience who understand their domain in detail but also understand ‘why’ the product exists and hence the dependencies.

#6: Vendor strategy & investment plans

You need to be comfortable your vendor is suitably resourced to support your current business and aligned with your future growth plans. To that end, you should ask them to share details such as number of resources in product/engineering (and the direction this has trended recently) and details on their overall product strategy - such as asset class coverage, technology stack refreshes etc.

#7: Modular  

A modular system is generally preferable both from a migration perspective (allows you to migrate functions systematically as opposed to all at once) and from the perspective of allowing you to purchase more or less of the system as your needs change in the future. You should understand how the pricing model aligns with the modules, to ensure you have the level of flexibility you require.

#8: Migration process  

A prolonged & problematic migration process can be both costly, as well as introduce an unacceptable level of risk as you straddle two systems. You need a vendor who has a credible plan (which they have executed in the past with similar clients to yourselves) in order to migrate you to their new platform without disrupting service. You should feel comfortable with the timelines they propose, and how they will deal with issues as and when they arise.

#9: Do vs can do

Vendor platform demonstrations often include items that are not yet in production. Be sure to confirm what is already built and in use vs only on a demo platform. If not built, you should ask for details of the expertise of those building it - ideally you want resources who have experience of building it elsewhere. You should factor this information into any plans you are given on timelines to build out new functionality; experienced resources are essential to deliver a well-thought out system in a sensible timeframe.

#10: Support model

Last, but by no means least, you should understand the support model in detail. Vendors often have vastly different service levels in this arena; you should get information on items such as how support tickets are managed, what the escalation process is, how much transparency will they give you on system root cause & planned fixes, what tools are they offering to allow your teams to work more autonomously.