Department Stabilisation

Department Recovery

Problem Resolution
In extreme cases, the Accounting Department, Middle Office, or Risk Department has "fallen over".
We can put it back together.

More commonly, there is just one area which either has fallen over, or is in danger of doing so.
We can assist any level of your staff, or take charge of an area, according to what will work best for you.

Our Excel expertise can be particularly relevant in recovering if a complex Excel file, or set of files, is causing problems now that the original creator is not around.
We repair/rebuild for immediate recovery, and then advise on longer-term solutions to avoid the same thing happening in the future.
We never forget that the future should be robust without our continuing involvement, so we train, document etc before we leave

Reconciliations   For one-off reconciliation projects, we use computer programming to deal with volume.

For recurrent reconciliations to be run by your staff after our involvement ends, we specify, code if appropriate, test, implement, and hand over.
See also our downloadable Excel tool to Match Items from Overlapping Lists.
Complicated statements from third parties are a speciality, E.g. Futures & Options Brokers.

Business Analysis   We have a particular ability to "see the wood and the trees at the same time".
i.e. to clarify the detail while always relating each level to the overall objectives.

Functional Areas: Middle Office, Market Risk, Operational Risk, Daily Reconciliations and Accounting, Month-end accounting processes, Annual accounting processes, Legal documentation etc.
We have a particularly wide range of experience in the Trading Sector, from Exotic Equity Options via Credit Default Swaps to Cocoa Arbitrage.

Our toolkit consists of all good ideas we have come across, many of which we have refined or combined.
And a few that are our own invention.
We are always looking for even better ideas, thinking through whether a given new idea is better or not.
Where appropriate we produce very quick examples showing exactly how a given idea can go wrong, rather than just dismissing it as "different".

Process Improvement   Unless you are a software company, the purpose of using systems is to achieve some process, not the other way round.
The process is owned by staff who use the system, not the IT department.
"I don't understand how the system works" is a recipe for things to go wrong.

So we start with the objectives of the overall process, and break it down into subprocesses.
We provide confidence to users to own their processes, to understand why a given output is important (often to someone else; do check with them) so as to achieve everything they need to with as few steps as possible, and remove any unnecessary elements which have crept in over time.
Then we look at how the existing system can achieve the objectives, whether entering additional data would save time later in the process, whether different static data in the system would help, and if necessary what (preferably minimal) changes in the system would help.

System Specification   When changes to a system are required, we specify them precisely. It is always less risky, and so less work and cheaper, if changes are peripheral, or at the end of the system data chain, so that is often preferable.
But sometimes getting gains requires addressing system elements further upstream.
This is a place where Excel is often most valuable, because it enables one to create worked examples where inputs can be easily changed and outputs verified.
Using Excel as a pseudo-database for production data is high-risk, but using it for prototypes with test data to verify logic and to communicate to programmers is often very effective and efficient.

Systems Usage Optimisation   A common complaint from users is "The system doesn't do X", when with some guidance they will be able to work with the system to do X.
Often systems are capable of providing functionality that is not immediately apparent, by choosing appropriate data, rather than by changing the programming.
E.g. if a system does not have a explicit function for internal trades, will it give us the functionality we need if we create a counterparty called "Internal_Bank" and execute internal trades with it?

System Testing   Parallel Testing used to mean setting up a new system and running it in parallel with the old system (or manual process) for a month/week/day to show what happened with real data and real users.
Nowadays "Parallel Testing" in Google brings up pages describing automated tests running in parallel on multiple machines/browsers.
A valuable technique, but not achieving the same things at all.
Full parallel testing for E.g. a month is nowadays considered too expensive for most projects, especially in terms of user time, because there is no slack in the user base.

But one can achieve something quite similar so long as the interface can be automated: run the set real transactions for last month/week/day through the process.
If that is considered too expensive, then a sensible approach is to run a sample of realistic curreny transactions.
Then do "gorilla testing" - enter extreme values trying to break the system - it is much better for that to happen in Test mode than after going live in Production. A key point is that after a fix is made, all tests (not just those that fail) should be re-run. The scope of that re-running is a matter of judgement. We can help in making this as quick as possible.

What we do not regard as acceptable is the approach adopted by some large consultancies of finding a problem with a type of transaction, fixing it, and re-running for only one example transaction - extreme cases being ignored. We always test thoroughly.

Risk Review   Particularly for Currency Risk, i.e. the effect on value (whether net assets, EPS etc is an important question) of movement in currency exchange rates.

Small Project Management   Almost everything described here is about change, and so is a project.
That means that it is much more likely to go well if we apply some simple project management techniques, E.g. define the objective clearly, describe the steps at a high level and break them down, identify known and likely risk factors, identify the critical path that is likely to determine the earliest possible end date, monitor and measure progress etc.
It does not mean creating lots of documentation for its own sake - it means documenting appropriate to the size of the project to gain the benefits from those who have thought previously.

The fact that we can fulfil roles sometimes performed by multiple people reduces handover risk and time.

Contact Us Site_Notice