Category: SAP hints

SAP Solution Manager – More Than Just SAP Marketing?

As its name suggests, the SAP Solution Manager is designed to provide support for the management of SAP customer implementations. Does it perform this task? Or is it just one of SAP´s marketing instruments?

Missing Functions for Complex System Landscapes
When discussing the pros and cons of SAP Solution Manager, we must first of all give SAP credit for being one of the few vendors providing a solution management platform at all.

But taking a closer look at the various components of SAP Solution Manager, what you see is rather some kind of patch work. It seems that many functions have been integrated just pro forma to comply with qualifications typically demanded by the market in RFPs (request for proposal)?

Some of the components, though existing, are only in parts or insufficiently integrated. In order to efficiently manage customer implementations, additional office solutions are needed. This, however, seems to be useful only for small-scale SAP implementations. More complex organizational structures or heterogenous SAP landscapes imply additional dependencies that prevent these solutions from answering the purpose.

Unfortunately, in many SAP Solution Manager implementations the focus is not on what the customer actually requires, but on those functions offered by SAP Solution Manager by default.

Expectation towards an Efficiently Working SAP Solution Management Platform
Much of what we expect from a SAP solution management is comparable to what a comprehensive application lifecycle platform would offer. It is particularly important that the complete service lifecycle of the SAP implementation can be managed, including all documentary, organizational and technical interdependences, covering all phases from the generation of the first process implementations to extensions and error recovery, and up to process deactivation.

Also, the complete cost and activity accounting (integrated financial management) should be made transparent all across the lifecycle of the solution. This is the only way to set up a cost-benefit equation for a customer implementation.

The structure of the solution should provide subdivisions according to the Business Services (BS) it supports so that these services can be aligned with the overall goal of the enterprise. This results in an effective service portfolio management (SPM) and ensures the targeted value of the implementation. A working service portfolio management makes evident that in the context of a consistent service orientation, IT service management (ITSM) and project portfolio management (PPM) can no longer be regarded as isolated elements.

In addition, advanced solution management applications should integrate consistency-ensuring measures directly into the processes in order to minimize risks. Wherever possible, automation should be favored, particularly for performing organizational tasks. This can be reached by digitization or coding.

The following example clarifies above statement. Digitization prevents overtaker problems during transports (consistency-ensuring measures), because the transports are directly carried out (automation) upon release (organizational task).

By the way: consistency-ensuring measures are particularly important for SAP customers using company templates when changes are transported: Applying Business Configuration Sets (BC Sets) or generally transporting SAP customizing changes can result in inconsistencies between templates and distributed implementations, because customizing of the involved systems can be changed at any time. Offering customizing synchronization and locking mechanisms, SAP Solution Manager provides a solution for this problem which unfortunately is not very well known.

Summary
It is crucial to success that the customer has a clear picture of all relevant IT processes involved in SAP solution management. This means that the focus must not be on the solution management tool, but on the risks that are addressed and minimized by Solution Manager. From this, we can directly derive the demands that should be placed on solution management.

July 28, 2008
Software Archeology – how to Successfully Change SAP Releases

16th century. The eyes of an archeologist are scanning a field. He is asking himself where he should start digging. In his life, he still has a few years left. Which area would, from his experience, hold a chance for him to make a discovery? Then he notices a tree. For growing, it would need nutrients, so underneath there might be something. This is what he knows from experience.

When he starts digging, he hits on a small house of a rather poor family. Disappointed, he gives up.
200 years later, a larger excavation project is started. The settlement is found to be the most important source of information about ancient times.

SAP
Those who know me are acquainted with my writing style exposing my affinity to exaggerate. Let´s take a typical SAP project, a release upgrade, for example. Doesn´t differ that much from the story of the unlucky archeologist, I think. In the beginning, you often know little about a system. Everything seems to be underground. You are asking yourself how to address the release change, and on the basis of which information you might dare a prognosis. What will happen during the project? If you are lucky, the consultant experts have a fair knowledge of the system and the processes implemented on them. If not, the project will almost typically go beyond its scope on the two axes expenditure of time and budget planning. As some of the most important project phases, such as testing and training of the end user, are neglected in favour of the implementation phase, you will be faced with a quality problem. This, in turn, will have an impact on the third axis, the user acceptance.

The way out
Typical SAP projects, such as upgrades, are planned according to the waterfall principle. But one important step of this method is massively neglected: The requirements analysis, also known as gap analysis – in other words, the question, „How did SAP influence OUR particular standard?” If you want to comprehensively answer this simple question with reference to a SAP landscape, the only solution to the “problem” of such massive analysis is its automation.

How can you access best quality and complete information in the shortest possible time?
There are quite a number of vendors who offer analysis tools, from SAP Consulting via RBE up to IntelliCorp. Each of these tools focuses on a particular aspect and therefore has its individual potency.

IntelliCorp´s Assessor Template for SAP Upgrades addresses the problem on a rather broad basis. The tool offers a variety of fully automated analysis workflows. Within a few days, three on average, it provides a wide range of material for use in the context of a detailed planning of the upgrade project. As a side-effect, the result provides a basis for the implementation team to operate on. Its high degree of flexibility makes it a tool which is suitable for all SAP applications, including commercial solutions, integration of third-party software or own namespaces in workbench.

About the author: Fritz Mosonyi is senior consultant and division manager for SAP tools at beteo partner SPP Wien.

June 30, 2008
Configuration Management for SAP Customizing?
A comprehensive configuration management is the most important basis of SAP Change and Transport Management. For ABAP code, this is accepted as general practice and supported by suitable tools. But how about configuration management for SAP customizing?

From our experience, the major part of changes transported across a SAP system landscape are customizing changes. Not surprisingly, the persons responsible for change and transport management often keep struggling with problems after roll-outs for lack of consistently applied configuration management for_these objects. A consistent change and distribution of customizing requires stringent configuration management.
Crucial to a cross-enterprise use and protection of SAP templates is that central and local objects are well documented, comprising all versions of their lifecycle up to the newest version.

Comprehensive SAP configuration management all across the SAP landscape is meant to ensure overall integrity of the objects involved in SAP development, including ABAP as well as non-ABAP objects:
- The use of well-defined standardized naming conventions clearly reveals to which organizations, areas and projects the objects belong.
- All changes to objects, including individual customizing settings, are documented. At any time, it is obvious who is – and at which times – the owner of settings, who is entitled to make and has made changes and for which reason. This allows the changes to be tracked afterwards, which is an equivalent to versioning.
- The documentation also includes the information as to who and what and who depends from a defined customizing setting. This is an integral factor of reasonable impact management.
In the context of each change to the SAP landscape systems, it must be made sure that the rules listed above for practicing a comprehensive SAP configuration management are observed. This, again, requires a strict organization of the change und transport management. Naming conventions for transport objects and transports must be established, transport packages must be grouped according to their content, organizational and technical processes must be clearly defined and adhered to.

Some projects are highly dependent on a consistent comprehensive SAP configuration management. Without this, very often the challenges to enterprise SAP organizations can hardly be mastered, especially in the context of mergers and acquisitions, strategic outsourcing projects, insourcing, and regional or global consolidations of systems. This is also true for customizing changes. However, a solid foundation as outlined above allows such projects to planned and implemented with reasonable effort and fair success. Also customizing changes of several systems can be consolidated without a negative impact.

In addition, a comprehensive SAP configuration management allows you to permanently record the data related to transports, to the transported objects and to the result of the transport, and to evaluate them. This is comparable to using suitable analyzing tools, such as the one offered by Prospero, which have been designed to disclose the causes of problems in SAP logistic processes, or even to give a prognosis concerning their results. The same is achieved by using SAP change management data for the transport of SAP changes. In any case, SAP change and transport management has still plenty of room for improvement in complex SAP landscapes.

Summary
Applying a wide-ranging SAP configuration management has turned out to be the most effective method to ensure a consistent and efficient SAP change and transport management and a consistent customizing across the SAP system landscape.

Unfortunately, the opportunity for global enterprises using large SAP systems to improve the quality and to save costs by investing in SAP change and transport management is very often not seized, because it is thought to be technically complex. But if the challenge is taken up it soon shows that the problems are more political or company-related than of a technical nature.
June 27, 2008
SAP Change and Transport Management – Efficient and Safe
In order to handle the various problems resulting from changes to a SAP landscape, it is common use to spend of lot of money on experts rushing to fix them. But there is a better alternative: Focussing on a tool-supported, automated SAP change and transport management environment, including measures to ensure consistency, can eliminate the cause of the failures once and for all. There is a couple of measures to be taken: organizational measures, technical transport validation, and consistency-ensuring measures with horizontal and vertical effects.

Basic Organizational Measures
- Definition, digitalization of the end-to-end transport process or of the whole change process
  - ensuring that no transport request (technical change) is issued without change request (organizational change)
  - diversification of the transport types so that for projects and releases the suitable transport can be selected
- Replacing manual execution by automatic technical implementations
  - no inconsistencies due to missing and/or incorrect interactions
  - release processes are validated, executed and documented
  - tedious routine tasks are automated
- Also operational customizing must be subject to a controlled change management process.
- Creating development guidelines and naming conventions to support change and transport management
  - changes can be checked for consistency with respect to form and – in parts – content
- Definition of a company template – particularly useful if there are more than one development client
  - centrally and company-wide implemented customizing settings can be protected
Validation of Transports
- Early detection and exclusion of risky objects from transport, e.g. NRIV objects (SAP number ranges)
- Formal validation of the transport objects with regard to project/support release and organizational unit they belong to
  - ensuring that a transport request contains only related changes or changes for specific areas so that parallel project activities are not compromised
  - code inspection based on system engineering, validation of the transport object´s affiliation
  - ensuring that the development guidelines are followed and verifying – on the basis of naming conventions – that the code is related to one single business area
- Verifying, for example by running test imports, if all referenced objects which are not yet on the target system are transported
- Object-related customizing documentation such as owner, change, changed keys, including customizing versioning
  - complete documentation, complete history (comprehensive life cycle of the customizing settings), traceability and audit trail
General Consistency Measures
- Content-related division of transport requests of multiple projects or maintenance requests
  - consistent, project-oriented deployment; interdependencies of objects are understood, taken into account and controlled
  - autonomy of projects in terms of change transport
- Opening and closing of the systems and clients should – whenever possible – be subject to an automated change process
  - system-based monitoring of the change; it can be tracked at any time, when system changes were possible.
Horizontal Consistency-Ensuring Measures
- Ensuring the correct sequence when transporting customizing changes, workbench transport objects (programs and data structures), considering dependencies between workbench and customizing objects with regard to overtaking issues.
  - No inconsistencies on target systems resulting from early arrival of objects (overtaker issues)
- Rollback functionalities and automated updating of systems and clients based on transport history (system or client copy) when systems are re-initialized, added or when changes need to be reset.
  - Full transparency as to which transport orders apply to which system or client level. Executed transport orders can be undone at any time when unexpected problem show up or lests are not successful.
Vertical Consistency-Ensuring Measures
- Ensuring the correct installation order of all changes (transport requests from all SAP component systems such as SAP CRM, ERP, BW for ABAP and customizing, Java packages, portal configurations) before they are further processed on the target system. This includes all changes that have to be installed together, not by themselves via different SAP Transport Systems (SAP TMS).
  - all changes belonging to a group are completely installed before the next organizational step is released
- Synchronizing and locking of company template customizing
  - no inconsistent company templates in target system landscapes
  - vertical distribution of these settings to all SAP component systems
Summary
Many big SAP organizations still practice a reactive method of solving the problems resulting from change transport. The enormous costs seem to be accepted as inherent to the process. But we have seen that applying a clean automated process including consistency-ensuring measures can save a lot of money and puts aside large parts of the work involved.

Interestingly, not the unnecessary and incalculable costs and effort motivate more and more enterprises to improve their SAP change and transport management, but the requirements which result from compliance rules and which, SAP IT, too, is faced with. Thanks to the transparency and traceability of the processes and to comprehensive documentation, SAP change and transport management, if stringently applied and supported by suitable tools, will supply these needs on the fly.
June 12, 2008

beteo SAP Change Control Miniguide

The new SAP Change Control Miniguide below has just been posted on our beteo website. Additions and feedback are welcome!

SAP Change and Transport Management Tools

Product	Vendor	Modules
Conigma Suite	Galileo Group	Change and Transport Management
Newmerix Automate!	newmerix	Change and Transport Management
PPM	HP	Change and Transport Management
Rev-Trac	Revelation	Change and Transport Management
SAP Solution Manager	SAP	Change and Transport Management
TransportManager	REALTECH	Change and Transport Management

Additional ALM information

June 11, 2008

Put your mind at ease even when SAP support packs roll out
Typical Situation
Installing SAP support packs is always quite a challenge. Which parts of the SAP-supported business processes are really affected? What exactly should be tested? Are there any own developments affected? What is the amount of resources required for testing and interventions? These are just some of the possible questions. Unfortunately, they normally can not even be answered so that in practice, the only secure option is “to test everything”. The effort involved in that, however, would be simply impracticable.

Experience
What does “testing everything” actually mean? All processes? All system components? Who has got a list of them? One of the most frequent answers to these questions by SAP operators is “Our key users will know”. To put it bluntly, this is what the usual quality assurance process will be like: The SAP base team installs the packages on the test system, sends an e-mail to all key users on Monday morning asking them to do the testing with the additional remark “if we don´t hear from you by Friday noon, we assume that everything went fine, and will go live.” The result of this approach is well-known.

Future
Is it acceptable that the SAP Competence Center as an enterprise service provider confers the task of quality assurance in the installation of support packages completely upon the user, it’s customer? This would mean that the key users are those who are responsible, the quality assurance process is no longer under control. It can neither be monitored nor measured. It is not surprising that public accountants and auditors focus more and more on this process and its documentation.

A Solution
How can the individual change management process be smoothly and cost-effectively implemented? A possible solution includes two main elements:
1. Step-by-step introduction of a tool-based quality assurance process for installing support packs: the existing QA process is extended step by step, each resulting in a visible benefit.
2. Automation: This includes not only the automation of test execution, but spans the whole cycle of digitalization and automation of the entire change management process, from the tool-supported impact analysis over the selection of the packages to be installed up to the generating of test cases to be executed, including possible troubleshooting.
Summary
Introducing targeted test execution for the installation of SAP support packs, the people in business and IT can put their minds at ease and, additionally, a lot of money can be saved: Subsequent to the installation of the support packs, the system availability will be much higher and stressful interventions will be reduced.

It is crucial to a successful introduction to continuously keep in mind the whole quality assurance process. With every single improvement, for example the introduction of an impact and risk analysis, it must be asked if in practice there is someone to carry it into execution and if it can be smoothly integrated into the QA process. Provided that these requirements are met, the results will de facto be applied, the expected benefit will be seen, and the processes will be monitored by accompanying measures, not only because of ITIL.

To overcome the technical difficulties involved in SAP risk and impact analysis, there are some useful tools available. The Intelli Corp´s Live Compare with the Assessor Support Pack Template, for example, has proved to be a flexible solution. In the process of support pack QA, these tools allow for a seamless integration with SAP, SAP Solution Manager, and prevalent testing tools such as HP Quality Center.

About the author: Fritz Mosonyi is senior consultant and division manager for SAP tools at beteo partner SPP Wien.
April 1, 2008
SAP Templates Consolidation – It’s Well Worth the Project

Template Protection across System Landscapes

In large SAP system landscapes, there will always be inconsistency between the systems through local changes in the course of the lifecycle of SAP applications. This may stir up a lot of trouble for SAP users. SAP Solution Manager, applied professionally, can avoid this. It reduces costs and time expended on interventions – and the responsible people can put their minds at ease. The approach to a protection of SAP Templates by the use of SAP Solution Manager all across a system landscape is described in the blog “SAP Template Distribution – A One Way Street”.

But before company templates on systems in use can be protected, it will be necessary to free them from inconsistency across the different system landscapes. A really company-wide template will hate to be created, one that in fact deserves this name. Without an effective template protection, it is often the very first cross-system roll-out which is accountable for inconsistency, caused by local system changes. So before giving some thoughts to the protection of templates, a general template worth being protected needs to be created – a consistent company-wide SAP template consolidated across systems.

How to proceed

With the help of the IntelliCorp and SAP Solution Manager tools, the procedure is as follows:

First, with the help of IntelliCorp IntelliCorp LiveCompare, all systems of the SAP landscapes are examined for inconstistency in the rolled-out templates. The aim is to identify and document all duplications caused by changes and all occurrences of inconsistency across the systems. This allows measures to be developed for the creation and management of an integrative company template, and all change management and roll-out processes involved, including template protection, to be defined and planned.

The next step is to use Solution Manager for realization of these measures. The “real” company template is now defined and implemented as Corporate Template. Subsequently, there will be no possibility to locally change templates that are implemented on the systems.

Summary

In large SAP environments, the roll-out of changes across the system landscape is continuously causing inconsistency between the system templates currently in use. This result is large-scale additional expenses for elimination of faults and quality deficiencies created by the rolling-out of changes. Instead of accepting these problems as inevitable facts, suitable measures and tools can ensure that they cease to exist. This effort is worthwhile and affects areas far beyond IT.

The results from the introduction of protected SAP company templates are very encouraging. They usually allow templates to be beneficially refined and extended later on.

By evaluating the insights gained from the template system analysis, also company-wide customizing tasks can be consolidated. For all SAP objects it can be defined, if and in which way they are – centrally or locally – changed. This is a further step in the direction of a consistent SAP Change and Transport Management all across the system landscape.

March 13, 2008
SAP Process Testing – Gaps to be Closed

Theory says that in order for effective business process testing to be done, testing requirements should already be deduced in the requirement’s phase of the software development lifecycle (SDLC). But do SAP users consistently test all the processes that are impacted by changes? Despite obvious consequences, this is hardly ever done.

Process models are not up-to-date
Many SAP users do not take the effort to document their business processes in order to derive quality measures and test definitions. But even when this is done, the focus of the projects is on developing a running system, and the process documentation is not maintained during the projects and are not up-to-date.

When changes are handed over to IT operations, the routine of consistently testing all of the processes to see what is impacted by a change is extremely difficult and time-consuming. Because the link between change and processes is not currently documented, the only choice would be a complete test of all business processes. Hence, if at all, processes are only partially tested. Process testing gets marked as completed just because of the lack of prerequisites for such quality measures. Consequences are fatal. Working systems using the same programs or customizations, suddenly behave differently. Components of homogeneous, but even more so for heterogeneous SAP systems, report errors or stop working.

It is just too laborious, too complex, and is not system supported to completely document systems from the technical objects up to the process level. After some time it becomes nearly impossible to understand why a process has changed or is implemented in a specific way. Developers in new projects, as well as maintenance programmers, are priority driven by their immediate project goals. Long-term system goals for maintainability of the overall application lifecycle are secondary at best.

Business Process Lifecycle Management
Understanding over time why and how processes have changed in a specific way is too hard. In SAP development methodology, a typical SAP Business Blueprint and SAP process model do not care whether individual processes that need delivered or already exist should be changed or be newly developed. Because it is not distinguished in such a way, it is not possible at this point in time to derive which processes were impacted from a change. Because of this, properly defining what the testing requirements should be becomes impossible. The prerequisites for a complete test will be missing later.

This is not only true for new development. The same drawback exists with support and maintenance programming and disciplines in IT Service Management(ITSM). There is no reference of changes to process objects in their lifecycle.

Projects need to maintain a sustainable lifecycle management for processes. At any time, it is comprehensible which version of a process was caused by which development project or service request, including what objects were impacted in which way. Consequences for later stage process testing in this way are identified early on so testing can be planned properly.

The ideal SAP system initializes business processes with the first project. Every new project or service request, roll-ins, roll-outs, enhancements, or bug fix impacting the business process, generates a new version of it, with proper test requirements that are included and comprehensible.

Conclusion
In order to not let SAP process testing just be a pretense, it is a must that process documentation is maintained throughout all phases of the development cycle by new projects as well as maintenance activities. It needs to be part of the IT organization’s application lifecycle discipline. It is only in this way that the impact of projects on business processes can be understood and business process test requirements can be defined and used for proper SAP testing.

January 16, 2008

SAP Search Guide

Searching the right information in the SAP information jungle can be quite time consuming. This guide is intended to help to SAP professionals to quickly find answers to typical questions on the internet. For each proposed search starting point prerequisites as well as an estimate for the time needed to find the solution are listed.This list for sure does not claim to be complete, so it does not reflect information needs specific to versions of SAP.

	Problem	Source, Categorie	Requi- rements	Search start	Procedure / Comment
General / Naming	What does SAP stands for?	Wikipedia	–	SAP AG SAP ERP	About the company and its products
	What is SAP talking about?	Terms, Definitions	– –	German English
	What stands this abbreviation for?	Acronyms, Abbreviations	–	SAP Designguild	The most important.
	Was this product renamed?	Naming	–	n/a	Will be my next Blog!
Education	Does SAP offer a course on this topic?	Education	S-User*	SAP Education Catalog
	When and where the next TechEd is planed?	TechEd	–	SAP Events	Apply > participate > Overview on future products and solutions
	Does SAP has CBTs (Computer based Trainings)?	eLearning	–	SDN eLearning	Select product in the catalog.
	Can i find a book on this topic?	SAP Press usw.	–	SAPPress Amazon
Releases	When will the next version released?	Product Availability Matrix	S-User*	PAM	Select product
	On what product do I have to count on in next time?	Special PAM Tabelle	S-User*	PAM Tabelle	Sort for Availability
	Timeline for ServicePacks?	Servicepack Stack Schedule	S-User*	SP Schedule	Use Link on products for details.
	What’s the difference between two SAP ERP Releases?	ERP Solution Browser	–	Solutionbrowser	Source-, Targetrelease and Solution area.
	Is my product still supported?	Special PAM Tabelle	S-User*	PAM Tabelle
KBase / Solutions	How to install a SAP product?	Installation documentation	S-User*	Installation Guides	Read the hole document incl. links on SAP Notes!
	How to configure a SAP product?	SAP Help	–	SAP Help	Select product (version) > Search > (follow the postinstallation configuration)
	Where to find the solution to a technical problem?		– S-User* – –	SDN SAP Notes SAPFANS SDN Wiki	According to experience: SDN > SAP Notes > Google > SAPFANS > SAPTechies Important: Check for notes to optimice your search!
	Who can answer a technical question?	Depose a problem	S-User, License SDN-User	OSS SDN	Slowly but surely. Faster but without guaranty for success
	Who can deliver a SAP solution?	SAP partners Search	–	Switzerland
	If all else fails!	ultimo ratio			079 447 xx xx Website
Design	How to design a SAP applications?	UI Design Resources	–	SAP Designguild
Design	Where do I get original SAP icons?	SAP Icon Library	–	SAP Designguild

* To access http://service.sap.com/ a SAP S-User is needed. Alternative a C- or I-User works of course too.
** SDN user needed. Free subscription possible on http://sdn.sap.com/. Alternative the logon works with the S-User*.
*** For product support you need an SLA with SAP.

November 22, 2007

SAP Template Distribution – a One Way Street?

Inconsistent customization settings – a typical issue of decentral SAP systems
Large SAP installations with multiple decentral system landscapes struggle to keep SAP customization settings consistent across the company. Conventional approaches , e.g. SAP Template Customization, to distribute templates lead inevitably to inconsistencies. Maintaining a consistent system requires extraodinary effort.

Conventional SAP company template roll-out
In most SAP installations central customization assures the integrity of SAP’s overall company structure. It is built and maintained on a central SAP template customization client. From there it is transported to different decentral customization development systems.

SAP company templates transported in such a way get activated on the multiple decentral customization clients. Locally enriched by further customization templates get finally transported by the transport management system (called TMS or CTS) into decentral system landscapes.

It is obvious that with such a procedure decentral customization changes risk to be applied to customization that was configured in the centrally managed company template. The consequence then is an inconsistency between the central and decentral template.

It is difficult to get this under control with organizational measures since there is no technical support to alert autonomous decentral developers when changing centrally configured items.

Further updates made to the central SAP company template then just cannot be activated on the decentral systems anymore. After being transported to the decentral system landscapes they potentially overwrite decentral customization. To still adopt changes from the central SAP company template requires extraordinary efforts and inconsistences are more predictable.

By the way: In contrast to the roll-out of customization the deployment of SAP ABAP development objects is handled without any problems by most large SAP users. Organizational measures are sufficiently assuring the quality of this process.

SAP Company Template Protection with SAP Solution Manager
It is not common knowledge that above problem with inconsistencies can be cured with system support from SAP. SAP Solution Manager can be used for this purpose. Correctly configured it can prevent developers from overwriting central template adaptations when they locally modify decentral system landscapes. A very effective automated quality assurance measure. The central customization gets protected on the decentral systems. The overall system configuration remains consistent!

This quality assurance measure for the roll-out of SAP company templates by SAP Solution Manager can be introduced even after multiple central and decentral modifications and roll-outs. A quality measure highly welcome to any SAP IT managers who know what it means to suffer from template inconsistencies. They normally have a good understanding of what it needs to reactively get rid of them!

November 8, 2007