Archive for February, 2009

PRMS – Wha’cha Gonna Do?

So these are the facts.  PRMS will continue to be supported by the help line but there will be no more releases of the product.  The only upgrade path will be to interface other server or i based packages from the Infor catalog with PRMS.   Given those facts, what makes sense as a strategy?

 

And maybe you don’t need a new strategy.  Not trying to imply that you do.  PRMS is a very stable product with a lot of functionality.   Many PRMS clients could go on using it just the way it is for a long, long time, without making their business suffer.  For these folks, as long as they have a perpetual license to use PRMS maybe it doesn’t make a toad’s worth of difference what Infor does.   Or maybe you want to at least rethink your options. 

 

A Word About Upgrading

 

I think that upgrading is not something that a lot of people spend a lot of time thinking about.  If you are on 8.4 right now do you really care that Infor is not going to offer any more releases?  After all, there are four releases sitting out there waiting for you already that you haven’t gotten to yet.  What kind of enhancement are you waiting for?  Even if you are on 9.2, the number of people who have moved to 10.0 (maybe I should say the number of people who haven’t moved to 10.0) shows that right now upgrading is not something that is really on people’s minds. 

 

Why?  I think there are two reasons. 

 

First, PRMS is pretty complete the way it is.  Oh, I know there are things you’d like to have but I would be willing to bet that 95% of the things that most people want would be used by only 1% or 2% of the folks out there so it’s kind of hard to justify putting them in the package.  Like I said two posts ago, many of the items being added to the other midrange products are already in PRMS. 

 

Second, one of the big inducements to upgrade would be if the package were going GUI and the main reason for that is that in most companies finance has the final say over any money expenditure (like an upgrade project) and they are the ones most in favor of GUI.  Without that carrot, there’s not much incentive. 

 

Third, I know I said two reasons but it just occurred to me that another problem is there are no more user ERP champions.  In the past these people would get folks excited about an upgrade but in today’s world were everyone is double booked, there is no energy left to do that.  IT becomes the default champion and you can’t really expect them to get too excited about an upgrade, especially one that they would lead. 

 

At the same time, even though people are not upgrading, I will admit that not having any more enhancement releases coming will make some people who would not have considered upgrading think about switching to some new software because their current product is ‘going nowhere’.   That’s just one of the weird things about how people think.  Makes no sense but is a fact. 

 

Stay on Maintenance?

 

I think at this point you have to sit down and ask yourself some serious questions.  If you are not going to upgrade, or if you are already on 10.0, then you have to ask yourself if you really need to be on maintenance.   Maintenance makes sense only if you are going to take advantage of the help line or the upgrades.  Most PRMS companies use the help line only a minimal amount, perhaps once a year or so.  And there aren’t going to be any more upgrades so no sense waiting up for that.  You could save yourself a pocket full of cash and use that money to do some add on work to PRMS for stuff you really need. 

 

And that is tempting for a lot of companies and may make sense.  One thing you want to watch out for, however, is by dropping maintenance you will probably be cutting yourself off from the evolve packages that Infor will be making available for use with PRMS.   Remember that is the whole crux of their upgrade strategy for PRMS – these off the shelf packages they have sitting around that can be tied into PRMS.  (Note – I don’t know this for a fact and have been unable to get a confirmation out of Infor, but it only stands to reason that you would have to be on maintenance to get the evolve strategy modules or at least to get them at a cheaper price.)   

 

Of course, the other thing you want to remember is that these Infor packages are not plug and play, they would have to be made plug and play for your particular release  and configuration of PRMS.  And that would cost money.  Plus, you have to remember that Infor isn’t the only one who has these GUI type packages available for integration.  There are lots of companies out there with a ton of different products.  The advantage of Infor is just that you don’t have to go looking too far.  If you dropped maintenance you would still be able to tie other packages in to PRMS and you could use your former maintenance dollars to do it.  Which isn’t really all that bad since there are a ton of people out there selling custom solutions and plenty that would work with the i (vice a Windows or Unix package). 

 

You can go back on maintenance later, of course.  Sometimes there is a fee for doing so,  something over and above your back maintenance costs.  And sometimes there isn’t.  Just depends on how bad Infor wants to get you back. 

 

So, am I saying you should drop maintenance?  No.  But I am saying it’s not evil to at least think about it.  Does it make sense for you?  Would you take advantage of anything covered by maintenance if you stayed on?   Just be honest with yourself. 

 

 

So, Is There Anything You Would Recommend, Dave?

 

Of course.  First, unless you are already on 10.0, I would recommend upgrading.  I know it sounds self serving but I think it makes a lot of sense.  And yes, that includes those of you on 8.4.  It’s not that bad, you just have to pay attention and do things in the most efficient and sensible manner.  And if you are on 9.0 or above, it is a relatively straight forward process.  I just don’t see the point of leaving anything on the buffet, after all, you’ve already paid for it, and you might as well take it home with you.  In most cases, you can do the upgrade (even from 8.4) with minimal impact on your users.   Most of the new functionality can be turned on later, when it is needed and when people are ready for it. 

 

The second thing I recommend is you start to take a very serious and comprehensive look at what new functionality the business is going to need over the next few years.   And check the wording here; ‘need’, not ‘want’.  There’s a difference.   To be quite frank, sometimes this is something that requires external help (someone like myself – hint, hint, nudge, nudge).  For example, the belle of the ball today is flexible or ‘multiple’ GL’s; being able to look at your financials from a number of different perspectives and ground rules.  But is this something that you really need, something that will actually contribute to the bottom line, or is it just something that is in vogue right now and we want it because all the other kids are doing it and it sounds way cool?  And is it something that you can build into PRMS or is it the kind of thing that really needs to be separate and interfaced with PRMS.  Remember, new functionality is more than just new functionality.  It is also new complexity and you have to make sure that the benefit is worth the increased complexity that any new thing brings.

 

Third, start thinking about what’s really important to you from a system perspective.  For example, I put a real high premium on keeping as many things as possible on the i, vice on servers sitting on boxes around the computer closet.  And I put a real high premium on keeping all of my data within the DB2 data base in PRMS.  But you may not feel that way.  You may want to recklessly distribute your data or add software that runs on independent servers until you have no more rack or floor space.  It’s up to you.  What’s important here is that you decide what scenario you feel most comfortable with because that will be important in helping you choose how you are going to satisfy your future enhancements appetite.   

 

Bottom Line

 

Unfortunately, there is no consensus here, because every one is special and unique.  For some, it may be time to cut the cord and go your own way.  For others, you may want to keep on keepin’ on and get whatever (if any) advantages that brings.  But no matter who you are it seems to make sense to do three things; get to 10.0 so you get all that there is to get, think very rationally and analytically about what functionality needs to be added to PRMS, and decide if you are an ‘i’ type or a ‘server’ type shop.  Start with that and see what the future has to offer.

PRMS – What Went Wrong?

When all is said and done I will have written four blog posts in a period of a week on PRMS.  I think that’s more than I’ve written in the last year.   It’s like now that we have a clear statement on what is going to happen to it that I just need to clear out my thoughts so that I can move on. 

 

I guess the thing that really strikes me is – this is so unfair.  It is unfair that PRMS is singled out as the only one of the four Power i ERP systems that is not going to continue being enhanced.  PRMS is a good ERP system.  It’s reliable, it’s easy to work with, there’s a lot of functionality, and I don’t know any technical person who has ever complained about having to deal with it.  Try matching that record with someone who has worked on JDE One World. 

 

But in this world there is precious little justice and I think that PRMS owes it’s situation to four basic facts. 

 

The first and probably most important was that it was bought by CA.  PRMS had a full head of steam up prior to that acquisition and was a major player in the midrange ERP market.  CA did absolutely nothing with the package and the sales initiative evaporated.  If you don’t sell it, you can’t expect it to continue to grow. 

 

Second, the PRMS developers split the user community by creating overly complex upgrade scenarios.   It’s easy to cast stones now but there were no benefits to the normalization in 9.0.  And the way it was implemented made moving to 9.X a challenge that many companies decided they could do without.  With many of the users on 8.4 and deciding that was the end of the ride for them it took away an important group of people clamoring for new releases plus reduced excitement for PRMS among the base. 

 

Third, many of the new components put into PRMS were overly complex.  Ever dealt with the currency server?  Even the date server was a pain to use.   That discouraged people from using those (and other) modules and contributed to the decline in interest in where PRMS was going.

 

Finally, even though I hate GUI (there, I said it, sue me!), PRMS was too slow adopting a GUI format.  As soon as the sales force realized that they couldn’t sell a product that was green screen, they should have bit the bullet and started to develop a true GUI version.  The emulation route never worked and nobody trusted it.  They could have done this module by module starting with Finance.  I would have hated it but it doesn’t look like they were taking my preferences into account anyway so who cares. 

 

But it’s all water under the bridge now.  I am going to turn around now and never think of this again. 

 

Yeah, right. 

The Future of PRMS – The Plot Thickens

I have done some more research on the Future of PRMS.  I have taken the liberty of reviewing the other future webinars for the other midrange products that Infor owns; LX (formerly BPCS), XA (formerly MAPCIS), and System 21 (formerly System 21).   The webinar downloads are sitting out there on the Infor Excellence Center web page (http://www.infor.com/systemi/) so I guess it’s not illegal.  You have to sign in to get to the download but that just involves putting in some basic info like your name, company, bank account numbers, that sort of thing. 

 

Anyway, the first thing that struck me was that of the four products, PRMS was the only one where the webinar didn’t talk about upcoming releases.  In other words, Infor is actively (very actively in fact) upgrading those other products but not PRMS.   It is true they are allowing PRMS to continue living, but not enhancing it is somewhat of a slap in the face, don’t you think? 

 

To be fair, PRMS already has many of the things that are being added to the other products.  But that’s not the point.  Why is PRMS being singled out in this way?  A couple of years ago they were giving MAPICS the last rites.   And now it’s got a string of new releases scheduled?

 

The answer is, I think, fairly simple.  PRMS is just the odd man out.  System 21 is a GUI based product.  XA, even though it was more or less dead continued to make slow progress toward a true Java implementation and now they are releasing their last green screen capable version, after this it will just be GUI.  And SSA gave preference to BPCS over PRMS (I guess I can understand that) and that preference has been transferred over to Infor. 

 

I mean how much more obvious can it get.  There is literally no PRMS presence at Inforum.  No releases of PRMS are forthcoming even though work proceeds on the other midrange products that Infor owns.   The webinar announcing PRMS’s future has a series of slides showing how you can piece by piece replace the current PRMS modules with other products (I didn’t see that slide in the other packages presentations).  There is no effort that I can see to sell or even encourage people to stay on PRMS.  I am attending a meeting in a few weeks at a PRMS client site where the Infor sales guy is bringing along some XA folks.   It’s like the family from hell.  We’re not going to kill you but you can’t live here and put that piece of pizza back in the box, mister. 

 

And I feel bad about that.  I like ole PRMS, I really do.  The code is solid and much easier to work with than many.  The functionality is very integrated and provides the bulk of what you need for most MRPII installations.  And it doesn’t require much support, pretty independent it is.  

 

So what went wrong?  And what should the sensible person do about it now?  Good questions, but this blog is already too long so those will have to wait a few days for new posts. 

EDI Simplification

I was reading a blog post by Klaus-Dieter Naujok on his blog last January. 

 

Yes, last January, as in 2008.  I just found his blog, it doesn’t seem to be active now but I took a quick look at the posts and this one interested me.  It was about EDI simplification. 

 

Now ideally, EDI simplifies things.  It allows you to trade with multiple vendors with no (well, very little) knowledge of their system or how they do business.  If you have properly integrated it with your business system, it provides a very efficient and automatic way to transfer data between you and your trading partner. 

 

But if that is true (and it certainly is) then why are so many EDI departments just awash in detail and complexity? 

 

The gist of  Klaus’s post is that it is the fault of the document standards; there are too many elements in the segments and too many options for companies to use.  He seems to have been involved in an initiative by EDIFACT to develop simpler standards that were scenario driven.  That is, you decide what you want to do business wise and there would be a specific scenario with specific segments and elements that need to be passed.   Now in reality there would probably be a ton of different scenario’s defined and that would be additional complexity but if you could at least get companies to agree that for this scenario you would use these data fields it would open the doors to, potentially, automated set up routines.  You really should check in with his blog posts to get the full gist because it’s possible that I haven’t reported things completely accurately.  http://www.klauskorner.com/Klaus_Korner/Blog/Blog.html

 

Now I am not going to get into whether or not this would actually make things simpler or not.  Ideally, I see how it could, but then on the other hand it’s hard for me to believe that a committee, especially some sort of broad based governmental committee is going to actually come up with a solution that will be simple.  It might start out that way, with an idea, but when it comes to execution, I’m not so sure.  I mean wasn’t the whole UCCNet thing going to make things simpler.  How’s that working out for you?   Bottom line – you need to read John’s posts and decide for yourself. 

 

What I am going to comment on is the idea of simplification.  EDI brings simplicity, but not necessarily to the ones who run it.  And the question then becomes, what can we do to make the situation simpler. 

 

Reduce Data Transmitted

The first thing that needs to be done is companies need to send and receive only the data they absolutely need.  We have all seen examples of companies that send you a date or an ID number only so you can send it back to them later in the cycle.  They had it when they sent it, what happened?  Did they delete the data when they sent it to you?  No, they still have it in their system, they need to look it up.  Half of the time spent developing and maintaining EDI installations is spent finding places for, and looking up data that does not need to be traded in the first place.  If you want to conserve something, start with your data. 

 

Now this is easy to say but hard to carry out.  Why?  Because most of us deal with companies that are bigger than we are.  In fact, many times they are much bigger than we are.  And what do all big companies have in common?  They don’t want any problems and the way to do that is to send every bit of data they can think of, and then request that you send it back.  Chances of them using it are slim, but at least it’s there if they need it.   That works fine for them, they are never to blame with their management, but it means a lot of extra set up work for you.  And that is a problem that I am not sure we can do anything about, although it is certainly something you can work on with them. 

 

Certainly it is not a problem that can be handled by a committee.  It is an individual problem, one where companies need to just decide that they want to minimize the amount of data sent, and especially minimize the amount of data returned to them. 

 

Let Your ERP System Do the Thinking

 

The second major complexity for many EDI departments is the complexity of their maps.  EDI mappers have evolved to the point where they can do almost any type of logic statement required.  Editing data, setting errors, you name it.  But just because you can do something doesn’t mean you should. 

 

Handling logic in the map does allow the EDI group to function separately from the IT group but is that in the best interests of the company?  

 

When EDI groups put logic statements in a map they are setting up business rules for the company.  Now I know I can get a big argument started with this but I believe that all business rules should be in one spot, the ERP system, not split between EDI and ERP.  EDI should be a simple mapping process.  Receive this element here, and put it there in the data base.  It is up to the ERP system to then take that data and evaluate whether it meets business requirements or not.  If it does, great, off it goes to fulfill it’s destiny.  And if not, then someone needs to be notified and a transaction can be sent to the trading partner letting them know of the problem. 

 

I have done both complex EDI maps and complex RPG business rules and I can tell you that it is much easier (and safer) to set things up in RPG which was designed for such statements than it is in EDI which has been enhanced to handle those situations. 

 

 Work to Reduce Errors

 

EDI is supposed to be automatic.  It is supposed to happen without any human intervention and without anyone know that it is occurring.  But every time there is an error, every time there is something that is out of the ordinary, the process stops and someone has to step in and do something. 

 

Many times we try to prevent these errors by bringing more data in so that we can somehow work around the problem (like bringing the description and weight just in case the product number is wrong so you can look up the correct product number). 

 

An easier and more lasting solution is to chart what errors you get and work with your trading partners to reduce them.  Is the problem on your side or the partners?  Is there a simple way in which additional edit checks or logic rules on one side or the other would help.  The biggest problem is building a business case to show your partner that fixing this problem is in their best interest also. 

 

Just a few ideas, not as fancy as an EDIFACT initiative, but some things that are actually under your control and which you can implement. 

Infor Webinar – The Future of PRMS

This past Thursday Infor held a special webinar to talk about the future of PRMS.  Hosted by Infor’s very own Kari Miller, the presentation was billed as a look at PRMS and where Infor was planning to take it over the next few years.  That information did come out but the webinar was really an opportunity for Infor to unveil their overall ERP product strategy and what was said about PRMS could have just as easily be said about XA or BPCS. 

 

 

PRMS Forever

 

The first part of that strategy and the first point Kari made was that Infor was going to continue to support PRMS.  “Infor does not sunset products”, she said, and that has certainly been true with the other products Infor has purchased.  There are no exceptions to this rule, all releases of PRMS are included.  That’s just the way it is and we might as well move on.  What we can ask ourselves is, what does supporting PRMS really mean? 

 

For one thing, the help line will continue to take questions on PRMS (for those on maintenance) and develop fixes as needed. 

 

On the other hand, it does not appear that any ‘fix tapes’ will be released as in days of old, although a list of fixes will probably be available online at infor365. 

 

Similarly, even though they didn’t say so, it does not appear  that we will see anymore across the board PRMS upgrades either.  No 10.1 or 11.3.  Maybe they will surprise me, but I really doubt it.  After all, they promised 10.1 sometime last year and the word I hear is that it hasn’t been started.  

 

But, PRMS will endure.  Are you using it today?  Is it working OK?  Super, just keep on keepin’ on. 

 

 

The Strategy

 

The second part of the strategy is a bit more complex.   While Infor is not talking about across the board upgrades, they are talking about providing vertical integration (software solutions pointed at a particular industry) and application area enrichment (picking a certain application area and reengineering the dickens out of it). 

 

The current plan, as Kari explained, would start with some enhancements specifically designed for the auto industry and the procure to pay cycle.  These enhancements would be available regardless of what PRMS release you were on.  That’s right, you can use these solutions no matter what release you are on, although no matter what release you PRMS.  For those who like GUI, the new enhancements would be GUI, and for those who prefer green screen the enhancements would be only GUI.  Would you have to pay extra for these packages?  Maybe, maybe not, depends on the package and what the situation is.  Can’t get more vague than that.    

 

What’s that?  You’ve heard that one before?  CA said it?  SSA said it?  And now Infor is saying it.  And they all said the same thing; vertical focus starting with the auto industry (now that’s a spot that has some cash to throw around) and a business concentration on ‘procure to pay’ (sure, do something for finance, they control the money).  What can I say, you’re right on.  In the past lofty goals would be announced, a task force would be established and after a year or so – nothing would happen.  The task force would be dissolved and a new strategy would emerge.  Am I right, people? 

 

So, what is going to be different this time?  Perhaps nothing.  Perhaps in the fall of 2010 I will be writing a blog post about Infor’s latest strategy kickoff that involves returning everyone’s maintenance fee for the previous three years.  But for some reason, I think this one has at least a 28% chance of making it.  Keep reading for the explanation. 

 

 

What Does it Mean for You?

 

The reason this didn’t work for CA was multi-threaded. 

 

First, they were going to build most of the stuff from scratch, and that involves some upfront time and capital (plus faith). 

 

Second, it’s not that easy to design a broad based solution that still has a lot of very specific functionality.  Even within an industry it is hard to find consensus.  It’s like designing software for your family.  No matter what you do somebody is ticked off. 

 

Third, when the product was delivered, if the customer base didn’t break their legs jumping on the band wagon and producing a significant revenue kick, Charles would lose interest and the whole thing would get shelved. 

 

As a result, my natural tendency is to say ‘yeah, right, hey look, I’m holding my breath’. 

But what if you could take that enhancement and not just sell it to PRMS users, what if you could market it to everyone who owns one of your business systems?  And what if you didn’t have to build it from scratch?  What if you already had a package out there that did what you were looking for?  So what if it wasn’t written for the 400.  Run it on a server.   Now that is an idea that might produce a significant revenue stream, and I think that is the tack that Infor is going to take. 

 

 

What I Think This Means for You

 

Now what I have said so far is pretty much what Infor said in the webinar.  Except maybe they weren’t as sarcastic, but that’s my special talent.  What I say from here on out, however,  involves a certain amount of unsubstantiated conjecture, so don’t hire a lawyer if it doesn’t go down exactly as I say.

 

I think Infor is planning to use mostly existing specialty solutions, make them SOA compliant to provide vertical industry and business process specific modules that can be used with PRMS and LX and MAPICS and every other system that Infor sells including Windows and Unix systems.  And that is a whole different situation from enhancing PRMS within it’s current framework. 

 

What that means is that we are talking about modules that are probably not written in RPG.  And that may not be a problem because I wouldn’t think you would get source code with this.  I mean, what’s the point of going SOA with a common module if you let somebody modify it?  But even if you get source, I would doubt it is written in RPG (especially since Kari said that all of these modules would be GUI). 

 

I think it’s also true that these applications will not be ‘built into’ PRMS the way we think of it.  For example, I just built a custom mod for one of my very favorite clients to track vendor and customer cost/price changes and to automatically generate new quotes, contracts, and some other junk.  This package (on sale in the lobby following the show) uses a bunch of PRMS files plus a couple of new files specially created for this, but the new files are built right into the PRMS data base.  Everything is integrated.  These SOA modules, however, can’t be built into the PRMS data base.  They have to be built so they interface with any of the products it is used with.  So they either have to have their own data base, (probably SQL based) or else have an interface module that has to be specifically programmed to connect with the PRMS data base.   It might even be possible that not all of the updates to PRMS are done real time, although I think the odds on that are small.  That would be very scary to me. 

 

Given the example Kari went over, you would have the flexibility to replace all of the modules of PRMS with these specialty modules.  In one sense, this seems nice.  I mean that is the definition of flexibility.  True ‘build your own’ ERP system. 

 

But it also gives me pause.  I don’t like interfaces.  And I like multiple interfaces even less.  I mean I never give updating the Customer Master a second thought, but I would worry about updating the Customer Master if it were being done from four different pieces of software.  I know that in this brave new world of ours we are supposed to want to run ‘piece’ solutions, tying bits of code together with baling wire and duct tape and expecting everything to just happen magically.  That is an attitude that comes to us from the windows world.  But one of the strengths of the AS/400 and PRMS has always been that everything was in one bowl.  I don’t get all warm and gooey about something that instead has a bowl, a pan, a baggie, and who knows else what to keep everything in.  It was to escape that kind of tyranny that many companies went to an ERP like PRMS in the first place.  And now we are in danger of building that kind of thing right back up.  Didn’t we learn anything in 11th grade history? 

 

Bottom Line

 

So what’s the bottom line here? 

 

Well, it looks like PRMS will be around for a good long time, and if it is running your business and you think it is doing a pretty good job, congratulations. 

 

But it doesn’t look like we are going to see much in the way of enhancements for PRMS.  You might as well upgrade to 10.0 and then take a good look around to see how it looks.  Maybe you don’t want to go any further.  ERP systems are like clothes.  You need some and it’s nice to have nice clothes.  Something that’s comfortable and fits well.  That doesn’t mean that you need an Armani suit, however.  You have to know when enough is enough. 

 

What Infor is offering is in line with where a lot of the pendants say we are going, and it is certainly in line with the view from the Windows world.  Get a bunch of boxes, tie them together, and pretty soon you have a wall.  But is that a better strategy than the one espoused for the last thirty years; the fully integrated MRP II model?  

Your ERP system is what you make it based on how you implement and how you police it.  And, without really meaning to, Infor is providing a chance to go either way here.  The choice is up to you. 

Â