[Info-vax] What does VMS get used for, these days?
Dave Froble
davef at tsoft-inc.com
Mon Oct 24 18:09:02 EDT 2022
On 10/24/2022 4:54 PM, Arne Vajhøj wrote:
> On 10/24/2022 4:42 PM, Arne Vajhøj wrote:
>> On 10/24/2022 10:06 AM, Dave Froble wrote:
>>> On 10/23/2022 7:18 PM, Arne Vajhøj wrote:
>>>> On 10/22/2022 5:09 PM, Bill Gunshannon wrote:
>>>>> When Banner was brought in to replace the custom apps on VMS at the
>>>>> University it was understood upfront that everything was going to
>>>>> change the users were the one's that would have to adapt.
>>>>>
>>>>> Compare that to where I worked in 1980 where I was tasked with
>>>>> developing a microcomputer based data entry system to get the
>>>>> "keypunch" people off the mainframe to free it up for production
>>>>> and development work. The first requirement was that what I was
>>>>> to develop had to present itself to the users exactly like what
>>>>> they had been using on the Univac-1100.
>>>>> How times change.
>>>>
>>>> Usually adapting usage to the standard packages way of doing things
>>>> is the smart approach.
>>>
>>> This is where Arne departs from reality ...
>>>
>>> He seems to believe in "lowest common denominator" ...
>>
>> > Reality is that some people suffer with poor tools, and if a well
>> > designed package can be found, it can be an improvement.
>> >
>> > The other side of that is that some people are working with tools that
>> > have been designed and refined over time to be exactly what they need,
>> > and anything else will affect their work, sometimes quite drastically.
>>
>> Not really. I don't think you got the point.
>>
>> It may make sense to pay for a custom solution tailored for
>> specific needs.
>>
>> It may make sense to go for a standard solution and use it
>> the standard way.
>>
>> What I am skeptical about is the approach of taking a standard
>> solution and do extreme customization.
>>
>> That sort of defies the point of the standard solution.
>
> Let us as an example say that we have a custom application
> with 1 million lines of code.
>
> Let us say that there exist a standard solution with 5 million
> lines of code which provides the same functionality plus a
> lot extra (some useful - a lot irrelevant).
>
> If the standard solution need 1% customization, then that
> is only 50000 lines of code. And there may be a business
> case. Obviously exact fit to requirements would need to
> be evaluated, but potentially it could make sense.
>
> If the standard solution need 40% customization, then
> that is 2 millions line of code. And it seems very unlikely
> that there is a business case. It would make more sense to
> add to the custom application.
I recall an app I provided maybe 30 years ago.
The users sold wholesale sporting goods. The marketing people were quite
inventive with pricing schedules and such.
So, an invoice went out to a customer with maybe 100 lines. The customer
complained that they didn't get the proper pricing.
What the users were doing was issuing a credit, for every line on the shipment,
so another 100 lines to be entered. Of course, during the correction,
additional errors could be introduced. Then key in another invoice, 100 lines,
with the correct pricing, which could incur additional errors.
Trust me, there were keying errors, which then caused the entire process to be
repeated again, and again, and again ...
:-)
Now, before someone mentions just issuing an adjustment in A/R, consider the
company had some sophisticated sales analysis, which was used among other things
to allow marketing to plan for the next year's activity. So getting the correct
sales data was sort of critical. Imagine needing to get your order into a
factory in the orient at least 6 months ahead of time.
Anyway, I quickly realized that all the relevant data was already available. I
designed an app that would read the original invoice data, and reverse it, then
go through it again allowing the user to just correct whatever needed to be
changed. Rather simple to program, and made a huge difference in the company's
operations.
Just an example of where a tool that provided exactly what is required can be so
essential to a business. The "standard method" was all the re-keying, and
re-keying, and re-keying ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
More information about the Info-vax
mailing list