Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

Методические указания по различным работам

Здравствуйте! Можете подсказать есть ли (или стоит ли делать) методические указания по различным работам (или может это называется как-то по другому)?

Например: пользователь жалуется на медленную работу компьютера, инженер открывает методичку и по ней делает необходимые работы. Далее при закрытии заявки он ссылается на методику, а лучше прикладывает документ с отчетом по работам в соответствии с методикой (Настройка ОС, настройка ПО, рекомендации по улучшению "железа", и т.п.  ).

Спасибо.

 

Комментарии (11)

  • Аватар

    [Gregson], 01 декабря 2014, 12:15

    0

    Так-то это называется регламент, и пишется он исходя из состава задач и персонала, ну и SLA конечно. Может кто из гуру и поделиться драфтом))

    • Аватар

      Чумаевский Александр _ [inkara.ru], 01 декабря 2014, 21:44

      0

      Эт вещь тяжелая , сложная, если ннормально сделанная то довольно дорогая и для каждой конторы индивидуальная зависит полностью от бизнес процессов конторы.

      Могу поделиться контактами человека который мне регламенты писал . Если действительно нужно - договоритесь без проблем. 

    • Аватар

      Ланцев Андрей [Sansey], 05 декабря 2014, 13:17

      0
      По мне так это называется "база знаний". Открыл, нашел похожий случай и вперед. Регламент можно применять только к стандартизированным ситуациям. Например, установка винды с нуля. А если "заглючил" копьютер, то тут вариантов масса:) имхо.
  • Аватар

    Севрук Владимир [sevruk.com], 01 декабря 2014, 22:42

    1

    Уважаемый Алексей. Никакого открытого справочника или каталога подобных докуентов нет. То, чем вы просите поделиться - это идивидуальный интеллектуальный продукт любой ИТ-компании по организации внутренних бизнес-процессов по оказанию ИТ-услуг клиентам. Компании и их руководители тратят годы и тысячи человеко-часов, чтобы появились такие методические документы.

    Например, в моей компании регламент по типовой заявке "пользователь жалуется на медленную работу компьютера" был разработан еще 7 лет назад и с тех пор постоянно обновлялся, дополнялся, изменялся и исправлялся. Как и остальные регламенты и служебные инструкции.

    Подобные методические документы - это конкурентное преимущество сервисной ИТ-компании. Поэтому врядли здесь кто-то поделится с вами подобными документами просто так.

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

    В качестве примера приведу тут одну из старых редакций нашего регламента:
     

    Пользователь жалуется, что компьютер тормозит
     
     
    1. Autoruns
    2. Process xp
    3. Ccleaner
    4. Далее если компьютер по прежнему тормозит, то приступить к выяснению какой из компонентов компьютера приводит к замедлению работы
     
    5. Выяснив, какой компонент является узким местом, понять подлежит ли он количественному или качественному улучшению (например увеличение оперативной памяти или дискового пространства) или замене на более мощный (например замена hdd на ssd)
     
    6. Написать комментарий, что необходимо заменить физический компонент системы. 
    В комментарии к заявке указываем: 
    кому,
    по какой причине и  
    на что требуется выставить счет.  
     
    Если это винчестер, то указываем:
    объём винчестера
    интерфейс
    объем данных пользователя, 
    свои рекомендации. 
     
    Если это оперативная память, то указываем:
    текущий размер
    тип памяти
    количество слотов на материнской плате
    количество установленных модулей
    название и разрядность операционной системы
    свои рекомендации
     
    7. При невозможности дальнейшего увеличения быстродействия компьютера объяснить пользователю, почему этого сделать нельзя. Продублировать все в комментарии и предложить пользователю приобрести новый компьютер или иной выход из ситуации. 
     
    Например: 
    1. Ваш компьютер не подлежит модернизации, так как процессоров под такие материнские платы уже не вы выпускается. Можем перевести вас на терминальный сервер и тогда приложения будут работать со скоростью сервера. 
    2. Вашему компьютеру уже больше 6 лет и его мощности не хватает для обработки ваших текущих задач.  Предлагаем вам приобрести новый компьютер, который ускорит вашу работу в несколько раз.  Вы перестанете раздражаться из-за тормознутости компьютера и сможете выполнять свою работу намного оперативнее.
     
    8. Стараемся не забывать о том, что мы пропагандируем использование больших мониторов от 24 дюймов и если у пользователя маленький монитор, то не стесняемся ему предложить перейти на большую диагональ. 
    Преимущества <24 дюймовых мониторов:
    Меньшая утомляемость и раздражительность
    Увеличение визуального пространства для отображения документов
    Отображение 2 страниц одновременно в текстовых редакторах
    Меньше усилий для прокрутки документов
    Панели инструментов всех приложений сразу видны на экране
     
     
     
     
    Смысл регламента в том, чтобы либо решить проблему пользователя, либо предложить ему решение, а не просто сообщить ему о том, что компьютер тормозной и с этим ничего нельзя сделать.

     

  • Аватар

    Иванов Алексей [ale387], 01 декабря 2014, 23:39

    0
    Спасибо, я так и думал. Если все же есть какие-либо шаблоны, либо перечень регламентов, буду очень признателен.
    • Аватар

      Юсов Алексей [alexus], 02 декабря 2014, 03:14

      0

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

      Никто же не удивляется, что юристы или адвокаты берут деньги за знание кодексов, которые в открытом доступе лежат - бери, читай!

  • Аватар

    [Gregson], 02 декабря 2014, 09:48

    0

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

    Начинать можно с простейшей алгоритмизации процесса, ну и желательно, хотя бы поверхностно,  ознакомиться с практиками ITIL для применения стандартизированной терминологии. По опыту могу сказать, что построение модели и закрепление её регламентами дело достаточно недолгое, другой вопрос, что совершенству нет предела))) и , по моему мнению, ну и ITL тоже, оптимизация процесс непрерывный)  

  • Аватар

    Иванов Алексей [ale387], 02 декабря 2014, 10:58

    0

    Т.е правильно будет составить такую библиотеку - 

    Инцендент либо проблема - модель решения - регламенты решения для модели

    • Аватар

      Перерва Станислав [paranoya], 02 декабря 2014, 11:38

      0

      Модель решения - лишнее слово. Есть инцидент, есть регламент его решения. Новый, не описанный инцидент? Есть регламент диагностики, который с накоплением опыта будет постоянно изменяться.
      Регламент - это дерево решений, а  не линейный список.

      • Аватар

        [Gregson], 05 декабря 2014, 14:13

        0

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