Slashdot Mirror


Teachers Give ERP Implementations Failing Grades

theodp writes "Nine months after the Los Angeles Unified School District launched SAP HR and Payroll as part of a larger $132M ERP rollout, LAUSD employees are still being overpaid, underpaid or going unpaid. In June, about 30,000 paychecks were issued with errors, falling somewhat short of the Mission Statement 'to effectively deliver services to meet the payroll needs of all District employees serving our students.' Meanwhile, a $17M PeopleSoft-based payroll implementation has been making life miserable for Chicago Public Schools teachers and staff since last April, including June retirees who were stiffed for more than $35M. It's been a bad computer year for CPS staff, who also had to contend with a new $60M system that wasn't up to the task of taking attendance."

19 of 169 comments (clear)

  1. Par for the course by realmolo · · Score: 4, Insightful

    In my experience, this kind of thing is typical.

    It's almost a rule that the more expensive the software, the more likely it is to really and truly SUCK.

    It's also a rule that the bigger the company/organization/school district/whatever, the less likely it is that "technology" purchasing decisions are made by someone who actually HAS A CLUE about technology. The reason being, of course, that technology is too expensive to let the "tech" people get involved with the purchasing process.

    Like I said, this is all par-for-the-course in the American corporate world. And school districts/government organizations are even WORSE.

    1. Re:Par for the course by grasshoppa · · Score: 2, Insightful

      You nailed it. I've only been involved with government work for about a year now, but from what I've seen this is par for the course.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    2. Re:Par for the course by alekd · · Score: 5, Insightful

      Neither SAP nor Peoplesoft suck. They might be expensive, complex, old-fashioned and suffer from having been around and tinkered with for a long time (especially true for SAP), but they do work and with them it is actually possible to implement a system with the required functionality that works in a reasonable amount of time. This is not something you could do with a custom-built system or any of the cheap COTS systems. The problem is typically not the technology, it is the convoluted and almost impossible to understand business rules in the payroll area. This is especially true in the public sector and in other places with heavy union involvement. Over time you get more and more complex rules for how to calculate pay. The end result is that nobody understands their pay slips anymore and it is nigh impossible to implement and test a system that handles all the exceptional cases. Still, they try and fail instead of simplifying the rules and use the money saved in consultant fees in a way that would actually benefit their employees.

    3. Re:Par for the course by realmolo · · Score: 3, Insightful

      I realize that SAP is complex, and that payroll is complex.

      IT DOESN'T MATTER. The software should work. The customizations needed should be relatively EASY to implement. I mean, it's not like they're trying to model global weather systems or something. SAP is really nothing more than a big fat database/spreadsheet. They should be able to make it work. There is no excuse.

    4. Re:Par for the course by ari{Dal} · · Score: 4, Insightful

      The price has nothing to do with it. Here's why software implementations fail:

      - failure to scope the project correctly.
      - scope creep, as everyone rushes to get their own stamp on the project.
      - on the other side, scope reduction, once some pinhead in accounting realises how much the scope creep is costing.
      - implementing for IT instead of the end user.
      - allowing either IT or business sole authority in software purchase decisions. Either way it's a guaranteed disaster.
      - instead of improving current processes, projects attempt to replace/revamp said processes completely, with little to no impact from the people who actually use them.
      - lack of training. Nine times out of ten when a project runs over budget, the first area cut is the end user training.
      - cheaping out on the implementation. I've watched companies spend millions on software licenses, then shortchange on the implementation.
      - rushed implementation. Instead of planning and implementing on a schedule, the project managers fix a timeline and say "get it done in this timeframe", completely ignoring how long it SHOULD take.

      I could add more, but this is just part of it.

      --
      Moral indignation is jealousy with a halo - H. G. Wells
    5. Re:Par for the course by Dionysus · · Score: 1, Insightful

      Well, if it's so easy, it's a great opportunity to create that simple software and take all the business away from SAP and Peoplesoft.
      Of course, talk is cheap

      --
      Je ne parle pas francais.
    6. Re:Par for the course by _Sharp'r_ · · Score: 4, Insightful

      Typical government/large corporate software project steps:
      1. Have a manager in a government bureacracy or at a director-level that the vendor takes out for "business" golf make the decision.
      2. Ensure that manager has no repercussions for his decision and probably isn't even in the same position when the project is supposed to go live.
      3. Have the vendor, with no knowledge of the existing system, come up with a timeline to replace it with their stuff, but "customized".
      4. Pay vendor millions in licensing fees. Golf has a very good ROI for big vendors.
      5. Pay vendor millions more to supply a few brand new employees who took the vendor's "class" on his product to "customize" it for you, thus making those employees valuable enough to get something of a real job working for someone else later.
      6. When the first few milestones are missed, have the vendor add a couple of people to the project that know even less than the original consultants.
      7. When things start go even slower, begin to blame the "extra" work that wasn't ever planned for to start with, but is critical to the project.
      8. To make up time, cut out any originally required user training.
      9. To make up more time, cut out all documentation efforts.
      10. To make up more time, cut out all quality assurance efforts and related paperwork.
      11. To save time, skip development and testing environments and deploy everything straight to production servers.
      12. Switch over to the new system, even though it's not done, hasn't been tested, and no one knows how to use it.
      13. Sign a long-term consulting contract with the vendor to pay them for keeping the original consultants on doing "maintenance" for the forseeable future, hoping something will eventually work.
      14. Ignore your own staff's original predictions and recommendations and complain about how no one could have predicted that this project could possibbly fail, since the vendor is the "industry leader".
      15. ????
      16. If you're the vendor, "Profit!!!!" . If you're the original manager, put "Successfully led a $50,000,000 software project" on your resume.

      --
      The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
    7. Re:Par for the course by Seumas · · Score: 2, Insightful

      The answer is to spend more money.

      Teachers should be familiar with that concept. Remember, when someone isn't producing results, it's not their fault -- it's that you're not throwing enough cash at the problem!

  2. Par for course all over in education by falcon5768 · · Score: 2, Insightful
    As a IT Technician one of the things that annoys me to no end is how terrible our payroll setup is. We run software designed for 98 not because it is good (its terrible) but because our business admin refuses to upgrade and had threatened to quit if we did.

    Considering we pay her half what a BA in the business world would make because she works in education.. her quitting is not a option for my district.

    --

    "Slashdot, where telling the truth is overrated but lying is insightful."

  3. Too much modularity! by Anonymous Coward · · Score: 4, Insightful

    One of the main problems facing these ERP systems is that they try to be far too generic. Site-specific functionality is jammed into the overall framework in the form of modules. Unfortunately, business logic is often very complex, and so it doesn't always fit well into these modules. This can lead directly to hackish attempts to circumvent the limitations imposed by the ERP modules system, which often leads directly to faulty software.

    Another problem affecting lower-end ERP solutions is the use of data abstraction layers like Hibernate. These layers separate the application developers from the databases that are actually storing the data being manipulated by the ERP system. Since the developers tend to now avoid writing SQL statements, they lose sight of the real relationships between the data stored within the database tables. Losing sight of these relationships means that the developers often take obtuse, roundabout ways to getting to data through the data abstraction layer, when the same data could be obtained in a few lines of SQL.

    1. Re:Too much modularity! by nuzak · · Score: 2, Insightful

      Having seen the typical quality of PL/SQL procedures written by database code-grinders on the cheap, replete with twisted logic and redundant queries and storage of huge resultsets in variables, I would MUCH rather trust Hibernate's caching and consistency algorithms. These people "understand the schema" about as well as they understand fluid dynamics, neurosurgery, or basic English writing and composition.

      --
      Done with slashdot, done with nerds, getting a life.
    2. Re:Too much modularity! by Allador · · Score: 2, Insightful

      Yes, but that's defeating the purpose of it. It is claimed that it "hides SQL" from OOP programmers. The parent's assertion is that hiding from the SQL prevents an understanding of the data and schemas, meaning the app developers are programming in the dark, using trial and error and wasteful client-side loops. Not true. The purpose of an ORM is not to eliminate all SQL from the app. It's to eliminate tedious, repetitive, CRUD sql that doesnt really add value.

      They're an 80% solution. They hugely simplify 80% of your db access, make it more consistent. Lets the developer work higher on the abstraction stack, and spend more time solving business problems, not plumbing problems.

      It's the same reason why every developer/shop worth their salt always end up with an in-house DAL to automate so much of this anyway.

      But ORMs are not intended to solve every problem, and this is well understood. For example, large complex lists that need to be pulled with a many-table join query. These sorts of things are often done using custom sql or at least using the built-in query language.

      The problems you describe are there because too many developers nowadays are too overspecialized, and dont know enough about the underlying database systems and theory. We're a long way from the point as an industry where this is practical. For large complex apps, the data is the value, and the data will often outlast the application. Therefore its good care and support is of the utmost concern.

      Too many developers I've run into lately just think of databases as glorified text files, and it hurts their ability to produce.
  4. Not just in education by thatskinnyguy · · Score: 3, Insightful

    It's common to think that ERP or some other big software is going to be the silver bullet for all of your company's problems. In fact, that is just throwing money at the issue.

    ERP implementations are meant to mirror existing business processes. If your business processes are ass to begin with, and there is no change before an ERP roll-out, your business will still experience the same issues.

    All this "blame the ERP vendor" stuff is crap. I blame the people who are running the system and poorly implemented it.

    --
    The game.
  5. It's even worse than that. by khasim · · Score: 2, Insightful

    ERP implementations are meant to mirror existing business processes. If your business processes are ass to begin with, and there is no change before an ERP roll-out, your business will still experience the same issues.

    But it is VERY difficult to "mirror existing business processes" because of TWO things:

    #1. Duplicating a human decision process is difficult in software - the human may have 50+ years of experience that s/he cannot articulate to the analyst. Which leads to ...

    #2. The process and business logic that is actually implemented is what the ANALYST believes should be implemented and how it should be implemented. (and then how it is written by the coder and whether it passes the test cases (and whether any test cases were written and tested)).

    It's all about the edge cases. Depending upon your market, your "edge cases" could be almost all of your business (and profits).
  6. Suckers by g-san · · Score: 2, Insightful

    This is one the biggest scam in business history. You get some company to buy into a huge software package, hire armies of consultants, schedule months of meetings, and they end up with something worse than what they had before, only poorer.

  7. Project Management & SAP Integrator by blue_teeth · · Score: 2, Insightful

    I am a SAP Integrator (not on the functional side, but on technology - SAP Basis).

    1. There is nothing wrong with the software or architecture design.
    2. SAP is highly customizable to customer's requirements.
    3. Projects are normally rushed thru without proper planning.
    4. Lack of quality SAP specialists. These days, SAP consultants are commodotized.
    It is difficult to identify a good consultant. It appears consultants without relevant
    industry experience were deployed (SAP+Government+Education+HR background)
    5. Testing, testing and testing !! I think corners were cut here.

    Go identify the culprits.

  8. Complexity Tax bites man by Tablizer · · Score: 2, Insightful

    This brings up an important point: organizations don't bother to try to simplify their business rules. Complex business rules make life harder even IF the computer does work because people still have to verify the results and answer questions from users (paycheck receivers). Beurocrats build up layers of messy rules like a desk or fridge that nobody ever cleans. Until real AI is invented, it may be unrealistic for a computer to magically fix it all. If such a system is too complex for regular payroll clerks to understand and navigate, then it is probably beyond automation also.

  9. ERP? by Anonymous Coward · · Score: 1, Insightful

    And what does ERP mean? I checked wikipedia, but none of it's possible meanings of ERP seemed appropriate. I'm just going to pick one that sounds intestering, though.

    I don't know why these schools can't pick a decent Erotic Roleplaying system. There are so many good ones to choose from, and it's very important that we get these students involved with one of them, so they can practice and know what to expect in the real world.

  10. Re:LAUSD problems by X · · Score: 2, Insightful

    > As for $300 hammers, someone connected to the California school system, or married to someone who is, should SHUT THE FUCK UP when is comes to criticizing government waste.

    Dude, that is so out of line it isn't even funny. First of all, "someone connected to the California school system" is a pretty broad brush. I'm going to presume you weren't including parents and students in with that, and probably not volunteers. Still you're talking about literally hundreds, if not thousands, of school districts (LAUSD just happens to be by far the largest), each of which is administered and run fairly independently of the others. You're throwing in the kindergardens in with the university system, etc. Secondly, most of the people who are part of the system are actually victims of the waste rather than causes of it. I know plenty of teachers who spend their own money (how beautifully inefficient is that eh? spending after tax money on something that should be an expense, but not being able to expense it) buying supplies for their classroom in order to compensate for inadequate supplies (all the while staring at a $2000 computer in their classroom that collects dust because a contractor hasn't show up yet to hook it up). They deal with "lockdowns" that occur once a month because someone in the neighbourhood (often one of the students) exchanges gunfire, and of course they feel horribly unsafe when that happens because most of the security money is spent on metal detectors, which provide little to no protection once a gunfight has actually broken out. They deal with students whose attendance can best be described as "erratic", often because they move from neighbourhood to neighbourhood (or even state to state or country to country) multiple times over the course of the year. On top of that they get to deal with parents who are completely uninvolved in their kids schooling, all the while they are expected to produce results. Those parents that do show up may very well not speak english and in fact may speak any of over 100 languages as their native tongue (and I'm not even talking about the ones that can't read or write, because that is a comparatively minor impediment for a teacher to overcome) and their kids may be similarly disadvantaged.

    It's fun to sit back and take pot shots from the sidelines without actually getting involved, but if you get down in the trenches and learn what is actually going on, you'll find the problem is very complex and way more fucked up than you can possibly imagine. No question there is waste, but part of the frustrating aspect of the situation is most of the people involved in the system can do little to correct it.

    The irony, is that the article really just reads like the typical article you read about ERP deployments at any business. The only thing that makes it especially tragic is that it it involves the school system. It is *normal* with ERP deployments to have the whole thing be massively over budget, massively behind schedule, have the bidding process be entirely corrupted (heck, it is hard for it not to be, as it is terribly difficult to get direct access to the innards of the systems), and for the whole thing to be strung around a consulting company's neck (typically they deserve half the blame, but far from all), and they're willing to take it because they are laughing all the way to the bank as they bill their way through the fiasco.

    If you think this whole mess wouldn't have happened without California's education system being involved, you are profoundly ill informed.

    --
    sigs are a waste of space