Clients are now being loaded with a marginal number of rejections.
The GIS configuration issues still have an impact but that problem is being solved quickly.
I'm still around the report load query problem, but it is not easy to test the performance on a slow system, since it takes too much time to process a query and return its result.
Wednesday, January 6, 2010
Day 273 - Configuration Issues
The GIS configuration is changing and that has a direct impact in the mapping rules.
We are now facing an increase number of data being rejected by GIS because its configuration has been changed but the mapping hasn't.
We are now facing an increase number of data being rejected by GIS because its configuration has been changed but the mapping hasn't.
Day 266 - Christmas Break
The project will be stopped for a short Christmas break.
The overall number of data being rejected by the GIS loader is decreasing every day.
But we are now facing a performance problem again. It takes too much time to query GIS in order to know how many errors and what time of errors occurred in the loading procedure. I'll have to take a look at these query performance so that the loading report does not take half-day for a simple auto claim data load.
The overall number of data being rejected by the GIS loader is decreasing every day.
But we are now facing a performance problem again. It takes too much time to query GIS in order to know how many errors and what time of errors occurred in the loading procedure. I'll have to take a look at these query performance so that the loading report does not take half-day for a simple auto claim data load.
Day 264 - Error Free Loading
Finally we are start to get error free data loading.
Some types of clients are already loading into GIS and this is reducing the number of claims rejected by the GIS loader.
I'm expecting to stop worrying with client problems soon.
Some types of clients are already loading into GIS and this is reducing the number of claims rejected by the GIS loader.
I'm expecting to stop worrying with client problems soon.
Day 260 - Problem Prioritization
The problem solving problem is finally being solved.
Management has prioritized the problems to be fixed and is now working faster in the problem assignment.
Management has prioritized the problems to be fixed and is now working faster in the problem assignment.
Day 253 - Problem Solving is a Problem
Some problems do take too much time to be solved, they get stacked in the sponsor queue. Sometimes management does not assigned the problems by the team members fast enough, sometimes the team depends on other people and sometimes the team simply does not have a quick answer.
This is a real problem since we are now facing a dependency problem.
There are unsolved problems in the client area which is keeping clients to be integrated in GIS. And since there are clients missing, many claims are being rejected.
And since there are claims rejected, account is also being rejected.
This requires a fast answer from the management in order to be solved.
This is a real problem since we are now facing a dependency problem.
There are unsolved problems in the client area which is keeping clients to be integrated in GIS. And since there are clients missing, many claims are being rejected.
And since there are claims rejected, account is also being rejected.
This requires a fast answer from the management in order to be solved.
Day 250 - Team Rearrangements
There is a team management small problem.
The teams seem to be rearranged from time to time and this instability is not good for the sake of the project.
For instance, one person that was responsible for the client data migration, has been reassigned several times to other areas, like account and claims, and is now in the testing team. Two other people started to be responsible for the client data migration, one for each system, but it seems that the new people depend on the initial person.
There is another person that is responsible for the data extraction for one of the source systems but it seems now that it is also part of the mapping team.
This happens less on other areas, but it seems that there is an unofficially set of people that is assigned to all areas.
There is a clear group help spirit, which is great, because this eliminates political problems as "this is my migration area, so keep out".
The teams seem to be rearranged from time to time and this instability is not good for the sake of the project.
For instance, one person that was responsible for the client data migration, has been reassigned several times to other areas, like account and claims, and is now in the testing team. Two other people started to be responsible for the client data migration, one for each system, but it seems that the new people depend on the initial person.
There is another person that is responsible for the data extraction for one of the source systems but it seems now that it is also part of the mapping team.
This happens less on other areas, but it seems that there is an unofficially set of people that is assigned to all areas.
There is a clear group help spirit, which is great, because this eliminates political problems as "this is my migration area, so keep out".
Subscribe to:
Posts (Atom)
Posts
