Juliette Welch: Thank you everyone for joining us for today's call: The Care and Feeding of Your New Enterprise Software. You Mean I'm Not Done Once I Go Live?
Shawn Windle will be our speaker for today. Shawn is the Founder and Managing Principal of ERP Advisors Group based here in Denver, Colorado.
ERP Advisors Group is one of the country's top independent enterprise software advisory firms. ERP Advisors Group advises mid to large sized businesses on selecting and implementing business applications from enterprise resource planning, customer relationship management, human capital management, business intelligence, and other enterprise applications which equate to millions of dollars in software deals across many industries.
On today's call, Shawn will discuss what to consider after your enterprise software go-live and ways to properly care for the investment in your new system.
Shawn, can I pass it off to you?
Shawn Windle: Sure. Thanks Juliette, I appreciate it.
So, this is Shawn Windle with ERP Advisors Group. Thanks for joining today.
And it's kind of a funny topic. We're going to talk about, care and feeding of your new enterprise software system and then you add into that, “you mean I'm not done once I go live?” It's just kind of a misnomer that we see with our clients sometimes that there's some expectations that may not have been set very well, especially through the sales process.
So, with this call, we're going to talk about what happens after go-live. There's going to be three key areas that we're going to talk about there. And then we'll also talk to different levels of support that are required once your system is in place.
Perfect, so let's jump into this. So, let me set the stage a little bit.
So, if you've heard some of our other calls, we really harp on the importance of doing — even at the very beginning — really understanding your needs for software. Do you really need to change? And if you do, do it. If you don't, don't do it.
So, we expect that needs analysis is done so that you don't know exactly what you're trying to accomplish with software.
Then you've done a really diligent selection process where you’ve gone to the market and looked at vendors that are viable, offer strong technology platforms, have experience in your industry, all that kind of stuff.
And then you use the demonstration script to go through the selection and get it down to a couple finalists and then you met your implementation team and you have a really strong contract negotiation process.
You made sure all your terms — the conditions were pretty much what you wanted and needed which is selection phase two.
And then phase three is the actual implementation where you take the time to get the software in place and you work with the technical folks to really understand — they make sure they understand your requirements again at a very detailed level.
They configure the application, maybe customize it to show it to you. You test the heck out of it — you're basically your super users test it to make sure it looks really good and meets their needs, and then you do really thorough trainings, some train the trainer kind of stuff.
And then you roll the software out to the end users. You have all your data migration done, all of your integrations are done, all that stuff with phase three implementation is done.
And at that point, usually our clients — they've gone live with the software. Usually it's a nonevent. Sometimes it can be a little scary, but you just work through that.
But by that time, most folks that go through this ERP lifecycle have what we call ERP fatigue, meaning they're tired of talking about the new software and what it's supposed to do and how to do the data migration for projects.
If you’re a professional services firm you have to move over all your in-flight projects for projects that are open, you have got to move over the historical billings and how much time was used. What were expenses? What were the recurring revenue schedules that we had? What's left to recognize recurring revenue?
Or software firm that have to deal with the contracts that they have in place, and they had to put all the contracts into the new system and sometimes that can be sometimes that can be a whole army of CPA's that have to do that because contracts can be a bit ambiguous.
So, there's just a lot of work that goes into the implementation, so by the time you go live, most folks are — they kind of wipe their brow and say, wow, I'm glad we got through that, and it's time to get back to my normal job.
And it is. But what can happen is folks don't realize they still need the care and feed that new enterprise software solution, even once it's in place.
So, what we're going to talk about then are three areas that we recommend that our clients really keep in mind in terms of once their applications are in place, what they have to do.
So again, I'm assuming all that work’s been done and it all went well, and if it didn't, go to our website, we got a bunch of other information for those other phases that could help.
So, here we go.
So, the first area for care and feeding of your new enterprise software is reporting.
Now this is really interesting. I've been doing this for a couple decades now. Our team or our combined team has about a — oh gosh, I think we're all getting old — we've got over 200 years of experience in enterprise software projects, so this is the real deal. Like this is all we do.
And inevitably what we see with our clients — the reason why they did the enterprise software switch in the first place usually is they wanted better data out of the application.
They wanted better reporting, so they went ahead and implemented a new system, put all the data in everything else so that they could have reports that were coming off.
I'm telling you every project that we do with our clients, clients rarely get the full breadth of reports that they want out of the phase one go-live. There just, there's too many other things you have to do to then do that last mile if you will — that’s a telecommunications phrase — we have to lay thousands and thousands of miles of cable. But you still have to get the cable to the guys place or the gals home for it to work.
It's that same concept here where you have to put down all the data. You have to get the business processes. Then you have to get everybody trained. You have to go through and shut down your old systems and get the new technology in place.
And there's so much work on that that rarely do clients actually spend the time to build out the reports that they needed in the first place.
Now the good news is that's why it's the first item on our list is after you go live, you can spend the time to really analyze what are the real reports that folks need? Especially once they've been in the app. They'll come to you and say, we need some software contracts or I need the waterfall schedule for rev rec to look like this. How do I do it?
And then you can put together the reports from there.
Another point underneath that is, you get used to what reports are coming out of the system already. Oh, there's no reports that fit my needs out of the app. Well, there’s usually like 400 prewritten reports, so after folks use the app for a little while, they'll start to see what pre-existing reports there are, so maybe those would help them, too.
So, that's the biggest area is be ready to write reports for your end users after go-live.
Now, the second area deals with something that is very hot right now, which is mobile and a multi-channel like omnichannel presence for interacting with lots of different users, maybe different stakeholders that the organization’s doing business with.
So, this is what I mean here is you did all the homework; you got everything in place so your app is working now. A lot of folks will want to get the exposure of the application beyond just their quote unquote “4 walls.” No business is within 4 walls anymore.
But within their employee base phase one, boom employees are using the app. Great, but you usually installed the software so that customers could interact a little bit more efficiently with you. They could do some simple orders online.
Or maybe even you have a vendor portal where vendors are posting their invoices for you to pay and you ask them to put the invoices there because you're tired of having emails and whatever is coming in faxes or even hard copies, and so you just say look, put them all here.
Or maybe there's even other stakeholders or other partners, certainly in wholesale distribution we usually have different kind of sales representatives or other partner firms that are out selling their products and so you want to put an order configurator out online.
So, that's a really key area is this mobile and omnichannel tools are put in so that you have folks that can interact with your software in a way that they couldn't before.
So, we really love actually to do that with clients, because again, it's just a much more efficient way to do business.
So, that's the second key area.
So, you've got the app in place, you've got your reports, now you've extended the application beyond your four walls, so to speak.
So, the third area of caring and feeding of your new enterprise software is just support.
So, this is a big one. I'm going to spend probably most of my time here on the call talking about the levels of support that you really need to have in place.
The other two issues that I mentioned are like — they’re like the icing on the cake. You've made the cake and put the icing on top, but the icing really makes the cake.
But the reality is the application itself requires — I think we've identified — we probably need to do another white paper on this — but we've identified over 15 areas that enterprise software needs to be supported in once you go live.
And I will guarantee you every project that you have ever done where you put in software, you've had to do these 15 things for every single project. You may not have even realized there were that many, but you had to do it because it was required.
So, let me walk through this here. The first thing I'm going to do in terms of support, the way we break it down is there's business support and then there's technical support.
So, we got two categories.
And within business there's three levels of support that we need our clients to provide. We help with that, too, but there's three levels of business support.
The first one is executive, the second is a consultant, and the third is analyst. And that's in terms of higher level little nebulous tasks down to very specific things.
So, let me talk about the things that this business executive support will have to do.
The first thing there is that somebody has to provide the strategic direction for what to do with your enterprise apps.
I mean, it might be as simple as, well, we run QuickBooks today and we have needs for professional services. We've been tracking time in QuickBooks and I'm not sure that's going to work, because we now are bringing in an inventory item and we're going to sell a piece of hardware with the services that we do.
So, what do we do for software for that then? That strategic direction — somebody has to say business is going this way, our customers are going that way. What do we do with the software?
So, somebody at the highest levels has to make decisions on what they're doing, so that's what we call strategic direction.
Then the next level that we have under the executive is a bit of a liaison role that that this executive plays with the vendor. It's kind of being willing to work with the other — well, let me actually change that a little bit, that one actually comes under consultant, I'm sorry.
So, we have strategic direction and then the next is called the executive liaison.
So, executive liaison is let's say it's the controller says that's it, I need new software. We're going — our business is going this direction. This is the way we need to go. We have to change.
Then that person then has to liaison over to the other executives in the business to get their support. It may be the owner who ultimately is writing the checkbook. It may be a CEO or VP of Sales or COO or other kind of liaisons where maybe this new software application will impact their operations.
So, there's a whole hat on how do you convince others to support new changing software, especially that impacts them?
So, those are the two hats under the business executive — strategic direction and then executive liaison.
Now the next level down of business support — we call it the consultant. This isn't necessarily an outside consultant, but it's somebody that consults with all of the users from the top to the bottom to understand what it is they want to meet and then works with the vendor at the highest of levels to get it.
So, under the consultant, we have three hats that they wear. The first one is improve the application usage. So, this person is looking at how can we utilize the application in a way that better supports our business?
So, an example of this is for, let's say, a human capital management application that this consultant role is working with the payroll folks or the HR folks. But it may also be specific employees to say, hey, how can we service you better for self-service and for other kinds of capabilities in the application.
Oh well, you know, we really need — a manager says, we really need the ability to track my applicants better online and understand who I've met with, how many interviews are left — I need some place to put all the documentation about this person so I can make a good decision.
Great, the consultant takes that and captures those as business requirements and then they go into their next hat which is vendor liaison where the consultant then works with usually an external party to actually build out some of the application usage requirements.
Sometimes you may have those developers internally to do that work, but I'll tell you, more than likely in our clients, the amount of business applications that they have is incredible — there's lots of them.
So, to maintain an expert internally for every single one of those apps usually is impossible. So, you have to then go work with a vendor on getting that done. And then there's contracting and paying them and all that kind of stuff and it usually sits on that business consultant internal to do that.
The last thing that this business consultant does also is they do license management. So, sometimes IT takes care of this, but usually it's more of a business person who really can track what software have we bought? How many users do we have? How much are we getting charged for this? When are the renewals coming up? Do we need the software or not? Should we just can it and go switch to something else? Then they talk to the executive of course.
But usually it's somebody who is fairly business kind of business techno-functional, like this consultant again who can understand what apps are being used for what, who can then say, hey, here's where we're at with the licenses and when the renewals are coming up.
Because if you don't pay attention to that, your contract’s usually set when you negotiate a deal to automatically renew, and you may have price rates or renewal rates that are super high, and you might be buying software or renewing you don't even need.
So, that consultant handles that function, so again, the executive does strategic direction and then they’re a liaison to other executives. The consultant does improving application usage, they’re a liaison to the vendor and then they handle license management.
So, I'm throwing a lot at you guys and we'll do a blog on this or whitepaper, probably both. So, if you want more data, just give us a call in the short term, but definitely look for those materials because there's a lot more to go through here, but you'll get the point of I'm trying to say here in just a minute.
So now we have, again, we have the business. We have executive. We have the consultant. Now the third major hat is called the analysts.
And this is the boots on the ground on the business side that's helping to support the application after it is implemented. And they have about five hats that we see them wearing.
The first one is they may do light application configuration versus heavy application configuration. They may add some custom fields. They may change a form. They may even build out some other kinds of workflows within the application. They're not too technical. They’re usually super business oriented, but they happen to be a little more technical.
That's the first thing they do is light application configuration.
The second thing, and I brought this up earlier because it — I just had to highlight it — was reporting.
So, these guys and gals are building out simple reports. So, you want to take an existing report and customize it, add some new fields to it, maybe do some metrics based off the data that's in the system, some KPIs and that kind of stuff, these folks do that.
The third thing they'll do is they'll administer security and roles so as you add new users, the analysts will usually set them up, maybe even add some roles that need to be created to limit the capability that a group of people have, so instead of doing each user’s security, create a role and then you assign users to that, which is super cool. That saves a lot of time.
They may also provide some user support, so meaning when there's a problem and somebody can't do whatever function they want to do in the application, so they call this analyst to say, help, I'm trying to run this report and it's not working.
Okay, well maybe that person can help with that, but this is more like trying to do a business function like trying to enter an invoice and the system keeps coming back and saying that it's in invalid data.
Well, the analyst knows how to enter a correct invoice and so they can help that person to get through that. Again, more business support they're going to provide.
And then the last area under the analyst is a mouthful, but it's functional upgrade regression testing.
So, what that means is, and this might be a surprise to some folks on the call, but when you buy a software as a service application like Salesforce or Workday or NetSuite, or Oracle Cloud ERP, or SAP ByDesign, Intacct. You know all these apps that are softwares that serve as pure cloud, they upgrade that application usually twice a year with major upgrades. But some of the vendors will update them weekly.
You might need — you wouldn't even know that they get upgraded. There might be fixes that some other client had a problem with that they decide to apply that patch on a weekly basis.
So, but when there's major upgrades, you have to have somebody that can regression test the app to make sure it works.
What regression test means is it means exactly — regression means to just go back instead of progression, meaning going forward. We're actually going backwards because now that that new software is coming out and we have to test it to make sure that our major business process cases are still met even though the application changed.
So, this analyst usually has to wear that hat and I'll tell you what, that is a hat that very few clients think about, folks that have been through implementations — and it can be a disaster.
Usually, the software vendor will help manage that fairly well, but you really do need somebody in there to do a regression test.
So those are the hats — the functions, basically — that the analysts wears. And again, there are five of them: light application configuration, simple reporting, administering security and roles, user support, and the last is functional upgrade regression testing.
So that's it. Wow, that's a lot. No, it's not. We didn't even cover the technical hats and the technical functions that need to happen to care and feed for your ERP. I'm going to touch on those here in just the last few minutes of our call.
Three hats under technical. There's a technical analyst, a developer, and an architect.
And the technical analyst is dealing with — again, that's more your boots on the ground, like the business analyst was — now we have a tech analyst. And this person is doing heavy application configuration, complex reporting, and then more technology upgrade regression testing.
So, what we mean there is, okay, we want to write a new application within a business app that we purchased.
So, let's say we want to write up a little simple customer CSR form, customer service representative form, to enter some real simple data into the application that we purchased. Well, you can go out and have a vendor that will do that for you. Or you might have internal resources to do it.
That is who that internal resources is — your technical analyst. And they're usually capable of doing some pretty deep application configuration.
Notice, I'm not saying development, but I'm saying configuring the app — lot of the click and drag, kind of what you see is what you get development where they might be building new forms and doing that kind of thing.
The second of three functions that they provide is the complex reporting. So, these people may go out with users and the users are saying that they want to bring data together in ways that doesn't even come close to existing today.
You need a technical analysts that really understand their needs, but then go into the app and they know the platform, they know the data structures, and they know the tools to bring data from different places throughout the application or maybe across apps to bring it together.
So, complex reporting is the second area that the technical analyst does.
And then their third function is the technology upgrade regression testing.
So, we had a client that ran NetSuite years ago and they had built out a lot of custom workflows on NetSuite. The whole business ran that way. And NetSuite made a change which we knew about to their workflow engine. But the problem was when they made that change, they broke every single workflow that the client had written.
So, had we known better at that time, we would have had more regression testing of the platform versus just even the functionality, but actually testing to make sure that the workflow engine worked the way we expected it to.
So, you get the benefit of learning from that client and some of the mistakes we made there is have somebody who tests the technology upgrades before they come out. They’ll usually provide a sandbox basically that you make those changes in.
Okay, two more hats here under technical.
The second one is the developer and they're basically customizing the application or the secondary as they're doing application programming interface integrations. So, they're making heavy modifications to the application, not configuration, but actually customizing, letting code into the application itself.
And there's this whole thing about, oh should we customize the application or not? Well, the reality is most clients need to do some of that, so having a developer and staff who can do it can be helpful.
And then the other thing they'll do is they'll write integrations between, let's say, Salesforce and a contract management system that when Salesforce has an opportunity that closes, it becomes booked and we want to push that over to our contract management system so that then we can start our billing from there. It's such a great use case, but it's hard.
Well, the developer would build those out, so those are the two functions under the developer.
The last hat we have under technical is an architect and this is somebody who deals with things like master data management, even new application design, data warehouse, and overall integrations across the enterprise.
So, this person is very technical, but they're able to look at how do we say a customer and our CRM is the same as it is in our professional services application, which is the same in our accounting application which is the same in our reporting engine.
So that's when we say master data management, it's managing data across the entire enterprise.
They may even be building out completely new applications on the platforms that you purchased, so if you buy something like Salesforce, theforce.com platform is super flexible and rich. So, you could build out the whole new app on that.
And then they're also, like I said, really responsible for how do we report and how do we manage data and store it throughout the whole application? That's what the data warehouse is.
Look, that's a lot. Definitely get the whitepaper on this, Juliette. That's what I wanted to talk through.
So, the key things to know here are definitely once you get that software in place, please keep these things in mind.
Any questions on any of this — let us know. But now you know, once you have the knowledge you can't go to the effect of not knowing, so none of these things are going to bite you wherever on your body you don't want to be bit because now you know about them.
Juliette, back to you.
Juliette: Wow Shawn, that was a lot of great information. Thank you for that.
Thank you everyone for joining us for today's call. And as Shawn said, definitely reach out to us and let us know if you have any questions. We are happy to help you. We can do email, phones, go to our website — we are happy to help.
Our next call is Tuesday July 10th: Pitfalls to Avoid When Implementing Your Records Management System. We will discuss how to avoid the most common points of failure when implementing your new RMS system to ensure your implementation will be a success, please go to our website erpadvisorsgroup.com for more details and to register, thanks again.
