There are unique approaches to finding a partner in a hardware vendor and a software provider. Here's a look at some of them.
Vendor selection if a complex task. Here are some approaches for finding a hardware provider:
- Set your standard. Standardize on what platform for networks or PCs or servers or storage you want. Make sure you have very good skill sets in your group with what you select. I'll talk about people in a later post, but pay extra for REALLY GOOD resources. You'll need fewer resources, but you will pay more for them.
- Set your hardware refresh schedule. I am a firm believer in the three-year refresh for PCs. I've seen it time and time again. PCs older than three years old supply around 70% of helpdesk issues. Network switches could be on a five-year refresh if you designed appropriately. Servers I leave to the application architecture review I discussed in Part 1 of this Blog. Typically, three years is about right, but the rule is not as hard and fast as PCs because the variability in your server environment is much more controlled. (Note: In a future post, I'll talk about virtual PC and getting rid of the PC in the enterprise. If given the opportunity, I would go this route exclusively today.)
- Know what projects are going to be coming up in the future. If you plan on doing VoIP next year or implement CRM in nine months, all of this has an impact.
- Sit down with the vendor you choose and share the project schedule, refresh schedule, and year-over-year purchase estimates. You can do an RFP here, but usually the deciding factors come from the hardware requirements and risk. Servers can go a couple of ways. Network gets tricky. I alluded to Cisco as a partner earlier. The reasons were definitely not cost. Cisco provided all the networking tools we needed and, more importantly, I had REALLY GOOD Cisco resources. Routers, switches, phones, wireless infrastructure, security infrastructure, etc., were all developed and tested together. Theoretically this limits variability. In most cases this is true, but even with Cisco, there are things that can happen. One example had to do with a technology that Cisco purchased (vs. built) and we bought it too soon in the integration cycle. Storage can go a few ways as well, but you get the idea.
- Negotiate. Based upon the spend levels, the full book of business and future projects, you should get a decent price. If you go through a smaller VAR (which I recommend), you get the visibility you need and a bunch of free stuff as well. Examples that I have had include implementation discounts, extra equipment and maintenance contract flexibility. Do references first. Talk to peers in your local area and make sure they can be relied upon.
- Partner. (See above)
Here are some approaches for software projects and licensing:
- Get rid of Lotus 123 and Access 97 applications. If applications are that important, they should be ported to supported software. Get a consultant to migrate these apps to an enterprise database with a web front-end. Usually no more than $15k per application but usually less than $5k. This is nothing compared to the support costs.
- Kill all software projects that have lasted longer than one year. If it's worth it, the business owner will fight hard and make his case to continue the project. These usually just die because the business can't justify them. If they don't, then they deserve your attention. Usually, I find these development projects are in support of legacy applications that need lot of TLC or are on old platforms. This is what is supposed to happen. Now you have a list of applications that need to be replaced and possibly outsourced. Regardless, a business process re-engineering effort will find tons of new productivity gains and money saving opportunities.
- Get a better Microsoft licensing deal. This may sound like an oxymoron, but it's possible to get some savings. Not much. But some. Regardless, you will need to get control over software licensing most likely so make the effort to get legal. There is precedent for software companies providing surprise software audits. Remember what I said about the cost of reacting versus planning? This could be big in this case. The effort will at least consolidate your software inventory and at best help you make a possible case for open source.
- Avoid in house development of enterprise systems if you can. Unless it is seen as a competitive advantage, buy instead of build. There are cases where the integration risk far outweighs the cost of developing the software. Another case is where the software vendors are incredibly weak. I have seen this in niche industries like horse racing and gaming. If you do develop, hire your own project managers and make sure they are REALLY GOOD. Outsource development, but manage requirements and the project relentlessly.
I have learned the hard way on how to select partners. One key selection criteria is the people. You need a partner that brings their A players to the plate every time. If you've been around, then you know what I'm talking about. During the sales cycle you get this technology god who knows his or her stuff. Then when it comes to implementation, the vendor sends sub-par resources that are cutting their teeth on your dime.
I go through and select the team. The vendor has to send me resumes and I interview the resources. I did have a rule that I only used resources supplied by the vendor and not a subcontractor. The benefits of this include the implementers knowing back doors to support or can call up developer staff if they don't get an answer quick enough through the support channels. I have seen one exception to this rule, however. There's a small consulting company in Texas that specializes on a particular application. This application is not widely implemented and many of the top implementers and engineers found out they could make more money consulting with this company than they could working for the vendor. I would suspect that this happens rarely, but it's a lesson I learned.
In the end, when you partner, you have just a few companies that can do what you need them to when you need them to do it at the quality you need them to do it and all at a good price. You have reduced variability in your purchasing and our infrastructure. You have a large team of experts that you can learn from without having to pay their salary. You're knowledgeable about the latest trends and technologies that your partners operate in. You have saved the company significant amounts of money. You have consolidated the entire company's technology spend. You have built the infrastructure (both systems and process) to crank out new and innovative technologies that help our company grow quickly relatively inexpensively.
Bottom Line: You're a freakin' hero. Congrats!
There is a good synopsis at a high level of vendor versus partner here:
The table at the bottom of this article really demonstrates the power of partner.
When I was at an e-commerce start up, the systems administration staff under our CIO worked with a new company called Arrowpoint. They built a new load balancing application/hardware appliance that did a lot more than just round robin load balancing. It was one of the first stabs at intelligent load balancing. It determined server load before sending the http request. It also did a lot of cool stuff for managing the websites like taking a server or two off line for configuration management, etc. Granted, it was a new technology and they were trying to get their product noticed and marketed so they busted butt to make sure it worked in a production environment. When it went online, their engineers were in our data center for days. If there was an issue, we didn't have to go through some lame support system, we went to the engineers and they were at our data center at 2 a.m if needed. That is a partner. They new we were taking a risk with them and they put just as much skin in the game on their end.
This turned out to be a great thing for Arrowpoint. They were later acquired by Cisco for a nice payday.