Based upon our experiences with projects using various PPM tools, we took the liberty of comparing two project portfolio management heavyweights, namely CA Clarity PPM v12 and HP PPM Center 7.5.

When it comes to project controlling and project management, CA Clarity PPM and HP PPM offer the traditional multi-project and project management functions as a complement to tools such as MS Project or in standalone mode. Open and flexible interfaces to peripheral systems as well as additional standard interfaces to project management systems established on the market, such as Microsoft Project, are included in both products.

Support for project planning and project prioritization for an innovation process that is superordinate to the projects is provided in the tools as a standard feature and best practice processes for it are included.

Both manufacturers offer a workflow engine with which these processes can be converted into digitized workflows corresponding to the requirements. The workflow engine interfaces for administrators are quite different at the first glance. Defining workflows initially seems simpler in HP PPM because the individual steps are arranged graphically on the screen and then, similar as with CA Clarity PPM, they have to be defined in detail. The user’s view of the workflow to graphically depict where the workflow is located in the process is more appealing in HP PPM.

Generally, the CA Clarity PPM’s user interface is more contemporary. In order to use the drill-down feature from the Clarity PPM dashboard graphics, one must first install the Adobe SVG Viewer that is available free of charge; this is not necessary for HP PPM.

Both products offer dashboard functionalities with drill-down capability based on portlet technologies and largely adjustable interfaces. In this way, both products can be completely customized and expanded to one’s own needs and preferred usage.

In addition, both products offer functionalities that, in addition to tactically provided budgets and resource allotments, also allow a strategic alignment to higher-level business objectives.

Here is where the actual approach-related differences emerge in regard to supporting accompanying business processes such as resource, time, and financial management as well as comprehensive innovation management within the company.

CA Clarity PPM v12

CA Clarity PPM offers functionalities from idea-related decision-making to prioritization and analysis, taking into consideration existing resource allocations and a diverse range of budgetary perspectives. In the tool itself, one can carry out both strategic as well as tactical planning, including execution and controlling management for single or multiple projects, in a flexible manner.

The modular setup of the functional components allows the system to be optimally fitted to an organization’s level of maturity in terms of project planning and management. Extensive functions for graphic workflows, collaboration, and document management round off the tool’s functionality.

CA Clarity Dashboard

CA Clarity PPM offers standard interfaces to:

• Microsoft Project, OWB (Open WorkBench)
• CA Unicenter Service Desk, CA Software Change Manager, and CA Unicenter Asset Portfolio Management

Features and requirements that favor using CA Clarity PPM

• Detailed cost control by defining cost plans
• Scenarios at project- and department-levels pertaining to resources and working with cost plan variants
• Supplier management functions
• Direct charging and billing (internally and externally) for projects stemming from a single point of control application
• Portfolio-related scenario staging based on various cost-benefit plans in addition to resource requirements
• Parent / child relationships for master and department portfolios and organizational structure-related portfolios/programs
• Integratability into existing CA products

HP PPM Center 7.5

HP PPMC also offers functions to strategically analyze and tactically plan future projects. In doing so, HP PPM places greater emphasis on project controlling aspects to manage the project portfolio of an individual business unit.

The functions pertaining to supplier, resource, time, and especially financial management are limited. If necessary, these can be covered by the integration of third-party solutions on hand in the company.

By means of an integration platform, the HP PPM product is easily integrated into the HP BTO software portfolio. Interfaces allow one to deploy HP Quality Center and HP uCMDB for example directly from the workflows.

HP PPM dashboard

HP PPM V7.5 offers standard interfaces to:

• Microsoft Project
• HP Service Manager (HP SM), HP Universal CMDB (HP uCMDB), and HP Quality Center (HP QC)
• SAP CTS (SAP Change and Transport Management)

Features and requirements that favor using HP PPM

• Portfolio management field exclusively in the focus of an (IT) organizational department
• Use of “leading” human resource, financial, and controlling peripheral systems
• No planned enterprise portfolio management (EPM) activities
• No billing for projects stemming from the PPM system, but stemming from the “leading” financial application
• Integratability into existing HP BTO products
• Existing use of HP PPM as the application deployment system, e.g., Oracle Applications, SAP, and Peoplesoft, as well as the need for interfaces to these

Clarity PPM vs. HP PPM Comparison

Generally, CA Clarity PPM and HP PPM are suited for use as project portfolio management solutions. Business-related factors or a preference for a given manufacturer therefore play an important role in the decision. Nevertheless, one of the two solutions can be objectively favored based on a company’s detailed requirements.

• Requirements for a comprehensive portfolio management tool, including integrated aspects such as financial and resource planning, as well as company-wide deployment are arguments for CA Clarity PPM.
• Requirements for a project portfolio management tool for project controlling within a department or company-wide, then integrated into leading financial, resource, and planning tools make HP PPM a viable alternative.

Actual practice has shown that one can work successfully with both tools. Successful implementation of a software-based PPM solution depends less on the individual strengths and weaknesses of the PPM software, and more on how the workflows of the individual organizations are depicted, how the applications are integrated into the environment, and what implementation approach is selected.

HP Service Manager is used to administer and process tickets within the framework of IT Service Management. The Service Manager adheres to ITIL V3. Various modules are used, such as incident, problem, change, etc. With the ESS (Employee Self Service) Web control surface, end users can issue their own interaction tickets, which a support technician can then use to open an incident. If no solution is found, the  Service Desk can transfer incidents and interaction tickets as well as track problems and changes.

HP Service Manager shows limits with Change Management

Simplified workflows are certainly possible with Service Manager. However if comprehensive Change Management is in operation, requirements exceed conventional ITIL functionalities. The administration of all relevant objects is of utmost importance. Information about infrastructure as well as about organizational (organizational units, roles, security aspects, etc.), technical (programs, change requests, transactions, etc.), and descriptive (documentation, concepts, test cases, etc.) objects – and their relationships – should be represented. This is beyond the scope of HP Service Manager. As soon as requirements increase and greater flexibility is needed, a tool such as the HP Project and Portfolio Management Center (PPM) is necessary. PPM provides extremely powerful workflow controls with a variety interfaces to additional tools and to the Service Manager. In addition, PPM allows control of any number of commands to be performed and external Web services to be controlled. This allows for example control of SAP transports, administration of Quality Center (QC) requirements and defects as well as an additional configuration database, such as HP UCMDB, to be updated. Compared to more technically mature PPM workflow controls, Service Manager demonstrates significant weaknesses in flexible administration and process configuration.

By integrating the change process into PPM, a change request issued in the Service Manager – in which no longer just the Service Desk but also other teams, tools, and processes are integrated and a broad range of decisions for controlling the change process are required – can be transferred to PPM. Because processes in PPM can be better and more flexibly modeled, the change process is completely administered through PPM. A change ticket in the Service Manager still receives only the requested status updates so that the Service Desk knows for example that a development has been launched or that a change is being tested and nearly complete. Users are continuously informed of status.

Integration change process: PPM-Service Manager

Integration with HP PPM

Through a PPM add-on called MAC (Managing Application Change), integration of different tools is possible. Necessary Java classes and configuration examples are provided during installation. All communication between PPM and Service Manager is based on the Web service interface in the Service Manager.

First of all, the Web service for the requested module must be configured in the Service Manager, in our case Change Management. When all necessary fields as well as any number fields and functions are available through the Web service, the Java stub for PPM can be produced from the Service Manager WSDL file. Through this stub, PPM can communicate with the Service Manager. Of course it is also possible to access the Service Manager from PPM or any other Web service.

At a determined interval, PPM searches the Service Manager to determine is a new change has been opened. This change is then fetched and opened in PPM as a new request. It is also possible to send status updates to the Service Manager, thereby informing the Service Desk about the progress of the process. When the process is complete, the same interface is used to send the message back to the Service Manager and close the change.

Conclusion

Service Manager workflow controls are not sufficient for implementing and automating a comprehensive change process from start to finish, for example test management in QC, expanded configuration management in the uCMDB, or transport administration in SAP.  However the possibilities are open upon integration of the change process into PPM. Configuration necessary to integrate the tools is nonetheless somewhat complex: the stub must by newly constructed as soon as the configuration of the Web service has been changed, mapping of fields takes place through JavaScript code and without a configuration control surface, time formats must be correctly converted, files must be repeatedly deleted, a small mistake results in the entire integration not functioning … In summary, integration appears to remain rather underdeveloped, and experience is necessary to achieve successful and efficient implementation.

However, when integration runs as desired, and all fields are correctly copied and converted, its usefulness is enormous. The most diverse processes are thoroughly integrated: from issuing tickets by end users and development to testing and deployment. This also includes dashboards, notifications, and reports that can be flexibly and process- as well as project-comprehensive generated, administered, and customized. Every participant stays informed, and changes to systems are controlled and thus implemented with lower  risk.

The most recent Forrester Wave (Q3 2008) examined the six biggest developers of functional testing solutions. Based on the current offer and the strategy regarding the direction the corresponding solution is to take, HP was ranked number one and IBM came in second. It’s time to take a closer look at the current flagship products and compare them against each other.

In the red corner of the ring, representing IBM, please welcome Rational Quality Manager Standard Edition (version 1.002) and in the white corner, representing HP, please welcome Quality Center 10.0 (Enterprise Edition). In this bout, the current world champion Quality Center (QC) will be defending its title against the challenger Quality Manager (QM) with the fearsome left hook in the area of “look and feel” as well as in the key discipline of “range of functions.”

Appearance – Playfulness vs. Solidity

Both solutions are opened using a URL in the browser. Here, Quality Center (QC) 10 still depends on Active-X, which has been deactivated in many companies and for that reason usually has to be distributed as an additional package to the clients. Quality Manager (QM) doesn’t face this obstacle and therefore runs perfectly, including in Firefox.

Once accessed, QC and QM have very clearly laid out appearances. In QM, one always starts on a personal dashboard. This dashboard is very easy to configure and looks good, too. As described in the blog entitled HP Quality Center 10 from a Test Manager’s Perspective, the QC 10 also offers an integrated dashboard which has a similar range of functions as QM’s.

One navigates through both test suites using a vertical icon bar, which can be masked in the QC and arranged horizontally as an option in the QM. Overall, QM seems faster and more modern, more dynamic, and more interactive, whereby QC seems more plain and professional. QC can’t be changed much, with most of it controlled by means of lists and parameters and a little VBScript. On the other hand, QM can be totally reconfigured and adjusted to the n^th degree in regard to a company’s internal workflows. If QM has more of a Facebook look and feel, then QC would be more like Xing; that’s why descriptions like playful versus grounded are apt.

Range of Functions

The getting-started hurdle for new testing solutions is high. In order to come close or beat the industry champion Quality Center, special moves are called for right in the first release. So what does Quality Manager include in its first release to take on QC?

It would be best for us to compare the individual mini-modules/functions that are needed in day-to-day work in a table to then pick out the corresponding winner:

Legend:
0 = Functionality/mini-module not available
1 = Functionality/mini-module available
2 = Functionality/mini-module better than the competitor's
3 = Functionality/mini-module is very good
* = proved stability and scalability (QC) /
    modern web 2.0 interface without Active-X (QM)

In my opinion, the primary difference pertains to QM’s interactive test plan (planning), which QC lacks. The test plan should in no way be confused with the Quality Center’s test plan module. This is a bona fide test plan that is jointly generated through the distribution of work items (generally by the test manager). Individual items, such as requirements, test cases, or assembling corresponding test teams can be delegated to other QM users by means of work items. The test managers in charge can monitor progress at any time via the dashboard, making it ideal for offshore projects!

QM’s test environment management, which is not available in QC, is also pretty neat. If connected, test equipment can be provided with images at the click of a button and reserved accordingly for a test.

In contrast, Quality Center offers an integrated baselining tool and risk-based quality management, which we were unable to find in QM.

Summary

In a direct comparison, Quality Center is (still?) in the lead. However, with the JAZZ platform and the Open Commercial Development, Quality Manager has a speed advantage that needs to be taken into account. The current version of QM doesn’t have multi-project support yet, but it is expected to be available in April 2009 with version 1.01. On jazz.net, one can also check (”open” for that reason) what is currently being tinkered on. That’s one reason to look forward to fast release cycles. It remains to be seen whether customers want this type of speed from these testing solutions and will also import the new versions right away.

The QC versus QM match doesn’t end with a knockout. If one tallies up the points, the winner is QC with a score of 20 to 14 because it simply does many things in a better or niftier way than Quality Manager (importing test cases is supported in QC with a Word or Excel plug-in; in QM, the upload is done without support in the XML format). But even here, QM will probably catch up quickly. This is also necessary since QM’s release 1 deals with a new solution which in everyday work still has “teething pains” (e.g., test cases can’t be copied and saving attachments is sometimes impossible).

Ultimately, it’s worth noting whether one’s company already relies on IBM Rational products and the JAZZ platform in general, because combining development, requirements engineering, and testing on the same platform has a lot of cost-saving potential. To top it off, choosing a functional testing solution is always a price-related issue.

Security is especially important in online applications, yet far too little attention is paid to it. Perform a quick risk assessment just prior to implementation, jerry-rig a plug for the biggest holes, and you’ll have the software up and running in no time. Then a few days later, the first bytes of customer data are stolen. Does it have to happen this way?

In an incredibly short time, online security risks have become the primary risk for businesses. One reason is that nowadays business-critical applications have to be accessible online at any time to customers, partners, and internal users. Continuous availability opens the floodgates for friend and foe. Interactive contents exacerbate the whole thing. Statistics show that hackers don’t have to be asked twice to do what they do. Currently, one of the favorite modes of attack is cross site scripting (XSS). For example, a hacker tries to manipulate a web application in such a manner that damaging script code is embedded in the displayed page (e.g., in a guest book or an auction site page). The browser processes this actually trustable website including the harmful code and thereby sends the current login information back to the hacker. Even though companies take security absolutely seriously, reports regarding successful attacks are a daily occurrence. What’s happening here?

Fig. 1: Quality vs. Security

FINALLY RETHINKING THE SITUATION

The lion’s share of an IT security budget is invested in network security, e.g., for firewalls and intrusion detection systems, even though according to Gartner , 75 percent of the hacker attacks take place directly via the application and not the networks. To spend money specifically on where the greatest danger lurks requires rethinking the situation. Ideally, pains are taken in software development to ensure that no security loopholes even exist or to remedy these immediately. Those who are late with their testing are wasting money. However, the problem isn’t that easy to fix because the software is geared to preferably provide what is described in the functional specifications. As a result, checks are performed on what the applications are supposed to do, but not on what they are not supposed to be able to do. Developers with expertise in the field of secure development are a rare breed. Testing also has to be tailored to the new requirements. Unfortunately, one rarely sees a penetration test as part of a test concept. Likewise, the skills profile of a tester who is supposed to verify the functionality is different than that of a security tester. While one is looking for things that don’t work, the other should be looking for the undesired functionalities that allow too much to take place – in other words, we’re talking about real detective work.

SOLUTION APPROACHES

Making online applications secure requires specific measures:

1. Implementing security rules, guidelines, and regulations
2. Creating security requirements and attack scenarios
3. Performing specific security architecture reviews
4. Developing and complying with secure coding guidelines
5. Performing:
a) White box penetration test
b) Grey box penetration tests
c) Black box penetration tests
6. Monitoring operating systems continuously
7. Making assessments and feedback loops part of the first step

Fig. 2: Toolbox for actual implementation measures

ACUTE NEED FOR ACTION

In Switzerland, the secure programming and performance of penetration tests are still in their infancy. There most certainly is a need to make application more secure and to include the entire software development cycle when creating secure applications. By implementing the solution approaches above, one can gradually increase the application security’s maturity. However, it takes considerable amount of time and money in the short term because systematic training of the test and development units is necessary. In any event, setting up one’s own security testing squad does make sense.

TOOL SUPPORT

Once the activities are defined, they can be accelerated. Large-scale software manufacturers such as HP or IBM have recently shored up their capabilities in regard to security testing of web applications through targeted acquisitions. Certain fields of use may also have corresponding open source solutions. IBM, like HP, offers security-related tools that support an application’s entire lifecycle from its creation to its replacement:

For developers:

• Code is checked for security while being entered
• Solution recommendations and links appear if requested

For testers:

• Automated security tests check web applications and services for flaws
• Any discovered flaws are saved with the corresponding priority depending on the security risk and assigned to the responsible developer

For security experts:

• A 24/7 solution combs through complete web applications looking for security loopholes
• Automatic verification pertaining to legal, company internal, and regulatory provisions

The tools described are becoming better and better. Experts scan the Internet daily for new risks. As for anti-virus solutions, the tools are kept current with new signatures and detection patterns by means of updates.

SUMMARY

Targeted investments are necessary. Regardless of the maturity level an organization has reached, there is always room for improvement. The investment is certainly worthwhile because besides financial losses, a company’s image is also at stake.

The new Version 10 of the HP Quality Center (QC) is now available. Yet what are the actual advantages of the new QC compared to its predecessor from a Test Manager’s perspective?

Below, I will take a look at some of the new features and changes, and I will answer the question whether one should even make the switch.

The Most Significant Changes

The new QC Version 10 has seen a series of changes, of which the most significant ones are:

• Version control
• Baselining
• Integrated dashboard
• Shared libraries
• Cross Project Customization

Version Control

Finally, QC has been provided with a fully integrated version control. In past versions, one had to make do with third-party integration, which generally stumbled rather than ran. The version control, if desired, must first be activated for every individual project via the SiteAdmin. Once this is done, all entities falling under the version control become Version 1. QC entities include requirements, tests, test resources, and business components. If one wishes to add a test step to a test case for example, one is automatically requested to check this test case. As soon as there is more than one version of an entity, one can compare various versions against each other or retrieve an older version.

Summary: The whole thing is intuitive and easy to operate. But what’s the use of having eight versions of a requirement, when one doesn’t know which software release a version belongs to?

Baselining

Along with version control comes baselining, which is intended to answer the question above. Using the new “Management” module that replaces the “Releases” introduced in 9.x one gets to the baseline function via the “Libraries” tab. This enables one to obtain a summary of a complete testing release and retrieve it if necessary. In this way, a test set can be pinned to a baseline in the test lab. In other words, as of now, the manual copying of entire trees into the test plan module is a thing of the past. At last, test managers will be able to properly organize software that has multiple parallel releases (in production, current release, future release).

Summary: Setting up the baseline works very well. While creating it, a log keeps one updated on what is currently taking place. However, setting up baselines probably needs to be done during off-peak hours since it can take a while for larger QC projects.

Integrated Dashboard

Equally interesting for test managers is the new integrated dashboard that can be found on the left-hand navigation bar where the “Management” module is, too. The special feature of the new dashboard does not pertain to the graphics, which are not particularly appealing, but the “Cross-Project” functionality. It is now finally possible, when working on a QC project, to get an overview of all of one’s ongoing projects. These dashboards are freely configurable and can be designated to be personal favorites or publicly accessible. Special Excel reports also enable direct access to the database via SQL. The generated reports can then be graphically processed at the same time by means of VBScript.

Summary: The new dashboard module is quickly customized and achieves its purpose in ongoing projects. What is missing is a sensible way of printing content for a given project meeting, for example.

Shared Libraries

Libraries, which are located in the “Management” module, can be re-used and distributed with Version 10. A library represents a collection of entities in a QC project, including their relationships to each other. When dealing with many similar projects, it offers the advantage of not having to repeatedly create entities. Libraries can be imported from project A into project B, compared against each other, or even synchronized. A library also allows one to collect the same entities as in versioning. Defects are not included, but they can be shared with the new “HP Quality Center Synchronizer” manually among several QC projects. As mentioned, the advantages really only present themselves when one has many and/or large-scale projects. I suppose that is why this functionality is available only in the QC Premier Edition (also available are the Standard and Enterprise editions).

Summary: It remains to be seen whether this function will actually be used in real-world applications. In my opinion, it makes perfect sense to be able to take over pre-defined assets from another project so that one doesn’t have to keep re-inventing the wheel.

Cross Project Customization

And now here’s the last big change: Cross Project Customization. Many organizations have defined standards, such as a uniform defect status field or a standardized priority scale, for their software quality-related areas. However, these fields and lists were often changed or even deleted by QC project administrators. Some companies have even gone to great lengths in using their own programming to define a template that can be distributed to all QC projects, thereby establishing a uniform standard.

For all those who want to spare themselves this time and effort or do not wish to keep an in-house programmed interface going, there is a solution. Site Administrator now provides a way to link projects with a template. If the template is changed, the delta can then be passed on later at the right point in time. This function has been awaited not only by test managers who like to have the same configuration in all their projects, but especially also by the respective operators of QC installations, namely the system administrators. Cross Project Customization is also only available in the Premier Edition.

Summary: This change is awesome! Finally, testing organizations or Test Factory managers are able to implement a certain basic standard in their projects. Once this is accomplished, nothing can get in the way of standardized, across-the-board reporting.

Is an Upgrade Worth It?

The new Version 10 is an absolute milestone not only for tests managers. It also makes life easier for testers, Test Factory managers, as well as QC system administrators. The new functions have been anticipated for quite some time and have been implemented in the new product in a well-conceived manner.

However, there are still questions about how stable the new version is (my tests ran flawlessly) and how simple a migration of a larger installation might be. If these questions receive favorable responses, one should absolutely consider switching over to the new version!

The new concept of the Enhancement Packages (EhPs) from SAP is ingenious from a technical perspective. It’s actually too bad that SAP, the supplier par excellence for business software, has taken so long to create this software logistics concept. Based on the time and effort they’ve put in, any SAP CIO can tell you what this gap in the framework has cost customers. Yet it’s not quite as cut and dried as suggested in the Inside IT article entitled “No More Tedious Upgrades” dated February 4, 2009. The way Roche’s CIO Jennifer Allerton is quoted, one might be led to believe that specialists are no longer need for upgrades. Allerton explained to the Wall Street Journal that Roche had completed four complete upgrades in the last year, which required a team of 15 specialists. She believed that the new Business Suite would enable the company to avoid having to carry out upgrades. And this is a deadly fallacy.

There’s no doubt that from a software logistics perspective, SAP did its homework. But this perspective is restricted primarily to the impact of changes only within the scope of standard SAP software functions. Customer-specific modifications and integrations are not considered. Can you name a large-scale customer that has not carried out massive modifications on it system, expanded it, and integrated it into its application environment? By the way, this is not unusual for SAP. Even in regard to the innovations pertaining to the Solution Manager and the Transport Management System, the problem is always only perceived from the software manufacturer’s viewpoint. The customer’s environment remains the customer’s problem. “Switch technology” that forms the basis of the EhPs can also be used when customers want to expand the SAP standards themselves; however, ABAP developers first have to learn new development methods to suit this purpose.

Accordingly, the EhP concept does not pertain to customizing or modified functions in actual customer SAP environments. However, this is typically where customers put most of their money when they implement SAP. Change impact analyses for EhP activations remain absolutely necessary. SAP assistance tools will not be able to accomplish these in the future either. In fact, they will continue to require, and all the more often, the utilization of tools developed by specialized companies such as IntelliCorp or Panaya.

Incidentally, a prerequisite for implementing EhPs is SAP NetWeaver 7.0. For SAP customers who are not yet running SAP NW 7.0, their only choice is still the conventional SAP upgrade.

Differences between Implementing EhPs and Traditional Upgrades

a) When installing new and upgraded SAP functions on the SAP platform

EhPs can be installed at any time, although the physical effort remains the same. However for the users, activating new functions and thus the customization of business processes is no longer directly time-dependent on solely installing the new functions on the SAP platform.

b) When activating the new and upgraded SAP business functions for users

In a separate step from the technical aspects of installing new functions, activating them can be done for users at any time, supposedly in a dynamic manner also for sub-functions of the SAP release.

However, this dynamic holds hazards. Just as in upgrades, it is critical when preparing EhPs to be activated to gather additional requirements of the newly provided functionalities. This is necessary to analyze the effects of activating new functions provided by SAP on the configured basis as well as on changes being made to the system that stem from projects and support change requests.

By means of such analyses, the impact level of activating individual EhPs and necessary preparatory and post-activation tasks, such as test activities, can be determined. This will clearly reveal how much time and effort was needed to import individual EhPs.

The flexible and dynamic activation of individual “business switches” is all the more reason to require an impact analysis. First, it is exceptionally helpful, when thanks to analysis tools, it already becomes clear which transactions contained in an EhP are actually implemented in a company. Based upon the business user expectations generated by SAP marketing, the customer’s SAP competence center has to comprehensively analyze these transactions in a time-flexible manner for the EhPs to be activated. Then pre- and post-processing measures for activation can be initiated on short notice in a systematic manner.

Impact Analysis

Most SAP customers have experienced the effects, regardless whether they stem from upgrades or now from “activating EhPs.” The fully implemented application portfolio is repeatedly upgraded so that the new technical functions based on old technical operating modes can be maintained, instead of actively managing only the delta between old and new functionalities (documentation, tests, etc.), not to mention that one can access information from previous application changes.

The only real fix remains to invest in a sustainable SAP Application Lifecycle Management solution to support the competing implementation of SAP initiatives and SAP operations.

Summary: SAP Enhancement Packages as a Panacea

The considerable amount of time required to identify, implement, and test new and customized business functions still remains the same even with EhPs, and is perhaps even slightly more due to the flexible, step-wise activation that businesses find appealing.

Due to the newly provided business functionality, available in whole or in parts, the impact analysis has become more complex and certainly more time-consuming.
Now that the technical installation of EhPs has become time-independent, time can be gained in the provision of sub-functions. This time savings must absolutely be re-invested in the impact analysis and the corresponding flexible pre- and post-processing so as not to incur the risk of quality-related problems in production that could result in production stoppages. As a result of this time-independence and the growing complexity in the system itself, the time and effort required by lifecycle management tends to increase if anything. The assumption that thanks to EhPs, one can save on resources needed for managing changes to the SAP system quickly proves to be a fallacy.

A Gallup poll from last year in German companies shows: 67 percent of employees make work to rule. Cause was the lack of leadership culture, of real self-evident characteristics such as esteem, respect, personal development opportunity and involvement in decisions. The damage to the economy because of the lack of innovation and frustration of customers projected at around 100 billion euros. Could in any case, even better, right?

About the positive relationship of cultural characteristics such as performance, trust, responsibility and autonomy with the success of companies, there are a large number of scientific findings and personal perception. It is more difficult to say which pattern in detail leads to success. Comparative studies depend on time and location: examples of American companies on the east coast of the early 90s do not necessarily answer to our questions today. Seemed earlier features such as stability and identity speak for superior cultures, there are now flexibility and diversity taken for granted. In the end responsible leaders must say what they think is right and what they want (reasonably related to an actual culture analysis of their enterprise).

Ever more powerful cultures differ

• by openness to other internally and externally, in contrast to autism and isolation,
• liberalism in the sense of positive appreciation of other perspectives, in contrast to the prevailing fundamentalist attitude,
• diversity as a richness and internal structure in contrast to the uniform.

These are the consistent results of comparative cultural and historical studies. Derived from this I have detailed and described some specific patterns from “adaptibility” to “trust”.

About the author:
Dr. Michael Loebbert is Coach and Management Consultant and author of the montly publication “Change Management Short Cut“.

HP PPM in combination with beteo’s SAP Change Control Current Practice can help SAP customers to reduce cost and risk the SAP change process.

This article summarizes the potential benefits, challenges and approaches of implementing a SAP change control solution based on HP PPM and beteo SAP Change Control Current Practice as well as illustrates a sample customer reference.

Potential Benefits of a SAP Change control solution with HP PPM and beteo’s SAP Change Control Current Practice

• Improved Efficiency: For 80% of all changes deployment time is reduced by 85 percent or more, manual intervention efforts by 50 to 70 percent – lowering overall SAP deployment cost and risk. Same customer headcount can manage more changes, reducing risk, change backlog and increasing traceability.
• One Uniform Change Management: One single approach will manage all changes to all applications, across all environments and platforms, automating migrations and deployments of all software changes from projects and support. Typically the overall time spent on the change process can be reduced by 20 to 30 percent.
• Digitized Best Practice: In addition the one approach will be codified, automated and governed for the entire change and deployment cycle with beteo Current Practice processes for effective change management. Like that best practice application development methodologies are enforced.
• Automated Deployment for customer projects, changes from customer’s support and from SAP: Roll-outs from change request process and project implementations, SAP upgrades, SAP service packs, SAP hot fixes, change requests from support, configurations, SAP instance consolidations, and migrations to avoid costly delays and errors are highly automated including consistency assuring measures. Managing multiple deployment environments is enabled with full control over individual changes and groups of changes or releases.
• Complete Visibility: A system of record audit trail for visibility across the entire change process with comprehensive reports and a real-time dashboard are made available.

Change Control challenges faced by SAP customers

For SAP systems as for any IT system nothing is more constant than change. At least once a week, numerous changes initiated by the customer’s  support, project teams or by SAP are moved into the SAP system landscapes and semi-automatically or manually transported to production servers. Because of the typically elaborate, complex system landscape of large SAP customers in their overall business environment, the risk that something goes wrong is high and complex, expensive manual interventions are often required to get changes applied without impacting the running SAP systems and customer’s operations.

A consistent, beteo Current Practice-based tool-supported SAP Change Control implements, controls and largely automates the SAP change process. A secure way of executing auto-deployment of SAP transports, for ABAP as well as non-ABAP changes, across the SAP landscape will be made available. It prevents system components from breaking down, resulting problems don’t need to be analyzed ex post and manually solved by system specialists anymore.

SAP offers a system with quite convenient possibilities to implement changes across system landscapes. Unless there are parallel changes from support and projects in complex system landscapes implemented, SAP’s tool supported transport management for changes does a good job. It allows transport routes to be defined across the system, transport requests to be released and change packages to be distributed and installed across the system, including defined validation steps.

But SAP’s rather sophisticated system has its limits. First, the process of rolling out changes is quite error-prone. Second, compliance rules are not completely met. And third, the system is susceptible to inconsistencies.

• Changes are more or less simultaneously distributed across the solution landscape via transport processes. Differences in runtime speed in the various phases of distribution and verification can cause time-dependent changes to be implemented in the wrong order.
• There might be conflicting changes from different projects, the customer’s support and SAP.
• Manual changes might be executed at the wrong time.
• SAP Customizing changes are not versioned and have no lock mechanism. It happens easily that they are unintentionally overwritten.
• Once changes and change sequences have been executed, they cannot easily be executed a second time.

Ways to handle SAP Change Control challenges

There are ways to proactively handle these problems with a reasonable effort. Applying beteo’s “SAP Change Control Current Practice” in combination with HP PPM implies the following:

• For all changes to the solution landscape, there is a change request and an approval. There is no transport request (technical change) without change request (organizational change). All changes are documented.
• Changes are grouped according to projects, areas of use and common technical objects involvement, so that the transport is unlikely to cause conflicts with the system environment. The projects have more autonomy concerning transport.
• Transport and routine tasks are automatically executed in the correct order, including comprehensive measures to ensure consistency.
• Potential errors caused by changes that are transported faster than others or by unintentional overwriting are recognized in time and remedied proactively. This also applies to transporting different changes from all kinds of SAP or non-SAP systems, such as changes to SAP CRM, SAP ERP, or SAP BW objects, SAP customizing, Java packages, SAP portal configurations – and to many interdependent components that must be changed.
• Entries into the Change Control documentation are made automatically and users of dependant objects for a change are being alerted.
• Change processes are strictly followed.
• All changes are executed in a secure way; rollback functions can be made available and changes run repeatedly.
• There is a complete audit trail for all changes.

A reference customer for a HP PPM based SAP Change Control

The reference customer needed a software solution that would formalize, standardize, and automate every step in the SAP Transport Management process. The new solution had to control the entire change management process in a single, end-to-end workflow — from change request through testing and interim releases to live activation. The new Change Management should underpin the automated, controlled distribution of new and/or modified SAP software processes on the basis of a regulated information flow .

The challenge
To formalize, standardize, and automate the process of taking new or modified electronic business processes in the SAP R/3 environment live, in accordance with the best practices defined in the Information Technology Infrastructure Library (ITIL). The customer was looking for a solution that would provide no-gaps support for every step in the SAP Transport Management System.

Business Value
With beteo’s experts and HP PPM, the customer achieved a change and transport management process to carefully control the system-wide distribution of software updates. The result: no more system failures, less manual work, and projects completed on time and on budget.

• The customer successfully adapted and implemented SAP Change Control based on HP PPM and a solution architecture by beteo’s senior solution architect in a short timeframe.
• The customer now has the ability to optimize its electronic business process on an ongoing basis, without risking the expense and annoyance of system failures.
• HP PPM Change Management helped ensure that already the first strategic SAP project was completed successfully — on time and on budget.

About the customer
The reference customer is a large German SAP customer occupying market-leading positions in several utility business segments.

Testing departments use HP Quality Center (QC) for quality management and testing activities. Besides managing test requirements, it also helps them to compile test plans, and to conduct and monitor testing. In addition, Quality Center gives them a way to manage all defect tracking.

However, developers often work with their own tools to manage bugs and defects, and to monitor problem-fixes. This is the case for example with Jira created by Atlassian Software Systems, which is primarily a tool for bug and issue tracking. Quality Center’s actual strengths, namely managing test requirements and test cases, are not effective in this utilization realm. Developers sometimes consider an additional tool as dead weight and far less user-friendly compared to already known tools such as Jira. For that reason, many developers are reluctant to work with QC and prefer “their” Jira.

Since using QC offers many advantages thanks to its high transparency and structure in terms of test management, QC and Jira are nevertheless used side by side in actual practice for the purpose of defect tracking. This results in a duplication of effort, less transparency, and additional complexity due to communication needs and media-related disruptions. Furthermore, synergies between the test and defect processes are not tapped.
An interface between these two tools could result in each role being carried out using the tool best suited for a given task. Such a bridge combines the tools pertaining to integrated process support and creates transparency throughout the entire test and defect processes, while also being able to manage and optimize them.

A defect management cycle for an error discovered by the testing department would appear as follows in a project:

Should the defect recur, the status is changed from “closed” to “reopen” and the trouble-shooting sub-process is re-initiated.

However, one should not create a suitable interface between QC and Jira based solely on an individual project’s requirements. The key is to have a flexible interface that one can tailor to specifications of new projects by means of simple configuration. Ideally, a QC-Jira bridge should be able to synchronize any given project-specific areas that fall under QC and Jira’s capabilities. In the event of further expansion, it is also critical to ensure that the organization of test management and development departments is geared toward the new, shared, integrated, and tool-supported process.

Summary: Integrating Jira and the Quality Center

beteo implemented an interface between Jira and QC at a large-scale Swiss transportation company. Thanks to the interaction between the two systems, all individuals involved in the projects can work with the tool best suited for their respective needs. Developers, test managers, and testers utilize the product tailored to their tasks. In this way, defect and test management are combined, simplified, and, thanks to a reduction in redundant activities and communication complexity, more cost-effective.

In a highly interesting and descriptive blog posting on the SAP Community Network, Tao Zhang, who works for Benteler Group, discusses the SAP consolidation process. His article focuses on the challenges and potential benefits, approaching the issue from the company’s perspective.

New Challenges

As I see it, the biggest challenges facing SAP system environment consolidation projects in the medium term aren’t so much the need to meet company requirements (namely the actual consolidation of the SAP systems) but the need to implement all the measures that will ensure the successful operation and further development of a consolidated system. In other words, it becomes critical to establish processes that will institutionalize the system’s continuous development. Otherwise, the projects and system adaptations carried out after consolidation will be subject to paralysis and failure.

Zhang’s article doesn’t disclose how SAP Change and Transport Management is supposed to function after consolidation. However, the problems associated with having to make competing changes on system components due to simultaneous projects or a company’s change requirements are substantially exacerbated by such a project. This is particularly true in customer environments where, typically, configuration management of the SAP customer landscape is not practiced.

Starting with Simple Protective Measures

Initially at least, simple protective measures can achieve a certain effect. This is one way to protect company templates and achieve a reasonable degree of harmony among the business processes implemented in SAP environments.

Configuration Management, Impact Management, and Change and Transport Management

However, to ultimately protect investments made in consolidated systems and harmonized business processes, one must address the need for suitable change and transport management processes and consistent comprehensive SAP configuration management. Moreover, the latter should include the objects related to process documentation, the documentation in general, and test management.

SAP Solution Manager Isn’t Enough

SAP, in order to satisfy such requirements, normally refers one to the Solution Manager. Based on my experience in the aforementioned SAP system environments, Solution Manager will be overwhelmed by the complexity of competing, simultaneous demands associated with company requirements related to change and multiple-project management. Instead what it needs are additional approaches that incorporate institutionalized change and transport management, configuration management and impact analysis, which should occur as early as possible in the development cycle.