PDA

View Full Version : What's so bad about SAP?


kasuo
03-04-2009, 11:31 AM
SAP was mentioned several times in this thread (http://boards.straightdope.com/sdmb/showthread.php?t=508105). 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?

An Arky
03-04-2009, 11:54 AM
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.

Smeghead
03-04-2009, 12:07 PM
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.

EmAnJ
03-04-2009, 12:25 PM
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.

Dazzling White Diamonds
03-04-2009, 01:04 PM
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.

Scarlett67
03-04-2009, 01:04 PM
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.

Khadaji
03-04-2009, 01:14 PM
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.

Cornelius Tuggerson
03-04-2009, 01:14 PM
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.

Raza
03-04-2009, 04:02 PM
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.

Ferret Herder
03-04-2009, 04:09 PM
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.

Tamex
03-04-2009, 08:11 PM
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?

Bartman
03-04-2009, 08:30 PM
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.

Ruminator
03-04-2009, 08:31 PM
Is there any good ERP software? Why would a company deliberately put themselves through this?

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.

Typo Knig
03-04-2009, 08:54 PM
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-ren-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:

treis
03-04-2009, 09:31 PM
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.

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.

tomndebb
03-05-2009, 12:12 AM
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.

lunar elf
03-05-2009, 09:27 AM
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.

Strassia
03-05-2009, 01:19 PM
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.

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

Charley
03-05-2009, 04:25 PM
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.

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).

Wilson
03-05-2009, 05:16 PM
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.

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!

Ximenean
03-05-2009, 06:14 PM
I work in the SAP industry (it is almost an industry in its own right), and I think tomndebb's summary is pretty good.

I think the reason that SAP is so successful is that they've made the best pitch, to date, at a true all-in-one business software solution. Integrated products from diverse vendors is an attractive idea, and probably some day it will actually work. But until that day, it's just simpler to buy your core MRP/ERP/whatever software from one vendor. This is the software that makes sure you have everything you need at the right time, that everybody's paying you, that you're paying them, that you're paying your employees and the taxman the correct amount, and so on and so on. It's a horrible interconnected mess, and nobody has ever come up with a workable all-encompassing solution for it.

SAP supposedly comes closest to achieving it. OK, it forces you to buy every component from SAP, even if most of them are shitty compared to the individual competition. But put it all together, and the idea is that you have an integrated (big SAP word, that, "integrated") solution better than the sum of the parts you could get elsewhere.

I'm not really convinced by all this, and think that a big part of SAP's success is clueless CIOs swallowing SAP's marketing bullshit and convincing each other that SAP is necessary. I think at some point an actually competent company, maybe somebody like Salesforce.com, will turn the ERP world upside down and SAP will be exposed as the barely competent dinosaur that it is.

rbroome
03-05-2009, 07:39 PM
I work in the SAP industry (it is almost an industry in its own right), and I think tomndebb's summary is pretty good.
I'm not really convinced by all this, and think that a big part of SAP's success is clueless CIOs swallowing SAP's marketing bullshit and convincing each other that SAP is necessary. I think at some point an actually competent company, maybe somebody like Salesforce.com, will turn the ERP world upside down and SAP will be exposed as the barely competent dinosaur that it is.

I think we have a winner:
from two posts upthread:
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.

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.

Like so many things (my pet peeve is corporate web sites-I have never seen one that was worth the electrons), making it look good to the senior execs that make the decision to buy is quite different from making a useful product.

hajario
03-05-2009, 09:20 PM
As a user, I hate it. It's totally counter intuitive. One false move in a busy screen full of buttons, tabs and links and you are shit out of luck. There's no way to search, no drop down menus with options, just a bunch of weird symbols.

Want to look at a document, enter CC04. Want to sign off on a document, enter IQS2 or maybe IQS1 depending on what kind of document. Start a purchase request, ZMM1 or something. Fuck. How does anyone make sense of that?

If you are creating a change order and you hit the button with the little green flag instead of the button with box and a pencil you have fucked yourself and probably lost all of your work which can't be saved part way though.

I don't know anyone who likes SAP with the exception of those fucking freeloading consultants who set up shop at your company for eighteen months and can't teach for shit when it comes time to do the training.

tomndebb
03-05-2009, 09:47 PM
Want to look at a document, enter CC04. Want to sign off on a document, enter IQS2 or maybe IQS1 depending on what kind of document. Start a purchase request, ZMM1 or something.
I always knew they should have built it on IMS-DC instead of CICS. :p

black rabbit
03-05-2009, 09:48 PM
Full disclosure #1: My employer competes with a very, very small subset of SAP's Logistics stack.

Full disclosure #2: I'm an infrastructure guy, so I cringe a little at the number of buzzwords I'm about to use.

Full disclosure #3: I'm on my second double deuce of Ruination IPA.

SAP will be toast within a decade. SOA and cloud computing sound like a whole load of flimflammery and bullshit right now, but when the Fortune 500 folks finally get their Service Oriented Asses in gear, a whole load of itty-bitty SaaS shops are going to spring up to eat SAP's lunch - in very small bites.

My company is doing quite well doing it now, with nothing more than a couple of EDI programmers and a few brilliant networking and systems folks (my team), a handful of web developers, and an ace DBA. We've sustained pretty impressive growth going on ten years now, and a significant number of our customers are also SAP shops. We do a very small bit of what SAP does, only much, much better, at a fraction of the cost.

And this is mostly via EDI and VANs or AS2, which is pretty one-off when compared to a mature, standardized SOA implementation. We just had our first current customer ask about switching from EDI to XML over secured FTP. They're chomping at the bit, and they're a Fortune 100. Make of that what you will.

Tamex
03-05-2009, 11:56 PM
As a user, I hate it. It's totally counter intuitive. One false move in a busy screen full of buttons, tabs and links and you are shit out of luck. There's no way to search, no drop down menus with options, just a bunch of weird symbols.

Want to look at a document, enter CC04. Want to sign off on a document, enter IQS2 or maybe IQS1 depending on what kind of document. Start a purchase request, ZMM1 or something. Fuck. How does anyone make sense of that?

If you are creating a change order and you hit the button with the little green flag instead of the button with box and a pencil you have fucked yourself and probably lost all of your work which can't be saved part way though.

I don't know anyone who likes SAP with the exception of those fucking freeloading consultants who set up shop at your company for eighteen months and can't teach for shit when it comes time to do the training.

That actually sounds worse than IFS. I can search (oops, I mean "query") for things if I happen to know which category to query under (and have rights to do so, which has been a constant problem). Our company managed to save a few bucks by having our managers who were on the IFS committee train us. :rolleyes:

Typo Knig
03-06-2009, 11:19 AM
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.

This perfectly describes the consultants I dealt with in both of the SAP-related projects I mentioned upthread. On the plus side, they were very nice people to deal with. But one should not have to explain to a logistics "expert" that an order may be for more than one item, so there may be more than one shipment involved in the order, and therefore two or perhaps a dozen shipping records. If it needs explanation, one should only have to explain this concept once. :rolleyes:

At least the consultants weren't arrogant jerks as well as being, um, uninformed. I've dealt with those kind of folks on other projects. :(

Charley
03-06-2009, 12:40 PM
It's true, and I really think it is one of the main reasons that implementations can go so wrong. A good implementation should be one that provides the business with the tools that it needs to do the work it needs to do - so surely the starting point should be understanding the work that the business does. If you spend any time on any of the support boards (particularly those that are not run by SAP themselves) it'll curl your hair. I just keep thinking "someone, somewhere is paying you very handsomely and THIS is the sort of thing you don't know?"

The SAP industry (and I agree that it is an industry) has unfortunately developed a name as a bit of a gravy train, and it's attracted far too many people with far too little business experience. The technical side of implementation isn't hugely difficult, although it's time consuming and it can be fiddly: what you pay external 'experts' for is the experience to know what the effects of your choices will be.

I cringe when I hear the horror stories, of which I have plenty too, and the real loathing, but it's common to hear. It starts to sound like an excuse, even to me, but I really do believe that it's a great system, considering what it has to do. However it is easily, and often, implemented very badly and that makes all the difference. For every person saying they can't find anyone who's had a successful implementation, I could find you one who has, and I could get you ROI numbers to measure the success. ::shrug::

(I'm trying to balance the need for full disclosure of my interest here with my desire to preserve some level of anonymity by the way, but I am very closely involved).

Tool of the Conspiracy
03-06-2009, 01:08 PM
This perfectly describes the consultants I dealt with in both of the SAP-related projects I mentioned upthread. On the plus side, they were very nice people to deal with. But one should not have to explain to a logistics "expert" that an order may be for more than one item, so there may be more than one shipment involved in the order, and therefore two or perhaps a dozen shipping records. If it needs explanation, one should only have to explain this concept once. :rolleyes:
My company recently converted from AMAPS to SAP. For a long time, I was able to joke about the consultants, "the third floor is full of sap". Thankfully, I don't have direct contact with it, but I've heard it called a "write-only" system.
Your anecdote reminds me more of the consultants the company hired to build its e-commerce site. After the contracts were signed and work was in progress, they asked if it was really important that an order could have more than one recipient.

Send questions for Cecil Adams to: cecil@straightdope.com

Send comments about this website to: webmaster@straightdope.com

Terms of Use / Privacy Policy

Advertise on the Straight Dope!
(Your direct line to thousands of the smartest, hippest people on the planet, plus a few total dipsticks.)

Copyright 2018 STM Reader, LLC.