SAP Implementations
January 6, 2005 5:52 PM Subscribe
SAPFilter. Any consultants, IT types, or even end users with experience in large scale SAP implementation? There is, of course, much, much more inside.
I'm on a five year project to replace home grown legacy systems with SAP. We are a sort of middleman, buying food, clothing, medical supplies, hardware and spare parts for all branches of the Armed Forces and various other customers. I'm looking for horror stories (i.e. Hershey foods debacle), success stories, anecdotes, what have you. What worked and what didn't? We're gradually rolling in 4.6 million items (yes, you read that right), bringing users on board bit by bit and adding functionality slowly.
I'm on a five year project to replace home grown legacy systems with SAP. We are a sort of middleman, buying food, clothing, medical supplies, hardware and spare parts for all branches of the Armed Forces and various other customers. I'm looking for horror stories (i.e. Hershey foods debacle), success stories, anecdotes, what have you. What worked and what didn't? We're gradually rolling in 4.6 million items (yes, you read that right), bringing users on board bit by bit and adding functionality slowly.
"You know how you von the Var? Vell now Vee Own YOU!" - lightly paraphrased words from the German instructor of my 3-week long course for SAP configuration. Seriously.
As long as you remember that this system dates back to mainframes and *still is* based on those greenscreens, but has a GUI on top that talks to them, as long as you remember that ABAP is (holds fingers together) THIS far from COBOL, as long as you remember that all 9000 tables' DDLs are in German, and as long as you remember that no matter how well the system it's replacing worked before, SAP can do it *better* with some "configuration" and perhaps a little ABAP and Basis work (plus, shhhhhhh... a whole lot of time, money and consultants), you'll do great.
Oh. You said you are part of the project? And it's Military? Well then, do as trharlan says, and make some bucks.
A place I used to work sent me to train for SAP. Luckily for me, there were other projects to work on, so after the training I worked to integrate other systems with SAP. The home-grown systems SAP was replacing worked well enough and were understood by current staff. SAP was a decision made based on decisions made by then-new IT upper management whose last job was Sales upper management. I think he read about it on a plane. This was 8 years ago. They are *still* trying to replace some of the home-grown systems with SAP modules.
I'm not really bitter. It's really more like disappointment. This same management mandated Microsoft/Intel hardware in corporate (previously 95% Macintosh) *because of SAP*, which has a NATIVE MacOS client. Apple frikken Computer uses SAP for chrissakes! This same management grew our Tech Support staff from four people (one manager and two staff on days and one staff on nights) to around 14 people to support the same number of machines simply because of the new support-heavy MS infrastructure.
What SAP does for businesses is centralize everything. Getting there takes a lot of time, and if you've got a set of home-grown apps that work together, there's not a lot of reason behind moving to SAP. Starting from scratch, I'd give it some serious thought. Coming from as heavy a DP background as I've got, centralization is a WONDERFUL thing.
From my experience:
Successes - Local order entry, plant management and scheduling were integrated after about a year. This was good.
Failures - Very business-specific chores took the longest to migrate and are still being migrated.
Not-Successes-if-Success-is-defined-by-full-Replacement - Everything SHOULDN'T be replaced. Two major home-grown systems critical to this company (of which one was in production and one was in development) are still separate, but integrated with, SAP.
Anecdotes - (Aside from my stultifying experience with the German instructor above) Go with Oracle or SAPdb. Don't go with Informix because it's "cheaper". Don't believe your VP of IT because he says that a huge 24' x 24' open cube with a hallway through it and desk area around the perimeter will help SAP get done quicker because everyone is working together in the same area. I mean, everyone will have their backs to each other!! Take your 5 years and multiply it by 1.5 for a truer estimate. If you are using the ASAP system, multiply by 2.0.
I have a bunch more, but I don't want this to seem like a vendetta - I really enjoyed doing the work I did at this place. I simply believe that SAP wasn't a good fit. Sadly, I didn't have a lot of pull, being a cog in the wheel and whatnot.
posted by tomierna at 9:19 PM on January 6, 2005
As long as you remember that this system dates back to mainframes and *still is* based on those greenscreens, but has a GUI on top that talks to them, as long as you remember that ABAP is (holds fingers together) THIS far from COBOL, as long as you remember that all 9000 tables' DDLs are in German, and as long as you remember that no matter how well the system it's replacing worked before, SAP can do it *better* with some "configuration" and perhaps a little ABAP and Basis work (plus, shhhhhhh... a whole lot of time, money and consultants), you'll do great.
Oh. You said you are part of the project? And it's Military? Well then, do as trharlan says, and make some bucks.
A place I used to work sent me to train for SAP. Luckily for me, there were other projects to work on, so after the training I worked to integrate other systems with SAP. The home-grown systems SAP was replacing worked well enough and were understood by current staff. SAP was a decision made based on decisions made by then-new IT upper management whose last job was Sales upper management. I think he read about it on a plane. This was 8 years ago. They are *still* trying to replace some of the home-grown systems with SAP modules.
I'm not really bitter. It's really more like disappointment. This same management mandated Microsoft/Intel hardware in corporate (previously 95% Macintosh) *because of SAP*, which has a NATIVE MacOS client. Apple frikken Computer uses SAP for chrissakes! This same management grew our Tech Support staff from four people (one manager and two staff on days and one staff on nights) to around 14 people to support the same number of machines simply because of the new support-heavy MS infrastructure.
What SAP does for businesses is centralize everything. Getting there takes a lot of time, and if you've got a set of home-grown apps that work together, there's not a lot of reason behind moving to SAP. Starting from scratch, I'd give it some serious thought. Coming from as heavy a DP background as I've got, centralization is a WONDERFUL thing.
From my experience:
Successes - Local order entry, plant management and scheduling were integrated after about a year. This was good.
Failures - Very business-specific chores took the longest to migrate and are still being migrated.
Not-Successes-if-Success-is-defined-by-full-Replacement - Everything SHOULDN'T be replaced. Two major home-grown systems critical to this company (of which one was in production and one was in development) are still separate, but integrated with, SAP.
Anecdotes - (Aside from my stultifying experience with the German instructor above) Go with Oracle or SAPdb. Don't go with Informix because it's "cheaper". Don't believe your VP of IT because he says that a huge 24' x 24' open cube with a hallway through it and desk area around the perimeter will help SAP get done quicker because everyone is working together in the same area. I mean, everyone will have their backs to each other!! Take your 5 years and multiply it by 1.5 for a truer estimate. If you are using the ASAP system, multiply by 2.0.
I have a bunch more, but I don't want this to seem like a vendetta - I really enjoyed doing the work I did at this place. I simply believe that SAP wasn't a good fit. Sadly, I didn't have a lot of pull, being a cog in the wheel and whatnot.
posted by tomierna at 9:19 PM on January 6, 2005
This thread is closed to new comments.
If you do a web search on:
"City of Tacoma" SAP problems
You'll get a variety of stories, including one with this quote:
"The city of Tacoma violated one of the key rules of a big ERP implementation," said Joshua Greenbaum, an analyst at Berkeley, Calif.-based Enterprise Applications Consulting. "They tried to do too much, too fast."
So that's one thing you're doing right.
If I had to offer a single piece of advice from more than a decade of being involved in system implementations, other than DO YOUR IMPLEMENTATION IN PHASES, it would be:
Don't be the first customer to implement any new functionality, if you can help it.
That means that if the vendor can't show you a customer running similar hardware to what you plan to use, don't use that hardware. If the vendor can't show you another customer who has the functionality you want (fast queries from a large database, computer-based image recognition, a Macintosh GUI, whatever), then consider other options (a third-party add-on, a workaround, a prototype/pilot that you're not absolutely committed to, whatever). Don't ever be the first on the block to implement a vendor's new release unless the one you have is badly broken.
Put otherwise: if you plan to do something that isn't ordinary, don't ask your vendor if they "can" do that something [because, with enough money, software can be made to do just about anything]. Instead, ask if their customers already are doing something. Then ask for a customer contact or two to confirm that the customers are doing that something, in a comparable environment, and are happy.
In the software implementation business, as in the Old West, the pioneers are the ones with arrows in their back.
P.S. Well, one more principle: if the vendor's software needs to be customized in an unusual way because one of your business processes is "unique", consider, then consider again, whether you really need to be so unique. Because if you do decide to be, you're going to forever have to deal with future vendor software releases that break your customization unless you pay for yet more software modifications.
posted by WestCoaster at 8:55 PM on January 6, 2005