Blog | Language | Customer Login | +1-925-218-6983
What is Visual KPI? | FREE 30-Day Trial | +1-925-218-6983 Subscribe via RSS Feed


Real-Time Dashboards & Alerts

Smartphones | Tablets | Web Browsers | PC & Mac | More

Visual KPI reads multiple data sources in real-time (big data, historians, databases, manual data, web services and more) and adds context with KPIs, groups/hierarchy, alerts, and geolocation. It gets your critical data in the hands of more users without extensive training and it can be deployed in days, not months. Want to see how we do it?

Mobile Operations Monitoring - Tour
Real-time KPIs on Browser, iPhone, iPad, Android, Windows Phone, tablet
Check out a 2-minute video and see the latest…
What is it?

Visual KPI is mobile dashboard software for any device. It reads existing data sources and delivers KPIs, scorecards, analytics and alerts in real-time.

Who uses it?

Decision makers. Operations. Remote workers. Data Junkies. Anyone who values knowing what's happening right now, regardless of their device.

Why use it?

Mobility is no longer optional. Visual KPI presents problems and opportunities before it's too late. Oh, and there's no six-month project that "might" pay off.

American Electric Power BP Wind Energy con edison operations Exelon Energy Genentech FMI - Freeport McMoRan Corning Pemex Tesoro


OSIsoft PI World Sponsor 

Why Subscribe?

1. You're always up to date
2. It's totally free!
3. All the cool kids are doing it


About Transpara

Transpara are the developers of Visual KPI, a mobile and web application for monitoring operations data from any device in real-time. Learn more…

Michael Saucier
Lead Vocalist & Band Manager
Robert Hylton
Exec. Producer & Percussionist
Collected thoughts on transparency, mobile monitoring and Bl,
operational intelligence, great software. . . and occasionally golf. 

The Intersection of Big Data & Mobility

Two of the hottest enterprise markets are about to collide. What does that look like and more importantly, what should it look like?

In our last post we looked at how historians and Big Data are aligned (quite well) and we have discussed all over this blog how to best mix historians and mobility. Now let's look at Big Data as a larger concept and talk about what is possible, what is likely and what we feel is the right approach (for now).


Spoiler Alert! Mobile applications should only show results and analytics from Big Data that meet the characteristics of mobile user behavior in general.


This cannot be overstated and applies to all data, not just Big Data. Real humans use their phones and tablets in very specific ways and at very specific times, which is why you see common characteristics show up in almost all of the top mobile apps (business or consumer). Here are a few:

  • Small chunks - break data into small, actionable parts I can work with on a small screen or with limited time. Analyzing wildly complex pivots of historical data on the train or waiting for the DMV is not the key use case here.
  • Timely - show me what is happening right now or just happened in case I need to take action. Mobile is usually not the case to do deep analysis into the past or the future
  • Context - give me more than numbers and pretty charts. Tell me if they are good or bad without me doing all of the work (KPIs are good for this)
  • Location-aware - where something is happening may be just as important as its severity. Am I close to the problem and can I fix it?
  • Alerts - the application should tell me when I should look at it, just like SMS, email or Facebook badges do.

We've probably all seen videos and software demos from the big BI vendors (SAP comes to mind) that show the CEO clicking a few buttons on their iPad to crunch some huge big data numbers from multiple angles to solve a wild problem right in front of the board of directors, but let's be realistic. The data guys will always be called upon to solve these issues and they will most likely do this on the desktop. Not because of technical limitations, but because it makes sense.

Mobile BI in general often reminds me of a quote from comedian Patton Oswald that goes, "We're science: all about coulda, not about shoulda." We consistently see what people can do on mobile devices, but after talking to hundreds (probably thousands) of customers we've seen a distinct pattern emerge for what people should, or want to do. Just like with email, Facebook, Twitter, Google Maps, banking apps and more, mobile users want to know what is happening right now and what they can do about it. They are constantly checking feeds and stock prices, getting directions to their next appointment, etc. This behavior must be applied to mobile BI apps to be truly useful.


We must learn from Facebook, Twitter, email and other mobile success stories to really see what subset of Big Data will be useful to mobile users.


Hopefully you are seeing the answer already. Some of the best Big Data tools like Splunk, Cloudera, Pivotal and many others are doing a great job helping you get answers from huge, diverse data sets. Like BI vendors, they also may have mobile versions of their desktop applications, but as we've discussed this isn't where success will be found because the behavior doesn't match the feature set.

The ultimate first task is to refine those answers down to the ones that make sense to show mobile users and let them drill in only when necessary. For the moment, this lends itself most to operations and other fast-moving data, where people need to be alerted on a pending crisis, or know when inventories are low, or see what they should work on next based on their location. To get this right for a large number of users, and preferably those without extensive training, you need to surface only those items that match mobile user behavior.

As always, we'll have more on this topic soon. Let us know what you think!


Historians & Big Data

We get questioned a lot about both historians and big data, and since our team works with both (and many other types of data) we thought we should add our perpsective to help clear up, or further muddy, the topic of Big Data.

First, let's get our head around big data with a some definitions from around the web:

  • Wikipedia: Big Data usually includes data sets with sizes beyond the ability of commonly used software tools to capture, curate, manage, and process the data within a tolerable elapsed time. Big data sizes are a constantly moving target, as of 2012 ranging from a few dozen terabytes to many petabytes of data in a single data set.
  • Gartner: Big data is high-volume, -velocity and -variety information assets that demand cost-effective, innovative forms of information processing for enhanced insight and decision making.
  • McKinsey: “Big data” refers to datasets whose size is beyond the ability of typical database software tools to capture, store, manage, and analyze. This definition is intentionally subjective and incorporates a moving definition of how big a dataset needs to be in order to be considered big data—i.e., we don’t define big data in terms of being larger than a certain number of terabytes (thousands of gigabytes).

For the purposes of answering how Big Data and Enterprise Historians relate, I think it is best to not just look at the size of the data (which is huge no matter how you look at it - see graphic below), but the characteristics of the data and the tools necessary to get value from it.

This is best summed up in a free guide from our friends at GE (makers of the Proficy Historian) called "The rise of Industrial Big Data." They offer quite a few insights and detail about the size of historian data, the speed at which it moves, and much more. Here is a graphic from the guide that shows the data output of just one single factory area for example:


So we know historian data is big and has high velocity, but what really makes historian data fit the category of big data is how unique the tools are for storing, retrieving and analyzing this data. By the simple fact that historians are their own category and that most successful historians (OSIsoft PI, GE Proficy, Wonderware Historian, Rockwell FactoryTalk, Etc.) are not based on relational databases or data warehouses demonstrates just how specialized these tools must be.

So, is there any importance to putting historians in the Big Data category? Does it even matter? I think the answer is yes, for several reasons: 

  • Historians are not as well know as they should be. They have been around for decades but are only known to a small subset of the technology world and have remained stuck in a narrow band of industrial uses for far too long. Attaching them to the 'hotness' of the Big Data category may shine some light on these powerful engines and the value they bring.
  • Historians bring some history and deep experience to the world of Big Data. Tens of thousands of companies run historians, and some historian customers have been running their systems for decades and have real knowledge that should be shared with the Big Data community.
  • Many of the tools that were brought up in the historian age could translate very well to the Big Data age and more people need to know about them. 

In our next post about big data we will explore how two giant and fast-growing industry topics are set to collide: Big Data & Mobility.

Until next time...


Transpara Visual KPI Not Affected by Heartbleed Bug in OpenSSL

Heartbleed OpenSSL BugOn Monday of last week, a group of security researchers discovered and publicly disclosed a vulnerability in OpenSSL, a software package that is widely used to secure online communications. They called the bug Heartbleed, which you can read about more at

Transpara does not use, and has not used, OpenSSL with out software or on our web site, so we were not vulnerable to this bug. As an Visual KPI user, there is no need to take any action unless you have added OpenSSL to you own environment outside of our software.

We have also investigated the services we use, such as our web site and many other services. It appears that all of these services have either fixed the bug or were immune to this issue by not using OpenSSL. Therefore, we do not believe that any data has been accessed. We are actively monitoring the situation and will notify you if the situation changes in any way.

If you have questions at any time, please contact us at or call +1-925-218-6983.


New Starter Package Pricing!

Full Pro Edition features, but limited to 50 objects and with a much lower price.

Looking to get started with Visual KPI or extend that initial free trial for a few months without incurring the full cost?  Our new Starter Package may be just the thing.

It's a fully-featured package that includes 10 named users and installation/setup for just $1500 per year on subscription (includes support/updates) or $5000 on a perpetual license (+20% annual support/updates).

Now you can aggregate multiple data sources and make them mobile, including OSIsoft PI, GE Proficy Wonderware and other historians with thousands of other databases, web services, business application and more, and do it at a reasonable entry price.

Note: the Starter Package is limited to 50 objects (KPIs, values, managed trends, tables) and is for new customers only.  Click below for more details or to request a quote:

More Starter Package Details


Excel: Still not a database, but...

Updated Excel interface allows improved access to open workbooks for trend data.

Microsoft Excel LogoWe have had great success with our Excel interface, but you might have heard us say (over and over) “please don’t think of an Excel file as a database. It is really limited.” We still mean that, but we worked hard to bridge the gap between these notoriously unreliable but pervasive little buggers and first-class data sources like historians, relational databases, web services and data warehouses.

If one or more of your data sources is Excel, you won't want to miss the updated Excel interface and these tips: Click to read more.

[updated 4/7/2018]

In case you need a few more reasons not to use Excel as a production data source, here are some details:

  • Visual KPI supports interfacing to Excel as a data source, but it is important to understand that it is notoriously unreliable data source for many reasons (users can change the format, rename things, move the file, and otherwise break things that applications like Visual KPI rely on to read). Below are detailed requirements for using Excel as a data source with Visual KPI:
    • A ‘production’ copy of the spreadsheet or workbook must be stored in an accessible read-only location that will not change, and this copy should never be the version used by users to make changes (XLS files cannot be read while open by any user)
      • Users should access a version of the XLS file meant for changes and once completed (or on a periodic basis) this version can be automatically copied to the production location to update the production XLS file
    • XLS files can have multiple tabs. Each tab must have a rectangular format where the top row is a header and at least one column includes a date or date-time value (e.g. Datetime, coumn1, column2, column3, etc.)
    • When changes are made to the overall format of the XLS file, these changes must also be reflected (or at least evaluated) in the Visual KPI Excel interface. Formatting changes that affect the interface include:
      • Renaming tabs
      • Renaming columns
      • Renaming the XLS file
      • Moving the XLS file to a new location or changing the path to the file
    • The following changes to the XLS file are ok and do not require updates to the Visual KPI Excel interface:
      • Adding rows
      • Deleting rows
      • Adding Columns
      • Reordering columns
Free 30-Day Trial

Transpara LLC
4715 W. Culpepper Drive‎
Phoenix, AZ 85087

© 2005-2018 Transpara LLC. All rights reserved.
Privacy Policy | Terms of Use | Copyrights

© 2005-2018 Transpara LLC | Privacy Policy | Terms of Use | | +1-925-218-6983