International Payments Ops workflow redesign
The challenge
Project-level
Our International Payments ops teams used 6 systems that presented the following challenges:
- Legacy tech, which created a high development overhead for new functionality – affected exec scorecard metric.
- Lack of payment validation checks, presented the risk that high value payments would be sent to the wrong recipient with no guarantee of retrieval.
- Unnecessary manual work that results in higher FTE head count -
e.g. data was sometimes incorrectly ingested when passed between systems so required manual intervention. - Difficulty cross-skilling or utilising resources across ops teams - ops systems are all very different.
I was engaged to create tactical wireframes. However, I advised our initiative partners that we needed to ensure the longevity of the backend architecture AND customer experience by accounting for ALL systems and a cohesive customer experience from the start.
My product partners eventually agreed to this approach.
Design approach
Sell in Discovery. 3rd time's a charm.
I attempted to sell in Discovery 3 times.
For the 2nd attempt: I met the Senior Product Owner, Product Owner and Lead Business Analyst to walk them through the Discovery activities and process. They communicated that their top 2 priorities were to meet compliance deadlines and ensure the backend architecture was future-proofed.
I revised my pitch with a peer, and went back to them with the following key rationale:
For the 2nd attempt: I met the Senior Product Owner, Product Owner and Lead Business Analyst to walk them through the Discovery activities and process. They communicated that their top 2 priorities were to meet compliance deadlines and ensure the backend architecture was future-proofed.
I revised my pitch with a peer, and went back to them with the following key rationale:
"In order to future proof the architecture, we need to know the future state design is because the design dictates how we'll build the architecture in the longer term. We can discuss this approach further with [our Lead Architect]."
They agreed to invest in a 3 week Discovery Sprint.
Determine scope
After interviewing a senior ops team member to understand the foundational aspects of ops - systems, team structure, KPIs, pain points, jobs-to-be-done - I worked with the Product Owner and Business Analyst to decide which systems to focus on for a 3 week Discovery sprint - we couldn’t get across all 6 in-depth the timebox.
We chose eOCP and ITF because they were:
A) the most used systems, and
B) Because one had the least amount of dependencies on other systems, which increased the chances of shipping a release sooner.
We chose eOCP and ITF because they were:
A) the most used systems, and
B) Because one had the least amount of dependencies on other systems, which increased the chances of shipping a release sooner.
Review current state
I did lightning downloads with our BAs as they’d had a strategic head start in discovering the systems we consolidated.
Example insight:
Example insight:
A key scenario where ops need to initiate a payment:
The FX markets are closing for the day, and the customer needs to make a high value or crucial payment (e.g. to honour a contract)
via a system that doesn’t permit straight through processing.
Ontology mapping
Ops speak and operate in a whole other language and world.
Example:
Example:
“So using PACs terms, for Day 2 payments we can add the full range of instructing or instructed agents in ITF the way we could if keying a message manually for MT104 and 103s.”
- Senior Analyst, International Payments
By systematising the complexity, I could better articulate how to connect the different aspects of the customer experience together AND provide foundational knowledge for how we might phase the approach with the Product Owner.
Async pain points exercise
I sent out an sync task below to inform the current state customer value map.
Stakeholder interviews
I interviewed the Heads Ofs, execs, retail and backend individual contributors.
For senior leadership stakeholders I focussed on KPIs, $$$s and the wider market.
For individual contributors, I focussed on jobs-to-be-done, learning ops concepts and questions from the pain points exercise that needed further clarification.
Example insight:
For senior leadership stakeholders I focussed on KPIs, $$$s and the wider market.
For individual contributors, I focussed on jobs-to-be-done, learning ops concepts and questions from the pain points exercise that needed further clarification.
Example insight:
“We had a $(5-figure) loss in one day from one generic non-validation issue.”
Consult analytics
I requested everything from average time to complete key tasks, customer segments, volume and $ value of payments on the different ops systems to
A) Gain a baseline for the current state customer experience, and
B) Inform the business case with numbers around $ loss risk for each platform.
A) Gain a baseline for the current state customer experience, and
B) Inform the business case with numbers around $ loss risk for each platform.
Concept and recommendations
The stakeholder feedback was that we needed to quantify the impact of some of the pain points:
e.g. What’s the time / cost associated with the workflow disruption pain points if any? Given the short timebox, we hadn't yet explored this in detail.
e.g. What’s the time / cost associated with the workflow disruption pain points if any? Given the short timebox, we hadn't yet explored this in detail.
Outcomes
Business case-level
A clearer cost out number was articulated to rationalise a higher $ value business case.
The working group shifted towards product-focussed outcomes instead of just a blind re-platform of everything.
The working group shifted towards product-focussed outcomes instead of just a blind re-platform of everything.