From the Cannabis Diaries #5: Go With The Flow

Updated: Jul 18, 2019

This post shares those experiences as a part of the Cannabis Diaries series of blog posts and podcasts. In this post and corresponding podcasts, we discuss why it is critical to understand how people work before grabbing for technology people, software, or hardware. Technology will not be the only factor, but it will be a key factor between success and failure as the cannabis industry evolves.

World class, industry leading brands outside of the cannabis industry struggle with knowing their processes and aligning their technology platforms. We see the potential for the same mistakes in the cannabis industry. By sharing these perspectives, we hope to prevent significant wasted time, money, and energy on technology mirages in the cannabis industry.

We recently finished a client engagement in the cannabis industry. Our responsibility was to review the current state of technology personnel, processes, and solutions, define the future state, and make progress toward the future state while hiring our replacements. All in all, fairly typical in consulting.

In our first week in California, I asked for a tour of the warehouse. Not the IT systems, but the warehouse itself. I wanted to see how people work, shake hands with the staff, and understand how IT was either making their lives easier or getting in the way. No laptop. No tablet. Just taking occasional notes on my phone as a warehouse administrator and I walked and talked. I mostly listened and asked for their opinions.

If you do not know how your business works, you are setting yourself up for expensive failures. One hour in process definition will save weeks of development time and money. This is an immutable law. Refuse to do business with any provider who is not willing to put the screens away and discuss how their process and your process compare to one another.

When you buy a software package or a solution, you are either driving or being driven. Specifically, you will be following the workflow that the software or hardware prescribes. Otherwise, you will need customizations that add to the cost to implement and cost to maintain the software. Customizations often make it difficult to negotiate a favorable contract or cut ties as you grow. This is how you end up with a Winnebago as your daily driver.

Most organizations dive immediately into software demonstrations and screen sharing dialogues. Software vendors will happily tell you that it is the best way to work, usually using some form of terminology, e.g., Agile, Activate, Activity-ize-ification, or some other branded excuse for not writing anything down. Stop. Ask for their default process, independent of the software.

For example, Salesforce has a prescribed flow for sales opportunities and deal flow. The solution is relatively easy to configure, but if you can compare your sales funnel, key filtering data, and critical decision points to the default Salesforce funnel and process, you can quickly mark up a whiteboard or piece of paper with a simple gap and fit analysis.

Well established companies managed by newly minted MBAs struggle to start with process. Based on our experiences thus far, cannabis industry leaders are no different. Frankly, most of these successful businesswomen and men have had bigger concerns than defining standards and processes. However, businesses that scale and make money in the long run support their people with processes and technology.

The cannabis supplier business process below was pulled together over the course of a 2 hour working session.

  • We focused on capturing the current state, taking care to avoid judging the process or activities as good or bad.

  • Circles represent different people in the process.

  • Squares represent different technologies or tools used in a particular step.

  • In a more formal flow, you might have decision trees and various paths, but in this context, we were creating an initial visual to drive design discussions.

In the image above, a relatively simple process required a lot of people and a number of technology solutions. If your gut tells you that this process looks overly complicated, you are correct. You would make a good consultant. For reference, Kettle has seen large insurance companies run five different claims applications, building a sixth, to support one claims process for three product verticals. Part of the value of writing down process is to make the inefficiencies and friction points painfully obvious. If you have more IT platforms than toes, you have a burgeoning problem.

In later meetings, we identified pain points and challenges within steps or handoffs between steps. These pain points were prioritized in terms of cost and value. When planning technology investments, you need to know if you are focusing on the $5 problems or the $5M problems. It is not that we ignore the $5 problems, but we address them in parallel to the high priority and high value problems.

The rest of this blog will focus on two scenarios from cannabis engagements. Both scenarios involved large scale software implementations. One implementation was a half million dollar Enterprise Resource Planning (ERP) solution. The other was a new HR Information System (HRIS) that was set to go live at the beginning of 2019, starting with payroll.

In both scenarios, the business teams were sold on the importance of buying software as the solution to their business problems. Unfortunately, the focus quickly shifted to features and demonstrations, rather than clear requirements, comparing business flows, and reviewing cost v. benefit.

Scenario 1: ERP Implementation

The project was launched at the request of the finance team. With a growing, distributed business, they needed to have tight and verifiable financial controls. Implementing an ERP presented an opportunity to standardize business operations and finance functions across the organization. A standard tool would make processes efficient, control costs, and simplify administration. The founding idea was sound and logical.

The current state, as observed:

  • Warehouse staff used hand scanners and paper printouts for pick, pack, and ship processes. Order accuracy was within control limits. Shipments were on time.

  • Back end integrations with QuickBooks helped reconcile inventory and financial transactions, though the systems were rickety and in need of maintenance.

  • Wi-fi coverage in the warehouse was spotty.

  • Workers entered the facility through an entryway monitored by an armed guard. Keypads monitored entrances and exits.

  • A paper shredder lockbox was needed for completed order manifests.

  • Route planning and delivery was largely manual. Inventory counts were manual.

  • Compliance and regulatory recordkeeping were updated daily. The process was far from utopia, but it got the job done.

4 months into design and implementation, the project was troubled. As the vendor solution became clearer, a number of difficulties, e.g., scope changes, were identified.

Here are a few customizations that the vendor identified, well after design was done:

  • Current hand scanners required a custom integration. The vendor recommended that we buy fifty iPads for the warehouse and replace the hand scanner and paper solutions.

  • All of our business units should scrap QuickBooks. Our software license included the finance module of the ERP and rather than integrating with QuickBooks, business units should just get on board with the new ERP.

  • Delivery management and route planning solutions were not out of the box, but they could be customized and integrated at a later date. The later date was not specified, although the business identified this as a critical feature needed to address competition.

  • Inventory controls were not a part of the initial deployment scope. Current challenges with inventory accuracy and quarantine management would be addressed at a date to be determined.

  • Integration with Metrc, the State’s chosen compliance solution, was in development. Metrc integration out of the box was a key selling point that drove the initial software selection. As a reminder, base your decision off of existing functionality, not vaporware and development roadmaps.

  • Repeat software demonstrations had failed to win support among business operators, e.g., employees in the cultivation and warehouse facilities. Employees were frustrated that 3 – 4 hours of their time was consumed by developers who appeared to be learning on the job.

Within 1 hour of walking the warehouse floor, we learned more about the good and bad of warehouse operations than the ERP team had learned in 4 months. It turns out that the ERP team had yet to set foot on site. Face palm.

The ERP team and the business were in direct conflict. Leadership had been sold a utopian vision, powered by the ERP. The employees performing hands on work were frustrated that IT was making their lives harder, not easier, and the new ERP wasn’t even live. What would life be like when the system went live?

Key Takeaways:

Expectations had been set without seeing how people work. You will not get buy in and adoption if people do not see that their problems are heard and addressed, even incrementally. Proper requirements gathering and design work requires an accurate view of how customers and people live and work. To gain this level of understanding, you must walk in their shoes. User experience and design leaders apply focus groups and user studies to understand and drive their designs. FaceTime, screen sharing, or video conferencing are reasonable workarounds if travel restrictions prevent you from being present physically.

IT should make work easier, not harder. Learning new systems, new devices, and new tasks without addressing core pain points was doomed to failure. When we asked for a copy of the workflow supported by the out of the box ERP, we were given a software demonstration. This was an immediate red flag that the potential change to workflow and activities were completely unknown. We paused the program, idled resources, and focused on immediate pain points, e.g., device security, e-commerce channels, and sales team effectiveness.

Software demos do not take the place of understanding workflow. Prior to shopping for expensive design or project software, Use Post It notes, napkins,photographs, or windows to document what you have observed, confirm your understanding, and drive subsequent system design or selection.

Scenario 2: HRIS Implementation

The HRIS project was launched by the VP of HR as part of an effort to standardize payroll, benefits, recruiting, and learning management. Like the finance team, the HR team was struggling to meet their performance objectives using their current patchwork quilt of providers and software solutions. 2 months before going live with payroll on the new platform, the VP of HR called to tell me that US payroll was being removed from scope, per the vendor. I was asked to dig into the details by the CFO and CEO.

What I found and why it mattered:

  • The initial vendor selection process was not documented. This is important because mature companies base IT investment decisions off of a brief, but clear, business case. If it costs more than a used Honda Civic, it should have a 2 page analysis of the costs and benefits.

  • My initial concerns were dismissed because the solution was in the cloud, i.e., software as a service. Where the solution is hosted (public cloud, hybrid cloud, private cloud, in a local server room or data center), does not matter as much as the ability to provide a plan for testing, training, and cutting over payroll. 1 month before payroll cutover, I still didn’t have those critical details available.

  • The change in scope was not formally documented. The vendor was removing 50% of the scope by taking US payroll services out of scope. Yet the initial contract, requiring full payment for full scope, was still in force. Eliminating or adding scope should result in a formal change request with corresponding price changes.

  • Payroll processes were undocumented. US and Canadian personnel that ran payroll were given access to a test system and asked to kick the tires. No formal test scripts. No formal use case scenarios. The chances that something would be missed in testing and break in production were high. Payroll is not something that you want to get wrong in the new year.

Key Takeaways:

Again, we were potentially changing a critical business process without understanding the full implications. Answering angry phone calls about missing paychecks was not the way that I wanted to start 2019. Despite assurances that the solution was “in the cloud” and that the vendor would take care of any issues, I knew that the client IT team and I would get an earful if something went wrong.

Cloud solutions or vendor agreements do not make life easier. In many situations, they are promising better service for a lower price than your own internal team can offer. Compare your workflow and activities, identifying the tools that you currently use, including potential integrations, regulatory needs, security tasks, and manual steps.

For example, here are some high-level steps, with supporting design considerations:

  1. Emma is a financial analyst who runs payroll for US supply chain unit operations. Could we have a central function run this and free up Emma?

  2. Every two weeks, she collects time card entries. Could payroll be run off cycle or ad hoc?

  3. She typically has to send reminders out via email, followed by phone calls. Could this be automated or simplified to make entry easier and faster?

  4. She cannot run payroll until she has completed timecards from everyone, which usually results in hounding at least two or three habitually late staff. Could we track a reportable history and have managers step in?

  5. She sends an email to the payroll services company, indicating that payroll is ready. Could we improve this process for efficiency, accuracy, and security?

  6. She receives an automated reply when the payroll is submitted, an invitation to review and approve the amounts for each person, and commit the run. How could we simplify the amount of checking and review that Emma has to do?

  7. The run automatically commits after 24 hours if Emma does not reply or have any edits. Has this ever created problems, e.g., if Emma is locked out of the system?

  8. Every so often, Emma is out of the office and James steps in to run payroll. He uses Emma’s account. Could we establish individual accounts for people for security and transparency?

If you do not know how your processes work, in this case payroll, you are simply outsourcing your problem in the hope that the vendor can do a better job than you. Cannabis firms should avoid the mistakes of their brethren in financial services, healthcare, and manufacturing and drive, rather than be driven.

24 views0 comments

© 2020 Kettle, LLC

Main St, East Greenwich, Rhode Island