I provide
excellence in systems and business analysis, identifying existing and
potential problems and their solutions. I provide excellence in systems design
and implementation, including documentation, testing and coding. My solutions
are robust, creative, correct, cost-effective, low maintenance and fit my
client’s needs. I rapidly acquire new skills and integrate my existing skill
base into any new environment.
Systems and business analysis and
problem solving. AS/400 (DDS, OS400, SEU, RPG(I, II, II, IV & LE), CLP,
System call routines, SDA, Data Queues), BPICS, MAPICS Sys/36/34 tools, C,
Fortran IV/77, PC’s
Microsoft Office, Microsoft
Project, Microsoft Front Page, Microsoft Publisher, Adobe Acrobat, Adobe
Photoshop, Windows (95,98,NT,2000,XP), C++, Forth, miscellaneous office
equipment (copiers, fax machines, calculators), engine lathe, oscilloscope,
VOM, soldering iron, fork lift, pallet jack, air impact wrench, air
compressor, paint sprayer, carpentry tools, cable laying, various vehicles up
to large gasoline trucks including ambulances, electrical wiring, some
plumbing, basic HVAC, child care, CPR, basic first responder, basic auto
mechanics, bicycle repair, photography, darkroom (color & B&W),
Graphic Arts production equipment, gardening and woods craft.
APICS
certified – Production Control
Bachelor's Degree, UW-Stout, BS in Industrial
Management - Graphic Arts Concentration
Emergency Medical Technician – Madison Area Technical School
Available on request.
Board Member, Friends of the Menomonie Public Library
Religious Education Chair, Menomonie Universal Unitarians
Volunteer, Menomonie Humane Society
Girl Scout leader
Other interests include: tai chi, gardening, photography, writing (fiction, opinion and nonfiction), reading, computer simulation, data display/interface design, permaculture, housing, alternative energy, pyrotechnics, history and philosophy.
A system must first and above all, reliably provide data
services needed by the people using it. Such services may or may not be
recognized by those who need them.
Data processing requirements determine design
requirements—specific tools used to implement a system are secondary.
A system should be well documented.
There are three basic types of documentation required: Internal
documentation for the maintenance programmer, documentation for everyday use and
training, and documentation for exceptional circumstances (i.e. year end
processing.) The level of detail required in each is the inverse of the order
presented—those functions used least often must be best documented.
Program design is an iterative process.
Multiple passes are usually required to properly identify and implement
all needed features. This is because very few people can truly visualize their
needs from a blank page. By
refining and redefining the design, features which become possible based upon
knowledge gained during one pass can be implemented in the next—often there
will be useful features identified and implemented which would not have been
considered without intermediate stages. Attempts
to fully design and lock a system design before implementing any of the design
will lack features that could have been easily implemented, and often will have
more value than the original conception.
A functional but ragged design may be implemented, but
effort should immediately be put forth to streamline such design to properly
document and provide ease of future maintenance.
The additional time spent to rewrite a system immediately after it is
functional will pay back many times over the lifetime of the software.
Software always stays in use far longer than anticipated.
The accuracy with which a project’s requirements may be
determined is directly proportional to the stage of development currently
achieved. No project estimate at
the beginning of a project can be expected to have any high degree of
correspondence to the final resources used.
Error and exception processing is vital to any non-trivial
project. If such processing is not
installed, the software, no matter how well it works, is not finished. When
possible, programs should incorporate measures to handle installation and
maintenance of required objects dynamically.
User interfaces need to address the concerns of the actual
user, not their manager. There is
no better design aid for a user interface than an actual user.
Craftsmanship is important, my mother, who taught me carpentry, painting, wallpapering, sewing and cooking also taught me to sign my work.
Client:
Stella
Foods, Green Bay, Wisconsin
Problem:
Synchronizing inventory data between BPICS and in-house resource planning
systems. Existing system required one person full time to handle processing
errors between systems. This created a severe lack of trust in the system by
those dependant upon the data.
Solution:
Centralize all inter-system transactions into one program, simplifying
maintenance and minimizing errors.
Result:
Systems synchronized without errors, freeing one person for other
programming tasks and greatly increasing reliability.
Procedure:
Analysis determined that the existing system handled data transfer
between systems via modifications in each program that did file maintenance on
either system.
A suite of programs was designed and constructed to create and maintain
data queues to sequence the transactions in chronological order (FIFO).
This suite included modules to add and remove items from the data queues
and resize and/or recreate the data queues and the associated programs
dynamically as needed. Documentation
and training in the use of these programs was provided to the programming team
implementing the project.
A program was designed to process the entries from the data queues
dynamically as entries were placed in the data queues.
This program handled all actual file updates to both systems.
This system was successfully installed over a weekend as part of the
warehouse system modifications.
Tools:
SEU, CLP, RPGIII, DDS, SQL, BPICS and AS/400 system calls.
Duration:
3 Months
Client:
Major
Packaging Converter
Problem:
Client had spent about one year prior to my involvement trying to design
a method of collecting and retaining cost information for products which were
manufactured for their clients but warehoused by them for weeks to months before
shipment and invoicing. Client
wanted to compare costing data at the time of manufacture to cost at time of
invoicing.
Solution:
A database was designed to hold the cost data at time of manufacture and
programs designed and written to access and compare this data with cost data at
the time of invoicing. This
comparison data was then transmitted to the home office.
Result:
Client now has capability to determine cost variations for products
between time of manufacture and time of invoicing.
Procedure:
Initial discussion involved the head of IS and four plant CFO’s from
the affected manufacturing plants. By the end of the day a rough plan of the
design for the database was in hand. Actual
program design and construction took an additional year.
Tools:
DDS, RPGII, SEU, BPICS
Duration:
12 months
Client: Peter Morin, Attorney
Problem:
The client was accused of violating internet pedophilia pornography laws.
I was requested to analyze internet records and the seized computer
system to determine if it was arguable that the client’s accused actions had
actually been the work of some other party.
Solution:
ISP and phone records and an image of the seized computer hard drive were
examined.
Result: It was determined that the argument could not stand up in court—the transactions in question correlated with the ISP and phone records. Data records on the hard drive were encrypted and inaccessible.
Procedure:
Comparison of time stamps of log files from the ISP and phone records
indicated that calls were made from the accused to the ISP at the times which
data was transferred. Analysis of internet usenet group archives indicated
correlation with this data and the user’s handle.
Tools:
Internet browser, Copernic Search engine.
Duration:
1 week
Client:
Michael Fairchild,
Attorney
Problem:
In a divorce case, it was suspected that one of the parties was
concealing information regarding the valuation of business assets.
Solution:
Access to the business’s computer was arranged with intent of
recovering any and all business-related data.
Result:
Minimal
data, suspected to be false, was retrieved.
Procedure:
An image copy of the hard drive was created after physically removing the
drive from the PC. Data recovery
software was used to attempt to discover any deleted data.
No deleted files were found on this Windows 98 machine, remnants of two
virus checking packages were discovered, as were three worms and one virus.
This led to the conclusion that information had been present on the
machine but had been removed and wiped before access was granted.
Testimony was given to this effect.
Tools:
Drive Image, Search and Recover, Quicken, ADS external USB drive case.
Client:
Tombstone
Pizza, Medford, Wisconsin
Problem:
A cost reporting program existed that was run four times each shift (once
for each floor manager) taking 45 minutes for each run.
During efficiency upgrade it was discovered that both this program the
original program from which this had been copied were not generating correct
costs.
Solution:
The program was redesigned for better efficiency, reduced to running one
time each shift for a period of 15 minutes.
When verifying the correctness of the rewritten code, it was discovered
that the original program was in error.
Result:
Program size was reduced by 50 percent, daily execution time reduced from
three hours per shift to fifteen minutes, and the module was modified to verify
that all of the required data was available before it was run automatically by
the system. If all data is not
available at run-time, the system notifies the responsible cost accountant of
the fact and requests manual execution. Copies of the report were distributed to
the appropriate managers via distribution list for each shift.
Procedure: Program was analyzed to identify those sections of code using the most resources. These sections were redesigned to be more efficient. A module was designed to self-submit which verified that the required data had been entered and waited until the data was either available or a set time limit had been reached.
While hand verifying the new cost calculation module it was discovered
that the original program and the program from which it was copied were giving
erroneous results. The primary copy
was repaired and the vendor notified of the error.
Tools:
SEU, DDS, RPGII, CLP, BPICS
Duration: 6 months