Нов партньор?

partners[@]IT-PlayGround.net

Създадено за Вас

информирайте се, споделяйте

Пишете ни:

hello[@]IT-PlayGround.net

Защо да се присъедините?

1. чудесни членове в екипа - приятелски настроени, отворени за нови предизвикателства
2. споделяне на знание и опит от всички
3. организиране на социални събития със страхотните членове на екипа в Благоевград и/или София
4. промо кодове от партньорите ни
5. LinkedIn препоръки след известно време
6. още страхотни възможности. Останете в очакване ;)

свържете се с нас: hello[@]IT-PlayGround.Net

Как да започнем от нулата с ITIL

Всяко начало е свързано с изключително напрежение, което се впряга в усилието да преследваме успеха. ИБИТ не е изключение и с времето процеса нараства до нещо, което е по-сложно и трудно за управление. Тази сложност не означава задължително, че целите се постигат с по-малко усилия или минимални притеснения поради еволюцията на методологията. Това обаче, с продължителното израстване и усложняване на процеса, води до повече време за завършването на дадена цел. Ето защо е важно да се определи абсолютният минимум, от който можем да градим за в бъдеще. Можете да го наречете "основа", "устои на структурата" или каквото име измислите, стига целта му да е ясна.

Подобен термин за това съществува в методологията на Lean мениджмънта или "чистото управление" и той се нарича "минимален продукт за съществуване". Разликата тук е, че ние говорим за процес. И без значение колко сложно може да звучи, това всъщност е базата на всяка ИБИТ (Инфраструктурна Библиотека на Информационните Технологии) дейност, която също можем да наречем "старт от кота нула". Веднъж създадена, тя може да продължава да еволюира. Друга версия на концепцията е да се разбие тежкия, труден процес на по-малки дейности, по-опростени и независими една от друга. Така лесно можете да определите коя секция ви забавя и можете да разработите само в тази част, вместо да променяте целия процес. Това намалява времето за изпълнение на задачите.

Запознати сме с термина "най-добра практика", но в този случай е доста мъгливо какво трябва да означава това в нашия сценарии. Въпреки това, не е лесно за определяне, тъй като индустриите варират и всичко опира до средата и изискванията, така че всяка "най-добра практика" ще бъде специфична за сектора или индустрията, за която се прилага. Една версия може да е добра за малка компания, и смъртоносна за корпоративния сектор, така че всичко зависи от променливите параметри. И запомнете, за разлика от Agile, тук имаме определени процес и ресурси и това е, с което ще работим. Някои биха си помислили, че това ограничава възможностите за промяна и гъвкавостта, но случаят не е такъв. Разбира се, той има своите върхове и спадове, но за три десетилетия и малко повече, процесът е развит до неговата зрялост.

Как можем да определим "старт от кота нула" или "усилие от кота нула"? Това е процес, продукт или услуга, която постига необходимите таргети и цели с малко или никакво усложнение или с най-краткото описание. Той включва всички необходими стъпки и изисквания, за да достигне крайната си фаза. В друга статия, която скоро прочетох, има добро обяснение как точно "старта от кота нула" може да повлияе четирите основни аспекта на един такъв определен процес: цел, потребители, двигатели и резултати. Или, раздробено, би трябвало да означава точно следното: защо, кога и за кого правим работата, което ни води до това коя е клиентската маса, в която се целим; как да подобрим процеса и какво ще ни донесе това подобрение като резултат. Ако е добре проектирано, ще ви донесе контрол върху паралелните дейности и координация.

Друго популярно мнение е, че ефективността се губи с времето. Но имайки базата, можем значително да изчистим процеса. Можем да мислим "старта от кота нула" като прагматичната страна на едно голямо и очаквано растящо животно. Дори и за хората казват, че това което има значение са първите 7 години. Можете да мислите за тази концепция по подобен начин - имате определено време за да установите "кота нула" и след като тя достигне зрелост, ще започне да се самообучава ... ако бяхме в идеален свят, разбира се. Това не означава, че не трябва да се намесвате, но въздействието от решенията ще бъде намалено и не толкова опасно, ако нещо се обърка.

Трябва също така да отбележим, че всичко това има значение, ако добавите определена стойност към процеса - и тук вече започваме да се срещаме с усложненията. Често с добавената стойност хората започват да губят обхват и нещата започват да заприличват на каша. И това, защото мениджърите искат да добавят възможно най-голяма стойност към проектите си, за да оправдаят ресурсите нужни за процеса. Да, ама не. Колкото по-дълго помните, че вашата приоритетна и първа цел е КЛИЕНТА и целта на РЕЗУЛТАТА е да го задоволите, тогава всичко ще е наред. Не се гмуркайте твърде дълбоко в процеса, защото така ще изгубите фокуса и посоката си. Това е било наблюдавано толкова много пъти в толкова много компании, че честно казано не бих могъл да ги изброя, нито бих искал да влагам усилие да го правя.

Нека да се върнем на "най-добрата практика" отново, тъй като това може да се окаже пропастта за "кота нула" и други концепции в ИБИТ, както и в Agile и Lean. Да кажем, че имаме вече определен процес и започваме да срещаме различни пречки. Това, което може да помогне да определим какво работи и какво не, е да изясним ролите и отговорностите в тази секция, биха си помислили някои. За да направим това с "най-добра практика" би отнело месеци, а ако сме в мултинационална компания може да отнеме и години - да определиш пропуските, да избереш по-добри инструменти, да наемеш и обучиш екип и да ги убедиш, че това е техния "най-добър" процес, тяхната "най-добра" практика. И тогава вашата "най-добра практика" се превръща във вашата пропаст. С "кота нула" имаме малко по-различна ситуация: отговорността се разпределя от самото начало на всички заинтересовани страни; екипите могат да се коригират според нуждите си; подобрението не е вградено, но се разглежда като част от културата на организацията и среща нужната промяна или проблем вместо ненужна опция или свойство. Ако се случи грешка, можете лесно да се върнете към основата/базата и да започнете изграждане оттам - няма нужда от въвеждането на огромни решения поради архитектура или някаква друга сложност. И все пак, имаме определен процес в неговата скелетова структура със абсолютните неоспорими нужди, така че няма как да е по-чисто и по-леко от това. И започваме отново добавяне на другите функции. И понеже това е скелет, както и база за целия цикъл, можете много лесно да пропуснете валидацията, контрола и другите добавки, за да увеличите стойността. Те могат да бъдат администрирани на по-късен етап - в преходния (transition) например, където ще е финалното преглеждане на това, какво иска клиента от самата имплементация, от самото въвеждане на тези функции. И така можете да използвате модела напред във времето - всичко ще зависи от вашата гъвкавост и степен на нагласа.

В заключение, ИБИТ дава възможност за различна употреба на основните изисквания, вземайки предвид особеностите на внедряващата организация. Въпреки това, поради неразбиране или страх от практикуването на новите вариации на работната рамка, много организации избират да се придържат към първите издания на пакета дейности на методологията. Това не означава, че трябва свободно да интерпретираме препоръките, описани в ИБИТ, но трябва да имаме по-дълбоко разбиране, от какво точно се нуждае организацията ни. Не можете да вземете процес, да го харесате и да го наречете ИБИТ или да го направите част от нейните дейности - ако отговаря на работната рамка - да, но ако не значи е нещо друго.
 

Урок: Как да създадем конкурс с видео/изображения ...
Основни концепции на ITIL & Agile

Свързани публикации

By accepting you will be accessing a service provided by a third-party external to https://www.it-playground.net/bg/

Абонирайте се за новини свързани със сайта

Powered by:  www.sslavkov.eu