In my previous posts, the Application Playbook Part 1 and Part 2, I discussed the theory behind Application Rationalization. However, the theory is not the same as the practice. Most organizations already have a lot of applications (some not even known by the ICT department), and to start inside a situation of vast application landscape instead of a lean one might be overwhelming for any ICT manager that begins with this task from scratch.
And believe me: the first situation (an enormous and inconsistent application landscape with many legacy applications) is more likely than the second one (a lean, fully transparent landscape).
In all cases, I start with defining a Roadmap over time with clear milestones. After that, I break these milestones down in a step-by-step plan. In the next two posts (this one and the one after), I will guide you through my approach based on the Roadmap I describe and the steps I take from setting up an inventory of applications toward an integrated system of application portfolio management. A structured method of application portfolio management is the Holy Grail in your adventure of Application Rationalization and management.
Once you complete your Application Matrix, you must maintain and update it periodically. If you and your team neglect to do this, a lot of work (and resources spent) will be for nothing. Securing processes and maintaining frameworks is one of the biggest challenges in ICT. It is exciting to create something new, but maintaining and improving it routinely is challenging for most people, requiring discipline and persistence.
Phase 1 Inventory/Application Survey
Almost every ICT manager runs at least once into an “Application Carnage” situation during a career in ICT. When you run into this challenge, the first step is to get insight and a clear overview of all the applications used and for what business processes the users utilize these applications. Therefore, the first step is to inventory and examine the relevant application landscape data. Completing this assessment by creating full transparency of all the applications an organization uses for all its business processes will give you comfort and a feeling of control as an ICT manager. Knowing what is out there is critical and allows you to set up a holistic approach to defining a good application strategy later in the process. To make an inventory of all the applications used for every process, you must survey every department. The easiest way is to send a clear survey format to the business process owner of a department and/or key users in which they can designate their internal processes and the applications they use for these processes. Below, I describe the four steps I advise you to take during phase 1: the inventory/survey of all your applications.
1.1 Systematic Positioning
A crucial step to rationalize and/or consolidate all your applications, in the sense of reducing functional overlap, is to position the functionality of all identified applications systematically. You do this by creating an overview of all business processes. Try to define these processes as generally as possible. For instance, an investment approval process might look completely different from a maintenance approval process. Still, in the end, both approval processes require the same workflow. Translating this into an “approval” process makes it more tangible and reduces the size of your inventory list. It also helps departments approach their processes more “high over” way, which might help managers get more oversight of departments in a “helicopter view.”
1.2 Classification of Applications
A systematic inventory of functionality requires a ‘framework’ of possible functionality. Examining which business process an application supports is not enough because you can use applications generically. The business process supported by an application does not always clearly show the premium source of the application’s functionality. A good example is an application built in Visual Basic (VBA) that supports a department. For outsiders, a generic application you use is Excel. However, for insiders, the actual function is not Excel but what the VBA programmer has written in Visual Basic to support a process. Getting insight into these programs is also essential, possibly being the trickiest point because most process owners and/or key users might describe the general program instead of the functionality of the source behind it (for instance, VBA). Make sure to integrate this part into your survey.
1.3 Measuring the number of Users
The following inventory step measures the number of users of the various applications, which is critical for you to define your strategy. Suppose a select group of users use specific applications with high maintenance costs. In that case, it might be worthwhile to evaluate the possibility of integrating the particular business processes aligned with that application into an application with many other users, still serving all functionalities that the users require to be productive. Sometimes this means adjusting a business process, and when this happens, you should do a costs/benefits analysis before making any decisions. Of course, involving business process owners is critical in this.
1.4 Estimating costs per application
For each application, you need to measure or estimate the costs of usage and management: the Total Cost of Ownership (TCO), including the direct costs of an application. These costs are licenses, maintenance contracts/Service Level Agreements: SLA, dedicated staff, and dedicated infrastructure (helpdesk, network, and workstation costs).
Phase 2 Rationalization
After completing the inventory/application survey phase, you will have a complete overview of all business processes and the applications that every business process uses. The next step is to rationalize your application portfolio.
2.1 Dropping unused or rarely used applications
Based on the number of users, it is possible to detect whether applications exist without users. If the user is no longer applicable, you can communicate with business process owners in case applications can be removed. I prefer communication first instead of the “bleeping” method (people getting in touch with you after you pulled an application without communicating this). As a service department, customers come first, so involving your internal customers (the users) in this process is a must, in my opinion. You can also question the use of applications with minimal usage by challenging the business process owners. As mentioned in 1.3, sometimes, changing a specific process might result in a situation where the modified process is compatible with a different application used by many users. The more business processes are suitable to a single application, the bigger the efficiency and the lower the maintenance costs of an application.
2.2 Updating all applications to the same application version
Make sure to register the version of your applications in your application overview and keep all users on the same version. Different versions might lead to unnecessary functional questions from users. Additionally, you should use an updated version because of security reasons as well. Developers deploy many updates to close security leaks that might be abused by malicious parties looking for ways to attack an organization from the outside.
Ensure to inform and support users if there are changes compared to the previous version of the application(s) they are using: both in terms of appearance (for instance, the GUI) and content. A good adoption process increases the involvement of users, the acceptance of changes, and the efficient use of the application in which the users can utilize all the available features. An adaption process should also be part of your IT strategy. Your (internal) users always come first and should be treated with the utmost care and attention: make sure to have a flexible team of allrounders in your ICT team who like to help facilitate users and key users. These functional application managers should breathe service & support and should not limit themselves to a fixed area of ICT expertise.
2.3 “Dead” code removal in customized applications
Legacy applications sometimes create unnecessary ballast in running and maintaining an application. This “dead” code happens after years of maintenance and changes to these (legacy) applications. You can use supporting software tools to detect unused code in these applications. Removing dead code might make older applications run more smoothly and relieve network and server capacity. Make sure to do extensive testing in a testing environment before releasing the polished application in your production environment.
2.4 Standardizing applications with equal functionality
When you standardize your applications, users might sometimes have to make some concessions on functionality or make changes to their business processes to work with the application. Make sure to pay extra attention to macros and manual coding in applications. Migration of these is often impossible, so you need to recreate them. Good examples of manual coded applications are VBA-coded/Macro driven applications in Excel or traditional ERP systems like SAP ECC that require FIORI or ABAB coding).
A good adoption process for your users is also an indispensable part of this change. Make sure to save plenty of time to continuously train and educate them to utilize as many functionalities of an application as possible.
Final Thoughts
It would help if you dealt with different variables on top of application management. Here are a few examples:
- Management and management strategy
- Budgets
- Business Processes
- People (application users, designers, functional application managers, etc.)
- External stakeholders (Customers and Suppliers)
Some variables will be easy to integrate into the application framework you design, but others might be more difficult. Make sure to set up a clear and understandable Roadmap that you can present to all stakeholders.
You and your ICT team must always include stakeholders/the business in the problem and solution process. They should have the final say in all decisions and solutions that an ICT department proposes.
The business and its users must work with all the available applications and are the true heroes of a successful business story: not a single ICT department. The ICT department should guide the stakeholders/the business in making the right choices. They should never be the final decision-makers and do not only inform but also involve them! Of course, that is just my own opinion and the philosophy I follow, so feel free to contact me if you have questions or a different view or in case you have 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.
