Author: bea4x

  • Business Technology Optimization (BTO)

    The New Role of IT
    For many years, all IT departments seem to have taken up the cause of cost reducing. This has changed. Business managers more and more consider IT a lever for boosting growth. Particularly, this means for IT departments to implement new business models and concepts as fast as possible.

    In most cases, IT departments are not prepared to cope with rapid changes. They utilize a major part of their capacity, sometimes 90 %, for routine work such as the operation of the data center. Very often, this means that no capacity is left for implementing the ideas and business processes the CEOs have in mind (source: Handelsblatt April 14, 2007).

    BTO Solutions
    Business Technology Optimization (BTO) solutions support enterprises in optimizing the business value created by IT. The goal is to consistently extend – by using suitable methods and tools – IT´s contribution in areas such as securing competitive advantages, increasing customer satisfaction and minimizing risks and costs.

    The combination of Business and IT perspectives may raise new questions as to the benefit, quality and reliability of an IT service.

    The focus should be on taking into account and improving the effects of IT on business results. The most important issues are: How flexible, fast and effectively do we want IT to react on enterprise decisions, corporate mergers and changed market situations? In which way do we want it to support the control of the product portfolio or the implementation of marketing strategies, and what should IT´s role of a communication platform for enterprise an customers be like?

    These requirements reach far beyond the conventional IT goals: Accounting for a number of bugfixes in development, reaching defined project milestones, or efficiently utilizing the helpdesk may be evidence of successful IT, but not necessarily of a successful business.

    BTO solutions are meant to support the enterprise with methods and tools to plan IT´s contribution to the business more accurately, to increase it efficiently, and to make it visible.

    By no means, BTO is just a project to be applied to one area of IT. Using BTO successfully means to consistently take into consideration the effects of business on IT operation, IT strategy, IT controlling, IT revision, IT process optimization and IT risk management, and, likewise, observe the influence of IT activities in these areas on business. To reach this goal, new methods and technologies must be introduced and efficiently applied.

    About the author:
    Klaus Otto is Sales Manager HP Software Commercial Accounts at HP Germany (Hewlett-Packard GmbH). This article only contains personal comments on the subject.

  • Project Roadmap: Quick Wins with Iterations

    My blog Scoping – A Guarantee for Success through Harmonized Expectations describes how to identify factors that are most relevant to the success of the project:

    • Expectations of all key roles are defined and synchronized from the start
    • The technical system architecture is designed
    • The functional requirements are defined
    • An implementation roadmap comprising project contents, required organizations and project procedure is set up

    Harmonized Expectations and Step-by-Step Implementation Targeted at Partial Success
    Experience has shown that defining and synchronizing expectations is of great importance. With regard to expectations, the project scope plays a major role. Unfortunately, project team members as well as clients often fail to define the project precisely enough, including a variety of options and features into the project. Limited time and budget available for a maximum content are part of everyday business. Teams are getting unfocussed and bogged down in details loosing sight oft the project target. The project clients get impatient, failures mute motivation, and the original business cases are questioned.

    It is well known that projects promise to be successful only if sub-goals are defined ensuring step-by-step success and continuously producing a visible benefit. This is particularly true for long-lasting projects. The main issue here is to focus on the most important and prioritized requirements and functions and adhere to their consistent implementation.

    Implementation Roadmap and Iterations
    One oft he main issues of the scoping phase is to generate a practice-oriented implementation roadmap. This includes clearly defined targeted project objects, a time schedule, and the organization implied. Experience has shown that dividing the project into several iterations with clearly defined targeted objects leads to business quick wins and to a successful completion of the project. To follow this strategy, the most relevant requirements and core functions are identified and implemented in iterations.

    The main goal is to provide constant benefit for the project client and the users as soon as possible. Quick wins are achieved by first implementing those functions which are most suitable to ensure the highest possible benefit. In further iterations, more functions are added to those successfully implied to finally integrate the solution step by step into further processes, methods, systems and organizations. At the same time, a consistent project management und project marketing support the roadmap implementation. Management, client, and users know at any time which functions are available to them, and when.

    Iterations Optimized by Quick Wins
    Dividing projects into several iterations provides decisive advantages. They vary depending on context and task, but in most cases, the following advantages are ensured:

    • System with core functionality which rather soon works efficiently
    • Systematic knowledge transfer to users and business by targeted training at the right time.
    • Quick benefit as a basis and guideline for further procedure
    • Early integration of business organization and building up support services
    • Optimistic attitude towards the project by successfully completing iterations and meeting the expectations
    • Flexibility in structuring the functional requirements and a manageable basis for Scope Change Management
    • Organziational changes are implemented step by step and associated with achieving success
    • Short feedback loops, „lessons learned“, can be implemented in the next iteration

    The Challenge of Implementing Iterations
    Very frequently, a rigid project procedure is set forth by large enterprises. In addition to document templates, this includes specified and standardized rules of phase acceptance. The project passes through several phases, comprising preliminary studies, rough and detailed concept, realization, implementation, and operation. A new phase can only be started, after the preceding phase has been completed. This approach is often contrary to the basic idea and the immense benefit achieved by an iterative procedure.

    It is true that dividing the project into several iterations results in quick wins. But if all iterations, i.e. new functions, are repeatedly forced to pass through all project phases from the preliminary studies to operation,  this necessarily implies disprofit by loss of time and additional effort. The great benefit is given away!

    It is quite important to find common solutions in collaboration with the responsible persons, for example, from the project management office (PMO) or from quality control. Experience has shown that it is recommendable to have the most prominent mile stones approved „officially“, whereas the individual iterations can be approved by project members and application of quality assurance measures. A step-by-step extension of this approach to include scoping and phase acceptance which is attuned to an iterative concept would be useful.

    beteo Iterations

    Summary
    The benefit of an iterative approach is enormously high. In the context of standardized and rigid project implementation, this can be quite a challenge. However, addressing it at an early stage, iterations can easily be integrated into the existing environment. In a further step, this concept can be extended to include scoping and phase acceptance particularly attuned to iterations.

    After harmonizing the expectations of all key roles and prioritizing the requirements, all functions should be divided into individual iterations according to their importance. This allows you to focus on the core features and the highest possible benefit. Systems are available to users at an early stage, providing efficiently working core functionality. There is a fast and well-structured knowledge transfer leaving more time for the organization to implement changes. Quickly and successfully completed iterations result in a sense of achievement and promote an affirmative attitude  towards the project.

    In addition, the iterative approach allows you to carry out faster feedback loops and more flexibility in planning further iterations. This ensures quick wins and step-by-step success of the project.

  • Forrester: HP is Number 1 for Functional Testing

    According to then most recent Forrester Wave Report dating July 8, 2008 on Functional Testing solutions HP clearly keeps on leading this market.

    Using 96 criteria Forrester evaluated 6 solutions and came to clear results:

    • HP continues leading the functional testing market since it acquired Mercury Interactive in 2006.
    • IBM has a very promising product roadmap and has expanded its support for packaged applications.
    • Borland Software and Compuware reinforced their position with their respective users – Borland for the more technical testers, Compuware fot the less technical.
    • Empirix‘ and Seapine Software’s offers are less-costly but also functionally less-capable mainly because of limited support for applications and technologies.

    Overall Forrester observed functional testing solutions not only keeping up with new technologies but also improving functionality for manual testing, test management and test automation.

    Forrester Research evaluated the the most recent available versions of the following functional testing offerings:

  • A Strategy is a Story

    As a reminder of what a strategy is and what it should provide:

    • It organizes and coordinates a variety of acts and decisions of one or more persons to a common goal,
    • it makes this in a deliberate contrast to other perhaps possible approaches, takes a conscious decision and risk.
    • Effectiveness is achieved not only with orientation, concentration and determination, but also by the “surprising” innovative difference in the competition.

    If a strategy works, it must be told as a thrilling story. The people involved with the company need to understand the strategy, reproduce it in theirs experiences and realize it in theirs actions.

    1. What decisions have to be made in the overall context and to implement in action? What is the difference before and after? How do I know when I’m the right track?
    2. What are the obstacles, risks, resistors, which must be overcome? What “adventure” must be dealt with? With what result?
    3. What is the key difference to the competitors? What is the pivotal point for success of the strategy? When exactly does the strategy come into reality?
    4. How does the strategy fit to our company, the characters and the temperaments of people, to our values and cultural patterns, which are available for the necessary decisions and actions?
    5. Is the designed suspense conducive and full with power? Is it overstraining or subchallenging for the development of company? Must there something be added?
    6. Is the story, which tells the strategy, in total  coherent and credible? The people involved can they identify? Which adapters still need to be supplemented?

    The narrative review of your strategy improves the effectiveness and power. Weaknesses can be found and the risk of miscarriage is reduced. And the strategy is processed for the systematic communication within the company.

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

  • Project Scoping – Aligning Expectations

    Projects often fail to be successful due to diverging, badly aligned expectations
    Dozens of statistics seem to suggest that there are dozens of reasons why projects fail to be successful. However, a great deal of them are attributable to vaguely defined objectives, problems related to technical architecture and a lack of management support. These causes, in turn, are in most cases due to either too optimistic or diverging expectations of the parties involved. Very often, projects are initiated without having identified and documented expectations as well as requirements on the part of all expert and management key roles.

    Scoping: Efficient approach to defining project content
    This is where scoping comes into play. This approach is extremely helpful when it comes to describing the functional requirements, defining project content and an adequate proceeding, and designing the technical architecture. The scoping phase targets at mapping the relevant context, ideas, requirements and prerequisites of all parties involved in the project in a well-structured way, reaching an agreement upon the project scope and establishing the project guidelines. Fixing an order of priority and laying down a clear structure makes the demanded objects transparent, well-defined, and synchronises the expectations of all persons involved. Experience has shown that syntonized expectations are one of the most important factors to ensure the success of a project.

    Scoping Ansatz

    Scoping phase in practice
    Several steps are necessary to reach these goals. Most of them must be executed in close collaboration with the client. This includes:

    • Defining a common objective and selecting relevant persons for workshops and interviews
    • Informing or training the project team members in order to create a common basis
    • Recording of business-related and functional requirements, needs and ideas during workshops and interviews
    • Understanding the technical requirements and challenges, the system landscape, and the necessary integrations
    • Prioritization with regard to quick wins and a high payback
    • Attending to a common understanding and identifying the points where the project gains momentum
    • Elaborating a detailed implementation roadmap, including time management and organizational planning, split up in iterations optimized by quick wins
    • Presentation of the results to the management

    Implementation Roadmap
    One of the most significant results from the scoping phase is the roadmap for implementation. The roadmap includes not only project content and proceeding, but also a time schedule and organizational planning, and provides a basis for the project. It is recommended to split up the project scope into several implementation iterations in favor of a clearly structured step-by-step planning and in order to immediately provide maximum benefit to the project client.

    Core factor of success
    Principally, scoping should be a closely integrated part of the project methodology. If, for example, there are no interviews, this will cause lead to a sign of alarm at the quality gate. If necessary, this item must be re-worked – or there is a clear decision not to do so.
    Experience has shown that the choice of persons involved in the scoping phase is of great importance. The key roles might vary depending on the task and the context, but it is indispensable to involve the client, the top management, the users, and the experts as regards content and technical issues. As soon as the participants are selected, the core factor of success are their availability as well as competent scheduling. We also recommend to have two persons hold the interviews in order not to loose sight of important aspects and to ensure complete documentation.

    Summary
    Scoping is a good way of fine-tuning project ideas and analyze the approaches to solution finding. Preferably, the scoping phase is an integral part of the typical procedure of all projects. As all information is collected by relevant key roles, the required data can be accessed, translated into requirements, and given a defined level of priority. From this, the concrete implementation roadmap is derived. Thus, the project idea is clearly defined, and the project scope is fixed with consideration of processes, organization, systems, including required system integrations, and other dependent processes. All persons involved in the project have a common interest in and are focused on the same issues. Their expectations are synchronized. The momentum gained by this common basis is the most significant stimulus for all to make the project a success story.

  • Software Archeology – how to Successfully Change SAP Releases

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

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

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

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

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

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

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

  • SAP Change Impact Management – PHW Business School and beteo study

    In collaboration with the PHW Business School, Zurich, Switzerland we are conducting  a study in the IT Change Impact Management area.

    We are analyzing a specific challenges of international corporations using SAP as their corporate software globally and specifically the challenges of their IT development organization because of impacts given by system consolidaton centralization efforts.

    Fundamentally we will focus on the following issues:
    – what benefits were and are to expect from these consolidation projects?
    – What are the (intermediate)  results?
    – What new challenges are there for further developments in the centralized SAP system and development world?

    The goal of the research is to analyze trends, identify possible sources of trouble and generate possible solutions for the new challenges.

    In order to accomplish this, we will conduct expert interviews with selected contacts in person and/or on the phone. The results will be available to all interview partners. We want to actively increase the interaction between client, partners and experts in this study.

    Interested? Leave a comment in the blog or get in touch with us, studie@beteo.ch.

  • Configuration Management for SAP Customizing?

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

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

    Comprehensive SAP configuration management all across the SAP landscape is meant to ensure overall integrity of the objects involved in SAP development, including ABAP as well as non-ABAP objects:

    • The use of well-defined standardized naming conventions clearly reveals to which organizations, areas and projects the objects belong.
    • All changes to objects, including individual customizing settings, are documented. At any time, it is obvious who is – and at which times – the owner of settings, who is entitled to make and has made changes and for which reason. This allows the changes to be tracked afterwards, which is an equivalent to versioning.
    • The documentation also includes the information as to who and what and who depends from a defined customizing setting. This is an integral factor of reasonable impact management.

    In the context of each change to the SAP landscape systems, it must be made sure that the rules listed above for practicing a comprehensive SAP configuration management are observed. This, again, requires a strict organization of the change und transport management. Naming conventions for transport objects and transports must be established, transport packages must be grouped according to their content, organizational and technical processes must be clearly defined and adhered to.

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

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

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

    Unfortunately, the opportunity for global enterprises using large SAP systems to improve the quality and to save costs by investing in SAP change and transport management is very often not seized, because it is thought to be technically complex. But if the challenge is taken up it soon shows that the problems are more political or company-related than of a technical nature.

  • Proof of Concept – Less Risk for System Implementations

    Scoping for defined requirements and harmonized expectations
    The scoping approach allows you to define requirements, expectations and project scopes when systems, methods and processes are implemented. This results in aligned expectations, a well-designed system architecture, defined requirements as well as a structured implementation roadmap. If the roadmap is implemented in several iterations, quick wins are achieved in addition to a direct benefit to the project client and the users.

    Technically complex problems as a challenge
    If system implementations are planned in technically complex environments, in addition to the purely technical requirements that have to be met, the following questions should be addressed:

    • Is a clean system installation possible?
    • Can the solution be integrated into the existing system landscape?
    • Which is the best way to coordinate the installation and integration with the IT organization
    • Are all used technologies compatible?
    • Which interfaces are affected, and in which way?
    • Can the described functions really be implemented?
    • How does the system behave with regard to usability?
    • Will the system be accepted by the users?
    • Which are the actual costs to be faced?
    • Which technical capabilities and roles are required for the implementation?
    • Can the planned benefit really be achieved?
    • How about the capabilities of partners, manufacturers and providers, and what characterizes collaboration with them?

    The above questions are only part of the criteria which are relevant to success. To answer them, further activities are necessary. Very often, there is a great deal of uncertainty about the technical and organizational feasability of the project as well as about the time and costs involved.

    Proof of concept: minimization of risk in decision-making process
    In the context of system implementations, proof of concept (POC) equals a technical feasability study. POC can be used as a part of scoping to check for technical and organizational feasability of projects. Prior to execution, the criteria relevant to success and the subsequent steps must be clearly defined in order to ensure maximum benefit. For working out a POC, it is recommendable to implement a mock-up or a prototype comprising the core functionality. This allows to test the functions, define them accurately and involve the users in the planned project at an early stage. Proof of concept reveals which requirements can be met in which way and which functionality demand workarounds or additional solutions. Thus, time and cost expenditure for installation and integration into the existing system landscape can later be well estimated and planned in agreement with the responsible IT organization.

    Pilot pojects as a performance indicator
    Experience has shown that working with pilot projects significantly adds to success. The prototype is used in productive systems on a limited scale. There are various alternatives to proceed:

    • limited user group
    • limited functionality
    • limited process scope
    • limited and/or isolated system environment

    Working with a pilot project allows you to rather accurately pre-estimate if the system in action meets all requirements, covers the planned functionality and proves to provide the expected benefit.

    Summary

    Proof of concept allows you to find out if the implementation of a system can be technically realized, and to evaluate the capabilities of manufacturers, partners and providers as well as the quality of collaboration with them. In addition, the expected time and cost expenditure for installation and integration into the existing system landscape are made calculable and can be planned in accordance with the responsible IT organization. Prior to execution, the criteria relevant to success and the subsequent steps must be defined.

    It is recommended to create a prototype which includes the core functionality, i.e. those functions from which the greatest benefit is derived. This allows the users to be involved at an early stage of the project; as a positive result, user-friendliness and acceptance by users can be evaluated and taken into account. If the prototype is tested in the context of a pilot project with either a limited user group, limited functionality, limited process scope, or on a separate system, this will result in a realistic view of the potential of benefit. Proof of concept is used to work out facts and foundations in order to minimize the risk of making inappropriate decisions in the process of system deployment.

  • Proactive Impact Management – the basis for BTO

    Business Technology Optimization as a Challenge
    Business Technology Optimization (BTO) targets at a closer collaboration of IT and business – nothing really new, just a daily challenge to the CIO. To support SAP IT organizations in reaching this target, beteo has designed the beteo Impact Hourglass.

    beteo Impact-Sanduhr

    With the beteo Impact Hourglass, principally all objects of the business domain (in the following BD) and the technical domain (in the following TD) which are involved in changes are seen integrally, comprising system and development, as well as in relation to each other. Thus, business and IT aspects of a system can be comprehensively understood, viewed and analyzed.  Relations between objects of both areas can selectively be established, according to the object type. Due to interdependencies, effects of changes can be mapped and understood across all levels.
    Persons from business and IT who are planning a change and are in charge of apecifying the change requirements can use the beteo Impact Hourglass to have all dependent objects from BD and TD displayed. This means that all objects which might have to be changed can be identified. This view including the technical objects as well as the descriptions of the business processes and all other describing objects of the development ensures that all objects affected by the change can be managed.

    The beteo Impact Hourglass is a suitable instrument to allow all persons involved in SAP system analysis processes – from planning to implementation of changes – to proactively carry out system impact analyses and simulations. Before there are any changes to the system, all possibly affected objects are identified. Special filters can be used to have particular object types and their relations displayed. So it is easy for users of the beteo Impact Hourglass to keep track of things. What is new about the beteo Impact Hourglass is that it not only allows viewing objects related to technical implementations (results from development and testing), but also organizational processes (business processes, activities, depending organizations) and describing objects (concepts, specifications, training, testing scenarios). Changes and their effects can be exactly planned, analyzed and controlled, and potential for optimization is revealed right away.

    beteo Impact analysis
    Basically, beteo Impact Hourglass enables three types of impact analysis.

    • Concurrent Impact Analysis
      The Concurrent Impact Analysis shows how many parallel changes are potentially made per object. This facilitates identifying risks on the one hand, and the grouping changes on objects on the other hand to address them at once. In most cases it is quite helpful to know in advance that there are upcoming concurrent changes to particular objects.
    • Dependency Impact Analysis
      The Dependency Impact Analysis shows which objects of the selected object type across the whole system and the development documentation might be directly affected by a particular change.
    • Interference Impact Analysis
      Starting from an object, which for example has been identified through Dependency Impact Analysis, the Interference Impact Analysis finds out which superordinate objects not directly connected to the same change are additionally affected. This might reveal processes using an object which has been indirectly affected by a change to another business process and therefore has to be tested after the change, because technically the same functions and settings are used in the system.

    Versioned documentation of Business Domain (BD), Technical Domain (TD) and related objects of system development

    The BD mainly includes organizational objects and objects resulting from describing system development measures. With the beteo Impact Hourglass, these objects and their relations can be documented and to each of them a lifecycle can be assigned. This ensures that the describing, organizational objects for each change request are identified and kept updated. Change requests not only refer to technical objects, but also to business objects and to all supporting objects which are created and customized in the context of the development process.

    The versioned documentation of the objects of business process management makes it easier to understand the evolution of all objects. Dependencies on real and describing business domain and technical objects and interdependencies between these objects are identified. Changes to programs and customizing activities can be presented and understood comprehensively and in relation to each other.

    Summary
    From the early stage of planning a change, before it is actually executed, the beteo Impact Hourglass provides a clear and complete conception of its effects and the possibility of evaluating them. This allows all types Impact Analyses to be proactively carried out and subsequently be tracked in the project phase.  Decisions in the context of practicability, planning of implementation – particularly of parallel upcoming changes – and project management and controlling can largely be improved and simplified.
    There are a number of useful tools available for the reactive Impact Analysis applied to objects of the technical domain (TD), such as IntelliCorp´s LiveCompare, Panaya Inc.´s Panaya, IBIS´ RBE Plus and Hewlett Packard´s Universal CMDB. However, they basically support the programmer and not as much the business analyst. The beteo Impact Hourglass integrates business processes into impact analysis and allows enterprises to benefit from Business Technology Optimization (BTO).