A old friend of mine frequently uses the phrase "You can't polish a turd". Until this week I believed this to be true until today.
We're four years and $140m into a BPR project that has a major SAP implementation at its heart. The intesting thing is that ten days after Phase 1 go live, and 1,500 related service desk calls later, the message I'm getting in the crucial run up to the end of financial year is that large parts of Finance simply can no longer do their day to day jobs.
Funny that because the SAP Implementation Program Manager's status email today doesn't really correlate with what I'm hearing on the ground.
Oh well. I suppose someone's just found that special way of polishing.
Showing posts with label Packaged Apps. Show all posts
Showing posts with label Packaged Apps. Show all posts
Sunday, March 14, 2010
Thursday, February 11, 2010
Suspect Packages
In the 70's and 80's companies used to write bespoke software for all their needs. Everything from payroll to financials to core business systems would be written inhouse in COBOL, RPG, PL/1, Pascal and the like. Then in the 80's and 90's the concept of packaged applications became popular. The rationale was that it was better to purchase and implement off-the-shelf packages rather than develop from scratch. This made perfect sense and much of my early IT work was involved in package implementation. Ideally a package could be implemented in months rather than written in years.
Software selection became vital as the business would often need to assess how flexible that package was and how easily it would fit into the existing processes. Working on the Technical Pre-Sales side it was always important to try to get a product fit of 90% or better. Inevitably though there was never a 100% product fit and in these situations there were two potential solutions:
1) For the business to adjust its way of working (sometimes called Business Process Reengineering)
2) For the package to be changed or modified (i.e. mods)
In the vast majority of cases the latter option was chosen as the business was reluctant to take on change. In one scenario I worked on a customer site where 70% of the programs had been modded making you wonder why they had ever selected the package.
The one exception to this model has always been SAP. They have always insisted that BPR is a fundamental principle of their implementations and as far as I know SAP implementations are never quick. Here at the Department of Hopes and Dreams we're currently 3 years into a SAP implementation and the frustration it is causing the business is unprecedented. Makes me wonder whether the advantages of packaged apps are still there.
Software selection became vital as the business would often need to assess how flexible that package was and how easily it would fit into the existing processes. Working on the Technical Pre-Sales side it was always important to try to get a product fit of 90% or better. Inevitably though there was never a 100% product fit and in these situations there were two potential solutions:
1) For the business to adjust its way of working (sometimes called Business Process Reengineering)
2) For the package to be changed or modified (i.e. mods)
In the vast majority of cases the latter option was chosen as the business was reluctant to take on change. In one scenario I worked on a customer site where 70% of the programs had been modded making you wonder why they had ever selected the package.
The one exception to this model has always been SAP. They have always insisted that BPR is a fundamental principle of their implementations and as far as I know SAP implementations are never quick. Here at the Department of Hopes and Dreams we're currently 3 years into a SAP implementation and the frustration it is causing the business is unprecedented. Makes me wonder whether the advantages of packaged apps are still there.
Subscribe to:
Posts (Atom)