Remote Deployments with Tulip

We always prefer to work with customers in person. There’s truth in the old lean adage “go to gemba.” That said, there are times when in-person deployments simply aren’t possible. For these cases, we’ve developed a comprehensive method for deploying Tulip remotely.

In this guide, we’ll walk you through how we deploy Tulip to customers when we can’t meet in person. We’ll cover:

• When to do remote deployments
• How we structure and execute a remote deployment
• Examples of successful remote deployments

Over the last few years, we’ve standardized how we deploy Tulip to our customers. This is a process we’ve done over a hundred times, and one that sets each of our customers up for success.

Remote deployments are simply an extension of this process. We took a process that works and adapted it to circumstances where on-site consultations aren’t possible.

The consistent success we’ve seen with remote deployments comes down to experience and expertise. We know the questions to ask. We know where the common bottlenecks and blockers are. And we know what level of technical detail is needed early on to keep projects on schedule. When we need “hands on the floor,” we walk our customers through physical processes virtually.

Our general deployment process unfolds in five stages (which we’ll cover in more detail later).

1. Overall Scoping – Here, we clarify the goals, initial use case(s), training needs, and associated timelines
2. App scoping and development – Map the process and design application outline for selected first use case(s); Build with you the first Minimal Viable Product (MVP) App(s)
3. Deploy, Test, Iterate – Put first apps into production or deploy to test environment. Iterate and improve the apps based on feedback
4. Determine next steps to scale initial use cases and/or pursue others

Key Differences

The biggest differences in process happen early, during scoping, app development, and initial implementation. In short, we spend more time really learning the ins and outs of your operations.

Things that are often obvious when you walk the floor together are easy to miss when remote. Project details and specs and slip through the cracks when you’re not looking at the work cell where your apps will do so.

So when we’re unable to meet in person, we spend more time gathering requirements and details early; adapt a more frequent meeting cadence to ensure the project moves; and more coordination with the team and stakeholders. For example, we utilize online collaborative process mapping and whiteboarding tools. This allows us to work outflows and requirements together, and gives us a more complete picture of your needs. We’ll also ask you to share photos/videos of the production areas. In our experience, these methods are effective methods for designing and deploying projects remotely.

Recently, the need for remote deployments has increased due to pandemic-related travel restrictions. However, there are other circumstances when remote deployments may be preferable. In these cases, we’ve successfully deployed Tulip to customers virtually.

Here’s how we break down our remote deployment process.

It’s worth noting that many of these steps can happen in parallel. For example, we often train customers on the basics of the platform and app-building during the scoping phase. Identifying new use-cases and preparation for scale can happen during the initial deployment.

Project scoping – During this phase, we lay the groundwork for a successful project. We get to know your goals and your operation.

This work adapts well to remote scenarios. Much of the initial project development can be done over the phone or video conferencing software. Each customer works closely with one of our internal industrial operations experts, who can help identify use-cases and business value upfront.

Across multiple meetings with the Tulip team, we’ll collaborate to:

• Learn your goals and determine where Tulip fits in your company’s journey
• Define success criteria
• Pick and prioritize use-cases
• Establish a timeline, scope, roles, and responsibilities

At this stage, you and your team have access to Tulip University–our interactive online learning resources–to start exploring and developing your Tulip app-building capabilities.

At the end of this stage, we’ll have determined what a deployment will look like, how and when it will take place, and what needs to be done to execute.

App Scoping and Development

This is where we dive into the nitty-gritty of your operations. Your customer success representative will start detailed discussions about your facility’s physical layout, processes, machines, equipment, tech stack, and the personnel involved.

While we do this over video calls, we do our best to get a sense of your physical shop floor and operations performance. Remotely, we can work from process maps, plant layout schematics, floorplans, and other resources to learn as much as possible. Often, we ask a customer to provide us with photos and videos, walk us through their current processes on a video call, and share dashboards with existing performance information. During this phase, we do our best to learn product flow, layout, and which activities are performed by specific worker roles, and how they link to the performance challenges or opportunities.

Next, we move into the app-building process. Depending on the complexity of the use case or the process, this may involve several digital training sessions with your customer team reps. You’ll then work to build your applications or workshop the initial applications build by our team–whichever we’ve decided on during scoping.

It’s important to note that the details of the deployment are all worked out during this stage. We’ll work with you to resolve any technical issues, like hardware, connections, and devices. And we’ll begin the training and change management activities outlined during scoping.

Deploy, Test, Iterate

By this point, everything should be set to go. The apps should be built, operations connected, and team ready to use Tulip.

To maximize the success of the deployment, we follow the agile method (if you’re unfamiliar, you can learn more about agile here). In short, agile prioritizes short, 1-2 week “sprints” over long, linear development cycles. The goal of agile is to learn more by doing more and thus make more progress in the long run. Further, these sprints give you the opportunity to check in with your team to determine whether the apps are meeting your goals. Is it intuitive for the end-user? Do supervisors and management have access to the data they need? Your answers to these questions can influence further iterations.

Our objective is to get the app into the users' hands in the first sprint. This allows us to get feedback on the development and usage, which we then build onto the process mapping and user journey mapping from previous worked out earlier in our collaboration.

When it comes to remote deploys, we work with your team to set clear sprint goals. At the end of every sprint (usually weekly or every other week), we check in and propose adjustments as necessary.

Leading up to and throughout this phase, we’ll continue to check in on all categories of the deployment, including connectivity, hardware readiness, app design, databases, and connectors.

Capability Building For Broader Deployment

By this point, Tulip is more or less “deployed.” After several cycles of testing and iteration, your applications should be suitable for production. The technical and cultural elements should be settled, too. If issues arise, our support staff are experts and resolving technical issues remotely.

At this stage, we’ll work with you to begin the next phase of the project. This could be building your team’s or your operation’s internal capacities–a good example of this is training power-users at multiple sites who can then train their teammates. This is also when we’d begin to help you identify new use-cases, or to devise an implementation plan for previously identified use-cases.