86 (SAC Implementation Update, Scott Plyler, Meagan Nelan, Eric Gavin)

Today's SWAPA Number is 86. That's the percentage of Contract 2020 provisions that will be implemented by the end of the third quarter of 2024.  That said, the remaining 14 percent includes some very big ticket items like a training bid, major changes to ELITT, and a new vacation bidding process. So on today's show, we're going to talk to Scheduling and Analytics Manager Meagan Nelan, new SAC member Eric Gavin and SAC Chair Scott Plyler about where Contract 2020 scheduling implementation stands now, what has been accomplished so far and what's coming over the next year.

If you have any feedback for us at all, please drop us a line at comm@swapa.org
Follow us online:
Twitter - https://twitter.com/swapapilots
Facebook - https://www.facebook.com/swapa737

Transcript

Amy Robinson:

Today's SWAPA Number is 86. That's the percentage of Contract 2020 provisions that will be implemented by the end of the third quarter of 2024. That said, the remaining 14% includes some very big ticket items like a training bid, major changes to ELITT, and a new vacation bidding process. So on today's show we're going to talk to Scheduling and Analytics manager, Meagan Nelan, new SAC member Eric Gavin, and SAC Chair Scott Plyler about where Contract 2020 scheduling implementation stands now, what has been accomplished so far and what's coming over the next year.

I'm Amy Robinson.

Kurt Heidemann:

And I'm Kurt Heidemann. And here's our interview with Meagan, Eric and Scott. All right guys, we're seven months since ratification and we've gone quite a bit through the implementation process. So let's start with a recap of what's been implemented so far.

Scott Plyler:

Well, the big ones that came up first were pay multiples and overrides. Those are always first and foremost on everybody's mind. So LCO being the most prominent of those and a myriad of other alphabet soup, ground time override, long duty override, reserve, release override, all sorts of ones. Also, the night override, previously known as red eye override got changed, added an additional hour. And the idea behind a lot of us was to get away from the daily reassignment pay and just make everything an override. Therefore we can get rid of some of the underpayment errors and we're already seeing the fruits of that. The errors in the pay audits are definitely going down, but bottom line is still keep checking your payroll report, wait for those audits completes and if you do see an issue, go to the SWAPA website, check out the pay audit tool and contact us or the company if you need to get something changed.

Meagan Nelan:

I think we've mentioned this before too and is probably worth repeating that all the work for those overrides, they started that before the contract was voted in, so I think that's a nod to that good faith that they were getting a head start to get your pay right because that's probably the most important thing. Everything else is good to have, but getting the pay right as soon as possible, there was that commitment there.

Amy Robinson:

I know we've talked about in the past things that had not gotten implemented when we expected them to. What were those and were any of those tied to pay?

Meagan Nelan:

So we've seen some defects, I guess you could say. GTO was a big one where there's a defect from your report to your first departure, that's all supposed to be captured as GTO and that wasn't programmed. And so now there's a manual effort to patch that and they have a fix in place, but it's still being worked on. So not to say that they're violating the contract, but the programming didn't meet the criteria holistically, but there's no disagreement. It's just now there's this extra step that your payroll team has to go and put that in for you.

Kurt Heidemann:

Talk a little bit about that because on the one hand, they're meeting the spirit of the contract but they aren't meeting the actual language or their, as you mentioned, defects. So are those violative? I know you're not contract admin, but I know you talk to them a lot. Is that something that we would file a grievance for or is it they're meeting the criteria?

Scott Plyler:

Well, it's the difference between them meeting the language versus it being programmed to meet the language. So things that aren't programmed yet or maybe didn't get programmed holistically to begin with, those are still being captured with manual processes or manual queries after the end of the month. That's why sometimes you'll see an audit complete, but it's not quite right. They do have a couple of extra processes after the month's over where they'll go back in and they'll add in manually some of the additional overrides or the pieces of the overrides that weren't captured in the original programming. So they're still meeting the language, it's just the process isn't quite as clean as what we had envisioned originally, but eventually they'll get to where everything is automated.

Meagan Nelan:

And I'll just add that we were still doing the final steps of the mediation process so we weren't looking over all those user stories and requirements and that's where that missed opportunity was there. We probably could have caught some of this and that's why we're part of it now is to look for holes or opportunities to further improve the way they're going to program it to again meet the language in the absolute best way possible.

Kurt Heidemann:

Meagan, not to contradict you, you said maybe we could have caught those. I don't think anybody on the negotiating team thinks that there wasn't enough work to do. It's just that we didn't have the bandwidth to do it. It's not that we dropped the ball, I would say. I don't want anybody of our listeners to think that SAC missed something. It was just we didn't have the bandwidth.

Meagan Nelan:

And it's more that we weren't invited to look over that yet. We were still negotiating at that point.

Eric Gavin:

We hadn't started our collaboration period yet with the company and we knew it was going to be messy, but we wanted the pay implemented sooner. And thankfully they had queries and manual processes to back themselves up until programming got implemented.

Amy Robinson:

So Eric, can you tell us what else has been implemented aside from just the pay multiples?

Eric Gavin:

The open time and reserve, we've got the fully rig open time. VPF has an interim paying at double time rates until we have VDT fully programmed, auto-bid for LRF and VDT is coming, pop before reserve, split to cover and the pop before reserve [inaudible 00:05:42] premium.

Kurt Heidemann:

Scott, I'll ask you based on those changes, have we seen a lot of changes in behavior either with the company or with the pilots?

Scott Plyler:

We certainly have. Even not taking into account a little bit of over-manning here, we've seen more efficient use of the manning, which is something we were pushing a lot for during negotiations that we would have behavior change. So optimized planned pairings are staying together, which means we have more quality in the open time instead of the split to cover without ... The full rigs are really driving that. Also, just having those opportunities for premium pilots come out. So what we've seen is lower reassignment rates because those planned pairings were designed to be run that way. We're having lower [inaudible 00:06:25] period inflation, lower reserve utilization. So we actually have a more efficient manning model right now for execution. It's just so unfortunate that we're a little bit over-manned based on the network schedule at the moment, but when we come out of this they're going to have a lot more bandwidth to add flying back in because our manning model is more efficient.

Amy Robinson:

So was there anything that was supposed to get implemented later that got moved up?

Meagan Nelan:

A big one there is the ability to trade over non-flies and the big one is vacation. So now you can trip trade giveaway and you can ELITT over vacation. There is a little defect with that where it's supposed to be a little bit more restrictive than it got implemented and they're going to go back and fix that. But that wasn't supposed to be delivered until the end of next year, but they saw an opportunity that that would be an easy one to go ahead and implement early. So I think again that's a nod to they are invested in getting things done on time if not early, and whenever there is a delay it's not taken lightly.

Kurt Heidemann:

So we've talked a little bit about things that came early. Let's flip the script here and talk a little bit about September. I know we had a bunch of things that were going to be due in September but we've had to push those back and that's caused a little bit of angst I guess among the membership. Can you explain exactly what got pushed and why?

Scott Plyler:

Well, there was a lot due in September. We do want to emphasize that a lot of it did get implemented, all the plan parameters for the bid lines and the pairings did get done. Duty day, block rest, domicile pairing mixes, commutable pairing minimums, allowing [inaudible 00:08:03] day lines to have less than three days between those work blocks. That all did get implemented. So the plan side did get implemented. More of the delay came with the automation for legalities for like reassignments and such for the Blaze program, SkySolver, where they're all relying heavily on legalities and a lot of the work that Meagan and Eric did was looking into how those legalities were working because both of them were former schedulers. Actually Meagan trained Eric at one point and Eric did a lot of work on reassignments while he was a scheduler. So they have a lot of knowledge about actually how those programs work and how it looks to the schedulers.

Amy Robinson:

I know one of our pieces of comm that we put out, we talked about Blaze a lot and I don't think necessarily pilots understand the differences between Blaze and SkySolver. Can you guys start there and give the listeners a chance to understand that a little bit better?

Eric Gavin:

Yeah, sure. So Blaze is for the pilot's perspective, all the red that you see at top of your board, your legalities and stuff. That's all driven by Blaze in the background in CSS. And then SkySolver is separate, which does your reassignments and solutions during cancellations and then has to abide by those legalities when it creates solutions. Also, SkySolver is what notifies the schedulers of any illegalities that come up so they could monitor. So they are two separate but they also need to work together.

And when it comes to the legalities, it's not something you just want to partially implement or implement with defects. It's not ... Pay, we can do it messy, we can come behind and clean it up. Legalities you want to get it right the first time. So this is something that was important to get done and when they started digging into it, they didn't know how much programming it was going to take until they actually started looking into it. I think someone was saying it's like renovating a house. You don't know what it's going to take until you start opening up the walls and see what's underneath and that's what happened here. So we wanted make sure that pilots aren't flying illegally, that wasn't going to be a good thing. So it needed to be delayed to be done properly.

Meagan Nelan:

And to give a little bit of a history lesson here because I know we have a lot of new guys. The last big overhaul of Blaze was done back in 2013 and that was to prepare for the implementation of 117, which had a brand new rule set from what the airline previously operated under. And that's when buffers came into play, that's when new cumulative requirements came into play, and Blaze was the oversight on all of that. Well we're a decade into 117 and we've learned that some of those buffers were a little bit more restrictive than what the airline really needed. That was part of our whole vision of the new contract was to undo some of that to give our pilots a little bit more flexibility while still keeping a safe operation.

So all that work that was done, in fact in 2013 kind of needed to be undone and that's part of what we've been going over and think there maybe were some misconceptions about how some of those rule sets were working and we uncovered that as part of this ongoing review of user requirements and that's why we had to make that decision, both they had to make that decision to pump the brakes and revisit what was required to get the contract rules right within Blaze.

Kurt Heidemann:

So just so I'm understanding Blaze is the limits, is it contractual and FAR or just FAR?

Eric Gavin:

Both.

Kurt Heidemann:

It's both. So that's the rules that SkySolver then uses to spit out a solution during execution and that's where the hang up was. That's why the schedule planning side was all good because it didn't rely basically on those two programs.

Meagan Nelan:

Right. Blaze feeds a lot of information into your CSS system to then be contractually compliant and then 117 compliant, and you want those things to be right.

Eric Gavin:

And then also for SkySolver, so Blaze you think of it as an engine. SkySolver has its own engine which is programmed by GE, but they have to work together even though they are separate, if that makes sense. Part of the problem too is the people programming this now didn't program Blaze or SkySolver or CSS in the first place. So when they're uncovering a need to change something, they actually need to dig into how it was programmed in the first place, which is why it's taken so long as well.

Meagan Nelan:

Yeah, going back to what Eric said about it almost being like a remodel, you start ripping walls out. There are things that we thought were programmed from the last contract, that the company thought was programmed from the last contract. And then when you get into the meat of it you realize, oh, that was never programmed, that was being manually managed or red eye is a good example. I mean there's a lot of provisions that were in the old contract pertaining to red eye, but there was no red eye operation so there was no urgency to program it. Now they're having to take a step back and spend the time on those things, especially now we got a date for red eye, even though it's not a new contract provision, time needs to be spent to go get that programming in.

Amy Robinson:

One of the things you were talking about was you kind of opened [inaudible 00:12:47]. Can you give us a very specific example of one portion of this where in scheduling it's created problems for you guys or one issue that you come up with?

Meagan Nelan:

Well, it seems like a little thing, but when you are legal to pick up SAQ flying, we all assumed that some of the restrictions from the last contract had already been programmed and it turned out they hadn't. And so it's very hard to have manual oversight of not allowing an SAQ award in open time because open time is a highly automated programming. A scheduler can't go in and not award something that shouldn't have been ... That pilot shouldn't have been showing legal for to begin with. So it's one of those things where there was no implementation plan for that because we thought that nothing changed from the last contract, so now they have to go in and add programming to that. So that's where you end up having to make updates to the implementation plan.

Scott Plyler:

And that's just a really small thing and then you start thinking about the legalities implementation that you have so many touches with that, whether it's between Solver and Blaze and all the different rule sets that we have now. When you find a small defect or something that was an oversight in the past or something that maybe wasn't fully written out in the implementation plan. And as you're going through all of these requirement documents for all of these things, like even for open time priority being automated, we just got I think over almost two dozen documents with all the requirements for each different piece of how that works. When you start digging into that and then you find one thing here and one thing here, they all kind of add up to a bag of stuff that you have to get reprogrammed and reevaluate and that causes some of these delays.

It's not so much that there's anything nefarious going on, it's just we're uncovering things that just hadn't been done in the past and now they have to be addressed and finally they're being addressed, which is a good thing, but we want to make sure it all gets done correctly.

Eric Gavin:

It's not just the fact of the flagging legalities to see the message, it's also how it's presented, the pilots as well as the schedulers. Since we have background on both sides, we want to make sure it's very clear to both schedulers and pilots that if a pilot is legal or not, and there should be no question about it with the legality. So that's also a big piece of it, why we don't want to do any work around our manual processes.

Amy Robinson:

You mentioned Eric, that they couldn't just do things manually and I think that's a question a lot of pilots ask is, well why can't we just start making these schedule things manually? Why would that not work out? Why couldn't you schedule the shorter wraps, lower duty limits, et cetera? Why couldn't you do that?

Eric Gavin:

And like I said, it'll be messy. When you deal with legalities, you want it be right. There's over 260 schedulers now. So if you're going to do manual processes, then legality is going to come up and then they have to determine whether they can force that legality or something's different. That takes education and 260 people to be on the same page as well as all of our pilots to understand then which legalities matter and which don't. And we don't want pilots flying illegal or making contractual violations and again this not like the pay where, okay, they didn't pay me correctly, but then we can fix it later. You can't go back and fix flying illegal or breaking it. So that's why we couldn't do that manual process and we didn't want to do it that way when dealing with legalities, which is very important to get right.

Meagan Nelan:

I think another thing to consider is we expect them to comply with the contract every single day. So maybe on a quiet day it could be handled manually, but when you think about a big disruption where you're ingesting hundreds of duty periods through SkySolver. If SkySolver doesn't understand the new rules, you're going to go in and manually change all those pilots again, you think about the conversations between crew scheduling and pilots when your programming is working against you, trying to manually have oversight there. And then what you're seeing on your pairing doesn't match what the language in the contract is, that's not sustainable. That doesn't set everybody up for success and that's the risk factor. I understand not wanting to take that on and promise something that might not be something you could actually deliver.

Scott Plyler:

Right, and during those large disruption days, if we do more manual processes, that means it's going to be less efficient, it's going to take longer to recover from these regular operations. That means longer wait times on phone calls, longer waiting for reassignments when your flight's canceled. If they're going to have to run solutions and then recheck it manually, it's just going to slow the entire operation down and be a bad product out towards our pilots as well and create longer duty days.

Meagan Nelan:

I will say one benefit because now we're meeting directly with the developers going back to the drawing board on some of the legality changes. Their initial plan was to just use whatever message was already in CWA and just overlaying it with the new limit. We had the opportunity to give some feedback and now the way your contractual rules are going to read on your pairing, it's going to more closely align with the way it reads in the contract. So I think it's going to be easier to interpret for both crew schedulers and for the pilots of what they see on their schedule now matches CBA and that's how it should have been all along.

Scott Plyler:

We're also getting rid of a lot of just the superfluous messages that it doesn't really matter to you if you're actually legal for it, it doesn't matter whether you hit a buffer or not, as long as you're legal, that's what a pilot wants to know. If a scheduler needs to see that, they can see it on their end, but trying to cut down on that extra noise on your pairing, we were able to do that as well.

Kurt Heidemann:

So let's get back to this last batch. What are the changes that we've postponed and when will they be coming into duty day and the rest type stuff?

Meagan Nelan:

The big thing that got delayed was your executed duty day limit because we did simplify and further restrict what you're legal to do when you hit that day of operation. So that's the big ticket item that got delayed. There's also a few rest requirements that got to delayed. And again, they planned everything in compliance. So your bid packet's in compliance. It's just when you get to the day of reassignment experience that that got delayed to December.

Kurt Heidemann:

And to your point, we're a relatively stable operation right now. We haven't had a lot of disruptions or a lot of reassigned duty periods as we have historically in the last few years.

Meagan Nelan:

Yeah, historical lows on reassignments. I was actually looking at executed duty period, how many have gone over the new contractual limit and it's been less than 2% so far this year. So if there is a time that it had to be delayed, this isn't the worst time because you have the manning and the stability in the network that it hasn't been as challenging as it was two years ago, for instance.

Eric Gavin:

Another piece that was delayed too, sorry, was the overlap two process, another system called OCSI, the Optimization Crew Scheduling Interface, which does our overlap correction, which they're actually able to do a manual process for that in the interim, which Meagan helps with some analysis with them to do it. So now, max five-day correction for work days, all deadheads are paid, all corrections fully rigged, so that is something that is delayed, but it has a manual process to it as an interim until they can get that programmed.

Meagan Nelan:

The one thing they haven't been able to do manually is some of the cumulative roles changed and that was one of the big programming things where there's just no manual way for them to comply with your cumulative restrictions. So that's coming later as well.

Amy Robinson:

Based on some of these delays and implementation, what is that going to mean for our pilots down the line? What is the domino effect of this? Or is there one?

Meagan Nelan:

Well, I started wondering if we were going to have a ripple. So we actually did have a meeting a couple of weeks ago to discuss what was on the docker for the fourth quarter, and the good news there is that everything is on track, so this isn't a domino effect. There are a couple of things that got bumped, but we had a conversation about essential versus non-essential on things that they were doing manually and had programming plans in place and those are going to end up having that ripple. But again, when you get back to and tend to the contract and compliance, there isn't any violation there. It's just those things that were nice to have for them are getting delayed.

Scott Plyler:

So they are in compliance, they're doing the process manually, getting it automated and decreasing their workload like on their payroll auditors or on the schedulers. That's the part that's been delayed because of this implementation. They pushed back their programming to help the company folks reduce their workload. But on the pilot side, you're still getting it completed manually.

Kurt Heidemann:

So that's the fourth quarter of this year. What's coming in 2025?

Meagan Nelan:

By the time you hear this, we will have already had a meeting with our counterparts over at SWA with a complete roadmap of 2025 because there are a lot of items on the docket for next year and it's good to see that we're starting to have those discovery conversations about what those requirements will be.

Kurt Heidemann:

So what are some of the big ones that are coming next year?

Scott Plyler:

Well release the check-in is one that a lot of people really are looking forward to on the reserve side. It's one that we do get questions on why they can't be done manually, but there are a lot of touches within CSS on how does that still compute with your reserve utilization? How does that touch the RCO? Are we going to drop the reserve block altogether? Are we going to have new coding for it? A lot of those process plus just putting those preferences in, what the timing is of when the release to check-in can actually be done. We've actually started going through those requirement documents already again, which is a good thing that we feel like we're starting to get ahead and that's a good thing for those.

We also have just the reserve proffer process that's second quarter next year. That's not just going to be the programming behind it, but that's going to be a whole new user interface for our reserves to use things like reserve ELITT, that's fourth quarter next year. Got a whole bunch of other stuff in exchange of flying as well. We're going to have to have Red Eye Reserve by the end of next year. We're going launching red eye with Red Eye Reserve which is limiting how that gets deployed, makes for some interesting workarounds, but that'll also have to be programmed by next year.

Meagan Nelan:

I'll just add that reserve proffer, one exciting thing about that is it's brand new, so it's not like they're making a modification to something that already exists and we've gotten a commitment from our counterparts that the pilots on our committee will be heavily involved because this is a pilot interface, it's an opportunity to get that type of feedback to make sure that it makes sense for our pilots.

Amy Robinson:

We talked a lot about reserve. What else is in there in next year's implementation?

Eric Gavin:

We also have the [inaudible 00:23:22] protection coming in for next year, which is a big work for GE, the engine that drives Solver for our pilots to put a preference about being [inaudible 00:23:30] or not. Also, additional just reassignment restrictions, a personal net-zero self-service deadhead release. A lot of these are very heavy lift program [inaudible 00:23:39] because they're brand new. We're not building on top of anything that already exists. So there's a lot of big IT programming ticket items coming for next year.

Meagan Nelan:

We also have direct drop and direct pickup out of ELITT. And then the ability to trade across months, which I think smooths your overlap period for coverage. And then we were actually going in circles about it this morning, but self-service, open time priority, and that's going to go in conjunction with a trading bid. So that's all by the end of the next year. So there's a lot on the table that they're going to be working on.

Scott Plyler:

And like you said, the good news is some of these are completely new processes where it'll have to be a new interface. So one of the things that we're really trying to get away from is trying to shoehorn our new provisions into the old programming. Some of the times, it just makes a lot more sense to start fresh with the program so you don't have some of those defects or some of those legacy things that we got rid of in this new contract still lingering in the programming. If you start fresh, it makes it a lot easier to implement it the way that we negotiated it.

Eric Gavin:

And thankfully they are taking our input with that too, which is nice being fresh start, we can actually collaborate and create a good product from the start instead of just putting something together to get it out there and done.

Scott Plyler:

It's a whole new ball game with this implementation compared to previous contracts. Like in the last contract, Meagan specifically got invited to do some testing on CSS, found a defect, and when we raised an issue with it, they stopped inviting her to go do testing. It never did get fixed and address, so then we wound up having to file a grievance over it. That's not the case now. The more that we're involved in it, the more ownership we have, but also the better the product gets so people don't have to be doing it once and then going back and fixing it, which takes away bandwidth from them. And then it also helps us because if we ever have to do some kind of grievance work on this, who has to do the work for the analytics? We do. So then it puts us behind on helping them implement the next stuff as well.

So it's better for us to be involved in the process and then everything gets done correctly. Sometimes if that means a little bit of delay here or there and there's a little bit of messiness because we're getting inside the walls then that's part of the messiness, but it's better overall for our pilots that it gets done correctly.

Kurt Heidemann:

Thank you to Meagan, Eric and Scott for coming on the podcast to talk to us about what they're seeing and doing as far as implementation of the scheduling provisions of the contract and what we can expect over the next year.

Amy Robinson:

If you have any feedback for us at all, please drop us a line at comm@swapa.org. We really do want to hear from you.

Kurt Heidemann:

And finally, today's bonus number is 9,320. That's the average number of man-hours per month that the company has spent on programming changes since ratification. And that's not including the hours spent prepping and collaborating with SWAPA to make sure the contract intent is being captured. This illustrates the sheer volume of work being done to get the implementation done correctly. You can see all of the updated items as well as additional dates on the newly updated Contract 2020 annotated copy on swapa.org.