seat58F
outsourcing relationships: international, inter-economic, interpersonal
September 4, 2010 ~ 09:45:07 AM * -07:00ST
first, the good news
Post # 323 by
admin on April 28th, 2009 ~ 07:17:47 AM
Posted as change, incident, knowledge, problem, release |
No Comments »
a new release, as a collection of enhancements or bug fixes, is expected to improve overall functionality and service effectiveness. change managers and release planners should be able to anticipate any negative effects, but the communication about those issues to end users or the helpdesk usually does not happen.
at minimum, problem managers need a heads-up to give them a chance to write some sort of release note to give the helpdesk a hint as to the expected impact.
working in the background
Post # 315 by
admin on April 24th, 2009 ~ 09:42:58 PM
Posted as incident, knowledge, problem |
No Comments »
top 5 Level 3 support activities
- taking Level 1 support requests to stay current
- evaluating tickets to mentor Level 1 agents
- evaluating tickets to tune the KDB
- evaluating category trends for service improvement requests
- building proactive end user communications content
delivery manager denial
Post # 48 by
rc on March 13th, 2009 ~ 02:03:56 AM
Posted as change, problem |
No Comments »
just accept it, your service architecture is part of the problem. delivery bugs contribute directly to outages, client dissatisfaction, and unnesessary cost on both sides. if the app development guys can do it, you can too. estimate the population of bugs, identify, document, prioritize and squash them one by one. (Unless the contract allows you to be paid by the ticket - and you really need to own up to that one.)
bad situation #1: recurring service support events ripple negative impacts to the client. so you get more tickets. patch installations and backups are obvious culprits. so too the lack of a structured return to production test suite. establish a calendar and stick to it. have really good reasons for emergency changes. take personal umbrage when a new ticket comes in. some enhanced capability (that the CIO will pay you for) could have prevented that ticket.
bad situation #2: the dependencies between infrastructure elements are not documented for the change managers, so they unintentionally break stuff. yes, comercially packaged configuration mgmt is expensive. yes, you can build a functional app with open source tools. It just a matter of ensuring that 2nd level support feels some ownership for the CMDB and the knowledge base.
bad situation #3: incident records are not analyzed for root cause. just train the supervisors in production statistics 101 and you can save some big bucks. everyone should be able to drive down client cost of service outages by 30%. to get there, the service provider needs 1st level mgmt expertise. Then add some supplier mgmt expertise, and you can talk about reducing your own costs and increasing your margins by engaging a supplier of your own.
Delivery Managers absolutely need to know the client perspective cost numbers, the CIO *will* ask at some point, and it should already be on your private dashboard.
promoting Problem Mgmt
Post # 509 by
admin on January 20th, 2009 ~ 09:59:25 AM
Posted as metrics, problem |
No Comments »
a dashboard for Problem Mgmt is a slam dunk. PM is all about prevention of incidents and alerts, that should easily decode to cost savings.
problem managers are also closely associated with maintenance of the knowledge database and a good KDB offers troubleshooting expertise to people on the front line, either on the helpdesk or in the field. PM investments should always show mean-time-to-repair dropping. If its not the case, then something strange is going on, like the introduction of new services that are not immediately benefiting from PM.
PM should also reduce the number of incidents (productivity increase to both parties) and increased availability (productivity for the outsourcer, reduced escalation cost and increase service improvement bandwidth for the service provider).
