Engaging Your Business Networks

Managing Automation – June 1, 2011
Most companies’ enterprise systems don’t foster genuine interaction with their partners or customers. Analyst Julie Fraser offers mobile BI as a forward-thinking example of how to change that.

Mobile BI and the Coming Enterprise App Backlash

Dashboard Insight – June 1, 2011
The popularity of mobile apps and app marketplaces like the iTunes App Store and Android Marketplace have developers swooning and consumers in a frenzy for the latest download. On the business side, especially medium to large enterprises, there is demand from users but storm clouds are brewing for those who have to manage devices, users, applications, and most importantly security. Mobile dashboards and BI are quickly becoming one of the first technologies to get caught in this crossfire.  More…

Mobile BI on the BlackBerry Playbook!

Hi all – just a quick note today about support in Visual KPI for the BlackBerry Playbook!  As you probably know, our web-app architecture allows us to support most devices with a modern web browser (over 400 at last count), and the just-released BlackBerry Playbook is no exception.  It’s less than 10 days old but ready to show off your best data.

Want to put your OSIsoft PI System data on a Playbook?  SQL Server, Oracle, SAP, Wonderware Historian, Rockwell FactoryTalk, SmartSignal, GE Proficy and more?  No problem.

Features?  Well, you get them all – that’s the point.  Monitoring, Dashboards, Scorecards, KPIs, Trends, alerts and analytics, right from the palm of your lap.

As for the device itself.  We do like what we have seen so far, even though the device has some early limitations (that will hopefully be overcome fairly soon).  We haven’t spent much time with it but will happily report back if we find anything interesting.  In the meantime, here are a pair of screen shots…

 

BlackberryPlaybook VisualKPI3.8 RollUp

BlackberryPlaybook VisualKPI3.8 KPIMap

If you want to read more about how we support devices and more, check out the full feature list of Visual KPI.

Thanks as always!
Team Transpara

The Who and What of Mobile BI

Wayne’s World Blog on the BeyeNETWORK, April 27, 2011
Robert Hylton, vice president at Transpara, a mobile BI vendor, offers three criteria for evaluating the types of tasks that make sense for mobile BI: 1. Here and now? 2. Small and intangible? 3. Perishable? Asking the above three questions at the outset of a project can help clarify what BI applications make sense to deploy on a mobile platform. “Many decision makers are surprised once they go through this process,” says Hylton.  More…

Architecting for Mobile BI: Browser or App?

Wayne Eckerson on the BeyeNETWORK – April 21, 2011
During the past year, every BI vendor has had an intense, internal debate about which mobile BI architecture to adopt. Some vendors, such as MicroStrategy and Mellmo (makers of Roambi), believe that users will demand feature-rich, device-specific mobile applications, while others, such as Transpara and QlikTech, are betting that browser-based mobile applications will eventually steal the day.  More…

BI Hits the Road III: Two Niche Vendors Considered

Technology Evaluation Center Blog – April 19, 2011
Jorge Garcia of TEC covers the emerging Mobile BI market by comparing Roambi with Transpara Visual KPI. “Visual KPI is a product to take into account when organizations need a platform able to work with multiple types of mobile devices already in place as well as to connect to several types of business software applications.”  More…

Information Wants to Be Everywhere

Control – April 11, 2011
Nancy Bartels tackles the consumerization of workplace tools as it relates to mobility on the plant floor. Western Power gave Blackberries equipped with Transpara’s mobile application to 1100 technicians in trucks all over Western Australia so they could better monitor their substations. The entire rollout went from prototype to use in one week.

The making of a great mobile KPI: It’s All in the Attributes

We get this question all the time.  Almost every time we deploy Visual KPI (which we do over the web in about 90 minutes in most cases) we spend about an hour deploying the software, but at least 30 minutes or more on discussing “what” the user wants to track, “what to call it,” and “how to organize it” (their data hierarchy).

ListViewSnippet

First, there are many types of KPIs and multiple definitions but for our purposes at Transpara a KPI is:

  • Anything you care enough to track (especially while you aren’t at your desk)
  • Operational in nature (the “P” is for performance, so slow-moving or future planning data is usually out)
  • Changes often (otherwise, why would you need it on your phone?)
  • Often requires alerting when things go wrong (it’s important, right?)
  • Has some form of context associated with it (is it doing well or not?)

For this post, we will focus on the last bullet above and touch a bit on the others as well.  Context is everything with mobile applications and even more so with decision support information like KPIs and alerts.  So let’s dive into the various ways you can turn an average KPI into something great…

  1. KPI name: Might sound less-than-critical, but naming can really make or break a mobile KPI.  Why?  First, it needs to be short – on a mobile device, you don’t want the name taking up the whole screen (e.g. “how much fuel is being consumed”=bad; “Fuel Usage”=good).  It will also show up on multiple devices, in different views and in multiple places so short always wins.  Second, it must be obvious.  Mobile data should be and will be shared so make sure others will understand what your metric means.
  2. Actual value: This is the heart of any great mobile KPI (or any KPI for that matter).  Getting it right means getting it from the original data source (no middle-men if you can help it) and that it is as current as possible (most of our customers strive for near-real-time).  In Visual KPI, it is the only required field other than the name.
  3. Targets & Limits: Let’s face it, a KPI is only a KPI if you can compare it with some expected behavior.  Something you want to achieve (a target) and various states away from it (limits) that will put your data in context.  These may come from internal or external sources of authority.  Oh, and edit and test your targets and limits constantly (this is where the Visual KPI Designer’s preview mode really comes in handy for rapid prototyping).  Most importantly, make sure your KPI limits and targets match the way people are actually measured and rewarded or they might end up being useless.  (I’ll write more about choosing your KPIs in another post.)
  4. Data sources: Data can come from many sources, even at the same time, but the key word is “source.”  The most important thing about operational KPIs is getting at the most reliable, timely and accurate data. People will be making decisions based on this, so be careful of intermediate or redundant data sources.  Also remember that constant values and other manually entered data can be important (especially for targets and limits, not very exciting for an actual value).
  5. Responsible Party:  KPIs are there to make sure the right people know when something has gone wrong (or particularly right).  Because of the decision-making nature of a mobile KPI, you may want to alert the responsible party (ideal) or at a minimum let whoever is looking at know who they should notify if something deviates from the expected.
  6. Alerts: Similar to the responsible party (above), but there are two other things that can make or break a good alerting system – timing and volume – and they are related.  First, a great KPI will only alert someone if the situation is real, meaning that the data really went to a new state.  While each situation is different, this often means setting a “time-in-state” value so that a temporary blip doesn’t trigger an alert if it wasn’t needed.  For example, several of our customers set alerts so they only happen if a KPI stays in the new state for over 5 minutes (again, depends on how active your data is).  Second, volume.  Simply put, it means to choose your alerts wisely or you will have alarm bells going off all over and a full inbox.  Only alert on a subset of your KPIs and only when needed.  Crying wolf isn’t the best strategy with operational situations.
  7. Hierarchy (how KPIs relate to each other): This is a large enough topic to warrant another post, but let me just say quickly that you need to define your hierarchy and naming convention with enough context to make sure things show up in the right places.  A good mobile monitoring and BI application will be flexible enough to let you view things from different angles so getting the hierarchy and naming right can be key to keeping your house in order.

As with most of our posts, we could talk for hours on the subject and bore you to tears (if we haven’t already).  Either way, this stuff is important if you want to get the most out of your tools and your people.  If you have questions, give us a call and we’ll happily geek out with you on any related (or sometimes unrelated) topic.