Friday, November 23, 2007

Monday, October 29, 2007

Change SAP logo in top right hand corner of SAP client

I was a little bored to do heavy duty technical stuff, and ended up doing this small thing. But it is interesting and worth the time spent.

The following steps demonstrates how to replace the SAP logo in top right hand corner with a dancing penguin. If you look at the penguin image in paint you will see that it is basically a collection of slightly different still images next to each other. Therefore if you have got the time and patience you can insert any moving picture you want.

1. Open field directory C:\Program Files\SAP\FrontEnd\SAPgui\themes\HighCont
2. Rename file sapalogo to sapalogo_tmp
3. Right click on the following file and select ‘Save Target As’, save to above directory
4. Repeat for directory C:\Program Files\SAP\FrontEnd\SAPgui\themes\enjoy

Tuesday, September 04, 2007

Importance in Business Intelligence: Types of BI

The first step in Business Intelligence is the process of transforming data into information. There are many ways of extracting the data and formulation into information, but in reality, the type of information needed is dependent on the type of the people who are expecting it. There could be people who might be working in the operational activities such as customer service representatives, and then there could be people who might be working in the tactical leave such as the lower and middle level management and those who are responsible for the strategy of an organization, such as senior and the executive management. Base on this classification, the BI component can be classified as:

1. Operational BI

2. Tactical BI and

3. Strategic BI

Based on the nature of the needs of their own field of working, the nature of the information also varies. See the following picture, which is referred as the BI pyramid depicts the nature of the information required by each user group. The pyramid is used to explain this as the number of users is less as we move from operational to strategic BI needs. This is the classical way of explain the types of BI and is religiously shown in all BI presentations:


The senior management who needs the strategic gives the information as a global overview of the entire business. In olden days it was referred as the Executive information system (EIS) and now evolved as dashboards as they are indicators of the actual performance of the critical indices.

The middle management who is very much working on the tactical issues, needs more flexible and detailed reports to improve their decision making. The information can be quickly assembled into useable form using ad-hoc queries. They are not the pre defined dash boards, but flexible and modular set of queries, which can slice and dice the data cubes for the discovery.

In the operational level, the requirement is with standardized, detailed, preformatted reports provided by an automatic report engine. Typically these reports are of the type of spreadsheets, and can be taken offline to format and regroup using standard software like Microsoft Excel.

Given the types of the BI that are needed for any organization, now-a-days most of the BI software packages do come with a variety of tools that addresses each section of the BI pyramid, though there are some inconsistencies on the definition of each layer. The only important thing that is missing in this pyramid is the data mining, which is for a special set of people who are specializing in that activity. Data mining is itself a huge subject and we can discuss this later as a separate topic. I recently read one very detailed paper (draft) by one of my colleague on the data mining explaining its relevance and importance to UNICEF.

Let’s now get into the practical side of the BI and the way in which is it used:

It is very hard to see a senior manager that is content with an overview of the business activities - unless he or she is incompetent. Any I’m sure the every competent senior manager will always need detailed data for some or many specific operations - and often on a regular basis. My honest opinion is that the dashboards are great for management meetings, but whoever runs an organization based on this alone, may at times will feel short of information that are required to make effective decisions. This is due to the very nature of the dashboard and the lack of details in it.

I have yet to see the middle managers that indulge in On-Line Analytical Processing (OLAP) and ad hoc querying more than others in the organization. Middle managers especially non-IT organizations are not more computer literate than anyone else. And OLAP and ad hoc querying do demand more computer skills from these managers. The very notion of using tools like this will drive them away from using them or try to move that work under them to operational group. Practically they get the information from the operations team, whose mind set is still in the preformatted reports.

Finally, who on an operational level feels happy about only having standardized and detailed reports? First problem is that they do not always agree with the standard form of reports, secondly the time taken to create & download the reports, thirdly the repetitive nature of the report generation creates boredom and finally they had to convert all the reports to spreadsheets for them to use it. We should not forget the fact that the use of spreadsheets is grown more then the legacy systems, ever after the implementation of all the new dimensions products such as ERP and BI.

Going back to my previous statement about the popular BI pyramid, which looks nice - especially when it comes in fancy colors - but it is rather imperfect and too far from what is practiced. As a result, more and more BI solution providers are beginning to realize that the reality is a bit more multidimensional than the BI pyramid: Strategic users also want detailed data and operational staff wants to have the overall picture. The middle managers want and need both detail and overview, and they are not more likely than anyone else to decide to spend and afternoon doing their own ad hoc queries in their office.

After a decade of BI evolution, some, but not all, have finally realized that BI is as complicated as anything else. The users are as irrational in their needs as they are with anything else. Many of them do like the colorful BI pyramid though and, given its inclusion in BI presentations, it will probably stay on for some years.

If allowed, I’d refine the BI pyramid by adding a group called systems analyst, which will be the central focus of the BI function, who will closely work with the three different user groups. They are the core set of people who knows how to use the BI tools effectively and efficiently and they are not the IT people. There is always the involvement of IT in this whole picture which is ideally the provider of BI infrastructure and not the provider of BI itself.

Monday, September 03, 2007

birthday cake


After long search, I found this as the character acceptable by my son for his 4th birthdat party cake!

Thursday, July 05, 2007

One ERP versus One Ecosystem

One ERP versus One Ecosystem

The one thing that has been reverberating in the Information Technology circles at UNICEF is about One Enterprise Resource Planning (ERP). This is based on a very strong recommendation that came out from the Business Process reengineering (BPR) by Dalburg and accenture was to have a true ERP environment in UNICEF .This has been a very controversial at the same time political decision that involves a whole a lot of resources in terms of money and people. Please go to the following link to see the entire recommendation.

There are two different aspects to effectively achieve the true ERP system. They are having One ERP system implemented and followed worldwide so the Head Quarters (HQ) and the Country Offices (CO) see the same information in the same way. The other way is to build an Eco system, as I call it, which will comprise of one ERP, combined with one or more systems distributed worldwide with proper interfaces.

Before getting in to the discussion of going right in to the True ERP discussion, we need to look at the evolution of the software during the past fifteen years. When people started using computers for business, it was towards simple applications such as financials, simple automation of the documents using word processors and spreadsheets. Then was the use at the manufacturing such as Material requirement Planning (MRP), Inventory maintenance, accounting involving Accounts payable and Receivables, etc. Even though this was of great help, there was no value addition in the decision making process. Then came the wave of adding more value to the computerization, and integrating the common functions such as Material requirement, Inventory, Purchasing, Financials, Costing, Sales, etc. This evolution is termed as MRP-II and a lot of software development focused on these integrated issue. Even though there was a lot of resistance to these MRP II software packages, they gained steady ground over a period of two to three years, when the managers felt the automation process lead to the formation of Islands of automaton and needed more integration to be able to make effective decisions. This gave birth to the Enterprise Resource Planning (ERP) software. SAP is one among the leader and very popular ERP software with others like PeopleSoft (Oracle) and SAS.

These ERP solutions blended the business and technology so well, that it was very difficult to differentiate them from one another. But in almost all cases, the ERP initiative was driven by the business and would have been supported by the IT section of the organization. However, there were clear overlaps as the technical personal were also equally responsible for the improvement of the business as they know the customizing of the software better than the business user.

This ERP philosophy brought all applications together and tightly integrated. The entire business community was very happy to embrace it for its integrated functions. Added to that because of the Y2K fear, many corporations jumped in to the ERP bandwagon and started their implementation. The ERP as designed brought in the tight integration between different components of the business, at cost of flexibility. As a result, the implementation resulted in huge changes in the way the business was run before. Change management team was a critical element in each implementation and eventually the organizations that were implementing the ERP solutions, started customizing the system to suit their businesses. This was more like cutting their own foot to fit the shoe size. This process of custom development led the ERP software makers to think of their benefit and they themselves started delivering different products for different sectors such as Public sector, Apparel and foot ware, Beverages, Banking, Insurance, etc.

In spite of the different product lines, the organizations did not leave their quest to customize the software to their need, as against critically evaluating their current business process. Reengineering was taken out of the list and Refitting was added. The software systems which were based on the best practice processes were bent to fit to the processes existing in the organization. This has greatly influenced the gains that were projected to happen with the ERP implementations. This in addition to the technological development in the internet era, the software companies, started adding more functionality, options and catchy front ends as bolt-on features shifting from their own integrated architecture.

The convergence of the processes now took the divergence once again. This process led the organizations to use various set of software tools to cater to each specific functions such as Customer Relations Management (CRM), Business Intelligence (BI), Supplier Relationship Management (SRM), etc in addition to the core ERP application.

This will lead to the debate of using one ERP software solution and the respective bolt-on function versus the use of ERP system and to use the working legacy system or third party cheaper software and interfacing them effectively. The second method can be referred as building one Ecosystem in which the processes and the business views in all individual systems are maintained consistently. The Ecosystem approach is very common in private sector based mainly on the implementation cost and to leverage the cost invested in the legacy systems.

The main advantage of the one ERP is that the implementation is fairly simple and the future upgrades could be smoother. The business logic and the process integrity are well established and you can have a seamless support from the software vendor. The major disadvantage could be the cost. Traditionally the solutions provided by the ERP systems are very expensive and also demand a reliable and established infrastructure to operate.

On the other hand, building one eco system will be a very cost effective method, but the ownership to design, develop and maintain the software needs to be addressed in house. Keeping up with the technology will be a big challenge in this case.

Either of the two solutions can be adopted strategically to any organization. In this moment UNICEF is in cross road to make a decision on going one way or another. This strategic decision will be a key to the success of the organization’s mission in the coming years.

Tuesday, May 22, 2007

RFC Calls for Manipulating Internal Tables

One of my friend had asked to explain the process of manipulating the internal tables with the RFC calls from SAP. The RFC is enabled by the function interface that is part of the RFC library provided by SAP.

These functions allow processing of ABAP internal tables in C.

ABAP internal tables follow the model of a relational database table.

ABAP internal tables consist of identical rows. When it is created, a table is empty. In ABAP you can fill rows into a table by the statements ‘Insert’ or ‘Append’. You can access a row by ‘Read Table’, and you can delete a row by ‘Delete’. You can free a table by ‘Free Table’, and you can receive information about tables by ‘Describe’.

These language constructs correspond to the following C routines:

  • ItCreate

creates a new internal table

  • ITAB_H

handle of an internal table

  • ItDelete

deletes the content of a complete internal table and frees storage

  • ItGetLine

reads a line from an internal table

  • ItInsLine

inserts a line into the given position of an internal table

  • ItAppLine

appends a line at the end of an internal table

  • ItDelLine

deletes a line from an internal table

  • ItGupLine

reads a line for update

  • ItFree

resets an internal table to initial state

  • ItFill

returns the number of lines in a table

  • ItLeng

returns the width of a table, i.e. the size of a row of the table

The syntax and semantics of the above RFC calls are identical for all platforms supported.

The syntax of the RFC calls is described in saprfc.h. The syntax of the RFC calls for manipulating internal tables is described in sapitab.h.

Creating and filling a new internal table with the following example

const int myTableSize = 200;
ITAB_H handle;
void * ptr;

handle = IitCreate("MyTable", myTableSize, 0,0);
if(handle == ITAB_NULL)
{
... error
}

do
{
ptr = ItAppLine(handle);;

if(ptr != NULL)
{
memcpy(ptr,..., myTableSize);
}
while(ptr != NULL);


More help is available in the SAP help site:

http://help.sap.com/saphelp_46c/helpdata/de/22/043074488911d189490000e829fbbd/frameset.htm

Thursday, January 25, 2007

Programming with Substitution

Substitution is a very powerful tool that SAP delivers with most of the application module. Let's first see what is substitution. A substitution is a configuration step, that allows a process (or a step) of replacing values as they are being entered into the SAP R/3 system using a transaction. For example in this case, we take up the substitution use in the Work Breakdown Structure (WBS). When the users are creating or modifying a particular WBS element (using transactions CJ01 or CJ02), we can change certain values behind the scenes based on certain required logic. This values can be either for standard fields or for customer fields (CI Structures). To know more about the CI structures, please see my blog on the CI structures.

And also remember, the entered values are checked against a user-defined Boolean statement (prerequisite). If the statement is true, the system replaces the specified values. Substitution occurs before data is written to the original database.

Even though in most of the cases substitution may be simple, in some cases it could be really tricky. This document is intended to address those cases. In this example, I'm going to demonstrate a custom field to show the entire process of substitution in a WBS structure.

Displaying substitution
For the project system, we open the IMG (transaction SPRO) and navigate to the following path:

Maintain substitutions and on the left frame go to the WBS element node

Go to the menu Extras -> Substitution Fields

This will show the list of the fields that are substitutable. In the standard system, most (or all) of the table related to the WBS (PRPS) will be available. As we discussed earlier even the customer fields in the CI_PRPS structure can also be used. In my case I needed to have a bunch of Z fields and they were added to the CI_PRPS structure and in turn to the PRPS table

By adding it to the CI_PRPS structure, these fields are available for me to enhance the screen for the WBS create/change transaction. To do this you need to create a project using CMOD and include the component CNEX0007. Use the screen exit to create a screen and the Function exit to add logic. Fine, now let's go back to the substitution.
SAP has a very basic common structure for all substitution related processes. The underlying table is GB01. This table contains all the tbles and fields that can be substituted based on the class type ('S' for substitution). Here is the screen shot of table GB01.

Once we decide the substitution field, we need to insert it in to this table. SAP does not provide you any means to do that. So use the following routine to add the entries
Program: ZNFI_UPDATE_TABLE_GB01
Copy the source code, and execute the program and add the fields as required into the table GB01.

After running this report for a set of Z values, the table GB01 looks like this:

Once this is done, then the substitution structures should be regenerated. Without this step that added fields in GB01 will not ba available for substitution. To do this we need to run the SAP program RGUGBR00.

Once you complete the regeneration, let's go to the actual substitution area to create and implement one.
In the example, I've created a substitution under WBS and under the node WBS_ELM

This document assumes that you know the substitution basics and the prerequisite. In this case my prerequisite is to check the project profile before carrying out the substitution. Then an user exit code is added U0500. Double clicking on this will take you to the code. Add the code to move the values to the PRPS structure based on the WBS level.

As usual, any comments welcome.