Difference between revisions of "Talk:Set up a new organisation"
(move to main, refine there) |
(section on roles of org system, begin with crm) |
||
| Line 1: | Line 1: | ||
This is some text I started in response to initial Athens requirements | This is some text I started in response to initial Athens requirements | ||
| − | + | == Roles of the organisational system == | |
| + | === CRM === | ||
| + | Customer relationship management will be a required role for any organisational system. We believe that Mediawiki can fill this role with a few extensions such as listview installed. CRM will allow the following functionality, so let's think about how we could go about providing it: | ||
| + | *Import contacts into the system in csv format, sometimes also outlook contacts, gmail, etc | ||
| + | *Display lists of contacts which can be filtered and mass-updated | ||
| + | *Set up new forms, web-based lead gathering forms | ||
| + | *Scheduled events | ||
| + | *Strong workflow orientation, leads are categorised and given to roles based on category. | ||
| + | *Permissions based on roles | ||
| + | *Email campaigns: Send information to a specific group of contacts and track responses in the CRM system | ||
| + | CRM software generally also has one or more of the following weaknesses: | ||
| + | *Either expensive to set up or too complicated, difficult to customise and maintain. | ||
| + | *Dependence and privacy issues with hosted solutions, giving your vital data to a faceless corporate with unknown goals and values | ||
| + | *Performance-hungry | ||
| + | *Very poor at handling documents or web content | ||
| + | *Poorly-integrated email function | ||
| + | *No proper integration of accounts, invoicing or warehousing (resource management) | ||
| + | There has been some research done on Organic Design which may be useful for this discussion" | ||
| + | *[[CRM]] | ||
| + | *[[SugarCRM]] | ||
| + | *[[Milan/28 April 2007]] | ||
== Data Structure == | == Data Structure == | ||
Revision as of 11:36, 18 June 2008
This is some text I started in response to initial Athens requirements
Contents
Roles of the organisational system
CRM
Customer relationship management will be a required role for any organisational system. We believe that Mediawiki can fill this role with a few extensions such as listview installed. CRM will allow the following functionality, so let's think about how we could go about providing it:
- Import contacts into the system in csv format, sometimes also outlook contacts, gmail, etc
- Display lists of contacts which can be filtered and mass-updated
- Set up new forms, web-based lead gathering forms
- Scheduled events
- Strong workflow orientation, leads are categorised and given to roles based on category.
- Permissions based on roles
- Email campaigns: Send information to a specific group of contacts and track responses in the CRM system
CRM software generally also has one or more of the following weaknesses:
- Either expensive to set up or too complicated, difficult to customise and maintain.
- Dependence and privacy issues with hosted solutions, giving your vital data to a faceless corporate with unknown goals and values
- Performance-hungry
- Very poor at handling documents or web content
- Poorly-integrated email function
- No proper integration of accounts, invoicing or warehousing (resource management)
There has been some research done on Organic Design which may be useful for this discussion"
Data Structure
Security & Spaces
Currently MediaWiki is not good at preventing view access to articles even using current extensions, so the safest way to handle this requirement out-of-the-box is to separate the articles exhibiting restricted view access to their own namespace.
Another solution which I'm currently working on is Security 4 which uses a database hook to allow restriction of access at a low-level. Basically it extends the inherent MediaWiki page protection mechanism to restrict access to page content or just to page source if preferred.
The new method is better because it can be applied to any article regardless of namespace and access is restricted on the proper user-groups basis.
Portals (a.k.a workspaces) are single points of access for specific sub-groups of the organisation. Such sub-groups could be departments, roles, resources or knowledge, see Wikipedia:Enterprise portal. In the wiki, all these concepts would already have a corresponding articles since the first step in setting up is to map all the concepts as articles, templates and properties. So some of these concepts will gain heavy use as a "one stop shop" for all current information about it.
In wiki's red "creation links" are extremely useful for allowing users to create new articles which form part of the organisations formal structure but without needed to know what to put in the new page. For example, a red link can be added to a portal which when clicked would create a new article representing a certain kind of job. The new article would be named according to convention (e.g. ("Gardening job 00156", or "Order:2008-06-11-0001"), and the newly created article can contain preloaded content, or take the user to a form to fill in semantic properties by.
The following is a list of some general possibilities to take into account when establishing a portals in the wiki:
- Page design and elements can have their own CSS rules depending on the current user, group, space or page etc
- The tree in the sidebar can exhibit content specialised for the current user, group, space or page
- SMW allows portals to contain dynamic lists of articles. Such queries can select lists of articles based on what categories they may or may not be members of, and by what semantic properties they exhibit.
- Portals often contain forums, chat rooms and links to other specific resources and tools.
Multi Language
Content can be made conditional based on the current users language preference. This allows templates to be defined with content in multiple langauges, or for other language version of articles to be defined in subpages for example Title/en.
