1. Introduction – the thesis

Companies have more data than ever before, yet decisions are still often made “by gut feeling” or based on an incomplete spreadsheet report. In one department the same metric may have a different value than in another. A report may only be ready a week after the decision has been taken. Sometimes the history that would allow a reliable year-on-year comparison is also missing.

The source of the problem does not necessarily have to be the absence of a data warehouse. It often stems from the assumption that building one closes the analytics topic. A warehouse helps store an organised, consistent history. On its own, however, it does not guarantee that the needed information will arrive on time, will be understood the same way across departments, and will suggest what action is worth taking.

| If in the company…                                      | It may be missing…                             |
| ------------------------------------------------------- | ---------------------------------------------- |
| the same metric has different values in different departments | common definitions and calculation rules       |
| a report appears after the decision has been taken      | an efficient data flow and update process      |
| results cannot be compared with previous years          | preserved history in an appropriate form       |

In the examples that follow it will be shown which business requirement went beyond the capabilities of a single system layer — whether a warehouse, a data pipeline or reporting tools — and what had to be combined or supplemented so that the solution truly supported decisions. Because in practice the needed effect rarely arises in a single layer.

2. How it all works together – a typical analytics system architecture

Each layer answers a different requirement. The system is not a choice of one of them, but selecting the right set for the business requirements — and those change as the company grows.

From data sources to a concrete decision

A typical flow can be presented as successive stages, each of which answers a different need:

sources (ERP/CRM/API/files) → pipeline → warehouse → business logic (rules layer) → BI/AI → decision

• Sources (ERP/CRM/API/files) supply the data needed to describe the company’s activity and its environment.
• Pipeline answers the requirement for regular, repeatable acquisition and preparation of data.
• Warehouse provides a common place for storing data, including data needed for analyses and comparisons over time.
• Business logic (rules layer) makes it possible to apply common interpretation and calculation rules.
• BI/AI helps present results, find relationships or estimate what may happen next.
• Decision translates insights from the data into concrete action.

This is a schematic, not a mandatory identical set for every company. Requirements may mean that other connections or additional capabilities are needed. See how this works in practice in the examples below.

Why omitting a layer costs the company orientation

The consequences become visible when a business requirement finds no answer in any of the layers. The absence of a pipeline, when regular combining of data is needed, means manual work and a higher risk of human error. The absence of a warehouse with history, when results need to be compared over time, makes such comparisons difficult or completely impossible.

If common interpretation rules are needed and business logic (rules layer) is missing, data may be available, yet individual departments will calculate the same concept differently — for example net and gross revenue. When the company needs to make results available to decision-makers but BI is missing, data may remain accessible mainly to IT.

The same happens when prediction is needed and a predictive layer is missing: the company can analyse what has already happened, but remains in reaction mode instead of preparing for possible events. In each of these cases the problem is not the technology itself. It is a requirement that goes beyond the capabilities of a single layer.

3. Lightweight warehouse and dashboards for a financial platform (2011)

It was not about expanding reporting in response to a growing number of transactions. The analytics system was designed and built before operations even started, so that data could be managed consistently and the most important business areas observed from the very beginning.

The online currency exchange platform was to handle transactions in a separate operational system. In parallel, a data flow, a warehouse and an analytical layer were prepared that were to collect information from various sources and present it in an organised form. The point was therefore not to replace the transactional system, but to create a solution that would allow the business to be managed on the basis of a common picture of the data.

Already at the design stage the need for automatic retrieval and combining of information from multiple sources was taken into account, including bank accounts and external market data sources. Thanks to this, management did not have to rely on manual compilation of information. A historical layer was also prepared that made it possible to analyse earlier results and trends independently of the current state of the source systems.

In this case it is therefore worth separating the layers rather than attributing the entire solution to a single technology:

| Layer                                   | Why it was needed                                                                                                                                   |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data flow                               | Automatically collected and combined information from multiple operational sources, including bank accounts and market sources, without manual data export. |
| Warehouse / operational analytical database | Stored data in a form that enabled analysis of history and trends, independently of the current operation of the source systems.                            |
| Business analytics                      | Made data available on understandable dashboards that management and the operational team could use without writing queries.                                    |

The lesson is not simply that dashboards were needed or that automation replaced manual work. What matters is the matching of several layers to a concrete requirement: data had to be combined, retain historical context and reach decision-makers without additional intermediaries. A well-designed foundation can serve for years without rebuilding — the solution does not have to be the newest if it still answers real needs.

4. Automatic acquisition of market data without an API (2012)

In this case the problem was not storing data, but the fact that the needed information was not available in a usable, organised form. Early-stage investment funds and angel investors had to assess whether it was worth entering online commerce, extending a brand into a new segment or investing in a particular market. For such decisions an up-to-date picture of what was happening on the market was needed — not merely a single, manually collected snapshot.

Manually checking offers on an auction platform quickly ceased to be feasible. The more information had to be tracked and the more frequently it had to be revisited, the harder it became to maintain regularity and compare changes over time. Without automatic data collection it was easy to notice the market only with a delay.

Therefore the solution first had to acquire data that the source did not make available in ready form. Continuous market monitoring made it possible to observe the current situation, while periodically preserved states made it possible to compare it with earlier periods. Recipients could therefore assess not only what was visible at a given moment, but also the direction of change.

That is why the e-commerce intelligence system was developed and implemented. A data warehouse alone would not have been enough, because there was not yet anything to store. The order of work here was the reverse of a typical scenario: first a mechanism had to be built that created an organised data set from information available on the market, and only then could those data be collected and analysed. Decision-makers thereby moved from reacting to delayed signals to observing the market in real time. The advantage came from systematically acquiring information that the market did not supply in a ready, easy-to-use form.

| Layer                                              | Role in the solution                                                                                                                                                                         |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data pipeline                                      | Actively collected and transferred information from the market to a place where it could be analysed. It therefore performed the function of a data pipeline, even though the source did not make the data available through a ready interface. |
| Data warehouse / operational data store (ODS)      | Stored successive market states, making it possible to compare them and discern trends rather than being limited to the current picture.                                                    |

5. A Large Raw Database and Two BI Layers Built on Top of It (2016)

The starting point was not a data warehouse designed around specific analytical questions. It was a large, raw operational database belonging to an internet portal: over a hundred tables and several dozen gigabytes of data, stored in a structure built to run the service — not to make analyzing its results convenient.

The portal handled user accounts and a secondary market for games. What was needed was a better understanding of registration dynamics, the demographic structure of users, their connections to external platforms, and transactional activity. The database itself contained the information needed for such analysis, but it didn't present it in a ready-to-read form. Finding a trend or isolating a segment required manually processing many tables and working through a large volume of data. Access via SQL queries didn't solve the problem for people who didn't work that way day to day.

That's why two separate analytical layers were built on top of the same source. One enabled self-service work on the data using MS Excel and Power Pivot, which could be refreshed and analyzed on the user's own terms. The other made interactive reports in Power BI available to a wider group of recipients. The source remained shared, but the way of working, the form of presentation, and the needs of the people using the data differed.

As a result, the raw dataset — which had previously required knowledge of queries and the database structure — became accessible in two more approachable forms. One supported hands-on, self-directed exploration of the data; the other supported browsing pre-built summaries and visualizations. Storing the information alone wasn't enough. What was needed were layers that gave it structure and helped make sense of it.

This case shows why a single layer isn't always enough. A raw store offers flexibility and broad access to the recorded data, but without transformation it doesn't automatically answer business questions. And even once the data has been prepared, a single form of analysis doesn't necessarily suit every recipient. The same source may require several layers of presentation and data work — each matched to a different way of making decisions.

Layer	Classification	Justification
Data storage	Data lake	This wasn't designed as a data lake in today's sense of the term. Functionally, though, the solution was closest to its raw-data layer: full copies of the operational data were preserved on a regular cycle, without transforming them for any specific report. This made it possible to later return to earlier states and build various analytical layers on top of them.
Analysis and presentation	BI — two independent layers	Two separate analytical layers drew on the same source, turning it into clear segments, trends, and visualizations for recipients with different needs.

The database was therefore a foundation, not a ready-made decision-support system. Only by combining it with analytical layers was it possible to work with the data without having to read the sprawling operational structure directly.

6. Telemetry and real-time event interpretation

It was not about simply collecting logs. Events were being recorded, yet their recording did not explain what they meant or what conclusion the user should draw from them. With a large stream of individual events arising during activity, what mattered was no longer only how many of them occurred or how long the activity lasted. What was needed was an understanding of what had actually happened.

A raw entry in a table is only a record of a single event. Only combining many such entries into a coherent session makes it possible to reconstruct the course of activity and assess its significance. In this case the conclusion was to reach the user immediately after the session ended — not only later when someone analysed the data.

The system therefore automatically combines individual events into meaningful wholes and then translates them into concrete feedback. The user receives a ready conclusion at the moment when they can still benefit from it. Data ceased to be solely a register of the past and became part of the current experience.

A warehouse with raw events alone could answer the question “what happened”, but not necessarily the question “what follows from it”. For that, rules are needed that recognise relationships between events and give them meaning. Data-storage technology does not replace such logic — just as simply delivering information quickly does not yet guarantee that it will be useful.

Value therefore does not arise from the mere number of recorded events. It appears when the system is able to combine them into a history, interpret it and present it in an understandable form. See the full architecture and project description Headshot Haven: Gaming Tracker and real-time data orchestration.

| Layer            | Role in the solution                                                                                                                                                 |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pipeline         | Events were automatically collected and forwarded in real time, without manual data export.                                                                          |
| Warehouse / ODS  | Grouped sessions were stored as history that could be returned to and analysed — not only as a current record of events.                                              |
| Business logic   | Rules determined which events make up one session and what conclusion follows from it. They gave the data meaning rather than limiting themselves to recording it. |
| BI               | The conclusion reached the user in an understandable, ready-to-receive form, immediately after the session ended.                                                     |

7. From event interpretation to ready advice in natural language

This was not another version of the report from the previous stage. Earlier, session data had been combined into a meaningful whole and changes in results had been shown. The question still remained, however: what specifically should be done differently?

Numbers, trends and comparisons alone do not point to one obvious action. Two people may see the same result and draw different conclusions from it. Accurate interpretation also requires knowledge of the rules and mechanics of a given activity — knowledge that the recipient does not always have to hand.

Therefore expert knowledge was added to the analysis results. The system combined patterns and comparisons with information about how a given activity works, and then composed personalised advice in natural language. Instead of another row of values, a ready answer appeared to the question of what to change next time. It was delivered after the session ended, without the need to analyse the data oneself.

This is a different problem from the one in the previous stage. Then events had to be grouped so that they formed a readable picture of the session. Here such a picture already existed, but it did not yet suggest what to do with it. Interpreting data and recommending action are two separate competencies — the second requires combining the analysis result with expert knowledge and translating them into a concrete message.

| Layer                                      | Role in the solution                                                                                                                        |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Data flow                                  | Automatically combined session events with an external expert knowledge base, creating a common set of information for analysis.            |
| Warehouse or operational data store        | Stored the results of successive sessions so that they could be compared over time.                                                         |
| Business logic                             | Determined which metrics and comparisons are relevant and in what order they should be taken into account.                                  |
| Analytics and recommendation generation    | Translated results and expert knowledge into descriptive advice matched to the concrete situation.                                          |
| Presentation and business analytics layer  | Delivered the advice in a readable form, in a place the recipient was already using, without the need to log into a separate tool.          |

It is clear here why the event-interpreting layer alone was not enough. It could show what had happened during the session and how the results had changed, but it did not yet have the basis for indicating the best next step. Only the combination of data, rules, expert knowledge and the way of delivering the result turned analysis into advice that could be applied immediately in the form of generating automatic recommendations and analysis in natural language

8. From forecast to ready offer: prediction that finds its own outlet in sales

There was no shortage of data. For years the ERP system had been recording transactions, orders and inventory levels. The problem was that the information remained in a system intended for handling current operations, not for predicting demand or supporting decisions. In an import-distribution company managing thousands of products and serving hundreds of customers, each of those decisions mattered.

Reports had to be prepared manually, and by the time they reached recipients they were often already out of date. Purchases were planned largely by gut feeling, and stock shortages only became apparent when a customer asked for goods. Departments worked on their own spreadsheets, so the same numbers could have several versions.

The ERP system performed an operational function here: it efficiently recorded transactions, orders and stocks, but did not answer the question of what demand would be in a month. The predictive layer and the sales tool were created alongside it — not instead of it — as a separate analytical system.

A common data model combined transactional information with business rules defined by users. On that basis it was possible to forecast demand for a specific product and customer, classify products according to their market behaviour rather than solely by category, and generate alerts before the risk of stock shortage became obvious. The analysis covered the entire customer portfolio — from hundreds to thousands of items — and the system could automatically indicate up to 50 recommended products for a given customer.

The forecast itself could still remain only a number in a report. Even if all the data were already combined and visible on a dashboard, the person selling would still have to translate the conclusion into concrete action: choose products, set conditions and prepare an offer. Only the next layer closed this process. Recommendations went into a sales-support tool that arranged a list of priority actions for the customer. It made it possible to quickly build an offer with conditions matched to individual products, and then export it to the company’s system and prepare it as a document for the customer — without manually rewriting data.

As a result, preparing an offer was shortened from hours of work to a few minutes. Stock problems could be noticed in advance, and purchasing decisions ceased to be based solely on intuition. The chain therefore did not end with analysis or recommendation: it reached as far as a ready commercial document.

| Layer                                     | Role in the solution                                                                                                                              |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data flow                                 | Automatically retrieved data from the transactional system and combined them, in a cyclic process, with business rules defined by users.         |
| Warehouse or operational analytical database | Provided a common data model for departments, instead of many spreadsheets containing different versions of the same numbers.                     |
| Business logic                            | Classified products according to their market behaviour and triggered alerts when defined thresholds were met.                                   |
| Predictive analytics                      | Used history to forecast demand and group products, rather than limiting itself to simple averages.                                              |
| Reporting and results presentation (BI)   | Made results available in tools matched to the roles of recipients, not solely in one universal report.                                          |
| Sales action                              | Turned recommendations into priorities, offer conditions and a document ready to be handed to the customer.                                      |

This is an example in which no single layer would have been enough to achieve the goal. A warehouse would organise the data and reporting would make them easier to read, but without the sales layer the recommendation would still have to be manually turned into an offer. Business value appeared only when the forecast reached the person taking action in a form ready to use, rather than requiring a further processing stage.

9. Data warehouse for a car importer

In the case of a car importer the difficulty did not consist solely in combining data from several systems. Some of the key information existed, but not in a form that could be directly loaded into a common model. An invoice or operational document stored as a file required prior reading and transformation. The warehouse itself could not combine data that it could not yet recognise.

The company used in parallel an ERP system, sales files, financing reports, XML documents and materials stored in SharePoint. Each source described a different fragment of activity. Establishing the full history of a single vehicle required manual matching of the VIN number with the invoice and financing conditions. Margins, discounts and inventory turnover were analysed separately, which made it difficult to find the cause of a deviation. In addition a report could lose its currency before it reached the decision-maker.

A layer was therefore needed between the documents and the warehouse: a mechanism that read information from files, turned it into organised data and combined it with the remaining sources by a common key — the vehicle number, i.e. the VIN. Only then was it possible to assemble sales, dealers, invoices and financing in one model. Margin, discount, inventory and financing conditions could be analysed together, instead of searching for answers in many exports and formats.

This is an important distinction: the data source existed, but the barrier lay between the document and the data, not between the company and the market. In another case a data flow may require reaching a source without a programming interface; here the system had to be taught to read information recorded in documents. In both situations the warehouse alone does not solve the problem until an earlier layer has delivered data to it in usable form.

On a common model one can base not only analysis but also further actions, such as preparing lease applications or invoice corrections. It is important that the results of such actions can be linked to the source document. Then automation does not become a separate, opaque system, but uses the same data and rules as reporting.

| Layer                                                           | Role in the solution                                                                                                                        |
| --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Data flow                                                       | Automatic retrieval and combining of information from the ERP system, files and SharePoint, including reading data recorded in documents.   |
| Warehouse / operational data layer                              | A common, historical model combining sales, dealers, invoices and financing by VIN number.                                                  |
| Business logic                                                  | Calculating metrics such as margin and turnover, and classifying data according to established rules.                                       |
| Reporting and analysis ([BI](https://pl.wikipedia.org/wiki/BI)) | An interface enabling independent navigation from a metric to the source data.                                                              |

A warehouse that combines organised data from systems is only part of the solution. In practice information important for decisions is often hidden in documents that first have to be read and transformed. Only combining this function with a data flow, a common model, business logic and an analytical layer makes it possible to move from dispersed files to a coherent picture of activity.

10. Orchestrating Data from Spreadsheets: Automatically Delivered Reports and Notifications

In this case, it was not enough to calculate the correct result and make it available in a report. Different recipients needed the information in different forms, while exceeding an important threshold — such as a deadline or budget limit — could go unnoticed until someone opened the report and checked it manually. The data and business rules were stored mainly in spreadsheets, so the solution needed to collect them in one place, organize them, and then deliver the relevant information to the right people.

Previously, several versions of the same reports had to be prepared manually, depending on the recipient and the required format. It was also necessary to monitor separately whether an agreed limit had been exceeded. The reports themselves operated in a pull model: the recipient had to request the information by opening the report and finding what was needed. The business requirement, however, went further — the system had to deliver the result itself and draw attention to exceptions.

The solution therefore operated in a push model. It retrieved data mainly from spreadsheets, combined them into a consistent model, and then automatically generated documents tailored to individual recipients and sent them in the appropriate format. It also checked specific parameters, such as deadlines, expenses, or predefined thresholds, and sent a notification whenever they required attention. An example of data orchestration, automated reporting, and notifications shows how combining data integration, business rules, and active delivery of results changes the way information is used.

This distinction separates the case from solutions where the primary need was to allow recipients to browse data themselves and retrieve the reports they needed — as in examples 3 and 5 — or to use analysis when planning sales activities, as in example 8. Here, the key requirement was not only to prepare the information, but also to deliver it without waiting for the recipient to search for it. The change therefore concerned not only speed, but also initiative: the system delivered the result and signaled when action was required.

The analytical layer alone would not have been sufficient to achieve this effect. Even a correctly calculated result would still require someone to open the report, prepare a version for another recipient, and check whether a parameter had exceeded its permissible value. Automatically delivering information and actively issuing alerts are distinct capabilities from calculating the information itself.

Layer	Role in this case
Data flow and integration	Automatically retrieved data mainly from spreadsheets and combined them into a consistent model.
Business logic	Defined when a parameter exceeded a specified threshold, who should receive the information, and in what form the document should be prepared.
Reporting and analytics	Prepared documents tailored to individual recipients and notifications sent without requiring them to check the report themselves.

It was therefore not simply a data warehouse, a data flow, or a single report. The solution required a combination of integration, business rules, and automated distribution of results. The value emerged when information was not merely available, but reached the right person at the right time — through a push model rather than only when someone went looking for it.

11. What really changed over the years

In each of the described examples the starting point was a concrete requirement that a data warehouse alone could not fulfil. What changed was not which technology was currently fashionable, but what the business needed: first consistent access to data, later automation, and finally a decision taken by the system.

This is not an exception or a peculiarity of individual implementations. Such a pattern repeats in practice in many growing companies, because requirements usually increase in a predictable order: from collecting and making data available, through automatic performance of repeatable activities, to recommendation or action without every-time human intervention. Each successive stage may require a further layer. Not because the earlier technology ceased to be useful, but because a requirement appeared that went beyond its scope.

The scale of data, the cost of storing it and the availability of tools based on artificial intelligence have changed. The expected reaction time has also changed: from a report prepared once a month to a recommendation that is to be ready within a few seconds. These are technological changes, but their significance is primarily business. When a decision has to be taken faster, it is no longer enough to gather data and show them on a chart. They have to be processed efficiently, interpreted, and sometimes the result passed on to the next action.

What has remained unchanged is the need for one consistent version of the data, the value of clean history and the necessity of understanding the business before starting to build a solution. It is still worth asking the question: what requirement does the current arrangement not fulfil before another layer is added to it? It was already relevant in the 2011 example and remains relevant today. It helps distinguish a real need from the mere desire to implement a new technology.

No company has to start with advanced analytics or artificial intelligence. The set of needed layers grows when requirements grow: first access to reliable data is needed, then their automatic processing, and later support or taking of decisions. A warehouse can still be a solid foundation — it does not, however, have to perform the function of the entire decision-support system on its own.

12. When to use which approach? A practical guide

The choice should not begin with a question about technology. First it is necessary to establish which requirement is still not being met: whether durable access to data is missing, a clear way of making them available, logic supporting decisions, or a connection of analysis with action. Only then can the layer that should supplement the system be indicated.

| Signal in the company                                                        | Unmet requirement                                                                  | Layer that may be missing                    |
| ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------- |
| Data are available mainly to the technical team                              | People responsible for results cannot independently review the needed information  | Reporting and data visualisation             |
| Data disappear, are overwritten or their earlier state is hard to reconstruct | Durable, organised historical data are needed                                      | Data warehouse                               |
| The warehouse works, but decisions are still taken by gut feeling            | Data have to be translated into rules, forecasts or concrete guidance              | Business logic and analytical layer          |
| Analysis shows what should be done, but does not trigger action              | The result has to be included in an existing operational process                   | Integration with processes and automation    |

How to match the solution to the company’s stage of development

Data exist, but are not available to the people who take decisions. If the needed information can be obtained only through the technical team or by manually preparing summaries, the limitation may be the way they are made available. In such a case the next step does not have to be expanding the warehouse. It may be a reporting layer that allows independent review of results and comparison of them according to need. A similar requirement appeared in the case of the financial platform described in example 3.

Data exist, but the history is not reliable. When values are regularly overwritten, come from many sources or it is impossible to reconstruct how they changed over time, a layer that ensures their storage and organisation is needed. In such a case a data warehouse may be justified not because it is the “target” technology, but because without it the requirement of working on a consistent history cannot be met.

The warehouse works, but does not suggest how to take a decision. Simply gathering data does not decide which action will be appropriate. When an indication of a probable result, a priority or the next step is needed, a rules and analysis layer may be necessary. In example 8 the prediction does not end with estimating a future result — it is linked to preparing a sales action. The requirement therefore goes beyond the warehouse alone.

The analysis result does not translate into action. If an employee has to manually transfer the conclusion to another tool, notify the right person or start the next stage of a process, the missing element may be process integration. In example 9 the same data model supports both analysis and automations. It is therefore not a choice between analytics and action, but combining them where the process requires it.

These layers do not have to arise successively or function as separate systems. What matters is establishing which part of the requirement remains unmet. Sometimes organised data and reporting will be needed at the same time, and in another case the existing infrastructure will suffice — provided it is supplemented with business logic or integration with the process.

The most common mistakes when choosing the next step

• Building “for the future”. A layer is developed for which there is not yet a concrete requirement. Instead of assuming that an advanced environment will be useful in the future, it is better to determine which task cannot be performed today.
• Omitting business logic. A warehouse is created, but it is not established which decisions it is to support and according to which rules the data should be interpreted. As a result information is gathered, yet its meaning still depends on manual analysis.
• Moving to artificial intelligence without a foundation. An attempt is made to obtain an advanced recommendation before the data are available, consistent and appropriately described. A new layer does not remove the deficiencies of lower layers — it may only make them harder to notice.

The practical question is therefore not “which technology to choose?”, but “which requirement cannot be met today and where does its boundary run?”. The answer indicates which part of the system should be developed — and whether a new layer is needed or a better connection of those that already exist.

13. Summary – what really matters

In each of the described cases the same question returned: which business requirement went beyond the capabilities of a single layer and what had to be added to meet it? The answer was different each time, because the needs were different: from preparing reports, through acquiring and interpreting data, to passing the conclusion on without manual work. That is why a warehouse, a data flow or a reporting tool should not be treated as the entire decision-support system.

Three principles for building a data-based foundation

• The starting point should be a decision requirement, not the choice of a tool. In the case of the lightweight warehouse and reports for the financial platform what mattered was which questions the summaries were to answer — only then was the solution subordinated to that.
• Each layer should answer a concrete requirement and be selected separately, not as part of a ready package. The example of the large raw database with two reporting layers shows that simply collecting data is not enough when different groups of recipients need different ways of analysing them.
• The system is worth expanding when a requirement appears that the current layers do not meet. With automatic acquisition of market data without a ready interface, the existing approach had to be supplemented with a way of obtaining data that the warehouse alone did not provide.

Questions worth asking yourself tomorrow

• Can someone outside the IT department independently answer a simple business question using the available data?
• Can the state of sales from a year ago be reconstructed?
• Do two departments give the same number when answering the same question?
• Does a conclusion from analysis ever reach a customer or a system automatically, without manual work?

The answers will help indicate where the current solution already fulfils its task and where a requirement has appeared that goes beyond the capabilities of a single layer. From that point further decisions are worth starting — not from the assumption that another technology is needed.

FAQ