Комментарии 33
Напишите еще, а есть ли у вас Jira? Я очень часто вижу что ее используют в фирмах для трекинга проектов и она фактически является точкой входа. Не будет ли дублирования функционала? Как вы решали этот вопрос?
Я тоже хочу попробовать внедрить OCS+GLPI в существующей компании, где учета нормального нет, есть только централизованная джира, и несколько важных для работы сервисов. Даже AD нет :) (работники сидят на всех основных платформах: Windows 7-8-10, Mac, Linux всех мастей, по убыванию).
Я тоже хочу попробовать внедрить OCS+GLPI в существующей компании, где учета нормального нет, есть только централизованная джира, и несколько важных для работы сервисов. Даже AD нет :) (работники сидят на всех основных платформах: Windows 7-8-10, Mac, Linux всех мастей, по убыванию).
А сколько всего у Вас в компании работает человек и сколько ИТ-сервисов уровня инфраструктуры и приложений?
Кстати, AD *nix и Mac вполне себе умеют через LDAP-коннекторы. А современные версии, по моим данным, это умеют «почти» из коробки без излишних «танцев с бубном»
Кстати, AD *nix и Mac вполне себе умеют через LDAP-коннекторы. А современные версии, по моим данным, это умеют «почти» из коробки без излишних «танцев с бубном»
Как минимум гит, гипервизоры, та же джира с вики и прочие.
Я знаю что AD можно и на самбе поднять (и именно в эту сторону смотрю), но не получится ли в итоге какой-то скрытый головняк?
Еще хочется использовать RADIUS для авторизации по портам (802.1x) и wifi (EAP), он как раз будет прослойкой между AD.
Т.е. уже есть ощущение что контроль начинает теряться (сотрудников около 50, машин столько же, еще около сотни разных устройств вроде телефонов), но еще нет понимания с какой стороны лучше зайти. Робко поглядываю в сторону тонких клиентов…
Моя стезя системное администрирование, тут вроде как и мое, но не совсем (у меня никсы всюду, веб-сервисы, базы данных, деплой и т.п. — т.е. я с точки зрения пользователя смотрю редко). Сейчас изучаю разные вещи чтобы попытаться вникнуть в тему, но не хочется просто взять и поставить AD чтобы было «как у всех» — хочу понять что именно я смогу получить, и какие минусы будут.
Я знаю что AD можно и на самбе поднять (и именно в эту сторону смотрю), но не получится ли в итоге какой-то скрытый головняк?
Еще хочется использовать RADIUS для авторизации по портам (802.1x) и wifi (EAP), он как раз будет прослойкой между AD.
Т.е. уже есть ощущение что контроль начинает теряться (сотрудников около 50, машин столько же, еще около сотни разных устройств вроде телефонов), но еще нет понимания с какой стороны лучше зайти. Робко поглядываю в сторону тонких клиентов…
Моя стезя системное администрирование, тут вроде как и мое, но не совсем (у меня никсы всюду, веб-сервисы, базы данных, деплой и т.п. — т.е. я с точки зрения пользователя смотрю редко). Сейчас изучаю разные вещи чтобы попытаться вникнуть в тему, но не хочется просто взять и поставить AD чтобы было «как у всех» — хочу понять что именно я смогу получить, и какие минусы будут.
Как уже описано Sergey-S-Kovalev немного ниже — первые шаги надо смотреть по его плану, с которым я целиком и полностью согласен.
От себя добавлю — самое главное — п.1 — ЗАЧЕМ это всё бизнесу. Даже не ИТ-отделу.
PS. Если бизнесу не нужно от слова «совсем», то можно на всё забить.
Без настоящей, деятельной поддержки уровня гендиректора небольшой компании — ничего не взлетит.
От себя добавлю — самое главное — п.1 — ЗАЧЕМ это всё бизнесу. Даже не ИТ-отделу.
PS. Если бизнесу не нужно от слова «совсем», то можно на всё забить.
Без настоящей, деятельной поддержки уровня гендиректора небольшой компании — ничего не взлетит.
Я все таки поправлю по п.1. Бизнесу сервисдеск не нужен. Он им денег не приносит. Сервисдеск нужен директору/начальнику по ИТ.
Для эффективного внедрения сервисдеска нужно ровно две причины: Что бы запросы от пользователей не терялись, и что бы жопа каждого первого ИТ специалиста была железобетонно прикрыта от необоснованных наездов от тех, чъе слово весит больше стоимости ИТшника в организации.
В первом случае — забытые задачи от руководства и начальства грозят наказаниями и портят карму.
Во втором случае — это ситуации связанные с тем, что начальник другого отдела может на совещаниях перед гендиром из раза в раз кидать фразу, что мол задачу ИТшнику поставил, а он подлец не сделал. Чем ставит начальника ИТ в уязвимое положение в коллективе. А при разборах выяснится, что задачу никто не ставил, либо ставилось в форме типа иди туда не знаю куда, почини то, не знаю что. Починить починили, но не то и не так ему хотелось. Про то как юзают сотрудники бухгалтерии 1Сника я вообще молчу. И бухгалтер, и расчетчик часто в одном лице, а зарплату за одного получает.
Итого. Бизнесу сервисдеск не нужен, он нужен ИТ подразделению, что бы наглядно показать на что бизнес тратит деньги и какова эффективность. Исключение: там где ИТ это профильное направление организации.
Для эффективного внедрения сервисдеска нужно ровно две причины: Что бы запросы от пользователей не терялись, и что бы жопа каждого первого ИТ специалиста была железобетонно прикрыта от необоснованных наездов от тех, чъе слово весит больше стоимости ИТшника в организации.
В первом случае — забытые задачи от руководства и начальства грозят наказаниями и портят карму.
Во втором случае — это ситуации связанные с тем, что начальник другого отдела может на совещаниях перед гендиром из раза в раз кидать фразу, что мол задачу ИТшнику поставил, а он подлец не сделал. Чем ставит начальника ИТ в уязвимое положение в коллективе. А при разборах выяснится, что задачу никто не ставил, либо ставилось в форме типа иди туда не знаю куда, почини то, не знаю что. Починить починили, но не то и не так ему хотелось. Про то как юзают сотрудники бухгалтерии 1Сника я вообще молчу. И бухгалтер, и расчетчик часто в одном лице, а зарплату за одного получает.
Итого. Бизнесу сервисдеск не нужен, он нужен ИТ подразделению, что бы наглядно показать на что бизнес тратит деньги и какова эффективность. Исключение: там где ИТ это профильное направление организации.
Тут всё зависит от бизнеса, на самом деле.
Если ИТ-отдел — это чисто техническая вспомогательная служба во главе с главным сисадмином, то да, бизнесу на этот отдел как то по барабану, а если в сферу ответственности ИТ входят бизнес-процессы и в той или иной степени менеджмент качества, то в этом случае ИТ — это бизнес-партнёр.
Лично для меня -сервис-деск — это всего лишь один из «интерфейсов», пускай и один из ключевых, для взаимодействия пользователей и ИТ-отдела.
Если ИТ-отдел — это чисто техническая вспомогательная служба во главе с главным сисадмином, то да, бизнесу на этот отдел как то по барабану, а если в сферу ответственности ИТ входят бизнес-процессы и в той или иной степени менеджмент качества, то в этом случае ИТ — это бизнес-партнёр.
Лично для меня -сервис-деск — это всего лишь один из «интерфейсов», пускай и один из ключевых, для взаимодействия пользователей и ИТ-отдела.
Полностью согласен с комментарием. ИТ отдел в компании в данном случае очень тесно завязан на бизнес-процесс.
И одна и целей внедрения — как раз упорядочивание и упрощение процесса взаимодействия с пользователями.
Надо отметить, что как ни странно, сотрудники компании очень лояльно отнеслись к подобной системе, и сейчас уже на этапе «опытной эксплуатации» активно её используют.
И одна и целей внедрения — как раз упорядочивание и упрощение процесса взаимодействия с пользователями.
Надо отметить, что как ни странно, сотрудники компании очень лояльно отнеслись к подобной системе, и сейчас уже на этапе «опытной эксплуатации» активно её используют.
В этом случае, в штате компании необходим сотрудник, отвечающий за бизнес-процессы как таковые и понимающий, обе стороны — и бизнес и ИТ. Будь то специалист по бизнес-процессам или бизнес-аналитик, но его не должны пугать такие слова как BPMN,ARIS, IDEF и одновременно для него должно быть родными слова AD, XML, .NET/Java, SOAP, REST, SLA, инцидент, проблема, управление конфигурацией и т.п.
PS. Я бы сначала определился со списком процессов взаимодействия бизнеса и ИТ и о том, как они должны быть реализованы. Т.е., ЧТО ИМЕННО хочет контролировать бизнес, в каком виде, как часто. Взаимодействие с пользователями — это лишь 50% работы ИТ-отдела, а
остальное — это уже взаимодействие с бизнесом и собственные внутренние процессы.
Кстати, очень рекомендую достаточно простую для понимания книгу — Роб Ингланд (ИТ-Скептик), «Овладевая ITIL». Найти, где её скачать несложно ( распространяется в pdf ).
По итогам прочтения и ответа самому себе и ИТ-директором на вопросы из неё можно уже делать детальный план и выбирать способы достижения целей проекта упорядочивания деятельности
PS. Я бы сначала определился со списком процессов взаимодействия бизнеса и ИТ и о том, как они должны быть реализованы. Т.е., ЧТО ИМЕННО хочет контролировать бизнес, в каком виде, как часто. Взаимодействие с пользователями — это лишь 50% работы ИТ-отдела, а
остальное — это уже взаимодействие с бизнесом и собственные внутренние процессы.
Кстати, очень рекомендую достаточно простую для понимания книгу — Роб Ингланд (ИТ-Скептик), «Овладевая ITIL». Найти, где её скачать несложно ( распространяется в pdf ).
По итогам прочтения и ответа самому себе и ИТ-директором на вопросы из неё можно уже делать детальный план и выбирать способы достижения целей проекта упорядочивания деятельности
начальник другого отдела может на совещаниях перед гендиром из раза в раз кидать фразу, что мол задачу ИТшнику поставил, а он подлец не сделал
В этом случае, если он не является его непосредственным начальником, то руководитель ИТ просто ставит его задачу ( проект? ) в очередь, правильно расставив приоритеты.
Единственное — это реалистично только для достаточно большой компании со зрелым управлением бизнесом. В ином случае — это всего лишь мечта об идеальном мире
Вы не поняли моей фразы. Суть в том, что есть проблема, но ИТ отделу ее не озвучивают. А на совещании говорят что ИТ касячит. Слово рядового специалиста против слова начальника другого отдела. Результат, кому поверит гендир — предсказуем. Что потом будет делать начальник ИТ уже не важно. Негатив в карму вброшен, и метода защиты от такого без сервисдеска нет.
Неоднократное повторение ситуации формирует мнение, что ИТ начальник не контролирует процессы, и вполне может пойти под замену.
Неоднократное повторение ситуации формирует мнение, что ИТ начальник не контролирует процессы, и вполне может пойти под замену.
Мы оба друг друга не до конца поняли.
Основной мой посыл — начальник ИТ в нормальной компании — это топ-менеджер и выше его только генеральный/исполнительный директоры, совет директоров и т.п.
Т.е. любой другой руководитель/директор — по факту, это один уровень и в этом случае споры решаются уже в несколько ином ключе.
Из своего опыта для меня логичным и нормальным является тот вариант, когда ИТ-менеджер выступает посредником между бизнесом и ИТ и решает проблемы бизнеса с помощью ИТ.
НО, я категорически не принимаю вариант, когда ИТ-руководитель находится в оппозиции бизнес-руководителям и всеми руками держится за свою власть и место даже в ущерб бизнесу.
Основной мой посыл — начальник ИТ в нормальной компании — это топ-менеджер и выше его только генеральный/исполнительный директоры, совет директоров и т.п.
Т.е. любой другой руководитель/директор — по факту, это один уровень и в этом случае споры решаются уже в несколько ином ключе.
Из своего опыта для меня логичным и нормальным является тот вариант, когда ИТ-менеджер выступает посредником между бизнесом и ИТ и решает проблемы бизнеса с помощью ИТ.
НО, я категорически не принимаю вариант, когда ИТ-руководитель находится в оппозиции бизнес-руководителям и всеми руками держится за свою власть и место даже в ущерб бизнесу.
Я бы тоже хотел, что бы в каждой первой окружающей меня компании наравне с замами по экономике, финансам и безопасности существовали еще и замы по ИТ, но все как то больше начальники департаментов и управлений, и в подавляющем большинстве начальники отделов ИТ. Тогда бы и разговор был на равных. Но увы, работаем с тем что есть.
Сергей, но с другой стороны именно к бизнесу придет ИТ с запросом по бюджету на устранения проблемы, выявленной на основании повторяющихся инцидентов на одном и том же блоке устройств. И именно статистика Сервисдеска сможет показать экономическую эффективность трат: например, когда несколько раз чинить уже дороже чем купить новое.
По п.1 — что касается зачем это бизнесу — бизнес очень хочет видеть чем занимается отдел + планирует внедрять показатели эффективности. Также само качество услуг оказываемых отделом ИТ стало падать, появились бессрочные задачи, игнорирования задач и т.д.
По большому счету задачу контроля и улучшения работы отдела поставил исполнительный директор компании, соответственно и основная поддержка с его стороны. Что касается руководителя — на момент первоначального развертывания системы у него появилась более важная и более интересная задача, поэтому проект был «заморожен».
По большому счету задачу контроля и улучшения работы отдела поставил исполнительный директор компании, соответственно и основная поддержка с его стороны. Что касается руководителя — на момент первоначального развертывания системы у него появилась более важная и более интересная задача, поэтому проект был «заморожен».
Как я и писал, в компании 150 человек, штат расширяется, критичных сервисов около 40, есть также не критичные.
Jira не используется, что касается OSC — используется модуль fusion inventory, единственная проблема которая возникла с плагином — каждое обновление системы как новая лицензия.
Я сходу обозначу все грабли внедрения сервисдеска, которые я увидел в вашей статье:
1. Отсутствие ожиданий от реализации внедрения. Вы сами не понимаете зачем оно вам нужно. Поэтому у вас в статье описывается внедрение сервисдеска ради сервисдеска. Нет четкой цели — «Для чего?». Что это даст бизнесу и тем 150 пользователям? Что это даст отделу ИТ?
2. Реанимация. В вашем же случае некромантия. Если первый раз был при текущем начальнике, то и в этот раз вы просто будете вливать свои силы в мертвую тушку. Возможно она даже будет шевелиться.
3. «Внедрением» занимается самый малоопытный и молодой член команды. При нормальном подходе к проекту внедрения сервисдеска привлекают тех кто ооочень хорошо знает, что и как в компании работает. Именно привлекают для внедрения, а не опрашивают или смотрят должностные обязанности.
4. ITIL/SLA/KPI и прочие страшные слова без первоначальной аналитики того как реально работает helpdesk в организации бесполезны от слова совсем. Если все это пишется и регламентируется до внедрения самого продукта и прописывается в его настройках до начала использования, то это еще один гвоздь в крышку гроба реализации проекта.
5. Многоуровневая поддержка в ИТ отделе из шести человек у которых строго определенные роли. Я не увидел у вас в статье наличие каллцентра, а в списке сотрудников отдела ИТ — диспетчеров. Т.е. опять ложное целеполагание.
6. «ITIL-факап» — это когда бизнес натягивают на ITIL, а не ITIL на бизнес как в общем то рекомендует эта методология. Т.е. нет понимания как работает методология в принципе. Но все себя мнят эффективными же менеджерами. Эффект будет закономерен.
7. «Бесплатнейший, опенсорс, фри-фор-алл». Их всех объединяет ровно одна вещь. Ужасный, не логичный UI. Нет, серьезно. Если конечно слаще морковки в жизни ничего не жрать, то даже очень ничего.
8. GLPI. Зашел на glpi-project.org, а мне провайдер сказал, что роскомнадзор заблочил данный сайт, хотя в реестре РКН поиск его не нашел. Я даже добрался до демо и повтыкал его. Да, действительно, что бы им пользоваться нужны мануалы, даже для специалистов.
Резюмирую, несмотря на то что вы там внедрите, но использовать это опять никто не будет, то вы хотя бы нормальный продукт используйте: ManageEngine ServiceDesk Plus Вдруг, дело было в UI :))))
Есть бесплатная версия этого вылизанного годами коммерческого продукта, которым пользуются такие неизвестные компании как Xerox / Honda / Scania / Dell / Siemens / Vodafone. И в отличие от OTRS, который пользуют не менее именитые компании он не требует напильника. Все инсталляции OTRS которые я видел всегда пилились внутренними разработчиками, потому что стоком пользоваться невозможно.
Бесплатная версия без регистрации — до 5 специалистов, если зарегаться и получить годовой ключ (продлевается без проблем сколько угодно раз в год на год) то будет ограничение в 100 одновременно работающих специалистов. Количество активов и авторов заявок не ограничено.
1. Отсутствие ожиданий от реализации внедрения. Вы сами не понимаете зачем оно вам нужно. Поэтому у вас в статье описывается внедрение сервисдеска ради сервисдеска. Нет четкой цели — «Для чего?». Что это даст бизнесу и тем 150 пользователям? Что это даст отделу ИТ?
2. Реанимация. В вашем же случае некромантия. Если первый раз был при текущем начальнике, то и в этот раз вы просто будете вливать свои силы в мертвую тушку. Возможно она даже будет шевелиться.
3. «Внедрением» занимается самый малоопытный и молодой член команды. При нормальном подходе к проекту внедрения сервисдеска привлекают тех кто ооочень хорошо знает, что и как в компании работает. Именно привлекают для внедрения, а не опрашивают или смотрят должностные обязанности.
4. ITIL/SLA/KPI и прочие страшные слова без первоначальной аналитики того как реально работает helpdesk в организации бесполезны от слова совсем. Если все это пишется и регламентируется до внедрения самого продукта и прописывается в его настройках до начала использования, то это еще один гвоздь в крышку гроба реализации проекта.
5. Многоуровневая поддержка в ИТ отделе из шести человек у которых строго определенные роли. Я не увидел у вас в статье наличие каллцентра, а в списке сотрудников отдела ИТ — диспетчеров. Т.е. опять ложное целеполагание.
6. «ITIL-факап» — это когда бизнес натягивают на ITIL, а не ITIL на бизнес как в общем то рекомендует эта методология. Т.е. нет понимания как работает методология в принципе. Но все себя мнят эффективными же менеджерами. Эффект будет закономерен.
7. «Бесплатнейший, опенсорс, фри-фор-алл». Их всех объединяет ровно одна вещь. Ужасный, не логичный UI. Нет, серьезно. Если конечно слаще морковки в жизни ничего не жрать, то даже очень ничего.
8. GLPI. Зашел на glpi-project.org, а мне провайдер сказал, что роскомнадзор заблочил данный сайт, хотя в реестре РКН поиск его не нашел. Я даже добрался до демо и повтыкал его. Да, действительно, что бы им пользоваться нужны мануалы, даже для специалистов.
Резюмирую, несмотря на то что вы там внедрите, но использовать это опять никто не будет, то вы хотя бы нормальный продукт используйте: ManageEngine ServiceDesk Plus Вдруг, дело было в UI :))))
Есть бесплатная версия этого вылизанного годами коммерческого продукта, которым пользуются такие неизвестные компании как Xerox / Honda / Scania / Dell / Siemens / Vodafone. И в отличие от OTRS, который пользуют не менее именитые компании он не требует напильника. Все инсталляции OTRS которые я видел всегда пилились внутренними разработчиками, потому что стоком пользоваться невозможно.
Бесплатная версия без регистрации — до 5 специалистов, если зарегаться и получить годовой ключ (продлевается без проблем сколько угодно раз в год на год) то будет ограничение в 100 одновременно работающих специалистов. Количество активов и авторов заявок не ограничено.
Вот в комментах каждый 2й умнее 1го :)…
А как "правильно готовить" сабж в СМБ-секторе? У вас есть чек-лист и "роадмап" или мастхев шаги по внедрению?
Поделитесь.
Думаю многим это спасет время/нервы!
При внедрении сервисдеска все очень просто:
— Определиться зачем оно вам? Я непосредственно про начальника ИТ.
— Развернуть портал. (минимум: подключить почту, настроить шаблоны ответов/подтверждений/уведомлений, подключить к AD, создать группы, наполнить их специалистами, требование заполнять поле Решение при закрытии заявки)
— Провести обучение специалистов (причем на использование продукта полчаса, и еще полтора вообще на логику работы и хождения заявок) (если продукт требует обучения всему функционалу специалиста более получаса — замените продукт)
— Приказ по организации о использования системы подачи заявок через почту, портал и если все это не доступно, по телефону.
— Воля начальника ИТ что бы задачи не ставились в обход сервисдеска. Специалисты должны работать только по задачам зарегистрированным в сервисдеске. Особенно если это задача внутри отдела ИТ.
— Подождать пару месяцев.
Теперь вы МОЖЕТЕ начать ВНЕДРЯТЬ сервисдеск.
Потому что за пару месяцев у вас появится:
1. История заявок, информация по работам по каждому специалисту, информация о хронической проблематике на рабочих местах пользователей, объем нагрузки на специалистов, понимание прозрачности работы ИТ отдела. Информация о узких местах в ИТ инфраструктуре.
Все это в виде понятного, реального отчета/графиков/аналитики.
2. Понимание у начальника ИТ чего ему еще не хватает (фильтры автоназначения на группы и сотрудников, категории/подкатегории/позиции при описании заявки что бы заполнялись, авторассылка отчетов, контроль выполнения задач от VIP, мониторинг определенных проблем критичных для его отдела)
3. Понимание, где процесс подачи заявок факапится (например, главбух категорически отказывается подавать заявки через СД, и в случае чего сразу реализует телефонное право через звонок ген/зам или просто директору)
4. Понимание кто из своих будет допиливать продукт на регулярной основе и требует ли это отдельного обучения.
— Все, теперь можно по честному внедрять, с проектной инциативой, паспортом проекта, описанием рисков и бизнес процессов. И я вам скажу что пока отдел ИТ часть организации и бизнеса, никаких SLA и KPI внедрено не будет. Они могут быть расписаны, описаны, настроены, но всем будет нас целая рать, пока их заявки будут выполняться в приемлемое время. На ITIL кстати тоже всем пофиг.
А для начальника ИТ должно быть понимание, что сервисдеск это полная прозрачность работы его отдела. Скажем так, не все хотят этой прозрачности.
Повторюсь, это смб, примерно до 2500-3000 пользователей.
— Определиться зачем оно вам? Я непосредственно про начальника ИТ.
— Развернуть портал. (минимум: подключить почту, настроить шаблоны ответов/подтверждений/уведомлений, подключить к AD, создать группы, наполнить их специалистами, требование заполнять поле Решение при закрытии заявки)
— Провести обучение специалистов (причем на использование продукта полчаса, и еще полтора вообще на логику работы и хождения заявок) (если продукт требует обучения всему функционалу специалиста более получаса — замените продукт)
— Приказ по организации о использования системы подачи заявок через почту, портал и если все это не доступно, по телефону.
— Воля начальника ИТ что бы задачи не ставились в обход сервисдеска. Специалисты должны работать только по задачам зарегистрированным в сервисдеске. Особенно если это задача внутри отдела ИТ.
— Подождать пару месяцев.
Теперь вы МОЖЕТЕ начать ВНЕДРЯТЬ сервисдеск.
Потому что за пару месяцев у вас появится:
1. История заявок, информация по работам по каждому специалисту, информация о хронической проблематике на рабочих местах пользователей, объем нагрузки на специалистов, понимание прозрачности работы ИТ отдела. Информация о узких местах в ИТ инфраструктуре.
Все это в виде понятного, реального отчета/графиков/аналитики.
2. Понимание у начальника ИТ чего ему еще не хватает (фильтры автоназначения на группы и сотрудников, категории/подкатегории/позиции при описании заявки что бы заполнялись, авторассылка отчетов, контроль выполнения задач от VIP, мониторинг определенных проблем критичных для его отдела)
3. Понимание, где процесс подачи заявок факапится (например, главбух категорически отказывается подавать заявки через СД, и в случае чего сразу реализует телефонное право через звонок ген/зам или просто директору)
4. Понимание кто из своих будет допиливать продукт на регулярной основе и требует ли это отдельного обучения.
— Все, теперь можно по честному внедрять, с проектной инциативой, паспортом проекта, описанием рисков и бизнес процессов. И я вам скажу что пока отдел ИТ часть организации и бизнеса, никаких SLA и KPI внедрено не будет. Они могут быть расписаны, описаны, настроены, но всем будет нас целая рать, пока их заявки будут выполняться в приемлемое время. На ITIL кстати тоже всем пофиг.
А для начальника ИТ должно быть понимание, что сервисдеск это полная прозрачность работы его отдела. Скажем так, не все хотят этой прозрачности.
Повторюсь, это смб, примерно до 2500-3000 пользователей.
Описал очень грубо. Хоть статью пиши.
Потому что раздел про риски проекта легко переваливает за десяток-другой пунктов.
Потому что раздел про риски проекта легко переваливает за десяток-другой пунктов.
Сергей, замечательные рекомендации.
По-моему, автор достаточно просто и базисно описал старт внедрения. Где именно его описание противоречит вашим добавлениям?
Почему вы думаете, что у автора нет или не будет поддержки руководителя?
Все описанное вами можно счесть вторым, организационным этапом внедрения, верно?
По-моему, автор достаточно просто и базисно описал старт внедрения. Где именно его описание противоречит вашим добавлениям?
Почему вы думаете, что у автора нет или не будет поддержки руководителя?
Все описанное вами можно счесть вторым, организационным этапом внедрения, верно?
Я понял ваш вопрос, попробую сформировать что-нибудь похожее в конце второй части (может дополнением)
1. Что касается ожиданий. Цели внедрения прозрачны — улучшение качества услуг, упрощение взаимодействия с пользователями и т.д. На данный момент при опытной эксплуатации есть результаты. Нет больше обращений с неограниченным сроком решения, нет задач на которые сотрудники ИТ отдела забивают/забывают.
2.Реанимация. Здесь не столько реанимация, сколько настройка системы после её развертывание, приведение к стандартам и потребностям компании. Как я написал выше, у руководителя в определенный момент появилась более приоритетная задача.
3.Внедрение. Тут не очень согласен про малоопытность. Каких-то конкретных особенностей отличающих работу данного отдела от отдела в других компаниях не так много. Есть большой опыт и работы с сервисдеск системой (правда HPSM) и частичный опыт внедрения. Здесь же я пробую (есть возможность) в том числе свои силы.
4.Как я писал — многие документы доделываются уже непосредственно во время работы системы. В том числе и SLA. Но есть те показатели которые были известны заранее, например по услугам провайдеров.
5. Есть план развития отдела, согласованный и проработанный с руководством. Поэтому система внедряется немного с заделом на будущее. Но без фанатизма.
6. Не пытаюсь натянуть бизнес на ITIL ни в коем случае.
7,8 — GLPI достаточно не плохой продукт в своей категории, конечно есть вещи которых в нем не хватает, но на данном этапе это не критичные вещи. Что касается использования сотрудниками — используют. Есть большое количество плагинов позволяющих доделать систему, добавить функционал (напишу отдельно), а что касается мануала — после того как я настраивал систему и не нашел нормальных мануалов — решил все таки расписать что и как делал, для тех кто столкнется с данной системой.
В любом случае спасибо за содержательный комментарий, я обязательно также посмотрю рекомендованную вами систему.
2.Реанимация. Здесь не столько реанимация, сколько настройка системы после её развертывание, приведение к стандартам и потребностям компании. Как я написал выше, у руководителя в определенный момент появилась более приоритетная задача.
3.Внедрение. Тут не очень согласен про малоопытность. Каких-то конкретных особенностей отличающих работу данного отдела от отдела в других компаниях не так много. Есть большой опыт и работы с сервисдеск системой (правда HPSM) и частичный опыт внедрения. Здесь же я пробую (есть возможность) в том числе свои силы.
4.Как я писал — многие документы доделываются уже непосредственно во время работы системы. В том числе и SLA. Но есть те показатели которые были известны заранее, например по услугам провайдеров.
5. Есть план развития отдела, согласованный и проработанный с руководством. Поэтому система внедряется немного с заделом на будущее. Но без фанатизма.
6. Не пытаюсь натянуть бизнес на ITIL ни в коем случае.
7,8 — GLPI достаточно не плохой продукт в своей категории, конечно есть вещи которых в нем не хватает, но на данном этапе это не критичные вещи. Что касается использования сотрудниками — используют. Есть большое количество плагинов позволяющих доделать систему, добавить функционал (напишу отдельно), а что касается мануала — после того как я настраивал систему и не нашел нормальных мануалов — решил все таки расписать что и как делал, для тех кто столкнется с данной системой.
В любом случае спасибо за содержательный комментарий, я обязательно также посмотрю рекомендованную вами систему.
+1 за ManageEngine ServiceDesk Plus
юзаем его во все поля ;)
Чего делает ваш 1С Программист?
Spiceworks и никаких гвоздей…
Кстати, OCS+GLPI на 200 раб. мест с десятком филиалов была внедрена успешно, но все ныряли в Spiceworks
Кстати, OCS+GLPI на 200 раб. мест с десятком филиалов была внедрена успешно, но все ныряли в Spiceworks
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Личный опыт внедрения системы GLPI. Часть 1