Ramesh Jeyaram is a software development project manager at UNIS LUMIN (IT) consulting services company that became a part of Softchoice. He managed the application project development for a professional sport association and facilitated its successful release in 2011. Ramesh was also a major decision maker in selecting Business Intelligence (BI) provider for the data warehouse and analytical reporting solution.
Ramesh, can you tell us what the major business challenge was?
In our athlete application, software that collects information about the athletes such as their sport performance and their health factors, we could manage what information could be captured and we were able to manage the difficulties around the data capture. Also, we managed to hold this information so everybody could see it. That was a typical application. But, in sports the applications are very much based on health. By the end of each year, the athlete health management needs all this information about the different players to be able to see who got injured, when, what type of injury and how much time and money have been invested during this year.
What we were trying to do, was actually to predict the type of injury that would happen. The top stage was obviously reporting what you did, so you can look at different tournaments and types of injuries that happened. But, the ultimate intent was to use these reports not just for the reporting purposes, but to build the intelligence on the specific cases. For instance, when Sidney Crosby got injured, they all started talking about concussions a lot more for the whole year. The athlete health management looked at different types of injuries, but focused on concussions. So, in application we’re capturing data about concussions. We needed, then, immediately go back in time to get all the statistics about concussions: when it was happening and what they did about it. In the application, it was difficult to report on those stats.
- What options did you consider for the analytical reporting solution?
There were not many options. The data was in the database and we could run reports of it, but this would take a lot of time to actually run these reports to get all information together. But, the ad-hoc reports are easy – the whole purpose of a BI solution.
We knew that we needed a data warehouse. When we talked to our client, all requirements they were talking about, reporting side, they were all BI requirements rather than the reporting requirements.
- What criteria did you use for selecting a business intelligence solution provider?
The criteria that we used were to clarify at high-level what the solution would look like. So, what we wanted was a consultant who would come with the experience of the similar requirements, could work independently and show us what the application should look like and what software we should use. We wanted somebody who is knowledgeable, who has experience and who can work independently. That’s what we were looking for.
- And how did the implementation go? Did BI satisfy your requirements?
Yes, absolutely. In terms of how the project implementation itself went, we obviously had some challenges, because it was not very clear what the client wanted. Although, we ultimately knew what they wanted to achieve in terms of reporting, it wasn’t clear what type of reports they wanted, especially in terms of infrastructure requirements, how the data on the production environment was going to be transferred and how the changes in the reports were supposed to be happening. Those were some challenges that we had.
You helped us actually to define that, in terms of production environment, what needs to be run and where, how to stage data and how much time it would take. These are the typical challenges in terms of implementation and in terms of a bigger picture. They should be the focus of the architecture itself in terms of creating reports, how long it takes and how they should be. But, I think the biggest value that you’ve added is by defining the big picture to find out how many servers we needed, what services we were going to run and how they needed to be connected that helped us develop an automation scheduling.
I think the key difference is – if you look for a great BI, between the developers and consultants, the developers would immediately dive deep into defining regulations. They are going deep to subject matter, while the core is to define the bigger picture. You started with the bigger picture and you kept emphasizing it to us to understand how you would use your service and how everything else would really work. I think that’s what differentiates BI consultant from BI developer.
- How did you think we worked with the developers? How easy it was to pick up and share information? Do you think the project went smoothly?
So, you needed the information, the schema, the data types and the volume of information for you to get started. From the management perspective, the key I would look for is how much time you consume and how much of the developers’ time you’re taking for you to get started. I think you didn’t take too much time. You picked up really quickly. From a manager perspective, it’s important how much of your time would it take to become productive. You did really well. I think you picked up very quickly, set yourself up quickly in terms of information architecture. You didn’t take that much time from the developers as our previous vendors did.
- Thank you. And finally, Ramesh, what feedback did you hear from the users?
The feedback was good. We had issues from time to time regarding some system delays, but on the reporting site the data was always correct. Unfortunately, we didn’t have a direct relationship with the client, but we still got a good feedback.