It's been a busy week here in the spaceship. In my real-life job as an SAP consultant I had a couple of customers I needed to do a lot of work for. Normally this doesn't pose many problems as I have most of the answers either in my head or close to hand. However this week has been a little bit different. I work on a product called the Bank Analyzer that is designed to handle the reporting of finance and risk information for large multinational banks. If you want to line up the buzzwords, then we would be talking about Basel II, IFRS, and other new regulatory changes that are being introduced. I know I've talked about this before, but basically the amount of data that this regulation requires is nothing short of staggering. As a consequence, SAP have been building an analytical solution for this area for the last five years. Now, we have reached version 5.0. If you are one of the few individuals who have been following this blog for a long time, you may have seen my opinions about the life cycle of software before. However, briefly I can summarise it this way, usually version 5.0 is version 1.0 in a new life cycle. I am delighted to find that I have been consistent in this prediction, because the Bank Analyzer is really no different.
What we have now introduced is something called the Integrated Risk and Finance Architecture, which brings together the previously separated worlds of accounting and risk management for banking. The reason this has made me busy however it is that the huge shift in functionality available within the system means that I have to spend a lot of time, particularly when making promises to customers, checking what is actually in the software. I know that there are specifications, and I know that these are what the developers used when they put the system together. However, interpretation is everything, what did the developers actually make of the specification and therefore what have they actually delivered?
This is something that I have talked about briefly in the complex sale discussion before. One of the main tasks of the competent salesperson is actually to understand their own product. This may seem self-evident, but it is amazing how many salespeople don't seem to want to make that effort. Luckily for me, I am a complete geek, and enjoy wandering round talking to Germans about what they have been doing with the coding.
Increasingly I feel that I'm facing a new challenge. The solution that we are selling is moving into territory where we are solving a problem that many people do not realise they have, or have great difficulty in understanding. If I come back to the concept of the Integrated Finance and Risk Architecture, without going into too much detail, it is obvious that personnel from both finance and risk departments in a bank might use a combined solution. There are very sound external and internal business reasons why the combination of these two areas makes sense. The problem is that these two departments have never been aligned historically, and generally from a political and functional point of view have no particular desire to be aligned in future. As a result, much of my current work is not just about explaining why are product meets the need, but about finding convincing ways to explain why the need exists.
It is an adage in sales that the customer knows best, it on the face of it is actually quite reasonable, but with the increasing complexity of different knowledge domains, it is notable that people who know how to do a job have a huge amount of specialised knowledge, but generally a very poor appreciation of the framework in which they work, whereas the management who are supposed to provide a framework, generally do not have enough time or bandwidth to keep up with the enormous rate of change in each of the underlying specialist domains. I am sure that Sig would agree with me that a hierarchy is actually very poor way to manage these kinds of problems, but as long as the budget is released by convincing the upper part of a hierarchy of the lower part needs the solution, then that is a problem that we have to tackle.
I suppose one of the reasons that my job was enjoyable, is that I have to spend my time thinking about how to not only respond to a requirement, but how to persuade people that it exists in the first place. If I were to liken it to the old training model, I suppose my job is turn unconscious incompetence in conscious incompetence, and then sell the roadmap through conscious competence to unconscious competence. In other words, you didn’t know you were unhappy, I’ve told you, and now, guess what, I can sell you the answer to happiness. Only it turns out that happiness is more difficult than you thought.
Such is corporate life.
Comments