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.
