If you have ever done a job search in the SAP area, you might notice that recruiters often split vacancies into two categories: technical and functional.
Who are they, those technical and functional people?
Frankly speaking, a functional consultant is the person who deals with the functional configuration of the SAP system, with business processes in different areas. It can be Finance, Logistics, Authorisations and so on. On the other hand, technical consultants are those who deal with levels below the business process: programming, system administration and so on. Mostly this means ABAP and Basis people.
However, sometimes I saw requirements, and you could see them too, for “technical Finance consultant”. I will assume it reflects the limitations of a recruiter who probably does not know the market very well. If you learn what it means – feel free to comment below or write to SAP Expert.
In the meantime, I think that the functional/technical categorisation misses at least one important component. It is another level of consulting skills, less often mentioned: solution consultant.
Who is a solution consultant? This is a person who sees the question in a wider sense than it was asked, and presents a solution that answers the question and also gives customer the best experience.
I was recently involved in an interesting conversation about one particular problem in SAP Finance, and this can be an example of the differences between Technical, Functional and Solution consultants.
Someone asked the following question.
Our company in Canada has a requirement to store bank details with a length of 21 characters, consisting of a 12-digit account number and a 9-digit routing number. How can we achieve this in SAP?
To give you some background, SAP’s standard field for bank account number is 18 characters long.
The answers in the conversation clearly differentiate between approaches. Of course, I have re-compiled them slightly from the original words of the conversation.
Let’s now analyse the difference.
|As a rule of a thumb,
SAP standard objects!
The answer provided by the Technical Consultant was to increase the length of the SAP standard field in the table that holds bank details (namely LFBK). However, this is not the only table that would require the change, simply because bank information is copied across to different tables when a payment program runs: REGUH, PYORDH and so on.It means that these tables will require changes as well. Together with them, all the programs that move data between the tables may require re-visiting and checking for the field definitions. Add here the necessity to revisit the DMEE engine structures that may use bank details to produce payment files. And because you are changing SAP standard objects, you risk losing support if anything happens with the system or data. This is a snowball, isn’t it?
A Solution consultant does not simply answer the question “how to put a 21-digit number into an 18-character field”, but gives the solution that allows storing data properly and is future proof.
Who are you: functional, technical or solution consultant?