English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools annual

Global: Zendy Free Plan

Global: Zendy Tools monthly

Global: Zendy Plus monthly

“Lookingfor Answers” is an apt description of the sysfem administrafor’s preoccupatwn: with sysfern devebprnenf projecfs diminishing in number, how doyou adherefoa deparfmenf’s system development misswn when usersupporf needsgrow in scopeand wmplexity? As fhe university systems mature, are there information needsat the deparfmenf level which can provide opportunities for challenging projecfs of a smaller scope?Is fherea disfincf dividing line betweenthecomputing responsibilities of userdepartments and of fhesysfemsdevelopment group? Or, is fhe line ajlexible bounday which can accommodatechan~”ng needs? This paper, therefore,will be “lookingfir answers” fo fhesequestwns in order fo formulafe a sfrafegic direcfwn for Projecf Cost Accounting af fhe University of Washington. If is an exfension of fhe university’s Financial Accounting Sysfem,and allows departments fo frack fhtn”rexpenditures againsf projecfs using their cusfom failored “charf n&s~ Thegoal is a role for user support-m”thin the sysfemsdevelopment misswn, and growth opportunities for fhe sysfemsgroup through proactive contact m“th user departments. INTRODUCING THE PROBLEM AND THE PLAN In the movie ‘Wall Street”, Gordon Gekko (Michael Douglas) says to Bud Fox (Charlie Sheen) that “the most valuable commodity I know of is information ....” In the dazzling financial world of company takeovers and buyouts, and stock and bond manipulation, this certainly was true in the 1980’s. But the importance of information is not just limited to Wall Street, nor is the idea a product of Wall Street. For the data processing and information systems world, the idea that information is an asset with a direct impact on an organization’s economic future was elaborated by the Diebold Group in a two articles on “Information Resource Management” in INFOSYSTEMS in 1979. ofaccounts”. Since fhe sysfem is department speafi, the using deparfmenfs must lookafter their own specialized informatwn needs.Yef, fhe sysfem hasa university miwwn: to makeunnecessary “shadow bookkeeping” by university deparfmenfs. Thepaper will seekto dejine the mission of the systemsgroup supporting departmental accounting, delineafe shorf ferm and long ferm Since I am an historian by education and a systems analyst by trade, my interest in, and commitment to, the computing profession is due to this concept of information, rather than the product of a fascination with the technology that produces it. For me, information, and its availability to the staff of any organization, is the driving force. It is also the source of a dilemma. How do you adhere Permission fo copy w“fhouf f~ all or part of this maferial is granted prom”dedfhaf the copks are not mcde or disfribufed for direct commeraizl advantage, fheACM copyright noficeand the fitleof fhepublicafwn and ifs dafe appear,and notice is ~“ven thatcopyz”ngis by permission of the Associatwn of Computing Machinery, To cqpy otherwise, or to republish, requireii a fee andtor aped! permbaion. Copyright 1991 ACM 0-89791-454-6/91/0010/03.25...$1.50 to a systems development mission, and attend to the specialized information needs of users which evolve from the systems developed and the data they store? This user services problem is a practical one for me because I have always worked in administrative programming. Its mission has been systems development to cover the major areas of company or university operations. In private industry, systems development and user support were basic to my responsibilities. I performed both functions. It was the management belief that if you want information about, or data from, a system, you go to the person who built it and administers it you go to the source rather than drift through the chain of command of various support and systems groups. At the universities where I have work, however, a greater division of labor has manifested. The administrative systems group develops and maintains the batch and on-line systems. Others have a mission to provide specialized services related to those systems. They can include customer trainin& administrative support, academic computing support, information center and departmental systems personnel providing problem resolution, user training, data download and ad-hoc report writing expertise. With all these individuals, and their organizations playing a role on the periphery of administrative systems, finding harmony in systems development and user services was not something I wanted to deal with. Rather, I preferred to keep the two separated. The dividing line between the development and support missions became an issue for me when departmental promotions and personnel changes in Information Systems, the administrative programming department, left me in charge of the Project Cost Accounting (PCA) system at the University of Washington. I had handled the maintenance and production processing functions for the system. Now that the people with the longest association with PCA had moved on to new pm.itions in the university, I had to handle the administrative tasks as well. I welcomed this change in responsibilities. I would finally see the practical business side of the system, not just the technical code and nightly production processing. On the other hand, the system was mature and no new development was contemplated. My main task would remain maintenance unless I took cm specialized projects for the departments using PCA. But specialized projects came under the responsibility of the departments themselves, or would be the territory of Customer Support& Training, the Information Center, or Departmental Systems. Back to rnaintenance...what a dreadful thought. While maintenance of PCA did not seem like an asset to my professional aspirations, the system’s usefulness to its users seemed unquestioned. If I was going to administer it, support it, and even advocate for it, perhaps I needed a little more information about the system, and why it was built. What documentation I had was incomplete. Additional information came from Customer Support & Training and the Information Center. Together, these files gave mea better insight into the origins of the Project Cost Accounting system. Let me briefly sketch that background. I will then proceed to the benefits which would accrue in providing support for PCA, and conclude with my approach pursuing that support objective. THE SYSTEM AND ITS MISSION PCA is a subsystem of the Financial Accounting System (FAS) at the University of Washington. The mission of FAS was financial accountability using data classification categories appropriate to Washington state agenciex fund, appropriation, program, budget and account. By the time FAS was implemented in 1975, a design for a cost accounting system was also in progress. Its objective was to breakdown the financial data into categories more appropriate for project and program management at the departmental level. The cost accounting fields designed for this purpose were project, task and option. Cost data would be reported by project, rather than budget, because multiple projects may be funded by a single budget, or a single project maybe funded by several budgets. In essence, project accounting was independent of the budget, with the task and option codes designed to summarize financial tmmactimw acrow departmental project~. The development of cost accounting was not pursued beyond 1975 due to the need for other systems which could feed FAS with transactions containing the cost accounting codes. The need to implement cost accounting was reviewed again in 1981. The study concluded that the payroll and purchasing systems, then under development, must be finished first. This would free resources for 326 ● ACM SICUCCSXIX1991 o ● e * . ● ● ● . ● ● Q . ● ● * ● ● Looting for Answers the cost accounting project, and provide systems which could generate accounting transactions containing the cost accounting codes. By 1985 these systems were substantially in place and the proje,ct

Finding harmony in systems development and user services