• No results found

Two Value Releases per Year. How IT Can Deliver Releases with Tangible Business Value Every Six Months

N/A
N/A
Protected

Academic year: 2021

Share "Two Value Releases per Year. How IT Can Deliver Releases with Tangible Business Value Every Six Months"

Copied!
72
0
0

Loading.... (view fulltext now)

Full text

(1)

Two Value Releases per Year

How IT Can Deliver Releases with Tangible Business Value

Every Six Months

(2)

TABLE OF CONTENTS

0 LEGAL DISCLAIMER ... 4

1 IMPROVE VALUE CHAIN AND REDUCE SG&A COSTS IN FAST CYCLES ... 5

1.1 New business models require innovation and speed in IT ... 5

1.2 IT & SAP - the Business Contribution and Value Center ... 5

2 REQUIREMENTS AND RELEASE MANAGEMENT COMBINED WITH SAP UPDATES ... 7

2.1 Managing Requirements from Business Users ... 7

2.1.1 Gathering Big Ideas: Project Portfolio Management ... 7

2.1.2 Gathering Small Ideas: Requests for Change ... 8

2.2 Release Management ... 9

2.2.1 Overview and Benefits of Release Management ... 9

2.2.2 Release Categories ... 10

2.2.3 Change Categories and Priorities ... 13

2.2.4 Combining Customer Major Release with SAP Innovation ... 14

2.2.5 Quality Gates for Minor and Major Releases ... 15

2.2.6 Release Calendar (per year) ... 15

2.3 Implementation of Requirements governed by Change Request Management and cProjects 15 2.4 Roles in Requirements and Release Management ... 16

3 MANAGE DUAL TRACK LANDSCAPE FOR MULTI-PROJECT SUPPORT ... 18

3.1 Implement a Dual Track Transport Landscape with 6 systems ... 18

3.2 Dual Track Cutover Process ... 20

3.3 Retrofit in a Dual Track Transport Landscape... 21

3.3.1 Semi-Automated Synchronization of Dual Landscape with Retrofit ... 21

3.3.2 When, and how often, to retrofit ... 22

3.3.3 Prerequisites for Retrofit in SAP Solution Manager ... 23

4 LEAN CUSTOM CODE – AVOID, IMPROVE, MINIMIZE ... 24

4.1 Custom Code Management Summary ... 24

4.1.1 The ‘green’ City Model – Lean Measurement ... 24

4.1.2 Custom Code Management - Governance Process and Optimization... 25

4.1.3 Custom Code Lifecycle Management - Transparency & Control ... 27

4.1.3.1 Get transparency about custom code ... 27

4.1.3.2 Process and Architecture ... 27

4.2 Avoid Modifications and get closer to SAP ... 28

4.2.1 Gap management by Innovation Control Center ... 28

4.2.1.1 How the Innovation Control Center works ... 28

4.2.1.2 Blueprint Analyzer ... 28

4.2.2 Monitoring and evaluating existing modifications ... 29

4.2.3 Get Closer to SAP ... 29

4.2.4 Replace clones ... 30

4.2.4.1 Distinguishing SAP Original Objects from Clones ... 30

4.2.4.2 Identifying the Usage Area of Clones ... 31

4.2.4.3 Cross system custom code versioning ... 31

4.2.4.4 Time for Improvement ... 32

4.3 Improve custom code quality ... 32

4.3.1 Custom Code Quality Improvement with SAP ABAP Test cockpit/Code inspector ... 32

4.4 Minimize Modifications ... 33

4.4.1 Usage and Procedure Logging ... 33

4.4.2 Obsolescence of customer objects ... 33

4.4.3 Deleting objects with CDMC ... 34

5 ONLY ADJUST AND TEST WHAT MATTERS ... 36

5.1 Identify change impact on custom developments ... 36

(3)

5.3 Reduced test effort through Test Scope Optimization ... 37

5.3.1 Preparing BPCA ... 37

5.3.2 Standard Change Impact Analysis using BPCA ... 38

5.3.3 BPCA Test Scope Optimization for large SAP change events ... 43

5.3.4 Quantitative Example ... 46

5.3.5 Value Proposition ... 48

5.4 Increase Test Efficiency by Test Automation ... 48

5.4.1 Test Option 1 ... 49

5.4.2 Test Data handling in SAP Test Option 1 ... 51

5.4.3 Test Option 2 ... 53

5.4.4 Test data handling in Test Option 2 ... 56

5.5 Outlook: EhP Scope and Effort Estimator ... 58

6 PERFORM UPDATES WITH NEAR ZERO DOWNTIME ... 62

6.1 Typical Pattern of Planned Downtime ... 62

6.2 Frequency versus Effort and Business Downtime ... 62

6.3 Managing Planned Downtime ... 64

6.4 Minimize Planned Downtime ... 67

6.4.1 Recommendations for ABAP-based systems ... 67

6.4.2 Recommendations for Dual-stack-based Systems ... 69

6.4.3 Recommendations for Databases ... 69

6.4.3.1 Any DB ... 69

6.4.3.2 SAP HANA database ... 70

(4)

0 LEGAL DISCLAIMER

This script is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this presentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including

but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent.

(5)

1 IMPROVE VALUE CHAIN AND REDUCE SG&A COSTS IN FAST CYCLES 1.1 New business models require innovation and speed in IT

Talking to many of our customers globally, there is enormous pressure on being able to implement new business models. Innovation and speed are required to compete with cloud providers like Amazon.com, for example, but up-front investments are hard to obtain and justify. Outcomes have to be predictable.

Very often IT, and even the existing software solutions (SAP and non-SAP), are perceived as inhibitors of required business innovations. This is often due to the extent of modifications, but may also be caused by a lack of the skills and resources required to adapt and change existing solutions. Changing this perception requires a solid strategy and a new way of working together. It requires a platform which enables, not prohibits, business transformation. With the SAP Business Suite on HANA and the SAP Mobile Platform, SAP provides the building blocks of such a platform. Moreover, the SAP building blocks fit together and are managed and supported as one end to end business solution by SAP orchestration. SAP solutions are efficient to run, and they are built to scale. Last but not least, with the SAP mobile platform, every consumer and partner is always connected. In this way, SAP provides the capabilities to run SAP solutions without interruption. Many SAP MaxAttention customers run their SAP solutions as a single global instance, supporting their business operations all over the world.

1.2 IT & SAP - the Business Contribution and Value Center

The speed of change of business models and the entry of strong new competitors into the market, require that change and transformation for more competitiveness be driven from the bottom of the pyramid.

IT and SAP have to become a Business Contribution and Value Center, to actively and timely support the bottom of the pyramid. To achieve this, and become part of the LOB innovation requirements and cycles, requires a new business relationship. A business relationship on the one side based on a KPI framework to measure the performance and quality of existing end to end business processes. Finally, in a joint taskforce, IT and LOB run the 6 sigma improvement cycles. All of this can only work if the improvements which require software solution changes can be made productive in frequent cycles. A value release every 6 months is required. If innovations and improvements are not feasible in the existing framework of installed business solutions and processes, they have to be designed properly. Their feasibility and viability has to be analyzed. Finally, and most importantly, the desirability must be understood and the services/products designed appropriately.

The SAP Business Suite on HANA, combined with the SAP Mobile Platform, are the enabling technologies and platforms to support the innovation required at the bottom of the pyramid. In combination with the business network cloud solutions of Ariba, and the cloud services of Success Factors, value can be delivered extremely fast. The SAP Business Suite is the business data foundation for most large enterprises today, especially for SAP MaxAttention customers. In many discussions with SAP MaxAttention customers they claimed that having all this data is important, but we do not do enough with it. The proper analytical functions could not be implemented on the transactional systems. The CPU and memory capacity was not available, and the transactional systems had too much impact on performance. This resulted in:

 many data copies, and many batch jobs to load and aggregate data

 a lot of manual and delayed work for accruals, profitability analysis, planning and analytics

Now, with SAP HANA, the reasons which made this necessary, no longer apply. There are no data loading programs and no aggregates anymore. All costs are allocated when they occur. All planning is done when required. We can provide much smarter IT solutions overall. The IT landscape becomes much simpler. Business process operation becomes much simpler, since work which needs doing today is now real time. SG&A costs (Selling, General and Administrative Expenses) are therefore reduced dramatically, and we establish one central data pool - one single source of truth.

On top of that, data from suppliers and customers can be integrated to implement an improved value chain, end to end, from suppliers to customers. To manage risk, SAP also provides flexible deployment options. We provide a technology (the SLT platform) which replicates data from the transactional data foundation to an enterprise data warehouse (SAP Business Warehouse on HANA), or to an in-memory database (SAP

(6)

HANA). This allows fast time to market with accelerators or data warehouse functions. Sometimes it is also better to integrate non-company data on data warehouse level than on transactional system level. The SAP Mobile Platform now allows us to establish, on the SAP Business Suite, a user experience on mobile devices, tablets for example. To an end user, this looks like a cloud solution. With SAP Gateway, this new user experience is developed customer-specifically, without disruption and modifications of the SAP solution as the SAP Business Suite is cloud-enabled by the SAP Mobile Platform.

To address these needs, rapid prototyping of new business models and capabilities is required. This is delivered in the framework of Build SAP Like a Factory. Based on building blocks delivered by SAP (Rapid Deployment Solutions, RDS) and industry/market best practices, the new business solution is integrated into the existing solution landscape. All integration issues and perceived gaps are managed in the Innovation Control Center. All gaps are resolved or closed quickly. To bring all these components together, SAP provides a new Build SAP and Run SAP Like a Factory methodology, with the following objectives:

1. A new value release with tangible and measurable benefits for each LOB, every 6 months 2. An upgrade to the latest release and technology, with (Near-)Zero Downtime, every 6 months Typical questions from customers are:

 How do I manage the gathering of requirements of big and small ideas from business users, and translate them into major releases, minor releases and standard changes? How do I integrate SAP updates into this release strategy?

 Are the designed software change processes and transport landscape effective? Do they support the release/maintenance strategy? Are they in line with industry best practices? How can the processes be improved for higher quality or higher agility for changes?

 Can the number of non-productive systems be reduced, without impacting the quality of service? What is the “right” number of supporting systems? What is the best practice for developing multiple projects in parallel?

 How can I predict, for a given SAP shipment (e.g. EhP), what custom code will stop working, and which regression tests will be required? Once scoped, how can I execute the adjustment and regression tests efficiently?

 How can I deploy all these changes with minimum downtime for business users?

In answer to these questions, this document lines out how to design and improve the software change management processes and the transport landscape, and how SAP Solution Manager can better automate tasks and control the process.

The target audiences for this document are IT architects, who ask the questions about software change management above. It is structured in five chapters:

1. Manage Requirements and Releases

Collect big and small ideas (business requirements) and manage their implementation in major releases combined with SAP updates, minor releases and standard or urgent changes

2. Manage Dual Track Landscape

Synchronize highly automated synchronization of dual development landscapes to support parallel deployments (releases) with minimum efforts and risks.

3. Lean custom code

Avoid, improve and reduce custom code enhancements, and modifications, to minimize effort for software maintenance and customer release projects.

4. Only Adjust and Test What Matters

Reduce project effort by focusing development and test on business-relevant changes and by automating tests.

(7)

5. Near-Zero Downtime updates

Ensure minimal business disruption by maintenance and customer release deployments, with the latest SAP near-zero downtime methods and technologies.

2 REQUIREMENTS AND RELEASE MANAGEMENT COMBINED WITH SAP UPDATES 2.1 Managing Requirements from Business Users

2.1.1 Gathering Big Ideas: Project Portfolio Management

Portfolio management, or multi-project management, takes care of high-level project management tasks like planning, controlling, resourcing, and reporting of multiple development projects.

The target of strategic multi-project management is to identify business and IT requirements for new development projects, prioritize them with the business, according to business cases, and with IT according to business benefits, and manage their risks.

Once a program or project is approved, it is handed over to the project management organization for detailed planning and execution.

As well as changes implemented in development projects, updates and housekeeping activities are necessary for production support. Operations, which are usually managed by ITIL processes, provide bug fixes, continuous improvements or standard changes, regularly.

Project developments and production support might “fight” for the same resources, such as systems or people. Such conflicts between production support and project work cannot be resolved in isolation. We need the complete picture which takes into account risks, such as:

 Project delays because key resources are blocked to solve problems which are critical for production

 If the same object is processed multiple times within a timeframe, there is a risk of blocking it, and also a risk of object version mismatches (transport sequence violations) and object downgrades. Additional measures are needed to govern multiple transport requests of the same object. Testing such changes can also become more complex, or even irrelevant (e.g. testing a scenario which will not be imported into production).

To overcome such conflicts, we recommend integrated portfolio management and IT service management processes, which can harmonize the incident and change management processes based on company criteria.

These processes provide an assessment based on unified criteria and weighting, synchronize operational requirements and project management regularly, and define holistic processes for planning, development and deployment. During the process, strict release management eases the coordination of requests.

(8)

You can use IT Portfolio and Project Management (ITPPM) on SAP Solution Manager to manage the project portfolio process.

SAP's portfolio management capabilities give high-level visibility over the entire project portfolio, portfolio analytics, capacities, budgets, and resources.

Portfolio management provides a comprehensive and up-to-date view of the entire portfolio of IT projects, to present the full extent of project risks and opportunities. It allows you to overcome delays that can occur as information is collected from disparate sources. Portfolio management gathers diverse data into dashboards, which are the starting point for portfolio analyses. Portfolio management integrates information from existing project management, human resources, and financial systems, to provide

an overview of the project portfolio and resource availability, and it provides easy drilldown to details.

The overall structure of a portfolio is reflected in the hierarchy of investment buckets. This allows you a flexible categorization of portfolios. Portfolio management supports multi-level portfolio hierarchies. Portfolios can have several investment bucket hierarchies, which can for example represent product lines, organizations or regional structures. Once you have set up the investment bucket hierarchy, you can add items to the individual investment buckets, plan the budgets and resources, and make assignments accordingly.

You use financial and capacity planning to store and plan financial and capacity data for your project, and to maintain actual cost data. You can maintain financial and capacity planning data for an investment bucket, a scope item, or an initiative. You can also enter negative values for financial and capacity planning. After you have saved your entries, the system calculates the values according to your customizing settings.

Portfolio items represent objects (project proposals, concepts, for instance) that should be analyzed within a portfolio. You can compare portfolio items or initiatives in a scoring model, based on quantitative key performance indicators. This enables decision makers to make informed decisions about portfolio items or initiatives. You can implement different scoring models to aggregate data. The quantitative scores of a scoring model are obtained either from portfolio item or initiative attributes, or the results of questionnaires. You can use qualitative responses to questionnaires to derive numerical scores for risk, strategic fit, feasibility, and other types of soft data of portfolio items or initiatives. The business value of portfolio items is documented and is the basis for checking value realization in the LoB, once the project goes live and the enhanced IT solution is used productively. As SAP Solution Manager connects to all productive systems in the landscape, the improvements realized can be measured and compared against the expected business case and the business requirements that define the scope of projects.

2.1.2 Gathering Small Ideas: Requests for Change

Requests for change can occur daily, from various sources, e.g. a problem to be solved because of an incident (break fix), a minor enhancement to an existing business process, or a change to an existing project. In SAP Solution Manager IT Service Management, a request for change can be created to trigger the approval and initiation of the change process. A request for change may include following information:

 Short description of the request for change Parties involved:

o Reporter

(9)

o Chand advisory board o Service team

o Service agent  Impact on the business

o Urgency o Priority

o Categorization of the request for change (business process or service effected)  Notes

 Change description  Solution description  Description of workaround  Queries to the reporter  Answers from the reporter

In this phase, all information required to make a subsequent decision about what needs to be changed and what is the impact, is collected. Depending on the impact, a category and priority are assigned to the change, to be able to obtain approval. Thus, small ideas are usually delivered in minor releases or in standard changes, in which transport to production is not bundled. Break fix support is managed in urgent changes, which are transported to production on request.

2.2 Release Management

2.2.1 Overview and Benefits of Release Management

Release management is the process of planning, building, testing, and deploying software and configuration. It ensures that a consistent and cyclic re-occurring methodology of deployment is used, and, reduces the likelihood of errors in production, using formal checks and procedures. A release is the set of software, configuration, processes and documentation required to implement one or more approved changes. A release is a single cohesive entity for development, testing, distributing, deployment and support.

The key objective of release management is to protect the live productive environment while enabling business-as-usual corrections and enhancements to be deployed in a controlled manner. Releases include:

 Major and minor business enhancements

 SAP Maintenance: Support Packages, Enhancement Packages  Problem resolution development

 Emergency fixes

Figure 1 outlines the principles of release management, release planning and a release calendar. In a release with multiple projects, as illustrated in Figure 1, all projects must be aligned when the release enters or exits a quality gate or major milestone.

The uppermost arrow depicts a timeline for which there will be three major releases. Four independent projects are shown in blue. The business owners, requirements analysis, change category and prioritization and the software change management (SWCM) organization will determine in which release a project is deployed. In this example, projects 2, 3 and 4 will be deployed in major release 2. These three projects must be aligned, and commit to ‘Synchronized Transition to Testing’ at the same time, and be aligned when the release enters or exits a quality gate or major milestone (e.g. end of development, testing cycles, and Go-Live).

For larger projects, which need to deliver functionality quickly and at different times, the scope of the project may need to be split by functions, and managed in multiple releases, such as for project 4.

(10)

Figure 1: Rel eases and S ync hroni z ed Tes ti ng of P roje c ts

Incident-related changes are often implemented by customers individually, even if the deployment is not urgent. Releases should be used for all change types. It is best practice to differentiate between standard changes, emergency changes, minor and major releases, to accommodate the different requirements of production support and project development.

There are clear benefits of managing all changes in releases:  A repeatable and reliable software release process

 A commitment to and visibility for the business of what goes live, and when

 The stability of the production system is increased because the frequency of transports to production is reduced, and solid testing of the release components, as one cohesive work package, is ensured.

 Quality gates can be defined as check points to sign off deliverables.

 The overall costs for testing can be reduced by using common regression and integration testing for several projects/changes, as one cohesive work package.

 Risk of inconsistencies is reduced, as forgotten transports or sequence violations are minimized  Administration efforts for transport management are reduced, as all projects move from one phase

to another at in the same time.

2.2.2 Release Categories

Changes need to be allocated/ bundled into a release category. There are generally 4 release categories:  Major release: has a significant release window to introduce major new functionality consisting of

large amounts of new development. Major releases are also used to deploy the latest SAP software versions, to immediately benefit from SAP innovations, legal changes and corrections. Time and resources need to be allocated for the required regression, user acceptance and performance testing.

Minor release: has a much shorter release cycle, and is intended for minor enhancements and problem resolution fixes. Due to the much shorter release cycle of a minor release, there will be

(11)

insufficient time for full regression and user acceptance testing, as conducted in a major release. A limited but targeted testing strategy is needed.

Standard change: is low risk, and the impact is clearly understood, such as certain configuration changes.

Emergency change: must contain only priority 1 changes that will be transported immediately, to solve critical production issues.

In contrast to major releases, minor releases enable changes in weekly to monthly cycles, in a traceable manner. If a user in a business department sees potential for improvement of a certain application, he can create an incident message directly from the transaction. Alternatively, a business process owner can request a small change. The incident appears in the work list of the Service Desk employee, who processes the incident and generates a request for change, if required. The request is approved and classified as an urgent change.

Because urgent changes need to be made in the minor release, the decisions made during the Change Request Management process are sufficient. This saves time, without neglecting the seamless documentation of the change.

Emergency Changes

Standard

Changes Minor Release Major Release Deployment

Cycle On request only Every 1 - 7 days Every 1 – 4 weeks Every 3 – 6 months Change

Categories Emergency only

Standard changes only (non-invasive, low risk and well known impact)

Non-invasive changes (+ re-import of emergency changes)

All types of changes, including invasive changes

Priorities Emergency only Normal Priority Normal Priority Normal Priority

Test focus

Regression test based on results of change impact analysis

UAT and Regression test based on results of change impact analysis

UAT and Regression test based on results of change impact analysis

UAT and Regression test based on results of change impact analysis, Interface Tests and Integration Validation.

Examples

Changes to solve high priority incidents Already approved changes, e.g. storage locations, MRP controller Non-critical configuration, medium priority incidents

New (major) functions,

Support/Enhancement Packages, Upgrades medium/low priority

Fi gure 2: Rel ease Cat egori es - Be st P ra cti ce exam pl e

The test strategies (scope, effort and duration) are different per release category, depending on the level of changes. Figure 3 illustrates the focus and prioritization of test activities.

(12)

Standard Changes Minor Release Major Release

T

es

t Typ

es

Unit Test

Yes (according to standard change process)

Yes (code inspections and peer reviews if possible)

Yes, including code inspections and peer reviews

Scenario

Integration Test No Yes Yes (important)

User Acceptance

Test No Yes (per correction/change)

Yes (usually required for sign off)

Regression Tests

Limited, based on results of change impact analysis

Extended, based on results of change impact analysis

Extended, based on results of change impact analysis Performance/

Load Tests No No

Potentially based on outcome of single activity trace in Integration Validation Additional Tests

(System Tests, Cutover Tests

No Usually no Potentially (depending on

request)

Fi gure 3: Focus and P ri ori ti z ati on of test acti vi ti es

The release to which to assign a change has to be decided during Change Request Management. The decision criteria include the criticality and priority of the change: high risk changes need more testing, and are thus candidates for a major release cycle.

This assignment is made in the assessment and authorization step, which is an early step in the change request management process. It includes:

 The definition of the test scope of a change request

 The central categorization and prioritization of the change requests according to the change categories (defining the change impact) and change priorities

 The assignment of the change request to a release category, based on the change category and priority

(13)

Fi gure 4: Change Reque st M anagem ent – Assessment of the Change Request 2.2.3 Change Categories and Priorities

In the previous section, we mentioned that only changes of a certain category and priority can go into a certain release category. It is important that the change categories and priorities are defined explicitly (“positive lists”) in advance, to avoid discussion in the day-to-day change request management process. Change Categories:

 Change categories reflect the impact and the risk associated with a change. Examples:

o Critical (invasive): Any configuration change or development that will, or could interrupt business-critical services, from a business or technical perspective, (e.g. changes to core transactions, user interfaces or common elements of business processes).

o Non-invasive: Any change that is not likely to affect the availability of one or more entire business-critical services, and that can be reversed in the event of an issue.

o Standard: Repetitive non-invasive changes with known outcomes and defined implementation procedures (e.g. new master data type configuration, like storage location).  The change request classification criteria should be defined explicitly, e.g. based on a number of

end users/countries/business units affected, need for training of end users, invasiveness of the change (new, enhanced, changed process), magnitude of the change (single module, single application, multiple applications), expected effort to build.

 For each change category, levels of decision makers should be defined.

 Define the category “standard change”, as this reduces the assessment and approval load. o The definition of a new standard change type includes the definition of the allowed objects

and required test and validation steps.

o Create a standard change list, including owners of standard changes, and a pre-approved list of who can create and/or release transports containing standard changes.

(14)

o Once a standard change type is approved, a request of this type does not need to be assessed and approved. It will follow the predetermined, documented workflow, including a well-defined test scope.

Change Priorities:

 The change priority indicates how urgent the change needs to be to be applied. Best Practice is to start with two levels of priorities, to keep the process simple.

o Normal: Changes of normal priority are those that can be processed in line with the change category definitions and associated target approval/authorization/implementation schedules. o Emergency: Changes addressing priority 1 incidents. In a priority 1 incident, a severe

outage affects multiple business processes, or an entire business unit.

 A fast track process should be defined, and used for urgent requests. A typical shortcut is that the change manager approves the request directly, and later asks the CAB for approval in a regular CAB review meeting. Alternatively, an emergency CAB would have to approve an urgent request. In both cases, at least a basic assessment of effort and impact is necessary.

2.2.4 Combining Customer Major Release with SAP Innovation

One key element of an accelerated release strategy, delivering measurable business value with each customer release, is to include the latest SAP software versions (OS/DB version, SAP releases, enhancement packages and support packages) at the beginning of a major customer release. New business developments are then automatically based on the latest SAP technology. Combining SAP and customer releases allows you to benefit from latest SAP innovations, legal changes and software corrections immediately, for example to improve of the level of security and performance of your SAP systems.

The following figure illustrates a typical IT calendar, containing all release categories, including SAP software updates.

Fi gure 5: I T cal endar

Most SAP customers separate the implementation of new SAP software versions and customer releases. The new SAP software is implemented by a “technical upgrade” project, with the goal to not change or enhance any business processes. Only corrections which are required to ensure that everything works the same after the upgrade as before it, are carried out.

In most cases, the reason for this decision is the combination of technical and functional changes increase the complexity of the project and, hence the risk of missing the main project goals, to stay in time and in budget, not to compromise business continuity and stability for the end users.

(15)

The latest SAP application lifecycle management innovations in the areas of dual landscape maintenance and the management of custom code, testing and business downtime, described in the subsequent sections of this document, mitigate the main risk factors, and allow you to benefit fully from SAP innovations in your releases.

2.2.5 Quality Gates for Minor and Major Releases

There should be at least three quality gates for a minor or major release:

Scope to build. After the definition of the requirement and before the build, all requests for changes except standard changes (pre-approved category of changes) need to be approved.  Build to Test: when development is completed (incl. developer/unit test), and before the release

is tested, assess the status of the release and ensure that only transports of proven quality are moved to the testing system. This quality gate is optional for smaller changes.

Test to Deploy: based on the test results before the deployment, the final go/no-go decision for deployment is made. Do this for all changes and check that the operations team is well-prepared.  Large scale changes and projects can have additional quality gates.

2.2.6 Release Calendar (per year)

A release calendar is a planning tool which tells the enterprise what to expect, and when. Ideally, the release calendar maintained for the enterprise contains all hardware and software activity.

Once release categories have been defined, a release calendar, including major, minor and maintenance events, is created, and communicated to the enterprise.

It is Best Practice to align the release Go-Live dates across all SAP applications in the environment, e.g. one go live weekend for both SAP ERP and SAP APO within a region, for regional implementations.

The release calendar needs to be aligned with the business for freeze periods, downtime scheduling and frequency of shipment of changes.

The release calendar should also include cut-off days, CAB meetings and testing periods.

Fi gure 6: A Rel eas e Cal end ar

2.3 Implementation of Requirements governed by Change Request Management and cProjects Application architects, application experts (customizing) and developers design and program the solution, including adjustment, customizing, and unit testing of their developments.

(16)

When the developers have completed the corrections, testers can test them. Change Request Management transports the changes into the test system in a consistent manner. SAP Solution Manager supports a dual control principle, to ensure that the developers and testers are different people. You can only transport the changes into the production environment after they have been tested.

The release manager implements the changes in the IT infrastructure in an effective, safe, and verifiable manner. The technical operator can then import the changes into the production environment. After deployment into production, the requirement is implemented, and the request for change can be concluded. The typical change request management process for such a change is described in the following figure.

Fi gure 7: Change Reque st M anagem ent P rocess

Change Request Management governs the engineering aspect of the project (architecture and design, build, test, deploy), and cProjects on SAP Solution Manager standardizes and improves project management from a PMO perspective (budget, time, skills, resources). It reduces administrative and system costs by providing project management functions that can be deployed independently, or integrated into your back-end systems (such as Human Resources and Financials). Project Management is ideal for managing phased projects. It delivers highly specialized support for product development, IT, or other types of projects. It supports structuring, scheduling, visualization, operative planning, and execution. You can create templates that you can use each time you create a project, to standardize your projects. You can include phases, tasks, and checklist items from project templates or checklist templates, in operational

projects, or other templates and their lower-level project elements.

2.4 Roles in Requirements and Release Management

Roles and responsibilities are important, and need to be clearly defined and supported by the executive sponsor and the entire organization. Clarity of roles and responsibilities will have a big impact on how effective and successful software change management will be.

Some of the key roles are:

Business Process Owner: Is operationally responsible for one or more processes in a line of business. The business process owner is responsible for:

o Operational process controlling

o Planning and execution of the operational process

o Competence and resource planning of processes on an operational level. Coordination with other processes

Business Relationship Manager: Orchestrates the collaboration between IT and LOB (business process owner) to identify optimization opportunities for the value chain, in two dimensions. Firstly, identify improvements in Customer/Consumer Experience and improve the integration of suppliers. Secondly, identify efficiency and automation improvements, to reduce selling, general and administration (SG&A) costs).

Create Request Review and Close Request Test Change Build Change Assess and Authorize Req Deploy Change

(17)

Portfolio Manager: Makes investment decisions using other people’s funds. Works closely with business relationship managers and a team of analysts and researchers, and is ultimately responsible for the investment strategy in IT.

PMO project manager: Ensures the project produces the required products, to the required standard of quality, within the specified time and cost constraints. Responsible for the project results according to the benefits defined in the business case.

Change Manager: provides a single point of contact, and is responsible for managing change, and the impact on the environment. Responsibilities include:

o Preside over change advisory board meetings

o Ensure received requests for change (RFC) are documented and addressed o Monitor the progress of change through production

o Validate and close the change, with change advisory board

Change Advisory Board (CAB): Consists of individual stakeholders who have decision authority over the implementation of changes. CAB members should have a clear understanding of the business and technology requirements.

o The CAB is led by the Change Manager

o The CAB meets regularly to approve/authorize all major and medium change requests, review the closure of completed change requests, and review the the change process performance indicators.

o Participants need to represent the different divisions, and understand the business needs and the dependencies, impact and risk of a change.

Emergency Change Advisory Board:

o For critical changes, an emergency CAB should be defined, to convene and decide about emergency change requests expediently.

Release Manager: Oversees the major milestones of a release, such as development, testing, deployment deployment, and is accountable for the end-to-end lifecycle and quality of a release. The tasks of a release manager include:

o Release plan scope, execution, compliance and delivery, in particular deliverables from multiple projects and their impact that must come together.

(18)

3 MANAGE DUAL TRACK LANDSCAPE FOR MULTI-PROJECT SUPPORT

The system landscape is a key element of a release strategy. A classical 3-system transport landscape is not sufficient to be able to deliver two value releases to the business. You should support such a release strategy with a dual track transport landscape, as described in the following section.

3.1 Implement a Dual Track Transport Landscape with 6 systems

The dual track transport landscape, also known as N+1, was designed for customers who need to continuously release a significant number of software updates, regularly, and provide a secure and stable production end user environment.

The advantage of dual track transport landscape is the addition of a parallel track to production, which contains a second development and testing instances that will be used continuously to develop, test and release software to the production track, in release waves, according to the release calendar.

This design has the salient and distinctive advantage over the single track that it enables the customer to move the entire project development scope, and all project development teams, away from production – a clear segregation of development tasks from production tasks and their personnel. Minimizing the change activity in the production track, plus the personnel that can make those changes, will empower the production support team’s risk management.

The dual track allows the project teams much more flexibility, as they are not constrained by production controls. For example, the path to production will not be blocked by project testing requirements or maintenance updates. Testing instances can be refreshed as often as the projects demand. More realistic quality gates can be enforced, and not circumvented by production priorities. For example, testing duration and its iterations can be driven by the needs of the projects, not by a production-imposed freeze period. The dual track strategy establishes a permanent set of instances with a consistent and permanent role, ensuring the SWCM teams know which tasks are performed when, and where. This is an advantage over the single track. A single track that handles large developments and maintenance usually requires the Basis team to intervene manually and establish temporary instances. This intervention introduces more risk, as these changes also change the SWCM processes, such as transport paths.

The dual track becomes a permanent software factory, continuously releasing (cutover) new functionality to production, according to the release calendar.

The retrofit functionality of SAP Solution Manager synchronizes dual track development instances.

A dual track transport landscape can reduce risks to production from project development, e.g. if the solution is still in full roll-out mode, there are different organizations with different skills involved, a lot of invasive transports are expected, or there is high risk sensitivity in the company or for the particular solution.

Fi gure 8: The 6- s ys tem dual trac k tran sport l ands cap e The 6-system dual track transport landscape:

 PRD (production instance)

 There are two development and three quality assurance instances: o PSD (production support development)

(19)

o DEV (project development) o QAS (project quality assurance) o PRE (project quality assurance)

 The SBX (sandbox) is temporary, and used to prototype new functionality, for sensitive updates, such as OS/DB upgrades, and for SAP maintenance. There is no transport path between the sandbox and the DEV system.

This instance strategy establishes a more secure production support track, that is shielded from major development activities in the project development track.

The testing instance (PRE) is added to the project development track, to better stagger, test and manage multiple projects with different go live dates. The following figure illustrates this:

Fi gure 9: S yst em Dual Tr ac k Tr anspor t Landsc ape - S t aggeri ng Rel ea ses Multiple releases in parallel:

1. Green Release-1: According to the SWCM Release calendar, Release-1 is scheduled to move to PRE for final testing. At this stage, and as part of the project quality gates, sufficient testing cycles have been executed in QAS to correct all major defects of a project. Otherwise the project is withdrawn from the release, or the Executive Sponsor is engaged. Before transporting all projects, developments, configuration, etc. belonging to Release-1, you copy production PRE into the project development instance PRE. Release-1 can now enter its final regression, user acceptance and performance testing, before being cutover to production.

2. Pink Release-2: Has completed most of the development, and is in scenario testing in QAS, correcting defects DEV.

3. Grey Release-3: Primarily in DEV development phase, initial QAS testing for some developments. 4. Orange Release-4. Development teams are often constrained by project conflicts from a prior release. Customers often use the SBX so that development/configuration teams can be productive with initial proof of concepts, including coding designs. The SBX is not in the transport path, and there are no transports forward from SBX. There are other tools to capture work done there. The 6-system dual track transport landscape, and the proper usage of SWCM processes, should manage most customers SWCM requirements, so we generally do not recommend another track, i.e. a third development environment (N+2).

(20)

The advantages and disadvantages of this landscape are summarized in the following table:

Fi gure 10: S ys tem Dual Tra ck Transpor t Lands cape - Ad v ant ages and Di sadv ant ages

A dual track transport landscape needs processes for cutover and retrofit. These are described in the following sections.

3.2 Dual Track Cutover Process

Cutover is the process in a dual track landscape to move the next release from the project development track to the production support track for go-live. Cutover updates the production track, limiting the impact to production and its supporting instances. Testing, for example, is not a function of the cutover process, as this would considerably increase the time it takes, and would block or complicate production emergency fix capability. Some considerations for cutover are: planned downtime requirements, how to manage production emergencies during cutover, and how long the entire process will take.

Cutover requires all instances in the production track be updated from the project development track. If the maximum downtime window is insufficient to update all instances in one step, the cutover must be staggered. For most customers, SAP recommends the following staggered cutover strategy.

The staggered cutover, as illustrated in Figure 0.5, is to cutover directly from the project landscape PRE into production PRD. In a second phase, production support PSD and PSQ are updated.

Figure 11: Cutover in a Dual Track Transport Landscape – Option-2

The advantage of this strategy is the cutover directly into PRD, which can be done in a period of least activity, such as a weekend or holiday. Once production has been updated, the supporting instances PSD

(21)

and PSQ can be updated in a second phase, which may extend into normal operations. The disadvantage of this strategy is that the cutover process requires some manual steps.

Note: You should not switch tracks, as this will change instance roles, lose versioning history,and, depending on organizational elements mislead development and support teams.

3.3 Retrofit in a Dual Track Transport Landscape

One of the key challenges with the dual track transport landscape is to synchronize (retrofit) changes between the two tracks. This is necessary, to ensure the two landscapes do not diverge. The need arises because changes made to production, to support normal business, must be incorporated into the project track.

Figure 12: Cutover in a Dual Track Transport Landscape – Option-2

This section provides an overview of how to use Solution Manager to support the retrofit process.

3.3.1 Semi-Automated Synchronization of Dual Landscape with Retrofit

SAP Solution Manager supports the retrofit process in Change Request Management but also as a stand-alone function. Retrofit in SAP Solution Manager achieves significant improvements in synchronizing dual transport landscapes. The major advantages are:

 Conflicts are detected automatically.

 Most changes made in the production support landscape can be retrofitted automatically, without manual effort.

 A complete work list of all transports to be synchronized (down to object level) is created, and all changes are logged.

The retrofit process with SAP Solution Manager includes the following functions:

 Developments in either transport landscape are recorded in SAP Solution Manager, so changed objects are known centrally.

 Conflicts between the production support and project development landscape are identified via cross system object lock (CSOL). A conflict occurs when the same object is changed in both transport landscapes.

 When you use retrofit in conjunction with Change Request Management, the process offers synchronization methods to align changes from the production support landscape into the project landscape, depending on the type of conflict and type of object:

o All objects without conflict (i.e. changed only in PSD) are transferred automatically. A transport of copies is created and sent to the project development system.

o For objects with conflicts (changed in PSD and DEV), the synchronization is performed semi-automatically or manually.

 A conflicting workbench object can be adjusted semi-automatically in a split-screen editor, using the SAP Correction Workbench. In rare cases, if the change was within the same area of context, the adjustment has to be made manually.

(22)

 If customizing settings conflict, the version in the production support system is recorded in a BC Set. During import into the project development system, it is compared with the entry in that system, and can be adjusted accordingly.

o Objects that are not supported by tools in the SAP Correction Workbench must be adjusted manually.

o Retrofit is performed at object level: if one object in a transport request must be retrofitted manually, the other objects can still be transferred automatically.

 If an object was changed several times, the changes are retrofitted in the correct sequence.  A retrofit of a change triggered from PSD into the project development system DEV, is considered

in DEV like any other project-related development change, so the adjustment in system DEV is recorded in a new transport request. A separate CTS project as the container for all retrofit changes is usually the best option, but the retrofit changes could also be put into a CTS project with other project changes.

o Putting the retrofit change into the CTS project which is scheduled to go live next – together with other developments – has the following disadvantage: If multiple projects with different duration and Go-Live dates are developed in parallel in DEV, strong governance and release management is required. If the project without the retrofit changes goes live first, object versions might be downgraded.

o Putting the retrofit change into a CTS project in DEV which is dedicated to collect all retrofitted objects (with cutover together with any next project which will go live) has the advantage that the retrofitted objects are always cutover – independently of individual project delays.

 All Retrofit activities are logged and can be reviewed at any time. 3.3.2 When, and how often, to retrofit

As soon as a transport request is released from the production support system (PSD), an entry for the retrofit work list is created.

When to retrofit:

 The retrofit should be done as soon as possible after the transport request is released, to keep the work list manageable

o In a long development cycle in DEV, the number of objects to retrofit can be quite large. The time needed for retrofit increases correspondingly, and needs to be continuously.

 Only tested changes should be retrofitted, to avoid multiple transports to retrofit. So the timing of the retrofit activity also depends on the testing strategy:

o Usually there is not sufficient test data in PSD, and changes are imported into PSQ to be tested. After the change is tested, it can be retrofited. If an error occurred in PSQ and a correction transport is needed, Change Request Management will ensure that the correct sequence of transports is preserved during retrofit.

o The retrofit activity can start immediately after the release of the transport in PSD, if the release of the transport means that the test was OK. (This can be the case if sufficient testing is done in PSD, or if the change is sent to PSQ by transport of copies, and tested in PSQ.).

 The retrofit must be complete before cut-over from the project landscape into the production support landscape, for final release testing. Change Request Management will check if the retrofit work list has been processed, before cut-over can start.

 When managing production support transports in releases, the best option is to retrofit after/with the weekly/bi-weekly minor release import from production support into production.

(23)

3.3.3 Prerequisites for Retrofit in SAP Solution Manager

The retrofit process in SAP Solution Manager has the following prerequisites: 1. SAP Solution Manager 7.1.

 Retrofit functionality already exists in SAP Solution Manager 7.0, but the processing logic is different, and the level of automation is lower than in 7.1. For new Change Request Management and retrofit implementations, use SAP Solution Manager 7.1

2. Change Request Management controls the transports in the production support system, and either Change Request Management or Quality Gate Management (QGM) is used in the project development landscape.

 Change Request Management can be implemented in different variants. The tighter the integration is, the more information can be reused.

 The minimum retrofit constellation is to use Change Request Management to create/release the transport requests, instead of doing this directly in the development systems. A change document , which automatically creates and releases the transport requests in the development systems, is then created and released in Change Request Management. This central transport management can usually be implemented within a few days, and is a viable option even if a non-SAP change request management or IT Service Management tool is used.

 With SAP Solution Manager 7.1, QGM can also create CSOL entries, so a mix of Change Request Management in production support and QGM in project landscape is also aretrofit option.

3. Cross System Object Lock (CSOL) is active

 CSOL avoids inconsistencies due wrong transport sequence, even in a single transport track.  With SAP Solution Manager 7.1, CSOL information is used to identify whether an object in the

project landscape has been modified. This is used to calculate the status for Change Request Management retrofit. So if there is no CSOL entry, auto-import by Change Request Management retrofit is possible, and if there is a CSOL entry, the system performs some additional checks, for example, whether the retrofit can be processed using the split-screen editor.

(24)

4 LEAN CUSTOM CODE – AVOID, IMPROVE, MINIMIZE

Customer developments in SAP systems are an important and easy way of implementing highly customer-specific requirements, and closing perceived functional gaps in the SAP environment. However, they are also one of the key TCO drivers in any SAP solution, and one of the biggest blocking factors for the fast implementation of new SAP software versions, so an enhanced and efficient custom code management throughout the lifecycle, is essential to mitigate these issues while still taking advantage of the business benefits.

SAP supports your custom code management aims by avoiding, improving and minimizing the custom code and individual enhancements in the SAP solutions run by your company. Following the lean principles, this aim will be accomplished by the phases of transparency & measurement, optimization and control. It provides numerous tailored tools and best practices for effective, holistic custom code management (CCM). They analyze your custom code and modifications and their use in your systems to get an overview of all customer developments. The customer developments that are actually used are identified and controlled better, using the functions provided by SAP Solution Manager. The objective is to improve the quality and technical implementation, while reducing the quantity and impact of custom code. Ways of avoiding modifications and moving closer to SAP are described. This helps you to achieve sustainable cost reductions for the operation and maintenance of your SAP system landscape. Leveraging the innovations to control the gaps and minimize modifications, ensures the value of IT, and increases business value.

4.1 Custom Code Management Summary

Today's IT system landscapes are seldom homogeneous solutions. Gaps in the landscape between established software modules are closed ad-hoc, and standard business processes are enhanced as required. Your custom developments are an important element in your system landscape. Such developments are necessary when your standard software cannot map certain business processes as desired, and there is no specialized, ideally certified, solution on the market. A complex amalgamation of standard software, enhancements and custom code results in potential risks, driven by the need to respond quickly to changing business requirements. Program code is implemented quickly, with insufficient focus on sustainability and transparency. Important factors such as documentation, the impact of changes on core business processes, and maintainability, are not taken into account until planned or unplanned events change the overall system landscape and leave a multitude of questions regarding custom enhancements unanswered.

Planned, recurring events such as minor and major software updates, or the introduction of new standard functions, can lead to increased testing requirements and significantly higher implementation costs for your custom developments. Unplanned events, such as new legal requirements, new technology or the need to adapt interfaces for external reasons, also frequently present unexpected challenges to custom enhancements. SAP proactively supports you in the targeted handling of all of these aspects.

4.1.1 The ‘green’ City Model – Lean Measurement

In light of the known characteristics of custom enhancements and custom code (number, quality, type of implementation, extent of documentation, and so on), four primary dimensions that can be measured and evaluated have been identified. They are quantity, quality, impact on core business processes, and classification of the technical implementation in relation to the SAP standard. The model also considers management and software lifecycle.

The visualization of custom enhancements and custom code with these metrics corresponds to the abstract representation of a city with buildings of various heights, colors and locations within it. Every city reflects an individual system within your system landscape.

(25)

Figure 13: Lean Measurement Dimensions of the city model

Staying with this metaphor, as the forward-looking mayor of your own city, comprised of multiple custom enhancements and custom code, you have a number of ways of beautifying or redeveloping it. To keep this “beautification of the city” from devolving into a costly and arbitrary process, in the following we will present the individual dimensions, tools and services with which SAP supports you in your pursuit of a well-run, cost-effective and forward-looking system landscape.

Quantity

In the quantity dimension, customer-specific objects are recorded according to their object characteristics, and categorized according to their technical implementation.

Quality

The quality of program code is an often neglected, but highly important, factor in the development of custom adjustments. In this dimension, SAP has made it possible to measure quality in a comparable way, to maintain quality standards.

Criticality and impact on core business processes

Your core business processes must be stable, ensure maximum availability and correctly map your functional requirements at all times. SAP supports you in the analysis of the most frequently used system processes, and shows you which of your frequently used core business processes are impacted by modifications or enhancements. You receive important information that is helpful for planning software updates or optimization.

Technical implementation

SAP NetWeaver provides a multitude of enhancement options that in some cases go far beyond classical Customizing, enabling you to enhance and adapt standard processes to meet your requirements. Beyond the ability to implement and define implicit and explicit extension points (BAdIs, user exits, enhancement spots), you can change SAP standard code through logged and unlogged modifications. Each of these system modifications has specific strengths and weaknesses, which should be evaluated, based on maintainability, risk and complexity.

4.1.2 Custom Code Management - Governance Process and Optimization

Effective custom code management ensures the quality of custom code functionality and controls the growth of custom code during the implementation phase. The purpose is to review and analyze the setup of existing custom code management processes and to optimize custom code management according the latest SAP best practices. Before the development organization can design and realize Custom Code for its needs, functional gaps, or competitive advantages in how the customer conducts his business, it is important to establish, that these development activities follow certain rules or standards.

(26)

It is very important to validate that these standards already exists, otherwise you will need to create and enforce guidelines for the development organization, before any major custom development. The development standards should address at least the following aspects:

 End-to-end process flow and procedure for the development of customer-specific coding: This process should be defined throughout your development organization. Some customers maintain offshore and onshore development models, whose regional specifics need to be included. Interfaces between regional teams, different departments which develop custom code, business departments (as the requestors), IT departments (as the operators and support organization for custom code) and other involved parties need to be described, and hand off/hand over procedures need to be established, documented, known and accepted. There must be a complete end to end process, from the request for custom code, followed by functional and technical validation and justification of the request, budgeting, specification, design and sign-off, development, tests, business user (functional) validation, technical validation (robustness, performance and maintainability (by operations support department)), deployment of the functionality, and, most importantly, technical and functional documentation.

 The custom development standard must also define and describe the phases in the custom code lifecycle. Similarly to existing standard functionality, applications and systems, your custom functionality passes through different stages of the application management lifecycle. The standard must describe these phases and the related activities. It must be clear who owns which phase, from the request for custom code, through design and development, deployment, operations, maintenance and optimization; who is responsible for which type of action in each phase. Define KPIs, or a general set of criteria are to identify whether it is necessary to enter, e.g. the custom code optimization phase, or replace it by standard functionality (if applicable), and how to retire custom code.

 It should be defined on a strategic and company-wide level, when and by whom custom code is permitted to be introduced. A list of principal requirements for the creation of custom code needs to be established, documented and communicated. This ensures that every time custom code is requested, the request is validated against the list of permissible requirements. For example, allow the creation of custom code only if the core SAP functionality is not modified, or insist that workaround processes be preferred to the creation of custom code (under certain conditions, such as economically acceptable effort, or the extent of the workaround). It should be stated in this section of the custom code development standard, which enhancements are allowed, which are not, which type of enhancements are preferred, and so on. That also means that important aspects of quality of custom code are defined and anchored in your development standards.

 If your organization has to follow specific custom development procedures, these need to be documented in the standard. Your standard could demand a four eye principle or a technical validation/release by a second or third developer; manager approval could be defined here, or the principle of creation of competing programs (which approach is better will be considered further). Anything that defines your procedures and principles need to be documented or added the standard.

 A major aspect and goal of developing or maintaining a standard for custom code development is the quality of custom code. While it is difficult or impossible to define quality in a standard, tools and technology which help to ensure quality, can and must be defined in the standard. The standard can include how requests are formulated and documented, and which tool is used to track and validate requests. For the development activities themselves, tools and technology needs to be mandated, to help ensure the quality of custom code.

As an example, the SAP development standard states that no report, program, or enhancement to existing code, can be deployed (shipped to customers), if the “SAP Code inspector”, a tool in the ABAP Development workbench, reports errors. SAP invests heavily in the maintenance and improvement of rules, which are checked by SAP quality tools (see chapter ‘improve custom code quality’).

The basis for this is the SAP Standard for Custom Code Management and related standards. SAP also provides the ESRV MOS Custom Code Management (V1.1) roadmap in SAP Solution Manager, which gives a comprehensive description of all essential parts.

Figure

Figure 1:   Rel eases  and  S ync hroni z ed  Tes ti ng  of  P roje c ts
Figure 11:  Cutover in a Dual Track Transport Landscape – Option-2
Figure 12: Cutover in a Dual Track Transport Landscape – Option-2
Figure 13: Lean Measurement  Dimensions of the city model
+7

References

Related documents

He proved an able leader in helping the supply chain organization to understand the value of implementing integrated planning and control processes and committing to operate

The rate of extreme poverty in rural areas has fallen from 250 million to 14.79 million people, while public goods and services such as universal primary education, public and

Though, for syphilis prevalence, the differences between current vs ever (seropositivity using antibody testing) infection, as well as the dif- ferences between diagnostics,

Relationship between the contribution of pelagic planktivorous fish to the diet of female and male Baltic perch and their x-3 HUFAs muscle content (%)... Table 1.. 2016b)

The intrinsic value of share was estimated using two stage dividend discount model, than multiple models (P/E Ratio, P/BV Ratio and P/S Ratio), balance models (book value),

In addition to the measures included in this report, the web site also includes mortality measures for Coronary Artery Bypass Graft (CABG) surgery; mortality for Inpatient

Based on the picture given, write an essay on what you and your friends did to help the people who were hit by a hurricane.. In

It is more common with patients with HLA-DR3 Herpes gestationis is associated with Grave's disease.. It is more common with patients with HLA-DR3 and DR4 and most often occurs