Home

Should You Trust Your Integrator To Pick Your Vendor?

January 27, 2010 - 5:55pm — bex

CMS Watch was recently asked should I let my implementation consultants pick my ECM vendor? That's a pretty tough one to answer. On the one hand, your system integrator would have a fairly informed opinion about what software would work best for your problem. On the other hand, they may have a financial incentive to push you towards one vendor over another... so even if the vendor merely guides the process, there could be danger. A biased consultant will generate a biased RFP which may intentionally favor one vendor over another. I've seen it happen many times.

Hopefully I will not alarm anybody when I confess my bias is usually towards Oracle software. I have this bias for a few reasons:

  • they have good products that are easy to install and scale well,
  • I know their products the best, so I'll be able to implement an Oracle-based solution faster than a non-Oracle solution,
  • I have a great working relationship with Oracle

This last point is more important than most people realize... The CMS Watch article focused mainly on the negative aspects of a close relationship... but there are several positive ones as well. The main one being that enterprise software is typically very complex, with all kinds of hidden features and tricky undocumented configuration. If you or your implementation team has a close relationship with the vendor, you'll be able to extract much more value out of the software you purchased.

So, what's the "fair" solution? Kick out anybody with bias? Not quite...

I usually recommend that clients get unbiased feedback to do the initial selection... The biased person should not be involved here, because they may favor products that are a bad fit, simply because it's "what they know best." However, after the initial selection, the problems changes a bit. At this point, any of the top 3 should suffice... so the question now is which one will make your team the most successful? At this point, biases are ok, as long as they exist because your TECHNICAL team knows and loves the product. If they are familiar with it, comfortable with it, and know how to maintain it, then let them go with their gut... even if it seems like "bias."

You shouldn't be afraid of technology biases: they are there for a good reason... you just need to know when to keep them in check to avoid making a costly mistake.

Comments

February 2, 2010 - 12:43pm — Barry (not verified)

"hidden features and tricky undocumented configuration"

Not to go off-topic here, but the point that "enterprise software is typically very complex, with all kinds of hidden features and tricky undocumented configuration" is especially irksome to me, a front-end developer currently struggling with a enterprise-level content management system.

Even though this system is highly-rated because of things like scalability and it's trusted core technologies, it has some significant problems when it comes to documentation. This makes it especially difficult for bringing new developers into our team and for implementing the components and tools we hear about. We've started building our own documentation, and have looked around for further training, but it bothers me that we've invested so much in this system but are still at a point where we can't find the information we want in the minimal documentation provided and we feel we need to hire another consultant or trainer to continue to implement it correctly. We had a consultant (integrator?) at the start of the project, but it was never expected to require outside assistance at this stage.

Are all enterprise-level systems really this way? If so, we were especially naive about the cost of implementation beyond the initial launch.

And wouldn't it be better for the provider to increase customer satisfaction by providing better documentation so that customer and developers can implement their products?

February 3, 2010 - 12:32pm — bex

Re: "hidden features and tricky undocumented configuration"

Unfortunately, most enterprise level systems require a great deal of experience and training with the system. This is not exclusive to content management systems. In general, features outpace documentation. That can be a good thing -- because you get more features than you originally thought -- or it can be frustrating.

In my opinion, that's why a good "community" of implementers is so important. I'd suggest you get connected with other people who implemented similar things in the past, and trade war stories. Online user groups are great as well.

Even if the company documented everything in their enterprise software system, this community connection is important because it helps you understand how the system works in practice, not just in theory.

Post new comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
This form prevents comments spam...