БИЗНЕС-СЕТЬ KINETICS CRM CALL-ЦЕНТРЫ ERP ITSM PM АБС
 ПоискПоиск   ПользователиПользователи   РегистрацияРегистрация   ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

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

 
ITSM Форум -> Обменяемся опытом
Автор Сообщение
Panososik



Зарегистрирован: 20.06.2007
Сообщения: 1


СообщениеДобавлено: Ср Июн 20, 2007 1:54 pm     Посмотреть профиль Отправить личное сообщение

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

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

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

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



Зарегистрирован: 01.12.2006
Сообщения: 3


СообщениеДобавлено: Пн Июл 09, 2007 12:16 pm     Посмотреть профиль Отправить личное сообщение

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



Зарегистрирован: 27.11.2006
Сообщения: 10


СообщениеДобавлено: Ср Июл 11, 2007 1:26 pm     Посмотреть профиль Отправить личное сообщение

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



Зарегистрирован: 15.08.2007
Сообщения: 1


СообщениеДобавлено: Ср Авг 15, 2007 7:08 am     Посмотреть профиль Отправить личное сообщение

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

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



Зарегистрирован: 19.08.2007
Сообщения: 2


СообщениеДобавлено: Вс Авг 19, 2007 11:42 am     Посмотреть профиль Отправить личное сообщение

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

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



Зарегистрирован: 09.03.2007
Сообщения: 26


СообщениеДобавлено: Вт Авг 21, 2007 6:10 am     Посмотреть профиль Отправить личное сообщение

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

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


Доказывается просто: берём бумажку и считаем ущёрб от простоя оборудования, простоя сервиса, сбоя в обслуживании. Посчитав идём к руководству с ЦИФРАМИ. Только в этом случае, когда вы будете оперировать РУБЛЯМИ И ДОЛЛАРАМИ УБЫТКОВ ИЛИ ПРИБЫЛИ вы получите деньги. Бизнес привык считать деньги и если вы сможете в цифрах показать, что это выгодно, то он эти деньги даст.
centaurus



Зарегистрирован: 19.08.2007
Сообщения: 2


СообщениеДобавлено: Вт Авг 21, 2007 4:17 pm     Посмотреть профиль Отправить личное сообщение

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

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



Зарегистрирован: 09.03.2007
Сообщения: 26


СообщениеДобавлено: Пн Сен 17, 2007 9:21 am     Посмотреть профиль Отправить личное сообщение

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

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



Зарегистрирован: 05.03.2007
Сообщения: 7


СообщениеДобавлено: Ср Ноя 28, 2007 5:30 pm     Посмотреть профиль Отправить личное сообщение

Ruslan писал(а):
1. Считаем деньги, которые теряем при сложившемся положении вещей сейчас.
2. Считаем деньги после внедрения принципов работы по ITIL

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



Зарегистрирован: 30.11.2007
Сообщения: 14


СообщениеДобавлено: Пт Ноя 30, 2007 7:09 am     Посмотреть профиль Отправить личное сообщение

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

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

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

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

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

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

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


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



Зарегистрирован: 21.05.2008
Сообщения: 14


СообщениеДобавлено: Сб Июн 07, 2008 1:53 pm     Посмотреть профиль Отправить личное сообщение

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

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



Зарегистрирован: 09.03.2007
Сообщения: 26


СообщениеДобавлено: Пн Июн 23, 2008 1:44 am     Посмотреть профиль Отправить личное сообщение

Поэтому первое, что надо сделать - это создать HD. Он даст вам так необходимую статистику. А чтобы умозрительно не брать цифры с потолка, надо как говорит Odissey
Цитата:
Если посчитать (не обязательно с секундомером, достаточно грубой прикидки) сколько времени инженеры тратят на общение с пользователями - получится определенное время на каждого инженера в сутки (неделю, месяц, и т.д.) Зная зарплату инженера можно получить сумму потерь в деньгах.
. Так же обстоит дело и с другими сотрудниками - это прямые потери так сказать, для начала хватит их. Есть ещё косвенные - к примеру, проигрыш тендера, из-за не работающей электронной почты.
ITSM Форум -> Обменяемся опытом Часовой пояс: GMT
Страница 1 из 1

 


Powered by LP © 2001, 2005 phpBB Group