I am curious, what is your role in the CMS deployment? Who is "we"? Getting to your issue, several things come to mind.
First, the trade-off between business flexibility vs. data security should be a part of the business requirements.
Is there a (systems) security officer? It is common for larger outfits to have a person dedicated to the role of vetting who should have which access rights to which systems. Historically, this role is nominally a part of systems, but is effectively a business liason.
If there are multiple business units, Systems can play a legitimate role in facilitating (not dictating) mutual access rules. In the end, who can see and do what is a business decision.
Good reasons for having systems folks do this include integration with existing support (i.e. you can call up the help line), backup personnel, shared credentials (corporate single sign-on), administrator training (these guys already know the basics), they are probably already giving hardware and other support, network/Internet support (they are usually involved in getting data through the firewall onto public websites).
Good reasons for maintaining "local" control include lack of Systems resources, lack of Systems knowledge, unsupported application/system. Often, these deficiencies can be overcome by negotiating a dedicated support person for the department/application who will acquire the needed skills. Sometimes a consultant can help to ramp up.
A CMS will sometimes distinguish between core admin functions and "librarian" functions. Core admin functions would be collection creation and replication parameters. Librarian functions would be metadata tag definition and requirements-per-collection. Sometimes, certain admin functions may be delegated. E.g. Mary Sue is the admin for the Marketing collection, Joe is the admin for the HR collection. This might mean they can add designate existing users as authors, reviewers and editors for a collection. Usually, adding new users remains a core function.
I cannot give you specifics for Stellent, but you can get those from the manual or Stellent support. Sometimes it is a question of asking the right question. Bottom line, you might avoid a corporate battle by asking questions and shifting the focus to the business requirements.
hth,
Charles Reitzel
On 11/13/2002, [EMAIL PROTECTED] wrote:
My company is about to install Stellent. We're in the process of mapping out roles and responsibilities for use of the tool. My area is the web programming area. We create all of our corporate web sites. It's our opinion that we should have the role of creating content workflows within the system. But our server administration area believes their role should be to create workflows. For anyone who is on the development end of websites, it, of course, seems silly that server admins would be involved in a business process they are so far removed from. But it is becoming a very huge battle.
So I'm looking for any documentation on workflow best practices, or just general best practices for CMS roles and responsibilities. (We feel we should have admin rights, but our server area wants to control that role.)
If anyone knows a URL, has some documentation, or has old war wounds, I would love to hear from you.
Thanks in advance.
Holly Boelter
-- http://cms-list.org/ trim your replies for good karma.
