"… конкретными показателями работы конечных ИТ-сервисов (риски, качество, скорость реакции и пр.)" — а можно привести пример описания какого-то стандартного ИТ-сервиса.
Скажу честно, наверняка автор опустил некоторые детали при составлении данной статьи и выделил наиболее значимые. В любом случае, все те, кто только начинает этот трудоемкий процесс, однозначно надо добавлять в избранное.
Статье не хватает сквозного примера. Чистая теория поможет структурировать знания опытному «бюджетнику», но очень тяжело усваивается начинающим (потому что не оставляет эмоционального следа после прочтения).
Потому что для вас они не представляют ничего особенного — вы их проделывали неоднократно.
Для меня настройка зонинга в фабрике — рутинная операция, а три года назад я не знал с какой стороны подойти к этому вопросу.
И стандартно-универсальный «досуха выжатый» алгоритм
1) Собрать данные
2) Обработать их
3) Сформировать план и реализовать
подходит к любому процессу, но мало чем помогает без практического примера.
«С помощью пистолета и доброго слова можно добиться гораздо большего, чем с помощью только доброго слова».
Была бы возможность — написал бы про все что можно, но время — ограниченный ресурс, так что приходится писать о том, что в первую очередь интересно самому. Возможно позже перейду и к практическим примерам, но в самых первых своих статьях хочу описать основные аспекты системного администрирования. По этой причине следующая статья будет о планировании аварийного восстановления, а не о практиках бюджетирования.
На реальных предприятиях без понятия про SLA.
Зато вполне реально разработать и согласовать «Регламент эксплуатации». Там уже заложить все временные и качественные характеристики обслуживания.
На реальных предприятиях SLA — это некоторый внутренний регламент ИТ-отдела, который не используется при общении с бизнесом. При общении с бизнесом используются категории рисков, возможных потерь и простоев.
Добавил в избранное, перечитаю в сезон планирований.
> И последняя, но самая важная деталь – это обоснование каждой из статей бюджета.
Жаль, что самой важной детали уделён лишь один абзац. Получается как у Ландавшица — «далее очевидно, что...». Печаль ИТ-бюджетов в не-ИТ-компаниях в том, что ИТ — кровососы и растратчики, они не приносят денег, а только тратят и тратят. Понимаю, нужно доносить начальству, что тратим не мы, тратят нашими руками другие подразделения. Это им нужна сеть, картриджи и техник для ответов на тупые вопросы. Но практически формализовать, кто и сколько потратил, получается не всегда, очень не хватает всяких бест практис и саксес сторис на эту тему.
Я писал в предыдущих статьях, что по моей практике в первый год бизнес не понимает для чего им ИТ-бюджет, во второй год они смотрят на него с осторожностью, ну а на 3-4-ый год — ждут с нетерпением. Увы, сейчас такое время, когда не бизнес ставит требования к ИТ, а когда ИТ необходимо воспитывать бизнес — по этой причине я и пишу статьи на хабр.
Памятка по составлению ИТ-бюджета