The purpose of this blog is to share some of the key points discussed at the upgrade symposium conducted by SAP on Feb 6, 07 in New York City. From the General Session
Over 50 % of the SAP customer base is running 46C version.
About 80% of the SAP customer base is running either 46C or 470 versions.
ECC 6.0 is going to be the standard version through 2010, potentially through 2012.
Even though the terms ECC and mySAP ERP are being used interchangeably, there is a difference between the two. ECC is a successor of the 470 version and is the core supporting mySAP ERP. MySAP ERP, on the other hand, includes additional components like e-recruiting and learning solutions that are integrated with the core.
ECC 5.0 is powered by NW 2004 and ECC 6.0 is powered by NW 2004s, where ‘s’ stands for the ‘suite edition’.
ECC 6.0 comes with the switch framework – essentially it is a set of code (extension sets) activated by switches at the kernel level. All the industry solutions are delivered inactive with the standard system. The customer could choose to activate one of those industry solutions.
Five enhancement packages are planed to be released for ECC 6.0. The first one was delivered in Dec 2006. Muse is expected to be released in Q3 2007.
It is not mandatory to run all the components of NW on day one after upgrade. Based on the requirements, customers should consider implementing ABAP stack first and then Java stack could be added to the same server or on a different server later on.
Unicode conversion is not mandatory in order to upgrade. It could be a part of the upgrade project or executed independently after the upgrade, if there is a need identified for the same. It would take longer if you do the Unicode conversion and upgrade at the same time. Of course, the size of the database would make a difference.
Consider archiving before going for Unicode conversion.
SAP recommends the use of various tools to accelerate and help with the upgrade implementation. Upgrade roadmap is one such tool that details SAP’s methodology to upgrade and helps with the planning and execution of the project. The roadmap has about 350 accelerators with links to the service marketplace (easy to find information). Solution Manager is a tool based on ASAP methodology and there should be a working version of the tool to be able to generate the upgrade key. Modification Assistant is another tool that should be used consistently by the developers to make modifications to the core system.
Automated testing is highly recommended by SAP. Though it might take a little longer to implement it the first time, but applying the support packages, enhancement packages, upgrade subsequently would become considerably easier.
Typically, SAP has seen that the CPU usage increases by 20 % and the database size increases by 1% after the upgrade.
Take away from the session
Keep it simple – Do ABAP first and roll out Java stack later (keep in mind that for ESOA, java is needed though)
Additional functionality will be made available in enhancement packages over the next few years, thus eliminating the need for another release/upgrade.
Automated testing is the way to go.
Shift from Basis to NW is a quantum leap – expect more training and expense in that area.
Experiences from Veeco Instruments, Inc (Went live with ECC 6.0 in October 2006)
The main reasons for Veeco to upgrade included avoiding maintenance costs, adopting new functionality (the new GL functionality looked interesting to them) and other features like adobe, portals, single sign, etc.
The goals of upgrade included a successful upgrade implementation, minimal downtime and minimal disruption of the functionality.
The upgrade was a pure technical one. The next steps for them are to look at Unicode conversion and adoption of the new functionality.
Among other things, proper project planning landscape planning, mass communications, backup planning, disaster recovery, testing, the best of the resources, close involvement of the various business units were quoted as the key factors for the success.
From the Unicode session
A Unicode project involves exporting the data and importing it to the new Unicode database. R/3 Load is a toll part of the kernel that unloads the data from the database and converts to the Unicode. The input for the tool includes providing information like from what codepage you want to convert.
Codepage scanner transaction – SPUMG
ABAP enabling of customer developments is another step in the project. Once Unicode enabled, the syntax check would be stricter and third party add on code needs to be adjusted as well.
Interfaces will be another area to look at during Unicode conversion. If ASCII data is being passed between systems, it will work in the Unicode version. If not, interfaces will need to be tested to make sure they work.
The typical timeframe for a Unicode conversion project would be 3-4 months, if the database is around 500 gigs and less (up to a TB) and you are converting from a single codepage. Also, the time taken will depend on the language analysis and interfaces that would need to be changed. The outage from the export/import of the data is typically 10-12 hrs.
If you are upgrading from 46C, you would be first upgrading to ECC 6.0 non-Unicode and then converting the database from non-Unicode to Unicode.
Take away from the session
Depending on the various factors, a Unicode conversion could be a fairly complicated project.
Consider data archiving before undertaking Unicode conversion.
From the Enterprise Services Oriented Architecture Session (ESOA)
Due to the fact that the business requirements change very quickly in today’s environment, it is very important to ensure the faster execution of the processes and that IT adapts to these changes quickly. SOA enables this very thing.
SOA allows to convert the functionality available in the backend into a service to enable reusability.
A web service, in simple terms, is application functionality available over the internet. Extending the concept, if a transaction can be converted into a web service, it is SOA enabled. To SOA, if you add business context, enterprise services (like security, authorization, robustness, etc) and put the service where it makes sense, that would be ESOA.
Take away from the session
In order to adopt ESOA, it is imperative for an organization to first solidify the foundation (MDM, consolidate application infrastructure, assess skills, etc) modernize the core, optimize the business use, and drive strategic differentiation.
