I have always worked for the Outsourcerer-IBM (which is different than working for "the real" IBM), so I might have some points to bring in:
- Best scenario I've worked was for a customer that kept 1 key-person for each area (z/OS, DB2, etc.). This person would bring historical knowledge, technical knowledge and sense of urgency depending on the situation. Weekly checkpoint meetings kept the teams aligned with what the customer desired; - SLAs MUST be carefully reviewed and agreed. Both sides could and WILL use it "against" the other side. If SLA is met, then no problem, no matter what's going on. Short-term contracts (3-5 years instead of 10-15 years) allow for a better SLA adjustment down the road; - There MUST be some sort of responsibility matrix with DETAILED activites (generic activites like "maintain systems" are too broad). Just by looking at this matrix, you should be able to tell: who's responsible for doing X? who's to be informed about X? who should be consulted if doing X?; - Outsourcers will probably request a lot of documentation (that in-house companies probably don't even have). This is vital! Part of the issues that might come could be avoided with a good documentation to start with; - Projects (processor upgrade, OS upgrade, router replacements, etc.) will most likely be treated like so (PROJECTS). Which means that probably a Project Manager will have to be involved to make teams talk to each other. Some overhead in these activities have to be considered; There are good and there are bad people working on outsourcerers, but I *guess* this is everywhere though, so no news. Where I worked, people tend to "standardize" the systems the most they can after transition has stabilized. This means the less exits, the better. Keep in mind the outsourcerer might have many clients and when someone gets called in the middle of the night it might be hard to remember the peculiarities of one of them. On the other hand teams are usually able to compare cross-customers solutions and propose enhancements should they apply. Hope this helps a bit. Regards, ------------------------------------------------------------------------------------------------------------------------------- *Lucas Rosalen* Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com <lrosa...@br.ibm.com>* LinkedIn: http://br.linkedin.com/in/lrosalen Phone: +48 792 809 198 2016-02-25 18:00 GMT-03:00 Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR) < z...@cdc.gov>: > I'm not going to judge anyone here - but I have always had the attitude > that if someone wants Mainframe help and I can help them - I am going to > help them. I would never have learned half of what I know after almost 30 > years in IT without others taking the time to answer a question or two (or > MANY) over the years. And I for one have learned a great deal just > monitoring these emails that come out on IBM-MAIN every day. I have a > folder of probably 500 emails I have kept over the years - and I still > access them occasionally to fix a problem, etc... There is a great deal of > knowledge on this forum and I for one am very appreciate of the help I have > received over the years - and I have also been glad to offer assistance > here and there where I can. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sankaranarayanan, Vignesh > Sent: Thursday, February 25, 2016 3:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Outsourcing Stories Good or Bad! > > No one's forcing you to Ed. But I'm guessing you're helping around here > because you love what you do, not because you want to help "your people" > alone. > One can't learn a lot from equals, and one certainly can't learn a lot > from those who are (for the lack of a more sensitive phrase) below them. > Sure, if this community doesn't want to help, that means workload mounts > for IBM in the form of a trillion more service requests lol. > But those who are here to learn will find a way. > > - Vignesh > Mainframe Infrastructure > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Gould > Sent: Friday, Feb 26, 2016 1:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Outsourcing Stories Good or Bad! > > On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote: > > > Some thoughts from someone on the other side. > > > > What's the point of saying "Oh, I'm an outsourced nobody." in a post > > where one is asking for help. So you may choose to not answer or sit > > on your high horse and ridicule their incompetence when they're > > struggling? > > If you guys (actual mainframe folk with decades of background) are > > going to compare outsourced folk vs yourselves, you're doing it wrong. > > Most of your outsourced folk are younger than the total experience you > > may have. Of course they're going to be inferior. > > Do you call a baby rubbish because it can't write a sonnet? Yes, the > > baby has no business writing sonnets but welcome to the world of > > outsourcing. > > > > When deciding to outsource, your employer has chosen money over the > > people who have served him/her for a long time. > > Don't take out your anger and disgust on people who are struggling to > > better themselves because they have massive shoes to fill. > > It's not his/her action that has led to you being laid off and being > > forced to accept ridiculous things (train or you don't get your 401k > > or whatever) in your last hours (on the job). > > > > That said, here's some actual feedback which may not be possible to > > implement at all though: > > 1. Exercise as many choices as you must to ensure you do not suffer. > > Try as hard as you can to not accept people who can't speak basic > > English. > > The big man at the outsourcer may not leave that choice to you but > > trust me, this is the root of all the abscess that you're > > (employer) being charged for. > > "This guy can't speak, so let's make him work under some 15,000 > > managers who repeat the same thing without adding value." > > Oh, and BTW, these managers are paid a f*k load more than the people > > working, I would assume. > > > > 2. Offshoring development, IMHO, is the worst thing you can do. > > You want your company to work on code that's written by someone who's > > knowledge is extremely limited, and someone who would keep trying to > > nail everything because he has a hammer? > > > > 3. If you are able to pick the right (technical) people, keep the > > overhead (hey, if we're "resources", what's above us ought to be > > "overhead" right?) to an extreme minimum. > > > > Who knows, some day Watson may make the whole industry go away and one > > machine may manage the other. At that point, you get to say "Ha! No > > more of these 'incompetent masses'". > > > > - Vignesh > > Mainframe Infrastructure > > > ----------------------SNIP-------------------------- > > Then why should we provide expertise for free? > We all learned the hard way with no IBM-MAIN at beck and call. > We developed our own word of mouth partners. You should be doing the same. > > Ed > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > MARKSANDSPENCER.COM > ________________________________ > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us > know and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as > this is prohibited and may be unlawful. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
