The life of an enterprise software company is full of transformations. Markets change, technologies change, and processes change. Sometimes we can choose whether to make a change or not, and other times we have no choice.
In the case of our Production Support process, we felt a change was necessary. Being Proactive is one of our core values, and it came into play here. We wanted to get ahead of emergent trends in the Production Support needs of our clients. Following our core values, we needed to proactively build a new process.
That’s exactly what we did. In short, we transformed our Production Support process to align it more closely with a lean model. The results have been fantastic. In this post, I’ll talk about why we made the change and what kind of results we’re seeing.
Background: Finding a performance metric for Production Support
About a year ago, the Corevist management team implemented the EOS model. EOS, or Entrepreneurial Operating System, is a model for executives to lead their companies to higher performance, efficiency, and personal satisfaction. One of the core tenets of EOS is, “Everyone has a number”—i.e., a performance metric that indicates if they’re doing their job well.
The EOS method makes the point that having a metric is the only way to improve. If you don’t have an objective standard, you can’t measure performance. The logic is simple—and brilliant.
In terms of our Production Support process, we asked ourselves, “What’s our number? What’s the one metric that will reliably tell us how Production Support is doing?” We decided that number was monthly on time delivery, which is defined as how many tickets are resolved before their requested delivery date.
Getting from 30,000 feet to a new process that works in daily life
The EOS framework and the “number” for Production Support gave us a high-level picture of the end result we needed. The next step was to work backward from that end goal and determine how to get there logistically. Our new Production Support process had to balance the two competing factors just as well as the old one had—and balance them even better, if possible:
- Factor 1 – Production Support is our #1 priority because it affects live client websites used by hundreds of thousands of B2B buyers.
- Factor 2 – Production Support must run Lean, without wasted resources.
Keeping these two factors in mind, we asked ourselves, “What do we do to make sure tickets get resolved within their timeframes?”
Because Corevist is a global company, hashing out a new Production Support process required strategic coordination across borders and timezones. How could we get off Slack, put the webcams away, and get everyone into a room to figure out a new process?
The solution was a three-day “international Kaizen,” if you will, with key support and development stakeholders from around the company. It was challenging, it was refreshing–and most importantly, it was effective.
Here’s what we came up with in our 3-day intensive retreat.
Corevist’s new Lean Production Support process
We’ve defined our new Production Support process around 3 key factors.
1. We implemented one-piece flow.
In an effort not to waste resources, our previous Production Support process involved a fair amount of task switching by developers. A developer might work on a support ticket partially, hand it over to our QA department, and move on to a project ticket (new development work). It looked efficient on paper, and it worked well for years, but it had one problem: You don’t get value for your work until it’s in production, and because of the frequent task switching, no one developer “owned” the finalization of the work.
From now on, a ticket is not done until it’s in production. A developer starts work on a ticket and doesn’t stop until the ticket goes to production. Once a developer has begun a ticket, he or she can’t be moved off it until that ticket is complete.
2. We implemented a pull process for support tickets.
Previously, we had a 1:1 relationship between a client and developer. Joe Smith is assigned to Acme Products, so he either fixes a bug for Acme Products, or he’s building new functionality which Acme Products has requested.
We realized this policy concealed an inefficiency. From a support perspective, it doesn’t have to be Joe Smith—anyone can provide support to Acme Products, or any other client. Joe Smith’s unique knowledge is the features and functionality that Acme Products wanted to add to Corevist in the future. But Support involves fixing code and UI issues, and anyone with the skills can do it.
That’s why we implemented a pull process for support. Now we have one support queue and all tickets go into it. When Joe Smith finishes a previous ticket, he comes in, takes the top ticket in the queue, and works on it from start to finish, with no task switching, following our 1-piece flow process (see above).
3. We automated our QA testing process.
Previously, our QA testing process largely depended on manual validation and verification by our QA department. Automation would always have been faster, but before we made the change, we had no need to automate fully. In the old world, even if it took the QA department 4 hours to test it, the developer had already moved on to something else.
That wasn’t holding it up. We had long lead times because of weekly deploys. That meant long lead times for bug fixes to go out, and that allowed us to take our time on QA. Now that we implemented 1-piece flow, we had to change our deploy cycle. We were deploying weekly on Thursdays. Now we can deploy every night if necessary. There’s no arbitrary block on deploying the other 6 days of the week.
Before, there was a potential for something to remain in an “almost done” state for up to 6 days. We had to modify our process to deploy same day if the ticket is ready. We don’t always deploy every day, but we have the ability to deploy every day if necessary. That means we have developers on one side who can’t do anything else until it goes to production, and those developers have the ability to deploy every day.
To circle back—the one remaining constraint on this new, as-needed deploy cycle was the QA department and manual check. To remove the manual constraint and enable this new daily deploy cycle, we automated the QA check process. Every new ticket now runs through a suite of regression testing to make sure it works.
Putting a new Production Support process… into production!
The net result of all 3 of these is, now our queue is almost empty. Our QA queue will never have more tickets than there are developers and, in fact, due to our 1-piece flow process, there can never be more than 1 ticket per developer in any queue.
The results are pretty exciting.
- We’re now consistently exceeding our target on-time delivery “number.”
- 30% increase in on-time delivery.
- Average ticket lifecycle duration went down 80%.
As a result of all these changes, we do an average of 15-20 deploys a week. We’re getting fewer tickets than ever before, deploying more tickets than ever before, and our percentage of on-time delivery is higher than ever.
What’s more, clients appreciate the fact that we deploy daily. They know that any bugs will be ironed out quickly, and they appreciate the immediacy of everyday deploys.
At Corevist, being Proactive is one of our 5 core values. With our new Production Support process, we’ve anticipated the need for a streamlined process as our company continues to grow and our clients’ needs grow more complex. With this new process, Production Support is future-proofed and running lean. We couldn’t be happier with that result.
Moving forward: FREE case study
Wondering what SAP-integrated ecommerce looks like in real life? Download this case study on Mannington Mills. You’ll learn how this leading flooring manufacturer launched a B2C-style catalog, integrated to SAP, and saw a 150% increase in web sales.
FREE Case study: 150% Sales Growth with Rich Content
Talk to us