Prosessinlouhinta antaa DMAIC teams event records for examining process paths and repeated activities. The Process Mining for Six Sigma study, published in the 2021 journal volume, developed a guideline aligning these techniques with DMAIC. Before extracting a log, the team needs to identify the improvement decision those records will support.
Määritä DMAIC-rajaus ennen tapahtumien poimimista
ASQ:n DMAIC-ohjeistus sijoittaa projektin rajauksen ja asiakasvaatimukset Define-vaiheeseen. SIPOC auttaa tiimiä sopimaan analyysiyksiköstä ja sen rajoista. Projektisopimus määrittelee sitten tapauksen ja sen mittauksen aloituspisteen. Se määrittelee myös tuloksen, joka lasketaan onnistuneeksi suoritukseksi.
Liiallinen kulunut aika ja korjausta vaativa virheellinen tuotos tarvitsevat erilliset operatiiviset määritelmät projektin ongelmakuvauksessa. Sponsorin Define-katselmuksen tulisi ratkaista, mikä asiakasvaatimus on etusijalla. Sen tulisi myös tunnistaa laatumittari, jota on suojeltava, kun tiimi muuttaa prosessia.
Measure: määritä, mitä tapahtumaloki voi edustaa
Tavanomainen tapahtumaloki yhdistää kunkin toiminnon tapaukseen ja kirjaa ylös, milloin se tapahtui. Resurssitiedot ovat valinnaisia, kuten PMSS-paperissa kuvataan. DMAIC-mittaussuunnitelma tarvitsee määritelmän jokaiselle kentälle ennen kuin tiimi laskee suorituskyvyn:
- Tapaustunniste: prosessi-instanssi, jota seurataan sovitun SIPOC-rajan läpi.
- Toiminto: kunkin tallennetun tapahtuman edustama liiketoimintavaihe.
- Aikaleima: järjestelmän tallentama ajankohta, kuten toiminnon aloitus tai valmistuminen.
- Lisämääreet: ne resurssi- tai tapaussarakkeet, joita tarvitaan suunniteltuihin vertailuihin.
Measure-vaiheen katselmuksessa on myös määritettävä, kuinka paljon työtä loki kaappaa. Julkaisussa Data & Knowledge Engineering ilmestyneessä 2024 tutkimuksessa tutkijat havainnoivat kuutta asiantuntijapalveluyrityksen työntekijää. He havaitsivat, että pääasiallisen muunnosjärjestelmän loki edustaisi noin 69 % havaitusta tiedon muunnos- ja validointiajasta. Kattavuus putosi 32.5 prosenttiin, kun sitä arvioitiin kaiken asiaankuuluvan asiakastyön suhteen. Nämä prosenttiosuudet pätevät tutkittuun yritykseen.
Lean Six Sigma -tiimille tämä kattavuusaukko tuo eteen rajauspäätöksen: kappaako ehdotettu loki projektisopimuksessa nimetyn työn? Gemba walk poimintakatselmuksen rinnalla auttaa tunnistamaan järjestelmätiedoista puuttuvan työn. Measure-vaiheen tuotoksessa tulisi nimetä nämä poisjätetyt toiminnot ja selittää, miten niiden puuttuminen rajoittaa analyysia.
Pullonkaulan tutkiminen vaatii muutakin kuin pitkän aikavälin
Pitkä aikaväli aikaleimojen välillä vaatii selityksen, ennen kuin Analyze-tiimi pitää sitä kapasiteettiongelmana. Vuoden 2024 Tietojärjestelmät-tutkimuksessa toimintojen välinen odotusaika jaetaan viiteen syyhyn: eräajoon, resurssien kilpailuun, priorisointiin, resurssien saamattomuuteen ja ulkoisiin tekijöihin. Tutkijat arvioivat lähestymistapaansa synteettisillä lokeilla ja demonstroivat sitä todellisessa prosessissa. Nämä kategoriat antavat Lean Six Sigma -tiimeille tiettyjä syitä tutkittavaksi ennen lisäkapasiteetin ehdottamista.
DMAIC-analyysisuunnitelman tulisi erottaa tallennettujen tapahtumien välinen kulunut aika odottamisesta ennen kuin toiminto voi alkaa. Tämä erottelu riippuu siitä, mitä aikaleimat tallentavat ja miten analyysi käsittelee työkalentereita. Kun viivekategoriat on vahvistettu, Pareto-kaavio järjestää ne kertyneen ajan mukaan projektin rajan sisällä.
Kilpailevat selitykset kuuluvat Ishikawa-kaavioon. Jos tiimi epäilee eräajoa, Analyze-katselmus tarvitsee todisteita, jotka yhdistävät vapautussäännöt havaittuihin viiveisiin. Pilotti, joka muuttaa noita sääntöjä, testaa eri syytä kuin pilotti, joka muuttaa resurssien saatavuutta.
Uudelleentyön luokittelu ennen virheiden laskemista
PMSS-julkaisun laskutusdemonstraatiossa verrataan tapauksia, jotka sisältävät toimintojen toistoja, muihin tapauksiin tarkastelemalla niiden polkuja ja käsittelyaikoja. Tämä vertailu tunnistaa tutkittavat tapaukset. Toistojen laskeminen virheiksi edellyttää prosessin omistajan hyväksymää liiketoimintasääntöä, joka erottaa korjaavan työn sallitusta toistosta.
DMAIC-mallissa ehdotettu mittari on niiden soveltuvien tapausten osuus, jotka sisältävät vähintään yhden vahvistetun korjaavan toiston. Erillinen ylimääräisten toistojen määrä kuvaa korjaustyön määrää. Tapaustason virhemittarilla on tällöin määritelty sääntö, jota 5 Miksi-kysymystä -tutkinta voi testata yksittäisiä tapauksia vastaan.
Parantaminen epäiltyyn syyhöön kytketyn pilotin avulla
ASQ sijoittaa ratkaisujen arvioinnin Improve-vaiheeseen. Pilottiehdotuksen tulisi yhdistää valittu muutos Analyze-vaiheen löydökseen. Vertailukohdan tapausmääritelmän säilyttäminen antaa tiimille johdonmukaisen pohjan vertailulle; ilmoitettu hyväksyntätulos asettaa testin muutokselle. Uudelleentyöprojektissa pilotin tulisi testata poka-yoke-ehdotusta vahvistettua korjauskategoriaa vastaan ennen laajempaa käyttöönottoa.
Improve-vaiheen katselmuksessa kysyisin, miten pilotti- ja vertailuryhmät vertautuvat toisiinsa, mukaan lukien mahdolliset erot työmäärässä tai tapaamisjakaumassa. Sponsorin on myös nähtävä suojattu laatu-indikaattori kuluneen ajan rinnalla. Lyhyempi aikaväli prosessinlouhinnan kojelaudalla ei ole riittävä todiste hyväksynnälle, jos tapausjakauma on muuttunut tai virheet ovat lisääntyneet.
Ohjaussuunnitelmien on sisällettävä tapahtumadatan putki
ASQ:n Control-vaihe sisältää pitkän aikavälin mittaus- ja reaktiosuunnitelmat. Ohjaussuunnitelman tulisi myös nimetä tapahtumapoiminnan toimintomääritelmien omistaja ja määrittää, kuka hyväksyy kartoitusmuutokset. Puuttuvat tietueet vaativat dokumentoidun käsittelyn. Toistuva uudelleentyö ja heikkenevä lokikattavuus tarvitsevat kumpikin osoitetun vastatoimenpiteen.
Dokumentoitujen mittausmääritelmien on siirryttävä ohjauskortteihin. Jos järjestelmämuutos muuttaa sitä, mitä aikaleima tallentaa, prosessin omistaja tarvitsee mittauskatselmuksen ennen seuraavan suorituskykysignaalin tulkitsemista.
Lähteet
- Business & Information Systems Engineering (2021), Process Mining for Six Sigma: https://link.springer.com/article/10.1007/s12599-020-00649-w
- Data & Knowledge Engineering (2024), Capturing and Analysing Employee Behaviour: An Honest Day’s Work Record: https://research-portal.uu.nl/ws/portalfiles/portal/239370240/1-s2.0-S0169023X24000740-main.pdf
