Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 100
Интересует такой вопрос — например, у рядового пользователя сломалась клавиатура/мышь/монитор (что угодно вместо удобно приведенного автором примера с принтером), как ему оформить запрос? Если учитывать возможность использовать компьютер коллеги, то можно столкнуться с такими проблемами как затраты времени этого коллеги, нарушение правил безопасности — если, например, отправлять запрос с его аккаунта и т.д. Если для этих целей ставить отдельные терминалы/компьютеры, то это уже выльется в большие затраты и начальство вряд ли одобрит. Собственно вопрос — как автор представляет себе живую модель взаимодействия?
Так как мы рассматриваем малый бизнес — то выхода тут два: сотрудник обращается напрямую к администратору, либо создает запрос по телефону. В обоих случаях инцидент регистрирует администратор. Если есть веб-интерфейс, он действительно может использовать компьютер коллеги.
К слову, в большом бизнесе оно ничем не отличается — мы используем компьютер коллеги вместе с коллегой и от его имени регистрируем инцидент, либо если коллега отсутствует — используем телефон.
К слову, в большом бизнесе оно ничем не отличается — мы используем компьютер коллеги вместе с коллегой и от его имени регистрируем инцидент, либо если коллега отсутствует — используем телефон.
Ну тогда получается что достаточно вести журнал обращений и предоставлять его в качестве отчёта начальству. И не нужно делать дополнительной работы по разработке/внедрению web-интерфейсов и прочего.
Конечно, если офис насчитывает малое — десять, скажем — число машин, то можно обойтись обычным журналом. Но если парк техники больше, а вы все еще один — следует оптимизировать свое время. Которое обязательно будет потрачено на верстку понятного для начальства отчета по журналу, на поиск в журнале критических инцидентов (для определения слабых мест инфраструктуры), на просмотр истории инцидентов с компонентом базы.
Экономия времени — это тоже важно, пусть даже придется затратить какие-то усилия в самом начале. Не обязательно что-то разрабатывать можно попробовать что-то бесплатное. Например, ru.wikipedia.org/wiki/OTRS
Экономия времени — это тоже важно, пусть даже придется затратить какие-то усилия в самом начале. Не обязательно что-то разрабатывать можно попробовать что-то бесплатное. Например, ru.wikipedia.org/wiki/OTRS
Скажу Вам следующее — в нашей компании (700+) человек, есть полноценная база образений в ИТ службу, внедренная в Lotus Notes, и в случае, если обращение в ИТ службу не может быть создано по объективным причинам, то пути следования у нас два:
-наиболее части применяемый — обращение с компьютера коллеги: обращение в ИТ службу, это не трактат и не требует описания проблемы более чем из 2-х предложений, так что затраты времени коллеги минимальны.
— менее часто применимы — если поломка касается аппаратной части, например монитор, клавиатура, то запрос делается посредством телефона, с обязательной регистрацией от пользователя в базе, после устранения поломки.
Так что Вы утрируете, зато ведение базы обращений дает понять, что не администратор выдумал это глупое обращение, а пользователь со всякой ерундой беспокоит ИТ службы.
PS: я являюсь именно пользователем, а не администратором и уверяю Вас, что за полтора года у всего нашего отдела (12 человек) быль только 1 случай обращения с чужих компьютеров, когда слетела Active Directory, каждый запрос отнимал не более 1 минуты — меньше, чем сотрудник тратит на перекур или перерыв на чай/кофе.
-наиболее части применяемый — обращение с компьютера коллеги: обращение в ИТ службу, это не трактат и не требует описания проблемы более чем из 2-х предложений, так что затраты времени коллеги минимальны.
— менее часто применимы — если поломка касается аппаратной части, например монитор, клавиатура, то запрос делается посредством телефона, с обязательной регистрацией от пользователя в базе, после устранения поломки.
Так что Вы утрируете, зато ведение базы обращений дает понять, что не администратор выдумал это глупое обращение, а пользователь со всякой ерундой беспокоит ИТ службы.
PS: я являюсь именно пользователем, а не администратором и уверяю Вас, что за полтора года у всего нашего отдела (12 человек) быль только 1 случай обращения с чужих компьютеров, когда слетела Active Directory, каждый запрос отнимал не более 1 минуты — меньше, чем сотрудник тратит на перекур или перерыв на чай/кофе.
Я не говорю что идея автора в корне бесполезна, наоборот, я хочу понять как можно реализовать данную модель в жизни. Но использование чужих ПК, а в случае невозможности обычный телефонный звонок для меня не выглядит достойным выходом из ситуации.
На данный момент думаю что более-менее приемлемым вариантом будет регистрация заявок через телефон посредством обработки звонков АСУ с последующей их записью и сортировкой. Как мне видится: звонит пользователь, ему асу предлагает выбрать тот или иной пункт в зависимости от поломки, далее, в соответствии с выбранными пунктами сортирует их, а уже потом их в порядке очереди исполняет IT-специалист и присваивает статус выполнено. Потом можно не только в виде текста показать начальству, но и дать послушать:)
На данный момент думаю что более-менее приемлемым вариантом будет регистрация заявок через телефон посредством обработки звонков АСУ с последующей их записью и сортировкой. Как мне видится: звонит пользователь, ему асу предлагает выбрать тот или иной пункт в зависимости от поломки, далее, в соответствии с выбранными пунктами сортирует их, а уже потом их в порядке очереди исполняет IT-специалист и присваивает статус выполнено. Потом можно не только в виде текста показать начальству, но и дать послушать:)
Могу Вам сказать следующее — в связи с тем, что мой отдел находясь в дирекции продаж, занимается достаточно специфичными вещами (очень большие проекты), а так же тем, что я являюсь технически наиболее грамотным с своем отделе — то основная часть запросов ИТ составляется именно мной, например с начал 2011 года мною написано 36 запросов, причем 28 из них содержат скриншоты и вложенные файлы, и лишь 6 запросов являются достаточно простыми и поддаются надиктовке.
Например есть у меня тех. база, позволяющая выгружать много разных отчетов, нужно создать еще 1 тип отчета, вложенных файлов запрос не имеет, но состоит из 20+ предложений, так как я должен изложить всю суть запроса.
Так что диктовка запроса через телефон не выход.
Например есть у меня тех. база, позволяющая выгружать много разных отчетов, нужно создать еще 1 тип отчета, вложенных файлов запрос не имеет, но состоит из 20+ предложений, так как я должен изложить всю суть запроса.
Так что диктовка запроса через телефон не выход.
если админ 1, то его может не быть на месте, а заявка через helpdesk (GLPI подымается за 2 часа включая установку ОС) не требует присутствия администратора на месте.
он может спокойно обедать, ходить в туалет и т.д.
Реально хелпдеск имеет смысл при более 15-20 пользователей.
он может спокойно обедать, ходить в туалет и т.д.
Реально хелпдеск имеет смысл при более 15-20 пользователей.
А как насчет обращений, которые не очень важные, но требуют незамедлительного решения? Например, не могут найти нужную кнопку в Excel (да, да — с этими проблемами тоже обращаются).
Абсолютно все запросы нужно регистрировать! Если действительно запрос срочный, например исходит от начальника — то нужно пойти и выполнить его, а постфактум записать в базу. Сотня таких запросов за квартал уже будет являться причиной найма низкоквалифицированного специалиста для освобождения вашего времени.
Низкая квалификация в области IT-познаний не всегда сопутствует низкой квалификации в других областях.
Я так понимаю, имелся ввиду низкоквалифицированный IT работник, для оказания помощи не требующей высокой квалификации, например, все те же подсказки по софту.
эээ… тогда собственно кому запросы? IT-специалист их будет слать их своим коллегам? Всё-таки думается подразумевались обычные пользователи — бухгалтера/менеджеры и т.д.
Смысл в том, что по ходу времени компании развивается ей нужны все больше новых сервисов, к примеру IP телефония, а времени внедрять ее у вас не будет из-за вот таких запросов. Обилие «глупых» запросов может послужить основанием для выделения рабочего места под вашего помощника.
С другой стороны верно и то, что в большинстве случаем поможет и обучение пользователей. Оно тоже приведет к уменьшению запросов=освобождению вашего времени.
С другой стороны верно и то, что в большинстве случаем поможет и обучение пользователей. Оно тоже приведет к уменьшению запросов=освобождению вашего времени.
Если будет зарегистрировано много обращений, которых бы не было при более высокой квалификации пользователей, начальники ИТ отделов могут поставить перед руководством вопрос об обучении сотрудников компании, такое происходит достаточно часто, и является более эффективным механизмом, нежели расширение штата ИТ службы.
Нужная кнопка в Excel — это уже недостаточная квалификация работника, если вдруг такой работник ее найти не может…
Сам работаю в небольшой организации, постоянно порываюсь, сделать что-то подобное, но всё руки никак не доходят. Пишите ещё, интересно.
Спасибо. Пишите еще.
Абсолютно непрактично.
Сами же привели пример «посмотри, у меня там компьютер не работает...», «посмотри, у меня сеть не работает», «посмотри, у меня вроде вирус, не грузится виндоуз» и еще куча подобных запросов, не позволяющих подать заявку через веб интерфейс.
А есть еще вопросы к админу, требующие простого мгновенного ответа «Какой пароль wifi», «какой адрес SMTP/POP сервера?». А после внедрения такой системы к админу не подойди — всем отправлять заявки через формочку. Бюрократия в действии.
Сами же привели пример «посмотри, у меня там компьютер не работает...», «посмотри, у меня сеть не работает», «посмотри, у меня вроде вирус, не грузится виндоуз» и еще куча подобных запросов, не позволяющих подать заявку через веб интерфейс.
А есть еще вопросы к админу, требующие простого мгновенного ответа «Какой пароль wifi», «какой адрес SMTP/POP сервера?». А после внедрения такой системы к админу не подойди — всем отправлять заявки через формочку. Бюрократия в действии.
Кто вам мешает ввести одновременно с базой запросов и базу простейших инструкций, например унас есть целый ряд инструкций — по отправки факсов через почтовый шлюз, по настройке почтового клиента и т.д., куча вопросов снимается сама собой.
По поводу запросов — компьютер не работает — да, первое время через базу будет сложно их проводить, зато пользователь будет понимать что этот отчет видит руководство, как следствие уменьшится количество глупых попыток поставить левый софт или понастраивать винду. ПО поводу вирусов — кто мешает поставить проксю, и антивирусы, 99% проблемы решено. Честно говоря, ни разу не слышал, чтобы в нашей компании (напоминаю, это 700+ человек) у кого-то возникли проблемы с вирусами, хотя степени защиты всего 2 — антивирус и прокси.
А насчет бюрократии — да бюрократия, но никто не говорил о том, что с админом запрещено общаться напрямую, я у себя делаю запрос, а для уточнений или ускорений просто звоню по телефону, все довольны — админ понимает что нужно делать, есть зарегистированное обращение и начальство видит что админ работает, у меня все исправлено.
По поводу запросов — компьютер не работает — да, первое время через базу будет сложно их проводить, зато пользователь будет понимать что этот отчет видит руководство, как следствие уменьшится количество глупых попыток поставить левый софт или понастраивать винду. ПО поводу вирусов — кто мешает поставить проксю, и антивирусы, 99% проблемы решено. Честно говоря, ни разу не слышал, чтобы в нашей компании (напоминаю, это 700+ человек) у кого-то возникли проблемы с вирусами, хотя степени защиты всего 2 — антивирус и прокси.
А насчет бюрократии — да бюрократия, но никто не говорил о том, что с админом запрещено общаться напрямую, я у себя делаю запрос, а для уточнений или ускорений просто звоню по телефону, все довольны — админ понимает что нужно делать, есть зарегистированное обращение и начальство видит что админ работает, у меня все исправлено.
Как раз наоборот, это практично с точки зрения бизнеса и оптимизации рабочего времени администратора. Да и с позиции пользователей… смотрите сами. Неужели профессиональный работник хочет ежедневно ловить админа, и спрашивать его — когда уже будет приобретена новая клавиатура, или установлен специфическое ПО? Отнюдь, ему это явно не в радость. Он попросту вынужден тратить свое время на эту беготню — и именно из-за отсутствия в организации удобной системы взаимодействия между пользователем и техническими специалистами.
К тому же, в тех редких случаях, когда онлайн-заявку подать нельзя, всегда можно зарегистрировать ее по телефону. Что до паролей к WiFi, или адресов POP3\SMTP — согласитесь, пользователю не нужно знать ни того, ни другого. Поскольку первое — риск для системы безопасности предприятия, а второе — работа, собственно, администратора — и никак не сотрудника.
А документировать вызовы — необходимо. Поскольку это отражает реальную работу администратора, и реальный уровень пользователей, а также рентабельности оборудования. Это важные бизнес-показатели, и всем выгодно отражать их объективно.
Поэтому согласиться с Вами я могу только в одном: после внедрения этой системы, к админу действительно будет не подойти. Ведь этого и следует добиваться — убрать из системы технической деятельности человеческий фактор. Админ — это техническая, а не социальная позиция.
К тому же, в тех редких случаях, когда онлайн-заявку подать нельзя, всегда можно зарегистрировать ее по телефону. Что до паролей к WiFi, или адресов POP3\SMTP — согласитесь, пользователю не нужно знать ни того, ни другого. Поскольку первое — риск для системы безопасности предприятия, а второе — работа, собственно, администратора — и никак не сотрудника.
А документировать вызовы — необходимо. Поскольку это отражает реальную работу администратора, и реальный уровень пользователей, а также рентабельности оборудования. Это важные бизнес-показатели, и всем выгодно отражать их объективно.
Поэтому согласиться с Вами я могу только в одном: после внедрения этой системы, к админу действительно будет не подойти. Ведь этого и следует добиваться — убрать из системы технической деятельности человеческий фактор. Админ — это техническая, а не социальная позиция.
>А документировать вызовы — необходимо. Поскольку это отражает реальную работу администратора, и реальный уровень пользователей
Ничего это не отражает. Это называется очковтирательство. Потому что есть профессии, такие как полицейский, охранник, админ и т.п. где результат работы тем лучше, чем меньше человеку приходит «запросов на поработать». Идеальный админ — это тот, у кого все отлично работает, ничего не ломается и он скучает на работе.
Ничего это не отражает. Это называется очковтирательство. Потому что есть профессии, такие как полицейский, охранник, админ и т.п. где результат работы тем лучше, чем меньше человеку приходит «запросов на поработать». Идеальный админ — это тот, у кого все отлично работает, ничего не ломается и он скучает на работе.
Таких ситуаций как Вы описываете не существует, ломается абсолютно все и обычно в самый неподходящий момент. Запросы поступают со всех сторон и самые различные.
Зря Вы админа с охранником сравнили. Небось он у Вас обязательно свитер носит и пьет пиво на работе?
Зря Вы админа с охранником сравнили. Небось он у Вас обязательно свитер носит и пьет пиво на работе?
>А есть еще вопросы к админу, требующие простого мгновенного ответа «Какой пароль wifi», «какой адрес SMTP/POP сервера?».
Проблема решается внедрением корпоративной wiki / KB.
По желанию — можно дополнить QA-ресурсом.
>Сами же привели пример «посмотри, у меня там компьютер не работает...», «посмотри, у меня сеть не работает», «посмотри, у меня вроде вирус, не грузится виндоуз» и еще куча подобных запросов, не позволяющих подать заявку через веб интерфейс.
1. Как справедливо заметили выше, оформление тикета по телефону еще никто не отменял.
2. На дворе — 21й век и никто не мешает использовать корпоративные смартфоны, обеспечивающие полноценный доступ к почте / WEB.
>А после внедрения такой системы к админу не подойди — всем отправлять заявки через формочку.
… ПК коллеги, телефон, SMS, мобильное приложение…
>Бюрократия в действии.
i lol'd, извините
Проблема решается внедрением корпоративной wiki / KB.
По желанию — можно дополнить QA-ресурсом.
>Сами же привели пример «посмотри, у меня там компьютер не работает...», «посмотри, у меня сеть не работает», «посмотри, у меня вроде вирус, не грузится виндоуз» и еще куча подобных запросов, не позволяющих подать заявку через веб интерфейс.
1. Как справедливо заметили выше, оформление тикета по телефону еще никто не отменял.
2. На дворе — 21й век и никто не мешает использовать корпоративные смартфоны, обеспечивающие полноценный доступ к почте / WEB.
>А после внедрения такой системы к админу не подойди — всем отправлять заявки через формочку.
… ПК коллеги, телефон, SMS, мобильное приложение…
>Бюрократия в действии.
i lol'd, извините
>Бюрократия в действии.
А как ещё совершенствовать IT-подразделение? Это всё-таки не уборщики — других денег стоят. Как ещё вы узнаете что ваш специалист, которому вы платите 50 тысяч рублей в месяц большую часть рабочего времени занимается тем, что стоит 20 тысяч, а его реально важные проекты из-за этого простаивают? Наймёте ещё одного за полтинник — уж двое-то разгребут? :) Как узнаете о низкой компьютерной квалификации пользователей? Да хотя бы конфликты внутренние разрешать как? Когда один говорит, что сообщал в IT о проблеме, а айтишники говорят, что первый раз о ней слышат.
Если у вас нет системы управления инцидентами и проблемами — вы понятия не имеете, чем занимается IT-подразделение и какие реальные IT-потребности есть у компании. Последствия — они обязательно будут: либо уйдёт айтишник на котором всё держалось и окажется, что заменить его могут только трое, либо у вас будет 5 человек за кучу денег, которые будут с умным видом гулять по коридорам со свитчем в подмышке, создавая иллюзию бурной деятельности и прося повышений, либо постоянные выматвыающие разборки между IT и юзерами.
А как ещё совершенствовать IT-подразделение? Это всё-таки не уборщики — других денег стоят. Как ещё вы узнаете что ваш специалист, которому вы платите 50 тысяч рублей в месяц большую часть рабочего времени занимается тем, что стоит 20 тысяч, а его реально важные проекты из-за этого простаивают? Наймёте ещё одного за полтинник — уж двое-то разгребут? :) Как узнаете о низкой компьютерной квалификации пользователей? Да хотя бы конфликты внутренние разрешать как? Когда один говорит, что сообщал в IT о проблеме, а айтишники говорят, что первый раз о ней слышат.
Если у вас нет системы управления инцидентами и проблемами — вы понятия не имеете, чем занимается IT-подразделение и какие реальные IT-потребности есть у компании. Последствия — они обязательно будут: либо уйдёт айтишник на котором всё держалось и окажется, что заменить его могут только трое, либо у вас будет 5 человек за кучу денег, которые будут с умным видом гулять по коридорам со свитчем в подмышке, создавая иллюзию бурной деятельности и прося повышений, либо постоянные выматвыающие разборки между IT и юзерами.
Мне кажется что никто не спорит с тем, что учёт должен быть. Спорят с тем, что он должен быть именно в форме бюрократической прослойки между пользователями и технической поддержкой и что само по себе это решит множество проблем.
«Бюрократическая прослойка» — само по себе не плохое явление же. Минус — увеличение времени отклика, да, есть такое. И это тоже можно регистрировать и основываясь на полученных данных принимать меры: если часто нужна справочная информация типа паролей-логинов-адресов — портал со справочной информацией или вики завести, если юзерам сложно писать заявки, не оставляют достаточно данных для быстрого решения проблемы — девочку-оператора с приятным голосом на телефон посадить, чтобы она принимала тикеты от юзеров и заносила их в систему.
Главное — иметь информацию на основе которой можно принимать решения, а откуда ей взяться, как не от пользователей?
Главное — иметь информацию на основе которой можно принимать решения, а откуда ей взяться, как не от пользователей?
Я вижу бюрократизацию как меньшее из зол, потому что иначе обеспечить целостность технической поддерки в большой компании ещё сложнее, но мы вроде говорили о небольших компаниях…
Вся возможная информация есть у пользователей. Каким образом установка преград между пользователями и технической поддержкой может улучшить обмен информацией?
Вся возможная информация есть у пользователей. Каким образом установка преград между пользователями и технической поддержкой может улучшить обмен информацией?
В небольшой компании от этого можно получить нехилую отдачу:
1. Если есть один админ и он всё успевает — пусть принимает звонки и заводит тикеты.
2. Если один не успевает — вопрос «почему?»
2.1. Если много проблем — какого они рода?
2.1.1. Если справится низкоквалифицированный специалист — нанимаем помощника за 1/2, а то и 1/3 стоимости админа.
2.1.2. Если проблемы серьёзные — делать нечего — ещё одного админа.
2.2. Если много обращений, справочных или по проблемам, постоянно отвлекают — нанимаем девочку за 1/3 стоимости админа и сажаем на телефон вооружив системой заведения тикетов и базой решений совсем уж банальных проблем, админ планирует и отрабатывает только тикеты.
И так далее. Решение без системы регистрации заявок: ещё одного админа — и пускай разгребают. ITIL преследует одну цель — рациональное использование IT-ресурсов компании. Когда человек (системный администратор), который получает 40-50 тысяч в месяц, консультирует юзера, где найти кнопочку в экселе вместо настройки системы резервного копирования или допиливания корпоративного портала (да хотя бы телефонного справочника с вики) — это очень странная, но такая обычная ситуация сейчас :)
1. Если есть один админ и он всё успевает — пусть принимает звонки и заводит тикеты.
2. Если один не успевает — вопрос «почему?»
2.1. Если много проблем — какого они рода?
2.1.1. Если справится низкоквалифицированный специалист — нанимаем помощника за 1/2, а то и 1/3 стоимости админа.
2.1.2. Если проблемы серьёзные — делать нечего — ещё одного админа.
2.2. Если много обращений, справочных или по проблемам, постоянно отвлекают — нанимаем девочку за 1/3 стоимости админа и сажаем на телефон вооружив системой заведения тикетов и базой решений совсем уж банальных проблем, админ планирует и отрабатывает только тикеты.
И так далее. Решение без системы регистрации заявок: ещё одного админа — и пускай разгребают. ITIL преследует одну цель — рациональное использование IT-ресурсов компании. Когда человек (системный администратор), который получает 40-50 тысяч в месяц, консультирует юзера, где найти кнопочку в экселе вместо настройки системы резервного копирования или допиливания корпоративного портала (да хотя бы телефонного справочника с вики) — это очень странная, но такая обычная ситуация сейчас :)
В большинстве случаев тикеты заводить вполне можно автоматически — либо по связке CallerID = клиент/сотрудник либо JabberID = клиент/сотрудник либо с email либо sms и т.д.
Было бы желание автоматизировать, затратив время и силы на начальном этапе, в дальнейшем нагрузка будет падать.
Возмите за пример работу саппорта в телекомах и сотовой связи — звонит клиент — сразу открывается его карточка со всеми данными. Спецу поддержки только свой ремарк внести или из шаблона выбрать и тикет уже готов и оформлен со всей нужной атрибутикой.
Было бы желание автоматизировать, затратив время и силы на начальном этапе, в дальнейшем нагрузка будет падать.
Возмите за пример работу саппорта в телекомах и сотовой связи — звонит клиент — сразу открывается его карточка со всеми данными. Спецу поддержки только свой ремарк внести или из шаблона выбрать и тикет уже готов и оформлен со всей нужной атрибутикой.
Это не так просто, как кажется. Пример плохой, поскольку там взаимодействие с клиентами — это основное направление деятельности и подобные системы типа «звонит клиент — сразу открывается его карточка со всеми данными» поддерживаются целыми отделами программистов и администраторов. Кроме того, нередки случаи, когда саппорт в телекомах, запутавшись в своей же системе начинает «жонглировать» клиента по техспециалистам и играть ему музыку в трубку часами. Везде свои демоны :)
Вот насчет «поддерживаются целыми отделами программистов» тут вы ошибаетесь ранее мне самому приходилось в т.ч. и обслуживать подобные системы и создавать их облегченную версию. В итоге скажу вам, что если создавать и устанавливать их прямыми руками — то затрат минимум. Если же нанять 100 китайцев и заставить их что-то савтоматизировать — тогда да, гемор с поддержкой обеспечен. Подобная грамотно настроенная система в затратном обслуживании не нуждается, это я вам как практик говорю, а не теоретик. Помнится еще было внутреннее правило для спецов поддержки — тратить не более 30 сек на фиксацию данных(а не сам разговор) по обращению и этого хватало!
Особо запущенные случаи, когда вопрос нельзя решить на месте, перенаправлялись в соотв службы внутри компании, но таких обращений <5% было.
Особо запущенные случаи, когда вопрос нельзя решить на месте, перенаправлялись в соотв службы внутри компании, но таких обращений <5% было.
Главное не создавать перегруженные интерфейсы как постом ниже или в redmine и аналогичных системах, где из-за обилия всевозможных опций при создании тикета и селекторов специалист поддержки попросту долго не проработает на этом месте. Нужно максимально упростить интерфейс ввода тикета и тогда процедуру их создания проще будет делегировать неИТ службам например.
А вам не кажется что эти варианты настолько очевидны, что для определения наиболее подходящего никаких особых систем внедрять не нужно? Нужен минимальный учет на стороне технической поддержки и немного желания на это посмотреть со стороны.
Понимаете, какое дело, учёт не может вестись «минимально»: он либо ведётся, либо нет. «Минимально» — это когда вы просите статистику за 2 месяца, а вам дают десяток листочков, на которых не понятно как всё собирать и отсутствуют 4-5 недель. Отругаете, через 2 месяца снова попросите статистику — вам принесут уже больше листочков, но будет не сложно определить, что 4-5 недель всё так же отсутствуют и дописаны вчера «от балды», чтобы не наругали.
И вы говорите «внедрять систему», будто это что-то монументальное и трудоёмкое. Установить и настроить GLPI — вопрос нескольких часов. Проинструктировать юзеров о том, что если они не могут дозвониться в поддержку, можно оставить заявку на сайте (с инструкцией, если там совсем туго) — и всё. Я просто не вижу причин, почему это можно не делать, если пользователей уже 20-30 и есть тенденции к пополнению.
И вы говорите «внедрять систему», будто это что-то монументальное и трудоёмкое. Установить и настроить GLPI — вопрос нескольких часов. Проинструктировать юзеров о том, что если они не могут дозвониться в поддержку, можно оставить заявку на сайте (с инструкцией, если там совсем туго) — и всё. Я просто не вижу причин, почему это можно не делать, если пользователей уже 20-30 и есть тенденции к пополнению.
Я понимаю ваши опасения, но мне кажется что они имеют больше общего с незаинтересованностью участников в порядке, чем со способом или системой учета инцидентов.
Правильная настройка это не вопрос нескольких часов, если только речь не идёт о перенаправлении всех на одну единственную общую форму описания проблемы в свободной форме.
Приблизиться по скорости к живому общению могут помочь шаблоны для типовых проблем, но их должно быть не безумное количество, а сами они не должны требовать ввода информации не имеющей отношения к проблеме. Это не пара часов, а регулярная работа. И вопрос что проще, их разрабатывать, поддерживать и биться с пользователями которые не хотят ими пользоваться или вести учёт и обобщение на стороне техподдержки без вовлечение в это пользователей.
Ни то, ни другое не будет работать без желания со стороны хотя бы техподдержки, а в случае «по ITIL'у» ещё и без желания со стороны пользователей.
Правильная настройка это не вопрос нескольких часов, если только речь не идёт о перенаправлении всех на одну единственную общую форму описания проблемы в свободной форме.
Приблизиться по скорости к живому общению могут помочь шаблоны для типовых проблем, но их должно быть не безумное количество, а сами они не должны требовать ввода информации не имеющей отношения к проблеме. Это не пара часов, а регулярная работа. И вопрос что проще, их разрабатывать, поддерживать и биться с пользователями которые не хотят ими пользоваться или вести учёт и обобщение на стороне техподдержки без вовлечение в это пользователей.
Ни то, ни другое не будет работать без желания со стороны хотя бы техподдержки, а в случае «по ITIL'у» ещё и без желания со стороны пользователей.
Для наглядности, стандартное окно заявки в системе HP Service Desk:
ID — номер заявки, который присваивается системой после регистрации.
Status — может быть зарегистрирована, поставлена (на ответственном за выполнение), выполняется, отложена, исполнена, закрыта (после подтверждения выполнения заявки обратившемся пользователем).
Registered — дата регистрации заявки.
Caller — пользователь, обратившийся с проблемой.
Для заявки выставляется приоритет (в зависимости от должности заявителя), что соответствует выделенному сроку для выполнения заявки.
Если заявка переводится в статус исполнена, то пользователю приходит письмо с просьбой подтвердить закрытие заявки (скрипт с двумя кнопками, Подтверждаю или Отклонить).
ID — номер заявки, который присваивается системой после регистрации.
Status — может быть зарегистрирована, поставлена (на ответственном за выполнение), выполняется, отложена, исполнена, закрыта (после подтверждения выполнения заявки обратившемся пользователем).
Registered — дата регистрации заявки.
Caller — пользователь, обратившийся с проблемой.
Для заявки выставляется приоритет (в зависимости от должности заявителя), что соответствует выделенному сроку для выполнения заявки.
Если заявка переводится в статус исполнена, то пользователю приходит письмо с просьбой подтвердить закрытие заявки (скрипт с двумя кнопками, Подтверждаю или Отклонить).
Хорошо написано, теперь понятно что такое ITIL.
Сами в гос. организации пользуемся HP Operation Management (Service Mangement) — штука удобная(позволяет даже определить подгруппу занимающуюся инцидентом и даже имеет базу знаний), однако для приема заявок как минимум должен сидеть один человек, обслуживающий диспетчеризацию — оценку приоритета инцидента, связывание инцидентов в проблему.
В чистом виде ITIL не работает в маленьких организациях. Контора до 100 юзеров с одним админом может ограничится следующим:
— Автоматический прием заявок, самый примитивный (почта\jabber\корпоративный портал\google docs)
— Управление конфигурациями, проблемами, доступностью и прочие сервисы ненужны.
— Приказ директора, утверждающий форму обращения в IT-службу и ЗАПРЕЩАЮЩИЙ иные формы обращений помимо регламентированых.
— SLA, распечатаный на листке А4 и висящий в коридоре у всех перед глазами.
Практические замечания: Система заявок должна быть максимально удобной для юзера. Если оформление заявки чуть сложнее, чем настучать в окошко IM «у меня не печатает принтер» — то внедрение потерпит неудачу. Если настройка, администрирование и разгребание дебрей системы обеспечивающей help desk у администратора занимает больше 10% рабочего времени — то такой help desk ненужен.
— Автоматический прием заявок, самый примитивный (почта\jabber\корпоративный портал\google docs)
— Управление конфигурациями, проблемами, доступностью и прочие сервисы ненужны.
— Приказ директора, утверждающий форму обращения в IT-службу и ЗАПРЕЩАЮЩИЙ иные формы обращений помимо регламентированых.
— SLA, распечатаный на листке А4 и висящий в коридоре у всех перед глазами.
Практические замечания: Система заявок должна быть максимально удобной для юзера. Если оформление заявки чуть сложнее, чем настучать в окошко IM «у меня не печатает принтер» — то внедрение потерпит неудачу. Если настройка, администрирование и разгребание дебрей системы обеспечивающей help desk у администратора занимает больше 10% рабочего времени — то такой help desk ненужен.
По рекомендациям почти с Вами согласен, единственное что думаю управление конфигурациями все-таки необходимо для более полноценной отчетности перед бухгалтерией, да и сама по себе инвентаризация вещь хорошая. Другое дело что не нужно делать ее слишком детальной.
ITIL не бывает в чистом виде, нет четких рекомендаций как и что нужно внедрять. Это всего-лишь набор инструкций. Внедрив только управление инцидентами, вы уже автоматически внедрили у себя ITIL. Я как-бы хотел и развеять этой статьей миф, что он не работает в маленьких компаниях.
Пускай в полном объеме и не нужно внедрять там управления проблемами, но понимать что это такое и уметь оформить проблему, пускай в виде отдельного инцидента не помешает.
ITIL не бывает в чистом виде, нет четких рекомендаций как и что нужно внедрять. Это всего-лишь набор инструкций. Внедрив только управление инцидентами, вы уже автоматически внедрили у себя ITIL. Я как-бы хотел и развеять этой статьей миф, что он не работает в маленьких компаниях.
Пускай в полном объеме и не нужно внедрять там управления проблемами, но понимать что это такое и уметь оформить проблему, пускай в виде отдельного инцидента не помешает.
Если оформление заявки чуть сложнее, чем настучать в окошко IM «у меня не печатает принтер» — то внедрение потерпит неудачу.
внедрение не потерпит неудачу, если основная формулировка де-факто будет «не было заявки — НЕ БЫЛО ПРОБЛЕМЫ». и всё. и это не зависит от способа оформления.
внедрение не потерпит неудачу, если основная формулировка де-факто будет «не было заявки — НЕ БЫЛО ПРОБЛЕМЫ». и всё. и это не зависит от способа оформления.
Полностью согласен, примерно так и реализовал здесь. Уровень компьютерной подготовки большинства персонала оставляет желать лучшего, далеко не всякий итышник не поленится каждую заявку оформлять в диалоге с десятком опций.
«Не было заявки — не было проблемы» — практически девиз современного техсаппорта в средних и крупных конторах с оплатой за время, а не за кол-во выполненных задач. Есть исключения, но их очень мало.
«Не было заявки — не было проблемы» — практически девиз современного техсаппорта в средних и крупных конторах с оплатой за время, а не за кол-во выполненных задач. Есть исключения, но их очень мало.
В ней хранятся все имеющиеся аппаратные, программные решения и персонал компании, каждому из которых присвоен инвентаризационный номер.Инвентаризационные номера наносятся на аппаратные решения с помощью наклеек, а на персонал с помощью наколок, на задней части шеи.
Всё это хорошо и правильно, только бессмысленно если поддержкой занимается один единственный человек или небольшая сплоченая команда. Вместо выравнивания нагрузки будет получен поток бессмысленных запросов от пользователей в стиле «Эксель не работает» и время будет тратиться на наведения порядка в ещё одной системе — системе регистрации инцидентов.
И вот почему:
— Формализация нужна когда есть потребность в передаче задания другому исполнителю. Опять же, с условием что все вовлеченные толково описывают как проблему, так и уже выполненные действия, что встречается очень редко.
— Пользователи зачастую не в состоянии внятно сформулировать проблему используя при этом некий общий словарь терминов. Если между вами и пользователями будет ещё один слой, вроде Helpdesk, то пользователей у них будет столько, что они, скорее всего, не будут понимать задач пользователей и будут выполнять роль испорченного телефона.
Что надо:
— Быть ближе к пользователям и больше понимать их проблемы. С этой точке зрения установка любых «шлюзов» между поддержкой и пользователями это зло.
— Вы как никто другой распологаете информацией о масштабах проблемы, поэтому именно вам проще всего обобщить. В любом понятном человеку формате.
— Вам никто не мешает описывать стандартные решения (а ля вики) и давать их пользователям. Авось хотя бы часть из них будет ими пользоваться для решения простых типовых проблем.
И вот почему:
— Формализация нужна когда есть потребность в передаче задания другому исполнителю. Опять же, с условием что все вовлеченные толково описывают как проблему, так и уже выполненные действия, что встречается очень редко.
— Пользователи зачастую не в состоянии внятно сформулировать проблему используя при этом некий общий словарь терминов. Если между вами и пользователями будет ещё один слой, вроде Helpdesk, то пользователей у них будет столько, что они, скорее всего, не будут понимать задач пользователей и будут выполнять роль испорченного телефона.
Что надо:
— Быть ближе к пользователям и больше понимать их проблемы. С этой точке зрения установка любых «шлюзов» между поддержкой и пользователями это зло.
— Вы как никто другой распологаете информацией о масштабах проблемы, поэтому именно вам проще всего обобщить. В любом понятном человеку формате.
— Вам никто не мешает описывать стандартные решения (а ля вики) и давать их пользователям. Авось хотя бы часть из них будет ими пользоваться для решения простых типовых проблем.
Честно, не совсем понимаю в чем проблема если всем занимается один человек. Да, сначала ему придется настроить систему, но это минимальные вложения времени, которые потом окупятся с лихвой. Поток бессмысленных запросов прекратится после первого квартала, когда будет видна картина у кого какой уровень и кого нужно отправить на доп. обучение. Я не думаю что кто-то захочет показать что после обучения он что-то не понимает.
Невнятно сформулированные запросы можно редактировать админ, опять же, в конце квартала все будет видно. Когда понимаешь что эти записи будет просматривать руководство начинаешь более четко формулировать мысли.
Внедрение этой системы не отменяет того что нужно в полной мере помогать пользователям. Если соберусь — напишу как можно использовать остальные процессы из библиотеки ITIL, как реагировать на отзывы от пользователей, улучшая уровень обслуживания. Тут описаны самые первые шаги, которые необходимо предпринять чтобы не было хаоса в работе. А уж какой бы не была сплоченной команда, или грамотный админ — все равно без четкого учета, оборудования, времени существует хаос.
А правильная документация — это верно, это часть knowledge management (управления знаниями).
Невнятно сформулированные запросы можно редактировать админ, опять же, в конце квартала все будет видно. Когда понимаешь что эти записи будет просматривать руководство начинаешь более четко формулировать мысли.
Внедрение этой системы не отменяет того что нужно в полной мере помогать пользователям. Если соберусь — напишу как можно использовать остальные процессы из библиотеки ITIL, как реагировать на отзывы от пользователей, улучшая уровень обслуживания. Тут описаны самые первые шаги, которые необходимо предпринять чтобы не было хаоса в работе. А уж какой бы не была сплоченной команда, или грамотный админ — все равно без четкого учета, оборудования, времени существует хаос.
А правильная документация — это верно, это часть knowledge management (управления знаниями).
Как бы это объяснить… Я вижу что в случае небольших команд ITIL вырождается в бюрократизацию, когда задачу проще решить, чем правильно зарегистрировать. Когда как для больших организаций такая степень бюрократизации может быть чуть-ли не единственным способом стабильно работать. И в том, и в другом случае, на пользователя перекладывается задача, которую проще всего решить на другом конце цепи — а именно, формализация запроса по общему словарю. В этом и заключается суть поддержки, как мне кажется: помочь пользователю в решении конкретной проблемы, а не заставлять его биться над кем-то выдуманной системой формализации запроса, игнорируя по пути самое важное что у нас есть — выработанные эволюцией механизмы взаимодействия между людьми. Возможно это звучит слишком пафосно, но суть передаёт. По моим наблюдениям людям всегда проще иметь дело с людьми, когда у них появляются проблемы.
Дупускаю что в идеальном случае система начинает работать как вы описываете. Я пока такого случая собственными глазами не видел — были только чуть более или чуть менее удачные приближения. Именно поэтому я весьма скептически отношусь к идеям внедрения ITIL в малом бизнесе. Что не умаляет ценности этой вашей статьи и следующих, которые я тоже надеюсь увидеть. ;)
Дупускаю что в идеальном случае система начинает работать как вы описываете. Я пока такого случая собственными глазами не видел — были только чуть более или чуть менее удачные приближения. Именно поэтому я весьма скептически отношусь к идеям внедрения ITIL в малом бизнесе. Что не умаляет ценности этой вашей статьи и следующих, которые я тоже надеюсь увидеть. ;)
Я понимаю о чем Вы говорите, я тоже встречал ужасно бюрократизированные решения. Тут основная проблема в том что методология ITIL должна поддерживаться на всех уровнях.
Начальство должно интересоваться отчетами, а значит отчеты должны подаваться в понятной форме.
Сотрудники должны быть заинтересованы в полном оформлении заявок, а значит оформленные заявки должны выполнятся первоочередно и в полном объеме.
Администраторы должны быть заинтересованы в уменьшении нагрузки, а значит должны более полно заполнять те инциденты, которые поступили к ним напрямую. Взаимодействовать с пользователями, улучшая интерфейс взаимодействия.
Понятно что это все идеализировано, но у нас зачастую нет понимания со стороны сотрудников или начальства, что порождает ту самую бюрократию. Сначала нужно сделать шаг со стороны администратора и показать преимущества этой системы. Потом они уже обратно не захотят возвращаться к системе с прямым контактом. Минусы естественно будут, но если взвесить все плюсы и минусы — плюсов будет намного больше. Во многом все еще зависит от правильной первоначальной настройки системы.
Начальство должно интересоваться отчетами, а значит отчеты должны подаваться в понятной форме.
Сотрудники должны быть заинтересованы в полном оформлении заявок, а значит оформленные заявки должны выполнятся первоочередно и в полном объеме.
Администраторы должны быть заинтересованы в уменьшении нагрузки, а значит должны более полно заполнять те инциденты, которые поступили к ним напрямую. Взаимодействовать с пользователями, улучшая интерфейс взаимодействия.
Понятно что это все идеализировано, но у нас зачастую нет понимания со стороны сотрудников или начальства, что порождает ту самую бюрократию. Сначала нужно сделать шаг со стороны администратора и показать преимущества этой системы. Потом они уже обратно не захотят возвращаться к системе с прямым контактом. Минусы естественно будут, но если взвесить все плюсы и минусы — плюсов будет намного больше. Во многом все еще зависит от правильной первоначальной настройки системы.
Начальство должно интересоваться отчетами, а значит отчеты должны подаваться в понятной форме.
… кто Вам сказал, что оно должно? :)
просто, они (отчеты) должны быть (желательно автоматически сформированными)…
Если начальству не интересно что происходит в компании это очень странно :) Не нужно вникать в каждую ИТ проблему, нужно видеть картину и дальше уже реагировать..
… видеть картину ИТ и поднимать проблемы наверх, в случае, если недостаточно своих полномочий для их решения, — задача того, кто управляет ИТ на предприятии. Вот здесь и необходимы системы управления, отчеты, как объективные аргументы… Топ-топ менеджеру значения таких показателей, как кол-во инцидентов, кол-во изменений конфигурации, просто так знать без нужды… абсолютно бесполезная информация :) а ежели, результаты работы ИТ подразделения всех удовлетворяют, но существует бдительный контроль со стороны выского начальства, то, на мой взгляд, — это ненормальная систуация…
Топик про маленький бизнес, в большом естественно все по-другому. В маленьком бизнесе конечно начальник должен понимать почему он должен покупать кому-то новую клавиатуру.
Полностью согласен! Верхушка руководства вообще не грузится такими задачами как кол-во тикетов и даже просрочек по ним в ИТ подразделении, пока в целом все ок.
Как правило их больше заботит расширение бизнеса, поглощения и т.п., ИТ для них что-то вроде компьютера без которого нынче никак не обойтись. Увы.
Как правило их больше заботит расширение бизнеса, поглощения и т.п., ИТ для них что-то вроде компьютера без которого нынче никак не обойтись. Увы.
… а в общем, я только «ЗА» полный учет и контроль процессов и активов, как говорится «эффективно управлять можно лишь тем, что можно достоверно измерить» :)
Пользователи зачастую не в состоянии внятно сформулировать проблему используя при этом некий общий словарь терминов. Если между вами и пользователями будет ещё один слой, вроде Helpdesk, то пользователей у них будет столько, что они, скорее всего, не будут понимать задач пользователей и будут выполнять роль испорченного телефона.
… вот посему, считаю, что обязывать пользователей использовать систему Helpdesk и, мало того, ограничивать одним каналом связи (веб-формы) — есть преступление против общественности :)
Данное ограничение имеет мнимую полезность — во-первых, пользователь вынужден тратить время на бессмысленные «точные формулировки»; во-вторых, техподдержке все равно в большинстве случаев связываться для уточнения и корректировать «точные формулировки» описания запроса; в-третьих, единственное обоснование — «экономия времени сотрудников ИТ» на практике оказывается не экономией вовсе, потому как, все что сэкономила техподдержка на трудозатратах и даже больше, оплатят своими трудозатратами пользователи, время которых, вполне себе может стоить дороже.
… считаю, что запрос может поступить, откуда угодно и как угодно, и он должен быть зарегистрирован в системе (но, например, при выполнении некоторых условий, типа «на запрос потрачено более одной минуты» и «его регистрация обоснована») и для препятствования «накручиванию счетчиков» техподдержкой ложными запросами, должны быть обеспечены и декларированы на всех уровнях процессы обязательного уведомления пользователей, от имени которых инициируется запрос, обо всех изменениях состояния запроса и, помимо этого, хорошо бы пользователю иметь доступ к системе для контроля всей своей активности.
как-то так…
Всё это хорошо и правильно, только бессмысленно если поддержкой занимается один единственный человек или небольшая сплоченая команда. Вместо выравнивания нагрузки будет получен поток бессмысленных запросов от пользователей в стиле «Эксель не работает» и время будет тратиться на наведения порядка в ещё одной системе — системе регистрации инцидентов.
Это всегда осмысленно.
Почему (2 примера):
— это поможет планировать. К примеру, появление удаленного центра
продаж (2-3 продажника) требует там провести интернет + 200 гиг на
терминальном сервере + 2 CALs + принтер + 4 пачки тонера в год.
— это поможет найти узкие места. Ну к примеру, как-то заметили что в
одном кабинете принтеры вылетают раз в полгода по небрежности (то
бумажку со скрепкой вдурячат, то водой польют). Профилактика от имени
начальства улучшила ситуацию и пропали вопли от бухгалтера (зарплаты не будет так
как админ нам не поменял картридж).
Это всегда осмысленно.
Почему (2 примера):
— это поможет планировать. К примеру, появление удаленного центра
продаж (2-3 продажника) требует там провести интернет + 200 гиг на
терминальном сервере + 2 CALs + принтер + 4 пачки тонера в год.
— это поможет найти узкие места. Ну к примеру, как-то заметили что в
одном кабинете принтеры вылетают раз в полгода по небрежности (то
бумажку со скрепкой вдурячат, то водой польют). Профилактика от имени
начальства улучшила ситуацию и пропали вопли от бухгалтера (зарплаты не будет так
как админ нам не поменял картридж).
На мой взгляд преимущество ITIL в том, что за нас уже подумано. Но это не отменяет кривого внедрения и использования, при котором, например, занания накапливаться не будут и планировать это всё не будет помогать никак.
Я не совсем понимаю какое преимущество даёт ITIL перед любой другой системой учёта инцидентов для случая с принтерами. Здесь проблема в отсутствии информации о том что было, почему было, когда было и кто виноват. Достаточно куда более простой системы на стороне технической поддержки.
Резюме: внедрение ITIL ради внедрения ITIL не панацея, осознанное внедрение любой системы учета — вполне.
Я не совсем понимаю какое преимущество даёт ITIL перед любой другой системой учёта инцидентов для случая с принтерами. Здесь проблема в отсутствии информации о том что было, почему было, когда было и кто виноват. Достаточно куда более простой системы на стороне технической поддержки.
Резюме: внедрение ITIL ради внедрения ITIL не панацея, осознанное внедрение любой системы учета — вполне.
ITIL это набор инструкций, просто он самый полный и из него можно вынести очень много полезных советов для учета. Вот и все. ITIL никогда не требует четкого внедрения по бумажке, очень гибкая методология, поэтому и популярная.
Нельзя внедрить ITIL, можно внедрить различные процессы по методологии, при чем это может быть очень детально для крупной компании и совсем обрезано для малой.
Смысл в том чтобы человек захотел, нашел и просмотрел книги по ITIL. Очень много полезных советов найдете. Это как с бэкапами, есть те кто их делают и те кто еще не делают.
Нельзя внедрить ITIL, можно внедрить различные процессы по методологии, при чем это может быть очень детально для крупной компании и совсем обрезано для малой.
Смысл в том чтобы человек захотел, нашел и просмотрел книги по ITIL. Очень много полезных советов найдете. Это как с бэкапами, есть те кто их делают и те кто еще не делают.
Продолжайте, хорошо и «на пальцах» расписано.
не плохо было бы указывать некоторые простые в освоении системы(желательно еще и бесплатные), для ваших рекомендаций.
не все же в гугл-докс вести… надо и на 10 ПК процессы автоматизировать.
не плохо было бы указывать некоторые простые в освоении системы(желательно еще и бесплатные), для ваших рекомендаций.
не все же в гугл-докс вести… надо и на 10 ПК процессы автоматизировать.
Спасибо, автор, продолжайте. Особенно интересует реализация ITIL. Инструментов много хороших и разных, и если кто-то уже выбирал и сравнивал платные или бесплатные, поделитесь наработками, пожалуйста. Планируем внедрять: ~200 пользователей, ~50 серверов.
Для такой компании идеальным решением будет www.manageengine.com/ по соотношению цена\качество. Сам устанавливал, после использования BMC Remedy и HP Service Desk впечатлило своими возможностями.
Из бесплатных вверху уже рекомендовали:
www.lissyara.su/articles/freebsd/programms/glpi/
Это не пробовал, не знаю.
ru.wikipedia.org/wiki/OTRS
Это пробовал, надо допиливать :)
Из бесплатных вверху уже рекомендовали:
www.lissyara.su/articles/freebsd/programms/glpi/
Это не пробовал, не знаю.
ru.wikipedia.org/wiki/OTRS
Это пробовал, надо допиливать :)
OTRS слишком тяжелая, glpi недостаточно гибкая, рекомендую Request Tracker как золотая середина между ними. Работал со всеми 3мя и RT мне больше всего понравился.
Я даже приведу аргументы.
OTRS — на первый взгляд подкупает своими возможностями, но когда дело доходит до работы, сложность системы и не совсем интуитивный интерефейс пугают и отталкивают новичков. Мое личное мнение OTRS это хелпдеск уровня государства ибо есть поддержка всех нужных вещей типа S/MIME и тонкая настройка.
GLPI — наоборот притягивает внимание новичков, приятный глазу интерфейс, и понятные кнопочки, но при работе возникают мелкие неудобства, которые не возможно настроить стандартными средствами. Типа перегруженность емайлов, служебной информацией при ответах, которые совершенно не нужны пользователю, невозможность тонкой настройки емайл оповещений.
OTRS — на первый взгляд подкупает своими возможностями, но когда дело доходит до работы, сложность системы и не совсем интуитивный интерефейс пугают и отталкивают новичков. Мое личное мнение OTRS это хелпдеск уровня государства ибо есть поддержка всех нужных вещей типа S/MIME и тонкая настройка.
GLPI — наоборот притягивает внимание новичков, приятный глазу интерфейс, и понятные кнопочки, но при работе возникают мелкие неудобства, которые не возможно настроить стандартными средствами. Типа перегруженность емайлов, служебной информацией при ответах, которые совершенно не нужны пользователю, невозможность тонкой настройки емайл оповещений.
Спасибо, коллеги за конкретику. Судя по описанию "Request Tracker" — это фактически тикетница. Если сравнивать с jira?
Честно говоря, не пользовался им, но слышал хвалебные отзывы, но он больше направлен на разработчиков да и коммерческий. 4 версия RT объединили c RT:FAQ, поэтому там можно вести базу знаний так же, кроме самих тикетов. В любом случае мне понравился продукт именно тем что он выполняет свою задачу и очень хорошо, хоть и не умеет ничего другого.
RT используем в нашей компании (ISP), в целом впечатления положительные, развесистый. Но как говорится, «недостатки это продолжение достоинств» — из-за «развесистости» очень перегруженный интерфейс, код хоть и на Perl, но совершенно неразборчив (слишком много перекрёстных функций, хотя это моё ИМХО).
iTop никто не пробовал? Выглядит прилично и бесплатно.
Я хелпдеск не пользую, но однажды смотрел ManageEngine ServiceDesk Plus — очень впечатлила.
Используем как основной инструмент — HP Open View Service Desk (выше есть скрин) — решение старовато, подтормаживает, однако, пока со своими обязанностями справляется. Как вариант использовать HP Service Manager, но начальство считает его дорогим.
Настроенная интеграция с Lotus Notes. В нем, помимо прочего, лежит Knowlege Base с инструкциями для сотрудников (бланки документов, простейшие инструкции и т.п.). Отправка заявки сводится к написанию письма на определенный адрес. Нет возможности написать — по телефону, пожалуйста.
Хочу добавить, что запросы типа «Эксель не работает» поступают очень редко, в конце концов это рабочий инструмент сотрудника, в котором он должен разбираться, а не постоянно консультироваться с Service Desk. Так же, формулировка проблемы в основном довольно четкая (относительно, конечно) и уж сделать скриншот ошибки могут (на удивление) практически все (PrtSc>Вставить в Word).
Из HPOVSD, кстати, очень легко извлекаются отчеты в Exel, по ним несложно отслеживать статистику, строя графики, диаграммы и т.д.
Настроенная интеграция с Lotus Notes. В нем, помимо прочего, лежит Knowlege Base с инструкциями для сотрудников (бланки документов, простейшие инструкции и т.п.). Отправка заявки сводится к написанию письма на определенный адрес. Нет возможности написать — по телефону, пожалуйста.
Хочу добавить, что запросы типа «Эксель не работает» поступают очень редко, в конце концов это рабочий инструмент сотрудника, в котором он должен разбираться, а не постоянно консультироваться с Service Desk. Так же, формулировка проблемы в основном довольно четкая (относительно, конечно) и уж сделать скриншот ошибки могут (на удивление) практически все (PrtSc>Вставить в Word).
Из HPOVSD, кстати, очень легко извлекаются отчеты в Exel, по ним несложно отслеживать статистику, строя графики, диаграммы и т.д.
А какие практические варианты CMDB (систем управления изменениями и конфигурациями) можете предложить?
Такие штуки имеют один простой недостаток — они написаны для идеального мира, где пользователи могут правильно сформулировать инцидент, обслуживающий персонал может правильно найти первопричину, про то, что «конфигурация» в некоторых случаях просто невозможна к ведению в каком-либо контролируемом виде, я даже и не говорю (попробуйте описать «конфигурацию» DNS-сервера в виндах).
попробуйте описать «конфигурацию» DNS-сервера в виндах
а в чем собственно проблема? честно не вижу…
AD меняет конфигурацию DNS согласно своим представлениям (которые определяются схемой AD, которая может поменяться в результате установки всякой ерунды, типа почтовых серверов) — как вы это предлагаете учитывать?
я предлагаю это ни в коем случае не учитывать! не учитывать динамические записи, не учитывать настройки «по умолчанию»… если «всякая ерунда» навроде «почтовых серверов» меняет конфигурацию DNS, значится это поведение должно быть отражено в документации этой «ерунды» и смысла документировать то, что уже есть в учебниках и в документации поставщика нет никакого…
я предлагаю учитывать только то, что отличает текущую конфигурацию от конфигурации «по умолчанию» и, при таком подходе, проблем с документированием «DNS-сервера в виндах», а главное, с воспроизведением аналогичной конфигурации не вижу…
Документации должно быть ровно столько, сколько необходимо специалисту для воспроизведения конфигурации.
я предлагаю учитывать только то, что отличает текущую конфигурацию от конфигурации «по умолчанию» и, при таком подходе, проблем с документированием «DNS-сервера в виндах», а главное, с воспроизведением аналогичной конфигурации не вижу…
Документации должно быть ровно столько, сколько необходимо специалисту для воспроизведения конфигурации.
Небольшой практический максимально дешевый, но рабочий пример реализации как составная часть описанного мною ранее на Хабре корпоративного портала. На панацею не претендую, но быть может комуто проще будет решить задачу аналогично.
Необходимые условия:
1. Вебсервер(к примеру LAMP) с базой сотрудников/клиентов
2. Jabber(XMPP) сервер (какой именно не особо важно).
Подготовительная работа:
1. На Jabber заводим учетку для бота для взаимодействия с клиентами или сотрудниками.
2. На вебсервере составляем классификатор ключевых слов(тегов) с названиями категорий и перечнем JabberID ответственных сотрудников.
Схема работы следующая:
1. Сотрудник или клиент пишет боту сообщение вида «ТЕГ Не работает.....»
2. Скрипт на стороне сервера получает сообщение, обрабатывает тег, сохраняет обращение в базу и отсылает закрепленным исполнителям уведомление о проблеме 1 к 1.
3. Техперсонал получает уведомление со ссылкой на вебстраницу, ознакамливается с проблемой, решает ее, пишет ответ тамже.
4. Заявитель(сотрудник или клиент) получает уведомление что либо его задача принята(например картридж выписан) либо что проблема решена.
В итоге получаем базу с типовыми проблемами и систему оперативного уведомления и прочую пищу для размышлений: что, как часто, у кого, кто решал проблему и т.п.
Затраты на внедрение: закупка железа(уже есть по условиям), закупка ПО — 0р, время на разработку 1 неделя, на багтестинг еще 1 неделя на 1-2 сотрудников.
Необходимые условия:
1. Вебсервер(к примеру LAMP) с базой сотрудников/клиентов
2. Jabber(XMPP) сервер (какой именно не особо важно).
Подготовительная работа:
1. На Jabber заводим учетку для бота для взаимодействия с клиентами или сотрудниками.
2. На вебсервере составляем классификатор ключевых слов(тегов) с названиями категорий и перечнем JabberID ответственных сотрудников.
Схема работы следующая:
1. Сотрудник или клиент пишет боту сообщение вида «ТЕГ Не работает.....»
2. Скрипт на стороне сервера получает сообщение, обрабатывает тег, сохраняет обращение в базу и отсылает закрепленным исполнителям уведомление о проблеме 1 к 1.
3. Техперсонал получает уведомление со ссылкой на вебстраницу, ознакамливается с проблемой, решает ее, пишет ответ тамже.
4. Заявитель(сотрудник или клиент) получает уведомление что либо его задача принята(например картридж выписан) либо что проблема решена.
В итоге получаем базу с типовыми проблемами и систему оперативного уведомления и прочую пищу для размышлений: что, как часто, у кого, кто решал проблему и т.п.
Затраты на внедрение: закупка железа(уже есть по условиям), закупка ПО — 0р, время на разработку 1 неделя, на багтестинг еще 1 неделя на 1-2 сотрудников.
Спасибо автору за хороший пост.
Всем заинтересовавшимся этой статьей, а так же проблемой методологии работы в рамках ИТИЛ на малых предпримятиях (или в аутсорсе) может пригодится наш будущий сервис (пока идет закрытое тестирование). Знакомьтесь и присоединяйтесь к проекту it-arena.ru и пробуйте наш smartnut. :)
(знаю, что реклама, но ведь в тему!)
Всем заинтересовавшимся этой статьей, а так же проблемой методологии работы в рамках ИТИЛ на малых предпримятиях (или в аутсорсе) может пригодится наш будущий сервис (пока идет закрытое тестирование). Знакомьтесь и присоединяйтесь к проекту it-arena.ru и пробуйте наш smartnut. :)
(знаю, что реклама, но ведь в тему!)
Большое спасибо! Если у Вас будет время, было бы очень интересно почитать об остальных рекомендациях ITIL.
Похоже пост сильно устарел, все таки последний комментарий датируется 2011 годом ^_^
Но вставлю свои пять копеек…
Время идет, но идеология ITIL остается и будет жить дальше. Когда-то давно мы столкнулись с такой же необходимостью как и автор, фиксировать инциденты и проблемы в лучших традициях ITIL. И приняли решение создать решение с нуля (да-да, многие скажут, что это зря «ведь есть куча готовых решений») и рады, что сделали это.
Поэтому хочу вас познакомить с нашим проектом, для ИТ-отделов и аутсорсинговых компаний, который позволит даже больше, чем ведение инцидентов и проблем.
Программа для всесторонней работы IT отдела.
Знакомьтесь:
Но вставлю свои пять копеек…
Время идет, но идеология ITIL остается и будет жить дальше. Когда-то давно мы столкнулись с такой же необходимостью как и автор, фиксировать инциденты и проблемы в лучших традициях ITIL. И приняли решение создать решение с нуля (да-да, многие скажут, что это зря «ведь есть куча готовых решений») и рады, что сделали это.
Поэтому хочу вас познакомить с нашим проектом, для ИТ-отделов и аутсорсинговых компаний, который позволит даже больше, чем ведение инцидентов и проблем.
Программа для всесторонней работы IT отдела.
Знакомьтесь:
Управление ИТ отделом 8Будем рады, если вы попробуете наша решение (есть демо-версия) и присоединитесь к нам :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование методологии ITIL в малом бизнесе