The following is the second part of a three-part series on the topic of transformation. So you've made the choice to transform, and you've illustrated your commitment by investing in all the process-related preparatory work I discussed in the first part of this series. Now comes the fun part for the IT team-making the technical choice. But as Coach Lee Corso of ESPN's College Game Day is known to say, "Not so fast my friend."
While I agree that it's time to have some really cool technical debates regarding everything from application platforms, to data and analytics strategies, and the core infrastructure required to support your new direction, there's still a critical decision to be made before you open the check book for your new toys. Here's the other important factor of this decision: it's not entirely yours! This is a strategic decision based on the business' core objectives and desired outcomes, as well as the time horizon of those outcomes. Therefore, this is a collaborative decision with the business and senior leadership team that frames or bounds your technical strategy. The basis of that decision comes from the choice to re-platform or re-engineer. To be clear, that is the real technical choice.
So let's play out both options a bit, starting with the consideration for re-platforming. Let's assume that your business has a process that is supported by a software application, which you've deemed to be a target for transformation. The business has evaluated its business process, reviewed external and internal facing key performance indicators (KPIs), and concluded that they are on the right track but need a boost. To achieve this boost, they've employed methodologies such as Six Sigma and LEAN, or they've even implemented high performing work teams. Yet it just doesn't quite seem to be enough. In this scenario, there's a real case for transformation by way of re-platforming.
I saw this a lot in my food and pharmaceutical production experiences, where we typically wanted to drive incremental cost or productivity and couldn't quite get all the way there with product reformulations, production strategy changes, or traditional cost-out actions. We then had to consider production technology platforms that included the physical hardware and software applications. This was done so that a year or so later, you, the consumer, could get your favorite cereal or required medication for a few coins less.
It would have been unnecessarily disruptive to rip out all the process hardware and controls for the sake of gaining incremental points of productivity when you could make modest changes to the platform, whether it be to the physical hardware or software-based components. In this case, re-platforming makes the most business sense, being the quicker, more economical option, and having the potential to deliver real business outcomes.
The contrast to that and the case for re-engineering lies in situations where you are dealing with extreme levels of process variability, uncompetitive KPIs at the business level, and/or real technological or operational disruptions to your business model. There are many scenarios to consider, but let's focus on a case where you have aging infrastructure and aging software applications that you've been continually modifying over the years to enable the incremental evolution of the business to keep it solvent or vibrant. But now your business has pressures coming from multiple fronts that drive the mandate for change.
First, your customers are demanding more content-rich communications on an ever-increasing frequency. Second, there are new entrants to your market that are offering next- generation type products or services, all enabled by a richer, fresher base of technology. And third, increasing regulatory requirements on things like lot control, process control, or safety abound and represent a significant departure from previous requirements. In the face of these, again you have to convene with your business leadership to develop a strategy around the when and how you want to address these challenges.
It is highly unlikely that there are any tools in the company's operational tool kit that will meet these changes on a sustainable basis. It is also unrealistic that the IT infrastructure and standing applications you've bandaged together for years will have enough remaining fluidity to allow you to modify them to address these external challenges sustainably. I stress the point of sustainability in this scenario because we know you can implement a short-term technological and operational fix, which has been your solution in past years, but this decision is attempting to solve a problem you've never resolved before. As such, you have to take a view of providing a strategy that allows your company to compete over a very competitive horizon, with the expectation of increasing external demands or challenges. In this case, you ultimately need to re-engineer the business processes and re-engineer the technological solution to enable the new business delivery model.
It's important to choose the correct path for the problem you are aiming to solve. The desired business outcomes have to take center stage in the technical choice. Even when you make the decision, you have to resist the trap of overbuying technology to support the business model. Remember, there is a shareholder or business owner out there who is expecting a responsible fiduciary decision. Additionally, your front line co-workers, who are in the trenches working to deliver on every penny of those investment dollars, are expecting you to make their circumstances better and give them a chance to win at the customer interface-level every day. They don't need you to build the Taj Mahal; they need you to build a solution that is simple to interface with and a process that runs consistently and quickly in relation to the customer's expectations.
I have made it a point over the last 10 years of my career to keep top of mind how many preventive maintenance jobs our technicians must execute to pay for the project we just funded, or how many miles and deliveries our professional drivers have to execute for us to implement the technology we choose. So do yourself and your company a favor-don't jump into coding before debating the correct technical choice, because your choices have real-life consequences across the whole of your organization.
Authored by Mel Kirk, SVP & CIO, Ryder System, Inc. Mel Kirk is responsible for all aspects of Ryder's IT organization, including technology vision and strategy, operations and project management, infrastructure and software development, resource optimization, and systems development lifecycle. Throughout a career that began more than 25 years ago, Mel has gained a broad base of leading-edge experiences including: building organizations; launching new technologies; supporting rapid growth; envisioning and implementing innovations to deliver business value; and developing and leading Six Sigma innovation teams. This article was published in CIO Talk Network. For more information, visit ciotalknetwork.com.
