| |
Reference Model for Dynamic
Networked Organisations:The deliverable "Reference Model for Dynamic
Networked Organisations" shows in general the complexity of the generation
of a reference model. Normally the process of developing a comprehensive
reference model needs a lot of time. However, a reference model for dynamic
networked organisations is generated which is able to improve the understanding
of projects within the agency and consultancy sector. The DyNO reference
model consists of four levels as it is described in the following picture.
The first level contains the business phases necessary for carrying out
agency/consultancy projects, the second level and the third level contain
business processes and business sub-processes. The forth level describes
the activity of an element within the business sub-process. The interrelation
between these levels can be described by the principle of classic hierarchical
process decomposition. Six identified phases document the structure of the
business processes within a virtual organisation as depicted in thhe following
figure.
Furthermore, the roles and functions respectively such as project manager,
main contractor, customer, supplier/partner are also depicted. The first
level of the reference model can be described through the phases consulting,
conception, production, control, realisation and service & maintenance which
show the sequence of typical DyNO projects on a general level. In order
to enable an appropriate use and management of the phases they should be
accompanied by supporting activities. Four supporting activities have been
identified which support the carrying out of agency/consultancy projects.
These are integration and communications management, quality management,
resource management and administration management. However, the six phases
and the related processes and sub-processes have some activities and tasks
which could overlap. The generation of generalised business sub-processes
was more difficult than the generation of generalised main processes. |
|
Because sub-processes provide a
detailed view of a business process element. Hence the complexity of such
models increases. All processes have to be valid for all involved partners
coming from both the agency and consultancy sector. However, this succeeded
through a close look at internal processes. The developed business processes
can be further detailed into business sub-processes and activity descriptions.
There are a lot of sub-processes identifiable. They provide a closer look
at the process and the activities within that process. However, not all
business process elements are divided into different sub-processes. It makes
no sense to provide a detail view of the business process if the process
itself is very simple and self-explanatory. In order to minimise the complexity
and amount of available sub-processes six of them will be described. These
have been identified within the deliverable D3 "Consolidated DYNOCA
end user requirements". Reference Model for Modular Software Systems
for Support:The general functionality and architecture necessary for
a system which is able to support agency and consultancy projects is illustrated
within the deliverable "Reference Model for Modular Software Systems
for Support". The DyNO (dynamic networked organisation) system which
will be developed by the DYNOCA consortium is able to support activities
and tasks necessary to carry out agency/consultancy projects for example
intelligent data sharing. These are described by the business process models
developed within D4 (Reference Model for Dynamic Networked Organisation).
Some process and sub-process elements are indeed worthwhile to be supported
by the DyNO system. Unfortunately, due to the generic view of the developed
business models it is not possible to cover the whole models within that
system. However, the DyNO system will be able to improve the communication
and co-ordination effort for agency/consultancy projects through the use
of advanced JAVA and XML technologies. The DyNO system architecture consists
of five layers as depicted below which will be used in order to ensure an
appropriate decomposition of functionality.
The user layer deals with the interface to the user (well known browser
functionality), the content presentation layers uses the HTML code for interpretation,
the server layer consists of different components (e.g. operating system,
web server, JSP engine), the business logic layer is responsible for handling
JavaBeans and JavaApplets and the data management layer enables the connection
to internal or external databases via RDBMS. |
|
The architecture follows the client/server
principle as depicted in the following.
Different user clients communicate with the server over the Internet
by using a browser. They have secure access to the database and the services
which the server offer. The safety of the connection is realised by using
user IDs with passwords and secure transactions over SSL connections. The
client should possess at least an email client and a browser. These are
necessary to use the system. The server contains different components necessary
for enabling the different system functionality as described in the picture
below.
The file transmission service deals mainly with the up- and download of
objects / files. The real-time communication service performs all tasks
necessary for a proper internal and external communication within the system.
The event mail service is responsible for the notification of the users
if changes occur. The notification will be sent at least to the default
email address of the user. The business logic module deals with JavaBeans
and JavaApplets handling. The database integration service provides access
to internal and external databases. Pilot Scenario Definition:The
DYNOCA Project consortium defined for both end users of the project a typical
pilot scenario with respect to their core business.The pilot scenario for
the consultancy sector is based on the business process "Consortium Agreement
Development" within a consortium of companies working in an European project.
This is an interactive process involving all project partners exchanging
a lot of information and administrative data. This kind of process is similar
to other documents that have to be produced by a consortium during an European
project lifetime like the ÒDissemination and use planÓ and others.This pilot
scenario for the agency sector covers the business process "content development"
within the company Berlin Information Group (BIG).This process deals with
data flow - contracting and collecting data - from freelancers to publishing
on the web. BIG is an independent company specializing in the collecting,
organising, and publishing of content in English, relevant to an international
public, about the city of Berlin and other European cities. The core of
the business is the content development, which uses freelancers and external
content partners to generate or deliver content, as well as to edit content.
The scenario we are looking at is the online product berlinfo.com and the
role of BIG as producer. The project berlinfo.com divides into main sub-projects:
content, technology, marketing, ad sales, design, administration, whereby
the strongest level of interdependencies exists between content, technology,
and marketing. |
|
