{"id":342,"date":"2019-07-08T15:54:06","date_gmt":"2019-07-08T19:54:06","guid":{"rendered":"http:\/\/www.heliotropicsystems.com\/blog\/?p=342"},"modified":"2019-07-08T16:03:13","modified_gmt":"2019-07-08T20:03:13","slug":"i-am-not-supposed-to-bad-mouth-an-incumbent-it-support-company-or-existing-vendor-right","status":"publish","type":"post","link":"https:\/\/www.heliotropicsystems.com\/blog\/index.php\/i-am-not-supposed-to-bad-mouth-an-incumbent-it-support-company-or-existing-vendor-right\/","title":{"rendered":"I Am Not Supposed to Bad Mouth an Incumbent IT Support Company or Existing Vendor, Right?"},"content":{"rendered":"\n

But what happens when something that another IT provider, or vendor, does is so not aligned with \u201cbest practices\u201d that it makes me shudder? What if their actions could cause a serious problem at the client\u2019s (or prospect\u2019s) site that might have otherwise been avoided? Couldn\u2019t I then be forgiven if I mentioned that the other guy\u2019s effort was misguided?<\/p>\n\n\n\n

I guess it depends on the circumstances.<\/p>\n\n\n\n

I encountered two instances of less than stellar computer infrastructure design in the early part of June, and my frustration was significantly higher than that expressed by the folks who were affected. Could I not be forgiven if I said, \u201cWell, you know, those guys really messed up here, but I have a way to fix it.\u201d<\/p>\n\n\n\n

But I can\u2019t explicitly say that because I don\u2019t always know the kind of relationship the client (or prospect) has with that vendor or IT company. Instead, I\u2019m usually turning things around by saying something like, \u201cWell that\u2019s not how I do things, because after 10 years in business, I\u2019ve learned that this approach \u2014whatever this<\/em> is \u2014 works much better.\u201d<\/p>\n\n\n\n

Of course finding the appropriate solutions to a client\u2019s \u2013 or a prospect\u2019s \u2013 problems is the core of my business. The tag line for Heliotropic Systems has been \u201cComputer Systems Analysis & Design\u201d for more than 20 years. My goal is to design and deploy computer and network hardware and software with the understanding that it is supposed to operate properly, based on the client\u2019s requirements. In my very parochial way of thinking, I guess that\u2019s pretty much what anyone would want, never mind expect.<\/p>\n\n\n\n\n\n\n\n

So let\u2019s take the first case. I received an email from a client that some of the video monitors at the site were not displaying the cameras. Overnight I had received alerts from their Uninterruptible Power Supply (UPS) systems that indicated there had been electrical disturbances from 1:20 to 1:25 in the morning. I responded to the client\u2019s email with that information, and then went to take a look at the camera closet to see what was going on.<\/p>\n\n\n\n

I found that the cameras and all of the related hardware were plugged into only two UPS devices. One of those devices was absolutely dead (it did not power on). Now most of you know that I\u2019m a huge proponent of UPS devices because they can protect equipment from fast changes in the electrical environment. I also point out to everyone to whom I sell these devices that they come with two \u201cbands\u201d \u2014 one that provides only protection and another that provides battery back-up plus surge protection. Your important equipment is supposed to be plugged into that second band.<\/p>\n\n\n\n

You can imagine my surprise when I found all of the hardware was plugged into both bands on each of those UPS devices. That means that some of the equipment was protected properly while some was not. It appears that one of the UPS devices simply couldn\u2019t handle the stress of the electronic interference. In other words, it did its job and sacrificed itself rather than letting the hardware get damaged.<\/p>\n\n\n\n

The cost of the camera implementation was in the low five-figure range, so I had to wonder:<\/p>\n\n\n\n