5 ms·

I am guessing one of the reasons is probably the software selected... oracle

by ismail 9y ago

threeseed 9y ago
Oracle Peoplesoft is used successfully at a number of organisations so blanket statements aren't helpful. But I would question whether it is better/cheaper in these cases to just write bespoke software from scratch rather than trying to modify a vendor's existing product.
dsfyu404ed 9y ago
Oracle/PeopleSoft can do payroll for a defense contractor with tens of thousands of employees across multiple nations. I think proper configuration is what's lacking in this case.
- debacle 9y ago
  Oracle costs a lot. It infects your entire stack, from hardware all the way up to personnel, and drastically inflates the cost from end to end. With no real utility advantage, either.
  - dsfyu404ed 9y ago
    That's not relevant to whether or not the software is capable of performing the task.
  - threeseed 9y ago
    Everything infects your entire stack. If I hire Java, Ruby, PHP etc people then everything from hardware up to personnel is going to be selected to optimise the delivery and execution of software. Kind of common sense that you would do this. I don't disagree that Oracle costs a lot and that they inflate margins pretty poorly but to say they have no real utility advantage is a bit ridiculous. Most of the world's enterprises are running core business systems off Oracle and if they move to the cloud it's usually to Oracle instances in the cloud not any other system.
- AndyNemmity 9y ago
  Proper configuration, and proper business needs mapped, and no moving targets, and probably a lot more, we'd have to be on the project to know.
j45 9y ago
Likely not true. Software implementations usually fail because of the implementors failing to understand and map the business needs prior to beginning in detail, vs launching with whatever and making twice as much money fixing it after the fact "as you go". I have lead a few full cycle ERP implementations, and replaced vendors along the way if they were not performing. The challenge remains is software vendors are not sufficiently motivated enough to learn the business in detail before implementing software to help run the process.
- AndyNemmity 9y ago
  It's a mix, I've lead many enterprise implementations, erp, crm, etc. It's not just the implementors, it's all of the above, from the lack of the customer even being able to communicate the business needs. It'd be lovely if you were right, because the problem is then fixable, but you can take the most motivated, best team of SMEs into a project, and be unsuccessful given the client. It's all a mess trying to get things done, and every single company is different. Going onsite that first few weeks is an exploration into in what exact ways the mess is going to manifest itself, and how we're going to fight our way through it.
  - j45 9y ago
    I agree. To clarify, I'd like to believe any client in the position to spend money on an ERP size solution (including payroll) has earned the right to do so - be they got large enough to have a problem by luck, manually inefficient processes, outgrowing existing systems, etc. There is still a responsibility in my mind on the implementors part to be experts who can assess the maturity in place at a clients operation, as well as the degree and potential depth of unknowns, as well as their bench's ability to be experts of closing the unknown. Too often, implementors are focused on landing clients, more than passing on work beyond their pay scale due to trivializing or outright ignoring things. Every single company is totally different - a desire for implementors to want to templatize as much as they can may be part of the issue. I'm being a bit harsh on implementors despite being one, I think it boils down to if you don't understand a business in detail, including it's data, before beginning, one should probably not touch it, whether its a client or the other side.
dragonwriter 9y ago
I'm certain one of the reasons is that all kinds of things were selected, before getting to the meet of the requirements. Which is typical of large government IT projects, where the order is often: choose some of the technology stack, write an contract opportunity (RFO, etc.) around the chosen technology and a vague (even if stated in terms that seem precise) concept of the requirements, select a contractor, who then pre-determines more of the tech stack based on their own offerings, business relationships, or competencies, then starts gathering real implementable requirements and building the customer-specific elements of the software (and even the last two are sometimes in the reverse order.)
- blantonl 9y ago
  ..and then start backing all that in to existing long standing customer business processes which aren't going to budge. And then you end up with the OP.

I am guessing one of the reasons is probably the software selected... oracle

by ismail 9y ago

I am guessing one of the reasons is probably the software selected... oracle

Oracle Peoplesoft is used successfully at a number of organisations so blanket statements aren't helpful. But I would question whether it is better/cheaper in these cases to just write bespoke software from scratch rather than trying to modify a vendor's existing product.

dsfyu404ed 9y ago

Oracle/PeopleSoft can do payroll for a defense contractor with tens of thousands of employees across multiple nations. I think proper configuration is what's lacking in this case.

debacle 9y ago
Oracle costs a lot. It infects your entire stack, from hardware all the way up to personnel, and drastically inflates the cost from end to end. With no real utility advantage, either.
- dsfyu404ed 9y ago
  That's not relevant to whether or not the software is capable of performing the task.
- threeseed 9y ago
  Everything infects your entire stack. If I hire Java, Ruby, PHP etc people then everything from hardware up to personnel is going to be selected to optimise the delivery and execution of software. Kind of common sense that you would do this. I don't disagree that Oracle costs a lot and that they inflate margins pretty poorly but to say they have no real utility advantage is a bit ridiculous. Most of the world's enterprises are running core business systems off Oracle and if they move to the cloud it's usually to Oracle instances in the cloud not any other system.
AndyNemmity 9y ago
Proper configuration, and proper business needs mapped, and no moving targets, and probably a lot more, we'd have to be on the project to know.

j45 9y ago

Likely not true. Software implementations usually fail because of the implementors failing to understand and map the business needs prior to beginning in detail, vs launching with whatever and making twice as much money fixing it after the fact "as you go". I have lead a few full cycle ERP implementations, and replaced vendors along the way if they were not performing. The challenge remains is software vendors are not sufficiently motivated enough to learn the business in detail before implementing software to help run the process.

AndyNemmity 9y ago
It's a mix, I've lead many enterprise implementations, erp, crm, etc. It's not just the implementors, it's all of the above, from the lack of the customer even being able to communicate the business needs. It'd be lovely if you were right, because the problem is then fixable, but you can take the most motivated, best team of SMEs into a project, and be unsuccessful given the client. It's all a mess trying to get things done, and every single company is different. Going onsite that first few weeks is an exploration into in what exact ways the mess is going to manifest itself, and how we're going to fight our way through it.
- j45 9y ago
  I agree. To clarify, I'd like to believe any client in the position to spend money on an ERP size solution (including payroll) has earned the right to do so - be they got large enough to have a problem by luck, manually inefficient processes, outgrowing existing systems, etc. There is still a responsibility in my mind on the implementors part to be experts who can assess the maturity in place at a clients operation, as well as the degree and potential depth of unknowns, as well as their bench's ability to be experts of closing the unknown. Too often, implementors are focused on landing clients, more than passing on work beyond their pay scale due to trivializing or outright ignoring things. Every single company is totally different - a desire for implementors to want to templatize as much as they can may be part of the issue. I'm being a bit harsh on implementors despite being one, I think it boils down to if you don't understand a business in detail, including it's data, before beginning, one should probably not touch it, whether its a client or the other side.

dragonwriter 9y ago

I'm certain one of the reasons is that all kinds of things were selected, before getting to the meet of the requirements. Which is typical of large government IT projects, where the order is often: choose some of the technology stack, write an contract opportunity (RFO, etc.) around the chosen technology and a vague (even if stated in terms that seem precise) concept of the requirements, select a contractor, who then pre-determines more of the tech stack based on their own offerings, business relationships, or competencies, then starts gathering real implementable requirements and building the customer-specific elements of the software (and even the last two are sometimes in the reverse order.)

blantonl 9y ago
..and then start backing all that in to existing long standing customer business processes which aren't going to budge. And then you end up with the OP.