Comments 64
Я правильно понимаю, что вы рассказываете, как придумывали ITIL?
что руководить группой у меня скорей всего времени не хватит, хватит только управлять.
и
приходилось именно руководить, а не управлять, и
В чём разница?
Т.е. для начала нужно удалить двух админов и нанять одного толкового, потом: ой, а че это звонки мне, начальнику, поступают. Надо что то делать. Надо затянуть пояса(пояс) админу, чтобы был еще рассторопнее. Делаем баллы и рейтинги. Больше закрытых заявок — больше премия. Больше скрытых бомб, больше зп при их решении.
Вообще я исповедую принцип, что хороший админ вообще работать не должен, это у НЕГО все должно работать. Поэтому — да — дело не в количестве людей, которые могут быстро заменить картридж, а в качестве людей, которые имеют понятие «технического долга», и стараются как меньше делать ворараундов (без которых тоже не всегда обходится).
Вообще я исповедую принцип, что хороший админ вообще работать не должен
ИМХО, Если это выполняется, то это застой, значит нет ни развития бизнеса, ни развития админа.
У нас 4 админа, и ВСЕГДА есть работа, если нет каких то внедрений нового ПО или сервисов, то значит что-то улучшаем (автоматизируем процессы, увеличиваем надежность, улучшаем безопасность и т.д)
Застоя вообще не бывает. Есть движение либо вверх либо вниз. Естественно, если не заниматься постоянным улучшением — то потом будет очень много работы.
Тоесть, Вы считаете, что раз у меня работает несколько десятков сервисов хостинга и я о их работе знаю исключительно по настроенному сколько то летназад мониторингу, чтобы найти себе работу я должен искать новых клиентов хостинга? или может это всё таки задача менеджера и маректолога?
А может я всётаки займусь более полезными и вообще не админскими задачами по программированию, и напишу пару внутренних систем на радость автоматизации?
Насчёт работа есть всегда — а) работает — не трожь. б) миграции, обновления п/о, в) мониторинг атак — которые могут ото дня в день меняться, д) увеличение автоматизации задач через црм… — последние две задачи — программирование и аналитика чистой воды, от админских задач там только логи работающих годами сервисов…
А может я всётаки займусь более полезными и вообще не админскими задачами по программированию, и напишу пару внутренних систем на радость автоматизации?
Насчёт работа есть всегда — а) работает — не трожь. б) миграции, обновления п/о, в) мониторинг атак — которые могут ото дня в день меняться, д) увеличение автоматизации задач через црм… — последние две задачи — программирование и аналитика чистой воды, от админских задач там только логи работающих годами сервисов…
В Макдональдсе всё работает не так, как вы предположили в статье. Монитора с заказами там нет. Есть человек ответственный за кухню, он и следит за наличием готовой продукции. + на основании статистических данных количества посетителей в разное время дня известно сколько готовых бургеров/салатов/ролов и.т.д. нужно держать в запасе т.к. время хранения ограничено. В итоге — это реально конвейер.
По вопросам мотивации:
— 1-2 в месяц менеджер проводит опрос на знание стандартов прямо в процесе работы (влияет на итоговую ставку в зп)
— есть так называемый «тайный покупатель», по результатам его отчёта могут выплатить премию всей смене.
— ну и нерасторопные сотрудники кухни это первые кандидаты на работу в зале — т.е. уборка и т.д. (а это просто очень нудная работа и смена превращается в вечность).
Ну и присутствует достаточно быстрый карьерный рост при хороших результатах работы (хотя «жарить картошку» может и директор при нехватке людей).
По всей служебной части ресторана стоят камеры и по сути все сотрудники под постоянным наблюдением. Не думаю, что это можно назвать полностью автономной системой.
По вопросам мотивации:
— 1-2 в месяц менеджер проводит опрос на знание стандартов прямо в процесе работы (влияет на итоговую ставку в зп)
— есть так называемый «тайный покупатель», по результатам его отчёта могут выплатить премию всей смене.
— ну и нерасторопные сотрудники кухни это первые кандидаты на работу в зале — т.е. уборка и т.д. (а это просто очень нудная работа и смена превращается в вечность).
Ну и присутствует достаточно быстрый карьерный рост при хороших результатах работы (хотя «жарить картошку» может и директор при нехватке людей).
По всей служебной части ресторана стоят камеры и по сути все сотрудники под постоянным наблюдением. Не думаю, что это можно назвать полностью автономной системой.
Хм, правда?
Мне казалось что у них висят там мониторчики с заказами что приготовить. Может это новинка или в другой закусочной?
Мне казалось что у них висят там мониторчики с заказами что приготовить. Может это новинка или в другой закусочной?
Такое есть в DODO PIZZA. Новомодная ИС.
Мониторчики висят у макдрайва. Но это не связано с тем, что нужно приготовить, по крайней мере напрямую.
Все бургеры/наггетсы находятся в так называемом «бине», откуда их и забирают кассиры. А следит за его наполнением и контролирует режим работы кухни «бинщик», он же упаковывает бургеры.
С описанным подходом с мониторами я замечал только пиццерии.
P.S. Работал в 2008 году в макдональдсе в Киеве. За это время принцип их работы не изменился. + мясо на гриле готовится около 35 секунд, + максимум секунд 25 на то, чтобы собрать/упаковать бургер. Готовые хранятся насколько помню не больше 15 минут. На обслуживание клиента по стандарту времени немного, около минуты, что невозможно если сначала взять заказ и только потом начать его готовить.
Все бургеры/наггетсы находятся в так называемом «бине», откуда их и забирают кассиры. А следит за его наполнением и контролирует режим работы кухни «бинщик», он же упаковывает бургеры.
С описанным подходом с мониторами я замечал только пиццерии.
P.S. Работал в 2008 году в макдональдсе в Киеве. За это время принцип их работы не изменился. + мясо на гриле готовится около 35 секунд, + максимум секунд 25 на то, чтобы собрать/упаковать бургер. Готовые хранятся насколько помню не больше 15 минут. На обслуживание клиента по стандарту времени немного, около минуты, что невозможно если сначала взять заказ и только потом начать его готовить.
Такой подход точно есть в KFC.
Примерно такая система есть в нашей сети ресторанов(хотя есть подозрение, и оно оправдано, так у многих) на сервере демон, ловит свои пакеты с POS терминала(официанты делают заказ блюда\блюд), обрабатывает, и бродкастит обратно в сеть, и уже клиенты с мониторчиками (марочники) ловят пакеты, «свои» обрабатывают — выводят на экран, не свои игнорируют. Соответственно в BOH настроено время приготовления блюд.Есть учет просрочек, времени приготовления(?speed of service?) как инструмент контроля кухни. много много всего в этой системе, и совсем не хотелось бы систему «кнутИпряник» на её основе, но это взгляд снизу.
Вопрос такой, заявки по «весу» были одинаковые? Т.е. за разный тип заявок, давалось одинаковое количество «баллов», не было ли проблем с тем что админы перехватывали друг и друга мало затратные заявки, по времени, и тем самым образовывался дисбаланс?
Первое что нужно делать вступая в роль начальника отдела ИТ — внедрять сервисдеск, если его нет. Только он покажет и продемонстрирует, чем занимаются сотрудники, в том числе и все. Внедрять лучше с приказами по организации. За приказом сразу следует игнорирование задач пришедших вне сервисдеска, исключения только от первых руководителей и при недоступности почты и портала одновременно.
У Вас первая ошибка в том, что вы свой документооборот пытаетесь затолкать контроль заявок, для этого лучше взять что нить готовое из коробки вроде ManageEngine ServiceDesk. И не нужно потом будет прикручивать какие то отчеты, рабочие процессы, интеграции с внешними системами.
Вторая ошибка, говорить «Ну ладно, нужно что то придумать еще» на "Заявки просто начинали копиться в разделе, админы то «не увидели почтовое сообщение», то «мы не заходим в систему документооборота»", хотя оно может вытекать из первого пункта. Иногда, чужими самописными продуктами пользоваться просто жесть. Лишние клики, поля, согласования, требования. Т.е. ты вместо почти автоматической фиксации работ занимаешься электронным бумагомараньем делая кучу ненужных движений, каких то согласований, подтверждений.
В любом случае инструмент есть, и в нем должны работать. Не запущенный сервисдеск или почта это йенг забитый на работу. Это равнозначно отключенному телефону. И отсутствию сотрудника на рабочем месте.
А что до KPI, то нужно всего лишь указать категории задач, задать по ним SLA, и перед каждой квартальной премией проходиться по всем заявкам где нарушен SLA для конструктивного анализа, после чего определять размер премирования или депремирования. Естественно после периода тестирования и подтверждения того, что сотрудники понимают как это происходит, да и что система вообще прозрачна для всех.
У Вас первая ошибка в том, что вы свой документооборот пытаетесь затолкать контроль заявок, для этого лучше взять что нить готовое из коробки вроде ManageEngine ServiceDesk. И не нужно потом будет прикручивать какие то отчеты, рабочие процессы, интеграции с внешними системами.
Вторая ошибка, говорить «Ну ладно, нужно что то придумать еще» на "Заявки просто начинали копиться в разделе, админы то «не увидели почтовое сообщение», то «мы не заходим в систему документооборота»", хотя оно может вытекать из первого пункта. Иногда, чужими самописными продуктами пользоваться просто жесть. Лишние клики, поля, согласования, требования. Т.е. ты вместо почти автоматической фиксации работ занимаешься электронным бумагомараньем делая кучу ненужных движений, каких то согласований, подтверждений.
В любом случае инструмент есть, и в нем должны работать. Не запущенный сервисдеск или почта это йенг забитый на работу. Это равнозначно отключенному телефону. И отсутствию сотрудника на рабочем месте.
А что до KPI, то нужно всего лишь указать категории задач, задать по ним SLA, и перед каждой квартальной премией проходиться по всем заявкам где нарушен SLA для конструктивного анализа, после чего определять размер премирования или депремирования. Естественно после периода тестирования и подтверждения того, что сотрудники понимают как это происходит, да и что система вообще прозрачна для всех.
Да в общем я и постарался запустить сервис деск сразу, только без использования коробочных решений. Никто в компании (в том числе руководство) не стал бы делать это в отдельной системе. Сложности возникают даже несмотря на то, что реализовано в знакомой им системе, даже с учетом того что горячая кнопка заявки находится на главной странице, и что заполнить надо три поля — тип (выбор из справочника), желаемая дата исполнения (выбор из дата-пикера) и описание проблемы (тут уж руками). Никаким новым продуктом никто пользоваться вовсе не будет включая высшее руководство. Да и вторая ошибка — не вытекает из первой. Можно было сделать что угодно — это же наша система. Вопрос в том что некоторым не хочется ничего ни при каких условиях.
А про SLA — это ценный совет! Наверное что-то попытаюсь сделать в этом роде…
А про SLA — это ценный совет! Наверное что-то попытаюсь сделать в этом роде…
Не заставляйте людей работать исключительно на портале. У нас порядка 99% заявок приходит исключительно по почте. Она проще и понятнее для всех. Отправил письмо с описанием и скриншотом на help@, сразу же получил номер тикета от автоответчика. Потом, после выполнения, приходит письмо о том, что заявка закрыта и комментарий от специалиста приложен. Люди вообще на портал не ходят почти. От них требуется проблему обозначить, от нас не потерять ее и решить.
Те кто вкусил прелести портала создают через него, там и SLA можно выставить более оперативный, и вплоть до конечно специалиста заявку назначить. Да и предопределенные шаблоны как бы ускоряют процесс.
Те кто вкусил прелести портала создают через него, там и SLA можно выставить более оперативный, и вплоть до конечно специалиста заявку назначить. Да и предопределенные шаблоны как бы ускоряют процесс.
В защиту автора. Хорошо рассуждать, в отрыве от реальных условий. Все, в той или иной мере, знают ITIL, но его последняя буква — это Library, вы в этой библиотеке берёте некоторую книжку процессов, в которой всё хорошо и логично описано, но выясняется, что эта книжка в применении к вашей реальности не содержит конкретных рецептов типа «На 30 заявок в сутки возьмите двух сисадминов, хорошенько перемешайте, сверху посыпьте измельченным сетевым инженером и отправьте в печь на полчаса». Поэтому всё идёт методом проб и ошибок. Замечательно, если есть система мониторинга, которая умеет заводить тикеты и отправлять их в сервисдеск. Замечательно если сервисдеск не стоит ни копейки, при этом умеет сам разбираться с приоритетами и направлять заявки на инженеров, и если при этом он еще умеет отслеживать геолокацию и распределять заявки так чтобы инженер с объекта на объект перемещался по оптимальному маршруту. Но, обычно, этого нет, либо есть, но стоит небюджетных денег.
Автор сделал решение, которое позволило ему заставить инженеров работать. А это уже решение проблемы. Соответствует оно при этом вашим ожиданиям, не соответствует — дело десятое. «В каждой избушке свои погремушки». Опишите вашу систему, инструментарий, организацию процесса. Почитаем, зададим вопросы.
Автор сделал решение, которое позволило ему заставить инженеров работать. А это уже решение проблемы. Соответствует оно при этом вашим ожиданиям, не соответствует — дело десятое. «В каждой избушке свои погремушки». Опишите вашу систему, инструментарий, организацию процесса. Почитаем, зададим вопросы.
Первая ошибка внедрятелей ITILа — это загонять процессы организации под методику. Суть ITILа натягивать его там, где оно натягивается. И ждать когда до остальных процессов бизнес и люди дорастут. Помочь и организовать, а не выстроить жесткий коридор.
Вы от сервисдеска уходите в IT Service Intelligence. Возвращайтесь с небес на землю :)
Автор, на мой взгляд, до сих пор слишком мягок в вопросе управления. Я не говорю, что нужно сразу и всех депремировать, но регулярная отмазка у админа про незапущенную почту и сервисдеск не нашла бы у меня понимания. Люди с такими отмазками у нас в зарплате и по карьерной лестнице не растут и обычно перемещаются на удаленную площадку в качестве эникейщика.
Вы от сервисдеска уходите в IT Service Intelligence. Возвращайтесь с небес на землю :)
Автор, на мой взгляд, до сих пор слишком мягок в вопросе управления. Я не говорю, что нужно сразу и всех депремировать, но регулярная отмазка у админа про незапущенную почту и сервисдеск не нашла бы у меня понимания. Люди с такими отмазками у нас в зарплате и по карьерной лестнице не растут и обычно перемещаются на удаленную площадку в качестве эникейщика.
Вы мне написали тоже самое, что я вам написал, но другими словами.
мягок в вопросе управления
Руководитель с опытом как раз должен хорошо понимать, где надо давить, а где давить не стоит. Он должен хорошо понимать, где нормальному выполнению задачи мешает раздолбайство, а где отсутствие ресурса — нехватка людей, времени, знаний, инструмента. Проще всего спрятаться за формальную сторону: «Не сделал? Депремирован, уволен». Шашкой махать — это самое лёгкое. Найти корневую причину и устранить ее, либо минимизировать последствия — это задача поинтереснее будет.
Хотя организацию работ никто не отменял. Во время работы в «Альфа-банке» в приснопамятные 90-е, по банку был приказ, что сотрудник обязан читать почту в 9.00, 14.00, 17.00, распоряжения поступающие по корпоративной почте приравниваются к письменным. Ссылки, про «я был на выезде»,«на встрече с клиентами» не принимались.
мягок в вопросе управления
Руководитель с опытом как раз должен хорошо понимать, где надо давить, а где давить не стоит. Он должен хорошо понимать, где нормальному выполнению задачи мешает раздолбайство, а где отсутствие ресурса — нехватка людей, времени, знаний, инструмента. Проще всего спрятаться за формальную сторону: «Не сделал? Депремирован, уволен». Шашкой махать — это самое лёгкое. Найти корневую причину и устранить ее, либо минимизировать последствия — это задача поинтереснее будет.
Хотя организацию работ никто не отменял. Во время работы в «Альфа-банке» в приснопамятные 90-е, по банку был приказ, что сотрудник обязан читать почту в 9.00, 14.00, 17.00, распоряжения поступающие по корпоративной почте приравниваются к письменным. Ссылки, про «я был на выезде»,«на встрече с клиентами» не принимались.
Полностью согласен с Вами!
Но попробую очень кратко описать как было у нас на работе. Изначально так — звонки пользователя, ближайшие территориально сотрудники разбираются, что нужно сделать, делают, или созваниваются-переписываются с другими отделами, внешними разработчиками и т.п. В принципе, всё работало, и достаточно оперативно. За качество не приходилось беспокоиться, т.к. каждый знал, что делать надо всё на совесть, иначе потом тебя же вызовут в 3 часа ночи доделывать-переделывать, а потом ещё премию срежут.
Потом внедрили систему на базе HP Service Desk, а потом перешли на HP Service Manager, с огромными доработками (по ходу эксплуатации). Внедрено всё: ITIL, SLA, KPI… Пользователей обязали звонить только на единый телефон службы поддержки, которая уже раздавала обращения в SM, начальники отделов раскидывали по исполнителям (или исполнитель сам мог забрать, если видел, что это в его компетенции). От звонков напрямую на 90% избавились лишь лет через 6-7, но и после всё ещё звонят напрямую, особенно оперативные рабочие места.
Методы контроля постоянно менялись — начиная от контроля времени взятия обращения в работу, и заканчивая внедрением крайнего срока, планового срока, и последующей «закруткой гаек». Дальше внедрение процессного подхода (в большинстве случаев в нашем деле бесполезное занятие, это не конвейер), распределение сроков по разным видам работ, ну и наказания за просрочки, и другие.
Дальше — больше, и в текущем состоянии эта система представляет собой неповоротливого монстра, с множеством связей с системами мониторинга (которые тоже автоматически могут генерировать заявки на устранение каких-то неисправностей), и с системами учёта кадров (SAP), по ней же отслеживается загруженность работников, в том числе в разрезе по разным видам работ, и строится прочая разнообразная статистика. Так вот, бывает ложь, бывает наглая ложь, а бывает статистика. А ещё бывает статистика, выведенная из этой системы.
В итоге
Но попробую очень кратко описать как было у нас на работе. Изначально так — звонки пользователя, ближайшие территориально сотрудники разбираются, что нужно сделать, делают, или созваниваются-переписываются с другими отделами, внешними разработчиками и т.п. В принципе, всё работало, и достаточно оперативно. За качество не приходилось беспокоиться, т.к. каждый знал, что делать надо всё на совесть, иначе потом тебя же вызовут в 3 часа ночи доделывать-переделывать, а потом ещё премию срежут.
Потом внедрили систему на базе HP Service Desk, а потом перешли на HP Service Manager, с огромными доработками (по ходу эксплуатации). Внедрено всё: ITIL, SLA, KPI… Пользователей обязали звонить только на единый телефон службы поддержки, которая уже раздавала обращения в SM, начальники отделов раскидывали по исполнителям (или исполнитель сам мог забрать, если видел, что это в его компетенции). От звонков напрямую на 90% избавились лишь лет через 6-7, но и после всё ещё звонят напрямую, особенно оперативные рабочие места.
Методы контроля постоянно менялись — начиная от контроля времени взятия обращения в работу, и заканчивая внедрением крайнего срока, планового срока, и последующей «закруткой гаек». Дальше внедрение процессного подхода (в большинстве случаев в нашем деле бесполезное занятие, это не конвейер), распределение сроков по разным видам работ, ну и наказания за просрочки, и другие.
Дальше — больше, и в текущем состоянии эта система представляет собой неповоротливого монстра, с множеством связей с системами мониторинга (которые тоже автоматически могут генерировать заявки на устранение каких-то неисправностей), и с системами учёта кадров (SAP), по ней же отслеживается загруженность работников, в том числе в разрезе по разным видам работ, и строится прочая разнообразная статистика. Так вот, бывает ложь, бывает наглая ложь, а бывает статистика. А ещё бывает статистика, выведенная из этой системы.
В итоге
Лишние клики, поля, согласования, требования. Т.е. ты вместо почти автоматической фиксации работ занимаешься электронным бумагомараньем делая кучу ненужных движений, каких то согласований, подтверждений.
Методы контроля постоянно менялись — начиная от контроля времени взятия обращения в работу, и заканчивая внедрением крайнего срока, планового срока, и последующей «закруткой гаек».
Метрики и должны периодически меняться/пересматриваться, так как:
1. Метрики должны быть нацелены на то что важно для компани в данный момент. Скорость назначения на админа — меряем скорость назначения, скорость закрытия заявки — меряем скорость, количество заявок — меряем количество и т.д.
2. Скажи как оценивается/изменяется моя работа, я сделаю все чтобы эта метрика было всегда отличная, наплевав на реальное качество. Всегда сотрудники будут подгонять процессы под метрики.
наказания за просрочки
Может лучше сделать премирование за хорошее качество, скорость и т.д.?
Пользователей обязали звонить только на единый телефон службы поддержки
и это правильно. Менее хорошее решение — писать в СервисДеск на почту (тотже ServiceDeskPlus умеет это из коробки).
ох, опять полотенце получилось:
| Потом внедрили систему на базе HP Service Desk, а потом перешли на HP Service Manager
Уже сочувствую.
| с огромными доработками (по ходу эксплуатации).
Ужасный неповоротливый монстр. Консольный интерфейс создан что бы специалисты страдали. Для постоянного допиливания нужен отдельно обученный человек. Для обучения использования спецов и пользователей — без курсов никак.
Евангелисты hpe прям светятся, когда рассказывают. Особенно их торкает от красиво вращающихся менюшек. На вопросы почему окно в котором идет основное описание заявки размером с два спичечных коробка, а скриншот вставленный в письмо появляется на отдельной вкладке и его можно посмотреть только в виде прикрепленного файла через какой нить вьювер — ответить не могут. Почти все скопировано с MS Service Manager (или наоборот, я не знаю). В обоих в системе заявку закрываешь дольше чем в занимаешься работами по заявке.
Он весь пропитан болью и кроме как откат принимающему решения лицу я не вижу не одной причины его внедрения. Ну может еще понты.
У нас основные каналы вхождения проблем это почти всегда электронная почта, редко портал и почти никогда звонки. Диспетчера нет, 80%+ заявок разруливают бизнес-правила, остальное начальники групп. Мы аутсорсеры, поставщики оборудования и ПО, разработчики, у нас есть свой ЦОД. Много предприятий и организаций на поддержке. Где то мы полностью рулим ИТ включая бюджетирование и развитие, где то на предприятих есть только начальник ИТ, все остальное наше, где то наши только сисадмины, где то только скуд, монтаж и сервис от нас.
В сервисдеске дикий микс из групп по организациям и направлениям деятельности. Точка входа одна. Портал для всех единый, но естественно каждый начальник и специалист видит только заявки по области относящиеся к нему. База знаний общая. Отделы ИТ некоторых предприятий сами полностью сидят в нашем сервисдеске, им их пользователи шлют задачи.
MS Service Manager пытались внедрить для внутренних процессов — не взлетел, у пользователей и ИТ спецов вызывал изжогу. Партнерка позволяет использовать, а не получилось.
HP Service Manager и LanDesk делали презентации и демо, предлагали тестовую интеграцию, но после описания структуры работы и движения заявок дело затухало. Брали паузу так сказать. Да и дорого.
Жира больше по проектным вещам, OTRS нужно допиливать слишком сильно, 1С Итилиум — привязка к 1С, а она не у всех есть. В итоге сидим на том, что я написал выше. Очень быстрое, достаточно гибкое. Не заставляет тебя поднимать кучу серверов и сервисов что бы тупо первую заявку зарегистрировать. 30 минут вместе с авторизацией по LDAP на взлет, ставь хоть на свой ПК. Официально до 100 одновременно работающих спецов бесплатно (но есть хинт — можно написать менеджерам и получить столько сколько нужно, правда рекламой завалят, представительства в России нет :) ), ограничения на количество учеток клиентов нет как и ограничения на задач в день/месяц. Проблем с обучением новых специалистов нет, две тестовых заявки и спец уже готов в нем орудовать тут же. Шаблоны отчетов из коробки, график, диаграмы, автоматическая рассылка. Есть модули по управлению закупками, активами, изменениями и портал самообслуживания за отдельное бабло. Там у разработчиков прям комплекс типа ситемцентра мелкомягкого, но сильно дружелюбнее к ИТшникам и ресурсам ваших серверов.
Про ITIL, SLA, KPI тоже скажу — всем нас#много#, особенно заказчикам. Всех интересует конечный результат без касяков и вовремя. Про показатели вспоминают только, если что то пошло не так, но при наличии протоколирования выполнения работ, почти всегда выясняется, что заказчик сам где то прокасячил.
Средняя нагрузка ~1200-1500 запросов и инцидентов в месяц, при том, что комплекс мониторинга в общем то в сервисдеск автоматом ничего не шлет.
| Потом внедрили систему на базе HP Service Desk, а потом перешли на HP Service Manager
Уже сочувствую.
| с огромными доработками (по ходу эксплуатации).
Ужасный неповоротливый монстр. Консольный интерфейс создан что бы специалисты страдали. Для постоянного допиливания нужен отдельно обученный человек. Для обучения использования спецов и пользователей — без курсов никак.
Евангелисты hpe прям светятся, когда рассказывают. Особенно их торкает от красиво вращающихся менюшек. На вопросы почему окно в котором идет основное описание заявки размером с два спичечных коробка, а скриншот вставленный в письмо появляется на отдельной вкладке и его можно посмотреть только в виде прикрепленного файла через какой нить вьювер — ответить не могут. Почти все скопировано с MS Service Manager (или наоборот, я не знаю). В обоих в системе заявку закрываешь дольше чем в занимаешься работами по заявке.
Он весь пропитан болью и кроме как откат принимающему решения лицу я не вижу не одной причины его внедрения. Ну может еще понты.
У нас основные каналы вхождения проблем это почти всегда электронная почта, редко портал и почти никогда звонки. Диспетчера нет, 80%+ заявок разруливают бизнес-правила, остальное начальники групп. Мы аутсорсеры, поставщики оборудования и ПО, разработчики, у нас есть свой ЦОД. Много предприятий и организаций на поддержке. Где то мы полностью рулим ИТ включая бюджетирование и развитие, где то на предприятих есть только начальник ИТ, все остальное наше, где то наши только сисадмины, где то только скуд, монтаж и сервис от нас.
В сервисдеске дикий микс из групп по организациям и направлениям деятельности. Точка входа одна. Портал для всех единый, но естественно каждый начальник и специалист видит только заявки по области относящиеся к нему. База знаний общая. Отделы ИТ некоторых предприятий сами полностью сидят в нашем сервисдеске, им их пользователи шлют задачи.
MS Service Manager пытались внедрить для внутренних процессов — не взлетел, у пользователей и ИТ спецов вызывал изжогу. Партнерка позволяет использовать, а не получилось.
HP Service Manager и LanDesk делали презентации и демо, предлагали тестовую интеграцию, но после описания структуры работы и движения заявок дело затухало. Брали паузу так сказать. Да и дорого.
Жира больше по проектным вещам, OTRS нужно допиливать слишком сильно, 1С Итилиум — привязка к 1С, а она не у всех есть. В итоге сидим на том, что я написал выше. Очень быстрое, достаточно гибкое. Не заставляет тебя поднимать кучу серверов и сервисов что бы тупо первую заявку зарегистрировать. 30 минут вместе с авторизацией по LDAP на взлет, ставь хоть на свой ПК. Официально до 100 одновременно работающих спецов бесплатно (но есть хинт — можно написать менеджерам и получить столько сколько нужно, правда рекламой завалят, представительства в России нет :) ), ограничения на количество учеток клиентов нет как и ограничения на задач в день/месяц. Проблем с обучением новых специалистов нет, две тестовых заявки и спец уже готов в нем орудовать тут же. Шаблоны отчетов из коробки, график, диаграмы, автоматическая рассылка. Есть модули по управлению закупками, активами, изменениями и портал самообслуживания за отдельное бабло. Там у разработчиков прям комплекс типа ситемцентра мелкомягкого, но сильно дружелюбнее к ИТшникам и ресурсам ваших серверов.
Про ITIL, SLA, KPI тоже скажу — всем нас#много#, особенно заказчикам. Всех интересует конечный результат без касяков и вовремя. Про показатели вспоминают только, если что то пошло не так, но при наличии протоколирования выполнения работ, почти всегда выясняется, что заказчик сам где то прокасячил.
Средняя нагрузка ~1200-1500 запросов и инцидентов в месяц, при том, что комплекс мониторинга в общем то в сервисдеск автоматом ничего не шлет.
Вы ещё про бюджет внедрения и стоимость лицензий на HP SM озвучьте и небольшие конторы тут же Кондратий обнимет. Такой SM никому не нужен.
В итоге сидим на том, что я написал выше.— это ManageEngine ServiceDesk?
А мне интересно, почему в данной статье эникейщиков обозвали админами? И если они и правда админы, то почему они занимаются тасканием компов, закупкой картриджей и вообще беготней по пользователям?
Для небольших компаний эникейщик, не только сисадмин, но еще и сетевой инженер и «1С-прогроммист», а иногда и метролог и инженер по АСУТП. И начальник отдела, как правило — не освобождённый.
Управленец работает в системе, контролирует сотрудников и следует правилам, а руководитель работает над самой системой, мотивирует сотрудников и изменяет правила.
Как пользователь схожего сервис-деска, опишу минусы.
1. Все, что можно будет сделать более легким путем, будет сделано более легким путем.
2. Зарплата в зависимости от количества/качества заявок — ведет к конкуренции между работниками за количество «баллов» но не за качество работы. Стараются перехватить самые легкие заявки от самых неконфликтных и сговорчивых клиентов. Конкуренция между работниками не всегда честная.
3. Зарплата в зависимости от просроченных заявок — ведет к тому что заявки принимают в коридоре и выполняют по мере возможности, а потом оформляют официально, «задним числом». Чтобы на бумажке все было красиво и начальник был доволен.
Сюда же можно добавить работу «тяп-ляп» — если горят сроки, никто не будет делать «чтобы было хорошо», сделают абы как, даже зная что косячные последствия всплывут через полгода (все равно исправлять будет другой).
4. Появляется имитация бурной деятельности — мелкие работы, которые раньше делались мимоходом за 5 минут, теперь оформляются в официально-бумажном виде аля «пропала кнопка в ворде — оформляем заявку на лечение вирусов, работаем, работаем...»
5. Ухудшение взаимоотношений с клиентами. Представьте, что позвонили в Сбербанк уточнить списания с карты за полдня, а вам говорят «я без заявки не могу — заходите на сайт, оформляйте заявку...».
6. Саботажные заявки =) У кого есть доступ, могут без проблем организовать нужному пользователю пропадание кнопки в ворде — и халявная заявка готова, а настоящую причину обнаружить будет крайне сложно…
1. Все, что можно будет сделать более легким путем, будет сделано более легким путем.
2. Зарплата в зависимости от количества/качества заявок — ведет к конкуренции между работниками за количество «баллов» но не за качество работы. Стараются перехватить самые легкие заявки от самых неконфликтных и сговорчивых клиентов. Конкуренция между работниками не всегда честная.
3. Зарплата в зависимости от просроченных заявок — ведет к тому что заявки принимают в коридоре и выполняют по мере возможности, а потом оформляют официально, «задним числом». Чтобы на бумажке все было красиво и начальник был доволен.
Сюда же можно добавить работу «тяп-ляп» — если горят сроки, никто не будет делать «чтобы было хорошо», сделают абы как, даже зная что косячные последствия всплывут через полгода (все равно исправлять будет другой).
4. Появляется имитация бурной деятельности — мелкие работы, которые раньше делались мимоходом за 5 минут, теперь оформляются в официально-бумажном виде аля «пропала кнопка в ворде — оформляем заявку на лечение вирусов, работаем, работаем...»
5. Ухудшение взаимоотношений с клиентами. Представьте, что позвонили в Сбербанк уточнить списания с карты за полдня, а вам говорят «я без заявки не могу — заходите на сайт, оформляйте заявку...».
6. Саботажные заявки =) У кого есть доступ, могут без проблем организовать нужному пользователю пропадание кнопки в ворде — и халявная заявка готова, а настоящую причину обнаружить будет крайне сложно…
Гибкой отчетности не хватает.
И тут соглашусь, но есть кое-где решения:
1. Это на самом деле плюс. Если задача будет выполнена надлежащим образом, почему бы не сделать её более простым путём? Или время исполнителя ничего не стоит, и его можно нагрузить делать то, что не нужно?
2. Здесь нужно ИТ-специалистов разбивать на функциональные группы/отделы, и заявки чтобы маршрутизировались в нужный отдел, где сделать автораспределение — чтобы ни один специалист не простаивал, и была более-менее равномерная загрузка. Конечно, если начальник отдела решит, что ту или иную задачу может сделать конкретный специалист — ему и переназначит явно.
3. Если по п.2 у специалиста просто не будет времени принимать какие-то другие заявки, то и не будет «заявок в коридоре». А если и будут, и пользователь согласен подождать — никто не будет в минусе. Работа была нужна? Работа выполнена? пользователь доволен? — да хоть сам оформляй. Главное чтобы была обратная связь (например, в почту пользователю приходил запрос на закрытие обращения, и возможно с указанием оценки).
Тут нужно организовать так, чтобы каждое обращение было привязано к определённому месту, и можно было бы потом отследить, кто и что делал на этом рабочем месте (или к пользователю привязать, вариантов много разных). Тогда каждый будет знать, что история сохраняется, и при наличии косяков могут докопаться. Даже если не докажут, но частые проблемы с рабочим местом после работы определённого специалиста уже может навести на мысль и присмотреться к работе этого человека.
4. Такое проявляется только когда ИТ-специалист не загружен другими работами, и нет плановых сроков по определённым типам работ (хотя это мне и самому не нравится, но в какой-то мере должно присутствовать).
5. Если зайти на сайт и сделать заявку быстрее и удобнее чем звонить — люди сами будут так делать. А если там надо заполнять кучу непонятных полей и ещё и баги присутствуют — то вот и будет ухудшение взаимоотношений, или пойдут звонки напрямую специалистам (если знают телефоны).
6. Классифицировать заявки по «запрос», и «инцидент». Если что-то не работает, или плохо работает — классифицировать как инцидент, а инциденты впоследствии анализировать и вводить меры для снижения их количества. Конечно и тут останется поле для деятельности — сговор с пользователем («скажи, что надо хром поставить, а я попозже подойду и твой синий экран исправлю»), или корректировка/скрытие инцидентов, чтобы выглядело всё красиво.
Не претендую на полноту решения, но часть из этого каждый может использовать. Конечно, тут можно очень много рассуждать, и в каждом случае будут свои особенности.
1. Это на самом деле плюс. Если задача будет выполнена надлежащим образом, почему бы не сделать её более простым путём? Или время исполнителя ничего не стоит, и его можно нагрузить делать то, что не нужно?
2. Здесь нужно ИТ-специалистов разбивать на функциональные группы/отделы, и заявки чтобы маршрутизировались в нужный отдел, где сделать автораспределение — чтобы ни один специалист не простаивал, и была более-менее равномерная загрузка. Конечно, если начальник отдела решит, что ту или иную задачу может сделать конкретный специалист — ему и переназначит явно.
3. Если по п.2 у специалиста просто не будет времени принимать какие-то другие заявки, то и не будет «заявок в коридоре». А если и будут, и пользователь согласен подождать — никто не будет в минусе. Работа была нужна? Работа выполнена? пользователь доволен? — да хоть сам оформляй. Главное чтобы была обратная связь (например, в почту пользователю приходил запрос на закрытие обращения, и возможно с указанием оценки).
Сюда же можно добавить работу «тяп-ляп» — если горят сроки, никто не будет делать «чтобы было хорошо», сделают абы как, даже зная что косячные последствия всплывут через полгода (все равно исправлять будет другой).
Тут нужно организовать так, чтобы каждое обращение было привязано к определённому месту, и можно было бы потом отследить, кто и что делал на этом рабочем месте (или к пользователю привязать, вариантов много разных). Тогда каждый будет знать, что история сохраняется, и при наличии косяков могут докопаться. Даже если не докажут, но частые проблемы с рабочим местом после работы определённого специалиста уже может навести на мысль и присмотреться к работе этого человека.
4. Такое проявляется только когда ИТ-специалист не загружен другими работами, и нет плановых сроков по определённым типам работ (хотя это мне и самому не нравится, но в какой-то мере должно присутствовать).
5. Если зайти на сайт и сделать заявку быстрее и удобнее чем звонить — люди сами будут так делать. А если там надо заполнять кучу непонятных полей и ещё и баги присутствуют — то вот и будет ухудшение взаимоотношений, или пойдут звонки напрямую специалистам (если знают телефоны).
6. Классифицировать заявки по «запрос», и «инцидент». Если что-то не работает, или плохо работает — классифицировать как инцидент, а инциденты впоследствии анализировать и вводить меры для снижения их количества. Конечно и тут останется поле для деятельности — сговор с пользователем («скажи, что надо хром поставить, а я попозже подойду и твой синий экран исправлю»), или корректировка/скрытие инцидентов, чтобы выглядело всё красиво.
Не претендую на полноту решения, но часть из этого каждый может использовать. Конечно, тут можно очень много рассуждать, и в каждом случае будут свои особенности.
Прости Автор, но вы создавали велосипед, вместо того чтобы прочесть хотя бы одну книжку по тому что уже 100 лет назад было придумано…
Не в обиду автору, но это яркий пример, когда человек не на своём месте. Компания, чтобы с экономить, поручает руководить отделом некомпетентному в этой сфере человеку, которому эта сфера не интересна или не близка, или у него есть основная работа (как в данном примере) и ему повесили неинтересные ему обязанности за ту же зп или очень маленькую надбавку. Чтобы его не трогали, он пытается отмахнуться и автоматизировать процесс.
И вот тут начинает вылезать некомпетентность и полный аншлаг. Вместо нормального хэлпдеска, для управления IT отделом, автор за основу берёт электронную систему управления кухней общепита. WTF!!!?? За основу управления IT отделом взят процесс управления кухней Мака! Причём только видимая для покупателя часть! Почему общепит? почему именно Мак? Чем хуже Бургеркинг или KFC? Почему не Uber, Яндекс такси, или DHL? Реализуется эта система старым ноутбуком и монитором, который весит «на видном всем месте».
Чем занимается ваша компания? Это стоматологическая клиника, которая делает кузовной ремонт?
Чтобы была эффективность, для начала каждый должен быть на своём месте! И каждому должна быть интересна его работа! И вам, и админам! И мотивация должна быть денежная, а не галочками, плюсиками, оценками, бабочками и баллами, которые в лучшем случае раз в квартал превратятся в копейки. И для управления IT отделом, нельзя ставить директора школы, который для своего удобства за основу управления введёт электронные дневники. Или прораба у которого система автоматизации — это крепкое словцо, арматура и стенгазета. Или как в вашем случае вообще Мак.
По вашему описанию, я понял, что у вас навыков управления нет вообще. А вам поручили IT отдел. И насколько я понял, с такой же лёгкостью поручили бы отдел продаж или бухгалтерию или вести склад.
Вы пытаетесь что-то изобрести, чтобы не дергали вас. Админы всеми способами филонят и делают всё чтобы не дергали их. И в качестве оружия между вами — это интерфейс заказов Макдака. Если вашу историю перевести в кинематограф, получится такой же треш, как это: https://www.youtube.com/watch?v=JS2UaC9G910
ИМХО. Без обид!
И вот тут начинает вылезать некомпетентность и полный аншлаг. Вместо нормального хэлпдеска, для управления IT отделом, автор за основу берёт электронную систему управления кухней общепита. WTF!!!?? За основу управления IT отделом взят процесс управления кухней Мака! Причём только видимая для покупателя часть! Почему общепит? почему именно Мак? Чем хуже Бургеркинг или KFC? Почему не Uber, Яндекс такси, или DHL? Реализуется эта система старым ноутбуком и монитором, который весит «на видном всем месте».
Чем занимается ваша компания? Это стоматологическая клиника, которая делает кузовной ремонт?
Чтобы была эффективность, для начала каждый должен быть на своём месте! И каждому должна быть интересна его работа! И вам, и админам! И мотивация должна быть денежная, а не галочками, плюсиками, оценками, бабочками и баллами, которые в лучшем случае раз в квартал превратятся в копейки. И для управления IT отделом, нельзя ставить директора школы, который для своего удобства за основу управления введёт электронные дневники. Или прораба у которого система автоматизации — это крепкое словцо, арматура и стенгазета. Или как в вашем случае вообще Мак.
По вашему описанию, я понял, что у вас навыков управления нет вообще. А вам поручили IT отдел. И насколько я понял, с такой же лёгкостью поручили бы отдел продаж или бухгалтерию или вести склад.
Вы пытаетесь что-то изобрести, чтобы не дергали вас. Админы всеми способами филонят и делают всё чтобы не дергали их. И в качестве оружия между вами — это интерфейс заказов Макдака. Если вашу историю перевести в кинематограф, получится такой же треш, как это: https://www.youtube.com/watch?v=JS2UaC9G910
ИМХО. Без обид!
Вашими устами да мед бы пить. Естественно везде и всегда люди должны заниматься своим делом, однако же такое случается в подавляющем меньшинстве случаев.
По поводу навыков управления — да совсем нет, учитывая, трудовую деятельность с 2009 года на должностях: начальник производства, заместитель руководителя, начальник группы разработки и наконец начальник ИТ отдела, и участие в президентской программе подготовки управленческих кадров.
Просто я предпочитаю подходить к делу творчески, пусть и изобретая велосипед. Вы думаете возможно развернуть полноценную ИТ службу в той компании где я сейчас тружусь по всем стандартами ИТИЛа, включая управление конфигурациями, оборудованием, инцидентами, услугами, безопасностью? Нет, уверяю, не возможно.
Наверное вы работали в компании где ИТ отдел в 50 человек, и управлять им было возможно по всем стандартам. Мне же увы приходится делать малину из того что есть. Да и этого не достаточно… :-/
По поводу навыков управления — да совсем нет, учитывая, трудовую деятельность с 2009 года на должностях: начальник производства, заместитель руководителя, начальник группы разработки и наконец начальник ИТ отдела, и участие в президентской программе подготовки управленческих кадров.
Просто я предпочитаю подходить к делу творчески, пусть и изобретая велосипед. Вы думаете возможно развернуть полноценную ИТ службу в той компании где я сейчас тружусь по всем стандартами ИТИЛа, включая управление конфигурациями, оборудованием, инцидентами, услугами, безопасностью? Нет, уверяю, не возможно.
Наверное вы работали в компании где ИТ отдел в 50 человек, и управлять им было возможно по всем стандартам. Мне же увы приходится делать малину из того что есть. Да и этого не достаточно… :-/
Присоединяюсь к ModoStudio, Вам это просто не нужно. Вы просто-напросто не считаете эту работу своей, хотя сами согласились ей заниматься (неважно вынужденно или нет).
По сути статьи хочу добавить, что мотивация выбрана неверно. С Вашим подходом получается, что ИТ-службе выгодно наличие большого количества однотипных простых инцидентов, в то время как для запросов повышенной сложности, для которых требуется навык нажатия более одной кнопки, нужно больше времени и компетенций.
А теперь представим, что какой-то инцидент происходит с завидной регулярностью на одной и той же системе. Для чего администратору тратить, предположим, 20 рабочих часов на системный подход к проблеме, если он может получить 50 баллов, 100% премии и, в оставшееся время, пить кофе, закрыв 5 заявок суммарно за 10 минут воспользовавшись каким-то «костылем»? Потому что он профессионал и честный парень?
По работе часто приходится сталкиваться с подобными методами «управления». Ясное дело, для бизнеса важно измерить эффективность работы службы, но это никак не может измеряться количеством отработанных запросов. Работа системного администратора должна быть направлена, в первую очередь, на сокращение числа проблем и уменьшение времени простоя сервиса, а никак не на внутреннюю борьбу за дополнительные 5 копеек к заработной плате.
а я пошел дорабатывать свои корпоративные системы
По сути статьи хочу добавить, что мотивация выбрана неверно. С Вашим подходом получается, что ИТ-службе выгодно наличие большого количества однотипных простых инцидентов, в то время как для запросов повышенной сложности, для которых требуется навык нажатия более одной кнопки, нужно больше времени и компетенций.
А теперь представим, что какой-то инцидент происходит с завидной регулярностью на одной и той же системе. Для чего администратору тратить, предположим, 20 рабочих часов на системный подход к проблеме, если он может получить 50 баллов, 100% премии и, в оставшееся время, пить кофе, закрыв 5 заявок суммарно за 10 минут воспользовавшись каким-то «костылем»? Потому что он профессионал и честный парень?
По работе часто приходится сталкиваться с подобными методами «управления». Ясное дело, для бизнеса важно измерить эффективность работы службы, но это никак не может измеряться количеством отработанных запросов. Работа системного администратора должна быть направлена, в первую очередь, на сокращение числа проблем и уменьшение времени простоя сервиса, а никак не на внутреннюю борьбу за дополнительные 5 копеек к заработной плате.
Искренне хотел вам влепить минус, но вы не злобствующий, а заблуждающийся. Таки две большие разницы.
От всех иллюзий избавляет работа в крупных конторах. Типа РН-Информ. Все ретивые инженеры там научаются любить Родину, руководители среднего и крупного звена — Правильной работе с Заказчиком, легальным способам оптимизации сроков SLA, работы с доступными ресурсами — однавинтовка отвёртка на три человека. The best, когда ты с представителем Заказчика, после работы, лепите телегу в Центральный аппарат, оттачивая формулировки, так чтобы никому из вас не прилетело. Это значит, что вы — за Заказчика, а Заказчик — за Вас. В ЦА сидят небожители, пукающие радугой, и летающие на единорогах. Их не интересуют проблемы на бренной земле.
10К за нал из своего кармана на СОВЕРШЕННО НЕОТЛОЖНЫЕ ВЕЩИ, которые через пару месяцев возместят, если вы правильно заполните отчётные документы. Или не возместят, если заполнили неправильно. Никого не волнует. Не будете шевелить булками, вас уволят на следующий день. Приложения по SLA — 60 листов очень мелким шрифтом, и я их помнил все на память. Совещания с раздачей пряников — 12 часов в неделю (полтора дня рабочего времени (!) я протирал штаны, рисуя узоры в ежедневнике)
Это Роснефть, детка!
Шо вы мне там говорите за оптимизацию?
Я чувствую коллег по теме, они из Газпрома, РЖД, Росатома.
Мы молча пьём красное вино из больших бокалов.
И смотрим на закат.
От всех иллюзий избавляет работа в крупных конторах. Типа РН-Информ. Все ретивые инженеры там научаются любить Родину, руководители среднего и крупного звена — Правильной работе с Заказчиком, легальным способам оптимизации сроков SLA, работы с доступными ресурсами — одна
10К за нал из своего кармана на СОВЕРШЕННО НЕОТЛОЖНЫЕ ВЕЩИ, которые через пару месяцев возместят, если вы правильно заполните отчётные документы. Или не возместят, если заполнили неправильно. Никого не волнует. Не будете шевелить булками, вас уволят на следующий день. Приложения по SLA — 60 листов очень мелким шрифтом, и я их помнил все на память. Совещания с раздачей пряников — 12 часов в неделю (полтора дня рабочего времени (!) я протирал штаны, рисуя узоры в ежедневнике)
Это Роснефть, детка!
Шо вы мне там говорите за оптимизацию?
Я чувствую коллег по теме, они из Газпрома, РЖД, Росатома.
Мы молча пьём красное вино из больших бокалов.
И смотрим на закат.
Зря разрешили админам создавать заявки. Как узнать, какая заявка фейк и создана, чтобы увеличить счетчик положительных заявок, а какая настоящая? Лучше уж тогда Вам или «старшему смены» дать права на создание заявок от имени пользователя.
Насчет ухудшения отношений с пользователями — им надо просто вбить в голову, что если админ выполняет заявку, поданую в обход сервис деска, он за нее ничего не получает. и пусть сам выбирает, плохая зп, но хорошие отношения или хорошая зп, но возможное «ухудшение» отношений.
Насчет ухудшения отношений с пользователями — им надо просто вбить в голову, что если админ выполняет заявку, поданую в обход сервис деска, он за нее ничего не получает. и пусть сам выбирает, плохая зп, но хорошие отношения или хорошая зп, но возможное «ухудшение» отношений.
Ну все не так сложно конечно. Я же вижу кто создает заявку, и насколько она актуальна. Если заявка — фэйк — пресекаю.
Почему это зря? Если сисадмин выявил отказ ДО того как это сказалось на работе пользователя, то сисадмин — молодец, в этом и разница между превентивным и реактивным способом работы. А ловятся эти вещи легко — тикет или событие из системы мониторинга есть?
Если сотрудник не счастлив на работе, то никакая мотивация не заставит его остаться.
Как говорили в Роснефти: «А кто хочет головой вниз висеть — идите работать в Google, а у нас — сопровождение производственных процессов».
С возрастом всё становится по другому.
Человек умеет делать свою работу, ему за неё платят. Обеспечивать семью — мотивация? Несомненно.
Человек работает в маленьком городке, где вакансий по его ИТ-специальности просто нет. Держаться за своё место есть мотивация? Да.
Счастлив он при этом или несчастлив — дело десятое.
С возрастом всё становится по другому.
Человек умеет делать свою работу, ему за неё платят. Обеспечивать семью — мотивация? Несомненно.
Человек работает в маленьком городке, где вакансий по его ИТ-специальности просто нет. Держаться за своё место есть мотивация? Да.
Счастлив он при этом или несчастлив — дело десятое.
Отличный кейс работы управленца.
Sign up to leave a comment.
Мониторинг заявок в ИТ. Проще чем бургер