SAP: How to write a Report Functional Specification

Chapter Three - Who will use it and How?

Specs can be thorough and complete, but are not any use if nobody reads them. You want your spec to be accurate and up-to-date, but also easily understood by the numerous people, job roles, and teams that are going to refer to it at various points in the project life cycle.

Let’s take a look at who they are and why they are interested in your design:

Peer reviews – I’ll talk about this in more detail in Chapter Seven. Your functional spec is going to have to be read and approved by multiple people. Often a more senior consultant or team lead will do an ‘internal team’ quality check on it. They will be looking to see that the design is appropriate, the various sections of the functional spec are complete and that the spec is of a good enough standard to pass the next level of quality checks. No-one wants to let shoddy work through to the next level and then get blamed for not doing their job properly!

Sometimes when the consultant writing the spec is based offshore, an onshore consultant is assigned to review the spec before it is approved for the Design Authority or Architect to give the final sign off. Again, in addition to checking the content of the functional spec, the onshore consultant needs to make sure they point out any gaping holes in the information presented, ensuring that the design meets the requirements originally identified.

Design Authority Architect Program Manager – Depending on the size of your project team, you will have one or more of all of these roles represented! This is the person or people that have the final say on whether your design is the right one to meet the user requirements, whether it’s been described in sufficient and clear detail and so on. If you have gotten it wrong, it’s this person that will take the brunt of it if they don’t pick up on the misunderstandings or errors when reviewing the spec.

Security Team – Those wonderful people who create job roles and assign authorizations and restrictions to user ID’s will probably be interested in your spec if you have defined a new transaction code to run the new report. They may only read the ‘Overview’ section and the relevant section in the spec that describes the security aspects, but often the Technical Build Team cannot begin without having a sign off by the Security team first.

TOP TIP If you are lucky enough to be working in a small project team without such rigid sign off processes, when you write the security section of your functional spec, take ten minutes to run it past someone in the Security team. You can do this either in person or by email, just to make sure they are aware of it and that you have included the details that they need to make it happen. They usually appreciate the ‘heads up’ and will be more inclined to help you out with testing roles for the various environments when you need them!

Technical Team – This is a small heading for what could be a number of people wanting to understand what is in your spec! During the spec writing phase, you may have already spoken to someone in the ABAP development team to check your ideas or help you prototype if it is something very different or complicated. If not, the first time the technical team have seen the detail of your design will be when you send them a copy of your spec. They will be checking to make sure it’s understandable, complete, and includes sample data and process steps for them to use in their build and initial testing stages.

Other Functional Teams – If your report is solely for use within the Finance Team for instance, then your spec may not be of interest to other teams working on other modules. But if for example it retrieves sales data for reporting with Accounts Receivable information, you may want to bring it to the attention of the Sales and Distribution Team and ask them to have a quick read through of what you have designed.

I have often found that making the other teams aware of my design that might impact on their areas was very useful for flushing out any incorrect assumptions on my part, or streamlining the design because I wasn’t fully aware of the functionality available in those other teams and they were. So think through any integration points with other modules and pass your spec to them once your design has been drafted to see if they can highlight any potential issues or make suggestions for improved design.

TOP TIP A good Consultant is constantly improving and not afraid to ask for input or feedback.

*************************************************

Previously, I worked on a very large project team within the Distribution team. There was a separate team responsible for ‘Sales’ that took care of everything from enquiries and contracts through to sales order processing, and then the subsequent billing functions. Another team looked after the Logistics Supply Chain functions, such as warehouse activities, materials management and stock planning. Our Distribution team were responsible for the deliveries and transportation shipment processes, whether they were from a Sales process, or a Supply Chain process. It was a busy project and as consultants, we only had time to be aware of the design in our own specific team.

One day, I received an email from a junior consultant in the Logistics Supply Chain team with his draft functional spec attached, asking me to have a quick read through and let him know if it impacted on our Distribution design in any way.

From his Overview and process flow model, I could see that he had a business requirement for a month end report to analyse certain stock movements. His detailed design was proposing to capture specific information into a custom table, using the user exit at Post Goods issue of an outbound delivery. On first reading, that sounded okay and his own Peer Review had agreed the design but thankfully this consultant was brave enough to ask for our team’s feedback! Had he gone ahead with his design, we would probably only have noticed during Acceptance testing when his user exit slowed the goods issue of our 5,000 deliveries a day to a standstill!

As his report requirement was for a month end timeframe, it was not critical that his custom table be updated the very instant that a delivery was goods issued, and given the volume of transactions being processed, his initial design would have caused us terrible performance problems! Instead, we were able to talk him through some alternative designs that wouldn’t impact performance. He settled on using a background job that ran nightly to pull the relevant goods movements from the Material Document table MSEG and update his custom table accordingly.

It only took an hour or two for us to review his design and make the alternative suggestions, and required only a little re-work on his part since the Technical Team had not yet started development. A whole lot less re-work than what would have been required if he had not brought it to our attention during his Review process!

**********************************************************

Key Business Resource – Often the original requirements are sponsored by a particular business area or resource. I’ve found it really useful to schedule a short review of my design with that business resource BEFORE I push the spec through for final signoff. This is sometimes easier to do than others, I admit!

If a business contact has been named as ‘owning’ the user requirements, then I try to have a ten minute conversation (or online conference if face to face is impossible) with them to run them through my design in a high level. I don’t mean talking them through the spec word by word. Most of the detail in the spec isn’t relevant for them. What they want to know is that I have understood their requirements, that I understand how the report is to be used by the business, and that the report they will end up with meets those requirements.

I concentrate on the overview. I list for them which business processes I think are relevant and ask if I have missed any, and I explain at a high level how I see the report will be run, how often, and what the output will look like. Obviously I can’t show them anything in SAP yet but I will probably have a PowerPoint mock up showing the columns and contents, selection screen and so on. If I’ve gotten something glaringly wrong or I have missed something out completely, this review will let me know. It is more direct than just sending them a copy of the functional spec and hoping that they read it, assuming ‘no response’ is acceptance of it!

TOP TIP If you feel uncomfortable about doing this kind of review with your Business Process Owner or maybe that it is not your position to contact the business resource in this way, suggest it to your Team Lead or the Design Authority. Explain how you see it could be very beneficial in the long run to get this informal ‘okay’ of the design now, before the Technical team begin developing it.

Training Team – As mentioned in Chapter Two, when you design a new report, someone will have to figure out how to train the end users who might have to run it, monitor it, or use its output. They often won’t become aware of its existence until well into the testing phases, long after you have moved onto writing your next specs!

If you’ve done a good job of making your spec understandable and describing how it will be run and so on, then the Training Team can make a start by reading your spec.

If your spec is complicated or hard to follow, they will probably give up and just come and demand your time to go through it with them in detail, most likely at a time when you are very busy working on something completely different.

TOP TIP It’s in your best interests to put the effort in when you are writing your spec to save yourself time and repeated effort later on! It will also make you stand out as a ‘good’ consultant and your reputation for producing good quality professional work will grow!

Go Live Cutover Deploy Team – On smaller projects, I’ve been involved in the design, build, test and then deployment of the functionality in my functional specs. That is great when it happens as you get that feeling of satisfaction to see something you’ve created going all the way to being used in a live environment.

But sometimes that isn’t the case. Maybe you have changed roles within the project team, or moved onto another project team altogether before your report goes live. Or maybe there are teams of people whose responsibilities are very specific to just this part of the project life cycle. If this is the case, or indeed if there is a chance you may not be around to push this new report live yourself, then you need to ensure that the relevant and critical pieces of information for those activities are summarized in your functional spec.

TOP TIP At a glance, I should be able to pick up your spec and understand from the overview what the report is and how its used, and then from the deploy section, what prerequisites I need to have in place for the end users to successfully use this report in future.