Общение на форуме в очередной раз подтолкнуло к вопросу о процессе Управления Работами (нарядами, задачами, заданиями, операциями и т.д.). Наверное, он появился благодаря софтовым решениям класса Service Desk, где периодически вспыхивали процессы workorder management, task management, activity management. Там же он появился благодаря тем службам ИТ, которые нуждались в таком процессе. Мы его уже проектировали, внедряли - и каждый раз с новыми, отличными от предыдущих акцентами в процессе. Здесь - для одной цели, тут - для другой, а тут - просто чтобы прибить под управление инцидентами и управление изменениями.
Когда возникает необходимость в подобном процессе управления? Симптомы следующие: проблемы при оперативных координации работ для разных исполнителей в рамках одного запроса на обслуживание, инцидента или изменения. Необходимость получения отчетности выполненной работы в инцидентах, запросах на обслуживание, изменениях в разрезе исполнителей, рабочих групп, департаментов. Нужно учитывать и контролировать исполнение регламентных работ. Нужно учитывать ресурсы и рабочее время в разрезе типов выполняемой деятельности.
Похвастаюсь немного. Ну и публичное упоминание будет, для последующих патентов. Неделю назад мой коллега, Саша Цимбалистов выдвинул гениальную идею в части способа расчета и корректировки нормативов на выполняемые работы. Разговоры о нормах на выполнение работ возникают то тут, то там постоянно. Есть вопрос конечного заказчика - почему под эту работу отведено именно столько времени, нельзя ли быстрее? На этот вопрос едва ли ответит даже утвержденный ГОСТ\ТУ (которых нет с 98 года).Каждый, кто сталкивается, более или менее успешно старыми тропинками пытается разрешить вопрос с нормами. Увы, гораздо чаще - менее успешно.
А наша идея абсолютно новая (насколько мне известно, сейчас в ИТ по России никто так не делает, на Западе - судя по публикациям, тоже). Мы сейчас эту идею попробуем сразу практически реализовать в проекте. По результатам посмотрим.
среда, 21 октября 2009 г.
Процесс Управления Работами (workorder management, task management)
Подписаться на:
Комментарии к сообщению (Atom)
11 комментариев:
"А наша идея абсолютно новая (насколько мне известно, сейчас в ИТ по России никто так не делает, на Западе - судя по публикациям, тоже)."
Скорее всего делают (либо делали), но не говорят или уже не говорят об этом по разным причинам.
Мы делали и расчет нормативов и их автоматическое определение по статистике и "Гартнер" и "бенчмаркинг" с открытыми источниками и расчет из SLA/OLA/UC.
В общем какой только экзотики не встречается ;)
ОГО! Сергей, полку itsm-блогов прибыло? Поздравляю с начинанием!
По вопросу, статистика статистике рознь все-таки :) Если делали именно этим способом - тогда зря не рассказывали. Будь идея опубликованной, мы сэкономили бы год-полтора минимум. А так - дошли самостоятельно.
Ну что прям "прибыло" пока не уверен, посмотрим как пойдет ;) "Эти гранаты не той системы", я больше к ЖЖ привык.
Главное чтоб работало и польза была. Рассказывать обо всем просто нет времени, может блог это изменит все таки cut&paste сделать проще чем писать статью.
Что-то я колеги не понял, в чём собственно идея, вы её так горячё обсуждаете. Или у меня между строк не читается или вы телепатически общаетесь ещё. :-)
По статистике-то хорошо нормативы расчитывать, да вот только это уже после, а вот прогнозировать сложнее, особенно если какие-то новые системы...
А вот открытых источников нам найти почти не удалось к сожалению, правда мы по рускоязычным всё больше искали.
Я идею озвучить пока не могу - мы ее еще не пробовали. Сергей думает, что угадал :) (я думаю он наверняка угадал направление, но не точно идею). И мы обсуждаем, кто что угадал, а кто что не угадал.
Я сейчас участвую в проекте, где есть и факт, и прогноз работ. К сожалению или к счастья, до февраля будет молчок.
Зато, если результаты с нормированием работ будут признаны успешными, сделаю доклад и статью. Если неуспешными - только доклад :P
Пытались мы как то информировать пользователя о "примерном(ориентировочном)" времени выполнения работы. Делалось так:
1. Берутся все заявки по услуге
2. Рассчитывается средняя длительность выполнения(от начала работы до выполнения)
далее рассчитывается ориентировочное время выполнения заявки...
и пришлось от идеи отказаться потому что пользователи в надежде что инцидент разрешиться в обозначенное время не разрешался... когда человек(исполнитель)опаздывал, когда проблема была сложнее... в общем отказались. Не последнюю роль сыграл вот такой девайс в кабинете у техников http://s02.radikal.ru/i175/1008/8e/abfa7b2177cf.jpg
Девайс прекрасен! 8)
А вообще, я бы не рекомендовал сообщать пользователю плановое завершение конкретной работы.
Плановый срок разрешения всей заявки (запроса, инцидента) - это более востребованная вещь. Но так просто это не организуешь, можно навредить.
Разделять надо: Норматив на выполнение работы и Ориентировочный срок оказания услуг (по восстановлению услуги или внесению изменения). Нормативы согласовать внутри и "спрятать", а если уж под чем то подписались, то невредно об этом сообщать пользователю, чтоб хоть знал когда к нему могут придти.
Олег: Девайс хорош. Но расчет "средней температуры по больнице" давно признан порочной практикой )) Тут или повышать мотивацию или очень точно классифицировать обращения. Тогда можно будет укладываться.
Из-за "специфики" (читать как инертности мышления заказчика) убрали все времена вообще.
Хотим пустить трудоресурсы в создание некого механизма общения пользователя и исполнителя по средствам личного кабинета пользователя, где Пользователь сможет задать вопрос, и если заявка уже назначена на исполнение, то исполнитель чтобы смог оперативно ответить простым и понятным интерфейсом. В идеале вообще конечно в Мессенджер постить исполнителю - но это уже далекое будущее. Что скажите, есть опыт использования подобной схемы?
Олег, сделать это конечно можно. И современными средствами, даже не очень сложно.
Только вопрос - зачем? Вы хотите, чтобы пользователь с обезличенным исполнителем общался? Или именно через портал, чтобы не отвлекал телефоном?
Мало того что общался, так еще и "отпечатки" оставались в системе, что поможет при разборе полетов. Видел нечто подобное в саппорте BlueCat (девелоперы IPAM) - лично мне понравилось что не надо искать письма с сообщениями от их специалистов. Заходишь в инцидент, а там все в одном месте. Исключительно удобно.
Отправить комментарий