And saving costs is just what the OP's managers are seeking to do by 
outsourcing.

Of course, outsourcers will always present their case in the best financial 
light to gather business, and their business is to make a profit. In my 
experience the savings they advertise are rarely achieved (I've worked on both 
sides of the fence).

The outsourcers generally provide a maintenance contract, typically taking over 
the hardware, operators and system programming staff. Under that contract, 
anything outside normal maintenance of the system(s) is chargeable. Want extra 
functionality coded in an exit? Pay for it. Want an unscheduled IPL to enable 
that exit? Pay for it. Want that exit debugged? Pay for it. Just want a dataset 
temporarily APF-authorised to evaluate a product? Pay for it.

War Story 1: I was working at a certain Australian Federal Government 
department who had outsourced to a certain mob with an Australian presence 
(whom I won't name except to say they like to be known as a large colour). I 
was helping test an upgrade to z/OS. I saw that a couple of exits had been 
back-levelled, and there were a number of inconsistencies in PARMLIB. I 
realized that they had taken a copy of the production system to apply the next 
z/OS to, and had not bothered to refresh it with any of the production changes 
since. Lazy, unprofessional, or n00b stuff. Most of the errors were fixed 
immediately, but I kept complaining in our monthly meetings that they had left 
APF-authorized a few redundant, deleted datasets. When I gladly left some 
months later, those dead APF entries were still there. I believe it was simply 
because they couldn't justify charging us for that change, and there were too 
many hoops to jump through on their side to delete those APF entries without an 
associated cost code or something, so it never happened. 

War Story 2: Same place, same outsourcer.  A z/VM system was being implemented 
to host file/print servers (we had not had a z/VM environment previously). When 
I was looking at the supplied RACF database, I saw a whole mess of userids and 
profiles that simply didn't belong. They had taken some-one else's z/VM RACF 
database (I know it belonged to a particular New Zealand-based bank) and dumped 
on our system instead of providing a pristine environment. Job done. I ripped 
into them, told them (and my management) they had just given us a security 
system that allowed unauthorised people to log in with operations and systems 
programming access levels. In the end I had to go through the database and 
provide the outsourcer with a list of exactly which userids/profiles to lose.

At the risk of repeating what others have said, your management needs to put 
together a solid contract with all costs clearly spelt out, ideally with 
defined service level agreements/objectives and penalties if such aren't met 
(e.g. if Mr. Outsourcer hasn't made that PARMLIB change to delete 
APF-authorized libraries yet, we'll start charging you!). I think it would be a 
good idea to keep at least one person with solid skills to liaise with them at 
a technical level and to keep an eye on what they do, since my experience is 
that you can't necessarily trust them to do a complete or professional job, no 
matter what their reputation.

Ant.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of baby eklavya
Sent: Sunday, 28 February 2016 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

*"The saddest part was the manager was not even literate on zOS systems.
All he knew was to save cost. So slowly most of the wannabe system programmer 
left. Now he wants a 2 year experienced guys to run equal to his
peer."*
This is exactly what i was trying to convey . At the end , they never save 
anything . Whatever money they think they had saved by replacing experienced 
staffs with freshers goes out again in the form of penalty , missed SLA , 
change failures .

Skill shortage is just one side of the story . When the work environment is 
controlled by such managers who only focus on saving cost , life becomes too 
difficult for beginners who want to learn and enhance their skills .
They eventually lose their interest in the technology  .

I remember a recent quote from Forbes.com -   "People don't leave the
companies , they leave their managers"



On Sun, Feb 28, 2016 at 11:08 AM, Jake Anderson <justmainfra...@gmail.com>
wrote:

> Hi
>
> Looking at this discussion I really wanted to share something over 
> here which was shared by one of my colleague.
>
> One of an American ISV company off shored their work to India.
>
> The technicians in India wanted to get trained in many areas like zVM 
> but the Indian manager was too hesitant and said there should be lot 
> of tickets or incidents so that he can get a training. The saddest 
> part was the manager was not even literate on zOS systems. All he knew was to 
> save cost.
> So slowly most of the wannabe system programmer left. Now he wants a 2 
> year experienced guys to run equal to his peer.
>
> So this is one of a case where they are not interested to address the 
> skill shortages.
>
> Jake
> On Feb 27, 2016 5:26 PM, "baby eklavya" <baby.ekla...@gmail.com> wrote:
>
> > As i stated earlier , i didn't intend to offend you . I don't have
> anything
> > personal against anyone in this list .
> >
> >
> > *"If you read what I said instead of sending out the first thing 
> > that
> came
> > to your mind, you would understand that I basically agree to 
> > everything you've said here, and that I've literally conveyed the 
> > same points"*
> >
> > If that's the case , I am happy for that and i apologize if any of 
> > my comments did offend you .
> >
> >
> > On Sat, Feb 27, 2016 at 2:33 PM, Sankaranarayanan, Vignesh < 
> > vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote:
> >
> > > To the person hiding behind a misnomer,
> > >
> > > " And there would be hundreds of people like me in this list who 
> > > would agree to what I am saying ."
> > > If you read what I said instead of sending out the first thing 
> > > that
> came
> > > to your mind, you would understand that I basically agree to 
> > > everything you've said here, and that I've literally conveyed the same 
> > > points.
> > > Am I arrogant? Of course I am, everyone is in ways they want to 
> > > be,
> but I
> > > don't believe I was with regards to this mail chain.
> > > Am I an amateur? Of course, I'm not arrogant enough to think I 
> > > know everything.
> > >
> > > – Vignesh
> > > Mainframe Infrastructure
> > >
> > >
> > > -----Original Message-----
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of baby eklavya
> > > Sent: Friday, Feb 26, 2016 11:32 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Outsourcing Stories Good or Bad!
> > >
> > > Vignesh ,
> > >
> > > Please stop this arrogance...This is not a place to cry for the 
> > > lack of education / exposure you didn't get on the Mainframe . I 
> > > am from India
> > and
> > > i respect the technicians in IBM MAIN a lot . When i started my 
> > > career
> on
> > > mainframe , nobody was there to train me on the subject which i 
> > > badly wanted and i was so scared to take up tasks on zos fearing i 
> > > would mess
> > up
> > > something . Then i had to survive and started learning myself 
> > > using the
> > red
> > > books and a lot of other documents available online .But then i 
> > > found
> IBM
> > > MAIN . This is the community which inspired me to stay on this
> technology
> > > and Now i have completed 12 + years on zos and i owe most of my
> knowledge
> > > to the legends here .
> > >
> > > Like Ed said , this is not a one way street . If you cannot 
> > > contribute here , at least be polite to others and learn how to 
> > > respect the individuals with such a vast knowledge  and experience 
> > > .You have no
> right
> > > to humiliate list members and if you think you can compare the 
> > > skill
> > levels
> > > ,sorry to
> > > say , they are poles apart .In fact    Unless you put your efforts ,
> you
> > > cannot learn anything . Nobody in IBM MAIN is sharing their 
> > > knowledge because they are bound to . But it is because they are 
> > > real
> professionals
> > > who had been on the system for so long and they know the pain of
> learning
> > > all these concepts .It is their passion and maturity on the 
> > > platform
> > which
> > > is making them respond to almost every query that is being posted 
> > > here
> .
> > > And there would be hundreds of people like me in this list who 
> > > would
> > agree
> > > to what I am saying .
> > >
> > > When management focus on cost reduction , they are not realizing 
> > > what
> > kind
> > > of pathetic service is being delivered to the clients.
> > >
> > >  And those idiots believe that Mainframe can be learned in few 
> > > weeks
> like
> > > windows . "Oh my boy ! what is so difficult in migrating from RACF 
> > > to
> CA
> > > ACF2 on Z/os when you can install Norton Antivirus on Windows 7 . 
> > > After all , both are there to provide security ". To be honest , 
> > > this is the
> > sick
> > > mentality of management folks which has eventually ruined the 
> > > quality
> of
> > > service that is being provided these days . And yes , i have seen 
> > > ITIL fulfillment teams who joins a Severity 1 incident bridge from 
> > > nowhere
> and
> > > keep asking for updates every second . The fun part is that , they
> don't
> > > have a clue about Mainframe . There was an auditor in my previous 
> > > firm
> > who
> > > kept on arguing why cant we setup zos similar to windows where the
> > patches
> > > are automatically downloaded and installed . And it took 2 weeks 
> > > to
> make
> > > him understand what is an RSU maintenance .
> > >
> > > Finally , i don't intend to offend anyone here . I thought of 
> > > writing
> > this
> > > here because I'am a fan of IBM MAIN and i cannot digest such 
> > > arrogance
> > from
> > > amateurs on a list like this which has seen the best mainframe
> > technicians
> > > of the world .
> > >
> > > 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
>

----------------------------------------------------------------------
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

Reply via email to