Speaker A We've had to become more efficient and effective at getting the work done just because of cost pressures. So particularly with it we've created new role that are focused on getting better and more timely information to the business units so that they can make better decisions. And I think that the fact that we've got better databases and better information that people can make decisions on has helped us and allowed us to create some roles that we didn't used to have, particularly in improvement roles. We had an initiative over the last two years called Business Process Integration which was supposed to look at business processes on an end to end basis rather than on a siloed basis and hopefully put new improved processes in place that would look at it on an end to end basis rather than kind of a function by function basis. And in the course of that, what we set up was improvement teams that were really and this goes back to something we learned in Stratified systems about setting up improvement roles. So they report up at a fairly high level in an organization, but their main function is to look for process improvements, design process improvements, and that's their function. And it's not something that you'd necessarily make part of a management job, but it would be part of a separate role and it's got the same level as other senior management roles in the organization and that's worked very well. I think it goes back to the basic clarity of role and some roles are focused on improving the productivity and the effectiveness of the overall organization and some roles are focused on getting the laundry out every day and if you can keep that clarity it seems to deliver better results.
Speaker B That sounds like a really good example of implementation of some of the design philosophy that is in stratified systems theory. Are there any other examples of that that have sort of really affected perhaps bottom line or improvement or complex problems that you might have come across?
Speaker A Well, we've implemented something that we've called organization change management where when we go through process redesign or a change in the organization function or structure, we've created a specific role that deals with the change management, the culture, the training, making sure that the organization is receptive to the changes that are coming. And we've created these separate roles that do that. And I think that's paid off, because, as you know, when you try and design improvement activities in an organization, you can have the best design or the best process improvement, but if the organization doesn't accept it, the culture can reject it, and it'll just be another initiative that went down the tubes. And what this is designed to do is trying to create the buy in and the receptivity of the organization into the kinds of changes that we've been making. It takes time to make these kind of fundamental changes in the way people think about how we get work done. And you can't take somebody who's been here 35 years and turn around overnight. You have to see successes and you have to take a piece at a time. At least in my experiences. You can't take all seven boxes or how many of our boxes there are. Now we have seven boxes or whatever in the model and say, well, here, we're going to slap this down on an organization next week. But start taking a piece and do it in a systematic, sequential piece. This is a marathon, not a sprint, which is kind of the way we've implemented a lot of it and it's even changed terminology over time. But you just keep working on it and you get a little better every year.