Using Six Sigma Tools to Manage Your Martech Stack

Troubleshooting can be an art as much as it is a science. The science of asking good questions rooted in experience and the experience of others. Let the Six Sigma tools we discussed help you build a strong framework for thorny problems in your stack.

Troubleshooting Frameworks

Every martech stack is a process or system to be monitored, maintained, and optimized. When something goes out of process (or breaks down), you need a solid set of steps and tools to drill into the root cause to resolve the issue and then prevent similar incidents.

Remember here are the Six Sigma tools you can use:

  1. Five Whys

  2. Fishbone

  3. DMAIC

  4. Variance Monitoring

  5. Process Analysis

  6. Use the Knowledgebase

The best way to understand how to apply the tools is to explore a case study.

API Overflows are breaking sales process

Problem Statement: the Daily Healthcheck shows API calls between systems spiked 5% over our alert threshold and it appears to be climbing.

Control Chart for API Calls

The initial review of the Control Chart shows the system is exceeding our alert threshold and may be trending beyond the subscription Upper Control Limit (UCL). The implication is that the overflow may create downstream impacts such as:

1.     An error that may impact sales data and thus revenue.

2.     Will trigger other downstream processes that will slow down work or revenue.

 

Thus, we want to jump in and find out the issue quickly.

Five Whys

·      Why?

o   Reviewing the Control Chart it looks like the spike began at 5am and rising rapidly at a rate of 100k/hr.

·      Why? What is the source?

o   If we can’t answer this clearly, then apply Fishbone and search KB for similar situation

o   Source analysis shows System A sending 500k API calls per hour.

·      Why is System A doing that?

o   System A sent 100K lead updates to System B

·      Why

o   I traced sample leads to Source “Vendor B”

·      Why?

o   I spoke with the System A admin who said he updated 250k records with refreshed data to support a project upstream.

o   He did not follow the agreed System Governance SOP.

Now we’ve used two tools – Control Charts and Five Whys. Murky situations can be made clear with Fishbone Diagrams as well.

Ishikawa Diagram for API Calls

Great! Now we know that the primary cause is System A admin was asked to update 250k records to support a data segmentation project requested by Sales leadership. He felt under pressure late in the day and did not consult the System Governance SOP checklist. The checklist is a manual step that someone must remember to do.

Remediation Steps

Other than potentially fixing any incorrect data, one of the remediation steps is to prevent a similar incident in the future.

Root Cause: System Governance is manual, approvals not baked into the system.

Solution: Build change control process where no action can be taken until at least 2 people review the request and downstream system impact is schedule and analyzed. Automated guardrails prevent (or warn) system admins from running more than 25k record updates without further approvals.

In this simple example, you can see how powerful Six Sigma tools can be to drill into complex situations, get to a cause quickly, and decide how to resolve it.

Previous
Previous

Data Quality: The Hidden Roadblock in B2B SaaS Marketing

Next
Next

Mastering Marketing Channel Mix Forecasting: A Growth-Driven Approach for SaaS Leaders