Beteo Blog

Author: bea4x

  • HP PPM Best Practices – From an Idea to a Specification

    Optimal preparation for development
    The blog post “HP PPM Best Practices – The Key to Success” deals with the preparatory steps which are necessary to develop a solution based on HP’s BTO tool suite. These steps are a prerequisite for working out a specification. The present blog presents a best practice approach to the transfer of ideas into real specifications for development and configuration of HP PPM solutions.

    HP PPM consists of several modules which amongst others cover the following business areas:

    Requirements – digitizing the processes
    In the phase of gathering ideas it is recommendable to digitize all processes that will be involved in the realization of the project. This requires that all processes are identified, indexed and specified. As a best practice method, the following approach has proved to be successful:

    • Mapping the total process in a BPMN (business process modeling notation). This includes the individual process activities and the roles involved.
    • Defining the status transitions by means of a state diagram in UML (unified modelling language). This represents the individual statuses and their interdependencies with the upcoming decisions.
    • Defining use case diagrams (UML) which support the activities and statuses from the above concepts. This involves the description of a defined process from the users´ perspective, written down as a continuous text. It must be ensured that all terms used in the concepts are synchronized.
    • Defining a service catalog. The service catalog facilitates the modularization and consolidates business-oriented services.
    • Summarizing the above concepts in a product requirements document.

    Preparing implementation
    After mapping the requirements by following the above steps, the implementation must be prepared. In terms of PPM this means:

    • Evaluation and transfer of the preparatory steps described above
      Evaluation in this context means to project the business-oriented requirements onto the level of the tools which are used. The focus is on the interconnection between the individual business processes. Status transitions and interfaces should be specified. To map process as a whole, BPMN has proven useful. In addition in this step automated activities are mapped.
    • Definition of request types and attributes
      Processes in HP PPM are controlled by forms. The definition of these forms (request type) must be related to the business processes. This implies to keep a field list including the attributes required for implementation.
    • The state diagram must be adapted to the technical conditions
      Statuses in HP PPM are not mapped in a 1:1 relation. On the one hand, they serve to control the information displayed in the form, on the other hand to analyze the progress of the involved business process. In most cases, some “technical” statuses must be added.
    Business Process Parameter Information Notes
    ↓ Input Information Field List Defined fields must be filled before the activities are started
    Activity Process Information BPMN, Field List The fields to be displayed and automated processes
    ↓ Output Information Status diagramm, field list Results of activities, maybe controlled by information in the fields


    Summary
    Sound preparations lay the foundation for the definition of the requirements. For changing ideas into requirements it is recommended to digitize the involved processes, which means identifying and describing them by means of BPMN and UML. Afterwards, the concepts can be evaluated, the request types (forms) and the attributes can be defined and the status diagram can be adapted to the technical conditions. Experience gained from successful projects has shown that this is the best possible way of describing the specification and of preparing the subsequent implementation of HP PPM.

  • Business and IT – Change Impact Must Be Managed

    Continuously growing system complexity
    Nowadays, existing IT systems cover more or less the complete business processes. In most cases, strategic decisions to buy commercial software  – instead of making software – are in place. New developments of complete business systems are the exception to the rule. Against the background of this situation, a new concept of developing applications is required: It is no longer build-centric, but rather change-centric, also see item #4 in the Blog written by Niel Roberston, CTO at ALM-vendor Newmerix.

    Whereas the development of new systems used to be a creative, innovative challenge, the requirement now is to make a varying number of minor or major changes in existing systems or to customize them. The systems are completely built up, they are in use, they are linked to several technical and productive entities or between one another, often via complex mechanisms, and they are localized – covering all system levels from small program components and local customizing up to selected business functions and entire business processes.

    In addition, modern systems are more and more composed from reusable components. Service-oriented architectures allow a clear separation between business processes and functional system components. A prospective design would also offer the possibility to protect services against negative effects caused by partial changes of the system. But obviously, new dependencies have arisen in such a landscape of reusability. Functional components are used by different business processes, and changes made within one business process or one business function may have an effect on various parts of the system.

    System consolidations contribute to this problem. In order to save hardware and software costs, business processes and functional components are locally or globally consolidated on the same system. This implies that changes which result from local requirements must always be seen in the context of the whole consolidated system.

    Impact on the system and on changes
    So before making changes, these interdependencies must be well understood to avoid unpleasant surprises. Experience has shown that in general there are several types of effects on the system which must be recognized and got under control.

    Which components are integrated parts of the system across all levels and must be changed? It is crucial to not only look at components used to run the system but also at all descriptive or organizational objects used during the project. Which other components, that seem to be independent parts of the systems, will be influenced? What is the effect of the change on planned or running parallel projects?

    Another point should be taken into account: In how far will the change add to the existing complexity? Sooner or later, you can make any system too complex to be maintained.

    Finally, the degree of complexity of the existing system must be considered under the aspect of the planned changes. Possibly, a system analysis would bring forward that the system is too complex for even a minor change to be undertaken. An analysis is the only method to get to a realistic estimate of the “environmental tolerance” of a change.

    However, far-sighted concepts of system design or the protection of components such as company templates could be targeted as preventive measures to create a system landscape which minimizes the effects of changes or identifies undesired changes and blocks them.

    IT Impact Management means IT Impact Analysis & IT Environment Protection
    In this scenario, IT Impact Analysis and IT Environment Protection become core disciplines of system development. For commercial software, there are first approaches to this task. Informatics organisations, however, which follow a defined concept of integrating Impact Analysis and Environment Protection into IT processes, are still rare. Instead, enterprises usually make an unnecessary effort all across the application lifecycle at a high price: The projects get too complex and beyond control, dependencies are not recognized, thus tests are not run and errors are discovered not before the system is run.

    However, there are ways out of this dilemma: Impact studies would help judging projects correctly. Even in situations, when parallel projects plan to implement changes of the same components, the process can be understood and controlled. Implementing changes in the context of different projects could even be a commonly targeted action. This would imply that the effort of understanding the component needs to be made just once. Since by an impact analysis the parts and aspects of the system, which will be affected by the change, are made visible, the right things can be tested and the quality of the system before roll-out into production can be tremendously improved. Installations of large commercial solutions can be adapted more flexibly to business requirements and be maintained and used for a longer period of time.

    Summary
    Stringently applied Impact Management, including Business and IT Change Impact Analysis and Environment Protection are rapidly gaining in importance. The use of commercial or newly developed software systems requires a new look on system building – every new requirement primarily leads to a change of the existing system.

    Service architectures and business process management allow re-use, but at the same time the effects of changes are multiplied.

    Change Impact Management, including Impact Analysis and Environment Protection, consistently integrated into the method of system development and supported by suitable tools, allows the systems to be changed across the lifecycle – in spite of a high complexity and with reasonable effort – and helps to avoid even more complexity with every change.

    The benefit of effective Impact Analysis and Environment Protection can be immense. Commercial software installations and service architecture systems can be further developed with reasonable effort and at a high quality level. The systems remain flexible for business and IT and the response times for changes can be shortened. They can endure longer lifecycles without having to be substituted at an early stage because they have become too complex.

  • 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.

  • Only Motivated Users Make IT Projects Successful

    The introduction of a new IT solution entails a large deal of different changes. New roles and responsibilities must be defined, supported by additional new software. An early integration of the future users is of great importance, but very often, there is not enough attention paid to it.

    A typical example from a “normal” project: Shortly before the new solution goes live, there is – in most cases – still one pending issue on the to-do-list of the project which has already been postponed several times: the user training. The budget, including several amendments, is already stressed at that time, and the last days before going live are busy with remedial actions.

    Neither client nor project manager and project team have so far attached value to the training of the users, although insufficient training of future users can easily turn into an unexpected obstacle in the project workflow.

    The results are as follows:

    • Instead of a user training, the project team is pursuing “a learning on the job” strategy
    • The users are forced to use the new system without or with insufficient training.
    • The project team supports the users after project finish, so that there are no resources for new projects left.
    • As applying the software is a gradual process, nobody really knows the exact time when change management starts to have an effect.

    The enormous damage for the enterprise is obvious:

    • There are additional expenses, meaning real costs, by the parallel use of the old and the new solution, which involves additional work for coordination and mutual arrangements.
    • The absence of a user training and the delayed transfer of know-how result in further costs, since the new solution cannot be used as scheduled. The planned benefit fails to arise.
    • The users are frustrated and do not come to terms with the new tool. There is an atmosphere of discontent, and the new system runs the risk of not being accepted.

    This suggests the conclusion that the planning and realizing of user trainings ranks among the most important success factors for the introduction of a new system. Also with respect to the implementation of an internal “support structure” and “support culture”, considering the aspect of knowledge transfer from the project team to those who use the solution is imperative.

    This means that the issue of user training must be communicated in the project team at an early stage and be actively promoted. This results in users who are fit for using the new tool when it is going live.

    This target can be achieved by the following measures:

    • From the very beginning, one of the users participates in the project meetings as user representative. He will get familiar with the introduction of the new tool and assume responsibility for the planning and realization of the training. This enables him to have a say in the development of the tool from a user´s perspective and to co-determine the structure and the procedural methods of the training.
    • Fixed dates as those for software updates or data migration, as well as downtimes caused by technical failure and holidays, must be observed when planning the training. Training sessions take place only if all training participants have time not only for taking part in the training, but also for familiarizing themselves with the new solution afterwards.
    • A concept to support the users is figured out: Who is in charge of answering general user questions concerning the application? Who will help the user with the practical use of the solution?
    • The individual roles such as key users, administrators, first and second level support, as well as persons responsible for operation or test execution are clearly defined. The employees assume these roles at an early stage of the project and are trained respectively.
    • The users are informed in time about the introduction of the new software and the training involved with it. An effectively flowing communication within the project, usually referred to as project marketing, is actively supported by all participants and responsible persons.
    • All relevant requirements for a successful training are planned in time, and meeting these requirements is secured by the time the training starts.
    • The training classroom is booked (and well aired :-))
    • The training documents are printed
    • The computers are set up and started, the software is installed
    • The system is ready to get started, training documents are handed ou
    • The users are not disturbed during training times
    • There are breaks for the participants to exchange experiences
    • A printer is available to allow the participants to make screen-shots
    • The trainer is well prepared
    • Feedback by the participants allows for the training to be improved and optimized in future
    • Immediately after the training, the users should be able to use the new solution. The direct transition is important to take advantage of the positive momentum gained from the training. Now the systems along with an uncomplicated support environment must be available.

    Summary
    For the successful introduction of a new software solution, not only the technical requirements must be fulfilled. In addition to consistency, availability and user-friendliness of the solution, it is important that the users are well-informed, personally engaged, highly motivated and well trained. The users should be involved in the project at an early stage of the project, the training must be planned in time, including the means required, and carried out in a professional way. Least not last, the new software must be made available right after the training and be used. The option to use the old system must be abandoned. If these clear principles are observed, the successful application of the new solution – and thus the success of the project – will be secured.

  • HP PPM Best Practices – The Key to Success

    For a promising start of HP PPM projects, there are important requirements to be complied with, rules to be observed and system configurations to be carried out, right from the beginning. In the following, the most essential best practices are listed, gathered from a large number of HP PPM projects.

     

    General Requirements for the Configuration and Development of HP PPM Applications:

    – Development guideline
    The development guideline includes all standardized rules for the development process, the applied methods and all tools to be used. Additionally, the development guideline is used to document the experience made during the development phase.

    – Glossary
    In the glossary, terms and abbreviations used in the context of development are explained. It is a means of standardization of terms used in conjunction with the development of HP PPM projects.

    – Role concept
    The role concept defines the roles of the development team members. It rules communication, escalation and responsibilities.

    – Development environment
    All tools used in the process of development are defined here. The developers have to be familiar with the used devices and the connection parameters.

    – Up-to-date patches and fixes
    The newest patches and fixes must be installed on all devices used for development and subsequent testing. You will find the newest patches on HP’s PPM Patch download page (HP passport Account required).

    – Best practices
    We recommend to continuously compile and document best practices. They can be derived from the software producer and, above all, from own experience. The results can be incorporated into the development guideline.

     

    Specific Requirements for the Configuration and Development of HP PPM Applications

    – Installation and configuration
    All necessary commercial software must be installed and configured on the system planned to be used for development according to the system manual.

    – Testing the development platform
    The development platform must be tested using the best practices provided by HP. The HP Quality Center offering automated tests may be a helpful support. It implies the advantage of re-use.

    – Testing the SSH connection
    Testing of the connections between the servers defined in the development environment is a must.

    – Setup of the computers of the developers
    The required development tools such as Eclipse, SQL Developer, WinSCP,… should be identically installed on the computers of all developers involved.

     

    Required Authorizations – Special Configuration for Starting a Development Cycle with HP PPM

    – User management
    Implementing a security group comprising the members of the development department who are meant to be authorized to user management. Reference to an organizational unit facilitates the administration of this group.

    – Developers
    Implementing a security group comprising all members of the development department. Assignment of the required access authorizations to change request types, request header types, workflows and validations.

    – Object owner
    Implementing a security group with all members who become owners of objects.

    – Package transport
    Implementing a security group with all members who are in charge of the transport of the development packages from the development system to the test system.

    Basic Settings – Special Configuration for Starting a Development Cycle with HP PPM

    – Required environments
    Setup of all necessary environments for all defined systems. Testing the connection to the environment checker.

    – Validation with global parameters
    By this measure, a globally applied parameter can dynamically be changed during development, all references being based on the up-to-date parameter. These parameter references are used in all objects. This avoids errors with the referencing of transported objects.

    – Transport workflow
    Definition of a workflow for the transport of the developed commercial software. This workflow maps the complete process of deploying the developed commercial software.

    – Change management packages
    Definition of a change management package which includes all developed objects of a version (labeling). This package is used as a medium of controlled transport of the developed packages.

     

     

    Summary

    These guidelines are an excerpt from the best practices compiled from many HP PPM projects (formerly Mercury ITG). They contain a rough overview of the experience and the insights gained from HP PPM configuration and development. If these basic requirements are met and the recommended rules are followed, the first step towards a successful HP PPM project is done.

  • 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”.

    SAP Company-Template System Landscape

    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.

  • End of an Exception: Quality Management Integrates SAP

    For testing SAP solutions, we used to depend on experts with specialized ABAP or JAVA know-how. Consistent testing of processes beyond SAP systems was quite a challenge.

    Now SAP offers SAP Quality Center by HP. It enables the customer to integrate SAP testing into a comprehensive Quality Management and testing of his IT organisation. This means that SAP testing is no longer a special discipline within Application Management.

    Through bidirectional integration of SAP Solution Manager and HP Quality Center, the precondition for the HP Quality Center to be used as a central control station for SAP testing – and thus for Test Management – has been created.

    For SAP customers, this provides a simple and intuitive approach to controlled access to HP´s Testing Tools, which HP acquired from Mercury Interactive in 2007. In addition to HP Quality Center, at that time called TestDirector for Quality Center, the tools include HP Quick Test Professional and HP Loadrunner.

    The combination of these tools allows for the test requirements to be directly derived from SAP Business Blueprints and to be used as a basis for creating test cases in HP Quality Center.

    In addition to meeting the requirements for SAP applications, HP Quality Center will make it possible to also include processes, that reach beyond the boundaries of SAP systems, into testing requirements, and to test them comprehensively. Testing teams are enabled to start testing from HP Quality Center, without being dependent on SAP specialists.

    So Requirements Management in IT can be standardized and optimized. A better transparency of testing processes will be achieved. Testing results can be compared and, through this, Compliance risks are minimized. Due to user-friendly Quality Management functions, testing automation and re-usability of the testing cases, time and costs will be saved.

    We may summarize that the integration of SAP “SolMan” and HP Quality Center bridges relevant gaps in Application Management allowing the SAP environment to be embedded into a comprehensive IT-wide Test Management.

  • Application Management Reduces SAP Costs

    In the context of large commercial software installations, the opportunity to reduce costs in the long run – all through the life cycle of the systems – is tremendous. Four fields of Application Management, pragmatically introduced and applied, are able to substantially contribute to this potential benefit.

    Project Portfolio Management
    A consistent Project Portfolio Management (PPM) which considers, evaluates, and releases all changing activities from a business as well as an IT point of view, will concentrate effort and reduce cost. In many cases, changes are evaluated from either business or technical perspective. To get to a comprehensive assessment of change requests by IT – concerning complexity and effects on other business processes or technical components – suitable tools are often missing. As a result, decisions are often based on wrong assumptions, and effort and cost estimates prove to be false.

    Quality Management
    A pragmatic Quality Management, consistently supporting the development process, and realized as an integrated tool, is often missing or insufficiently implemented. Integration of development and quality methods and tools spanning all phases from definition of requirements up to testing, will ensure completeness of testing and, above all, hold the scope of testing activities at a reasonable level. Often, Quality Management fails because the scope of testing cannot be clearly defined. As a result, complete testing gets too laborious and will be left out in parts or even completely. When attempting to put the changes into effect, then, at the latest, there will be undesirable additional costs.

    Environment Protection
    The presumably most difficult issue with large SAP and other packet software installations can generally be referred to as Environment Protection – and it holds the greatest potential for benefit.     The number of components in modern systems is dramatically growing. The reutilization of customizing settings, data, processes, functions, program components or services helps in the first place to lower development costs. On the other hand, it increases the risk of changes taking effect on various parts of the system, intentionally or unintentionally.

    So how could be made sure that one or more changes at a time will not interfere with other functions that are, at the same time, running or being edited? There are in fact approaches to address this problem by the help of methods and tools. But most of them are to a large extent restricted to the developers´ perspective. They are inadequate for customizing activities, let alone for a business analyst evaluating the effects of changes, which means inadequate on business level. Environment Protection is getting a more and more exigent issue as the amount of internally and externally created services used in the context of SOA (Service Oriented Architectures) is constantly growing.

    Lifecycle Management
    The lifecycle of large applications is not restricted to three or five years. From a realistic point of view, we should rather talk about ten, twenty or more years. And these applications are permanently in a process of change. A consistent Lifecycle Management for all objects, no matter if they are of rather business-related, technical, organizational or descriptive nature or relate to the technical process of their development and operation, is a pressing requirement. The issue is not only relevant for the results of development – how is a result changed over a longer period of time, and for which reason? – but also for the development process itself: What does its realization look like? And, once it is clearly defined, should it repeatedly be carried out in the same way? Changes must be targeted and documented. Useful and reasonable documentation, digitalization, administration, and automation are in demand. This is a promising approach to avoid redundant and unnecessary activities in the context of system change and development.

    Summary
    Application Management projects around SAP and other large packet software installations in all kinds of industries make it obvious that the targeted investment in Project portfolio Management, Quality Management, Environment Protection and Lifecycle Management is profitable.     With reasonable effort, they produce high benefit all through the lifecycle of the systems. But there is also a short-term advantage, the reduction of errors. Better defined system environments facilitate parallel work on projects. And it will be possible to benefit from prior projects, with respect to development as well as testing and deployment.

    Project work, in particular, clearly shows the high demand for an optimized support of methods and tools in the context of Application Management. In many cases, there is still a great deal of unnecessary manual work done – an issue bearing a great potential for software vendors and at the same time being a challenge for producers of commercial software. In our new beteo mini guides, we present a survey of Application Management tools – not only for SAP systems.

  • Happy Birthday beteo

    beteo is celebrating its first birthday! You would not believe it, but on February 21 beteo was one year old. A good reason for all friends of beteo to be happy.

    We are proud to see what has been achieved in this first beteo year:
    beteo has become a real company, headquartered in Sarnen, Switzerland, with offices in the Zurich Area as well as in Berlin. Today we have 15 people working for beteo in Switzerland, in Germany, in Kharkov, Ukraine, and in Hyderabad, India.

    beteo is a consulting and software company which helps clients working on comprehensive software installations, foremost SAP,

    With expertise and tools from partners like SAP, HP and specialized software vendors, we are involved in longterm activities supporting large customers in Germany, Austria and Switzerland. What do a market leader in steel industry, a popular sporting goods manufacturer, a large governmental organization, a top Swiss transportation company, the leading Swiss logistics organization and one of the largest Swiss life insurances have in common? They all improve their Application Lifecycle Management with the support of beteo!

    We plan to offer our first own product by May – in the beginning mainly to support our own activities, as a complementary solution to the products used by our customers: SAP Solution Manager, HP PPM, SAP xRPM, HP Universal CMDB, HP Quality Center and TimeWinner. Later on, our product offering and expertise will be extended by specialized solutions from new beteo software partners

    We are permanently broadening our experience and we love to share it with our customers, our partners and the market. In doing so, we promote best practice Application Management not only for the sake of beteo. Project Portfolio Management, Quality Management, Environment Protection and Lifecycle Management are the main disciplines addressed. Our beteo Blog and Website in English and German as well as our contributions to Wikipedia are well observed, linked and commented by the market, from analysts and our competitors alike. Gradually, our vision is becoming reality, and a global dialog on Application Lifecycle Management is in sight.

    beteo is a success story. Both, our consulting as well as our software activities are highly demanded and we are continuously enlarging our teams – not only in Zurich, but in all places where our clients are in need for our support. beteo has ambitious plans, and I am looking forward to an enthusiastic update e-mail for beteo’s second birthday.

  • SAP xRPM and HP PPM – Complementary Solutions?

    Whether in Gartner’s Magic Quadrant for PPM or in evaluations for project portfolio management tools, HP PPM (HP Project and Portfolio Mangement Center) and SAP xRPM (xAPP Resource and Portfolio Management) are always positioned as competitors. But do the specific features of these very specialized solutions justify this positioning?

    What are HP PPM and SAP xRPM ideally used for?
    HP PPM has more or less been exclusively designed to be used for managing IT project portfolios. When it comes to integration with software development and application lifecycle components like testing, configuration management databases (CMDB), and business process management tools (BPM), HP PPM shows its real strengths. The strong process engine of HP PPM cannot only control and drive organizational process, it can also control the technical execution of other software components and allows the integration of quality assurance measures and impact analysis steps. Traditional workflow tools rarely go beyond automating organizational flows. With HP PPM, it is possible to systematically control and track portfolio authorization and to include decision criteria from integrated application portfolio analysis. The following also need to be understood and fed back into the decision process: the impact of a project to the IT system, whether or not implementation of the existing system increases the complexity of an IT system, and if the complexity makes it impossible to make a change to the system. What is missing in HP PPM, are capabilities to thoroughly analyze a project portfolio financially.

    SAP xRPM has been built to support business project portfolio analysis with financial data – not for only IT projects, but for projects of any kind. Based on information from SAP BI (SAP Business Intelligence) and SAP SEM (SAP Strategic Enterprise Management), this is readily identifiable by its architecture. The tool’s integration with SAP financial business data is SAP xRPM’s greatest advantage. SAP xRPM can access the most recent financial information from the customer’s SAP system anytime. Additionally, SAP SEM allows defining and running ad hoc financial simulations, and a “What-if analysis” can be run as part of a portfolio assessment. As opposed to HP PPM, SAP xRPM shows weaknesses in process control and in the area of specific IT portfolio analysis needs. In this area, the integration with development and application lifecycle technology is missing.

    Conclusion
    The decision for the right portfolio and project management solution normally depends on its integration with the management information and tools of the project resources. Missing integration means additional effort and challenges for the planning and execution. HP PPM and SAP xRPM deliver unique integration but into two very different areas: application portfolio versus financial information. The article “PPM – Alibi without Impact Analysis” provides further information on which functions should be covered by a portfolio and project management solution, and how different vendors with their products differentiate themselves.

    The logical consequence from the above positioning could be a complementary use of both HP PPM and SAP xRPM. This way, portfolio management can profit from the strong process engine of HP PPM and the analytical capabilities of xRPM. From a technological point of view, the two solutions can ideally marry, and HP PPM provides the technological capabilities to do so. It can also integrate a lifecycle product like SAP xRPM Architecture, concepts and target use of the tools are different. For this reason, the key to a successful project portfolio management solution is to combine both tools and precisely define the requirements upfront. Only then can the combined HP PPM and SAP xRPM be designed, and failure can be prevented. HP PPM properly integrated with SAP xRPM can be PPM at its best!

Powered by