This week, we speak to Jay Vakharia1, Enterprise Business Intelligence & Analytics Manager at McGrath RentCorp. Jay began his career in web development, starting his career as a multimedia and web programmer at Pioneer Advertising & Multimedia and Tata Interactive Systems. He then functioned as a consultant for some years before beginning his stint of nearly two decades at McGrath RentCorp.
Could you give us a brief description of your current role?
Could you tell us about your journey into the BI and Analytics space?
I have been working in the BI and Analytics space for 14 years. However, I began my career in web development. I worked at Tata Interactive Systems in Mumbai, India before coming to the United States in 2000. When I first came to the Bay Area, I was involved in several contractual engagements working on web applications. In 2001, I received an opportunity to work with McGrath RentCorp when the company sought to create its web presence with a site called eRentTestEquipment.com. Before the site went live, the company hired several contractors to carry out certain enhancements and bug fixes. That was my first role at McGrath RentCorp. In 2007-08, the company decided to implement a sophisticated rental and logistics engine called Rental Result for one of our largest divisions. This logistics engine came with the Cognos BI platform, which had not yet been acquired by IBM, and I was offered the opportunity to switch gears and begin working on BI.
Making the shift involved a definite learning curve. While the tool itself was not difficult to gain expertise with, the model, platform, and the data being served through the Cognos platform required greater understanding. This is primarily what I have noticed with other platforms as well. From a self-serve perspective, the tools are not difficult to use. However, people struggle with developing an understanding of the data, model, and framework.
What are some of the interesting and important lessons from the domain that you would want to share?
One of the most important lessons I have learned is regarding the acquisition of BI products. A few years ago, McGrath worked with a mid-sized BI company that bundled it’s reporting tool with Rental Results and we were offered limited options to evaluate different BI products. This continued in 2012, when we implemented the business applications from a major software provider. Again, we did not go through an evaluation process of the various tools or BI platforms available at that time, in terms of the best fit for our environment and operations. Organizations may think of themselves as an Oracle shop or a Microsoft shop, and pick their BI platform accordingly. However, it is important to evaluate different products rather than picking just one technology provider.
We are now undertaking a transition to a new BI tech stack. For evaluating this new stack, we came up with a matrix of key criteria to consider, identifying reducing complexity, reducing cost, and increasing performance as the primary goals. When shifting from a homegrown, on-prem setup to the cloud, organizations will certainly want to increase performance to be able to scale further. However, that has to be balanced with the immediate costs, when you have a smaller user base, for instance. Simply put, organizations should classify the various problems they want to solve using a new technology, rate the different available platforms in terms of pricing, complexity, overheads, performance, and other factors, and then choose their products appropriately.
Next, a proof of concept should be mandatory before implementing an actual product. With cloud platforms offering free credits, organizations should leverage them to test products under real conditions. They should deploy their actual data in the PoC and test how a platform performs, and how different it is from other available products and the existing platform.
Could you tell us a little bit about your team structure and tech stack?
How involved and challenging was the cloud (Snowflake) transition for you and your team? How did you anticipate the effort and impact of the transition?
The evaluation process was challenging and time consuming overall. Given the reliance on our critical data infrastructure and insights that the business teams were dependent on, we planned the transition over a 3 year period. The transition is currently ongoing, hence I’ll share more about how we went about the process.
The main goals for the transition were reducing complexity and cost. Based on these goals, we shortlisted technologies to modernize our data stack. We created POCs to help evaluate the technologies that we would use for the transition and zoned in on the Tableau / Snowflake / Rivery stack as our final stack.
We decided to go with two parallel (legacy and modern) data stacks to reduce business impact. Once we stood up the new infrastructure, we started transitioning dashboards from the old stack. On completing validations across stacks, we switched off lights on the legacy dashboards.
Our transitioned users were amazed with what they saw and with the options that Tableau enabled for them, notwithstanding the benefits of Tableau Online for getting benefits to incremental features.
Transitioning to Snowflake, a managed service on the cloud was extremely beneficial to our development teams too, reducing the need with mundane activities like backups and like. This opens up new capabilities allowing for better management including creation of new warehouses for Tableau, Workflows, etc. allowing us to manage costs better
With Rivery, we get ELT in cloud, fetch data from cloud sources, much faster than tools like Infomatica. Very competitive in costs from the features delivered. Allows for a large footprint in data structures with * Variety of sources and destinations * New insights delivered to business * Adoption is picking up
How quickly were you able to resume business as usual post transition? Can you please share best practices/ tips and tricks for organizations planning their transitions?
We experienced no impact given our transition model. We left the legacy BI stack running and it is still operational and running in parallel. We are retiring content (dashboards) one at a time after re-creating and improving the same in the new platform.
My guidance to teams undertaking this journey would be:
- Pick a platform pay-as-go and scale up
- Keep existing platform running to minimize costs
- Understand and use feature overlap between stacks to your advantage
- Review your lessons learned and factor in learnings while you go through the transition
- Cost of delivering new features on older stack is under represented and needs to be accurately planned
- Snowflake transition - We have had to build everything ground up. Document naming conventions, view and table naming conventions. The more organized and planning effort that you put in the better. Have clear guidelines for data engineering team to come out ahead after the transition.
How would you quantify the benefits and unanticipated effects of the transition?
- Data discovery used to take 75% time and 25% to uncover insights, now flipped
- Less resources/cost of managing tech stacks and keeping the lights on
- Can focus more on the business
- Increased performance for the end users
- In the past they didn’t have the patience for dashboards to load and requested email, now performance has flipped the switch
What do you think are some of the trends emerging in BI? Where do you think the field of BI is headed five years from now?
What are some of the exciting and challenging aspects of managing a BI and analytics team?
The most exciting aspect is the range of data sources we get to work with. With application teams, applications do not change on a regular basis. We are constantly in the process of extracting data from new sources as well as augmenting data from traditional sources. So, there is always the excitement of dealing with new sets of data and uncovering new insights for the business.
My primary challenge comes from managing a small team that is simultaneously responsible for production support—managing tickets, change requests, and so on—and for working on specific data projects. Even when contractors are hired for more complex projects, our internal sources become involved because of their business and domain knowledge. This is exciting for my team members. However, they do get involved into the production support aspects more than they would like. It has been challenging to balance these two aspects, but we still have to keep the lights on with the routine work of production support.
What are some of the biggest mistakes that companies make during the hiring process that either result in bad hires or drive away good candidates?
When you look at a candidate's resume, what are some of the must-have requirements or red flags that you would look for?
If a candidate has switched between too many projects in the recent past, that is a big red flag. In terms of BI and analytics, getting up to speed on the data itself requires between three to six months. So, I prefer candidates with a minimum tenure of at least one-and-a-half to two years with each company.
On the plus side, one thing I look for is how the work of a candidate at previous companies helped drive the business forward. BI and analytics have evolved significantly in the recent past and are no longer about merely serving information. They now involve developing insights and using analytics and insights to change and drive business, generate more revenue, cut costs, and so forth. I want to see information on how a candidate made a difference to a company’s business in these directions.
For example, we recently developed a sales rep analytics dashboard on Tableau and Snowflake for one of our business units. A previous version of this dashboard existed on OBIEE. The OBIEE dashboard was more tabular, a pivot-type that was interactive to a certain extent and allowed us to filter data using different prompts and drilling through at one level. However, using the power of Tableau, we were able to uncover several new insights into sales rep performance. In the tabular format, it was difficult to clearly capture several metrics such as month-to-date pacing on goals, the conversion ratio on outbound calls, leads, quotes and bookings. Using colours, graphs, and charts in Tableau, we have been able to uncover several insights regarding our top customers, where we are losing and gaining business, which segments to focus on, and so forth.
What advice would you give to prospective candidates who want to prepare for an interview with you?
What vital skills do you think young BI developers and analysts should focus on developing?
What are some of the problem spaces that your team are exploring that you think candidates might find exciting?
We are currently building up a next-generation system for one of our largest divisions. We are also going to be deploying next-generation customer relationship management, CPQ (configure, price, quote), and so on. BI plays a major role in these developments. New systems mean new dashboards, new insights and so on.
At McGrath RentCorp, we do not have a data volume issue. However, we do face a velocity issue. We deal with a variety of disparate data sources as we serve four rental divisions using a range of different applications. So, our work involves transforming and marrying a lot of data on a regular basis.