Jet Reports es la herramienta para construir el mejor BI y de forma mas rapida

HAUNTING STATISTICS pg.2

THE WAYS OF THINGS pg.3

BI ISSUES CATEGORIZED pg.4

THE RISKY PART pg.7

WHAT DO WE DO NOW pg.10

Build BI Faster, Cheaper and Better

Those numbers seem unrealistically horrible. Yet, as an organization that builds and deploys BI environments for hundreds of companies each year, we work with IT groups and business users who come to us facing them all the time. This has been a longstanding problem with BI implementations and that is why Data Warehouse Automation (DWA) is such an exciting concept. DWA is a faster, better, and cheaper way to build a Data Warehouse. This is because technology is used to automate the entire data warehousing life cycle; from planning, analysis, design, and development, even extending into operations, maintenance, and change management. By using and adopting a DWA tool, huge efficiencies are gained and a tremendous speed advantage ensues.1

The DWA concept has a distinct parallel to manufacturing, where, about 100 years ago—thank you Henry Ford—we realized that there were parts of many processes that demanded automation. Time and money were saved immediately. Efficiency went up and product quality improved.

Building Business Intelligence (BI) is no different. The parts that demand automation in the Data Warehouse life cycle are the repetitive, labor intensive, time consuming ones like writing code by hand, performing QA cycles and documentation.

The idea behind DWA is that if you can automate these time-consuming tasks, then the project team can focus on the components that require more intellectual input than raw technological horsepower. Proponents of DWA claim that using it will accomplish an initial BI implementation up to five times faster than traditional methods. This results in a higher success rate for BI projects, and most importantly, it allows for faster, better, and more cost effective delivery of BI output to the business.

1DM Review & IDC Business Intelligence Survey, October 2006

A survey by IDC and DM Review Magazine gives us these haunting statistics:

► 17 months is the average implementation time for a BI project ► 5 months needed to deploy the first usable BI artifact► $1.1m is the mean, annual expenditure on a BI project for companies with more than 1,000 employees► 31% of BI projects are declared successful► 36% confidence rate that the right data is available to the right people at the right time

Data Warehouse Automation is a faster, better, cheaper way to build Business Intelligence.

Jet Reports | 10450 SW Nimbus Ave | Suite B | Portland, OR | 97223 | www.jetreports.com Pg. 2

http://www.jetreports.com

The way we were

One of the widely accepted pitfalls of traditional data warehousing methodology has been that building a Business Intelligence project is a long, tiring and expensive process. DWA offers a solution to that, and in fact, it has been doing so for several years now. The Data Warehousing Institute (TDWI), a think tank devoted to all things data related—and a great resource for education and training—started teaching DWA classes in 2014 and has included the technology as one of the emerging trends for 2015 and beyond.

Data warehouse automation will thrive: Data warehouse architecture and implementation has transitioned from an art to a science. When combined with the increasing demand for analytics and user frustration with delays, automation will drive the development of new and/or additional products to automate the data warehouse life cycle, including design, creation, operations, and change management.

That Was the Year That Was: Major Data Warehousing Events of 2014 (and Predictions for 2015) – December 16, 2014, TDWI.org

RISK

TIME

What this trend implies is that we can change the way we think about building a Data Warehouse. The expected practice of extensive up-front analysis, design, and modeling is left behind. The mindset changes from ‘get it right the first time’ to ‘develop fast and develop frequently.’

This shift enables business users to get what they are asking for very quickly, decide if it is right, and then move on to the next thing. It also accommodates change much better because it doesn’t force the development team to ‘lock down the code’ and declare: “No more changes!” Change is so easy to implement, it becomes part of the process.

TIME

MONEY

LABOR INTENSIVE

USER ADOPTION ISSUES

END USER WORK-AROUNDS

EXPENSIVE

LACK OF EXECUTIVE SUPPORT

LABOR INTENSIVE

USER ADOPTION ISSUES

END USER WORK-AROUNDS

EXPENSIVE

LACK OF EXECUTIVE SUPPORT



The way we want to be

Enough of the theory! Let’s go back to the scary statistics and use them to discuss the practical applications of DWA. Their root causes can be broken down into three major categories spanning technical, data and organizational issues:

Technical issues – building a Data Warehouse and set of OLAP cubes is largely an effort in writing masses of SQL code. Code is what moves data from a source system (like your ERP) to a target system (like a Data Warehouse). Code is used to define metrics, create data structures like product hierarchies, and conduct calculations both simple and complex. Building a Data Warehouse with manual code is time consuming, resource heavy and error prone.

For example it can take a skilled SQL programmer hours to move a single field from a source database to a target destination. You can think of any DWA platform as a code-generating machine. Instead of writing a block of SQL code, you can use a mouse click. That simple click generates a substantial amount of code which compiles in the background - in this case, a SQL Server Integration Services Transfer Package to move a field from the source database into a Data Warehouse. The same underlying tools and processes are used as if it was done by hand, but the difference is that it takes about a second to complete the operation instead of an hour, or more, of coding. The raw speed advantage is obvious, but since the process is programmatic, i.e.: done by a machine the same way every time, human error is eliminated, testing time is greatly reduced, and re-working the code to fix errors is not necessary. Time and money are saved, and results are delivered faster.

Human error is eliminated, testing time is reduced, re-works are not needed – results are delivered faster, time and money are saved.

USE master GO

SET NOCOUNT ONDECLARE @Kb floatDECLARE @PageSize floatDECLARE @SQL varchar(max)

SELECT @Kb = 1024.0SELECT @PageSize=v.low/@Kb FROM master..spt_values v WHERE v.number=1 AND v.type='E'

IF OBJECT_ID('tempdb.dbo.#FileSize') IS NOT NULL DROP TABLE #FileSize CREATE TABLE #FileSize ( DatabaseName sysname, [FileName] varchar(max), FileSize int, FileGroupName varchar(-max), LogicalName varchar(max))

IF OBJECT_ID('tempdb.dbo.#FileStats') IS NOT NULL DROP TABLE #FileStats CREATE TABLE #FileStats ( FileID int, FileGroup int, TotalExtents int, UsedExtents int, LogicalName varchar(max), FileName varchar(max))

IF OBJECT_ID('tempdb.dbo.#LogSpace') IS NOT NULL DROP TABLE #LogSpace CREATE TABLE #LogSpace ( DatabaseName sysname, LogSize float, SpaceUsedPercent float, Status bit)

INSERT #LogSpace EXEC ('DBCC sqlperf(logspace)')

DECLARE @DatabaseName sysname

DECLARE cur_Databases CURSOR FAST_FORWARD FOR SELECT DatabaseName = [name] FROM dbo.sysdatabases WHERE [name] <> 'RVR_FSA' ORDER BY DatabaseName OPEN cur_Databases FETCH NEXT FROM cur_Databases INTO @DatabaseName WHILE @@FETCH_STATUS = 0 BEGIN print @DatabaseName SET @SQL = 'USE [' + @DatabaseName + '];DBCC showfilestats;INSERT #FileSize (DatabaseName, [FileName], FileSize, FileGroup-Name, LogicalName) SELECT ''' +@DatabaseName + ''', filename, size, ISNULL(FILEGROUP_NAME(groupid),''LOG''), [name] FROM dbo.sysfiles sf; 'PRINT @SQL INSERT #FileStats EXECUTE (@SQL) FETCH NEXT FROM cur_Databases INTO @DatabaseName END



Data issues – data is messy. Any large data set is guaranteed to have gaps, errors, and duplications, among other atrocities. These need to be discovered, understood and rectified before the data can get used. This exercise often takes longer than expected because there is usually a need to combine several data sets in order to get a full view of company operations.

For example, combining CRM information (the date a sales opportunity was entered) with the ERP Financial module (the date a first invoice was posted) will give you sales cycle times and enable financial projections. Now there are two messy data sets to deal with, and in the real world, we usually end up dealing with many more.

A typical multi-database scenario involves trying to get data from various source systems to match. One system records a specific type of revenue transaction, but it may not be the system of record for the company, and as it turns out, has a different chart of accounts structure. In order for the revenue transactions to flow into the correct revenue accounts, a mapping exercise must take place.

If you were using traditional methods, you would need to write and maintain SQL code to handle this mapping. This is a great example of a time consuming, repetitive task, that doesn’t require human creativity and is better accomplished through automation. DWA software would do this with a single click – generating the code in the background – in seconds. It is the same for other field transformation tasks, scheduling jobs and generating documentation – all are candidates for automation.

DATA ISMESSY



Organizational issues – A shared vision and understanding about the data and the numbers must be created in order to deliver a BI product that business people will use. And this is often the hardest of all tasks. It is vitally important to get everybody on the same page about what data is important and how it is to be consumed. Everyone must understand and agree which individual pieces of data will come together to tell the story of the organization and, how it is operating. For example, it doesn’t really matter if gross profit is defined as Sales minus COGS, or if it is defined as sales minus COGS plus SGA. What matters is that everyone comes to an agreement on the formula.

Obviously, a piece of software is not going to create a shared vision. But, the ease, and speed, at which results can be delivered using a DWA platform can help. DWA allows you to quickly combine disparate pieces of data, take them through a complete BI development cycle, and deliver results to the business to see if it works. This exercise would be unthinkable in the traditional model because it would take weeks, if not months, to do. The potential time waste and failure would be catastrophic to the project.

With DWA, this can be completed in hours, and in essence, it allows you to fail fast. Results can be tested by business users immediately and changed quickly if they are incorrect. IT and the business users typically find themselves going through a collaborative process to design, build and deliver BI products.

That’s right, IT and the business users working together on a shared vision about data and how to make it most useful.

Maybe that is what is most intriguing about the promise of DWA: it is a technology that solves long standing problems and has a ripple effect into non-technology issues. It allows us to get to what is important from a BI project: the ability to respond quickly to changing business conditions. Business users are getting what they want, when they want it, as opposed to what they asked for six months ago. Rapid time-to-value is consistently realized since new BI and analytic functionality can be delivered in days instead of months.

The speed at which Data Warehouse Automation delivers results creates a shared vision.

Data Warehouse Automation has a ripple effect into non-

technology issues



And now: the risky part

Talking about non-technology issues, consider what DWA can do for the concept of risk. Every IT project has risk associated with it. Risk of failure. Risk of going over budget. Risk of low user adoption. In short, it is all about the risk of wasting money and wasting time. And time is a key component here because in a project with an expected completion date, risk goes up as time passes.

Business users have expectations that what is promised will be delivered. They need data in a usable format in order to make decisions. Accounts Payable must have accurate information on a daily basis to keep the cash coming in. Sales and Purchasing have to know what is in inventory to sell and replenish stocks. If these capabilities are not delivered as promised, you are procuring risk on multiple fronts. The risk of not having information to make decisions, or worse, making decisions on faulty information.

When you adopt traditional methods to build BI, here is an example of what happens: a team of consultants descends on your company and starts gathering requirements. These folks then go off and try to build BI that matches what they heard. This involves writing tons and tons of code, and it takes forever. Remember, IDC says it takes five months.

Finally, the consultants come back and deliver something. But since it is five months later, one of two things is about to happen. Either: a) what they deliver is wrong, and all that time and effort is wasted. Or b) what they deliver is exactly what you wanted – but that was five months ago, so now all that time passed and things have changed – it’s no longer relevant.



Here is an illustrated example of what is happening to “risk” all this time. It moves to the right and UP, with all kinds of unanticipated issues emerging:

In the DWA world, the technology part happens so quickly, it changes the way BI projects get built. The traditional requirements gathering phase morphs into more of a priority setting exercise. This happens because virtually any idea that comes from the business users can be put into effect without a monster effort. Business users’ needs are collected, prioritized and then ‘time-boxed’. This means that priority number one is evaluated and an estimate is given for how long it will take to build – a day, five days, or 10 hours. Then, the developers don’t disappear into a dark room and start writing code, because, they don’t have to. That part is automated with DWA. What they do instead is to start delivering: priority one first, then priority number two, and so on. At Jet Reports we call these iterations, and we can start delivering BI products to the business in days – financial reports, sales dashboards, aged AR, etc.

RISK

TIME Requirements gathering Testing User validation Delivery to business Re-work Delivery to business Repeat

Consumption of resources

Dead time

Managing user expectations

Userdisappointment

End user work-arounds

Data integrity issues

User adoptionsuffers

Data integrityissues

End userwork-arounds

Lack ofexecutive support



You can think of each delivery cycle as not only short, and quickly followed by another one, but also as its own, individual event. Its success or failure does not depend upon, or affect, any other delivery cycle. This means that business users can begin using the first, most important deliverables as soon as they are ready, while eagerly waiting for the next set to land in their laps.

Time is saved because technology allows us to do things differently.

Risk is mitigated because delivery of value happens rapidly and frequently. The ‘deliver fast, deliver often’ approach ensures that the BI solution is constantly aligned with the needs of the business.

Shorter implementation times, faster delivery, and easier maintenance mean lower costs and a quicker return.

Because of the way it generates mountains of SQL code with the click of a mouse, DWA lets one person do the work of five. It allows you to stop paying people to do something as mind numbing as writing SSIS scripts. Most importantly, it puts information into the hands of business people five times faster than before.

RISK

TIME Conversationwith

businessusers

Deliveryto

business users

Conversationwith

businessusers

Deliveryto

business users

Conversationwith

businessusers

Deliveryto

business users

Now look what happens to that risk curve. Instead of going to the right and up indefinitely, you have small blips that span only days or weeks – not months.



What do we do with all this automation?

DWA allows BI teams to forget about the laborious, time consuming, hands-on work, and focus on the ideas. More time is available to work with the business users to find out what information will really make a difference. What KPI’s do they need to catch a trend early? What process change will cut days out of their reporting cycle? How can corporate data be used to save the company time and money?

In fact, DWA will likely cause you to stop thinking about IT and business folks as two different groups. They end up in the same room so often, talking about results, that they start to form a cohesive team with a collaborative view.

Instead of stark and abstract requirements gathering sessions with a long wait time afterwards, you have workshop style meetings where business users are talking and their ideas are being turned into reports and dashboards right in front of them. This iterative style of building BI turns the task of maintenance into a continuation of development. Since it is rare that anybody really knows 100% of their requirements, this method supports the uncertain and changing reality of the business world.

That is what DWA is – not just a better, cheaper, faster way to build a Data Warehouse. By its very nature, it changes the way we work. Like true innovation should, it builds on itself to transform our habits and our way of thinking. It changes the things we focus on – we focus on business issues – not technology. It inspires productivity and it produces results.

Data Warehouse Automation can change more than the way you look at your business, it can change how you do business. If you would like to know more about taking the first step towards effective change and tangible BI results quickly, reach out to us here at Jet Reports.



Your Author:

Jonathan OeschLoves ERP, Loves Data. Loves what happens when data from a transaction processing system gets turned into usable information that people can rely on; “It’s like that chemistry lab in college where you walk in with your raw supplies and leave with a perfectly round rubber ball.”

VP of Business Intelligence at Jet Reports. Speaks, writes, blogs and tweets about BI strategy – sometimes in his sleep.

[email protected]


Jet Reports provides robust, easy-to-use reporting and Business Intelligence solutions that empower business users across the globe to make informed decisions.

► Proven solutions – used by over 100,000 users worldwide.► Support you can rely on – renowned customer service.► Empowers users – Training to match every learning style.

mailto:jono%40jetreports.com?subject=


Date post:	15-Apr-2017
Category:	Technology
Upload:	clara-camprovin
View:	232 times
Download:	0 times

Jet Reports es la herramienta para construir el mejor BI y de forma mas rapida

Technology