Top of Mind with Tambellini Group
Top of Mind with Tambellini Group
The Magic of Hyperautomation
To realize the benefits of hyperautomation, the University of South Florida (USF) identified three crucial factors for success: an agile mindset, investing with the right partners, and a willingness to experiment with new technologies. Alice Wei, Assistant Vice President of Digital Transformation and Innovation at USF, joins the Top of Mind family this month to share how she spearheaded USF’s innovative strategies to rapidly deploy custom applications for the benefit of students, faculty and staff.
Hello, and welcome to the November episode of the Tambellini G roup's Top of M ind podcast. I'm your host, Liz F arrell. The appetite for new technology i n higher education never a bates and departments across all institutions are constantly on the lookout for the next tool or application that can add efficiency and improve that user experience. By the same token, many of the tech tools institutions invest in can fall short of expectations and end up being underutilized or not used at all. So what's the alternative? Some institutions are lucky enough to have the resources to support an in-house development team that can custom build their applications, but those teams are often overwhelmed with requests and constantly playing catch u p. There are, however, some notable exceptions among universities that have effective visionary technology leadership to support innovations. And today we are joined by one of them Alice Wei. Alice serves as the AVP of digital transformation and innovation at the University of South Florida. In addition to overseeing digital transformation university-wide for nearly eight years, she also serves in a similar capacity for USF Health for five years. And in both those roles, Alice has spearheaded innovations in how USF builds applications for rapid deployment using hyperautomation, including low code and composable architecture, along with an agile framework for project management. These efforts of yielded exceptional results, allowing USF IT to quickly build scalable enterprise-grade applications in a matter of weeks and sometimes even days. Most recently, her efforts were recognized by Gartner when her team won the 2021 International Ion Innovation Award for their work during the pandemic to build applications on quick turnaround that helped the entire university community adapt and thrive during a volatile time. In addition to everything Alice does at USF, she is presented on this topic at various national forums as well as co-authoring multiple papers and a chapter in a book on the value of hyperautomation and higher education. We wonder when she sleeps, but we're glad that she found the time to be here with us. So welcome Alice. Thanks, Liz. Thanks for inviting me. I'm glad to have you here. We are very lucky to have you make the time to talk to us today because your work and the results are an inspiring case study that can show what is possible in advancing technology transformation in higher education when you have those magical ingredients of the right team and the right approach. So I wanna get into all the nuts and bolts of what works at USF and why it works. But before we do that, can you describe a few terms for our listeners? I mean, we hear a lot about the, the value of hyper automation or using a natural framework. Those are thrown around a lot in it, but how they're applied as you know, means different things to different people. So what do they mean for you and USF?
Speaker 2:Yeah, it's a really good question. I think we tend to assume people know terminology and industry and we use it very liberally. So happy to explain, um, at least what these terms mean to us at USF. Hyperautomation, I liken it to more of a strategic approach for how we utilize technology to discover, streamline and automate business processes. Um, this should help with optimizing and speeding up flow for how a business operates day-to-day. Um, so that's how I would summarize auto hyperautomation. And I think that may have different interpretations, but at the core you're trying to speed up operations and how you run your business on a day-to-day basis.
Speaker 1:What about with composable architecture?
Speaker 2:Composable architecture? I'll use the Lego analogy here. And, if you imagine when you have a bunch of Lego blocks from different sets that you've bought in the past, you are able to build new stuff just from your own mind or from other, you know, guides that you find on their internet. And that's how composable architecture should work, is your architecture should be component widget digitized in a way that you can build and reuse widgets. New things and new innovations will emerge from existing stuff that you've already built in the past. It makes it scalable, uso that you can build very quickly as well. So speed and scalability become a thing that as a byproduct of composable architecture as well as you only have to focus on maintaining the quality and the resiliency of that one instance of that widget as opposed to 10 different versions of that widget, for example.
Speaker 1:Very cool. I like that Lego analogy. And the last one we have here is agile framework.
Speaker 2:Agile framework I think is really integral in hyperautomation and being able to do composable architecture. So I think it's a big wrapper. When you think agile, you think project management, but there's also a cultural aspect to it or a philosophical aspect to it, which is are you delivering value to your clients in a timely manner, in a way that is iterative? But also are you open to failing and learning from those failures? And are you allowing your teams to fail in a safe enough environment, um, and so that they can be freed to build the best thing that they can build as a team. So I think from a management standpoint point, we often view it as an iterative way of getting stuff done, but from a people over process perspective, it's about making sure that your team feels safe, um, whether it's in the work that they do or you know, in the mental health that they have coming into work every day.
Speaker 1:T hat that's a great definition of it. I've never heard that, that sort of people aspect of it before. I've always heard the process. So I like that holistic definition of it. The strategies that you've used and t heir resulting impact, like as we mentioned with the award, they've gained all this heightened visibility during the pandemic because you all just, as I s aid, we'll talk about that a bit more later, but it's amazing the stuff you all were able to do in such a short amount of time. But when we spoke about this previously, you had said that, y ou k now, t his is stuff you a nd a nd your team had been doing for what, eight or nine years there at USF. It's sort of in, in the DNA of the IT team. And you mentioned that USF Health, like they began using low c ode before it was known as low c ode. Can you share with us how this all got started way back when and why? Like were there certain pain points that prompted this?
Speaker 2:Sure. I think I started on this journey when I was a relatively new manager too. I had just been given a team of 16 programmers essentially. So we were doing ColdFusion development at the time, which is just another program programming language like Java or Python. And, um, the, the new manager in me wanted to make a difference in how we were doing things because the problem statement that I was presented with along with the team was, we have a dying technology. ColdFusion was on its way out the door as a technology, so we needed to change our length programming language or platform something, but we couldn't stop giving value to our clientele, which were USF folk. And that equates to for USF all our health, college and schools, basically. They were all joined together under the umbrella of USF Health. And, that was a big challenge because when you're changing out any kind of infrastructure that takes a lot of effort in itself. And on top of that, this 16 member team, even though it seems quite large, was maintaining and sustaining 170 some custom applications. And we had a backlog of requests like 200 long. And so there was no way we could move forward with moving into new technology while continue to deliver value. The third aspect of it that was a challenge was our clients were already complaining that they weren't seeing the same level of value that they'd gotten when they first invested. So that was also something that I had to figure out how to balance with, you know, taking on this team as a relatively new manager at the time. So yeah, that was, I think, the big pain point. And I think a lot of organizations will have similar pain points in the past or even currently on how do you answer to all those problems that we'd commonly see.
Speaker 1:Right. And you're the new manager too, so now this is all on you. Welcome to your new role.
Speaker 2:Yep.
Speaker 1:So what did you find, Like w hat was your solution to this?
Speaker 2:Yeah, so we were looking for a sustainable model that a development team could continue on with and not create too much what we would call an industry technical debt. And still provide that value, right? The value statement was the biggest piece is, you know, we invested in you, we believe in you, and we still want more. So how do we get that more from out of, out of you? And, I think one of the first things that I did was really assess the type of applications we're building. So out of the 170 that we had out in production, I would say 80–90% of them were mostly consisting of fancy forms to fill for someone to fill out. And then it did some kind of workflow in the back end to route stuff. And I think a lot of organizations, especially in higher ed, can relate to that. If you really look at the applications you're building, a lot of times it's just a really fancy form that you're building in the front for someone to fill out and you wanna take action on it at the end. And so you don't really need necessarily high code, which is what we now call program proven languages like Python and JavaScript and even ColdFusion at a time. You don't need high code necessarily to do that stuff because there, even at that point there were business process management solutions that focused on workflow. They were basically workflow engines. They had pre-built logic for workflow. And so we stumbled upon that, I would say niche at the time, um, through some calls with analysts and discovery on, you know, what would be the best solution for us. And we ended up in a very unique situation where the business process management ecosystem was also transforming. We looked at multiple vendors. There was IBM, Pega, Appian where the big names at the time. We chose Appian because they were actually presenting themselves slightly different from the other competitors at the time. In that, they were really pushing this low code concept where anyone could code is what they were selling. And to me, coming from a non application development background before I took on this team, and seeing the demographics of, you know, the challenges it was to get programmers, actually even then, forget the talent challenge now. Right? Even in 2014, it was a hard, it was hard to get programmers. That really appealed to me cuz that meant anyone could code. I could get any kind of person, whether it was a junior in college, a graduate in college, a young woman, a young man, you know. Whatever their background is, it didn't matter because the low code promise was you only need to know some, you know, advanced Excel logic and you would be able to learn how to code in Appian. And the other sales pitch which really appealed to us was this 10 x speed. So whatever, however long it took for you to do it in high code, you can now do it 10x faster in low code. And so that's what we went with actually as our solution.
Speaker 1:It sounds like one of those two good to be true things where you don't need high skill people. They basically like, if they know Excel, it's like building your new Lego house and it's going to go really fast. And we hear a lot of these types of claims that are made miracle claims about technology tools are gonna solve all your problems, They're gonna make it quicker. And at least in higher ed, we know so many of them tend to fall short of their promises. Is that what happened here was was there any increase in speed?
Speaker 2:There was not only increase in speed, but we were able to recruit from all sorts, all walks of life. We hired in people that were high school graduates, we hired people that were non computer science majors. It was truly—it's still learning curve—but we were able to get to that point where the diversity of thought really became valuable because they came from different walks of life. So even the solutions they created were more creative, you know, non-traditional non-conformance to how you would do application the design. So that really helped. But also the speed was something that was really shocking to us. We had opted for professional services to come in and help us with our first implementation in Appian. And we, based on their advice, we picked a medium level complexity project to start with. And what blew both the IT team's mind as well as the client's mind was that they had a working type prototype after two weeks. Wow. Which, you know, you hear it's people claiming that even then there are people who claim they have working prototypes, but this was in production. You could push this to reduction and it could work. The only thing missing was actual real data and that was a problem we solved later, but the speed to value was definitely there. And the shock factor was definitely something that our clients were not used to. And I want ot add to that also, in order for that realization of speed, you have to be willing to experiment. And it goes back again to the agile philosophy—mindset of iterations. So we went in together both the business and IT in terms of investing in a trial that could fail. We didn't know and we just tried. And, within a four-week window, we had an application that was ready to go live.
Speaker 1:Do you remember what that application was?
Speaker 2:Yeah, it was a change of advisor. So for a college, our college of public health, actually they wanted students had to get like six signatures from varying levels of faculty—I think from department chairs—so that they could get permission to change their advisor. It sounds super simple, but the time it took the student to actually get approval was bordering on months because they were taking around a physical paper door-to-door hoping somebody was there to sign it. And it was, you know, it was manual. And when we built the solution in four weeks and went out, part of the thing that we did was reduce as much waste as well in the workflow. So it allowed the department chairs to see who was changing their advisors, but they didn't need to sign off unless they wanted to intervene, for example. So we reduced the sign number of signatures down to like two and the process can complete within days, as opposed to months. So that it's not just the speed of delivery, but it's also the speed in which the work gets done after it's implemented.
Speaker 1:I mean, that's pretty amazing. And you just also, we hear so much about technology can't make students like graduate faster or be more successful, but a lack of it can definitely be a barrier. And that example you provide is such an illumination. Like you think of students who maybe like they want a different advisor if that's taking months, like how many people do you lose? Especially when we're talking in healthcare where another area aside from programming, coding, and sciences where we have so many shortages. I haven't heard a better example of success than that. And it gives such a good sense of just how transformational the right tools can be in the right hands. Also showing like when early results are successful, they game momentum, right? And spread through an institution. So we, we've talked about the gestation and the birth of this. Awesome, you know, hyperautomation, usage, all the different tools you're using that speed up. Um, you had mentioned since they started in USF, as they started, excuse me, in the health team, they've then evolved where you're overseeing this custom development team for all of USF. And I think one of the things you had told me was if it hadn't started in the health part, it wouldn't have happened at all. Can you explain why that's the case?
Speaker 2:Yeah, I think there's a bunch of different unique situations tthat need to be in place. Although I think you can replicate in others, it's just you need to find the right partnerships. One, it's being that, you have to have trusted partners out in business. Like I said earlier, you have to have someone willing to go in and have and take a risk with you, whether it's in the form of some dollars or you're investing. We had to have someone buy the licenses for Appian for us, for example. It did not have budget for that. And so the college had to be the ones that say, I'm willing to invest in this technology. I'm gonna fund it. I'm gonna fund the professional services that come in and do the implementation. And it will invest in the resources—the project management, the technical people—to do the work, right? And so in, in that aspect, you need a good partnership and a safe space to experiment. So it can't be something you roll out to the entire university. It has to be a small enough pool that you get quick feedback and you don't get completely crushed in the first round of go live. So that's one. I think the other is that the university has a sense of I need to build something and it needs to be perfect by the, you know, when you, when you hand it off to me. And again, that's another risk factor in saying it may not be a perfect product in the end, in the, in the first round and the be okay with working with something that's not ideal, but we'll continue to iterate around it. And so I think the, definitely the partnership, the philosophy of show me, don't tell me. So by the time we took it to the larger, the rest of the university, we had a ShowMe, we had perfect working examples that have been running for one or two years already. So from a highstakes perspective for the university, it was working, it was not in theory it was already valid and we've proven it. It worked. One of the other projects we did, which was for our college of medicine, which is a lottery system, when we scoped this with our original 16 member custom development shop, it was supposed to be, we said it was not even worse the college investing in because it would be take so long and it would be so expensive. So we're talking two plus years to get a complete product. And when we've talked to later on with other universities, other medical schools, they've spent millions on the same problem. It's the same structure actually. You could reuse the same product in most most medical schools, but they've spent millions on it. And we were able to do this with the low code solution that we have in a quarter.
Speaker 1:Wow.
Speaker 2:And it worked
Speaker 1:Obviously
Speaker 2:Quarter and under a million dollars. I can guarantee that. Yeah. And so those are the things that we had to have proof of before we could take it to the larger group where there was, in our instance, we had 2020 plus, you know, schools and colleges that we had to, uh, get approval from. And, I think that's really the uniqueness of it. You could start at the university level, but you still have to pick a singular partner, not the entire university.
Speaker 1:Yeah. So those partnerships are so important and as you said, like just not just from a budget standpoint, but that we're, we're taking the leap of faith together, um, having one of the business units do it. So you had touched earlier on how there was this transition to quick delivery and that required a change of culture from your clients on the health side at USF. Like they had to shift their expectations from you got this, this speed coming up with, with adding Appian and other things. And it sounds like a nice change of culture to make. Oh, I get things faster, that's great. But there is more to that culture change involved in this, especially as you said, like you're taking it from tthis specific group that you're working with to university-wide. So, what has a change in the culture for it to work at that broader level for such a big institution?
Speaker 2:It's a really interesting topic to discuss because I think it's change on all sides. It's changed for the business and this change for the IT department. I think for the business it's about owning what they want built. In a lot of instances when you see big major ERPs being implemented, for example, or even just new solutions, the client doesn't necessarily take ownership of what that it's theirs, right? It's their babies to defend and that they know how the logic was decided in terms of how it was implemented. And so it gets saddled with oftentimes that ownership, which then becomes, a challenge in terms of understanding what the cost of maintenance is and also why they should continue to invest in this product, for example. And so part of what was uniquely emerging for us that we saw is when we build stuff with our clients in these low code solutions, and even in our forays into other auto hyperautomation tools like, uh, process mining and robotic, um, robotic process mining, uh, automation, um, it's more around the fact that we go into the room together, IT and the business, we lock ourselves in a room for a week, two weeks, whatever long it takes. We do a zero planning. And when they come out of it, they understand that we started with a canvas, a blank canvas, and at the end all the scope and the requirements were decided by the business with consultation from it. And so when they walk out of those rooms, the business fully is aware of what's being implemented and bought in and feel like it's their babies. They don't need it to defend it for them. It becomes a true partnership because they know what decisions they made on what they built and it was built for them, not for the high level manager that has to have a dashboard, right? It's for the person on the ground that needs to do it for the advisor that needs to meet with the student, This is what I needed and this is what I got. Right. I think that is a big mindset shift that whether you use a hyperautomation tool or not, it's a cultural thing that you have to have in order for, um, quality work to come out. I think the other aspect of it, which is an interesting one is, I don't really understand why when it comes to investments in technology, especially in the higher ed space, there's a lot of fear around risk. And it's either an all or nothing kind of mindset. I give you x million dollars and you better give me something that I want at the end of it. But out in, you know, companies out in industry with companies that do innovation really well or even in our research branch of our universities, failure is a common thing and accepted. And you look at it as a lesson learned, and you move on and you and you make something better out of the failures that you've had that happened. And I think it would really benefit organizations as in and especially in higher ed to perceive IT investments in that way. So maybe don't give that$20 million initial upfront money talk through what kind of experiments or innovations we need to do in smaller size investments so that you can validate this is gonna work. Right. That way your IT group is freed up to figure things out in a small or small enough sizing so that it's not high risk and you're also not investing$20 million up front on something that you may or may not get a value out of. We've seen this happen many times where, you see it on the news some, some school invested 30 million and moving to something X, Y, Z and at the end of it, not even two years in you hear about this, they canceled the project because it didn't work.
Speaker 1:Exactly. And that money still has been spent. You don't get that back. Exactly. You don't get that time back. You also don't get like that enthusiasm or camaraderie back. You've then got this like fatigue change, fatigue, um, cynicism perhaps towards technology in its promises. Yeah. It made me think of someone recently said to me, fail should stand for first attempt in learning. And I think what you're describing is such a great example of that.
Speaker 2:Yeah. It shops also have to pivot to be able to have that mindset too. I think there's also, it's both sides need to change, right? Business needs to be be willing to trust more and invest in smaller increments so that we can learn from our mistakes and it needs to learn how to take those small investments and do stuff with it. Because I think sometimes we also try to ask for a large sum knowing that they'll never come back to us again, right? And, so again, the show show me not tell me, right? So can we get into a mindset where both sides are okay with if you invest some the money in me and I'm able to show value, you're going to actually invest in me more. Not just say, Okay, then do what you already have and that's it. Right? So I think it's a two-sided change
Speaker 1:And I think it's important too for everyone listening to this to realize you're talking about doing this over, you know, almost a decade, right? The the there, this, it took a while to get here, but a few years ago now, gosh, it's crazy to think it was a few years ago. Obviously the pandemic hit and you all, as you explain these projects to me as this was our chance to flex our muscles, like it looked like sort of a victory lap there. And you and your team built these custom solutions that helped USF survive during a very unique time when things were changing. Requirements were changing every day in terms of what's needed for testing. Is it safe to be back in school? What, what can we do remotely? What can we get rid of more of these paper based processes and everything? Um, I thought it would be a cool example for everyone to hear, um, some of these things that you did just so they get a sense of, you know, this, this tangible value that it brings. Um, can you tell us about one of these things that I know we've talked about before, but the, the CARES financial aid funding distribution. What did, what did you all do with that? How long did it take? What was the feedback on that?
Speaker 2:Yeah, the CARES Act funding was very much needed but also very controversial when it came out because every institution had to figure a way how to distribute the money and also interpret how we're allowed to distribute the money. I would say.
Speaker 1:A lot, I think<laugh>.
Speaker 2:Yeah. And that took time, right? And I think the thing that we were able to show from an IT perspective, um, and it extended to beyond just our low code solution. We now have an ecosystem of hyper automation, right? So, you can't do low code if you don't have a good service bus for data for your APIs and stuff like that. So we've used MuleSoft and we have a CRM that is able to connect in and do all that kind of stuff. So really in our automation first off. But I think the, so there's that aspect that you have to plan years in advance, right? You have to have those in place, otherwise it was scrambling at the last minute. So in terms of flexing our muscles, what we were able to do was utilize all those existing infrastructure and build apps literally in a week, five days. So as the business was interpreting the law or the guidance on how to distribute CARES Act money, we were literally building as they decided on how things were gonna happen. And so, so it was a long period of silencebecause they were trying to figure out with our lawyers and everything. And then finally they had a decision and they needed to execute quickly. Like things were going very rapidly. And, because we had the data integration already, we had connectivity into our dynamics CRM, and we had our local solution Appian-built with connections already existing infrastructure to communicate with students. We built all of that in a week because we were just reusing, again, the composable architecture. We reused so much of what we've already built and I think we only had to pull in like additional data set or something like that. And we were able to help the university quickly distribute that money, uh, as they needed. It was not simple business logic, but we were able to still build it within five days
Speaker 1:Yeah. Compared to what other institutions were dealing with. And there's that immediate, like you look at the end result, What did that mean? That meant students got the funding they needed to be able to stay in school. I mean, that is such a tangible important value for that. And
Speaker 2:Money to live, some of them did not have funding to even just survive through the pandemic when people were told to stay home. So that was very crucial.
Speaker 1:Yeah. It must have really helped in terms of retention and matriculation too. So keeping those students afloat. In other news on that there was also these pass fail grading option requests. what happened there?
Speaker 2:Yeah, That was the semester, the first semester that we had the pandemic. So, spring of 2020. A lot of students were really pushing for, I think both students and faculty and administration were pushing for us to change the grading system to a pass fail as opposed to a grading a grade for that semester because people were getting sick. They, they didn't, they were getting confused or stressed out, not able to really focus on their learning and all that other other reasons amongst, you know, just those things. And so, there was a decision made that we would move to a pass fail system for that semester, which required a lot of technical lift for us. One, people had to, there needed to be a mechanism for the students request for pass fail. So then we had to take in, again, a form and then we had to have a workflow in the back-end that allowed our administration to review and approve that these people qualified for a pass fail grade change, and then actually pull it, push it into our student information systems in a way that was not going to require a lot of manual work. So all that together, again, we were able to do within a week because of the architecture that we've built, the technology stack that we had invested in up until this point, not knowing that we're going to have a pandemic in any way, right? But we had this dream, this audacious dream of how we wanted the university to run from a technology standpoint. And that, you know, as horrible as the pandemic was and still is, we were able to really flex our muscles and show what we've been doing in our, you know, in our little corners of the world in it by, you know, just extending our help and rapidly developing solutions for our business.
Speaker 1:Yeah. And just proving, I mean, nimble and built for anything really. This wasn't something you were anticipating for, this wasn't part of, you know, a disaster recovery plan or anything like that, or some other things you had mentioned too. Like, these I think also speak on the same themes. Like you were able to use those building blocks. You had the culture in place, you had the, the successes before and you had the partnerships coming together. Like when we're talking about other things that tripped up a lot of institutions, things like COVID testing, virtual advising appointments, hiring exception forms to streamline the approval process when there are people you've gotta hire right away and you need them. Like these are all bureaucratic things. No one wants them to slow everything down, but inevit inevitably they can. A nd, they did. So, b ased on this long list of tangible success stories, it seems like y ou using automation, like using composable architecture, all the things you all are doing i s such a no brainer. It leads to these tangible results. It's less expensive than, you know, spending those millions of dollars on getting a new ERP system. So why aren't more institutions taking this approach? What is holding them back?
Speaker 2:I think it's a lot of the setting up those partnerships in the organization, establishing that trust that you can deliver, and also being able to kind of, like I said, size the work in a way that you can actually deliver something iteratively. I think, you know, we, if you were a client to yourself or if you were a client going somewhere to get a service, you wouldn't wanna wait a year, for example, for you for your roof to get done on your house. You'd want to see it happening as it was progressing. And I think it's a similar mindset that both, like I said, the IT side, the technology side and the business side need to really think through, um, in terms of what they demand and also accept as a project. For example, you know. If you're gonna try something out, some, some of the technologies that we in it have bought, or not ones that we were necessarily comfortable with, but there was a level of trust that we'd built with these clients that we have and saying, we're gonna try it out and see if it works, and then we'll have conversations later if it doesn't. It's not a blind faith thing, but we've done our research and we've done our due diligence, but you have to be able to have those really good conversations with the business to say, are we doing the right thing from the long-term perspective? And is there something we can validate so that we avoid expensive costs later because we didn't think about, we weren't able to think about these things. And that allows the show-back to be quicker and the cost of the show-back to be less and more pable for both sides. I think.
Speaker 1:Yeah, I mean, it just sounds like trust is a big thing here. Starting small. And another thing that you've touched on too is that fear of experimentation.
Speaker 2:Fear of failure. Actually, it's not the experiment, it's the failure part. What happens when I do fail.
Speaker 1:Yeah. And it sounds like in USF'S case, at least on your team, it's to learn from that and move forward.
Speaker 2:It is.
Speaker 1:Well, you've given us some amazing insights on not only the, the challenges that exist, but great advice on how to overcome them. Alice, thank you so much for taking the time today to share your insights with me and our listeners. I hope others will learn as much from your experience in this discussion as I have.
Speaker 2:Well, thank you for having me, Liz.
Speaker 1:That concludes this month's episode of Tambellini Group's Top of Mind Podcast. Don't forget to check out our other podcasts and public resources through our blog at thetambellinigroup.com.