Volume 10 No. 8 August 1980
NEXT MEETING
September 4, 1980
LUNCHEON SPEAKER
Jack Kiley
Assistant State Treasurer
"State Treasurer's Cash Management Program"
Speaker Introduction
Jack Kiley was born and raised in the New York area. He attended Lehigh University and, upon graduation, received a commission in the Army, and was promptly sent to Fort Lewis, Washington.
After two years in the service, Jack attended graduate business school at the University of Washington. While at the "U", he was offered a political internship in the state capital sponsored by the Ford Foundation. He subsequently became a budget analyst on the bipartisan Legislative Budget Committee. One of the studies he participated in during the five years that he was on the staff of the Budget Committee was a review and analysis of the deposit practices of the State Treasurer. Bob O'Brien, State Treasurer, subsequently hired Jack to implement the recommendations made in his study. He has been with the Treasurer's Office approximately eight years, holding various positions, and now occupies the second slot as Assistant State Treasurer.
Jack is on the Board of the Washington Finance Officers' Association and is a member of the MFOA's Committee on Treasury Management. He has spoken on cash management and investment practices at numerous meetings of municipal and county treasury officials, to the Western Treasurers Conference, the National Association of State Treasurers, the National Association of State Auditors, Comptrollers and Treasurers, the Municipal Finance Officers Association, and the recent Government Cash Managers Conference in Washington, D.C.
Personality Profile
Our personality profile this month features Patti Palmer, our ADPM chairman for 1980-81. Patti has been very active in ADPM activities for several years. Many of you may know her as the past editor of the ADPM Newsletter, a position she has performed excellently since July 1977. Patti has also previously held the offices of Program Chairman and Secretary/Treasurer.
Patti is currently an Assistant Manager Information Systems - Systems Development II (AMIS - SD II) with the Department of Transportation. She has been DOT's Software Manager since July 1979 and is responsible for all software design, development, maintenance and enhancements for an IBM 3032 MVS/SE system which supports TSO, JES2, CICS and ADABAS.
Patti graduated from Lincoln High School in Tacoma. She attended a two-year data processing program at Clover Park vocational Technical School, graduating in 1969 and received her Associated Arts Degree in data processing from Fort Steilacoom Community College in 1970. In 1977, after several years of weekend and evening classes, Patti received her Bachelor of Science Degree in Education from Southern Illinois University.
Patti's working career in data processing began in 1968 when she started as a programmer in Tacoma. In May, 1969, Patti moved to Olympia to the Office of Financial Management where she was a programmer for about 18 months. In October, 1970, Patti transferred to DSHS and became a Programmer III in the software section. For two-and-one-half years Patti was responsible for generating, testing, documenting and maintaining HASP and OS systems for an IBM 360 system.
In February, 1973, Patti transferred to the Department of Transportation and assumed the responsibility of a Computer Support Specialist I (CSS I). Her primary responsibility was keeping the telecommunications system online. Patti became a CSS II in November, 1974, and AMIS-SDI in 1976, an SDS in 1978, and was promoted to Systems Software Manager in July, 1979.
Patti is the mother of two daughters: Shandy, age 21, works in the sales audit section for J C Penney in Tacoma and was married on June 27. Coelleen, age 18, is a nurse's aide at Panorama City in Lacey and is looking forward to a career in law or nursing. She plans to attend school this fall.
Patti is also an avid traveler (recently visiting Hawaii, the Caribbean, and Canada), a past member of the YMCA Board of Directors and an active participant in local community projects. She enjoys hiking, biking, camping, photography, and gourmet cooking. In her 'spare" spare time, Patti "works out" at the Capital Fitness and Recreation Club, is a citizen band radio enthusiast, and pretty good racquetball player, and runner and enjoys jazz ballet and aerobic dancing.
As you can already tell, Patti is a very active person. Recently she was selected as a grant recipient of a Federal Highway Administration Fellowship to pursue her studies at The Evergreen State College. She plans to earn a Master's Degree in Public Administration.
As ADPM chairman, Patti plans to set goals for the Association which will provide a positive direction for FY 1980-81. She would like to reestablish the Association as a place where top data processing managers meet to discuss common problems and to share plans for the future. Her other goals include:
Patti's goals for herself for the future include:
Good Luck, Patti!!
Jim Andersen
SPI
DPA Acquisition Policies/Standards Update
An ad hoc committee of data processing managers is in the process of reviewing the current DPA policies, standards and guidelines that pertain to acquisitions of data processing resources. The purpose of this review is to provide recommendations to the DPA staff for updating these policies, standards and guidelines.
The State ADP policies and standards to be reviewed include:
The review may also include:
The committee is considering modifications to (1) achieve greater flexibility in acquisition delegations, (2) base approval dollar criteria on total costs rather than annual costs, (3) evaluate greater value limits for each approval category, (4) the "Factsheet" to achieve greater flexibility, and other items~ At present, the committee is preparing draft revisions to the appropriate policies, standards and guidelines for distribution to the State Data Processing Managers for review and comment~
A solicitation addressed to the State Data Processing Managers by Terry Wold, dated July 21, 1980, requesting constructive comments regarding improvements to the acquisition procedures, resulted in only one letter (suggesting no changes) returned to the DPA staff by the August 8, 1980 deadline. NOW! is the time to provide your input on these DPA procedures (or forever hold your peace)~ Look for the draft revisions to be distributed soon and make your appropriate comments~ If you have any questions, contact Jim Michal who is coordinating this project.
Jim Michal
Data Processing Authority
ADPM Planning Conference
Just a reminder. Our planning conference is scheduled for September 9 and 10 at Evergreen State Co1lege.
As of August 11, 32 participants (representing 19 agencies) are registered.
Committee assignments have been made. Chairmen and scribes for each committee have been selected and briefed on the planning session format. Preliminary planning work is underway.
Bill Lundberg, Chairman
Department of Natural Resources
Human Resource Development Belevedere
Thank you, all of my friends who have approached me inquiring as to the whereabouts of my position with the Division of Human Resource Development (DHRD), Here are the answers to the two questions you have most asked.
The answer to the first question is: "Yes, I do work for DHRD which is headed by Dr, Mary Jo Lavin. However, I report to Mr, Fi Fiorini, Assistant Manager for the Employee Development Unit at DHRD". The function of the state DP training coordinator has been allocated under this organizational unit.
The answer to the second question is: "Yes, my working title is Program Manager, Technical Training". The title does not mention DP, specifically, because in the future, I will be developing and coordinating technical courses that could be related to DP such as accounting and others.
Before we get to business, I would like to take this opportunity to express my gratitude to the following DP managers for agreeing to instruct the indicated training courses under tight constraints of preparation time and short starting date notice.
Now, let's discuss business: Jan Kelsey and Fran Heitzmann from WDPSC, and myself have just completed the first-pass debugging of the CAI package on introductory statistics. It took us a little longer than we anticipated. (Am I telling you something you don't already know about debugging?) Watch for Dr. Lavin's guidelines for registering your DP personnel in this IBM individualized training course.
As most of you know, I teach a graduate class: MC5IS, Information Systems for Management, for the MBA/MPA Program of City College, Tacoma Campus. I had Cliff Cotey, WDPSC, as a guest speaker on the August 5th meeting. After his presentation of the WDPSC, its purpose, functioning and services, a bull session of questions and answers was triggered. My students very much welcomed Cliff's presence that night.
Jim Michal, DPA, will be my guest speaker on August 26, 1980. Comments on his presentation will follow in the next month~s issue.
Courses coming in October, 1980 are:
The HRD contact person in your shop or agency should have received the course announcement (blue flyers) by now.
i Saludos amigos!
Dr. Ruben L. Marti
Division of Human Resource Development
Data Structured System Design - Edit Models
Report models were presented first because they are the most visable portion of a system. They are the starting point for the design or upgrades of most systems, and they are the easiest to understand, Edit models are presented next since their function is to assure the accuracy of the date going into any system. If the data going into any system is inaccurate and yet still allowed to enter, that inaccuracy will cast doubt on the integrity of the total system.
With report models the model structure was fixed and the designer simply inserted an entity name in place of report, entity A, entity B, etc. There was very little modification of the structure other than the insertion of the additional features desired.
Edit models are different than report models. They are a set of instructions for the designer to follow to develop a specific processing structure to edit a specific set of data. The model structure is not the final processing structure.
Edit models are data structured like the report models. However, they are different in that the transactions are read at a higher level than they are in the report models. In edit models the highest level is the edit process and the next level is the entity being processed. In most cases this entity is a logical transaction representing a specific data entity not just a physical record. Therefore, the term Each Entity is used rather then Each Record.
A variety of functions may occur in an edit routine. The data may be edited to determine its validity and checks for reasonable values can be made.
Relation edits may be done between two or more fields to further determine data validity and reasonable values. Code generation may occur where the data entered is converted to a code that used throughout the remainder of the system. Records may be sequenced, duplicates removed, or missing records noted. All of these functions assure the integrity of data entering the system.
There are two approaches to determining whether data passes or fails an edit. The first is to assume that the data is correct, check for failure, and if a failure occurs indicate a failure. The second is to assume the data is incorrect, check for correctness, and if correct indicate a pass.
The first method is used with the edit models because it usually results in less processing time. The amount of logic developed will be identical in either case, but the processing will be less in the first instance because the actions will be taken only when the data fails the edit. If, however, the error rate is extremely high, i.e. over 50 percent of all checks are failing, — then it would be better to use the second approach.
Four general edit models have been defined. The first, and simplest, is a data edit with no relation checks. The second is an edit with relation checks always performed. The third is an edit with relation checks performed only if the entire entity passes the edit. The fourth is an edit with relations checked only if all the attributes involved in the relation pass.
The basic edit model edits individual attributes, but does not check any relations between attributes. It is the simplest form of edit and is used as the base for building the other edit models. Figure 1 shows the basic model structure.
In Begin Data Edit, Begin Entity, and Begin Attribute logical indicators are set to pass indicating that the assumption is good data. If the data fails the edit then the indicators are set to fail as shown in the Criteria Fail, Attribute Fail, and Entity Fail sets.
The first edit transaction is read in Begin Data Edit. All other transactions are read in End Entity. The only processing check is for end of data after reading each new transaction.
At the beginning of each entity the transaction is printed before any editing occurs. Then errors are found the error messages are stacked under the printed transaction. It is possible to print indicators under the fields in error, or to print the transaction after the error messages. These features are easily added to the basic logic structure.
At the end of an entity a check is made whether the entity passed or failed, and the appropriate write is made to a master file or to an error file. Actually, any desired processing may be inserted in these sets since there are numberous ways to handle entities that pass and fail. Whatever is done, this is the place where it is done.
In the Criteria Pass and Attribute Pass sets OK is entered. Usually nothing is done when the data is correct. However, if something is desired, this is where it is entered.
The actual processing structure would be similar to the structure shown below. The highest two levels would be the Data Edit and Each Entity sets. Within Each Entity there is a list of inclusive OR's which acutally perform the criteria checking. Each inclusive OR would be the negative of the criteria, i.e. if data is not valid, and its subset would contain the actions to perform when the data is in error.
| Begin Data Edit | |||
| Begin Entity | |||
| Data Edit | Each Entity | If . . . If . . . If . . . If . . . |
|
| End Entity | |||
| End Data Edit | . |
The next edit model is one where any relation between two or more attributes is always edited regardless of the pass or fail conditions of any attribute in the entity. Figure 2 shows the mandatory relation edit model structure.
The mandatory relation edit model is the same as the basic edit model, except that an Each Relation set has been inserted between the Each Attribute and the End Entity sets within Each Entity. The Each Relation set contains the same structure as the Each Attribute set. The only change is that the error codes are set for relation pass or fail nor for attribute pass or fail.
This model shows that for each entity all the attribute checking is performed including any data conversions, validity, and reasonable edits. Following the attribute checking all the relation checking is done regardless of what happened during the attribute checking. The relation checking includes any calculation, validity, and reasonable edits. After the relations are edited, End entity is processed the same as it was in the basic edit model.
The mandatory relation edit model is used when there are relations to be edited, and when the errors need to be identified and corrected as early as possible. By performing all the edits all the errors will be listed, however, there is the chance for multiple or redundant errors to be listed.
The mandatory relation edit model will lead to unnecessary processing, particularity for data with a high error rate on attributes involved in the relation edit. It will also lead to unnecessary user time to review all the errors. However, the objective is to catch all the errors at the earliest time.
The third edit model edits relations only when all attributes have been edited within an entity, an all the attributes pass the edit. In other words, the entity must be in pass status before any relation editing is done. Figure 3 shows the entity pass relation edit model structure.. It is the same as the mandatory relation edit model except that Each Relation set is moved one level lower in the structure and an inclusive alternative set is inserted. This alternative set checks if the entity is in pass status, and if it is then the relations are edited. If not, the relations are not edited.
This edit model lists only true relation errors and minimized both processing time and user time to review and correct the errors. However, it may increase the elapsed time to correct the errors. The model is generally used for data with many errors and many relations, particularily when there is not hurry to correct the data.
The last of the general edit models checks relations only when the attributes involved in the relation pass their edits. The status of other attributes not involved in the relation have no meaning on the relation edit, nor does the status of the entity. Figure 4 shows the attribute pass relation edit model structure. It is the same as the mandatory relation edit model except that the Each Criteria set with Each Relation is moved one level lower in the structure and is prefixed with an inclusive alternative set checking if the attributes involved in the relation are in pass status. If all attributes are in pass status then the relation is edited.
This model is a compromise between the last two models. It is used to find all true errors at the earliest possible time. However, the risk is wasted processing time for data with very few errors and for data with numerous errors. The user time is minimized since only true errors are listed.
If the data contained very few errors, then the checking of the status of each attribute involved in the relation would be unnecessary and the mandatory relation edit model could be used. If the data contained numerous errors, particularily on attributes involved in the relations, then processing time would be wasted performing checks on attribute status most of which failed. The entity pass relation edit model would be the best in this instance.
Therefore the attribute pass relation edit model is used when there are a moderate amount of errors on attributes involved in relation edits, when user time is to be minimized, and when errors are to be corrected at the earliest time.
Michael Brackett
Dept. of Fisheries
Association Minutes of Data Processing Managers, August 7, 1980
Mr. Jim Brinker, Staff and Research Director of the Senate Research Center, was our guest speaker. His topic was "The Public Policy Processes".
He noted that the legislative environment is not a neat and tidy place. The real world within which public policy is developed is so loosely structured that some would say it defies description. The legislative process has two "tracks" in which to view the development of public policy:
The "Hows" of the legislative process deal with real politics, as well as legal procedures. A critical element for both processes is information. Mr. Bricker pointed out that his pet bias is the Rational Model, or as he called it, "Closeted Research", for planning use as problem—solving. The impression that the research process proceeds and produces solutions for problems is counter productive in the political environment. Emphasizing the theme that the legislative environment is an untidy place reflects the inappropriateness of the rational planning system for the legislative stage. The rational model would have an issue viewed comprehensively rather than selectively. An oversimplification -- if you follow the rational planning model to its ultimate you are denying your own form of government.
The political model would require just the opposite. The comprehensive political approach tries to address the fundamental problem, as well as all corollary issues. For influence, information generation is the basic problem of such an approach, for it is beyond the control of the affected agencies and clientele groups.
If a legislator votes "NO", it may not have anything to do with your (planning) product, but a constituent or personal issue. However, from Mr. Bricker's point of view, most decisions are made based on information made available by rational planning systems. Mr. Bricker pointed out that another institutional research model not productive within the legislative environment is derived from traditional management theory and may be labeled "three evil E's": economy, efficiency, and effectiveness.
The suggestion was made that the first two E's have no place in the legislature. They come close to contradicting the legislative process itself. They are tied to the assumption that the corporate model of systems technology can be applied to legislatures. When applied to the legislature, preoccupation with notions of economy and efficiency gives rise to news articles about the inadequacy of a legislature which met for 110 days and passed only 20 bills. In this equation, no room has been left for strategic leeway, deliberation, and even defeat of certain proposals. Defeating issues may well be equally, if not more, significant than the passage of legislation in serving the public's needs. Carrying the economy and efficiency model to its extreme would eliminate the fundamental give and take of the representative form of government.
As to effectiveness, it does apply to the first "track," procedure applications, if you put effectiveness in the political sense such as computer supported information and systems. However, it is a value judgment. What is a "good" bill to me, may be a "bad" bill to you.
Mr. Bricker cited from Alan Toffler's article entitled The Third Wave. His thesis is that this complex society has outgrown our political system's ability to deal with it, and needs to be restructured. He cites need for change in decision making systems. The ability to produce mass information can affect decision making. In that the American political system information flow processes is channeled in a "vertical hopper"; i.e., Agricultural committees (made up from rural area representatives) handle agriculture legislation. In Washington State, we are also looking at it from a horizontal point of view through Legislative Information System and LEAP (Legislative Evaluation and Accountability Program).
Several informational documents, computer produced, were presented by Mr. Bricker, which are used extensively by the legislature and individual legislators. One document was the State Sheet which tracks the status of some 3,000 bills. Prior to 1971, the status of legislation was updated manually. The ability to know the status of legislation is exceedingly important. A second document presented was a typical Senate floor calendar, which includes the legislation digest and analysis is "the bill digest". It is drafted by an attorney who is not familiar with the history or the purpose of the bilk The digest tells you what the bill does. The "analysis" is added by committee staff and updated each step of the legislative process. It states the issue being addressed, and the effects of the bill, if enacted. The analysis of bills has greatly enhanced the legislators. They are able to read what the bill actually is trying to accomplish. It is more difficult for a special interest group to control the legislation.
There is better information; therefore, there is better legislation, which is better for the public. However, if management effectiveness is one of your concerns and you measure that in terms of time, there may be less effectiveness because it takes longer to pass a bill. Availability of information slows down the process.
Out of the legislative information system comes a final report which is basically the "legislative analysis". This includes the vote of the legislature and cites the law reference. The report is produced in four working days following the close of a session.
Following some questions from the audience, Jim concluded with a cute story about a Peanuts cartoon. "Charlie Brown, Lucy, and Linus were lying on a knoll watching the clouds. In response to Lucy's question of what they see in the clouds, Linus goes on at great length about Beethoven, a map of the Caribbean, the stoning of Stephen, and so forth. Looking perplexed as always, Charlie meekly acknowledges that he was going to say that he saw duckie and horsie, but changed his mind,"
Bricker suggested that if Charlie Brown were viewing the legislative environment, he might well be closer to the truth than Linus. People see different things in the clouds.
Approval of Minutes
The minutes were approved with the exception of a misspelling of Dr. Reuben Marti's name.
Treasurer's Report
Due to Bob Purcell being on vacation, there was no treasurer's report.
DPA Announcement
In July, another committee began review of the DPA's acquisition standards with Jim Michal of the DPA staff coordinating the effort. This group is focusing on the objectives stated in the DPA's Long-Range Strategy Plan for more flexibility in delegations, and for modified dollar approval criteria for agency, staff, and Board actions.
Updating Acquisition Policies/Standards
Jim Michal has scheduled the third meeting for August 15 to discuss the proposed changes to pertinent acquisition policies and standards.
Uniform Service Center Budgeting and Accounting
During July, a committee consisting mainly of Service Center fiscal officers began meeting with staff member Ted Nelson to review and update the Service Center Financial Operations and Chart of Accounts Standards. They will also be tackling the issue of DPA/User rate approval procedures, which was the subject in both a recent DPA meeting and in the DPA's April 1980 Strategic Plan.
Systems Development Standards Committee
A committee, chaired by John Flanagan, has been formed of representative groups from the data processing community to review and update the systems development standard. They have had three meetings and hope to have a model standard ready for review at the ADPM Planning Conference. A key element of this review and revision will be the incorporation of appropriate feasibility study/post-implementation review mechanisms, as directed in the Authority's "Long-Range Strategy Plan".
Managers' Matrix
Ron Pierce reflected back to the first meeting of the job matrix, which was December 5, 1973, and what has taken place to the present--the frustrations and accomplishments. Once again, Tim Seth was acknowledged for his contribution. Association of Data Processing Managers Planning Session.
On September 9 and 10, the State Association of Data Processing Managers (ADPM) will hold a two-day planning session, similar in format to that held by the DPA last November. Dr. Hollister will deliver the keynote address at the conference. Since a set of four subcommittees will address a full range of "DPA Issues," a number of the DPA staff will participate in order to provide resource information on the issues.
Statewide Communications Study
The Statewide Communications Study effort has turned out to be as far—reaching and complex as originally visualized, and managing the scope of the effort is proving a challenge. Because of the State's fiscal austerity program, the challenge of the study is to propose alternatives to the current environment which are cheaper, quite apart from service improvements and productivity aids, which may provide more cost—benefit, but which would require increased expenditures. A status report will be presented by John Flanagan of the DPA staff at the September meeting.
Forum -- October 22 & 23, 1980 -- Vance Tyee
The determination was made there would be guest speakers and vendor presentations, with office automation being the main theme. The guest speakers will be arranged by E. A. Hansell and the vendors will be arranged by Joe Coogan. No hardware will be displayed. The announcement of details and the brochure will be mailed out by the second week in September.
Office Automation Technical Committee
This Committee meets every Thursday at 8:00 a.m, in the General Administration Building Second Floor Purchasing Division Conference Room. The Committee is drafting a written procedure for agencies to ultimately follow while acquiring office automation hardware and software, to be reviewed by the Division of Purchasing in early September. The Committee members consist of Dick Conant, Chairman, Employment Security, Carolyn Greer- Inghram, DSHS; Joseph Coogan, DPA; Wayne Hemphill, General Administration; and Fred Crow, DOT.
Job Matrix for Managers
Tim Seth stated he was holding an armchair review with the individual agencies, to resolve differences of opinion, with the department representatives and personnel people. For those individuals affected, personal letters would be sent on August 15, 1980.
On September 2 there will be a meeting to review and hear what will be on the two-day notice for the newly proposed computer operation series. Mr. Seth would welcome anyone from the Association who would wish to be present.
Association of Data Processing
Managers
Meeting Agenda
Sebastians
September 4, 1980
12:00 Noon