Partnersourcing Your IT Service Blueprint

Beginning October 12, Indiana University's award-winning client services and support division will provide 24/7 IT help desk and support services via phone and e-mail for the students, faculty, and staff on all Ivy Tech campuses. The concept came about during an introductory meeting between IU and Ivy Tech IT leadership, whose growing relationship started in 2011, when the two implemented a data center partnership. Ivy Tech mentioned they were considering contracting support services, and after several conversations it became obvious that both institutions could benefit significantly from a partnership by which IU extends its support services to Ivy Tech.

By entering into this agreement, both IU and Ivy Tech aim to provide the best technical support services for the least cost to the students and taxpayers of Indiana. The partnership eliminates duplication of systems, space, staff, and management between the two institutions, making efficient and effective use of tuition and state resources. Ultimately, by collaborating and leveraging resources, IU and Ivy Tech will increase the quantity and quality of support for their communities — especially for those balancing work, families, and education. (For more details, read the news release announcing the partnership.)

IU Service Blueprinting

While participating in discussions about extending IU's technical support to Ivy Tech, IU set out to create a retroactive blueprint of our services. To put it another way, we worked backwards, documenting key aspects of our support services while considering how we might extend that technical support to Ivy Tech. When the inter-institutional technical support model became a reality, our service blueprint took on increased importance. We were about to go from supporting 130,000 students, faculty, and staff on IU's eight campuses to supporting that community plus 210,000 students, faculty, and staff on Ivy Tech's 30 campuses.

Service blueprinting is the rigorous study of distinct aspects of service innovation. Even with an established science of service blueprinting, however, organizations have not traditionally studied or analyzed services as compared to products. As our experience illustrates, technical support services are, by their very nature, grounded in processes and stored in the collective experience of staff. Service innovation is a result of practical, informed decision making that is organically human-centric — it is not a tangible product that can be easily captured and measured, as transformation is fundamentally fluid.

Operational Metrics

At IU we capture, measure, analyze, and act on support center operational analytics. We ensure that call handling processes are collectively understood and appropriately documented, but we also encourage staff to adjust processes to accommodate customers' needs, contexts, and situations. Process exists, but it is not rigid. Call handling involves process-driven escalations, notifications, communications, and tracking, whereas customer handling is dynamic and relies on interpersonal communication skills. Ultimately, our customer service skills are defined by their human-centric focus, articulated in Empowering People, IU's second strategic plan for information technology: "Indiana University should develop student-centric IT applications and systems that can contribute to student success through support of academics, administrative tasks, and student life." (This is just one recommendation in an entire section devoted to human-centric IT.)

When Ivy Tech and IU began discussions, it was critical to examine how we continually create, recreate, and deliver innovative services that reflect this human-centric IT focus. Ivy Tech leadership essentially wanted us to reproduce our technical support services on their campuses. Our self-examination would provide the initial blueprint for their enhanced service offerings.

It was relatively straightforward for us to define IU's current services. We provide proactive support for the more than 130,000 students, faculty, and staff, which includes access to convenient technical expertise by phone, e-mail, chat, walk-in, and remote sessions. Our technical support is wide, with troubleshooting for over 250 technology services. Our technical support is also deep, with internal tiers of expertise for critical technologies. Knowledge management, self-help documentation, contact logging, and customer service analytics inform all of our services. Ultimately, our goal is to eliminate the need for assistance — if an IU community member does not require our assistance, then that is the best support possible.

Feedback Mechanisms

To adapt the IU service blueprint to Ivy Tech, we needed to identify the feedback mechanisms behind the systematic metamorphosis of IU's service innovation cycle. However, our culture of customer-centric proactive and reactive service is not easily quantified. Continuously refining and reinventing our support requires:

1. Rigorous study of our customers' ever-changing expectations and perceived value of the service components
2. Iterative tweaking or wholesale transformations, a process that involves both internal IT providers and external vendors that provide services to IU

Lagging indicators (e.g., customer satisfaction surveys, first-contact resolution, or call abandonment rates) simply indicate how well our services meet current users' needs. Only leading indicators will help us position new services for rapidly evolving user trends or enable us to attract currently underserved niche populations. IU's IT leaders strategize based on informed vision. Therefore, our service blueprinting is strategically focused on consumers of our services, not on the process-oriented design of existing practices. As a result, we believe that service blueprints should highlight and explain the interconnections in underlying organizational support processes that drive and support customer-focused service execution.

Community Partnerships

We have established relationships with many students, faculty, and staff who proactively inform our support. Our Student IT Advisory (SITA) group consists of over 90 students recruited from various disciplines and campuses. They serve as liaisons for the IT organization, increasing awareness of the potential and limitations of information technology, highlighting new technologies and uses, promoting effective and efficient use practices, and recommending practices for protecting intellectual privacy and property. SITA members also facilitate community outreach, act as focus group members, and solicit feedback from their peers.

Our IT Community Partnerships team, made up of full-time business strategists, leads SITA. Community Partnerships' role is to enable the university's eight campuses to leverage enterprise services, aggregating needs and promoting cooperation (thereby reducing duplication). Outreach to all IT providers on IU's eight campuses is part of the University Information Technology Services (UITS) structure. It is inherent in our organization's design.

New within our support structure are IT managers, who by design report to both an academic unit and to UITS. Dual reporting helps ensure the effectiveness and efficiency of technologies that support the academic and research missions of the schools. This model of IT management — currently involving Geological Sciences, the School of Public and Environmental Affairs, and the School of Engineering and Technology — ensures continuous dialogue between the university community and its IT provider, forging a real-life, day-to-day connection that guides our alignment of enterprise services to academic needs. It also heightens awareness and implementation of enterprise services by distributed technologists. All told, partnership schools are much more aware of and inclined to use central services such as UITS enterprise storage options, web services, and virtual applications. More importantly, we have benefited greatly from their perspectives on how to best enable faculty, staff, and students to use our services.

IU/Ivy Tech Joint Service Blueprinting

To provide a service blueprint for our partnership with Ivy Tech, we are first working to identify their critical customer contact points, and then to illuminate how inter-institutional IT and functional processes can ensure a positive customer experience. Using this approach, IU and Ivy Tech began to blueprint support processes such as those in table 1. We are easing into service delivery, first providing evening and weekend support and then moving to 24/7 IT help desk and support services after gaining experience.

Table 1. Service Blueprint Components: Network Issues

Blueprints like this will provide depictions of visible and invisible service processes that staff, management, and constituencies alike can understand. All involved parties can then recognize their roles in service delivery and service transformation. This visualization of the service processes (and the foundational organizational structure) enables everyone to contribute to the service's evolution. We will continue this type of strategic blueprinting at future inter-institutional retreats for Ivy Tech and IU technologists.

Strategic, Political, Cultural, Technical: Making a Truly Joint Blueprint

Future iterations of support service blueprinting will document essential but elusive proactive processes, especially those that reveal leading indicators behind service innovation. This will be key to evolving the combined inter-institutional support model. However, as important as customer-centric service blueprinting is to the success of this joint venture, it may be the comparatively easy part. Providing a service for another organization requires more than simply changing gateways or sculpting new process diagrams. The service processes and technology — in this case, phone systems, ticketing systems, knowledge base documentation, e-mail lists, escalation paths, notification systems, and other systems common to service delivery (no matter where service is initiated) — may already be in place and ready for quick tweaks, skinning, and configuration for another organization. While this step is relatively straightforward, there is a lot more to joint service blueprinting.

In any organization, there are strategic, cultural, and political considerations (for background, see "Three Perspectives on Organizations"¹). Often these involve long-established and ingrained practices, some of which are not obvious. Almost every organization believes they are "unique" or "special" — however, more often than not, that uniqueness lies not in technical areas but instead in political and cultural dimensions.

To provide services for another institution, as if coming from that institution, you have to invest time in understanding the strategic, political, and cultural environments. For example, one institution might regard electronic communication as the official method and expect everyone to monitor e-mail and respond quickly; another institution may regard face-to-face communication as the official method and not pay close attention to or expect quick e-mail responses. One institution might call leadership and faculty by their first names; another institution may be more formal and address people by their official titles and last names. One institution might work from strategic planning priorities; another may work ad hoc. Understanding and respecting these nuances will ease the transition of service, providing a more comfortable user experience that stems from understanding the culture and political circles.

Add to this technical nuances — one institution might be 100 percent behind open-source development and sharing, while another simply wants software delivered by a vendor — and you will soon realize that there is more here than even the initial three environmental considerations. Understanding all four areas — strategic, political, cultural, and technical — is key to inter-institutional blueprinting.

How did we apply this concept at Ivy Tech? We learned, or rather re-learned, this concept on the job, which seems too often to be the case. We knew how to deliver the service; what we did not know was how decision making works at Ivy Tech (which organizational levels made which types of decisions; what the timeframe was for decision making; which project management reports were required; what was the fastest and best way to communicate within the technology organization). Once we had local representation, we began to learn the culture and the politics as applied by Ivy Tech. We are still learning, and probably will continue to do so throughout the first year of the contract and beyond.

Timeline

Customer or Partner?

As service provider, IU does not need to make a profit like a corporation with stockholders. We do not have a sales force, so there were no marketing materials, service level agreements, reference sites, or project roadmaps to share with Ivy Tech to close the deal. We already understand the quirks and calendaring associated with delivering support to higher education, and we have a proven reputation for providing excellent support. Unlike the typical sales agreement for an outsourced product, this partnership was formed mostly on trust. Each school took risks (not a common contract term!). Ivy Tech had to trust IU to learn what differed between the two institutions, and then to deliver its own well-executed and respected services as Ivy Tech services. IU had to take risks on the contract terms, betting on the resources that would be required to deliver 24/7 services in an unknown environment.

Both risks only become rewards by a factor of trust. Since this is a leveraged rather than profit-oriented agreement, the risk margin typically built into a vendor agreement was not included. Instead, both entities had to trust each other. We had to build relationships between the various levels of our organizations, and we had to have champions at each institution to advance the deal and work through various issues. Such an agreement requires a close partnership, and co-intentions of making the agreement a success. This is different than a typical vendor/customer relationship in which the institution is the customer. In this partnership, the customer is the student, faculty, or staff member contacting IT support. Escalations require some actions to go back to Ivy Tech. Communication for planned — and unplanned — outages must go between the two organizations. Feedback is the two-way street of trust.

This is a partnership. In order to deliver the best possible customer experience, both organizations have to work in harmony and with the same motives. Our intention is that the agreement will soon be only a vehicle for excellent service delivery to the Ivy Tech community, and the partnership will continue to grow and form the best joint service blueprint possible. We have essentially developed an alternative to the two traditional options of insourcing and outsourcing – partnersourcing. Insourcing, as defined by the Oxford English Dictionary, is the action or process of obtaining goods or services in-house, especially by using existing resources or employees. Conversely, outsourcing involves obtaining goods or services by contract from outside sources. With both in mind, we have arrived at:

partnersourcing, n.

1. The action or practice of obtaining goods or services by joining or associating with an outside source
2. The action of undertaking work as a partner who lifts or supports another organization's goods or services

Partnersourcing

Service blueprinting can help define and improve existing services. In the case of technical support, it's crucial that the service blueprint is determined both by existing customers, processes, and metrics and by systemic, human-centric lines of communication developed over time. However, when considering a partnership that is internal or external to your institution, you will likely find that a solid service blueprint alone is not enough. A cycle of proactive engagement with partners, constituencies, and customers is essential to staying current and innovative — and ultimately to success. In the nonprofit arena, sales departments are often nonexistent, but relationships must be carefully developed and maintained nevertheless. Take the time to carefully learn and reflect upon the cultural implications and nuances of partnerships. Combine this awareness with solid financial and operational metrics. Be sure to verify the political implications with many sources. When you've completed all of these steps, you're ready to leverage the opportunities of scale necessary for successful partnersourcing of IT services and support.

1. Deborah Ancona, Tom Kochan, John Van Maanen, and Eleanor Westney, "Three Perspectives on Organizations," in Managing for the Future: Organizational Processes and Behavior, module 2, 3rd ed. (Cincinnati: Southwest Publishing, 2004).