JD Edwards Application Support vs CNC Support: What’s the Difference?

Yeah, I actually really like talking about this because I feel like most companies kind of treat tickets as you get a ticket, you work it and you close it, you fix it, you move on, on to the next one.

But I feel like here to your peace, we really try to take a step back and really look at these reoccurring tickets. And I feel like it's kind of one of the best signals you have where you can kind of take a step back and look at, you know, why is this issue keep popping up, happening again and again.

So I really like the trick is to stop looking at tickets one at a time and really look at them as a whole because I think the patterns can tell you really different thing depending on like which side they're coming from.

So you know, if you're seeing the same application tickets over and over again. So, you know, the same questions, same mistakes. It could be that's not a issue. They're usually pointing to one or a few things.

And maybe it's a training gap. So people genuinely don't know how to do the process. They don't know how the module works, and they need somebody to help them understand how this module works.

And maybe it's a configuration problem that just never got fixed. So, you know, people just kind of keep pushing that off and maybe that process is just funky or maybe there's just bad data.

But again, you keep looking at these reoccurring tickets and you start noticing these patterns and like, again, we like to take a step back and see what's going on and try to like fix that.

You know, so goes the same way for the CNC side. If we're getting repeated tactical tickets, you know, it could be pointing to something with a performance tuning or a monitoring gap or, you know, something that's going on in the system that we need to take a step back and look at and say, you know, if this server is constantly hitting, you know, Max resources, so it's maxing out on CPU or memory.

Like this is maybe an opportunity for us to add more resources to the server. And then hopefully that, you know, orchestration that's running out there on the EIS server starts running more efficiently and isn't dying in the middle of processing.

So really I feel like when you kind of zoom out and you look across all the tickets and you see these trends, you know, maybe also you could be simply just under resourced.

So again, that's something if you kind of look at these and you're getting, you know, high, old and high of the tickets coming up and you're, you're just not able to handle that volume. You know, it's, it's useful to be able to look at that stuff and say, well, maybe we need to hire another functional resource or a CMT for that.

So, you know, really I feel like the way I'm just kind of summing up is don't just close the tickets, like really read them, make a step back, look at the patterns.

You know, the individual ticket is a problem solved. But like that pattern across all the tickets is really, I feel like a road map and how we we do a better support model for our customers.

So the team's really just, you know, they pay attention and they stopped fighting the same fires over and over and we just actually start fixing things. And not only does it make our lives easier, it makes our customers lives a lot easier. So I feel like that's the most important piece of that.

So, yeah, yeah.

And it's that idea of like, yeah, you can have these recurring tickets and you can put out that fire every time. And yeah, that might be a quick win, but you're not getting at the big fish there. You're not getting at the true problem there.

So you're going to have that problem over and over and over again until you really do. And that's a perfect way of putting it. Take a step back, really assess why this is happening instead of being focused in on, all right, this is the main, this is the specific issue.

Let's try to fix that specific issue because then, yeah, you can see it in multiple things other than just that one specific situation that you're in.

But what should like a good classification look like between application and CNC teams?

Yeah.

I mean, I think again, the most important thing here is just to really emphasize through users putting in the tickets to just put as much detail as possible. I think that's really the 1st and then like most important thing, you know, what is happening, where is it happening?

How is it affecting you? Is it affecting just you or is it affecting multiple people? Has anything changed recently, you know, and when exactly did this start happening?

So those types of things are so helpful and really quickly just help us identify what's going on.

And so from there, you know, the goal is just identify that issue quickly, but not try to force that into the wrong bucket. So sometime it's obviously an application issue and then sometimes it's clearly ACNC issue.

But again, you know, there are plenty of situations where it's not immediately obvious, and that's OK. But I think the worst thing that you can do is just spend hours arguing over like the ownership instead of just solving the problem and working together as a team.

So I feel like that's where that collaboration, you know, part really becomes important. And if the root cause isn't clear, whether it's application again or CNC, it's important just to work together as a team behind the scenes.

And you know, that's, that's helping the application team can validate the business practices working correctly, while the CNC team can verify, you know, the environment or the backbone, you know, technical backbone there or the security, you know all that is working as it should.

So, you know, if you're able to look at it from both perspectives, I feel like usually you can get that answer much faster than working and that like isolation or working on your own.

But I would say at the same time, there still needs to be very clear ownership. So if both teams are involved in working together, I do think it's important that like one team owns that communication with a customer because you don't want that back and forth.

And then again, you're wasting time going back and forth between multiple people. The one team should ideally own that communication with a customer to really drive, you know, drive the issue to a resolution.

And that just prevents the tickets from falling through the cracks and gives the customer like a really single point of contact, which just, you know, always makes things easier.

And really, you know, finally, like the, the good support isn't about just closing the ticket, right? It's, it's about recognizing those patterns again, you know, if you see the same type of issue occurring over and over, that's an opportunity to improve the training, fix the process, like address some configuration or tuning issues.

And then, you know, that's when the support really becomes proactive instead of just being reactive.

Oh, I like that. I like that a lot.

But it's a big theme that we have on this podcast is being proactive instead of reactive because again, like you could be sitting there and having these similar issues, taking down your system that cost money, that cost time.

And those two things for a lot of our customers are something that they will not give away.

So I mean, yeah, all you have to do is kind of look, take a step back and understand the actual problem and tag it there.

But that kind of goes into my next question here. How should some of these JD customers decide whether they need application support or technical CNC support or maybe a combined support model?

Well, and that's like a really great question. And you know, again, we do have a lot of customers that come to us and they may not be clear on like what they actually need.

And you know, I think our kind of recommendation is, you know, think of, think about this from the business perspective and really, you know, look at look at your task tickets, like look at, you know, what's actually breaking.

So whether you're looking at, let's say the last three months or six months worth of issues that have come up, you know, go through those tickets and read them. I know it takes time, but that's really like what is important and what helps you kind of identify the support that you need.

So you know, looking at those patterns and, and that should really help you just determine like what direction to go in here for support.

And again, the way I look at it from a business perspective is, you know, if most of your issues are about the users and the business process and like actual functionality of using JDE, somebody can't post the transaction or a reports coming out incorrectly or master data is just an absolute mess.

You know, set up questions on AP, something like that or you know, procurement, manufacturing that really points to application, application or functional support. That is the functional world.

And it's it's people trying to do their job in a module and something is just not behaving.

And now if you flip that, if most of your issues are about the system kind of underneath again, that technical backbone, the environment setup, deployment package build, doing the tools, release upgrades, applying ESU, performance tuning your batches, how you know how your batch jobs are running, security, you know, that's all that technical level, that's the the CNC side.

And the users might not even see that directly. But when when stuff goes sideways and JDE like and everything is going sideways again, that points to you're having a lot of technical CNC issues and you probably should go the CNC route for support specifically.

And for like a lot of businesses when they kind of sit down and do that exercise again, I know it takes time, but the answer could honestly be, well, maybe we need both and that's kind of the third tab.

So you know, maybe you're having a lot of technical performance issues, but you often need help with how a module's working and that functionality of the module.

So when they're cross functional or when it's just kind of maybe really difficult to diagnose and you're having a lot of those cross functional issues, you know, that's where maybe you start to look at, well, maybe I need functional application and I need C&C support.

So you know, there there's the thing, you know, with the theme between the functional and technical side, right? But that's where the handoffs live and that's where you know the handoffs or where the time gets wasted.

So when you can look at it like a company or a business that can provide both that functional and that Technical Support layer, and you can sit there and, and work with both teams or they're working together behind the scenes, you know, that combined, that combined model really kills that ping pong and that wasted time.

So what question should buyers ask a support partner before they sign up or something like this?

All right, well, I think, you know, one of the most important things buyers can do before signing up with a support partner is just get a very clear idea of what support actually means.

And trust me, that word can mean, you know, very different things from, from one provider to another. We, we know this from experience. We hear this just based off of, you know, talking to our customers and getting that feedback.

And you know, I'd really start by asking what's included in the application for, you know, are they only fixing issues when something breaks or, you know, are they like actually helping with user questions and business processes and guidance and training and, and testing and ongoing optimization, right.

So if you're using, you know, if, if you're using JD Everett from a CNC perspective, I'd also ask, you know, what's covered there.

So this is the court includes system administration, performance tuning, package build are are they going to help us go into the right direction?

You know, when we're looking for guidance on what our our system needs, do we need to upgrade those types of things? You know, is that included in, in that support that we're getting?

Like I would also say too, like asking more questions on what is supported is, is so helpful too, because you might be surprised with some, what some companies offer support wise, other companies don't even think about, you know, so we, we, we always try to look out for our customers.

We always try to cover, you know what we can for our customers, even if it's stuff that we don't necessarily support, we will try to help as best we can, right?

We can't guarantee you we're going to be able to fix that problem, but you know, we can be there for that support, whether that's the application side or if that's that technical layer.

I think another important question is how do they handle tickets that specifically aren't very clear exactly what we've been talking about, right?

So in the real world, users don't always know what the problem is, whether that's technical, functional, again, maybe a training issue.

So I feel like a good support partner should really have that structure, triage of the process and how that identifies that root cause instead of just simply bouncing, you know, the ticket between the team.

So you want to know that when you're you're looking for a support partner that they have these support teams that are going to work together behind the scenes and really try to make the customer successful.

You know, I'd also want to know whether the they provide both functional and typical support. So you want to make sure they have both that expertise.

There might be companies that only kind of dabble in the, the functional side or that CNC side, right? So, you know, you want to make sure that if you're talking to a support company that you see if they can support both of those.

And it's just really important to kind of understand where they draw the line between the support and the project work as well.

You know small enhancements. You know practice improvement. Small pools upgrade their configuration changes. You know, sometimes those can fall into the Gray area.

So really setting, you know, those expectations up front kind of helps avoid some of those surprises later.

And I'd also ask like, how do they deal with the reoccurring issues? Again, we talked about that earlier.

If that thing ticket keeps coming up, are they simply just resolving that over and over or are they actually taking a step back and investigating that underlying cause and really trying to find a permanent solution so that this doesn't keep happening and it's not a pattern that keeps happening.

So, you know, one last thing is just, you know, like what monitoring tools do they use? I think that's kind of a really important question as well.

How do they manage tickets? Do they, you know, handle documentation? Do they document processes? Is there knowledge sharing? How do we handle escalation?

Those types of things and, and those types of things may not be exciting, but those are some of the most important things that you should know going into working with the support partner.

And you know, like ultimately the best support partners, you know, we don't just keep the lights on. We really help customers mature over time.

We want to be the we want to be the expert for you and help, you know, move you into the right direction.

And instead of being reactive and, and trying to break fix these models, we want to have a proactive approach and we want to fix these reoccurring problems and, you know, help reduce these issues.

And we want your system to be more stable. And, you know, that's, that's just what our goal is at the end of the day.

It's not just the, hey, put in a ticket. We're going to fix it. We're done.

You know, we really want to help support you and, and have the best, most efficient system as possible.

Yeah.

So if you're if you're one of the customers that are out there right now listening to this, what would you say the best take away from this episode would be?