Очень корректное сравнение. Сама по себе методология ITIL не повышает производительность и скорость работы сервисных подразделений. Основной эффект от ITIL — это повышение прозрачности работы сервисных подразделений — сколько люди ждут в очередях, сколько занимает времени обработка запросов и так далее. А вот как эту прозрачность применять на благо — это уже вопрос к руководителю сервисного подразделения: нанимать больше людей (открывая дополнительные окна), упрощать или автоматизировать рабочие процедуры.
К примеру, мы видели в статистике 2015 года, что у нас много времени уходит на обработку запросов связанных с предоставлением прав доступа, поэтому мы напряглись и заскриптовали эту процедуру — теперь предоставление прав доступа — это пара кликов мышкой для применения соответствующего файла с правами доступа.
И как пользователь и как технический специалист могу сказать, что весь этот ITIL и в самом деле придумал, нет — «понавнедрял» на просторах нашей Родины только настоящий передаст. Техподдержки везде сплошь и рядом стали дубовыми. Аналогично и с обратной стороны: безумные и никому ненужные задания.
Ну я лично не имею ничего против электронных очередей во всяких госучреждениях и банках. Кое где внедрение самых основ ITIL серьезно меняет жизнь к лучшему.
Под термином «заявка» я подразумеваю любые обращения пользователя в техподдержку. Дальше они уже делятся в ServiceDesk на три категории — инциденты, запросы на обслуживание и консультации. В таблице 8 содержится статистика обращений по каждой из этих категорий. Каждая из этих категорий имеет свой SLA в ServiceDesk, но я в премии учитываю только общее количество выполненных заявок и сделаны они с нарушением SLA или нет.
А почему тогда этого показателя нет в системе мотивации?
Он есть в системе мотивации — раздел «Отзывы» в таблицах. Если ни по одной из заявок специалиста за месяц не было отзывов, то специалист получает коэффициент 0,6.
Как и времени выполнения заявки.
Время выполнения учитывается в разрезе «выполнено в срок или нет».
А «опросы удовлетворённости клиентов» в малом бизнесе будут работать?
Да, работают и очень даже хорошо. У нас после выполнения заявки пользователю приходит опрос с просьбой оценить качество работы специалиста по заявке (по 4 критериям) и пользователи активно в этих опросах участвуют — каждый месяц мы суммарно получаем порядка 60-80 заполненных анкет по заявкам. То есть примерно каждая четвертая заявка получает оценку от пользователя.
Ну, у всех сотрудников разная мотивация к работе, при этом она еще и меняется со временем — ребенок родился, квартиру ремонтирует, взял ипотеку и так далее.
Никакого противоречия с моей статьей нет. Масштабируемость — это возможность системы справляться с возрастающей нагрузкой исключительно за счет добавления аппаратных ресурсов. В моей статье описаны причины по которым в малом бизнесе масштабировать заложенную изначально инфраструктуру не получается и одна из таких причин (пункт 9 в статье) это как раз использование облачных сервисов.
Кажется, что перенос бизнес-логики, управляющей стриминговым сервисом такого масштаба — это все-таки существенный шаг (не на пару месяцев работы и объемы данных достаточно существенные могут быть):
Как мне кажется, основная причина переноса бизнес-логики в AWS — это сетевая задержка. Т.е. стримить потоковое видео вы можете из единственного дата-центра, но если вы будете авторизовать пользователей по всему миру в единственном дата-центре, то из-за сетевой задержки и особенности работы TCP (установление соединений и так далее) все задачи авторизации/поиска контента и так далее у пользователя будут «тормозить». Уверен, что как только бизнес-логика станет достаточно большой задачей, нетфликс все же соберется и организует свои собственные дата-центры по миру. Во-первых, это будет дешевле, ну а во-вторых, достаточно странно платить деньги за какие-то услуги своему прямому конкуренту (Amazon имеет свой собственный видео-сервис).
Все крупные проекты используют свое железо — облака выходят в 3-4 раза дороже, плюс облака — это инженеры и разработчики, на которых ты никак не можешь повлиять.
Ну и пока искал информацию по стартапам в облаках, нашел статью с кричащим названием: «WHY SOME STARTUPS SAY THE CLOUD IS A WASTE OF MONEY». www.wired.com/2013/08/memsql-and-amazon
Frenkiel estimates that, had the company stuck with Amazon, it would have spent about $900,000 over the next three years. But with physical servers, the cost will be closer to $200,000. «The hardware will pay for itself in about four months,» he says.
Общий вывод — если ваш стартап завтра может загнуться, то покупайте облака. Если планируете работать долго, то только свое железо, только хардкор.
Годом ранее Netflix завершил свою долгую миграцию на виртуальную инфраструктуру Amazon. С 2016 года все важные процессы — от трансляции потокового видео до управления данными о сотрудниках и клиентах — происходят в облаке.
Это ложь. У нетфликса в амазоне был очень маленький кусок сервисов (типа авторизация клиентов) и от них они собирались отказываться из-за того, что расходились с амазоном в каких-то технических аспектах. Все сервера с контентом у них на собственных физических серверах и они много чего разрабатывают для быстрой отдачи с этих серверов. Вот, в частности: medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99
Настолько сложно все описали, что даже сами запутались и ввели людей в заблуждение. Если коротко: инцидент — отклонение от нормального функционирование, проблема — причина повторяющихся инцидентов. Замена пробитого колеса на докатку — это обходное решение инцидента, проблема — это гвозди на дороге из-за которых колеса постоянно пробиваются.
Управление инцидентами — процесс, направленный на оперативное восстановление работы отказавших систем. Управление проектами — процесс, направленный на анализ причин повторяющихся сбоев и устранение этих причин (если это экономически обосновано).
Как по мне, разница между Helpdesk и ServiceDesk небольшая. В реальности и то и другое в компаниях используется практически одинаково. Ну и да, ни один ServiceDesk не умеет обнаруживать повторяющиеся инциденты в автоматическом режиме и создавать проблему — все же это делает руками человек. Остальные выводы относительно различия Helpdesk и ServiceDesk попахивают булшит.
У вас не каталог услуг, а описание зоны ответственности максимум. Как я подхожу к формированию каталога услуг, я описывал в одном из своих первых комментариев на этом ресурсе: habrahabr.ru/company/croc/blog/187124/#comment_6515936
Мы в одной компании никого не предупредив выгрузили в pst порядка 50 почтовых ящиков, размер каждого из которых превысил 20 Гб. Выгрузили и оставили этим пользователям по 5 Гб последней переписки. Далее сделали рассылку вида: «так и так, сердечно извиняемся, но пришлось выгрузить вашу почту в архив. Если вам будут нужны старые письма — обращайтесь». После чего полученные архивы pst разложили по трем разным местам, чтобы случайно не потерять их. Дак вот, за 2 года за старой почтой обращался только один пользователь и в итоге нужное ему письмо было найдено не в архивах, а в его текущем почтовом ящике (sic!).
В комментариях уже было написано, что все важные вещи должны быть или в договорах или в соответствующих учетных системах, а не в почте. Не забывайте еще один важный момент — среднему корпоративному пользователю глубоко плевать на судьбу компании, в которой он работает, и уж тем более, ему плевать на судьбу этой компании после своего увольнения из нее. Поэтому в случае безлимитных почтовых ящиках новому сотруднику достанется от старого сотрудника почтовый ящик с 50 Гб хлама и миллионом писем, в которых найти эту самую важную информацию новому сотруднику будет просто невозможно.
Тем не менее, ограничение объема почтового ящика никак не мешает хранить в нем всю важную переписку хоть за 10 лет — для этого достаточно просто удалять всю ненужную переписку, что пользователи и делают при наличии подобных ограничений. Почтовые ящики большого объема (10-20 Гб) на моей практике нужны только тем сотрудникам, которые ежедневного пересылают десятки писем с фотографиями.
Очень корректное сравнение. Сама по себе методология ITIL не повышает производительность и скорость работы сервисных подразделений. Основной эффект от ITIL — это повышение прозрачности работы сервисных подразделений — сколько люди ждут в очередях, сколько занимает времени обработка запросов и так далее. А вот как эту прозрачность применять на благо — это уже вопрос к руководителю сервисного подразделения: нанимать больше людей (открывая дополнительные окна), упрощать или автоматизировать рабочие процедуры.
К примеру, мы видели в статистике 2015 года, что у нас много времени уходит на обработку запросов связанных с предоставлением прав доступа, поэтому мы напряглись и заскриптовали эту процедуру — теперь предоставление прав доступа — это пара кликов мышкой для применения соответствующего файла с правами доступа.
Ну я лично не имею ничего против электронных очередей во всяких госучреждениях и банках. Кое где внедрение самых основ ITIL серьезно меняет жизнь к лучшему.
Он есть в системе мотивации — раздел «Отзывы» в таблицах. Если ни по одной из заявок специалиста за месяц не было отзывов, то специалист получает коэффициент 0,6.
Время выполнения учитывается в разрезе «выполнено в срок или нет».
Да, работают и очень даже хорошо. У нас после выполнения заявки пользователю приходит опрос с просьбой оценить качество работы специалиста по заявке (по 4 критериям) и пользователи активно в этих опросах участвуют — каждый месяц мы суммарно получаем порядка 60-80 заполненных анкет по заявкам. То есть примерно каждая четвертая заявка получает оценку от пользователя.
Как мне кажется, основная причина переноса бизнес-логики в AWS — это сетевая задержка. Т.е. стримить потоковое видео вы можете из единственного дата-центра, но если вы будете авторизовать пользователей по всему миру в единственном дата-центре, то из-за сетевой задержки и особенности работы TCP (установление соединений и так далее) все задачи авторизации/поиска контента и так далее у пользователя будут «тормозить». Уверен, что как только бизнес-логика станет достаточно большой задачей, нетфликс все же соберется и организует свои собственные дата-центры по миру. Во-первых, это будет дешевле, ну а во-вторых, достаточно странно платить деньги за какие-то услуги своему прямому конкуренту (Amazon имеет свой собственный видео-сервис).
www.datacenterdynamics.com/content-tracks/design-build/microsoft-sells-data-center-to-uber/94260.fullarticle
Ну и пока искал информацию по стартапам в облаках, нашел статью с кричащим названием: «WHY SOME STARTUPS SAY THE CLOUD IS A WASTE OF MONEY».
www.wired.com/2013/08/memsql-and-amazon
Общий вывод — если ваш стартап завтра может загнуться, то покупайте облака. Если планируете работать долго, то только свое железо, только хардкор.
Это ложь. У нетфликса в амазоне был очень маленький кусок сервисов (типа авторизация клиентов) и от них они собирались отказываться из-за того, что расходились с амазоном в каких-то технических аспектах. Все сервера с контентом у них на собственных физических серверах и они много чего разрабатывают для быстрой отдачи с этих серверов. Вот, в частности: medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99
Управление инцидентами — процесс, направленный на оперативное восстановление работы отказавших систем. Управление проектами — процесс, направленный на анализ причин повторяющихся сбоев и устранение этих причин (если это экономически обосновано).
Как по мне, разница между Helpdesk и ServiceDesk небольшая. В реальности и то и другое в компаниях используется практически одинаково. Ну и да, ни один ServiceDesk не умеет обнаруживать повторяющиеся инциденты в автоматическом режиме и создавать проблему — все же это делает руками человек. Остальные выводы относительно различия Helpdesk и ServiceDesk попахивают булшит.
Удаление ненужной переписки — это такая же задача, как и мытье рук перед едой.
Тем не менее, ограничение объема почтового ящика никак не мешает хранить в нем всю важную переписку хоть за 10 лет — для этого достаточно просто удалять всю ненужную переписку, что пользователи и делают при наличии подобных ограничений. Почтовые ящики большого объема (10-20 Гб) на моей практике нужны только тем сотрудникам, которые ежедневного пересылают десятки писем с фотографиями.