Robert Standefer

Lately I’ve been working on documenting the processes I use for reviewing change requests. There are two processes that are used for this weekly endeavor. One involves the lifecycle of a change request from creation to technical approval (my job), and then it goes off to higher powers. The other is the process I use in the actual technical review.
I can represent the high level process rather simply.

Of course, there’s a lot of stuff going on in there, but it works at a high level. The detailed process is much more complex, and I don’t have a model for it yet because I haven’t figured out how to represent it in notation.
That describes, then, a larger problem: is my process so complex that it is too difficult to model? Or is the process flawed and should be redefined using a model-driven approach? The current method is a very manual process. My attempts to automate individual aspects of the process have proven quite difficult. That indicates to me that the overall process is flawed and needs to be redesigned.
I think I’m going to take a step back and analyze the technical review process with a more objective eye. That is, instead of looking at it in terms of “this is what we’re using, and it gets the job done,” I’ll look at it as “this is a new process that has not been executed before.” At the end of the day, the process should be easily understood by people who are not intimately involved with the actual work.
Perhaps at that point, the process will be clearly documented and individual tasks can be relegated to automated workflows. More on that later!