Managing Your New ERP System

stockfresh_95289_five-businesspeople-at-boardroom-table_sizeS
By the time most businesses reach the finish line of an ERP project, they begin to suffer from what we like to call “ERP Fatigue.”

By the time most businesses reach the finish line of an ERP project, they begin to suffer from what we like to call “ERP Fatigue.” They have already spent a lot of time, thought, and effort on seeing the project through to Go-Live, so the natural inclination is to get back to work as usual.

Request a Consultation

We want to prepare you for reality. In order to maximize the value of those initial investments, more needs to done. Processes need to be set into motion that will continuously care for and feed the new system. This might sound like bad news, but the good news is, if you are reading this, and you set-up the right processes proactively, the business will be in the top quartile in terms of ERP ROI.

Reporting, Mobile, and Omnichannel Functionality

Most ERP projects prioritize better data, mobile, and multichannel capabilities as main objectives. However, businesses rarely receive the full potential of these elements from Phase 1 Go-Live. Too many other fundamentals need to be established first. We like to compare this to the last-mile problem in telecommunications. When laying cable, thousands upon thousands of miles need to be laid, but the network still needs the last mile before any of that work becomes useful for the end user.

The same concept is at work here. Reporting, mobile and multichannel are the last mile of infrastructure to lay, which will unlock ERP value above and beyond the old system. So, you need to have a team in place who can write reports, itemize/prioritize business needs, and develop solutions. This team will lay the last mile and then continue to make improvements.

Reporting

The business needs to access data sources, generate reports in usable formats with the right information and distribute to all pertinent personnel.

Mobile

Employees want to be able to access key workflows, expense reporting, time tracking and more when they are out of the office. Mobile capability helps them stay engaged, increasing productivity while increasing data quality.

Omnichannel

Omnichannel functions connect multiple, siloed sales channels and merge them into one, cohesive and consistent experience across the brand to meet customer’s expectations.

These three areas are common goals of ERP projects today, but the specific goals might be different for your business. We recommend setting reporting as a priority but setting a roadmap for improving beyond the essentials, so that the business can develop a system where stakeholders can interact with the business in new, exciting, and ultimately more efficient ways.

Setting up the right team will not only turn these potentials into reality, but also ensure the system continues to run smoothly.

Business Process Support vs. Technical Support

A valuable new ERP system unlocks new capabilities.  Yet this requires the right human resources to care for, feed and maximize ERP value.  We have identified a minimum of 15 areas to cover in order to ensure the ERP is able to improve sustainably. Divided into business process support and technical support roles, these are further divided into activities to give you an idea of how the entire team becomes a strategic asset.

Business Processes

ERP Executive Appointee

Strategic Direction | Executive Liaison

The ERP executive provides strategic direction for the ERP while aligning that direction with priority business objectives. The C-Suite needs someone who they trust to be able to configure the ERP solution for their unique business challenges.  The Executive Sponsor is someone who can say some customers are leaving us because of X, and we can solve that with the ERP by doing Y and Z. That person also needs to be able to manage the rest of the business support team to execute new priorities efficiently and effectively.

Consultant

Capture Business Requirements | Optimize Applications

Despite the name, this role does not necessarily need to be given to someone outside the company. The consultant role asks: How can we utilize the application in a way that better supports our business? He/she will consult with users to capture business requirements, then serve as liaison with an external party to build out some of the application usage requirements.

Sometimes the “external party” will be internal, but because we have seen business applications proliferate, maintaining an expert internally for every application is usually impossible.  This means the consultant will most likely work with at least one vendor, and may assist with the contracting and payments.

License Management

You need to track software purchases and agreements, users, renewals, and to ensure payments make sense. Since you will most likely have multiple vendors, and each agreement will be unique, taking a proactive and detail-oriented stance on these agreements can be important to minimizing cost in the short- and long-term.

Analyst

Light Application Configuration | Simple Reporting

You need someone on the business side to support the business functionality of the ERP by listening to users, helping resolve challenges, and streamlining. We see this role performing five critical functions.

Light Application Configuration

After the initial go-live, applications will still need to be configured to meet the needs of business users. Analysts work on the business side of configuration, dealing with high-level workflow, but they might work with technical support to handle deeper changes.

Simple Reporting

Reporting can be light or heavy. Analysts on the business support side might add new fields or set up some metrics based on system data. This is the last mile in terms of turning data into information.

Security and Roles Administration

As you add new users, analysts will create groups, assign roles, and manage permissions, so everyone can access the information they need without compromising security.

User Support

When an employee has trouble accomplishing business functions with the application, such as entering an invoice, they rely on the analyst to help them move forward.

Functional Upgrade Regression Testing

Software as a Service (SaaS) applications, such as Salesforce, Netsuite, Oracle Cloud ERP or SAP tend to roll out major upgrades to their software twice per year. Regression testing ensures that these upgrades do not interfere with business functionality in any way, and it is an important role. You want to proactively fix issues before they cause problems.

Technical Support Team

Technical Analyst

Heavy Application Configuration | Complex Reporting | Technology Upgrade Regression Testing

The technical analyst is a boots-on-the-ground role which handles the more technical side of reporting and application configuration. We also recommend this role take a proactive approach to application upgrades.

Complex Reporting

Some new reporting capabilities will require the ERP to bring data together in new ways. This will require deeper knowledge of the app, the platform, the business’ data structures and tools.

Technology Upgrade Regression Testing

In this role, the technical analyst will work in tandem with the business analyst, fixing any technical issues with application updates. Using a sandbox to test the changes at this stage ensures the ERP will function seamlessly once the changes are made.

Developer

Heavy Modifications to Applications | Integrate Applications

An in-house development staff that can customize code for your applications and who is completely familiar with your ERP and business can deploy impactful changes.  This may outweigh the cost of using outside consultants.

Integrations

For any major application, there are a number of useful sub-apps and tools to deploy, and these will often require some integration to work at peak efficiency (i.e. Salesforce and contract management need to be integrated so that opportunities are continuously tracked in both systems without causing double data entry or other inconveniences).

Architect

Master Data Management | Application Development

The architect is very technical, but also can make intuitive connections between systems and applications, understanding/defining similarities in how a customer is understood in the CRM and also in a professional services application. Master data management requires a big-picture view of data across the enterprise. We also see this role building out new applications when necessary to execute the strategic direction.

Make Sure Your ERP Implementation is a Success

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.

RELATED