What is a business rule and who enforces them? How do they erode over time, why and what happens when they do.
In the service delivery business a common big rule (one that is the basis for other rules) is that a Customer tells the provider what they would like to have serviced. So, while a business process is typically written down as a guide for employees to follow (to accomplish such tasks as quoting, invoicing, billing, booking, supporting, etc.) a business rule is more often a general understanding that is woven into the cultural fabric of a company, or is an industry standard practice.
For the sake of argument, I will focus on support services and the creation of an agreement between a vendor and customer. In the computer industry, computers, software licenses, peripherals etc, are frequently distributed over large geographic areas and, more and more often, globally. So when a customer wanted to put their gear on a support contract they work with a service provider and share the list of gear they want covered with a support agreement. The vendor then takes the list, determines the cost of supporting it, adds an appropriate margin and provides a quote back to the customer for consideration. The BIG rule here is that the customer is responsible for letting the vendor know what they would like to have serviced. Once agreement is reached, the vendor loads the provided list into some sort of entitlement database with a contract number, and provides the customer with a contract and support phone number. Entitlement is based on the serial number of the failing system at the time of the service request.
Things they are a changing. Today, as more and more IT managers are asked to do more with less, those once rigid controls of inventory and assets have taken a back seat to more urgent needs like installations, maintenance and crisis management. Where once systems administrators were co-located with the gear they managed and could simply walk over and power cycle a system or read off a serial number, that has now become the exception not the rule. We are seeing a huge shift to remote management, everything from 'work from home' to offshore out sourcing. It is not uncommon now for an SA in India to call in for support on a system in North Carolina, for example. If electronic serial numbers were uniformly available this would be less significant, but they are not. Compounding this lose of inventory control is the rapid merger and acquisition of companies with their own IT departments and data centers. By design, mergers reduce head count, leveraging economies of scale to drive down cost and grow revenue. As each new acquisition is cobbled onto an existing IT install base the ability to effectively track and manage their assets is diminished.
IT management is still held accountable for uptime and availability of their assets and thus must ensure that all appropriate support is in place for the gear they cover to meet their Service Level Agreements with their customers. This is the first chink in the armor of the simple BIG rule. The manager, knowing he does not have a perfect list of inventory, approaches the vendor and says: "Here is a pretty good list of my assets across the hundreds of sites I am responsible for, but I know it's not complete. I can not afford to have your company deny me support for a system I might have missed on this list, so I need an agreement from you to cover me even if the serial number we call in on is not on the contracted list. "
Traditionally this would have been handled by Time and Materials service. This is where the customer pays a standard flat rate per hour for a technician and the cost of any parts needed to effect the repair. By design this is a more expensive service to receive and to deliver. Since it is less predictable and has no bankable reoccurring revenue stream, the vendor is not as able to adjust resources effectively and thus offers the service as a stop gap measure only. The price is kept high to drive customers to a more predictable and manageable service model and steady reoccurring revenue streams. This allows for better coverage models and tighter resource management.
Now lets break the BIG rule. When the customer is of significant size, and brings significant revenue to the vendor, they can make requests that must be addressed. In this example the customer is unwilling to take on the risk of incurring the higher costs of T&M services for gear they have failed to identify. They expect, require and demand a fixed cost for ALL their gear to reduce their risk of unexpected costs and missed Service Level Agreements due to the best effort nature of T&M services. So they pressure the services sales representatives to cover ALL the equipment. But how, since the very foundation of entitlement is driven by serialized assets existing in an entitlement database. Give Service, Service First, Elite, Strategic, Global, Premium, the list goes on, all names given to solutions to this problem. These special large account plans offer many other services, but the core remains the same, getting them service no matter what. The argument goes something like this; Customer X is so important that we can not afford to be rigid or black and white and must get out of the box to solve their problems. The sales representative dangles a multimillion dollar contract in front of a deal review board who are financially focused, with NO knowledge of the back end processes to implement such entitlement challenges and they jump. These jumps to acceptance are accelerated in economic down turns and become exacerbated with struggling companies. Once this train leaves the station for one customer, it quickly becomes the model for the rest, and the snowball effect comes into play. Once a struggling company begins breaking their own rules, the complexity of the service solution they offer grows quickly and yet the resources required to implement such complex solutions decline. The net effect is reduced quality of the service, lower customer satisfaction and morale, beginning a self defeating cycle.
The business rule that once suggested, "we will contract for support any equipment you tell us about" has now become, "we will contract for support any equipment you own" thus moving from serialized assets to customer name (legal entity). This now breaks the rule, and the consequences begin to cascade from here.
Perhaps if this new entitlement model were designed from the ground up, rather than being forced into it, we could have found a solution for these accounts that would stand the test of time and integrate into longer term strategies. But there is little incentive to do this as Sales and Marketing are focused on selling. The back end implementation and delivery is someone else's problem to solve. To deliver this new entitlement model, the natural thing to do is look for the choke points. Where, in the existing process, would the customer be denied service without a serial number, and put a bridge or stop gap measure in place. A custom solution for each variation sold. There are two main ports of entry; the phones and the web. Knowing the web challenge I will focus on the phones. We create a new business process that says if Customer X calls in, and they can't provide a serial number or the serial number they do provide does not exist, refer to a customer account list and based on what you read there, give them the service level listed. With hundreds of people taking calls around the world it became very difficult to know which of the hundreds of thousands of customer should be looked up in this exception process and it fails. Adding complexity are the various ways customer names are spelled, and various different operation names a given company amy work under. Customer are denied service and satisfaction falls. So we created a special phone number or ID's they could use that would route their calls to a special group of people trained to read their custom pages and take the appropriate actions. This seemed to work and customer satisfaction returned to high levels, more or less. Standardization across the globe is difficult and incentives vary driving different behavior creating inconsistency.
This model depends on several things that are intangibles such as trust. The support services organization must trust that the sales organization is doing a competent job determining the install base is accurate in general terms. For example, if the customer had 1000 system on contract five years ago and buys 100 new ones each year and retires 50 old ones each year, you would expect 1250 systems on the quote. Traditionally the sales representative, with the customers support, would agree on this number, list the known serial numbers and locations, make up dummy serials and locations for the missing gear and sign a contract. The trust must be there for this to work. If the service delivery teams doubts the effectiveness of the sales representative in capturing all the assets, they grow to believe they are giving away their services or not being fairly compensated. When times are tough and layoffs are happening this trust becomes more difficult to maintain.
If you do not trust that your sales team is capturing all the assets on the contract, and you are giving service to the whole account, then you by default must assume to are missing revenue opportunities. We often fail to realize or acknowledge the fact that this behavior also reduces the preceived value of the service being delivered. If a customer can get the same level of service for half the price, the value of that service is half what it previously was. Or another way to look at it would be, if the customer knows they are growing their install base, and yet are able to hold their cost of support constant, they assume the service was over priced to begin with. This creates a vicious cycle; the service delivery team continues to deliver the same level of service, the sales representative knows they are covering more systems and interprets this to mean the delivery organization is inflating their prices and over charging, sales is justified in their actions...
Stay tuned for ERP and Install Base and the shift back to rigid serialized entitlement and those it effects....
Posts
