The 7 circles of SAP project delivery hell - Basis Technologies
-
Upload
martin-metcalf -
Category
Documents
-
view
30 -
download
4
Transcript of The 7 circles of SAP project delivery hell - Basis Technologies
The 7 circles of SAP project delivery hellWhy system changes are slow, clumsy, and every sane person’s worst nightmare
If you’re anything like a typical SAP-based business, you need a reliable production system that keeps running without fail:
Setting up a new storage location
But at the same time....
Your business is constantly evolving. Anything from:
Setting up a new storage location
To creating a new report for accounts
But at the same time....
Your business is constantly evolving. Anything from:
Setting up a new storage location
To creating a new report for accounts
To re-inventing the market with a revolutionary new offer
But at the same time....
Your business is constantly evolving. Anything from:
Setting up a new storage location
To creating a new report for accounts
To re-inventing the market with a revolutionary new offer
… means you need to make a change to your core business platforms.
But at the same time....
Your business is constantly evolving. Anything from:
And you need to rely on them more and more often these days. In parallel. At different paces.
To different priorities.
Unfortunately, the way things are right now, pretty much every single SAP change threatens
your working systems with major disruption:
In short, most companies open the
gates of hell every time they make a change to
their SAP systems.
Here’s what that hell looks like for most organizations:
The visibility vortex
If you’re the person responsible for delivering SAP releases in your organization, you don’t need us to tell you this:
The visibility vortex
And that’s not just the requests and ideas for potential changes – it’s the actual development, too. Lots of people are working on lots of changes simultaneously. Even dev team leaders don’t necessarily know who’s doing what and where they are in the process.
The visibility vortex
Not to mention the C suite, who’s hopelessly out of the loop.
All of which kills collaboration and makes the system changes in your organization about as transparent as brimstone.
The reason nobody knows what’s going on is that there isn’t a single system in place that
everybody can work from.
Spreadsheet limbo
Instead, Jim is using IT service management software while John, Mike and Laura are each working from a different version of the same spreadsheet.
Spreadsheet limbo
And that’s not even mentioning the exponential document proliferation that happens when you outsource some of your dev and change.
Spreadsheet limbo
So just tracking everything that’s going on is more than enough to keep release managers and IT directors busy (and close to insanity) all day.
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
Ring up the third controller from the left, with a request
for an approval
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
After approval, write an email to your basis guys asking them to deploy the changes
Ring up the third controller from the left, with a request
for an approval
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
Stand over their shoulder to make
sure sequencing is done right
After approval, write an email to your basis guys asking them to deploy the changes
Ring up the third controller from the left, with a request
for an approval
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
After approval, write an email to your basis guys asking them to deploy the changes
Ring up the third controller from the left, with a request
for an approval
Stand over their shoulder to make
sure sequencing is done right
Print out a spreadsheet that’s definitely old news
by the time you bring it to the CAB meeting
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
After approval, write an email to your basis guys asking them to deploy the changes
Ring up the third controller from the left, with a request
for an approval
Stand over their shoulder to make
sure sequencing is done right
Print out a spreadsheet that’s definitely old news by the time you bring it to
the CAB meeting
Re-key changes across several development
systems and hope that they’re identical
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
After approval, write an email to your basis guys asking them to deploy the changes
Ring up the third controller from the left, with a request
for an approval
Stand over their shoulder to make
sure sequencing is done right
Print out a spreadsheet that’s definitely old news by the time you bring it to
the CAB meeting
There’s another nasty effect from all the different documentation silos: You do everything by hand.
Things like:
Re-key changes across several development
systems and hope that they’re identical
Your production system, which is the big beating heart of your business, needs to be able to react to demands quickly.
Agility annihilation
For developers, this means continuous dev and deployment. Not twice a year or once a quarter, but whenever the code is ready.
Agility annihilation
That sounds great, but without an up-to-speed testing setup it easily turns into a business agility killer:
Agility annihilation
Agility annihilation
Because there’s no way you can deploy your changes quickly without the confidence that you’ve tested against production-like data.
But as things are in most organizations, it takes ages to stand up a test system that’s wortht its salt.
And that pretty much means saying goodbye to more agile development. And that’s goodbye to agile business change, too.
Agility annihilation
The torment of QA
Here’s another reason manual testing is still one of the most pain-inducing processes for many businesses:
In the real world of big-organization dev-test-release cycles, there is no such thing as plenty of time, ever.
The torment of QA
And this means that dev happens in a hurry, with coders trusting the testing team to pick up the pieces, tie up the loose ends and hope that the support team fixes anything that needs fixing.
The only problem is that when changes move to test, testers are usually neck deep in work, and up against several bygone deadlines already.
The torment of QA
So instead of prioritizing quality control early on, you end up washing all the dev debris into test, rushing approvals, and trusting in random sampling and sloppy dependency checks.
The torment of QA
The torment of QA
And that knot-in-your-gut-feeling means you just know this kind of procedure is incredibly bad news for
The torment of QA
And that knot-in-your-gut-feeling means you just know this kind of procedure is incredibly bad news for
• The overall quality of your code
The torment of QA
And that knot-in-your-gut-feeling means you just know this kind of procedure is incredibly bad news for
• The overall quality of your code
• The stability of your SAP system.
The torment of QA
And that knot-in-your-gut-feeling means you just know this kind of procedure is incredibly bad news for
• The overall quality of your code
• The stability of your SAP system.
YIKES!
The licking flames of approval
Let’s go back to those approvals for a minute. They’re kind of a big deal, because it’s really hard for anybody to see five levels down into the impact of the change they’re approving.
The licking flames of approval
Wouldn’t it be great if...
People actually had some insight into what elements in the system are affected by a given change?
The licking flames of approval
Wouldn’t it be great if...
A little red flag popped up when you touched a risky object? Or when two developers are making a change to the same one?
The licking flames of approval
Wouldn’t it be great if...
An “ok” didn’t just mean “I guess it’s fine”, but was actually a conscious approval based on a thorough dependency check?
The licking flames of approval
But as things stand, people are authorizing an intimidating number of dev changes without really knowing what is being changed at a technical level.
The licking flames of approval
Which is kind of crazy considering this stuff will eventually come full circle and end up affecting priority number one, which is:
Given all that, it’s really not too hard to imagine the worst nightmare coming true:
A release that you’ve developed and tested. And suddenly, when you’re moving it into production, for some reason, everything goes wrong.
The cutover catastrophe
The cutover catastrophe
And you know: X It will create downtime
X Stop your business
X Enrage your users (or worse, customers)
The cutover catastrophe
And you know: X It will create downtime
X Stop your business
X Enrage your users (or worse, customers)
X Lose you money, every single second
The cutover catastrophe
And you know: X It will create downtime
X Stop your business
X Enrage your users (or worse, customers)
X Lose you money, every single second
X And benefit your competitors.
The cutover catastrophe
And this simple fact makes you want to be responsible for that transport like you want another hole in the head.
You didn’t need us to tell you:
More often than not, SAP changes are
• Slow
• Inefficient
• Unmanaged
You didn’t need us to tell you:
More often than not, SAP changes are
• Slow
• Inefficient
• Unmanaged
• Of uncertain quality
You didn’t need us to tell you:
More often than not, SAP changes are
• Slow
• Inefficient
• Unmanaged
• Of uncertain quality
• And potentially dangerous to your business.
And you certainly know that for most organizations that have invested in a pricey SAP solution, another costly tool to manage that solution isn’t an option.
And you certainly know that for most organizations that have invested in a pricey SAP solution, another costly tool to manage that solution isn’t an option.
So where’s the good news?
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Bring everything together in one place So everyone can track the status of changes and releases
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Orchestrate parallel development So all your improvement efforts, even in a complex SAP landscape, go hand-in-hand
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Embed quality control from day one For faster releases and fewer surprises in test and production
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Actively move changes through your system To avoid the downtime created by manual management and communication silos
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Optimize testing and approval So you can focus on fixing the gaffes, instead of finding them
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Check dependencies thoroughly To make your code safer and more stable
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Instantly back-out failed changes So your operation and profits have a safety net
And this means you can focus on change strategy instead of headache management, save your company a lot of money and yourself the torment of ad hoc, manual, disorganized transport management.
A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:
Our team of indomitable SAP specialists has been through the seven circles of release
management hell and back.
And they’ve created a fire-hardened, software-only, easy-to-implement tool that helps you get the most out of your SAP development, speed up the process and minimize the risk around your dev activity.
And they’ve created a fire-hardened, software-only, easy-to-implement tool that helps you get the most out of your SAP development, speed up the process and minimize the risk around your dev activity.
It’s part of a family of development and performance optimizers that are re-enabling businesses by changing the way they run their SAP systems.
Talk to usWant to know more?
www.basistechnologies.com