Työn jakaminen ja joukkoistus
Tämä sivu on ensyklopedia-artikkeli.
Sivutunniste: Op_fi3363 |
|---|
| Moderaattori:smxb (katso kaikki)
Sivun edistymistä ei ole arvioitu. Arvostuksen määrää ei ole arvioitu (ks. peer review). |
| Lisää dataa
|
Mikroduuni, kilpailutus ja työn osituksen toteutus
Lahtökohta: Hallinto/yritys/yhteisö/yksityishenkilö tarjoaa työtehtävän yhteisölle. Työtehtävä voidaan jakaa osiin sekä työstä kiinnostuneiden henkilöiden osaamisen ja resurssien mukaan että työtehtävän laajuuden ja rakenteen mukaan. Tarkastelu on yleinen eikä jaottelua julkisiin ja yksityispuolen hankintoihin tehdä vielä tässä vaiheessa kohdassa (B). Kevyt toteutus (A) keskittyy nimenomaan julkisiin hankintoihin.
(A) Kevyt toteutus
- Jos mahdollista, työn tarjoaja pilkkoo työtehtävän alle 30000 E palasiin ("toimintatonni"). Näin pienet firmat ja yksittäiset kiinnostuneet eivät joudu epäreiluun kilpailuasemaan isoihin toimijoihin nähden. Yhteisö voi myös avustaa työn pilkkomisessa
- Palasten toteuttamisesta käydään kilpailu kuten kuvattu kohdassa "Kilpailutuksen järjestäminen" alempana
(B) Raskaampi toteutus (resurssipankki ja ositusalusta)
- Työn tarjoaja tarjoaa joukkoistettavaa työtehtävää (ongelmaa) julkisella foorumilla (esim. Innocentive.com, vähän parannettu mol.fi, jossa siis työpaikkojen sijaan esitellään ratkaistavaksi tarkoitettuja ongelmia)
- Työn ositukseen tarvitaan palvelu (ks. Mikroduuni-ryhmän sivu), jossa työstä kiinnostuneet voivat ilmoittautua resursseiksi erilaisiiin työtehtäviin. Jos työ on valmiiksi ositettua tarjoajansa puolesta, ja resurssiksi ilmoittautuneita on runsaasti, palvelu voi olla pitkälti automaattinen ('match-making'). Jos työn osittamisesta haetaan suurta uudelleenkäyttöhyötyä (esim. hallinnon tai prosessien tehostamiseksi) ja/tai työntekijäresursseja on vähän, on järkevintä osittaa tehtävä yhteistyössä tarjoajien ja työstä kiinnostuneiden kanssa.
- Kun ratkaistavan ongelman osittaminen tapahtuu yhteisöllisesti voidaan myös työstä saatavia palkkioita jakaa yhteisöllisesti (vrt. osallistuva budjetointi). Tässä voidaan apuna käyttää resurssienjakoalustaa, joka havainnollistaa erilaisten rajoitteiden (käytettävissä oleva rahamäärä, osallistujien määrä, aika, lainsäädäntö, laatuvaatimukset jne.) vaikutukset jakoprosessiin kaikille avoimella tavalla. Kukin siis tietää mitä toiset saavat ja kriteeristöjä voidaan vaihtaa parempien optimien hakemisessa. Aina voidaan palata myös vanhaan suljettuun jakoon ja kilpailuprosessiin.
- Rahanjako/palkitseminen voidaan toteuttaa paitsi perinteiseti myös käyttämällä jotain modernimpaa joukkorahoitusalustaa (esim. Kickstarter). Palkkiot voidaan korvamerkitä tietyille osaongelmille, jotka ovat kriittisiä kokonaisuuden kannalta tai hallinto voi antaa pienen strategisen lisäpanostuksen tärkeiksi rankatuille ongelmille (esim. jos jonkin tietyn ongelman ratkaisu on jo kerännyt yksityisen puolen rahaa mutta ei ole päässyt tavoitteeseensa). Joukkorahoitusalustalla rahoituspotentiaali on kaikkien tiedossa koko ajan, ja strategisia rahoituksia voidaan tehdä. Mikäli työn lopputulokset eivät täytä sovittuja kriteerejä, rahat palautetaan. Jos veronmaksajien rahaa on käytetty tiettyjen ongelmien ratkaisemiseen, pitäisi ratkaisujen olla myös avoimena datana ja ohjelmistoina kaikkien hyödynnettävissä.
- Resurssipankki ja ositusalusta sisältää myös luettelon ratkaisua kaipaavista ongelmista (= ongelmapankin), joilla ei vielä ole rahoitusta sekä ratkaisupankin jo ratkaistuista ongelmista (erityisesti tietotyössä), joita voidaan uudelleen hyödyntää ja yhdistellä.
- Ongelma/ratkaisupankki auttaa näkemään onko jokin ongelma jo ratkaistu ja voidaanko vanha ratkaisu kopioida tai yleistää uuteen tarkoitukseen.
- Ongelma/ratkaisupankki luo tarjontaa ja kysyntää (koodari X huomaa että eri tahojen ratkaistavaksi ilmoittamat ongelmat A, B ja C hyötyisivät algoritmista Y. Vaikka ongelmille A, B ja C ei olisi vielä erillistä rahoitusta olemassa, voisi koodarin X firma tiedustella A-, B- ja C-ongelmien omistajatahojen halukkuutta yhteisrahoitukseen. Näin hinta per rahoittaja voisi pudota murto-osaan ollen kuitenkin koodarin kannalta edelleen järkevä tulonlähde.)
- myös ongelmien dokumentointiin (ei ainoastaan ratkaisujen dokumentointiin) kannattaa panostaa, muuten ongelma ei aukea eikä analogioita pystytä näkemään.
- olemassaolevia ratkaisuja pankeiksi (a) koodipohjaisiin tietoteknisiin ratkaisuihin GitHub (b) toimintatapakäytäntöjen välittämiseen Innokylä.
- yksinkertaisimmillaan ongelma- ja ratkaisupankki voidaan toteuttaa huokeasti ja siinä voidaan hyödyntää olemassa olevia palveluita (ks hankerekisteri, Otakantaa.fi, SADe-Raymp/Liiteri).