Let's import some data. quick!
-
Some people have a very long time ago started project, here, that plan to globalize the human ressources management of over 10.000 employees. 2 years before I said our intermediate management, during a related meeting, "don't forget to discuss with all IT services about the way they manage their own datas". After that, I totally forgot that project, I thought it had failed and was abandonned, no more informations about. Today we had that meeting ("Ho, the beast is still alive?"). And it was very interressant
- We have less than 3 months to convert our datas (good news, now we know the deadline)
- We still don't have technical details (that would be too easy)
- Against everything that was said before, we won't import our datas to the global system. No, our intermediate management will export the global 2000+ people datas (including our 200+) they have the responsability over to the final system themselves
- We have the responsability to import our 200 data in the intermediate system
- This is mission critical buisness, if we fail deadline or datas are corrupted, we will be forced from the actual, not very good working automated payement system, to a situation were all payement are to be done manually, for one year.
- This intermediate mission critical application that will handle the 2000+ people data and where we have, ourself, to import our oracle based datas, is written in f*** access. And last time i saw it, it was a piece of crap.
In the end our datas will do: Oracle -> mdb access file (no idea of specs) -> another mdb access file (not our problem)-> an obscure export format -> another oracle server -> oracle's peoplesoft database.
Did i say we have absolutely no idea of the format the mdb file will be in? And to fill it, it might be necessary to modify our own homebrew people management application to add missing field and ask our RH to fill them? And there will probably be tons of them? Maybe be, we will have an idea before end of month. Maybe....
I smell the parfume of failure floating around, don't you?
- We have less than 3 months to convert our datas (good news, now we know the deadline)
-
You haven't had much to do with enterprise systems before, have you? This all looks perfectly normal to me.
Access is a perfectly good system to use as an intermediate data-cleansing layer. It lets you do bulk updates, create little mapping tables to convert old tables to new, lets you edit individual problem data items by hand and it has enough scripting capability to produce whatever tab-seperated fixed-width format the mainframe wants.
So long as the time frames and resourcing levels are reasonable, then there's no WTF at all. If I was given the assignment of "please write an Access database to convert 2000 employee records into {this format specification in Excel} by Friday" then it would be a little tight, but probably not a WTF. If it's only 200 records then I would suggest a 10-finger interface instead of Access but only because I am lazy.
-
it's not a clean layer, it's a complete application scavenged to serve as an import layer, with lots of useless mandatory informations. Importation must be reproductible anytime in the future, as the new system is not supposed, before 2 years, to replace our current system. So it must be full automatic. The deadline we can't miss is the test importation dedaline. If we miss the test, we have to wait 1 year for next batch of test.
Ho, did i say we have MAX 3 trial for importation before we are ejected from the process and have to wait next year? Funny :)
The resourcing? No, i'm given the choice: either we miss that deadline, either i delay our current project which is supposed to replace one of our mission critical tool that can fail anytime now. On both end, if it fail we lose lots of money. And we have to do with that sh** application because our management didn't have the resourcing to put an importation layer (from csv, xml whatever) on the intermediate system.
Considering the reaction amongst all people around the table, am not the only one to consider them crazy :)
-
@tchize said:
I smell the parfume of failure floating around, don't you?
DUDE!!! Thanks for my epic new signature line!!!
(Oh, and here's my other new sig line: "Don't take this the wrong way, but every time you enter the room it smells like someone smeared shit all over my face.")
-
Dude, you clearly have not had much experience with either project or conversion work (or you believe all the BS they teach in Uni classes). My team and I started a conversion project last year, first task was to document the Collection, Cleanse and Convert process, unfortunately we were given access to neuther the source, nor the target systems and were expected to write our processes. It hasn't gotten much better since, though we are on Prject manager number 3... I've started referring to them, not by name, but by number.
Your one looks like a dream to me.
-
The big problem I've found with data migrations* is the gulf between how long experience tell us it will take to do properly and how long the client thinks it will take...
The data is never clean.... The rules always have exceptions... There's always something you're not told and have to find out the hard way... Etc...
*of any reasonable size
