Tervezés

A legtöbb informatikai szolgáltatásnak van valamilyen formájú esemény-kezelõ rendszere. Azonban az esetek többségében ez csupán imitált tevékenység, ami messze nem kielégítõ szolgáltatást eredményez a felhasználók számára. Az informatikai infrastruktúra menedzsment egy fegyelmezett megközelítést nyújt a problémakezeléshez.

Személyzeti kérdések

Ha elhatározásra került, hogy a problémakezelés az informatikai vezetés felelõsségi körébe tartozik, ki kell nevezni a probléma-menedzsert. Ezt követõen sor kerülhet a funkció nagyvonalú tervezésére és a személyzet iránti igény becslésére. A problémakezelési funkcióhoz szükséges létszám jelentõsen változhat részlegrõl részlegre. Függ a részleg méretétõl, komplexitásától és megbízhatóságától, valamint függ olyan más tényezõktõl is, mint a rendszerfejlesztés és a karbantartás kiterjedtsége, hatóköre.

A már kinevezett probléma-menedzser és az informatikai szolgáltatási vezetõnek formális és gyakorlatias tervezést kell végrehajtania, amelynek kezdeti fázisai:

• A problémakezelés szerepének meghatározása
• Figyelemfelkeltõ kampány
• Döntés a problémakezelés szervezeti struktúrájáról
• Taktikák tervezése a problémakezelési rendszer kialakítására
• A problémakezelés funkciót kifejlesztõ projekt kezdeményezése

A problémakezelés szerepének meghatározása

Meg kell határozni a problémakezelés funkció szerepét az informatikai szervezeti egységben. Az átfogó cél az informatikai szolgáltatások minõségének maximalizálása az elromlott dolgok megjavításával, a hibák újbóli elõfordulásának megelõzésével. E cél elérése érdekében a problémakezelésnek egyszerre kell reagáló és megelõzõ jelleggel mûködnie.

Összefoglalva, a problémakezelés csoport felelõs a következõkért:

• Reagáló eljárások:
  • a számítógépes tevékenységek, a hálózat-felügyelet és a Gyorssegély-szolgálat támogatása az események megoldásában, amikor csak szükséges,
  • a problémák meghatározása (az események kiinduló oka) és ehhez kapcsolódóan a megoldásuk vagy ismert hiba státuszba való konverziójuk,
  • az ismert hibák felügyelete és az elhárítási tevékenység koordinációja.
• Megelõzõ eljárások:
  • a rendszerek vagy szolgáltatások változtatásának kezdeményezése az egyes események elõfordulásának vagy újbóli megjelenésének megelõzése céljából,
  • az esemény és a probléma elemzõ jelentések szemlézése trendek azonosítása és a lehetséges problémáknak még elõfordulásuk elõtti azonosítása érdekében,
  • összetett rendszerben annak megakadályozása, hogy az egyik rendszerben megjelenõ probléma megjelenjék a többiben is.

A problémakezelés megelõzõ tevékenysége történeti adatokat kíván, hogy a trendelemzés és az elõrejelzés révén lehetõvé tegye a potenciális és az elõrelátható problémák azonosítását. Ebbe beletartozik az is, hogy meg kell elõzni a problémák átterjedését az egyik rendszerrõl a másikra.

Figyelemfelkeltõ kampány

A probléma-menedzsernek figyelemfelkeltõ kampányt kell megterveznie és végrehajtania, hogy segítse a problémakezelési funkció általános elfogadását és informálja az érintetteket arról, hogyan és miképp befolyásolja munkájukat a problémakezelés. Szemináriumok, személyes találkozók, körlevelek használhatók erre a célra. Fontos tudatosítani, hogy a problémakezelést azért hozzák létre, hogy támogassa a hatékonyan elõállított és minõségi informatikai szolgáltatásokat. E kampányt már a korai szakaszban el kell kezdeni, és folytatni a funkció implementációjáig, vagy még azon is túl.

Döntés a problémakezelés szervezeti struktúrájáról

A problémakezelési funkció szervezeti struktúrája függ a környezet felépítésétõl. Centralizált üzemeltetés esetén, ahol lényegében egyetlen adat-központ van, ott egyetlen csoport ajánlott.

Többelemû adat-központ esetén vagy elosztott jellegû szituációban számos lehetõség van. A figyelembe veendõ legfõbb tényezõ az, hogy vajon a problémakezelés személyzetét szétosszák valamennyi adatközpont részleghez, vagy minimalizálják a kihelyezett személyzet iránti igényt.

Figyelembe veendõ tényezõk:

• A távoli központok és szolgáltatások mérete és komplexitása, és szervezeti fontosságuk.
• A távoli számítógépes rendszerek becsült megbízhatósága, a távoli részlegen használni tervezett alkalmazások stabilitása.
• A távoli központok fölötti centralizált felügyelet lehetõségének kifinomultsága és eredményessége.
• A távoli központok biztonsági követelményei.
• A lokális számítógépes üzemeltetés és a hálózat felügyelet személyzettel való ellátottsága.
• A távoli részleg személyzetére háruló munkateher és a kielégítõ munkakör lehetõsége.
• A felhasználói vezetéssel kialakított viszony jellege (politikai klímája).
• A képzett problémakezelési személyzet elérhetõsége.

Ez a szituáció nem egyedi, és más területeken is megjelenik (mint pl. a gyorssegély-szolgálatnál). Az informatikai vezetésnek szüksége van egy kezdeti képre arról, hogy kell a problémakezelési funkciót szervezni és egy integrált problémakezelési rendszerré alakítani, a problémakezelési személyzet, a felügyeleti személyzet és a támogató csoportok között megosztva a feladatokat.

Elõzetes tervek és taktikák kidolgozása a problémakezelés kialakításához

A probléma-menedzsernek meg kell bizonyosodnia arról, hogy elegendõ pénz áll rendelkezésre a személyzet, a szoftver, a berendezések és a kapcsolódó fejlesztések költségeinek fedezésére. Mivel a problémakezelés négy nagy alrendszerbõl épül fel, ezek kifejlesztése és megvalósítása fokozatosan történhet. Azonban más Információtechnológiai Infrastruktúra Menedzsment funkciók, mint a konfigurációkezelés és a változáskezelés integrálódnak a problémakezelés folyamatába, és ezért a tervezéskor figyelembe kell venni õket.

Meglévõ részlegek

Nincs egyszerû megoldás azoknál a már meglévõ részlegeknél, ahol szükség van az új rendszerre való átalakításra, de közben további terheket jelent a meglévõ eljárások folytatása. A meglévõ gyengeségek határozzák meg a prioritásokat. A legrosszabb (helyzetû) területek kapnak elsõbbséget. Pl. ha a rosszul ellátott változtatási eljárások és a silány üzembe helyezés eredményeként gyatra szolgáltatásban részesülnek a felhasználók, ez válik elsõdleges fontosságú területté.

A szûk keresztmetszetek kialakulásának elkerülése érdekében fokozatos megközelítés ajánlott. Hangsúlyt kell helyezni a kompatibilitás fenntartására és az integrációra valamennyi megvalósítási és szemle fázisban.

1. fázis

A felhasználók támogatását, az események, problémák és az ismert hibák kezelését szolgáló meglévõ, napi gyakorlatot jelentõ eljárások felmérésével és szemléjével kell kezdeni. Meg kell vizsgálni, milyen támogató eszközöket használnak? Kielégítõ-e a más informatikai infrastruktúra menedzsment funkciókkal való kapcsolat? Mit kell megtartani, és mit megszüntetni (erõsségek-gyengeségek)?

2. fázis

Meg kell tervezni a gyorssegély-szolgálat megvalósítását a megfelelõ eszközökkel. Ki kell alakítani a konfigurációkezelés által kezelt nyilvántartásokat az esemény-felügyelet és a változáskezelés számára. Létre kell hozni a problémakezelés esemény-felügyeleti részét, és meg kell határozni a specialista támogatási csoport felelõsségi körét.

3. fázis

Az esemény-felügyeleti rendszert ki kell terjeszteni, és lehetõvé kell tenni a számítógépes üzemeltetésnek és a hálózat-felügyeletnek az események közvetlen naplózását.

4. fázis

Ki kell alakítani a vezetõi jelentéseket készítõ rendszert.

5. fázis

Meg kell valósítani a problémakezelés, a konfigurációkezelés és a vezetõi jelentéskészítés egyensúlyát.

A megelõzõ jellegû tevékenységeket akkor lehet kialakítani, ha a problémakezelés személyzetére már nem rónak túlzott terheket a reagáló jellegû feladatok, a szolgáltatások minõségének javulása következtében. E fokozatos megközelítés révén csökken az érintett funkciókra gyakorolt többletteher, azonban növekszik a szükséges idõ is - a simább fejlesztés ellenére.

"Zöldmezõs" részlegek

A zöldmezõs (új) részleg elõnye az, hogy az informatikai infrastruktúra menedzsment összetevõinek teljesen integrált rendszere építhetõ ki a meglévõ szolgáltatások kezelésének terhe nélkül. Ha nem lehetséges a problémakezelés kialakítása a gyorssegély-szolgálat, a változáskezelés és a konfigurációkezelés kifejlesztésével együtt, akkor a prioritást a problémák és változások egyedüli kezelésének kell adni.

Hangsúlyozottan ajánljuk, hogy az éles felhasználói szolgáltatások elindításakor valamennyi informatikai infrastruktúra menedzsment funkció hatásos implementációja álljon rendelkezésre.

A funkciót kifejlesztõ projekt kezdeményezése

A problémakezelés kifejlesztését és megvalósítását teljesen meghatározott projektként kell végrehajtani. Javasoljuk a PRINCE-t (a PRINCE projekt menedzsment módszertan, lásd ITB 5. számú ajánlás) felhasználni, formális átvételi eljárásokkal minden szakaszban. Projekt követelményjegyzéket kell készíteni, amely tartalmazza a megvalósíthatósági tanulmányt és a projekt fázisokat. Meg kell határozni a terjedelmet és a függõségeket. Ajánlatos egy számítógép-alapú problémakezelési rendszer szoftvercsomag használata. A projektnek a következõ fázisai lesznek:

Megvalósíthatósági tanulmány:

A rendszer követelmények, a felhasználói igények, a szoftvercsomag-alapú megoldások, a költségek és hasznok magas szintû értékelése szükséges az ajánlott megközelítés megfogalmazásához.

A kezdeményezési fázis:

A projekt költségeinek és erõforrásainak kiszámításához és allokációjához átfogó szintû követelmény tervek és technikai tervek szükségesek, megfelelõ részletezettséggel.

A specifikációs fázis:

A problémakezelési rendszerhez szükséges felhasználói specifikációt és az elfogadási kritériumokat részletesen le kell írni.

Termékértékelés és rendszerfejlesztés:

Értékelni kell az alternatív szoftvercsomagokat, és meg kell tervezni a testre szabott és a kisegítõ jellemzõket.

A rendszer és az eljárások fejlesztése:

Ki kell fejleszteni a felhasználóra szabott és a kisegítõ jellemzõket, meg kell tervezni a dokumentációt és a tesztelést.

Megvalósítás:

Elõ kell készíteni a mûködési környezetet, az átvételi tesztelést, majd az éles üzembe helyezést.

Megvalósítás utáni szemle:

El kell végezni a rendszer teljesítményének, eredményességének és megbízhatóságának formális szemléjét.

Mûködtetés és menedzsment (a projekt után):

Gondoskodni kell a problémakezelés rendszer folyamatos mûködtetésérõl és vezetésérõl, hogy a kitûzött (a hivatkozási alapban rögzített) célok teljesüljenek.

Idõzítés

A problémakezelés bevezetési prioritásának meghatározásához meglévõ részleg esetében meg kell becsülni az informatikai szolgáltatási tevékenység elfogadott szintjeit a következõ tényezõk felhasználásával:

• Az informatikai szolgáltatások minõsége (az események számával mérve).
• A szolgáltatási minõség trendjei.
• Az ismert hibák azonosításának könnyûsége.
• A felügyelõ személyzet (számítógépes üzemeltetés és a hálózat felügyelete, gyorssegély-szolgálat) által megoldott problémák aránya az összeshez képest.
• A tervezett feladatokon és a váratlan események elhárításán (esemény-felügyelet) dolgozó személyzet aránya.
• Vezetõi információ elérhetõsége a hibák okairól és súlyosságairól.
• A szolgáltatásokat támogató termékek (szoftver és hardver) minõsége.

Ha ez az értékelés az eredményesség alacsony szintjét jelzi, a problémakezelés bevezetésének magas prioritást kell kapnia. Egyébként általában törekedni kell a minél hamarabb való bevezetésére. Zöldmezõs részlegeken a problémakezelés kifejlesztése és megvalósítása az új informatikai tevékenységek kialakításának integráns részét kell képezze. A megelõzés a legjobb gyógyszer!

Figyelmet kell fordítani a funkció kapcsolódásaira is. A problémakezelés az egyik fõ kezdeményezõje az informatikai infrastruktúra változtatásainak, számos változtatási kérelmet (VK) nyújt be. Emiatt fontos a jó kapcsolat a változtatáskezeléssel, mivel a nem megfelelõen felügyelt változtatáskezelési eljárások növelhetik a kezelendõ problémák megjelenésének kockázatát. A konfigurációkezelés látja el a problémakezelés eljárásait (alfunkcióit) információval a problémák, ismert hibák okozójaként azonosított konfigurációs elemekrõl (KE). A problémakezelés az alapja a rendelkezésre-állás menedzsmentnek is, mivel kezeli a megbízhatatlanságot és nélkülözhetetlen statisztikákat szolgáltat. A problémakezelésnek a Szolgáltatási Szint Megállapodások elfogadott szolgáltatási szintjeinek biztosításában is fontos szerepe van. Emiatt fontos, hogy a tervezés során a már meglévõ funkciókhoz igazodjunk, illetve ajánlott valamennyi kapcsolódó funkció kialakítása, hogy a problémakezelésbõl fakadó hasznok teljes mértékben kiaknázhatóak legyenek.

Megvalósítás

Az elõkészítés és a tervezés végeztével a feladat e tervek által egy eredményesen mûködõ problémakezelési rendszer megvalósítása. Az esemény-felügyelet alrendszer a gyorssegély-szolgálat bevezetésének részét képezi. Mi a rendszer és az eljárások szempontjaira összpontosítunk.

A problémakezelési rendszer fejlesztése

A következõ tevékenységek szükségesek ebben a fázisban:

• A problémakezelési eszköz beszerzése és üzembe helyezése.
• A képernyõ és jelentési formátumok igényekre szabása.
• Az egyedi rutinok kifejlesztése.
• A kódolási rendszer specifikálása.
• A Konfigurációkezelési Adatbázis (KKAB) létrehozása - amennyiben még nem elérhetõ.
• A dokumentáció elõkészítése.
• A rendszer funkcióinak és teljesítményének tesztelése.

A problémakezelési eszközök beszerzése és üzembe helyezése

A kiválasztott problémakezelési rendszer szoftver üzembe helyezése és tesztelése érdekében megfelelõ idõben kell a rendeléseket feladni. Még a tervezési fázisban szükséges lehet némi berendezésre (számítógépre). Nagyon valószínû, hogy hardver beszerzés és szoftverfejlesztési munka szükséges a problémakezelés mûködtetése érdekében.

A szállítás esetleges hosszú teljesítési ideje miatt a rendelés feladását ajánlatos a korai idõszakban elvégezni. A felszerelés kiegészítésre, bõvítésre szorulhat, és további informatikai infrastruktúra elemek lehetnek szükségesek a problémakezelési funkció számára, amikor az mûködni kezd.

A képernyõ és jelentési formátumok kialakítása

A tervezési specifikáció követelményei szerint meg kell valósítani minden változtatást az eszközökön. Törekedni kell arra, hogy az ilyen testre szabási tevékenységet minimumon tartsuk, és az olyan jellemzõk megvalósítására kell koncentrálni, mint az automatikus mezõfeltöltés és a nem kívánt vagy szükségtelen mezõk és adatok törlése. Ha egy általános célú terméket választottunk, ez a testreszabás magában foglalja a kódfejlesztést és a rendszer-paraméterek beállítását is.

Az egyedi rutinok fejlesztése

Ki kell fejleszteni minden szükséges rutint, amellyel a megkívánt funkciók elláthatók, de az eszközök nem nyújtják õket. Ezek a rutinok lehetnek, pl. adatbázis-beolvasó és konvertáló szolgáltatások, vagy kapcsolófelületek (interfészek) más informatikai infrastruktúra menedzsment rendszerekhez, illetve rendszer-karbantartási szolgáltatások.

A kódolási rendszerek specifikálása

Egyetértésre kell jutni a többi érintett féllel (pl. a gyorssegély-szolgálattal, a speciális támogató csoportokkal, a konfigurációs menedzserrel, a számítógép mûködési és hálózat-felügyelettel) a probléma/hiba-felügyelet által alkalmazott összes kódolási rendszerek struktúrájáról.

Két kódolási rendszer feltétlenül szükséges. Az egyik a probléma besorolási kód, ami azonosítja a problémák/ismert hibák okait. E kód fõ célja, hogy lehetõvé tegye a problémáknak és okaiknak az elemzését, ezért a kód kialakításánál számításba kell venni a késõbb megkövetelt jelentéseket is. Megfontolandó egy strukturált kód használata, amely lehetõvé teszi az elemzést különbözõ részletezettségi szinteken. Ez a fajta kódolási rendszer struktúrájában hasonló az esemény-kódolásban alkalmazotthoz, de a finomabb bontás a hibás KE precízebb azonosítását teszi lehetõvé.

A másik kódolási rendszer a súlyosságot méri, megmutatja valamennyi probléma hatását az informatikai szolgáltatásokra. A súlyossági kód kigondolásával párhuzamosan eszkalációs eljárásrendet kell kialakítani valamennyi súlyossági szinthez, irányelvként használva a szolgáltatási szint szerzõdésben elfogadott és definiált tervezett hibaelhárítási idõket.

A Konfigurációkezelési Adatbázis létrehozása

Ha a rendszer-specifikáció része egy interfész a KKAB-hoz, ki kell fejleszteni azt. Ha nincs KKAB, gondoskodni kell róla, hogy a konfigurációs menedzser létrehozza kézi adatgyûjtéssel vagy a meglévõ forrásokból való konverzióval.

A dokumentáció elõkészítése

Felhasználva a termékértékelési és rendszertervezési fázisból eredõ dokumentáció-tervezési specifikációt, elõ kell készíteni és engedélyeztetni minden rendszer-dokumentációt. Ebbe beletartoznak a mûködtetési kézikönyvek és a rendszertervezési specifikációk módosításai.

A rendszer funkcióinak és teljesítményének tesztelése

A rendszert alapos tesztelésnek kell alávetni, hangsúlyt helyezve az egyedi rutinokra és a rendszer interfészekre. Nem szabad megfeledkezni a rendszer adminisztrációs és a helyreállítási funkciókról. Teljesítmény tesztre van szükség a feldolgozási arány és a válaszidõ célok eléréséhez. Amennyire csak lehetséges, próbáljuk ki és ellenõrizzük a probléma/hiba adatokat felhasználó jelentéseket és ellenõrizzük ezek integritását is.

A megvalósítás

A megvalósítási fázis a következõ fõ tevékenységekbõl áll:

• A megvalósítási terv szemléje és finomítása.
• A személyzet képzése a rendszer koncepciójára és mûködtetésére.
• Átvételi teszt végzése.
• Üzembeállítás.

A megvalósítási terv szemléje és finomítása

Szemlét kell tartani a megvalósítási terv fölött a "Rendszer- és eljárásfejlesztés" fázis során szerzett tapasztalatok fényében, és a tapasztalatok alapján meghatározott minden szükséges változtatást is el kell végezni a tervben.

A személyzet képzése a rendszer koncepciókra és a mûködtetésére

A megvalósítási fázis során a problémakezelési funkció személyzetét ki kell képezni a problémakezelés és a hiba-felügyelet területére. Az alrendszert ritkábban használók, mint amilyenek a speciális felhasználói csoportok, további segítséget igényelnek mind ebben a kritikus periódusban, mind az éles mûködés elsõ napjaiban. Meg kell bizonyosodni afelõl, hogy a problémakezelés személyzetét idejében kiképezték arra, hogy biztosítani tudja ezt a szükséges további támogatást.

Teljesítmény-átvételi teszt

A befejezett problémakezelési rendszert részletes átvételi tesztnek kell alávetni, beleértve a rendszer funkciókat, interfészeket és a kapcsolódó berendezéseket és hálózatot. Ekkor kell tesztelni a mentést (back-up) és a katasztrófa-elõkészületeket, valamint az eljárási dokumentációt. Az elfogadási kritériumot a specifikációs fázisban kell felvázolni, a teszt-specifikációt pedig a rendszertervezési fázisban kell kialakítani. Az elfogadási tesztelés lehetõséget ad a személyzet képzésére is.

Az üzembe helyezés

A probléma/hiba-felügyeleti alrendszerrel kapcsolatos rövid távú nehézségek valószínûleg nem befolyásolják közvetlenül a felhasználói szolgáltatásokat. Ezért az üzembe helyezés viszonylag alacsony kockázatú tevékenységnek tekinthetõ. Ilyen körülmények között nem szükséges az alrendszert a felváltásra kerülõ korábbival párhuzamosan mûködtetni. Azonban, ha a régi rendszer létfontosságú vezetõi információkat vagy szerzõdéses kihatásokkal járó, a szállító teljesítményét értékelõ jelentéseket szolgáltat, megfontolandó a párhuzamos mûködtetés. Semmilyen esetben se vállaljunk olyan kockázatot, ami veszélyeztetheti a problémakezelés funkció hitelességét az informatikai szolgáltatás vezetés vagy a speciális támogató csoportok szemében.

Meg kell gondolni a meglévõ probléma/ismert hiba feljegyzések kézi rögzítését az új rendszerbe, különösen a probléma adatok esetében. Ha ez nem lehetséges az éles használat kezdete elõtt, az adatok fokozatosan is felvihetõk az éles mûködés során, a legnagyobb súlyosságú problémákkal kezdve. Ha a meglévõ adatok elektronikus formában kerültek tárolásra, egy átalakító rutin alkalmazása megfontolandó.

Nyilvánosságra kell hozni egy részletes üzembe helyezési ütemtervet, és meg kell bizonyosodni arról, hogy minden érintett tudatában van az eseményeknek. Ki kell választani egy napot és egy idõpontot, ami a legkényelmesebb és általánosan alkalmas, mint amilyen egy csúcsidõszakon kívüli periódus.

Az éles használat elsõ szakaszában alaposan figyelni kell a rendszert és a személyzet eredményességét, és meg kell tenni minden szükséges korrekciót a nehézségek megszüntetésére.

Megvalósítás utáni szemle és audit

Az üzembe helyezést követõen amint lehetséges, végre kell hajtani a projekt szemléjét. Meg kell vizsgálni, hogy milyen volt a projekt lefolyása, idõben befejezõdött-e, túllépte-e a költségvetést, milyenek a tapasztalatok. Szükség van egy formális megvalósítás utáni szemlére. Ebben a következõket kell megvizsgálni:

• A szükségletek és a realitás egyeztetése - sikerült-e a meghatározott követelményeknek megfelelõ rendszert létrehozni, különös tekintettel a teljesítményre.
• A tevékenységi szintek összehasonlítása az elõrejelzésekkel - a munka volumene és a személyzet létszáma összevethetõ-e az elõrejelzésekkel?
• Az emberi összetevõ értékelése - milyen a teljesítmény és milyen érzésekkel használják a rendszert?
• A hatékonysági és eredményességi mérõszámok szemléje - a tényleges mértékek hogy viszonyulnak a célokhoz?
• Az elért hasznok meghatározása.
• Összevetni a tényleges és a tervezett szerepet - sikeresen ellátja-e a problémakezelés a neki szánt szerepet?

Problémák

A problémakezelés funkció bevezetésével kapcsolatban problémák is jelentkezhetnek, törekedni kell ezek elkerülésére:

• A felhasználók közvetlenül fordulnak a problémakezeléshez illetve a specialista csoportokhoz, a gyorssegély-szolgálat megkerülésével - a problémakezelés csak az engedélyezett forrásokból fogadhat el kéréseket.
• Korlátozott az integráció az esemény/probléma/hiba felügyeleti alrendszerek között - ha az egyes feljegyzések között nem képesek kapcsolatot teremteni, akkor elveszhetnek a problémakezelésbõl fakadó elõnyök.
• Az éles és a fejlesztõi környezet rendszere inkompatibilis - ez megnehezíti az ismert hibák átadását a két környezet között.
• A személyzet elkötelezettségének hiánya - ellenállás lehetséges, fõleg a normál szolgáltatási idõszakon túl, és minél informálisabb volt a korábbi gyakorlat, annál nagyobb az ellenállás valószínûsége. Ennek elkerülése végett az érintetteket minél jobban be kell vonni a tervezésbe, tájékoztatni kell õket és a személyes meggyõzés lehetõségeit is igénybe kell venni.