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

Comments

Par for the course

[realmolo]

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.

Re:Par for the course

[alekd]

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.

Re:Par for the course

[realmolo]

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.

Re:Par for the course

[ari{Dal}]

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.

Re:Par for the course

[_Sharp'r_]

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.

Too much modularity!

[Anonymous Coward]

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.

Not just in education

[thatskinnyguy]

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.