Blog: Dan E. Linstedt

« RFID Tracking and Nanotechnology for BI | Main | The Answer? MDM - MMDM - SOA and Registries »

IT from Cost Center to Profit Center - Next Steps

In a previous blog entry I discussed the nature of turning IT from a cost center into a profit center. In this entry I'll disclose a few of the requirements, and a few of the steps needed in order to head in that direction. Of course, you can always comment or send me an email - I'll be happy to discuss these items with you directly. Keep in mind that the company I did this with: a. I was an employee of IT, b. I was the "new guy" in the good-old-boys-network, c. there was a huge disbelief that IT could deliver anything let alone on-time or within budget, d. the organization was split by business contracts; my co-worker couldn't work on my project without budgetary approval even though they were a part of IT.

Also keep in mind that this company (at the time) was 7 sectors, 53 companies (all managed by P&L) including IT, and 150,000 employees. It was a large company, and a lot of hurdles had to be overcome.

Here are the steps I took to make it from scratch to success in 9 months:
1. Moderated the user community, defined roles & responsibilities, held the business users accountable for the amount of time they signed-off on to dedicate to our project.
2. Became familiar with the business language and terminology. Spent time with the business users to show I was serious. Interviewed some of them, but mostly watched them work and took lots of notes, asked lots of questions pertaining to HOW they did things. Learned what was efficient and what wasn't from a business perspective, in other words what they did that was a manual effort - that could be automated.
3. Found "friends in business" who began to believe in what I was doing, I educated them on the progress both good and bad - they stuck with me in the "bad" times and held the nay-sayers at bay until we delivered.
4. Delivered close to on-time, and close to on-budget. We were slightly over due to scope creep and the Business Users changing the business requirements.

Once we delivered, the real magic began. First we delivered on the promises to support the reporting requirements the business had. Then, we started educating the users on everything else we had stored along the way. Showing value to the fact that the enterprise data integration store (EIDS) or EDW contained not only "good" data but "bad" data as well, dispelling the whole notion of truth.

In this particular case, we focused on bringing finance data into the warehouse for matches against workers' hours and comparing that against contracted hours. Finance fought us tooth and nail at first, then they hired auditors to shut us down, claiming the data warehouse was wrong.... Well, if you've followed my blog, you'll understand that they couldn't shut us down, and what happened was: the auditor found a billing error that had been occurring in the operational reports for over 15 years. Once we had finance's blessing, other things became easier.

The following steps are necessary to complete the transition:
1. Establish and stay close to the original business sponsors of your integration store project.
2. Bring in more data than they ask for, begin to show them and the rest of the business HOW you can link this information together and make sense for the business, put together slide shows, give presentations, invite users to web-conferences, ask the business user to set it up and send out the e-mails. DON'T send emails as I.T., most of the time other business organizations will ignore you.
3. Have your business user start the presentation by explaining the value you've brought to them, have them explain a specific case or two - the more specific the better (in terms of dollars and cents/sense).
4. Tell the business user ahead of time: if we get a business user to sign up, we'll give them a log-in for 1 to 2 weeks for free. We'll track their queries; build a simple star schema (one star, single data mart, single denormalized reporting table).
5. At the end of their trail period, if they've used their data, logged in and actively "queried" it, then offer them a deal (through the business user of course): Pay to play - want to keep it? looks like you're using the information, help support the cause - sign an SLA and put money in the pot for storage, maintenance work, and hardware upgrades, and we'll keep your data on-line. If you can't afford it, don't want to or aren't using it, we'll drop the tables today, delete the data - and if you want it later, just ask.

What happens is: success breeds success, for every 1 to 2 business users that don't want to sign up there will be 5 waiting in line to get their integrated data set.

This is a bottom up implementation style; please please please remember to architect TOP DOWN so that when you add new data sources, your enterprise data integration store can handle it without much effort. (See the Data Vault data modeling architecture for more information).

The point being:
1. You need an AUDITABLE and COMPLAINT historical, integrated, enterprise information store.
2. You need a business user willing to go to other business units and sing the praises of the value you brought to them.
3. You need to track queries, and logins, and data utilization from new business units.
4. You need to be willing to SHUT DOWN those who do not pay-to-play.
5. You can't be afraid to get executive sponsorship and to go to the executive staff when you need business disputes resolved.

I did it, as a peon in a corporate good-old-boys-network world. It can be done. When I arrived on site, the project was 6 months in the hole, the business users were angry (to say the least) and the money holder was ready to pull the plug. 6 months later and 3 phases later we delivered with a team of 3 people and a data architect. It can be done. We received executive visibility and sponsorship after delivering.

If you are curious, or have hurdles in your organization you'd like to overcome we can help you. We've got assessment and corporate guidance assistance available. We've been there, we know what it takes.

Got a story? I'd love to hear it.
Cheers,
Dan Linstedt
CTO, Myers-Holum, Inc
http://www.MyersHolum.com

Share: