More recent posts from the Servicenav team
27/3/20
ServiceNav 4.9 – New widget, SMS voice notifications, service templates
22/1/20
ServiceNav 4.8 – Graph widget improvements, new icons, service templates
10/1/20
Last month, the ServiceNav team were at VMworld in Barcelona, exhibiting in the New Innovators Pavilion. We met with hundreds of representatives from all sorts of organisations to discuss ServiceNav, it’s capabilities and the real issues that customers are facing in their organisations on a daily basis. Here are just three of the main themes of our conversations:
Organisations dependent on break-fix services to keep them operational are suffering from a lack of proactivity from their service providers. This isn’t good for the customers, but the service providers themselves are at risk by sticking with an old business model and not moving with the market as we discussed in a recent blog.
Similarly, organisations that have their own in-house IT team find themselves on the back foot by not having any monitoring solutions. They’re unable to anticipate disruptions to services; instead depending on users to report failures as they occur and having to manually compile service reports to justify performance and support required investment without any real metrics.
The people we talked to didn’t know what to look for in a monitoring solution and had been put off by the apparent complexity and technical nature of some of the products on the market.
Pricing models have taken organisations by surprise in different ways:
Many of the organisations we spoke to were concerned at the complexity of the solutions they have in place and the expertise that’s required to set up the monitoring or to make sense of the reporting. In fact, many said the tools are unpopular internally and they are driven to manually creating reports in MS-Excel in an effort to simplify things.
This can come about when there are different budget holders making independent decisions about what’s best for their part of the organisation. For example, monitoring Product X might be deemed best for the network team, Product Y for the storage team and Product Z for the Oracle DBAs.
The other common reason for organisations ending up with multiple tools is that they use the one that is shipped with a piece of hardware or buy the one that’s recommended by the vendor at time of purchase. So, Product A with a server deployment and Product B for a new IP telephony solution, for example.
In either case, there is no easy way to build a holistic picture of IT services, or to compile a shared view of the IT environment. Different products require different training and the organisation can end up with many niche product experts.
27/3/20
22/1/20
10/1/20