The big change is a focus on verticals. Instead of buying an application that is generic and targeted to a very broad audience, you buy that stuff, and you also get components targeted to your specific industry. The big change is a focus on verticals. Instead of buying an application that is generic and targeted to a very broad audience, you buy that stuff, and you also get components targeted to your specific industry. There's a substantial change in the architecture. You can purchase components, so that you don't have to put the whole thing in. You can put in what you need. This is a result of vendors realizing that they all have to play nice with each other in order to do business. This is what SAP's NetWeaver is addressing. It's all about integration. The third way that ERP II differs is that processes are now able to extend outside the enterprise; portals is one way that happens. Back in '98 and '99, none of that this stuff was on the radar. A portal was a Web thing that you went to Yahoo for, right? Vertical applications? Well, if you were lucky, you were working with a vendor that had some experience in your industry. It wasn't a strategy the way it is now. Major vendors, including SAP and Oracle, recently issued support deadlines. Why now?
There are two drivers. First, it's in the best interest of the vendors. It's much more cost-effective to support only newer versions. Then, if we hypothesize that many ERP customers went live between '98 and 2000, they are somewhere between three and five years into their cycle. It's time. So what are most people doing?
I think what folks will do, instead of upgrades that require big change, is implement more technical upgrades. These can potentially be expensed, and they are laying the foundation for future activities. I could be wrong, but I think people are going to play it close to the vest. If they just … do the technical upgrade, they do have to go back to the users and give them changes in functionality based on what they have deployed. But that's not typically a big change. There's not a lot of change on the technical side. But when I do a big one, if I'm going to SAP R/3 Enterprise, those are major architectural changes. If I am going to consolidate instances, that's [a] harder change. The issue is there is not a lot of return when they are doing just technical upgrades. What I advise users to do is think of their technical upgrade as their future platform. Your future projects will be less costly because you are working with a more friendly platform. The new versions are built with all that integration in mind. What do you tell people who say, 'Do I need to get R/3 Enterprise now?'
You don't have to go to R/3 Enterprise today. But you should probably get yourself to 4.6. Now, SAP has been pretty good about this. I think the 4.6 support lasts for a while. What's the biggest challenge when it comes to upgrades?
The biggest challenge that users have is that they have to justify the thing. There are a couple of different tactics. One is a technical upgrade. Or you can choose the upgrade project as an opportunity to revisit some things that aren't working well, see the ghosts of implementations past. You can also choose a new function; you can deploy CRM or PLM as part of an upgrade. You can decide to add a big piece of functionality. Let's say I don't have the money or staff to upgrade in any way this year. How bad could life get for me?
I have had a lot of folks ask me, 'What's the impact if we … don't have maintenance?' I tell them to ask themselves these questions: 'Does the system meet all your needs today? Do you have a good data-archiving procedure? Are you willing to lock down any development activities?' If they say 'yes' to all those, then perhaps you can wait. How long?
You are going to put yourself on an island. For you to try to connect with trading partners on an old version, you are going to spend a lot more time and money trying to figure that out. It's a little like that Gilligan's Island episode. They could make electricity but, man, they had to pedal that bike, and that was tough. Is it up to the vendor to help me with my upgrade?
The vendor needs to step up and have great detailed documentation about what the upgrade means, so users can do the mapping. Ideally, the vendors would have tools available to help move the data to the new version. Now, of course, the users have made changes to the product over the years, and that mapping is not as direct as one would hope.