Sometimes, it takes work to separate the message from the messenger. Parents will tell stories of how a stern message best comes from a teacher, coach, or extended family member. The same concept applies to application rationalization.
During AWS re:Invent, I asked AWS CEO Adam Selipsky how AWS is helping customers deal with the talent shortage as hybrid environments increase in complexity. His answer? Application rationalization helps reduce the overall burden on IT staff. However, his observation isn’t controversial. The fastest and least risky application transformation is the transformation you don’t have to make.
If two departments use two different solutions for similar processes, logic dictates that one application will suffice. On the surface, it seems obvious. As a result, organizations cut costs and complexity, thus focusing IT efforts on adding net new value. So the case for application rationalization is straightforward, right?
The question is, who should lead the application rationalization project? I’ve done my fair share of data center moves over the years. The move typically starts with application rationalization. It’s an opportunity for IT to start fresh with the applications that matter most to the business—my experience point to extremes in outcomes. Outcomes are binary, risk and complexity get reduced, or months of delay and negative impressions of IT. The uncertainty resulted from IT and stakeholders bickering over retiring redundant applications.
Who’s the Judge?
Before undergoing an application rationalization project, you must start with some basic principles. First, who gets to decide which applications are redundant? Most large IT organizations staff business analysts. These analysts are some of the best sources of information about business processes and application usage. As a result, getting your Business Analyst organization together to hash out an application capabilities matrix and target applications for retirement is relatively easy.
The next step is frustratedly difficult. Let’s say you are leveraging SAP for your ERP system. The manufacturing division uses an add-on application to predict demand and the service department leverages an add-on application to create work orders. Your business analyst team recognizes that SAP has the native capabilities of each add-on product. The obvious next step is to retire both add-on applications and reduce the overall footprint, correct?
Who gets to tell both organizations that they must train their workforce on a new tool and adjust business processes? Resolving tensions is an essential part of who delivers the message. Unfortunately, I’ve seen even the best communicators fail at this point. It’s tough to hear anything but “IT is taking away another tool.” However, what happens when you change the messenger?
The best application rationalization project is the one you don’t have to build. Proper portfolio management alleviates the need to perform application rationalization. Or at least a portfolio management program provides the best way of assessing each application’s value within a given organization.
Portfolio management is the formal process of reviewing and approving each organization’s project against an organization’s resources. For example, how does a manufacturing company’s leadership decide to invest $1,000,000 in capitalized expenses? Do you spend that money on forklifts or moving SAP from HP-UX to Linux?
The organization develops a process to compare the relative business value of each project. That process may include a business plan with measurements such as TCO, ROI, and Risk. Then, a committee of stakeholders across the company gets input on each project. In the end, if your project or application gets cut, you have your peers to blame vs. a single department.
If your organization has a portfolio management process, having that team spin up a review of applications is a lower friction route. In addition, given the culture that implements portfolio management, chances are there aren’t many redundant applications. So, the chances of success increase substantially.
What if you don’t have a formal portfolio management process? I highly recommend you borrow the concepts. Get someone from the COO/CFO/CEO office to sponsor the program for application rationalization. IT is a critical source of information for that team. However, the Support and Manufacturing teams must hash out what business processes to change vs. IT dictating change. Same message, a different messenger, and better results.