I believe a key to understanding how information moves around your organization is to think of it as a mini economy. (I know, the economy is not our favorite subject right now, but bear with me).

There are information suppliers, and information consumers. The consumers are willing to pay more or less for different types of information, and different methods of supplying information have different costs. In the end, the market decides what gets done and what does not get done.

And like many markets, there is also a underground economy- places consumers go if the official prices don't make sense, or the products they want are not available on the open market.

In many companies, the IT department in theory has a monopoly on information supply, however the underground is active and constitutes a significant supply. The underground in this case is all the excel spreadsheets, the MS Access databases etc. used to make the shadow systems and spread marts. Spreadmarts seem to exist in the majority of enterprises- I've mentioned an interesting study regarding these shadow systems previously, and the attitudes people have.

To help illustrate this I am going to make up some data and put it in colorful graphs.

Looking at the first graph, in broad terms a data warehouse based approach will have higher costs than one based on data marts (because data warehouse provide more cross enterprise integration, which requires more effort), and the spreadmarts will have the lowest perceived cost. It's important to note that the actual cost of spreadmarts are higher, but percieved cost is what drives the consumers choice.

The trick is that because the percieved cost of spreadmarts is so low, and because there is no sanctioned enterprise solution to compete, a significant amount of effort is put in to these systems for any type of analysis that is percieved to be possible. Of course for certain data volumes or complexities there is no alternative to a full fledged data warehouse or data mart project, but for almost everything else, business users and analysts will often try to go it alone creating a chaos of spreadsheets and data bases.

The problem is, even "experts" can't accurately estimate how much effort the data analysis is. So estimates for how long it will take to "whip it up in excel" by non-experts are almost always low by orders of magnitude.

Don't dictate. Engage with sanctioned tools that work the way people want to work.

The key to adjusting this market imbalance is to introduce a new sanctioned product line, in effect undercutting the "black market".

This is exactly what self serve data transformation is about. Rather than leaving users to do it themselves in Excel- IT can provide specific tools, and thereby reduce the amount of completely opaque data transformation going on, while still providing users with the ability to get what they need.

So why is that better?

• It opens up the dialog - Talking is better than having a "Us" vs "Them" mentality. It lets you meet the people involved, lets you discuss their challenges with them, and provides an opening for discussion of important topics like data quality, master data management and data security.
• You'll know who the power users are - Right now, it is potentially anyone who has Excel- chances are that's everyone in your organisation.
• It gives you visibility on what matters to the business - If you know what the hot topics are, it can help you keep the official systems relevant and prioritize your efforts where they will do the most good.

What has to be different in this new relationship, however, is that IT has to understand about the "self" in self-serve. People will do things that no self-respecting ETL developer or data warehouse architect would ever sanction. If you clamp down and stop them, they will abandon the tools and return to the wild west. IT believes that it has the power in the relationship, but in fact the users are able to walk at any time. So add value, communicate, educate, but don't dictate. If your relationship with the business users, and the "Kings of the spreadmart" is poor to start, you have to give it time to evolve.

"But we just can't let them do that."

Resist the urge to clamp down.

Keep your systems secure, guard your infrastructure, but don't have any illusions that you can stop people from analyzing and transforming their data.

If they want to calculate net sales in a particular way then they'll do it in excel, and it will be the number that the CEO sees. The business is made up of grownups, after all. IT has a responsibility to explain the issues and challenges that shadow systems and rampant spreadsheeting can cause, but I have yet to see or hear of a company where an authoritarian approach works. As Princess Leia said- "The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."

Arming the rebels

The business intelligence vendors are all realizing what the crowd pleasers are- really good integration into office applications, excel at the forefront. People want at their data.

Microsoft has of course long provided the main weapons for the shadow systems, MS Excel and MS Access- and they are going nuclear with the addition of "Power Pivot" to Excel 2010- although it is largely a presentation layer tool, and probably won't be used widely for data transformation itself.

Trying to fight all this with the standard tools of closing down the ability to export data, hiring an army of report writers, and constantly raving about the dangers and pitfalls of run away spreadsheets is like pushing on a rope.

Provide a safe, legal alternative to the free for all.

Talk to your business users. Understand their needs. Provide them with tools. Work with them to both empower responsible analysts, and avoid the worst issues that existing shadow systems are creating.

Here's the secret- If you answer yes to all of the following its probably a good idea to buy:

• You've configured your Enterprise Resource Planning (ERP) software exactly as the vendor who wrote the data warehouse or data mart expected you to.
• You use ALL the modules of the ERP- and do not have any "best of breed" applications for any areas.
• You are interested in the key performance indicators that they have included and they calculate them the same way your company does
• Your end users like the layout, formating and color choices in the reports included and have promised not to ask for changes.

In fact if all this is true, then you will probably save HUGE amounts of money by using a pre-built package.

But. Lots of things tend to get in the way of that dream. More often then not it's not the pre-built package that needs to be focused on- it's what you have in your system and how you've configured it.

ERP Customization

Anyone who has been involved in a large ERP project knows that there is always at least a bit of customization. If the ERP is a good fit to your industry, and the project is focused on avoiding customization and using all those "flex fields" and "category codes" as they were intended, then the pre-built data warehouse that is available for that ERP might be a very cost effective route.

But here's the rub; in many ERP projects rather than change the existing processes (which by the way is often the justification for installing an ERP- process improvement), the business users find reasons to "keep things as they are"- and as a result, the ERP bends to the existing process rather than the other way round.

This means that new tables are created to hold information that normally would be in a different format in one of the standard ERP tables. This means that that code in field "X" that normally would mean something is overloaded to mean three or four things. This means that field "Y" that isn't needed by your company ends up being used for something completely different.

Well, when the pre-built data mart plugs into your ERP, it doesn't know anything about those tables you've added, and its assuming that the data is in the standard tables. Its already configured its ETLs, and star schemas to use those two fields that you've high-jacked, and so all those reports and cubes don't make any sense without modifications.

To be fair, many of the pre-built data warehouse frameworks have evolved to have lots of flexibility and configurability in them- you can modify and map the ETL jobs provided to fit your data. You can turn off KPIs so that they don't load in false data.

But the trick is the more you have to modify, map and configure, the more effort you spend. The more you shut off, the less you have. In the end you can find that you are always trying to fit your specific requirements into the general, vanilla requirements that came out of the box. Often, this configuration is more effort and demands more compromises than just building what you need.

Non ERP transactional systems

In some ERP implementations, certain modules of the ERP are not used and instead a third party software provides the functionality. Often, key information is then moved in and out of the ERP as required for transactions via an enterprise application integration (EAI) tool. In many cases, the reason the additional system is used is because it has more functionality (and therefore stores more detailed and varied information) than the ERP module. As a result, the EAI tool cannot move all of the information into the ERP, only summaries and selected data. This means that for the functional area that is treated by that module at least some of the detail users are interested in does not exist in the ERP. And if it's not in the ERP, it won't be picked up by the pre-built solution.

Diverse and specific report requirements

Its amazing how the layout (column order, summarization, which key performance indicators where) of a report can be very very important to report consumers. Its also amazing how much work can be required to modify the hundreds of reports and cubes that came with the pre-built system. Report writers everywhere are nodding their heads. Enough said.

Data Quality Issues

Even if you've used all the tables and fields in the ERP exactly as needed, and the reports look just fine to your users, if they have not already been given access to all this information you will probably find that there is lots of data quality work to be done. This cost is there for both the build and the buy options- just be aware of it, because it means the buy option is going to be more than just the sticker price.

One ray of hope- very specific industry solutions

Hold on, the vendors say, but we have industry specific data warehouses and data marts- these are built just for your industry so they know your business. We have one for banking data marts, another one for pharmaceutical data marts, you can get a sales data warehouse specifically for retail, and so on.

Without a doubt the more focused the pre-built data warehouse or data mart is the more likely it is that its going to save you time and money.

Conclusion? Often when something sounds too good to be true...

The bottom line is, although you can tell I'm not head over heals for prebuilt datawarehousing, I think the field has evolved. But then again, so have the prices.

The key is to be realistic regarding how much modification will be required now, and going forward, and how many of those hundreds of cubes and reports that are included are actually going to be applicable to your business.

It is possible that a package exists that will provide the best value. Just be very very careful when you are comparing the costs- because its never quite as sweet a deal as it first seems.

Smaller, very focused pre-built data marts, particularly targeted to applications or modules that are used fully by an enterprise are probably much lower risk and more likely to provide real value than a massive "out of the box, install it in weeks not years" data warehouse.

My personal experience with pre-built products was that in the end, when the dust settled, we had touched almost every ETL job, and the reports that were the most used and useful were ones we had built from scratch, largely using data loaded out of custom ERP tables.

If you have customization in your ERP, you have to think hard about this. The reason the custom tables were put in there was because they hold information that was important enough to justify the development. This probably means that the information in them is going to be important to the business intelligence you are building.

This survey, published by the business application research center, reports that although your BI vendor might be telling you that baseline adoption is 20%, it turns out it's a lot less.

In any given BI-using organization, notes Nigel Pendse, a principal with BARC and the primary architect of BI Survey, just over 8 percent of employees are actually using BI tools. Even in industries that have aggressively adopted BI tools (e.g., wholesale, banking, and retail), usage barely exceeds 11 percent.

I have to admit that the around 10 percent didn't surprise me overall, but I was expecting that in those particular industries they would be much higher- i.e. even higher than the 20% figure that big BI has been telling us for years. Not having worked in retail or banking directly, I just assumed that they were all glued to their reports and cubes.

The article goes on to say that some indicators show that adoption is actually falling slightly. All this while the mega vendors have been focusing their message (and supposedly the capabilities of their tools) on "BI for the masses" and "self serve business intelligence".

So what does this mean? Well, maybe it means that all those people who are frustrated by their big business intelligence, are disappointed at how few people are actually using the reports, and are wondering how the other companies do it should know that, well, on the whole the other companies don't do it either.

On the other hand, maybe the "right" number of people using business intelligence is 5%. Maybe in some industries it's three people at head office and thats it. In other cases it might be that the target should be every single employee using BI every single day. I think in the end the ever useful "it depends" is in play here.

What I do believe, however, is that big business intelligence is broken (I'm talking about the mega vendors). If it's not completely broken, then it looks broken and everyone is talking about how it's broken. Which is just another form of being broken.

I wonder what would happen if we looked at the adoption rate for Microsoft Excel for data analysis? Going out on a limb here, but I'm betting it's more than 8%.

People vote with their behavior. Obviously, its not all doom and gloom, and it is possible to have a highly successful business intelligence deployment. In a former life, I had issues making sure we had enough funding for Cognos licenses because certain cubes were so popular that we had more demand than supply. But I've also looked at log files for entire data marts that were flat out empty. Hundreds of reports built and maintained without users.

What makes BI successful

Generally, the key difference wasn't the tool, or the features, it was the content. Data warehouses and data marts that had been driven by the business and were focused on what the business wanted to see, in the way they wanted to see it were successful. Projects that were technology focused, run by IT and did not have the needs of the end users anywhere on the map would end up doing nothing but consuming cash and data center space.

It simply does not matter if the report takes 2 seconds or 2 hours to generate if it is not important to the business and there is no decision to make after seeing it.

Big business intelligence seems to think that BI for the masses is a tool problem- something in how their portal works, or how many rows of data per second their appliance can process. Sure, if the tools are hard to use or learn, it's a factor, but I think more often than not business intelligence isn't used because it's not providing what is required.

There are a lot of very talented business intelligence professionals that work very hard to deliver the goods, and there are lots of very successful business intelligence projects of all sizes that create real value. But the whole industry needs to take a hard, honest look at where we've come from, where we are going, and be honest about who is using what and why.

Often, people use excel because last week they didn't know exactly what they needed, and it is a tool that lets them build it themselves this week when the boss wants the answer and there is a decision to make. With all its flaws, it's still the most adopted Business Intelligence tool in the world.

Should everything be done at lightning speed? Is it really never possible to know what analysis is needed and use a traditional business intelligence approach to creating it? Of course not.

But are there some types of analysis that need to be done very quickly? Yes. Should we as an industry ignore these, or "leave that to the users in excel". I don't think so.

I'm spending all my time building a self service data transformation tool because I believe there is room in the overall architecture for less formal and more creative, ad-hoc tools. Excel is the ultimate in informal (often far too informal). At the other end of the spectrum, a carefully run, tightly managed data warehouse project is the ultimate in formal (and often is overkill, hopelessly expensive and too slow for a rapidly changing environment).

I'm looking at the middle ground where we meet the users part way, and nurture capabilities to do rapid prototypes, one-time analysis and user driven data transformation. Not as a replacement for big BI- but as another tool in the tool box.

The first one talks to the question of what the perfect BI tool is- answer? One that people actually use. The second uses a story to illustrate that many uses of information to make better decisions are business intelligence- even if one of the Mega tool suites isn't used, and there is no massive data warehouse in sight.

Both of these blog posts remind me of my days in the business intelligence supply side of a large organization, where I was tasked with creating, maintaining and evolving the "official" business intelligence systems. Anytime I gave a presentation to end users (often a demonstration of a new tools capabilities and power) the same question would always come up- Can we export data into our spreadsheets?

Everytime I showed an export to Excel functionality, the release of tension in the room was noticable. Everyone relaxed. They could get their numbers out, they could take charge themselves, and could get the information they needed. We worked hard to try to provide the functionality in the core systems, but the reality is that the needs of the users changed, often more quickly than we could make our massive databases, ETLs and SQL structures evolve. We were beholden to our change management procedures, we had to analyze the impact of changes on the whole.

At times, it was suggested that we "crack down" on the proliferation of spreadsheets and home made MS Access databases that sprouted when a need couldn't be met by the main system. But the reality is, the best solution is to work with the analysts- provide them new tools, understand their needs and don't rule out solutions just because they do not follow the "standard" business intelligence methodology of servers, big integrated suites of tools and rigid IT department involvement.

As with all things in life, balance between the "proper" way to do things, and a pragmatic approach that values individual initiative and results is important. After all, it's the only way what is "proper" can ever evolve and improve.

Microsoft Access has a clear role to play when a small, light database application is required. However, it has a learning curve, and is not necessarily the best tool for data analysis.

Product Segmentation Query Example

Lets look at an example ms access query or two and see how we can do the same thing Datamartist, only without the queries and without any SQL. For this example, lets say that we have two sets of sales data from different time periods, and a product list, and we want to define some product segments based on color and price. We want to get a summary of the sales Qty and average price sold by month, broken out by the new categories which are as follows:

• "Red and High Priced" If the product is Red and its minimum price is more than $1000
• "Red Low Price wide price range" If the product is Red, has a minimum price less than $1000 but has a min to max price of more than $200
• "Red Low Price small price range" If its Red and not in the first two segments
• "Yellow" if the product is yellow.
• "Other" for all the rest

The three data tables we have are as follows:

1. Sales 03-06 with about 120 000 rows, which contains sales data from 2003 - 2006
2. Sales 2007 with about 30 000 rows, which contains sales data for 2007
3. Products which contains the colors for all the products and their minimum and maximum prices

So- first step is to combine the two data tables, in Access, this is done with a UNION query with the following SQL code:

select * from [Sales Data 03-06] UNION select * from [Sales Data 2007];

In Datamartist, we simply connect the two tables up to a combine block.

Next, we need to define the segmentation- again in Access this is done with a Query, this time by nesting IIF statements to add a new column called "Product_Segment" to the resulting query.

SELECT Products.Product_ID, Products.Product_Name, Products.Product_Group, Products.Product_Category, Products.Product_SubCategory, Products.Shipping_Weight, Products.Color, Products.Price_Min, Products.Price_Max, IIf([Color]="Red" And [Price_Min]>1000,"Red and High Priced",IIf([Color]="Red" And ([Price_max]-[Price_min])>200,"Red Low Price wide price range",IIf([Color]="Red","Red Low Price small price range",IIf([Color]="Yellow","Yellow","Other")))) AS Product_Segment
FROM Products;

In Datamartist, we use a segmentation block to do the same thing. The interface is graphical, and the syntax is the same as you would use in Excel. There is no need to nest any IF statements, because the overall block is designed to do that. Heres what the blocks look like- the MS Access import block on the left, and the segmentation rule block on the right.

Each segment has the statement that defines if a row is in the segment or not. The block tests each segment rule in order, starting at the top- the first statement that solves as "TRUE" defines the value for the Product_Segment column for that row. Dragging the segments up and down changes what order the rules are checked.

(Click to Enlarge)

Then we have to Join this new product dimension (with the segmentation column) to the sales data, and summarize.

In MS Access, this is done with more queries- Heres what Access looks like when we're done.

Compare that list of Tables and Queries to the visual, left to right layout of the Datamartist data canvas that does the same thing. Without ever having to write any SQL code:

The VISUAL way to do it

In Datamartist you can see the flow of the data, the row counts are clearly displayed, and clicking on the connectors will bring up the underlying data set in the data viewer. Its clear which block feeds which, and by adding more blocks and connecting them at the desired point in the data flow, new analysis can be created.

Take Datamartist for a trial run- download it now because maybe you don't have to learn microsoft access queries after all.

So the idea of self serve business intelligence is a wonderful idea- the problem is that its not all about pretty graphs and fancy web user interfaces. You need to somehow design the data model so that every possible report that users dream up is possible- or move so much data modeling functionality into the report writer that it ends up looking more like a data transformation tool, yet is easy to use. There are "new" techniques that are getting lots of discussion- columnar databases are one, and certainly they provide interesting techniques, but only IF you've got meaningful data.

Here's something to try- call up your favorite Business Intelligence vendor, and ask for a demo. It will be wonderful, it will be clear, easy, and simple- and it will be done on a set of data that was made by someone who knew exactly what the demo was going to be.

Real world data is messy, and it often does not follow simple rules. As a result, it takes significant work to build analysis- and to have a system that is ready for ANY analysis that any user might think up at the moment is non-trivial.

But its a worthy pursuit. And I think there are three key fronts in this battle;

1. Reporting and Analysis front end tools
2. Data transformation and integration tools
3. Fixing the source systems.

All the big players have integrated suites of products that perform the functions of the first two categories- IBM/Cognos, Oracle, SAP.

There are also lots of very interesting new tools in the first category- Tableau is one that gets a lot of buzz. Of course, the king of graphing and dashboarding is still the spreadsheet, and Excel has the crown.

There are lots of tools for the IT department in the second category. Datamartist is a unique new tool for the end user in this area- a self-serve desktop tool for data transformation. It is a tool that allows users to quickly transform data sets to experiment and create new analysis that can then be queried and viewed using the tools in the first category.

But in the end, I think the number one limiter on achieving the dream of self-serve business intelligence will be getting a handle on the quality of the data in the source systems. Garbage in means garbage out- and the last two layers shouldn't have to tie themselves in knots trying to fix issues that are generated in the transactional systems.

But they do tie themselves in knots- and it is those knots that stop users from more freely and accessing their data using an intuitive and almost brainstorming approach- which in the end is the goal of self serve.

Unless the underlying data in the source systems is quality controlled, and designed to capture the information that is critical for analysts, then the Business Intelligence layer will have to work too hard to "fix" the data, keeping a large IT team busy writing code, and there's nothing self serve about that.

In the end, the data quality issue is often what makes data warehouses and data marts so expensive to build- and drives users to spreadsheets or even databases (microsoft access is a common one). This is what I call "self serve data transformation"- and this is what Datamartist does- if you're frustrated with the access you have to your data- download it and give it a try.

Knowing this, it's not surprising that a huge amount of data collection, extraction, and transformation happens in Excel spreadsheets, or Access databases that are made without the involvement (and often under the direct scorn of) the IT department in large companies. In my previous life I was in the IT department, and I saw some amazing systems generated with hundreds of spreadsheets and databases. This mix of spreadsheets and databases, created without the involvement of the IT department by power users or external consultants (financed out of departmental budgets) are often referred to as Spreadmarts or Shadow Systems.

For an interesting survey on the subject, take a look at TDWI's report "Strategies for Managing Spreadmarts: Migrating to a Managed BI Environment". This report is now a year old, but I'm certain as valid as ever.

The title suggests that the solution is managed BI- I won't get into that right now, but you'll notice the study was sponsored by the likes of Microsoft, Cognos, Microstrategy and SAP- so of course the solution is Big Business Intelligence solutions.

But what's really interesting from the survey, is how the different groups within the respondent companies feel about spreadmarts and shadow data systems. The analysts love them, the executives are unsure, and IT hates with a passion. This makes for an interesting mix.

This is very much what I've seen in my experience. IT and the Business are at odds with each other, and senior management is either disinterested or forced to take sides.

Where do I stand? I'm in the "avoid them if you can" camp when we're talking about a tangle of spreadsheets and undocumented MS Access databases that can be error prone and time consuming. I understand why it's often unavoidable, but I've seen first hand how painful these systems are to maintain.

On the other hand, I don't subscribe to the school of thought that says "Excel needs to be eliminated- analysts should use the Business Intelligence systems only, otherwise there will be chaos." Let's not go overboard. Excel and spreadsheets are useful tools, and have their place. Additionally, I really feel for business users who simply can't get what they want from the IT departments. I used to be the IT department, and it was frustrating to not have the resources available to build what people needed.

As one of the authors of the above report, Rick Sherman, said in a recent podcast:

"reality is no matter how many IT folks that you have in your company you're not likely to have enough resources or time to meet every business users reporting or analytical requirements..."

He presents what is a refreshingly balanced approach to Excel. In his predictions for trends in 2009, number 5 is "Excel becomes an accepted tool in a BI portfolio". He points out that this may not be mainstream in 2009, but I hope he's right about the trend. A pragmatic, inclusive strategy with more power to the people while avoiding the chaotic side of spreadmarts is where the solution is.

With data marts (just like leasing a car) you get behind the wheel quickly, and it gets you where you want to go in style.  And the monthly payment is something you can afford now.  However, long term, well, in three years you don't own it, and have paid a bundle.

But let's be realistic.  Just as having all the cash on hand to buy the car outright just might not be in the cards,  a true data warehouse might require a very significant outlay before anything comes out the other end, making it unaffordable.  A quick, focused departmental data mart could be delivering value in a matter of weeks with relatively little investment.  (Your actual mileage may vary- depending on where you're at, its always dangerous to believe someone when they say "a matter of weeks" when software and people are involved.)

Will that departmental data mart, or even a number of data marts lead you to a single version of the truth?  Will it give you deep competitive advantage through a culture of data analytics and cross enterprise master data management? In my honest opinion, No.

But is it something you can afford in today's economy, and will you learn things about your data, your company's information culture, and your business that will be useful if in the future you embark on a true data warehouse initiative.  Yes.  Yes it is, and yes you will.

And I'll take it one (blatantly promotional) step further.  Is a personal data mart on your desk top as good as a full fledged departmental data mart with an army of highly paid developers maintaining it?  Probably not.

Is the personal data mart on your desk basicly free in comparision to the servers, software and hired help the data mart requires?- Yes. And does it, just like the data mart does for the data warehouse, prepare the ground for the next evolution when the economy turns around? Yes. Yes it does.

In difficult times companies that are pragmatic, and do what is possible, preparing for the day when more will be, survive to see that day.

It seems obvious that doing nothing because you can't afford to do the best thing is a bad strategy- but we need to ask ourselves, how often do we make that exact choice through inaction?

Why do so many people turn to Excel for their analysis needs? Because with excel they are in control.  With Excel it IS personal. Massive, expensive data warehouses are one size fits none. Excel is the ultimate in customisation. 

“Despite years of investing in BI, many IT organisations have difficulty connecting BI with the business, and to get business users fully involved and out of the ‘Excel culture’”
- Bill Hostmann, Vice President and distinguished analyst at Gartner

Excel isn't always enough

Many users frustrated by the limitations in Excel in terms of data volume and functionality want more.  Some of them take up programming macros- others spend money they'd rather not on throw away database development.  But demand encourages supply, and new tools are beginning to emerge.

As Ted Cuzzillo put it so well in his trends for 2009 blog post recently:

“on business desktops, new, highly individualised tools will sprout.”

The Datamartist vision is that of a user driven tool that provides the flexibility of a spreadsheet with the key functionality of a database without the database. 

Personal data marts can for the first time be built directly on the desktop, without programming, yet handling millions of rows of data, and implementing truly useful data analysis.

An Extract, Transform, Load (ETL) tool is an intermediate software application that extracts the data from the source system, transforms it (often another way to say it FIXES it) and then loads it into the destination system. They are also very expensive.

The destination system is usually a data warehouse or data mart, and most of the ETL tools available are server based.  The ETL tool and related development is key to any any data warehouse project (and represent a third or more of the cost on a typical project).

Although most ETL tools use a visual interface of one sort or another, at the core they require programming skills and specialized knowledge. Google "datastage training" and you'll see that there is an industry grown up around learning how to use these tools.

But there's nothing magical about it. If you ever made a spreadsheet with data from multiple sources, transformed the data, and then either made reports or moved the data into another spreadsheet then you have made (or most likely were an integral human part of) an ETL. The problem is that out of the box tools like Excel and Access are so flexible, that too much is possible.  Where to start?

The amazing thing is that EVERYONE needs ETL functionality, yet overwhelmingly the tools available are expensive, hard to learn and designed for the really, really heavy lifting.

Surely not every data manipulation task that is too much for Excel needs an enterprise ready server based ETL tool? Particularly in the current economic environment, oversized solutions are not an option.

A hard working analyst that has a bit of data analysis to do, and nothing but Excel or maybe Access on his/her desktop is short on options and long on messy spreadsheets or the need to "learn SQL in 21 easy steps".

The vision behind Datamartist is to provide an easy to use, powerful, yet low cost data transformation tool, that guides users to generate well structured data analysis sets.  And all at a price that represents less than a single day of those consultants you have to hire to use the other software you paid too much for.

This is the perfect time find out what easy, flexible, visual data transformation can be like-  download now.