We talked about process design as a prototyping tool for thinking through what we want to do on an IT project and what's going to be valuable before we go off and a build a bunch of stuff. So here, I'm going to show you how the team at H and H might sketch out a process. Now, they identified this really important event of identifying a part and then, being able to see how much it's going to cost and when they can get it. So that the technician can easily figure out what their next steps are with the customer. Now let's say that they want to make sure that they've thought through the larger context of how that works so that they've adequately expended their stories. And sort of thought through the bigger picture before they start implementing an atomic piece of it. Not coding the whole piece of it, but at least sort of thinking it through at a high level. So, that process might look something like this. When we do these processes we always want to start with a specific input and a specific output. I would say that the input is a need for a part, so there's a part needed. And then the output is probably I would say, the parts verified. And I say that because other stuff can happen, the part could be the wrong part or it could be broken, and then the process isn't really done. So probably this is the logical, thorough conclusion of what this process should look like. So what are the things that happen? Well, the first step is going to be with the technician. We know they've finished, the trigger here, the sort of prior event, is that they've concluded a diagnosis where they know they need to replace a part. And the first thing that they need to do is they need to ID the part. Figure out what it is, so they can understand what it is. And this is going to be the technician doing it, so I'll put a little T there. And then, what happens? Well, actually I guess there's a few things that could happen. He's trying to find it in the H and H system, so is it in the system? because it's probably possible that it's not, and then maybe dispatch is going to help him out with that, so we would create an item for dispatch. And we'll put dispatch here. Actually, we'll put technician, too, because they create it and then the dispatch would get it. And, okay, then let's say it is in the system. Yes, then what happens? Well, then they need to know about the customer's contract, because we talked about the possibility that maybe the customer will order the part themselves. So they could be on a fixed price contract or some kind of prior agreement about just going ahead and ordering parts. So if they are on a fixed order contract and it's okay to order this part, then that's going to be one event. If they need a signature, then that's another thing. Or maybe the customer orders their own part, we saw that possibility. Okay, so I think we've sort of thought of the space of things that can happen at that point and made sure that we've sort of identified those. Well so let's say everything's okay, they can go ahead and order the part, then they're going to want to plan, they're going to want to order it and plan delivery. And that's going to happen in this case and as long as they get the signature, this is the thing the technician will do, then they go to the step two. And we'll put a customer thing here because that's the customer. And then I guess they plan the delivery, it gets delivered. And if everything's okay then we're done. So we'll just go to kind of what that closing would look like. Then this is one loop. Now, what happens if it's not okay? Then I guess there has to be some kind of a return process. Nope. And then, I guess probably basically they need another part. So, we would just kind of go back to the beginning here on that step and then the customer orders it, I guess, the customer delivers it. And then maybe notifies them. Notify, I faked the I there, but you get the idea. And then it's delivered, and then we get the same result. So, we principally have really dealt with this item here, this IDing of the part and what happens next. But, when we look at these IT systems that are going to have to implement a business process, sometimes it's a good idea to make sure that we kind of quickly zoom out, as it didn't really take that long. I don't have any specialized knowledge about HVAC. And we sort of think through the different things that might happen and we can take this and ask the applicable people. Hey, is this how this would work? Is this not how this would work? In that way, we avoid surprises and ground balls and things we didn't think about as we're writing our stories and then implementing code. So this is a good way to kind of prototype your ideas in an IT situation to make sure that you're thinking about what's going to be valuable and you're thinking holistically about what needs to be done without a lot of initial work. [BLANK AUDIO].
