SAP

This is a topic that has seen discussions amongst Consultants and Business alike for quite a few years. And the truth is there is no one fixed ‘mantra’ that can be a solution to this debate. While there are approaches and methodologies defined and executed by various organizations, the solution for one organization or Industry does not apply to the other. Every organization will need to find its own balance between the two.

For example the most commonly used theory is “build a global process template consisting of various Level 0 processes and roll it out to all the geographies. The local changes that can be allowed to the template can only be restricted to the legal requirements of that location.”
Some of the level 0 Process referred to are again standardized to:
- Order to Cash
- Procure to Pay
- Produce to Inventory

These processes can vary a bit in naming but essentially they all do mean the same. If these were so standard, why is it that each time a template is created it undergoes a change with each rollout? Why is it that each business that uses template insists they are different? Why do we always demand and complain about flexibility from the system?

In my view the equation is or appears complicated because of the number of dimensions that are normally involved in such companies. I have tried to put together a set of dimensions (not the only ones) to determine the balance a company has to take between standardization and flexibility.
- Type of business (Project, Manufacturing, Trading, Services)
- Reluctance to Change/Global spread (rigidity, cultural mix etc)
- Compliance Mandates

For example an Organization in the Manufacturing type of business, and having high reluctance to change and requiring high levels of Compliance: can afford to standardize on Manufacturing and procurement processes while requiring flexibility in the areas of Sales and tracking of items.
Similarly, an organization in Projects kind of business, requires high flexibility in Manufacturing while a lot of standardization can be achieved in the sales processes

I would be interested to hear inputs and thoughts about this line of thinking based on your experience in projects. 

Posted by Ravishankar Subramanyam Hossur at 12:15 PM | Permalink | Comments ( 7 ) | TrackBacks ( 0 )

Coming to the last of the blog series on BI layers, this topic will also touch upon some popular analysis models used by data architects and analysts to develop and understand an enterprise data model.

Data preparation layer – This layer is important from a data mining perspective as it is concerned with exploring large volumes of data to determine patterns and trends of information. Preparation of data for loading into data marts and pre-calculation of values to be loaded into OLAP data repositories are usually done here.

Metadata Repository Layer – Data about data is metadata and to take this data well beyond data structure names and formats is the responsibility of this layer. This layer must be comprehensive in scope covering data flowing between the various layers and not to forget transformation and validation rules.

Warehouse Management Layer – Can be considered as a security administrator and responsible for scheduling tasks to build and maintain data in data warehouse and data mart layers.

Application Messaging Layer – Other than transporting information between various layers, this layer encompasses generation and storage of control messages and its communication to the target

Internet/Intranet Layer – Basic data communication, browser based user interfaces, TCP/IP networking are all part of this layer.

Before we wind up this blog series, I wanted to mention some popular analysis models which can help understand the data model of an EDW.

Context diagrams which help outline major business processes are well known. Swim Lane Diagrams which deconstruct business processes and Entity Relationship diagrams(ER) which depict relations between data entities play an important role in developing an enterprise data model. Understanding of data’s business purpose and context helps mitigate the risk of suboptimal data in the warehouse.

Posted by Meena Iyer at 9:06 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Procurement practitioners have been front runners in adopting changing technology for past few years. Tactical savings in time and hence the cost of acquisition was definitely a leading intent behind this adoption. In the process, practitioners have realized that adapting to newer technology does provide huge information visibility and free up a lot of their operational time to think on much critical issues like source selection, supplier rationalization, low cost country sourcing etc. In the upcoming posts I will focus on some of these evolving technological changes and their impact.

Today let’s confer around evolving trends in Sourcing.

Leading technology packages in procurement domain like SAP SRM, Ariba, Oracle iProc, Maximo etc. have been able to bring about a major change in business processes.

Supplier Registration and enablement – Supplier’s can now access any customer and register on their website to show their interest in becoming a supplier. This not only enhances the speed of the registration process but also opens up huge opportunity for customers to tap much wider supplier network without any incremental costs. The technology solutions now come equipped with segregation facilities to sort suppliers based on product categories and initiating automated approval workflows for enabling these suppliers. Of course the cost of supplier evaluation will have to be born as that is more of a technical process applicable to specific industry vertical.

RFx and Auctioning process – Electronic RFx document submission and receiving an electronic response from suppliers’ has been a norm for quite some time for their obvious advantages. This process is getting sophisticated with digital signatures that ensure document safety, project management interface and document storage facilities offered by various product companies. The whole solution not only helps in managing a particular event but also ensures that knowledge captured is stored for any future reference.

In auctioning, hosted v/s owned auction engine models still fight it out tooth and nail though there is a visibly increasing trend towards owning a reverse auction tool to have advantages of increased flexibility and better value proposition. Both RFx as well as Reverse auctions are very important tools in supplier discovery process today.

At the end of RFx or Live auction, creating a local or ERP contract / Purchase order at a click of button is, again, another important functionality that most of the packages offer.

While I completely understand that the above description is an extremely high level overview of the package functionalities in sourcing domain, through my posts going further, I will attempt to deep dive in some of these in order to bring more clarity.

Till then, happy reading. Your comments would be highly appreciated and I will try to fine tune course of this blog to accommodate some of those comments.

Bye till we connect again,

Regards,
Atul Chorbele

Posted by Atul Chorbele at 5:27 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

In the earlier blog I covered the names of the various BI layers and the need for a logical model/data architecture in an enterprise data warehouse.Now let us get into the details.

Let’s go bottom-up starting from the data source layer.

Data source Layer – This layer depends on the source of data . Source could be operational data maintained by an organization’s existing systems or could be external data where data is provided by external sources or non-operational data where the information required by end users is not maintained in a computer accessible format.

Core data warehouse Layer- This is the most granular layer and I will also agree with BI gurus who argue that this layer should hold fully normalized data to give it the much needed flexibility to deal with complex and ever changing business structures. Last but not the least should support historical data , and must have dimensions/attributes with drill up/down/across facilities.

Data Mart Layer – This layer has subsets of information from the core data warehouse layer and is organized to meet needs of particular business units or functional streams and allows users to slice and dice the data .When compared to the normalized warehouse layer , this will involve a fact table connected to de-normalized dimension tables .

Data Staging and Quality Layer- This layer has the responsibility of copying data and transforming it to the data warehouse format and also for quality control .

Data access layer – This layer is between the data staging/quality layer  and the data source layer and helps connect with data stores in the data source layer. This layer is very helpful as it avoids the need to know how exactly the data stores are organized.

I will cover the rest of the layers in my series 3 of 3 blog .

One parting shot -> now that storage capacity is no longer an issue , the ultimate goal should be to have atomic(most granular) data in the warehouse layer as this can be built further up for analysis purposes .Having summarized data at the bottom layer defeats the purpose of analysis.

Posted by Meena Iyer at 9:13 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

As organizations gain experience from the one to one traditional model, they also realize that there are pro's & cons of the one to one model. On the other hand demand for continuous improvement and higher returns from the existing investments is making them explore managed services model.

Managed services model like Platform based BPO are evolving from a confluence of BPO and technology streams. The model brings in synergies from economies of scale in technology deployment and integration. It also provides avenues for human resource optimization by adopting a shared services strategy for service operations.

Catch me on my future posts on Platform based BPO solutions.

Posted by Nitin at 8:50 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Background:

Fundamentally, computers deal with just numbers. Characters are converted to predetermined numbers in order to be stored in the system. For example in the ASCII encoding “A” is stored as 65 (Dec) and “a” as 97 (Dec). As the need to store characters from different languages arose, different forums were formed to create different code pages that would suit their requirement. However, there was no order maintained to ensure that the numbers consumed by characters in other code pages are not reused. Soon there was a mess with different characters being represented by the same number in different code pages and also because of the repetition of some of these characters.

To alleviate the problems associated with data transfer between different encodings or platforms, the Unicode Consortium was formed in 1991 in California, USA. The Unicode Consortium is a non-profit based organization founded to develop, extend and promote use of the Unicode Standard, which specifies the representation of text in modern software products and standards.

Unicode is now an internationally accepted standard that assigns characters from virtually every language and scripts a unique Unicode Scalar Value, which is a number written in hexadecimal notation. Unicode currently defines over 98,000 characters, with room for over 1 million characters. Unicode defines each character only once. Unicode can be used for the system code page, front end and printing.

Unicode Conversion in SAP –

To conduct business in multiple languages in SAP, it was required to deploy the appropriate code page (on versions 4.6c and below). The table TCPDB contains the number of code pages deployed. Each code page can support one or more language. Systems having multiple code pages deployed are referred to as MDMP (Multi Display Multi Programming) systems. In SAP R/3 4.7 SAP introduced the Unicode concept. However SAP continued to support the MDMP installations too. In June 2006 SAP released ERP 6.0 and with this version stopped supporting MDMP altogether, which means that Unicode conversion for such implementations has become mandatory. Single code page systems can continue to operate in ERP 6.0 in a non Unicode environment.

Approaches for Unicode Conversion:
§  Combined Upgrade and Unicode Conversion (CUUC)
§  Twin Upgrade and Unicode Conversion (TUUC)

General Restrictions on conversion to Unicode –

1.    You cannot install a Unicode system with a non-Unicode system in one database (MCOD).
DB2-z/OS: Read SAP Note 1068215 for information about MCOD with Unicode and non-Unicode systems on DB2-z/OS.
2.    SAP Systems which deploy one or more EBCDIC code pages (= code pages with SAP internal numbers < 1000)  cannot be converted to Unicode:
a.    Run transaction SE11 and check if database table TCPDB contains entries < 1000.
b.    If yes, the system must be converted to ASCII first.
3.    SAP Unicode systems are not released for Informix.
4.    Conversion from Unicode to non-Unicode is not possible.
5.    Note the restrictions for Unicode Solution Manager monitoring non-Unicode systems with MaxDB database (SAP Note 924650).

For utilities, asset management is a critical component of business Performance. Utility companies face the challenge of implementing operational and maintenance standards and practices to continually improve the balance between asset reliability and costs. Asset management in Utility has following challenges compared to other industries
- Different operating environments
- Static assets such as overhead cables and poles must be monitored to account for the effects
Of load factors including electrical current, wind, and temperature
- Need of Flexible asset management to optimize core and advanced processes.
- Customer service is an integral part of asset management  for planning outage and schedule maintenance
- Accurate information of asset is essential for improving operational efficiency and customer service. Therefore a new technology such as mobility and Graphical information system becomes integral part of asset management to improve the speed and efficiency of asset maintenance and repair.
- Regulatory requirements and demonstrating compliance is common across the utility sector therefore requires a good asset management
- Stringent safety regulations particularly in case of nuclear power industries

The other major challenges are

- Untimely, expensive equipment failures
- Low utilization and return on capital employed
- Long delays due to availability of resource and Spares
- High costs for production interruptions, Constrained Budget, Higher time to repair
- Mandatory requirements of federal, state and local regulatory authoritie

Success of asset intensive industries, such as utilities directly depends on the reliability and productivity of capital asset deployed. Deployment and Maintenance of this asset means investment. Hence the challenge for asset intensive industry is “maximizing the Returns on Investment (ROI)”.

Meeting the above challenges requires focus on the following list of Business Objectives:
- Reduce CAPEX (CAPital EXpenditure)
- Reduce Time to Market
- Reduce OPEX (Operating Expenditure)
- Increase Asset Utilization
- Improve Health, Safety and Environmental (HS&E) Performance
- Meet regulatory requirements (such as PAS55 (UK)) FERC (US)

Note : We will discuss how EAM SAP can help buisness meet its objetives in next issue of the blog.

Posted by Gopal Krishna at 5:16 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

To deliver effective Business Intelligence , organizations need to progressively design and implement a rugged data warehouse with the right enterprise data flow architecture and not to forget a logical data architecture.

In this 3 part series , I would like to take you through the various layers that encompasses - data sources, core data warehouse, data mart layer, data staging and quality, data access , data preparation, metadata repository layer , warehouse management layer , application messaging layer and also the internet/intranet layer .

Why do we need a logical architecture and is this something that can be designed real quick ? Well, the answer to this is both yes and no.

Typically different parts of large business organizations often deal with different customer ,product, different sets of transactions and so on . So it is needed to logically separate the data model by the different business domains , but the implementation of such a logical model can only take place in a phased manner . This needs to the aligned to the layers of the enterprise data warehouse.

Ultimately , the data architecture needs to be structured to accommodate business needs in the most efficient manner and main factors to consider include entities forming part of these transactions ,hierarchies important to the business and types of transactions the organization engages in.

In the next blog , I would start talking about the layers in detail and lets try and understand how this layer concept also helps in building a good BI governance model and maximize the value an organization derives from its BI Initiatives.

Posted by Meena Iyer at 10:11 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Background..

In today’s world companies are under increasing pressure to reduce costs, meet tougher performance and production targets, comply with regulatory requirements, and maximize return on assets. A new, more collaborative and integrated approach to enterprise asset management (EAM) can yield significant savings and improve the operational performance of asset investments. This new approach spans all phases of the asset life cycle – investment planning, specification, design, asset construction, operations and maintenance, and, ultimately, decommissioning and disposal. It is time to look at asset management in a more holistic and collaborative business context. EAM helps companies manage physical assets – production plants, capital equipment, vehicle fleets, and facilities complexes – over the complete asset life cycle. In conjunction with powerful reporting and analysis, the SAP solutions’ EAM capabilities enable you to reduce operating costs, better manage capital expenditure, and improve asset utilization.

What is EAM?

EAM is the management of all assets owned by a company, based on maximizing the return on investment in the asset

Examples of Asset-Intensive Industries
• Aerospace and defense
• Automotive
• Chemical
• Facilities management
• Government and public sector
• High tech
• Mining
• Petroleum
• Transportation
• Utilities

The Evolution of EAM

Note : The contents are extract from different source.

Posted by Gopal Krishna at 10:09 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

It must be kind of surprising to hear 3 R's in the context of SAP. But it’s true that composite applications and its 3 R’s can transform how clients use SAP to transform their business.In these difficult economic times, what we are looking for is maximum value of the $ investment and here I am adding my 2 cents to it.

The first “R” stands for “REUSE”. Just as reuse of our resources in nature helps preserve our environment. Composite applications promote reuse of technology assets in business environment.  Normally, organizations have a mix of both SAP specific and Non-SAP cherry picked applications in their IT landscape. These don’t communicate to each other easily and the challenge is  to bring them together and reuse them to support newer business models, divisional and regional requirements.

The Second “R” stands for “Refurbish”. As in a normal life scenario, we try to maximize money’s worth, in business it is sometimes more beneficial for an organization to go for incremental enhancement rather than outright change. Change in business requirements does not necessarily mean that you have to start afresh, with composite application on your side, existing systems can be refurbished or incrementally enhanced with extra features  to support change in business requirements.

And this brings us to the third “R” which stands for “Revitalizing” the IT environment. Revitalizing is all about rejuvenating and bringing fresh perspective to any situation.  And composite applications does  exactly that. Now businesses do not have to play by the rules set by technology. Organizations can orchestrate, monitor and analyze their "own" processes.

And all of the above make equal sense whether you already have upgraded to new mySAP release or you are evaluating to upgrade to new mySAP environment.

Catch me on my future blogs to discuss more on how new releases of SAP NetWeaver, mySAP and eSOA are supporting to achieve 3 R’s of Green SAP.

Posted by Ashish Tewary at 10:06 AM | Permalink | Comments ( 1 ) | TrackBacks ( 0 )