## 5 Results
### Data Preparation  
After documenting the 'Data Preparation' phase for various real-world projects, we assembled the most common problems and their solutions. In the top BPMN diagram (Figure 1), there is a proposal for the top level of this phase. The structure is linear, with two main parts, which can iterate, if necessary, until the desired result is achieved. The process follows the 'Data Understanding' phase. It starts with 'Adjusting structure', being either working with given exports, or returning to the 'Data Understanding' phase for a while, to design a new export structure that is close enough to the required structure (if possible and necessary). The next step is 'Integration of data sources' via a common identifier (e.g., ID), timestamp, composed keys, etc. If two sources cannot be integrated in a meaningful way, a return to the 'Data Understanding' phase, or even the 'Business Understanding' phase, may be necessary to reconsider either available data sources or business/data-mining goal, respectively. Successful integration is followed by adjustments inside the source. The following order proved to be the most advantageous one: First, 'Adjusting attributes (columns)' is performed. The desired attributes are selected, new ones are calculated, and supplementary ones are removed. Then, 'Adjusting records (rows)' follows, as to keep only the records happening in the desired time periods (e.g., omitting records from holidays and weekends or keeping just records from specific working shifts). This also includes dealing with empty and semi-empty rows. The latter may be either removed or reconstructed. The last step is 'Adjusting values', in which various issues are addressed, concerning data types and formats. In multilingual companies, language issues were found to be very important and may take time to be solved (and unearthed, in the first place). After that, the 'Data Preparation' phase is completed, and the 'Modelling' phase can start. Identification of sub-phases of a certain phase, as presented above, was only one of the reasons why we decided to use case studies as a basis to form our proposal. Another, and arguably the most important, reason was to identify problems occurring in real-world projects. That is the kind of knowledge only praxis can provide, and a source of a company's best practices. Some of the problems tend to be more general, recurring, applicable to almost every project; such problem is, sadly, lack of (available) documentation. Others are more specific, but still common enough to be considered for a certain group of projects. Then there are very specific problems which occur only rarely, but are also documented in case a similar project will be solved in the future, and also to challenge new data scientists in the team by introducing them to the hypothetical problem. Our proposal is based on problems which occurred in at least two presented projects. We assembled the most common problems that occurred to us during the 'Data Preparation' phase. We then classified these problems into groups, based on their affiliation to one of the six data-quality dimensions. Accuracy:  
* Incorrectly guessed types;
* Incorrect formats of numbers and dates. Completeness:  
* Missing rows;
* Rows with empty values and rows with mostly empty values. Figure 1: Top diagram proposal for the ‘Data Preparation’ phase. Consistency:  
* Structure incompatible with other sources;
* Missing common unambiguous identifier;
* Two time periods have completely different structure;
* One period recorded much less frequently;
* Naming inconsistencies;
* Spelling inconsistencies (aka case, diacritics);
* Inconsistent usage of decimal point/comma;
* Different time formats;
* Names/text written in mix of languages. Timelines:  
* Only one parameter recorded at a time;
* Sources not time-synchronized.