BPCS ERP LX --- my 60, 000 foot point of view + more AS/SET details

Dear Helen ...

About your more detailed questions on AS/SET and LX ....

AS/SET from v8.2 was used for the very last time to generate RPG.
Then they invested some time to clean out some parts of the RPG
... for example, SSA claimed that they took out a few million
not-too-helpful comment lines. At that point, all associations
with AS/SET were permanently severed.

SSA's rationale is that the AS/SET was getting in the way of using
industry-standard development tools (including ...just a wild guess ...
maybe the tool that SSA used to get to the not-pretty GUI screens).

For people that are AS/SET experts or have AS/SET-savvy
development tools, it's a disappointment.

     Here's an example of a development tool, a software change
     management package, that handles AS/SET just great:
     Tight as a Drum ----> http://www.upisox.com/drum.html
          Warning to readers: that was a sales message.

After this final RPG generation of v8.2, I believe SSA then did
some tinkering with product functionality in the RPG source.
For example, they added those several hundred exit
points I refered to in point  "j"  below.

The few pages of sample code screen shots presented to us were
standard issue RPG .... we did not see any "free format" RPG.

 Please note this: those several pages of RPG code (that
 had been stored on the presenter's PC in preparation
 for a tough question from a client audience) were not
 necessarily  representative of the other X million lines
 of v8.3 RPG code. Hence my advice to take a look at
 an ample sample of RANDOMLY selected LX code
 before you arrive at a maintainability conclusion.


God bless you,
Milt Habeck
Managing Partner
Unbeaten Path International

(888) 874-8008
www.unpath.com




+++++++  +++++++  +++++++  +++++++  +++++++  +++++++
From: helen@xxxxxxxxx
To: mhabeck@xxxxxxxxxx
Sent: Friday, February 17, 2006 3:49 PM
Subject: Re: [BPCS-L] BPCS ERP LX --- my 60,000 foot point of view

Thank you for your 60,000 foot point of view.   I wasn't completely clear
on what you were saying here...is AS/SET totally absent in this source?  If
so, what style of RPG are they usuing (any free form at all)

    So, in my view, the maintainability of the v8.3 RPG code should
    not be considered a fully resolved issue. Anyone who has seen the
    cryptic nature of AS/SET-generated RPG code will probably want to
    review an ample, randomly-selected sample of LX RPG source
    before arriving at any firm maintainability opinions.

Helen Hull
Sr. Programmer/Analyst
Group Dekko Services LLC




+++++++  +++++++  +++++++  +++++++  +++++++  +++++++

To: BPCS user community
Sent: Friday, February 17, 2006 2:16 PM
Subject: [BPCS-L] BPCS ERP LX --- my 60,000 foot point of view

Hi ...

I've recently had an opportunity to look at an SSA presentation of LX
functionality. It was a fairly good look over a three day period. The
objective of SSA in this presentation was to persuade a potential upgrade
candidate that LX addressed a long compilation of needs identified by that
company (a company that currently is at the v4 level).

Here are my general impressions and opinions, in no particular order:

a. It's all GUI. To tell you the truth, green screen looks prettier. The
font SSA uses universally and the screen layouts and graphic elements
employed are anything but attractive ... certainly not easy on the eyes.

b. More on the screen display .... SSA uses, at most, 5/8ths of the
verticaldimension of the screen. The bottom of the screen is wasted
white space that just holds a small box for function keys. Net result:
A display with multiple lines of information requires lots of screen
paginations to see anything.

c. Last on the screen display: not so user friendly on the field labels.
The field on one A/R report specification screen is labeled "Curr."  Well,
if you know the fields in the database, you could guess that Curr meant
"currency" ... but if you're less savvy, you might think it meant
"current." There's more than enough room on that part of the screen to
spell out "Type of Currency" .... but what shows up is plenty of white
space and just the four letters "Curr."  This issue is prevalent in all
BPCS modules.

d. Functionality distinctions between v6 and v8 for modules that already
exist in v6 are pretty minor. Examples include longer field lengths for
some things (like customer PO number and item class and/or type). Cost
accounting functionality is identical to v4.05CD (except for the GUI
presentation).

e. The new functionality has mostly arrived in the form of bolt-ons and a
generous percentage of those don't run on the iSeries platform. They are
pieces of software that SSA has acquired and re-branded as part of "LX"

f. They have a nice financial budgeting bolt-on which looks to be well
integrated with the BPCS G/L. It's an application of Cognos. My opinion is
that a BPCS user could get the same functionality on v6.x if they wanted to
buy that part of Cognos or if SSA wants to license the bolt-on to non-v8.3
users.

   By the way, integration with non-G/L parts of BPCS isn't there
   and isn't claimed. Oliver Wight, if he was alive, could write a book
   on the integration possibilities into non-G/L parts of BPCS that
   have not been exploited.

g. LX comes with a package of hundreds of pre-programmed reports and/or
performance metric analyses that do not exist in v6. These reports are
generated by Cognos off a data repository which is extracted from BPCS
(not real time).
Now, in my opinion, before using most of these reports or metrics, you'd
want to dig into the logic to make sure that the report was consistent with
the way you wanted to run your business.

   Example: I've seen customer service level defined many, many
   different ways and SSA's definition is unlikely to be accidently
   consistent with your company's private definition.
   Now, if you're going to invest the time to go through all these
   reports/metrics before using them, then you could do this yourself
   on v6 or even v4 ... if you had a Cognos license.

h. Examples of other bolt-ons include sales forecasting/demand planning,
logistics planning, and rule-driven/constraint-savvy manufacturing
planning.
My impression is that if a company needed this kind of functionality to run
their business better, then that company would be well advised to do a
software selection analysis within each specific software market segment
rather than just presuming that SSA had acquired the IP for the "best of
breed" in each of those segments.

    Here's my strongly-held opinion about these bolt-ons:

        Let's say a BPCS v6 company could earn a huge ROI from better

        idea would be to immediately invest in a best-of-breed logistics
        package and knit that to BPCS v6.

       That seems like it would help the enterprise more/faster than SSA's
       idea of buying v8.3/LX.

       If you go out and buy LX for the privilege of implementing the
       logistics software brand that SSA happened to purchase .... then
       your company has to go through the arduous version migration
       steps for business processes that already work just fine in v6
       BEFORE  your company gets any traction on what
       would really generate an ROI (e.g. logistics planning).


i. SSA claims to have made some effort to clean up the RPG code generated
by AS/SET. AS/SET is gone.

    In response to a question about this, the SSA presenter showed us
    screen shots of part of the code for one RPG program. Someone who
    knew RPG in the room was able to find a place where in line 2500x a
    value was assigned to a variable but before that variable was used,
    the value was replaced in line 2500x+2 with something else.

    So, in my view, the maintainability of the v8.3 RPG code should
    not be considered a fully resolved issue. Anyone who has seen the
    cryptic nature of AS/SET-generated RPG code will probably want to
    review an ample, randomly-selected sample of LX RPG source
    before arriving at any firm maintainability opinions.

j. They've added hundreds of "exit points" in the source at places where
they believe users might want to insert customizations. It's like
pre-inserted subroutine calls that can either be used or ignored.  The
intent is to keep the virgin code un-mingled with BPCS customizations so
that adoption of future upgrades is not impeded by the customizations. It's
new, interesting, creative and it might work for quite a few things. .

k. In LX, ELKE has been re-named (EAM? I forget) and it looks like the
integration back into BPCS purchasing has been substantially improved.
Other integration is still pending.

     Example: planned production machine maintenance time period info
     doesn't look like it gets over into a place where Capacity Planning
     could incorporate that planned downtime into CRP calculations.
     I'll admit in advance that my memory on this detailed point isn't
     as good as it should be.



This is way too long already, so I'll stop.
If anyone wants to talk about this subject, please give me a call.

Warm regards and peace to you,
Milt Habeck
Managing Partner
Unbeaten Path International

(888) 874-8008
www.unpath.com