Ohjauskeskus, vapauttakaa käsiraudat!

kaiken toimialojen ja vertikaalisten sektoreiden välisen liiketoiminnan yhä monimutkaisemmaksi käyvä ja globaalistuva luonne yhdistettynä nopeisiin “Internet Time” – liiketoimintamalleihin tuo muutoksen johtamiseen uutta painoarvoa. Kyky hallita tehokkaasti muutosta on nousemassa kilpailijoiden erottavaksi avaimeksi – mahdollistaen organisaatioiden kehittää liiketoimintamalleja ja tuotelinjoja sekä vaihtaa vaihdetta riittävän nopeasti vastaamaan nykyisen talouden mahdollisuuksia – ennen kilpailua.

kun organisaatiot kamppailevat projektien hallinnasta tässä ympäristössä, Konfiguraationhallinnasta (cm) on tullut yhä kriittisempi osa, joka tarjoaa puitteet muutoksen hallintaan.

CM: n tieteenala koostuu kuudesta YVA-649: n (ANSI, 2004))

• CM Planning and Management (cmpm),
• Configuration Identification (CI),
• Configuration Change Management (CCM),
• Configuration Status Accounting (CSA),
• Configuration Verification & Auditations (CVA), ja
• CM digitaalista tietoa.

kuitenkin ISO 10007 (ISO, 2003) ryhmittelee CM neljään luokitukseen:

• CI,
• Configuration Control (CC),
• CSA, ja
• Configuration Reviews and auditions (R&a).

(CCM ja CC ovat kaikissa käytännön tarkoituksissa samat, samoin CVA ja R&A.)

huomaa, että konfiguraation valvontaa käsitellään tässä artikkelissa. Konfiguraatiomuutosten hallinta ja muutosten hallinta ovat myös termejä, joita käytetään kuvaamaan samaa prosessia.

monet projektipäälliköt pitävät konfiguraationhallintaa tuotekehityksen estämiseen suunniteltuina rajoittavina ja rajoittavina järjestelminä, jotka yleensä vaikuttavat projektin aikatauluun kielteisellä tavalla. Valitettavasti liian usein yleisiä CC-prosesseja, jotka on suunniteltu suuriin, monimutkaisiin ohjelmiin, kuten aseiden tai lääketieteellisten järjestelmien kehittämiseen, määrätään muunlaisissa projekteissa. Näitä prosesseja ei ole räätälöity vastaamaan esimerkiksi verkkokehityksen tai uuden tuotteen käyttöönoton tarpeita. Tämä johtaa lopulta voimakkaaseen turhautumiseen CC-prosessiin ja” handcuffing ” – vaikutukseen-jossa prosessit, joita ei ole suunniteltu vastaamaan ohjelman tarpeisiin, vaikuttavat negatiivisesti edistymiseen.

projektipäälliköt toteuttavat konfigurointiohjauksen, jolla hallitaan ja seurataan muutoksia. Prosessien tarkoituksena on varmistaa, että muutosten hyväksymisessä käytetään asianmukaista tasoa ja että muutokset perustuvat parhaaseen saatavilla olevaan tietoon. Prosessit tarjoavat puitteet muutostarkastelulle. Näin tiimi voi arvioida, onko muutoksen toteuttaminen hyväksyttävää ja tunnistaa mahdolliset ongelmat ajoissa. Nämä prosessit mahdollistavat kalibroinnin ja tarvittaessa tarkentamisen.

todellinen kysymys ei ole, toteutetaanko konfiguraatiokontrolli, vaan minkä tasoinen konfiguraatiokontrolli toteutetaan. Organisaatio voi vaatia “yrityksen standardin” konfiguraationhallintapaketin kaikissa projekteissa. Tämän tyyppinen järjestelmä on usein tyrkytetty projektitiimeille kokoonpanon hallinnan puutteen ja siitä aiheutuvien taloudellisten vaikutusten vuoksi. Projektipäälliköiden, jotka tunnustavat, että “yhden koon” lähestymistapa ei toimi, on osoitettava, että käytössä on asianmukainen valvonta, jotta vältetään aiempien virheiden toistaminen.

Konfiguraatiokontrolli toiminnassa

tyypillinen kehitysprojekti ei vaadi konfiguraatiokontrollia suuren asejärjestelmän tasolla. On tärkeää antaa ryhmälle riittävästi joustavuutta ja varmistaa samalla, että käytössä on valvonta-ja tasapainojärjestelmä. Avain mihin tahansa järjestelmään on prosessin dokumentoinnissa vaadittava työ sekä prosessin edellyttämä dokumentointi. Alla kuvattu näytteen CC-prosessi on suunniteltu täyttämään pienen ja keskisuuren sovelluskehitysprojektin vaatimukset.

projektiryhmän tulee ensin analysoida konfiguraatiokontrollin asianmukainen rooli projektissa. Tämä, vähintään ohjelmistoprojektissa, merkitsisi teema dokumentointi kaikki kooditiedostot sisäisesti ja jonkinlainen ulkoinen dokumentointi. Muita osa-alueita ovat muutosten hyväksymis-ja dokumentointiprosessit. Osallistujien yksimielisyyden pitäisi riittää. Säännöllisesti kokoontuva jäsennelty hallitus on tietysti parempi.

nyt mennään yksinkertaisen Konfiguraationhallintaprosessin eri osa-alueisiin.

asiakirjat

Konfiguraationhallintasuunnitelmassa (CMP) määritellään CC-prosessi. Joissakin sovelluksissa, joissa CC-prosessi on melko yksityiskohtainen, kehitetään Konfiguraationhallintasuunnitelma (Configuration Control Plan, CCP). Kummassakin tapauksessa kaikki prosessit ja menettelyt katetaan konfiguraationvalvonnan suorittamiseksi.

Muutosasiakirjoissa itsessään (Tarkennettu myöhemmin) on annettava riittävästi itsestään selviä tietoja siinä määrin, ettei niiden lähettäjältä vaadita lisätietoja. Tämä on tarpeen, koska on mahdollista, että alullepanija ei ole käytettävissä muutoksen toteutuessa.

prosessi

CC-prosessi on yksinkertainen (näyttely 1). Yksilöllä on idea tai löytää virhe nykyisestä järjestelmästä. Tämän henkilön tulisi dokumentoida havaintonsa Enterprise Change Request (ECR) – lomakkeella, jota käytetään kirjaamaan kaikki tietyn projektin virheet, muutokset tai parannukset. Muutospyyntö ohjataan vertaisryhmille ja esimiehille tarkistettavaksi, minkä jälkeen se hyväksytään ja toteutetaan.

näyttely 1-Yksinkertainen Konfiguraationhallintaprosessi

Muutosdokumentointi

muutoksen dokumentointi on konfiguraationhallintajärjestelmän kriittisin osa. Dokumentoinnin yksityiskohdat eivät ole yhtä tärkeitä kuin dokumentoitavat tiedot. Dokumentoiduissa tiedoissa on kuitenkin kuvattava muutos ja sisällettävä vähintään seuraavat tiedot. Dokumentointia koskevat vähimmäisvaatimukset ovat:

tietenkin, enemmän tietoa dokumentaation, sitä helpompi on luoda, palauttaa, analysoida, ja korjata. Lisäksi tämä auttaa lopullisessa dokumentaatiossa tuotteen toimitusta varten.

kun yksilö havaitsee nykyisessä projektissa virheen tai vaatimuksen, hän dokumentoi vaaditun muutoksen. Muutospyyntö sisältää tietoja pyynnöstä ja kuvataan skenaario, joka löysi virheen, kuka löysi sen, kun se havaittiin, ja Suositellut korjaukset. Pyynnössä olisi myös mahdollisuuksien mukaan yksilöitävä määrityskohteet, joihin muutokset vaikuttavat, ja asetettava jonkinlainen vakavuuden tai prioriteettikoodi, jonka avulla voidaan tunnistaa, milloin tämä muutos, jos se hyväksytään, tapahtuu.

Muutoshyväksyntä

muutoshyväksyntä tulisi antaa nimetyltä projektivalvojalta, jolla on “ison kuvan” näkemys muutoksen vaikutuksista. Vertaisarviointi on erittäin tehokas keino tarkistaa muutoksen kaikki puolet ja varmistaa, että kaikki muutoksesta kärsivät alueet otetaan huomioon. Asiakkaan suostuminen muutokseen olisi eduksi parannuksille. Pienissä kehitysprojekteissa suurin osa muutoksista on kuitenkin “viankorjaustyyppisiä”, eikä asiakas näkisi muutoksen vaikutusta.

tiedonkeruu

tiedonkeruu on elintärkeää, jotta saadaan tietoa samankaltaisista kohteista ja löydetään suuntaukset ja suuntaukset. Näiden tietojen olisi sijaittava sähköisesti, mikä mahdollistaa tietojen helpon palauttamisen ja tietojen manipuloinnin tilalaskentaa ja mittareita varten. Tietoja voidaan käyttää “lessons learned” – raportin laatimiseen, joka jaetaan koko organisaation tekniseen parantamiseen.

Muutoksen Toteutus.

kun kaikki tarvittavat hyväksynnät on saatu, alkaa toteutustehtävä. Jokaisessa toteutusvaiheessa tehtävä testaus varmistaa, että vaikutukset ohjelman muihin osa-alueisiin ovat minimaaliset. Kaikki testaus on suoritettu ja muutos toteutetaan koko ohjelmaan.

suljetun kierron prosessi

suljetun kierron prosessi, jossa muutoksen alkuunpanija tietää muutoksen lopputuloksen ennen kuin se näkyy lopputuotteessa, on avainasemassa onnistumisen kannalta. Tämä pätee kaikenlaisiin teollisuudenaloihin rakennusalasta valmistukseen ja ohjelmistoihin.

tämä suljetun kierron prosessi asettaa ohjauskortit, joilla on erilaiset roolit muutosprosessissa (näyttely 2). Jokaisella johtokunnalla on velvollisuus tarkastella muutosta koko peruskirjansa yhteydessä ja tehdä lopullinen päätös jokaisesta muutoksesta. Lautakunta voi tietenkin vaatia lisätietoja ennen kuin se voi tehdä tämän päätöksen, mutta sen pitäisi olla minimaalinen.

Institute for Configuration Management (ICMHQ) opettaa cmii (CMIIU)-metodologiaa konfiguraatioiden hallintaan ja on kehittänyt tämän näkemyksen suljetun kierron muutosprosessista. Tämä prosessi alkaa ja päättyy lopputuotteeseen. Huomaa, että konfiguraatiomuutosten hallinta näkyy silmukassa kolmella eri tasolla. Jokainen alue on määritelty eri tavalla, ja sillä on omat roolinsa ja vastuunsa.

• tekninen tarkastelu — varmistaa, että kaikki yksityiskohtaiset arvioinnit ja toteutettavuusanalyysi ovat täydellisiä.
• muutoksen arviointilautakunta (Change Review Board, CRB) arvioi muutoksen vaikutuksia liiketoimintaan. Onko tämä muutos voimassa liiketoimintaympäristössämme? Täyttääkö se yhden strategisista tavoitteistamme? Sopiiko se näkemykseemme? Hyväksytyllä muutoksella CRB voi ilmoittaa muutoksen aikataulun tai olla ilmoittamatta sitä riippuen kilpailuennusteista ja liiketoimintariskistä.
• muutosten Toimeenpanolautakunta (CIB) – jakaa tarvittavan rahoituksen ja määrittää muutosten toteuttamisen aikataulut. Tähän sisältyy myös muutoksen vaikuttavuuden osoittaminen, joka määrittää, milloin muutos on voimassa. Vaikuttavuus voi koskea päivämäärä, rakentaa, sarjanumero, tai erän numero. Tämä riippuu lopputuotteesta.

Fast Track vaihtoehto silmukka on, jossa kaikki kipu CC vapautetaan ja omistajat voivat saada muuttunut hyväksytty minuuttia vs. päivää. Avain Tähän on tietenkin kunkin tuotteen asianmukainen dokumentaatiopuu. Jokaisella asiakirjalla on oltava Luojansa ja käyttäjänsä. Jos muutokset vaikuttavat vain heikkotasoiseen dokumentaatioon, niin Fast Track on kunnossa ja muutos huutaa CC-prosessin läpi.

Yhteenveto

avain onnistuneeseen Konfiguraationhallintaprosessiin on koko projektiryhmän sisäänosto. Työryhmän jäseniä ei pitäisi pyytää luopumaan järkevästä harkinnasta ja valvonnasta sellaisen hallinnointirakenteen vuoksi, jota ei ole suunniteltu täyttämään käsillä olevan hankkeen vaatimuksia. Konfiguraationhallintaprosessit on suunniteltu vähentämään vikariskiä ja varmistamaan, että suoritukset saavutetaan ajoissa ja budjetissa. Jos projektiryhmä osallistuu Alkuperäisen Konfiguraationhallintakehyksen luomiseen-projektiryhmän osallistuminen ja hyväksyntä nopeutuu ja perustettu infrastruktuuri tukee liiketoiminnan tavoitteita.