Аутсорсинг или техподдержка?

    Преамбула


    Представьте, что есть некое предприятие. Разумеется, с business-critical архитектурой. Любой простой – потеря денег. Сеть для предприятия строил интегратор. К экспертам этого же интегратора бегают инженеры предприятия за советом и моральной поддержкой. Формально, договора поддержки нет. Но взаимодействие есть, в том числе и потому, что у предприятия каждый год есть время для бюджетирования и это очень хорошо для интегратора, когда о тебе помнят. Несложно предположить, что при серьезной аварии, которую не смогут устранить в приемлемые сроки, нельзя будет найти виновного(но можно наказать невиновных и наградить непричастных!).

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

    Услуги техподдержки


    В первую очередь напрашивается именно это. То, что происходит де юре, оформить официально де факто. Причем начав с одного предприятия, нужно идти продавать услуги остальным. Что нужно сделать?
    • 1. Разработать типовой договор на оказание услуг по техподдержке(думаю на просторах интернета можно найти «рыбу» или что-то вроде «Договор о техподдержке для чайников»). Разумеется, с приложениями. Обязательно с lead-time и разбивкой по приоритетам, например critical/major/minor/tech cons.
    • 2. Создать презентацию и послать сейла с пресейлом в гости к потенциальному заказчику рассказывать о преимуществах. Лейтмотив – ваши проблемы ложатся на наши суровые мозолистые плечи целиком и полностью. Показать сколько теряет бизнес на простоях и за какую сумму вы готовы решать проблему.
    • 3. В зависимости от согласованного в договоре времени реакции и устранения аварий (например, 24 на 7, плюс не более 4 часов на полное восстановление сервиса) необходимо будет организовать отдел поддержки. Внимание! Все попытки обойти этот пункт всегда заканчивались неуспешно. Очень важно понимать, что подписавшись под 24*7*4, вам потребуется минимум два человека, главным образом занимающихся поддержкой.
    • 4. Продумать состав и расположение ЗИП. С точки зрения бизнеса ЗИП это замораживание денег, поэтому если суммы внушительные, то придется искать компромисс.
    • 5. Продумать и оформить процедуру взаимодействия с заказчиком, включая веб-сервисдеск или хотя бы отдельный email. Определить форму приема кейсов по авариям. Определить номер аварийной поддержки (который будут носить поочередно два инженера поддержки). Определить сроки и формат отчетности. Определить вариант фидбэка от заказчика. Определить процедуры взаимодействия экспертов с инженерами поддержки. «Оформить вторую линию поддержки». После самых критичных кейсов опередить процедуру «Disturbance reporting».
    • 6. При сложной архитектуре заказчика в перспективе можно предложить решение мониторинга и автоматического формирования кейсов в поддержку при аномальных значениях счетчиков/показателей.
    • 7. При увеличении количества заказчиков, необходимо расширять штат поддержки, причем очень рекомендую выделить отдельного человека менеджера-руководителя поддержки, который будет взаимодействовать с заказчиком, получать фидбэк и оперативно решать вопросы взаимодействия.

    Это крупным помолом. Добавьте, если что-то важное упустил.

    Аутсорсинг


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

    Вывод


    Оба варианта реальны. Если бы я консультировал заказчика-предприятие, я бы рекомендовал использовать услуги поддержки. Первые несколько лет. Когда исполнитель будет знать сеть заказчика как свои пять пальцев (как, например, семейный доктор болячки всего семейства за последние дцать лет ), только после этого можно отпускать в аутсорсинг. С максимальным количеством точек контроля, прописанных в договоре. И конечно, все это справедливо при действительно сложной критичной архитектуре.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 32

      +3
      Реалии таковы, что отдавать техподдержку в аутсорс бояться из-за риска утечки данных. Этот единственный аргумент перевешивает все экономические и другие выгоды аутсорса
        +1
        Этот единственный аргумент перевешивает все экономические и другие выгоды аутсорса

        На самом деле аутсорсинг чего-либо относительно сложного (я не про рабочие места пользователей) скорее невыгоден, чем выгоден, хотя по ряду причин удобен высокому руководству. И качество работы аутсорсеров обычно оставляет желать лучшего, так как ориентирован аутсорсер не на качественную работу сервиса, а на максимизацию затрачиваемого на проект и оплачиваемого времени в определенных рамках (в случае техподдержки добавим пункт «быстрое закрытие заявки»). Как в том анекдоте, где опытный врач лечил пациента 10 лет, молодой врач после этого вылечил пациента за неделю, и старший потом долго орал на молодого по поводу «я его 10 лет доил, а ты что наделал?».

        Ну и наличие собственной экспертизы плюс возможность контактировать непосредственно с вендором нередко на порядки сокращает время устранения инцидентов по сравнению с передачей кейса интегратору, сотрудники которого как правило недостаточно компетентны, чтобы устранять аварии максимально быстро и эффективно, но скорее всего смогут уложиться в заявленные в SLA 4 часа (целая вечность, ведь при серьезных авариях счет идет на минуты и секунды). Потому когда действительно важна доступность сервиса — компании стараются обходиться штатными единицами, используя аутсорсинг разве что для самых унылых и рутинных операций, но не передавая им самое сложное из всего, например — нестандартный траблшутинг. Например, «у одного пользователя не работает сеть» запросто передается интегратору, но вот «у всей организации нарушена связность» надо решать самим.
          0
          Консалтинг вендора, не?
        +1
        SLA можно прописать в виде двух фронтов поддержки. Первый фронт — техподдержка предприятия, второй фронт — техподдержка интегратора.
        Вопрос переговоров. По моему опыту, согласование SLA в такой форме, при наличии статистики инцидентов и проблем за пару-тройку месяцев требует нескольких недель совещаний и часов 50 плотной работы компетентного менеджера проекта по подготовке детального соглашения. На выходе — для предприятия прозрачные показатели мониторинга и понятная схема ценообразования, для интегратора — ежемесячная внятная выручка, плановая загрузка специалистов.
          0
          О, knight capital приходит с предложением зааутсорсить business-critical приложение высокочастотной торговли. Контракты, саппорт, восстановление в течение 4 часов и т.д.

          Потом приложение сливает половину капитализации компании на бирже за 3 часа. И?
            0
            Штатный сотрудник вносит ошибку в код проекта, в результате чего приложение сливает половину капитализации компании на бирже за 3 часа. И?
              0
              А если нет разницы, зачем отдавать компетенцию в чужие руки?
                0
                Для снижения расходов
                  0
                  Отдавать компетенцию в чужие руки для снижения расходов? А что тогда у компании останется своего? Некомпетентность?
                    +1
                    Вообще, это нормально для бизнеса — отдавать непрофильные направления на аутсорсинг. Посмотрите на тот же Apple (просто первый попавшийся самый крупный пример), у них своего только маркетинг, продажи и R&D. Самая затратная часть — производство — отдано на аутсорс.
                    Западный бизнес умеет считать деньги, поэтому для _непрофильных_ направлений для них выгоднее нанять специализированную компанию, экспертиза у которой — за счет значительно бОльшего опыта — существенно выше. В деньгах, кстати, это не всегда выигрыш относительно собственного персонала. В уровне экспертизы — при грамотном выборе поставщика услуги — всегда.

                    P.S. Само собой, мы рассматриваем общий случай. Всегда кому-то может повезти, и компания отхватит себе гения за копейки. Но гении капризны, а если соответствующее направление достаточно большое, все гениями быть, увы, не могут.
                      0
                      Ох, как вы круто завернули. Мол, Эппл компетенцию аутсорсит. И не зря вы слово «экспертиза» вместо «компетенция» используете. Эппл не отдаёт никому ни единого бита своей _компетенции_. Ни одного аутсорсингового проекта по программированию (хотя казалось бы, умеют считать деньги — отдать индусам и не париться).

                      Более того, раз уж мы тут в контектсе IT-инфраструктуры говорим, сколько сервисов Эппл отдала на аутсорс? icloud где работает? Репозитории с софтом и корпоративным документооборотом?

                      Так сказать, «не в этой жизни».

                      Аутсорсить кручение болтов или там, «клининговые услуги» — это всегда пожалуйста. ИТ-инфраструктуру бизнеса — только если бизнес готов отдать свою компетенцию в бизнесе в чужие руки и зависеть от прихоти чужого дяди.
                        0
                        Погодите, как-то вы смешиваете в одном все. Само собой, Apple не отдает на аутсорс программирование, потому что это IT-компания в том числе, это её основная компетенция. А вот у УралКалия, к примеру, основное направление условно — калийные удобрения. А IT — непрофильное направление. И для них вполне себе логично отдать его на аутсорс, равно как и бухгалтерию и уборку в офисных и не очень офисных помещениях.
                          –1
                          А что у Урал Калия на IT хранится? Точнее, я могу сказать, что произойдёт, если компания останется без подрядчика по уборке помещений, и даже если подрядчик прос… т все поли… тряпочки для мытья пола.

                          Скажите, что станет с Урал Калием, если сервер с его бухгалтерией превратится в тыкву за 2 дня до предполагаемой даты подачи годовых отчётов в налоговую?

                          (я знаю про бэкапы, я просто показываю разницу между аутсорсом непрофильной деятельности и жизненно важных сервисов).
                            0
                            Скажите, что станет с Урал Калием, если сервер с его бухгалтерией превратится в тыкву за 2 дня до предполагаемой даты подачи годовых отчётов в налоговую?

                            Ну так никто не заключает договоры, типа «ну, вы сделайте чтобы бухгалтерия работала». Сервер с бухгалтерией можно и нужно отдавать на аутсорсинг, просто требования к исполнителю должны быть соответствующие. Если исполнитель заявляет 99.999%, то это легко проверить в любой момент. Плюс штрафные санкции.
                              0
                              Штрафные санкции работают, когда ущерб для бизнеса охватен и переживаем. То есть штрафы для клининговой компании, которая в туалете не убрала — замечательно. Компании, которая профукала WiFi в лобби — тоже. А если аутсорсер потерял данные банка по выданным кредитам, да ещё и бэкапы того, не распаковываются, то кого утешат штрафы?
                                0
                                Плюс штрафные санкции.

                                Обычно штрафные санкции не превышают месячные затраты на аутсорсера. А чтобы был серьезный SLA, надо платить по совсем другим тарифам. И конечно же никто не подпишется на штрафы, сравнимые с капитализацией аутсорсера.
                                  0
                                  Подпишется, если заказчик подпишется на приобретение оборудования и заключение контрактов, которые будут гарантировать предоставление услуги. Либо сама услуга будет в себя включать аппаратную часть (аренду, со сути), что соответствующе отразиться на стоимости.
                                    0
                                    Вне зависимости от закупки железа, аутсорсер не подпишется на SLA, по которому есть хотя бы малейший шанс потерять свой бизнес (или нанести ему серьезный урон) в случае факапа. А что толку заказчику от штрафа в несколько миллионов рублей, если простой стоил десятки миллионов долларов?
                                      0
                                      Я во всех этих спорах не понимаю одной вещи: какая разница, допустит ошибку аутсорсер или свой собственный работник? При этом предполагается, что опыт (и, соответственно, количество набитых шишек) у аутсорсера гораздо больше, поэтому он знает, где подстелить соломку в большем количестве случаев. Если же нет, то встает вопрос о том, кто же нанял такого аутсорсера.

                                      Ну, и если мы говорим о миллиардах, никто не мешает нанять компанию-аудитора для периодического аудита.
                                        0
                                        При этом предполагается, что опыт (и, соответственно, количество набитых шишек) у аутсорсера гораздо больше

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

                                        Ну так без этого вообще никуда. И не одну, а чередовать их.
                                          0
                                          Аутсорсер аутсорсеру рознь.

                                          Например habrahabr.ru/company/fujitsu/blog/215479. В GDC — десятки специалистов самого высокого класса, и их квалификация зачастую просто недостижима для специалиста обычной компании, потому что объем и рабочая нагрузка несравнимы. Да и подход к работе выстроен так, чтобы за счет правильно выстроенных показателей эффективности специалист постоянно развивался. Это еще большая редкость.
                                            0
                                            их квалификация зачастую просто недостижима для специалиста обычной компании

                                            Вы уверены, что недостижима?
                                            объем и рабочая нагрузка несравнимы.

                                            Собственно, именно из-за нагрузки маловероятно, что вашими задачами будет заниматься грамотный человек, а не джамшут. А рабочая нагрузка штатного специалиста направлена как раз в том направлении, которое и требуется компании, именно в нем он и получает опыт.
                                              0
                                              Вы уверены, что недостижима?

                                              Таково мое убеждение, основанное на опыте. Одна из причин как раз «объем и рабочая нагрузка».

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


                                              Это крайне спорное утверждение, еще и шовинистского толка. Правильно поставленный рабочий процесс направлен на исключение несоответствия квалификации поставленной задаче:
                                              — если инцидент решается специалистом недостаточной квалификации, он не будет решен в срок SLA. Это штраф для обслуживающей компании.
                                              — если изменение планируется и внедряется специалистом недостаточной квалификации, то, вероятнее всего, он даже не сможет составить план изменения. А плохой план не будет утвержден заказчиком, поскольку, специалисты заказчика, как правило, не на экспертном уровне, но приблизительно разбираются в предметной области. И некачественное изменение не будет оплачено. А задача — заработать.

                                              Конечно же, я говорю про хорошую обслуживающую компанию (как в моем примере) и твердые контрактные обязательства.
                                                0
                                                Таково мое убеждение, основанное на опыте.

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

                                                Обычно на этом пункте экономят.
                                                — если инцидент решается специалистом недостаточной квалификации, он не будет решен в срок SLA.

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

                                                Варианты:
                                                1) Один планирует, другой делает.
                                                2) Планирует человек с недостаточным опытом. Грабли вылезут в процессе работ.
                                                А плохой план не будет утвержден заказчиком, поскольку, специалисты заказчика, как правило, не на экспертном уровне, но приблизительно разбираются в предметной области.

                                                Снова заблуждение. Сколько раз мы через это проходили. Доходило до смешного: аутсорсеры детально, с максимальной дотошностью планируют миграцию сервиса с одного IP адреса на другой, учитывают все мелочи, расписывают порядок действий нескольких подразделений. Все согласовывают на всех уровнях, все довольны, проблем не ожидается, тесты пройдены успешно. А потом этот уже согласованный план попадается мне на глаза, я задаю аутсорсерам невинный вопрос «ребята, а про DNS никто не забыл?». Суета, доработка, снова согласование, и спасенная продуктивная инфраструктура. Никто из согласующих не заметил ошибки.

                                                И такое встречается в случае ВСЕХ интеграторов. Хотя вроде бы нам выделены лучшие люди.
                                                И некачественное изменение не будет оплачено. А задача — заработать.

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

                                                Либо у вас такие задачи, что всё совершенно стандартно и с объемом один человек на полставки справился бы, либо таких интеграторов не бывает. Хотя возможно, есть более мелкие, которым есть дело до собственной репутации и которые действительно стараются сделать хорошо.
                                                  0
                                                  Обычно SLA — часы даже там, где реальный срок решения должен составлять минуты. Штатный сотрудник может уложиться в минуты, аутсорсер — вряд ли.

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

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

                                                  Снова заблуждение. Сколько раз мы через это проходили. Суета, доработка, снова согласование.

                                                  В итоге вы забраковали изменение, и оно в исходном виде не прошло, что к лучшему. :)
                                                  Мне кажется вы согласитесь, что вам было не в пример быстрее и комфортнее проверить план изменения, нежели лично составить его с нуля, а затем лично выполнить (часа в 3 ночи в выходной)? Ваши 5 минут против 4 часов аутсорса. И возможно, аналогичный план, разработанный своими сотрудниками был бы не лучше, а времени отнял бы на порядок больше.
                                                    0
                                                    соответствие требуемого SLA (реальный срок решения должен составлять минуты) и зафиксированного в контракте SLA (часы) это, в основном, организационная проблема и проблема заключенного контракта.

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

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

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

                                                    А вот скучные, унылые задачи вроде массового конфигурирования по короткому и простому шаблону с минимальными проблемами в случае ошибки я наоборот доверю скорее аутсорсеру, чем себе или скрипту. Я от такого быстро схожу с ума, а скрипт гипотетически крайне опасен и за ним надо внимательно приглядывать.
                                +2
                                А что изменится, если то же самое произойдет при работе собственных специалистов? При этом с компании-подрядчика можно будет получить хоть что-то, а собственных специалистов компания-заказчик в лучшем случае по статье уволить сможет. Я не понимаю альтернативы, которая сможет избежать бед, вами описываемых. Где она?
                                  0
                                  Скажите, что станет с Урал Калием, если сервер с его бухгалтерией превратится в тыкву за 2 дня до предполагаемой даты подачи годовых отчётов в налоговую?


                                  То на следующий день его восстановят из резервной копии.

                                  А кто его сломает — свои, или аутсорсеры — не принципиально, с той лишь разницей, что у аутсорсера шансов это сделать несколько меньше, поскольку их квалификация, как правило — выше.
                            0
                            Пылесосы Electrolux плохо и некачественно сосут, Mercedes-Benz испытывает затруднения при движении задним ходом, а Bridgestone прокалывается в 4 раза чаще конкурентов из-за аутсорсинга обслуживания ит-инфраструктуры?
                              0
                              Не знаю, я ничем из перечисленного не пользуюсь.
                      0
                      Вообще-то управление рисками бизнеса — обязанность топ-менджемента этого бизнеса.
                      И если на аутсорс отдается поддержка приложения, которое может бизнес убить, должен быть аварийный рубильник для такого приложения и процесс, обеспечивающий вырубание этого рубильника в случае если потери превышают некоторый рубеж. И ответственность за этот рубильник и его выключение остается на топах.

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

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

                        И никакой «рычаг для отключения» не поможет, потому что если в компании нет компетенции, то вовремя этот рычаг просто некому будет дёрнуть. А когда станет понятно даже секретаршам, что что-то не так, вообще уже поздно будет дёргаться.

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

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

                    Only users with full accounts can post comments. Log in, please.