Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 01/02/04

  • Next message: Peter E.C. Dashwood: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO" 
    Date: Fri, 2 Jan 2004 13:20:26 +1300

    "Doug Scott" <dwscott@ieee.org> wrote in message
    news:VA.000003c0.006c5d05@ieee.org...
    > Judson,
    >
    > > It would be interesting to learn how you see
    > > these in a 'no batch' scenario. :-)
    >
    > I did a lot of work on this. You can do most updates in real time, but
    > reporting is by its very nature a batch process.
    >
    > ---

    Yes, it certainly is today...

    But, let's look at it from another angle...

    There was a time when corporations had a mainframe and that was all there
    was.

    I remember running end-of-month processing for a household name motor parts
    manufacturer in Auckland in the late '60s. Tapes (disks weren't invented)
    were sorted for around 6 hours and then "The Reports" were run. (this took
    another 4 hours as stock movements and levels of over 100,000 parts were
    produced for several hundred branches.)

    A mountain of green lineflo (anyone remember that <G>?...) was manually
    split up on the Branch control breaks and distributed by post to the various
    Branches.

    After some time and numerous complaints from the Branches, we realized that
    all this effort was really wasted because the reports sat in a corner
    gathering dust until they went to the "pulping" bin (today that would be
    "recycling"; the money obtained from this was used to help fund the staff
    Xmas party at each Branch...)

    The fact was that it was easier to go to a bin and check the stock level
    than it was to wade through the report and see what the computer "thought"
    should be there. So the report was really pretty useless.

    The EDP manager suggested that this report should simply be summarized (he
    saw a chance to get some of the tension out of his already stretched
    budget). There were howls of outrage from the Branch managers who
    vociferously asserted that this report was fundamental to their operation
    and they couldn't live without it...(Human nature is beyond the scope of
    this discussion <G>...)

    The report stayed. It was produced for years and ignored for years until
    online processing was implemented and the stock levels (and consequent back
    order status, where applicable) were available on a green screen at the
    touch of a button.

    It is interesting that the ability to know whether an "out of stock" item
    had been back ordered and when it was due to arrive, added enough value to
    the system that it was now preferable to enquire online, than to walk to the
    bin and check a card...

    Here are the points I am trying to make:

    1. The purpose of producing a report is to provide "information". (This is
    NOT the same as "data", but we won't go into the distinctions, or sidetrack
    to Marshall McLuhan, or investigate the finer points of Information Theory,
    even though that is what CLC LOVES to do...<G>. For this post, let's just
    stay with the NEED for reporting...<G>).

    2. There are alternative ways in which information can be presented.
    Reporting is an arguably archaic one. Even if you decide that reports are
    "good", they are certainly NOT the ONLY way to present information. One of
    the cited advantages of reports was that they could be filed and referenced
    later. Nowadays, a decently designed transaction system can reproduce a
    report from up to 7 years ago, in seconds, with no requirements for
    microfiche readers, storehouses or reinforced flooring...

    3. Modern managers have grown up with spreadsheets and databases and are
    used to visualizing information in the form of graphic models. Lines of
    "print" are not as informative for summarized data. Colour and graphics are
    becoming a necessary part of modern Management Information Systems.
    EVERYTHING is on a screen; if hard copy is required, it can be obtained at
    the touch of a button. The concept of Batch "listings" will progressively
    disappear as more immediate forms of information presentation replace it.
    (Think about the last time you used a quill pen...Now think about the last
    time you retrieved information from the Internet...)

    4. Government (and similar Legal) requirements for information on duly
    filled out forms are being met by EDI, so there is no need to get a listing
    and transcribe the data to a hard form.

    5. New media (PDAs, cell phones, etc.) are coming on line and information
    can be (and in an increasing number of progressive businesses, IS BEING...)
    retrieved anywhere, any time. CEOs who want to know the top performing
    Branches World wide can get it on their cell phones with "bottom lines"
    updated every few minutes.

    Why would you go "back to the office" to consult a listing, when you can
    have it reproduced on your phone or PDA at the restaurant where you are
    lunching clients?

    6. Much of the current "Reporting Requirements" in Corporations are based
    around Batch Hard Copy because that is cheap and effective, doesn't strain
    the system, and is "traditional" (especially on mainframe-centric sites).

    As these systems are replaced by more Network oriented solutions (and,
    believe me, they WILL be...), questions will legitimately be raised over
    exactly WHAT information is really required to run the business, HOW
    AVAILABLE should it be (there are issues of security around listings; anyone
    who can read can have access to it if they get hold of it. Displayed data is
    easier to control.), HOW TIMELY does it need to be (Batch reports can only
    reflect the situation as it WAS at the time the report was run...), and
    finally, the sheer resistance to using paper (large amounts of it) for a
    questionable benefit.(The rising generation are much more environment aware
    than we were...)

    I know the "paperless office" we were promised years ago has failed to
    eventuate, and it is unlikely to, but the need for Batch Reporting can
    certainly be challenged and I hope the above will persuade you that it can.

    I do not see "Reporting" as being the reason we will perpetuate Batch
    Processing.

    (In fact, I don't see Batch Processing being perpetuated at all, and that is
    where we came in...)

    Pete.

    >
    > Doug
    >
    > dwscott@ieee.org
    >
    >

  • Next message: Peter E.C. Dashwood: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"