If your CEO is like ours, he (or she) is always looking for additional revenue streams for the company and ways to free up IT resources.
We learned that fact after integrating Izenda into thousands of applications, and asking CEOs what their motivation was for integrating a third party Ad Hoc reporting solution. Here are their top three answers:
- Increased revenue from existing customers.
- Made their product more competitive against the competition.
- Satisfied their customer’s (or internal user community) requirement for better ad-hoc reporting.
As you might imagine, once these CEOs started seeing the benefits mentioned above, they always told us they were sorry they took so long to get going. So, why did they take so long? (See if any of this sounds like your shop.)
- CEOs and VPs of Product Development always try to determine where they’re going to get their biggest payback. In addition, they have to juggle the human resources and money available against the demands of their user base and customers. They mistakenly believed that putting out the fires of the day, would lead to customer satisfaction down the road. It’s the “Maybe now they’ll be happy” syndrome.
- Analysis – Paralysis. Analyzing the pros and cons to death and failing to commit to any strategy. Probably enough said here.
- The “not invented here” culture. Most companies we deal with are Independent Software Vendors (ISVs). Many of these companies believe they have to write all the software their company uses. “Hey, we have great coders here. I’m sure we can do it ourselves.”
Unfortunately, they fail to take into consideration three very important points:
- There is great amount of value to a company for sticking to its core competencies. Doing what you do best. Focusing on your core application suite and bringing in third party components to enhance that application.
- Opportunity lost revenue. Simply stated; How many deals are we losing, or how much more upset are our users getting, while we work internally on the add-on?
- The internal cost to develop and support the add-on product. You should be able to add up the cost of your development team’s salaries, benefits, etc., and make a sound financial decision on “buy vs. build.”
While this article may sound like a self-serving way to get you to try out Izenda, we believe this scenario is true for any third party add-on going into your application suite. We would really like to hear from you on your experience, and guidance to other users, on using third party add-on applications.
Does your architecture rule out providing reports and dashboard for Java based applications running on UNIX servers?
We've been using Izenda Reports for about two years as an add-on to our proprietary software. While our software has a good library of reports for franchise owners, there were very few reports that were available for corporate information encompassing many stores and several brands. Izenda Reports has made it possible to create standing monthly bookings and sailings reports, as well as gives us the ability to write a report for special circumstances. When an earthquake hits in Chile, or transportation workers go on strike in Spain, we are able to easily find our stores' clients who may be affected and proactively notify the stores so they can start working with the client. We would have no way of doing this without our Izenda reports. We also use Izenda Reports for creating marketing mailing lists which are built using a unique set of filters with each list pulled.
Sharon Johnson, Manager of Franchise Services, Cruise Holidays
We're wrestling with some of these issues now. We have an internal database re-architecture and reporting tool project that's several months behind schedule, so "why so long?" is a frequent topic of discussion in our conference rooms. Much of that has to do with project management errors, but more relevant to this discussion is the "easier to build" mentality.
In this case, the resistance to third party tools came from the development team itself, so the rationale was a little different than what I see in your post. There's the "the front end is the simple part – we can knock that out quickly", but that's proven to be untrue. There's the matter of mid-stream reporting changes that require re-coding by the developer, interrupting the build cycles and extending deadlines. I understand that reporting tools such as Izenda put the report design more in the hands of the business types, which would have mitigated that issue. Finally there's the "they're just internal reports – they don't need to be too pretty". It's true that they *were* just internal reports, but we've had several requests from customers to have access to the same transaction data, so once this project is out we'll need to kick off a new one to make the reports more user friendly and accessible to our partners and customers, when we might have addressed that upfront.
So, yes, there's something to be said for taking a long, hard look at software tools on the market that fall outside of your core area of expertise.