Добрый день! Помогите, пожалуйста, с таким вопросом.
Кто ни будь практиковал в компании «привязку» поступающих Запросов На Обслуживание, к уже текущим Запросам На изменение?
Правильно ли такое делать в рамках ITITL?
Если коротко, то у нас ЗНО попадают под SLA, а любые созданные ЗНИ – нет.
По-хорошему, надо что бы это ЗНО попало под SLA, и заказчик мог спокойно отслеживать временные рамки, отведенные на запрос.
Добрый день!
Во втором случае имеется ввиду запрос на изменение и его SLA? Не совсем понятно, зачем заказчик должен забивать себе голову ещё каким-то SLA, если у него уже есть запрос и целевой срок его решения. Может пример какой-то реальной ситуации приведёте?
Не знаю, как там по современному ITIL, но логика подсказывает, что заказчику должно быть всё равно, каким способом будет решаться его запрос на обслуживание. Возьмём запрос на добавление нового рабочего места. Вы обязались делать такие запросы за 2 рабочих дня. Если вам для добавления очередного рабочего места сотрудника “внезапно” потребовалось расширить сетевую инфраструктуру и заменить какой-нибудь коммутатор или маршрутизатор на более производительный, то заказчика это беспокоить не должно. Он же платит вам за SLA в 2 дня, и должен получить услугу в этот срок, в противном случае получайте претензию.
Да, ЗНО и его SLA.
Не должен заказчик этим голову забивать, согласен.
Но хотелось бы следующее реализовать, как пример:
Сотрудник оформляет нестандартный запрос в отдел к серверным администраторам (там есть уже готовые услуги, но его не попадает под шаблоны), его проблема попадает не под ЗНО, а под ЗНИ, мы формируем ручками ЗНИ и хотим этот нестандартный запрос на обслуживание подвязать к ЗНИ.
Если мы его оставим как есть, да, он будет решаться в рамках ЗНО.
Но мы хотим, что бы это решалась в рамках ЗНИ и в тоже время учитывался SLA.
(Может это звучит запутанно и непонятно)
Мы будем заинтересованы в том, чтобы уложиться в отведенные сроки ЗНО и заказчик будет знать, что его запрос ограничен временными рамками.
На сколько, вообще, такая практика возможна, на сколько она правильная и практикуют ли её вообще в организациях?
Может есть альтернативная точка зрения на это.
В настоящий момент, такая ситуация, что с точки зрения исполнителя (нас), нам конечно удобно создать ЗнИ, самим там создать задачу или запрос на обслуживание и ковырять его сколько нам душе угодно, т.к. ограничения по времени и SLA у нас НЕ распространяются на Запросы На Изменение. По сути это неправильно и хотелось бы сделать так, чтобы обе стороны остались довольны, мы со своим ЗНИ и заказчик со своим ЗНО.
Если у вас есть практика выполнения нестандартных запросов, то как вы регламентируете их срок решения? В моём представлении каждый такой запрос может быть уникален, как и срок его решения.
А сейчас заказчик чем недоволен? Тем, что он не знает, когда ждать решения запроса, и потому не может планировать свою работу или тем, что у него нет рычагов воздействия на вас, а вы под видом Изменений протаскиваете и бесконечно долго делаете обычные запросы?)
Я изначально исхожу из того, что у нас с заказчиком продуктивное взаимовыгодное сотрудничество, никто не пытается никого оставить в дураках. Поэтому я бы предложил SLA для изменений не вводить, но указывать предполагаемый срок выполнения для нетиповых запросов. Для него можно добавить в запрос отдельное поле. Предполагаемый срок выполнения может быть изменён по согласованию с заказчиком (для высоких и критических приоритетов) или без согласования (для средних и низких). По количеству изменений предполагаемого срока выполнения и по разнице между ним и фактической датой выполнения можно будет делать выводы о качестве планирования и управлять этим показателем. Обязательно связывать такой нетиповой запрос с изменением, номер изменения (возможно, статус и какие-то ещё атрибуты) вывести на портале пользователя в исходном запросе, чтобы заказчик видел какую-то динамику решения. Такие мысли.
Да, как раз в этом направлении мы и хотим работать.
И разумеется, никого в дураках оставлять не хотим.
Смотри в сторону только взаимовыгодного сотрудничества с заказчиком (заказчики это по сути наши сотрудники компании).
И хотим, что бы для заказчика была наглядно-прозрачная система отслеживать не только свои ЗНО, но и запросы, которые попали под ЗНИ.
Видимо, нужна доработка такой связки внутри нашей системы.
Спасибо большое, Владимир, за обратную связь и грамотный ход мыслей.
У нас есть теперь над чем подумать.