SAP was mentioned several times in this thread. Years ago I worked for a company that was readying their systems for a transition to SAP. There was talk of having to learn new terminology to fit what SAP has set up, most of it seemed like a pain since some terms existed in the company but was used differently, potentially throwing people off.
So what’s the word on SAP’s not-goodness?
Well, you can’t just buy it off the shelf, install it and it works. Indeed, it takes a tremendous amount of planning and expertise to get it going. I worked briefly on an SAP implementation, and it was pretty hairy.
One of the biggest negatives I have about SAP or any ERP is that the people who get sold to on the idea of using it aren’t the people that actually use it.
“Great, this thing can tell us how much it costs to have x person spending y% of their time on z project!” Sorry, that means you’re going to have to have somebody dig up all the information that would be necessary for such a query to have informative results and enter it or migrate it from a legacy system, then somebody would need to make sure all that type of info is accurate on a near-constant basis.
The fact of the matter is that most companies don’t have this data in the first place and don’t have the resources to maintain it, and most of their employees won’t be able to use it or supply sufficient data for it to be used effectively. You will not be able to convince rank and file employees that spending a chunk of their time feeding data to an automated “dude with a clipboard” for his TPS Report is particularly helpful.
I was on the receiving end of a SAP transition, and all I can really say is that it made no sense whatsoever. I think our setup wasn’t carefully thought through, though.
We’re going live with SAP in a couple of months. I know that those who are working on the transition have been doing so for about a year, and it’s very time consuming and frusterating.
I’m a COBOL programmer who became an ABAP developer when my previous employer decided to use SAP.
For starters, SAP is HUGE - and like An Arky said upthread, you cannot buy it off of the shelf and have it work. There is lots of configuration to be done, both system-wise and business-wise. You need your employees trained, as well. Ideally, you would have SMEs - Subject Matter Experts - who would be a part of the implementation process from start to finish. These people wind up being your Go-To People. They not only know the business, they know the SAP system as well. Implementations should also be done with an Implementation Partner, and choosing one wisely can make or break a project.
I now work for a different employer as an SAP Application Specialist. I have no business background, per se, and I have to tell you being tasked to learn all that I support has been daunting. Did I mention that SAP is HUGE? Ginormous, even. The logistics portion of the system alone houses Materials Management, Sales and Distribution, Logistics Execution, Production, Plant Maintenance and Quality Management. Those are just the primary modules. Logistics is the side I support. I also do a tiny bit of ABAP development and some Basis administration.
For a large company with the budget to maintain a proper SAP support structure, and has a fairly common manufacturing practice, SAP is a can be a good ERP tool. For those companies without budget dollars available or are not your typical manufacturer (such as Higher Education), SAP can be less than optimal.
Mr. S had to use SAP when he worked as a job planner at a printing company, and he HATED it. As in came home every day and lay down on the couch with an ice pack on his forehead for an hour hated it. His main gripe was that it didn’t play well with any sort of deviance from “standard” – in other words, custom jobs. In printing, EVERY job is a custom job.
I’m sure if he were here he’d have all sorts of invective to share. Suffice it to say, the only people I’ve heard saying good things about SAP are those who don’t have to use it.
I find it interesting that I have never spoken to anyone involved with an SAP project that felt it went well or that it was worth while, and yet they still are successful. I know one guy whose company have tried to implement it *three *different times.
I wish I had that kind of marketing force for my product.
It looks like we’ve finally found a German product that sucks. Its a lumbering arcane behemoth, and the people unfortunate enough to know how to use it charge a LOT.
From my experience 9 years ago: The user interface looked like it was designed in the 70s, for 1970s computers. EARLY 1970s.
I was tasked with generating some reports from the base tables (this was a SQL Server version). North of 20,000 tables, each with 10-character column names, with both table and column names in German. A 10-character English column name can be cryptic enough.
A major research institution started using SAP (they’re intentionally mispronouncing it “sap” rather than saying each letter) and they’re fairly consistently months behind in sending me checks in response to the invoices. :mad: Considering they were on the ball before the implementation, I’m inclined to believe them that it’s due to SAP.
Ugh. Our company actually uses one of SAP’s lesser-known competitors (IFS–Swedish instead of German), and we have many of the same complaints. Is there any good ERP software? Why would a company deliberately put themselves through this?
My experience is mostly with Baan (Dutch instead of German)… and I have to say… No, there is no good ERP software.
Because the alternative scenarios are worse:
Using in-house custom coded software for order entry, warehouse management, etc and funding an expensive payroll of in-house programmers to maintain it. Your company falls behind because your staff programmers cannot write reports or deliver new functionality as fast as other companies that already run SAP (or Oracle Financials).
Using an old software package that is out of date with poor (or end-of-life) support from the manufacturer.
Have 20 separate systems/applications (one system for order entry, another system for inventory, another for billing, etc) with the associated hassles of keeping the systems in sync via flat file transfers, nightly batch jobs, etc,
ERP packages are not sexy toys. They just do the unglamorous job of running the business. ERP are complicated behemoths because run companies run complicated businesses. If one just runs a lemonade stand with a collection cup for cash payments, ERP is overkill.
For example, customers can go to dell.com… order a computer and customize it with various options. This custom order turns into a orchestration of bill-of-materials and assembly workflow for a computer to arrive at your door. The $400 QuickBooks accounting software you can buy off the shelf cannot handle complicated scenarios like that.
I use the end products from two SAP implementations for Uncle Sam. My system needed to interface with the new products, which replaced old clunky mainframe-based products.
The mainframe products were much, much, much better in both cases. Both projects were years late and hugely over budget.
One of the products has, over the last 7-ish years, improved to the point of being down “only” 4-5% of the time each month. (I have to track it.) The mainframe product it replaced was down fewer total hours per year, and was up (if very slow) for end of month/quarter/year processing.
The other product had its first deployment (of 6 sites) five years ago. The second roll-out was supposed to be six months after the first. It just got re-re-re-re-re[sup]n[/sup]-scheduled from March to May of this year. No bets on when it’s really going to happen.
Neither of these SAP-based products talk to anything. For the older one, to allow my system to interface with it the contractor had to build a web site that talks through a twisty series of various pieces of middleware, all different. I believe the flow chart was a 1905 Rube Goldberg original. The newer product - the contractor just gave up on interfaces for anyone at the last minute. Hello- it’s a government system - it has to talk to other stuff. And the interfaces were in your contract! Oh, were in your contract. :rolleyes: My system gets its data from another project - they get data dumps (Og only knows how old) and load them into an standard DBMS. At least we can talk to that.
I don’t know if the faults are with SAP or the CONtractors who foisted this systems on Uncle Sugar. No love for SAP in my office.
And what I really, really try hard not to think about come April 15th of every year is that when the agency director who oversaw one of the cluster-orgies retired, he was immediately hired by the contractor that was responsible for the mess. :mad:
This. Most users only have to deal with one or two small aspects of the overall SAP system. For those tasks, it pretty much blows compared to other dedicated pieces of software. However, nothing else that can do the 20-30 functions SAP might do for a company and work very much better.
First companies created their own code to handle their business. The serious problem with this approach was that the people who wrote code and the people who needed data processed rarely knew enough about each other’s jobs to effectively process data. The earliest computer systems were little more than ways to have machines put the marks on papers that people used to do.
As some programmers/analysts and some users began to learn more about what the users needed and the programmers could actually do with computers, the systems began to (slowly) get better. Once a few of them thought they actually understood what was going on, some companies began to offer to write systems for other companies so that the systems would actually serve a purpose other than to reduce the number of underpaid accountants making marks on papers. Then some of those people began to form their own companies to write and sell systems to other companies.
However, since each company has its own corporate culture and its own way of doing business, the systems, (or packages), had to be written with very open-ended requirements with hundreds of modules that had to be selected or bypassed to fit into the companies’ businesses. When company A and Company B each bought System XYZ, they would use some critical parts from it, then tailor other parts to meet their own needs. The advantage to this approach is that a company can hire one or two programmers to babysit the purchased systems, relying on the vendor company to continually make upgrades, while the company can use the rest of their programming staff to handle the bridges among different outside systems or to create reports and other functions that the package does not handle well, (or at all). The disadvantage to this approach is that no outside vendor’s package ever meets all the needs of a company, so they are forced to keep using internal programmers to keep the data flowinging where it is needed. In addition, every time the vendor upgrades the system, some part of the staff has to scurry around and make sure that the changes are not going to destroy a bridge or a function on which the company had built part of its business model.
SAP’s brilliant/insane/diabolical solution was to write a system that actually did do every single thing, (in theory), that any company could desire in its data systems, with the spectacular catch that SAP would not write an open-ended system that could be adapted so that anyone could use it. Instead, SAP wrote a single set of comprehensive systems, then told all its customers that they had to change the way they did business to match the SAP software.
So, one of two things typically happens: either the company does try to revamp its entire business model to follow the SAP software–causing massive consternation among the customers, the vendors, and the employees as business practices that may have decades of institutional tradition are tossed aside–or, (more typically), the company simply refuses to believe that they need to do that and they wind up spending six or seven times the energy, time, and money making enormous ad hoc changes to all the data flows so that they can try to do business the old way while donating a significant portion of their capital to the SAP retirement funds.
I have seen claims of successful SAP installations, but I have never seen claims that any SAP installation was not excruciatingly painful.
The job prior to my last one was a temp, turned perm position with a company that was migrating to SAP about 9? years ago. I was placed in HR when the HR admin totally flipped out about learning a new system, and so they figured a bright eyed 20something college student would be a perfect fit. (They hadn’t even started migration, they were training in a test environment)
Within that position, and several others through the company I was exposed to various aspects of the SAP system. My first temp assignment there had me entering employee training information (20-30k entries). This specialty chemical manufacturer (previously a division of a much larger company) had training programs for pretty much every chemical that was on site. We figured we’d name the training program by chemical, then 1 through whatever for training for that chemical. Something like ChemName###. So, you build the type of training, then you had to build the class event (might have 20 times that class happened), and then add each employee to that class.
At first I thought this was the most convulated system on the planet, but as the project went on I became the ‘go to’ person for training data in SAP. Everyone was astonished when I got all the data into the system in about 3 weeks - they thought it’d be a 3month summer project!
From there I’d bounce around as a temp working on various projects helping set up data for various groups, teach people how to use the modules I was using etc. I eventually got hired for anything and everything, since I touched so many parts of the smallish division.
But aside from that, SAP seemed a lot more stable than whatever they were using before. It seemed like an absolute resource hog, and many people did not understand all the cool data you could get from it - if you wanted to wait awhile. I’d say on the whole the company’s implementation to each division was pretty successful.
That’s funny, I use it now and at my last company and it now looks like it was designed in the early 90s. So progress, I guess.
I know someone who works at SAP, and they all hate using it too.
In my experience, it works fine for logistics, ordering, and inventory management if you know the interface (which can be customized with third parties) and the implementation makes sense for your application.
Where it really sucks, is when you skimp on implementation or your try to use to track employee activities.
At my last job we switched to SAP for material and order management without to much in the way of pain. I worked in service and they didn’t really think about us so we lost a lot of the reports we had formally used, but for the primary users it went well. Then they wanted to replace our call and trouble tracking software with SAP. This is were they really screwed up.
With software like this you can pay a lot of money upfront to customize, but then if you want to upgrade you need to pay all over again, or you can use it out of the box and have a cheaper path to upgrade. My last company got burned by having a highly customized version of their last call and trouble database, so they choose to go with as little customization as possible. They were sold on the reports and tracking they should be able to do, but entering data was so cumbersome, that the reports were worthless. Logging notes ona trouble call went from a very intuitive 30 second process (enter number, push add notes button, bring up screen with two drop downs, comment section, time entry and submit button) to a ten minute slog through multiple screens, meaningless drop downs, and slow loading sub forms, where any mistake means you have to start all over.
The executives were thrilled with all the reports that showed how much money and time was going where, but we on the front end couldn’t even pull up a meaningful list of prior issues on a specific piece of equipment. The whole system seemed to be designed for executive presentations and not to actually make it easier to service the customers.
Jonathan
I think that this is the critical point. You can’t compare SAP as a system with anything other than other systems that do the same thing - that is, with other ERP systems. It has a hugely wide scope and considering that, I actually think it is an incredible thing. SAP implementations are almost always complex and they often involve a number of groups of people who don’t really understand what they’re getting in to. I’ve worked on too many implementations which were pitched as an IT concern, for instance, with little real understanding of the huge effects that were imminent all across the business.
One of the unfortunate effects of the enormous expansion in the SAP customer base in the very late 90s was a huge influx of new ‘consultants’ who combined a lack of understanding of SAP and ERP systems genearally with a complete lack of understanding of business processes and requirements. There are still far too many people working professionally on implementations who just don’t know what they’re doing, and they help contribute to the bad rap that the system gets. I do believe that the system itself can be great, but it can very easily be badly implemented, or in inappropriate contexts. SAP is an enormously successful organisation, with a hugely successful set of products, and there are good reasons for that.
(I’ve been working on SAP implementations for close to 15 years).
Very very true. My part of my company implemented SAP starting 9 years ago, I was involved in the implementation and have been on the SAP Support side ever since. Some of the consultants we had on some of our projects were jokes. They didn’t even try to understand the business and/or barely understood SAP. We’ve had some (few) excellent ones, however.
And really, SAP is very customizable. It’s just not EASILY customizable beyond the standard configuration settings. But with ABAP programming, you can do pretty much anything. For example, as someone mentioned, the standard service call screen is a mess of screens and subscreens that aren’t about doing it fast. Same with the order entry screen - useful fields are all over the place.
So, after a number of years of struggles, we designed a custom front end for our call center agents to use, that made the interface as simple as possible. A search screen, that routs to one of two data entry screens, that have a couple of tabs to get to useful information.
I’ve said this before - but having good programmers that understand the business is a huge key in a successful SAP implementation (and to the continued improvement of same). And that’s coming from a non-programmer who is supposed to be the liaison between the business and the programmers!