5. I can’t afford it
Just like any new approach, decision automation software costs money, so does the training, so does the initial help you need. A sense that it cannot be afforded comes from either the team with the initial problem or from the IT department as a whole.
When the problem comes from the team the most common cause is that internal budgeting processes are screwy. For instance a team of programmers might be available but the budget to invest in decision automation is not, even if this investment would reduce the number of programmers needed for the project. The programmers are assigned but the software budget is managed to a cap and the one cannot be swapped for the other. If your organization has this problem you may be hard pushed to do anything about it but you might want to consider working somewhere else…
A more genuine problem arises because budgets are often assigned separately for development and ongoing maintenance. Thus, justifying some change in the project based on decreased maintenance costs may involve pulling several budgets together and showing that the total will be lower, even though the initial project might be larger. If you organization has figured out how to get initial services built for re-use then the same approach might work here. If not, try talking to the business owners as they know they will need the system to evolve over time and so might well help you justify the larger initial cost. Sometimes it is easier to go to the business owners and tell them how the decision automation investment will impact the functionality that can be delivered and get them to agree a larger total budget because they will get additional benefits from the additional functionality that can be delivered – they might save staffing costs for instance.
One other thing worth considering is the ancillary cost of manual decision-making – faxes, overnight packages, unnecessary third party reports etc. Many decision automation projects dramatically reduce these costs and that can provide a great justification for the additional investment.
The bottom line is that it is sometimes easier for projects to write the next generation of legacy code rather than fix the decision automation problem. Somehow you must establish the true cost of the “old way” and create an urgent need to change in the minds of the project owners and sponsors.
When the IT department as a whole is having a problem with the cost of entry you have a slightly different issue. Many IT departments are not building new systems because they are swamped trying to maintain older systems on a shoestring. With a huge maintenance load many IT departments are focused on this problem almost to the exclusion of all others. The attraction of decision automation in this circumstance is that it can help reduce maintenance costs in the medium term. If you have systems that take a lot of maintenance, consider if using a business rules maintenance system to manage the business logic would make it easier and cheaper to maintain. If it would, and often it will, see if you can have several years maintenance budget considered at once and show how the additional investment on decision automation now will pay off in reduced maintenance in subsequent years.
Some IT departments are also focused only on costs not on benefits. Embedding analytics that make offers more targeted or risks more precisely managed can improve the top line enough to justify additional expense. Opportunity costs to the business from delays in implementing changes can amount to huge sums in fast-moving competitive situations and that too can justify additional investment. Don’t allow a focus only on costs to blind you to the upside potential of decision automation.
Business rules management systems and embedded analytics, the core technologies for decision automation, have a great ROI for the right kind of problem. Try not to let outmoded budget processes hold you back.
