Acheron Analytics
  • Home
  • Who We Are
  • Services
    • All Data Science Services
    • Fraud and Anomaly Detection
    • Data Engineering And Automation
    • Healthcare Policy/Program ROI Engine
    • Data Analytics As A Service
    • Data Science Trainings >
      • Python, SQL and R Trainings
      • ARIMA And Predictive Model Forecasting
  • Contact
  • Acheron Blog
  • Partners

Tableau Warning! Why Not to Use Tableau

2/19/2017

0 Comments

 

There are a plethora of data tools out there for professionals to use. All with their specific use case and strategies. Tableau is one of several highly utilized data visualization tools. It is easy to use, can be connected with multiple data sources, including flat files, databases, CRMs, etc. Honestly, for a non-technical person, it is probably one of the best tools.

However, for all the good Tableau has, it has a dark, hidden secret….

What you may ask? It is quite simple. It is too easy to use!

Wait, What? How does that even make sense. Aren’t tools supposed to be easy. Shouldn’t we just be able to click twice and have a beautiful report? Yes, you should be able to do that, we are in total support of simplifying technology.

However, there is the risk of failing to plan in these situations though…

Now, if your team is accustomed to proper software development procedures, and has good SDLC practices, you are in good hands. If, however, your team is a bunch of bright, and intelligent business analyst who are eager to impress you. You might have problems.

There is a fine line between the constant prototyping and documenting every literal change request(including font changes). Somewhere in the middle, is where you need your BI and Data Science teams to be. They need to build you reports quickly but they also need to ensure they build them in a maintainable way with proper QA steps, analyses stages and risk assessments.

Where does the ease of Tableau fall into all this. If you can make a report in a few clicks, the temptation to not actually think about what you are creating, what data sources it relies on, and how to QA it. How do you know the report will always work and that it is always accurate? Do you know if your data is good? Who manages that data? What happens if the data source disconnects or changes? Did you contact the owner to make sure they know you are using their data? And most importantly, did you check if you already have this report and do you need to revamp it, or not make a new one.

We brought up just a few questions that need to come up when planning any data driven project. We were mostly using them as examples to why Tableau can cause inexperienced teams problems.

Tableau is a great tool. In fact, I love it for prototyping, and mock-ups. We can demo an example report for a client, or executive in a range of 30 minutes to a few hours. The report might even be usable at that stage (This depends on how well I know the data source). That doesn’t mean it should be. Tableau is created to be robust, but it has a lot of issues that need to be considered.

Besides being too easy to use (Yes, we know that sounds weird). Tableau isn’t always as smooth with integrating with technologies as you may think. For instance, we once created a pretty cool report that you could track all your invoices and click a link to them using tableau. Pretty snazzy right! All the executives were raving how they could actually track their invoices. Before..they were literally just told they owed money..

The invoices were connected to an internal app that only worked on IE. So the end-users had to use IE to get to the invoices. This was fine for about 6-7 months. Then, one day, the company updated the Tableau. Things should have been hunky dorey right?

Of course, there was one problem. This version of Tableau worked terribly in IE. It would throw errors, freeze up and just cause constant issues. We couldn’t do anything to fix it and because our internal tool only worked on IE, there was no winning. Obviously, we can’t go into the source code of either program and try to get it to work. Now, a dashboard that our entire executive team relied became unusable.

Some of this is due to the companies haphazard approach to third party applications. However, it is also a good example of how sometimes, you miss mapping out risks, which makes it even more important that you analyze the each component of your future solution.

Tableau is really a great tool, but like any tool, it requires a decent understanding on how to implement it. Tableau can be very dangerous. As the great saying goes, with great power, comes great responsibility(To learn tableau best practices).
0 Comments

Business Vs. The Data Professionals

2/13/2017

0 Comments

 

Business and technology continues to struggle to find a harmonious unity. With new buzzwords floating around like 'Big Data', ‘Data Science' and 'Machine Learning', it has now become even more difficult for the business and tech teams to work together coherently.

In the book, Analyzing the Analyzers: An Introspective Survey of Data Scientists and Their Work, the author points out that “Despite the excitement around ‘data science’, ‘big data’, and ‘analytics’, the ambiguity of these terms has led to poor communication between data scientists and those who seek their help”.There remains a chasm in between technology and business. In the end, how do we get these two estranged business entities to find a common language?

We recognize that technology has always been a source that creates buzzwords and inspires innovation. Data science has been the source of a lot of the excitement for about a decade. When people experience and read what companies like Google, Amazon and Facebook have been able to do with their data and the value they have gained, of course managers want to jump on the opportunity.

Wouldn’t you want to be the one that brought your company to the level of all these titans of the tech industry? That would be pretty sweet!

However, in the rush to get to their final destination, these management teams try to cut corners and end up skipping the journey. These giant corporations like Facebook and Google, have had years to perfect their craft. They didn’t jump on the band wagon, they built it. They realized that good data science and machine learning started with good data, and proper processes to get the end user (whether the data scientist or the customer) the data they really need.

Most of these companies have been doing it for over a decade. Now, we have lots of copycats trying to imitate other companies success. Managers are hiring data science teams, BI teams, and applied mathematicians left and right. Then, they try incorporating them into their companies current tangled eco-systems of specialized teams.

When this occurs, most managers run into several problems.
  1. First, they realize their data has been locked up by DBAs and Data Warehouse Gurus. These protectors and designers of data have processes a marathon long in order to get even one SELECT statement worth of data out of their warehouse.
  2. Second, on the other side of the spectrum, there has been so little process around data acquisition and standardization, that most of the data sources they these managers thought were valuable aren’t. Those are just the internal problems that most companies face.
  3. On top of all this, management runs into the issue of hiring data science teams that have no idea how to provide value because management doesn’t ask the right questions, and the data science teams don’t know how to elicit them.

Your Data Is Locked up

A common problem most data scientist and BI analyst experience is getting to their companies data. This typically is caused by people with great intentions. DBAs are often the sole guardian between data that is operation critical and the slew of internal threats like devs, BI analysts, and fresh out of school grads. If allowed, these intelligent but unaware miscreants would drop an entire database, delete tables, and cause all sorts of mayhem without even knowing it.
Guess who gets blamed for all of this? And who has to fix it?
Yup, the DBA.

They have a lot of good reason for not wanting to freely let anyone have access to their data stashes. However, this causes data scientist to be bogged down with processes. Even if they are allowed data, they often have to construct their own pipelines/ETLs and structure new databases.

All of this eats into a data scientist’s ability to be productive at what they do best. Suddenly, a simple 4-week project of analyzing sales data, becomes a eight-month-long mission to create a new datawarehouse, build ETLs and QA the data before they can even start your first bit of analytics work.

When you are paying an employee upwards of 100k, this isn't practical. You need them to be fully functional, and fast!

Your Data is Not Reliable

For all the hubbub about the value of data, very few data evangelist warn companies about dirty data. Most Hadoop infrastructure salesmen, and tableau specialist are just trying to sell the next “it” product. They convince companies and managers that no matter what shape their data is in, they have the tools to fix it.

If they’re anything like that, it should tell you that they have never worked with data beyond the 3 months of intro their start up gave them. Of course, the less the salesman knows the better. If he doesn’t realize the limitations of his own product, it is easier for him to tell the truth without knowing he is lying.

In some cases, data is just wrong. Over the years, systems may have never been QAed and the gold mine you think you are siting on, may just be a garbage dump.

First thing is first, before you go off and buy yourself new toys to utilize your data, make sure your room is clean. I don’t care how this is done. Whether you hire someone internally, or look for consultants. Get someone to analyze your data sources every few years.

Some form of an audit can be very valuable. Something that guarantees your data is good and can trace when it might have gone bad. Otherwise, when you spend several hundred thousand dollars of capital budget on a data science tool or new machine learning algorithm, you might just end up with an expensive paper weight “so to speak”.

Your Data Team Is New To Business

Data scientist are a rare breed. While every business analyst who has used SQL or R for three months are suddenly throwing the title on their resume, there are truly very few data scientist that meet the true qualifications  that businesses are looking for.

Larger companies have gone so far as to plucking professors out of colleges with three PhDs, twenty research papers and a Nobel Peace Prize because they prove to be the most qualified for the role of data scientist. Of course, once you have captured a few of these illustrious creatures, what are you going to do with them?

A lot of businesses just throw them at data, and expect value to be found. Don’t get me wrong, ambiguity is great and all but how do you expect them to know what is valuable to you, or the company? Especially if you just hired the team?

You can’t just expect them to know what you want.

There needs to be open dialogue that allows them to see what the business needs to reduce the tech gap. There needs to be conversations of what the businesses sees as strategic initiatives, expected data science team outputs and external threats that can be mitigated using the company's new possible competitive advantage. Even machine learning engineers are given 1.5 years to come up with each valuable new algorithm or concept. Data science teams won’t always be successful right away. It will take even longer if your company doesn’t include an executive to lead these teams who is also part of high level strategic meetings. That way, he can help provide insight to the team in where the company is going.

This gap between business and technology isn’t new. We have dealt with it since before this generation and only a few companies that were tech centric really seemed to find the solution. Others remained in the dark, and fumbled when it came to finding value from their tech and data teams.

This gap is caused by the fact that management can’t qualify what they want properly and the data scientist don’t ask the right clarifying questions. Yes, requirements should be somewhat vague to avoid boxing in your results. However, managers are still responsible for defining what is valuable. Without doing that, your team might learn some cool things and create awesome dashboards and websites. They might do all of this, and provide your company a utility of 0, Nilch, Nada!

Your department might have just spent hundreds of thousands, maybe even millions of dollars to start this team and they might provide some cool deliverables. All of which, don’t benefit you, or your strategy team can’t implement. Then what was the point. If you just spent so much time, and money on a project that yielded no form of benefit besides a cool dashboard...why?

Data scientists have a lot of good energy. They are brilliant in multiple fields. Only some are brilliant in making value for the business without being told what that means (in all fairness, this is a trait that is not specific to data scientist, accountants, analysts, and even managers sometimes fail here). When you are an individual contributor, it can sometimes be hard to see the big picture. This is what I believe business managers are for.
​

Overall, data science and analytics provide companies the opportunity for a competitive advantage. It allows managers to make better decisions, and connect better with the customer. However, it is important to take a close look at what resources you have to work with, before attempting to bring projects in front of your data science teams.

0 Comments
    Subscribe Here!

    Our Team

    We are a team of data scientists and network engineers who want to help your functional teams reach their full potential!

    Archives

    November 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    February 2019
    January 2019
    December 2018
    August 2018
    June 2018
    May 2018
    January 2018
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017
    April 2017
    March 2017
    February 2017

    Categories

    All
    Big Data
    Data Engineering
    Data Science
    Data Science Teams
    Executives
    Executive Strategy
    Leadership
    Machine Learning
    Python
    Team Work
    Web Scraping

    RSS Feed

    Enter your email address:

    Delivered by FeedBurner

  • Home
  • Who We Are
  • Services
    • All Data Science Services
    • Fraud and Anomaly Detection
    • Data Engineering And Automation
    • Healthcare Policy/Program ROI Engine
    • Data Analytics As A Service
    • Data Science Trainings >
      • Python, SQL and R Trainings
      • ARIMA And Predictive Model Forecasting
  • Contact
  • Acheron Blog
  • Partners