Long-time correspondent Bob Ernst writes, “It hit me that what has become a major function of a corporate IT department is enabling your company to comply with the rules of doing business with another company. Without this capability, the efforts of manufacturing, sales and marketing are unable to sustain the customer relationship.”
I agree, with the proviso that “has become” should read “should have become.” In my experience, it’s often someone well-hidden from IT, using Excel spreadsheets to keep track of customer-specific product and service requirements, and more Excel spreadsheets to take care of customer-specific reporting requirements.
For example: Whenever I’ve worked with non-profit organizations built around winning grants, I’ve seen pretty much the same systems mess: handcrafted grant reporting managed as a monthly panic attack when the non-profit is small, and as a swarm of satellite spreadsheets “connected,” if I might abuse the term, to the enterprise ERP system, which is utterly incapable of handling the task on its own.
But as you’d expect from someone named Bob, Mr. Ernst isn’t wrong.
For example, sometimes the rules are a matter of keeping track of parameterized product and service features, as when you travel on business and your preferred rental car provider keeps track of contractually specified rental options, such as which forms of additional insurance employees should and shouldn’t sign up for.
Or, for that matter, if your customer is enterprise IT and requires the PCs and laptops it buys from you to all have the same, standardized set of key components (I presume — I don’t work in that part of Dell, but was responsible for PC acquisition earlier in my career).
But there are plenty of businesses that rely on negotiated contracts to define the terms and conditions of doing business. Some are insurance companies, some are in the transportation business, others are manufacturers, and one I worked with quite a few years ago managed rebate programs.
Then there was the company that didn’t have any of this, but which did have eleven bargaining units (unions, if you don’t belong to the Magic Buzzword Club), each of which negotiated unique compensation and benefits terms for its members, all of which had to be hard-coded into the payroll system.
What all these situations had and have in common is that each contract signing was a new and often unique scramble for IT, calling for custom, contract-specific code.
Except for the life insurance businesses I’ve worked with; their underwriting and policy administration systems provided the business with what amounted to an insurance contract description language. This provided enough flexibility to handle most contracts, at this cost: New business staff needed at least three months to become at all productive, and a couple of years to become truly proficient.
And, sales force ingenuity was (and, I’m sure, still is) nothing to be trifled with — some contracts still result in a need for IT to extend the language.
What I find interesting about this need for information technology to manage unique customer requirements is that there is, to the best of my knowledge, no body of theory to accommodate it.
It’s quite the opposite, in fact: The prevalent guiding theories are such stalwarts as Lean and Six Sigma, both of which preach standardization and simplification. My experience working with consultants schooled in these disciplines suggests their solution would be to simplify, standardize, parameterize, and limit customer choices to the result.
It isn’t that they’re wrong. It’s that, they are, as someone once said, insufficiently right.
To draw an inexcusable analogy, it’s as if Lean and Six Sigma are the Newtonian physics of business. In the world of everyday forces, temperatures, sizes, masses, densities, and accelerations they handle things just fine.
But just as a lot of the universe operates at quantum and cosmological scales, near-light-speed velocities, ferocious accelerations, and light-capturing gravitation — situations where Newtonian physics breaks down — so there are plenty of business situations that don’t fit the simplify and standardize formulation.
As when, for example, that isn’t what customers want to buy.
Changing metaphors, your average process consultant is the clichéd hammer owner, for whom all problems look like nails.
If your business depends on selling customers what they do want to buy, even when what they want to buy will take custom code and one-off business processes, you’re looking at the situation from the other side.
As yours truly once said, when all you have are thumbs, every hammer looks like a problem.
My 2 cents:
1. Identify the areas of the organization where “time eaters” seem to live.
2. Identify: Which time eaters are keys to organization viability to meet expectations? Which ones are keys to the business exceeding expectations?
3. This is the hard part – Find or develop software that flexible enough and powerful enough to reliably handle the time eater situations. Here, picking the right tools that CAN do the jobs is key. No room for prejudices or favorites. Be willing to look, think, listen, and be outside your comfort zone.
IMHO, if you don’t have a sufficiently powerful, flexible, and maintainable tool set, you’ll seldom be able to make a real difference for the organization, regardless of what other resources are available to you, in these kinds of situations.
Some companies has tried to deal with this through rules engines, storing all the one-off (or five-off) situations in a “rule” that should then be referenced by all the other real-time and batch systems. Having a single place for these rules to live is certainly a Good Idea.
The breakdown happens when existing systems can’t talk with the rules engine, and you wind up writing internal APIs to enable the communications. If you are able to get that done, then the rules engine still makes sense.
The real rub is when writing the API is taking longer than planned, and deliverables have to get done, so someone writes the rule into one or more local systems, promising to “move it to the rules engine later.” Later never comes, the rules engine isn’t the panacea that was expected, and we’re back to local rules in each system in the chain.
Thanks for verbalizing a problem that many of us deal with regularly. At least it’s good to know that it’s not unique to either one company or one industry.
Ugh — inability to edit after posting — “some companies HAVE”
There is, of course, a middle ground in many of these situations, one that’s the cliche “win-win” scenario: design the product with some built-in flexibility! Someone should be playing “what if?” early in the requirements process to see where this might come into play.
Let me provide a specific example of a product where the designers were thinking ahead. Note that, although I name the product, this isn’t necessarily an endorsement (I only endorse things with regard to the needs of whoever is listening to me).
The product is Intuit Online Payroll. The first feature I want to mention, which is a little more germane to the article, is that the system has no trouble dealing with different employee groups that have different pay schedules. One of my clients, for example, pays hourly workers weekly and the salaried owners bimonthly. No problem — when I’m processing payroll, I simply tell the system which employee group I’m working with and it goes from there. With a good bit of data modeling this can be extended to a large business dealing with 11 different unions, as in your example (in fact, I did exactly this when I worked for a major international company 20 years ago).
The second feature, which is more hard-coded but still required forethought, is state disability premiums. In most states where this exists, premiums are a percentage of the worker’s earnings — regardless of whether it’s the employee or the employer that pays them. Here in Washington, though, each employer’s premium is determined by industry, company, and job classification experience and the premium is a set rate per hour. So far, IOP is the only small-business software I’ve found that handles this exception to the general rule (I know there are others, but most are priced out of the reach of small accounting offices like mine). All it took was some “what if?” during the design process, resulting in a product that adapts to the customer’s needs without any custom programming being required.
The example I’ve used is obviously aimed at small businesses, but the principles apply equally to enterprise level software. In my mind, failure to at least consider how to introduce flexibility to the product is usually a result of being either cheap or lazy.
Isn’t this what ITIL is supposed to do?
I don’t think so. ITIL doesn’t have much to say about the application layer, or, for that matter, about architecture in general, and this issue is all about the application and information architecture.