Saturday, September 18, 2021

More than a year later

 So here we are almost a year later and I'm still cleaning up IBM's handwork.

But they're not the only culprits, even as the recent Right Angle upgrade shows. Even our own employees don't document or communicate their work. 

Having said all this, I wish for a few of our IBM people back. People with good attitudes who could get the work done.

So, the re-engineering continues, but under new (better) management. 

The management in the last few years was utterly atrocious. I don't even know where to begin, so I won't.


Monday, August 31, 2020

Cleaning up - the aftermath

IBM has been gone for a month or so now. Some of their handiwork has become apparent not just in the reverse KT sessions, but in what was NOT transferred.
In our "successful" transition to SAP, someone from Deloitte dropped several balls and missed doing 2 important reports. One being more critical than the other. They managed to slap something together in eHana which really didn't need to be done. To complicate things, this became a 2 part process where I loaded data and they reported it on a schedule that assumed it was there.(and sometimes it wasn't)

THEN, to make matters worse, they depend on SAP tables that they shouldn't depend on which restrict data and no one knows who maintains those tables. Then, Deloitte's contracts ends and they "hand" it off to the Business Intelligence group which has no clue what this does or how it works.

On the other report, IBM had (without talking to me) created an SSIS package and SSRS reports and scheduled them. They did a little KT at the end, but what was done was mostly useless as they used horrible naming schemes, left things in staging tables but used them as production, and scheduled reports to run under their own userid which expired right after they left. What a mess!

Sunday, March 1, 2020

Running. Resume in hand

The end is near and the contractors see it, so they are running with resume in hand and taking whatever knowledge they had with them.
A year ago, one of them was let go for cost saving and the documentation I was given was extremely outdated. When drilling down on questions I got non-answers or contradictory ones. Support had to go one and it got very difficult.
So the mainframers are nice guys and they are what's left (thought not all). They will remain through the SAP transition to archive stuff, but that's it.
So the bigger question surround the SSIS guys. One of which is pretty useless. No one seems to have a good handle on what's happening with them except that they will be removed from the account.
I've been told that their work will go to someone else, but no news on that. My guess it will go to the same guy who doesn't support the stuff he's supposed to now.

Wednesday, September 18, 2019

coming to an end

With the mainframe conversion to SAP, we are left with 3 onshore resources, one of which has found another job. We have some non-mainframe resources still in India and we depend on them pretty heavily. Jan 1 is a cutover. What is going to happen to the resources is still up in the air. Who is going to take over the work is also a question that hasn't been answered. But at this point, we'll be sad to see them go.

Wednesday, December 12, 2018

Things have greatly changed. Almost of of our outsourced resources are gone. Some went to better pastures when they saw the writing on the wall and some were forced out due to lack of activity and the work was forced back onto the unsuspecting business analysts who are mostly unable to support the applications going forward.
Of the remaining, most are now the dependable ones. There are still a few laggers but the onshore presence has dropped greatly. The bulk of the remnant is mainframe based and will go when the mainframe is replaced. At that point, basically all knowledge of the systems will be lost.
There is little to no backup for applications today, even critical ones.

Tuesday, May 6, 2014

How to really tick off a customer account

So about a half year ago, a "subcontractor" is hired onshore. This is good for the vicinity factor (although we never see him) , for language clarity and for work time zones. There was much rejoicing. But it was short-lived. So to bring this guy up to speed, I pay him a visit in his first week to give him a rundown of what's where and what he needs to look out for. He falls asleep in an hour. OK. I get it. I'm boring. He didn't seem interested to start with. Then I got a hold of his resume and was less than impressed. Didn't seem to stay anywhere for more than a couple months. That means no one wanted him. So, we put him to work and he seems to know the technology a bit. Enough to kind of make it through. He can do simple stuff, but there are some things he's just not competent in. And this guy is going to support a critical system?!?!?! One thing that's different about him is that his estimates are very small. Other people guess 40-80 hours. He guesses 4-8 hours. And he's more accurate. Wonderful. Now if no other bugs were introduced into the program.... So he creates EXEs and copies them out to directories, but has no clue how the user is accessing them. I tried to explain terminal servers and Citrix, but it went over his head. At one point, the SQL db server moved. The program became unbearably slow. So I tell him to drill down and figure out what is causing it. He tells me that it's because I had him change code a week ago. I try explaining the effect of a server move and latency, but again, it's lost. Finally, I can't take any more of this and I go in to test and find that the form in question is calling in the entire customer master to grab a few fields from one row. Not once or twice, but 3 times. (not blaming this on him. Someone else wrote this lunacy) I tell him what lines of code to fix and it more or less fixes the problem.
So who would have though that his own organization would come to us and ask if we wanted to take support for this technology back? That is one request we actually loved to hear. I think we'd been through 3 guys after they let go the guy who originally wrote/rewrote those systems. (that was a bright move) So we agree on a date about 4 months out. Two weeks before, he mentions that he knows what is coming and asks me if I still want him to work on things assigned to him. Not thinking that 4 days later, in the afternoon, his company asks us if it's OK to let him go a week early. Before we can respond, he sends out an email telling us he's done and it's his last day. What an embarrassment. So to breach the contract, they let this guy go a week before he was scheduled, forcing us to suck up the support. Good thing I wasn't on vacation or sick. They gave us an apology and said that it was something about a policy on subcontractors from above that they had no control over. I asked how many other companies were affected and "they didn't know". So what I read here is that there's more to this story than is being told. They wanted him gone either because of expense or because he fell asleep at his desk all the time. But still, cutting the last week...that was a slap in the face.
Fortunately it's only a week and nothing big is planned. Thankfully the servers are all moved and nothing else needs to be done.

Sunday, April 7, 2013

Several months ago, the company was bought out. We not only changed owners, but departments merged. The people who thought that outsourcing as a good cost cutting measure are gone and the old school people are back in charge, but since contracts are in place, there is little to do. So, it becomes evident that we are back to doing the work. In cases where there's not much choice, we use them, but otherwise do the work ourselves. This leaves little room for higher thinking and planning, but sometimes gives opportunity to review software we were less familiar with. And so we wait for the end...