What is a process?
In my previous notes, you have learned that you, the CIO, must suggest IT strategies to support the business objectives or business strategies. How to do that? You might do it this way:
- The CEO conducts the annual business strategic planning process with other executives (COO, CFO, vice presidents, senior managers and etc.).
- Assuming that the CIO (you) is involved in the process, so, he learns about the business objectives and strategies for the coming financial year and proposes rough ideas about the potential IT strategies to support the business objectives and strategies. He should provide very rough estimates on the business values, costs, resources and risks of such IT strategies.
- The CEO, with input from the CIO and other executives, selects a short list of IT strategies for further studying.
- For each selected IT strategy (which supports a business objective or strategy) you should be able to identify the executive who will be benefited the most. That executive should be enthusiastic enough to act as the champion.
- The CIO works with the architects to give better estimates on the costs, resources and risks for such IT strategies.
- The architects may conduct researches and if required, feasibility studies.
- The CIO obtains the support from the champion.
- The CIO obtains the support from the CEO and other participants.
The work flow above is called a process. Why is it useful to clearly specify (define) the process?
Seeking support
In the above the process, it is clear that the CIO, CEO, champions and architects need to collaborate to execute the process (these are called "roles" in the process). Each role has to carry out a certain responsibilities (e.g., an architect has the responsibility of estimating the cost, resource and risk of the IT strategies). Therefore, to establish the process, you must first obtain their consent on those responsibilities. In fact, as they're the collaborators, it is best to seek their suggestions to make the process better in order to obtain their strong support for the process.
Therefore, the process definition above can serve as a tool to get their agreements and support on the process including their respective responsibilities. This is the first important purpose of defining the process.
BTW, if you're careful, you may note that while roles like CIO, CEO and architect are probably job titles, but champion is probably not as it varies by case (e.g., the chief marketing officer may be the champion for an IT strategy involving facebook marketing). It means that you need to include all such possible people to act as the champion in this agreement seeking exercise.
Continuous care and delegation
Is it done after defining the process? Once you have a process, you need to continuously check if it is really working well and improve it. For example:
- Is it effectiveness (does it work at all)? For example, has it generated IT strategies which turned out to be not supporting any business objectives or strategies?
- Is it producing high quality output? For example, has it generated just mediocre IT strategies or excellent ones?
- Is it efficient? For example, does it turn out that it takes many times of back-and-forth to convince the CEO?
- Is it embedded into the DNA of the organization (maturity)?
- Is it dealing with risks properly? For example, has it generated IT strategies which turned out to overlook a major risk?
Who will do this work on a continuous basis? As it is a lot of work, having a single person to do it for all the processes (or just all the IT processes) in the organization makes no sense. So, for each process, a process owner must be assigned. For this particular process, the process owner should probably be the CIO as this process has the most relevance for him. For a process regarding, say, user acceptance test, it should probably be the QA manager.
Defining IT processes
As it is extremely important to have IT processes properly defined, monitored and improved, this is itself an important process in Cobit.
No comments:
Post a Comment