9 ms·

My mother works for a fairly large textile lab. For decades, they used an internally developed system for lab reports (they had a few programmers and admins the

• forinti 4y ago
  What was the motivation to switch to SAP? Was the in-house solution lacking?
  • math-dev 4y ago
    Working in a large corp, I find IT consultants from the outside overpromise and underdeliver on projects It’s infuriating as anybody below senior management can see right through it
    • hef19898 4y ago
      SAP and ERP consultants are not your average IT consultant in that case.
    • sumedh 4y ago
      > anybody below senior management This happens because the people working below senior management are usually not slick talkers and many people in senior management do not understand IT. So a savvy salesman who knows the right words can convince the guys at the top to do what he (its almost always a he) says.
  • lqet 4y ago
    AFAIK, they introduced SAP elsewhere in the company, and it became difficult/too expensive to manage the communication between the old system and the SAP system. I can imagine too well how the conversation between the SAP people and the company went because I also took part in similar conversations with clients in a previous job a long time ago: client asks you if software X can do thing Y. Both you and the person representing the client have only superficial domain expertise on Y. "Oh, you mean enter data into a form? Of course software X can do that, it was designed exactly for that purpose!" The complexity of the task is eventually discovered in production.
    • ornornor 4y ago
      > The complexity of the task is eventually discovered in production. I’m amazed that this is what happens every. Single. Time. And yet we plow ahead with this kind of projects like we have no idea it’s the usual outcome. A couple years and millions over budget later, we rediscover this axiom. I really don’t get it. And try to warn about this, you’re labeled as not a team player or whatever and paint crosshairs on your back for the next round of layoffs. It’s just soul sucking.
      • lotsofpulp 4y ago
        On an individual decision making scale, there are no repercussions for the bad outcome. The people who decide on plowing ahead get another bullet point on resume for “accomplishing” something, since the outcome is impossible for an outside entity to verify, but doing “something” is verifiable.
      • magicalhippo 4y ago
        > I’m amazed that this is what happens every. Single. Time. The details about the day-to-day operations disappear quickly as you move up the hierarchy. My boss recently had a meeting with a large customer of us, we deliver a product used heavily by one of their departments. Here's roughly how that went down: My boss: "Well, what about when you do orders of type X?" Manager: "Oh we don't do those" My boss: "Really?" My boss brings up the order list and filters on type X, finds at least one entered each day by user ABC Manager: "Oh... so that's what she does" So that information was lost in just one level. This is why we try our best to get the actual users involved when discussing requirements with a customer. I don't think I've ever experienced a project where at least one of the users haven't brought up some edge case the manager wasn't aware of or had completely forgotten. On the flip side, the projects where the users are left out of it until it goes live never goes well. We'll get it fixed eventually, but there's always pain for far longer than necessary.
  • ssdspoimdsjvv 4y ago
    In-house tooling requires a dedicated team, not just developers but also analysts, testers, etc. Often a company inside the company. If the software needs to change due to industry changes or regulations or something like that, it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes.
    • PeterStuer 4y ago
      The idea that the SAP solution will be "off the shelf" is just not true. You will need as many of those roles, probably many more, to keep the SAP based solution running.
    • modo_mario 4y ago
      >it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes. If your company is small or at least in a field with lots of competition sure. I work in a >100person company that encounters loads of regulatory changes due to food safety and lots of international trade and 2 people developing is good enough. The part doing the accounting and such is largely outsourced to an ERP but is honestly simpler yet just as costly if not more. What's more things go wrong. That's a given and the absolute best way to deal with it is with someone as close to the processes as possible. you don't want to be calling vendors that are generally absent to see in which part the software lies. Even for industrial equipment that is a lot more single process it is kind of accepted that we people on the ground need to know a good bunch to troubleshoot ourselves rather than paying someone to come over. After all if we wait for that we get a bottleneck that has dozens of people twiddling their thumbs.
  • PeterStuer 4y ago
    Their most succesfull salespitch to the CEO is that you're not a real company untill you join the SAP club.
    • tiborsaas 4y ago
      Kinda genius pitch, if a company can't burn millions without serious troubles it's not really a stable, big player :)
    • saiya-jin 4y ago
      Or you don't have a solid business until it withstood trial by SAP implementation and subsequent reality check
    • speakfreely 4y ago
      Salesforce uses this one, too.
  • crispyambulance 4y ago
    If it was like typical ERP/MRP rollouts... The short answer is that a sales guy in a nice suit took some execs out for steaks and more than a couple cocktails. The long answer is that management, these days, is trained to outsource everything while still being clueless about what the people they're replacing actually do.
• threatripper 4y ago
  They probably cheaped out on SAP consultants. Each of the old IT staff in the old system you can replace with 3-5 SAP consultants.
  • avereveard 4y ago
    SAP is better though as a set of libraries than a solution, and it's worth a lot precisely because it will fit whatever whacky process an organization has so that the org doesn't need to change itself while adopting the software. The most obvious failure modes are going for the lowest bidders incentivizing them to deliver with a skeleton crew, trying to nickel and dime the budget cutting features or their scope or straight up coming at the table with no documentation of how orgs own internal processes actually work. I know of no project failing because of sap or their consultant on its own without any of the above comorbidities.
    • mr_gibbins 4y ago
      I taught enterprise systems for a while and SAP's ethos is very much 'change your business processes to fit SAP, because if they don't fit SAP, they're probably wrong'. This is actual advice (in slightly different wording) that comes from their training materials.
      • threatripper 4y ago
        It's probably both. If you fit the standard pattern you'll have an easy time to adopt. But they also support edge cases with extra work. A small company with many non-standard processes will need so much extra work that it's not worth it. Then it is cheaper to redesign the company and reshape the company processes. I find it very difficult to fight for sensible defaults in a company when everybody only sees their area and has a very strong opinion about that. Only a strong force like the SAP transition can break up with those encrusted structures.
        • jasamer 4y ago
          Lidl tried to switch to SAP, keeping their own processes and customising SAP to fit their needs. After seven years and 500 million euro spent, the project was cancelled and they went back to using their old inventory system. So, in this case, customising SAP to fit the company's processes wasn't worth it even for a rather large company like Lidl.
• julienfr112 4y ago
  SAP embed in the software knowledge and enforcement of the organization the company should have. This knowledge that build in the last 30 years by working in logistic, manufacturing, retail... When you install SAP, you should obey SAP, like I don't know, rust (don't try to do c++ in rust ;-) ... If SAP has nothing to say about organization at a Lab, just don't by SAP.
• johannes1234321 4y ago
  The thing with an SAP introduction is that one has to analyze and understand how the business actually works to adapt the system to it. However in reality nobody really knows. There is a general idea, hopefully, but over time there are more and more shortcuts and side processes and things. Unless you analyze them an introduction of any new business software (be it SAP or Oracle or whatever) will fail. Whether it is worth it depends a lot and is hard to say. It will certainly demotivate many employees who are used to the old way, but might lead to streamlining (partially due to software, but norendue to analysis) and more insights (with risk of then optimizing the wrong metric)
  • hef19898 4y ago
    Agree, except one point. You adapt your system to SAP, not the other way round. And tgat is actually a much better thing than it seems, because SAP is used in so many comoanies that you get a load of best practices out of the box. Adapt those core competitive advantages you have, take the rest as is. By the way, edge cases, if if they work in a legacy system, are a thing to get rid of during a SAP / ERP implementation. Most people see ERP systems as IT projects and fail. ERP projects are at least as much business reengineering projects as they are IT projects.
    • jensgk 4y ago
      Yes, that is also my understanding. SAP implements "best practice" solutions, and companies adapt to SAP to get the advantages af that.
    • saiya-jin 4y ago
      First part what you mention is a bit arrogant, no company wants to do that, and by doing it would lose most of competitive advantage which can very well be in those edge cases and their handling (and often they do lose their edge by going SAP way and sometimes collapse because of it). Like hearing SAP sales guy. Second part is actually correct - you have to change your way into how SAP works, its just a typical crappy legacy rigid mammoth software that requires overpriced army of devs/analysts, not much more. If it would be marketed that way, they would go bankrupt very quickly because no company willingly wants to do that, and certainly not at that cost. But anytime some c-suite manager picks up SAP, you can be sure there were some nice meetings done in ultra luxurious places and more often than not some bribes went that way, in one form or another. This is the way, if your system sucks so much it destroys companies
• kensai 4y ago
  I am sorry, but anecdotal cases of hickups in the transition between a bespoke system to an SAP one do not mean that SAP is useless. I don't understand why you don't blame the internal IT guys who did not nail the specifications for the SAP to work exactly as wanted in the first place? And what is the take-home-message here? Should they have stayed with their (admittedly not good enough) internally developed system? Should they have gone for an Oracle solution (plagued with its own set of anecdotal catastrophes)?
  • nordsieck 4y ago
    > I don't understand why don't you blame the internal IT guys who did not nail the specifications for the SAP to work exactly as wanted in the first place? Often times it's very difficult to correctly specify a system. This is one of the problems with lock files and why some people have gone over to docker for development. IMO, the people to blame are management, who needed to appropriately staff the transition for enough time to get it right. > Should they have stayed with their (admittedly not good enough) internally developed system? What evidence is there that it wasn't good enough? Sometimes management gets sold on a "better" system, only to find out that it isn't actually better.
    • kensai 4y ago
      This is not for me to prove or answer, but the OP who brought the anecdotal case here as "proof" that SAP is Scheiße. :)
• SnowHill9902 4y ago
  That’s because SAP is a bed of Procrustes.
• vain_cain 4y ago
  I see a lot of comments here saying a company should adapt their business processes to their ERP, and in my experience they are wrong - with the exception of accounting(Good luck trying to customize accounting modules within ERPs to fit your process). I don't work with SAP, but I've been working with Microsoft's ERP(Dynamics NAV/Business Central) my whole professional career(almost 5 years). When it comes to shipping, manufacturing, HR, supply, sales, planning, quality assurance etc... every big company is going to have a million edge cases which are impossible to cover with the standard functionality of an ERP. And most importantly - hundreds, or maybe thousands of employees that have gotten used to working a certain way. When you try to make your process fit to a standard ERP functionality you are fighting two dragons: 1) Working your way around edge cases - with the right consultants/developers this doesn't have to be a big pain. 2) Getting your employees to change the way they have been working for years, or even decades. And in addition giving them an overwhelming UI - I've never seen this work as planned. This is also probably the reason the company your mother works for had so many pains. On the other hand, if you try to make the ERP fit to your processes, there's only one dragon you need to slay - extending the ERP's functionality. I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.
  • IceDane 4y ago
    > and in my experience they are wrong - with the exception of accounting > I don't work with SAP .. Yeah.. that's just it. Your experience doesn't matter. Adjusting your business to fit SAP nearly as much as an unspoken requirement. It's not just a smart bit of wisdom people throw around. It's literally what you have to do if you want to have any hope of implementing SAP successfully, because it is such a colossal, messy charlie-foxtrot that there is no hope otherwise. Not even SAP's own people understand their own mess.
    • vain_cain 4y ago
      You're right, for some reason I just assumed all ERP's are as easily extendible as Microsoft's. It just makes sense they would be oriented that way due to the complexity of the world. I often hear horror stories about SAP, and can't for the life of me figure out why it's so popular(except it's more oriented than other ERP's to non-tech savvy people).
• ineedasername 4y ago
  The job of the implementation project and team (generally comprised of power users and staff from the vendor or certified partners) is to find those edge cases and automations so they can be dealt with. Most ERP has halfway decent workflow automation tools and development tools that make small modifications easy and large ones at least possible, though for huge gaps an organization might just choose a best of breed 3rd party tool and write bidirectional ETL jobs using APIs. The real problems are 1) organization staff on the implementation who don’t actually know enough edge cases etc. This can be through poor requirements gathering ir because the power users are considered too important to take off their normal work and the company is too cheap to hire enough temp staffing to cover their absence. 2) A bad “fit-gap” analysis the maps old system functions to the new system to find the gaps. This is the vendor/partner (consultants) job so that’s on them. Failing here sets the project up for failure or major cost overruns or just years of people pissed if that they can’t do what they need to do. It also breeds shadow systems and work arounds that make knowledge transfer after staff departures vastly more difficult. 3) vendor/consultants looking to maximize $$ by either sandbagging hours of work with unnecessary things like customizations that are just not needed. I’ve seen plenty of examples where vanilla functionality is much faster than the old system but “that’s not how we do it here” . The vendor doesn’t care to push back because they’re getting paid for the extra work, and when the customer runs out if its 1,000 hour block of custom dev time and still has essential work undone the customer has no choice but to pay up or suffer. Meanwhile the vendor has every email and change request order signed off in their records where the customer approved the work so they just shrug their shoulders. 4) A general unwillingness by the customer to actually pay the $ required to do these things right. There seems to be a sense in higher level leadership that “it’s software, how hard is it to install software?” and have no clue and don’t care to hear it until the sky is falling that there’s a lot more to it. There’s more too, but I’ve been on a few of these and never seen one that didn’t include some combination of the above. They absolutely can go smoothly with a minimal amount of the above but it takes real work and a dedicated procurement & vetting process just to find the right outside implementation partner (going with the vendor itself is sometimes okay, sometime not. I wouldn’t touch Oracle Consulting ever ever.) Even then it will not always be as smooth as using a legacy erp with roots in the early 80’s that has been customized for decades. But that sort of tech debt is massive. New functionality can be a nightmare, causing more tech debt and raising maintenance costs non linearly. If it needs regular updates for things like federal compliance (tax systems or other regulated areas) a vendor might when it finally EOL’s a system it first released before you were born still provide those updates to remaining customers of their legacy product to give extra time to transition but then you need to either role your own dev team to do it or pay outside consultants to do so: Retirees from places like SAP often make a nice bit of extra income doing dev work like this. TLDR: Too late, you already read this far.
• treis 4y ago
  >Everytime I talk with my mother, she complains about the system and tells me that another colleague has quit I used to be a consultant for a big non-SAP workflow product. Had a long time employee quit specifically because of how bad the product was. That was not an easy thing to explain away.
• irrational 4y ago
  I work on a home grown solution at work, but they are considering abandoning it for a third party system that everyone we talk to says is inferior in every way. For some reason, the higher ups trust software built by someone else rather than their own people.
  • civilized 4y ago
    > For some reason, the higher ups trust software built by someone else rather than their own people. The pointy-haired bosses of our nightmares are real.
  • RNAlfons 4y ago
    The reason is that their own people become exchangeable if you switch to something of the shelf.
    • veltas 4y ago
      Joke's on them, SAP is different everywhere.
  • targafarian 4y ago
    Marketing is a helluva drug. People are trained to trust big companies and the bigger the company the more they trust it. I think the issue is the variance in solutions if you compare all the homegrown solutions against all the big company solutions. And that gets managers into the mindset that there's less risk in a generic big company solution. But of course that misses all the details for a specific case like yours. It would be like interacting with other people who knew based on the average of everyone on Earth as opposed to dealing with the person you knew based on their own personality. But it's easy to manage based on these kinds of broad generalities and, as the saying at least once went, no one gets fired for choosing IBM.
    • irrational 4y ago
      In this case, the third party company is tiny. And they keep screwing up. Even something as simple as right to left language translations they can't get right, even when we walked them through how it should work and shared code with them.
• dominotw 4y ago
  > . The SAP solution missed so many edge cases that a huge number of lab reports were either inaccurate or completely wrong because information was lost in SAP translation between different labs. Is this the story of every migration, every rewrite though?
  • marcosdumay 4y ago
    On every rewrite, the system gets either better with time or abandoned. A system completely broken forever is something only the upper management can create.
• rossdavidh 4y ago
  From what I have seen and heard, this is a pretty typical result of converting to SAP.
• agumonkey 4y ago
  SAP should be illegal. I've seen those kind of non-tool that cause more diseases and more efforts too often.