Fuzzy Job Description of a SAP Developer
Tony Beyer

Their name, which is short for "Systems, Applications and Products in Data Processing, may not be catchy--but if you work in the field of enterprise resource planning (ERP) software, you know who SAP is.  SAP is the world leader in ERP software, holding a 33% market share according to a recent survey. 

What makes SAP different from other ERP systems is its wide bandwidth of functionality.  While PeopleSoft might have the best human-resources package, for example, or Manugistics the best forecasting package, many people feel that SAP does the best job of offering the broadest range of excellent products and services, across more industries, than any other company in its field. 

This same versatility, though, makes giving advice about working with SAP  a challenge. With so many options, where do you begin?  Whose perspective do you use?  What area needs the most concentration?  In this article, I will describe some aspects of SAP from an independent consultant’s perspective.  I'll attempt to provide some insights to important elements for success on a project--and propose ideas for enhancing your experience and improving the results of your work. 

The essence of any SAP project is configuring the system to facilitate the transactions needed to run the business.  Your understanding of the functional and technical aspects of SAP, therefore, has to be connected with your users’ knowledge of the company’s business processes: the mountain range of details about how the system will support customers, vendors, products, services, partners, employees, materials, planning, reporting, and more.  This, obviously, requires a massive and time-consuming effort.   You'll need to perform extensive testing and quality checks before "going live" to ensure that the system is designed properly, convert master and dynamic document data, turn on interfaces, and more.

But what principles will help you get to  the point where the system is ready to run the daily transactions needed to support the business?  Here are some important questions to ask that will help you apply your knowledge successfully when working on an SAP project (in fact, many apply to any consulting situation):

·        How do I fit in to the project?
What are the business processes?
Who are the business owners?
What is the project methodology and documentation?
What is the testing strategy?
How is communication managed?
How is training and change management delivered?
How can I maximize your effort?

How Do I Fit In?

The size and complexity of SAP itself is often mirrored by the number of people involved in the project.  SAP projects are usually run by large consulting companies, in conjunction with representatives from the client company.  Add up the people involved with initial implementations, upgrades to new releases, adding special functionality or new modules, interfacing with vendor or customer systems, interfacing with other divisions within the same company, and so on, and you often end up with an unwieldy project team.

This situation poses two tasks, one of which is fitting in personally with the team environment.  You'll need to get a sense of not only where you fit within the team, but where your team fits within the total project (since your team's work will almost always affect that of other teams, and vice versa).  As a newcomer thrust into the mix, your immediate challenge will be getting up to speed as quickly as possible, proving yourself as a valuable team member even as you're still deciphering the state of affairs.  Your success will depend on how well you demonstrate not only your skills to accomplish tasks, but also your understanding of the politics of the client and other consulting companies on the project.  When you're struggling to get on someone’s calendar for a meeting, balance your desire to keep things moving forward with the recognition that most project members are strapped for time--and the awareness that when you’re in someone else's house, you need to go by their rules. 

The second task is figuring out how to make your project fit with the client company's way of doing things.  Since each company is unique, you can expect to design plenty of non-standard business processes, from interfaces to reports, labels and outputs, web applications and EDI, and master data conversions.  These special requirements are usually managed by creating functional and technical specifications that (1) describe the work needed to accomplish the need, (2) design the solution, (3) program the solution, (4) test it, and (5) implement it. 

What Are the Business Processes and Project Methodology?

Most projects use the Accelerated SAP (ASAP) implementation methodology--or at least portions of it--for gathering requirements, defining the scope of what functionality will be used, defining the business processes to be used, translating these into the needed transactions and functionality, developing test scripts and training documents, and documenting decisions made along the way.  This is an effective way of leveraging SAP’s years of knowledge and experience from past implementations.  With many templates designed to save time and effort in building the system, ASAP is a valuable tool to communicate to all team members, and it is especially important to new people on the project.  But it's important to remember that although ASAP is used in conjunction with project management, it is not a substitute for project management.  

ASAP methodology may suggest, for example, that team members who are familiar with the company’s business processes set up the system by defining key values in configuration tables, then assigning them to the respective business processes in other tables (e.g., a special order type can be defined for full truck-load orders, then assigned to a specific sales organization that needs to use this type of order).  But skillful project management is necessary to ensure that they achieve the goal of  configuring the system so the users can quickly execute their daily transactions with a minimum amount of manual entry, and a maximum amount of automatic processing.  

Who Are the Real Business Owners?

Another key element of project management is defining the real business requirement within each specification if custom programming is required.  Bad specifications result in work that has to be redone, lost time, and unhappy customers.  Many times, however, specifications are faulty because someone only defined part of the requirement, or did not define it clearly. 

Be aware of the possibility that the customer may have a vested interest in the design of some functionality, and this may affect your requirements.  For example, the customer may be using your outputs or reports to help with some aspect of their business process.  On one project I worked on, a major customer compared and reconciled invoices with packing slips before paying each invoice; as a result, we had to re-design and add more data to the invoice to satisfy this business need.  When you are working with processes that affect the end customer, it’s a good idea to get their feedback on how they are using reports and outputs and other data that you are giving them--you'd much rather make changes to accommodate these uses during development than do it afterward.

Here are some ideas to avoid the  nightmare of "going live," only to find out that the specifications writer didn’t really understand the full business process and requirement:

·        Have key business owners review and approve the specification before the developers start working on it.  In addition, try to get approval from the actual users who perform the legacy transactions (who may not be the formal business owners).

·        Make the key business owners test the specification, after it is complete, to verify that it works as they want it to.  Someone from within the client company should be responsible for verifying that the functionality meets the business requirement.

·        Ask questions, based on your experience, to stimulate project team members to do a better job gathering requirements and translating them in the system.  If you feel that you don’t have a good requirements definition, keep asking questions until you’re satisfied, or until you are told to stop asking.


ASAP provides many templates to facilitate the testing process.  Someone close to the business process, though, should identify the most common scenarios or combinations to be tested.  Expand your testing to include feedback from your key customers, so you can be sure that nothing is missed.  

Similarly, you should test for the real environment where the programs and functionality will be used.  In a typical remote testing environment, you might only have one label printer, but the factory floor actually has one printer per pack station, so you should test the process to ensure that the label can print at each respective printer.  These details are sometimes overlooked; don’t wait until the last minute to test for the real scenario.  Use actual legacy business documents to verify test script results.

When working on problematic outputs, develop a test matrix.  For example, the invoice is one of those documents that seems to have perennial changes to it, even after going live.  In SAP, however, there are several transactions that allow you to reprint documents easily.  If you have a matrix of baseline invoice numbers that are correct, along with the actual invoices, you can reprint these documents after each code change and review them to ensure that the change did not break any functionality.

Some other important testing considerations are as follows:

  • Close the loop on it.  Test for the "yes" path as well as the "no" path. 
  • Be creative in trying to "break the system."  Do the transactions the way they should be done--then do them in wrong and incomplete ways, like a new user might do. 
  • Where interfaces are involved, make sure all error messages can be displayed (and make sense) to the actual user, especially when testing web applications. 
  • Many times, testing will not reveal an error situation until a certain combination of master data is used (for example, customer number, material number, and quantity).  It’s impossible to test for every combination, so use the 80/20 rule and try to find the tests that will cover the most common user situations.


Given the number of people involved in developing such a highly integrated system, weekly or periodic team meetings are essential to a successful SAP project, especially after going live.  A quick discussion of what everyone is working on, what problems they are having, what new things they have learned or noticed, and so on can be invaluable in identifying when team members' efforts or discoveries impact other areas. 

Similarly, sending e-mails to the team before moving new functionality into production can prevent members from stepping on each other’s work, and help them trace the cause more quickly if something does break in production.   

Talking to key users can help you get to the root cause of problems.  On one project, we had a sporadic problem with availability checking for certain materials.  After checking with the planners, we found that they were running Material Requirements Planning (MRP) at random times during the day, rather than just at night as we had assumed.  Once we knew their procedure, we were able to make an adjustment to fix the allocation problem.   

Besides the current release level, it is very important to keep track of what level of "hot pack" (bug fix) has been installed.  During testing, it's easy to forget that on most projects, the client fails to keep up with applying the hot packs, resulting in unnecessary problems.  In every project I’ve been on, we encountered an apparently unexplainable situation that was finally solved by applying an existing fix. 

SAP has a very nice online support system for identifying known problems and solutions.  It also includes many notes that explain complex functionality for consultants, and you can submit questions to them as well. 

  Training and Change Management

Knowledge transfer and change management are a big part of our job as consultants.  Clients do not want us to stay forever; instead, they want us to share our knowledge with the users, so those users can run their processes effectively.  This can be a critical factor for smooth and successful execution after we leave, and that in turn will influence the clients' decision to call us back for future work. 

Training is an essential part of our knowledge-transfer responsibilities.  Untrained users will do transactions incorrectly, in an incomplete way, or not at all--and this can prevent downstream transactions from taking place.  For example, a missing warehouse management transaction could prevent a shipment transaction from taking place.  Moreover, users need to know not just how to do the transactions, but how to identify and react to omissions and exceptions.  SAP is filled with many excellent tools to manage exceptions, but these tools are useless unless users know when and how to use them. 

Change management is a key facet related to training.  When you make a change or add a new feature, is this being communicated to everyone who needs to know?  Has the training documentation been updated?  You may not be directly responsible for training (since many companies have their own departments for this purpose), but you should know if any changes are significant to the users, so that you can communicate these changes to the appropriate people.

It is often difficult to get users to take ownership of their own system, but we have a responsibility to encourage them to do so.  As consultants, it is sometimes also our duty to train other, less experienced consultants.  These tasks may feel like burdens sometimes, but remember that very few people (perhaps including yourself) know it all.  Not only that, but the success of the project requires knowledge transfer--and that success should always be our ultimate goal.      


There are obviously many factors and topics to consider when working on a SAP project, and what I have provided here are just a few observations from my experience.  We have all heard about problem projects, and listened to dozens of reasons to explain the bad results.  My experience with SAP has been that all of the problems were eventually fixed--and the underlying problem was not the software, but rather the incorrect use of it.

We may not always be empowered to make the key decisions that determine the outcome of our project, but we can certainly communicate our ideas to those who can influence change.  Some of the key factors that need to be considered to minimize project problems are the following:

  • A strong commitment from management, who allow adequate time to make a good project plan and supply enough full-time skilled people to the project
  • Good project management and team building, including excellent communications and support systems
  • Empowering people to make decisions--and, conversely, getting users to commit to owning and taking responsibility for their processes
  • Proper use of ASAP or business process methodology, including (1) keeping the project oriented toward the business processes that are in scope, (2) getting good requirements definitions, (3) thorough testing and quality checks by the business owners and users, and (4) effective training and training documentation for all processes
  • Fostering an environment of learning and knowledge transfer, accomplishing goals, and having fun along the way.  If that is not happening, it’s time to look for the next project.     

You can review SAP products and services by visiting their website, which contains several good white papers, along with a great deal of other content worth reading.  Here is the URL for their site, along with a few other sites that you can use to look up information and to seek assistance with your questions:

Tony is an independent consultant, and president of Beyer Business Solutions.  He is APICS and SAP certified, and has many years of experience in industry, software development, and consulting.  Beyer Business Solutions works in conjunction with other consultants to assist customers with SAP projects and other projects in the supply-chain area. 

You may contact Tony at tonybeyer@att.net   

Licium Corporation is not responsible for errors or omissions of any kind. If you have questions or comments, feel free to contact us.

Copyright © 1996-2009 Licium™Corporation. All rights reserved. Licium is a trademark of Licium Corporation. All product and company names are trademarks or registered trademarks of their respective companies. All other trademarks are the property of their respective holders.

Articles & Features

Fuzzy Job Description of a SAP Developer

A Change In the Weather

Recent Adventures in Making Money (or Not) on the Internet

A Tale of Two Servers

Java Resource Links

Web www.licium.com