At AtoBI, we are always sure to stay ahead of the curve when it
comes to the software programs best suited to the needs of our clients. One of
our current software programs in use is MapR, a Data Platform used to gather AI
and analytics dataware. There are many benefits to using MapR, and yet recently
there has been some concern as to its future and how best to support its users.
CEO of AtoBI, Elaine Graydon, attests to the efficiency and benefits of using
MapR, and will continue to support MapR throughout these changes.
Firstly, let’s look at the
benefits of using MapR.
No matter your underlying infrastructure for data, the MapR
dataware can handle a multitude of different data types. Users gain access to
the MapR Data Platform, which allows them to store, manage, process and analyse
data no matter their source. This software includes complete data protection
and disaster recovery, to give you confidence knowing your data is protected.
MapR and HPE
After MapR Australia closed on May 17th 2019, there was a lot of
uncertainty around customer support, expansion licensing and new purchases.
Before this, MapR had announced they would be closing their corporate
headquarters due to funding issues. This caused some upset for users, and the
time between this occurrence and August 4th left MapR clients up in the air.
However there is good news, as on August 4th Hewlett Packard Enterprise (HPE)
acquired MapR signaling a positive change. AtoBI customers can be confident
that MapR will continue to function and thrive. With support from MapR/HPE and
us here at AtoBI, there is no better time to start using this dataware and make
the most of your data capabilities.
We are pleased and excited to continue to bring this amazing
toolset to our customers, a toolset we know will continue to provide outcome
requirements. MapR will now continue to be innovated to match customer
requirements, and we are confident in the future of MapR for Australians.
Want to know more about our work
with MapR? Contact
us online or email us email@example.com to get in touch regarding MapR. AtoBI are
industry experts in business solutions, and together with AI technology we can
help you improve efficiency in all areas of your business.
Clients often come to
us to assist with their system upgrades. One of the key areas of discussion is
around what version should they upgrade to and when should the upgrade occur?
There are several
reasons why you may need to upgrade or apply a system patch/point release: take
advantage of newer features; keep aligned to vendor supported version; to
address a bug/issue with your current installed version;… Whatever the reason
is it is important that you have a upgrade strategy. An upgrade strategy should
address the software version that you are planning to upgrade to (eg, N or
N-1); the frequency of major releases from the vendor; the available window to
perform the upgrade in; the anticipated budget of performing the upgrade; the
recovery/roll-back strategy in case the upgrade needs to be aborted; what
system and user testing is required after the upgrade; communications to the
end users of the system upgrade and any actions required by them;…
First, the frequency
question. Some may say this is an easy problem to solve but what if the vendor
only releases one major release a year. Then if you adopt an N-1 policy for
updates then your system could be potentially two years old for your users!
Conversely if releases are five times a year and you want to adopt an N-1
strategy then you are potentially looking at five upgrades in a year. This may
become cost prohibitive for the benefit that you gain. Balance is the key here.
As a rule of thumb, you should perform at least two upgrades per year
approximately 6 months apart and away from any blackout window or other
critical processing periods.
The next question is
whether you should adopt an N or N-1 upgrade strategy. This becomes more of a
question around your confidence in the vendor to provide a quality release with
minimal bugs. We normally advise that you follow an N-1 approach assuming the
software vendor does several major releases a year as a starting point. If
releases are more frequent and the core of the software is stable and isn’t changing,
then you may consider following an N approach. Perhaps when there are
significant changes to the core of the software fall back to an N-1 release for
several upgrades and then go back to an N approach. Some clients may decide to
temporarily change from N-1 to N to take advantage of a new critical feature
that is in demand by the business.
Finally, should you
upgrade for minor/dot releases? The simple answer is no unless it fixes a bug
that your business is experiencing, provides additional security or provides a
feature that you need for your business.
You must not forget to
perform upgrades as you introduce risk to the business by not regularly
upgrading. Data and system security are often cited as a concern by not
upgrading but another risk is that you may be unintentionally holding the
business back by not taking advantage of new software features. System
stability is often stated as another reason not to upgrade which I feel is a
short-sighted view. When you do eventually upgrade you are placing a
significantly increased risk on the business post upgrade. The reason is that
the upgrade is no longer a routine business task, and this leads to the upgrade
potentially becoming a major project which will attract other risks and costs.
Not sure how to plan
an upgrade strategy, email AtoBI at firstname.lastname@example.org and let us help.
Simply put, it means data visualisations
seamlessly integrated into a larger environment, such as a company intranet
Traditionally, Business Intelligence (BI)
software has been self-contained applications that require installation and
training for users, making it a chore for them and increasing maintenance loads
on IT teams. This approach has always been a blocker for delivering answers to
business questions, since most users are too busy doing their jobs to go
hunting for data in slow, difficult-to-use software applications.
Embedding analytics into an existing
environment provides relevant, real-world and always up-to-date information to
end users in a place that they’re already familiar with. It does not require
users to go seeking data or to learn new software applications. Rather, it puts
interactive visualisations at their fingertips and keeps the important
information front of mind for them all the time.
Not only can embedded analytics provide high-level KPI data to users in a place like a corporate intranet, it can also be used to deliver complete solutions for users requiring detailed analytics tools. This entire scenario can be delivered in-browser and seamlessly integrated into the intranet.
Ease of use
Central location for all data analysis and reporting
Provides the same look and feel interface whilst accessing data from different
but how do we do it?
While the idea sounds large and very
expensive, it doesn’t have to be either of those things. AtoBI can rapidly
deliver solutions from small-scale visualisations in existing environments
right through to fully interactive, cross-platform analytics applications that
integrate data from multiple sources and deliver it in a web browser.
Because there’s no better way to start than a quote from one of the most iconic athletes of the decade, as Lebron James once said:
“You can’t be afraid to fail. It’s the only way you succeed. You’re not gonna succeed all the time and I know that.”
In the age of unprecedented information growth and data-driven businesses, it appears most Business Intelligence (BI), Artificial intelligence (AI), Corporate Performance Management (CPM) and other data-related projects will fail, or won’t fully reach their objectives.
Keeping in mind failure is a risk one can only mitigate, the question is:
How can organisations maximise their chance of success when selecting and implementing technology, and in the unfortunate event it goes south, how can they leverage failure to later generate higher value?
1- Engage with all key stakeholders
All data-driven projects, from BI to AI & Machine Learning (ML) aim at breaking silos of information within the business, consolidating data from various sources, building a 360° view across all systems, providing more context to support business-driven decisions. However, this is often seen through the technology lens and organisations also often need to break silos of communication. This can only be achieved with the support of senior management.
The Human factor is obviously critical for success/failure and must start from the very beginning. Engaging with all parties can be compared to an internal sales process:
Create win-win relationships
The first question that needs to be answered is: “What’s in for me?“
You want the Sales team to stop using spreadsheets for their monthly forecast because it’s error-prone, inefficient , and forces the Finance department to spend hours in manual data processing? Well, it’s only going to work if you also understand how it can provide value to them: helping negotiate better deals, answering customers’ questions faster, making more commissions… and balance with the perceived cost of change.
The Finance team needs a flexible budgeting tool because the planning solution managed by IT is too complex for ad-hoc analysis, what-if scenarios and instant queries (especially in times like monthly re-forecast or closing)? How can it be implemented with the support and in conjunction with IT, complementing their effort & investment rather than running under-the-radar, parallel processes?
Many Artificial Intelligence projects failed because they couldn’t link operational and strategic outcomes, provide clear value & ROI to front-line managers and employees.
Identify roles & responsibilities
Mapping key stakeholders, influencers, decision-makers, supporters, detractors… is vital not only to get the project started, but also to keep everyone engaged and accountable for the project outcome. I have seen projects where everyone from IT, Sales, Finance departments, both at operational and management levels were extremely engaged and excited at kick-off, but two months into the project failed to deliver due to the lack of clear responsibilities and accountability.
Common personas in successful projects are:
The Champion(s), who will get their hands dirty and learn how to translate the business needs into a technical language by mastering the technology. They will be the main interface between the organisation and the technology vendor/partner.
The Enabler(s), who will create bridges between all stakeholders, keep them engaged and mobilise resources throughout the project.
The General(s), accountable for the project outcome at a top-management level with the authority to make decisions and keep a strategic focus.
The Engineer(s), in charge of keeping the project compliant to the company’s IT standards & policy and providing the technical infrastructure.
The Customer(s), (I am referring to internal customers here: the end-users) who must provide consistent feedback and communicate back on how the project is adding value (or not) at an operational level. Their voice is not always audible or heard but determines the long-term success of any implementation.
2- Define clear outcomes
This can be a tricky step, because the impact of a BI/CPM/AI… roll-out is not always easy to quantify, i.e. “You don’t know what you don’t know”.
Measuring success is comparing the difference between where you were, where you are now and where you are planning to be.
It all starts with a purpose
Projects start with challenges to overcome. Artificial Intelligence and Machine Learning initiatives have a purpose because they will help increase customer satisfaction by 25%, automate the reconciliation process so the finance team can support the CFO with more frequent & in-depth reports, reduce risks of hospital acquired complications by half, lower inventory costs… Not because it can beat a human at Go or looks good on a resume.
Some organisations adopted AI and ML for the wrong reasons, or failed because they lacked to clearly articulate the use case correctly.
Like a new high-tech spaceship, BI, CPM or AI technologies only have a meaning when you know your destination and what the steps are to get there.
Success can be measured in both quantitative and qualitative measures. Automating the budgeting process might not increase productivity by an expected 20% ratio or dramatically change the outcome from what it was in the past, however, will help your Finance team spend more time on providing better-quality recommendations, prevent them from calling sick or burning out and improve employee retention. Providing high-tech, fancy instant visualisations and nice-looking dashboards, but less flexible than old Excel spreadsheets might actually bring low value to the end-users.
Short term outcomes and low-hanging fruit is tempting, but must also serve long term goals (Some companies still invest in legacy tools to solve immediate issues, which can hinder long-term initiatives) We can also measure value and set priorities by factoring Risk, Cost, Complexity…
Defining clearly your criteria to measure business outcomes and adjusting them constantly is your compass to success (or failure, which, in this case, will help you learn and adapt).
3- A project is not a one-off
Implementing a new BI platform is like learning a new language: you can only improve and realise how much value you can get out of it. Don’t think it will be over anytime soon: it does not end with the delivery of the initial scope but must build new habits, initiate new projects and raise further questions.
Walk before you run
We all know Apollo 11, but landing on the moon was only made possible because of previous Gemini, Mercury and Apollo missions’ successes, and tragic failures too. (If you like space and lessons of persistence, the Soviet Venera program also speaks for itself…)
Back to the good old motto “Think Big, Start Small, Deliver Quickly”, it is not about technology anymore, it’s about managing change, driving transformation across all parts of the business step by step. And rather than “change” which is a one-time concept, we should switch to a more accurate one: “permanent adaptation”.
It also means no failure is permanent, and not achieving success in the first place does not imply you can’t achieve your goals in the next phase. Preparing for failure is:
Taking acceptable risks
Monitoring and documenting your journey
Learning and adapting from your experience
Don’t be dependent
The relationships between internal and external stakeholders is also a journey. I like to relate it to the dependency cycle of Katherine Symor, later adapted by Vincent Lenhard, where relationships tend to constantly evolve from:
A dependence stage: The traditional, old-school BI approach where the business depends on IT or an external third party to provide them with analysis.
A counter-dependence stage: Finance, Sales… running their own parallel spreadsheets in reaction to the lack of flexibility and autonomy, without complying to IT processes (Excel)
An independence stage: Both processes co-existing separately with no synergy, but it is inefficient and the risk is that this doesn’t meet corporate expectations. Silos still persist.
An interdependence stage: IT and the business collaborating and leveraging each-others’ efforts (Self-service BI)
This means the way you manage internal stakeholders must change over time, but also how you engage with third-parties (vendors, partners, consultants…) from pure technology experts to trusted advisors who know your business/industry and provide value at another level without unhealthy dependence (technical, IP, commercial…).
4- Keep an open mind
Selecting a solution is not a 100% rational process (we’re just humans after all). But it can get close to it.
Starting with the Law of the instrument: “An over-reliance on a familiar tool or methods, ignoring or under-valuing alternative approaches. – If all you have is a hammer, everything looks like a nail.”
What worked in another environment, even very similar, might not always be applicable to the current one. Keeping an open mind means considering alternative solutions with a scientific approach and keeping out from personal bias.
Try before you buy
Would you buy a car without trying it first? (You might, but it’s taking an unnecessary risk)
Technologies are more and more flexible, agile and easy to use. Most vendors offer a trial version and there is no better way to gauge potential value by running a proof of concept.
Not only it will provide a better look and feel of the final outcome, but it is also a good way to evaluate the quality of your interactions with the vendor or partner. The difference between a POC and a full project is merely the size of its scope.