Talk:Set up a new organisation

genericize

shouldn't there be a more generic but thorough work order procedure? I propose the following, the method that andrew and i use at streamline

First and foremost

• Initial creation (or restructuring) of an organisation MUST include a comprehensive process of establishing shared values, visions and goals / desired outcomes.

All parties involved MUST spend the time to co-create this. We must further detail and create an easy to follow template - step by step (The Dummies Guide to .... principle)

Exit strategies for all parties at any given time must be considered and transitions (alternative templates)--Dana 18:44, 15 December 2008 (NZDT) available--Dana 18:44, 15 December 2008 (NZDT)

1.0 Introduction – Working Together

During the Introductory meeting, Vendor and prospective clients learn each other's goals and methodologies to determine what relationships are possible.

Deliverables

• Service Agreement

A signed agreement in the form of a retainer or hourly service agreement that commits Vendor to a specific Project and Role(s)

2.0 Orientation – Understanding and Organizing

Deliverables

• Process / Service Timeline

A diagram showing the sequence of events that must take place in order for the company to complete the processes being streamlined

• Bubble Diagrams

Diagrams, also known as workflow models, that are key to getting everyone on board and using the same terminology. The extent of diagramming is dependent on the breadth of the project at hand.

3.0 Specification – Setting The Direction

Although it may sound daunting, a complete specification showing every piece of desired business logic, every workflow, every dataflow and every user interaction will be assembled during this step. Streamline has a unique and enjoyable method to quickly capture these and then translate them into Project Specifications.

Deliverables

• Project Outline

An outline showing all major/primary components that need to be developed, integrated and/or procured to complete this project

• Project Specification

A list of what needs to be implemented to support both the desired workflows and the technical functionality

4.0 Development and/or Selection – Making it Real

Projects are frequently comprised of a combination of custom, existing and 'off the shelf'components. This step incorporates both the development of custom software, the selection of software from outside vendors and the Integration Plan to keep it all working together.

Deliverables

• Development And Change Logs
• Logs providing the bookkeeping of software development by tracking all

time and expenses

• Integration Plan

A document showing how each component will interact with each other and what workflows and communications must happen to facilitate that interaction

5.0 Acceptance – Defining Done and Wrapping it Up

To make the Project's finish line a fixed target, practice "Defining Done" This practice looks at all original deliverables set forth in the Project Specification and the Change Log and creates a punch list of open issues known as the Acceptance Log.

Deliverables

• Acceptance Log

A log of all issues that must be addressed in order to call the project complete

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

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 & Navigation

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.