Teachers Give ERP Implementations Failing Grades 169
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."
Par for the course (Score:5, Insightful)
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.
Comment removed (Score:3, Insightful)
Too much modularity! (Score:4, Insightful)
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 (Score:4, 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.
All this "blame the ERP vendor" stuff is crap. I blame the people who are running the system and poorly implemented it.
Re:Par for the course (Score:3, Insightful)
Re:Par for the course (Score:5, Insightful)
It's even worse than that. (Score:3, Insightful)
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).
Re:Par for the course (Score:4, Insightful)
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 (Score:5, Insightful)
- 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.
Suckers (Score:3, Insightful)
Re:Par for the course (Score:1, Insightful)
Of course, talk is cheap
Re:Par for the course (Score:5, Insightful)
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.
Project Management & SAP Integrator (Score:2, Insightful)
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.
Complexity Tax bites man (Score:3, Insightful)
Re:Too much modularity! (Score:3, Insightful)
Re:Par for the course (Score:2, Insightful)
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!
Re:Too much modularity! (Score:3, Insightful)
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.
ERP? (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.
Re:LAUSD problems (Score:3, Insightful)
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.