Your vendor hired some really smart people – but are you cutting them off?

At the recent Melbourne VMUG I ran into a fellow blogger who works for HDS.   Now I have known this person for some years and interact with him regularly, I have a lot of respect for him and for the work he does (after meeting him I have even more).   But here is the thing:   Up until that day, we had never met in person.

The reality is that in this day and age, actually meeting someone face to face is not needed for you to have a professional courteous and beneficial working relationship; in fact as the world becomes more digital and businesses become more global, this paradigm of “I know this person really well, trust and respect them”, can happily include  “but I have never met this person face to face”.

The reason I bring this up is the never-ending struggle I have to get remote access enabled for the products that I support and sell.   When I worked at IBM this was always a challenge.   IBM is a huge company with enormous resources, but without remote access, the only way to leverage those resources when resolving an issue, was by offloading logs and waiting for them to be analysed.

The simple truth is that without either access to the device in question, or access to the correct logs from the device in question, whatever problem you are having is going to take much longer to fix.   And while that remote support person is waiting for your logs, they can work on someone else’s problem:  not yours.

Ouch.

I like to call this delay time and frankly when you add up all the hours it took to resolve an issue, delay time will be a major component.

So how to kill delay time?   The simple answer is remove the root cause:   Lack of remote access.   If you enable the remote support teams to actually access the source of your pain directly, you will inevitably get that issue resolved faster.   By how to do this?  Most vendors offer a remote access method, that inevitably forms one of four techniques:

  • Modems – yes those old faithful, slow and cumbersome squealers are still out there, but their days are numbered.  Modems are slow and the interface does not lend itself to anything too smart.   In the past, security concerns about modems related to fears about war-dialling hackers, but I am not certain most script kiddies even have modems anymore?   Of course having mentioned war-dialling, you cannot go past the classic film Wargames (apologies for the advertisement you may be forced to watch 5 seconds of).

  • Shared desktop – Things like GotoMeeting and Cisco Webex are examples of this.  This is my least favourite method as it usually demands the use of someones desktop/laptop in the client data center.
  • VPN in – This is a process where the vendor logs into your network using a tool like Citrix or Endpoint.     This is quite common (I use Citrix Access Gateway in particular on a regular basis), but often needs devices like key fobs or is tied to unique signature files (which can make it hard to share this access with team members).   For a vendor this is usually the easiest way to get remote access, where it is already a corporate approved method.
  • VPN out – this is a process where your product builds a tunnel outbound to a server at the vendors support HQ.   This form of private tunnel is controlled from the client side, but once built, allows the vendor to access the device from their remote location.  The client can then collapse the tunnel when the problem is resolved.   This is my favoured process as the process is always outbound and is normally easily controlled by the client, however equally it is often the hardest to get approval for.  This is quite simply because it may not match what is currently a corporate approved method, plus it may require firewall changes, which always raises eyebrows.

My main beef is that many organisations do not have any set strategy.   Ideally they don’t want to have any issues, which would allow them to avoid having to even think about this.   But in reality when bad things happen, you want the smartest most capable staff at your vendor plugged into and resolving your issue in real-time, not delay time.   Those people will almost certainly be in a different city or country.   You want their help, you need their help and you DON’T want them working on someone else’s problems while waiting for log files from yours.

So please… think about a remote support strategy and bring those smart people into your circle of trust.  You wont regret it.

 

Advertisements

About Anthony Vandewerdt

I am an IT Professional who lives and works in Melbourne Australia. This blog is totally my own work. It does not represent the views of any corporation. Constructive and useful comments are very very welcome.
This entry was posted in advice and tagged , , , , , . Bookmark the permalink.

4 Responses to Your vendor hired some really smart people – but are you cutting them off?

  1. Anthony of course you could leverage cloud technologies to assist with your remote access, or even protect the enterprise in the centre build a protective bubble of virtualised apps or desktop and then have the ability to support BYOD strategies.

  2. Sameed says:

    These are some of the best methods to work on solving issues! But alas, my region is more like – grab laptop, start car and head over to the client site. And all the while you’re working to solve the problem, the client is just sitting there, sipping coffee….

  3. OwenH says:

    This is somewhat simplistic. Sure, there are plenty of technology solutions, but this is rarely the barrier.

    For example, do you know some organisations are required to identify who has access to their equipment? By identify I don’t mean “vendor tech support ID:12345”. As the saying goes, you can’t outsource risk.

    Just a point from the other side.

    • Thanks for your comment. It really highlights the struggle between achieving the highest levels of availability and the also achieving the highest levels of audibility and compliance. I totally agree that clients should have the right to know exactly who is requesting access and exactly why they need it and exactly what they did when they had it… thats only fair and reasonable and may in fact be required by policy or law. The struggle I see is that remote access requests are put in the too hard basket and availability suffers as a consequence, when in fact a clear understanding of requirements from both sides could result in a better outcome.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s