As I mentioned in Part One of this series, heritage applications mean more than just software to the users. Many departments have an almost symbiotic relationship with the software they use. Over time, they’ve adapted their business and management processes and their software to each other to a degree that may not be optimal for either, but gets them what they believe to be the greatest value. I’ve seen many work groups balk at adopting an obviously better software product because of the perceived difficulty of designing and rolling out new business processes that will allow them to take advantage of the new tools. Others have objected because they were deeply invested in using reports that weren’t completely replaced by the new software. These are legitimate concerns, and the practicing IT project manager needs to address them.
Every work group has customers to whom they provide services using their current software solution and associated processes. However, over time it becomes apparent that some services have more business value, or are more in demand, or are more complex to prepare and deliver. The key to reaching agreement between the IT department and the users on which product features are critical for the success of a proposed replacement product is to keep the focus on service delivery.
It can be useful to conduct one or more workshops documenting the current state. Get the users together in a room to talk about business processes, identifying the various services they provide to their customers, and sketching out the work flow for each. Then identify the process elements supported by the current solution, and those that are not supported or that require work-arounds. Finally, identify any steps that are driven by real or perceived limitations of the current product. If needed, conduct another workshop centered on current management processes, focusing on reports and access control.
After the workshops, meet with the managers to rank-order or otherwise prioritize the various services provided, both in terms of business value and the complexity or number of transactions processed. Services with both high business value and high degrees of complexity or frequency of demand should be considered critical product features, and absolutely required for any replacement candidate. Even if some degree of business process re-engineering is required in order for the users to utilize the new software properly, these services justify the incremental cost and effort.
One of the defining characteristics of SaaS offerings is the use of browser-based applications to deliver services directly to the customer. Those services with high business value but relatively low complexity should be considered for conversion to self-service. Note that the cost of rolling out a self-service application may be driven by the need to communicate and train the users in the general population, so consider the size of that group early in the process.
Those services with high complexity but relatively low business value should be considered for business process re-engineering, simplification, or even elimination. If the users haven’t asked their customers why they should still provide a service with such a poor relationship between cost and benefit, this is an excellent time for that conversation. Finally, those services with both low complexity and low business value should be considered for conversion to a manual process. Not everything should be automated!
At the conclusion of this analysis, you should have general agreement as to what will be a “must-have,” and what will be negotiable when considering alternative software solutions. If your users have gotten engaged in the process, you might even find them “racing ahead” in the search for a new solution.
Next week, I’ll talk about the “softer” aspects of heritage applications – the familiar user interface and security model, and the sense of job security an obscure application can provide to the local expert.