Monthly Archives

October 2021

3 faces of Enterprise PowerBI Training

The 3 faces of Enterprise PowerBI Training

By | Enterprise PowerBI | No Comments

Since Self Service BI became an actual thing we have advised many organisations on how to roll it out successfully and give the best ROI as part of our Enterprise PowerBI Training solutions. A key mantra for me has always been to tune the content to the audience. After all, you book The Wiggles for your children’s party, not a heavy metal band (well, unless they are into Hevisaurus).

Over the course of working with organisations to define these audiences, consistently there are 3 personas that come up, each with their own needs with regards to enablement in terms of data and training. These 3 personas are:

  • The Actor
  • The Creator
  • The Author

Lets have a quick walk through these roles!

The Actor

An Actor is reading from the script, interpreting what is in front of them but not changing it.

This user makes up the bulk of users in most organisations. Their use of data and reporting is as an input to drive or inform decision making. The individuals in these roles can range from the CEO who needs to have an at-a-glance dashboard of their organisations performance, to a field sales worker who needs to know the buying profile of their next client.

The level of interactivity with any reporting will be basic – maybe selecting a few options or filters, perhaps drilling down a pre-set path to get some finer detail. Consequently the degree of training and enablement they need is fairly light. Key information for them is where to find the report, what the data on the report actually means and what buttons to press.

The Creator

A Creator builds an vision from the script, taking it to design their performance.

This type of user is actually one of the most important in terms of organisational impact. These are the people that are tasked with generating content for the Actors, and as such have a deep understanding of the data in their domain. These are the people tasked to work with the technology experts to build out the data models that drive much of the self service capability.

These users really get into the guts of the data and understand it in depth. When an Actor asks for explanation on a particular data point they are the ones that have to investigate. The technical training they need focuses on content creation and publishing. The enablement needs to cover things like business analysis skills, Master Data Management and Data Cataloguing.

The Author

The Author of course writes the script, starting from very raw materials to build a story.

Most people calling themselves PowerBI experts sit here, and most organisations have a handful of them – they are not a big population (though in my world are a vocal one!). They sometimes fill the role of creator but more often than not are trying to make sense of the organisations data, how it interlinks and where the hidden treasure lies. They “self-serve” from the raw data, constructing new ways to get insight into the organisations performance.

Here enablement focuses on technical capability as they need to understand how to manipulate and interrelate data that may be in less than ideal forms and certainly hasn’t been through an enterprise cleaning process. Data Catalogues support them in the discovery process.

To wrap

The key message to take from this post is that when rolling out Enterprise PowerBI Training at scale these different communities and capabilities need to be addressed – and in different ways. There is no value in sending all of your team on advanced PowerBI training if the skills learned will never find a practical application. Similarly if you build it, they won’t come – you need to guide them there.

Good luck, and if you need some help or advice, please get in touch.

PowerBI Desktop Security Risk!

By | Uncategorised | No Comments

Who doesn’t love PowerBI Desktop? Enterprise BI capability on your desktop for free! You can connect to virtually any source, pull all the data from it and start creating powerful analytics in a matter of minutes. Brilliant! But PowerBI Desktop Security Risk is rarely considered….

PowerBI Desktop Security Risk

PowerBI Desktop Security Risk

Sorry, did you just say “Pull all the data”?

Oh yes. All of it. Everything the developer has access to. You know how business owners used to stress about sales people having their own black books or stealing the customer data? This is so much worse.

If someone (not even a PowerBI developer) has enough access to one of your systems they can pull everything they want from it into PowerBI. There may be some restrictions put in place at the application level which restrict what can be pulled, but users find them annoying and so often access to the data is often very generously granted. The risk then lies in these two factors:

  • Any application security is removed by pulling the data into PowerBI. All those logins that prevented application access now have no effect.
  • A PowerBI file is an unencrypted store of all that data and is easily shared. It can’t even be password protected.

Most of the time this is not really a big concern – people are trying to do the right thing and just want the data to do their jobs. But there are two key scenarios where this risk becomes problematic.

Scenario 1: Malicious actor

Someone within the business wants your data for their own purposes and needs a simple, portable store to take it off your systems. PowerBI is a great tool for pulling large quantities of data and making it highly portable. As PowerBI Desktop is free, once someone has a PowerBI file, they have a means of reading all that data at their convenience.

Scenario 2: Naïve actor

A user builds a piece of valuable reporting that helps someone external to the organisation. They email it to that 3rd party, forgetting that some of the working data has client personal information in it. There has now been an inadvertent data breach for your business to control.

How do you limit the PowerBI Desktop Security Risk?

As with all issues to do with governing risk, there are a mix of hard (technical) and soft (policy) tools you can bring to bear to the problem.

On the “hard” front, first is your Data Loss Prevention software which actively stops PowerBI files being distributed outside of your organisation by email, upload or whatever methods of egress you want to control. Second is controlling the spread of the software by limiting who can actually install it on their desktops. Finally, keep a better grip on your data through rigorous access control, and deploying tools such as Azure information protection to keep an eye or lock on sensitive data.

On the “soft” front, your teams need to be educated on the risks of data loss, costs of data leakage and how it can happen. It won’t deter malicious users much – but it will at least give the naïve actor pause for thought.

How does my organisation protect itself?

PowerBI presents risks but it also offers the ability to really drive data driven decision making in your organisation. It just needs to be governed and directed properly to make sure you maximise the benefits while minimising risks. We have advised many organisations on just this – please reach out to us if PowerBI is in growing your organisation and needs to be properly managed as part of an Enterprise PowerBI implementation.

 

Identifying RPA Use Cases

By | Automation Initiation | No Comments

A very common issue we have seen in the last 12 months is identifying RPA use cases in organisations. In our workshop events, we regularly have discussions with attendees around their existing RPA use cases, and it is not uncommon for attendees to really struggle to identify a single existing business process that they think would make a good candidate for automation. However, we actually know from experience that this, in fact, is a good indicator for automation opportunity. This blog post explains how and why the most successful organisations with RPA usually have a difficult time getting started, and what to do if you are in a similar situation.

The Problem

The first part of the automation initiation journey is simply to identify and assess RPA use cases within your business. There are many ways of going about this, ranging from internal business process analysis to sophisticated process mining technologies. Ultimately though, a business will need to identify a single RPA use case to act as a proof-of-concept and good kickstarter to their RPA journey. This candidate use-case will typically possess the following attributes:

  • Clearly defined benefits that have objective advantages
  • Very few downsides, risks or reasons not to proceed with developing it as a proof-of-concept

However, we have seen and spoken to many businesses who say they struggle to identify a single good RPA use case. Common traits for these businesses are that their:

  • Processes are not written down anywhere
  • Processes are not formally revised and updated regularly
  • Staff cannot clearly articulate what it is that they do each day/week/month

At this point, businesses might well be thinking that automation is either too difficult or not presently applicable, and will abandon pursuing RPA altogether. But the reality is that if a business is really struggling to reconcile their internal processes with automation, that is not such a bad thing. In fact, if you can’t identify a single good candidate for RPA, that is a good sign that you are in need of automation. This is because it says that your business, and specifically business processes, are far too reliant on your staff and/or systems. Your business is likely to be operating purely thanks to the efforts of long-term staff, who personally hold all your process knowledge in their brain, and legacy systems that are not being fully utilised, or at the very least, are not being continually challenged as to how the technology can be improved/redesigned to improve efficiencies.

This ‘make-do’ attitude means that your business is exposed in two ways:

  1. You are more at risk and indeed affected by staff turnover. When existing staff leave, tremendous business process knowledge leaves with them, significantly impacting both short and long-term business.
  2. Your business is obviously inefficient – there simply MUST be processes in a business which can be more effectively outsourced to automation. No business has ever demonstrated to us that it did not possess a single process that could not be more efficently done via automation, and certainly all big-businesses and market leaders utilise automation in their organisations.

Despite the abovementioned risks having significant consequences, very few businesses take any steps to meaningfully address or manage them. But managing these risks is actually very straightforward.

How to Solve the Problem

The key is to first recognise that this perceived absence RPA opportunities is not because of a true lack of process candidates, but is because of an internal, cultural approach to business, which over relies on staff/systems to execute processes. By recognising this approach, you can begin to enact change to inject good habits and policies into your business. These will typically take the form of:

  • Documenting all your processes in detail
  • Implementing a continuous improvement framework for your processes (including regular reviews and assessments for risks and opportunities)
  • Implementing proper process discovery technologies, such as UiPath Process Mining, Task Mining or Task Capture

After making the above changes, businesses will very quickly begin to accumulate lots of information about their processes, both known and unknown. More importantly though, they also begin to enhance business processes because the knowledge has now been taken from the minds of employees and put on paper, allowing that knowledge to be collectively analysed. This strategy of diversifying process knowledge away from staff not only reduces the risk of business disruption from staff turnover, but allows existing processes to be challenged and enhanced, making them ripe for automation. It is at this point that the original problem of identifying RPA use cases is now solved, because your business is now flush with well documented and well evolved processes.

It’s surprising that the most successful organisations with RPA have usually gone through the above experience: struggling to get started, realising what that struggle actually means, resetting their approach to business process, and succeeding in RPA initiation and implementation. If you want to succeed with RPA, you need to recognise and accept this experience within your own organisation, and understand what it means and how to successfully navigate it. Otherwise, rejecting the opportunity for RPA can be a very costly mistake that could have been easily avoided.