Originally published on Toolbox Tech.
By Kevin Chan, Purchasing Manager at LogDNA
As organizations implement more software-as-a-service (SaaS) solutions than ever, vendor selection and management are critical to company success. Kevin Chan, Purchasing Manager, LogDNA, shares key considerations to bear in mind while selecting the right SaaS vendor.
Enterprise leaders must be able to evaluate, pick, and deploy the right tools for their organization. Evaluating vendors is not an easy feat. Every niche problem is a competitive space, and it can be overwhelming. Let’s break down what tech leaders should look for in a SaaS vendor to ensure maximum benefit and return on investment.
One Size Rarely Fits All
Some tools offer bells and whistles beyond what you require but are nice. In comparison, others provide a tool that focuses in-depth on your use cases. Both approaches have their merits.
It’s important to reflect on your endgame and how fast you can get there with each tool. It’s also important to consider whether or not the operation will be simple after you’ve made it to your defined endgame, not just for yourself within your team but also for others around it. You’ll want to look at the ease of implementation, automation, reporting, and notifications. You should understand what type of controls you have in place and if they would be easy to incorporate into your existing process.
Lastly, avoid fixing what already works. Does the tool improve your current process in some way? Will it? Ensure that the tool can improve the processes for everyone and that you aren’t unnecessarily adapting something just to adapt it.
In Preparation for Growth
As enterprises set out on their growth tracks, the following points need to be kept in mind to ensure a good business-vendor match.
Scaling
No one can predict the future, but you want to make sure that a tool has room to grow with you so that you don’t have to change solutions again in a year or less. With that in mind, you’ll need to consider three factors:
- User experience: It’s essential to be mindful of how many tools the team currently uses and how they access those tools daily. Do they need to log in to the interface to use these tools, or are there plugins that allow them to access the tools and their information within their existing workflows?
- User management: This specifically relates to whether or not it supports single sign-on (SSO). The best integration is Security Assertion Markup Language (SAML) with System for Cross-domain Identity Management (SCIM) provisioning. Avoid things that don’t scale well, like managing user names and passwords individually.
- Reporting: Handling issues such as how data is reported from the tool, whether the data is centralized with a specific data team, etc., will help with visibility and transparency as the tool is used.
Cross-Team communication
It’s essential to take a step back and make sure you understand who would be interfacing with the tool, who would need access to the tool, who would be making the inputs, and who would be on the receiving end of the outputs.
Make an effort to also speak with the team to make sure that they need, or even want, the tool. If it’s going to be something that’s potentially poorly received or disregarded, it might not be worth adopting. The team should be as close as possible to unanimous in deciding whether or not to implement a tool. The exception is if a system will be implemented across multiple teams and can streamline a process. We sometimes see this in tools that support a DevOps culture, where a single developer or IT operations engineer may not see the total value of adopting a new tool, but it will ultimately help improve workflows or cross-team collaboration. In these cases, it’s worth meeting with the stakeholders to discuss the impact of adopting a tool to get buy-in and help them understand the decision.
Risk assessment
Last but not least, there are specific items to consider when assessing the risk of the vendor.
Commitment and all of its details (duration, involved parties, terms) is a factor you’ll want to look at. For brand-new vendors, you may prefer a shorter commitment level. Typically this results in something no longer than one year with no auto-renewal stipulations. This allows for greater flexibility and the ability to discuss multiple-year deals for established vendors later under certain circumstances. Service-level agreements (SLAs) are also typically good when working with vendors that impact your cost of goods sold (COGS); just be sure to note whether or not there are service-level credits provided.
Data, privacy laws, and things related to General Data Protection Regulation (GDPR) are a big topic collectively. For now, just know that you should make sure that you have a solid understanding of what data is received, stored by, or transmitted to the vendor. With vendors, you’ll also want to manage the issue of confidentiality. For this, you should consider signing a non-disclosure agreement (NDA). You should also ensure that your legal team reviews agreements that meet a particular risk or spending threshold. The vendor legal review process has changed significantly over the last five years due to how ever-changing data privacy laws are.
Finding the Right Fit
SaaS solutions are becoming more pervasive within the business, and correctly evaluating before entering a contract will help ensure teams gain maximum benefit and return on investment (ROI). The top consideration is always whether or not the tool’s capabilities fit the intended use case and will help achieve the desired outcome promptly. However, tech leaders must not overlook factors like scale, cross-team communication and buy-in, and privacy and risk when evaluating a new vendor. If all elements align with a company’s goals, SaaS tools can provide teams with substantial value.
