How many times in a day do you say I wish there was a tool to do this” to yourself and move on with your work? The more we talked to the people in the world of Operations, we realized that they say this a lot more frequently than any of us.

Something breaks in operations every day and that makes things super hard not just those who are on the move delivering value to their customers but also the ones who build systems for these people.

More often than not, product and operations teams hit a roadblock when their growth demands them to go granular with their data visualization, and with so many open sources and paid platforms to choose from, the quintessential build v/s buy dilemma can get overwhelming especially for decision-makers in the world of operations.

We talked to senior leaders in businesses across the globe to understand their operations workflows and how they navigate through such strategic decisions internally.

What makes measuring Operations hard?

A typical mid-air refueling exercise using a flying boom

Not everyone reading this article will be involved in operations that require the kind of precision aerial refueling takes. However, behind the scene acts like managing stockouts, rebalancing vehicles, optimizing demand and supply (and the metrics around these), etc are challenges that ops teams across the world deal with every day.

Well, for any business driven by operations in today's world, without a robust analytics stack in place, ensuring maximum utilization of moving assets becomes impossible.

Here's what current analytics stacks look like at a typical company in the mobility sector.

Modern analytics stack at a typical mobility company. 

Do you see the problem here already?

Maintaining a stack of tools and processes to parallelly manage all of these individual operations isn’t a simple task in any manner.

And to add to all of it, getting to the root of an issue every time something breaks takes a surprising amount of detailed analysis (aka writing queries), which makes it difficult to get right the first time around, and the pile of important details you have to deal with increases quickly.

Combining this with our inability of estimating time correctly, the whole exercise requires iterations, time, and at the end of the day, a lot of money.

Why building may seem like an obvious choice?

Building an analytics stack for your operations doesn’t necessarily mean you have to start from scratch. It essentially means a combination of open-source libraries, custom code, and internal expertise to stitch a solution together, built for your unique use cases.

Planning fallacy at play during internal discussions

With numerous open-source options to pick from, building a custom solution from scratch may appear to be an enticing option for the following reasons:

  • Complete control over how metrics are calculated;
  • Fits your use case 100%, you can create any charts/features you want;
  • You can integrate it with any of the other tools you’re using.

However, you also need to consider that it is improbable that you will get the resources to build this vision of the perfect tool. One of the reasons is that investing in something that is not part of your core differentiator is probably not a great use of your resources in the first place.

While it is both convenient and simple to get a basic version of something up and running in a short time. As your use-cases get diverse with scale,  the volume and complexity of your fleet data will compound over time and most teams run the risk of either being left behind in terms of technology & reliability or going back to where they started.

The open-source dilemma

Most kick-ass open source solutions are built and maintained by a community of contributors who care about a particular problem. In this case, helping you always stay on top of your game.

While these open-source tools evolve in responding to market needs, it is the communities behind them that engage in building new features, and releasing security patches, documentation, and support.

However, the moment you induct an open-source framework and build your own version on top of it, you branch into an uncharted territory, where your engineering teams end up managing what an entire community of creators was originally responsible for.

How do you decide then?

Our goal with this article is not to count the odds against building a custom solution and persuade you into buying something at the end of this page. It is in fact helping you with the right framework that can help you ask the right questions before deciding which way to go.

The right framework

A common trend that we observe during our interactions with mobility companies is that analytics stacks at most companies are broken in some or another way, with every step of the process involving an entirely different set of tools of their own. These point solutions and processes solve only a small piece of the puzzle requiring a combination of at least 5 different skill sets.

Whether you’re deciding to buy, build internally, or a hybrid solution for your operations, the best place to start would be to ask the following questions.

Identify the Technical and Functional Scope of your solution

Given the complexity and ambiguity involved in operations, it is important to begin this exercise by defining the functional and technical foundations of your desired solution.

Typical laundry list during the initial scoping process

While compatibility may not be an issue when you choose to build your own solution in-house, the ease of integrating with your existing data sources can vary across commercial off-the-shelf solutions.

Questions to ask yourself

  • What are our data sources? How easily are they available/accessible?
  • What are our reporting format requirements? How will they change as we grow?
  • What is the level of integration needed?
  • What COTS solutions are available? How compatible are they with our platform?

Feature/solution fit

Consider using the MoSCoW method to assess and prioritize feature requirements from your ops teams.

Must-Have: Critical for the system's success.

Should Have: Important but not necessary or critical.

Could Have: Desirable but not necessary. Or if time and resources permit.

Won’t Have: Least critical or for a later time.

Understanding the workflows of your operations teams is extremely important. While their needs drive your prioritization, having clarity on their core non-negotiable needs and noise becomes extremely critical when you’re building internally.

However, when considering COTS solutions, it is important to look beyond the claims made by the software vendor and thoroughly assess their feature roadmap and USPs unique to your future requirements.

For example, even the most popular BI tools in the market require you to manually upload CSV files and write complex SQL queries for data visualization.

Questions to ask yourself:

  • How do we plan to use the output: Executive dashboards or interactive, real-time analysis?
  • How will our needs change over time, as we add more customers?
  • As internal users become more sophisticated, will they need new or better features?
  • Are canned report templates sufficient, or will our users be able to drive more impact with full analytical flexibility?

Performance & Reliability

It is important that you establish your current performance needs, but you must also look into the future to determine your growth needs. Irrespective of an in-house solution or an off-the-shelf alternative, an exhaustive assessment of future risks of failure and performance bottlenecks is an important milestone in this entire exercise.

Questions to ask yourself.

  • How will we ensure performance and speed - today, and with future scale?
  • Where might our performance bottlenecks exist: connection speed, network speed, database performance, processing, query architecture, ETL scale, solution design, etc?
  • How will we test, measure, and assure system performance and reliability?
  • If downtime occurs, what are our exposure and risk?

Design and User experience

A poorly implemented stack of tools can result in delayed response times during critical breakdowns as root cause analysis becomes complex.

Complex systems may require trained analysts repeatedly write SQL queries to derive any insights out of your data, which not only adds to the delays in response times but compels your operations teams to be always dependent on analysts for any decisions.

Questions to ask yourself:

  • How intuitive is and complex is the solution we need to design?
  • How important is the overall user experience?
  • Are pre-set visualization templates sufficient, or will our ops teams need design capabilities?
  • How often will reports and dashboards be created and revised?

Documentation, Training, and Support

The proof of the success of your analytics solution will ultimately depend on the ability of your operations teams to learn these tools and obtain the results they want. In high-growth environments, working with large volumes of data can be overwhelming even for the most experienced analysts.

Product support, training, and documentation will play a major role in the adoption and ultimately the success of your end-users.

Maintaining changelogs, developing help content, and providing ongoing support can eventually end up consuming more resources than the actual development in the longer run — something to be taken a lot more seriously.

Questions to ask yourself:

  • How intuitive or complex is the solution we’ve put together or purchased? Will we need ongoing, in-depth training and documentation?
  • How often will documentation need to be updated due to feature and version changes?
  • What is the initial cost of developing support content? And what is the cost of ongoing support?
  • How will ongoing support be handled? Who will be ultimately responsible for training the support team?

Speed to Market

Poor visibility of your operations can lead to simple everyday issues escalating into edge cases with little or no time for planning effective resolutions.

Ensuring you don’t cut corners in rolling out a solution while still catering to the needs of your ops teams is key, not just to the profitability of your business but the overall satisfaction of your customers.

Questions to ask yourself:

  • What are the factors driving the development timeline?
  • How competitive is the market we’re operating in? Will a ready product offer us an edge in terms of speed & capability?  Is the deviation in focus warranted?
  • What are the potential consequences of delivering later versus sooner?
  • Have we considered all of the components of a complete delivered solution in the project estimate: inputs, design, POC, Development, Integration, QC, Feedback loop with your Ops teams, documentation, training, etc.?
  • What factors may affect our ability to deliver a solution on a timely schedule? To what degree do we have control over those factors?

Economics and ROI

Unit economics and ROI will eventually define the urgency with which your Build v/s Buy dilemma needs to be addressed. While ROI analysis can be an excellent tool to win the confidence of all the stakeholders involved, it will only be as accurate as your initial assumptions.

Having a realistic margin of error in your build estimates becomes as important as the degree of thoroughness required to vet a potential vendor’s capabilities during the evaluation phase.

Questions to ask yourself:

  • Have we associated timelines to both the costs and payback opportunities
  • Have we also considered potential lost opportunities due to resource & focus and diversion from core business?
  • Have we considered the ongoing costs of design and feature revisions?
  • What is our margin of error on the build & timelines?

Why could be a great buying decision for Ops teams

If you ticked the Buy check box in more than 3 places in the above framework, then can do wonders for your operations teams, while your product & engineering can teams focus on their core competencies, which is essentially delighting your customers with exceptional experiences.

Built for Data-Driven Ops teams.

Every line of code that went into building Locale was written keeping high-fidelity operations teams in mind. Unlike mainstream visualization tools out there meant for business reporting, acts as a centralized control tower, not just for your operations teams but other Business Intelligence dependent functions of your organization like growth and marketing teams.

No code supply and demand mapping at a city level. 

Operational excellence is a collaborative effort

With locale, you don’t just bring all your operations data into one centralized place, but you also bring all the stakeholders responsible for your operational excellence into a collaborative space where you don’t just run experiments but also measure their impact on your north-star metrics in real-time.

Tagging people in real-time.

Empathy + Expertise at the core is the only operational analytics platform out there that is tailor-made for the workflows of your ops teams — however, it doesn’t end just there. Every single customer we partner with is onboarded by a dedicated and extremely empathetic customer success team, that is deeply invested in your success.

Real-time alerts for personnel on the ground.

From ingesting your data, integrating with your workflows to training your end-users, we ensure your organization’s journey towards operational excellence is driven by our collective domain knowledge and a shared sense of purpose.

Book a demo with one of our specialists to discuss use cases unique to your business.

Ready to explore the insights hidden in your geospatial data? Go granular with today.