Are You Really In Control of Your SAP Change & Release Process? Part 2

Introduction

In this two-part blog series I am taking a look at some SAP change and release edge cases that have the potential to catch out even those organizations with a decent ‘core’ process based on things like automated checks, notifications and deployments. They’re even more likely to rear their head in the kind of spreadsheet-based processes which we find are still all too common in many businesses. The goal is to help you clarify where your business stands and whether you are unknowingly taking unnecessary risks which - in a worst-case scenario - could lead to significant Production outages.

Safeguarding Production

In part one of the blog, I covered Development-related scenarios, but while ensuring a quality Development environment is a necessary foundation for a secure and efficient change management process, safeguarding Production is probably the key objective. So now it’s time to look at the really important issues – that is, the ones related to your Production systems. There are five common challenges that, in my experience, don’t get the attention or consideration they deserve and all too often cause unpleasant outcomes.

1. Transports that should never make it to Production

Certain transports may only be intended to move to Test systems but unless you have the right controls and workflow with which to enforce this policy, there’s every chance that they might spill over into Production. In fact, a solid core process that keeps systems ‘tidy’ and properly aligned might make this even more likely.

Obviously, the risk can vary wildly, since the potential impact is completely dependent on what is contained in the non-prod transport. But there’s no doubt it could be significant. For example, what if you have a program designed to create dummy data in your QA system? Such a program which would corrupt the integrity of a Production system. Or what about security-related changes which allow a relaxation of controls in Non-Production systems? It could be a compliance nightmare if those get to your live systems.

What questions should I be able to answer?

Do you have robust criteria you can use to categorize changes as “Non-Production only”?
How can you reliably indicate whether a given change should be handled as “Non-Production only”?
Do you have a fool-proof way to ensure that such changes cannot be deployed to a Production system?

How ActiveControl can help?

Configure a “Non-Prod” change type to automatically “complete” the change when it has reached the final test system, so that it is removed from the workflow and the queue. In addition, block such changes from being approved into the production system

2. Very fast deployment (a short time between creation/release and Production import)

At Basis Technologies we’re all about helping customers to reduce cycle times (how long it takes to make a change and get it to Production), but it’s always done with a focus on quality and risk avoidance. We come across plenty of organizations who have taken a slightly different path and have – perhaps with the best of intentions - attempted to accelerate delivery of SAP change without appropriate tools or processes in place. The outcomes are not always pretty.

Very short timescales between transport creation and their import to Production can be an indicator of a lack of real control and often result in common problems like overtakes or missing dependencies. And those are probably the good outcomes! Short cycle times and fast movement of change are laudable goals but it’s critical to understand the level of risk that your process exposes you to.

What questions should I be able to answer?

Do you know how many transports go from transport release to import in Production in under 24 hours?
Would you expect that number given the length of your typical release cycle is monthly?
Can you evaluate what proportion of your changes are being handled as “Emergency Changes”?
Do you have the means to tell whether all the necessary checks (coding, testing, validation) have been completed for each separate transport?

How ActiveControl can help?

Emergency Change Type - Configure an “Emergency” change type and associated workflow to provide a fast track for critical updates that ensures all other changes go through the appropriate checks and steps.
Automatically notify developers that parallel development is underway but not yet deployed to Production, to help avoid an overtake and promote collaboration.
Reporting – Stay in control of what proportion of your changes are using the emergency change type. If it looks to be growing, understand whether it is being mis-used and treat the root causes.

3. Very slow deployment (a long time between creation/release and Production import)

There’s a flip side to the problem of excessively fast cycle times (whether they’re caused by abuse of process or a lack of control in the first place) and that’s very old transports which have yet to make it to Production. I’ve seen transports that are more than one, or even two years old and still in development. That’s an incredibly risky scenario. Clearly it’s never the expectation that a transport will take so long to get to Production, so the impact when it does could be very different from what was originally intended.

The biggest risk is that the configuration or objects contained within those transports might be out of date, resulting in a downgrade of the current production capability. And who knows what the consequences of that might be? (Answer: no-one. Want to take that chance?)

Of course, this is all without even considering how the change control process allowed a requirement came to be accepted, developed, and then never tracked through to a live system…

Re-import of transports that have already been fully deployed to Production somewhere in the dim and distant past is a related issue here, given the associated risk of downgrading the configuration or objects contained within those transports to an older version.

What questions should I be able to answer?

Do you have the means to report on when all the transports in Development were created (and therefore how old they are)?
Are re-imports to Production either expected or allowed?
Do your tools / processes examine or warn you of such old or abandoned transports suddenly coming back to life?

How ActiveControl can help?

Govern & Clean-up – Ensuring that the changes made in abandoned transports, or those that aren’t required, are cleaned-up can be achieved via a combination of auto notification (aging) and escalation, including reminders to the owner and, if unactioned, to others responsible for the landscape.
Monitor & Warn
- Automatically notify the developer that parallel development is underway but not yet deployed (or may have been abandoned) to Production (help avoid overtake / later downgrade
- Automatically observe SAP transport dependencies and conflicts to eliminate overtake and overwrite of changes. Detect overtake and regression issues at transport, object and object key level
- Require additional approvals based on Date Analyzer for transports older than a certain age

4. Governing non-transportable changes

Even if you have the most rigorous transport management process in place, there’s a wrinkle. Certain changes which need to be handled in SAP landscapes cannot be ‘transported’. Examples include server parameter changes or pre/post-import activities which are necessary to ensure a successful change set-up.

But the fact that they’re non-standard in terms of workflow doesn’t mean these are unimportant. In fact quite the contrary – these are things that could break your Production system if not handled appropriately. If manual activities are not a part of your process you run the risk that they are forgotten, or that some servers and parameters are inconsistently aligned. Outcome? Yet more issues.

What questions should I be able to answer?

How do you handle non-transportable change today?
How do you ensure such changes are “complete” and get deployed to all target systems?
How do you ensure that related changes cannot be deployed until all non-transportable changes are complete?

How ActiveControl can help?

Manual Activities - ActiveControl allows the inclusion of manual activities as pre- or post-import steps, ensuring that notifications, audit trail, approvals, etc are handled for non-transportable changes within the context of the change being deployed. It will also ensure that dependent activities, e.g. transport import, will not go ahead until such activities have been completed.
Standalone Activities - In addition, manual activities can be modelled standalone and tracked to confirm they have been completed in all target environments before the high-level change can be completed.

5. Sensitive timeframes

So we come to the final hurdle. The last thing that could trip you up. You’re controlling the stuff that’s not supposed to get to Production. You’ve made sure no-one’s abusing the system to get things in too fast, and you’ve weeded out the zombie changes that take forever to get out of Development. You’ve even got to grips with non-transportable change and made it a traceable part of your change and release process. But even with all that, there’s still a chance that problems might occur, and there may be times when that simply isn’t acceptable.

Periods like month-end, year-end, or particular shipment peaks for your business (e.g. Black Friday) might be extra-sensitive times during which change needs to be more thoroughly examined or even stopped to be 100% sure there will be no disruption. Though with ActiveControl in place most of our customers find this is no longer an issue, some businesses still take this kind of ‘zero risk’ approach.

What questions should I be able to answer?

Do you really have the means to prevent or limit changes during critical time periods?
Do you have a rigorous, auditable approval process for exceptions, and if so how do you ensure that it’s enforced?
What’s the opportunity cost of limiting innovation for one or more periods each year?

How Active Control can help?

Change Factory Calendars - Active control itself can have an associated factory calendar defined to require additional approvals during what you would define as sensitive times for your business
Minimize risk – ActiveControl’s suite of over 60 analyzers and highly customizable approvals workflows mean that most users have the confidence to continue deploying change throughout the year.

Conclusion

So that’s it. Eight scenarios across two posts, which I hope have either highlighted some issues you hadn’t previously considered, or stimulated some consideration of their potential importance. Either way these are the kind of things that can help you to gain real control over your SAP change and release process.

Automation software like ActiveControl can help you to do just that, providing a powerful way to get on top of all of these issues without implementing cumbersome, hard-to-maintain processes for each. If you would like to learn more about how ActiveControl can help to keep your Production systems safe (I haven’t even mentioned our transport backout function), please don’t hesitate to get in touch.