Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.
Wednesday, August 1, 2012
At some point, most IT leaders or practitioners will run up against the conflation of the terms “customer” and “user” within the context of managing a program, project, or service. This is especially true for those of us who cut our teeth implementing business applications such as ERP or Student Information Systems. On the one hand, during those projects we tend to involve large numbers of end users in the requirements, design, and acceptance testing process; these activities tend to give their participants the opportunity to define the solution. We take our cues from them and tend to want to make them happy; to the business systems analyst or functional consultant these end users are without question "the customer.”
But the harsh reality is that most of those end users do not pay the bill, so to speak. According to several management frameworks -- most notably the IT Infrastructure Library (ITIL), at least in my world -- the term "customer" should be reserved for those who pay; such an entity often represents the interest of many end users, and may or may not be a user herself, but critical differences in priorities, needs, and influence exist. For example, users may desire additional features but the customer may not want to pay a premium for those features. Unfortunately, service providers are often stuck in the middle. To exacerbate the problem, there may be cases where the (paying) customer refuses the surcharge but delivers the message to their users in a way that ascribes blame to the service provider rather than own up to her decision(s).
The problem of differentiating customers versus users can be especially acute for those individuals serving in the perhaps-misnamed function of "customer service." These folks may never have a direct interaction with the Big C Customer, but instead stands on the front-line fielding complaints, concerns, and issues (and occasional praise) from the users, the actual consumers of the service we provide. People in customer service roles often land there by virtue of a passion for helping people and solving problems. Their relationship with the user community is tangible and grounded; in the same way they seldom interact with customers, their managers and managers' managers seldom interact with the users. This disconnect presents real challenges, especially when organizations start rolling out IT Service Management and try to re-align processes and functions to meet the boilerplate from the Crown.
At a recent all-day retreat for my organization, we had a group activity on stakeholder mapping. It was not entirely successful, except insofar as it cast light on this divide. In fairness, we face a few (not quite) unique challenges that make a complicated problem worse. First, the issue of being an internal service provider. We are a pure cost center; no revenue flows into my organization. In such a context, we cannot define "customer" by virtue of bill-paying criteria. But we ought to be able to think in terms of leadership, right? Except that our institution is extremely decentralized. And unbalanced: not all organizations are created equal. Some organizations (the schools, in our case) indirectly pay (via a central assessment) for our services, whereas other units in Central Administration, funded from that same tax, receive the services "for free." And then there is the issue that in some cases we provide services on behalf of another unit in Central Administration. So is that unit -- and that unit only -- our "true" customer?
All of this isn't to say that user satisfaction isn't important. At the end of the day, the customer, whoever that may be, will not be happy if the users are banging down her door, rioting in the hallway, screaming in her ear, or otherwise demonstrating discontent with the service. We have to listen to the users; they are the subject matter experts, they do the work of the place. It is tricky business to simultaneously roll out new user satisfaction tools and say that users aren't really the boss.
The problem is that we know we cannot meet their every desire. For us to succeed, we need customers who prioritize, advocate for their users, and communicate with their users when a request does not move forward.
For this to happen, we need to formalize our Business Relationship Management (BRM) processes and develop a clear, (relatively) jargon-free customer outreach packet. In addition to obvious content such as org charts and walk-through of our service catalog, this document articulates the tension between customer service and user demand and defines the relative roles and responsibilities on both sides of the service delivery process.
In the end, we walk a very fine line! But recognizing these tensions is certainly a critical step in helping us keep our balance.
Labels: ITIL, ITSM, Management
Saturday, July 28, 2012
The adoption of industry standards is not easy. Even if it were, Higher Education does not tend to join the vanguard for information technology (with the recent exception of BYOD, for which many industry leaders looked toward the successful model in higher ed). So we, like many peer organizations, are only now starting to implement IT Infrastructure Library (ITIL) practices for IT service management (ITSM).
During the first year of our journey (July 2011-June 2012), we focused was on education and awareness; through a combination of online training (via Element K - now SkillSoft) and classroom training we have achieved 75% training and certification despite also completing four major ERP upgrades and a half-dozen other projects in that time frame!
But with awareness come many questions, including the obvious: "what next?" Indeed. Before one can decide where to go from here, it is wise to think about current state challenges across the dimensions of People, Process, and Technology.
People
- How receptive are people to change?
- Do we have the skills necessary for ITIL adoption?
- How will existing job descriptions or organization structures change?
- Do people understand "the why" for adopting ITIL?
Process
- Our existing processes are already wrapped in red tape; can we seriously be considering the layering on of more rules?
- Which aspects of our work are actually "IT Services?"
- Which of our existing processes best fit with ITIL? (low-hanging fruit)
- Which of our existing processes least fit with ITIL?
- How does ITIL relate to other "new" processes such as Agile/Scrum?
Technology
- Do we have the tools to track / measure our services?
- Do we have the tools for customers to request our services?
In my organization, we realized quickly that the top priority had to be Service Catalog and Service Portfolio Management; scary as it may seem, no one individual in my department had a complete picture of all the services we provide. Given our segmentation into logical silos based on line-of-business and/or vendor product (Oracle EBS, PeopleSoft Enterprise, Hyperion Planning, Grants Management, etc.) this was not particularly surprising to me; what was surprising was the size of the list once it was collated!
The development of a Service Catalog has proven no easy feat. It has taken several months to create initial drafts of service definitions and load them in our internal Atlassian Confluence portal. Internal reviews have been difficult to wedge in between other commitments (sounds like we need to move on Capacity Management, huh?) We are hoping to go live by the end of the summer!
My personal journey to adopt Service Strategy best practices has already begun. In addition to shoring up my understanding of the processes in this volume via ITIL Intermediate training and certification (halfway through The Art of Service online module), I am actively thinking about how to more formally implement Business Relationship Management and Service Portfolio Management over the next twelve months.
Within my organization, the natural follow-on activity to publishing a Service Catalog (to be properly ITIL I guess I should say “catalogue?) is to formalize service levels and implement the necessary controls for Service Level Management. But the major focus for us in the new fiscal year will be Request Fulfillment and Knowledge Management.
I expect it to be an interesting year and will be back soon with more observations and thoughts as we travel down the road.
Labels: ITIL, ITSM, Management, Service Catalog
Thursday, September 15, 2011
Every summer I sit down for 30 minutes with the members of my team—roughly forty business analysts, systems operations analysts, product managers, and project managers. I inherited this tradition from my predecessor and the first time around I found it to be a valuable undertaking—challenging as may be to execute forty-odd sessions in the vacation-rich summer months!
When I was new to my position the approach was rather straight-forward – I simply asked what staff members thought was going well (or poorly) in the department and what they were looking for from me as a leader. In those early months, their suggestions, questions and concerns were huge. And although I had no doubt about the value of repeating the exercise, I was fearful that repeating last year’s “agenda” could be a recipe for long stretches of silence.
I crave staff input – I want to understand everything: motivators and de-motivators, career objectives, opportunities for improvement for the department and the institution. Furthermore, as months upon months of Sunday’s “The Corner Office” in
The New York Times has taught me, it is equally important to understand individual likes and dislikes, favored weekend activities, favorite books, etc. And as a part-time cinephile and foodie, I wanted to ask about favorite movies and meals!
Too many questions, too many interviews, and too little time: I needed a system. Being an applications guy, I entertained the thought of building a systems solution myself… Or scouring the App Store. But then I realized (for once?) that technology was not the answer.
Hidden away in a filing cabinet outside my office was a laminator. I blew the dust from the lid, framed out my discussion prompts using an MS Word label template, pre-heated the laminator, ran my labels through, and located a long-abandoned paper-slicing guillotine stowed behind a copier on the second floor. Interestingly, nobody inquired why I was partaking in light arts and crafts on a Tuesday afternoon.
The next morning, I had my first of 40 interviews. The rules were simple: for the first 20 minutes, you draw questions from the bag; we’ll leave the last ten minutes to talk about anything else on your mind; in that time you’re free to turn the questions around or continue drawing prompts.
It worked. The conversations flowed nicely, a neat balance between quasi-interview and idle chit-chat. By the second week, rumors about “the bag” (a very snazzy Whole Foods fabric bag with ample room to shuffle the laminated cards) had circulated but since the average participant only saw about 30% of the questions most people were still surprised by the questions. (Although toward the end I fielded several prepared responses to the exceedingly difficult “vegetable” question).
On the corner of my desk is a legal pad filled with detailed notes from these discussions – I have started to pull out key themes, insightful quotes, and lists of the eclectic musical and movie tastes in the department. I feel closer to the team, more aware of their needs and personalities. I am proud of my “innovation” (quotes because it is unlikely I can claim IP over this technique) but already thinking – what shall I do next year?
Labels: Innovation, Management