Denial of access

I hear a story like the one I heard this week and I want to ask the apparent villain why. There must be a reasonable explanation.

At first glance, he’s like other managers I’ve known of who throttle promising work for what seems like a personal need for control. “So tell me,” I’d like to say over beers, “what were you thinking when you denied that analyst free access to that data? What’s your side of it?”

If beer didn’t work, I could imagine waterboarding, even though his explanation would then be less reliable.

Here’s the story: One young analyst’s boss wanted an answer to a simple question: How many customers are receiving premium service and paying standard rates? (Sorry, I can’t identify the company.)

The analyst had little training. He was only the most curious, persistent, and resourceful member of his department. He also knew a little SQL. But, as he puts it, “I didn’t know a dimension from a measure.” But despite scant knowledge and many obstacles, in a few months he won the company just over $500,000 in unforeseen revenue the first year.

First stop: the business intelligence system. But problems showed up quickly. While the billing database — the only one within the BI system — listed about 20,000 customers receiving premium service, the installation database listed 25,000, and the customer database listed 30,000. Each should have had the same number.

He knew why they contained bad data. Each new customer triggered a 45-step process that required customer service representatives to enter numbers in correct fields and to choose from drop-down menus. Errors came easily.

The IT manager seemed to shrug at this. He refused the analyst access to the desktop client, which would have allowed him to join the other two databases. All the analyst could do was review each record one at a time. When the analyst asked for help to learn the BI product, help was denied. Nor could he have access to the vendor’s help resources.

“They say it’s their database and they don’t want anyone running queries against it,” he said. “They’re afraid it would impact the performance. But all I want to do is pull a table out. Give me an export! I’m not asking for a complex query. It’s not sensitive data. In fact, anyone in the company can get at it. They have a strange philosophy.”

He admits his next move was sneaky, but justified. He used an SQL injection, a technique for unauthorized entry, to extract a table from the customer database. That database, he said, looked to him like a “10-year-old’s work,” and had no security built in. The administrator caught on when the analyst slipped up and ran an update. The administrator loudly threatened, the analyst said, “to have me listed as a terrorist.”

A loyal insurgent, maybe. Except for the accidental update, he never altered records. He’s only sent batches of corrected records to other departments.

“My boss was able to prove that I had done a great deal of good stuff in cleaning up the database,” he said.

The greatest benefit was identifying 2200 customers who received premium service but only paid for standard service. That list went to the billing department. Every one of those customers began paying more, at an average of about $20 a month.

Even so, approval for the relatively small amounts to buy the two tools he’s found most useful in trial versions, Lyza and Tableau, has taken months.

Insurgents often annoy veterans with their ideas and can-do spirit. I can imagine what the IT manager might say in a candid moment. “The little bastard thought he knew more than we did,” for example. “He would just mess things up.”

Or he might say, “All our data’s screwed up. You think I’m going to let him see all that, tell his boss, and let everybody know?”

He might also say, “I’m a jerk. I’ve always been one.”

Next stop: reasonable and articulate friends of mine who work in IT.