Cloud Migrations: An Opportunity for Institutional Collaboration

[This article is the fourth in a series that presents case studies related to important themes within enterprise IT.

1. Developing Institutional Cloud Strategies
2. The Impact of Cloud Implementations on Budget Strategies
3. The Dean’s Information Challenge: From Data to Dashboard
4. Cloud Migrations: An Opportunity for Institutional Collaboration

Each article in the series begins with a scenario that provides context for the theme, followed by several case studies.]

Institutional business processes and workflow typically build up over time based on existing and changing needs and preferences as well as system capabilities or lack thereof. Moving a service to the cloud provides an opportunity for IT to engage the campus in a collaborative effort to reexamine and update those existing business processes to either gain efficiencies or increase functionality. Bringing all stakeholders together in the planning for a cloud migration can expose interdependencies and inconsistencies, leading to opportunities for high-level improvement in processes and workflow. Important to this effort are change management, governance, and focus on the changing skill sets required within IT as the role shifts from one of IT implementer to that of analyst, consultant, collaborator, and problem solver. Two institutions that are engaged in major cloud implementations describe their efforts to engage their campuses in conversation about the fundamental shifts caused by the cloud.

Scenario

Sara has spent considerable time over the past year addressing concerns about putting data into the cloud and creating appropriate funding models for cloud-based solutions. She realizes, however, that these discussions have been about specific "technical needs of the moment." While people have been receptive to these specific issues, they do not seem to be aware of the fundamental shift that can occur in services and support when implementing cloud-based solutions, a shift that almost always requires an examination of business processes across the institution. Sara realizes that she needs to start an institutional conversation about the role of the cloud at her institution and that the conversation needs to not only involve the cabinet for issues of funding and priorities but also all of the major departmental stakeholders, as they will be the most affected by a shift to the cloud.

California College of the Arts

Mara Hancock, CIO and Vice President of Technology

The California College of the Arts (CCA) was founded in 1907 by Frederick Meyer, a German cabinetmaker, whose vision was shaped by the Arts and Crafts movement. A core tenet of that movement was that the arts and crafts could and should influence and shape culture. CCA is a small (1,900 FTE) nonprofit art and design college located in Oakland and San Francisco. The Bay Area is a global hub for technological and cultural innovation, and CCA prides itself on being part of that culture, preparing students for lifelong creative work by cultivating innovation, community engagement, and social and environmental responsibility.

CCA's ERP Cloud Migration

CCA is entering the final phase of the migration of our enterprise resource planning (ERP) services to Workday, the Student Information System. At its completion we will have effectively retired seven different systems and moved all the related business processes onto a single platform. We launched core HR and Payroll in January 2015, and followed that closely with an implementation of Faculty contracting. Over the summer of 2016 we launched Performance Management, core Financials, and student recruiting and admissions. We will configure and launch academic appointment, promotion and tenure, and faculty recruiting in spring 2017 and are in the planning stages for Workday Student. Implementation of Student will begin in July 2017 with a goal of completion within 18 months.

The opportunity to expose, examine, and ultimately improve associated business processes has been a rare and singular moment for the institution. Such a migration cannot be done well without the right structures and processes in place to support the effort. That said, these structures and process have been built with longevity in mind. A unique trait with a modern cloud technology is the flexibility it affords into the future in regards to reviewing, adapting, and refining processes at more consistent intervals. Ultimately, this requires ongoing oversight and engagement that lasts in perpetuity.

Business Processes: Expose, Examine, Change

The Workday implementation at CCA is being managed by the director of the Project Management Office (PMO), who manages all our large strategic projects. Through the learnings from each of these implementations, she has crafted and evolved an early engagement process that includes sponsors, functional partners, and key stakeholders. This allows us to express a balance of requirements that support strategic, back-office, and end-user needs.

As with most institutions, CCA's business processes have grown organically over time. They are often dictated by the existing systems, lack of systems, or personal preference of the individuals in associated roles. While we will probably not want to replicate those business processes verbatim, there is value in exposing them to help create a strong case for change and to bring other stakeholders into the conversation to examine the process and envision a better path forward. This can be done from both the end-user workflow and a systems workflow, as we did with our student recruiting workflow and systems. See figure 1 for an example.

Sharing Business Processes

In higher ed IT we often talk about how each of our institutions seems to think it is a special snowflake, necessitating a unique approach to each business process. A cloud platform has a single shared tenant, with all customers using a shared code base. The platform hosts a powerful and flexible business process framework, replacing the customizations that made our ERP systems so brittle. With the shared tenant and framework, clients can work across verticals to share business processes. CCA took advantage of that in our implementations and have used it to tweak and improve the system. The Workday Community helps enable our discovery, discussion, and, ultimately, influence on the product.

Project Governance and Decision Making

Because of the phased nature of our migration, we were able to start fairly simply with governance for the HR and Payroll implementation and extend and grow the structure as we added new modules. For each implementation phase we identify the sponsors, a steering committee, and a project team. The sponsors consist of the senior cabinet members whose business units are engaged and affected. The steering committee consists of key stakeholders from the back office and end users. The project team consists of the folks who know the processes and the data most intimately. Most decisions get made in the project team, but significantly changed processes come to the steering committee for feedback and to the sponsors for final approval. Because Workday provides a lot of "self-service" functionality, we found that having key end users involved in the steering committee was important to ensure we understood their workflows and goals as well as those of the back office.

As multiple modules transitioned from implementation to operations, we created a Workday Operations Advisory group. This group consists of key functional owners and IT. It acts to provide oversight for continual improvement of the system and ensure a cross-institutional lens so that we consider the business process changes holistically.

We recently began planning for the Student system, the largest implementation of them all. This will be an approximately 10-month planning project within which we bring together representatives from Financial Aid, Academic Affairs, Student Records, Enrollment Services, Student Affairs, and IT to look across the divisions and map out the entire workflow against a calendar timeline. This project uses online mapping software so that each unit can create business process cards and move them around as appropriate. The intention is to expose the opportunities for improvement at a high level, identify interdependencies, and dig into the cross-cutting business processes in detail so that we understand how they impact all the units. This is the first time these units have done this type of work, even those involved in the legacy implementation.

In the next phase of planning, we will not only explore ways we can improve or redesign these processes from the administrative perspective, we will also focus on the end-user experience, particularly for students and faculty. Through focus groups and interviews we will map their journey navigating through CCA, in particular where their paths intersect with the system or administrators, to understand their motivations and goals and to highlight what works well and what doesn't. These insights will be incorporated into the design process for the Student implementation. Figure 2 outlines the mapping, and figure 3 shows one business process.

Lessons Learned

Exposing, documenting, examining, and refining business processes is hard work. As a small institution, we expect people to wear many hats. During implementation and planning, we have found it challenging to back-fill for the individuals on the project teams — not because of a lack of willingness by upper administration, but because of the preference of the units involved. I believe they feel it is harder to train someone else to do your job than to work longer hours for a short period of time. As we look forward to the Student work and the depth and breadth required, I believe we will have to break that cycle.

People are still adjusting to the concept that we can continually improve and adjust the business processes. While I think that this has great potential to provide better support and user experiences for the college and creates less stress in terms of getting it exactly right the first time, it places more consistent pressure on the team — their work is never done! We are also finding that the roles within IT need to shift from IT implementer to IT consultant and problem solver.

In addition, we've learned that in moving our processes online and into an automated process, the end users initiating these transactions face higher expectations of their technical proficiency and functional knowledge. Before, the manager who wanted to hire a new employee, or the office manager who wanted to order supplies, could simply fill out a paper form or PDF. Any missing or incorrect information was corrected at the time of data entry by back-office team members. Now, the end users have to be more knowledgeable about things like employment options and how budgets are structured. The need for better and constant change management and training is greater, and we're still learning when and how to deliver this in the most effective and efficient manner.

Tallahassee Community College

Bret Ingerman, Vice President for Information Technology

Tallahassee Community College (TCC) is a public, two-year college located in Tallahassee, Florida. It offers over 60 degree and certificate programs and has an enrollment of more than 12,000 for-credit students of whom 77 percent transfer to a four-year institution after graduation. We also serve over 17,000 non-credit students annually. To meet the educational needs of the campus community, TCC employs 716 full- and part-time faculty and 1,192 full- and part-time staff.

First-Stage Adoptions of Cloud Solutions

Like many schools, TCC began its exploration of the cloud with electronic mail. In 2013, facing the need to replace an aging server infrastructure, TCC instead decided to move e-mail to Microsoft Office365 in the cloud. Like many of the first-stage adoptions of cloud solutions, the catalyst for the decision was primarily financial: it cost less to have e-mail hosted in the cloud than it would to replace (and continue to replace) hardware on campus. Even though the campus was involved in the selection of the e-mail suite, the project was driven and managed by IT. And aside from an upgraded software experience, the campus saw little impact as a result of the move to the cloud. Another example of a first-stage cloud adoption involved moving our learning management system (LMS) to Canvas, a cloud based technology. In many respects, the first stage of moving to the cloud was more about where the servers were located than any significant change in the services themselves.

Second-Stage Adoptions of Cloud Solutions

The second stage of adopting cloud technologies arose more from specific service needs and desires than from the underlying server issues. Vendors began to create "point solutions" for specific campus needs by writing targeted web-based applications. Because the vendors could easily host these applications in the cloud, without the need for the campus IT department to install and maintain software, they started to market these solutions directly to end users. Often that meant IT was brought into the conversation after the initial pitch and demo to a specific department or individual. Sometimes IT wasn't brought in until after a department or individual purchased a specific solution. As departments learned, however, IT was ultimately needed to help make sure the new application could authenticate to and communicate with other institutional systems.

In the case of second-stage cloud adoption the end users were the catalyst for the change; they felt their staff or clients needed certain features and services. Rather than saving money, these procurements frequently came at an additional cost to the institution: they were not replacing existing systems or services but rather adding new services to a growing campus portfolio. TCC has seen the procurement of a host of second-stage, cloud-based point solutions including ones for judicial affairs, campus activities, career services, human resources, advising, and academic affairs.

Third-Stage Adoption of Cloud Solutions

The third stage of moving to the cloud is the adoption of cloud-based software and services that result in a profound change to significant parts of the institution. An example of a third-stage cloud project for TCC was moving our ERP solution from the campus to Workday, a cloud-based, software-as-a-service (SaaS) application suite. The catalyst was the knowledge that the existing 20+ year-old legacy system was well past its prime in both the technology used and the features available. This led to a broad desire to adopt new technology for supporting the underlying business of the college that would

• focus on the end-user experience,
• provide a robust platform for future growth, and
• use a modern technology toolset that included cloud-based software-as-a-service (SaaS).

We have completed the migration to Workday for our core ERP functions and are in the process of moving our student information system. Such a move required involving all parts of the institution in the decision, as it was more than just an economic decision (which drove the first stage of cloud adoption) and not something that a single department within the college could decide to do on its own (which is characteristic of the second stage of cloud technologies). The same is true of our other major cloud project: moving our telephone system and call center to the cloud. Much like the ERP migration the initial catalyst for the project was an aging technology stack, but through conversations with other areas of the campus we realized that we wanted to look at a new model for telecommunications that would provide a robust platform for growth and change.

Issues Raised and Addressing Them

Each type of adoption of cloud technologies has raised issues, causing TCC to have a number of internal conversations about the role of the cloud in our technology decisions and in our services. Perhaps the easiest and most obvious conversations about the cloud involve costs. The first stage of projects was really about moving IT infrastructure from the campus to the cloud, so the conversations about cost could happen between the finance and IT departments as a normal part of the yearly IT budget process. However, once the second stage of cloud projects started, individual departments were making purchasing decisions on cloud solutions on their own, based on their own budget availability. One problem with this approach to funding is that while the departments may have had a source of funding for the initial purchase, many of the products they wanted to procure required a multiyear commitment of funds —something their budget was not set up to handle. A second financial issue involved frequent additional costs related to procurement of the specific application. These could range from the need to acquire middleware to enable the third-party application to authenticate to and/or share data with other campus systems, to the need for additional staff hours to handle configuration and integration efforts. While these issues in and of themselves were not insurmountable, having them presented as a mandate after an acquisition, and under a timeframe that never took into account existing IT projects or budgets, was problematic. We continue to stress to departments the need to consult with the finance office on budgetary needs related to the acquisition and with IT to learn about additional costs and implementation timelines.

Another set of conversations that need to happen revolve around contracts. While IT and finance have a great deal of experience reading and modifying contracts, individual departments seeking to buy cloud solutions often lack such expertise. As a result they may fail to take into account contract needs such as those for legal compliance, including FERPA and PII, as well as practical needs, such as data ownership, data privacy, programmatic access to data, etc. And, of course, departments may think that they can sign cloud contracts without checking to see if they actually have the institutional authority to do so. Fortunately, departments typically reach out to us early in the contract stages — but that also has sometimes been the first time we learn about the project itself. On the positive side we have had a number of successful conversations about consolidating the budget and contact for these point solutions from the individual departments to IT. The reasoning is simple: adding the management of additional software solutions to IT is a marginal increase in workload for IT, as we perform similar tasks for many other products, as opposed to a more significant investment of time for departments that have never had to manage such contracts.

Finally, the biggest need for conversation about cloud solutions has to do with the fundamental way that such solutions can impact the business that we do, the way we do it, and the people who do it. With the first stage of cloud procurement this wasn't an issue because while things changed for IT, little changed for most of the campus. The second stage of cloud adoption is usually initiated by the departments themselves, so they are likely eager and prepared for the change. These migrations have a larger impact on IT than on the rest of the campus because we are frequently coming up to speed on the need, the timing, and the impact of the project well after initial conversations with the department. What makes this more challenging is the resentment that sometimes occurs when you need to have the project take a step back in order to ensure that the chosen solution can work in the existing technology environment and that IT has what it needs to help ensure success. The worst possible outcome for a second-stage cloud solution is when IT discovers that the specific solution chosen by the department is either not suited to, or can't work at all within the existing environment. While these conversations are never pleasant, they can have a silver lining when they lead to a deeper understanding on the part of the department as to why they need to include IT at the outset, and on the part of IT as to learning the specific needs of the department.

Frequently, a third-stage movement to the cloud fundamentally alters how business is done and how solutions are supported. When moving to multitenant, SaaS-based cloud solutions, the impact across the campus can be great indeed. Such third-stage migrations often move the IT organization from writing or modifying code to configuring applications or designing workflows within the software to meet the users' needs. The role of the traditional IT worker changes from one of programmer/analyst to one of business analyst, where IT must spend more time with and understand the business needs of the supported departments in order to configure the systems accordingly. At the same time, the workloads of the departments change as modern cloud-based tools frequently give them the power to make configuration changes on their own that in the past would have required IT. Further, most cloud solutions undergo more frequent updates and changes than the more traditional on-premises solutions. Whereas on-premises updates may have been limited to once a year, cloud platforms can upgrade features and services as frequently as once a week. And every change in features or services requires fresh regression testing to make sure that software still continues to operate as designed. So while the burden on IT might lessen because they no longer have to install the code necessary to update the software, the burden on the departments increases because they must test far more frequently than ever before. We should realize that this type of testing is unfulfilling: if everything goes as planned, all of the efforts devoted to regression testing will confirm that nothing has changed in other parts of the system.

As you can see, a variety of changes occur within an institution as their adoption of cloud solutions increases. As a result, the best defense against unanticipated challenges and problems is to take a more aggressive initial approach to discussing stakeholders' needs, solutions, and consequences.

Taking Advantage of Cloud Migrations

A major cloud migration provides an opportunity for IT to engage with all institutional stakeholders in a conversation about the impact of the migration on business processes and workflow. IT leaders can take advantage of this opportunity by using existing governance structures, focusing on change management principles, and recognizing shift in IT's role away from solutions provider to broker or consultant. The lessons learned from these two institutions offers a roadmap for IT departments at other colleges and universities as they work to guide their institutions through major cloud migrations in a way that results in greater efficiency and efficacy of enterprise systems.

---

Mara Hancock is CIO and vice president of Technology at the California College of the Arts.

Bret Ingerman is vice president for Information Technology at Tallahassee Community College.