Are SAP people really "IT" people?

I've been looking at Net Admin, Sys Admin positions at several companies these pasy few months and have seen a lot of posting for SAP people.

Question is: Are SAP people really "IT" people?

I say this because I had a chance to play with a SAP GUI and it looks a huge database/excel GUI and really quite boring. Ok, I understand the complexity behind the ERP system, its functionality, etc - but with the exception of the DBA's that maintain the huge database (eg. Oracle, SQL Server, etc) it doesnt look like its much "hands-on" IT - perhaps more of a data analysis/business type stuff.

So my post actually has two questions:

1. Are SAP people really IT people?
2. Would anyone in SAP recommend you have a background in IT or business?

Just Curious.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

eMeS

lespaulman74 wrote: »

I've been looking at Net Admin, Sys Admin positions at several companies these pasy few months and have seen a lot of posting for SAP people.

Question is: Are SAP people really "IT" people?

I say this because I had a chance to play with a SAP GUI and it looks a huge database/excel GUI and really quite boring. Ok, I understand the complexity behind the ERP system, its functionality, etc - but with the exception of the DBA's that maintain the huge database (eg. Oracle, SQL Server, etc) it doesnt look like its much "hands-on" IT - perhaps more of a data analysis/business type stuff.

So my post actually has two questions:

1. Are SAP people really IT people?
2. Would anyone in SAP recommend you have a background in IT or business?

Just Curious.

No offense, but the question is really irrelevant. We all do what we do because business needs drive the need for IT. It's never the other way around, and if you think it is then your worldview is very limited. IT does not exist for the sake of existing.

When I think of IT, I like to think of this definition:

Information technology (IT), as defined by the Information Technology Association of America (ITAA), is "the study, design, development, implementation, support or management of computer-based information systems, particularly software applications and computer hardware."[1] IT deals with the use of electronic computers and computer software to convert, store, protect, process, transmit, and securely retrieve information.

I would distinguish those who use SAP, from those who configure/support it etc. Your post doesn't really tell us; are the positions you're seeing looking for people to do SAP admin, configuration, etc.., or are they looking for people to use SAP to accomplish business tasks? The answer to 1 depends on the focus of the position. Are the positions primarily from a business perspective and require the use and knowledge of SAP, or are they primarily from an IT perspective in support of business needs by configuring and administering SAP solutions?

In terms of question #2, I know quite a few people that have done SAP work. It's not the most common skill set. In my experience, these people have tended to be well-versed in both the business and technology. They tend to be independent consultants and often command very high rates.

MS

Turgon

lespaulman74 wrote: »

I've been looking at Net Admin, Sys Admin positions at several companies these pasy few months and have seen a lot of posting for SAP people.

Question is: Are SAP people really "IT" people?

I say this because I had a chance to play with a SAP GUI and it looks a huge database/excel GUI and really quite boring. Ok, I understand the complexity behind the ERP system, its functionality, etc - but with the exception of the DBA's that maintain the huge database (eg. Oracle, SQL Server, etc) it doesnt look like its much "hands-on" IT - perhaps more of a data analysis/business type stuff.

So my post actually has two questions:

1. Are SAP people really IT people?
2. Would anyone in SAP recommend you have a background in IT or business?

Just Curious.

Yes SAP people are IT people although many of the roles are more of an analyst role than anything else modelling the flows of information. ABAP programmers are more technical. SAP R/3 exposure has lead to some tremendous careers for many people. Certainly in the late 1990's many people tried very hard to ride the SAP curve as it made inroads in many companies. In Europe if you could obtain several years experience rolling out a major implementation in SAP then a great career was potentially in the offing. As it turned out, while a SAP project involves many people, typically only a few obtain the sort of exposure that really leads to credible status as a consultant. In many cases companies relied and still rely on highly trained specialists to come in and provide the skills an 'in-house' team lacks when a SAP implementation takes place. The projects can run for several years. You find a lot of people name dropping SAP to get on the field but under the surface the skills they provided were sometimes marginal even if they did play a fairly important role in the implementation. This is because the specialist technical skills are bought in and significant implementation experience is required to lead the project. If you really had the goods in terms of SAP experience it was a licence to print money in Europe but competition was serious. SAP courses are expensive.

My first company went for SAP. A dedicated team was comprised of people from different departments in the business but none of them had implementation experience. That was brought in from outside. I find SAP is one of those areas largely ignored by many IT professionals who do not work for companies using it, but it is huge. The same could be said for Oracle, UNIX, and IBM Midrange systems. All these systems combined provide the bulk of transaction systems still in use today, but with the dash to MS desktop computing in the late 90's a few people forgot about that.

JockVSJock

In my experience, SAP people, along with others who do PeopleSoft/Oracle ERPs are not IT people.

The majority of these players who are part of these projects are either business analysis and managers who try to get their hands around poorly designed business processes and don't understand what they are trying to implement. Most of the time, they customize something that shouldn't be customized, in order to try and fit the mainframe system that they want to replace and screw up their implementation. What we are trying to implement are typically the following:

-HR System (hiring information, employee information, benefit information and retirement information)
-Payroll/Financial System
-Purchasing System

Again, these systems get implemented wrong because companies refuse to change their business processes, so they have to call in the next player, the high paid consultant to save the project. Let's break down the IT skill set:

Business Analysis: Most of the time, these are home grown. Not much education/certification past high school diploma and/or tech skills. And not really understanding the big picture for the business process either. Typically not their fault either. As for tech skills, next to none. A few can desk check code and some can point-and-click a SQL query on a front end, leaving the hard work done on the back end, so they really don't have a understanding why their cartesian join keeps bombing out the database. And, 9 times out of 10, they won't get the training they need in order to understand what they now need to do in order to buy into the system. I have worked two projects where PeopleSoft was implemented and none of the users got any training. The management truly believed that it would be 'easy.' And in both cases, work screeched to a sudden halt.

Managers: Most of the time, most of these people have a Cobol programming background, who have a hard time grasping the client/server and web based app environment most of these systems run on. Also these people need to be the agents of change: making business process fit the system, not the other way around, understanding the business processes from beginning to end, getting their people to buy in to the system, and getting people the training they need in order to be successful. Honestly, these people really aren't that technical either, they have to be a cheerleader for change.

High paid consultants: I've worked with some very respectable consultants who have the balance between tech, typically programming background and the business side background (accounting, payroll, benefits, and retirement). These people are worth their weight in gold and more. Unfortunately, i've seen these people brought in to fix projects that have gone south, and there is nothing they can do to save the situation because of the two other types of people above.

So...short answer, typically most people involved with ERPs are not tech. If you want to get good at SAP, probably best to have a programming background and also be able to pick up and learn the business side (accounting, payroll, HR, retirement and purchasing) very quickly. In most cases, these processes are not documented well, or the person doing they has a full understanding of what they are doing, so this type of work can be very difficult.

eMeS

JockVSJock wrote: »

Again, these systems get implemented wrong because companies refuse to change their business processes, so they have to call in the next player, the high paid consultant to save the project.

You've got it backwards. The business does not change to meet IT, IT meets the needs of the business. I'm not saying here that business processes do not need to be optimized, they do, however, trying to stuff your business into a certain box to meet specific IT requirements/restrictions is ass-backwards.

JockVSJock wrote: »

Business Analysis: Most of the time, these are home grown. Not much education/certification past high school diploma and/or tech skills. And not really understanding the big picture for the business process either. Typically not their fault either. As for tech skills, next to none. A few can desk check code and some can point-and-click a SQL query on a front end, leaving the hard work done on the back end, so they really don't have a understanding why their cartesian join keeps bombing out the database. And, 9 times out of 10, they won't get the training they need in order to understand what they now need to do in order to buy into the system. I have worked two projects where PeopleSoft was implemented and none of the users got any training. The management truly believed that it would be 'easy.' And in both cases, work screeched to a sudden halt.

This matches for the most part what I've seen as well. The way I would describe it is that people that an organization couldn't really figure out what to do with end up becoming "business analysts". Theoretically, business analysts should be high quality people that can bridge the divide between the business and technology...rarely is this the case and rarely do people in these roles have the authority to really make anything happen.

JockVSJock wrote: »

Managers: Most of the time, most of these people have a Cobol programming background, who have a hard time grasping the client/server and web based app environment most of these systems run on. Also these people need to be the agents of change: making business process fit the system, not the other way around, understanding the business processes from beginning to end, getting their people to buy in to the system, and getting people the training they need in order to be successful. Honestly, these people really aren't that technical either, they have to be a cheerleader for change.

Again, this is a bit wrong. It's not the job of manager's anywhere to change a business process to fit a system. It is their job to ensure that systems meet business requirements.

MS

JockVSJock

While we probably agree that IT is a tool in the toolbox for the company. We do not agree on how it is implemented.

In traditional SDLC, during the analysis and logical phase, teams of users and developers work together to discover the needs to the business from the new system and/or the current business processes. This can be done by interviews, data flow diagrams and entity relationships to translate what the system can and can't do.

Basically its limitations, which all systems have.

Let's say Company A has the capability to cut off-cycle paychecks with its mainframe, with no issues to its General Ledger. It cuts over to an ERP and on paper they should be able to replicate this process with no issues.

However, they try to implement this with the ERP and it causes issues with the GL and this needs to be clean for external auditors and Federal reporting. They don't want to change the Vanillia ERP because that causes customization and this causes alot of headaches (hard to maintain, hard to upgrade).

Management whines, 'why can't the new system do this, we have always done it this way' when they sit down with an external consultant. This person states that they need to change this process, need to stop this practice due to system issues and should run these off-cycle paychecks when they do their normal payroll, which is once a month. Pretty simple solution.

Management pouts a bit, however Company A's staff prep's to make the change to the business process (clean up bad data, make few test runs in a dev environment and then make it so in production). The change is made Company A now runs off cycle check with the regular payroll, thus causing no issues with the GL.

This is a real world example, because I lived it. It is one of the many examples that i can give you where the business that had to change its process due to issues/limitations with the system. This happens all the time and more people live happily ever after when this happens, instead of trying to make changes to the system to fit the business.

eMeS wrote: »

You've got it backwards. The business does not change to meet IT, IT meets the needs of the business. I'm not saying here that business processes do not need to be optimized, they do, however, trying to stuff your business into a certain box to meet specific IT requirements/restrictions is ass-backwards.

This matches for the most part what I've seen as well. The way I would describe it is that people that an organization couldn't really figure out what to do with end up becoming "business analysts". Theoretically, business analysts should be high quality people that can bridge the divide between the business and technology...rarely is this the case and rarely do people in these roles have the authority to really make anything happen.

Again, this is a bit wrong. It's not the job of manager's anywhere to change a business process to fit a system. It is their job to ensure that systems meet business requirements.

MS

eMeS

JockVSJock wrote: »

While we probably agree that IT is a tool in the toolbox for the company. We do not agree on how it is implemented.

In traditional SDLC, during the analysis and logical phase, teams of users and developers work together to discover the needs to the business from the new system and/or the current business processes. This can be done by interviews, data flow diagrams and entity relationships to translate what the system can and can't do.

Basically its limitations, which all systems have.

Let's say Company A has the capability to cut off-cycle paychecks with its mainframe, with no issues to its General Ledger. It cuts over to an ERP and on paper they should be able to replicate this process with no issues.

However, they try to implement this with the ERP and it causes issues with the GL and this needs to be clean for external auditors and Federal reporting. They don't want to change the Vanillia ERP because that causes customization and this causes alot of headaches (hard to maintain, hard to upgrade).

Management whines, 'why can't the new system do this, we have always done it this way' when they sit down with an external consultant. This person states that they need to change this process, need to stop this practice due to system issues and should run these off-cycle paychecks when they do their normal payroll, which is once a month. Pretty simple solution.

Management pouts a bit, however Company A's staff prep's to make the change to the business process (clean up bad data, make few test runs in a dev environment and then make it so in production). The change is made Company A now runs off cycle check with the regular payroll, thus causing no issues with the GL.

This is a real world example, because I lived it. It is one of the many examples that i can give you where the business that had to change its process due to issues/limitations with the system. This happens all the time and more people live happily ever after when this happens, instead of trying to make changes to the system to fit the business.

But if this was one of the requirements of the business, shouldn't this have been determined up-front during requirements gathering? (BTW, look up "Service-V Model", I prefer it to the traditional waterfall approach). That sounds more like a failure to gather and understand the true requirements than anything else.

It's a great example, because I've actually cleaned up something that was very similar to this. Business was able to cut off-cycle checks (not payroll) before, a new system is implemented, and voila, the new system doesn't allow this functionality. Although what you've said is well thought out and logical, it sounds like to me what was fixed was only a symptom, and not the true root cause.

Basically the "solution" in this case was exactly what you said, IT indicated to the business that they would have to change their process and that nothing could be done.

Guess what the business did in this case? I won't keep you in suspense. They continued their old process, but instead of using the system provided by IT (which couldn't at the time do precisely what they wanted), they put paper checks in a lock box in all of their offices. This would be ok for a small customer, but in this case this was a very-large organization with about 2000 field offices.

I don't retreat to the land of theory often, but this is one of the things that I think theory has right and general practice has generally wrong. The business and business processes drive IT, not the other way around. In the absence of IT (or in the case of overly constraining IT), the business will find a way to continue its work.

I could give you about a million examples where best practices support this, but those would be primarily from areas where I'm credentialed and familiar. This is just a guess, and I might look later, but I would bet in all of those Cisco books (esp the design ones) that something is said about business needs driving the need for IT and the design of IT systems...

Also, I think we could answer the OP's question better if we had more detail about the specific positions. I would argue that people that install, configure, and administer SAP solutions are very much "IT People" (although I still don't know why it matters). I would tend to agree with your assessment of most people in "business analyst" roles...they tend to be neither "IT" nor "business", and from what I've seen are not fully accepted by either constituency...

MS