Tuesday, May 7, 2013

Continuing Education

I am excited about discovering a new, FREE learning site today through one of my LinkedIn groups and thought I would share!


Lots of possibilities - I'm starting small with Introduction to Data Science.  I'm thinking the course on musical improvisation is interesting though...

Monday, May 6, 2013

Aiding the Analyst - Tips for the Hardware Guys


Information Technology is the heart of almost every business - even though they are often viewed as a necessary evil.  At some point the IT staff is going to be called upon to aid another employee in getting data from their transactional systems for reporting purposes.  Having come from an IT environment that was dominated a by hardware-centric staff aspiring to be network administrators, I have a few tips that will make aiding analysts much easier.

*Note - I'm not going to reinvent the wheel and write lengthy tutorials.  These are just techniques I've learned over the years that have helped me and my staff.

Learn Basic SQL
In order to troubleshoot most transactional systems, you need to have at least a rudimentary understanding of relational databases.  Learning the basics of writing SQL is not difficult and there are plenty of resources to help you out.  IT professionals should have a basic understanding of tables, unique rows, keys, and relationships as a foundation for the basic SQL statement.  Knowing how to construct a basic SELECT statement is the logical progression from there.  Minimum basics - SELECT statement structure, FROM clause and joining 1 or more tables, join types, and WHERE clause.  I would say that the minimum is just selecting rows from one table but when working with analysts you will almost always be using multiple tables.

Utilize Microsoft Office Tools
Excel and/or Access can be good alternatives until you are comfortable writing SQL statements.  Both can connect to your database via ODBC connections and offer graphical interfaces for query creation.  If the request is a fairly simple data-dump, Excel is going to be easier.  If you have a need for more complex data manipulations, Access is the way to go.  In Access you can set up your ODBC connection then link directly to the tables in your database and use the built-in wizards to help you build the queries you need.  The resulting datasets can then be exported to Excel.  The best part of utilizing MS Office is that you can train most analysts to use these tools to pull the data for themselves.  (If you're feeling adventurous look into PowerPivot for Excel)

Employ User-Defined Fields to Facilitate Reporting over Multiple Systems
If you don't have a data warehouse that consolidates your data combining data from multiple systems can be challenging.  I worked in the gaming industry for over 10 years and no matter the size of the property there are at least two transactional systems in use and it can often be advantageous or even required to combine data from both into a single view.  Save the analyst (or you!) from having to manually enter data from reports into a spreadsheet and find out if there are any user-defined fields available that you can configure to contain foreign keys.  (See Step 1 )  I think this will be best understood with an example.

I was employed at a property that had a casino floor/CRM system, a point of sale system for food and beverage and retail, a hotel management system and an accounting/payroll/HR system.  What do they all have in common?  Employee IDs  and each one unique.  IT was responsible for security in all these systems I needed to find a way to make processing terminations seamless.  I was provided with a list of terminated employees on a regular basis but had to manually review each system to revoke their access so when we changed vendors for the casino floor system, I took that opportunity to institute a process that would make things much easier.  In the new system there was an additional field on the employee set-up screen that we used to hold the employee's "master" employee number from the HR system.  NOT their SSN but their unique identifier.  I created a report that joined the HR employee table to the casino system employee user table which returned all the information needed to revoke the access of any terminated employee.  It also allowed for additional reporting, like system access by title, that helped make our department more efficient as well as compliant.

Make the Case for a Data Warehouse
OK - I’m more than a little biased here but if you have multiple, disparate systems that are reported on daily you probably need a data warehouse or data mart.  Research the options and tools and formulate the ROI.  If it is favorable, start making the case to management and solicit help in this regard from the analysts. 

Thursday, May 2, 2013

"A Report Tool on Every Desktop" ??


"Democratization of Data" is the Business Intelligence (BI) catch phrase of the hour.  The idea that data should be accessible at every organizational level for faster and better decision making independent of technical acumen appears desirable and should give companies an advantage in the fast-paced world in which they compete.  Additionally, BI projects are notoriously long and expensive so spreading that cost over as many employees as possible increases the return on investment.  That all sounds great in theory but I question the feasibility of this scenario in the real world.

It has been my experience that while middle management is quick to complain about their information challenges and the speed at which they receive information, they still don't want to be responsible for getting it for themselves.  Who would be their scapegoat?  Furthermore, if a pivot table in Excel intimidates them (and you know it does!) they really don't think they can understand how to use your new, simple, point and click analysis tool.

I realize I'm generalizing A LOT.  I'm sure there are some who would love to have access to BI tools and be self-sufficient.  I also don't mean to cast those who don't feel this way in a totally negative light.  I guess I question why those who rely on analysts now don't do their own reporting.  Is it really because it takes someone technical to compile this information for them?  Is that really the only hurdle and the 'democratization of data' is going to solve the problem?  I don’t think so.

I have worked with many people over the years in different departments who dedicated hours upon hours to printing reports from transactional systems then keying that information into a spreadsheet so they could get the information they needed.  Yes - when I discovered this I found ways to automate or help them with the process but the point is they felt responsible for getting this information and they were going to get it anyway they could.  These people will embrace self-service BI.  Those others who hounded me for data and couldn't even transpose a few columns in a spreadsheet without my help will not.  Frankly I would have loved to have some of these tools available way-back-when just to make my life easier. 

I also question if a "report tool on every desktop" is right for business.  Most businesses pay managers and above to consume information not compile it.  Should businesses pay an executive $75-$100 per hour or more to build reports?  Don't get me wrong, I readily see the benefit of decision makers being able to slice and dice on the fly but it takes technical people and analysts working in the background to make that doable in the seconds it should take.  Execs should be directing the company and making decisions.

Although this post could be construed as a mini-rant, I do love the idea that our tools are getting easier to use and hope that helps to expand true BI. 

Wednesday, May 1, 2013

Not the Same ol Resume

I am pretty excited about something usually mundane - my resume.  I decided to take a page from all the graphic artists out there who have created some pretty unusual and visually stimulating CVs I have seen recently on the web.  Since my specialty is Business Intelligence, I decided to showcase some of my reporting skills and format my resume as I would a data visualization.



Some highlights:

  • I quantified my experience as KPIs (key performance indicators) and listed them in two tables.  It was interesting creating data tables in Excel about myself!  To get the metrics, I created a table with columns for month, year, company, title as well as columns for technologies and skills I wanted to measure.  I then populated each row accordingly with one row per month of work experience - for tech and skills I entered "1" for each month utilized.  I used pivot tables to get the metrics I included on my resume.
  • The QRC is a link to my LinkedIn profile.  (I generated it at QRStuff.com)
  • I used a great font by Kazuyuki Motoyama called Ligature Symbols for all the little "icons".
  • The section I struggled the most with was Education and Experience.  I tried a flow chart and a timeline before settling on a Gantt.  I'm thinking of adding meaningful color coding to it that represents the industry of each company.

Hope you find some inspiration!