Infor Birst offers multi-tenant cloud BI for deployment in a public or private cloud, or on-premises. It provides an in-memory columnar data store and a BI layer comprising a reporting engine, predictive analytics tools, mobile native apps, dashboards, discovery tools, and an open client interface.
$30,000
Per 20 Users Per Year
Looker
Score 8.2 out of 10
N/A
Looker is a BI application with an analytics-oriented application server that sits on top of relational data stores. It includes an end-user interface for exploring data, a reusable development paradigm for data discovery, and an API for supporting data in other systems.
During the vetting process, we looked at 14 different products (one of them internal) to see if they would fit our needs and whittled it down to this one over a three month period. We did not contact sales for all of them (sales sites were enough to rule out some), but did have …
Birst allows direct access to an internal data store, which none of the products we evaluated provided. We also found the birst ETL layer far more powerful than the other platforms we considered.
The ability to scale was the primary factor for our CIO's approval. The other products had solutions for scale, but Birst has the one we preferred. As an IoT company our CIO concentrates on products that will meet our requirements today and far into the future. The other …
I evaluated everything under the Gartner BI quadrant (i.e., Tableau, Birst, MS SSRS, MicroStrategy, etc.) — from the niche players, all the way through the powerhouse (supposed) "leaders" in BI. Looker was a nice fit for my company, because all though we are quite large (in …
Birst is well suited for an organization looking for a cloud-hosted analytics solution that is contained within one package. It is able to connect to a very wide variety of different data sources, and has options for either light or involved ETL procedures, depending on the users experience with preparing data. As with any BI project, it would not be suitable for an organization where there is no dedicated team to maintain and manage the project.
Quick dashboards from Google Sheets - Easier to do the graphs than in Google Sheets - Operational dashboards to be used in the day-to-day work - It is good both for retrospective data and to do a pulse check of the current status - Better for not giant amounts of data and not multiple data sources. - If you need a lot of graphs to be displayed on the same page, it can be a bit glitchy during configuration (then the use works fine).
Birst is an platform that provides connectors to some of the applications we use, but also allows us to bring in data from disparate systems to perform ETL and integrate all of the data for analyses. It makes no assumptions about your data, which is good for us, as we have a lot of customizations to many of our systems.
Filtering - you can filter across different dimensions and metrics to get a more specific "cut" of data
Refreshing - data automatically ingests into Looker which allows reports to be updated and backfilled in real time
Conditional Reporting - you can leverage Looker's reporting features to flag when a given metric or KPI falls below or above a specified threshold. For example, if you had a daily sales benchmark in a SAAS organization, you could use Looker to flag whenever daily sales falls above or below the benchmark
Looker is less graphical or pictorial which makes it less attractive
Consumes a lot of memory when there are multiple rows and columns, impacts performance too
At times when we download huge chunks of raw data from Looker dashbords, the time taken to prepare the file is enormous - The user fails to understand if Looker has frozen or if the data is getting prepared in the background for downloading. In turn, user ends up triggering multiple downloads
We have been able to overcome any of the drawbacks we've found with Birst easily and it has fulfilled almost all of our analytic needs to date. Having seen their roadmap it would be highly unlikely we would move away from this platform any time soon. You simply can't beat the functionality that Birst provides for the price and the things I see coming out of the company solidify that our decision to choose Birst was the best possible choice. We have never regretted the decision.
We've been very happy with Looker so far, and all teams in the organization are starting to see its value, and use it on a frequent basis. It has quickly become our accessible "source of truth" for all data/metrics.
I would like to see additional usability put into the ETL scripting. Recently, Birst added a nice function reference inline to formula creation which has kept me from having to return to documentation so much. The same in ETL would be very beneficial. The interface problems related to the Flex framework are being addressed in a rewrite to HTML 5, but for now they are still a hindrance to a higher usability rating.
Looker is relatively easy to use, even as it is set up. The customers for the front-end only have issues with the initial setup for looker ml creations. Other "looks" are relatively easy to set up, depending on the ETL and the data which is coming into Looker on a regular basis.
We frequently experience -103 errors due to us using the Live Connect functionality, which does not seem to handle even minor interruptions in connectivity, and treats all future connection attempts or data requests as errors, even if the issue does not exist any longer
Everything runs very fast and smoothly. The only process that I wish was faster would be processing the data after uploading new data or making changes to the existing data model. It can take 15-20 minutes (roughly) to upload and process new data once you start getting into 10's of millions of rows. Given my experience with how long it takes me to pull the same data using SQL Server Management Studio, I don't think Birst is unreasonably slow - but for me to give a higher rating, I would want it to be unreasonably fast
When we have an issue that is stopping our business from proceeding, I want answers sooner than later. While Birst does have a published response time for each case level, we always wish it could be quicker. What response improvement could there be with a larger support team? In response to first question: Blackhole of issues - Birst needs to improve upon closing issues that resolution was dependent upon code fixes or enhancements, perhaps someone to add a comment on all case tickets at least every 60 days. Escalation - I always have the ability to electronically or via phone escalate a ticket. I also have my Customer Success Manager through whom I can escalate topics.
Never had to work with support for issues. Any questions we had, they would respond promptly and clearly. The one-time setup was easy, by reading documentation. If the feature is not supported, they will add a feature request. In this case, LDAP support was requested over OKTA. They are looking into it.
I have attended two different training sessions. The first one was my initial training on the system. It was well paced, clear and concise. If there were questions that were not able to be answered by the instructor, he took down the question and actually followed up and provided us a response quickly. The second session was specific to the dashboard and report design components. This training was very good though there were some attendants who had little or no experience and their questions slowed the class.
Although I found the online resources helpful, a lack of appropriate examples for certain tasks key to report creation and advanced modeling make the online training/documentation less than perfect. For an inexperienced BI professional, the online training would not enable a streamlined launch of the product.
Have clean data! Birst flexibility allows - Start small, then introduce functionality and complexity along the way. If you try to present all the functionality [bells and whistles] and wow them, but bad data is uncovered, the end user blames the new application and turns away.
During the vetting process, we looked at 14 different products (one of them internal) to see if they would fit our needs and whittled it down to this one over a three month period. We did not contact sales for all of them (sales sites were enough to rule out some), but did have a lot of demos with a significant portion of them and reviewed several of the major industry studies as well. We had representatives of both user interests/design and the technical backend on the evaluation process.
The major features we were looking for a product that we could embed inside our own SaaS application, connect to a sharded Postgres database, had multitenancy and allowed for customer generated reports/ self-reporting. Some of the minor "nice to have" features we were looking at was scheduled reports, especially if we could plug it into our own scheduling system (for CAN-SPAM compliance), internationalization, and support.
In the evaluation, Birst hit all of the must-haves and enough of the nice to haves that they made it down to our final two and the trial was the clincher to make it our final choice.
Looker is an off-the-shelf, free tool for Google business users. Other than the internal cost of time to build, we had no costs to set up what we needed to do. Knowledge sharing internally and using templates greatly reduced this cost, making the overall cost very low.
we can see that loading a lot of data can cause a noticable slow down in performance. Birst support indicated that they don't really consider anything less than 30 seconds to be an issue, but that is not the case for our customers, so we have had to change some of implementation to address this
Being a manufacturing company we tend to lag behind technologically. But having all the data for different ERP systems in one place has been an eye opener for the executives. It has lessened the need to convert some legacy ERP systems.
Having such a simple reporting tool is a great asset to some of our sites that have traditionally had trouble gathering data from AS400 systems.
Allowing others to self-serve their own analytics and connect it to Looker simply and easily has helped unblock the central data team so they can instead focus on validated dashboards whilst stakeholders manage their day-to-day analysis themselves. Countless engineering hours have been freed up by not having to manage every user permission for each BI tool; we have a BYOBI approach; Bring Your Own BI
Creation and management of a semantic layer (LookML =Looker Modeling Language ) allows peoples sandboxes and production databases to become clutter free. Minor adjustments, conditional fields, and even some modelling can all be done in LookML which doesn't need oversight or governance from the central data team.
LookML, specifying drilldown fields and their sub-queries, as well as generally creating dynamic parameters with Liquid are all great features, but can have a steep learning curve. it may take some time to understand how to create this middle layer correctly, or even pose a risk of inheriting complex code from another source which can be unmaintainable if it becomes too big. Some level of governance is recommended if Looker is used by a large number of editors.