| |||
| | | |
| |
CMS-implementation II: descriptionof the workflow through rights and roles
A lot of online editorial offices work with a similar role concept which, however, often is only supported insufficiently through the applied publication system. At the introduction of a CMS these role concepts have to be reconsidered and frequently additional roles are identified, which can improve the editorial processes. A definition of the roles should always be made on the basis of an existing process description and adapt itself to the distribution of individual working steps. From a technical view roles are classifications of users, through the assignment of which the users are granted certain rights. In addition to this, a role also determines the position of the user within a workflow. There is also often the requirement that a user is to be assigned to several roles. First of all, roles should be defined on the basis of the previous process description, which are indispensable for the editorial operation. These typical roles are, for example, chief of service, editor, author, external author, picture editor, graphic artist/ HTML-editor, portal manager. In this, each editorial office uses different terms of roles, which however often are connected with similar tasks. Each role should be described on the basis of its tasks in the editorial process. In this it also has to be clarified if, for example, an editor has to be distinguished from an author or if the tasks of a picture editor and a graphic artist cannot be depicted in a common role. In addition to the above mentioned roles further roles, like for example, planner, audio/ video editor, teaser manager, documentalist, archivist or supplier/ investigator can be important, in particular in large online editorial offices. However, basically you should not try to make the whole thing more complicated than it is. Roles only make sense if they can be administrated in a simple way during the later operation and if they are really important for the implementation of the workflow. One should also think about a possibly necessary regulation of deputy at the definition of roles. Editorial offices which, for example, only work with one chief of service, who is responsible for the release of all contents, need such a regulation just in case. Within the context of the role definition one should also make a definition of groups if this is possible with the selected CMS. Some content management systems equate roles and groups, others can differentiate here. Thus, for example, groups can be determined on the basis of access to certain areas of a portal (for example, depending on categories like news, economy or sports. For example, a utilisation of groups can be very helpful if you want to allocate a contract to a certain role within a group. An example would be the allocation of an article contract through the chief of service to the authors (roles), which are responsible for the category sports (group). Rights The target of a role and right definition is to create a set of rules and regulations of authorisations and to facilitate their effective assignment to users or roles. At the end it should be clear who may do what within the editorial process and who is responsible for what. Following the procedure at the process description of the individual object types also the rights can be classified. They can be distinguished, for example, in contract rights, process rights, publication rights and administrative rights. Normally rights refer to individual object types. For example, if the right "draw up article" is not assigned to a user, he does not get access to the "article entry template" in the backend of the CMS. On the basis of the above mentioned classification the individual rights can be determined. Contract rights, for example, are the right to draw up an object contract in the system or the right for "self contract" (if for example, an editor draws up an article contract for himself and afterwards writes the article himself). The process rights should include all relevant object types. Process rights are, for example, authorisations to write articles, draw up urgent messages, insert pictures, insert files, insert audio/ video objects, draw up teasers, integrate external applications, draw up forums, draw up votings, draw up chats, draw up newsletters, change objects or delete objects. Examples for publication rights are the rights for the release ("insert life") or the withdrawal of objects, for the teaser administration or the additional linking of objects. From the administrative view, apart from the authorisation to administrate users also the administration of objects is important, like for example, the administration/ maintenance of forums and chats. Allocation of roles and rights After having determined the roles and the necessary rights, the individual rights are allocated to the determined roles. Thus, later through the allocation of a role all rights, which the corresponding role includes, can be allocated to a user. The allocation of roles and rights can be carried out on the basis of a matrix, which could be like the following (here only some selected roles and rights are listed as an example):  Table: role and right matrix
Allocation of roles and working steps In order to have a sound information basis for the definition of workflow now the determined roles can be allocated to the individual working steps from the process definition of the object types. Here one also should begin with the article. On a basis of a table the roles can clearly be allocated to the working steps. Basically for each working step the question is asked who is allowed to carry out this working step in the editorial process. In case of an article, for example, it has to be clarified who can draw up an article contract, who can write an article, who can check written articles, who releases articles, who revises articles etc. This role allocation should be carried our for all workflow-relevant object types. At the allocation there are frequently new requirements or also new ideas for additional roles. Therefore the whole process should offer the possibility to repeat previous stages and to reconsider the results at any time. A strategic procedure cannot meet the complex requirements of the editorial processes. Workflows The previous results for the specification of the workflow should be taken into consideration, so that the whole work was worth while and the use of workflows really makes the editorial work easier. Basically an own workflow can be defined for each object. Also here you should ask yourself the question if special workflows are necessary or if you can fulfil a large part of the requirements of different objects by means of a standard workflow. Of course, the larger implementation expenditure should not be forgotten, which the use of object-specific workflows implies. From an editorial view, some advantages can be realised through the use of workflows. These are, for example, the standardisation of the processes mentioned at the beginning and the safety at the publication ("four-eyes principle"). However, an increased standardisation often reduces flexibility, therefore it should not be forgotten to identify regulations of exception. This applies, for example, to urgent messages, which as a rule should not be subject to any own workflow. Also the mentioned self-contracting makes it possible to avoid the stipulated workflow on demand. In this case the steps for initialisation and approval are invalidated. This way, for example a chief in service could directly write an article through self-contracting and afterwards release it ("insert live") immediately himself. In the following some aspects are mentioned as an example, which from the view of an editorial office are important at the workflow definition for the daily work:
Since the role of a user determines his position in the workflow, it makes sense to outline the planned workflows and to position the participating roles correspondingly. In the case of the article this can be as follows:  Illustration: article workflow with role allocation (zoom)
Result The analysis and implementation of the editorial processes belongs to the elementary tasks at the implementation of a CMS. In order to master the chaos, which can befall you when you try to cope with this task, a structured procedure is recommended. At the definition of roles, rights and workflows you "should keep your feet on the ground" and only describe and implement the things, which are really necessary for the depiction of the wished processes. The task is to find the right way between standardisation and flexibility. Basically the editorial members should be intensively integrated in the whole process. They are the later users and know best where there is demand for modifications. At any case you should take the chance to actually improve the editorial processes by using a CMS and thus to be able to work more effectively. If at the end everybody is allowed to do anything and the voting is carried out per telephone or e-mail, one has definitely not used the full capacity of a content management system. 03/2004, Jörg Bretzke
| | | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| © 1999-2008 FEiG & PARTNER | Disclaimer | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |  |  | |  | |  | |  | |  | |  | |  | |  | |   |
|
| ||
| know how news events | |
| ||
| ||
| ||
| ||
|
