× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dear DeeDee ...

The answer to your question is yes. The exit points are intended to facilitate bringing a stream of data back into BPCS.
Now, within the boundaries of a three-day presentation, there was
no way to finish addressing this issue:

Have each of the exit points defined a comprehensive enough array of retreived (arriving back into BPCS) data to support the function of a fancy external system? It's certainly true that the outbound data defnitions need not be 100% comprehensive, because an external system could always go back into the BPCS database all by itself and yank out some additional factors. Getting fully robust results back into BPCS through a given exit point is another subject. Yes, your observation is correct ... the exit point idea theoretically would enable buying the best-of-breed bolt-on for
a given functionality instead of purchasing the brand of IP that
SSA has decided to acquire.
In my opinion, Cognos was a good acquisition.
I'm not convinced that the best-of-breed software brand in other
market segments now "addressed by LX" was even for sale when SSA went shopping.


Milt Habeck
Managing Partner
Unbeaten Path International

(888) 874-8008
www.unpath.com






+++++++  +++++++  +++++++  +++++++  +++++++  +++++++
From: DeeDee Virgei To: SSA's BPCS ERP System Sent: Friday, February 17, 2006 3:42 PM
Subject: [BPCS-L] BPCS ERP LX --- my 60,000 foot point of view

Thank you Milt!  I, REALLY appreciated your unbiased views...

In a nut shell, after reading through literally 1000 of enhancements, I
too was most interested in the added exit points and would love to learn
more about how they work, how reliable they are, if they can also be
used as entrance points...  My thinking is, if these exit (and I think
entrance) points work the way I hope, then we would be able to choose
from other best-of-breed/boltons in addition to what SSA has to offer.
I know that sounds like SSA w/b shooting them selves in the foot, but
that would make their ERP product much easier to interface w/ (FYI, that
is what the 'i' in iSeries stands for...).
I still have 'a general web presentation on LX functionality' on my SSA
wish list...

Thanks again Milt.

Best Regards,
DeeDee Virgei
Project Leader
Nelson Stud Welding, Inc.


+++++++  +++++++  +++++++  +++++++  +++++++  +++++++
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




+++++++  +++++++  +++++++  +++++++  +++++++  +++++++
From: Milt Habeck
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
logistics planning (for example) .... then, in my opinion, the 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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.