Anteckning: Principer för att skapa ett informationssystem. Omarbetning av affärsprocesser. Processkartläggning och modellering. Tillhandahåller processen för analys och design av IS med funktionerna i CASE-teknologier. Implementering av informationssystem.

6. Utveckling och implementering av ett informationssystem

6.1. Principer för att skapa ett informationssystem

Många användare av hårdvara och mjukvara har upprepade gånger stött på en situation där programvara som fungerar bra på en dator inte fungerar på en annan liknande enhet. Eller så samverkar inte systemenheterna i en datorenhet med hårdvaran i en annan. Eller så vägrar ett annat företags informationssystem envist att behandla de uppgifter som du tagit fram i informationssystemet på din arbetsplats. Detta problem kallas problemet med kompatibilitet mellan datorer, telekommunikationer och informationsenheter.

Utvecklingen av datorsystem och verktyg, deras utökade implementering inom alla områden av vetenskap, teknik, tjänster och vardagsliv har lett till behovet av att kombinera specifika datorenheter och informationssystem implementerade på deras bas till enhetliga informations- och datorsystem (ICS) och miljöer. Samtidigt stod IVS-utvecklare inför ett antal problem.

Till exempel krävde heterogeniteten hos tekniska medel för datorteknik när det gäller organisationen av beräkningsprocessen, arkitektur, kommandosystem, processorbitkapacitet och databuss etc. skapandet av fysiska gränssnitt som som regel implementerar ömsesidig kompatibilitet av enheter. Med en ökning av antalet typer av integrerade enheter ökade komplexiteten att organisera det fysiska gränssnittet mellan dem avsevärt. Heterogeniteten hos programmerbara miljöer implementerade i specifika datorenheter och system, i termer av variationen av operativsystem, skillnader i bitdjup och andra funktioner, har lett till skapandet av mjukvarugränssnitt mellan enheter och system. Det bör noteras att för att uppnå full kompatibilitet mjukvaruprodukter som utvecklats för en specifik mjukvarumiljö var inte alltid framgångsrika i en annan miljö. Heterogeniteten i kommunikationsgränssnitten i människa-datorsystemet krävde ständig koordinering av mjukvara och hårdvara och omskolning av personal.

Principen om "öppenhet" för informationssystemet

Att lösa kompatibilitetsproblem har lett till utvecklingen av ett stort antal internationella standarder och avtal inom området för tillämpning av informationsteknik och utveckling av informationssystem. Grundbegreppet har blivit begreppet öppna system.

Termen "öppet system" kan nu definieras som "en omfattande och konsekvent uppsättning internationella informationsteknologistandarder och funktionella standardprofiler som specificerar gränssnitt, tjänster och deras stödjande format för att möjliggöra interoperabilitet och mobilitet för mjukvaruapplikationer, data och personal."

Denna definition, formulerad av specialister från IEEE (Institute of Electrical and Electronic Engineers), förenar innehållet i den miljö som ett öppet system tillhandahåller för utbredd användning. För närvarande är det allmänt erkända samordningscentret för utveckling och harmonisering av öppna systemstandarder OASIS (Organisation for the Advancement of Structured Information Standards).

De allmänna egenskaperna hos öppna informationssystem kan formuleras på följande sätt:

utbyggbarhet/skalbarhet: ger möjlighet att lägga till nya IS-funktioner eller ändra några befintliga, samtidigt som de återstående funktionella delarna av IS oförändrades;

mobilitet/portabilitet: säkerställa möjligheten att överföra program och data vid uppgradering eller byte av hårdvaru-IS-plattformar och möjligheten för specialister som använder IT att arbeta med dem utan att omskola dem när de ändrar IS;

interaktion: förmågan att interagera med andra informationssystem (de tekniska medel på vilka informationssystemet implementeras förenas av ett eller flera nätverk på olika nivåer: från lokalt till globalt);

standardiserbarhet: IS utformas och utvecklas på grundval av överenskomna internationella standarder och förslag, öppenhet implementeras på grundval av funktionella standarder (profiler) inom informationsteknologiområdet;

användarvänlighet: utvecklade enhetliga gränssnitt i interaktionsprocesser i "man-maskin"-systemet, vilket gör att en användare som inte har speciell "datorutbildning" kan arbeta.

En ny titt på öppna system bestäms av det faktum att dessa funktioner betraktas tillsammans, som relaterade till varandra, och implementeras i ett komplex, vilket är ganska naturligt, eftersom alla ovanstående egenskaper kompletterar varandra. Endast tillsammans gör kapaciteten hos öppna system det möjligt att lösa problemen med design, utveckling och implementering av moderna informationssystem.

Uppbyggnad av informationssystemmiljön

Den generaliserade strukturen för alla IS kan representeras av två interagerande delar:

funktionell del, inklusive applikationsprogram som implementerar applikationsområdets funktioner;

miljö eller systemdel som säkerställer exekvering av applikationsprogram.

Två grupper av standardiseringsfrågor är nära besläktade med denna uppdelning:

standarder för gränssnitt mellan applikationsprogram och IS-miljön, Application Program Interface (API);

standarder för gränssnitt mellan IS själv och dess yttre miljö (External Environment Interface - EEI).

Dessa två grupper av gränssnitt definierar specifikationerna extern beskrivning IS-miljö - arkitektur, ur slutanvändarens synvinkel, IS-designer, applikationsprogrammerare som utvecklar funktionella delar av IS.

Specifikationer för externa gränssnitt för en IS-miljö och, som kommer att ses nedan, specifikationer för interaktionsgränssnitt mellan komponenter i själva miljön är exakta beskrivningar av alla nödvändiga funktioner, tjänster och format för ett specifikt gränssnitt. Uppsättningen av sådana beskrivningar utgör referensmodellen för öppet system.

Denna modell har använts i över 20 år och definieras av Systems Network Architecture (SNA) som föreslogs av IBM 1974. Den bygger på att dela upp datormiljön i sju nivåer, vars samverkan beskrivs av motsvarande standarder, och säkerställer sammankopplingen av nivåerna oavsett nivåkonstruktionen i varje specifik implementering (fig. 6.1). Den största fördelen med denna modell är en detaljerad beskrivning av anslutningar i miljön ur tekniska anordningar och kommunikationsinteraktioner. Den tar dock inte hänsyn till sammankopplingen med hänsyn till applikationsprogramvarans mobilitet.

Ris. 6.1.

Open Systems Environment Reference Model (OSE/RM) definierar uppdelningen av alla informationssystem i applikationer (applikationsprogram och mjukvarusystem) och miljön i vilken dessa applikationer fungerar. Standardiserade gränssnitt (API) definieras mellan applikationer och miljö och är en nödvändig del av profilerna för alla öppna system. I IS-profiler kan dessutom enhetliga gränssnitt för interaktion av funktionella delar med varandra och interaktionsgränssnitt mellan komponenter i IS-miljön definieras.

Modell för att skapa ett informationssystem

Metodologiskt är det viktigt, tillsammans med de övervägda modellerna av IS-miljön, att föreslå en modell för att skapa ett IS som skulle ha samma aspekter av funktionella grupper av komponenter (användare, funktioner, data, kommunikation). Detta tillvägagångssätt kommer att ge en komplett process för design och stöd i alla skeden av IS-driften och möjligheten till ett välgrundat val av standarder för systemutveckling och projektdokumentation.

Ett företag är en komplex ontologisk (konceptuell) struktur, bestående av en viss uppsättning enheter och relationer (fig. 6.2).

Samspelet mellan dess element, bestämt av affärslogik och inskrivet i en uppsättning affärsregler, är företagets aktiviteter. Informationssystemet "reflekterar" logik och regler, organiserar och transformerar informationsflöden, automatiserar processerna för att arbeta med data och information och visualiserar resultaten i form av uppsättningar av rapporteringsformulär. Därför bör du först skapa en affärsmodell för företaget, som är en återspegling av företaget och dess informationshanteringssystem.

När man skapar en modell bildas ett "kommunikationsspråk" mellan företagschefer, konsulter, utvecklare och framtida användare, vilket gör att de kan utveckla en enhetlig idé om VAD och HUR ett företagsledningssystem (företagsledningssystem) ska göra. En sådan affärsmodell är ett påtagligt resultat, med hjälp av vilket du kan specificera målen för IS-implementering så mycket som möjligt och bestämma följande projektparametrar:

• huvudsakliga affärsmål som kan uppnås genom processautomation;
• lista över platser och sekvens av implementering av IS-moduler;
• faktiska behov av volymer av köpt mjukvara och hårdvara;
• verkliga uppskattningar av tidpunkten för utbyggnad och lansering av IMS;
• nyckelanvändare av IS och en uppdaterad lista över implementeringsteammedlemmar;
• graden av överensstämmelse hos den applikationsprogramvara du väljer med specifikationerna för ditt företags verksamhet.

Modellen är alltid baserad på företagets affärsmål, som helt bestämmer sammansättningen av alla de grundläggande komponenterna i modellen:

• affärsfunktioner, som beskriver VAD verksamheten gör;
• kärn-, stöd- och ledningsprocesser som beskriver HUR företaget utför sina affärsfunktioner;
• organisatorisk och funktionell struktur som bestämmer VAR affärsfunktioner och affärsprocesser utförs;
• faser som bestämmer NÄR (i vilken ordning) vissa affärsfunktioner ska implementeras;
• roller som avgör WHO som utför affärsfunktioner och WHO är "mästaren" över affärsprocesser;
• regler som definierar sambandet och interaktionen mellan alla VAD, HUR, VAR, NÄR och VEM.

Efter att ha byggt upp en affärsmodell (eller parallellt med denna) kan du börja bilda en modell för design, implementering och implementering av själva IS (Fig. 6.3).

Erfarenheten av att skapa och använda "anpassad" IS tillåter oss att grovt identifiera följande huvudstadier av deras livscykel:

• definiera systemkrav och analysera dem - bestämma vad systemet ska göra;
• design - bestämma hur systemet kommer att göra vad det är tänkt att göra; design är först och främst en specifikation av delsystem, funktionella komponenter och sätt för deras interaktion i systemet;
• utveckling - skapande av funktionella komponenter och individuella delsystem, anslutning av delsystem till en enda helhet;
• testning - kontroll av systemets funktionella överensstämmelse med de indikatorer som fastställdes i analysstadiet;
• implementering - installation och driftsättning av systemet;
• drift - den normala operationsprocessen i enlighet med IS:s huvudmål och mål;
• support - säkerställa den normala processen för drift av systemet på kundens företag.

Att fastställa systemkrav och analys är det första steget av att skapa ett IS, där kundens krav förtydligas, avtalas, formaliseras och dokumenteras. Faktum är att i detta skede ges svaret på frågan: "Vad är informationssystemet avsett för och vad ska det göra?" Det är här nyckeln till framgången för hela projektet ligger.

Målet med systemanalys är att omvandla generell, vag kunskap om den ursprungliga domänen (kundkrav) till exakta definitioner och specifikationer för utvecklare, samt generera en funktionsbeskrivning av systemet. I detta skede bestäms och specificeras följande:

• externa och interna driftsförhållanden för systemet;
• funktionell struktur av systemet;
• fördelning av funktioner mellan en person och systemet, gränssnitt;
• krav på tekniska, informations- och mjukvarukomponenter i systemet,
• kvalitets- och säkerhetskrav;
• sammansättning av teknisk dokumentation och användardokumentation;
• villkor för genomförande och drift.

Utvecklingen av ovanstående specifikationer när man skapar en IS avsedd att automatisera hanteringsprocesser går i allmänhet igenom fyra steg.

Det första steget i analysen - strukturell analys av företaget - börjar med en studie av hur företagsledningssystemet är organiserat, med en granskning av ledningssystemets funktions- och informationsstruktur och identifiering av befintliga och möjliga konsumenter av information.

Baserat på resultaten av undersökningen bygger analytikern i det första skedet en generaliserad logisk modell av det ursprungliga ämnesområdet, som återspeglar dess funktionella struktur, funktioner i huvudaktiviteten och informationsutrymmet där denna aktivitet utförs (fig. 6.4) ). Baserat på detta material bygger analytikern en funktionell modell "As Is" (As Is).

Det andra steget i arbetet, där intresserade representanter för kunden, och vid behov oberoende experter, nödvändigtvis är involverade, består av att analysera modellen "I befintligt skick", identifiera dess brister och flaskhalsar och identifiera sätt att förbättra ledningssystemet. baserat på de identifierade kvalitetskriterierna.

Det tredje steget av analys, som innehåller designelement, är skapandet av en förbättrad generaliserad logisk modell som visar det omorganiserade ämnesområdet eller en del av det som är föremål för automatisering - "As To Be"-modellen.

Processen (fjärde steget) avslutas med utvecklingen av en "Automationskarta", som är en modell av ett omorganiserat ämnesområde, på vilket "automationsgränserna" nödvändigtvis anges.

I de flesta fall förbättras "As Is"-modellen av systemanalytikern genom att eliminera uppenbara inkonsekvenser och flaskhalsar, och den sålunda erhållna versionen av modellen betraktas vidare som en preliminär "As It Should Be"-modell, som sedan kompletteras i i enlighet med strategin för företagsutveckling (Fig. .6.5).

I stadiet för att analysera kraven för det designade systemet introduceras följande:

• användarklasser och motsvarande affärstransaktionsdiagram;
• modeller (diagram) av tillämpade aktivitetsprocesser och motsvarande listor över funktionella IS-uppgifter;
• klasser av domänobjekt och motsvarande entitetsrelationsdiagram som återspeglar informationsmodellen för denna ämnesdomän;
• topologi för placeringen av avdelningar och användare som betjänas av denna IS;
• parametrar för att skydda data, information och själva systemet.

Huvuddokumentet som återspeglar resultaten av det första steget av att skapa ett IS är referensvillkoren för projektet (utveckling), som förutom ovanstående definitioner och specifikationer också innehåller information om ordningen för att skapa systemet, information om tilldelade resurser, måldatum för enskilda arbetsmoment, organisatoriska rutiner och aktiviteter för acceptans av etapper, skydd av designinformation m.m.

Nästa steg är design. I verkliga förhållanden är design en sökning och modellering av en utvecklingsmetod som uppfyller kraven på systemfunktionaliteten med hjälp av tillgänglig teknik, med hänsyn till de givna initiala villkoren och begränsningarna. Design av informationssystem börjar alltid med att definiera syftet med projektet. Huvuduppgiften för ett framgångsrikt projekt är att säkerställa att det vid tidpunkten för systemstart och under hela dess drift är möjligt att säkerställa:

• den erforderliga funktionaliteten hos systemet och graden av anpassning till de förändrade driftsförhållandena;
• erforderlig systemgenomströmning och minsta systemsvarstid på en begäran;
• problemfri drift av systemet i önskat läge, beredskap och tillgänglighet för systemet för att behandla användarförfrågningar;
• enkel drift och underhåll av systemet;
• nödvändig datasäkerhet och användarrättigheter.

Prestanda och tillförlitlighet är de viktigaste faktorerna som avgör systemets effektivitet. Bra design är grunden för ett högpresterande system.

Informationssystemdesign täcker tre huvudområden:

• designa datastrukturer som kommer att implementeras i databasen;
• designa program, skärmformulär, rapporter som säkerställer utförandet av dataförfrågningar;
• design av en specifik miljö eller teknologi, nämligen: nätverkstopologi, hårdvarukonfiguration, använd arkitektur, parallell bearbetning, distribuerad databehandling, etc.

Baserat på resultaten av systemanalysen i det preliminära projektstadiet utvecklas följande:

• projekt för implementering av mjukvara och hårdvara, projekt för användargränssnitt och teknik för användare att arbeta i systemet;
• specifikationer för distribuerad systemarkitektur och telekommunikationsnätverk;
• dataflödesmodeller (diagram);
• funktionella blockscheman över applikations- och systemprogramvara (den senare i enlighet med accepterade IS-miljömodeller och standardprofiler).

Det preliminära konstruktionsstadiet kan innebära att prototypdelar som är viktiga ur användarens synvinkel för att testa att de uppfyller kraven tidigt i utvecklingsfasen.

I detaljdesignstadiet utvecklas följande:

• komplex av funktionella IS-program och projektet för implementering av IS-miljön;
• datastrukturer, verktyg för databasunderhåll;
• nätverksadresser, telekommunikationsprotokoll och andra komponenter i informationsutbytesmiljön som ingår i den designade IS;
• regler för begränsning av användaråtkomst och sätt att implementera dem.

IS implementeringsstadiet innebär utveckling och testning av komponenter och omfattande testning av systemet.

Drift- och underhållssteget innebär att övervaka IS:s funktion, att göra nödvändiga ändringar i informationsbasen under det pågående arbetet och att uppgradera IS-funktionerna av applikationsspecialister med hjälp av verktyg inbyggda i systemet.

Stadierna för utveckling, testning, implementering, drift och underhåll av en IS förenas av termen implementering. Implementering av IP är en extremt komplex flerdimensionell process som utförs på basis av uppsättningar (profiler) av harmoniserade internationella standarder, specifikationer och avtal. Denna praxis är en garanti för att det skapade informationssystemet kommer att implementeras som ett "öppet system". Med andra ord kommer en sådan IS att vara skalbar, mobil, portabel, ha användarvänliga gränssnitt osv.

Ett informationssystems livscykel är utformad i enlighet med principen om top-down design och är som regel av spiral-iterativ karaktär. De implementerade stadierna, med start från de tidigaste, upprepas cykliskt i enlighet med förändringar i krav och yttre förhållanden, införande av ytterligare restriktioner etc. I varje skede av livscykeln genereras en viss uppsättning tekniska lösningar och dokument, och för varje steg antas de initiala dokumenten och lösningarna i föregående steg. Livscykeln för en IS slutar när dess mjukvara och tekniska support upphör.

6.2. Omarbetning av affärsprocesser

Införandet av informationsteknik och informationssystem som implementeras på grundval av dem i ett företags dagliga verksamhet ger det taktiska och långsiktiga affärsfördelar. Ledningens önskan att använda IT kan bara förbli goda avsikter om den inte följer uppställda krav och regler för utveckling, design och implementering av IT. Ovan pratade vi om de grundläggande kraven för standardisering av objekt och funktionella uppgifter, utan vilka det implementerade systemet inte kommer att vara ett öppet system, vilket sedan kommer att leda till många problem under dess implementering och drift.

Att följa standardernas krav när man utvecklar en IS leder automatiskt till det faktum att företaget självt - den externa miljön för IS - också uppfyller de nödvändiga kraven: definition och standardisering av klasser av användare och objekt, topologi för dataflöden och arbete, arkitektur av ärvda och utvecklade delsystem, tillstånd för affärsprocesser och etc.

En affärsprocess är ett system av sekventiella, ändamålsenliga och reglerade aktiviteter, där man genom kontrollinflytande och med hjälp av vissa resurser, särskild tid processinsatser omvandlas till output - till resultat som är värdefulla för konsumenten och ger vinst till tillverkaren.

En standardiserad företagsövergripande affärsprocess implementeras som ett nätverk av huvud-, hjälp-, stöd- och ledningsprocesser (Fig. 6.6).

Samtidigt beror uppdelningen i huvud- och hjälpprocesser i viss mån på ämnesområdet och inriktningen av företagets verksamhet: för ett tillverkningsföretag är till exempel den juridiska avdelningens verksamhet hjälpmedel, och för en juridisk resp. konsultföretaget är de främsta. Processidentifiering är nödvändig förutsättning, utan genomförandet av vilken informationsinformation av aktiviteter är omöjlig.

Företagschefer som har bestämt sig för att implementera IT måste verkligen förstå att början av arbetet med att designa ett informationssystem oftast innebär obligatorisk omstrukturering av affärsprocesser! Reengineering representerar många metoder och rekommendationer, bland dem måste du välja de som det bästa sättet uppfylla de uppsatta målen.

Omstrukturering av affärsprocesser är en uppsättning metoder och åtgärder som används för att omdesigna processer i enlighet med förändrade förutsättningar för den externa och interna miljön och/eller affärsmål.

Det finns flera grundläggande regler som bör följas under rekonstruktionsprocessen:

• utveckling av konsekventa steg-för-steg-procedurer för processomdesign;
• användning av standardspråk och notationer i design;
• förekomsten av heuristiska och pragmatiska indikatorer som gör det möjligt att bedöma eller mäta i vilken grad den omdesignade processen eller funktionaliteten uppfyller de specificerade målen;
• strategin för att lösa särskilda problem och deras helhet bör vara systematisk;
• även en liten förbättring bör ha en snabb positiv effekt.

Omarbetning av affärsprocesser och funktioner börjar med en genomgång av företagets mål, dess struktur, analys av behoven hos interna användare och marknaden, producerade produkter och tjänster (fig. 6.7).

Omplanering av mål och mål innebär att revidera företagets policy och svara på följande frågor:

• Vilka nya utmaningar ställer de förändrade affärsvillkoren oss inför?
• Vad representerar företaget nu och vad vill vi ha av det i framtiden?
• Vilken typ av konsumenter betjänar vi, hur mycket tillfredsställer vi deras krav och förväntningar, och vad behöver göras för att attrahera nya?
• Vilka specifika indikatorer avgör ett företags effektivitet, arbetsproduktivitet och produktkvalitet. Är denna definition komplett och adekvat?
• Vilka informationsteknologier och verktyg kommer att hjälpa oss med detta?

För att besvara dessa nyckelfrågor är det först och främst nödvändigt att utföra en detaljerad beskrivning av företagets affärsarkitektur, dess affärslogik, bygga en funktionell modell för samspelet mellan affärsprocesser, resurser och personal och återspegla det i IS-arkitekturen, innehållet i moduler av informationsdelsystem och visualisering av informationspresentationsformer. Det är också nödvändigt att ha metoder och verktyg för att omorganisera processer, lösa tillämpade problem och leda ett reengineering-projekt (Fig. 6.8). Beskrivning av företagets affärsarkitektur låter dig:

• bygga ett diagram över de viktigaste flödena av data, arbete, förflyttning av ekonomi och dokument;
• förstå hur information distribueras mellan avdelningar och vem som är slutanvändaren i en viss affärsprocess;
• beskriva samspelet mellan processer och moduler i informationssystemet;
• fastställa den kritiska betydelsen av typer av information för specifika nivåer av företagsledning;
• identifiera dubbla strukturer och kopplingar.

Resultatet av denna beskrivning är:

• förfinad processnätverkskarta;
• matris av relationer mellan processer och avdelningar som är involverade i dessa processer;
• information om vilka automationssystem som finns, i vilka verksamheter de används, var och vilka data som används, vilka automations- och informationssystem som behöver utvecklas;
• funktionsdiagram över dataflöden (Data Flow), arbetsflöden (Work Flow), finansiella flöden (Cash Flow), ledningseffektflöden (Control Flow) och dokumentflöde (Doc Flow).

En funktionell modell kommer att hjälpa till att skapa exakta specifikationer för alla operationer, procedurer och relationer mellan dem. En sådan modell, om den är konstruerad på rätt sätt, ger en omfattande beskrivning av den fungerande processen och all informationsflöden inom den. Denna modell beskriver tillståndet "I befintligt skick". Baserat på resultaten av analysen av möjliga förbättringssätt är det nödvändigt att gå från den verkliga modellen till en modell som kännetecknar förbättringar - "As To Be"-modellen, alternativ - "As It Should Be" (Fig. 6.9). .

Funktionell modellering är ett ganska allvarligt problem. Den konstruerade modellens fullständighet och överensstämmelse beror både på modelleringsverktygen och på kvalifikationerna hos de specialister som utför denna modellering.

Omstrukturering av affärsprocesser är ett komplext och mångfacetterat projekt som kräver noggrann planering och utarbetande av detaljer. Tabell 6.1 visar huvudstadierna av omkonstruktion.

6.3. Processkartläggning och modellering

Idag har tre huvudsakliga funktionella modelleringsmetoder (och deras medföljande verktyg) blivit utbredda: IDEF (Integrated DEFinition), UML (Unified Modeling Language) och ARIS (Architecture of Integrated Information Systems). För var och en av dem finns det vissa mjukvaruprodukter som, förutom utveckling, låter dig utföra transformationer och operationer för efterföljande arbete med de resulterande modellerna. De mest använda idag är IDEF-metoderna och BPWin-programvaran, som innehåller metoderna IDEF0, IDEF3, DFD (Data Flow Diagrams) och ERWin (IDEF1x) från Computer Associates.

Historien om IDEF-metoden börjar på 70-talet av 1900-talet med SADT-metoden (Structured Analysis and Design Technique) utvecklad av Douglas Ross (Softtech INC). SADT användes ursprungligen av det amerikanska försvarsdepartementet för praktisk processmodellering som en del av programmet ICAM (Integrated Computer Aided Manufacturing). Det grundläggande kravet vid utvecklingen av den familj av metoder som övervägdes var möjligheten till ett effektivt utbyte av information mellan alla specialister som deltog i ICAM-programmet (Icam DEFinition). Denna metod omvandlades sedan till IDEF0-standarden (Function Modeling, FIPS nr. 183). IDEF-familjen inkluderar redan nämnda IDEF3 (Process Description Capture) och IDEF1x (Data Modeling, FIPS nr. 184).

Efter publiceringen av standarderna användes de framgångsrikt inom en mängd olika affärsområden, och visade sig vara ett effektivt sätt att analysera, designa och visa affärsprocesser (förresten, det används också aktivt i inhemska statliga myndigheter, för till exempel i Skatteinspektionen). Dessutom är den utbredda användningen av IDEF (och den tidigare SADT-metoden) ansvarig för framväxten av grundidéerna i det nu populära konceptet "Business Process Reengineering" (BPR).

Informationsprocessen är en hållbar process (en sekvens av arbeten och handlingar med data och information) relaterad till stöd för ett företags produktion och ekonomiska aktiviteter och vanligtvis fokuserad på informationstjänster för att skapa nytt värde. En affärsprocess inkluderar en hierarki av sammanhängande funktionella aktiviteter som implementerar ett (eller flera) affärsmål för företaget och återspeglar resultaten i informationssystemet, till exempel informationsstöd för hantering och analys av produktproduktion eller resursstöd för produktproduktion (produkter betyder här varor, tjänster, beslut, dokument).

Arbetet med IDEF-metoden börjar med att sätta ett modelleringsmål. Världserfarenhet visar att fel i målsättningen leder till i genomsnitt 50 % misslyckanden i modelleringsprocessen. Att formulera ett mål styr initialt arbetet i en given riktning och begränsar därför utbudet av frågor för analys. Det praktiska arbetet börjar med att definiera sammanhanget (Context, Context Diagram), det vill säga systemets översta nivå, i vårt fall företaget. Efter att ha formulerat målet är det nödvändigt att beskriva modelleringsområdet (Scope), som därefter kommer att bestämma de allmänna rörelseriktningarna och detaljdjupet (Decomposition). I själva verket definierar IDEF-metoden själv standardiserade objekt för drift och visning. Dessa inkluderar till exempel en funktion (Aktivitet), en gränssnittsbåge (Pil), en anteckning (Note), såväl som metoden för deras placering och tolkning (Semantik).

I Nyligen Mjukvaruprodukten Business Studio har dykt upp på den ryska marknaden, som är speciellt skapad för att arbeta med IDEF-metoder och har ett intuitivt och användarvänligt gränssnitt (User-friendly Interface).

IDEF0-beteckningen och metodiken är baserad på konceptet "block", det vill säga en rektangel som uttrycker en viss affärsfunktion (Figur 6.10). I enlighet med standarden måste en funktion uttryckas med en verbfras I IDEF0 är rollerna för rektangelns sidor (funktionella betydelser) olika: översidan har betydelsen "kontroll", den vänstra sidan betyder "input". ”, den högra sidan betyder ”utgång”, undersidan betyder ”utförandemekanism”.

Den andra delen av metodiken och notationen är "flödet", som kallas "gränssnittsbågen" i standarden. Detta är ett element som beskriver data, informell kontroll eller något annat som påverkar funktionen som visas av blocket. Strömmar indikeras med en substantivfras.

Beroende på vilken sida av blocket flödet riktas till kallas det följaktligen för "ingång", "utgång", "kontroll". Det figurativa elementet som representerar flöde är en pil. En ström kan tolkas som en representation av ett objekt, vilket förstås som informationsobjekt, och ett verkligt fysiskt föremål.

En viktig faktor är att "källan" och "destinationen" för flöden (det vill säga början och slutet av pilen) som regel bara kan vara block. I det här fallet kan endast utgångssidan av blocket vara källan, och vilken som helst av de återstående tre kan vara mottagaren. Om det är nödvändigt att betona flödets externa natur, kan "tunneling" -metoden användas - dölja eller visa gränssnittsbågen från "tunneln".

Och slutligen, den "tredje pelaren" i IDEF0-metoden är principen om funktionell nedbrytning av block, vilket är en modelltolkning av den praktiska situationen att varje åtgärd (särskilt något så komplext som en affärsprocess) kan brytas ner (nedbrytas) till enklare operationer (åtgärder, affärsfunktioner). Eller, med andra ord, en handling kan representeras som en uppsättning elementära funktioner.

Ett exempel på en funktionell modell av processen för leverans och leverans av produkter visas i fig. 6.11.

Graden av formalisering av beskrivningen av affärsprocesser kan variera beroende på vilka uppgifter som löses. Ett specialiserat språk BPEL (Business Process Execution Language) har utvecklats för att beskriva informationsprocesser. BPEL är baserat på XML för att formellt beskriva affärsprocesser och protokoll för deras interaktion med varandra. BPEL utökar interaktionsmodellen för webbtjänster till att omfatta transaktionsstöd.

För närvarande utvecklas BPMS-metoden (Business Process Management System) aktivt - en klass av programvara för att hantera affärsprocesser och administrativa regler. (Termen BPM-system och helt enkelt BPM används också). Genom att använda BPMS kan du organisera effektiv interaktion mellan chefer och IT-specialister, utnyttja befintliga delsystem bättre och påskynda utvecklingen av nya.

BPMS huvudfunktioner är modellering, utförande och övervakning av affärsprocesser. Baserat på övervakningsdata identifierar företag flaskhalsar och förbättrar sina affärsprocesser. Ledningscykeln är sluten när, med hjälp av BPMS, förändrade affärsprocesser snabbt sätts i drift.

Moderna metoder för att designa och utveckla IS-mjukvara försöker helt fokusera på möjligheterna med automatiserade, operativa förändringar. Den svåraste processen visade sig vara standardiseringen av BPEL-språket för att förena användningen av samma konstruktioner av programvara från olika tillverkare. IBM och Microsoft har definierat två ganska lika språk: WSFL (Web Services Flow Language) respektive Xlang.

Den växande populariteten för BPML och den öppna rörelsen av BPMS till användare ledde Intalio Inc., IBM och Microsoft till beslutet att kombinera dessa språk till nytt språk BPEL4WS. I april 2003 bidrog BEA Systems, IBM, Microsoft, SAP och Siebel Systems med BPEL4WS version 1.1 till OASIS för standardisering i Web Services BPEL Technical Committee. Även om BPEL4WS dök upp i versionerna 1.0 och 1.1, röstade WS-BPEL OASIS tekniska kommitté den 14 september 2004 för att kalla specifikationen WS-BPEL 2.0. Denna ändring gjordes för att anpassa BPEL till andra webbtjänststandarder som, baserat på namnkonventionen, börjar med bokstäverna "WS-".

Active Endpoints Corporation, Adobe, BEA, IBM, Oracle och SAP publicerade konsensusspecifikationer BPEL4 People och WS-HumanTask, som beskrev hur interaktionen av processer med människor kunde implementeras i systemet och BPEL-notationer. Det förväntas att semantik kommer att läggas till BPEL i form av WS-HumanTask och diverse andra tillägg.

6.4. Tillhandahåller processen för analys och design av IP med funktionerna i CASE-teknologier

Termen CASE (Computer Aided Software/System Engineering) används för närvarande i en mycket vid mening. Ursprunglig betydelse termen CASE, begränsad till frågor om automatisering av enbart utveckling av programvara, har för närvarande förvärvats ny mening, som täcker processen att utveckla komplexa IS i allmänhet.

Nu syftar termen CASE-verktyg på mjukvaruverktyg som stödjer processerna för att skapa och underhålla IS, inklusive analys och formulering av krav, design av applikationsprogramvara (applikationer) och databaser, kodgenerering, testning, dokumentation, kvalitetssäkring, konfigurationshantering och projekt förvaltning, såväl som andra processer. Således bildar moderna CASE-verktyg tillsammans med systemmjukvara och teknisk support en komplett IS-utvecklingsmiljö.

Framväxten av CASE-teknologi och CASE-verktyg föregicks av forskning inom området programmeringsmetodik. Programmering har fått funktioner systematiskt tillvägagångssätt med utveckling och implementering av högnivåspråk, metoder för strukturerad och modulär programmering, visuell modellering och designverktyg baserade på UML (Unified Modeling Language), verktyg för deras stöd, formella och informella språk för att beskriva systemkrav och specifikationer , etc. Dessutom underlättades framväxten av CASE-teknik också av sådana faktorer som:

• utbilda analytiker och programmerare mottagliga för begreppen modulär och strukturerad programmering;
• utbredd användning och konstant tillväxt i datorprestanda, vilket gjorde det möjligt att använda effektiva grafiska verktyg och automatisera de flesta designstadier;
• införandet av nätverksteknik, vilket gjorde det möjligt att kombinera enskilda utförares ansträngningar till en enda designprocess genom att använda en delad databas som innehåller nödvändig information om projektet.

CASE-teknologin är en IS-designmetodik, såväl som en uppsättning verktyg som låter dig visuellt modellera ett ämnesområde, analysera denna modell i alla stadier av IS-utveckling och underhåll och utveckla applikationer i enlighet med användarnas informationsbehov. De flesta befintliga CASE-verktyg är baserade på metoder för strukturell (för det mesta) eller objektorienterad analys och design, med specifikationer i form av diagram eller texter för att beskriva externa krav, kopplingar mellan systemmodeller, systembeteendedynamik och mjukvaruarkitektur [Vendrov A. M. , http://www.citforum.ru/database/case/index.shtml].

CASE-verktyg låter dig skapa inte bara en produkt som är praktiskt taget redo att användas, utan också säkerställa den "korrekta" processen för dess utveckling. Teknikens huvudmål är att separera mjukvarudesign från dess kodning, montering, testning och att "dölja" så mycket som möjligt för framtida användare alla detaljer om mjukvaruutveckling och drift. Samtidigt ökar konstruktörens arbetseffektivitet avsevärt: utvecklingstiden minskar, antalet programvarufel minskar och programvarumoduler kan användas i framtida utvecklingar.

De flesta CASE-verktyg är baserade på metodiken/metoden/notationen/strukturen/verktygsparadigmet.

Metodiken anger riktlinjer för att utvärdera och välja ett programvaruutvecklingsprojekt, stadier och arbetssekvens samt regler för tillämpning av vissa metoder.

Metod - en systematisk procedur eller teknik för att generera beskrivningar av programvarukomponenter (till exempel beskrivningar av flöden och datastrukturer).

Notationer är avsedda att beskriva systemet som helhet, dess element: grafer, diagram, tabeller, blockdiagram, algoritmer, formella språk och programmeringsspråk.

Strukturer är ett sätt att implementera strukturanalys och konstruera strukturen för ett specifikt system.

Verktyg - tekniska och mjukvaruverktyg för att stödja och förbättra metoder.

CASE-tekniker har följande huvudsakliga fördelar, vilket gör att de kan användas i stor utsträckning vid utvecklingen av informationssystem:

• påskynda processen för kollektiv design och utveckling;
• låter dig skapa en prototyp av ett beställt system med specificerade egenskaper på kort tid;
• befria utvecklaren från rutinarbete och lämna tid för kreativitet;
• säkerställa effektiviteten och kvaliteten på utvecklad programvara genom att automatisera kontrollen av hela utvecklingsprocessen;
• stödja underhåll och utveckling av systemet på hög nivå.

Det bör noteras att, trots alla potentiella möjligheter hos CASE-verktyg, finns det många exempel på deras misslyckade implementering, som ett resultat av vilket CASE-verktyg blir "hylla"-mjukvara.

I detta avseende måste följande beaktas:

• CASE-remedies ger inte nödvändigtvis en omedelbar effekt det kan endast erhållas efter en tid;
• de verkliga kostnaderna för att implementera CASE-verktyg överstiger vanligtvis kostnaderna för att köpa dem;
• CASE-verktyg ger möjligheter till betydande fördelar först efter framgångsrik implementering, effektiv användarutbildning och regelbunden användning.

Du kan också lista följande faktorer som gör det svårt att avgöra den möjliga effekten av att använda CASE-verktyg:

• ett brett utbud av kvalitet och kapacitet hos CASE-verktyg;
• relativt kort tid att använda CASE-verktyg i olika organisationer och bristande erfarenhet av deras användning;
• stor variation i genomförandepraxis för olika organisationer;
• brist på detaljerade mätvärden och data för redan avslutade och pågående projekt;
• brett spektrum av ämnesområden för projekt;
• varierande grad av integration av CASE-verktyg i olika projekt.

Vissa analytiker tror att de verkliga fördelarna med att använda vissa typer av CASE-verktyg först kan realiseras efter ett eller två års erfarenhet. Andra tror att påverkan faktiskt kan inträffa under driftfasen av IS livscykel, när tekniska förbättringar kan leda till lägre driftskostnader.

Nedan listas huvudtyperna och arbetssekvensen som rekommenderas vid konstruktion av logiska modeller för ett ämnesområde inom ramen för CASE-tekniken för att analysera ett företagsledningssystem.

1. Genomföra en funktions- och informationsundersökning av företagets ledningssystem (administrativa och administrativa aktiviteter) (Fig. 6.1.2):
   • fastställande av företagets organisationsstruktur;
   • bestämning av företagets funktionella struktur;
   • fastställande av listan över målfunktioner för strukturella element (avdelningar och tjänstemän);
   • bestämma omfattningen och ordningen för inspektionen av de strukturella delarna av kontrollsystemet i enlighet med de formulerade målfunktionerna;
   • inspektion av verksamheten för de utvalda strukturella elementen;
   • konstruktion av ett FD-diagram av ett styrsystem som indikerar strukturella element och funktioner, vars implementering kommer att modelleras på DFD-nivå.
2. Utveckling av verksamhetsmodeller för strukturella element och ledningssystemet som helhet:
   • identifiera en mängd externa objekt som har en betydande inverkan på aktiviteten hos ett strukturellt element;
   • specifikation av in- och utdataflöden;
   • identifiering av huvudprocesserna som bestämmer aktiviteten hos det strukturella elementet och säkerställa genomförandet av dess målfunktioner;
   • specificering av informationsflöden mellan de huvudsakliga verksamhetsprocesserna, förtydligande av kopplingar mellan processer och externa objekt;
   • bedömning av volymer, intensitet och andra nödvändiga egenskaper hos informationsflöden;
   • utveckling av en hierarki av dataflödesdiagram som bildar en funktionell modell av aktiviteten hos ett strukturellt element;
   • kombinera DFD-modeller av strukturella element till en enda modell av ett företagsledningssystem.
3. Utveckling av informationsmodeller för strukturella element och en modell av informationsutrymmet för kontrollsystemet:
   • definiera modellenheter och deras attribut;
   • utföra attributanalys och optimering av enheter;
   • identifiera relationer mellan enheter och definiera typer av relationer;
   • analys och optimering av informationsmodellen;
   • kombinera informationsmodeller till en enda modell av informationsutrymmet.
4. Utveckling av förslag för automatisering av företagsledningssystemet:
   • bestämma gränserna för automatisering - sammanställa en lista över automatiserade strukturella element, dela upp processerna för kärnaktiviteter i automatiska, automatiserade och manuella;
   • sammanställa en lista över delsystem och logiska arbetsstationer (automatiserade arbetsstationer), fastställa sätt för deras interaktion;
   • utveckling av förslag för ordningen för design och implementering av delsystem och individuella logiska arbetsstationer som ingår i IS;
   • utveckling av krav på grundläggande tekniskt stöd för informationssystem;
   • utveckling av krav för grundläggande IS-mjukvara.

En logisk modell som återspeglar verksamheten i företagsledningssystemet och informationsutrymmet där denna aktivitet äger rum representerar en "ögonblicksbild" av tillståndet (funktionell struktur, tjänstemäns roller, interaktion mellan avdelningar, accepterad teknik för bearbetning av ledningsinformation , automatiserade och icke-automatiserade processer etc. .) vid tidpunkten för examinationen. Denna modell låter dig förstå vad företaget gör och hur det fungerar utifrån systemanalys, och att formulera förslag för att förbättra situationen.

Utvecklingen av en logisk modell för ämnesområdet, dess konsekventa omvandling till en modell av mål-IS, kommer att möjliggöra integration av lovande förslag från ledning och ledande anställda i företaget, experter och systemanalytiker, och att bilda en vision om företagets nya, omorganiserade och automatiserade verksamhet (fig. 6.12).

Den konstruerade modellen är ett komplett resultat av följande skäl.

1. Den innehåller en modell av den befintliga manuella tekniken som antagits av företaget. En formell analys av denna modell gör det möjligt för oss att identifiera flaskhalsar i företagsledning och formulera rekommendationer för förbättring av den (oavsett om ytterligare utveckling av ett automatiserat system planeras eller inte).
2. Den är oberoende och kan separeras från specifika utvecklare, kräver inget underhåll och kan smärtfritt överföras till andra. Dessutom, om företaget av någon anledning inte är redo att genomföra projektet i det här ögonblicket tid kan modellen ”läggas på hyllan” tills den behövs.
3. Det möjliggör effektiv utbildning av nya anställda inom specifika områden av företagets verksamhet, eftersom den relevanta tekniken ingår i modellen.
4. Med dess hjälp är det möjligt att utföra preliminär modellering av lovande verksamhetsområden för företaget för att identifiera nya dataflöden, interagerande processer och strukturella element.
5. Det säkerställer spridningen av samlad erfarenhet hos andra företag och gör det möjligt att förena dessa företags administrativa, administrativa och finansiella verksamhet.

En modell är inte bara en implementering inledande skeden arbete och grunden för bildandet av tekniska specifikationer för dess efterföljande steg. Det representerar ett oberoende resultat som är av stor praktisk betydelse, eftersom det tillåter vidare användning av CASE-teknologier för själva designen och utvecklingen av IS.

6.5. Implementering av informationssystem

Implementeringen av företags IP, utvecklad oberoende eller köpt från en leverantör, åtföljs ofta av störningar (omdesign) av befintliga affärsprocesser på företaget. Vi måste bygga om dem för att uppfylla kraven i standarderna och logiken i det system som implementeras. Låt oss genast notera att införandet av informationssystem löser ett antal administrativa och tekniska problem, men ger upphov till problem kopplade till den mänskliga faktorn.

Implementeringen av ett informationssystem underlättar i regel hanteringen av företagsaktiviteter, optimerar interna och externa informationsflöden och eliminerar flaskhalsar i ledningen. Men efter att systemet framgångsrikt har installerats, "testat" i drift och visat sig vara effektivt, visar vissa anställda ovilja att använda IS i sitt arbete. Som ett resultat av omarbetningen blir det tydligt att vissa anställda till stor del duplicerar andras arbete eller inte behövs alls. Dessutom åtföljs implementeringen av CIS av obligatorisk utbildning, men som rysk erfarenhet visar finns det inte många som är villiga att omskola sig. Att bryta gamla färdigheter och skapa nya är en lång och svår process!

Det måste tydligt förstås att företagens IP är utformad för att förenkla ledningen av en organisation, förbättra processer, stärka kontrollen och därmed ge konkurrensfördelar. Endast ur denna synvinkel kan fördelarna med dess genomförande bedömas.

Efter denna logik blir det tydligt att även om företagets IS generellt sett är avsett att förse alla användare med nödvändig information, är hantering av utvecklingen och implementeringen av CIS företagets högsta lednings privilegium! Förstår ledare detta?

Även här måste vi bekämpa ihärdiga stereotyper. "Varför behöver jag ett företagssystem om det redan går bra på företaget?" "Varför bryta något om allt fungerar?" Men oftast finns det ingen anledning att bryta den. I det första skedet behöver du bara kompetent och korrekt formalisera och överföra de identifierade processerna inom vilka företaget lever till företagets IS. En sådan formalisering kommer bara att vässa och förfina framgångsrika marknadsförings- och produktionsidéer, optimera lednings- och kontrollprocessen och möjliggöra riktade förändringar i framtiden.

Införandet av ett nytt IS är en komplex process, som varar från flera månader för små IS till flera år för IS för stora distribuerade företag med ett brett utbud av produkter och ett stort antal leverantörer. Framgången för ett projekt för utveckling (förvärv) och implementering av IP beror till stor del på företagets beredskap att genomföra projektet, ledningens personliga intresse och vilja, ett realistiskt handlingsprogram, tillgången på resurser, utbildad personal, och förmågan att övervinna motstånd på alla nivåer i den etablerade organisationen.

Vid det här laget har en standarduppsättning av tekniker för att introducera informationssystem dykt upp. Grundregeln är att slutföra de nödvändiga faserna sekventiellt och inte hoppa över någon av dem.

Följande faktorer är avgörande för implementeringen:

• förekomsten av tydligt definierade projektmål och IP-krav;
• tillgång till en strategi för implementering och användning av IP;
• genomföra en förprojektundersökning av företaget och konstruera modellerna "i befintligt skick" och "som kommer att vara";
• planering av arbete, resurser och övervakning av genomförandet av genomförandeplanen;
• deltagande av högsta ledningen i implementeringen av systemet;
• utföra arbete med IS-implementering av systemintegrationsspecialister tillsammans med företagsspecialister;
• regelbunden övervakning av kvaliteten på utfört arbete;
• snabbt få positiva resultat åtminstone i en del av de implementerade IS-modulerna eller under provdriften.

Innan du börjar utveckla ett implementeringsprojekt måste du:

• formalisera målen för IS-implementeringsprojektet så mycket som möjligt;
• uppskatta de minsta nödvändiga kostnaderna och utgiftsposterna;
• sätta en hög prioritet för genomförandeprojektet framför andra pågående projekt;
• ge projektledaren maximala befogenheter;
• utföra massutbildningsarbete med företagets personal för att förmedla till alla vikten och nödvändigheten av de kommande omvandlingarna;
• utveckla organisatoriska åtgärder för användning av ny informationsteknik;
• fördela personligt ansvar över alla stadier av implementering och provdrift.

Det är också nödvändigt att bestämma de funktionella områdena för implementering av informationssystemmoduler:

• organisationsledning;
• organisatoriskt och administrativt stöd;
• Affärsprocessledning;
• förvaltning, finansiell planering och redovisning;
• personaladministration;
• dokumenthantering;
• logistik;
• hantering av relationer med kunder och den yttre miljön.

Utöver det som listas ovan är det nödvändigt att ställa tekniska krav för implementering av IS:

• systemplattform: implementering och anpassning av en färdig lösning från tillverkaren eller skräddarsydd utveckling i enlighet med kundens tekniska specifikationer.
• integrerbarhet: data lagras och bearbetas i en enda informationsutrymme- Detta säkerställer deras fullständighet, konsekvens, tillförlitlighet och återanvändbarhet; systemet kan innefatta nyutvecklade och redan använda tekniker och applikationer.
• anpassningsförmåga: systemet är konfigurerat i enlighet med kundens krav och egenskaperna hos kundens informationsfält.
• distribuerat: systemet kan fungera effektivt i geografiskt avlägsna divisioner och grenar av företaget.
• skalbarhet: systemet kan implementeras i form av en ram som innehåller basmoduler och utökas i enlighet med kraven i en föränderlig extern och intern miljö.

Huvudfaser av implementering av informationssystem

Fas "Preliminärt arbete med förberedelse av IS-implementeringsprojektet." Under förprojektundersökningen av företaget (fig. 6.1.4) samlas detaljerad information in om organisationens strukturella struktur, funktionella relationer, ledningssystem, huvudsakliga affärsprocesser, flöden inom företaget (Control Flow, Doc Flow, Dataflöde, arbetsflöde, kassaflöde), nödvändiga för att bygga lämpliga modeller och välja objekt för automatisering. Tidpunkt, resurser, typer och volymer av arbete, utbud och kostnad för mjukvara, hårdvara och telekommunikation, kostnaden för personalutbildning etc. bedöms.

Fas "Projektberedning". Efter slutförandet av den första fasen utförs preliminär planering och bildande av projektstartprocedurer:

• bildande av projekt- och expertgrupper;
• fördelning av befogenheter och ansvar;
• fastställande av organisatoriska och tekniska krav för implementeringsprocessen;
• klargörande av kundspecifikationer och förväntningar;
• utbildning av implementeringsgruppen bestående av specialister från kundföretaget.

Den sista är väldigt viktig poäng av någon anledning missas det ofta när man gör upp en genomförandeplan. Men framgången för hela projektet beror mycket på det! Efter finansieringsstart anses projektet vara igångsatt.

Fas "Projektgenomförande". Under det huvudsakliga implementeringsarbetet skapas, installeras och konfigureras systemmiljön, systemadministrationsprocedurer bestäms och grundläggande hård- och mjukvarusystem och applikationer installeras. Systemet konfigurerar företagets organisatoriska, bemannings- och organisatoriska-funktionella strukturer med hjälp av sådana organisatoriska enheter som en filial, avdelning, division, arbetsgrupp, etc.

Installation, konfigurering och uppsättning av nätverks- och telekommunikationsverktyg utförs, data överförs från tidigare lokala system och gränssnitt bildas mot äldre och externa system. Samtidigt placeras alla skapade modeller, planer, fungerande mjukvaruprodukter, dokumentation i implementeringsprojektets slut-till-ände-förråd (Fig. 6.17)