Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Government The Almighty Buck The Military United States Your Rights Online

Army's Huge SAP Project 'At High Risk' 166

itwbennett writes "The Army's $2.4 billion SAP project is delayed, over budget, and, once implemented may not even meet its original objectives, according to a recent auditors' report. For its part, the Army is less concerned with the auditors' findings about the project that will manage a $140 billion annual budget and serve nearly 80,000 users once it is complete: 'The Army believes the risks identified in this report are manageable and do not materially impact the [project's] cost and schedule,' said an official with the Assistant Secretary of the Army (Acquisition, Logistics, and Technology)."
This discussion has been archived. No new comments can be posted.

Army's Huge SAP Project 'At High Risk'

Comments Filter:
  • by sortius_nod ( 1080919 ) on Saturday July 09, 2011 @07:31AM (#36703698) Homepage

    When you go with SAP.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Horseshit. That's what you get when you don't clearly define what you want, when you change requirements all the time, and when you delude yourself into thinking that SAP will work for you "out of the box."

      • by amiga3D ( 567632 )

        And when it's more important for you to set up your big contractor job after retirement than to watch out for the public's money. I've seen that time and again where officers get seduced by contractors for a big 6 figure post retirement check.

        • by fyngyrz ( 762201 )

          "The Army's $2.4 billion SAP project is delayed, over budget,

          ...they should have planted more maple trees, no?

          Seriously, when someone writes a summary, please don't use unexplained acronyms. You know we don't RTFA.

      • by Anonymous Coward

        EXACTLY!

        I was in the ARMY for six years and I know how it works. I have worked with (not for) SAP for six years. If you KNOW what your REAL requirements are and you define them well, implementation does not have to be hell. Unfortunately, people don't usually understand the difference between actual REQUIREMENTS and their old processes. Almost without fail the business will declare their old processes as their requirements... and try to force SAP to function almost exactly the way their old system did... wh

        • by Tablizer ( 95088 )

          Almost without fail the business will declare their old processes as their requirements... and try to force SAP to function almost exactly the way their old system did

          I've seen this with a system in which it was decided to mirror the paper forms in structure, which also meant keeping the duplication of the paper forms. Complex algorithms were needed to find the latest version of things like addresses. It would be like asking Henry Ford to make his cars shit like a horse and gallop away twice a month when a

          • Agreed. Very often the "requirement" is written about how they do it, rather than what the end result should be - which you can get by a different way.

        • How do you determine your needs in an organization where the managers don't want to be involved in the move to SAP, the processes vary quite a bit across the business, no-one really understands what SAP can do (and they don't want to learn), and the current processes depend on individual Excel/Access/etc apps which can't be stamped out if people don't buy into SAP?

          Can you give me a typical success story for a large, complex, diverse, IP driven enterprise?
      • I spent 30+ years in IT doing administrative programming. I saw this sort of thing happen constantly. Almost all the users I ever dealt with were of the "How do I know what I want until I see what I get" persuasion. So we gave them what we thought they needed and told them to live with it. They did. If you tried to force users to define their needs as completely as possible, you'd never get out of the requirements-definition phase of a project. Never. Users have neither time nor inclination to define th
    • by PhunkySchtuff ( 208108 ) <kai&automatica,com,au> on Saturday July 09, 2011 @08:17AM (#36703910) Homepage

      Exactly, the thing with a SAP rollout (or anything else of this magnitude) is that you pass the point of no return quite early into the project and then the consultants have you exactly where they want you - you can't go back now to your old system, but the new system doesn't really do what you expected it to either so as expensive as it seems, it's cheaper to keep paying more to fix the new system than it would be to migrate everything back to the old system...

      Once it's all in place and working as it should, SAP can be a fantastic thing to have but getting there is _never_ as straightforward as one would be lead to believe initially.

      • by sphealey ( 2855 )

        > Exactly, the thing with a SAP rollout (or anything else of this
        > magnitude) is that you pass the point of no return quite early
        > into the project and then the consultants have you exactly
        > where they want you

        Here's a thought: consultants are there to do just that: train, guide, and consult (e.g. _assist_ with analyzing). The people doing the implementation should be the organization's managers (not "project managers" - managers) and the employees who will be using the system. Once a projec

        • Egh... You have no idea what an SAP consultant title constitutes, do you? Hint: There's not much actual consulting going on there.
          • by sphealey ( 2855 )

            I dunno - after my first 10 ERP implementations I sort of lost track of which system I worked on for which project/employer. Clearly you know far more than I.

            sPh

            • by BooRadley ( 3956 )

              Since you're a member of the 4-digit ID club, then you may just be old and gray enough to have survived more than 10 of them. Are you functional or technical?

              • by AK Marc ( 707885 )
                I was the first sale on Avaya's SAP implementation. After three sets of the wrong equipment and complete failure of accurately scheduling project member time internally, our system was installed. I'd have complained, but as far as I can tell, the billing was no better and we ended up with a credit on our bill when we should have owed $120k (they billed us once for the product we ordered, and then credited us back each time when we shipped the three sets of wrong equipment back).

                Given that it took them
        • by HungryHobo ( 1314109 ) on Saturday July 09, 2011 @03:24PM (#36707050)

          Story I heard second hand where jeff is a friend of a family member:

          There was once a small startup where the founders noticed that most of the software for handling a particular task was needlessly complex and stupidly hard to use.

          So they created their own version which was apparently good and very easy to use. the few customers they did pull in were very happy with it but they couldn't seem to break into the big leagues.

          They discovered that some such attempts to sell their software to big corps had been shot down by the local consultants.

          They tried contacting the big consulting firms to try to find out what they considered to be wrong with their software so that they could fix whatever problem was putting off the consultants but got back useless boilerplate replies just stating that they didn't think it was suitable.

          Then one night in the bar at an exhibition one of the founders (lets call him jeff) got chatting candidly to someone from one of the big consulting firms(lets call him carl).

          So jeff asked carl if he'd seen their software and what he thought of it.
          carl said that it was quite excellent.
          jeff asked why then did carls firm recommend against their clients using it.
          Carls reply was that it was simply too easy to use and too easy to set up.
          If Carls company recommended a worse piece of software that was hellish to set up then they were guaranteed many many billable hours as the client would be almost guaranteed to need consulting services.

          So jeff went home and his startup set to work adding a myriad of essentially useless options and made the software vastly harder to configure.

          it was still the same software once it was running but now the manual was a tome rather than a pamphlet and the setup took an expert rather than an amateur.

          Like magic sales went up as consultants were suddenly willing to recommend it to their clients.

          • Story I heard second hand

            You appear to have mistyped "totally made up".

            I'll be charitable and assume it's true that such a system exists and does all you say it can.

            All it would take is one small, hungry consultancy - even a bunch of mates - to start pushing it and they could undercut their competitors by a huge margin, while still coining it in.

            Prove you're not a liar, on this one at least: provide a citation. Name of company and system. Real names for jeff[sic] and carl[sic].

    • by Surt ( 22457 )

      I'm confused why you're modded funny rather than informative.

    • Re: (Score:3, Informative)

      by trevelyon ( 892253 )
      Yep, never been involved in any SAP implementations but I've seen several. Not one was completed anywhere near the deadline or original budget. Additionally, none of the companies got what they thought they were going to from it (always decreased deliverables). Mind you this is a relatively small implementation pool (5 companies) but zero successes is not a good sign.
    • by Evets ( 629327 ) *

      This should be modded insightful.

  • Not surprised (Score:5, Interesting)

    by edgedmurasame ( 633861 ) on Saturday July 09, 2011 @07:33AM (#36703706) Homepage Journal
    The only people who will get something out of SAP are the consultants who get paid to "fix" it.
    • ah, my kingdom for mod points.. As to the earlier post that requirements weren't locked down, and changing needs lead to this. I doubt that there has EVER been a SAP project that didn't have significant scope creep and redefinition midpoint. Also, two or three different phases with different consultants (early, mid, and closer) to get to a mostly functional system.

      Ah, the joys of enterprise software.

      • If requirements et all aren't locked down, then frankly don't start a massive scale project. Instead, start small get something delivered and work to build it up over time when they have a better understanding of what they actually need. A bit of discipline in the programming side can work wonders in making small things big. I've done it, it isn't impossible in the least.
        • If the scope of a project is big enough, it is actually impossible to nail the requirements because they will never get consistent. This is also the reason that there is a direct correlation between the size of the project and the successrate. To my knowledge, no single IT-projects over 100 million dollars has *ever* been completed within a reasonable amount of time and in range of the budget, with most of the desired features intact.

          Ofcourse, even with a gazillion users there's no need to have a really com

        • by Evets ( 629327 ) *

          That makes sense for everything. But when the consultants don't know the product, the client doesn't know the product, and the sales rep doesn't know the product, it's impossible to know what the requirements should be. Mix in the fact that the consultants need projects to move forward because they need the money, and sales people need projects to grow because they need the money, and the client needs projects to move forward because their current state of operations is overwhelming and obviously ineffici

  • by spaceplanesfan ( 2120596 ) on Saturday July 09, 2011 @07:39AM (#36703732)

    Why that isn't cancelled, but Webbs telescope is? Ah, its thats the Army....
    RIP US space program

    • http://www.jwst.nasa.gov/ [nasa.gov]

      I just visited NASA Goddard (great visitor's center, take the kids) and according to the web site they're working toward a 2018 launch of the James Webb Space Telescope. Quite impressive if you can also wrangle a lab tour.

      • The latest proposed budget for NASA cancels it.

        Too bad we spend so much money on wars that don't make us any safer that we can't afford science. I am so utterly disappointed in Obama...I didn't fall for any of that "change the world" stuff, but I honestly thought he would be better than this. I can't remember who said it, but this isn't my quote, 'As a President, Barack Obama makes a great Senator'.
        • To be fair Obama asked for a raise in their budget and Congress cut it and asked for a small cut in the military budget and Congress upped it.

          President don't have as much control as the talking heads may imply. On the other hand I'm sure he could have done more. Just thought it was a good thing to know, though

  • What is it about government IT projects that makes them go so disastrously wrong? The UK government are no better at getting it right. The MOD* procurement system was a similar mess - over budget, and didn't do what it was set out to do.

    * Ministry of Defense

    • by Joce640k ( 829181 ) on Saturday July 09, 2011 @07:53AM (#36703784) Homepage

      Because:

      a) They always employ people with the right connections instead of the right competence

      b) Because the consultants they hire know the real money comes from doing it wrong? Why make an effort to deliver on schedule and under budget when you can take your time over it and earn twice as much money in the process?

      You might think I'm joking but I've sat in some of the meetings. When I arrived I was under the delusion that I was there to do some work but I was completely wrong, we were only there to kill time before going off to a nice little French restaurant somebody had discovered. My bad.

      • the real money comes from doing it wrong

        The longer I stay in the software industry the more this fact depresses me.

        • by jd2112 ( 1535857 )

          the real money comes from doing it wrong

          The longer I stay in the software industry the more this fact depresses me.

          If I were a little better at programming and were a LOT less honest I could get stinking rich writing enterprise software.

          I take that back, my programming skills, though weak, are better than a lot of the enterprise software developers I've encountered.

        • I believe that it is really because the software industry is young. Most industries went though this phase for a while before discovering the truth: The REAL money comes from the next project.
          • Say you are a builder. If you make a good building for a client they will come back to you for the next one. Software is different. They will install the next one from your distribution, unless you foresaw this problem and broke the software so this couldn't happen.

      • by Anonymous Coward on Saturday July 09, 2011 @08:15AM (#36703902)

        c) They still believe in Waterfall development methodology. They also believe in "fixed-price" contracts. It's the change requests that kill you. The consultants gladly build what you asked for. Then when you realize that you really didn't know what you wanted, they have you.

        • by amiga3D ( 567632 )

          Oh man. You nailed that dead center. Too bad you posted anon 'cause that was a plus 5 informative if ever I saw one.

        • Gosh, that's going to be the most insightful comment. The only thing I can do is ammend it a bit.

          Currently, as least in Europe, every high priced contract needs to be tendered in the open. This however means that you need to know beforehand what you want. So basically they bring in the consultants at an early stage to create the business case. Then they tender the thing (after a Q&A of the possible participants). And of course price will be a big decider for who wins the tender, so each and every partic

        • The Waterfall model works very very well in *cultures* where it fits. In Japan for example time and time again they have used the Waterfall model successfully. Americans with a government contract? Yeah, they don't culturally fit the model and, as it's been pointed out, a government contract will make you money for as long as you can extend it in America.

          There's nothing wrong with the Waterfall model - but perhaps the American government should learn no American company bidding for a contract with a Waterfa

          • by JamesP ( 688957 )

            Waterfall works if you have:

            - a very clear definition of the problem, hence, the problem shouldn't be too big (think a Wordpad sized project)
            - a very thorough knowledge of the technology and its limitations (project that works in several web browsers? forget it)
            - almost no variation in deployment and use conditions

            Not many projects fall under those categories

            • by sphealey ( 2855 )

              > - a very clear definition of the problem, hence, the problem shouldn't be
              > too big (think a Wordpad sized project)
              > - a very thorough knowledge of the technology and its limitations (project
              > that works in several web browsers? forget it)
              > - almost no variation in deployment and use conditions
              >
              > Not many projects fall under those categories

              And more generally: that is knowledge and wisdom that is typically only obtained by /doing the project/ - hands-on.

              sPh

            • I've worked on a lot of projects here in Japan and I can tell you with absolute confidence you are wrong. Most console games are developed under a Waterfall model for example. A lot of embedded software as well. The Waterfall model works if you have developers who actually implement according to the designs and do it well. The Waterfall works in getting products to market. I'm convinced this has a big part to do with social and developer culture in Japan.

              Perhaps another factor is how the Waterfall model is

              • by JamesP ( 688957 )

                I've worked on a lot of projects here in Japan and I can tell you with absolute confidence you are wrong. Most console games are developed under a Waterfall model for example. A lot of embedded software as well. The Waterfall model works if you have developers who actually implement according to the designs and do it well.

                Except you just proved me right.

                Games: 20% code, 80% art. And that's true even for the first Super Mario games. And game engines are reused often.
                Fixed platform (same thing for embedded sw). Working in a restricted platform is much easier in some aspects than, for example, a desktop program.

                Reading the Mythical Man Month may explain it better.

                The Waterfall works in getting products to market. I'm convinced this has a big part to do with social and developer culture in Japan.

                Perhaps another factor is how the Waterfall model is implemented here. We have planners for example - they do all the planning and they deal with inconsistencies that arise during implementation. Planner work -under- designers, but planners work -for- programmers. Furthermore, the Waterfall model is just used for the core application - peripheral features and post-release enhancements [kakuchou - kaizen] are rarely handled using the Waterfall model. In addition the implementation step is usually broken up between departments with a set of joining critical-passes - basically becoming a separate process in and of itself.

                That's very interesting. Yes, for core features Waterfall works better.

          • by olau ( 314197 )

            There's nothing wrong with the Waterfall model

            Yes, there is. Go read up on Design of Design by Fred Brooks (known for the mythical man month and no silver bullet).

            The problem with the waterfall model is that it does not allow for learning. With many IT projects, both the client and also the developers need to learn about the problem space and each other.

        • There have been succesfull projects with waterfall methods. There have been a lot of succesfull projects with fixed price contracts: for the last 15 years I've never done business on any other basis (both as buyer and as supplier) - if you know what you are doing it's not a problem at all.

          Even competence of the people involved isn't an issue. In a project that big, there's bound to be a lot of nitwits but the competent people can usually work around them.

          No, what kills this thing is that even with the Gods

      • by bertok ( 226922 ) on Saturday July 09, 2011 @09:54AM (#36704420)

        Well, I'm a consultant working primarily for government, and I can honestly say that those aren't the reasons why these projects fail.

        Corruption in hiring is surprisingly rare in western countries, and usually involves only a small subset of the people on a large project. I've heard it's a serious problem in developing countries, but I've only seen it a few times here, and and I've only ever seen it lead to a project failure when the project team was only a handful of people.

        You'd be surprised about the work ethic of consultants.

        For some consulting organizations, there's so much work that they prefer to have their consultants finish projects quickly so that they can go on to other projects and hence satisfy all of their customers, not just some of them. Not turning up at all is a surefire way of losing a customer to your competition, which can go from nonexistent to serious in very little time if they suddenly start landing big projects.

        More commonly, consulting is only a part of what a company does. Large vendors like SAP sell licenses, support contracts, and consulting separately. If one branch of the company starts annoying the customers (too expensive, slow, incompetent, etc...) then this drags down the results of other branches too, and then their executives become very angry and complain directly to the CEO. God help the consultant working for an organization that makes most of their profit from licenses if the fuck up a sales deal!

        Lastly, consulting firms tend to hire better-than-average people, and those tend to be high achievers and motivated professionals. Delivering projects on time and on budget looks good on a CV, and can lead to even more lucrative positions.

        I've seen enough projects that I've figured out that government contracts go over budget or time for several inter-related reasons:

        - Ridiculous levels of risk aversion -- if there's no bonus or profit to be had, then no risk is worth it. This leads to some very stupid decisions, over-engineering, etc...
        - Management overhead -- big bureaucracies ignore the cost of management overhead, because the only way to reduce it is to fire a bunch of managers, but management makes hiring and firing decisions! Almost nobody would ever fire themselves. Instead, managers rationalize the need for management. There's no arguing with people about useless processes, when the existence of that process, useful or not, keeps them employed.
        - Conservative approach to IT -- a big project is hard enough, but when you also have to deal with decades old software and sometimes even hardware, the difficulty becomes astronomical. In quite recent times, I've come across all sorts of fun things in the core infrastructure of large organizations. For example, OS/2 is still in use. Novell NetWare refuses to die. I've seen Windows 95 as a server in a data center just recently. I did a lot of work on an enterprise DOS application just a couple of years ago. It's not just systems, but processes to. Why change anything, just because the software is completely different, and the hardware is six orders of magnitude bigger or faster?

        So imagine being the consultant hired to rip up and replace 10s of millions of lines of code across hundreds of undocumented systems, most of which should have been cleansed with purifying fire decades ago, but you're not allowed to. Instead, you have to sit patiently through a never ending series of pointless meetings that serve only to prevent any bureaucrat from ever having to make a decision, or take any blame for anything.

        • Lastly, consulting firms tend to hire better-than-average people, and those tend to be high achievers and motivated professionals. Delivering projects on time and on budget looks good on a CV, and can lead to even more lucrative positions.

          Yeah.... No.... Do you happen to work for IBM or Accenture? Because they definitely don't hire 100% of high achievers and they definitely don't tend to. Although IBM is the best "supplier" of freelance SAP consultants on the market(EU) at the moment.

        • by TarPitt ( 217247 )

          I do similar work and I'd like to add that sometimes projects are, by nature of the customer itself, impossible to accomplish successfully. Requirements may be impossible to pin down or shift randomly. Resources necessary to finish the project are unavailable. Key users may be hostile to the project and unwilling to use a system that they feel (right or wrong) is a political hammer against them.

          What I have NEVER seen is a consultant or system integrator willing to tell the client blunty that they have cr

      • a) They always employ people with the right connections instead of the right competence

        And even when they do, they believe that certificates and training takes precedence to experience. In short people in government are taught to be ignorant of experience, but guess who's teaching them that? Yep, the genera populace’s distrust of people breeds such ignorance. In all fairness, the state employees are not dumb they just have to make sure that they follow the rules and generally know that experience is worth much more than the paper.

    • by Nicolas MONNET ( 4727 ) <<nicoaltiva> <at> <gmail.com>> on Saturday July 09, 2011 @08:33AM (#36703974) Journal

      It fails just as often in the private sector, the difference being that there, the client usually goes bankrupt before you hear about it.

      • by rtaylor ( 70602 )

        Indeed. Worked one of SBCs failed one-bill attempts. I have no idea what the total loss was but they lost $2B buying and later selling consulting firms who were pretty much dedicated to doing that piece of work.

      • by JamesP ( 688957 )

        It happens with other corporate crap, like ClearCase.

        If ClearCrap wasn't crap google would use it, simple as that.

    • Re: (Score:2, Informative)

      Because it's not their money, and they're not spending it upon themselves.

      Milton Friedman identified 4 types of spending:

      • Spending your money on yourself. You'll get what you perceive is the best value.
      • Spending your money on someone else (like a present). You'll be quite careful how much you spend, but perhaps less careful about what it goes on
      • Spending other people's money on yourself (you're given a budget to buy a PC). You'll buy the best thing you can, but not care too much about value
      • Spending other peop
      • by cyber-vandal ( 148830 ) on Saturday July 09, 2011 @09:02AM (#36704098) Homepage

        It doesn't happen in the competitive private sector.

        Yes it does. You just don't get to hear about it either because it's confidential or because private sector waste isn't a good story.

        People do a project because it makes/saves money, and then make it work.

        I have worked on many projects in the private sector and heard about plenty more where the IT director has believed what a salesman told them and ended up with an absolute disaster. What you say might be true for SMBs but big organisations are not too different to the public sector.

        • Amen. "COMPANY wastes money on software that doesn't work!" is a terrible story, to which people respond "who cares". "GOVERNMENT wastes YOUR MONEY on software that doesn't work" is much better story.
      • Ever heard of a budget? You know, the thing that all government agencies have. A bureaucrat most definitely cares about how much is spent, because he can't spend more.
        Government agencies do IT projects because it saves the people their time. So that the average government employee can play some games or read news. In the enlightened world, it's not the IT department that orders a system to be upgraded or created, it's the actual department that needs it. IT departments is usually the one that oversees the
      • "Spending other people's money on someone else (most government spending)."

        Well, just exactly like corporations. You don't think a general manager or a CEO is expending *his* money, do you? He is expending *your* money via your retirement funds that go to the stock market.

        "Because it's not their money, and they're not spending it upon themselves."

        Yes, quite exactly like corporations. No wonder their success rate for big projects is more or less that of the government.

        "I've done work on government project

    • I've worked for both the UK government and the private sector and the failure of large IT projects has one thing in common. Shite external contractors who promise the earth without knowing the first thing about what's actually required. It would be far better to have people who know the area doing the work, but for some reason senior managers all seem to believe their staff are less competent than any of the external companies who all have a well-documented record of uselessness. Private Eye [private-eye.co.uk] should be re

    • by Plugh ( 27537 )
      This is not a fixable problem. Governments are simply not properly incentivized to be able to cope efficiently with large, complex projects. This is part of David Friedman's Machinery of Freedom [wikipedia.org], essentially an argument for stateless anarco-capitalism. The full text of the book is available as a link off the wikipedia article. Worth a read.
      • by darjen ( 879890 )

        Right on, great book. These people essentially have unlimited funds, thanks to the taxpayers. Why bother getting it right when you can just take more and more money anyway?

    • by lucm ( 889690 )

      Huge projects usually fail because they are deadline-oriented. From there everything goes down the drain because every bump on the road will cause the project managers to either :

      1) compromise on the quality of the implementation, which leads to resistance from the people in charge of maintenance because they feel that problems are offloaded to their department. This actually initiates a downward spiral in quality and collaboration areas.

      2) compromise on the number of features that are delivered, which lead

    • by Bert64 ( 520050 )

      Because the system is grossly corrupt...
      There are only a very small number of very large and highly bureaucratic consultancies who ever get picked to manage these projects, and they tend to have very little in the way of technical skills and a corporate culture that scares such people away.
      They massively over charge, deliver extremely poor quality work safe in the knowledge that there are very few competitors all of which are equally incompetent so there's no danger of losing out.

    • Because this math "a $140 billion annual budget and serve nearly 80,000 users" makes sense to the government.

    • "What is it about government IT projects that makes them go so disastrously wrong?"

      Who said it's only the government?

      Want to know one of the most (in)famous SAP fiasco back in the day? The one from the company that wanted to put itself as *the* reference consultancy for big SAP projects on its own implementation. The verily non-government HP.

  • by CuteSteveJobs ( 1343851 ) on Saturday July 09, 2011 @08:13AM (#36703890)
    In Australia a State Government used a ridiculously expensive "off the shelf" SAP payroll solution that turned into a complete disaster. A year later and staff still aren't being paid properly. Lots of finger pointing between IBM, SAP and Corptech who is the State Government's IT corporation. They paid $40M for software that didn't work, and still doesn't work.

    Take that number in. $40M. Ridiculously overpriced even if it did work, but this doesn't even do that. Payroll isn't rocket science. A few competent programmers locked away for 6 months could do better. Far too much money is thrown at so-called 'enterprise software'.
    http://www.itnews.com.au/News/218348,ibm-under-fire-for-qld-health-bungle.aspx [itnews.com.au]
    http://www.arnnet.com.au/article/351650/ibm_says_queensland_health_sap_failure_its_fault/ [arnnet.com.au]
    http://www.zdnet.com.au/qld-health-sap-woes-lead-to-cash-advances-339302381.htm [zdnet.com.au]
    http://www.goldcoast.com.au/article/2010/05/07/215335_gold-coast-news.html [goldcoast.com.au]
    http://www.theaustralian.com.au/australian-it/qld-health-pays-hefty-price-for-sick-payroll-system/story-e6frgakx-1225813063057 [theaustralian.com.au]
    http://www.computerworld.com.au/article/351608/updated_qld_govt_blames_ibm_health_payroll_bungle/ [computerworld.com.au]
    • by JamesP ( 688957 )

      What the government should do is sue all the contractors. Return the software and ask for damages. Lawyers are good at coming with bullshit numbers.

      Sue them for 100x the value they got from the gov.

  • Probably... (Score:2, Informative)

    by Anonymous Coward

    They probably hired a big, fat consulting company like Accenture to implement SAP for them, who's in it to get even fatter by putting as many unqualified warm bodies on a contract as possible, rather than hiring a someone who will actually run it like a project and get out... someone who is actually concerned about the customer's best interests. One would hope that the Army would know better.

  • 1. It's written in fucking COBOL

    2. It's the vilest user interface I've ever seen. I have no idea how anyone could come up with something that bad.

    3. C. O. B. O. L.

    • C and ABAP (Score:3, Informative)

      The SAP R/3 kernel is written in C. The application layer is written in ABAP and can be extended in ABAP or Java. So, the the claim with COBOL is BS.
      • ABAP is sufficiently similar to COBOL that I think it'd be fair to call it a relative in the same language family.

        And if you think the SAP user interface is bad, may I introduce you to BAAN or Daly & Wolcott, both of which make SAP look like god's own gift to UIs?

      • Plus 1 to the parent - The back end of SAP is in fact written in it's own proprietary language: ABAP, although when you look at the code it has more than a passing resemblance to COBOL. I've called it "mutant COBOL" for years now. It grew out of a reporting script in the early years of SAP and even today every program starts with a "REPORT" keyword. Whilst SAP can be extended in JAVA and they have a massive J2EE front end for a lot of their web based applications they are moving away from Java (something t
    • Gasp it's written in something that has a proven track record of working and being scalable. For fuck's sake rewrite it in Ruby on Rails immediately!

    • My experience with SAP is that some of my classes tried to introduce us to it from a user/manager perspective, so I don't know about the technical backend, but I agree about the epically shitty UI.

  • by Anonymous Coward

    My company recently switched to SAP... it more than doubled the time it takes us to do anything. that software is garbage, yet people keep buying into it. they have great salespeople.

    Now the US army is switching to it? The military will shut down. We joke that the Germans (it is german software) are getting the world back for beating them in WWII.

    You can't understand how bad this software is until you actually see it.

    • MS stuff is like swimming in a pool of golden unicorn tears compared to most "enterprise software". The reason is quite simple: a lot of small companies use MS stuff, and if it was as hideous as most "enterprise" software, people wouldn't buy it or upgrade.

      In enterprises, the purchasing decisions are made by people who don't use it day-in-day-out. They look at things like the reporting module, see that's great and buy it. I worked in an organisation that dumped a working in-house change control system for a

  • by Anonymous Coward

    "The Army's $2.4 billion SAP project is delayed, over budget, and, once implemented may not even meet its original objectives"

    Surely "The Army's $2.4 billion SAP project is a SAP project" would have been sufficient, guys. ;)

  • by Zedrick ( 764028 ) on Saturday July 09, 2011 @09:04AM (#36704108)
    Haha, SAP.... :-/

    (mod me +5 insightful, I used SAP for years and promise that I deserve it based on the short but very insightful comment/review above)
  • Has there ever been an implementation of SAP that didn't go massively budget and fail to meet its initial goals?

    • My company runs SAP as its ERP system, and the project was only a little late -- but on budget and met its initial goals. We were migrating from Daly & Wolcott on an AS/400. Then again, we only have about 260 employees, and we did a fair amount of the work using our own people. We didn't just foist the whole thing off on consultants, as is most often the way.

      As someone who writes integration code with ERP systems, I can say that for all the problems SAP has, it's not nearly as terrible as others. I've w

      • SAP has this brilliant option for medium sized companies: If you adjust your business process to what SAP deems appropriate then SAP implementation in your business will succeed.
        And AMEN to comparing SAP to other ERP systems. SAP is somewhat good...
    • by sapped ( 208174 )
      I have been implementing SAP for 13 years (look at my nickname) now and the majority of our implementations went live at the right time and within the original budget. Of course occasionally you get a client that hires you and then proceeds to do the complete opposite of everything you tell them to do and eventually it turns into a disaster. That said, it's not unique to SAP, I have seen this problem when I was developing other kinds of software as well.
  • The Army's $2.4 billion SAP project is delayed, over budget, and, once implemented may not even meet its original objectives, according to a recent auditors' report.

    You could have just said, "The Army is engaged in deploying SAP."

    The rest can be inferred by anyone familiar with an SAP roll-out.

  • SAP implementation is a mess even in the civilian world - and then throw military procurement bureaucratic issues into the mix?

By working faithfully eight hours a day, you may eventually get to be boss and work twelve. -- Robert Frost

Working...