Archive for the ‘adatminőség’ Category
The true story of contact list data migration
Project contact list migration part 1
My old Nokia phone reached this year the school-age (became 6 years old), and I was satisfied with him in the past. Unfortunately it became deaf and mute recently, so I was forced to purchase a new phone (iPhone).
I possess a mobile phone since 1997 and I carried the contacts from phone to phone. Beside this I have an Address Book of the E-Mail software (Thunderbird) with contacts, an address book of Outlook Express from an old PC, and an Excel table which is a copy of my former business phone.
So I have 4 sources with various contacts (redundancy is there), and a question: How to merge and migrate all contacts within the shortest time and maximum quality? (in this question I have to be maximalist: I do not accept 95% data quality, because what should I do with 20-50 garbage contact in my new phone?)
Migration Planning and Project Initiation
After the scope is defined very clearly, I form the topic of effort estimation generously this time: max. 2 days.
Configuration Management and software tools:
Because typing on the PC is 10 times faster than with the tiny buttons of iPhone, I have to find 1 or 2 transient data store, where the synchronization can happen very fast. For the last step iTunes synchronisation tool is the only appropriate way and it works properly.
Plan of workflow
The key element of the workflow is the right choice of the transient data store. Because the export-import possibilities of the different data sources are unknown at the moment, this key momentum will be clarified during the project.
Because of this we found in this tiny project a risk which can affect the delivery time (in this case the time of full contact list on the iPhone) – and as we know the most of the data migration projects (84%) fail because of delayed delivery time.
Transient data store for migration Nr.1
The extraction of the contacts from the Nokia is theoretically very simple: I have no tool, no data cable to download the contact list – so the manual job remains whatever it hurts. The destination: plain paper or an address book directly. I have chosen the direct entry into the Thunderbird Address Book, because nowadays I type faster than write. And with this move the number of data sources will decrease with one.
Surprise Nr 1: There is no direct connection between iTunes and Thunderbird. The possible contact sources of iTunes are Windows Address Book, Google Contacts and Outlook Express Contacts.
So lets export the data from Thunderbird to Windows Address Book. Of course there is no direct connection in this direction, so I have 2 possibilities: CSV export and LDIF (LDAP server).Note that at this time we have 3 transient data sources: Thunderbird Adress Book, CSV (or LDIF) and WAB.
Short summarized: about 30% of the contacts were simply not migrated, I don’t know the reason. After one or two attempts I dropped this possibility and have chosen the remaining option: Google Contacts
Transient data store for migration Nr 2.
The life is not easy, there is no direct connection between Thunderbird and Google Contacts. After a short research I found the Zindus add-on for Thunderbird, where the synchronisation between Thunderbird and Google Contacts supposed to be solved.
And it worked: the data synchronisation between Thunderbird and Google and also between Google Contacts and iPhone through iTunes.
Surprise Nr 2: However as I checked the application contacts in iPhone, I faced a new problem: the sequence of last name and first name.
For explanation: Hungary is one of the rare places of the world (beside Japan I think), where the official sequence of the name is “Last name” “first name“. So I want to see my contacts in the phone that way, however Google Contacts messed this sequence up.

Of course the Google application does not recognise (even if the settings are for Hungary), what is the right sequence. The fast solution is put a comma between “Last name” and “first name“, like Bossányi Tibor. And this is again manual work for many hundred contacts. (I don’t want to tell long stories about the attempts to set the settings to English (UK),exporting the list in CSV to find the fastest solution to put this comma into the names. It does not work.)
Summary
To not to loose too much time with this simple operation (at the first look), I had to think in a project way: finding a clear scope, a simple effort estimation and a measurable action plan to avoid shifting this activity. In this first part I found the most optimal way between the possibilities by attempting more different ways and measure which is the most effective in aspect of time and data quality.
The next (last) part I will write about the data quality rules which have been set up, and the migration from remaining legacy sources.
Sources
Data Migration Project Checklist from datamigrationpro.com
Data quality in the online marketing
,
What do you do with the bounced e-mails after sending some thousands to your customers?
Every enterprise which stores a mass of data meets the Loch Ness-monster of the data handling which appears from the nothing and you cannot catch it. If the newsletter auto-responder system could cry (or even swear like a trooper), then you have to close your ears which is it worth nothing, because the noise comes through the ear-plug: “this is not a database, this is a dump“.
Why is a clean database important? Because the online marketer cares about the conversion, measures the percentage of the number of buys / sent e-mail and it matters if only 0.1% or 30% does not find the target address and fail to land in the right e-mail account.
Why does so many error arise in the customer database?
Although the (good) online marketer try to solve the subscription form as simple as possible (name and e-mail address), there are many reasons why will be useless the data at the end.
- the customer puts a wrong e-mail address into the form
- a bad name is given – it is important, because in most of the cases the marketing e-mails are personalized
- The provider of the target e-mail address judges the sender address as a spam
- if the customer reaches the level of buying attend, and he gives an erroneous the shipping or billing address
- e-mails are bounding back because of full mail box.
Explanation of the colors:
blue: a better newsletter and auto-responder software can handle these errors – they are syntactical errors
green: to eliminate these errors the owner of the data is also needed, who knows what should be corrected – so an automatism is excluded (they are semantic or content failures).
What can the online marketer do to enhance the data quality?
- Nothing: It is also a solution, but of course a lot of money can be lost
- He maintains the database regularly: The maintenance can be done manually, but we all know that most of the online marketers and even their webmaster aren’t bit artists so they can spend 1-2 days to cleansing of the data. A better solution is using a software special for this area, with this the task can be completed within some hours – after the determination of the correction from error patterns. However I must highlight again, do not imagine the whole job so that the customer list is fed in the input and a perfect list will be spit out in 2 hours! It does not work that way. In many cases the decision of the owner of list is needed how to correct some sort of data error.
If you have a question about the maintenance of the customer database then please write a comment or contact me directly through the “contact” menu.
Data Profiling – Remove the spiderweb from the back of the wardrobe
You were probably in the situation when your furniture had to be moved from their old place because of relocation to another city or before flat painting. You move the floor-rooted piece of furniture and you realize that the back is covered with discusting spiderweb and other grime. What will you do: leave it as it is, because it cannot be seen near the wall or you will remove it immadietly?
Next time you will reckon and check the corners, not visible places of the room what should be removed what does not match into the room. That means you execute a dirt profiling from time to time in your flat.
A similar approach must done during the data migration project. Checking the data quality is one of the first steps in the project: with the execution of the data profiling can we build a first impression about the scale of the project. That means this step must be executed before the final effort estimation!
What is the data profiling?
During the data profiling process you will examinate the data in the legacy source to collect statistics and information for building the data quality rules. For the dimensioning of the definition of the data profiling, I have chosen the determination by Informatica: The data profiling has 3 dimensions:
- column level
- table-intern level
- inter-table level
Metadata profiling
The first two levels (column level and table-intern level) can be examined with the metadata profiling. On the column level you can check the
- data types
- domain, range of the values (i.e. post code must be within the interval of 1001-9999 in Hungary)
- pattern (i.e. the phone number has the pattern: +nnWnnWnnnnnn)
- frequency counts (i.e. most of the sells happen on workdays: Tue, Wed, Thu)
- Statistic numbers (min, max, median value, avarage value, etc)
- dependencies
- Redundancy
You can draw information within the table by dependeny checks (this category takes also place in the third dimension: in the inter-table level). You can determinate the dependency between column values by the normalization rules from the logical data model design: i.e. a national code of a phone number is related to the ‘city‘ column.
Finding dependencies between the tables (inter-table level dimension) are based on table model design: i.e. a foreign-key value customer-id in the orders table must appear as primary key in the customer table. After my experience the most the data garbage is coming from the missing referential integrity between the tables which was caused by poor data model design.
Example by an open source tool
I have chosen the Data Profiling Tool by Talend on a database with some tousand records of the ‘Address‘ table. The free downloadable version supports the first two dimension of the data profiling types: column level and table-intern level.
In the picture below you see the example of two columns: Address and AddressID. The meaning of the colors of the column Address.
- Red: number of all records in the table (6575)
- Yellow: NULL values
- Orange: Distinct Count (6180)
- Blue: Uniqe Count (5910)
- Pink: Duplicated Count (270)
- Light Blue: Blank Count (39)

The Primary Key AddressID seems to be OK, because the count of the Unique values are the same with the count of the rows. But what can we do with the column Address? Theoretically it can be also uniqe, however the column contains street and number.

You can see in the picture above the defect rows. There are clearly bad administrated data, instead of the real address we find city name, phone number and duplicated addresses. To eliminate the duplicated rows the connected tables of address must be also checked by the data profiling tool.
In this short example you could see more data profiling types: redundancy for the duplicated rows, range for the recognized phone numbers, frequency counts, etc.
Summary
The data profiling is the anteroom for the creation of the data quality rules. To execute the whole data profiling, you have to check each column, each table and each connections between the tables. If you have the statistics and all information about the defects, then the data migration team, where the right stakeholders from the business side are also member of the team, must decide about the measurements and the invested efforts for the fixing.
References
Ne hagyd, hogy a technológia Istene ördöggé váljon
Az adatminőség-pokol harmadik köre: a technológiában tivornyázók köre
Dante Poklának harmadik körébe a tivornyázók, torkosok és falánkok kerültek. Az adatminőség-pokol harmadik körébe azok tartoznak, akik a technológiában dőzsölnek, ettol az eszköztől várják az üdvözítő megoldást.

Azonban nem azok a vállalatok az igazi bűnösök, akik felhasználják a különbözo technológiákat ahhoz, hogy a vállalaton belül az elfogadható minőségű adatokkal támogassák az üzleti folyamatokat. Ok áldozatok.
Habár megfontolandó kérdés, hogy a CIO és CEO (műszaki igazgató és a ügyvezető igazgató) mit érdemel, ha bedől egy ügyes (vagy nem elég felkészült?) értékesítőnek, aki elad a vállalatnak egy csodálatos szoftvert, amelyet
- könnyű installálni
- felhasználóbarát kezelőfelülete van
- a tranzakciókat nanomásodpercek alatt elvégzi
- pillanatok alatt felfedezi és az adatminőségi problémákat
- és nem is engedi, hogy az üzleti folyamatokban adathibák keletkezzenek.
Ez a rendszer önmagában nem elég, nem oldja meg a problémákat. A legfontosabb, hogy a vállalaton belül tevékenykedő emberi lények közreműködjenek.
Emberek
Emberek kellenek ahhoz, hogy megfogalmazódjon a gondolat, hogy a vállalat működésében felfedeztek egy problémát, amikor olyan adatokkal kell dolgozni, amely inkább csak hátráltatja a hatékony munkát. Ezt a problémát meg kell valamilyen módon oldani. Felállítanak egy csoportot, amely az üzleti oldalról az adatok tulajdonosai, használói vannak, az IT oldalról azok, akik a folyamatokat biztosítják.
Le kell győzniük a félelmet, hogy a esetleg blamálódnak a hibák okozása vagy sikertelen kijavítása miatt. Figyelembe kell venni az emberi faktort, mert emberek fognak részt venni projektben, és az ő sikerük fogja meghatározni az egész projekt sikerét, nem a használt technológia maga.
Folyamatok
Az üzleti folyamatokban áramló adatok karakteriszitkája vállalatról vállalatra különbözik. Sot ugyanabban a vállalatban a különbözo funkcionális egységekben is mások lehetnek az adatminőségi követelmények. Más üzleti szabályok érvenyesülnek a különbözo projektekben is. Ezeket tehát figyelembe kell venni, amikor meghatározzák a hatékony módszertant, amely segít sikeresen véghezvinni az adatminőség javításhoz létrehozott projektet. A legjobb módszer maximalizálja a ráfordított idő- és költségkeretet.
Technológia
Végre. Talán megkönnyebbülsz, hogy a hatékony technológia is szükséges a célok eléréséhez. Konkrét megoldásokat most nem említek ebben a bejegyzésben, mert általánosan megfogalmazott problémára nem lehet konkrét, kiragadott megoldást megemlíteni. Létezik open source és nagyvállalatok számára rendkívül komplex és drága technológia is.
Összefoglalva komplex problémákra nem létezik gyors és egyszeru megoldás. Nincsen varázspirula technológiai megoldás (válaszd a kéket vagy pirosat), és nem is lesz. Egy szervezet útkeresése az adatminőségi problémák megoldására csak akkor lesz sikeres, ha egy emberek alkotta motivált csoport a helyes módszertant alkalmazva felhasználja a legjobb technológia nyújtotta lehetoségeket.
Ez a bejegyzés az “Adatminőség-pokol 9 köre” sorozat 4. része volt.
Hiperaktív adatminőség
Ez a bejegyzés az “Adatminőség-pokol 9 köre” sorozat 3. része. Korábbi bejegyzések: itt és itt.
Cégtulajdonosok, adatkezelők figyelem!
Megérne egy kérdést, hogy mit tart a vállalkozásában vagy a saját területén a legnagyobb értéknek. Talán az emberi erőforrásokat? Gépeket, eszközöket? Kapcsolatokat? Esetleg az információt, amelyet adat formájában az adatbázisban tárol?
Ha az utóbbi, akkor érdemes elgondolkodni, hogy mit tesz meg azért, hogy ez a legnagyobb érték az is maradjon. Az első gondolat természetesen az, hogy rendszeresen biztonságba helyezi az adatokat (biztonsági mentések formájában), de ezzel most itt nem foglalkozunk. A következő lépés az, hogy ne szemétkupacban kelljen turkálnia, ha valamilyen információt elő szeretne bányászni az adatbázisaiból. Ha úgy gondolja, hogy ez is fontos, akkor nyomjon meg gombot a következő szavazásban:
Ha az első gombot nyomta meg, akkor mindenképpen olvasson tovább! Hacsak nem Ön agya az IBM Blue Gene szuperszámítógép klónozott változata. Ha más gombot nyomott meg, akkor is olvasson tovább, mivel megoldásokat találhat a HOGYAN-ról.
Ha idáig eljutott az olvasásban, akkor csak az tudom mondani, hogy “Gratulálok! Ön kezdi megérteni, hogy az adatminőség biztosítása fontos helyen szerepel az üzlet továbbfejlődésében. ”
Rendben, mit fog akkor csinálni, hogyan fogja megoldani a problémát?
Thomas Redman a Data Driven: Profiting from Your Most Important Business Asset (Adatvezérlés: profitálás a legfontosabb üzleti vagyonból) című könyvében egy analógiát használ, amit úgy hív, hogy adatminőség-tó.
“A tó reprezentálja az adatbázist és a víz a benne levő adatokat. Az áramlás, amely új vizeket hoz a tóba, olyan üzleti folyamatok, amelyek új adatot hoznak az adatbázisba. A víz szennyezett, mint ahogy az adatok is tartalmaznak szemetet. Hasonlóan a hiányosságok az üzleti folyamatban hibákat generálnak az adatbázisban.
Az egyik út a víz minőségének javítására a víz tisztítása. Vagyis szurok beépítése, a víz átfolyatása speciálisan tervezett tartályokon, kémiai anyagok használata a baktériumok megölésére és a PH-érték beállítására.
Az alternatíva a vízszennyeződés csökkentésére a gyárak szennyeződéskibocsátásának redukálása.
A kontraszt a két megközelítésben igen erős. Az első esetben maga a tó van a fókuszban, a második esetben a tóba ömlő áramlás. Hasonló a képlet az adatok esetében. A hibák megtalálása és kijavítása az adatbázisban olyan adatokon, amelyek már léteznek. A hibák megelőzése az üzleti folyamatokra és a jövőben keletkező adatokra koncentrál.”
Reaktív adatminőség
Abban az esetben, amikor a feladat a hibák megtalálása és korrigálása az operatív adattárban (operative data store – ODS) és a adattárházban (enterprise data warehouse – EDW) vagy más vállalati adattárban, akkor a vállalat reagál a felmerült problémára. Más szóval a hibák javítása azután történik, miután az adatbázisba kerültek már az adatok.
Proaktív adatminőség
Ha a vállalat a megelőzésre fordít figyelmet, vagyis a hibák kijavítása már az adatforrásból jövő adatok adatbázisba kerülés előtt megtörténik, akkor a vállalat proaktívan áll a kérdéshez. Thomas Redman felállít egy tizes szabályt a proaktív adatminoség leírásakor, mely szerint:
“Tízszer többe kerül az a munkaegység, amely a hibás input adatok (pl. késői, hiányos, inkorrekt) kijavítására irányul, mint az a munka, ha input adatok tökéletesen kerülnek az adatbázisba“‘.
Nyilvánvalóan lehetetlen a hibák tökéletes megelőzése, azonban minél nagyobb a bejövő adatok kontrollja, annál nagyobb az adatok minősége a vállalatok információs rendszerben.
Hiperaktív adatminőség
Mivel a legtöbb komplex probléma nem oldható meg gyorsan és könnyen, a legjobb megoldás a kétfajta adatminőség-biztosítás kombinálása. Jim Harris ezt hiperaktív adatminőségnek hívja. A lényege, hogy az adatminőség biztosítása egy vállalat mindennapi feladata kell hogy legyen.
Kinek a feladata az adatminőség biztosítása?
Az adatminőség-pokol 9 köre – a közönyösek köre
Kinek a feladata az adatminőség biztosítása?
Kik a legfobb közönyösek, akik megérdemlik az elso kört? Maguk a vállalatok, ahol esetleg már realizálódott, hogy órákat vesztegetnek el naponta azzal, hogy a megfelelo adatokat elobányásszák az adatbázisból, holott elvileg néhány másodpercen belül rendelkezésre kell állnia. Itt nem arra gondolok, hogy lassú az alkalmazás, vagy a hálózati kapcsolat a felhasználó számítógépe és az adatbázis között, hanem hogy rossz adatok jelennek meg. A rossz adatot nem lehet az ajánlatra vagy számlára írni, hanem előtte ki kell javítani, vagy esetleg más módon előállítani a kívánt dokumentumot.
De vajon költenek-e a vállalatok a mai gazdasági klímában egy új projektre, ahol amelynek az a feladata, hogy az adatminőséget biztosítsák, és az a célja, hogy rengeteg időt és pénzt spóroljanak meg azzal, hogy a helyes adatok rögtön rendelkezésre állnak. Azok költenek arra, amely cégeknek a gyenge adatminőség miatt elvesztegetett idő már fáj. És jobban fáj, mint az adatminőség biztosítására, adattisztításra fordított összeg.
Hogy milyen módozatok vannak arra, hogy egy vállalatnál elérjük a kívánt minőséget, arról egy későbbi bejegyzésben írok.
De, például a Drótkerítésgyártó Vállalat úgy döntött, hogy befektet, és optimalizálja a költségeit adatminőség szempontból is. De ki fogja elvégezni a munkát? Az IT részleg, vagy az üzleti részleg?
![]() |
![]() |
Az adatminőség biztosítása az IT feladata
Az első gondolat az, hogy az informatikai részleg, mert az információ az adatbázisban van tárolva, és az alkalmazások amelyek menedzselik az adatok elérését/módosítását. Ezért, ha probléma van az adatokkal, akkor az informatikusoknak kell megoldani a helyzetet.
Aki így gondolja, az töltse le az adatmigrációról szóló tanulmányomat, amely az adatminőség témának a testvérterülete.
Nyilván egy informatikus nem fogja tudni eldönteni, hogy az ügyfél Kovács József azért van kétszer az adatbázisban, mert véletlenül kétszer vették fel az adatait, vagy azért, mert két Kovács József nevű ügyfél van. Ha az informatikus dönti el, hogy mit lehet változtatni az adatbázisban, akkor könnyen lehet, hogy nagyobb károk keletkeznek, mintha hagyták volna az adatokat békén. Mert második Kovács József a vállalat legfőbb kliense, drótkerítés-nagykereskedő, és éppen őt törölték ki az adatbázisból…
Az adatminőség biztosítása az üzleti folyamatokhoz értők feladata
Vagyis az adatminőség biztosítása az üzleti részleg feladata, mert az adatok az üzleti folyamatok során képződnek, és a felhasználók azok, akik menedzselik a feladatokat, és ha problémák vannak az adatokkal, akkor az ő felelősségük az elrontott adatok tisztítása és helyretétele.
A megoldás tehát, hogy A Drótkerítésgyártó Vállalat vezetése kijelöl egy titkárnot és egy értékesítésen dolgozó szakembert, együtt összeülnek és 2 hét alatt kiszedik az összes szemetet az adatbázisból. Ebben az esetben lehetséges, hogy az értékesíto kivonása miatt akkora bevételtől esett el a Drótkerítésgyártó Vállalat, hogy jobb lett volna inkább az adatokat békén hagyni. Mert elvesztették a német Joseph Schmidt drótkerítés-nagykereskedőt, aki 30%-kal több megrendelést biztosított volna a vállalatnak.
Vagyis?
Az adatminőség biztosítása mindenki feladata
A sikertelen adatminőség-projektekre az a jellemző, hogy az üzleti részleg függetlenül definiálja a követelményeket és az IT részleg függetlenül írja meg a specifikációt. Ezután hipp-hopp elvégzi a “kódolás, tesztelés, leadás és a “kész van!” győzelmi felkiáltás lépéseit, ezáltal az üzleti részleget meghagyva a “megoldás” frusztrációjában.
A sikeres adatminőség-projektet az jellemzi, hogy egy központilag menedzsment megbízott összeforrasztja az IT és üzleti részleget egy iteratív sikeres projektté. Ebben az üzleti részleg birtokolja az adatokat, és érti, hogy milyen jelentősége van a mindennapi üzleti folyamatokban, az IT részleg pedig definiálja a szükséges adatminőségi normákat és folyamatokat.
Az adatminőség-pokol 9 köre – a Föld
Ki itt belépsz, hagyj fel minden reménnyel

Ez a felirat fogadta Dante Poklának bejáratát. A vétkek súlya szerint helyezkednek el a Pokol egyre mélyebb köreiben a bűnösök aszerint, hogy milyen mértékben sértették meg isteni és a természeti törvényeket.
Ne félj, nem fogunk egyből a pokolba leszállni, ma még csak a Földön fogjuk elkövetni a bűnöket az adatminőség földi világában, hogy aztán megbűnhődjünk a pokol egyre mélyebb bugyraiban.
Az ok, hogy a pokolban kötünk ki: csak az Egyesült Államokban évente több, mint 600 millárd dollárba kerül a gyenge adatminoség.
Vegyünk csak egy példát. Aki feliratkozik a migration.hu oldalon, hogy letöltse a tanulmányt, az beírhat egy családi nevet és keresztnevet. Mondjuk beírja így, mert siet:
Családi név: Kiss
Keresztnév: Gáza
A levelezőrendszer ilyen kezdetű levelet fog küldeni első alkalommal, ha nem javítom ki kézzel:
Kedves Gáza!
…
Gáz, nem? Hibás a felhasználó, mert o írta be így a nevét, hibás vagyok én is, mert nem nézek meg minden egyes nevet, aki megadja az email címet. Mondjuk nekem még nincs százezres nagyságrendű adatbázisom az érdeklődőkbol, de mit csináljak akkor, ha naponta jön 2000 látogató az oldalra, és ebből 400 megadja a nevét és email címét?
Manapság egyre inkább internacionalizálódunk. Ennek többek között olyan hátránya is van, hogy a vállalatok többnyelvű szoftvert használnak – mert esetleg nem minden Gizike tud angolul – és vannak szavak, esetleg földrajzi nevek, amelyek máshogy tárolódnak az adatbázisban. Például a holland Hága városa 52-féleképpen írható le: Den Haag, Den Haague, stb. El tudod képzelni, hogy mi történik akkor, ha például a vállalat piackutatást szeretne folytatni ebben a városban, és címeket gyűjt az adatbázisból?
Így láthatod, hogy milyen könnyen keletkeznek a bűnök, amelyeket az adatminőség poklába vezetnek. A következő bejegyzésekben végigmegyünk a pokol mind a kilenc körén.
Piackutatás 2 – a negatív statisztika okai
Az elozo bejegyzés a számai alapján láthattad, hogy az integrációs és adatmigrációs projektek nagyon nagy százaléka nem sikeres. Felmerül a kérdés, hogy mi ennek az oka?
Ha elviszed a 15 éves autódat a szerelohöz rutinellenorzésre, elso pillantásra a tapasztalt autószerelo azt fogja mondani, hogy két nap múlva készen lesz, és kapásból felsorolja, hogy mit fog átnézni és cserélni. Ha a harmadik napon felhívod a szerelot, vajon mit fog mondani?
“Kedves Uram, ennek az autónak sokkal több baja van, mint amit elozoleg sejteni lehetett. Ez az autó egyáltalán nem volt karbantartva, a szervízkönyvben is látszik, hogy néhány kötelezo szervíz hiányzik. Ezen kívül van néhány olyan hibája, amelyhez nincs megfelelo muszerem, és el kell vinnem a Hiper Diagnosztikai Garázsba, hogy a pontos okot megállapítsuk és kijavítsuk.”
Ha nem látod egybol az analógiát, akkor segítek
- A tapasztalt autószerelonk rosszul becsülte fel a munka nagyságát az elején, és hiányosan határolta körül a feladatokat számodra.
- Az autószerelo muhelynek nem volt mindenhez megfelelo eszköze
- Bizony, te is hibás voltál, mert nem tartottad eléggé karban az autót.
Az adatmigrációs projektekben szinte elenyészo annak az oka, hogy a migrációt végrehajtó csapat tapasztalatlan, ill. elso projektes. Legkritikusabb probléma a feladat körülhatárolása ill. becslése az adatmigrációs projekt elején. A megfelelo szoftverek használata és azok megértése is fo hiányosság. Emellett a forrásadatok minosége a legtöbb esetben kivánnivalót hagy maga után, és ez még bonyolultabbá teheti a migrációt.
Ezen kívül van nehány kisebb súlyú, javításra szoruló körülmény, amelyek felsorolását meghagyom neked. A kisebb súly nem azt jelenti, hogy ezek hiánya miatt a projekt még sikeres lehet, hanem azt, hogy kevesebb százalékban fordult elo, mint sikertelenségi tényezo. Tehát ezek is fontosak, és meg kell oket is említeni ebben a blogban. Megoldás közzététele 1 hét múlva (vagyis nem a következo bejegyzésnél).


















english
magyar
