A Letter From Our CEO
The global situation caused by the COVID-19 (novel coronavirus) outbreak is changing day by day, hour by hour. As all our...
Information technology (IT), operational technology (OT) and digital strategy executives who are considering whether to build their own connected worker solution in-house, or partner with a third-party software provider.
Ask any operations manager if he or she wants to get more data about the day-to-day tasks performed by workers on the plant floor or remotely in the field, and the likely answer is yes. Who doesn’t want to connect their workers to get better insight into what teams are doing, how they do it, and how they can be doing it better so that the company can make or save more money?
This isn’t a new problem. But, from a technology and implementation perspective, it’s easier said than done.
Because getting data out of your workers relies on those workers to adopt and use your technology at scale, any major decision should be made with the end user in mind.
One of the first decisions to make is whether you should partner with an external software provider or develop your own. Here are six important types of questions to ask during your decision-making process.
How quickly can you develop and implement a product? Do you have the right internal champions, team(s) with relevant experience, chemistry, and dev tools ready to go? Is the team insulated from external noise and competing priorities?
Considerations: SaaS solutions can be pre-configured out of the box to accelerate time to market (TTM) and time to value (TTV). The time between configuring something and having it in the hands of users to begin capturing data and driving outcomes can be in as little as a few short weeks. These solutions are usually designed with the end user in mind, meaning en masse adoption is often much higher and faster.
Internally-built solutions can take several months (up to a year, in some cases) before it gets in the hands of actual end users. There are typically long lists of must-dos and “parity” items that your output must include; otherwise, it’s deemed incomplete. The larger the initiative and the longer something is being developed, the less likely it will ever ship, let alone be successful. LEARN MORE
Do you have a program in place to grow usage over the long term? Is leadership across locations and business units truly held accountable to deliver value and success, and contribute to a well-understood outcome they agree on?
Considerations: SaaS solutions often provide dedicated customer success teams to define and drive not just technical key performance indicators (KPIs) but also adoption goals, based on proven best practices. Customer success organizations can partner with leadership teams to show quick wins.
Internally-built solutions often rely on multi-tasked teams (IT and functional) to drive top-down success. Competing priorities are often distracting, and localized challenges will slow down TTV. It’s critical to have the people or person responsible for outcomes be able to laser-focus on the initiative, especially in the early period of adoption where users are learning and asking questions.
Do you have the budget and resources to realistically and adequately ensure plan continuity?
Considerations: An internally-built product is likely to incur higher ongoing maintenance costs and higher costs to perform timely upgrades that match changing business needs. An internally-built solution also needs to handle user bugs, user issues, app crashes, platform issues and various other user problems.
SaaS solutions, on the other hand, can amortize their build and upgrade costs across multiple customers. SaaS platforms often have industry-standard SLAs for performance and availability, and support teams with a clear escalation process and someone on the other side of the screen ready to listen and help. LEARN MORE
The modern API has taken on some characteristics that make them extraordinarily valuable and useful:
What level of investment is needed to build basic functionality or integrate the new solution to existing systems – MES, ERP, etc. – as well as other future technologies (e.g., augmented reality, voice I/O, wearables, etc.)? Can you quickly add new functionality as new business cases demand them?
Considerations: SaaS platforms leverage APIs to quickly and easily connect with common core enterprise systems. They also regularly evaluate new players in the space and emerging use cases to determine integration opportunities. SaaS solutions also take into account multi-language support, future feature enhancement, new feature delivery, and triaging ongoing customer app feedback.
To be sure, an internally-built solution might leverage existing business integrations. Where things get tough is when features need to be improved, new features are requested, and everything being built has to be supported and maintained. Users expect features to improve over time as they provide feedback. LEARN MORE
Do you have the resources to continuously monitor product maturity and to look for a better way of doing things?
Considerations: Vertical SaaS solutions are hyper-focused on product-market fit, and are constantly evolving and enhancing their platforms to meet changing needs and address emerging concerns. There’s a clear roadmap and ongoing internal testing of new technology.
An internally-built solution needs TLC to avoid becoming stale and outdated, and to continue to ensure it is able to address even basic use cases. The cost of continuing to invest in incremental enhancements can grow quickly as more complex use cases and scenarios are requested. Is the product you’re building something that the successors of your leaders value and want to continue to invest in? Are you building something so custom that it will be difficult to rip out down the road? LEARN MORE
Do you have the in-house expertise to conduct research and testing, and build designs and interactions to deliver a consumer-grade experience that users expect? UX is not to be skimped on; it could mean the difference between satisfied users adopting your solution or creating upset users that will campaign against any digitization initiative.
Considerations: An internally-built solution requires having someone on your team with a UX pedigree. UX contains several domains that have to work together to deliver the best experience to satisfy the user. UX shouldn’t be – but often is – taken for granted because of the top-down nature of an internally-built solution.
A SaaS platform has teams of people who focus on conducting user research, user testing and iterative prototyping that leverage common design languages and design patterns for the best user experience. LEARN MORE
Building solutions at scale isn’t for the faint of heart; it requires dedicated long-term resourcing, specialized expertise and committed championship, just to name a few.
But, to be clear, partnering with a SaaS provider isn’t always perfect, either: There are other customers and markets competing for their attention, and they may not have the institutional knowledge of
The best approach is to put bias and pride aside: Outline your goals, sit down with your team, and come to a decision that’s best for the users – the workers in your factories and in the field. In the end, it’s them who will provide the knowledge (and, therefore, the data) you need to make your connected worker initiative a success. LEARN MORE
Because getting data out of your workers relies on those workers to adopt and use your technology at scale, any major decision should be made with the end user in mind. Here are six important types of questions to ask when you’re trying to decide whether to buy or build your own solution. [5-min. read]