Archive

Archive for September, 2008

Operational Risk Management – II: Incident reporting

September 17th, 2008 Dr Kitipan Kitbamroong No comments

"However beautiful the strategy, you should occasionally look at the results"...WCPrint Print

Incident reporting: static analysis is the first step normally used to identify losses. Summary statistics first display frequency and severity data by event type and by business line, according to the regulatory categories. This report is of certainly needed for compliance purposes, however it might be not the best tool for the risk management of a financial institution, which has a different structure or nature of activities.

An example of a more useful set of summary statistics would match the organization chart of the financial institution, bank, or company that uses its database. With a capability in viewing the reports in dimension splits by department, by people in charge, or by geographical zone of activity.

For a bank retail network for instance, the reporting may be split by bank branch, and, or by type of client. Even before detailing the frequency and the severity of each type of loss, incident reporting in an organization or in a department should first display the total loss amount caused by operational events.

Several simple measures, long neglected and sometimes never measured in financial institutions in the past, may provide a powerful tool to raise awareness on operational risk within an organization

Next, the analysis can identify the “low severity, high frequency” losses and the “high severity, low frequency” losses, with the remaining events. Both need further investigation, since they can be the symptoms of serious breaches in control within the organization. One of the key criteria in operational risk management is whether a possible loss is capped or not. That is, in case of an operational event, the potential loss amount is limited by any type of control. Capping potential losses is, and should be, a main concern for senior management. To that extent, rare events of large amounts are the first candidates in the identification of uncapped risks.

Likewise, recurrent minor losses require further investigation, at least once. They might also be the consequence of an effective cap of losses in an activity highly exposed to operational risks. Operational losses due to processing errors are frequent but limited due to effective control procedures and systems design. But recurrent losses could also be a more worrying symptom of a systematic breach in control or in process that lead to systematic or frequent losses, with possibly very large amounts at stake.

An incident database is a view of the operational losses in an organization that can provide, if interpreted correctly, a list of priority controls and investigations to be performed. Database analysis provides the facts, but does not identify the risks.

Post to Facebook Facebook Post to Ping.fm Ping This Post

Print

Is coaching the missing piece in PM?

September 12th, 2008 Dr Kitipan Kitbamroong 1 comment

It is just another rainy day in Bangkok and looks like continuing for some time, I had just spent the afternoon consulting with a PM vendor pre-sales consultant on how a planning and budget process works.

As we know, basicaly the planning & budget process allows modelling the business to link from “strategic activity”. And then budgeting for resources is done based on the “chart of accounts”

This process also allows planning and reforecasting alternatives to be set up when a strategy fails to perform – i.e Best, Benchmark, Worst Case, or in easy terms “what if” scenario analysis.

Basically, that’s all there is to it, although there are some tricky parts when dealing with multiple units, products, versions and currency etc., which software just handles for us.

Generally the questions we face are both “technical-driven” e.g. where does the data stay or where the query is stored and “business-driven” e.g. what does a planner do and when the planning process fits in the budgeting cycle.

I could have not answered this if I didn’t have hands-on experience on the problem myself, even though in many cases I may not know specifically the detail functions of a particular vendors application well,

But we have been through this exercise end to end, from both the business side and the functional side with various software packages. Each time we do this, it seems software vendors don’t know about business side and business people don’t know about the application. That is certainly a gap that needs to be filled, to marry knowledge of business processes and applications , and facilitate an improvement change in the process.

For this, we need to have ability to look at processes and review the current AS-IS position and highlight issues; Then based on need and benefit, propose a potential TO-BE position and define functional requirement and a scope for change, This naturally addresses work flow, process design and business case for change.

 

Facilitating this requires cross domain coaching to allow all staleholders vendore and customer to envisage the “deliverables” and how to get there from start to hand over. And then to see how to support and exploit the ongoing of change management afterwards.

I firmly beleive that the “Coaching” ingredient is all too not down-played or lacked emphasis so making it a big missing piece in successfully implementing Performance Management processes.

Post to Facebook Facebook Post to Ping.fm Ping This Post

Print

Operational Risk Management – I

September 4th, 2008 Dr Kitipan Kitbamroong No comments

Today I had a chance to discuss with a client regarding Operational Risk for banking and financial sectors and would like to share the ideas here. 

Operational risk is defined as “the risk of losses resulting from inadequate or failed internal processes, people, and systems or from external events. The definition includes legal risk, but excludes strategic risk and reputation risk.” [1].

Operational risk management [2] serves basically two goals: the avoidance of catastrophic events, and the reduction of medium and small losses. Some techniques are efficient to serve the first goal, while others better serve the second. The techniques given here, starting from the most static one to the most proactive one, each of them being an input of the other following are demonstrated.
  1. Incident Reporting – static analysis. It gives a chronology of past events, their nature, their cause and how the case was handled.
  2. Dashboards – dynamic analysis. They describe the evolution of operational events by activity or by department, providing a dynamic representation of the losses.
  3. Key Risks Indicators (KRI’s) / Key Performance Indicators (KPI’s) – benchmarking analysis. Allows a comparison of the dashboards to predefined standards and an assessment of the evolution of the risk.
  4. Risk and Control Self Assessment (RCSA) – proactive analysis. Provides a prospective view of the potential risk based on the collection of information by experts in the field.

In our discussion, we realized that banking and financial sectors in Thailand still deploys only up to static analysis from the various case studies that could be found and read in public forums like http://pantip.com/cafe/sinthorn. The point addressed was now that the Bank of Thailand has announce that commercial bank has to compile with the BIS policy, where should they start, which solution should be considered and weather the solution deployed completely answers the subject given. I’ll write about this in the coming articles.

[1] Bank of International Settlements, (2003): “The New Basel Capital Accord”, Consultative Document, Basel Committee on Banking Supervision.

[2] Bank of International Settlements, (2002) “Sound Practices for the Management and Supervision of Operational Risk”, Basel Committee on Banking Supervision.

Post to Facebook Facebook Post to Ping.fm Ping This Post

Print

PM Seminar @ The Sukhothai, 22 Aug 08

September 1st, 2008 admin No comments

Sherwood Group Consulting and INFOR jointly held a seminar titled “Adding Performance Management value to your ERP in a toughened market”.

The seminar started with a warm welcome from Ernest Low. As INFOR’s Sun System customer, this seminar would provide a chance to introduce Performance Management as a tool to value add the current ERP system.

Gordon Wood then shared a vision of macro economic impacts to day to day operation and how one should position and be take advantage of these in the tougher market we are approaching. He also facilitated a discussion of the common pains points during planning and budget preparation process e.g. data integrity,  approval process and budget control and monitoring issues, and how large international organizations used best practices to manage those pains.

The participants then had a chance to view the live demo run through provided by Kitipan Kitbamroong and Infor Team on the functions and features of the application.

During the seminar, lunch and afternoon tea were served from La Scala’s Italian Restaurant.

Presented material can be located here. To be informed of the upcoming seminar, please contact us.

Post to Facebook Facebook Post to Ping.fm Ping This Post

Print
Categories: Performance Management Tags:

Twitter links powered by Tweet This v1.7, a WordPress plugin for Twitter.