Process control
Processes should also be well defined in understandable text just like we always do to our fellow programmers when recommending comments in their code. And just like the norm in programming, most documentation happens after the fact because people don't have enough time to document the program until it has stopped changing at the end of the development cycle.
Process owners are the people who understand the process and can help educate others on how to use the process. I have to help naive ITIL students who tend to think that process owners are not in charge of implementing the process. This always gets me on my soapbox. An implementation of a process, e.g. an ITIL key process, is not going to happen because you read the book. It must be digested, customized by deleting the right parts, and supplemented with all of the current business structure in order to be understood. Then the process activities are noted and people check them off as they need to when they need to encouraged by success and trimmed down by reality. In programming, it would be the project sponsor who got the ball rolling for the new software and would own the software when complete. They also get new funding when the project is a success and get project funding reductions when the process is too cumbersome.
How and when the process is used is a matter of policy and the ways that you can use these process steps have limits. Just like a computer program, the steps can be run for certain types of tasks and shouldn't be run for others. You don't close the books of an accounting process except for once a month. You don't ship more inventory than you have in stock. Process objectives are probably determined by what planted the seed in the ground for using this process in the first place. In a software project, the business objectives drive the funding and usually can be found in a business case document or a sponsor's mind.
I was reminded of the input and output nature of a process when looking at the method declaration and saw that it defined a general form of a resource just like all the other types of resources. But until functional programming came along to supplement object oriented programming, we never had a way to send the process information from one place to another internally even though the values of any data could be sent to and fro. The methods represent values but only in an abstract way. In a distributed world, the process is represented by remote procedure call frameworks like CORBA, web services and other forms of proxied calls. Data was distributed through XML, EDI, and all sorts of more simple data models.
Software testing is a way of thinking about your code from the norm or from the original business requirements. This validation is a quality aspect of coding. Test driven design drives home the point that the test is a way of thinking about how your code should be called and used before the implementation is written. ITIL states that "Even before starting, it is important to think about what the process outcomes should look like." (Service Design, p. 44) We also work with requirements in a hierarchical way so that the lower level requirements of the code can roll up to the next level of activity and eventually be mapped to the business goals that drove the project. Then when the system is complete, we have a measurable way to compare what was originally planned and implement improvements if necessary.
- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug
No comments:
Post a Comment