Business Configuration – Is it Time?

I was talking with a carrier recently who asked an interesting question. "So many of the modern core systems include highly configurable environments. Does it really make sense for the business to be making their own changes?" We have seen a movement toward more involvement by the business in the configuration of software systems. Many of the tools have dual development environments - a simplified environment that supports the business making simple changes - modification of rate algorithms/tables, product definitions, lists of values, drop downs – sometimes through wizards. Typically a more robust environment is used by IT to manage screen and workflow configuration, business rules configuration, data/ object model configuration and interface configuration. Many IT departments have taken the philosophical position that their job is to enable the business to do as much as possible themselves and to do so as transparently as possible. There are a number of good reasons for this. There’s a better alignment between responsibilities and ownership. It enables the business to be ready for testing, training, and other necessary activities. The business gets to see the changes they’re making and have control over some of the aspects. They can make the changes based on their own prioritization of them. But for most companies, there are significant hurdles in this movement so the shift has been and continues to be quite gradual. Specialized knowledge such as logic and abstraction may be needed and may not reside in the business. Changes may impact multiple stakeholders so a process must be in place to assure consistency across business units. Version management is usually important – but different levels of maturity may exist in different parts of the system. The business may not understand the global impact on cost, performance, and maintainability when making changes on systems and environments especially if they are working with complex rules or products. Sometimes IT resists moving the responsibility to the business – but here’s a secret. Most IT departments don’t actually enjoy configuration work. Most would love for the business to do it themselves. Why then do we see significant resistance on the part of IT departments to move it? In most cases, IT knows that they are the ones who are held responsible for the system and will be the ones to answer the phone at 2 am or work the weekend investigating a problem. IT is also usually the group measured by system availability, incidents and SLAs and doesn’t want to be penalized for other groups’ activities. In many organizations, business hasn’t been willing to invest in the tooling, interfaces and governance necessary to make it practical for them to self-manage. But IT wants to be sure the other areas are going to be held to the same standard of governance that IT is. These standards were put in place for a reason. And some carriers are concerned about regulatory issues and making sure that there is segregation of duties as well as good auditability around the changes being made because of the discoverability of those changes. Auditability requires a great deal of consistency across processes that can be harder to maintain when spread across multiple units. If you’re going down this path there are some things to think through. First, make sure you’re solving the real problem. The business may want to take responsibility because they feel they have difficulty engaging IT, that there are quality problems or that IT doesn’t have sufficient business knowledge of what needs to be done. Sometimes business wants to take control because they feel changes aren’t being made quickly enough or senses prioritization or resourcing conflicts. All of these items should be a separate conversation. It may well be that the nature of the work requires a process or skill that will make it better housed in the business. But if it’s one of the other issues, solve for that before moving responsibility to the business. If you do decide to move configuration to the business, make sure the business is well trained on how to use the tools – and has an understanding of the dependencies outside of their specific area. Some carriers find it most effective to find a few ‘super-users’ in the business and to roll out capabilities to these users in a phased manner. Create a test environment that supports the business. Many times, they’re simply looking for a sandbox environment where they can model what they want – and then use that as the starting point of a request to IT. Include the business in the same governance process for quality assurance, testing, and release management. While software vendors have created robust tools that can support business driven configuration, carriers should assure processes, procedures, and governance is in place before moving the capability from IT to the business.