Back office catalog
Published on April 29, 2011, edited by Tibi, Kurt, Ishan, Ian, Francois, and Steve. See original doc, last modified on Oct 14, 2012 before content was moved here. If you contribute to this doc make sure you respect Content rules.
Work on the value system is hosted on github. We are using REA (for Resources, Events and Agents) designed by Bill McCarthy of Michigan State University (See more on Bill McCarthy’s website). See a prototype HERE.
The Back Office Catalog is an online collaborative tool used to assign value to deterministic, recurrent back office tasks. It contains all imaginable such tasks. Tasks are organized in categories. Each task is assigned a number of points (it is weighted), which reflects the effort needed to accomplish the task, the skills involved in it, the complexity of the task, the means used, etc. This database is searchable, users can add more tasks, and everyone is able to evaluate tasks, i.e. to allocate a number of points for every task (valuation process). All inputs for one particular task are averaged! As more and more users participate in the valuation process the value of each task reaches a (statistically) stable level, which reflects the average, popular evaluation. The Back Office Catalog is used as a reference by everyone who needs it, in any value network.
It is advised to have a Back Office Catalog of relative values instead of absolute values. In other words, one particular task can be chosen as a reference task, to be compared with all other tasks. This would make the Back Office Catalog easily adaptable to different contexts.
The Back Office Catalog avoids tedious peer-evaluation of every task for every member. Members provide relative evaluations to tasks from time to time. The catalog is automatically applied to all contributions, reducing the load for evaluation on the community.
- See original document on the Back Office Catalog as defined earlier for a Discovery Network
- Kurt Laitner made us understand that the Back Office catalog can only be used for deterministic and recurrent tasks. (See the network to network interface discussion). There are defined tasks (have a procedure, history and average/expected time to complete data) and undefined tasks (we know it needs to be done, and have named it, but it is rather open ended), then another side of things that aren't tasks at all (have not been identified on the to do list) but may have value so should be tracked and perhaps even characterized - this is where we track things that have the probability of producing value somewhere down the road but aren't related to an identified task (like attention - showing up, participation - effort in current terms, that may or may not pan out)