If you are responsible for the success of data migration, you will want to build a detailed plan that will walk you through all of the three phases of data migration: pre-data migration preparation, the data migration itself, and post-data migration cleanup. I like my data migration plan to contain detailed steps that ensure that I don’t forget anything. Each step lists a specific named responsible person along with their area of responsibility and contact information. Unless I am responsible for executing the task myself, I prefer the named person to be a client employee (i.e. the business owner of the process) rather than a project consultant. This is where the responsibility should be, and it requires that the business process owners actually participate in the activity rather than sit on the sidelines and watch.
SAP Data Migration – Answering the Important Questions (Part 1)
It is data migration time on your SAP business project. Whether your project is implementation, acquisition, or merger, the goal is pretty much the same: the seamless inbound acquisition of master and transactional data from one or more external data sources while ensuring that this activity has minimal impact on the rest of the business. This is where we attempt to move years of neglected master and transactional data from a loosely structured, anything-goes legacy system into a very tightly integrated and highly structured SAP system. You must consider the likelihood that the concept of master data management had not been invented yet when the legacy or source system providing your data was implemented.
How much data to move? How much data to leave behind? What to automate, and what to execute manually? How to gracefully orchestrate and execute a data migration cutover from one system to another? Where and how to fit the data migration plan into the overall business implementation plan? How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!
SAP Solution Manager (SOLMAN) Template Projects
In my previous post I discussed some of the functionality available in Solution Manager (SOLMAN) to capture and build business process scenarios, processes and steps. Once you captured this information it could be readily transformed into a test plan and SOLMAN functionality used to execute, manage and monitor testing.
This is good functionality and once your business scenarios, processes and steps are in SOLMAN you can use them as a baseline for additional projects.
Consider the “global template” scenario that crops up in companies today: a core set of business processes are designed and rolled out on a global basis – the only deviations allowed are those mandated by local legal requirements (a.k.a. localization). On top of this there are the business scenarios that fall outside of the business template. You don’t want to build a standard implementation project from scratch each time for the core business processes. This is where template projects save you time and effort.
[Read more...]
SAP Upgrades, Solution Manager, Test Plans, and Testing
In this entry I’ll pull together a few threads from previous posts (testing, documentation, upgrades and offshore development) and throw in some Solution Manager (SOLMAN) functionality. These pieces can be fitted together to help accelerate a project and testing preparation via use of the SAP Test Workbench.
Nowadays SAP wants you to use SOLMAN to manage your landscape and use it as the main conduit to interact with the mother ship in Walldorf. Lots of SAP installations use SOLMAN as a way to generate developer keys and as a document repository: valid uses, but only a small fraction of the available functionality. Let’s explore some more of that SOLMAN magic.
[Read more...]
Leave SAPPHIRE NOW with an iPad!
Visit DataXstream at SapphireNow
-
What: SapphireNow
-
When: May 16-19, 2010
-
Where: The Orange County Convention Center in Orlando, Florida
The Art of Writing an SAP Functional Specification
Overview
I am currently working on an SAP implementation project that is just starting its realization phase. One of my first tasks, as a member of the technical implementation team, is to review completed functional specification documents for RICEF objects. These documents, written by functional subject matter experts, are supposed to detail business requirements that address gaps, and which need to be incorporated into the system being implemented. The purpose of the review is to make sure that the functional specification documents are complete, accurate, and contain the approval signatures required to move on to the technical design phase.
SAP Upgrades & Offshore Resources
It looks like it is official: 2010 is the year of the upgrade. A little validation is good for my self-esteem. Now that’s out of the way and I’m polishing my attaboy trophy let’s get on with it.
In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources. My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post. Now that you’ve found these customizations, what do you do next? Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.
What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming. This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.
I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through. This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly. Let me digress.
[Read more...]
The Software Component
In my last blog entitled What’s in a Namespace, I discussed the value of developing deliverable custom solutions in a reserved unique namespace. In this blog, I will discuss how a namespace is related to a software component. I will also discuss the typical product lifecycle, the software component version, and the convention which we use for establishing the software component version release increments.
DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients. We develop all of our custom add-on products in our own reserved and unique namespace /XSTREAM/. But, we also need to reserve a separate unique namespace for each add-on product that we package and deliver using the SAP Add-on Assembly Kit. So, we have a single development namespace /XSTREAM/ and a separate “packaging and delivery” namespace for each add-on product. Why is that?
SAP Upgrades & Recycling Project Artifacts
In my previous post on SAP upgrades I discussed how to get started on your project and to determine whether you are doing (ahem!) just a technical upgrade or intend to venture into deploying additional standard functionality, too. In this post I’ll talk about how you can plan, anticipate and potentially accelerate some of the execution activities to verify the upgrade is working.
SAP Solution Manager (SolMan) Services
“Included with your purchase is a Thingamajig. You may not understand it, but trust us, it is very valuable to you. In fact, you must use it!” When it comes to SAP, this thingamajig is SAP Solution Manager (SolMan). DataXstream understands how to implement and leverage Solution Manager’s rich tool set to facilitate systems transparency and collaboration during SAP implementation. Whether your SAP solution is just getting started or is mature, there are many tools and features within Solution Manager to help improve the management of your SAP solution.
Helping You Get the Most out of your SAP Arsenal with SolMan
DataXstream can help you get the most out of SolMan. We provide a variety of services to deploy and configure SolMan, and we also educate others on how to best utilize it. These services consist of:
- Analyzing customer SAP initiatives and mapping out a corresponding deployment plan for Solution Manager to streamline those initiatives.
- Sizing, installing and attaching Solution Manager into the various SAP landscapes.
- Configuring Solution Manager to support a new implementation. This includes configuring implementation functions; setup roles, authorizations, and work centers; establishing project management for blueprinting, documentation, testing and training; and finalizing promotion cutover.
- Configuring Solution Manager to streamline and document an Upgrade or Expansion initiative. This includes refining “new implementation” documentation to support any revisions, creating and rolling out configuration templates, instituting Change Management, and performing risk mitigation.
- Incorporating legacy application integration and support into Solution Manager to build a holistic view of the SAP environment.
- Deploying “Run SAP” industry best practices to manage and support the heterogeneous environment, including incident management, change requests, diagnostics and root cause analysis.
- Integrating SolMan’s Service Desk with a Third-Party Service Desk. This is done by being able to call the SAP Service Desk API’s. These API’s can be exposed as WebServices that can be called by the Third-Party Service Desk. To learn how DataXstream integrated SolMan Service Desk with CA (formerly Computer Associates) Service Desk, read Steve Park’s blog.
More Information
