About the correct work of BA in a financial institution

Some time ago I decided to get an additional education to the already existing and slightly exhausted master of Systems Engineering. I had to prepare several essays for entering the selected school. Reflecting on them, I greatly exceeded the required 400 words, and so that the good would not disappear, I decided to correct them and post them here.

The topics for the essay are related to my work, so I will further analyze some aspects of business analysis . I hope someone will be interested.

From my own experience I can say that programmers and other software developers do not always understand why we need an analyst on a project . Some familiar engineers often tell me that they can do everything themselves, and they don’t need someone who really doesn’t understand programming who will tell them what and how should work .

In this article I would like to tell you what the "right analyst" should do . Like me, yeah.
')
To begin with, I probably agree that the analyst is not always needed . If you are doing a small project in an area where you are well versed, or if you have a small team and a certain “expert” is always at hand, then you can probably do without our help.

In other cases — for example, if you are reworking a large system, or building something new in the field where you are not quite an expert, the help of an analyst is necessary .

I would also add that analysts are often stupid in the truth. I have come across cases where an analyst writes a pile of unnecessary documentation to anyone, wasting time on it, and distracting helpful staff from writing code. Or, when the analyst, instead of the requirements, describes how it should work — which, in principle, is a very common mistake and a separate topic for the article.

A few years ago I wrote about the role of an analyst in an Agile project . Now I work on a little less Agile, but a more financial project - in one of the largest companies trading in oil and its derivatives, as well as metals and other instruments.

The company has been on the market for more than 20 years, and has grown incredibly since its foundation. As is often the case in such companies, a lot of sistems for different functions are divorced here - like a trade recording system, a risk system, accounting systems, and reporting systems. The company has at least 2 systems for each function, and in some cases 8-12 systems. Often, the systems are glued together by some exeli in shared folders, some exel-macros and scripts, some stored procedures are caused by some self-made programlins.

I was asked to redo the system for managing position and risk for trading in derivative financial instruments - futures, swaps, options, and the list goes on.

Below I have painted the different types of activities that I conduct for this project.

* Define scope

As I described above, the company has more than one system for each function. Some of these systems are supported by IT, so they are relatively easy to identify, disassemble into components and redo. The main problem for me is Excel, and self-made components and all sorts of macro, which are used by traders and risks.

As a result, almost every contact with the user turns out that the official systems are not good enough for some function - either a report in the wrong format, or the wrong unit of measurement, or in general, the wrong model is used or the trade is not supported at all. Each such trouble is resolved depending on the technical knowledge of the given user or the presence of a person to whom the trader can attach its permission. Most often, the solution of the problem is a few flimsy ones which are intertwined with each other, sometimes another local library or database ...

By tinkering with the risk system, one of the questions is “ should the new system replace this Excel? ”. Agree - a difficult question. On the one hand, if this is a flaw in the existing system, the new one should take it into account and correct it. On the other hand, traders love Excel and will never get off it.

There is another part of the problem definition issue. There is a system X and it, among other things, is able to convert psi-lambda into omega-ro. It seems like a useful transformation, but does not work for all the tools, and it is not clear who uses it. No one is recognized, but the task is not easy and it would be cheaper to add this feature now and not in six months.

My task here is to draw the boundary of the system and to ensure that all participants in the process agree with this line - from programmer to Risk Officer.

* Understand traders

No wonder - someone must understand the business of users . To be honest, we and programmers are not bad at all, but are busy enough to deal with the trading processes and Excel.

I remember at the very beginning one trader told me "I have a long scale on the back leg of this spread." Yeah, and another expiration date between the legs.

My task here is to understand what traders and other business users tell me, and translate their requirements into a language that engineers can understand. And back.

* Prioritize

The next point is prioritization. Of course, a software engineer often knows where to start — well, for example, from the most complex, or perhaps the most risky, or from what the rest of the system will be built on. Here I will not advise - all the more so when they do not ask.

But in terms of business, there are also priorities . And oddly enough, they are often mysterious and incomprehensible.

The company where I work is scattered around the world. In each region there are certain features - tradable products, processes, level of reporting and regulation. Accordingly, the breakdown of supply in phases is very logical and preferable.

I always have a question - who is the first ? Do we first develop coal options, or add Forex support? Or maybe you should do sending reports to directors?

There are many techniques to solve this issue - for example, to see where the greatest risk is . Who can lose more money per unit of time - a coal or forex trader? Or, you can see from the other side - if we can get coal support in 2 weeks, and Forex in 8 weeks - what should be done faster?

Part of my work is to provide some figures on the example of those superiors, so that they decide what they think is better. Often, apart from numbers, you need to provide some explanation - for example, how one process differs from another, or one type of trade from another - so that the authorities , far from such details, can draw conclusions . And sometimes it is generally worth thinking a lot - how to make less so that I can get more, and then finish a little so that everything is good. Agree, the programmer is unlikely to want to do such a garbage!

* Organize processes so that “everything worked”

This is quite an interesting item. Changes in the system often affect process changes . Sometimes the process change is quite simple, the process can be changed while learning the system. However, often changes in processes affect many departments in different geographic locations and time zones.

In such cases, it is necessary to begin to examine the existing processes , subjecting all participants to questioning with addiction , and sometimes torture . After this, you should document the existing processes and confirm that the understanding of the processes is quite correct. Later, you need to develop new processes and coordinate them with all the affected parties, make sure that nothing is missed, that all affected systems have the necessary interfaces, and all participants in the process are convincing enough to use them. After that, prepare the necessary documentation and presentations , and finally, train all the participants.

I think, and here you will agree that neither programmers, nor project managers will not want to deal with such a burden.

* Create artifacts for engineers

Here I will not go deep - everyone is familiar with the specifications, us cases, stories and other artifacts.

* Demonstrations, training and UAT

Last but not least, system input in production.

For a start, you have to show it to users. In our company it is a laborious business and takes a lot of time. The fact is that my business users are busy people living in different parts of the world, so demonstrations usually go one-on-one, tailored for this particular user. I'm not even trying to count my man-months spent on it ...

Next - learning. Unfortunately, a specially trained girl cannot be involved in this function - because traders ask tricky questions about their deltas and scales, and often straighten the product for revision. They also have their own spreads, which in the process of learning should be turned into shorts with a slight movement of the hand ...

The most difficult is probably UAT (user acceptance testing). This is when it is necessary to transfer an employed trader from a familiar system (spread or other) to a new and brilliant one. And it pricks, does not give in, and does not converge, and the analyst tries to figure out why everything worked before, and now when he presses - no! There is a delta - 5.2 and there - 5.7 - and under the conditions of stress, under constant mothers, you are trying to figure out - how much is necessary?

And then in the end it is necessary for him to prepare and slip a piece of paper with a list of test scenarios where the trader must sign “Saw, works” - on each item. Fun, in general.

Who is the analyst?