Комментарии 15
Спасибо, жду продолжения
ваш опыт нам пригодится. ждем продолжения.
Вся статья — типичное евангелие от святых, тех кто не работал в грязи земной.
Человек рассказывающий сразу про SLA и ITIL при начальном внедрении сервисдеска либо внедрял сервисдеск ровно до момента сдачи заказчику без последующего сопровождения, либо недавно прошел какие либо курсы и владеет только теорией. Обучают на курсах всегда с позиции аутсорсера.
Отдел ИТ является частью бизнеса, если он часть организации. Поэтому рассказ про диалог с бизнесом это взгляд с позиции аутсорсера. Подход очень сильно отличается.
Аутсорсер по договорам жестко ограничен SLA и каталогом услуг. Внутренний отдел ИТ может вообще не иметь SLA и каталога услуг, поскольку заточен под решение задач любой разнообразности и за время пока автор запроса не начал жаловаться начальству.
Сервисдеск нужен в первую очередь ИТ отделу, и в рамках своей работы он диктует правила. Если, например, у бухгалтерии есть правила подачи документов и отчетности и у экономистов правила подачи бюджетов и согласования закупок, по почему ИТ отдел не может регламентировать правила подачи заявок по проблемам? Может и должен.
Самая первая цель заведения сервисдеска — не потерять ни одного запроса от пользователей, вторая — проследить историю исполнения запроса. Третья — прикрыть зад ИТшникам от необоснованных наездов про невыполненные задачи. На этом этапе временных затрат со стороны ИТ специалистов нет, поскольку регистрация заявок почти вся автоматическая (обычно через почту), а необходимость описания решения при выполнении заявки вполне компенсируется тем, что раньше по заявке сто раз звонили и сотрудникам нужно было сообщать что все готово.
И уже только после всего этого идет разговор про отчетность и тем более анализ работ. ITIL натягивается на процессы там где он натягивается, а не процессы подгоняются под ITIL. Бизнес до этого должен дорасти.
Сервисдеск должен появляться в момент появления отдела ИТ и как следствие его начальника. Количество ПК не имеет значения.
Человек рассказывающий сразу про SLA и ITIL при начальном внедрении сервисдеска либо внедрял сервисдеск ровно до момента сдачи заказчику без последующего сопровождения, либо недавно прошел какие либо курсы и владеет только теорией. Обучают на курсах всегда с позиции аутсорсера.
Отдел ИТ является частью бизнеса, если он часть организации. Поэтому рассказ про диалог с бизнесом это взгляд с позиции аутсорсера. Подход очень сильно отличается.
Аутсорсер по договорам жестко ограничен SLA и каталогом услуг. Внутренний отдел ИТ может вообще не иметь SLA и каталога услуг, поскольку заточен под решение задач любой разнообразности и за время пока автор запроса не начал жаловаться начальству.
Сервисдеск нужен в первую очередь ИТ отделу, и в рамках своей работы он диктует правила. Если, например, у бухгалтерии есть правила подачи документов и отчетности и у экономистов правила подачи бюджетов и согласования закупок, по почему ИТ отдел не может регламентировать правила подачи заявок по проблемам? Может и должен.
Самая первая цель заведения сервисдеска — не потерять ни одного запроса от пользователей, вторая — проследить историю исполнения запроса. Третья — прикрыть зад ИТшникам от необоснованных наездов про невыполненные задачи. На этом этапе временных затрат со стороны ИТ специалистов нет, поскольку регистрация заявок почти вся автоматическая (обычно через почту), а необходимость описания решения при выполнении заявки вполне компенсируется тем, что раньше по заявке сто раз звонили и сотрудникам нужно было сообщать что все готово.
И уже только после всего этого идет разговор про отчетность и тем более анализ работ. ITIL натягивается на процессы там где он натягивается, а не процессы подгоняются под ITIL. Бизнес до этого должен дорасти.
Сервисдеск должен появляться в момент появления отдела ИТ и как следствие его начальника. Количество ПК не имеет значения.
Человек рассказывающий сразу про SLA и ITIL при начальном внедрении сервисдеска
За основу я взял библиотеку ITIL, да. Собственно и рассказываю как на ее основе можно быстро развернуть сервис деск и учесть базовые рекомендации.
Как вы могли заметить – самая первая статья должна помочь читателю в принципе понять –а нужно ли ему это? Про SLA я собираюсь писать в самой последней статье, т.к. это наименее значимый на мой взгляд пункт при начальном внедрении внутри компании. Но достаточно значим, чтобы его в принципе упомянуть. А PDCA, постоянное улучшение сервиса, оценка качества услуг, отказоустойчивость, непрерывность в принципе не будет затрагиваться.
Поэтому рассказ про диалог с бизнесом это взгляд с позиции аутсорсера.
Это не взгляд с позиции аутсорсера. Если ИТ директор равноправный партнер среди топ-менеджмента, то он выстраивает диалог с бизнесом. Объясняет, чем именно занимается ИТ отдел, какие у него есть ресурсы, что он может и что не может. И постоянно доказывает, что свой, родной ИТ отдел лучше всех этих аутсорсеров. Доказывает в цифрах.
Для этого и нужны все эти отчеты. А в идеале – вносит предложения призванные увеличить прибыли этого самого бизнеса и/или сократить издержки.
Человек рассказывающий сразу про SLA и ITIL при начальном внедрении сервисдеска либо внедрял сервисдеск ровно до момента сдачи заказчику без последующего сопровождения, либо недавно прошел какие либо курсы и владеет только теорией. Обучают на курсах всегда с позиции аутсорсера.
Вы ошиблись все три раза.
И меня печалит на сколько необоснованные выводы вы делаете.
На момент когда я пришел в компанию у нее было три дежурных инженера (я был один из этих троих), два программиста и 30 точек на обслуживании.
Заявки скидывались инженерам по почте, в почте же был учет + телефон.
Сейчас уже порядка 150 объектов, более 10 инженеров и полноценный отдел автоматизации.
ИТ отдел при мне рос вместе с компанией, и я принимал активное участие в его становлении.
В том числе внедрял системы учета обращений (аж две штуки) и выстраивал процессы работы с заявками.
Собственно, занимаясь всем этим я и узнал что оказывается есть такая штука как ITIL и можно не хаотично пытаться хоть что-то сделать, а попытаться использовать чужой опыт, чужие best-practice. Уже имея порядка пяти лет опыта работы прошел более-менее полноценное обучение и получил сертификат (да, это была чисто моя блажь, хотел красивую бумажку :-) ).
Спасибо первому ИТ директору, с которым успел поработать – он в принципе начал внедрение, заложил именно фундаментальную базу с рядом утвержденных документов. Я уже больше поверх нее технические аспекты допиливал.
Внутренний отдел ИТ может вообще не иметь SLA и каталога услуг
Может. И это очень дурная практика. Чем больше компания, тем эта практика дурнее.
Тогда говорят «компьютер включен в розетку, значит за работу розетки тоже отвечает ИТ отдел». Каталога услуг нет? Нет. Идите и чините.
«Хотим чтобы ИТ еще и видеонаблюдение нам ремонтировало. Какой ввод новой услуги? Какое выделение дополнительных мощностей? Там всего-то 150 регистраторов и 450 камер. Текущими ресурсами справляйтесь. И без понижения качества там у меня.» Это отсутствия портфеля услуг. Расчет издержек на новую услугу входит в этот блок.
« Мне нужна мгновенная реакция от ИТ отдела. Я позвонила, а они пришли только через 10 минут, что за безобразие?» И это говорил не топ-менеджер, а обычный дизайнер. И нет нормального SLA, согласно которому у нас 15 минут на реакцию и сутки на устранение. Жалоба идет вице-президенту, от него втык, т.к. он как владелец бизнеса. Он не принял SLA и у ИТ отдела нет запаса времени на реакцию.
Времени ровно столько – пока не начнет жаловаться пользователь.
Некоторые жалуются уже через 15-20 минут.
Сервисдеск нужен в первую очередь ИТ отделу, и в рамках своей работы он диктует правила.
Выстроенный сервис деск ИТ отделу как таковой не нужен. ИТ отдел без полноценного сервис-деска может сколько угодно ныть, что много обращений, что не хватает инженеров и т.д. Сервис деск нужен бизнесу, чтобы более-менее объективно оценивать ситуацию по части ИТ (поддержки) в компании.
(сейчас мы говорим про выстроенный и более-менее организованный сервис деск, а не несколько инженеров, которые реагируют на звонки)
ИТ отделу полноценный сервис-деск нужен только в случае реальной нехватки ресурсов, чтобы обосновать потребность в доп. затратах
почему ИТ отдел не может регламентировать правила подачи заявок по проблемам? Может и должен.
Может только в том случае, если бизнес ему это разрешил. Если бизнес сказал принимать все заявки в любом виде, то принимаем все заявки в любом виде.
Либо идем работать на другой бизнес. Это уже компетенция руководителя доносить эту мысль до бизнеса. Вести с ним диалог.
Самая первая цель заведения сервисдеска — не потерять ни одного запроса от пользователей, вторая — проследить историю исполнения запроса. Третья — прикрыть зад ИТшникам от необоснованных наездов про невыполненные задачи.
Мы Сервис-деск. Наша задача как любой сервисной службы – счастье клиента.
Если клиент доволен (в моем случае это внутренний клиент), то мы справляемся с работой.
Если клиент не доволен, то мы не справляемся с работой.
Все остальное – мультики, как говорят мои питерские коллеги.
И уже только после всего этого идет разговор про отчетность и тем более анализ работ. ITIL натягивается на процессы там где он натягивается, а не процессы подгоняются под ITIL. Бизнес до этого должен дорасти.
Вы не поверите, но именно про это и была первая стать – не везде имеет смысл внедрять сервис деск. Компания должна до этого дорасти. А отчетность…если у вас заявки в принципе регистрируются в какой-то системе, то отчетность из нее вполне можно вытянуть. Даже ведя заявки в аутлуковских тасках мы ухитрялись вытягивать с него нужные нам отчеты.
Сервисдеск должен появляться в момент появления отдела ИТ и как следствие его начальника. Количество ПК не имеет значения.
Не редки случаи, когда с хелпдеска ИТ отдел и начинается. Нанимают эникейщиков для ремонта компьютеров. Компания растет, берут больше эникейщиков.
В какой-то момент понимают, что хозяйство разрослось на столько, что надо бы как-то его нормально организовывать. Обычно этот период очень удачен для тех, кто хочет из эникейщика стать кем-то большим, чем просто эникей.
Собственно, для таких людей в том числе я и пишу. Чтобы они знали какой шаг можно сделать следующим. И их не оттеснили/выгнали, заменив более грамотными, а дали расти вместе с компанией.
И постоянно доказывает, что свой, родной ИТ отдел лучше всех этих аутсорсеров.Вот вообще не всегда это факт. Чаще дешевле оставить у себя только команду разработчиков, а остальное отдать на аутсорс. Примеров за границей — каждый первый. У нас ощутимо реже.
На момент когда я пришел в компанию у нее было три дежурных инженера (я был один из этих троих), два программиста и 30 точек на обслуживании. Заявки скидывались инженерам по почте, в почте же был учет + телефон.Какое совпадение. Ну раз меряться изволите, то я тоже могу. Начал примерно так же как у вас с розницы на 40 магазинов. Сейчас уже не только розница и я не рядовой спец, я уже перестал считать точки обслуживания. А количество организаций с внедрением сервисдеска перевалило за 20+, включая организацию на 1800+ человек. Сертификата нет :/. Я предпочитаю деньгами.
Тогда говорят «компьютер включен в розетку, значит за работу розетки тоже отвечает ИТ отдел». Каталога услуг нет? Нет. Идите и чините.Вы уж определитесь, либо у вас ИТ дир один из топов, либо такой позиции в штатке нет, и тогда если скажут и разетки чинить будете.
Хотим чтобы ИТ еще и видеонаблюдение нам ремонтировало. Какой ввод новой услуги?Вы опять перемешиваете внутреннего аутсорсера и собственный ИТ отдел. Совершенное разные уровни зрелости ИТ.
Жалоба идет вице-президенту, от него втык, т.к. он как владелец бизнеса. Он не принял SLA и у ИТ отдела нет запаса времени на реакцию.… Некоторые жалуются уже через 15-20 минут.Вас читать страшно. У вас там адекватные люди вообще есть? И вице-президент у Вас так близко к народу :) Впрочем я могу рассказать множество таких и подобных историй. Касяки бухгалтерии, которые пытаются выдать за касяки прогеров или глюки программы учета вообще на стадии внедрения сервисдеска быстро всплывают.
Однако есть задачи, которые нужно сделать прямо сейчас, хоть там и SLA 2 часа. И поверьте, наличие подписанного всеми SLA Вас не спасет там, где задачу можно и очень нужно было решить за 5 минут, а спец продинамил всех на два 1 часа 55 минут.
Например, решение проблемы с банк-клиентом при отправке платежа по кредиту, который бухгалтерия любит отправлять в последний час приема платежей у банка.
Выстроенный сервис деск ИТ отделу как таковой не нужен. ИТ отдел без полноценного сервис-деска может сколько угодно ныть, что много обращений, что не хватает инженеров и т.д. Сервис деск нужен бизнесу, чтобы более-менее объективно оценивать ситуацию по части ИТ (поддержки) в компании.Простите, мой опыт отторгает Ваше субъективное виденье кто кому нужен, ибо бизнесу насоченьмного есть сервисдеск или нет. Бизнес для принятия решений хочет конкретных реальных цифр. Возьмутся они из сервисдеска или кипы задокументированных обращений ему пофиг.
Если бизнес сказал принимать все заявки в любом виде, то принимаем все заявки в любом виде.Помоему вас там за аналог поломоек держат, простите. Бухгалтерия значит формат отчетности требует, юристы комплекты документов вполне законно требуют, а ИТ значит должно проглатывать в любом виде? У вас точно ИТ в организации выросло? А под вашим бизнесом не какое-нить государственное унитарное предприятие понимается? Ну или там в топах братки бывшие не сидят?
Если клиент не доволен, то мы не справляемся с работой.Делайте так, что бы при любом результате во рту у клиента оставался привкус лесных ягод. Главное делать свою работу хорошо и вовремя, а от неадекватов защитит сервисдеск и совместная комиссия по разбору с заказчиком.
не везде имеет смысл внедрять сервис дескЯ говорил про процессы ITIL, а про сервисдеск Вы ошибаетесь.
Даже ведя заявки в аутлуковских тасках мы ухитрялись вытягивать с него нужные нам отчеты.Сомнительный повод для хвастовства. Ну прям по детски.
Не редки случаи, когда с хелпдеска ИТ отдел и начинается. Нанимают эникейщиков для ремонта компьютеров. Компания растет, берут больше эникейщиков.Как только появляется второй эникейщик, первый становится главным ответственным у руководства. Сервисдеск как таковой может и не появится даже на 10м эникейщике.
ну и в оконцовке
Быть одним из 10 инженеров и отвечать за работу 10 инженеров совершенно разные вещи, заставляющие думать, планировать и нести ответственность совершенно по разному.
Чаще дешевле оставить у себя только команду разработчиков, а остальное отдать на аутсорс.
Надо просто банально считать, что дешевле. Каждый случай индивидуален.
Ну раз меряться изволите, то я тоже могу.
Вы уже свое хозяйство ранее доставали и его размер мне вполне известен.
Сертификата нет :/. Я предпочитаю деньгами.
Я тоже :). Но красивую бумажку международного образца таки хотелось, поэтому взял отпуск, оплатил курсы и за неделю подготовился и сдал экзамен. Благо значительную часть и так знал, курсы нужны были больше для упорядочивания знаний.
Реально это была просто хотелка. Некоторые люди хотят новый телефончик. А вот мне хотелось сертификатик :)
Вы уж определитесь, либо у вас ИТ дир один из топов, либо такой позиции в штатке нет, и тогда если скажут и разетки чинить будете.
В нашем конкретном случае ИТ директор только формально топ. Вес у него не такой большой как хотелось бы. Компания занимается розничными продажами.
Вы опять перемешиваете внутреннего аутсорсера и собственный ИТ отдел. Совершенное разные уровни зрелости ИТ.
Как именно я перемешиваю? Внутреннему ИТ отделу вменили контроль работоспособности всей системы видеонаблюдения без расширения штата и без права отдать это целиком на аутсорс. Сломалась одна камера – организовывайте доставку замены и монтаж на месте. В регионах поразово вызывайте спецов для монтажа. Собственно я начинал проработку как бы это все-таки тихонечко полностью спихнуть на аутсорс, но не успел найти компанию, которая бы нас устроила.
Вас читать страшно. У вас там адекватные люди вообще есть? И вице-президент у Вас так близко к народу :)
Адекватных к счастью большинство. Но из-за неадекватов им приходилось меньше времени уделять. Вице-президент лично собеседует каждого нового сотрудника в офис (вплоть до секретаря и ассистента). Из-за этого у некоторых свеже-нанятых сотрудников сложилось такое мнение, что можно его тревожить по всякой ерунде. Ну и себя хотели, наверное, показать. Как они за дело радеют. Отдел был полностью свеже нанятый. О выходе сотрудников нас уведомляли за день-два до выхода, всем нужны компьютеры повышенной мощности, лицензии на корелы, фотошопы, иллюстраторы… А вот денег закупать их заранее никто не выдавал. Из-за этого тоже было достаточно много нервов.
Однако есть задачи, которые нужно сделать прямо сейчас, хоть там и SLA 2 часа. И поверьте, наличие подписанного всеми SLA Вас не спасет там, где задачу можно и очень нужно было решить за 5 минут, а спец продинамил всех на два 1 часа 55 минут.
SLA в том ракурсе, который я описываю (вернее только опишу в последней статье, когда до нее доберусь), призван защитить ИТ специалистов от неадекватов.
Главбух один раз четко сказала – если мы не сдаем отчет до 16:00 сегодня, то на компанию штраф 5 млн. р. У бухгалтера все было готово, надо только его отправить. Надеюсь вы сможете быстро починить компьютер моему бухгалтеру. Ясно дело мы все отложили и занялись этой проблемой.
Бизнес для принятия решений хочет конкретных реальных цифр. Возьмутся они из сервисдеска или кипы задокументированных обращений ему пофиг
Хм, а откуда возьмется кипа задокументированных обращений в удобном для работы виде? Если никто не озадачился налаживанием процесса работы с инцидентами?
Бухгалтерия значит формат отчетности требует, юристы комплекты документов вполне законно требуют, а ИТ значит должно проглатывать в любом виде? У вас точно ИТ в организации выросло? А под вашим бизнесом не какое-нить государственное унитарное предприятие понимается?
Коммерческая структура, розничная сеть, ТНП. Как вы заметили юристы и бухи законно требуют. Если бы не требования законодательства, то их бы так же обязали проглатывать как есть. Учитывая, что с полного нуля таки выстроили процесс управления инцидентами, не так хаотично стали делать изменения, то да, рост на лицо. Но до потолка еще далеко.
Делайте так, что бы при любом результате во рту у клиента оставался привкус лесных ягод.
Ну хоть в этом мы с вами сошлись полностью :).
Сомнительный повод для хвастовства. Ну прям по детски.
Вы меня неправильно услышали. Это не хвастовство. Вы считаете отчетность отдельным блоком. Я хотел показать, что если есть хоть какая-то система учета обращений, то из нее отчеты можно вытянуть. На сколько они будут подробными – другой вопрос. Но зная какие метрики ты хочешь видеть ты уже сможешь более осознанно выбирать систему учета.
Сервисдеск как таковой может и не появится даже на 10м эникейщике.
Я это и не утверждал. Просто в определенный момент здравый собственник должен задаться вопросом – а чем эти 10 оболтусов у меня заняты? Не переплачиваю ли я им? Если процесс управления инцидентами налажен, то ИТ отдел сможет дать вразумительный ответ в цифрах. А если не налажен, то придется оперативненько налаживать, дабы в следующий раз уже иметь ответ.
Быть одним из 10 инженеров и отвечать за работу 10 инженеров совершенно разные вещи, заставляющие думать, планировать и нести ответственность совершенно по разному.
Согласен, инженером было намного проще. Голова о многих вещах не болела :)… Давно это было…
И в оконцовке – вы умный человек. И вы конечно же поняли, что статья писалась не для вас. Не для того, у «кого количество организаций с внедрением сервисдеска перевалило за 20+, включая организацию на 1800+ человек». Маловероятно, что вы почерпнете в ней для себя что-то новое.
Я делюсь тем опытом, который успел накопить в одной конкретной организации. Есть специалисты, у которых нет этого опыта. Надеюсь им материал будет полезен.
Рассчитываю, что на этом мы с вам холивары закончим.
Если у вас есть конкретные рекомендации напрямую по материалу статьи, то готов их выслушать и возможно внести в текст статьи. Думаю человеку с вашим опытом есть что сказать по делу.
Только прошу давать именно в формате правок, а не обобщенных рассуждений. Как пример « в третьем абзаце стоит добавить, что это работает только в таких случаях, а вот в таких случаях мы имели абсолютно обратный эффект».
Если дадите примеры из реальной практики — то вообще шикарно.
Надо просто банально считать, что дешевле. Каждый случай индивидуален.Если у Вас типовая конфигурация учетной системы, выгоднее аутсорс. Если у Вас кастомная конфигурация под специфические потребности бизнеса, выгоднее своя команда разработчиков. Выбор невелик.
А вот мне хотелось сертификатик :)Для души, понимаю.
Собственно я начинал проработку как бы это все-таки тихонечко полностью спихнуть на аутсорс, но не успел найти компанию, которая бы нас устроила.А иногда их нет, или они неоправданно дороги. У нас часть направлений выросло именно по такой причине.
О выходе сотрудников нас уведомляли за день-два до выхода, всем нужны компьютеры повышенной мощности, лицензии на корелы, фотошопы, иллюстраторы… А вот денег закупать их заранее никто не выдавал.Управление закупками, бюджетирование. Триальные лицензии в конце концов. Сейчас еще и «облачные» продукты позволяют гибко подходить к процессу затрат.
Хм, а откуда возьмется кипа задокументированных обращений в удобном для работы виде? Если никто не озадачился налаживанием процесса работы с инцидентами?Да он через пеньколоду может быть реализован, Вы ж сами приводили пример регистрации через таски в календаре. Отличный пример. Намазывать уже можно, но полноценно жрать не получится.
Коммерческая структура, розничная сеть, ТНП.Ну розница это лучшая школа жизни я считаю. Кто там построил процессы, уже больше проблем с организацией этих процессов иметь не будет. Где бы то нибыло. Гигантская текучка персонала, дедлайны по комплектованию и развертыванию оборудования на точки, каналы связи и телефония, 1000+n мелких, зачастую не прогнозируемых проблем, проблемы там где их быть не должно, потому что операторы не смогли прочитать главный пункт в инструкции написанный жирным красным большим шрифтом.
Я не скучаю по тем временам.
Но зная какие метрики ты хочешь видеть ты уже сможешь более осознанно выбирать систему учета.Это работает не так. Нужно собирать ВСЕ метрики, всю доступную информацию. Рано или поздно она пригодится или понадобится. А Вы уже на шаг впереди и готовы :)
Надеюсь им материал будет полезен.Конечно, я ж добавил в него кучу информации :) но все плюсы все равно Вам.
Рассчитываю, что на этом мы с вам холивары закончим.Да. Полотенца текста, суть теряется.
Почему же выбор и внедрение Service Desk до сих рассматривается для внутреннего ИТ? Видимо, это наследие ITIL. А тем не менее сервисные компании, оказывающие услуги постпродажного обслуживания оборудования или ПО, также заинтересованы в подходящей Service Desk системе
Материал в первую очередь предназначен для сотрудников ИТ служб небольших компаний. Если компания переживает фазу роста, то ИТ отделу приходится приспосабливаться под новые реалии. Больше сотрудников, больше техники, больше всего… когда два посменных ИТ специалиста уже не справляются и начинает расти недовольство пользователей.
Как-то так.
А сервисные компании, как правило, заранее заботятся о пост продажном сопровождении. Т.к. это часть их бизнеса. И услуга сопровождения после продажи — отдельный источник дохода. Причем регулярного дохода.
Вашим конкурентам в комментарии к другой статье я уже подробно объяснил, чем мне не нравятся облачные решения по сервис-деску и почему я считаю область их применения достаточно узкой.
У вас цены, кстати, более приемлемые, чем у того конкурента :). Поэтому для малых организаций можно попробовать.
Как-то так.
А сервисные компании, как правило, заранее заботятся о пост продажном сопровождении. Т.к. это часть их бизнеса. И услуга сопровождения после продажи — отдельный источник дохода. Причем регулярного дохода.
Вашим конкурентам в комментарии к другой статье я уже подробно объяснил, чем мне не нравятся облачные решения по сервис-деску и почему я считаю область их применения достаточно узкой.
У вас цены, кстати, более приемлемые, чем у того конкурента :). Поэтому для малых организаций можно попробовать.
Поэтому для малых организаций можно попробовать.Бюджета на такое в малых организациях никто не даст.
Но я бы посмотрел сравнение функционала Okdesk c Manage Engine ServiceDesk Plus за ноль рублей.
Бюджета на такое в малых организациях никто не даст.
100+ наших клиентов из микробизнеса и SMB опровергают данное утверждение. А за ноль рублей нас сравнивать не нужно. Мы стоим дороже, потому что наша ценность для конечной сервисной компании значительно выше указанного решения ;)
Клиенты платят в случае, когда сервис нужен, а необходимого бесплатного функционала нет, либо его внедрение неадекватно по трудозатратам и поддержке, чем грешат абсолютное большинство (но не все) бесплатные продукты.
Сравнение было бы уместным в контексте того, какие преимущества ваш продукт имеет над бесплатными продуктами, особенно указанным мной выше. Пока что я вижу только одно преимущество — микробизнес и SMB не знают о его существовании.
Сравнение было бы уместным в контексте того, какие преимущества ваш продукт имеет над бесплатными продуктами, особенно указанным мной выше. Пока что я вижу только одно преимущество — микробизнес и SMB не знают о его существовании.
Сергей, так мы не понимаем как нас можно сравнивать? MSP — это про ITIL со всеми вытекающими. Мы совсем не про ITIL. То есть если сравнивать в «лоб», то общее будет в виде «возможность регистрации заявки» и т.д.
Вот тут habrahabr.ru/company/okdesk/blog/343976 мы написали достаточно подробно во второй части статьи про рынок и отличие решений. Если этого недостаточно, будет здорово, если Вы зададите конкретные вопросы, а не попросите абстрактно сравнить 2 принципиально разных решения.
Вот тут habrahabr.ru/company/okdesk/blog/343976 мы написали достаточно подробно во второй части статьи про рынок и отличие решений. Если этого недостаточно, будет здорово, если Вы зададите конкретные вопросы, а не попросите абстрактно сравнить 2 принципиально разных решения.
:anws
За ссылку спасибо, видимо пропустил в своё время.
Про то что вы не знакомы с идеологией ITIL я уже понял. Рассказывать, что натягивать ITIL там где оно натягивается, и делать по своему потому что так удобнее здесь не вижу смысла.
То что вы называете «Help Desk для автоматизации поддержки юр.лиц» и есть ServiceDesk по своей сути, но поскольку маркетинг заточена на продаже новых фич, то вполне старые и очевидные вещи нужно обзывать по новому и продавать. Вы именно так и делаете.
Для всех остальных Help Desk это базовая система по управлению запросами (заявками и инцидентами), Service Desk это Help Desk c CMDB, модулями управления активами, закупками, изменениями, проектами, etc… интеграцией с мониторингом, оркестрацией, конфигурацией и тд. и тп. Все остальные методы деления надуманны.
Поэтому у вас логичнее говорить что вы Service Desk, а их бесплатных не бывает.
зыю
ай. веткой промахнулся, в корень написал
За ссылку спасибо, видимо пропустил в своё время.
Про то что вы не знакомы с идеологией ITIL я уже понял. Рассказывать, что натягивать ITIL там где оно натягивается, и делать по своему потому что так удобнее здесь не вижу смысла.
То что вы называете «Help Desk для автоматизации поддержки юр.лиц» и есть ServiceDesk по своей сути, но поскольку маркетинг заточена на продаже новых фич, то вполне старые и очевидные вещи нужно обзывать по новому и продавать. Вы именно так и делаете.
Для всех остальных Help Desk это базовая система по управлению запросами (заявками и инцидентами), Service Desk это Help Desk c CMDB, модулями управления активами, закупками, изменениями, проектами, etc… интеграцией с мониторингом, оркестрацией, конфигурацией и тд. и тп. Все остальные методы деления надуманны.
Поэтому у вас логичнее говорить что вы Service Desk, а их бесплатных не бывает.
зыю
ай. веткой промахнулся, в корень написал
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Service Desk — быстрый старт. 1 часть. Определение цели внедрения Service Desk