Концепция построения ДИТ по ITIL

[Panososik]

Коллеги приветствую!

позволю пару слов в качестве предыстории.. итак буквально 3 дня назад я вышел на новую работу (лизинговая компания) до этого имел 7 летний опыт проектной деятельности в ИТ сейчас же передо мной задача "выстроить ИТ так чтоб все было гут!" ситуация на предприятии довольно стандартна : свои разработки свои программисты куча потребностей от пользователей их устраняют появляются все новые и новые помимо этого существующие системы нужно развивать все в состоянии пермаментного аврала поддержки пользователей как таковая отсутствует любой пользователь просто пишет о своей проблемме и один из разработчиков ее решает.. или забывает вообщем вроде бардак полный но так как у нас почти везде так то бардаком это называть не буду ибо вопреки всему компания ведь работает ну так вот

хочу собственно выстроить ИТ службу так чтоб и ее сотрудники не были демотивированы и бизнесу жилось хорошо мыслей в голове что плохо сейчас и что слделать чтоб стало хорошо много но во первых решил написать общую концепцию которая четко покажет к чему мы должны прийти... в связи с чем у меня вопрос есть ли у кого-нить опыт создания подобной концепции? я не прошу дать скатать чай не студенты на сессии просто прошу показать "берег" с которого поплыву.. ну и свои наработки конечно готов выкладывать

аутсорсеров прошу без ТКП ибо бюджета пока никакого не планируется буду воевать тем что есть.
_________________
чем дальше тем сильнее я осознаю как мало знаю

[starplayer]

1. Составьте список используемого ПО и оказываемых ИТ-услуг, расставьте приоритеты по убыванию критичности отказа.
2. Оцените состав и возможности текущего персонала.
3. Определите "степень беды" и найдите возможные пути устранения.
4. Составьте список действий по устранению проблем и просчитайте "бюджет изменений" (выделите три вида - горячие требующие немедленной реакции, среднесрочные - "пока терпит, но... ", плановые - из ИТ-бюджета следующего года).
5. Выходите на руководство и с цифрами на руках доказывайте, что "так жить нельзя".

[Дашкевич Дмитрий]

Я предлагаю начинать с каталога сервисов. Попробуйте представить ИТ-службу сторонней по отношению к бизнесу структурой. Соответственно, определите свою зону компетентности - сервисы, которые Вы обязуетесь педоставлять бизнесу. Появится некий прайс (без цен) - перечень услуг по каждому сервису. Далее можно разносить компетенцию по сервисам между подразделениями и сотрудниками самой ИТ-службы и продумать работу на стыках. Что это даст? Во-первых регламенты. Во-вторых, начальные метрики, первичную статистику. Появится повод более пристально взглянуть на функциональные обязанности ИТ-сотрудников, а, возможно, и на штатное расписание. К примеру - может имеет смысл ввести штатную единицу диспетчера ИТ-службы?
Классификация инцидентов и мощности потока обращений по сервисам выявит узкие места, даст пищу для размышлений о недостаточности ресурсов. Возможно, где-то используемое ПО приносит больше проблем, чем пользы. Где-то возникают вопросы по аутсорсерам и провайдерам. А где-то оборудование не отвечает задачам.
Немаловажный вопрос - консолидация информации об ИТ в едином пространстве. Как хранятся данные? Кто вносит изменения? Сколько времени уходит на поиск необходимых данных?
Ну, это так, навскидку...
В любом случае - появится пища для разработки соглашения с бизнесом и определени необходимых ресурсов.

[Rovk]

Тоже самое - месяц работаю в компании с подобной ситуацией.
Я начал с написания положений и регламентов (парольная защита, доступ к ресурсам, стандартизация ПО, заявок и т.п.), одновременно пишу каталог сервисов и SLA

ИМХО, если не начать с положений и разграничения ответсвенности - сложно будет заставить людей работать по новому

[centaurus]

Ситуация похожая. Бюджет - нулевой. з.п. копеечные у инженеров и операторов, рабочие места вообще ни какие...
Предполагаю даже написав OLA и пр. регламенты. ни чего соблюдаться не будет. Но в тоже время требуется качество и оперативность работ... В тоже время мотивация как и квалификация сотрудников SD на нуле и требовтаь что-либо от них не возможно при таких условиях.

х.з. что делать и как доказать что не инвестировав денежков в сервисДеск эффекта не будет...

[Ruslan]

[centaurus]

проблема в том, что деньги которые они отдадут - утеут сразу, а окупаемость развития ИТИЛа весьма призрачна.
Простой сервиса в глобальном маштабе, намного меньше и не регулярен, чем статичное увеличение бюджета ДИТа, а ведь это десятки специалистов (не только СД), дорогой спец. софт, оборудование и т.д...

Затраты получаются просто бешенные и затраты на ДИТ начинают значительно привышать затраты на тех кто реально приносит деньги. И получается что вместо открытия нового магазина\офиса\филиала деньги ушли в поддержку того что есть =))

[Ruslan]

Собственно опыт нашей компании:
1. Считаем деньги, которые теряем при сложившемся положении вещей сейчас.
2. Считаем деньги после внедрения принципов работы по ITIL
3. Расчитываем цену владения и окупаемость (цена внедрения, увелечение ФОТ, закупки техники под эти нужды и т.п.)
4. Анализируем результат если результат неудовлетворительный - идём к шагу 3 и умеряем аппетиты.
5. Выходим с рачётами на руководство компании и доказываем ему нужность внедрения.

Совет: Не обязательно внедрять всё и сразу. Делайте постепенно и показывайте руководству результаты по этапам - в денежном эквиваленте (Пример - организована SD - время простоя техники сократилось на 20%, количество обработанный заявок за день - 95, решены в течении суток - 75, в течении двух суток - 20, экономия благодаря оперативному решению проблем 3000$). Почувствуйте себя в роли экономиста - учитесь считать всё в денежном эквиваленте. Ставьте себя на роль руководителя предприятием и смотри с его точки зрения на ваше предложение и просьбу денег. И ещё раз нопоминаю - деньги дают тогда, когда это обосновано и видно выгоду.

[Romker]

[kgpozdnyakov]

Я думаю подобные методики реального впечатления на владельцев бизнеса не произведут.

Я бы для начала сконцентрировался на простых и доступных цифрах:

1. Производительность труда - ПК или ПО на 1 специалиста
2. Запасы на складе

У нас по практике на 1 специалиста приходится от 100 до 200 ПК.
Один специалист решает в день от 8 до 25 заявок.

Что касается, запасов материалов и запчастей на складе - это отдельная история.

Что касается прикладных систем - то основной негативный фактор в описанной ситуации, надо подумать о том - сколько доработок ПО нужны бизнесу и одобрены, а сколько фантазий пользователей и разработчиков. Можно просто взять статистику и пойти к руководителю и попросить его отметить - что нужно, а что бред.

Далее надо сравнить производительность труда с рыночными показателями и предлать повышение за счет конкретных мероприятий, например из ITIL, но не только. Например, один из ключевых методов повышение производительности труда - перехода на дистнционную поддержку с перехватом консоли пользователя.


Удачи,
Кирилл

[Odissey]

Есть очень простой и эффективный довод в пользу внедрения диспетчерской службы (хотя бы из одного-двух человек):
Если посчитать (не обязательно с секундомером, достаточно грубой прикидки) сколько времени инженеры тратят на общение с пользователями - получится определенное время на каждого инженера в сутки (неделю, месяц, и т.д.) Зная зарплату инженера можно получить сумму потерь в деньгах.
Это то время, когда инженеру платят деньги не за то, зачем его нанимали(!!!). И если эти "потерянные" деньги частично перевести на оплату диспетчера (низкоквалифицированного и недорогостоящего) - получится реальная экономия СРАЗУ! )))
А эффективность работы инженеров повысится, благодаря тому что диспетчер снимет с них непроизводительную нагрузку...

Получив диспетчерскую службу и хотя бы какое-то средство регистрации заявок - получаем доставерную статистику для обоснования дальнейших изменений...
К сожалению, в отсутствие системы измерителей (когда все цифры умозрительные) обосновать бизнесу эффективность инвестиций практически невозможно...
_________________
Бороться и искать, найти и перепрятать!

[Ruslan]

Поэтому первое, что надо сделать - это создать HD. Он даст вам так необходимую статистику. А чтобы умозрительно не брать цифры с потолка, надо как говорит Odissey