I recently spoke with QlikView experts Ian Crosland (principal pre-sales consultant) and Adrian Bereanu (senior consultant, SAP technologies) about how organizations can bring SAP data into their QlikView dashboards, analysis and reports. (See this related QlikView blog article.)

QlikView makes SAP integration possible quickly and easily with:

  • A certified connector. QlikTech offers an SAP-certified connector called QlikView Connector for use with SAP NetWeaver®. We use this connector to access data in traditional SAP transaction systems, SAP BW (data warehouse), and SAP reports and queries. We use ODBC when accessing SAP systems like Business One.
  • A field and table name mapper. A QlikView script builder maps the cryptic SAP table nomenclature to meaningful business descriptors. The script builder imports SAP metadata (table names and descriptions) and translates it into any language the organization has active in the SAP Data Dictionary. For example, the field "KNA1" becomes "customer master" and the field "VBAK" becomes "sales order header." When people who have worked with SAP for many years see this they say, "Wow."
  • Mind-blowing "Seeing Is Believing" events. In a Seeing Is Believing event that can last anywhere from one to five days, QlikView consultants go into a prospective customer's site and demonstrate QlikView applications running with the customer's real data. (See this related QlikView blog article about QlikView Seeing Is Believing events for SAP customers.) Consultants fire up templates showing commonly-used data (e.g., sales numbers), connected to 30 or 40 different SAP tables on the back end, and the customers' eyes light up.

With the QlikView Connector for use with SAP NetWeaver®, our script builder, and power-packed Seeing Is Believing events, QlikView can unlock SAP data and deliver business value in just a few days.

What are your experiences implementing QlikView in SAP environments?

We consistently hear from QlikView customers and consultants in the field that accessing data in SAP systems is significantly more difficult than accessing data in other kinds of back-end systems. To try to understand what's so hard about it, I spoke about it with QlikView experts Ian Crosland (principal pre-sales consultant) and Adrian Bereanu (senior consultant, SAP technologies). Ian has worked with SAP technologies for six years and Adrian for more than fifteen.

The main reason it's hard to access SAP data from non-SAP systems is technical complexity. Specifically, SAP systems have:

  • A proprietary interface. Most SAP repositories have a proprietary interface?exceptions include offerings like Business One, which is targeted at small businesses. You can't access most SAP repositories via the standard open database connectivity (ODBC) protocol.
  • Tens of thousands of tables. SAP repositories can have 50,000 to 80,000 tables depending on the degree to which the deployment has been customized.
  • Cryptic table and field descriptions. Table and field descriptions are abbreviations derived from the German language?not easily understood by most business users or even SAP technical architects.
  • Mysterious table locations. Some tables don't even exist in the underlying database; they only exist in the Basis layer (NetWeaver), where tables may actually be a collection of four or five other tables. An example of this is a table called BSEG (cluster table) within the SAP finance module (FI), which is only accessible through the NetWeaver layer.

Making matters more difficult, not just anybody can write a connector and put it on top of SAP to access the data in the repository. All connectors must be certified by SAP. In addition, SAP may place license restrictions on some customers that prevent them from connecting to the source repository with anything other than SAP software.

For information on how QlikView helps organizations unlock their SAP data, stay tuned for a related blog article coming out later this week.


Decision support systems should support a "build to think" approach by enabling people to run tests and create prototypes with their data (see last week's related blog article). I recently spoke about this with QlikTech technical advisor Elif Tutuk and I've got more of her perspectives to share with you.

Traditional BI tools do not support a build to think approach; rather, they force the opposite. With query-based BI tools, project teams spend weeks or even months "thinking to build" by creating a reporting system they hope people will use to get business insights. The resulting decision support system gives users no freedom to prototype, to come up with new ways to analyze data. With traditional BI tools, people cannot build to think?they cannot learn fast and reshape their perspectives quickly to rethink the how and why of new opportunities in the business.

Here's how QlikView supports a build to think approach:

  • QlikView users load millions of rows of transactional data into memory from a variety of data sources and immediately start observing. QlikView lets users analyze granular data with no pre-calculation or pre-aggregation.
  • With the associative experience, users can see relationships within the data. (See QlikView blog posts about the associative experience here, here, and here.)
  • Users select values and see which ones are associated as well as those that aren't. They use selections to refine their questions.
  • As they learn more, they move on to narrow their business questions, building metrics on the fly. They continue to use these metrics in charts to see patterns or catch outliers.
  • They gain insight into the root cause of an outlier on, say, a region-level chart, by selecting that data point. They then create another chart (say, at a product level) to understand the details. This is what we mean by prototyping new ways of analyzing the business.
  • They find unknowns hidden in the data and share these with colleagues using bookmarks and collaboration objects.
  • They determine that this new way of analyzing business data is very powerful so they move it up to the QlikView Server under the auspices of IT, to be used by all.

QlikView helps decision makers build to think, and do it quickly. Users can ask a business question, build a chart to find the answer, make selections to see associations, and change the chart or create a new one instantaneously. They can test and prototype, learning all the while, without taking their eyes off the data or interrupting their thought process.

For more insights by Elif Tutuk, see the May, 2010 podcast, "Delivering High-Value Analytics" and the May, 2010 QlikView PerspeQtive, "Think About Design When Thinking of BI."

In today's competitive business environment, organizations have to remain nimble, relevant, and responsive. Constant change is inevitable. Everything is dynamic. Business decision makers are challenged with coming up with ideas no one else has, just to survive and compete. These requirements put pressure on decision support systems to be highly flexible.

I recently spoke about this with QlikTech technical advisor Elif Tutuk. As a technical advisor, Elif helps QlikView clients and partners adhere to best practices for QlikView implementation and development. She joins projects in the beginning and works through to completion to ensure that customer satisfaction is high.

Testing and Prototyping Are Important Business Analysis Practices

Elif is a big advocate of design thinking?a creative way of solving problems or issues that looks at a wide range of solutions before selecting one approach. Elif has been putting design thinking into practice with business intelligence?with QlikView software, in particular?for the last several years. She worked for multiple QlikView customers before joining QlikTech as a technical advisor in early 2010.

One of Elif's strong views is that testing and prototyping are critically important in helping an organization be nimble and responsive.

  • By running tests, we can determine whether a new product or business process is likely to be successful, or examine key assumptions about how the business works. For example, a retail executive might want to know, "Why do some customers stop buying our product?" A doctor might want to know, "What treatments did this cured cancer patient receive?"
  • We can learn an enormous amount by creating quick prototypes?by "building to think." With prototypes, we create temporary solutions that teach us something and can be changed quickly to test new ideas based on what we have just learned.

Decision makers need BI software that helps them build to think, and do it quickly. They need a tool that is flexible and nimble and enables them to ask a business question, build a chart to find the answer, make selections to see associations, and then change the chart or create a new one instantaneously. Next week I'll be publishing a related article about how QlikView supports a build to think approach. Stay tuned! [Here's a link to the related post: "QlikView Supports a Build to Think Approach to BI."]

For more of Elif Tutuk's insights about design thinking and BI see the May, 2010 podcast, "Delivering High-Value Analytics" and the May, 2010 QlikView PerspeQtive, "Think About Design When Thinking of BI."

We get lots of questions from current and potential customers about how QlikView works with SAP?and why. After all, SAP offers business intelligence software of its own (SAP BW and SAP BI). I recently spoke with QlikTech principal pre-sales consultant Ian Crosland, who has lots of first-hand experience with both SAP BW / BI and QlikView implementations in SAP environments.

Ian gave me a peek inside the typical "Seeing Is Believing" proof-of-concept event he runs for SAP shops interested in QlikView. A Seeing Is Believing event is a 1-3 day event during which QlikTech demonstrates QlikView working in the prospective customer's environment with the customer's real data. Ian has conducted more than 25 of these events to date.

Our typical QlikView Seeing Is Believing event for SAP customers looks something like this:

  1. An SAP architect gives the go-ahead, often reluctantly, and agrees to load the QlikView Connector for use with SAP NetWeaver® onto an SAP test machine.
  2. Ian shows up bright and early in the morning, coffee in hand, and installs QlikView Desktop on the test machine.
  3. He runs a script builder in QlikView to translate technical SAP field names into useful business descriptions.
  4. The at-first skeptical SAP architect produces an SAP report, written in SAP's ABAP language.
  5. Ian sits down with the architect and analyzes the tables used by the SAP report. Ian gleans the relevant tables to be extracted and loads them in QlikView, keeping the existing calculations (e.g., margin and profit ratios).
  6. Ian builds analysis objects in QlikView to enhance the previously static SAP report. He shows how users can slice and dice the data and navigate their way through it using QlikView's associative technology.
  7. He tells a "100 reports in 100 minutes" story, showing how prebuilt QlikView business value solutions (templates) can contain more than 100 business answers. The prospective customer sees their own real data in these reports. After a little bit of training, users can modify the reports themselves.
  8. Finally, for good measure, Ian runs the QlikView SAP Accounts Receivable and ASAP Accounts Payable templates?which take 10 minutes each. At one Seeing Is Believing event, Ian identified that the company's biggest debtor was its own sister company?a previously buried insight.

In a Seeing Is Believing event, an SAP architect who was our biggest hurdle has become QlikView's greatest fan. SAP users previously had access only to static reports that took weeks or even months, and legions of consultants, to design. Now users have direct, hands-on interaction with their data. They can wander through the data, gathering answers to questions they may not even have known they had. On their own they connect the dots and identify outliers, finding new meaning in their data, without assistance from IT pros or consultants. (For more info about QlikView's associative experience see the related QlikView blog posts, "Unpredictable Questions and the Power of Gray" and "The Car Engine Analogy.")

Most business intelligence tools are good at answering the first question someone might ask, such as "What are my best selling products?" or "Who are my top customers?" or "What are the sales trends for my products or customers?" Some BI tools go a little further to provide clever ways of visualizing answers to questions like these.

Answering the initial question is not all that difficult, as evidenced by the number of tools that can do it. The tough part is answering the subsequent question based on the answer to the first question, and then the third and fourth questions, and so on. I'm not talking just about drilling down, which while useful does not go far enough. The greater difficulty is making it possible for business people to answer any question they come up with in highly intuitive and interactive way.
I talked about this with QlikTech's market intelligence manager, Tim Brain. He walked through a scenario showing how QlikView is designed to do just this: answer the unpredictable questions.

Imagine you're a marketing analyst who wants to understand where to focus your promotional efforts. The first question you want to answer is, "What have been my most profitable products so far in 2010?" Next, you want to understand which customers are buying these products. As you think it through you realize that what you really want to know is which customers are not buying them. You click your way through a QlikView document. You come up with another question: "Which of those customers who aren't buying our most profitable products have been active buyers in the last two months?" And there you have it: your list of customers to target in a marketing campaign.

Using insights gleaned in QlikView, you can begin putting together a campaign to target specifically those customers who are active buyers but who are not buying the products you need them to be buying. QlikView helped you find not just the associated data (highlighted in white), but the unassociated data (highlighted in gray).

The really useful answer is rarely the initial one provided by a report or a specific piece of analysis. We're not talking about a drill path; rather, we're talking about a series of related questions based on a set of data associations. With Qlikview, data associations persist as the user conducts analysis. QlikView works the way your mind works. It's intuitive and supports the natural flow of the insight discovery process, answering not just the obvious questions, but the unobvious questions as well.

One thing we're trying to do a better job of at QlikTech is communicating the associative nature of QlikView. I've seen lots of conversations taking place online (for example on the QlikCommunity site as well as Donald Farmer's blog and Curt Monash's blog). So I tapped into the brains of Dan English, our Global Product Manager for OEM and Integration for his explanation, and I'm sharing it with you here.

First and foremost we should clear up the semantics. If one uses the Wikipedia definition of an associative model of data then it is correct to say that QlikView does not store data in an associative format. However, QlikTech uses the word associative in an entirely different sense. When we say that QlikView is associative we mean that at a data engine level QlikView creates and maintains real-time associations among all result sets, creating a cohesive and intuitive view of business information.

We describe QlikView's architecture as associative to differentiate it from query-based business intelligence tools. With all query-based BI tools (whether ROLAP, MOLAP, or HOLAP) each individual result set is returned from the underlying data engine without any inherent association back to the data repository as a whole, or to any other query result set (see figure below).

When we say QlikView is associative, we aren't talking just about QlikView's intuitive user interface?the UI that utilizes green for selected data, white for associated data, and gray for unassociated data to illustrate relationships hidden in business information. (See this QlikView blog post.) We're talking about a revolution in data engine architecture, in that:

  • Every data point in a QlikView document shares a common selection state. With QlikView's data engine, each and every discrete data point in a given QlikView document?whether it is part of an aggregated result set (e.g., straight table, pivot table, chart, etc.) or unaggregated data (e.g., data in a list box)?shares a common selection state (e.g., universe of included and excluded data).
  • All data points are constantly updated based on the selection state. All the data points in a QlikView document are continually and instantaneously updated based on changes the user makes to the selection state. The associations among result sets are maintained 100% by the underlying data engine, which is built on a column-store, in-memory architecture.

QlikView's associative architecture delivers unprecedented flexibility

Why is QlikView's associative engine so important? One might argue that a real-time query tool gives you the capability to answer any question you want. After all, within the limits of the tool's user interface, you can define any result set you want, right? We maintain that the answers to real-world business questions are almost never exposed in the result set of a single query. Almost always the answer can only be extracted by examining the relationships of two or more associated result sets, often aggregated along completely different dimensionality.

The bottom line: QlikView represents a fundamentally different class of analytic engine. All associations are based on the data model set up when the QlikView document is developed. Those associations are used to update every single result set in real time each and every time the user changes the selection state. This is the source of QlikView's associative magic.

The Car Engine Analogy

Posted by Erica Driver Aug 13, 2010

In an earlier post, I wrote about why QlikView users have an emotional attachment to our software. In that post I gave a sneak peek into a white paper I'm working on with my colleague Dan English, QlikTech's Global Product Manager for OEM and Integration. Dan uses a great analogy to explain QlikView's associative experience.

Let's say the goal is to understand how an internal combustion engine works using digital models. With the query-based paradigm, we would look at individual parts of the engine in isolation. We would see one part at a time. We would be left to attempt to understand the relationships (or associations) among the parts and how the parts all fit together as a cohesive whole to create a working engine.

Using QlikView's associative technology, however, we now have access to a digital model of a complete working engine with each part in correct relationship to all of the other parts. We can tweak the throttle in the digital model (or execute a selection, in QlikView) and see how that affects the fuel intake, carburetor, and exhaust. We can watch the pistons pump and turn the crankshaft. We can deconstruct the engine at our leisure and look at each part in context with the parts next to it.

This is the power of QlikView. Instead of getting several separate answers to discrete queries, the way you do with traditional BI solutions, you get to see how those answers (like the engine parts) fit together, giving valuable context to make better, faster decisions.

Tim Brain, our market intelligence manager, shared some insights with me about the business intelligence software market. He's head the nail on the head about a couple of key points, and I thought I'd share them with you.

Erica Driver: What do you think is really important right now in the BI tools market?

Tim Brain: I would sum it up with one word: simplicity. Simplicity equals success. Customers want something that is quick to implement and easy for business people to use. These requirements have been difficult to address with traditional BI tools. The traditional tools rely on reporting and ad hoc query analysis which by their very nature are limiting and require time to implement. They ultimately fail to deliver the required end-user experience.

Erica Driver: Some of our competitors are big, formidable software vendors. What do you see as the stack vendors' weak spots?

Tim Brain: The stack vendors typically have grown through acquisition and offer a pile of disparate technologies. These solutions don't address the complexity problem. Their solutions are all query-based so they take a long time to implement and require complex skill sets. It takes a huge amount of time to join the data up.

Erica Driver: In that vein, what do you see as QlikView's main differentiator?

Tim Brain: Our main differentiator is the associative experience. QlikView makes it very easy for business people to search all relevant data quickly and easily. I consistently hear from our customers that we offer the most engaging experience of any BI tool out there. This is what drives the exploration, discovery, and refinement of what's really important in the data. With other tools, users just dabble. They might export data to Excel to do more analysis. QlikView allows users to conduct analysis right there in our tool. This is a breakthrough experience for so many of our users.

Erica Driver: How do you expect customer requirements to change, moving forward?

Tim Brain: I see requirements changing in a few ways. Demand is increasing for mobile device support. Customers want to integrate BI capabilities into other areas of their business. And BI is becoming more social. Stay tuned for more from QlikView in each of these areas!

I've been hearing a lot of talk about in-memory business intelligence lately. To shed some light on the topic, I am working on a QlikView technology white paper with my colleague Dan English, QlikTech's Global Product Manager for OEM and Integration. We're writing the piece to go beyond the simple talk of the in-memory architecture QlikTech pioneered and get into QlikView's most valuable differentiators. This morning I spoke with Dan about some of his ideas, and bring them to you here.

What Dan and so many QlikTech customers feel is the most special aspect of QlikView is the associative experience. In QlikView, when users look at any two data points they know precisely how these data points relate to one other. The associations exist among all data points in a QlikView application regardless of where the underlying data resides. If users want to narrow down their data selection to a single product or country or year, for example, they can see how every other data point in their analytic dataset reacts to that selection, instead of just affecting the individual query results they are looking at. Everything always remains in context.

As you can see in the video clip, when the user clicks on a data point in a listbox in a QlikView document, the entire dataset for the whole QlikView application instantaneously filters itself based on the selection the user made. The user's selections are highlighted in green. The values in other listboxes that are still relevant based on the selection are highlighted in white. Values that are excluded based on the selection are highlighted in gray.

Our associative architecture creates a living fabric of data, in which all the fibers are interconnected as an organic whole. As people use the software to find the answer to one question, they think of another question. They blaze a trail through the data, bringing some information into focus, examining it in a new way, and taking the analysis in a fresh direction. This is what makes QlikView so intuitive and "sticky." New QlikTech employees (like me!) are often surprised at how emotionally attached users become to QlikView for this reason. Nowhere else have users been able to achieve this associative experience.

Get ready to sing along, folks. Pull up the tune of Dire Straits' "Money for Nothing." Swap out "MTV" with "iPhone here" and you'll be all set. Here we go. "I want my, I want my, I want my iPhone here."

This is the story of the consumer enterprise. The word "consumer" literally means one who acquires and uses stuff. This is a bit different from what enterprise software vendors mean by the word. Enterprise software companies tend to mean "people when they are not at work," and the term typically has a technology ring to it.

The underlying premise is that there's "work technology" and there's "home technology." The trouble with this is twofold:

  • The boundary between work technology and home technology is blurry. Here's a first-hand example. When I joined QlikTech in early July, I brought my personal iPhone and iPad to the IT department and said, "Can I get my email on these?" Within 10 minutes, I had my company email and calendar on both devices. I went to the Apple iTunes store and downloaded QlikView to my devices, as well. And when I turned on my shiny new standard-issue corporate laptop I personalized it, changing default settings and installing tools that I like to think boost my productivity.
  • Every information worker is also a consumer. With this comes a consumer's sensibility about what technology can and should do. I have used dreadful software in the workplace, grumbling the whole time about the illogical user interface or clunky features. (Meridian mail, anyone?) And I have delighted in the experience of using technologies like Google search, iPhone/iPad, and iTunes. I want this same ease of use and fun factor in my work toolkit.

One reason why I am so happy to have landed in a product marketing role here at QlikTech is because the company not only recognizes these tensions, but has built its software product around them. QlikView breaks the business intelligence mold with software designed for what we think of as the consumer enterprise: workplaces made up of people who have consumer expectations about technology. For a brief look at what I mean, check out the "Introduction to QlikView" video we published a little while back.

Filter Blog

By date:
By tag: