Как организовать техническую поддержку в веб-студии

Внутренняя кухня

Оговорюсь, что расскажу про техническую поддержку только с точки зрения программирования. Дизайн, креатив и контент — тоже важно, но их организовать в разы проще (по примерно такой же схеме).

Свои проекты мы делаем по гибкой методологии scrum. Это значит, что в процессе работы клиенту не обязательно придерживаться толстого и нудного ТЗ, а можно добавлять/удалять/изменять любые хотелки прямо по ходу работы. Плюсы: гибкость и прицел на постоянное развитие проекта сразу. Минусы — постоянно неактуальная документация.

https://www.youtube.com/watch?v=ytpolicyandsafetyru

Грозовая туча: старые и новые проекты.

Над каждым проектом работает КОМАНДА разработчиков. Это важно, потому что после запуска проекта как минимум два-три человека причастны к коду и могут его поддерживать. На практике это сильно лучше, чем если бы всю разработку делал бы один «незаменимый» гений.

С незаменимостью также помогают бороться две вещи: строгие стандарты кодирования и регулярные code review, которые мы проводим на своих проектах.

Временное подключение к поддержке дополнительных программистов, не участвовавших в реализации проекта, я не очень люблю: высок риск запустить прогрессирующее отравление проекта. Это явление есть проявление человеческого фактора и кажется, во многом обусловлено русским менталитетом. Желание творить крупными мазками, а не кропотливо доводить детали.

Нежелание нового разработчика лезть в чужой код и его понимание, что проектом он занимается временно — приводит к тому, что в код втыкаются костыли. После появления в коде критической массы костылей даже команда, которая изначально разработала проект, начинает считать код чужим и решает задачи с помощью новых костылей.

Через некоторое время проектом заниматься никто не хочет и все ноют что он — говнокод. Купировать отравление можно, но довольно затратно: часто требуется провести глубокие кодревью и рефакторинг. Иногда два-три раза подряд. В общем, добавление новых людей на поддержку я считаю оправданным только в трех случаях:

1. Мне нужно ввести нового человека в проект, чтобы он занимался им дальше на постоянной основе.
2. Для развития новичков под присмотром куратора.
3. Очень-очень редко (и рискуя получить за это минусов в карму), но все же: как мера воспитания слишком честолюбивого разработчика с задатками гурмана. Я имею в виду тех редких людей, которые на любую задачу начинают разглагольствовать, что она им не интересна, все технологии — го%но, весь чужой код — вообще го%но и даже свой, который он писал неделю назад — тоже устарел. Он вполне может схлопотать себе на ближайшие 2-3 месяца (или пока не угомонится или пока не станет ясно, что не сработаемся) проекты только на техническую поддержку (это в то время, как его коллеги получают новые, интересные проекты).

При планировании нагрузки на разработчиков мы рассчитываем, что их рабочий день состоит из двух частей: работа над основным проектом (закладываем 6 часов) и технической поддержки (оставшиеся два часа). Как правило, часы техподдержки наступают с 16:00 и до 18:00. Это время хорошо подходит для решения мелких и простых задач.

Обратная сторона медали — деплой на продуктивные сервера происходит в конце рабочего дня, и в случае чего целую ночь на продуктиве может висеть кака. На критичных проектах деплой или часть саппорта мы переносим на утро. Если в какой-то день нет задач на техническую поддержку — программист занимается основным проектом.

В перерывах между спринтами (например, когда идет интенсивное тестирование и заниматься проектом нельзя), мы можем ставить больше техподдержки, если это целесообразно. В утренние часы разработчиков стараемся не дергать (без крайней необходимости). Это связано с тем, что важно, чтобы разработчики работали в потоке и как можно меньше отвлекались и переключались.

Итак, мелкие и срочные задачи мы вклиниваем в эти два часа в день, с 16 до 18 (ну фактически, с учетом командной работы это может быть и 4 и 6 часов, в зависимости от того, параллелятся ли задания). Крупные задачи, которые можно делать в спокойном режиме, мы запускаем в работу спринтами (минимум по 40 часов), в основные часы. Работа спринтами стоит для клиента дешевле (в пересчете на стоимость часа), чем экстренные и срочные задачи, которые нужно сделать еще вчера.

За коммуникацию с клиентом на технической поддержке в большинстве случаев отвечает тот же менеджер, что и работал над проектом. К сожалению, это не всегда рационально с точки зрения использования дорогущщего времени менеджеров (дорогие — не только в смысле затрат, а в смысле ТОС: менеджеры очень часто становятся бутылочными горлышками системы, а час простоя в бутылочном горлышке равен часу простоя всей системы).

Если на менеджера за счёт технической поддержки чрезмерная нагрузка (мы называем это «рвет радугой») и потери на передачу проекта другому менеджеру принципиально окупятся — в этом случае я могу поменять менеджера. Во многом проекты на поддержке попадают подрастающему поколению для прокачки собственных сил и набора клиентской базы. Крайне редко менеджера меняем, если на проекте возник какой-то конфликт с клиентом и нужно начать отношения с чистого листа.

Опять же, в очень исключительно-редких случаях нехватки менеджерского времени, с формулировками клиента напрямую работает программист. Однако мы стараемся минимизировать такие коммуникации, т.к. нечеткость формулировок крайне нервирует программистов, а ответы программистов на вопросы клиентов без предварительной вычитки могут конфузить клиента наповал.

Нажмите на картинку для перехода к интерактивной карте

Кто есть кто на этой схеме?

– это единое окно «входа» обращений пользователей. Специалисты Service Desk в режиме 24х7 принимают все поступающие обращения по почте, телефону или через веб-интерфейс и фиксируют все заявки в ITSM-системах (IT Service Management, управление ИТ-услугами).

ITSM-системы позволяют следить за этапами работ и придерживаться сроков, прописанных в договоре или регламенте. Специалисты Service Desk – «первая помощь» при неполадках в работе АРМа. Они должны понять причину проблемы со слов пользователя или диагностировать её, подключившись удаленно к АРМу.

https://www.youtube.com/watch?v=ytadvertiseru

В ответ на обращение пользователя специалист Service Desk либо дает сотруднику рекомендации, либо удаленно устраняет проблему, используя накопленную базу знаний (перечень типовых обращений).

Если специалист Service Desk не может решить проблему, то он перенаправляет заявку на следующую линию «обороны» – инженерам технической поддержки второй линии.

Инженеры второй линии поддержки, или аникейщики, определяют дальнейшие шаги: решить обращение удаленно или выехать на место.

Служба Service Desk и вторая линия составляют «ядро» процесса технической поддержки. Процесс может показаться громоздким, но когда он отработан, то это конвейер, функционирующий согласно регламентам, которые обеспечивают эффективность оказания услуги и соблюдение SLA. Какие еще специалисты и ресурсы задействованы в процессах оказания услуги «Поддержка пользователей»?

Источник

Ставить задачу в любой, даже в самой безумной формулировке

Это важный момент, который касается ответственности. Ответственность — штука обоюдоострая. Здесь есть несколько принципов, о которых мы договариваемся с клиентом. Как правило, с самими принципами клиент не будет спорить (они понятны и логичны), однако будет пытаться найти лазейку между принципами. Менеджер проекта, кстати, тоже.

1. Говно на входе — говно на выходе.
   Тут понятно. Плохо поставленная задача с высокой степенью вероятности будет сделана неправильно.
2. Без телепатии.
   То есть, вообще считаем, что по умолчанию телепатии нет. «Это же было очевидно» или «Я подразумевал что это будет само собой», к сожалению, не аргумент.
   Я считаю это правильным принципом. Однако в нем есть изъян. Это очень большая лазейка для недобросовестного менеджера проекта бесконечно тянуть деньги и делать одну и ту же задачу. Однако во-первых, клиент интуитивно чувствует, когда его доят, во-вторых — ему это очень сильно не нравится, и он вам обязательно про это скажет. А в-третьих, можно внедрить формальную процедуру разбора полётов, чтобы отлавливать подобные инсинуации.

   Но об этом — позднее.

3. Полученное задание должно быть проанализировано с точки зрения выполнимости, целесообразности, полноты и ресурсов.

   Грозовая туча: заказчик и менеджер студии.
   

   Наверное, 70-80% рабочего времени менеджера тратится на то, чтобы въехать в задачу, уточнить формулировки, понять, на что она может повлиять, предложить более эффективные ходы, предусмотреть все риски или оценить задачу. Вполне возможно, что вместо того, чтобы отдать задачу в работу, менеджер будет названивать и задавать вопросы. Или вообще отговорит клиента делать ее. Да, нам не заплатят за то, что мы отговорили. И иногда очень сложно подобрать аргументы, чтобы отговорить. Но так — кармически правильнее. Впрочем, если наши аргументы не помогут — у нас не будет выбора, кроме как заткнуться и сделать как просили :).

4. Мы понимаем, что двойных трактовок не избежать.
   На уровне здравого смысла это так. Опять же, тут есть лазейка как для менеджера, так и для клиента — «включить дурочку». Но если работать системно, то любителей шнырять в лазейки можно отловить и наказать, применить управляющее воздействие.
5. В некоторых случаях для уточнения формулировок потребуется платная работа аналитика или программиста.
   В основном это касается больших задач или тех, где нужен эксперимент или рисёч. Или совсем уж запутанных постановок и явной дислексии.

Итого, мы оставляем за собой право уточнять и переформулировать постановки клиента в более чёткие. Уточнять и дописывать детали. И даже отговаривать клиента от каких-то задач (если на наш взгляд они сделают проект хуже). Однако за финальные формулировки несет ответственность клиент. Те формулировки, которые мы зафиксировали один в один будут направлены в разработку. И по ним же будет проверять наш тестировщик. И по ним же мы будем сдавать задачу.

Да, но нет. Понятное желание, слепое потакание которому создаст кипиш, панику и неразбериху в студии и сделает любой проект технической поддержки убыточным. Чтобы такое обрабатывать, менеджеру проектов нужно ничего не делать, но всё время быть на стрёме. А это экономически нецелесообразно и морально тяжело.

На все проекты по техподдержке мы заводим единую систему хранения задач клиента. Таскменеджер. Там же идет их уточнение, оценки и проставляются статусы. Что это будет технически за система — не так важно (оперативную работу можно организовать и в Google Docs и в портале Битрикса). Самое первое, что требуется для того, чтобы менеджер и клиент притерлись — это настойчиво но вежливо научить клиента писать и отвечать в таскменеджер.

Понятно, что все равно в каких-то случаях клиент будет писать по Skype, звонить по телефону или писать 50 писем в течение часа в почту. Задача менеджера здесь: вежливо попросить поставить задачи в таскменеджер. Можно даже ссылаться на то, что в скайпе задача потеряется, пожалуйста, поставьте ее в таскменеджер. Поначалу это может раздражать клиента, однако со временем плюсы такого подхода станут понятны и ему.

Тем не менее, обсуждение задач, особенно крупных, неэффективно вести в трекере. Скайп, телефон с обязательной фиксацией результатов разговора в конкретные задачи. Обычно разговор резюмирует наш менеджер проекта. Задача клиента — проверить и утвердить правильность формулировок и дать добро в работу.

Понятно, что бывают ситуации, когда всё упало и нужно звонить и срочно решать вопрос. Например, у нас был случай, когда в интернет-магазине обуви в момент валютной паники, начало прилетать по 100 заказов в час, и клиенту потребовалось срочно остановить продажи, т.к. не справлялась логистика. Понятно, что в случаях форс-мажора мы все бросим и решим проблему по телефону.

Специалист службы качества

Этот специалист выполняет следующие функции:

• готовит ТЗ на добавление нового заказчика в ITSM-систему;
• по обращениям специалистов Service Desk решает нестандартные ситуации, не описанные в документации;
• на основании получаемых из ITSM-системы отчетов анализирует нарушения SLA;
• по результатам анализа проводит корректирующие мероприятия, изменения в документации (регламентах, инструкциях…) или в настройках ITSM-системы. В собственной ИТ-службе эту роль может выполнять, например, ее руководитель. В аутсорсинговой компании – это отдельная должность.

Точных оценок

По большинству проектов технической поддержки оплата идет по фактически затраченному времени. Задача менеджера — дать предварительные оценки трудоёмкости и выяснить у клиента, делаем задачи или нет. В случае, если мы начинаем отклоняться от оценки (например, нашлась какая-либо особенность у проекта, которая не дает нам закончить работу в срок), обязанность менеджера — предупредить клиента, сообщить новые прогнозы по оценкам и уточнить, делаем задачи или нет. Раздувать сроки и оценки особого смысла нет, т.к. клиент это чувствует и выскажет нам это при опросе удовлетворенности.

Тем не менее, для некоторых проектов корпоративного сектора, где существует громоздкая процедура бюджетирования, такой подход не годится: все оценки и бюджеты нужно подписывать и утверждать заранее. В этом случае в наших оценках будет заложено максимальное число рисков, которые мы можем предусмотреть, по каждой из задач.

Замечу, что работа по time&material на практике для клиента быстрее и дешевле, однако возможна только если клиент доверяет и доволен. Нам это тоже выгодно, т.к. сокращает затраты на менеджмент и бюрократию (а менеджер, напомню, у нас бутылочное горлышко системы).

К вопросу о точных оценках: несмотря на то, что есть хорошие методы оценок, точных оценок не бывает. Эту мысль сложно донести до клиента и тут очень легко уйти в демагогию. Я предпочитаю не увлекаться с клиентом обсуждением этой темы, а просто обрисовать две схемы работы: с оценками, в которые заложены наши риски и оценками, где все риски несет на себе клиент, и дать выбор. В конце концов и мы должны понимать, что бюджеты клиента ограничены, а клиент — что нам нет смысла работать без прибыли.

Если вас всерьез интересует вопрос точных оценок — в конце статьи я там насколько ссылок.

Заказ материалов, доставка и хранение

https://www.youtube.com/watch?v=ytaboutru

Для техподдержки требуется подменная техника на время ремонта сломанной, запчасти и расходные материалы, которые нужно быстро доставлять на места, в том числе в регионы. Для этого нужна грамотно организованная логистика и складские помещения вблизи объектов обслуживания (относится и к собственной ИТ-службе, и к аутсорсинговой компании).

Источник

Я перечислил основные составляющие услуги «Поддержка пользователей». Немаленький список, который должен работать как единый слаженный механизм. Эти составляющие, соответственно, входят и в расчет стоимости поддержки.

Ответственности за сделанное

По схеме работы по финализированным оценкам, все риски по кодированию лежат на нашей стороне. Замечу, что не любой проект мы готовы обслуживать по такой схеме.

При схеме time material по сути все риски лежат на клиенте. Если ошибок много и их исправление выставляют клиенту — он будет недоволен и вам про это скажет. Как правило, экономически выгоднее не вступать в спор и поправить свои ошибки за свой счёт, не нагнетая обстановку, даже несмотря на то, что согласована схема работы по фактическим часам. Я придерживаюсь того, чтобы исправлять ошибки за наш счёт, если:

• проект на поддержке;
• понятно по шагам, как ошибку воспроизвести;
• обеим сторонам очевидно, что это — ошибка разработки (реализации).

Последний пункт дает повод для инсинуаций как заказчика, так и разработчика, поэтому не может быть описан формально. Например, если причиной ошибкой послужила неполнота постановки задачи — ответственность за это лежит на клиенте (т.к. именно он отвечает за приемку финальных формулировок). Более того, это значит с клиента не брали денег за реализацию задачи в более полном объеме.

Если косяк откровенно наш — берем и исправляем, не компостируя мозги. Так в итоге дешевле.

Исключение: очень сложные системы с большим количеством зависимостей. Поменяешь запятую в карточке товара — сломается какой-нибудь хитрый импорт, который запускается раз в месяц. Здесь либо нужен code freeze полный тест системы на каждое изменение (что очень дорого), либо полное покрытие кода тестами (что тоже очень-очень дорого), либо смирение, что такие ситуации возможны.

Замечу, что чтобы схема работала — нужно, чтобы спорные ситуации возникали как можно реже. Иначе клиент будет недоволен поддержкой или поддержка будет убыточной для студии.

Еще нюанс — мы не несем на себе ответственность за 3-х лиц (например, хостинг) или упущенную выгоду. Обычно это воспринимается адекватно.

Расчет стоимости поддержки пользователей

Предлагаем расчет и сравнение стоимости услуг «Поддержка пользователей» собственной ИТ-службой и при аутсорсинге в четырех вариантах: при количестве пользователей 200 человек, а затем при увеличении этого количества до 400, 1000 и 3000 пользователей.

Ниже приведена таблица результатов типовых расчетов, которая показывает, сколько придется потратить на поддержку при разном количестве пользователей.

https://www.youtube.com/watch?v=ytdevru

В таблице приводятся практические расчеты стоимости, подготовленные в рамках технико-экономических обоснований для ряда заказчиков. В стоимость аутсорсинга включены также налоги и накладные расходы компании.

Отметим, что в варианте с собственной ИТ-службой заказчик при увеличении объемов вынужден брать в штат дополнительных специалистов, чтобы укладываться во внутренний SLA. А аутсорсинговая компания имеет возможность увеличить долю (%) занятости специалистов необходимой квалификации.

Источник

При сравнении своей ИТ-службы и аутсорсинга при объеме до 200 АРМов стоимость поддержки будет выгоднее для собственной ИТ-службы. Но при увеличении штата сотрудников более 400 АРМов стоимость услуг аутсорсинговой компании становится привлекательнее, чем своей ИТ-службы. При дальнейшем увеличении рабочих мест аутсорсинг наращивает преимущество благодаря нелинейному увеличению задействованных специалистов по поддержке АРМов и отлаженных процессов по поддержке.

Самое важное. Ретроспективы. Разбор полётов

Это самая важная часть системы технической поддержки. Без нее будет накапливаться взаимное скрытое недовольство, которое перерастёт в один прекрасный день в конфликт. Виноват будет всегда web-разработчик. Всегда!

Замечу, что в долгосрочной перспективе бухтение клиента практически неизбежно (ну или я не знаю случаев, когда клиент был бы целиком доволен 2-3 летним итогом поддержки, не имел каких-либо нареканий и время от времени не смотрел бы на сторону). Итак.

Довольно правильно делать с клиентом пересмотр сделанного за 2-3 месяца. Формально анализировать список задач и смотреть причины возникновения ошибок. Это могут быть формулировки, и в этом случае вы совместно должны решить, как вам улучшить постановку задач. Это могут быть слишком частые ошибки программирования, и тут нужно искать причины на своей стороне. Наконец, клиент может быть недоволен тем, что его не отговорили от каких-то его идей и это привело только к лишней трате денег.

Вы должны системно проверять, доволен ли клиент работой с вами. Встречаться лично, разговаривать, обсуждать перспективы проекта, перспективы бизнеса клиента и его планы на ближайший год. Особенно осторожным следует быть при смене менеджера на стороне клиента. Важно рассказывать клиенту, где вы можете пойти ему навстречу и где нет, и почему. Это добавляет открытости и управляемости.

Без этого в долгосрочной перспективе вас сольют.

Выше мы сравнили стоимость поддержки пользователей для аутсорсинговой модели и силами своей ИТ-службы. При выборе своего варианта реализации услуги вот еще что стоит учесть.

• Аутсорсер может обеспечить «эластичность» цены – пропорциональное изменение стоимости при изменении количества поддерживаемых пользователей.

Услуга «Поддержка пользователей», как правило, оплачивается из расчета за один поддерживаемый АРМ. Если АРМов обслуживается меньше, то ежемесячная оплата снижается. Это выгодно компаниям, испытывающим сезонные колебания бизнеса.

 Пример эластичности аутсорсинга

Компания «Айс Крим Аквамарин» продает мороженое. Представим, что в каждой палатке установлен один АРМ, один принтер, касса и камера, и таких палаток в Москве около 100 шт. Пусть SLA будет «лайтовым»: решение инцидента в течение 8 часов в режиме 8х5.

В таких условиях и аутсорсеру, и своей ИТ-службе потребуется по меньшей мере два сотрудника. Но когда для палатки с мороженым наступит «мертвый сезон» (осень-зима-весна) и продажи мороженого упадут в разы, компания решит сократить количество мобильных палаток до 50.

Теперь один специалист собственной ИТ-службы станет недозагруженным и заказчику в течение примерно полугода придется платить зарплату впустую (при средней з/п с учетом налогов это 80 тыс. х 6 мес. = 0,5 млн в течение сложного для бизнеса периода затишья. В это же время аутсорсинговая компания задействует инженера с малой загрузкой на других проектах, а заказчик будет платить лишь за поддержку оставшихся в работе АРМов.

Сопоставляя цену услуг аутсорсера и расходы на собственных специалистов, заказчик часто не учитывает налоги: «Почему вы просите 55 тысяч? Я найму админа и буду ему платить 40 тысяч». При этом затраты на собственных ИТ-специалистов включают следующие выплаты:

• Налог на доходы физических лиц (НДФЛ) – 13%*,
• Пенсионный фонд РФ (ПФР) – 22%*,
• Фонд социального страхования (ФСС) – 2,9%*,
• Фонд обязательного медицинского страхования (ФОМС) – 5,1%*.

Итого: 43%*

Если добавить эти 43%, то, скорее всего, цены будут сопоставимы.

Помимо налогов в список затрат на собственную ИТ-службу нелишним будет включить оплату рекрутинга, то есть расходы на поиск работников, размещение вакансий, собеседования и т.д.

* Цифры приведены для случая, когда суммы выплат сотрудникам не превышают предельную базу для начисления страховых взносов, устанавливаемую Правительством РФ (для наших расчетов это, как правило, так).

Пример из практики

Буквально несколько месяцев назад ко мне поступил запрос рассчитать стоимость поддержки рабочих мест пользователей. Объемы были не очень большие – в районе 200 пользователей плюс серверное и сетевое оборудование. Расчет я красиво обернул в коммерческое предложение и направил заказчику.

Через два дня заказчик сообщил, что ему понравился состав нашей команды и принципы работы, а вот со стоимостью услуг он совершенно не согласен. Оказалось, что заказчик рассуждал достаточно банально: «Я плачу за двух специалистов порядка 80 тысяч рублей в месяц – по 40 каждому. А ваше предложение содержит цифру почти вдвое выше».

Мы посчитали и добавили к стоимости специалистов заказчика все налоги, и цифры оказались сопоставимы. Заказчик оценил, что мы можем при необходимости выделять инженера нужной специализации, который бы решал узкопрофильные задачи, а также заменял отсутствующих специалистов (в отпуске, на больничном), и все-таки выбрал аутсорсинг.

• Аутсорсинг подразумевает, что вы получаете готовый результат — сервис согласно подписанному SLA.

Повторюсь, что внедрение централизованной службы поддержки пользователей в своей компании предполагает отладку бизнес-процессов, создание службы Service Desk, внедрение ITSM-системы, обучение специалистов, ведение базы знаний, работу с сервис-партнерами, организацию логистики поставок «расходки».

Источник

• Аутсорсер несет юридическую и финансовую ответственность за невыполнение SLA.

Если SLA выполнен не полностью и ниже порогового значения KPI, то аутсорсер производит перерасчет ежемесячного платежа, снижая счета. Для своей ИТ-службы создание механизма материального стимулирования и ответственности за невыполнение требований по качеству и оперативности техподдержки – сложная и иногда просто не решаемая задача.

https://www.youtube.com/watch?v=ytpressru

В целом ряде случаев от штатных ИТ-сотрудников бывает «физически» нелегко добиться приемлемого уровня SLA. Например, небольшие и средние компании, как правило, берут ИТ-специалиста на фиксированную оплату. Он – «единица», которая должна поддерживать в рабочем состоянии технику. С таким сотрудником не подписывают SLA на выполнение работ – он просто делает работу по мере возможности.

Источник

Пример из практики

Аутсорсинговая компания платит штрафы за нарушение SLA. Точнее, сумма счета снижается на размер штрафа. В нашей практике такое случается редко, и все же никто от этого не застрахован.

Однажды мы не выполнили SLA из-за того, что региональный партнер в «неподходящий момент» решил отказаться работать по договору. Нам пришлось оперативно (в течение суток) искать нового партнера. Но за время поиска случился инцидент – не работал один ПК пользователя. Наш инженер приехал, выполнил необходимую работу и восстановил АРМ, но уже с некоторым нарушением SLA. В конце месяца, когда выделенный заказчику менеджер нашей компании писал отчет, он сделал перерасчет в пользу заказчика из-за этого нарушения SLA.

При выборе аутсорсинговой схемы заказчик снимает с себя проблемы, связанные с отсутствием специалистов на время отпусков и больничных.

Источник

Пример из практики

Небольшая туристическая компания имела в своем штате администратора, который верой и правдой приходил обслуживать ИТ-инфраструктуру. Никто не задумывался о том, что один администратор в офисе – это риск оказаться в ситуации, когда инфраструктура не работает из-за его неожиданного увольнения, болезни или даже планового отпуска.

Еще один момент — у аутсорсинговой компании есть накопившиеся компетенции в виде базы знаний, сокращающие время на решение некоторых инцидентов.

Итого

Спрос на техническую поддержку сейчас значительно превышает предложение. Особенно в кризис многие будут стремиться «подлатать сайт», а не стартовать какие-то серьезные работы. Тем не менее, организовать работы грамотно, чётко и рентабельно здесь ОЧЕНЬ сложно. В первую очередь потому, что требуется высокие и разносторонние компетенции менеджеров и разработчиков. Оперативность, многозадачность и частые переключения. Много-много рутины. И это все на фоне высокой конфликтности атмосферы.

Нажмите на картинку для перехода к интерактивной картеВсе это в противовесе с возможностью спокойно делать новые и интересные проекты на новых неизведанных технологиях 🙂

Пожалуй, мне остается пожелать удачи в поиске баланса между созданием нового и поддержкой старого!

Какие еще вопросы волнуют компании, когда они рассматривают вариант аутсорсинга

В рамках действующего контракта повысить цену сложно, а вот при подписании нового договора — возможно. Снизить такую вероятность можно, выбирая исполнителя на основе конкурсных процедур, условия которых в числе прочих параметров учитывают и стоимость услуг.

Переходный период. Поставщику услуги нужно освоиться с ИТ-инфраструктурой заказчика, отладить процессы – на это может уйти от нескольких недель до нескольких месяцев. Срок зависит от опыта аутсорсинговой компании и от размера компании-заказчика. Во избежание спорных ситуаций прописывайте адекватный переходный период в договоре и по возможности предоставьте аутсорсеру максимально полную информацию и средства для оказания услуг (базу знаний, перечень и состав поддерживаемого оборудования и т.д.).

Вопросы информационной безопасности. Чтобы гарантировать заказчикам соблюдение требований информационной безопасности при оказании ИТ-услуг, сервис-провайдер ежегодно проходит сертификацию на соответствие международному стандарту ISO 27001. И сервис-провайдер должен быть готов по требованию ознакомить заказчика с принятой у него политикой информационной безопасности.

Вот такая получается картина.

Считайте, анализируйте, выбирайте. Как организовывать поддержку пользователей – решать вам. И меньше вам «пожаров» в ИТ-инфраструктуре!

https://www.youtube.com/watch?v=ytcreatorsru

Источник