Posted on December 17, 2008 by Paul Ritchie
Regular Crossderry readers know I’m partial to ERP upgrade tips and advice (here, here, here, and here). This list by Beth Stackpole stood out as one of the more practical and insightful “Why to upgrade” lists around. In particular, point four is often overlooked.
- Upgrade an ERP system that’s more than five years old.
- Upgrade when ERP system integration is difficult.
- Upgrade when an ERP system is missing the “modern” features and functions required to efficiently run the business.
- Upgrade when employees, partners and consultants aren’t using the system — or aren’t available to fix it.
- Upgrade when it’s obviously time, whether the hard upgrade ROI is clear or not.
As they say… read the whole post.
Filed under: Business Case, Complexity, Implementation Costs, IT Strategy | Tagged: Beth Stackpole, SAP Upgrades, SearchManufacturing, SearchSAP, Upgrades | 2 Comments »
Posted on August 30, 2008 by Paul Ritchie
Back in the day I did quite a bit of work on planning, managing, and executing SAP upgrades. This article by Michael Doane — the “from 4.2 to ECC 6.0″ head-scratcher notwithstanding — lays out some good considerations for how and when to think about consulting vs. support services.
As I’ve pointed out in previous posts, SAP generates tons of content and tools that don’t get enough time, attention, and use. On the upgrade topic, I’d like to point folks to http://service.sap.com/upgrade (registration required if you haven’t already done so). The SAP Upgrade Roadmap page (here) is a great place to start to dig in…
Filed under: Methodology, Program Management, Project Management | Tagged: Michael Doane, SAP Upgrades, SearchSAP, Upgrades | 1 Comment »
Posted on August 26, 2008 by Paul Ritchie
I was going through a list of upgrade tip articles collected by Demir Barlas (here) in his SAP Watch blog (here). Most of them look unobjectionable, but one touches on a pet peeve. Amit Jain calls them out here (original SDN post here):
6) Cloned programs — Cloned programs are customer programs copied from standard programs… [they] are coded by copying the standard program to a Z-program, having the standard includes or standard function modules. This causes issues after the upgrade, because the standard includes or functional modules might not work with our custom code.
Clones are insidious, because developers don’t think they’re system modifications. They’re right: they’re worse than system modifications. I’ve never heard a compelling case for cloning. Directly modifying the standard program — while not exactly encouraged by SAP — is a more straightforward and honest approach:
- There’s no more pretending that a clone isn’t a modification. Taking standard code, modifying it, tacking on a “Z” to the name, then claiming it isn’t a modification seems disingenous.
- Clones hide from SAP monitoring and other system features. In an upgrade, SPAU has features that attempt to account for mods when updating the code base. It is much simpler to deal with mods in SPAU than by searching through the new SAP program.
- Clones create non-value added work. For example, all of the dependencies to/from the cloned program have to be re-established manually during an upgrade. Never mind the manual bookkeeping involved…
Filed under: IT special interests, Program Management, Project Management, Project Success Factors, SAP | Tagged: ABAP, Amit Jain, Cloned programs, Demir Barlas, Modifications, SAP Upgrades, SAP Watch, SearchSAP, SPAU | Leave a Comment »
Posted on July 11, 2008 by Paul Ritchie
Eric Samuels at the SAP Watch blog has an interview with Steve Strout, the new ASUG CEO (here). This post focuses on the recent surge in upgrades in process or completed (the SAP press release is here). A couple of key quotes:
First, it’s an extremely stable release. People are able to do a technical upgrade without much hassle. I know of people who have eliminated upwards of 70% of their custom code just by moving to this release. I also think SAP has done a tremendous job of making the migration a relatively easy one. I know that when I went from 4.6c to 6.0, it was a pretty straight forward process and we didn’t find any real surprises.
SAP has worked diligently on easing upgrade hassles and reducing downtime for years (full disclosure, I was part of the Upgrade Competence Center back in the day and I’ve led three major upgrades). We also have continually updated our ASAP for Upgrades roadmap (you’ll need to be registered in Service Marketplace to access the upgrade roadmap entry page here, online version here).
In addition…they will start taking advantage of Service Oriented Architecture and expose access to their SAP environment and create new ways of taking out steps of a business process – thus reducing their overall costs. We are starting to see people use SOA technologies to innovate and create new ways for their business to do all new things. And this innovation can’t occur at the same price point with the older technology.
Yup…Enterprise SOA is coming and our customers are putting in the business process platform to support it.
Filed under: Business Case, Implementation Costs, SAP | Tagged: Enterprise SOA, Eric Samuels, Paul Ritchie, SAP Upgrades, SearchSAP, SOA, Steve Strout, Upgrades | 3 Comments »