Seven Things IT Managers Can Do Right Now to Accelerate Innovation

Our e-book, “7 Things the SAP® CIO Can Do to Improve Time to Market” and the seven practical tips I provide here will give you some ideas for significantly accelerating your go-to-market plan for innovation. 

For many of our customers, the CIO is responsible for innovation management, exploiting potential for improvement and tackling tasks related to strategic consulting. For simplicity’s sake, let’s assume that innovations are defined as IT requirements in your company. Technical users often expect them to be implemented, quality-assured and put to use rapidly.  

The process involved is referred to as Requirements to Deploy.

Our aim is to ensure you design your Requirements to Deploy process in a way that lets you keep pace with the speed of requirements in your specialist areas, or even better, keep a step ahead of the competition in terms of speed of innovation.

IT as a Business Process – Using the R2D Process as an Example

The process by which a requirement (R) is implemented (through development and customizing) and then deployed (D) is often referred to in IT as Requirement to Deploy (or R2D for short). In the Opengroup  IT4IT reference architecture, R2D is defined as a value flow with phases and activities (see 3.3.2 Requirement to Deploy here).

“Innovation Is the Only Way to Win” - Steve Jobs

One thing Steve Jobs surely didn’t mean is “innovation at any price.” However, one thing I am sure of is that breaking through traditional barriers that would otherwise have a negative effect on efficiency, flexibility and general transformational progress is vital to innovation. With that in mind, I encourage you to check out our suggestions and practical tips below for yourself, and to use them to eliminate any barriers to innovation that may be holding you back.

Seven Options and Practical Examples for Establishing Your CI/CD Process

CI/CD (continuous integration/continuous deployment) in software development involves combining best practices and changing the way specialist departments, developers and testers work together today. As someone in a senior position, that may also require some change from you. However, we believe that change is worthwhile. Below you can find seven options that will pay off for you, along with examples of their implementation.

1. Empower your teams to work with maximum autonomy. For instance, that means handing over the planning and prioritizing of all tasks, and therefore the definition of the next release, to your team (even with moderation).
2. Avoid unnecessary approval processes without increasing risk. Where approval can be granted through the successful completion of automatic quality checks, no one should have to grant it (see this blog article on exception-based approval written by my colleague).
3. Maximize the efficiency of your teams. For instance, through free-flowing Requirements to Deploy processes that – if the quality is good and the checks are successful – automatically transport the software to the next stage of the system environment.
4. Increase quality without increasing effort. At this point, I have to mention the example of fully automated quality assurance (with more than 60 analysis tools) in ActiveControl (change and release management).
5. Stop “putting your head down and plowing through”. Even if your R2D processes are highly efficient, you should always ensure that your business-critical processes are functioning properly using effective regression testing. This can now be done fully automatically (without scripts), e.g. using Robotic Test Automation.
6. Make the work and costs involved in every single change transparent. To do so, you first need to define the KPIs (key figures, data, facts) for your R2D process and then establish an environment that records and fully automatically updates this data for you in the background. Not impossible at all!
7. Start with the principle of “release when ready.” The aim of any SAP changes and customizing in which you have invested effort must always be a quick go-live. To achieve that aim, deploy suitable rules-based DevOps mechanisms (keyword: rules engine) up to and including full automation for the go-live of your software packages.

Feedback and Review for Fine-Tuning Your New Procedure

Once you have applied the seven steps from our e-book that are outlined above, you will be on the right path towards establishing a Requirement to Deploy workflow that can deliver significant business value. But it doesn’t stop there. Every top-class R2D process should come with a feedback loop for ensuring continuous improvement and providing clarity about what works and what doesn’t. Look around you, too – at people who use these technologies and methods successfully – to optimize your very own R2D process.

Benefit from Best Practices Based on Successful Customer Examples

In the e-book, we take an example from practice to show the day-to-day provision of software in a way that does not jeopardize system operation, and why it is so important to be aware of the costs and expenses of any change. Continuous improvement goes hand in hand with recording work in progress and the time taken for approval, and often involves identifying hidden factories.

The Four Crucial Phases from Requirement to Release

Requirements usually reach our IT teams through IT service management tools or simply by e-mail – ideally in consultation with “business analyst” or “subject matter expert” roles and possibly with a system architect or developer. (George Dinwiddie deals with this topic in more detail in his fascinating article here, loosely based on the film “The Three Amigos” ... https://www.stickyminds.com/sites/default/files/magazine/file/2013/3971888.pdf ).

That ensures that everyone in the team has the same understanding and expectations of a requirement (often referred to in agile software development as the “user story”).

Even in typical DevOps tool chains, you will find the phases mentioned, including Planning, Building, Integrating, Testing, Release, Go-live and Running. Successful releases begin with people who prepare a requirement rationally with objectives in mind and then use suitable systems (that come into effect in the Building and Testing phase) to achieve the continuous release.

The Next Thing You Can Do

1. The e-book mentioned above, 7 things the SAP CIO can do to improve time to market, is available for you to download from our website.
2. We have made an interesting video about ActiveControl, our fully automatic and integrated change and release management software for SAP. It takes the fictional “constructive company” as an example to illustrate the collaboration between specialist departments, business process experts, developers and testers. You can view it here: https://www.basistechnologies.com/activecontrol-day-in-the-life-demo-thank-you/.
3. If you would like to read more about how Scrum and KANBAN can provide some inspiration for your innovations, I recommend the ten steps by David Lowe (from Scrum & Kanban, UK).

For a one-on-one demonstration of the Basis Technologies automation platform, please contact us at https://www.basistechnologies.com/request-a-demo/.