As always, SAUG Summit is a great opportunity to catch up with customers and other Australian companies running SAP. In particular, to talk about their experiences and future plans and their progress towards automating their SAP DevOps Toolchain. When I was walking around the exhibition hall talking to the other exhibitors several common themes emerged. Namely, SAP DevOps, Agile Development and Digital Transformation. All reflecting the growing trend among SAP IT support teams to increase the volume of change and increase the speed at which it is delivered.
A question our customers repeatedly ask is: “How can we effectively manage risk that change introduces to production? “. An excellent question to include in your current portfolio of areas to address with your change management process plan. To effectively manage risk, one must be able to identify and categorise risk. That is, could the change cause a problem, and what happens if it does (likelihood and impact)? For simplicity, I’ll cover two obvious categories, high risk and low risk.
After many years analyzing customers’ change control processes we’ve learned that no two processes are ever the same. However, I’ve noticed that when a company sets out to improve their change control processes, they tend to make them more complex than necessary. Particularly when attempting agile processes for the first time.
The recent article Ringing Down The Curtain On Change Management Theater by Forrester analyst Charles Betz made me think about the future of SAP change management. What is it going to look like in 3, 5 or 7 years? One thing that is certain is that it won’t look the same as it does today. Over the years, I’ve seen SAP customers go from managing SAP change with spreadsheets, emails and ITSM tickets (and many still do it that way); to ITIL-based, semi-automated processes; and now towards business-driven automated Agile/DevOps practices.
I recently caught up with an SAP support team manager at a customer who has been using Rev-Trac change control automation software for about 4 years. At the time of implementing Rev-Trac, the customer was a “Green Field” SAP installation. This meant Rev-Trac was installed with the initial SAP systems and every transport from the very first development transport created has been tracked and change controlled using Rev-Trac. I asked what some of the most valuable benefits were Rev-Trac had brought to the support team.
Earlier this week I spent a day with one of our technology partners’ customers at the EPI-USE Labs user group event in Sydney. Part of the day included a presentation from David Powell, General Manager, IT Security Strategy at the National Australia Bank (NAB) around the criticality of IT security at both an individual level and at a corporate level. The presentation was both fascinating and eye opening, to say the least.
In the rush to get to SAP’s HANA database, some customers have not given proper consideration to the Z-code that has been developed over the years and its compatibility with the new DB. During the initial SAP implementation, nearly every company that I know of was “special” in some way and choose not to go with the SAP standard. Therefore, we all have substantial Z-code we used to fill that and other gaps in our processes. Now with the HANA DB on the scene, some are finding that post migration, some of their Z-code either won’t work or has some serious performance issues running on the HANA database.
That has proven to be a difficult question to answer accurately because the Solution Manager scope has been expanding over the years to cover many different functional and solution support areas.
One of the best resources to help understand the overall size and scope of Solution Manager is the recently published SAP Solution Manager 7.2 Adoption Framework. This lengthy document describes 40 different functional areas in Solution Manager 7.2. SAP also provides some rough guidelines regarding estimated efforts to implement the functionality. What struck me was the overwhelming amount of effort required when you take a closer look.
One of the great criticisms underpinning the move away from Enterprise Core type software applications to more agile cloud based applications is the slow and frustrating rate of change that is unsuited to the rapid response era in which we now operate – with robust change control procedures often seen as the culprit.
I recently read a great analogy describing Waterfall vs DevOps. While Waterfall requires the team to be driving 4X4 vehicles to deliver their change across a landscape, DevOps requires an automation evangelist to pave smooth roadways so that the delivery team can drive supercars at fast pace across the landscape. One of the keys is around user experience, which has in the past been overlooked by many organizations in the enterprise space.