Take Charge of Your Business Software Purchase

Let’s talk shop. We all use software every single day at work and in our personal lives. We all buy software—whether it is subscriptions to Headspace and SimCity apps or team tools and enterprise solutions for our companies. We are all buyers. And many of us will be on buying committees, maybe even leading the search and decision process. If that is you, read on because I’m going to share insider info. I’ve been on and led those committees, but I also have been on the vendor side, as a sales consultant, implementer, and now marketer.

Your Goals vs. Vendor Goals

If you need to buy software for your team or company, you have some need. Your business needs will drive your requirements and search for possible solutions. In addition to the need, you have a budget, team expectations, a work culture. You also have competing projects and real work priorities. Finally, you want (need!) to buy a successful solution.

You’ll have your metrics on return on investment (ROI) and success, but minimally we all define success as:

1) The software was implemented fully

2) People are using it

3) It’s making work better in some way

But what are the goals of a software vendor? It seems like a too-obvious question with the answer being to make a sell. The question is what kind of sell the vendor wants as that indicates vendor behaviors—from development, delivery, and support of their solutions to how the vendor wants you to engage during the buying cycle and how you should engage the vendor.

Solution Delivery Requirements

The key is to know what each vendor identifies as requirements for the end solution delivered. Why? The delivery requirement for software is about deployment and maintenance—what will be supported and what the experience should be.

What does this mean? Let’s take a look at this connection between requirements and end solution to see how requirements are the insight into a software vendor’s goals on everything from revenue streams and sales processes to product architecture, implementation tasks, and customer relationships:

• Technical: Cloud or on-premises.
  This is the branching point for technical expectations. If Cloud, what type of Cloud? Public Cloud will have the most minimal requirements for your resourcing but should include industry-standard security requirements and potentially added regulatory-driven requirements. Private or hosted Clouds usually push some resource requirements to you, the customer, for hardware, infrastructure adjustments, and security modifications. On-premises will have customer requirements to provide in hardware, infrastructure, security, and people resources you need to identify.
• Configuration: Business-ready or blank slate.
  This decision is made early in a software company’s life and is perhaps one of the most significant for users to understand. What does this mean? If a requirement is to create a software that is designed for a specific business process, then the software vendor must do in-depth use case studies for those processes and create a solution that fits the needs. This would include identifying data object types needed, process flow behaviors, security or access controls, and more. It creates boundaries, but within those boundaries the vendor can deliver something that is ideally suited for those processes. The result is something where configuration is easy, typically low-code or no-code.If the requirement is to provide an open or blank-slate platform with an emphasis on nth degree configurability, then you’ll be looking for a solution with a published, open architecture and extensive API or middleware layer that allows you to define the system’s behaviors. You’ll want to ensure the vendor is committed to continuing development on the solution and its coding access points. In addition, you’ll need to document all customizations for maintenance—as the system is now unique to you and requires resources.
• Software Updates: Don’t assume.
  Remember the discussion on the technical branch with Cloud and on-premises—obviously on-premises means you are most likely responsible for software updates at a technical level. If you do go the on-premises route, make sure you understand what is involved in an update. How is the package delivered to you? Is data integrity maintained? Is it a true update (apply a set of executables to bring the system to the latest release) or is it an uninstall/reinstall process? How long does it take for updates? What happens if the update fails and you need to roll back? Get all your questions answered so you can plan.For Cloud, you might think all cloud solutions provide the same update experience. This isn’t true as it depends greatly on the cloud architecture and what requirements the software team had when developing the technical layers of the solution. If the solution is deployed for you on a single-tenant Cloud, you most likely will need to schedule the update with your provider as you are the only customer on that platform. That may not be a bad thing unless that deployment method is coupled with some decisions about configuration and integration that allow you to create custom-coded areas. Any coded work outside of a standard API or integration layer requires testing before update (remember the documented list we talked about in Configuration above?). For Cloud, ask the questions about how updates are released, if you need to schedule, what happens to your configurations and integrations, and downtime expectations. Also, check to see what your team is responsible for and if there are any charges you might incur if you need more support for anything.
• User Provisioning: Think scale and maintenance.
  When dealing with enterprise software across teams, you will have necessary user provisioning tasks related to system access—what users can see and do in the solution. Software companies can make user provisioning as easy as possible for you, but it doesn’t just happen automagically. Scalable user provisioning design is a requirement that then needs thoughtful architecture around how data objects and fields intersect with users and actions users can take.
• User Training: As little as possible.
  We use software every day in our personal lives—to bank, make travel arrangements, order food, communicate, schedule meetings, hold meetings, get news, and fill those waiting moments. What this means is that at our company our users have expectations about software, how it should behave, where things should “be” on the screen, how they can search, and more. These expectations flow into work software. When looking at solutions, one of the first things you’ll notice is ease of use (or lack of it). Are the most common actions obvious? Does the software help people do work with flows, tips, and overall design? No solution will 100% function how every user on your team wants it to, but you want users to have an overall positive experience with the software. This lessens training on how to use the software so you can focus on what you need users to do—the processes.
• Integration: Depth and breadth.
  Your business needs most likely include eliminating data silos and a good solution will most likely do that for you, bringing connected data sets under control in one place. However, businesses have many teams with data sets and needs that are particularly suited to certain types of solutions. For example, customer relationship management (CRM) processes are very transactional, and the data set varies greatly from product lifecycle management (PLM) processes and data set. The result is that we don’t have one huge solution to rule them all. Instead, most companies have a set of core enterprise solutions with recognized flows where certain parts of data sets need to connect, either in one direction or both directions.When evaluating solutions, understand how the software companies approach this reality. Do they have flexible integration options across a wide range of other business spaces that should intersect, or do they emphasize only certain solution choices in other business spaces? Even if a vendor supports your other enterprise tools today, if those are the only ones on the list, you may be locked in if your company decides to switch. Here is an example: You are shopping for a PLM system and you have Oracle ERP and Salesforce CRM today. If data flows across PLM to ERP and CRM are important to you (and they probably should be), you’ll look for vendors that integrate with what you have. Be careful though—if the vendor ONLY integrates to Oracle ERP, what happens if operations moves to NetSuite in two years? Explore how the vendors have approached integrations as a strategy, not just specific point-to-point needs.
• Expansion of Software Footprint: Room to grow.
  Finally, the one constant is change. Your business will hopefully do well, resulting in growth and new pain points. How does the software vendor account for growth—both in the solution platform and how the solution is packaged (sold)? Is the solution developed in a way that leverages your configuration and user provisioning for new functionality or modules, or do you have a lot of steps to re-create your basics for a new module? Is it easy to “turn on” or deploy functionality areas or does it involve a technical implementation and services? How does the vendor sell the solution? There are many ways to package offerings and, of course, software companies need to make a profit—but they also can create packages that are sensible for how you do business and grow, or they can create structures that make it difficult to predict final cost or feel like death by a thousand cuts.

Aligning Goals

It all comes down to goals. The question you need to answer is this: What requirements did the software vendor have for the end solution, its delivery, updates, and maintenance? Requirements determine everything—from the sales experience and pricing and packaging of a solution to the deployment experience and long-term maintenance. Ultimately, requirements tell you what a software company’s goal is for their relationship with you. Make sure your goals align with your vendor’s goal or you’ll risk failure.