ASAP Methodology

ASAP stands for Accelerated SAP. Its purpose is to help design SAP implementation in the most efficient manner possible. Its goal is to effectively optimize time, people, quality and other resources, using a proven methodology to implementation. ASAP focuses on tools and training, wrapped up in a five-phase process oriented road map for guiding implementation. The road map is composed of five well-known consecutive phases: Phase 1 Project Preparation Phase 2 Business Blueprint Phase 3 Realization Phase 4 Final Preparation Phase 5 Go-Live and support

ASAP Methodology - Phase 1 : Project Preparation

Phase 1 initiates with a retrieval of information and resources. It is an important time to assemble the necessary components for the implementation. Some important milestones that need to be accomplished for phase 1 include Obtaining senior-level management/stakeholder support identifying clear project objectives architect an efficient decision-making process creating an environment suitable for change and re-engineering building a qualified and capable project team. Senior level management support: One of the most important milestones with phase 1 of ASAP is the full agreement and cooperation of the important company decision-makers - key stake holders and others. Their backing and support is crucial for a successful implementation. Clear project objectives: Be concise in defining what your objectives and expectations are for this venture. Vague or unclear notions of what you hope to obtain with SAP will handicap the implementation process. Also make sure that your expectations are reasonable considering your company's resources. It is essential to have clearly defined ideas, goals and project plans devised before moving forward. An efficient decision making process: One obstacle that often stalls implementation is a poorly constructed decision-making process. Before embarking on this venture, individuals need to be clearly identified. Decide now who is responsible for different decisions along the way. From day one, the implementation decision makers and project leaders from each area must be aware of the onus placed on them to return good decisions quickly.

Environment suitable for change and re engineering: Your team must be willing to accept that, along with new SAP software, things are going to change, the business will change, and information technology enabling the business will change as well. By implementing SAP, you will essentially redesign your current practices to model more efficient or predefined best business practices as espoused by SAP. Resistance to this change will impede the progress of your implementation.

ASAP Methodology - Phase 2- Business Blueprint

SAP has defined a business blueprint phase to help extract pertinent information about your company that is necessary for implementation. These blueprints are in the form of questionnaires that are designed to probe for information that uncovers how your company does business. As such, they also serve to document the implementation. Each business blueprint document essentially outlines your future business processes and business requirements. The kinds of questions asked are germane to the particular business function, as seen in the following sample questions: 1) What information do you capture on a purchase order? 2) What information is required to complete a purchase order? Accelerated SAP question and answer database: The question and answer database (QADB) is a simple although aging tool designed to facilitate the creation and maintenance of your business blueprint. This database stores the questions and the answers and serves as the heart of your blue print. Customers are provided with a customer input template for each application that collects the data. The question and answer format is standard across applications to facilitate easier use by the project team. Issues database: Another tool used in the blueprinting phase is the issues database. This database stores any open concerns and pending issues that relate to the implementation. Centrally storing this information assists in gathering and then managing issues to resolution, so that important matters do not fall through the cracks. You can then track the issues in database, assign them to team members, and update the database accordingly.

ASAP Methodology - Phase- 3 - Realization:

With the completion of the business in phase 2, "functional" experts are now ready to begin configuring SAP. The Realization phase is broken in to two parts. 1) Your SAP consulting team helps you configure your baseline system, called the baseline configuration. 2) Your implementation project team fine-tunes that system to meet all your business and process requirements as part of the fine tuning configuration.

The initial configuration completed during the base line configuration is based on the information that you provided in your blueprint document. The remaining approximately 20% of your configuration that was not tackled during the baseline configuration is completed during the fine tuning configuration. Fine tuning usually deals with the exceptions that are not covered in baseline configuration. This final bit of tweaking represents the work necessary to fit your special needs. Configuration Testing: With the help of your SAP consulting team, you segregate your business processes into cycles of related business flows. The cycles serve as independent units that enable you to test specific parts of the business process. You can also work through configuring the SAP implementation guide (IMG). A tool used to assist you in configuring your SAP system in a step by step manner. Knowledge Transfer: As the configuration phase comes to a close, it becomes necessary for the Project team to be self-sufficient in their knowledge of the configuration of your SAP system. Knowledge transfer to the configuration team tasked with system maintenance (that is, maintenance of the business processes after Go-live) needs to be completed at this time.In addition, the end users tasked with actually using the system for day-to-day business purposes must be trained.

ASAP Methodology - Phase 4 - Final Preparation:

As phase 3 merges into phase 4, you should find yourselves not only in the midst of SAP training, but also in the midst of rigorous functional and stress testing. Phase 4 also concentrates on the fine tuning of your configuration before Go-live and more importantly, the migration of data from your old system or systems to SAP. Workload testing (including peak volume, daily load, and other forms of stress testing), and integration or functional testing are conducted to ensure the accuracy of your data and the stability of your SAP system. Because you should have begun testing back in phase 2, you do not have too far to go until Go-live. Now is an important time to perform preventative maintenance checks to ensure optimal performance at your SAP system.At the conclusion of phase 4, take time to plan and document a Go-live strategy. Preparation for Go-live means preparing for your end-users questions as they start actively working on the new SAP system.

ASAP Methodology - Phase 5 - Go-live and Support:

The Go-live milestone is itself is easy to achieve; a smooth and uneventful Go-live is another matter altogether. Preparation is the key, including attention to what-if scenarios related not only to the individual business processes deployed but also to the functioning of technology underpinning these business processes and preparation for ongoing support, including maintenance contracts and documented processes and procedures are essential.

We can divide the SAP projects into three categories. They are 1) SAP Implementation Projects 2) SAP Support Projects 3) SAP Migration Projects 1) SAP Implementation Projects In this type of projects, Customers are moving towards SAP software. Previously they might be using some other software. 2) SAP Support Projects Once SAP project is implemented, it should be supported by the consultants in day-today business. In Support projects, the support team helps the customer in day-to-day business. 3) SAP Migration Projects As we see, SAP is continuously upgrading the R/3 software. Customers are moving from the older versions to new versions. When the customer decides to new version, it is called SAP Migration Projects. Now-a-days many customers are migrating from older versions like 4.5 or 4.6b, 4.6c to ECC 5.0 or ECC 6.0

There are six types of projects.It includes, 1) Implementation Projects: These projects are the projects where the activities would be started from the scratch till go live. These are also called as full-life cycle implementations or end-to-end implementations. The following are the phases involved in an implementation project. They are: i) Plan ii) Blue Print iii) Build iv) Test v) Go live vi) Post implementation project

Plan is a phase in which the scope of the project is friezed. Blueprint phase is used to put the understanding of the scope of the project and the approach to map the same in SAP system on a paper. Build is the phase where the solutions are developed in SAP system as per the agreed scope in the blueprint. Test phase is used to test whether all the solutions developed in SAP system are meeting the customer requirements.

Go live is the phase where the solutions given in SAP system would be accepted by the users and their after all the processes would be processed in SAP system. Post implementation support is a phase where support is rendered to the customer in order to resolve the initial hiccups immediately after implementation.

2) Support/Maintenance Projects: These are the projects where the SAP systems which are already live would be supported in case of any change management. 3) Global Projects: It is a project which would be seen in case of multinational companies. In these kinds of projects the solutions are rolled across geographical locations in a phased manner. 4) Upgrade Projects: These are the projects where version of SAP would be upgraded from the old to latest. 5) Mergers & Acquisitions: These are the projects where the exisisting company is being merged or being acquired by another company. 6) Conversions: These are the projects where the process of a company would be converted from one platform to another platform. Ex: People soft to SAP.

Process
Sales and Distribution is SAP begins with establishing customer relationship and ends with invoicing for the delivery of goods or service provided to the customer. A standard process flow for sales transaction has the following flow: 1. 2. 3. 4. 5. Inquiry Quotation Sales Order Delivery Document Invoice

The customer order management cycle begins with pre-sales activities.

Sales Order
A standard sales order in SAP contains:

Customer & its partners details Material information Pricing conditions

Delivery dates and quantities Shipping/Transportation information Billing information Accounting Interface information Required Output Details Document Status

Inventory sourcing at Sales Order & Delivery

It is handled through:

Availability check

Shipping
SAP supports following shipping process:

Outbound delivery creation Picking Packing Post Goods Issue

Billing
SAP supports following billing process:

Creating invoices for products and services Creating credit and debit memo Cancel previously posted billing documents Automatically transferring billing documents to accounting

When a billing document is created for a sales order we

Credit the sales revenue account Debit the customer receivables account

Sandbox is a server which can be said to be a playground for trying and testing configuration and scenario. This server will have Master Data and Transaction Data.

Golden Client is a server which will only have configuration and a clean server with only relevant configuration. This server will not have Master Data and Transaction Data.

1) Sand Box Client

The name itself is self explanatory. As like sand, in this client you can play around with configuration settings and dump as many datas you can.

2) Golden Client

Here again the name is self explanatory. As like the value of Gold, through this client, you can only make configuration changes and transport to quality. You cannot do any transactions here. This is a sensitive client and access will not be given to all. Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process.

The Development Client is also the Golden Client because it has all the correct configuration settingswhich have been tested and are error free. The Golden Client is taken a reference while performing some other configuration settings.You cannot change any settings in the golden client. Sandbox server is for trial & error, Here any thing done doesnt affect the other servers, Implementers use this Server at the very initial stage of realization. Here they create a demo structure, how actual configuration will be done & it can be erased later. Sandbox word means drawing on the sand & rubbing if do not match the figure & try again to meet the correct figure. Golden server is a kind of development server, here implementers do the real configuration as per requirement & if satisfied with the configuration, they transport it to the quality server for testing & if not, the re-do the configuration to meet the requirement (remember, this is a very neat and clean client and you cannot use it for rough usage) Master data is not configured in Golden server Reply They are:-

Presentation Layer Application Layer Database Layer

Presentation Layer is the system with GUI where the enduser works and directly collect the requirment from end users to be process to on the next layer(Apps Layer & DB Layer) The Application Layer of an R/3 System is made up of the application servers and the message server. Application server is where the dispatcher distribute the work load to the different work processes(like Dailog workprocess, Background workprocess, Spool workprocess, Update Workprocess, and Enque workprocess)and makes the job done.

Types of Work Process

Although all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher. Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers. The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:

The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail. Dialog Work Process Dialog work processes deal with requests from an active user to execute dialog steps. Update Work Process Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background. Background Work Process Background work processes process programs that can be executed without user interaction (background jobs). Enqueue Work Process The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW

concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes. Spool Work Process The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process. The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process. You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.

Database Layer is where it contains three buffer( Database buffer,SQL buffer and Redolog buffer )and as Actual database where the commited data is stored.

History of SAP R/3

The first version of SAP's flagship enterprise software was a financial Accounting system named R/1 called as YSR. This was replaced by R/2 at the end of the 1970s. SAP R/2 was in a mainframe based business application software suite that was very successful in the 1980s and early 1990s. It was particularly popular with large multinational European companies who required soft-real-time business applications, with multi-currency and multi-language capabilities built in. With the advent of distributed clientserver computing SAP AG brought out a clientserver version of the software called SAP R/3 (The "R" was for "Real-time data processing" and 3 was for 3-tier). This new architecture is compatible with multiple platforms and operating systems, such as Microsoft Windows or UNIX. This opened up SAP to a whole new customer base. SAP R/3 was officially launched on 6 July 1992. It was renamed SAP ERP and later again renamed ECC (ERP Central Component). SAP came to dominate the large business applications market over the next 10 years. SAP ECC 5.0 ERP is the successor of SAP R/3 4.70. The newest version of the suite is SAP ECC 7.0. the srp is the bast module is planning.

Releases

SAP R/3 Release 1.0A Release Date 6 July 1992 SAP R/3 Release 2.0 / 2.1 Released 1993 SAP R/3 Release 3.0 / 3.1 Released 1995

SAP R/3 Release 4.0B Release Date June 1998 SAP R/3 Release 4.5B Release Date March 1999 SAP R/3 Release 4.6A Release Date 1999 SAP R/3 Release 4.6B Release Date Dec 1999 SAP R/3 Release 4.6C Release Date April 2001 SAP R/3 Enterprise Release 4.70 Release Date March- Dec 2003[2] SAP R/3 Enterprise Edition 4.7 SAP R/3 Enterprise Central Component 5.0 SAP R/3 Enterprise Central Component 6.0 SAP ERP 6.0 - Enhancement Packages (1,2,3,4,5,6)