I've already replied to Mark offline, but I'm posting here in case my experiences are of interest to anyone else -
It probably depends on who you ask! I used to work for a supermarket chain in the UK and we outsourced in 2006. This included z/OS, and the outsourcer was one of the larger Indian owned companies. Their business model was such that the pool of talent they called upon was based on the business area that the client was in. So, for example, if you were in retail, your outsourcing centre might be Chennai, if it was finance it might be Hyderabad, and so on. The problem with that was that the retail outsourcing centre had virtually no z/OS skills, and due to internal cost considerations they were very reluctant to use colleagues from other parts of the business. We were short of sysprogs at the time as a couple of people had left, and they supplied us with two guys who had no sysprog skills whatsoever. Once was an Ops Analyst so at least he knew z/OS from that perspective, but the other guy had a Windows background. I don't think he'd ever seen a mainframe before. So we had to spend months training them to get them to anything like a reasonable standard. Another issue is that they continually rotate people around different accounts, so as soon as one does start to get a bit familiar with your setup, they'd be moved somewhere else. This applied to managers as well as technicians, and again, the managers that were imposed to manage the z/OS sysprogs and Ops Analysts had no mainframe experience (in fact elsewhere, at another company, the Ops Analysts were generally referred to as the Opans. The no-mainframe-experience manager that was put in charge had obviously never even heard of an Ops Analyst never mind knew what they did, and having misheard the name subsequently referred to them on all documentation as Op Hands). The user base gets very frustrated with a help desk who are completely unaware of any of the in house systems they support, and cannot do anything without a script. I'm sure UK laws were broken as far as redundancy goes; I don't know all the ins and outs, but I believe that you can only make someone redundant if there job no longer exists at that location, or close by. So, if the role moves to India, that obviously you out the door. But we probably had close to half the Indian team working in the UK, and probably more in some areas such as the Wintel team where there was a lot of hands on work in the data centre. They replaced UK workers who had trained them up (sorry, completed the "knowledge transfer") and had then been made redundant. The outsourcer will tell that they can do absolutely anything you want, no matter what it is. Only after they have the contract do they start to wonder how they can actually do it. There are cultural differences too, such that they will very rarely question what they've been asked to do. It doesn't matter if it doesn't make sense, if there's a better way to do it, or if it's just plain stupid - it's the requirement, so that's what we'll do. There is also no incentive for them to improve things unless they get paid for it - as an Ops Analyst I'm thinking of all the myriad of useful ISPF utilities we'd knock up for one thing and another. That all stops. Similarly, quick fixes and user enhancements that the Apps guys would deliver as part of BAU all had to be costed and paid for. BAU only covered fixing something that was down, invariably it wouldn't even address the root cause of the problem - that would be an enhancement. Another outsourcing contract to a telecoms company resulted in simple requests to lay a cable in the data centre costing several hundreds of pounds, including something like 20% "project management" costs - something the in-house guys would have just got on and done in about 15 minutes. Cultural differences go beyond that though, in many ways there seems to be a lack of any organisation. An ex-colleague still works for them and finds it very frustrating. He has countless stories of meetings being cancelled at the last minute (or even after they're supposed to have started) even when he's travelled to London especially. One time he was told he must go to a client site when he thought that the meeting could have been perfectly well conducted by telecon. No, you must go, he was told. He got there only to find he was the only one there, everyone else had dialled in and the client was giving him funny looks wondering why he was taking up a whole meeting room by himself. Another time he had to fly to Denver for a three hour meeting where he didn't say anything as it wasn't relevant to him. So, are there any good points? As I said at the start, it depends who you ask. At least when you phoned the helpdesk it was answered quickly, even if they couldn't actually help you. Previously with a limited number of staff you could often be waiting in a queue for 10 minutes, often far longer. They have the resources to throw at an issue, so a project to move off a load of old Wintel hardware was actually completed quite quickly having been making little progress over several years prior to the outsourcing. At the end of the day, I'm sure it's much cheaper which is often all that the senior management are interested in. So, in summary, I'd say from the technician's perspective it's pretty bad and very frustrating, especially if you take pride in doing a good job; from the user's perspective it's incredibly frustrating and from the management's perspective it's very good! -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Wilson Sent: 24 February 2016 10:31 To: [email protected] Subject: Outsourcing Stories Good or Bad! I am working with a client in Europe that is being requested by his senior management team to look at outsourcing their IT systems, including their system z platform. Would anyone be willing to share any war stories of their experiences with Outsourcing good or bad? Offline from the list via email or for anyone attending Share in Texas willing to have a coffee/beer and discuss face to face. Mark ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
