Folks new to SAP often focus on one career path: SAP consultant working for a top tier consulting company. While this is a popular choice, it is by no means the only choice. There are many ways to categorize the careers in the SAP field, so I'm going to look at the totality of SAP careers through several different filters in an effort to give you a completely developed picture. These filters are subjective and I'm open to including any that I've missed. Just let me know in the comments!
In each section, I'll break down the categories and try to give the characteristics of each. Not pros and cons, per se, becuase what one person sees as an advantage could be a disadvantage for someone else. Honestly, this blog should probably be split into several blogs, so I apologize for the length. Here goes:
Specialties: Functional vs. BI vs. Technical (Development) vs. Technical (Basis) vs. Project Management vs. Testing vs. Training
Also known as: configurer, configurator
Specialize in the business processes (Financial, Controlling, Human Resources, Materials Management, Production Planning, etc)
Background: business undergraduate and/or MBA degrees. Additional certifications (CPA, CPIM, etc) are also helpful.
Job duties: conduct workshops to gather requirements, present options, assist in the decision making process, then translate business decisions into SAP configuration. Functional specialists also write functional specifications and design rationales.
Required skills: good social skills, strong written and oral skills, good with public speaking, strong knowledge of functional processes
Also known as: data modeler, reporting specialist
Specialize in converting raw data into reports, dashboards, and graphics for the folks who will analyze the data and make decisions.
Background: business undergraduate and/or MBA degrees. Technical classes in data modelling are helpful. Programming experience can also be a plus.
Job duties: Interview request owner for requirements, translate functional requirements into technical requirements, use various tools to generate reports, dashboards, or other summaries.
Required skills: strong written skills, analytic mind
Also known as: developer, ABAPer, "tools" consultant (haven't heard this last one outside of SAP America though), java developer
Use programming to fill gaps in the business process. Create Workflow, Reports, Interfaces, Conversions, Enhancements, and Forms (WRICEF)
Background:Business undergraduate or computer science undergraduate, programming classes or experience required.
Job duties: Translate functional specifications into technical specifications. Translate technical specifications into code.
Note: Conversion is a huge part of implementations and typically the conversion function does continue to some degree post go-live. Often conversion is large enough to be considered separately from the rest of development during implementations.
Also known as: Basis, Netweaver System Administrator, SAP Admin
Administer SAP systems: installation, infrastructure design, backup & recovery, high availability, networking, etc
Background: undergraduate degree. Operating System and/or Database certifications helpful
Job duties: Gather technical requirements, present options, assist in the decision making process, then translate technical business decisions into SAP infrastructure.
Required skills: Strong written and oral skills, strong analytical/troubleshooting skills, ability to work under pressure
Also known as: Security, Information Assurance specialist
Design security, create and administer users
Background: undergraduate degree. Experience with OS/DB user administration helpful.
Job duties: Gather security requirements, design segregation of duties strategy, then translate security decisions into SAP security configuration.
Required skills: good interview skills (to interview employees and determine requirements), strong written and oral skills
Also known as: PM, Team Lead
Manage scope, cost, schedule, risk, quality, resources, and communications.
Background: business undergraduate and/or MBA degrees. Often start as Functional. PMI or other Project Management certification helpful.
Job duties: Manage scope, cost, schedule, risk, quality, resources, and communications.Basically, attend a ridiculous number of meetings and do whatever it takes to keep the project moving forward on schedule and on budget at the required quality.
Required skills: Excellent social and negotiation skills, strong written and oral skills, good with public speaking, strong knowledge of project management theory and practice
Also known as: testers, Quality Control
Test the processes either in an automated or manual fashion. Report the results to project management. Coordinate issue resolution with necessary configurers, developers, etc
Job duties: Organize testing, conduct testing, report test results, follow up on test resolution.
Required skills: strong written and oral skills, strong detail orientation
Also known as: trainer, Organizational Change Management
Responsible for creating end user training materials and delivering training prior to go-live
Background: business undergraduate and/or MBA degrees. Additional certifications (CPA, CPIM, etc) are also helpful.
Job duties: Work with functionals to understand processes as configured and create training materials, stage data and exercieses, conduct training
Required skills: Excellent public speaking/training skills, very strong written and oral skills
Implementation vs. Support
Implementations involve gathering requirements and implementing those requirements.
Folks in implementations deal with massive change to an organization.
Stress level is high, especially near go-live.
Implementations often require work at nights and on weekends. Frequently implementations take place on a 4/10 work week, meaning Monday through Thursday, 10 hours per day but Friday is off.
Consultants and internal company personnel work together to determine requirements and implement changes. All of the specialties from the first section are typically present.
"Business as usual", Production Support
Limited change, usually modifications to existing processes. Support does involve change, however, as change requests are made and approved.
Since the system is live, production problems have extremely high status.
Support personnel tend to work more normal business hours (exception, Basis folks typically work when others don't, so weekend, night, and holiday work hours should be expected for Basis personnel)
Internal personnel only for the most part. Sometimes spot consultants are broughtin for specific issues, but in general all support is handled in-house.
All of the specialties from the first section are typically present, but sometimes greatly reduced as compared to implementation (for example, project management team, testing, and training team might be much smaller post-golive)
Consulting vs. In-house/contractors
Employment Status: Consultants are not employees of the company implementing SAP. They are brought in for their expertise, both SAP and non-SAP expertise.
Compensation: Base Salary is typically about the same, perhaps a bit higher than in-house, but consultants typically receive bonuses which brings overall compensation higher than in-house. (Note: this is true in the United States. I have seen some data that indicates that consultants in other countries actually make less money than in-house counterparts. I've not been able to make much sense of this data.)
Home-life: high degree of travel. Typically away from home 4 to 5 days per week. Travel expenses are typically reimbursed and so consultants typically eat well and get to live perhaps a higher lifestyle than in-house counterparts. Travel can be difficult for family, however, and divorce rates are typically higher for consultants than for in-house counterparts.
Professional Respect: High degree of respect is typical from company management. If a consultant and an in-house employee disagree, often management will side with the consultant. Projects can be more easily be "sold" to management by consultants (especially consulting partners). Consultants with equivalent skills and job responsibilities often have higher reach into the implementing company.
Type of work: Consultants typically are involved only in implementations. This can be great if you primarily enjoy design work. It can be frustrating if you like to see the progression and "perfection" of a system over time. No "ownership" of the system long term.
Career progression: Consultants typically have to become project managers and salesmen in order to make partner in a stereotypical consulting organization. Early career skills (functional, technical, etc) often don't relate to the skills which enable success in late career (project management, salesmanship). Consultants *can* specialize and stay in their specialty but compensation eventually stalls. Consultants who try and miss partner can be frustrated for long periods of time or even be forced out of their consulting firm (up or out). Making partner can actually increase work load and stress and is sometimes seen as a mixed blessing.
Requirements to start: Generally consulting companies requires at least one if not two or three complete implementations before they'll hire someone, although some companies recruit the "best and the brightest" directly from undergraduate and MBA programs.
Employment Status: In-house folks are typically employees of the company implementing SAP, although I include contractors as in house as well. Contractors are hired to conduct long-term support of a system and are typically treated similar to employees.
Compensation: In general, overall compensation is lower for in-house employees and contractors as compared to consultants, but see comment in the consulting section.
Home life: Typically require little to no travel. Working hours will match those of consultants (but won't get consultant type compensation) during the implementation but will return to "normal" post go-live for long term support. In-house employees and contractors typically have "normal" home-lives, which is generally easier for those with children.
Professional Respect: At times, in-house employees struggle for respect of management. If a consultant and an in-house employee disagree, often management will side with the consultant. Projects can be more easily be "sold" to management by consultants.
Type of work: Employees/contractors do both implementation and long term support of system post go-live.
Career progression: In-house employees have the opportunity to advance within the company to become management and senior management over time. Contractors are barred from this type of progression unless they become employees. Contractors typically have one job and don't change over long periods of time. In-house employees who miss key promotions can be frustrated for long periods of time. Employees also have the option of staying in one job for along period of time but at the cost of career and salary stagnation.
Requirements to start: Generally companies draw from in-house non-SAP support staff to hire SAP support staff although they do also hire experienced folks from outside. To start from an inside position, you'll generally have worked for the company for a few years as an end user or in some related capacity. To start from outside, companies will expect you to have implemented SAP either as a consultant or as in-house employee at another company. Companies generally do not recruit from undergraduate or MBA programs directly into their support organization.
Working for a Consulting Company vs. being an Independent Consultant
Working for a Consulting Company
Somewhat protected from economic downturns, able to collect paycheck while "on the bench"/"on the beach" (in between assignments)
Independents argue that consulting companies have a history of cutting folks loose the minute the market gets tight. My observation is that top tier companies will hold on to consultants for 6 months to a year where smaller companies have less ability/inclination to hold on to consultants for that long when times are tight. Your mileage may vary on this one.
Independents argue that higher compensation of being independent allows you to ride out the patches in between assignments as easily as if a company were paying you to be on the bench. Your ability to budget for these downtimes makes the difference here.
Go where you're told, when you're told.
Less responsibility to get yourself busy, but less ability to affect type and duration of assignments.
More likely to end up at a customer as a bad fit if management doesn't know your skill set or is incompetent.
It's possible to get "pigeonholed" into the same type of assignment over and over.
Since "beach/bench" time effectively kills your bonus, some view the inability find your own work extremely frustrating.
Paid vacation and benefits
Company pays for training
Stuck with whatever training/equipment the company chooses to provide.
FREEDOM. Free to choose when to work and for whom to work and rate of compensation.
Requires more diligence with money.
Vacation, sick and training time directly affects the bottom line and can encourage some to limit those times.
Cost of insurance/benefits are higher.
Compensation can be much higher since there is no company to skim profit off the top.
Since number of hours worked directly affects compensation, the temptation to work far more than the industry average 2000 hours per year by taking on multiple clients or just putting in long hours for a single client can be irresistible.
Responsible for your own equipment.
Training is a double whammy. You have to pay to attend and you lose money because you're not billing a customer.
Requires more time to deal with paperwork for invoicing and expenses.
Different customers can be better or worse at paying in a timely fashion.
There are more points to be made under each of the categories, but this should be enough to get a discussion going. All combinations here are possible. For example, some companies have a new functionality task groups so you can be an in-house functional person dedicated to new implementations. The great majority of in-house folks do post-go-live support and the vast majority of consultants concentrate on new implementation, but there are no hard and fast rules.
Please ask for clarification if I've muddled anything or bring up points I've missed/covered badly.