 | ||||||
 |  |  |
 | |||
| | ||||||
| | ||||||
|
| | |
| |||
| | ||||||
Fuzzy Job Description of a SAP Developer 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? 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. TestingASAP 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:
|
Fuzzy Job Description of a SAP Developer |