Внедрение Service Desk и CRM. 13 главных причин неудач и как их избежать?

    По данным The Standish Group в США и Европе за 2015 год:

    • 31,1% от всех ИТ-проектов остановлены и не завершены;
    • 52,7% от всех ИТ-проектов завершены со срывом сроков, значительным увеличением первоначально запланированного бюджета или кардинальным изменением изначально запланированных целей;
    • только 16,2% от всех ИТ-проектов оправдали ожидания.

    Итого: 83,8% (фактически 8 из 10) неудач против 16,2% успеха.

    image

    Последние лет 10 эти цифры практически не меняются — при внедрении ИТ систем, бизнес сталкивается с типовыми проблемами, которые можно сгруппировать следующим образом:

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

    А что приводит к неудачам внедрения Service Desk и других систем в России?


    Мы разрабатываем Help Desk систему для автоматизации всех процессов постпродажного обслуживания в сервисных компаниях. Поговорив с более чем 5000 представителями из самых различных сервисных отраслей (средний и малый бизнес), мы решили поделиться причинами неудачных внедрений Service Desk в России/СНГ и методами преодоления большинства трудностей! На самом деле проблемы получились «универсальные» для внедрения любых ИТ систем и ИТ проектов.
    Уверены, это позволит вам подготовиться и избежать хотя бы часть из них.

    Внедрение Service Desk. Российские реалии


    Общение с 5000+ сервисными компаниями, работающими в сегменте b2b в России и странах СНГ, не дает точную статистику по проектам, но позволяет выявить похожие группы проблем (не без локальной специфики). Далее каждый пункт мы рассмотрим подробнее, остановившись на самых популярных «представителях» неудач. Стоит отметить, что использованная классификация проблем условна и выбрана лишь для удобства изложения. Выделенные группы друг с другом пересекаются. К примеру, боязнь изменений неразрывно связана с организационными моментами и т.д.

    Серебряная пуля


    image

    «Service Desk система сама решит все проблемы»


    Многие действительно верят, что система автоматизации решит все проблемы. В сложившихся процессах большинства сервисных компаний царит хаос, и кажется, что внедрение Service Desk или CRM позволит получить полный контроль над ситуацией в части продаж или клиентской поддержки.
    Это большая ошибка. Есть известная поговорка: «Если у вас в компании хаос, то итогом внедрения системы автоматизации будет автоматизированный хаос».
    Никакой инструмент не решит назревшие внутренние проблемы. Эффект от внедрения Service Desk в компаниях с низкой зрелостью, несомненно, даст серьезный эффект (например, позволит исключить потерю заявок, сократить просрочку SLA и т.д.). Но успешное завершение проекта с понятными и измеримыми результатами, которое и дальше можно развивать, в общем случае вряд ли возможно без изменения организационной составляющей.

    «Натянем» на наши требования


    Эта проблема характерна для более крупного и бюрократизированного бизнеса.
    Как правило, процессы в таких компаниях развиваются в течение длительного времени, складывается какая-то схема управления. Поверх этой системы существует “лоскутная” автоматизация — Service Desk в каких-то конкретных направлениях, разные CRM в разных департаментах и т.д. Но бизнес хочет получить единую централизованную и автоматизированную систему, увязав все процессы друг с другом. Ошибка в том, что при этом он не хочет подстраиваться под существующие системы и лучшие практики, в соответствии с которыми они разрабатываются, пытаясь «натянуть» выбранный продукт на свои требования. А сделать это крайне сложно.

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

    Внедрить Service Desk. Боязнь изменений


    image

    «Наши клиенты так не привыкли»


    Сервисные компании действительно считают примерно следующим образом:
    “Это не заработает, потому что наши клиенты так не привыкли”.

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

    «Потребуется реорганизация»


    Эта проблема в бОльшей степени связана с внедрением именно service desk систем из-за сравнительной сложности процессов поддержки. Отказ от проектов связан с боязнью реорганизации. Но зачастую такие изменения идут на пользу бизнесу. В их основу могут лечь «передовые практики и библиотеки», в которых они агрегированы — ITIL, или подход к организации сервисного управления ITSM, но малому и среднему бизнесу от использования этих «лучших» практик, конечно, отказаться.
    Отличный пример — сервисная компания, где обслуживанием занимается уже не 2-3, а 10 и более человек. При таких масштабах, во-первых, уже имеется большой поток заявок, во-вторых, есть четкая градация людей и по компетенциям, и по оплате. Реорганизация службы поддержки подразумевает выделение первых, вторых, третьих линий, изменение взаимодействия с подрядчиками и много всего прочего.
    Не учитывая реорганизацию, компании либо боятся запускать проекты внедрения service desk систем, либо внедряют их, но не получают требуемого результата (автоматизируют хаос).

    «Реальные временные затраты вырастут»


    Компании откладывают внедрение инструментов, когда понимают, что реальные временные затраты сотрудников при работе с новой service desk системой вырастают. И это чистая правда!
    Времени, на первых порах, действительно придется тратить больше. Например, придется регистрировать 100% заявок, отмечать выполненные действия при их обработке, списывать трудозатраты и т.п. Но точки неэффективности не выявить без фиксации активностей и отслеживания метрик по ним. А потому перед стартом проекта нужно просто ответить себе на вопрос «Чего мы хотим по итогам внедрения service desk?»

    Панибратство: «Коллеги будут недовольны»


    В российском бизнесе очень распространены «панибратские» отношения. И чем более “домашней” является компания, тем больше это вызывает сложностей. Особенно ярко это проявляется в компаниях на периферии — в бизнесе на 10 — 20 человек, которые давно работают вместе.

    Панибратство порождает сложные моральные вопросы, когда требуются изменения или увольнения тех, кто работает плохо. Часто в таких ситуациях проект приостанавливается, а новый инструмент не используется, потому что внутри компании возникает недовольство или вопрос без ответа: «Как же так?»

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

    Организационные ошибки и сложности при внедрении Service Desk


    image

    Внутреннее сопротивление


    Сотрудники компаний не любят изменений сложившегося уклада. Например, сидел диспетчер и в журнале ручкой по-старинке записывал все обращения от жителей дома о неработоспособности лифта, спокойно пил чай. А тут его заставляют что-то фиксировать в непонятной системе. Естественно, он сопротивляется.

    Проблема в том числе бывает связана с возрастом. Чем старше коллектив, тем он сложнее в части принятия нового, изменения форматов работы.

    Нет реальной заинтересованности руководства / ЛПРов (лиц, принимающих решения)


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

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

    Отсутствие или проблемы с проектным подходом


    image

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


    Когда компании не выделяют людей, отвечающих за результат внедрения сервис деск системы, ничего не получается.

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

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

    Нет выделенного времени у тех, на кого это повлияет


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

    Нет реальных требований и сценариев использования (scope проекта)


    Такие проблемы часто встречаются и на западе: на старте нет четких требований ни к системе service desk, ни к результатам проекта. Это приводит, в том числе, к бесконечному процессу выбора решений. У таких заказчиков есть желание автоматизировать абсолютно всё — натянуть систему на свои требования (об этом — выше), либо предъявляемые к системе требования постоянно изменяются.

    В конечном счете проекты забрасывают, не начав: тестируют 20 систем по несколько раз и осознают, что ни одна не подходит. Еще хуже, если проект был запущен, определены какие-то бюджетные и временные рамки, а потом требования «расползаются», что приводит к значительному срыву срок и серьезно «раздутых» внутренних затрат. На определенном этапе становится проще его забросить.

    Нет «воздействия» (Check — Act)


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

    Любой проект напоминает «спираль». Есть так называемый цикл Деминга — Plan -> Do -> Check -> Act. Если говорить про Service Desk, то одна из типовых задач внедрения такой системы — сокращение просрочки по SLA. Но после начала работы многие компании в принципе не пользуются отчетами. А часть тех, кто все-таки пользуется, не планирует последующие изменения в своих процессах, позволяющие добиться как-то лучших показателей. Без этого итоговой удовлетворенности от проекта не получить.

    Сказка про «качественно/быстро/бесплатно»


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

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

    Внедрение Service Desk. Как избежать ошибок?


    image

    Вот несколько универсальных рекомендаций, которые позволят Вам сэкономить время на этапе запуска проекта и внедрения Service Desk системы:

    • В компании должен быть «драйвер» проекта внедрения системы. При этом у него должны быть полномочия для принятия решений, в том числе, непопулярных, и об этих полномочиях должно быть известно всем участникам проекта и тем, на кого повлияет система по итогам запуска.
    • Необходимо определить цели и зафиксировать требования (к системе, проекту, результатам). Прежде чем начинать поиск service desk системы, необходимо определить цели, потому что в их отсутствии эта эпопея может ничем не закончиться.
    • Следует выделить бюджет / время / команду. Все эти ресурсы, очевидно, зависят от требований. Не должно быть иллюзий: желание натянуть систему на индивидуальные требования приведет к большим затратам (костюм на заказ — всегда дороже). Scope проекта также определяет время, которое нужно выделять со стороны драйверов и участников проекта, а также у всех людей, на кого повлияет использование системы.
    • Не нужно бояться изменений и «нового». Изменения можно тестировать на части клиентов или пользователей, например, на нескольких заказчиках. Да, придется тратить больше времени, реорганизовывать структуру, особенно после выявления очагов неэффективности. Это сложно и иногда больно, тем более с учетом панибратства. Но это нужно, если ставить во главу угла эффективность организации и бизнес сам по себе.
    • Настойчиво преодолевать сопротивление – правильно «продавать». Сервис деск системы предназначены не только для контроля работы, но и для выстраивания прозрачных отношений с клиентами. Сотрудники, даже возрастные, понимают эту и другую разумную аргументацию.
    • Сфокусируйтесь на основном бизнесе. Когда компании решают за полгода-год изобрести свой собственный велосипед — разработать CRM, Helpdesk и т.п. — это почти всегда заканчивается провалом. Но главное — это показатель того, насколько ваш бизнес на текущий момент работает неэффективно.
    • Перестать верить в сказки про “бесплатное, дешевое, качественное”. Само не “полетит”. Основная проблема внедрения всех систем — это как раз организационные сложности и изменения, которые придется проводить, иначе система хоть и принесет результат, но он будет не совсем тот, который можно было бы получить.

    Заметка опубликована на основании материала из блога Okdesk
    Okdesk
    Облачная Help Desk система для сервисных компаний
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 8

      0
      Сфокусируйтесь на основном бизнесе. Когда компании решают за полгода-год изобрести свой собственный велосипед — разработать CRM, Helpdesk и т.п. — это почти всегда заканчивается провалом. Но главное — это показатель того, насколько ваш бизнес на текущий момент работает неэффективно.
      Парни, вы точно хорошо шарите в бизнесе? Во-первых, вы ставите на один уровень CRM и хелпдеск, это две большие разницы. Во-вторых, а хрен ли мне не разработать, если МЕНЯ и МОИ ТРЕБОВАНИЯ это устраивает? В-третьих, чего это неэффективно? У меня аутсорсинговый бизнес, у меня есть пара мешков свободных денег на разработку «под меня», я нанимаю команду, она пилит мне нужное МНЕ ПО. Я работаю в своём бизнесе, ребята на меня работают. И я становлюсь — внимание — ещё эффективнее. Инвестирование, развитие, расширение, масштабирование, диверсификация — нет, не слышали? Эхххх, молодёжжжь!
        0
        Полагаю, речь шла в общем, хотя знаю конкретную компанию, разработчика аутсорсера, которая напилила свое решение под ITSM процессы и отказалась в пользу покупного, в конечном итоге, оказалось так дешевле.
        Опыт бывает разным.
          0
          Смотря в чем вы измеряете «шарить в бизнесе» :)
          1. Конечно, когда мы ставили запятую между CRM, Help Desk и т.п. мы имели в виду любой класс систем «внутри» которого десятки и даже сотни вариантов почти на любой «вкус» и кошелек.
          2 и 3. Это вопрос про TCO и конкретные цифры. Если у вас есть свободные (странное слово для «эффективной» компании) ресурсы (пара мешков) в виде людей, денег и времени на:
          — систематизацию и разработку требований;
          — перевод требований с языка бизнес потребностей на язык, понятный программистам
          — разработку решения на базе требований (нужно учесть, что потребуются люди разных компетенций, например, на разработку Back части, мобильных интерфейсов и т.д.)
          — тестирования того, что разработали
          — поддержания, администрирования и развития того, что разработали
          — и это не считая «инфраструктуры», «лицензирования» и т.д.
          То, конечно, можно и самостоятельно разработать, и отдать на аутсорс, и делать, что хочется.
          Собственно про этот «велосипед» и речь. С другой стороны: хозяин — барин :)
            0
            Смотря в чем вы измеряете «шарить в бизнесе» :)
            В литрах там, километрах… ;-)

            Я вас услышал. Спасибо.
          0
          Хелпдеск и CRM могут вполне жить в содружестве. Главное — понять цели и как разграничить функционал. Есть статья на эту тему, в которой рассматриваются решения ZEDLine Support (облачный хелпдеск) и RegionSoft CRM (десктопная CRM со встроенным ServiceDesk'ом). Обсуждаются как различия, так и возможность их одновременной работы в режиме интеграции. Ссылочка на статью на хабре. Рекомендую.
            0
            Последний комментарий и ссылка на статью уж слишком явная реклама, а обилие скриншотов, скорее намекает на «пользу» контента. Тем не менее она написана на основании нашей старой статьи habr.com/ru/company/okdesk/blog/343976, о чем коллеги забыли написать, поэтому пусть будет
              0
              У компании RegionSoft 100 статей в блоге. И касательно CRM, и касательно хелпдесков, об IT отрасли в целом, масса аналитики и опросов. Вы реально считаете, что им требуется перепечатывать ваши статьи? Мне вот, например, не понравилось, что в их корпоративном блоге в комментариях к их нескольким последним статьям я увидел от ваших сотрудников ссылки на ваши материалы и необоснованные намеки. Пиар за счет конкурентов — это нехорошо. Вероятно, вы распознали серьезного конкурента и решили попакостить в их блоге. У каждого свои методы продвижения. Это ваш выбор. Я бы с компанией, выбравшей такой тип пиара, сотрудничать не стал, поскольку моральная составляющая контрагента, которому я должен платить деньги, для меня лично играет немаловажную роль.
                0
                То есть вам что-то не понравилось и поэтому вы решили поступить также? Хм…

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

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

                2. Вы подозрительно много комментируете статьи RegionSoft относительно других материалов. Я, честно, очень хочу верить, что это просто интерес к компании и никакого прямого отношения вы к ней не имеете. И если это так, я очень прошу не называть решение коллег, по крайней мере в текущем виде, конкурентом Okdesk. Не потому, что это смешно и не потому, что оно таким не является от слова «совсем», а потому что если это повторять в каждом комментарии (что почему-то делают и коллеги), то доверие к вашей личной «независимой» оценке у людей объективных, анализирующих и понимающих рынок, серьезно обесценивается.

                3. Вы совершенно правы по поводу продвижения. Названные Вами коллеги ведут себя, мягко говоря, не очень красиво в рамках «аналитических» статей с рассмотрением «более 20 решений», оперируя бездоказательными фактами и, главное, очень субъективными доводами вида «медленно работает», «перегружен интерфейс» и т.д. Так продвигались в начале нулевых. После указания на некорректность, обещают прислать доказательства в личные сообщения и, конечно, этого не делают. У взрослых такой подход называется манипуляцией и «некачественным PR». Хотя Хабр «стерпит».

                4. И тут с Вами согласен. Каждый выбирает себе «партнёра», «поставщика», «решение» по целому ряду факторов. Кто-то по количеству статей или карме, кто-то по подтвержденной результатами экспертизе и компетенциям, отзывам из отрасли, кто-то просто потому что «подход» и поведение в «инфополе» импонирует. Хорошо, что на рынке ПО в нашей стране проблемы этого самого выбора нет, а значит каждый найдет то, что ищет.

                Удачи Вам, вне зависимости от выбора, в любых активностях. Время всё расставляет по местам.

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

            Самое читаемое