In the planning and implementation phase of the information system, some needs from the user’s organization will most probably arise. These needs have to be studied and clarified carefully to create a reasonable solution, which serves the interest of the user’s organization.
9.1 Needs
During this work I have studied the basic needs of the user’s organization in a large scale, so more specific development needs for the system could arise dur-ing the system usage when the users become acquainted with the system. Next there are shortly summarised the main needs which have been noticed during the work. I have also recommended some options to handle different needs with the system. During the system implementation, these needs have to be ob-served and reasonable solutions or procedures to handle these cases with the system have to be terminated.
Documents from Andritz’ system to the customer’s system
Document transfer from Andritz’ own document management system to the cus-tomer’s system should be studied and transfer methods should be united. Dif-ferent possibilities to handle the transfer are considered in chapter 8.3.4.
Document access rights
Nowadays document access rights for a specific document are managed by the document creator, which is on the other hand a good thing because the ment creator knows best the content of the document. At the same time docu-ment creator doesn’t necessarily know if some other users for example in differ-ent business unit need the documdiffer-ent. The documdiffer-ent can be stored in the ar-chive without usage or can be created again when the other users don’t know that document has been already created. Also when the document creator has
to take care of the access rights there is one more task to perform. If the creator doesn’t know who will need the document, he or she must clarify it. These “ex-tra” tasks can cause resistance to the system usage.
The quality of the documents, which are created into the system, will automati-cally improve because the system guides to use document templates and when the system is commonly used and the users don’t want to put unfinished docu-ments to it. If the access rights are defined as fixed default to users, this could become a threshold for the user. Users consider the system as “monitoring de-vice” which is used to monitor the quality of their documents.
A solution to this can be default access rights, which can be changed. Users are usually working with the same workgroup and the documents are usually crea-ted for this group. So the access rights can be set as a default for this group and can be changed by the user if needed. In this situation the user doesn’t have to define access rights separately for all documents because they are a default. These access right groups have to be defined exactly, in cooperation with the users.
DMS linking to other systems
Linking of important service systems to DMS, for example Installed Base Mac-hine Chart system is needed to link with DMS in a defined scope, chapter 7.3.2.
This facilitates lifecycle information collection from the equipment.
Rules for document transfer
Common rules and practices for transfer of different document versions from sales to delivery (As-Sold) and delivery to customer and service (As-Built) has to be developed. Also the direct transfer of “As-Built” material from Andritz’ own DMS to the customer’s system is important to study.
Picture form for service business
Service needs a place were digital photos, which are taken from equipment fail-ures and damages can be saved with a link to the equipment. The photos could be stored in the DMS via Installed Base Machine Chart system. This requires its own metadata form for digital pictures. The form can be created by modifying a picture form, which is already used in Graz Austria. Before this is done, the de-tailed office document form can be used as digital photo metadata form. More about this in chapter Digital photos in page 83.
Updates to document metadata definitions
For the service business some additions to document metadata definitions are needed. For example document statuses “As-Sold”, “As-Built” and “As-Is” are needed. These have to be inserted into metadata document statuses. Other needs may arise during the implementation.
Documents from subsuppliers
One coming development need will be the transfer of subsuppliers documents to Andritz’ system. Andritz uses several different subsuppliers for manufactur-ing, engineering and service operations. These suppliers document their prod-ucts and transfer these documents to Andritz. These documents are also needed in Andritz DMS so in the future practices for this transfer are needed to develop.
Clear rules how to use DMS
Clear rules for DMS usage are needed. If rules are missing, employees easily keep old traditions. For example, when the DMS is implemented, document savings in old local servers, which have been used as document repositories, could be prevented.
9.2 Possible problems in implementation
Some problems can arise in implementation stage. In this project these can be for example:
• System servers are in Hollola, which will decelerate the connection to DMS.
• The system can be too complicated to use by some users.
• There is no other language versions available than English.
• The system is considered a monitoring device.
• Does the usage bring documents available for right users or are the documents saved usually with too limited access rights?
• System benefits cannot be seen or reached. Users don’t understand the benefits of the system to other users, or the documents are saved with too limited access rights and distributed like earlier. This makes the sys-tem almost useless.
To avoid problems in DMS usage, all system users must be well trained to use the system; also the benefits of the system must be clarified to users. A clear statement about system implementation from business managers is also needed to clarify the situation.