Řízení změn (inženýrství) - Change management (engineering)

The správa požadavků na změnu zpracovat v systémové inženýrství je proces vyžádání, stanovení dosažitelnosti, plánování, implementace a vyhodnocení změn a Systém. Jeho hlavním cílem je podpora zpracování a sledovatelnosti změn vzájemně propojeného souboru faktorů.[1]

Úvod

Mezi řízením žádosti o změnu existuje značné překrývání a nejasnosti, ovládání změny a správa konfigurace. Níže uvedená definice tyto oblasti ještě neintegruje.

Správa požadavků na změnu byla přijata pro svou schopnost poskytovat výhody zlepšením ovlivněného systému a tím uspokojením „potřeb zákazníků“, ale byla také kritizována za její potenciál zmást a zbytečně komplikovat správu změn. V některých případech, zejména v EU Informační technologie doména, více prostředků a práce je vloženo do údržby systému (a správy požadavků na změnu) než do počátečního vytvoření systému.[2] Typické investice organizací během počáteční implementace velkých ERP systémů tvoří 15 až 20 procent celkového rozpočtu.

Ve stejném duchu, Hinley [3] popisuje dva z Lehmanovy zákony vývoje softwaru:

  • Zákon pokračujících změn: Použité systémy se musí změnit, jinak se automaticky stanou méně užitečnými.
  • Zákon rostoucí složitosti: Změnami se struktura systému stává stále složitější a ke zjednodušení je zapotřebí více zdrojů.

Správa žádostí o změnu má také velký význam v oblasti výroby, která je konfrontována s mnoha změnami v důsledku přibývání a celosvětově soutěž, technologický pokrok a nároční zákazníci.[4] Protože mnoho systémů má tendenci se měnit a vyvíjet, jak jsou používány, problémy těchto průmyslových odvětví se do určité míry setkávají v mnoha dalších.

Poznámky: V níže uvedeném procesu je dokázáno, že výbor pro změnu by měl být odpovědný nejen za přijetí / odmítnutí rozhodnutí, ale také za stanovení priorit, což ovlivňuje dávkové zpracování žádostí o změnu.

Proces a jeho výstupy

Popis procesu správy požadavků na změnu je uveden v technika meta-modelování se používá. Obrázek 1 zobrazuje diagram procesních dat, který je vysvětlen v této části.

Obrázek 1: Model procesních dat pro proces řízení změn

Činnosti

Existuje šest hlavních činností, které společně tvoří proces řízení žádosti o změnu. Jsou to: Identifikace potenciální změny, Analýza požadavku na změnu, Vyhodnocení změny, Plánování změny, Implementace změny a Kontrola a uzavření změny. Tyto činnosti jsou prováděny čtyřmi různými role, o nichž pojednává tabulka 1. Samotné činnosti (nebo případně jejich dílčí činnosti) jsou popsány v tabulce 2.

Tabulka 1: Popisy rolí pro proces správy požadavků na změnu
RolePopis
ZákazníkThe zákazník je role, která požaduje změnu z důvodu problémů nebo nových požadavků na funkčnost; může to být osoba nebo organizační jednotka a může být interní nebo externí vůči společnosti, která je požádána o provedení změny.
Projektový manažerThe projektový manažer je vlastníkem projekt které se týká ŽÁDOST O ZMĚNU. V některých případech existuje zřetelný manažer změn, který v tomto případě převezme tuto roli.
Výbor pro změnuZměna výbor rozhodne, zda bude implementována žádost o ZMĚNU nebo ne. Někdy tento úkol provádí také projektový manažer.
Změnit staviteleTvůrcem změn je osoba, která plánuje a implementuje změnu; dalo by se tvrdit, že plánovací složku (částečně) přebírá projektový manažer.
Tabulka 2: Popisy aktivit pro proces správy požadavků na změnu
AktivitaDílčí aktivitaPopis
Identifikujte potenciální změnuVyžadovat nové funkce[5]Zákazník touží po nové funkčnosti a formuluje POŽADAVEK.
Setkání problém[5]Zákazník narazí na problém (např Chyba ) v systému a to vede k PROBLÉMOVÉ ZPRÁVĚ.
Žádost o změnuZákazník navrhuje změnu vytvořením ŽÁDOSTI O ZMĚNU.
Analyzujte požadavek na změnuUrčete technickou proveditelnostManažer projektu určuje technickou proveditelnost navrhované ŽÁDOSTI O ZMĚNU, vedoucí k ZMĚNĚ TECHNICKÉ FASIBILITY.
Určete náklady a přínosyProjektový manažer určuje náklady a přínosy navrhované ŽÁDOSTI O ZMĚNU, což má za následek ZMĚNU NÁKLADŮ A VÝHOD. Tuto a výše uvedenou podaktivitu lze provést v jakémkoli pořadí a jsou na sobě nezávislé, proto je modelování jako neuspořádané aktivity.
Vyhodnoťte změnuNa základě ŽÁDOSTI O ZMĚNU, její ZMĚNĚ TECHNICKÉ VYBAVITELNOSTI a ZMĚNĚ NÁKLADŮ A VÝHOD VÝBORU PRO VÝBĚR ROZHODNUTÍ rozhoduje go / no-go Toto je modelováno jako samostatná aktivita, protože je to důležitý krok procesu a má další roli při jeho provádění. Je modelován jako dílčí aktivita (bez jakékoli aktivity, která ji obsahuje), jak doporučuje Remko Helms (osobní komunikace).
Změna plánuAnalyzujte dopad změnRozsah změny (tj. Jaké další položky ovlivní změna) je určen v ANALÝZE ZMĚNY DOPADU. Lze tvrdit, že tato aktivita vede k jinému rozhodnutí go / no-go, nebo že dokonce tvoří součást aktivity Analyse change request. Je zde modelován jako plánovací úkol pro tvůrce změn kvůli jeho vztahu s aktivitou Propagovat změnu.
Vytvořte plánováníJe vytvořeno ZMĚNOVÉ PLÁNOVÁNÍ implementace změny. Některé popisy procesů (např. Mäkäräinen, 2000) ilustrují, že je také možné „uložit“ změny a zpracovat je později v šarže. Tuto aktivitu lze považovat za dobrý bod.
Implementujte změnuProveďte změnuZměna je „naprogramována“; tato aktivita má silný vztah k Propagate change, protože někdy musí být změna přizpůsobena i jiným částem systému (nebo i jiným systémům).
Propagujte změnuZměny vyplývající ze změny Execute musí být přeneseny do dalších částí systému, které jsou touto změnou ovlivněny. Protože tato a výše uvedená podaktivita jsou na sobě velmi závislé, byly modelovány jako souběžné aktivity.
Zkouška změnyTvůrce změn testuje, zda to, co sestavil, skutečně funguje a zda splňuje ŽÁDOST O ZMĚNU. Jak je znázorněno v diagramu, může to vést k iterativní proces společně s výše uvedenými dvěma dílčími činnostmi.
Aktualizujte dokumentaciDOKUMENTACE je aktualizována tak, aby odrážela použité změny.
Uvolnit změnuZveřejněna nová SYSTÉMOVÁ ZPRÁVA, která odráží aplikovanou změnu.
Zkontrolujte a zavřete změnuOvěřte změnuImplementace změny v novém SYSTÉMU RELEASE je ověřena naposledy, nyní projektovým manažerem. Možná se to musí stát před vydáním, ale kvůli konfliktním zdrojům literatury a úvahám o složitosti diagramů bylo vybráno modelovat to tímto způsobem a zahrnout tento problém.
Zavřít změnuTato změna cyklus je dokončen, tj. je zabalen ZÁZNAM ZÁZNAMU ZÁZNAMU

Výsledky

Vedle aktivit ukazuje diagram procesních dat (obrázek 1) také výstupy každé činnosti, tj. údajů. Tyto výstupy nebo koncepty jsou popsány v tabulce 3; v této souvislosti jsou nejdůležitější pojmy: ZMĚNIT POŽADAVEK a ZMĚNA VSTUPU DO LOGU.

Autor definuje několik konceptů (tj. Postrádá odkaz), protože buď nelze najít žádné (dobré) definice, nebo jsou zřejmým výsledkem činnosti. Tyto koncepty jsou označeny hvězdičkou („*“). Vlastnosti konceptů byly z modelu vynechány, protože většina z nich je triviálních a diagram by se jinak mohl rychle stát příliš složitým. Některé koncepty (např. CHANGE REQUEST, SYSTEM RELEASE) se dále hodí pro správa verzí přístup navržený Weerdem,[6] ale toto bylo také vynecháno kvůli omezením složitosti diagramu.

Tabulka 3: Popis konceptů pro proces správy požadavků na změnu
PojemPopis
POŽADAVEKPožadovaná funkčnost komponenty (nebo položky; NASA, 2005).
ZPRÁVA O PROBLÉMUDokument popisující problém, který nemůže vyřešit pracovník technické podpory úrovně 1; obsahuje položky jako datum, kontaktní údaje osoby, která problém hlásila, co je příčinou problému, umístění a popis problému, přijatá opatření a dispozice, ale toto není znázorněno v diagramu (Dennis, et al., 2002).
ZMĚNIT POŽADAVEKDokument, který popisuje požadovanou změnu a proč je důležitá; může pocházet z PROBLÉMOVÝCH ZPRÁV, vylepšení systému, dalších projektů, změn v základních systémech a vyššího managementu, zde shrnuto jako POŽADAVKY (Dennis, et al., 2002). Důležitý atribut: „rozhodnutí go / no-go“, tj. Bude změna provedena nebo ne?
ZMĚNIT VSTUP DO ZÁZNAMU *Výrazný vstup do sbírky všech změn (např. U projektu); Skládá se z ŽÁDOSTI O ZMĚNU, ZMĚNY TECHNICKÉ VYBAVITELNOSTI, ZMĚNY NÁKLADŮ A VÝHOD, ZMĚNY ANALÝZY DOPADU, PLÁNOVÁNÍ ZMĚNY, ZPRÁVY ZKOUŠKY a OVĚŘENÍ ZMĚNY. Ne všechny tyto položky musí být zahrnuty, pokud je proces ukončen dříve (tj. Pokud změna není implementována).
ZMĚNA TECHNICKÉ FASIBILITYKoncept, který označuje, zda „spolehlivý hardware a software, technické prostředky schopné uspokojit potřeby navrhovaného systému [tj. požadavek na změnu] může organizace získat nebo vyvinout v požadovaném čase “(Vogl, 2004).
ZMĚNĚTE NÁKLADY A VÝHODYOčekávané úsilí potřebné k implementaci a výhody (např. Úspora nákladů, vyšší výnosy) získané implementací změny. Také se jmenuje ekonomická proveditelnost (Vogl, 2004).
ZMĚNA ANALÝZY DOPADŮPosouzení rozsahu změny (Rajlich, 1999).
ZMĚNA PLÁNOVÁNÍ"Schéma, metoda nebo návrh pro dosažení nějakého cíle nebo pro dosažení něčeho [tj. změna] “(Georgetown University, n.d.), v tomto případě změna.
POLOŽKA"Nespecifický termín používaný k označení jakéhokoli." produkt, včetně systémů, subsystémů, sestav, podsestav, jednotek, sad, příslušenství, počítačových programů, počítačového softwaru nebo dílů “(Rigby, 2003); má (překrývající se) podtypy PŘIDAT POLOŽKU a ZMĚNIT POLOŽKU.
PŘIDANÁ POLOŽKA *Vysvětlení: nově vytvořená POLOŽKA; podtyp POLOŽKY.
ZMĚNĚNÁ POLOŽKA *Vysvětlení: POLOŽKA, která již existovala, ale byla změněna; podtyp POLOŽKY.
PROTOKOL O ZKOUŠCE„Dokument, který popisuje průběh a výsledky testování provedeného pro systém nebo komponentu [ovlivněnou změnou]“ (IEEE, 1991).
DOKUMENTACEPodle definice Pennsylvania State University Libraries (2004) je DOCUMENTATION „[p] tištěný materiál, který doprovází jiné materiály (obvykle neknihový), a který vysvětluje, poskytuje návod k použití nebo jinak funguje jako průvodce k hlavním materiálům . “ V této souvislosti to mohou být také digitální materiály nebo dokonce školení, pokud se týká (částí) systému.
ZPRÁVA SYSTÉMU„[M] zboží vydané k prodeji nebo k veřejnému představení“ (Princeton University, 2003). Skládá se z jedné nebo více POLOŽEK a doprovodné DOKUMENTACE.
ZMĚNA OVĚŘENÍUrčení, zda výsledek implementace změny splňuje požadavky stanovené dříve (Rigby, 2003).

Kromě jen „změn“ lze rozlišit odchylky a výjimky.[7] Odchylka je oprávnění (nebo žádost o něj) odchýlit se od požadavku na položku před jejím vytvořením. Zřeknutí se je v zásadě stejné, ale než během nebo po vytvoření položky. Na tyto dva přístupy lze pohlížet jako na minimalistickou správu požadavků na změnu (tj. Bez skutečného řešení daného problému).

Příklady

Dobrým příkladem procesu správy žádostí o změnu v akci lze nalézt v vývoj softwaru. Uživatelé často hlásí chyby nebo si přejí nové funkce svých softwarových programů, což vede k změnit požadavek. The software produktu společnost poté prozkoumá technickou a ekonomickou proveditelnost implementace této změny a následně rozhodne, zda bude změna skutečně realizována. Pokud tomu tak skutečně je, musí být změna naplánována, například pomocí funkční body. Skutečné provedení změny vede k vytvoření a / nebo změně softwarový kód a když se tato změna rozšíří, pravděpodobně to způsobí změnu i dalších fragmentů kódu. Poté, co se počáteční výsledky testu zdají uspokojivé, lze dokumentaci aktualizovat a vydat společně se softwarem. Nakonec projektový manažer ověří změnu a uzavře tuto položku v protokolu změn.

Obrázek 2: Příklad žádosti o změnu pro automobilový průmysl

Další typickou oblastí pro správu žádostí o změnu ve způsobu, jakým je zde zacházeno, je výrobní doména. Vezměme si například design a výrobu a auto. Pokud se například zjistí, že se airbagy vozidla automaticky naplní vzduchem po jízdě na dlouhé vzdálenosti, bezpochyby to povede ke stížnostem zákazníků (nebo snad hlášení problémů během fáze testování). Na druhé straně to vytvoří požadavek na změnu (viz obrázek 2 vpravo), který pravděpodobně změnu ospravedlní. Je však třeba provést - s největší pravděpodobností zjednodušující - analýzu nákladů a přínosů, poté bude možné žádost o změnu schválit. Po analýze dopadu na design a výrobní plány automobilů lze vytvořit plánování implementace změny. Podle tohoto plánování může být změna skutečně realizována, a poté bude doufejme důkladně otestována nová verze automobilu, než bude uvedena na veřejnost.

V průmyslových závodech

Vzhledem k tomu, že složité procesy mohou být velmi citlivé i na malé změny, je správná správa změn průmyslových zařízení a procesů považována za zásadní pro bezpečnost. Ve Spojených státech, OSHA má předpisy, které určují, jak mají být změny prováděny a dokumentovány. Hlavním požadavkem je, aby multidisciplinární tým provedl důkladnou revizi navrhované změny, aby bylo zajištěno, že bude použito co nejvíce možných hledisek k minimalizaci šancí na zmeškání rizika. V této souvislosti je správa požadavků na změnu známá jako Správa změn nebo MOC. Je to jen jedna z mnoha součástí Řízení bezpečnosti procesů, oddíl 1910.119 (l). 1

Viz také

Reference

  1. ^ Crnkovic, Asklund & Persson-Dahlqvist, 2003
  2. ^ Dennis, Wixom & Tegarden, 2002.
  3. ^ Hinley 1996.
  4. ^ Huang & Mak, 1999.
  5. ^ A b Vlastně ne oba Vyžadovat novou funkčnost a problém se setkáním mít nastat za účelem získání ŽÁDOST ZMĚNY; obvykle jen jeden ze dvou vůlí. Jejich modelování jako neuspořádaných aktivit se přibližně blíží tomuto významu; alternativou by bylo vytvoření dvou samostatných „výchozích bodů“ (tj. počátečních stavů), přičemž oba by ukazovaly na žádost o změnu.
  6. ^ Weerd 2006
  7. ^ Scott & Nisse, 2001.

Další čtení