RE: ALF Expense Analysis

Many of you are well informed about the ALF and related issues;
unfortunately, there are many more who do not understand the issues related
to ALF.  This will be my two cents worth to clarify (if I can be so bold.)

 

1.      XA ALF prices are very uniform.  Of the approx. 250 or so world wide
MAPICS accounts that I have worked with, the ALF is very consistent at
approximately 16% of ILF.  I can name the 3 exceptions (but won't to protect
the innocent) but they all relate the size of the account.  2 of the
accounts were new ILF customers and paid 5 years ALF upfront.  The one other
customer renegotiated based upon an enterprise agreement that expanded their
sites from 2 to 42, and again paid 5 years ALF.  

While I would not categorically state with 100% certainty, I'm comfortable
enough to put it out there.

 

 

2.      XA ALF is not only 65-74% of MAPICS revenue, it is more like 85-90%
of MAPICS XA only revenue.  In other words, the product mix of non-XA lines
reveals just how much revenue comes from existing XA customers relative to
the non-XA product lines.  It is important to understand there is a very big
difference between what ALF funds and what benefits derive to a customer
that pays ALF.  MAPICS funds ALL operations out of ALF revenue.  

But that is irrelevant to customers who need to be focused on the benefits
of ALF.

a.      First, Support.  I currently work with customers that run MAPICS XA,
JDE (world, one-world, XE, 5, etc. etc.), JBA, PeopleSoft, Oracle, SAP,
Intentia, etc.etc.  MAPICS support is second to none.  That is not just my
personal opinion, but surveys support it as well.  An anecdotal story, I
currently work with a customer that pays Oracle $1.2 million per year in ALF
(yes its more than just maintenance) and had to pay another $1 million in
consultants, training and employee time over 6 months to migrate from 11i
(11.2)  to 11i (11.5)!  Now that's crazy!  But my customer feels it was
justified by performing a true ROI analysis. (and they were right)
b.      Second, PTF support.  While it could be vastly improved, when it is
compared to other ERP vendors, the quality, deliver methods and timeliness
of the code is very good.     While on this point, the only people that need
to track the weekly list of PTF's should be new accounts that are not live
yet.  Once you have live stable code, the only reason to look for a PTF is
if you run into a code break in your existing system.  (Or a criticla PTF
for PayRoll because of a new government requirement)  As a general rule,
based on the history of XA R1 - R6, 6 months after General Availability you
can feel comfortable putting a new release into a test environment.  The
customers who work the code issues on new releases are a) new customers b)
existing customers with a dedicated testing staff, c) idiots who don't test
code and just apply it to their live environment and then call the hotline
when it doesn't work.
c.      Third, upgrade support.  It is amazing to me that a customer that
purchased MAPICS I on a system 36 can STILL upgrade to MAPICS XA 7.  I admit
it may take a long time and go through some convoluted twists, but. name one
other vendor that can claim that 16bit S36, 32bit S38 (and some S34) and
some 48bit (early XA) can maintain data integrity into the world of 64bit
computing. (Which by the way MAPICS has been doing since R3!)

3.      XA ALF is based on XA ILF, just because you didn't buy any new
modules this year, does not change the fact that ILF prices went up and
therefore ALF does too.  
4.      XA ILF prices are based upon marketing whimsy and pixie dust.  (As
are all prices.)  There are many variables in developing pricing for ILF.

a.      Competitive Features:  When compared to the tier one vendors (SAP,
Peoplesoft, Oracle, JDE) MAPICS feature function holds up very well. (I know
you won't believe it, but it's very true and independently evaluated many
times a year.)  There is always room for improvement, after all it is
software, but the improvement is driven mostly by marketing forces.  (A
squeaky wheel gets the grease.)
b.      MAPICS Concurrent licensing or Registered licensing (Note I said
"MAPICS concurrent" not "concurrent", they are not the same thing.)
c.      What new modules will drive upgrades to MAPICS and/or new customer
license revenue?  A cynical view would say MAPICS manipulates its customers
by creating new modules with ALF money and then charging customers for the
new module.  A more appropriate view would be to understand the benefits of
the new application.  There is not one of the new client applications (EPDM,
MM, CSM, OBPD, and PM) that cannot justify their expense vs. continuing to
use the old apps. (PDM, IM, PCC, REP, COM, PUR, etc.)  If you'd like to
argue this point, please send me your internal ROI analysis to
(kdfox@xxxxxxxxxxxxx) because I've never seen then not cost justified.
d.      What new module combinations will generate new upgrades to MAPICS
and/or new customer license revenue?  Thus the tremendous success of "MAPICS
Essentials" or the failures of "MAPICS Foundation".
e.      .. the bottom line, is ILF pricing does not following a straight
line % increase each year and that causes the ALF to follow along.  For
example, how did the ILF increase on average 14% in 2001 when NOBODY was
buying software?

5.      XA ALF is very comparable to their direct competition.  Note I said
direct competition, not non-competition.  I've seen idiots compare MAPICS XA
to Great Plains.  Sorry guys (and gals) Great Plains has its good features
but can't hold a candle to the depth and breath of MAPICS XA feature
function.  Currently I have a customer attempting to compare MAPICS XA to
Soloman.  I'm not saying that those applications won't work for you, but
that means your company no long fits the "mid-range" market definitions and
you SHOULD be looking at them and NOT MAPICS.

 

That having been said, most of the above (excluding the new client apps) are
very difficult to put a value on.  And as a result, it's very difficult to
justify.  Difficult, but not impossible.

 

The best way to develop an ROI is to determine the costs of the
alternatives.  For example, if you did not have support what would it cost
you?  Analyze the number of fixes you required during the past 5 years. (To
project averages for the next 5 years)  Determine, the cost of developing
the fix yourself AND the cost of your business operating without the fix
during that time.  (Not fair to assume you knew the problem was coming, now
is it?!)

 

Next, for upgrades (i.e. R6 to R7 ..oops bad example) identify the benefits
of the changes to your organization. Don't forget to include
training/consulting costs to take advantage of the new features or worse,
any additional programming costs because you created a programmer's annuity
three years ago.  Conversely, if the new feature eliminates custom code,
don't forget to include the 5 year benefits of eliminating that same annuity
(i.e. changing the code bi-annually to permit upgrading to the new release).
I'd be interested to know how many of you are taking advantage of the new
Purchasing/Manufacturing to Outside Process interfaces that are a "free"
part of R6?  This feature alone can justify upgrading to R6 and its part of
"Green Screen" MAPICS.

You also MUST look at the alternatives of a different vendor.  MAPICS
customers are always shocked when they look at the cost of competitive
products.  (Remember we are talking about Tier 2 to Tier 1 vendors).  You
are not held hostage by MAPICS, you do have market alternatives.  If it cost
justifies moving to a different solution, then you should do it!  If you
can't justify another solution, then by definition you've just justified
MAPICS as YOUR solution.  As one of my friends used to say, kind a'neat,
huh!

 

Finally, all IT expenses should be annually reviewed for supporting
corporate strategic goals and for the value they deliver.  If any software
no longer provides value or supports corporate goals, it should be
jettisoned.  Likewise, if software is providing more value to an
organization, then proportionately more cost should be easily justified.
One of the biggest issues my customers struggle with is trying to understand
the cost of adding new licenses.  For example, I have one customer that had
75 user licenses.  This customer added workflow two years ago and instantly
the number of MAPICS users went from 75 to over 400!  When they requested a
quote from their affiliate, and received it, and they just about croaked.
They were looking just at the expense and not the additional value that the
new seats brought to the company.  Worse, for the CIO, had not informed the
board of the potential cost of deploying Workflow.  I was asked to help out,
and found the job very easy.  The ROI on the additional licenses was 4
months.  Hard dollars direct to the bottom-line in 4 months!  It was a no
brainer.  The board approve a 6 figure expenditure in 5 minutes.

 

Last comment (and yes I could go on and on):  Over 90% of MAPICS customers
NEVER tell MAPICS what there top ten unfulfilled requirements are.  Every
year, as a customer, I would send a letter to MAPICS with my requests.  I
would make trips to Atlanta to meet the development team.  My company had 16
user licenses.  It was THAT important.  If more customers communicated to
MAPICS what their requirements are and most importantly, will be.  Then ALF
will become more valuable.

 

Hope this helps put some light on the ALF issues.

 

Kevin Fox