Meet the team: Jeff Jaisle
September 3, 2020
Meet the team is a series by Seraph, where junior team members lead conversations with senior Seraph consultants to learn from their experiences.
Today we present a conversation with Jeff Jaisle an Engagement Manager at Seraph with 25+ years experience in the Automotive and Manufacturing space as the previous COO of Brose North American Operations, and VP of Operations for both Benteler Automotive and JAC Products.
Data needs to be valid and in a relevant context to be useful
Justin: What's the biggest challenge with manufacturing teams using data to drive decisions? Do issues arise from: not collecting, not using collected data, or not drawing the correct conclusions from data?
Jeff: Typically the latter, most places have numbers and data they collect, rarely have I seen a situation where nothing is collected. The problem is two-fold.
- Sometimes what's being collected isn't real; numbers are gathered, but when validated, either they're incomplete or wrong.
- Data isn't visualized in an actionable way. Data is collected and funneled into various spreadsheets, but it never goes anywhere. It gets locked up in the system, preventing it from being easily communicated and readily accessible to the team. Data needs to be in a relevant context to drive a decision.
Justin: Are data owners, the people who would use that data, typically not involved in that process? Why would a company put together a system to collect data and not have it be relevant to the operations team?
Jeff: The collection, processing, administration, organizing, and communication of the data is parsed out to various people along a chain - most of the data collection begins at the shop floor. Also, the team is spread out across multiple shifts spanning multiple operations utilizing dozens and dozens of people. To make sure data is accurate, each person has to be trained. For example, scrap is typically collected manually. When a scrap part is made, an operator on the floor will decide the part is scrap, mark it and fill out a multi-part form. Then part of that multi-part form gets torn off and is brought up to the office where somebody transcribes it into a database and emails that out to a distribution list.
I don't know if anybody designs systems with that intent, processes just evolve organically over time into something that's either incomplete or has critical disconnects.
Over-automation can leave a system vulnerable
Justin: I'm picturing a situation where there is a recurring error, so the team implements a new scrap tracking process that collects a lot of detail to drill into a specific problem. As time goes by, that process is maintained and added to over time as more needs come in. The amount of data collected will keep increasing. Can companies collect too much?
Jeff: That's the other extreme. Systems break down, so the team decides to fix it with a more automated or more sophisticated approach, and then they go overboard. In operations, not everything is broken. Most of the stuff in place actually works as intended. It's the classic Pareto principle: eighty percent of the problem is driven by twenty percent of the causes. When companies go automated, they have sensors communicating thousands and thousands of pieces of data to them. When eighty to ninety percent of the data is indicating "all is well," a massive amount of data piles up, of which only a small percentage is actually outside the standard or norm, indicative of a focus area. You can get swamped with the pile of data that you need to filter through. The other thing I've found when you over automate, or, when anything occurs outside of what you anticipated, the automation doesn't know how to handle it. There is a benefit for having humans somewhere in the process. A person that can help make an interpretation or adjustment. There are a thousand different ways that automated systems can produce bad information. Human judgment still matters.
Departmentally separated streams of data need to be united for a complete operational picture
Justin: So, when are these numbers often reviewed? Is it usually daily, weekly, or monthly?
Jeff: Usually, all of the above. The process often starts on the shop floor, where operators write on a whiteboard or an Andon display shows the hourly production data. The leadership hierarchy, supervisors up to the plant manager, will have a walk around the facility and those boards communicate information to them. Data from every hour and every shift is consolidated into a production report. Most shops have a daily production report sent to a certain distribution, and that's the daily cadence.
Occasionally, downtime comes along with that, but in many cases, downtime is collected separately from scrap and production. Production teams record produced parts, and maintenance departments collect the downtime data. Maintenance reports typically focus on uptime and utilization. The daily review of these numbers is mainly focused on understanding production vs. plan in order to make short term adjustments to shipping or the next day's schedule. In addition to the daily routine, there's usually either a weekly or monthly cadence for more in-depth problem-solving and continuous improvement. In most cases, the data for these monthly meetings are prepared by three different departments; production, quality, maintenance.
Justin: Would it be helpful to have those results centralized, or is there a benefit to have that data siloed separately?
Jeff: To me, I think that's the most beneficial feature in ProductionNet. We're calling it the Total Loss Overview. It's a powerful screen where you can see a tremendous amount of information about your operation in one straightforward graph. We convert the downtime minutes into lost pieces via the standard cycle time. Scrap and production are already measured in pieces; with downtime now in pieces, we can stack all that together so it can be viewed in one graph. Having production, scrap, downtime, and performance loss all on one single bar against the target gives you a complete overview of your production losses.
Total Loss Overview
Justin: It makes perfect sense to me as a novice, but I think your description of different departments collecting different information historically explains part of why Total Loss Overview it isn't a standard. Maintenance collects downtime because that's what they're measured on and so on. It goes back to what you described; things aren't so much designed as they are the product of organic evolution.
Jeff: Also, downtime is collected in minutes, so the maintenance department would have to know the standard rate for that piece of equipment and the product that it was running at that time. In the past, there wasn't really a good way to collect to have all that information and accessible spot, so it would've taken more work. The advent of systems like SAP created a possibility to do that because those standard rates are actually in the system, but generally, they're not tied together in the same module. That's the nice thing about what we did at ProductionNet; we can add that information into the configuration and the user doesn't have to do anything more. The program runs/completes the conversion in the background.
In a crisis, go to the heart of the operation and procure an accurate stream of data
Justin: When Seraph is brought in to manage a crisis at a client, the scenario is typically a supplier putting their customer at risk. What are your top priorities for a crisis management engagement in your first couple of days on-site?
Jeff: After greeting and meeting, the first day or so is just parked out on the shop floor, watching operations, understanding the process, and talking to the people to understand the issues and the perceptions surrounding them. Then we vet the data streams and management reports. Oftentimes we find problems with accuracy, thoroughness, or timeliness in the data. That's one of the reasons we developed the ProductionNet. Now very quickly, we can get in and establish a steady stream of information to drive improvement.
First, understand what's going happening on the floor and vet the data that's collected. In parallel, we start analyzing the human side, identifying the players and the personalities involved in the organization. I tell everyone that has been on one of my projects; it's not sufficient to be right. You have to implement and effect change. Having information and understanding what to do is the first part, but the second part is driving and implementing a sustainable change. If nothing changes today, then tomorrow is the same, over and over, it's Groundhog Day. When you're coming in as a consultant, you have none of the history and little understanding of the interpersonal dynamics. It's an art to understand how to get personalities aligned and unlock the willingness to make a change. We look at the technical side and people side simultaneously - who are the decision-makers, what makes them tick. For most issues impacting company performance, there was somebody who was at least partially responsible for creating that problem. Somewhere there's going to be a stakeholder that's not comfortable with pinpointing the issues. There's a particular sensitivity and nuance required to get the result without alienating key individuals and creating a resistance to change.
People are at the core of the business, ignore reality at your peril
Justin: As a follow-up, from a VP of Ops Level, how do you assess when a team has the requisite capacity and capability to overcome a problem? How do you decide if you're able to use that plant's resources or you have to consider using help from elsewhere in the company or external resources?
Jeff: In all those situations, somewhere, there's an individual with accountability and an individual with responsibility for all or part of the problem. All enterprises are driven by humans, and those human beings have made a collective series of decisions to get them into the situation that they're in. Very rarely do you have some force majeure that's the root of the issue. Usually, when organizations are in a tough place, some decision was or wasn't made that got them into that position.
The trick is to figure out whether or not it can be rectified with the existing personnel. If the personnel are unwilling to make a change or are not capable, they need a different assignment. Something was always causal. Humans picked the equipment; humans designed the process, developed the plan – all the above. If the outcome isn't what they expected it to be, something could have been done differently in that scenario. It doesn't mean they are bad, nor does it mandate someone to be fired, but you could trace every crisis back to a series of decisions. Leaders only have two things that they can be. They can be either be accountable or insignificant. Generally, if the person has a high degree of significance in the organization (if they are respected, people follow them and people are listening to them), they somehow created a part of that problem or stood on the sidelines and didn't use their ability and influence to steer the ship away from the rock. The more significant the person is to the organization, the more likely it is that they have some accountability to the results and outcome.
Seraph's team of operational managers and senior consultants intercede on our client's' behalf to fix a crisis that is putting the business at immediate risk, turnaround a situation that is damaging the bottom line or restructuring to improve the balance sheet. Seraph has successfully delivered projects in the following regions: The Americas, Europe, China, and India. Seraph's Industry Expertise Includes Aerospace, Automotive, Energy Infrastructure, Healthcare, and Medical Devices. Through our other operating companies, we are continually looking for distressed situations where we can put our expertise and capital to work to create value.