Accounting Information Systems

1
Accounting Information Systems

• Session 2
• Chapters 9 4

2
A. System Software - Operating system
- Utility programs - Language
translation programs procedural
languages fourth generation languages
object-oriented programming languages
- Data management software
- Communications software
3
(No Transcript)
4
B. Applications Software - Transaction
processing software - Decision support
software - Expert systems
5
C. Object-Oriented Systems Illustration 9-6
6
(No Transcript)
7
Computer System Configurations A system
configuration describes how devices are combined
to support the applications used in the computer
system.
A. Teleprocessing Networks uses centrally
located processors Illustration 97
8
(No Transcript)
9
B. Distributed Networks - multiple processors
connected by data communication
links a. Advantages and disadvantages b. Distribut
ed data bases replicated or partitioned
10
C. Local Area Networks (LANs) may include
several workstations, a file server, a print
server, a communications server, and a hub.
11
D. Client-server computing clients end users of
computers servers processors that provide
services to clients
12
E. Intranets an implementation of internet
technology within a company extranet in
intranet that allows access to people outside the
company
13
Electronic Data InterchangeComputer-to-computer
transmission of the data contained on business
documents, such as invoices or purchase
orders. A. Benefits 1. savings in clerical
costs 2. lower inventory levels 3. avoids
carrying costs of excessive inventory 4. faster
response to changes in customer demand 5. better
customer service 6. increased sales
14
How EDI Works Two approaches 1. Two companies
computers communicate through another company, a
value added network. Illustration 98 2. Two
companies establish a private network between
their computers. Illustration 99
15
(No Transcript)
16
(No Transcript)
17
C. EDI Transactions D. Difficulties with
EDI 1. Controls - Control procedures that work
with paper documents dont affect EDI
transactions. 2. Companies using EDI must
establish standard data formats. Will XML
replace EDI?
18
Commerce on the Internet A. Internet Storefronts
sell to the public B. EDI over the Internet
transactions between companies
19
Document Flowchart
I . Understand a system before flowcharting it.
Interview users, developers, auditors, and
management, or have them fill out a
questionnaire read through a narrative
description of the system or walk through system
transactions. 2. Identify the entities to be
flowcharted, such as departments, job functions,
or external parties. Identify documents and
information flows in the system as well as the
activities or processes performed on the data.
(For example, when reading a description of the
system, the preparer could draw a box around the
entities, a circle around the documents, and a
line under the activities.)
20
3. When several entities, such as departments or
functions, need to be shown on a flowchart,
divide the flowchart into columns with a label
for each. Flowchart the activities of each entity
in its respective column. 4. Flowchart only the
normal flow of operations, making sure that all
procedures and processes are in the right order.
Identify exception procedures by using the
annotation symbol. 5. Design the flowchart so
that flow proceeds from top to bottom and from
left to right.
21
6. Give the flowchart a clear beginning and
ending. Designate where each document originated,
and show the final disposition of all documents
so there are no loose ends that leave the reader
dangling. 7. Use the standard flowcharting
symbols draw them with a template or a
computer. 8. Clearly label all symbols. Write a
description of the input, process, or output
inside the symbol. If the description will not
fit, use the annotation symbol. Print neatly,
rather than writing in freehand. 9. When using
multiple copies of a document, place document
numbers in the top right-hand corner of the
symbol. The document number should accompany the
symbol as it moves through the system.
22
10. Each manual processing symbol should have an
input and an output. Do not directly connect two
documents, except when moving from one column to
another. When a document is moved to another
column, show the document in both. 11. Use
on-page connectors to avoid flow lines that go
all over the page and make it look cluttered. Use
off-page connectors to move from one flowchart
page to another. Clearly label all connectors to
avoid confusion. 12. Use arrowheads on all flow
lines. Do not assume that the reader will know
the direction of the flow. 13. If a flowchart
cannot fit on a single page, clearly label the
pages 1 of 3, 2 of 3, and so on.
23
14. Show documents or reports first in the column
in which they are created. They can then be shown
moving to another column for further processing.
A manual process is not needed to show documents
being forwarded. 15. Show all data entered into
or retrieved from a computer file as passing
through a processing operation (a computer
program) first. 16. Use a line from the document
to a file to indicate that it is being filed. A
manual process is not needed to show a document
entering a file.
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
E-R diagram represents an entity with a rectangle
containing the entity s name. A line connecting
two rectangles represents a relationship between
two entities. At each end of the line a small
symbol shows the nature of the relationship. If
this symbol is a bar perpendicular to the line,
it means "only one." If the symbol is a crow's
foot, it means "one or more." Some modeling
conventions use a small circle next to the other
symbol to indicate the possibility of no
occurrence
33
(No Transcript)
34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
CINDY WAXER Special to The Globe and Mail It's
not often that you bear someone refer to an
all-expense paid sojourn in an exotic location as
"six months of hell." Yet that is precisely how
Michael Moore, a 32-year-old information
technology consultant based in Toronto, describes
a temporary, overseas assignment for which he was
recruited in late 1997. Approached by a company
specializing in the resale of information-technolo
gy services, Mr. Moore didn't hesitate. to sign
on the dotted fine. After all, the contract
stipulated that he would enjoy unlimited access
to emerging technologies while supplying the
company's enterprise-wide computer system with
Internet capabilities. "But when I got there, the
current production system was so poorly designed
that I couldn't even start to take advantage of
any of that new technology," he
complains. Instead, Mr. Moore, whose systems
development skill landed him the approximately
600-a-day contract, spent six months applying
Band-Aids to the system's faulty production
design. It was a remedial, routine task that,
according to Mr. Moore, could have easily been
performed by an operations manager for only 300
a day. Countless other IT consultants find
themselves living a similar outsourcing
nightmare, Misrepresentation of a project's
requirements, unreasonable delivery dates,
bloated project teams and politically charged
corporate cultures are all contributing to the
souring of client and IT consultant relations.
38
A late 1998 survey of IT contractors found that
63 per cent of respondents said that a company's
concern, for an IT consultant's needs have
decreased in the past two years. And 61 per cent
of respondents said that adequate job
descriptions are almost never provided by
clients, according to the survey sponsored by
Computer Action Inc., a Canadian IT contract
staffing firm. Outsourcing relationships
promise to increase a company's efficiency,
reduce costs, alleviate staff shortages and grant
access to world-class capabilities. So then why
do so many of them fail? 'There was a lot of
money burned not 10 million, but closer to,
well, put another zero on that," says Mr. Moore,
referring to yet another disastrous IT project.
In this case, it was a company that had insisted
on recruiting no less than 250 IT consultants to
ensure the completion of a single assignment.
It's a "bigger is better" philosophy that has
corporate executives convinced that the success
of a project is contingent on the size of its
team.
39
But more importantly, warn experts, the
philosophy is a telltale sign that too many of
today's hiring managers are better acquainted
with human resources practices than with systems
development requirements. After all, says Mr.
Moore, most IT professionals know that a small
team of highly specialized individuals is often
more efficient than an army of techies. What's
worse, many IT consultants claim, is that
managers lacking sufficient technical knowledge
often negotiate contracts bascd on unrealistic
assessments. of long term project costs,
unreasonable delivery dates and an absence of
contingency plans. Dianne Webber is the delivery
manager of Unisys Canada Inc., a provider of
information services and enterprise Class servers
that regularly recruits IT consultants. "A lot of
big projects have had risks unfold, bigger than
the planners have expected, which is why a lot of
companies haven't made big profits on technology
projects," she says.
40
In fact, outsourcing relationships predicated on
unrealistic project plans pose an enormous
financial risk to IT consultants as well.
According to a 1998 Dun Bradstreet Corp.
report, there are almost 150,000 outsourcing
firms in the United States alone. With
competition at an all-time high., an IT
consultant can't afford to invest time in a
project that is doomed to fail and blemish a
curriculum vitae. "When you go into an interview
with a prospective client. it's not just them
interviewing you for a specific skill set. You
want to interview them to make sure that what
they're hiring you for is the right fit. It works
both ways," says Nick Morvay, an IT consultant
with almost 15 years of industry 1experience who
works in Georgetown, Ont., near Toronto
41
Addendum

• Session 2

42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
(No Transcript)
47
Data Flow Diagram
1. Data flow diagrams, a graphical description of
the source and destination of data, how data
flows within an organization, the processes
performed on the data, and how data is
stored. 2. Document flowcharts, a graphical
description of the flow of documents and
information between departments or areas of
responsibility within an organization. 3. Computer
system flowcharts, a graphical description of
the relationship among the input, processing, and
output in an information system.
48
3. Determine System Boundaries. Determine what is
to be included and what is to be excluded from
the system. Include all relevant data elements in
the DFD, since anything excluded will not be
considered during system development. When in
doubt about whether to include data elements, do
so until a definitive decision can be made to
discard them. 4. Develop a Context Diagram. A
context diagram is a good way of depicting system
boundaries. It has the system of concern in a
circle in the middle of the diagram. The outside
entities the system interacts with directly are
in boxes on either side, connected by data flows
depicting the data passed between them. DFDs are
prepared, in successively more detail, to depict
how data flows in the system.
49
5. Identify Data Flows. Identify all data flows
entering or leaving the system's boundary
including where the data originates and its final
destination. Any significant movement of
information is usually a data How. All data flows
come from and go to either a transformation
process, a data store (file), or a data source or
destination. As each of these is identified, it
should be connected to the appropriate data flow.
Data flows can move in two directions this is
shown with a line with arrows on both ends 6.
Group Data Flows. A data flow can consist of one
or more pieces of datum data elements that
always flow together should be grouped together
and shown as one data flow until they are
separated. If the data elements do not always
flow together, they should be shown as two
separate data flows.
50
7. Identify Transformation Processes. Place a
circle wherever work is required to transform one
data flow into another. All transformation
processes should have one or more incoming and
outgoing data flows. 8. Group Transformation
Processes. Transformation processes that are
logically related or occur at the same time and
place should be grouped together. Never combine
unrelated items into a single transformation
process if data are not processed together or
are sometimes processed differently, separate
them.
51
9. identify All Files or Data Stores. Data is
stored temporarily or permanently in mo systems.
Each data repository and each data flow into and
out of it, should be identified. 10. Identify All
Data Sources and Destinations. All sources and
destinations of data should be identified and
included on the DFD. 11. Name All DFD Elements.
All DFD elements (except data flows into or out
of data stores the data store name is sufficient
for identification) should be given unique and
descriptive names representing what is known
about them. This makes a DFD easier to read and
understand and provides the reader with key
information. Naming data flows first forces the
developer to concentrate on 1 the all-important
data flows, rather than on the processes or
stores. Once data flows have been labeled, naming
the processes and data stores is usually easy,
since they typically take their names from the
data inflows or outflows. Choose active and
descriptive names, like "daily inventory update"
and "validate transaction," rather than "input
data or "update process.' Process names should
include action verbs such as update, edit,
prepare, reconcile, and record.
52
12. Subdivide the DFD. A cluttered DFD is hard to
read and understand. If you have more than five
to seven processes on a single page, then use
higher and lower-level DFDs. Decompose the
context diagram into high-level processes, and
then explode these high-level processes into
successively lower-level processes. 13. Give
Each Process a Sequential Number. In a completed
DFD, each process is given a sequential number
that helps readers move back and forth between
the different DFD levels. Data flows should only
go from lower-num6ered to higher numbered
processes. 14. Repeat the Process. DFD developers
must work through organization data flows several
times. Each subsequent pass helps refine the
diagram and identify the fine points. As you
refine the DFD, organize it so that it flows from
top to bottom and from left to right.
53
15. Prepare a Final Copy. Draw a final copy of
the DFD. Do not allow data flow lines to cross
over each other if necessary, repeat a data
store or destination to accomplish this. Place
the name of the DFD, the date prepared, and the
preparer's name on each page.
54
Differences Between DFDs and Flowcharts According
to a study by Kievit and Martin, data flow
diagrams and flowcharts are the two most
frequently used development and documentation
tools. Their study shows that 62.5 of
information professionals use DFDs and that 97.6
use flowcharts. Over 92 of users were satisfied
with the use of both DFDs and flowcharts and use
both. A number of differences separate DFDs and
systems flowcharts. First, a DFD emphasizes the
flow of data and what is happening in a system,
whereas a flowchart emphasizes the flow of
documents or records containing data. A program
flowchart emphasizes the flow of data as it is
processed by a computer.
55
A DFD represents the logical flow of data,
whereas a flowchart represents the physical flow
of data. The logical view of data is the way
users conceptually organize and understand the
relationships among data items. It shows what the
system does with data-where data originate and
are subsequently stored, the processes data
undergo, and what ultimately happens to the
processed data. The physical view refers to how,
where, and by whom data are physically arranged
and stored. It is concerned with the physical
aspects of the system, such as hardware,
software, data structure, storage media (disks,
tapes, etc.), and file organization. Second,
flowcharts are used primarily to document
existing systems, since they emphasize how data
are processed and stored. DFDs, in contrast, are
primarily used in the design of new systems and
do not concern themselves with the physical
devices used to process, store, and transform
data.
56
Enterprise resource planning (ERP) systems
integrate all aspects of a company's operations
with its traditional AIS. Thus, when the sales
force enters an order, the effect of the
transaction automatically flows to all affected
parts of the company. Inventory is updated,
production schedules are adjusted, and purchase
orders are initiated to acquire any needed raw
materials and supplies. The important point
underlying enterprise resource planning systems
is the need for and value of cross-functional
integration. Financial data must be linked to
other non financial operating data. This means
that the traditionally separate functions of
information systems and accounting need to become
much more closely connected. Indeed, many
organizations are beginning to combine these two
functions. For example, several universities have
recently merged their accounting and information
systems departments.