"Bill Van Looy's discussion of fixing a bug related problem (below) got me thinking. Like Bill perhaps, my first experience with non-monolithic, highly reusable, sub-procedure and sub-routine (could it have been object oriented?) designed commercial applications was when working with the IBM MAPICS, CMAS and DMAS applications in the mid 1970s. From time to time IBM would release a ""PTF"" (program temporary fix), a ""patch"" to those of you not familiar with IBM jargon. On occasion the fix would create more problems than it solved due to the fact that a customer could ""tailor"" their installation in thousands of different ways by setting options. For example, it was possible that the problem Bill discussed did not exist unless you had selected the Last Cost option for inventory. The options set up which sub-programs would execute, and which parameters were fed to them from the calling program. The good news was that all of the code was in one machine at one site. Debugging errors was laborious, but at least you had access to all of the code. My question is this... What happens when, as some have suggested, the ERP is replaced by thousands of SOA pieces being provided by thousands of third parties world-wide? I can imagine my request for ""A"" being submitted to provider ""1"", who submits some part to the request to sub-provider ""2"", who submits some part to.. Well I think you get the picture. What a wondrous web we weave. Steve Murray > From: Bill Van Looy via erp-select
> Reply-To:
> Date: Mon, 10 Sep 2007 01:03:32 -0400 > To: phil Robinson
> Subject: RE: [erp-select] Tier's (was Re: Infor Syteline) > > > > MAPICS -- Don't really know. The version that I used 20 years ago I > would have considered to be more like Tier II, but I know that it has all been > totally rewritten. I think at one time after the old PICS system it was > the most widely use ERP package in the market. The linked nested RPGII code > it was written in at the time was a programmers nightmare. -- Also one of > my fondest memories of a software bug - it posted a $1,000,000 debit entry > with no offsetting credit. Only way I could clear the books for month end > close was to write a program to put in a one-sided $1,000,000 credit -- was a > lot of fun documenting that one for the auditors. > > > Regards > > Bill Van Looy > 678-358-4906 cell > 770-645-5463 home office > > > -----Original Message----- > From: phil Robinson via erp-select > [mailto:erp-select@Groups.ITtoolbox.com] > Sent: Friday, September 07, 2007 10:02 AM > To: Bill Van Looy > Subject: Re: [erp-select] Tier's (was Re: Infor Syteline) > > > > Bill, > > 1) Seems like I have got agreement on the tiers +/- a tier which is as > muc > h > as you could hope for on this forum! Maybe I should make some > modification > s > to my table. > > From your comment I guess you would put MAPICS in Tier 3? > Also what about SAP B1 in Tier4? > I don't have much experience of MS Dynamics packages. AX in Tier 2, GP > in > 3 and NAV in 4 seems to be where MS would like to position themselves at > least. Not sure if users would agree. > > 2) I don't work for O. Wight so don't have access to their class ""A"" > lists > to know the software used. My latest copy of their ABCD checklist is > the > Fourth Edition but no mention of positive ROI. It is all about process > not > results! > > Phil > BPIC.co.uk > > >> From: Bill Van Looy via erp-select
>> Reply-To:
>> Date: Tue, 4 Sep 2007 00:24:36 -0400 >> To: phil Robinson
>> Subject: RE: [erp-select] Tier's (was Re: Infor Syteline) >> >> >> >> Phil, >> 1. Weird to see MAPICS in the Tier III bucket. >> >> 2. Given your definition for inclusion have you found any SAP or > Oracle >> implementations that have actually gotten O.Wight Class C > certification. >> Actually this is a bit of tongue in cheek, but with your O. Wight UK >> connections do you know of any that have been certified as Class A - >> that >> would imply a positive ROI on the implementation? >> >> Bill Van Looy >> 678-358-4906 cell >> 770-645-5463 home office >> >> >> -----Original Message----- >> From: phil Robinson via erp-select >> [mailto:erp-select@Groups.ITtoolbox.com] >> Sent: Monday, September 03, 2007 4:30 AM >> To: Bill Van Looy >> Subject: Re: [erp-select] Tier's (was Re: Infor Syteline) >> >> >> >> It is easy to make something simple look complex but the real > challenge >> is >> to make something complex look simple. >> >> For me the value of dividing ERP software into Tiers is to help > software >> users with their choice of software. Often this means stopping smaller >> companies wasting their time evaluating Tier 1 products and larger >> companie >> s >> trying to use Tier 3 & 4 products. A frequent occurrence as regulars > to >> this forum know all too well. >> >> I unashamedly plagiarise this forum, picking off the gems and >> summarizing >> them in as simple a form as possible on my web site. I have done my >> best >> for Tiers at http://www.bpic.co.uk/erp_software_tiers.htm . I would > be >> interested in any comments, corrections or additions from confused > users >> an >> d >> seasoned professionals alike. >> >> I guess this post is inviting a Tsunami of salesmen to ask why their >> produc >> t >> is not included. My UK list is based on packages implemented to a > class >> ³C >> ² >> level or better, the ³Other² is packages with a significant > presence >> in the >> UK so I need to hear from UK users and/or consultants to include >> packages. >> >> Phil >> (UK based Ollie Wight trained class A user and now consultant) >> >> >> >> >>> From: BAustin via erp-select
>>> Reply-To:
>>> Date: Fri, 31 Aug 2007 13:24:37 -0600 >>> To: phil Robinson
>>> Conversation: [erp-select] Tier's (was Re: Infor Syteline) >>> Subject: RE: [erp-select] Tier's (was Re: Infor Syteline) >>> >>> >>> >>> Geoff, >>> >>> Tiers, in my opinion, were created by software companies sales people >>> for competitive purposes. i.e. If you were an SAP salesperson back in >>> the day when Oracle was just an up and comer in the applications >> space, >>> it would be easy positioning for this salesperson to say SAP is Tier > I >>> and Oracle is Tier II. The delineation on how this could be true > could >>> be anything (more functionality, more existing customers of similar >>> size, industry, etc.), but, MOST importantly, a higher ""prestige"" is >>> suggested. >>> >>> Unfortunately, this will always be subject to interpretation. From my >>> experience, the Tiers have to do with 1) revenue size of the company >>> buying ERP, but it also has to do with the very definition of what > ERP >>> is, or 2) what is the completeness of functional areas it covers for > a >>> particular companies needs. i.e. Does ERP have to have integrated >>> Financials to be classified as ERP? Does not having integrated >>> Financials drop a vendor to a Tier 4 status? What about a s/w package >>> having or not having MRP? Etc. >>> >>> I would be interested to find out how others in this forum define, 1) >>> ERP and 2) how it directly relates to how a certain Tier is >> determined. >>> >>> I think the grey area, in terms of Tiers, is in the small to > small/mid >>> market (the definition of small to mid market is also up to >>> interpretation BTW). Revenue size is typically broken down by > software >>> companies as follows: >>> >>> Small $0 - $50 mil. >>> Small/mid - $51 - $100 mil. >>> Mid - $100 - $250 mil. >>> Mid/Large - $250 - $500 mil. >>> Large - $500 - $2 Bil. >>> Fortune 500 (or, maybe even fortune 1000) - $2 Bil. + >>> >>> Additionally, this is how many software companies breakdown their >> sales >>> forces and/or products that serve these respective markets. >>> >>> Brett >>> >>> -----Original Message----- >>> From: Geoff Crawford via erp-select >>> [mailto:erp-select@Groups.ITtoolbox.com] >>> Sent: Friday, August 31, 2007 8:38 AM >>> To: Brett Austin >>> Subject: [erp-select] Tier's (was Re: Infor Syteline) >>> >>> >>> >>> At 09:09 AM 8/31/2007, ghsmith via erp-select wrote: >>> >>>> Andy, >>>> >>>> Please tell me where to go to get definitions of Tier 1,2,3,&4 ERP >>>> systems or define please. From your comment below, the tiers appear >>>> to be based on company revenue or turnover. Is this a formal or >>>> accepted standard or salesspeak? Everyone throws around the term. >>> >>> I changed the subject because we're off on a tangent. >>> But it's a good tangent - we do throw those terms >>> around quite a bit. >>> >>> The short answer is no, there is no standard for what >>> Tiers are. All the vendors I'm sure want to think >>> of themselves as higer Tier means better and that's not >>> always really true. >>> >>> It's completely arbitrary what people mean, but you'll >>> find two general defitions. Probably a bit more common >>> is refering to packages simply by how big the package >>> is - either in sales revenue, or the size of the maker >>> of the package. To me that's not very useful, it tells >>> you about the maker of the package, but not much about >>> what the package itself does - infor is a good example >>> because they've got packages targeted at some relatively >>> small companies and yet are a $ 1.5 billion company. >>> >>> So I personally use a different methodology - I base >>> my tiers on what size company the package is targeted >>> for. Packages out to capture the Fortune/Global 500 >>> are ""Tier 1"". Packages that are mid market are >>> ""Tier 2"", very verticalized packages in niche markets >>> are ""Tier 3"", and the smallest are ""Tier 4"". >>> >>> >>> Geoff Crawford >>> geoff@innov8cs.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> >> > > > > > > > > > //*-------- INTERESTED IN THIS MESSAGE? RELATED CONTENT -------- J2EE - SOA Manager/Senior Manager http://www.ittoolbox.com/ext/46243 Process-Driven BI: Building Smarter Business Processes (White Paper) http://www.ittoolbox.com/da/521418 -------------------------------------------------------------*// "

>My question is this... What happens when, as some have suggested, the
>ERP
>is replaced by thousands of SOA pieces being provided by thousands of
>third
>parties world-wide? I can imagine my request for ""A"" being submitted to
>provider ""1"", who submits some part to the request to sub-provider ""2"",
>who
>submits some part to.. Well I think you get the picture.

Leaving the ""thousands of pieces"" aside for a second (I can't see
it being that level), and certainly leaving aside the question
of if this is even on topic for a ""selection"" list .....

What happens today when you go to a supplier for a whole replacement
engine? They make a call out to the piston maker, and the valve vendor,
etc. And the valve vendor makes a call to the gasket company, and
the hardware guy for screws and bolts, etc. etc. Not really much
different than what happens today outside of the systems area.

Architecture has a lot to do with selection. If not, we could still be
using monolithic code and green screens. Does it really matter if my ERP is
integrated with or interfaces well with MS Office apps???

When I take my car to the shop at least all of the engine is in one place,
at one time, ready to be diagnosed. The mechanic does not have to go out to
the individual parts suppliers to work a solution.

I totally understand that the manufacturer (developer) may outsource or use
components (software widgets) manufactured (written) by others. However
when I do the troubleshooting required because all of a sudden my debits and
credits don't balance, I like to be able to lay everything out in one place.

Don't get the impression that I am against SaaS or SOA. I think these
things are the way of the future, at least for optional components. I would
prefer to submit an address to a verification engine that someone else is
responsible for, and get a validation as opposed to writing my own engine or
purchasing one and installing it on a local system.

However, there is a lot of potential for finger pointing and other ancillary
issues when dealing with a group of partners. The risks here need to be
fully understood and overcome least you become a Mattel trying to figure out
where lead got into the toy paint.

>My question is this... What happens when, as some have suggested, the
>ERP
>is replaced by thousands of SOA pieces being provided by thousands of
>third
>parties world-wide? I can imagine my request for ""A"" being submitted to
>provider ""1"", who submits some part to the request to sub-provider ""2"",
>who
>submits some part to.. Well I think you get the picture.

Leaving the ""thousands of pieces"" aside for a second (I can't see
it being that level), and certainly leaving aside the question
of if this is even on topic for a ""selection"" list .....

What happens today when you go to a supplier for a whole replacement
engine? They make a call out to the piston maker, and the valve vendor,
etc. And the valve vendor makes a call to the gasket company, and
the hardware guy for screws and bolts, etc. etc. Not really much
different than what happens today outside of the systems area.

I think we've been down this road before. We'll have to
agree to disagree.

>Architecture has a lot to do with selection. If not, we could still be
>using monolithic code and green screens. Does it really matter if my ERP is
>integrated with or interfaces well with MS Office apps???

Green screens are not architecture - that's a matter of the user
interface. And while some may turn their nose up at it, there
are industries and packages where green screens are still being
purchased because they're actually preferred for heads down
data entry. Not that many of those systems don't also have
very nice graphical interfaces as well, but green screens
are by no means dead.

My point from the last time around is that no one goes out
and selects because of the architecture itself. If they
are, they're lying because architecture itself doesn't do
*anything*. It's the same as realizing people don't buy
software, they by solutions to their problems that happen
to be software based. People look for ""my inventory
must be accurate"" not ""I need integration platforms"".
Inventory accuracy might well be aided by having systems
with SOA capabilities but that's not the reason they would
buy. Someone would buy equally as well if a non-SOA system
could keep the accuracy just as high with a different
method.

>When I take my car to the shop at least all of the engine is in one place,
>at one time, ready to be diagnosed. The mechanic does not have to go out to
>the individual parts suppliers to work a solution.

Ever done ERP's for after market auto parts business?? All is not
what it seems. That mechanic may go to one mass distributor,
but even that distributor's line of parts is OEM'd by massive
numbers of manufacturers. Sure, there might be one initial
call because having only one place to call is literally what
value that distributor provides. And in today's JIT environment
it doesn't even work that way - as much as they want to buy
from one place, the number of parts actually in stock is
practically nothing unless they're the every day wear and
tear item. But from there those items are just not kept
on hand - just try calling up and asking for a crank shaft
or a piston ring. Even the dealers and their JIT stock don't
have those on hand - they come from a national distribution
center, and even there they are at such levels they
spill over to nothing on hand all too often and you're end
up waiting for those big ticket items direct from the OEM.
(and if you haven't been in the auto biz you may not know
it typically takes several hundred manufacturers for everything
in a car by the time the outsourced to the outsourced to
the outsourced set of vendors is added up) It's an absolutely
perfect example of *exactly* what I said happens.

>However, there is a lot of potential for finger pointing and other ancillary
>issues when dealing with a group of partners. The risks here need to be
>fully understood and overcome least you become a Mattel trying to figure out
>where lead got into the toy paint.

I can agree on that - but that's a business matter, not a software
issue.

Disagreement is not a bad thing, it can generate insightful comment useful
to the forum.

Green screens (the user interface) are definitely part of an architecture,
just as are the hardware, operating system, network infrastructure and
database. While I violently agree that they are more efficient for high
volume transaction entry than the typical 'point and click' GUI, I don't see
anyone developing systems from scratch using the approach. They exist only
as a carryover from a previous computing environment (architecture) which
did not support a GUI.

Yes, ERP buyers should focus on the solution, not the pretty box it comes
in. However I would hate to be the guy out selling a high function
character based application today. If I showed a prospect a 1980's style
menu screen instead of the same functions on a GUI menu I would be drawn and
quartered. So much for people not buying based on architecture.

My point regarding the auto repair (and SOA) was focused on the diagnosis,
not the supply chain. The service parts and repair business is tough, and
yes I have worked in that environment. I am a supply chain guy you know.
The auto industry is mild compared to the utilities industry where customers
expect their electrical power restored within hours of a heavy snow storm,
or the commercial aircraft industry where planes can fall from the sky when
not properly maintained.

As a servicing dealer, I would ideally like to have any part available, not
in my inventory but from a supplier, at the snap of my fingers. But this is
not always possible and I must also provide reasonable customer service. My
customer will not wait 4 weeks for his Audi oil filter to come from Germany,
he expects to get his car back from the oil change this afternoon. I may be
able to convince him that the piston ring is special order, but if it take 4
weeks to get it the customer will soon be ordering his new BMW (or Lexus).

But that is all post diagnosis. The mechanic broke down the engine and had
everything he needed right in front of him in order to determine that a new
ring was needed. Procuring the part is not his job, and the car is pushed
into the lot until the part arrives. The mechanic goes on to diagnose the
next problem. The Service Advisor has to deal with the unhappy customer.

The key here being the ability to have everything 'in front of him' so that
he could perform the diagnosis.

I see problem diagnosis and resolution as the Achilles heel of SOA, and look
forward to seeing how it is addressed.

I think we've been down this road before. We'll have to
agree to disagree.

>Architecture has a lot to do with selection. If not, we could still be
>using monolithic code and green screens. Does it really matter if my ERP
is
>integrated with or interfaces well with MS Office apps???

Green screens are not architecture - that's a matter of the user
interface. And while some may turn their nose up at it, there
are industries and packages where green screens are still being
purchased because they're actually preferred for heads down
data entry. Not that many of those systems don't also have
very nice graphical interfaces as well, but green screens
are by no means dead.

My point from the last time around is that no one goes out
and selects because of the architecture itself. If they
are, they're lying because architecture itself doesn't do
*anything*. It's the same as realizing people don't buy
software, they by solutions to their problems that happen
to be software based. People look for ""my inventory
must be accurate"" not ""I need integration platforms"".
Inventory accuracy might well be aided by having systems
with SOA capabilities but that's not the reason they would
buy. Someone would buy equally as well if a non-SOA system
could keep the accuracy just as high with a different
method.

>When I take my car to the shop at least all of the engine is in one place,
>at one time, ready to be diagnosed. The mechanic does not have to go out
to
>the individual parts suppliers to work a solution.

Ever done ERP's for after market auto parts business?? All is not
what it seems. That mechanic may go to one mass distributor,
but even that distributor's line of parts is OEM'd by massive
numbers of manufacturers. Sure, there might be one initial
call because having only one place to call is literally what
value that distributor provides. And in today's JIT environment
it doesn't even work that way - as much as they want to buy
from one place, the number of parts actually in stock is
practically nothing unless they're the every day wear and
tear item. But from there those items are just not kept
on hand - just try calling up and asking for a crank shaft
or a piston ring. Even the dealers and their JIT stock don't
have those on hand - they come from a national distribution
center, and even there they are at such levels they
spill over to nothing on hand all too often and you're end
up waiting for those big ticket items direct from the OEM.
(and if you haven't been in the auto biz you may not know
it typically takes several hundred manufacturers for everything
in a car by the time the outsourced to the outsourced to
the outsourced set of vendors is added up) It's an absolutely
perfect example of *exactly* what I said happens.

>However, there is a lot of potential for finger pointing and other
ancillary
>issues when dealing with a group of partners. The risks here need to be
>fully understood and overcome least you become a Mattel trying to figure
out
>where lead got into the toy paint.

I can agree on that - but that's a business matter, not a software
issue.