While interviewing a candidate with 3+ years of SAP experience for functional consultant position I asked him a very typical question.
Have you ever worked on functional specifications?
"Yes many" prompt came the reply.
What was the requirement for which you wrote the specs?
"Humm I am not able to recall the exact requirement. I only did some configuration in that. The functional specs were written by someone else from onsite."
How can you do configuration in functional specs. Can you give
me some idea of the requirement?
Now the candidate was totally on defensive. He answered. "I haven't worked much on functional specs. I just have an idea about the functional specs."
Needless to say the outcome of the interview.
Sounds interesting?
But its true that based on my experience around 90% of the candidates for SAP functional consultant position have heard about functional specs. Around 20% have actually worked in some or the other form on them. However not more than 5% has actually worked independently and of those half of them lack the correct procedure to write them.
Functional specification comes next only to configuration when it comes to functional consultants job and without mastering it your SAP experience is incomplete. A poorly written functional spec creates big communication issue between technical and functional consultant and the matter is further compounded when they are not sitting at same location. You can only imagine the mess it will create if the functional spec is not properly written and the technical guy is sitting in different country and worse still his spoken English is not good (eg Chinese, French, koreaian etc etc).
Functional specs are written when the standard SAP is not able to meet the client's requirement. Based on the functional spec the ABAPer will write the technical design doc. and then the functional guy will test the same in the system and document the results in his test script.
We come across 3 situations which calls for functional specs to be written
1. Enhancements /modifications - If business requires some special procedure.
2. Reports - Client's customized reports.
3. Interface - EDI interface involves ALE/IDOC.
Here are some tips to write great functional specs. The objective should be that the technical guy should understand it in one go and to reduce any further clarification.
1. Understand the requirement completely. This will depend on your business understanding. Make sure that the client's requirement cannot be met through standard SAP before working on it. Please suggest the client if any alternative business process which is supported by SAP and meets his requirement too.
2. In case of reports you must be competent to decide whether it's a R/3 or BW report. one example - if the report involves data analytics (like you do in pivot table of excel) it will be a BW report. However its data collection will be done in R/3.
3. You must mention the business need and business value the report/enhancement will add to the business. This is for future reference and also to convince the other users.
4. Any legacy system changes to be done once the enhancement/report is run should also be mentioned. You can mention changes regarding business process or data. This may be an input for change management team and also for cutover strategy.
5. In case of interface please do mention if it's a display or non display document.
6. Please do not write the structure in place of table and field. Make some effort and find out in which field the data is stored. ABAPer will appreciate it.
7. Don't just write table and field name but also give the data pulling logic. This is perhaps the most important part. At times it is really difficult to make the technical guy understand how the data is getting pulled. Without understanding this he can't proceed further. For example
Target quantity - PACKPO-TRGQTY needs to be transported to Rounding quantity VBAP- ABLFZ
The data pulling logic for the same will as follows
VBAK-VBLEN doc cat E= VBAP-VBLEN
VBAP-MATNR= PACKPO-MATNR Item cat M
8. Be careful about the data volume while designing the input screen of a customized report. You must very carefully decide which of these should be mandatory and optional else it will create a performance issue at the time of load testing.
Please note that every implementation has its own unique format for writing functional specs however the above mentioned points needs to be covered to make it more communicative and effective.
Have you ever worked on functional specifications?
"Yes many" prompt came the reply.
What was the requirement for which you wrote the specs?
"Humm I am not able to recall the exact requirement. I only did some configuration in that. The functional specs were written by someone else from onsite."
How can you do configuration in functional specs. Can you give
me some idea of the requirement?
Now the candidate was totally on defensive. He answered. "I haven't worked much on functional specs. I just have an idea about the functional specs."
Needless to say the outcome of the interview.
Sounds interesting?
But its true that based on my experience around 90% of the candidates for SAP functional consultant position have heard about functional specs. Around 20% have actually worked in some or the other form on them. However not more than 5% has actually worked independently and of those half of them lack the correct procedure to write them.
Functional specification comes next only to configuration when it comes to functional consultants job and without mastering it your SAP experience is incomplete. A poorly written functional spec creates big communication issue between technical and functional consultant and the matter is further compounded when they are not sitting at same location. You can only imagine the mess it will create if the functional spec is not properly written and the technical guy is sitting in different country and worse still his spoken English is not good (eg Chinese, French, koreaian etc etc).
Functional specs are written when the standard SAP is not able to meet the client's requirement. Based on the functional spec the ABAPer will write the technical design doc. and then the functional guy will test the same in the system and document the results in his test script.
We come across 3 situations which calls for functional specs to be written
1. Enhancements /modifications - If business requires some special procedure.
2. Reports - Client's customized reports.
3. Interface - EDI interface involves ALE/IDOC.
Here are some tips to write great functional specs. The objective should be that the technical guy should understand it in one go and to reduce any further clarification.
1. Understand the requirement completely. This will depend on your business understanding. Make sure that the client's requirement cannot be met through standard SAP before working on it. Please suggest the client if any alternative business process which is supported by SAP and meets his requirement too.
2. In case of reports you must be competent to decide whether it's a R/3 or BW report. one example - if the report involves data analytics (like you do in pivot table of excel) it will be a BW report. However its data collection will be done in R/3.
3. You must mention the business need and business value the report/enhancement will add to the business. This is for future reference and also to convince the other users.
4. Any legacy system changes to be done once the enhancement/report is run should also be mentioned. You can mention changes regarding business process or data. This may be an input for change management team and also for cutover strategy.
5. In case of interface please do mention if it's a display or non display document.
6. Please do not write the structure in place of table and field. Make some effort and find out in which field the data is stored. ABAPer will appreciate it.
7. Don't just write table and field name but also give the data pulling logic. This is perhaps the most important part. At times it is really difficult to make the technical guy understand how the data is getting pulled. Without understanding this he can't proceed further. For example
Target quantity - PACKPO-TRGQTY needs to be transported to Rounding quantity VBAP- ABLFZ
The data pulling logic for the same will as follows
VBAK-VBLEN doc cat E= VBAP-VBLEN
VBAP-MATNR= PACKPO-MATNR Item cat M
8. Be careful about the data volume while designing the input screen of a customized report. You must very carefully decide which of these should be mandatory and optional else it will create a performance issue at the time of load testing.
Please note that every implementation has its own unique format for writing functional specs however the above mentioned points needs to be covered to make it more communicative and effective.
Seeking for SAP Singapore, reach us Alenu Group Now! at (65) 6884 5030
No comments:
Post a Comment