Search The SAP Consultant

Tuesday, December 06, 2005

Reports on SAP

As we all know, all software take the input from the user, process it and give the output. One of the forms on which the output can be given to the users is ‘Reports’. SAP provides a large number of standard reports that can be used during the day to day operations. Today I would like to introduce two important SAP Area menus that can be used to access most of the SAP standard reports.

1. SAP Easy Access Report Selection

SAP Area menu SAP1


2. SAP Easy Access Info Catalog

SAP Area menu SAP2


I hope the above SAP Area menus would help you to explore and utilize the standard reports provided by SAP. Please feel free to send me your comments.

Tuesday, November 29, 2005

The concept of Table buffers – For functional consultants – Part one

First of all I would like to thank all my SAP friends from all over the world for the emails that you sent me. As well as I would like to thank SAP business community team for the motivation that they have given to me. Thank you guys! I really appreciate it.

Today I’ll talk about the concept of table buffers on SAP. This topic is pretty interesting and gives certain implications on ABAP programming model. I think it’s really useful to the functional consultants to have certain amount of knowledge on this subject.

As we all know, a well developed ERP system should try to optimize its performance by using every possible way. Especially the response time it takes to process the requests from the business user should be minimize as much as possible. By taking this factor into consideration SAP has designed the concept called ‘Table buffer’.

This concept has been developed by considering two main factors.

1. The network traffic between the application server and the database server

As I explained on my earlier posts the SAP database server and the application server can be located on two different physical servers. So every time the application server requests some data from the database, it should be transferred through the network from the database server to the application server which may lead to high network traffic on a typical SAP installation where multiple requests will be passed per second. This factor would slow down the system.

2. The database load

When the programs processed by the application server, directly deal with the tables on the database to manage the data, it increases the database load which will slow down the database’s performance. This will affect a program which uses a specific table in the database as well as other programs which try to use some different tables in the same database.

Solution for the issue

The concept of table buffer simply load the data of a database table into the application server’s RAM. So the programs would access the data from the application server’s RAM rather than directly from the database table.
By buffering data, we increase performance in two important ways:

1.The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.

2.The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.
According to the benchmark tests, buffering a table can cause a select statement to run 10 to 100 times faster or more.

The next question that SAP had was, whether to allow all the tables to be buffered or not. Obviously we all would say ‘Yes’. However, buffers are stored entirely on RAM, so space is limited by the amount of RAM available. In fact, there is so much more data than there is RAM, that tables must be buffered with caution to prevent overruns. If a buffer overruns, it might swap to disk, which can eradicate any performance gained by buffering. So SAP has developed this concept in such a way that each individual table can be configured to be buffered or not. But the tables containing a numeric data type as the primary key cannot be buffered

Buffering can be activated through the technical settings of any table. The following screenshot shows table T001, which has been activated to be buffered.

How does this concept work?

When an ABAP program issues an open sql statement, the application server will first check whether the table has been activated to be buffered or not, if the table has been activated to be buffered, the server will check the RAM for the buffered data.

If the buffer is available, the program will read the data from the RAM else it will read it from the database, populate the buffer and subsequently read from the buffer.

I think this post should have given you a basic idea about the table buffers. Definitely this concept improves the performance of the system, but we have to take certain facts into consideration when we try to activate the table buffer on any table. On my next post I will talk about the implications of table buffers in a more detailed way. As well as I will take a look at the multi application server environment and the table buffers.

Please send me your comments.

Wednesday, November 23, 2005

The concept of Data dictionary on SAP – For functional consultants

You should have heard about the word ‘Data dictionary’ on SAP. Today I thought I would explain the basic concept of data dictionary to the readers. As you know ERP software such as SAP heavily depend on database management systems. Frankly speaking an ERP system works as a front end to the database. Where we capture the data and store it in the database tables, and then we use the captured data to arrive at various business conclusions with the help of the programs provided by the ERP.

Most ERP systems store the configuration, transaction and master data in the database. But SAP has gone one step further and even stores the Program source codes in the database. It’s called SAP Repository. I’ll explain how the programs are being executed by the ABAP processor of the work processes, on a later post.

So as you can see, SAP has to deal with database heavily. As well as SAP has to allow the customer to enhance it’s capabilities, according to the business requirements, which may be done by modifying or creating various database objects such as tables, views and indexes. If SAP allows the customer to directly deal with the underlying database, it may lead to unnecessary problems and even lead the system to an unstable position. As well as it will not be possible to track the changes done to the database.

By taking all those into consideration, SAP has developed its software with a concept of ‘Data dictionary’. You can imagine the data dictionary as a mirror image of the actual database objects, which is part of the SAP itself, where the structures of the database objects such as tables have been replicated. For example every table in the actual database would have a corresponding table structure in the Data dictionary. ABAP programs will deal with the data dictionary objects which intern will connect to the actual database objects. For example if you check the table T000, which stores the client information.

The data dictionary object will look like the image shown below.


The details of same table on the actual database are shown below.

In addition, Data dictionary works like a remote control to the actual database. Developers create the database objects on the data dictionary and activate them; in the background the system will automatically generate the corresponding SQL statements and create the objects on the actual database.

As a strict rule the developers would never create or modify database objects such as tables directly on the actual database, in case if some one has created or modified a database object directly on the database, there is no way that the data dictionary could synchronize with the database object, which will lead to unnecessary problems and may affect the system performance and stability.

We can create objects such as Tables, Structures, Views, Data domains and Data elements on data dictionary. As well as SAP provides various tools to check the consistency between the database and data dictionary objects. I will look at each of those in detail on my future posts.

Please feel free to send me your comments.

Monday, November 21, 2005

Change the parked accounting document

Today we’ll see how we can control the access to the fields on a parked document, so that different groups of employees will only be able to change the fields to which they have been authorized to make any changes . The concept is very simple but I would say this is very effective and flexible to play around with. All we have to do is group the fields on the document into field groups and assign the field groups to the roles, which will then be assigned to the users. Simply follow the following steps to implement this concept on SAP.

Define Field Groups for Documents

Step one:

First we have to define the field groups. We can use the ‘Define Field Groups for Documents’ activity on SPRO


Select the object type as ‘Parked documents’. Please note that we can apply the same logic to other documents such as ‘Documents’, ‘External documents’. ‘Sample documents’, ‘Recurring documents’ and ‘Documents with preliminary postings’

Enter a Field group as a two digit numeric value and type a Description.

Step two:

As the second step we have to group the document fields. Use activity ‘Group Document Fields’ on SPRO to perform this step.


Select the object type as the ‘Parked documents’. Select the Field group that we have created in step one and assign the desired fields.

Step three:

As the next step we have to assign the field groups to the Roles which will then be assigned to the users. Every user can be given authorization to change fields in one or more groups. This means that a user may either change all or no fields of a document. The classification of the fields into groups should be carried out with this in mind.
Execute transaction code PFCG to maintain the roles. Select the desired role and add the desired field groups to the Authorization object ‘F_SKA1_AEN’


Bingo!!! That’s it. Now the users with the role Z100 attached to them would only able to modify the fields ‘Exchange rate’ and ‘Fiscal year’ on the parked documents while the others would not be able to modify any fields at all.

Field groups can also be used to filter the data on report ‘RFBABL00’ (‘Display of changed documents’)

I hope this post would have helped you to understand how SAP even allows us to control the access to each and every field on the documents. I strongly believe this flexibility with SAP is the main factor which makes SAP as the number one ERP in the world.

Please don’t hesitate to send me your comments.

Sunday, November 20, 2005

Automatic table history

Some times it’s critical to monitor the changes made to the important tables on the SAP database. SAP provides a way to automate this function. Today I will take you through the steps that we have to perform in order to activate this functionality. After we have carried out the following steps we would be able to monitor the changes using the transaction code SCU3

Step one:

Activate the ‘Log data changes’ option on the technical setting of the selected table. By default this option would be activated for tables such as T000 (Client), T001 (Company code) by SAP.

Now you may ask me if the automatic table recording has already been activated for tables I mentioned above, why system gives the following error message when try to view the change documents using SCU3


Yes we have to do one more step to activate the automatic table history functionality on a given client.

Step two:

Maintain the client number, for which we want to activate the automatic table history, against the parameter ‘rec/client’ on the application server profile.

Bingo now we are ready to go. Now we can use transactions SCU3 to view the change documents.

Ok now let me explain how exactly this works. Every time when you perform an ‘Insert’, ‘Delete’, or ‘Update’ statement on an ‘Automatic table history’ activated table, it will maintain a log on the change document table ‘DBTABPRT’. Check the following screen shot to see the structure of the table ‘DBTABPRT’


Details such as Table name, Date of change, Time of change, Host name, Person who has changed, Transaction code that has been used to change, ABAP Program name, Type of the operation (whether is it insert , delete or update) and the data change will be recorded on the table DBTABPRT. Later when we use transaction code SCU3, it will fetch the data from this table and display the change documents.

But it’s not possible to activate the automatic table history to a table where the length of the primary keys is more than 86 bytes and the length of non primary keys is more than 500 bytes.

As well as consider the fact that activating the ‘Automatic table history’ may slow down the database operations since all the tables with the above option activated need to access the table DBTABPRT to update the change documents and which may lead to table locks. So it’s advisable to activate the 'automatic table history' only on the tables which are really crucial.

Please send me your comments about this post.

Saturday, November 19, 2005

Parallel Accounting on MySAP Financials

Today I thought I would write about how we can maintain financial accounts according to multiple accounting standards. MySAP financials makes this process pretty simple with the new general ledger. On this post I will walk you through the steps that we have to do in order to maintain accounts per multiple accounting standards.

First we have to define the ledgers according to the number of standards on which we have to maintain the accounts. For maximum flexibility we can define one ledger per standard. But always consider the fact that we are going to duplicate the database entries per ledger for each double entry. So I advise that if you feel that there are standards which are pretty similar, use only one ledger for those similar standards.

There should be at least one leading ledger. Along with that we can define any number of non leading ledgers to satisfy our needs. When we define ledgers, system will automatically create ledger groups on a one to one relationship to the ledgers.

A ledger group is a combination of ledgers for the purpose of applying the functions and processes of general ledger accounting to the group as a whole. When posting, for example, we can restrict the update of individual postings to a ledger group so that the system only posts to the ledgers in that group. We can group the ledgers into the ledger groups with a representative ledger from which the system will determine and check the posting periods for that ledger group during postings.

After we have defined the ledgers we can specify the parallel currencies on which we want to maintain the accounts on leading and non leading ledgers for each company code. You can have up to three currencies per ledger per company code. But the non leading ledgers can only be maintained on the currencies that specified for leading ledger. But note that you don’t have to maintain non leading ledgers on all leading ledger currencies.

Another interesting functionality is that you can even specify different fiscal year and posting period variants to the company codes for the non leading ledgers than the leading ledger.

Even we can control how other components like ‘Cost Center’, ‘Consolidation’, ‘Business Area’, ‘Profit Center’, ‘Segmentation’ and ‘Cost of Sales Accounting’ will update the ledger by assigning the necessary scenarios to ledgers. A scenario determines which fields are updated when postings are received from other application components. We cannot define our own scenarios. For example we may only update the leading ledger with the cost center details while keeping the other ledgers untouched. This gives the ultimate flexibility to manage the trade off between the database performance and the financial information requirements.

We can add additional fields to the summery table and capture information that cannot be captured by the existing fields on the summery table FAGLFLEXT. Again we can assign the fields to the ledgers like we do to the scenarios as I explained above. I’ll talk about how we can assign additional fields to the summery table FAGLFLEXT on a different post.

My SAP financial even allows us to maintain multiple planning versions per ledger. For example we can use scenario planning techniques by defining different planning versions for individual ledgers which I feel really useful to the managers on this highly unpredictable business environment.

After we defined the ledgers and the ledger groups we can define the accounting principles on SAP system and assign them to the ledger groups.

Once we have carried out the above activities the next step would be to create the accounting document types and their number ranges for entry view. The important point I want to stress at this time is that we have to define number ranges for the accounting documents specific to the non leading ledger groups too. And we cannot use the same number range object we used for the leading ledger. The reason is when we post documents to a specific ledger group if we have the same number range assignment as leading ledger; it will create number gaps on the leading ledger accounting documents. So system will not allow you to specify the same number range object of leading ledger to be assigned to the non leading ledgers.

When it comes to Document types for general ledger view, we don’t have to do anything for leading ledger since in the case of this ledger, the document number in the entry view always corresponds to the document number in the general ledger view. We only have to make these settings for any non-leading ledgers that have a fiscal year variant that differs in at least one company code from the fiscal year variant of the leading ledger in this company code. In this case, the document number in the entry view does not correspond to the document number in the general ledger view and we have to define a separate document type with document number assignment for the general ledger view.

These are the basic settings that we have to do in order to carry out parallel accounting on MySAP Financials. Now we can use transaction codes FB50 and F-02 to post double entries into all the ledgers and transaction codes FB50L and FB01L to post double entries to selected ledger groups. We can generate the financial statements per ledgers when we need them.

This is a basic idea about how we can configure parallel accounting on MySAP Financials and hope that this post has given you a good idea about some of the new SAP general ledger functionalities. Please feel free to send me a comment.

Friday, November 18, 2005

SAP Application server – The Concept

Today I would like to have a look at the SAP application server architecture and how does it work. As you know when we want to work on SAP, as the first step we log into the SAP Application server using SAP GUI. From that moment the SAP application server processes each dialog step executed by the user and responds back to the presentation server. If the dialog step has some SQL statements to be executed, the application server passes the request to the SAP database server.

In an SAP landscape there can be multiple SAP application servers on one SAP system. So you may wonder how SAP determines the application server into which the new user has to be directed. This is the job of SAP message server, which makes the communications possible between the application servers, presentation server and database server. So when a new user logs in, first he will be connected to the SAP message server. SAP message server will determine the suitable application server based on the work load of each instance and will direct the user to an instance with less work load. You can view the details of the message server by executing the transaction SMMS

The following diagram shows the main components of the SAP landscape.


Dialog step

Once the user has been logged into the application server, he can start executing the programs. Each program can have many dialog steps. A dialog step is nothing but the process that will be processed by application server between two screens of the transaction. For example when we post the general ledger entries using the transaction code FB50, we enter all the relevant data and press the ‘Post’ button. You can notice after you have pressed the button, the screen becomes inactive and the data will be sent to the application server. Once the document has been posted the screen will become active again with the confirmation. So the activities done by the application server between those screens is called a dialog step.


Application server components

The Basis is the runtime environment for the ABAP programs. We can start the SAP application server by typing ‘startsap’ on the cmd command. When we start the application server a collection of R3 system files will be executed and will wait for the requests from the presentation server. We have to note that even though ABAP programs are operating system, hardware and RDBMS independent, the SAP kernel and the Basis system are OS, hardware and RDBMS dependant. Now let me introduce the main components which make the application server

1. Dispatcher
2. Work processes
3. Gate way – this is the interface for R/3 communication protocols
4. Shared memory


Dispatcher

When a presentation server requests a dialog step to be executed, the request will be sent to the dispatcher of the application server on which the user has been logged in. dispatcher will add the request to the dispatcher queue. Then the dispatcher will allocate the requests to the available work processes based on first in first out basis. As I said before one program can have many dialog steps and all the dialog steps of a given program need not always be executed by the same work process. This gives certain amount of implications to the ABAP programming model.

Work processes

Do you remember that I have written on the previous post that ABAP programs are executed by software processors rather than directly by the CPU? Yes work processes within application servers act as the virtual processors. Each work process will have the following components.

Task handler.
Screen processor – which processes the flow logic of the program
ABAP processor – which processes the ABAP program logic
Database interface

There are different types of work processes which perform different types of tasks. Such as dialog work processes, background work processes, spool work processes etc. the number of work processes and the type can be controlled by changing the parameters on the application server profile. Application server profile is a configuration file located at each application server which would contain the parameters and the values of the server.

You can view the application server profile by executing the transaction RZ10. From the menu bar of the transaction RZ10 select the Goto à Profile values à Of a server. Then double click on the server name. The following parameters will specify the number of work processes.

rdisp/wp_no_btc
rdisp/wp_no_dia
rdisp/wp_no_enq
rdisp/wp_no_spo
rdisp/wp_no_spo_Fro_max
rdisp/wp_no_vb
rdisp/wp_no_vb2

The system administrator can use the application server profile and manage the number of work processes to optimize the system performance. For example the administrator can set more dialog work processes during daytime and more background work processes during nights.

You can use transaction SM50 to view the activities on the work processes. Press and hold F8 to see the activities.

When the application server has been started the work processes will register themselves with the database layer. In other words each work process will act as a database client and open a dedicated connection to the database.

One of the fundamental concepts in business application development is that the database changes should be consistent before and after a sql operation has been carried out. In database world, we call it as transaction; a transaction will execute the entire sql set or rollback to the initial stage. In SAP world it’s being called as Logical Unit of Work (LUW).

The work process will execute the entire SQL statements belong to a dialog step as a LUW, this makes sure that the database is consistent before and after a dialog step has been executed by a work process.

But now you know that the dialog steps belong to one program might be executed by different work processes which mean it would have multiple LUW. So there is a chance that the database may be inconsistent if the program terminates after certain dialog steps are executed and the rest are not. For this issue there are bundling techniques provided by ABAP. One of those is SAP LUW which bundles the dialog steps with the underlying SQL statements.

Shared memory

All the work processes on an application server shares a common shared memory space. I will discuss the concepts of user contexts and roll area on a later post. We had a maximum memory limitation with the 32 bit computer processors but with the introduction of 64 bit processors the memory limitations are not an issue any more.

I hope that the above explanations would have given a high level understanding about the SAP application server and its components. We can optimize the performance of SAP system by manipulating the number of the application severs on an implementation and the number of work processes and their types on each application server. Please feel free to send me your comments by clicking on ‘Comments’ button shown below.

Thursday, November 17, 2005

SAP system landscape – basic idea for functional consultants

As we all know SAP works on client server architecture. The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The actual client/server model started gaining acceptance in the late 1980s. The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralized, mainframe, time sharing computing.


I’ll explain the client server model using a small example. I’m sure that all of us have used Microsoft outlook to send and receive mails to our buddies. To send a mail we open the Microsoft outlook on our pc, type the new mail and press the send button. Here the Microsoft outlook acts as a client. Once we pressed the button outlook connects to the exchange server which will receive the request from the client and send the mail for you. Here the microsoft outlook as a client sends the request to the exchange server. server receives the request and process the tasks.


When the client and server programs both run on the same computer, the configuration is referred to as single-tier client/server. (A tier is the boundary between two computers.) When they run on different computers, the configuration is referred to as two-tier client/server.
A program can function as both a client and a server if it both requests information and replies to requests. When you have three programs in communication, the configuration is called three-tier client/server.


The main advantage of the software of this nature is that it can be fine tuned to give maximum performance for the given scenario. The client/server configuration enables the MySAP ERP system to spread its load across multiple computers. This provides the customer with the ability to scale the processing power of the system up or down by simply adding another computer to an existing configuration, instead of replacing a single computer that performs all of the processing, such as that which occurs in the mainframe world.

The main software components on a SAP system can be categorized as follows.
1.Presentation server
2.Application server
3.Database server

Presentation server

Presentation server is nothing but the laptop or PC which has sapgui.exe that you use to log into SAP system.

Application server

An application server is a set of executables that collectively interpret the ABAP/4 programs and manage the input and output for them. Application severs act like a mediators between the presentation server and the database sever. Application sever receives the requests from the presentation sever and process them on its work processes. I’ll talk about the work processes in details later on this blog. The important fact that I want to share with you is that the ABAP programs are processed by ‘Software processors’ and not directly by the CPU. I’ll discuss about the components of an Application sever later on this Blog too.

Database server

The database server is a set of executables that accept database requests from the application server. Database server will pass the requests to the RDBMS that has been used. As you should know SAP supports Database management systems from various vendors such as Microsoft SQL server, Oracle, Informix and Sybase etc. The RDBMS sends the data back to the database server, which then passes the information back to the application server. The application server in turn passes that information to the ABAP/4 program.

Some technical terms that useful to functional consultants

I think it’s appropriate to tell you the meaning for some terms used by technical consultants. If you hear a word MySAP ERP system or R/3 system, it means an implementation with one database. In other words, the implementation that you did for company A with one database as the backend is one system and the implementation at company B is another system

Another frequently used word is ‘Instance’ this simply means the application server. If your technical consultant buddy says we have one instance which means we have one application server. If he says five instances which mean five application servers are running on the environment. For example HP runs around 70 instances or application servers to manage its global transactions.

Different types of configurations

As we have seen above SAP is a client server based system which gives us enormous flexibility to configure the system to suit our environment. Presentation server, Application server and Database server can be put at different possible positions to get the maximum throughput from the system, which means there are virtually unlimited configuration possibilities.

1. SAP three-tier client/server configuration: the presentation servers, applications servers, and database server all run on separate machines. This is the most common configuration for large systems, and is common in production. As well as you can have multiple applications and database servers to share the work load.

2. SAP distribution presentation configuration: the application and database servers are combined on one computer and the presentation servers run separately. This is used for smaller systems, and is often seen on a development system.

3. SAP two-tier client/server configuration: the presentation and application servers are combined and the database server is separate. This configuration is used in conjunction with other application servers. It is used for a batch server when the batch is segregated from the online servers. A SAPGUI is installed on it to provide local control.



4. SAP central configuration: all servers are combined onto a single machine. This is rarely seen because it describes a standalone R/3 system with only a single user. I don’t think anyone will buy SAP with millions of dollars to install it on their PC :)


SAP is much more flexible than any other traditional ERP systems. It’s the duty of the technical and functional consultants to sit together to draft a technical system blueprint to maximize the performance of the SAP. As well as we should also consider the budget and hardware limitations when drafting a technical landscape.

I hope this article gave you a better understanding about the SAP technical landscape. Please feel free to send me a comment about this article by clicking on the ‘Comments’ button.

Wednesday, October 12, 2005

8 SECRETS TO A SUCCESSFUL SAP IMPLEMENTATION

Many wonder what constitutes a successful SAP Implementation. Everyone wants to have a great success story to talk about, from the top management to the implementation consultant. Success is a relative term.

You will hear: "Successfully went live on the planned date and on budget" - You should ask though whether the initial scope was implemented or did they have to take business processes out of scope in order to make it. - You should also ask how are things now that you went live? Can you ship to your customers without any problems? Is the system performing well? Are the end users fully trained and are they doing their job well? Do you still need consulting support to go through your day-to-day business?

Once you put these questions into perspective you can really define a successful SAP Implementation in many ways and many levels.

Success Factors

Here is a list of factors that determine the relative success of a project as mentioned above.

1. Communication:

For a successful SAP project implementation the number one factor is good communication among the project team members. Everybody claims that they are good communicators and we surely have the technology to maintain constant communication with land-phones and cell-phones and email, but it is true that they are not used to their maximum ability.

For example, when there is an issue, which needs to be communicated to multiple people, usually one will email to a number of people who should really be involved. It is extremely annoying and brakes the communication chain when somebody replies only to the sender of the email without including the rest of the members.

SAP is such integrated software that has constantly touch points among the modules. As such, constant integration among the teams is of paramount importance.

Not only constant communication is important, but GOOD communication is important. People must be very clear about what they are talking about. There is a little phrase: "Mary had a little lamb" - these five short words can create such confusion and result to numerous different meanings;
· Mary used to have a lamb but does not anymore
· Mary had a little lamb which now has grown into a big one
· Mary "had" (i.e. ate) a little lamb
I am sure you can make a lot of other meanings out of this small sentence

Now imagine, if this little sentence can cause such confusion, what mess would be created when dealing with complex business processes, spanning through several departments within an organization and involving anywhere from fifty to thousands of employees, end users, managers, consultants.

So the key is good, accurate, specific and timely communication. Clarify things several times. Explain them as if you were talking to little children.

In order to achieve this type of good communication team members should have their workplaces physically close together. I have seen in many recent cases where the Consulting firm in order to "minimize" costs for the client, they outsource much of the Development ABAP programming work outside the USA and in most cases to other continents.

Based on all the things mentioned above, how can good communication be achieved? It is not possible to simply create a program spec with a description in writing and expect a programmer located on the other side of the planet to figure out what the Business Process is, and what would make the program work according to the client's requirements.

Some consulting firms that do this practice will argue that "it is possible and they have success stories to tell". Well, remember at the beginning of this article what we talked about "Success".

We have witnessed this type of "success" when we went in to resolve the issues of such implementation method. We have witnessed the never-ending consulting hours that the client has to pay because of this implementation method. Often the client is made to sign a contract which says something like "…when the program is complete (but not really working as per the client's requirements - this is not stated anywhere) any change to it would be considered change of scope…". Such practice force the client to either abandon the effort of making the program work because of the extra scope-change cost or keep paying more, in order to try make the program work.

These tactics are unfair to the clients and give a bad name to the Consulting industry.

The client needs to take charge of these situations. Make the rules of good communication. Make the rules of the type of consultants you want to have. Provide the physical and technological infrastructure for the basis of good communication. Do not allow "consulting" companies to hide behind a "Big" corporate name.

Clients deserve the best for the huge amounts of money a SAP Implementation cost. Communicate well, take control of your project and do not be sold on "air-talk".

2. Full Corporate Management Support:

Nothing will happen, nothing will move, unless Management supports it. There must be full and utter commitment and support for the project. If Management does not show both in words and deeds that the SAP Implementation is important than the team members, end users and so on, will not be on-board, will not be dedicated. Without dedication the project is bound to fail.

The ways management provides support for the project is by actively participating in the planning and management of the project. Proactively getting involved not only in the high level plans and decision making, but also in the lower level and just as important activities of the day-to-day activities of the project. Get in touch with the project team members, know and be interested about their job and where they stand. This will motivate and keep people committed.

When management is involved then issues get resolved easier, conflict is overcome faster, because the management know the details of what is going on. How is this achieved? By keeping weekly status and communication meetings (remember communication?) These meetings are not to judge or interrogate anybody. They are done so that all members are informed as to what is happening keep the pulse of the project.

The management should help the project move forward, not hinder it with too many bureaucratic procedures. Keep meetings short and to the point. Maintain one status report, not 15 different reports. Have procedures but do not overdo it to the point where the project becomes inflexible and time consuming to make a decision or take a corrective action. Manage the project and provide people enough freedom to do their work. This will be appreciated.


3. The Project Plan and a Methodology are Guidelines - Not Rulers:

Make a good plan. Make a Realistic plan. Most projects do not have a realistic plan. People think everything can be done really fast. They do not allow enough time for the unforeseen parts of the projects. The vendors delaying to deliver the hardware, running out of disk space, actual training time takes a lot longer that thought, users need more training or they are overloaded with their every day job that cannot attend training and much more. The Master Data are corrupt and we need a new SAP Client. We can make a copy. We plan one day for the copy, but why is it always that a SAP client copy always fails the first time resulting taking two or three days?

Remember, if anything can go wrong, it will go wrong. Allow enough time in your plan for travel time, for public holidays, for vacation. There are so many project managers planning to go-live on January 1 - how foolish, inappropriate and disrespectful to the work and dedication of the people. As soon as Thanksgiving comes around things slow down dramatically and especially the last two weeks of the years are down to a crawl. Take these times of the year into account.

If you cannot go live as per the plan then do NOT go live. It is better, cheaper and safer to delay the go-live and being able to serve your customers. Better than going live just to make a big corporate announcement that we went live as planned but then everybody runs around like headless chickens trying to fix problems, help the users, correct errors, serve your customers.

Allow time for errors. Always have contingency plans. What if the go-live fails. Make sure you have a way to regress to the legacy system to be able to function properly as a business.

the most known SAP Implementation Methodology is ASAP or Accelerated SAP. Consultants should be Certified by SAP. Following this methodology can be very helpful and really accelerating your process. It can also be a inhibitor and delaying factor if it gets overused. ASAP contains a huge amount of tools, templates and instructions of how to implement SAP. Use common sense. There is no reason to try to use one hundred percent of the ASAP methodology. Use only the parts that help you. There are excellent templates for documentation, BPP documents, Training and testing documents, which would take a lot of time to create from scratch.

4. Make a proper Scope:

Which parts of SAP will you implement. Often team members get too excited and want to implement a hundred percent of the processes SAP offers. Not possible. SAP should be implemented according to the Business needs and processes. There was a team member once that wanted to use Classification in the Material Master at a time that it did not make sense for their business. There was another team member that wanted to implement Evaluated Receipt Settlement or ERS for Vendor Invoicing at a time when most invoices did not much the Purchase Orders. These members were warned that these processes were not appropriate. They did not listen. The process failed.

Be realistic. Because SAP can do almost everything it does not mean that you should implement almost everything. You must make sure that your users are technologically advanced, computer literate enough and that they understand the business processes, which will allow them to comprehend and manage the change that such an implementation will bring.

5. Motivate, Appreciate, Reward your people:

It may sound a cliché, but it must be done. Do not do it just to be politically correct. Do it because you mean it, put your soul into it, make it personal. This is one of the few things someone should take personally in business!! People will work twice as hard when they are appreciated. In order to be able to know what you are rewarding people for, you must be involved it their day-to-day business - here come back again the Full Corporate Management Support point mentioned above. A "thank you" goes very long way.

6. Manage Change:

One of the most important factors is how the organization handles changes. This is one of the riskiest part of this business. To make your people understand that change is a good thing. To make the embrace change and make it happened.

This challenge is accomplished with all the above points mentioned, i.e.
- Full Corporate Management Support
- Communication
- The Project Plan and the Methodology
- A proper Scope
- Motivate, Appreciate, Reward your people

If these are followed and executed successfully, people will appreciate and embrace the coming changes. Admittedly, very, very hard thing to achieve for many reasons. Human nature is to avoid change. Therefore, going against human nature is starting off the wrong way. People are afraid of business change because often they are afraid of their job security - unfortunately often rightly so.


7. Politics:

Every project has them (politics) to some degree. Make sure politics and hidden agendas do not derail your implementation process. Stay focused and bring out in the open differences sooner than later. Do not allow people with hidden agendas mislead the project to the wrong direction. Stop this soon and stop it hard. Politics should not be tolerated and should be dealt with firmly and tactfully at the same time.

8. Find Excellent Resources:

The client, the management, must be involved in the consulting recruitment process. Do not simply trust the Consulting firm. Make sure the consultants know their stuff. Make sure the consultants do not have "layers" of intermediaries before they reach you - the final client. The more layers, the more the Consultant's rate is reduced, which in turn it means that the consultant who are willing to work for the lower rate are usually the least knowledgeable. In life you get what you pay for - and even though you as a client might be paying dearly for the consultant, too many layers reduce the consultant's rate and therefore the quality.

The next time someone says "we had a successful project", analyze the facts first to determine the degree of success. Some consulting firms (not to mention names) when their relative success of a project is pretty low, they "declare victory and leave the project"!! They announce to the world of the "success" of the project and then they move on leaving the client to suffer the consequences both in business and cost terms.


(Thanks to Evolutionary Consulting, Inc)

Sunday, August 28, 2005

About Me

Hello Reader,

My name is Shathees Loganathan. I was born and brought up in a beautiful island called Sri Lanka and living in USA as a permanent resident since 2007.

I'm an associate member of charted institute of management accounts UK (CIMA) and a member of charted global management accountants (CGMA). Currently I'm reading for my MSc in strategic business management from Manchester Metropolitan University UK.  I have also completed a two year diploma in software development at NIIT India while doing my studies to become a management accountant which helps me a lot when playing around with ABAP coding and HANA data models wearing the finance hat.

I am in SAP consulting world since 2004. I have lead the SAP finance rollouts for clients such as MAS holdings in Sri Lanka, Warnaco (USA, Canada, Mexico), Global Brands Group, Timberland, Maidenform, Bio-Rad, Viacom (US, Canada, Europe, South America including Brazil) and Wiley (US, Canada, Europe, Asia). I was also part of pre sales efforts through out my career including the resent engagement with Nike along with EY in 2017.

I can be reached thorough any of the following channels.

Email - shathees@gmail.com
Phone - 585 471 0704
Skype - shatheesl

Cheers!