Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Создание нарядов по шаблону.

Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Страницы: 1
Создание нарядов по шаблону.
Еще один вопрос всплыл.

Приходит заявка, например на выход нового сотрудника, в связи с этой заявкой всегда заводится 5 нарядов - доступа, телефон, рабочее место итд. Исторически у нас делается так - заводится новое изменение связанное с обращением, к этому изменению применяется шаблон, по шаблону создаются наряды.

На вопрос - почему так делаете, почему не создать наряды по шаблону в самом обращении? Старослужащие сотрудники отдела отвечают - в уже зарегистрированном обращении создать наряды по шаблону невозможно, поэтому используются изменения...

хмммм..... неужели действительно невозможно добавить наряды по шаблону в зарегенное обращение? а то хрень какая то получается. изменения вообще не по назначению используются и пользователи путаются в этих бесконечных - Ваша заявка закрыта, Создано новое изменение....
Странно, а для чего вообще по Изменениям и по Заданиям (Нарядам) – делать уведомления, сотрудникам?
О назначении задания еще понятно, но все остальное это точно лишнее.


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

Изменения удобны тем, что к ним можно завязать любой сложности связи (нарядов/заданий – у всех локализация разная). И править на лету любую ошибку в маршрутизации, либо докручивать кол. Связей и групп.
Да создать то можно, но правильно ли это?
Если читали ИТИЛ, то СД как-то сделан с условием поддержки процессов ИТИЛ-а. Так вот, такого вида обращения считаются "обращения типа изменение", т.к. в вашей структуре намечается изменение. По данному запросу открывается Изменение, т.е. Change, который и поддерживает Наряды(WO) c Рабочим порядком(Workflow). Рабочий порядок в таких случаях очень обязателен, например: нет смысла подключать ПК если нет стола для работника, т.е. первым Нарядом должен быть стол, а потом уж подключение. Рабочий порядок в обращении не поддерживается.
Цитата
Василий Каменев пишет:
Да создать то можно, но правильно ли это?

Если читали ИТИЛ, то СД как-то сделан с условием поддержки процессов ИТИЛ-а. Так вот, такого вида обращения считаются "обращения типа изминение", т.к. в вашей стуктуре намечается изминение. По данному запросу открывается Изминение, т.е. Change, который и поддерживает Наряды(WO) c Рабочим порядком(Workflow). Рабочий порядок в таких случаях очень обязятелен, например: нет смысла подключать ПК если нет стола для работника, т.е. первым Нарядом должен быть стол, а потом уж подключение. Рабочий порядок в обращении не поддерживается.


Вот вот, и я о том же - неправильно тут использовать изменения.
Изменения должны создаваться, если пользователь требует внести изменения в функционал, инфраструктуру итд. Change management имеет своей целью отслеживать изменения и связывать их с Инцидентами, чтобы понимать, какое Изменение повлекло тот или иной Инцидент. А какой Инцидент может повлечь создание нового рабочего места? Такой запрос - это чистой воды ServiceCall.

Цитата
Григрий Ненашев пишет: Изменения удобны тем, что к ним можно завязать любой сложности связи (нарядов/заданий – у всех локализация разная). И править на лету любую ошибку в маршрутизации, либо докручивать кол. Связей и групп.


Мы мыслим в одном направлении, потому что корни из одного места растут...наверное. Хотя, как я уже сказал, это неверный подход.

И все таки вопрос - как же к самим Обращениям привязать такую же удобную систему создания Workflow, какую мы используем в вами Григорий сейчас в Change?
В общем, сделать это можно, но это своего рода доработка. Примеры
Код
Вот вот, и я о том же - неправильно тут использовать изменения. <br />Изменения должны создаваться, если пользователь требует внести изменения в функционал, инфраструктуру итд. Change management имеет своей целью отследивать изменения и связывать их с Инцидентами, чтобы понимать, какое Изменение повлекло тот или иной Инцидент. А какой Инцидент может повлечь создание нового рабочего места? Такой запрос - это чистой воды ServiceCall.


smile:) да нет же, правильно! пользователь может и не требовать, а обращение становиться Изменением. Он может думать что это "один клик" , а реально работа для нескольких групп.
Страницы: 1

Сегодня были (гостей: 1, пользователей: 0, из них скрытых: 0)