In my last post, I started to put the theory of Application Rationalization into practice, first by Phase 1: setting up an application inventory by doing an application survey. After you have completed Phase 1, you start with Phase 2: the rationalization of the applications you have inventoried. Once you have completed these two phases, you can consolidate (Phase 3), after which you can do a periodical evaluation of all your applications: portfolio management (Phase 4).
The key to success is sticking to your strategic Roadmap and your step-by-step plan. Also, keep discipline in periodically evaluating and maintaining/updating all your applications and adjusting your strategy if needed. As discussed previously, neglecting maintenance and analysis will lead to a situation in which a (big part) of your initial work (and resources spent) will be for nothing. Because an application landscape is so dynamic (new updates, technology advancements, new business strategies/stakeholders, etc.), losing grip once instated is easy when you are not actively participating in the daily dynamics of your application landscape. This way, you also keep claiming ownership of all applications Having said this, let’s get back to putting theory into practice and complete the Application Rationalization process beginning with the third phase: consolidation.
Phase 3 Consolidation
By consolidating your applications, you can streamline your ICT resources and remove applications’ redundant functionalities. Consolidation, if executed properly, also reduces the complexity of your application landscape and can improve the utilization of user experience, functionalities, and computing resources. Many organizations with bloated application portfolios turn to an approach of application consolidation to get in control of their application landscape again.
Consolidation can be very challenging, and during the consolidation phase, you will see that it’s hard to get any more quick wins which leads to making decisions based on the functionality of applications.
3.1 Migrating applications with overlapping functionality
Thanks to the inventoried functionality of the applications, it is possible to identify (partially) overlapping functionality. For this functionality, you have to ask yourself whether all applications are necessary or whether one can take over the role of the other(s). Here, it is inevitable that the business sometimes has to sacrifice some functionality if the savings in application costs (for instance, maintenance) exceed the costs of changing specific business processes. Don’t forget to include “hidden costs” in this.
Often, management overlooks business interruptions created by insufficient knowledge/communication of new business processes. You have to include these “hidden” costs in your business case and make management aware of the costs and benefits of good adoption management.
3.2 Leveraging unused functionality of existing standard applications
The functionality of a standard application is sometimes not entirely used by the business. In some cases, it is conceivable that your organization can exploit the license costs for specific licenses better by broadening the functionality of existing standard applications. A flawed adoption process in the past can also lead to ineffective use of existing applications. A flawed adaption process can include:
- Bad (or even no) training of users after you deploy a new application or application functionalities.
- No aftercare after deployment. Many organizations’ ICT departments completely ignore applications, and users work with these applications after deployment and the first adaption. Make sure to periodically check up with (key) users and business process owners to determine if they are satisfied with the application and to listen to their suggestions based on their first-line experience when working with the newly deployed application. I like the idea of a continuous improvement team in the ICT department that entirely focuses on optimizing applications. This team of all-round functional application supporters should be present inside the business. It can create a bridge between (key) users and business process owners on one side and the ICT department/ development team on the other.
- No manuals/work instructions are available that clearly explain how all features of an application work, including basic troubleshooting in case of application malfunction. Creating manuals/work instructions with (key) users and business process owners is a core part of any developer’s job. Still, this step is skipped (partially) in many cases. The team of all-round functional application supporters (as mentioned in the previous bullet) can also support this.
- There are no transparent communication tree in case (key) users and business process owners face application issues. Knowing who to consult when you run into trouble with an application is essential to prevent inefficiencies in your business processes. Continually evaluate and update this communication tree periodically to avoid the risk of obsolete points of contact.
3.3 Optimizing the ICT platforms used
Concentrate and standardize application development and management on a limited number of platforms and make the most of their capabilities. Platforms can contain many applications/functionalities, and you should always focus on just a few platforms. Once decided, don’t switch platforms unless you are confronted with substantial organizational changes (for instance, a takeover).
Working with platforms is essential, in my opinion, and it limits the scope of your selection process and creates a clear strategic framework within your organization. If you have the golden rule: if an application doesn’t fit, don’t put it on your grid.” you create a lot of transparency and clarity inside your organization.
When choosing a platform, look for a strong enough supplier to weather economic and technical storms. In addition, look for platforms with a strong user community that has built up an extensive network of partners that can support you.
A platform with only a tiny core of developers (< 100), is privately owned by one or a few individuals, is only locally active and has limited resources/funds available is a no-go for me.
3.4 Data optimization
You often use data in multiple applications, so you must make changes to this data in various files. Besides inefficiency, this duplicate capture also creates the risk of data discrepancies and errors. It is often complex to replace the different files with a single captured file. Another solution is to make a single ‘mutation point’ in the form of single source files from which various applications can draw: the “one source of truth” strategy.
Phase 4 Portfolio Management
The first three phases of inventory, rationalization, and consolidation are needed to clean up the applications in use. Setting up an application portfolio management process is necessary to ensure that the results are not a one-off action. Portfolio management is a tool from the financial world that you can use to make the total of applications transparent and manageable despite the great variety of applications.
After recognizing the various rationalization and consolidation possibilities, comes the phase in which you start realizing the savings. Utilizing these savings requires the prudent planning and implementation of application-related projects. Because follow-up projects in application consolidation, in particular, can be complex and far-reaching, you need to prioritize between the various proposals based on the following:
- The cost of the projects and the cost savings to be achieved;
- The speed at which you can realize the savings;
- The risks and dependencies of the various projects;
- The organization’s ability to change
The considerations you create when putting together the overall project calendar form the project portfolio management process. Within this process, you align assets with organizational and technological developments, resulting in several desired changes in the assets that you have to weigh against each other by giving priorities, e.g., based on efficiency or necessity, and constraints of the organization, e.g., budget or change capacity. Setting up portfolio management processes and procedures ensures structurally optimal cost levels rather than ad hoc one-off savings.
The application portfolio management process is a part of asset portfolio management, and the connection between these two forms of portfolio management can be seen as follows:
Rationalization and consolidation projects can result (if properly executed) in cost savings like:
- A decrease in licensing costs
- A reduction of applications management costs
- A decrease in infrastructure management costs
- An increase in available hardware (server) capacity
Your Application Roadmap helps you identify the organization’s rationalization and consolidation opportunities that can collectively lead to lower ICT management costs of up to 25%. The relatively easy-to-implement rationalization activities can contribute to a severe elimination of the applications in the use of up to 15%. The associated cost savings will likely be lower, between 5% and 10%. If you execute your whole Application Rationalization strategy correctly, you can realize an additional 10 to 15% savings in your application management costs.
Final Thoughts
Running a tight ship of your application landscape that sometimes feels for the business as “inflexible” can cause internal struggles and frustration with (key) users and business process, owners. However, in many cases, you can modify (parts) of a business process to make it more compatible with an application or platform, leading to an increase in the functionality of an application.
Changing a business process might hurt user experience, but providing a flawless adoption process with enthusiastic support and training of the users will eliminate the risk of less user experience. It might even increase the user experience in the end.
Ensure that the ICT department becomes and stays the organization’s “institute for applications,” where businesses can consistently consult the ICT department during application decisions. My approach is to stick to one golden rule: ICT should always support the business, meaning ICT never decides for the business. The classic ICT mindset tends to bend this golden rule, tempting the ICT department to choose for the business. Based on my experience, this leads to solutions not fully supported by the business that eventually become obsolete because nobody wants to work with these solutions.
Presence is also essential for the ICT department to stay an “institute for applications.” Don’t play “hide and seek” games with the business. You should always have a proactive approach, which means that you must regularly check with business process owners and (key) users whether all applications are satisfactory and whether they have any questions and/or areas for improvement for the ICT department regarding applications.
Also, make sure to facilitate regular training sessions with all users and detailed application manuals for users easily accessible in a centralized (digital) location. Of course, the application playbook I wrote these past posts is my philosophy/vision and strategy.
Feel free to contact me if you have questions, a different view, or any additional advice/tips about this subject. If you want to keep me in the loop if I upload a new post, make sure to subscribe, so you receive a notification by e-mail.
