woensdag 26 mei 2010

Risks and (managed) Self Service BI

Dear friends,

Currently, i'm building a presentation about Managed self service BI (MSSBI) and i'm investigating how to set up an risk management process for judging the risk of certain Self Service BI (SSBI) solutions. So what's the story: (power) users will be creating a lot of SSBI solutions and they have to be managed somehow. Why? Well, if certain SSBI solutions are used in critical business processes and the power user knows all the details of that solution that's a great risk for your company. For example, if that employee leaves your company, great damage can happen. So there should be a governance committee which collects information about the solutions built by the (power) users.

Risk can be split into a function of  'change that it will happen' and 'the impact WHEN it happens'. That will give something like this R(isk) = P(robability) x  I(mpact). This means that you could have a critical process (high impact) but the change that it will hapen could be low due to good documentation, multiple powerusers who created the solution, etc. Or you could have a non critical process but a high risk that it will happen. So the following diagram, shows what kind SSBI solutions you should put into a managed environment.

Below, i have some indicators summerized, which should be taken into account for SSBI risk analysis:
  • What kind of business proces is that SSBI solution built for. Is it for a critical process or is it for a non critical proces built?
  • How many users are using it? If a lot of users are using it, it could be critical. Or when the solution needs scalability and the solution can handle that (anymore). The SSBI solution has been built in the past and the use of data has grown and the number of users has grown. It has grown into a solution that can't be handled efficiently anymore. Then, it needs to be managed.
  • The number of times it has been used. If a SSBI solution is used once each year than it won't be important? This is quite arguable because you could say that if it isn't used much it won't be important but a profit and loss report could be used a couple of times per year but it is important for your company.
  • The data that is being loaded into the SSBI solution.
  • The kind of data that is loaded into the SSBI solution.
  • How well is the solution documented? If a SSBI solution is very well documented and the (power) user needs the flexibility of the solution to create changes to it by him-or herself, there is less need for integrating it in the managed environment.
  • How well is the solution secured? If business critical information is in the SSBI solution stored, the risk of hacking the solution is larger than a good secured solution.
  • Is the solution properly backupped and are these backups tested in a good manner?
Well that's it for now. If i can think of more riskfactors i will blog about it in the near future.


Geen opmerkingen:

Een reactie posten