Even though IT is integral in implementing any form of full-scale Customer Relationship Management (CRM) solution, IT departments at opposing companies rarely have anything resembling a synergistic relationship.  The reason, of course, is that IT is most often not the customer.  We act more as a conduit for business solutions.  But by taking a closer look at how our vendor relationships are managed, we can find areas where process improvement is possible.

I was at a hospital last week to assist a vendor with a new system installation when the topic of server patch management arose.  Given that patch management is an area of focus for our company, we prefer to deploy critical OS security updates in a short timeframe following their official release.  This isn’t a topic that we typically debate with our software vendors.  We just do it in the name of security and work through any unintended consequences afterward.  It’s amazing how quickly company processes change after the network is brought down by something like the SQL slammer worm.

But the sensitivity of the medical system being installed in this case meant that consultation with the vendor about OS patches was the smart thing to do.  As it turned out, the vendor was very particular about which Microsoft patches could be installed.  Thorough testing is performed by the vendor for each released patch and, once passed, is placed on the approved list.  Here is the rub – we have to contact them for each patch to find out if it is approved.  How impractical is that, and how can the process be enhanced?

The vendor’s process for patch deployment places the onus on the customer, but holds the leash on which patches they will support.  A vendor maintained centralized patch management solution, such as Microsoft’s WSUS, would be my first preference.  The solution would involve publishing the approved security patch on a management server, and then “pushing” it to customer servers over a VPN or SSL connection, and always at a time that is documented as after customer business hours.  The only servers managed in this way would be servers specifically maintained by the vendor.  If such an elaborate system is not feasible, then at the very least the vendor should shoulder the responsibility of emailing the approved patches to a designated customer email route.

The above situation involved a seller and a customer, but the focus was never on interaction with the customer’s IT department.  The focus was on the relationship with the department receiving the medical computer system and the hospital as an entity.  This is how most implementations are carried out, and this is as it should be.  The IT department will not use the new system; just facilitate the infrastructure for its use.  But that doesn’t mean some forethought shouldn’t be placed on the relationship between the vendor’s IT staff and the customer’s IT staff.

I should note that the vendor in the example is a large and very capable company that we conduct a significant amount of business with.  I should also note that in most project deployments carried out with the vendor, it seems as if it is the first contact their IT department has had with us.  For instance, it is always necessary to point out that we have a branch-to-branch VPN configured for remote support purposes, and we require all servers on the network to be a member server in our domain.

Detailed records should be kept about a customer’s information network and support architecture as much as they should be kept about their supply chain model.  A total customer profile within a CRM solution should absolutely include IT details.  Not only does this result in a more favorable comfort level and rapport with the customer, it also produces smoother installations and more successful problem resolutions.