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