Information Technology Reference
In-Depth Information
•
The
unit decision process
of the organiza-
tional domain
use the acronym DM for someone in charge of
taking decisions and responsible for the decisions
taken. Irrespectively of being or not DMs, every
people are considered potential contributors to
the stream of decisions that the UDP outputs. The
status of DMs must of course be acknowledged in
a UDP as those people who actually take decisions.
A DM may decide alone, in which case he sim-
ply declares the decision taken through the UDP.
If a DM finds useful to get inputs or contributions
from other people in the domain then she raises
an
issue
. Raising an issue activates support for
conversation upon which the decision is taken.
The concept of issues may be applied to both
cases: a DM deciding alone, may be considered
a special case of an issue having been raised and
decided without a conversation process. From
this point of view, a UDP is composed by issues
leading to decisions.
There is no reason for issues being only raised
by DMs. If any person in the organizational do-
main can raise issues, another potential benefit
of a CODSS may arise in that issues that would
escape DMs attention are caught by the UDP and
adequately dealt with.
•
The
compound decision process
of the or-
ganizational domain
The unit decision process (UDP) of
Y
is the
software supporting the top-level conversational
decision process ultimately responsible for the
conduction of
Y
. People responsible for
Y
as a
whole are inherently in charge of creating, main-
taining and improving this top-level conversa-
tional decision process and they will get support
for it from the UDP of
Y
.
Let us assume now that organizational domain
Y
includes other organizational domains
X
1
,
X
2
,
…,
X
n
. The compound decision process (CDP)
of
Y
is the software structure composed by the
UDP of
Y
, the UDPs of
X
1
,
X
2
, …,
X
n
and their
connections. In the following, more details are
given about these concepts.
unit decision processes
One assumes now that a CODSS has been imple-
mented and is used in an organization. Under this
condition, one will identify a sub-organization
with its representation through the concept of
organizational domain. Likewise, one will identify
conversational decision processes in the sub-
organization with the UDP and CDP supporting
them. The rationale for this is if a CODSS is
implemented and used, the support it provides to
conversational decision processes becomes inte-
grated in these. Furthermore, the conversational
decision processes will be changed, as many other
human interaction processes have been changed
by the utilization of computers. It becomes easier
to refer to the potentially emerging reality in terms
of organizational domains, UDPs and CDPs, as
these concepts provide a higher level of abstrac-
tion with a consequent wider field of application.
Inside a domain some people will be in charge
of taking decisions, some will not. For short, I will
formalism for supporting
unit decision processes
One presents now a formal analysis of the deci-
sion process to make more precise the support and
advantages that a CODSS can make available to
decision processes with conversations. The analy-
sis enlarges and details the sketch given in the
introductory section. The formalism is a classical
one, with elements from Simon (1976), Newell
and Simon (1972). It is presented as a possible
example to base implementations.
Let us consider a DM taking a decision alone.
To decide, the DM disposes of a set of perceptions
P
1
. This set encompasses, necessarily, perceptions
about the environment or state of affairs
S
1
that
does not meet some reference criteria
R
1
. The is-
sue of taking a decision is raised in first place by
Search WWH ::
Custom Search