Project preparation

The project preparation phase, depicted below, focuses at two main activities, i.e. to make a setup for the TSO and to define a solution vision. These activities allow an organization to put in on the right track towards implementation.

Design and initially staff the SAP TSO

The first major step of the project preparation phase is to design and initially staff an SAP technical support organization (TSO), which is the organization that is charged with addressing, designing, implementing and supporting the SAP solution. This can be programmers, project management, database administrators, test teams, etc. At this point, the focus should be at staffing the key positions of the TSO, e.g. the high-level project team and SAP professionals like the senior database administrator and the solution architect. Next to that, this is the time to make decisions about choosing for internal staff members or external consultants.

The image at the right shows a typical TSO chart.

Craft solution vision

The second project preparation job is to define a so-called solution vision, i.e. a vision of the future-state of the SAP solution, where it is important to address both business and financial requirements (budgets). The main focus within the vision should be on the company’s core business and how the SAP solution will better enable that core business to be successful. Next to that, the shortcomings of the current systems should be described and short but clear requirements should be provided regarding availability (uptime), security, manageability and scalability of the SAP system.

Sizing and blueprinting

The next phase is often referred to as the sizing and blueprinting phase and forms the main chunk of the implementation process. The phase is illustrated below.

Perform cost of ownership analysis

This phase starts with performing a total cost of ownership analysis (TCO analysis) to determine how to get the best business solution at the lowest costs. This means to compare SAP solution stack options and alternatives and then determine what costs each part of the stack will bring and when these costs will be incurred. Parts of the stack are for example the hardware, operating system and database, which form the acquisition costs. Next to that, there should be taken a look at recurring costs like maintenance costs and downtime costs. Instead of performing a complete TCO analysis for various solution stack alternatives that would like to compare, it can be wise just to do a so-called delta analysis, where only the differences between solutions (stacks) are identified and analyzed. The image at the right depicts the essence of a delta analysis.