Библиотека за управление

Концепцията за ППИ в управлението на ИТ услугите

К. Василиев, Е. Столберг, генерален директор на LLC " 1S-ESKV "

Тя вече се е превърнала в общо място за разсъждения за все по-голямото значение на ИТ услугите в икономиката на предприятието и, съответно, за нарастващата стойност на автоматизацията на дейностите при предоставянето на тези услуги. Въпреки това, ако погледнете проблема през очите на нормален ИТ мениджър, с добри инструменти тук не е лесно. Функциите на ИТ-услугата, в автоматизацията, която може да ни заинтересува, са разнообразни. Това традиционно, както и бизнес моделирането и управлението на проекти (главно проекти за разработване и / или разработване на приложения) и управление на потребителските изисквания, бюджетиране и нещо друго. Съществува здравословно желание да се премахне от рафта софтуерен продукт, покриващ всички тези функции в една единствена информационна среда, тъй като е интуитивно ясно, че функциите са тясно взаимосвързани и имат много общи информационни обекти. Но тук има удар. Най-напредналите експерти са информирани за продуктовата линия IBM Rational. Това е наистина концептуално (и в много отношения програмно) пълен многофункционален набор от инструменти, покриващ почти всички по-горе секции, макар и с ясна пристрастност към управлението на разработването на нови продукти, което не е толкова важно за повечето ИТ услуги. Но от рафта е толкова лесно да не се премахне - ще бъде прекалено тежък. Това е скъпо, не е лесно да се приложи. Разбира се, за 98% от Топ 500, където се използва, според IBM това вероятно не е проблем. Но за тези предприятия, където разходите за овладяването им лесно могат да надвишат целия годишен ИТ бюджет, IBM Rational не е решение. И какво?

Има, разбира се, разработени инструменти за отделни функционални раздели. За бизнес моделиране - ARIS, BPwin, същата Rational Rose. За управление на проекти - Open Plan, Primavera, MS Project. За да управлявате изискванията - да речем, HP Open View. Но, на първо място, инструментите също са, в голямата си част, тежки и на второ място, разединени, информационно несвързани, холистичен процес сами по себе си не се организират. И на трето място, това, което е особено важно за инструментите за бизнес моделиране, е малко практично. Въпреки че същият ARIS е позициониран както като инструмент за визуализация, така и като източник за автоматизация, трудно ми е да си представям практикуващ мениджър, който в правилния си ум и твърда памет ще може да го използва по един интегриран начин (над една или две картини). И сложността на описанието на обекта тук е такава, че това описание за работещ бизнес очевидно губи своята значимост много преди да бъде съставен.

И какво правиш? И се оказва, че Бог ще му даде душата. Вземете някои от изброените инструменти, набързо ги пришийте с твърдите нишки на незаменимия Excel и, доколкото е възможно, живейте.

Можете, разбира се, да се обърнете към консултации, да попитате какво се носи в Париж и Лондон (с акцент, разбира се, върху втория "о"). Днес те са, разбира се, ITIL, и всеки уважаващ себе си консултант за няколко хиляди рубли на час с удоволствие ще обясни на простия ръководител всички тънкости на окончателните различия между инциденти и проблеми. Гимнастиката, така да се каже, умът. Консултирането обикновено живее от факта, че първо създава проблеми и след това продава евтино средствата за решаването им. Остава обаче не съвсем ясно какво е по-ценно за управлението на ИТ услуги - ITIL или алкохол, но това вече е въпрос на вкус.

Ако е по-сериозно, ITIL е добра колекция от теории, тя е доста разумна и пълна информация за всичко това, може би някой ден ще бъде по отношение на темата за нейното разглеждане, но въз основа на идеите си практическите инструменти са едно и също за съжаление за сравнението, напишете универсална инструкция как да действате в живота, основана единствено на разпоредбите на Светото Писание. Не за това е предназначено Писанието - формулира само принципите, с които се препоръчва да се консултира в подходящи ситуации. Огромното мнозинство от хората в края на краищата не трябва да готвят хлапе в живота, поръчваме поръчката да не се създава в млякото на майка му за тях не е толкова актуална. И с различен подход към въпроса се оказва, както сега, смислите, мениджърът за ITIL, но не ITIL за мениджъра, пише.

По-сериозно критично разглеждане на въпросите, свързани с ITIL, авторите планират да отделят отделна статия. Тук искаме да предложим нашата концепция за автоматизация на ИТ услугата на принципите на единно информационно пространство (UIS) - нещо подобно, ние смея да кажем, ERP за предприятието като цяло - и концепция, базирана на доста прости практически помещения. И да предложи не само концепция, но и нейното внедряване в оригинален оригинален софтуерен продукт на свой собствен дизайн. Разбира се, нашата концепция не е възникнала от самото начало - много от нейните идеи са напълно преплетени с IBM Rational, към която се отнасяме с голямо уважение. Но ние си поставихме много определена задача: да приведем въпроса към продукта, който всеки ИТ мениджър от средно предприятие и по-горе може да извади от рафта, за да автоматизира управлението на услугата като цяло. Както го направихме - съдете се сами.

Мястото на ИТ услугата в пространството на предприятието (организация)

Започваме, както се очакваше, с няколко прости общи съображения и определения.

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

  • клиент, имам предвид самото предприятие в лицето на неговото управление. Тъй като е необходимо на клиента, той (той) прави искания и финанси дейности, тъй като ще приемем за простота, че ИТ услугата на услугата не се възлага на външни изпълнители;
  • потребители, т.е. служители на предприятието, които използват пряко ИТ услуги. Силно не им посъветвайте да ги объркате с клиента. Ако клиентът на ИТ услугата не е ръководството на предприятието и потребителите, дори на ниво директор, тази ИТ услуга няма да бъде завиждана;
  • корпоративна инфраструктура, която предоставя определени услуги на ИТ услугата, като финансова, счетоводна, персонал, поръчки, логистика, административни и други. Възможно е част от тази инфраструктура да може да бъде част от самата ИТ услуга, в който случай тя трябва да се управлява и в рамките на услугата;
  • аутсорсинг, т.е. специализирани дизайнерски, консултантски, изпълнителни и обслужващи организации. Тяхната роля е, че те временно или постоянно предоставят на ИТ услугите трудови ресурси, които е трудно или неподходящо за самата услуга да се поддържа в държавата. Специфичността на ИТ услугата е, че тя често е най-важният потребител на аутсорсинг услуги в предприятието, което съответно изисква по-голямо внимание от гледна точка на управлението и добавя разнообразие от главоболия в отношенията с мениджмънта;
  • доставчици на компютърно оборудване, софтуер, консумативи и др. По принцип транзакциите с тях, както вече беше отбелязано, в зависимост от модела за управление на предприятието, приет в предприятието, могат да бъдат изцяло или частично изолирани на външни единици по отношение на ИТ услугата. Но във всеки случай, при избора на доставчици и при договорната работа с тях, ИТ услугата активно участва.

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

Затова разбрахме кои основни външни обекти трябва да бъдат разгледани в UIS на ИТ услугата. Да продължим нататък, т.е. дълбоко в.

Функции на ИТ услугата (състава на ИТ услугите)

ИТ услугата се занимава с предоставяне на услуги на предприятието, основно три сорта:

  • изграждане на инфраструктура. Ние ги приписваме на работата по изграждането на информационни и компютърни мрежи (IVS) - инсталирането на компютри, изграждането на мрежови връзки, оборудването на компютрите с основния софтуер, създаването на услуги с общо предназначение (интернет, електронна поща, информационна сигурност);
  • разработване и внедряване. Тези термини, които тук се отнасят до интегрирани и специализирани софтуерни приложения, които осигуряват ИТ среда за изпълнение на основната работа на потребителите;
  • експлоатация на всички построени и изпълнени.

Строго погледнато, от гледна точка на основните инструменти за управление, първите два вида ИТ услуги могат да се разглеждат заедно на определено ниво. Но само на определено ниво за разработването и реализацията в нашата терминология има огромни технологични особености по отношение на инфраструктурното строителство, което трябва да се вземе предвид в системата за управление на услугите, по-специално.

Обекти на ИТ услугите и функционалните модули на ИТ системите за управление

Нека се опитаме да разгледаме проблема за "работника-селянин", очите на практичен ИТ мениджър (въпреки че той, разбира се, професионална и здравословна професионална терминология, той не е чужденец).

Клон за разработване и внедряване

Бизнес моделиране

Централната връзка, от която танцува цялата система за управление на ИТ услуги, е потребителите. Потребителят се характеризира със своето работно място (PM) и с лицето на служителя, който го притежава. RM трябва, в съответствие с изискванията на клиента, да оборудва и допълнително да поддържа оборудването в работно състояние. Лицето трябва да бъде обучено и принудено (не намираме по-хармонично понятие) да изпълнява функциите, предписани в изискванията за РМ в автоматизираната информационна система (АИС) на предприятието.

Откъде идва RM? Ние се осмеляваме да приемем, че информационният обект, който ги доставя, е структурата за управление на предприятието, затова в нашата UIS е необходимо да се предвиди място. Свързването на човек с РМ е таблицата за персонала. При работа на смени няколко работници могат да бъдат назначени на един RM.

Откъде идват изискванията на клиента за функциите, възложени на всеки от тях? Ние ще изградим следната проста логическа верига. Съществува функционална структура на предприятието, което означава дърво на разлагане на управленски функции - от цялостното управление на бизнеса до частните операции, като освобождаването на материали от склада или таймедърд. В този случай ние се интересуваме от тази структура "как трябва" (вярваме, че преходът към нея от "както е" на хартия е предшестван от ИТ услуги и не ги засяга пряко). Ако изградим такава структура и обвързваме функциите с RM, вече имаме нещо. Нещо, но не достатъчно за по-нататъшно смислено управление. Какво следва?

Освен това, както обикновено, процесите, които осигуряват изпълнението на функциите. За всяка функция като цяло има няколко. Процесите свързват RM един с друг в една верига или (ако има разклонения в процеса) към мрежата. Разбира се, RM може да участва в няколко процеса.

Ще се позовем на тези процеси като информационни процеси (IP), за разлика от по-традиционните "бизнес процеси" (BP). Целта на въвеждането на тази концепция е строгостта на определението, което е необходимо за нашите задачи. Под БП сега всеки разбира всичко. В най-широк смисъл, тази концепция включва производствени и технологични процеси, които в този случай не ни интересуват, и процеси на управление, които не засягат пряко АИС. В светлината на това ние определяме IP за нашия случай като някаква проекция на PSU на AIS. Както вече бе отбелязано, IP е графика, чиито върхове са PM, а дъгите са последователността на изпълнение на операциите на процеса. Всеки връх може да бъде свързан с няколко неща: вход (сурови данни), изход (резултати от информация), инструменти (обработка на софтуер и технологично обучение). Както можете да видите, обектите са се увеличили. Нека да разгледаме по-отблизо някои от тях и да продължите към създаването на нови, като отидете на следващия модул.

Управление на конфигурацията

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

След това имате права за достъп. От всеки RM, представен във всеки IP, е необходимо да има право да чете входните обекти и да записва в изходните обекти. Това е донякъде опростено (на нивото на цялостната схема на схемата за интелектуална собственост); може да има допълнителни изисквания, за да се определят определени права в контекста на конкретен ПР; Възможно е тези изисквания да бъдат въведени в полетата за данни. Ние ще класифицираме тези тънкости към специалните изисквания на клиента, които вече не се реализират чрез нивото на права на достъп до метаданни обекти, а чрез действителните кодове за обработка на софтуера. Тези изисквания, разбира се, трябва по някакъв начин да бъдат фиксирани в системата.

Правата на достъп могат да се изпълняват индивидуално за всеки RM или чрез шаблони за роли, за да се спестят разходи за дизайн. Следователно обектът "роля" се появява.

И освен това, по тази тема на мотивите, следва самото конфигуриране на приложението. Ако нивото на обектите на метаданните е очертано официално в описанието му, можем да автоматизираме връзката между изискванията за конфигурация и нейното състояние (ако е необходимо, в различните версии) чрез прости средства. Ако не, тази връзка не автоматизира или автоматизира с трудности. Нейната автоматизация е много ценна, тъй като осигурява изключително търсена, но рядко осъществена възможност автоматично да поддържа в нашата EIP структурирана техническа документация за работната конфигурация, което значително намалява разходите за оперативна поддръжка на внедрената AIS и значително подобрява нейната надеждност.

Също така отбелязваме, че при внедряването на мониторни приложения имаме нещо като стандартна конфигурация и нещо като работна конфигурация, която се различава от стандартната, от наличието на нови обекти на метаданни (включително обработка на софтуер) и евентуално от промяна на стандартните.

Тук, засега, ще спрем пътя по развитието и изпълнението и ще обърнем внимание на други, добри, защото за тяхното формиране вече сме създали определен материал.

Инфраструктурен строителен клон

Тук всичко, от гледна точка на обектите на УИС, е достатъчно просто. Имаме RM, имаме изисквания за тяхното участие в ПР. Съответно има изисквания за софтуерно и хардуерно оборудване за всеки ПМ. Ако те отговарят на стандарта на предприятието за оборудване на мястото на клиента, стандартната конфигурация е прикрепена към този PM, ако не е направена специална заявка. Както и при мрежовите връзки, сървърните конфигурации и т.н., изискванията, които произтичат от набор от изисквания за всички RMs, тяхното географско разположение и т.н. Съответно, съществуват такива обекти като мрежи, сървъри, клиентски компютри (терминали), мрежово оборудване, мрежови връзки, чието описание е необходимо както за създаване на работа за тяхното изграждане, така и за последваща работа.

Отрасълът на експлоатацията

Изграждат се всички инфраструктури, съоръжения за изграждане и внедряване в процеса на изграждане; Новите видове обекти на експлоатация почти не генерират. Началната точка за действие по отношение на оперативните услуги (или услуги за поддръжка и поддръжка) е оперативно изискване, обикновено идващо от потребителя. От съществено значение от гледна точка на системата от обекти на УИС може да се има предвид факта, че процесът на ескорт генерира такива явления като версии на оригиналните обекти, които сами по себе си придобиват статуса на обектите и преизпълняват своите управленски процедури. При изявлението на тези факти нека спрем.

Управление на изискванията

В нашата изложба многократно възниква концепцията за изискване. Обмислете всички подробности, свързани с него, обобщаващи информацията от различни отрасли.

Препоръчително е да се разграничат два вида изисквания: изисквания на клиента и изисквания на потребителите. Незабавно посочваме, че структурата на отражението им в UIS е почти една и съща за двата вида; Различията се проявяват на качествено ниво и на ниво управленски процедури.

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

Изискванията на потребителите възникват по инициатива на последните само като независими обекти. Как правило, они рождаются в ходе эксплуатации системы, однако, учитывая, что опытная эксплуатация системы обычно считается составной частью этапа внедрения, первые такие требования появляются именно на этом этапе.

Требования пользователя, если говорить о них в общем виде, целесообразно разделить на проектные (или бизнес-требования) и эксплуатационные (сервисные). Для проектных требований существенно то, что они для своего исполнения должны в результате процедуры согласования обрести статус требований заказчика; соответственно и должен быть построен регламент управления требованиями. Это относится, прежде всего, к требованиям, затрагивающим структуру внедренных ИП, объектов конфигураций приложений, прав доступа. Требования этого рода, не прошедшие согласование, не исполняются. Эксплуатационные требования должны, в случае необходимости, пройти разве что процедуру бюджетного согласования; если же эта сторона вопроса не вызывает проблем, требования исполняются. К такого рода требованиям могут относиться требования на апгрейд или ремонт компьютера, замену картриджа и т.п.; возможно, к примеру, и малозначительные изменения отчетов, потребляемых только данным пользователем. В этом деле много нюансов, которые мы здесь для краткости опустим, поскольку нас интересует тут, прежде всего, сам факт наличия в ЕИП объектов данного вида и определенных способов работы с ними.

Управление работами

Принятое требование порождает одну или несколько работ (новый для нас вид объекта). Соответственно, необходимость управлять исполнением работ (заданий) порождает целый блок дальнейших объектов.

Отметим, по ходу, что работы, относящиеся к хорошо структурированным объектам, могут, в ряде случаев, порождаться системой на основе списка требований автоматически; также можно наладить различные процедуры верификации полноты перечня запланированных работ относительно предъявленных требований. Это колоссальное преимущество ЕИП перед локальным использованием инструментов проектного управления общего назначения, которые надо набивать перечнем работ только «из головы». Несомненно, такие «нерегулярные» работы в каком-то количестве возникают неизбежно и в нашей системе. Но чем их меньше, тем выше качество деятельности ИТ-службы, тем меньше риск того, что в кузнице в решающий момент не окажется гвоздя. Во всяком случае, автоматизированная система точно не забудет, что перед началом эксплуатации надо заполнить исходными данными справочники и ввести остатки, обучить и аттестовать каждого пользователя и т.п.

Работы, особенно на стадиях строительства инфраструктуры, разработки и внедрения, редко носят одиночный характер; их есть смысл объединять в какие-то комплексы (агрегаты). Для отмеченных стадий стандартным агрегатом работ является проект, т.е. комплекс логически взаимосвязанных работ, имеющий общий результат. Данный вид объекта ценен для таких дальнейших действий, как сетевое календарное планирование взаимосвязанных работ, распределение ресурсов, бюджетирование. Возможны в системе и агрегаты работ без определения их логической взаимосвязи. Здесь уходит аспект сетевого планирования, но сохраняют значение распределение ресурсов и бюджетирование. Такие агрегаты целесообразно вводить, например, по видам эксплуатационных работ. Понятно, что работы могут не только порождаться периодическими требованиями, но и носить регламентный, постоянный характер, также влияя на загрузку ресурсов и на бюджеты.

Соответственно, возникает такой вид объекта, как ресурсы. Для наших целей интерес представляют ресурсы, в основном, двух видов — трудовые и финансовые; такие вещи, как, например, оборудование или материалы редко ограничивают возможности выполнения работ в зоне ИТ-услуг.

Трудовые ресурсы объединяют персонал ИТ-службы организации, персонал, предоставляемый аутсорсером, и, в необходимых случаях, ресурсы пользователей. С точки зрения назначения исполнителей и календарного планирования они ничем не отличаются друг от друга, но для целей тарификации, бюджетирования и т.п. должны иметь определенные различающие характеристики. Финансовые ресурсы назначаются через такие объекты, как бюджеты (общий, бюджеты комплексов работ) и бюджетные статьи в нужной для целей управления детализации.

Общая структура

Начнем здесь с простого и в свете изложенного теперь достаточно очевидного тезиса: структура и основные процедуры, составляющие функциональные модули ИТ-услуг, могут быть унифицированы для применения как на стадиях первичного создания АИС, так и на стадиях эксплуатационного сопровождения. Детали, специфичные для этих стадий, несложно отразить в процедурах, заложенных в описываемую систему, и в характеристиках отдельных объектов. Так что ЕИП для всего процесса управления ИТ-услугами у нас формируется на едином для этих стадий составе функциональных модулей и объектов.

Этим тезисом мы можем с чистой совестью увенчать данный раздел изложения: функциональные модули системы управления ИТ-услугами определены, состав объектов ЕИП сформирован. Общий вид структуры полученного ЕИП может быть представлен на нижеследующей диаграмме. Указаны основные функциональные модули и объекты, обеспечивающие взаимосвязь модулей и поддержание информационных характеристик.

И под конец не удержимся от попытки внести вклад в сокровищницу консалтинговой терминологии: почему бы по аналогии с ERP не назвать изложенную концепцию IRP (Informational Resources Planning)? Забьем копирайт на эту идею и двинемся дальше.

Реализация концепции

Как и в ИС иного назначения, возможны два основных варианта реализации концепции — в гетерогенной среде нескольких программных приложений для каждого функционального модуля и в среде одного базового (разумеется, допустимы и промежуточные варианты).