Evaluating new ERP

[comatt1]

We are currently in the process of either building a new in-house, custom ERP package (since the mods we have done with SX.e makes it inrecognizable). We are into worldwide distribution with about 150 million in sales and deal mostly with distribution/warehousing. If we purchase a different ERP package, I have no intention of being on board to go non-Progress with the new ERP package (however, it isnt my choice).

Do any other ERP packages which have features similar to SX.e manage to work well within warehouse environments. I have used QAD, but that had much better features for manufacturing and managing configured products, etc.

We are more than capable of customizing to our needs, but is anyone work within a warehousing environment that can effectively manage inventory/shipping/sales using a Progress based ERP?

PLEASE TELL ME THERE IS.

 

[tamhas]

There are both ABL ERP packages with strong warehousing and standalone ABL warehouse solutions. Whether any of them cover your needs is a wild guess since we don't know what your needs are.

 

[comatt1]

I should have probably posted for anyone who had actually made the move from SX.e to another database, what did they move to. With the issues most people I have talked to, I imagine many have.

 

[comatt1]

There are both ABL ERP packages with strong warehousing and standalone ABL warehouse solutions. Whether any of them cover your needs is a wild guess since we don't know what your needs are.

Here the requirements

 

[tamhas]

With all due respect, that level of requirements specification is close to meaningless. Get 100 pages of descriptive narrative, examples, use cases, tables, etc. and you would be a little closer to being able to tell one from the other.

Note that it is perfectly reasonable to construct such an RFP and get the prospective vendors to respond to what they do, what they don't do, how they can modify, or what alternatives they can propose. I.e., you don't need to fill out the form yourself.

 

[rhi]

The fact is, there are only a few Progress based ERP solutions. Why in the world would you not be in support of the right ERP solution for your business, regardless of the technology?

For example, Oracle has a Warehouse Management solution - http://www.oracle.com/applications/order_mgmt/warehouse.html.

I know people in this forum don't like to hear the 'O' word, but believe me, having been involved in both the Oracle & Progress worlds, the technology under Oracle is more mature and feature rich and if integration is a key, you can't do much better.

 

[tamhas]

One of the *really* big reasons to prefer a Progress based ERP system with source is that it is so much easier and more economical to modify it. It is rare for an ERP system to provide a high level of "fit" because distribution and manufacturing companies are so diverse in their products, vertical markets, supply environments, and distribution channels. The ability to evolve the package to meet those specialized needs is priceless.

 

[rhi]

True, all ERP systems need customizations and developers to do it. I have seen it with all systems I have worked with (QAD, Oracle, PeopleSoft), but I don't know if I agree about it being more economical. One shop where I worked had both QAD and PeopleSoft. There were 6-10 QAD/Progess developers and only 2 PeopleSoft devlopers. The reason seemed to be that because QAD lacks features that a more feature rich Oracle or PeopleSoft system has, it required more customizations to bring it up to speed. And integrating QAD to other systems required more work, and also required us to pay for and train Filenet consultants in Progress 4gl/SQL, whereas they already knew Oracle SQL.

Even out of the box costs are no longer an excuse to only look at Progress based solutions. While Progress license costs have sky-rocketed lately, Oracle's solutions offer smaller versions of their application suites for small and mid-size companies. The only real "savings" in Progress might be if you already own the licenses and even that may not be true if you are switching to another Progress based ERP. I don't know how Progress for SX.e is licensed, but if you buy Progress from QAD, you can only use it with QAD, so if you want to make the switch to another Progress based ERP - you gotta buy new Progress licenses.

Having said all of that, I still maintain that if the only thing you look for in an ERP is the technology it is running on, than you are no good to your company.

 

[tamhas]

I'm the last person to be suggesting that one should look at technology first. Indeed for certain verticals, there may be a horrid mismatch between requirements and capabilities for any of the major technologies and the best possible fit might even be something in Pick or Theos. Of course, that comes with a price too.

But, if your opinion is based on this one particular experience, it might be good to look a bit broader afield. QAD has certainly sold a lot of software over the years, but it is hardly the package I would point to as illustrating the benefits of ABL. Was this shop really running both QAD and Peoplesoft to do the same thing? Seems bizarre. But, even if the case, this could easily be a case where the fit of one was better than the other, but this isn't to say that there were other packages with better fit. If I pick package A in technology X with a 70% and package B in technology Y with a 90% fit, then of course I am going to have to do a lot more work on A, regardless of the virtues of the technology. But, add in package C in technology X with a 90% fit and then one can actually compare the cost of ownership of X versus Y. Progress blows everyone out of the water there.

Interesting concept you have that Progress license costs have gone up since actually they have gone down. I'm an AP and have all the price lists for years. I suspect there is a bit of apples and oranges comparison going on there. Even so, looking at initial license costs for the technology is just the tip of the iceberg. Add in the cost of managing the system and the cost of modifying it over the years and you get a more true cost of ownership. And, like I say, Progress blows others out of the water there.

Obviously, requirements and fit are the first criteria, but most often that still leaves a lot of options in the hunt. When that is the case, understanding the impacts of choosing one technology over another is important. Just like choosing the right vendor is important.

 

[rhi]

When you said "One of the *really* big reasons to prefer a Progress based ERP system" it sounded like you were for evaluating the technology as the main thing. I would say it should be considered, but only after the fact and mostly due to integration. My experience is their costs have gone up. you must be getting a better deal, obviously.

No, QAD & Peoplesoft were not doing the same thing - I never said it was. Just that having 2 ERP systems with simlar numbers of modules, similar size databases, but watched the struggles that existed and cost associated with upgrades. This was just an example, as it is hard to list the numbers of things over 15 years of experience has formed my opinions.

I think it sounds like we agree, much needs to be evaluated. But this thread was opened with comatt1 asking if other Progress based ERP exists, and I am saying, based on my experience, it is worth looking at other technologies. The major companies have realized the SMB market is worth a lot of money to them, so they have realized that and are now offering cost competitive products.

I think your statement of cost of ownershp and Progress "blowing everyone out of the water" is silly. I have seen cost of ownership go through the roof just simply due to poor management of projects.
I know the Progress religious types like to use cost to scare people into staying with Progress rather than evaluating other technologies, but the truth is that today it is just a lie. They no longer are the cheapest solution.

 

[tamhas]

My experience is their costs have gone up. you must be getting a better deal, obviously.

My "deal" is percent discount off of list, so it isn't my deal that is better. Moreover, a significant number of PSC APs these days, particularly the big ones, are on a percent of application agreement where their cost for PSC licenses is simply a percentage of what they sell their application for, not a price fixed by PSC in advance.

No, QAD & Peoplesoft were not doing the same thing

Which makes them hard to compare, no? If QAD was doing the manufacturing and Peoplesoft the financials, then it is often the case that financials need very little mods and the manufacturing needs a lot. Hardly apples to apples.

For an existing ABL shop, one of the costs which might enter in is retraining of employees should they choose something else. I may also be that they have substantial investment in custom mini-apps written in ABL.

I wouldn't suggest that was the best way to go about things, necessarily, but it is a lot more understandable than the zillions of RFPs I have seen that specify Oracle or SQL Server because it is the "corporate standard". And, of course, a lot of that has to do with retraining, custom apps, and pre-existing knowledge.

To be sure, you can do anything badly, but are you familiar with the Gartner study on cost of ownership?

They no longer are the cheapest solution.

Sure, you can always do something in Access....

 

[wsong]

Up to now, I havn't seen any ERP software is particularly strong and easy enough in distribution and warehouse mgmt by the user criteria. (SAP, Oracle, QAD, Axapta). Most of the unused functions and modules will be a nuisance if you go for ERP packages and use its distribution and warehousing function because they are tangling with the functions you are actully using. Any attempts to get them to current business practice could be very expensive (e.g External Web interface, GPS tracking, barcoding, wireless, RF Tag etc)

The only reason I would think of to select ERP package maybe because most ERP package has financial management integrated.

I would suggest you look at the best-of-breed on the market which are specifically targeted to this market

Development can also be an option, provided you can find the development house with the developers with good knowledge of the industry and you as customer is very clear about what you want.

Good luck

 

[rhi]

Tamhas, just curious, outside of Progress or Progress based ERP, what is your skill set and experience (either technical or functional)?

 

[tamhas]

Well, since you asked ... I have been doing professional development since 1966 and I stopped counting at 50 languages, which was quite a few years ago. I have 28 years experience in distribution applications and 33 years in financial applications, but also have a variety of experience in scientific applications, data-oriented, mathematical, and analytical. I created my own 4GL prior to discovering Progress and, just in case you think I got fossilized at that point, I made a rather conspicuous move to Forté and their OO4GL in the mid-90s, but I am back with Progress. Further details available at http://www.cintegrity.com/company.html

 

[rhi]

Getting back to your comment about "apples to apples", I don't think one QAD shop vs another can have a true apples to apples comparison. But, I can draw a comparison between QAD, Oracle & PeopleSoft ERP apps because I have much experience in all 3, and conclude that since cost is no longer an excuse - no reasonable person should limit their choices of ERP apps to Progress based only.

I asked about your experience to see if you were defending away from anything but Progess because of what you know, or don't know. I conclude from your web site, that you have no experience with Oracle or PeopleSoft ERP, so your defense against those products in favor of Progress is baseless.

I can understand the reason for your position though, because Progress is obviously how you make your living.

I see you listed on your "accomplishments", in 1997 that you successfully defened against replacement of Integrity/Solutions by Oracle and PeopleSoft.

I commend you for your sales efforts, but I'll bet that customer is kicking themselves for buying your vapor-ware, now that you've pulled it from the market. (The MAJOR reason not to go with small vendors for ERP):lol:

I also see you did a Siebel implementation in 2004. This is a good career move. Much, Much more work available in the Oracle Apps arena.

 

[tamhas]

You seem to be moving in the direction of ad hominem attacks, which will bring the conversation to a shrieking halt, if you continue.

Among other things, you seem to have forgotten that I agree with you that, as a general rule, deciding what you need and seeing who has it, without regard to technology, is the best strategy. I've run into enough places that had decided on Oracle, even though I had a better solution to have good personal reasons for that, but I also have a number of years in which I was doing vendor-independent computer systems acquisition consulting before I found that I could actually provide a better service for my customers by taking ownership of the package ... they were the ones who talked me into it.

Not all experience shows in the resume, of course. Nor is being a worker bee doing an implementation the only way to gain experience and knowledge.

And, no, that customer didn't kick themselves ... in fact, they were extremely happy to have saved a couple of million dollars in customization that would have been required to merely equal the capabilities of my software had they switched. Happy enough to run around publishing conventions bragging about having the best royalty contracts package that anyone had ever seen. They would be busy working together with me today had they not been acquired by Wiley.

And no, Siebel was not a career move. What I am doing these days is helping companies with legacy ABL applications to modernize, pioneering the automated generation of UML from ABL code. I will be speaking about this at the next Exchange, if you would like to learn about it.

While I agree with the general principle, all I am trying to do is to balance your extreme "you must do it my way or you're an idiot" position with the recognition that a shop which has an established investment and expertise in Progress applications and which may, in fact, have some important business "mini-apps" in ABL that they would like to keep, is not being totally unreasonable about preferring a Progress application.

If they are starting out a a COBOL shop, desperately needing to modernize, then certainly they should be looking at a variety of technologies and packages to see who has the best fit. But, even then, it shouldn't be merely a question of best fit out of the box because they should also be considering the cost to move the application from what comes out of the box to a more acceptable level of fit and the cost over multiple years of evolution of the software to changing business conditions. This is what sold that customer back in 1990, BTW ... it was having a prior vendor where the cost of mods was so high that they just couldn't afford to do most of them. With me, they could do mods all day long because there was a clear ROI in relationship to the modest expense. As a consequence, we took them from a $5M company to a $50M company without adding a single person in the office operations staff. Now, that's ROI.

 

[wsong]

Hi, Tomhas

I want to listen to your opinion on "Doing the logic in Progress, Front end in .Net". What is the advantage of this type of model over the other competitive solutions.

I saw Vantage is doing that, QAD is also going this direction.

Thanks & Best Regards

Willy Song

 

[joey.jeremiah]

Hello Willy,

i'm also for doing the business logic side in progress but the ui side in another.

mostly because i'm also for ria, web 2.0 ui's not on any fat client.


i've started my own company recently, hired workers, office space the whole deal.

mostly progress but some other things, some crm, bi and reporting etc. and i'm kind of swamped right now


but there are several projects i have and i want to post, a query optimizer, misc libraries etc.

and possibly write and put together code about architectures.


i've got some experience on flex, but the latest silverlight release also looks very promising.

i would definitely do the ui part on one of them.

 

[tamhas]

I've never been a big fan of doing UI in ABL ... at least for anything other than ChUI. The main point, of course, is that UI should be separate, so that the rest of the application doesn't care what it is written in. Personally, I am most interested in WUI using something like Ajax rather than any heavy client solution, regardless of technology. I suspect that a lot of the .NET enthusiasm is more of a question of getting on the bandwagon rather than any intrinsic virtue, but in any case I wouldn't do a new ABL GUI client in the modern era.