Today our topic is on upgrading or replacing your current system, whether it’s BPM, ECM, ERP — whatever business sytem you are using- ww will attempt to answer the questions, “When is it time for a new system?”
 

Full Transcript

Today our topic is on upgrading or replacing your current system, whether it’s BPM, ECM, ERP, we’re just going to talk in general about when it’s time to upgrade or invest in a new technology.

To start, I’ll ask you the question, how do you know when you just need an upgrade versus when it’s time to do a complete overhaul and you need an entirely new system?

Now that’s a great question. I have children, so it always reminds me, you know the old joke, “What time is it when an elephant sits on your fence? It’s time to get a new fence.”

This is sort of the same thing to me, because there are points where it’s just really obvious, the thing broke. Most of the time, though, it’s a lot more subtle than that. The thing is, probably you have systems in place and probably they’ve worked pretty well over the years. If it’s been there for a long time, it was possibly state of the art when you got. But of course, the state of the art has advanced since then. But you don’t have the newest system, so you don’t know what you’re missing.

So a lot of times the thought gets planted, at trade shows or conferences or during webinars where you’re learning new material, you’re hearing from other people in the same kinds of businesses that you’re in, you discover the kinds of things that they’re doing and the capabilities of the systems that they’re using.

You realize you don’t have those or you only have some of them or they don’t work to the same degree. You sit back and you think, “Oh, this thing we’ve got is doing the job, but gee, what could we do with that extra functionality?” In some ways I liken it to when’s it time to get a new car and the whole, “Well, I want one,” versus “I need one,” kind of thing.

If you just need a station car to go back and forth to the train to get to work, you don’t really need the latest and greatest or the most comfortable or the most sporty. But if you drive long distances regularly or you’re a sales rep and you’re constantly living in the car, the creature comforts are more important. So if your seat starts to sag and your back starts to hurt, it’s like, “Well, OK.” Or the maintenance costs are getting to the point where it’s the rough equivalent of a new car payment.

It’s the same thing with the information technologies, it works, you’re getting your job done, the outcomes are acceptable. But maybe it’s time, how do you know? That’s where you have to start looking in the mirror and saying, “What really do we need? Where are the choke points? What are our colleagues at other companies doing and facing? Are we having those same issues? How are they addressing it?”

Really go through that strategic pre think that we talk about almost every time we get together and start making the lists, just like you would with a new car.

So what are the biggest considerations that you need to make when you’re thinking about this situation?

Well, I’m going to ignore, for the moment, the raw budget piece of it, nothing’s free. Some things are less or more not free than others, if you follow that twisted logic. But I would classify the considerations into three buckets, I think. Economics is one, but beyond raw budget there’s that whole notion of do we want to make this ourselves or do we want to buy it.

If you have a big IT staff and they’re well capable, maybe there are just improvements that can be made or interoperability connections that can be forged. Maybe there’s code that can be written, your own people can do. Or do you want to go buy it from a vendor and license a piece of software and partake of their services?

Do you want to rent? Big on the air quotes today. The whole notion of the cloud or time sharing or software as a service or whatever you want to call it. If you want to do that from a third party, you kind of rent the application. It’s another way to go, it’s an economic consideration as much as anything.

Certainly there are budget ramifications there. But it’s a little bit different than just the raw price tag. So that’s the economics.

Functional considerations have to come first. Is it doing what it needs to do? The things that may be missing or less deep, do they exist in another system somewhere? Is there a way to forge that interoperability I just mentioned? Because maybe, in fact probably, you don’t need, these days, a single system to do it all. You may have pieces of functionality already in your organization that you can leverage.

So the whole interoperability piece, to me, has a big play here, more so, maybe, even in direct programmatic integration. But there’s trade offs there too. That leads me into one of the other considerations, which are human. Do you have the skill sets? Maybe you don’t have the knowledge in house. So do you want to bring in a consultant? Do you need to hire someone?

How many vendors/technology stacks are we talking about to be interoperated upon? Because there’s a line to be drawn there, but sometimes it’s a dotted line. So going a single vendor route can, but not always, but can make some sense that way.

The human considerations often, just to back up for a second, relate to that question about, “Well, how do you know when it’s time to?” Especially if you have an old system.

There may be one fellow or gal in your organization who knows the code. When that person gets up to retiring and leaves the company, there’s nobody left to maintain it.
You hear stories about those kinds of people who retire and then come back as consultants. Of course, the joke is, you’re paying them more as consultants then you ever did as an employee because you have to.

We tend to think about these technologies and these solutions as always being brand new, shiny, and out of the box. When it breaks or gets old, we toss it out and put in something new. It doesn’t really work that way.

These are not MP3 players that are practicably disposable. They have long enough lives that the life cycle not only of the technology but the people around it do play an important role. All of these things need to be rolled up into one in order to help make that decision well, is it time?

Is there a rule of thumb for how often you need to go back and look and say, “OK, what improvements can be made? What do we need, an upgrade? Do we just need to look at our processes? Do we need a new system?”

I haven’t found ones mathematically. When I ask that question of the students in my class or my clients, there’s relatively little consensus except, “Oh yeah, we should do that.” Most of the consensus is, “We should do that, but we don’t.”

The number that pops into my head is every two years, maybe. The ideal steering committee, the ideal government committee, the ideal needs assessment committee would do this regularly to make sure that they’re not falling behind. That there’s somehow somebody designated to keep tabs on what the latest solutions are and what they can do to keep tabs on what colleagues and competitors are doing. To keep tabs on your constituencies, whether it’s your end users internally, your customers externally, or your business partners.

What are they asking for? What are they complaining about? I wouldn’t do it every 10 years and I probably wouldn’t do it every 10 months.

But every couple of years, it’s worth circling back, sitting down and trying to do this with a little formality to make sure that it happens, so that you don’t get left behind. The flipside of that, too, is there are competitive advantages to be gained, especially in a down economy. If you’re fortunate enough to be in a position to do these deep things and make some strategic investments in your infrastructure, it puts you that much further ahead of your competitors who may just be clinging to survival.

So when the economy finally does turn around, you can really leave them in the dust. You may have a 2 year lead on them in terms of the latest and greatest.
Finally, not necessarily a function of a bad economy or a good one, but the regularity with which companies tend to merge with each other or swallow each other. That’s a good time to do this, too.

Part of those discussions about how to merge the operations needs to focus on a lot of these same issues. What technology stacks does the other group have that you can leverage or plug into, or maybe it’s their stuff that needs to be thrown out. Those kind of obvious transactional touchstones are good times to sit down and do this as well.

How do you make sure that when you go out and start looking for a new system or upgrade or whatever it may be that you’re not just going to end up making the same mistakes or end up with the same bad processes or the same bad system?

First of all, I have to congratulate your class for paying such good attention and talking about getting maximum total value, because of course, that’s my whole thing. Looking at the process and the collaboration as well as just the money surrounding these things. That’s my sense of maximum value. Checkmark for you. The other comment I’ll make, and it’s a common sensibility, just like a car, to go back to that original analogy, these things just age out eventually. It doesn’t mean the one that you had was bad or that you made a mistake in picking it or that something’s wrong with your operation.

I tend to gravitate towards that as well, because it’s the most dramatic example of the kind of circumstance that we’re talking about. The fact of the matter is, as we’ve hit upon, markets move, businesses change.

Just the natural course of events will cause the technology stacks to show their age. It doesn’t mean that they’re broken, like I said before. It doesn’t mean something has stopped…occasionally a server will die. Those things happen.

But I don’t want people watching this to think that, “Oh my gosh, I did something wrong,” necessarily. As we’ve talked about in the past, for the most part these things work and they work pretty well.

The real key to getting maximum total value from it is understanding your needs. We go back to the question you just asked me. Make sure that you’re in tune with what’s working optimally, where there’s room for improvement, whether the improvements to be gained would be worth the investment to make those improvements. There’s diminishing return as well that comes into play.
It’s not so much to me avoiding the same mistakes, although if you made mistakes, that would be good to avoid. But really looking at where do we go from here? In the classes, we talk about how do you move from the current state to the future state? You take those inventories about what do we have and what are we doing, and we measure things and we figure out what the goals need to be.

Then you start mapping the capabilities and the existing solution to that list and see, is that achievable, or do we need something more, or do we need something different? Or can we leverage something over there in the organization rather than over here?

It’s not that things were wrong or bad, but sit down, look in the mirror and say, “Yeah, we could probably do that better.”

You’ve worked with a lot of companies, and just to kind of branch off from there, I’m curious, have you ever been called into a situation where maybe a business had recently got a system or maybe it was something out of the box that they tried to do themselves. Have you ever seen a situation where the system they put in place just generally did not fit their business at all, and how did that happen and what did they do?

Yeah, it happens. It usually happens because one or the other of those considerations got missed. I think usually it’s the human part, in my experience. The needs assessment, the functionalities, they can be incomplete, but they hardly ever get missed. The economic considerations, if the organization has any kind of business sense, same thing. They might be incomplete but they’re hardly ever missed.

But the human considerations, as it so often proves to be, really can take an otherwise good idea and consign it to the scrap heap, or at least it didn’t work, although functionally it kind of did.

The notion of skill sets, I have this little catch phrase that I use, politics, baggage and religion. This falls under the baggage. Everybody knows about politics in companies, and the religion is it has to be one vendor or another or I can’t even talk to you, kind of thing.

Part of the baggage, and certainly the religiousness will weigh you down, but part of the baggage is the people that you have, what do they already know how to do? What knowledge do they have, what experiences have they had, either with your company or in a prior organization?

I’ve seen companies that are pretty good at what they do, and then they decide they want to do something else, and they don’t realize, for instance, we’re a Microsoft shop, our people can make Microsoft products sing and dance, but they’re going to put in a product that’s built on Java or something else.

Again, it may not be the wrong choice, but if they don’t have the people who can work with that tool or in that environment, that can really be problematic, especially if it’s not thought about at first. Because then you end up having to decide, “I’ve got to buy the services from the vendor or I have to hire somebody new.”

It becomes this extra layer of uncertainty. All addressable, but there’s time and money you may not have thought about. We tend to talk about human factors as being critical to solutions’ success in terms of user adoption and change management and that kind of thing. Interface, ease of use.

But it also works on the other end of this. I think that’s what we’re talking about here, where you go through what do we need the system to do, and that’s all great, but you forget about what’s necessary to get the solution to do that.

To me, that’s a human resource issue, less certainly than a technology issue. Did that get to the question? I think that maybe it did.

Do you have any final thoughts that you would like to leave us with?

I think I just close with what I always do, is the need for introspection, that you really do need to sit down and think about stuff before you do stuff. It doesn’t all have to be life, the universe and everything, but you want to make decisions because you made decisions, not because things just happened and they became decisions.

That has as much to do with which systems to buy as whether or not to upgrade your system in the first place. You have to sit down and ask the questions and get answers that are defensible from a business standpoint before you can really do anything else. Otherwise you’re trying to steer from the back end of the process and that’s really hard to do.

More by Steve Weissman:

You might also like:

3 Tips for Getting Executive Buy-In	The Hidden Costs of Doing Nothing	Unscrambling the Process Technology Puzzle

Link to original post From http://www.iDatix.com

About Samantha McCollough

Samantha McCollough is the Marketing Manager at iDatix. She came to the company with a passion for business and technology coupled with experience in content creation and inbound marketing. When not writing, she enjoys scuba diving and spending time with her 2 dogs.