Paralelní adopce - Parallel adoption

tento článek obsahuje pokyny, rady nebo návody k obsahu. Účelem Wikipedie je prezentovat fakta, ne trénovat. Prosím pomozte vylepšit tento článek přepsáním obsahu jak na to nebo stěhování to Wikiverzita, Wikibooks nebo Wikislovník. (Září 2014)

Paralelní adopce je metoda přenosu mezi předchozím (TO ) do cílového (IT) systému v organizaci. Aby se snížilo riziko, starý a nový systém běží současně po určitou dobu, po které, pokud jsou splněna kritéria pro nový systém, je starý systém deaktivován. Tento proces vyžaduje pečlivé plánování a kontrolu a značné investice do pracovní doby.

Přehled

Tato položka se zaměřuje na obecný proces paralelního přijetí; V případě potřeby se pro smysluplnější interpretaci procesu používají (reálné) příklady. Kromě toho se pro vizualizaci procesu používá model procesních dat, který má poskytnout úplný přehled o všech krocích zapojených do paralelního přijetí, avšak důraz bude kladen na jedinečné vlastnosti paralelního přijetí. Některé společné charakteristiky, zejména definování implementační strategie, které platí pro všechny čtyři obecné druhy přijetí, jsou popsány v Adopce (implementace softwaru).

Jiné druhy adopce

Kromě paralelního osvojení lze identifikovat další tři obecné druhy osvojení. Volba konkrétní metody adopce závisí na organizačních charakteristikách; další informace o tomto tématu budou uvedeny níže. Další tři metody adopce jsou:Adopce softwaru produktu: Adopce velkého třesku (také známá jako přímá konverze, strategie slam dunk nebo cold-turkey), Postupné přijetí a pilotní přijetí.

• Přijetí softwarového produktu: Přijetí velkého třesku / Přijetí ponorem: Přijetí velkého třesku znamená převod celé organizace ze starého systému na nový v okamžitém přechodu. Toto je nejlevnější možnost, ale pokud nový systém selže, organizace má velké potíže. Otevírá také rizika pro systém, který uživatelé nepřijmou. Může to však být jediný přístup, který lze použít, když tyto dva systémy nemohou koexistovat nebo je aktivace nového systému nouzová.
• Postupná adopce (také známá jako postupná konverze): V implementaci postupného osvojování se organizace postupně převádí na nový systém v různých fázích, podle modulu nebo subsystému. Některé systémy nelze zavést po částech, protože jsou příliš závislé na celém systému. Používání postupného osvojování má menší rizika, ale způsobí největší narušení, protože přechod ze starého systému na nový zabere nejvíce času.
• Pilotní přijetí: Metoda pilotního přijetí se používá pro velké organizace, které mají více poboček nebo převážně nezávislá oddělení. Nový systém je zaveden v jednom z míst nebo oddělení a postupem času je rozšířen o další místa nebo oddělení. (omezená hranice, pokud nový systém selže) (Turban, 2002)

Existuje několik případů, kdy paralelní převod nelze považovat za životaschopnou strategii převodu. Nejprve zvažte, zda nový systém obsahuje významné změny schématu. Datové prvky vyžadované jedním systémem, které nejsou naplněny druhým, mohou vést v nejlepším případě k nepřesnostem v datech a v nejhorším případě k poškození dat. Dalším problémem je, pokud se systém spoléhá na spotřebitelskou technologii (COTS). Pokud dokumentace dodavatele COTS uvádí, že více než jedna aplikace nemůže sdílet stejnou databázi, pak není možný paralelní převod. Příkladem mohou být produkty Oracle Siebel. Jiné produkty COTS mohou také zavádět omezení, pokud opravy nebo velké upgrady vyžadují jedinečné licenční klíče. Po aplikaci mohou provést změny v databázi, které mohou způsobit, že aplikace falešně detekuje paralelní systém běžící proti stejné databázi jako pokus o získání kontroly nad licencováním a tím deaktivaci systému.

Umístěte do procesu implementace

Zdá se, že existuje málo konvencí týkajících se procesu paralelního přijetí. Několik zdrojů (např .: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999) nepoužívá jediný název popisu procesu. Termín paralelní přijetí je v těchto zdrojích označen, i když pro každý zdroj konzistentní jako: paralelní převod, paralelní běh, stínový běh, paralelní výřez a paralelní implementace. Zdá se, že tomu tak je, protože obecný popis procesu nevyžaduje zvláštní klasifikaci. Existuje docela dost standardních implementačních metod, kde jsou popsány různé techniky adopce, ale často v praktickém kontextu; scénář z reálného světa nebo komplexnější sada implementačních technik, jako je Regata: metoda adopce, SIM a PRINCE2. Obecně lze paralelní adopci nejlépe chápat jako a Systémové inženýrství metoda implementace nového systému.

Metoda paralelního přijetí se v zásadě liší od rozhodnutí změnit systém v organizaci a lze ji považovat za jeden z možných prostředků k dosažení tohoto cíle. Existuje však několik faktorů, které se berou v úvahu při určování toho nejlepšího implementace strategie. Úspěšná implementace může navíc do značné míry záviset na metodě přijetí. (Lee, 2004)

Proces

Proces paralelního přijetí nelze představit bez věnování pozornosti krokům před skutečným převodem, konkrétně konstrukci scénáře převodu a identifikaci a testování všech požadavky. Proces je proto vysvětlen procházením všech identifikovaných procesů na obrázku 1 a krátkým řešením společných činností, které jsou nezbytné pro kteroukoli z identifikovaných konverzních strategií.

Obrázek 1 poskytuje přehled procesu paralelního přijetí. Levá strana zobrazuje tok aktivit, které přispívají k procesu. Aktivitám, které běží současně, předchází silná černá čára. Když skončí paralelní běh aktivit, aktivity se znovu spojí podobnou černou čarou. Pokud z aktivity do jiné neexistuje žádná šipka, znamená to, že se jedná o agregace větší aktivity výše. Aktivity jsou rozděleny do čtyř hlavních fází:

• Definujte implementační strategii, který se zabývá druhem implementační strategie, by měl být proveden.
• Před implementací, která souvisí s konstrukcí plánování všech aspektů a požadavků souvisejících s implementací.
• Připravte organizaci Organizace by měla být řádně připravena podle předchozí fáze.
• Konverze zabývá se skutečným procesem převodu a ukončením procesu převodu; pokračuje v novém systému.

Hlavní fáze jsou rozděleny na další činnosti, které budou stručně popsány v tabulkách 1-1 až 1-4.

Pravá strana modelu popisuje data zahrnutá do procesů. Některé z těchto konceptů, které jsou znázorněny jako dvojice překrývajících se otevřených obdélníků, lze rozdělit na více než jeden koncept. Dvojice překrývajících se uzavřených obdélníků označuje uzavřený koncept, což znamená, že jej lze rozdělit na více konceptů, ale pro proces paralelního přijetí to již není zajímavé. Obrázek s kosočtvercovými tvary naznačuje, že koncept, který je s ním spojen, slouží jako agregovaný koncept a že tento koncept se skládá z ostatních konceptů. Nakonec otevřená šipka představuje vztah mezi super třídou a podtřídou. Koncept spojený se šipkou je nadřazenou třídou konceptů, které jsou s ním propojeny. Tato syntaxe na obrázku 1 odpovídá Unified Modeling Language (UML ) standardy. Koncepty na obrázku 1 jsou definovány v tabulce 2. Více kontextů pro tyto dílčí aktivity v procesu bude uvedeno pod tabulkami.

Obrázek 1. Diagram metaprocesních dat paralelního přijetí

Koncepty z obrázku 1 jsou definovány v tabulce 2-1 níže.

Stanovení strategie paralelní implementace

Obrázek 2. implementační strategie

Paralelnímu přijetí předchází stanovení implementační strategie, která není pro paralelní přijetí jedinečná, ale lze ji považovat za součást řízení změn proces, do kterého organizace vstupuje. (Lee, 2004). Některé faktory podílející se na stanovení implementační strategie týkající se metod adopce jsou podrobněji popsány v Adopce (implementace softwaru).

Riziko versus náklady

Důvodem, proč se organizace rozhodla pro paralelní adopci ve prospěch pilotní konverze, velkého třesku nebo postupné adopce, je často kompromis mezi náklady a rizikem (Andersson, Hanson, 2003). Paralelní adopce je nejdražší metodou adopce (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), protože od organizace vyžaduje, aby po určitou dobu paralelně fungovaly dva systémy. Provoz dvou systémů současně znamená investici do Lidské zdroje musí být provedeno. Kromě dobré přípravy (extra) personál, které musí projít stresujícím obdobím paralelního běhu, kdy se postupy navzájem kříží. (Rooijmans, 2003, Eason, 1988) Je třeba vyvinout úsilí na konzistenci dat a prevenci poškození dat mezi těmito dvěma systémy. (Chng et al. 2002, Yusuf, 2004) Nejen pro samotný proces převodu, ale také pro jejich školení v manipulaci s novým systémem.

Pokud je nutné, aby byl nový systém implementován na základě přístupu velkého třesku, je riziko selhání vysoké (Lee, 2004). Když organizace silně požaduje změnu starého (staršího) systému, kompromis mezi extra zahrnutými náklady pro méně riskantní paralelní přístup, by měl být ve prospěch těchto dodatečných nákladů (Lee, 2004), přesto vidíme že přijetí ERP následuje ve většině případů po velkém třesku (Microsoft, 2004, Yusuf, 2004).

To znamená, že organizace by měla jasně přemýšlet o své implementační strategii a integrovat toto rozhodnutí do své Řízení rizik nebo Řízení změn analýza.

Vývoj implementačního skriptu

Obrázek 3. Před implementací

IT požadavky

K řádné přípravě organizace je nutná analýza požadavků jak požadavků IT, tak požadavků organizace. Více informací na analýza požadavků a řízení změn lze najít jinde. Pro paralelní přijetí je nejdůležitějším požadavkem IT (je-li relevantní) pozornost současného provozu obou systémů. Ve fázi převodu je časový slot, kde starý systém je vedoucím systémem. Aby bylo možné přenést data ze starého systému v době dohánění do nového systému, musí být k dispozici přechodový modul (Microsoft, 2004). Jiné implementační metody tento požadavek přímo nemají. Více informací o požadavcích na IT najdete v Softwarové inženýrství.

Organizační požadavky

Kromě IT požadavků vyžadují i ​​organizační požadavky Řízení lidských zdrojů problémy jako, školení personál, vypořádat se s možná změnou Organizační struktura, organická organizace nebo Mechanická organizace charakteristiky organizace (Daft, 1998) a co je nejdůležitější: podpora vrcholového managementu (Brown, Vessey, 1999). Brown a kol. (1999) identifikují dvě odlišné role, které může vrcholový management iniciovat: takzvané role sponzora a šampiona:

• "Sponzor projektu je odpovědný za rozpočtovou podporu a zajištění toho, aby klíčoví zástupci podniků hráli roli v projektovém týmu."
• „Šéf projektu může, ale nemusí být formálním členem projektového týmu, ale může hrát klíčovou roli v úsilí o řízení změn“

Paralelní proces adopce je velmi stresující a vyžaduje dobře připravené zaměstnance, kteří dokážou vypořádat se s chybami, kterých se dopouštějí, aniž by konzervativně dychtili po starém systému. (Eason, 1988)

Časové plánování

Je velmi důležité mít podrobný plán provádění nového systému v organizaci (Lee, 2004, Eason, 1988). Nejdůležitější věcí v časovém plánování paralelní konverze není spěchat a nebát se možných zpoždění ve skutečné fázi konverze. (Lee, 2004). Může být velmi přínosné pracovat také s jasně definovanými milníky (Rooijmans, 2003), podobně jako PRINCE2 metoda. Více informací o časovém plánování najdete v Plánování a Strategické plánování.

Příprava organizace

Obrázek 4. Příprava organizace

Vyhodnocení požadavků

Vyhodnocení požadavků zahrnuje předefinování implementačního skriptu. Měly by být otestovány IT a (pokud je to možné) organizační požadavky. Lze provést některé testy, kde lze vyhodnotit organizační odpovědnost (Rooijmans, 2003) a také požadavky na IT. I zde je opět důležité mít podporu a zapojení vrcholového managementu (Eason, 1988). Pokud neudělají zdroje k vyhodnocení může být implementace neúspěšná jako přímý důsledek. Po tomto vyhodnocení je implementační skript předefinován do explicitnějšího scénáře převodu.

Scénář převodu

Scénář převodu tedy sestává z plánu organizační změny ve všech aspektech. Existují však dvě témata, jimž se v rozsahu paralelního přijetí dosud nedostala pozornosti, kterou si zaslouží.

• Strategie řešení / plán odvolání: Odlišný od ostatních scénářů přijetí je také integrovaný do scénáře převodu řešení nebo pohotovost strategie s a vrácení zpět plán. Strategie řešení je definována v širším rozsahu v jiné položce, ale v této souvislosti označuje, jak je definováno ve výše uvedené tabulce: Plán zálohování; přijatá strategie, ve scénáři převodu zabránit chybám v procesu převodu a pokusit se je obejít, aby implementace mohla být stále úspěšná. (Microsoft, 2004). Plán vrácení zpět, jako jedna z možných strategií řešení, je zahájen, pokud se ve fázi převodu něco pokazí. Jelikož tyto dva systémy běží současně, v paralelním přijetí, plán odvolání naznačuje, že databáze nebo jiný systém, který zpracovává transakce, by měl být ve starém systému plně vysledovatelný (Microsoft, 2004). Ve skutečnosti paralelní přijetí podle definice poskytuje tento plán odvolání díky své povaze vedoucího systému a (vedoucího) záloha Systém.
• Ukazatele kritérií: Vzhledem k tomu, že scénář převodu je plánem provedení převodu těchto dvou systémů, zahrnuje také kvantifikovatelná kritéria. Předefinované IT a organizační požadavky se přenášejí do měřitelných komponent. Pokud kritéria nejsou při převodu testu splněna, měla by být nasazena strategie řešení.

Konverze

Obrázek 5. Konverze

Skutečná fáze převodu je nyní na místě. Během tohoto procesu je organizace ve stresujícím období (Eason, 1988, Rooijmans, 2003). Oba systémy běží paralelně podle scénáře převodu a nový systém je pečlivě sledován. Když budou splněna kritéria nového systému, starý systém přestane být vedoucím systémem a nový systém převezme kontrolu nad ním. Dobytí, která jsou součástí řešení Tato strategie je zálohou starého systému a poskytuje prostředky pro spolehlivostní inženýrství a obnova dat. Existují dva druhy způsobů, jak dohánět: automatické dohánění a dohánění ručně. (Rooijmans, 2003). Případně služba vzdáleného zálohování lze nasadit také.

Kontrolní systém

• Automatické dohánění: Dobytí, která jsou přenášena automatizovaným systémem vytvořeným ve fázi přípravy organizace. Tento systém automaticky přenáší data nebo informace do nového systému, když dojde k převodu ze starého vedoucího systému na nový vedoucí systém. Výhodou automatizovaného systému je, že je rychlý a přesný. Nevýhodou je, že výroba systému přenosu v dřívější fázi vyžaduje čas.
• Ruční dohánění: Pokud skutečná konverze vyžaduje jen malé množství času nebo je složitost informací, které by měly být přeneseny do nového systému, malá, může se organizace rozhodnout přenést úpravy ručně. Výhodou tohoto postupu je, že není třeba, aby systém (softwarový program) přenášel informace a možné problémy, které s tímto druhem přenosového programu přicházejí. Kompromisem je přesnost a čas. Manuální přenos dohonů vyžaduje značné množství času navíc a je citlivější na malé lidské chyby (Rooijmans, 2003). Navíc jsou další investice do pracovní doby již vysoké; manuální systém dohánění vyvíjí na personál ještě větší tlak.

Hodnocení / Praktická relevance

Z případových studií lze vyvodit několik poučení: Případ systému NevV DMV, který popsal Lee (2004), zjistil, že implementace nového procesu může mít také politické důsledky. Když systém, který bude změněn, ovlivní širokou veřejnost a nebude se měnit pouze interní systém, existují další tlaky, které ovlivňují organizaci. V tomto případě se pojmy jako image a pověst společnosti mohou drasticky změnit, pokud zákazníci čelí více zpožděním, například při komunikaci nebo objednávání zboží. Navrhuje se, že pokud je systém politicky citlivý, je třeba věnovat větší pozornost metodě převodu a přednostně je zvoleno paralelní přijetí, protože s sebou nese menší riziko.

Série poznatků získaných z řady skutečných scénářů implementace nového portfoliového systému, prováděných obchodně-poradenskou společností (Venture, 2004), ukazuje několik zajímavých poznatků získaných z praxe. zdá se, že dokonale zapadají do problémů zmíněných pro generický paralelní proces adopce, založený na kombinaci vědecké práce. Shrnout:

• Hodnocení rizik a plánování pro nepředvídané události (náhradní řešení) je velmi důležité
• Přiřaďte role projektového týmu
• Vytvořte konkrétní milníky (jako PRINCE2 ), které zahrnují plány školení a testování
• Identifikujte potenciální rizika a v případě potřeby proveďte pohotovostní plán
• Sdělte stav projektu
• Změny by měly být náležitě autorizovány
• Strategie převodu musí pečlivě prozkoumat požadavky na data
• Nové a změněné údaje by měly být testovány podle pravidel ověřování
• Vytvořte důkladný plán vrácení zpět
• Pokud je to možné, vyjednejte přestavbu pilota

Existují také přinejmenším dvě obtíže s paralelní konverzí, díky nimž může být její použití v 21. století nepraktické, ačkoli se jednalo o jádro průmyslové praxe, když vstupy tvořily balíčky děrných štítků nebo kotouče pásky. Tyto jsou:

1. Je nepraktické očekávat, že koncoví uživatelé, ať už jsou to zákazníci, pracovníci výrobní linky nebo téměř kdokoli jiný, že zadají každou transakci dvakrát prostřednictvím různých rozhraní.

2. Časové rozdíly mezi dvěma víceuživatelskými interaktivními systémy mohou správně přinést různé výsledky, i když oba systémy fungují správně, jsou vnitřně konzistentní a samy by je bylo možné úspěšně použít.

Výsledkem je, že paralelní převod je dnes omezen na několik konkrétních situací, jako jsou účetní systémy, kde je absolutní ověřitelnost výsledků povinná, kde jsou uživatelé všichni interní v organizaci a rozumí tomuto požadavku a kde nelze povolit pořadí činností ovlivnit výstup. V praxi jsou dnes metody pilotního a fázového převodu relevantnější.

Viz také

• Přijetí softwarového produktu: Přijetí velkého třesku
• Postupné přijetí
• Adopce (implementace softwaru)
• Regata: metoda adopce
• Řízení změn
• Spolehlivost inženýrství
• Rollback (správa dat)
• Řízení rizik
• Softwarové inženýrství
• Implementace

Reference

Články

• Andersson I.Hanson, K. (2003). Šíření technologie v softwarové organizaci, Licenční práce v aplikované informační technologii, Univerzita v Goteborgu
• Brown, C.V. & Vessey, I. (1999). Přístupy implementace ERP: Směrem k pohotovostnímu rámci, Sborník z 20. mezinárodní konference o informačních systémech, Charlotte, NC, 13. – 15. Prosince, 411-416.
• Chng, S., a Vathanophas V. (2002). Směrem k mezioborovému podnikovému systému: studie cílové skupiny. 6. tichomořská asijská konference o informačních systémech (PACIS 2002). Tokyo, Japonsko. 2. – 4. Září 2002.
• Lee, O. (2004). Případová studie systému Nevada DMV, Časopis Akademie podnikání a ekonomiky, Svazek 3
• Ribbers, P. & Schoo, K.C. (2002). Navrhování komplexních programů pro implementaci softwaru, 35. výroční mezinárodní konference na Havaji o systémových vědách (HICSS'02), Svazek 8
• Yusuf, Y. & Gunasekaran, A. & Abthorpe M.S. (2004). Implementace projektů podnikových systémů: Případová studie ERP v Rolls Royce. International Journal of Production Economics, 87, 251-266.

Knihy

• Daft, R.L. (1998). Organizační teorie a design. West: International Thomson
• Eason, K. (1988). „Kapitola 9, Implementace a podpora,“ v: Informační technologie a organizační změny. Londýn: Taylor & Francis
• Turban, E. & Mclean, E. & Wetherbe J. (2002) „Kapitola 14, Budování informačních systémů“, v: Informační technologie pro management. New York: John Wiley & Sons, Inc.
• Rooimans, R., Theye, M. de a Koop, R. (2003). Regata: Implementace ICT také jako uitdaging před nebo ve vier-met-stuurman. Haag: Ten Hagen en Stam Uitgevers.

externí odkazy

• Replatformace řady obchodních aplikací ze systému UNIX na Windows. (2004), verze 1.0 Microsoft, Citováno 5. března 2006 [1]
• Implementace systému účetního portfolia: Poučení ze zákopů (2004), Venture Financial Systems Group Ltd.Získaný 6. března 2006 [2]