Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: есть ли плюсы в портале самообслуживания?

Опубликовано 17 сентября 2012
Рубрики: Service Desk, SLA, SLM, BRM, Вопрос из зала, Практика и опыт
Комментарии

СамообслуживаниеАнна Лобова, IT Manager и постоянный читатель нашего портала, а также регулярный участник ITSM-вебинаров, задаёт вопрос в виде развёрнутого кейса. Анна просит наше сообщество помочь ей и раскритиковать кейс в пух и прах. Давайте поможем.

 

Не секрет, что без каталога услуг, SLA, базы знаний, системы регистрации и учета запросов сотрудникам ИТ живется нелегко: пользователи просят все что хотят и прямо сейчас. Очевидность необходимости всех этих и других «айтиловских примочек» объяснять в очередной раз не стану.

Но как предоставить пользователям эти данные в удобном формате и более того: как собрать их вместе и залинковать между собой таким образом, чтобы не приходилось ломать голову в лабиринтах завязанных между собой данных? Бесконечные таблицы и справочники будут непонятны и неудобны для «вечно спешащих» пользователей. Но все же разметка границ «вот это мы делаем, а вот это не к нам» очень сильная защита ИТ отдела или как минимум возможность выгадать время на перенос той самой «границы» в случае если пользователь запросит услугу из раздела «out of service».

В нашей компании мы столкнулись с ситуацией «чистого поля», когда нет ни регламентирующих ИТ работу документов, ни регистрации ИТ запросов. С одной стороны создавай что душе угодно, а с другой – все что создаешь должно быть простым и понятным пользователям, еще не привыкшим к ИТ процедурам и сервисному подходу в целом. Поэтому первым делом я озадачилась изучением специализированного ПО для регистрации и учета ИТ запросов и, дойдя до Microsoft System Center Service Manager, натолкнулась на такой вот ролик. Видео настолько меня вдохновило, что я попробовала, до закупки ITSM системы, имея только MS SharePoint, реализовать и учет ИТ запросов и Портал самообслуживания (куда выложить и каталог сервисов и SLA и все что необходимо пользователю, чтобы самостоятельно справиться с возникшими вопросами).

Для выполнения поставленной задачи и чтобы не создавать множество документов я решила поступить следующим образом:

  1. Составила таблицу, в ней прописала сервисы (это Каталог Сервисов). В ней же указала формат поддержки и время на исполнение инцидентов и RFC (это SLA)
  2. Создала вики-сайт в SharePoint, выложила наши сервисы
  3. Для каждого сервиса создала свою страничку, где разместила всю информацию по сервису (детальное описание, составляющие, корпоративный стандарт, необходимо ли согласование для получения сервиса, режим поддержки, время на восстановление и изменение сервиса)
  4. Указала на страничке ссылку на заказ сервиса (запрос на изменение), ссылку на сигнал бедствия в случае проблем в работе сервиса (инцидент), ссылку на статьи об этом сервисе в базе знаний
  5. Опубликовала контакты первой линии поддержки
  6. Сейчас, пока у нас нет никакого ПО для регистрации и учета ИТ запросов (в настоящее время регистрация реализована средствами простейшего списка SharePoint с настроенными уведомлениями исполнителю и обратившемуся), ссылки «Заказать этот сервис» и «Проблемы с этим сервисом» всего лишь представляют собой mailto:help@company.domain, однако в скором времени мы залинкуем их в предзаполненные формы запросов в ITSM системе (будут заполнены атрибуты «тип сервиса» и «тип запроса»: инцидент, RFC…), и специалистам 1 линии не придется тратить время на создание и маршрутизацию большого количества запросов (согласитесь – очень существенный бенефит).

Резюмирую и закругляюсь: создание портала самообслуживания упрощает пользователям доступ к необходимой информации, позволяет в простом виде вызвать форму создания нового ИТ запроса с уже предзаполненными полями не открывая ИТ консоль, позволяет предоставить такие сложные документы как Каталог сервисов и SLA (и другие) в user-friendly виде, в конечном счете разгружает специалистов первой линии поддержки (и не только их), а также дает возможность пользователю открыть раздел Базы Знаний уже выбранного сервиса.

Список ИТ Сервисов:

Индивидуальная страница Сервиса:

Как видите, конечный пользователь не увидит таблиц Каталога Сервисов и SLA, ему не нужно будет открывать консоль ITSM системы, он зайдет на портал, почитает про сервис, посмотрит Базу Знаний, закажет его или пожалуется на него, увидит контакты поддержки и режим поддержки каждого сервиса, а также его доступность. Все просто, удобно, приятно.

Вопросы к обсуждению:

  1. Как вы считаете, удобно ли такое внедрение Базы Знаний внутрь портала самообслуживания?
  2. Будет ли пользователям удобно заказывать сервис через портал самообслуживания, нежели через консоль регистрации и учета ИТ запросов?
  3. Есть ли какие дополнения \ замечания к списку сервисов и разделам описания сервиса?
ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

Также по теме:

Комментариев: 29

  • Роман Журавлёв

    По вопросам, сформулированным в конце кейса, мои ответы таковы:

    1. да, конечно. При соблюдении двух условий: пользователи используют портал; база содержит полезные знания. В описанной ситуации и для того, и для другого есть все предпосылки, как я понял.
    2. Пользователи предпочитают работать с, во-первых, привычным, а во-вторых – удобным интерфейсом. Причем именно в таком порядке. Так что в случае, если они примут портал, и он станет привычным, они почти наверняка предпочтут его любому новому интерфейсу. Но пока портал просто перебрасывает их в старую добрую электронную почту, а если у сотрудников компании есть возможность работать с порталом с личных устройств, то, возможно, и не перебрасывает (некорректная реакция на mailto). В этих условиях портал проигрывает почтовому клиенту и по привычности, и по удобству.
    3. В контексте кейса у меня дополнений-корректировок нет. Если портал корректно отражает согласованные правила-договоренности-документы, значит, хорошие список и описание. Уточнения могут быть к самим правилам-договоренностям, но вопрос ведь не об этом.

    Вопрос же,вынесенные в заголовок, гораздо сложнее. Я убежден, что портал самообслуживания полезен далеко не во всякой организации. Грубо говоря, чем выше квалификация пользователей, тем больше пользы от хорошего портала. Чем ниже квалификация пользователей, тем ниже вероятность получения пользы от любых форм самообслуживания. Я видел много зарегистрированных пользователями инцидентов, которые по сути были запросами на обратный звонок для выяснения того, что же автор имел в виду. Иногда гораздо полезнее и рациональнее нанять еще одного оператора на телефон, чем развивать и поддерживать систему самообслуживания. Но это, мне кажется, уже совсем другая история; вопрос Анны не об этом.

  • Anna Lobova

    Роман, спасибо. Именно так, сейчас мы в стадии “приучения” пользователей к порталу (выпустили его только месяц назад), далее будем смотреть насколько всем привычно и удобно. Спасибо за комент!

  • Dmitry Melnikov

    Добрый день!

    Игрушка должна быть интересна для игры… Тогда в нее будут играть.

    По вопросам:
    1. Пользователь должен “созреть” для работы с базой знаний. Ваши готовы? А может им до сих пор удобнее позвонить живому человеку и задать свой вопрос по телефону?
    2. Согласен с Романом – по своему опыту перевод пользователей на новый интерфейс – занятие пожароопасное. Необходима качественная реклама от ИТ-подразделения этого новшества в личном общении с пользователями (вплоть до организации встреч в подразделениях организации и выступлений ИТ-специалистов). Еще важно, где именно внедряется система. Допустим в рознице, в связи с особенностями бизнеса в магазинах, гораздо эффективнее использовать CALL-центр.
    3. Дополнения/замечания здесь уместны от Ваших сорудников, которые этим пользуются. Документы должны работать, а не просто “быть” для галочки.

    • Anna Lobova

      Спасибо за критику, Дмитрий. Со всем согласна.

  • Вадим

    1. База знаний, безусловно, полезна. Но, думаю, используемость её пользователями – вещь сомнительная. Поясню свою логику на следующем примере. Если у пользователя возникает какая-либо проблема (которую потенциально можно решить самостоятельно, в т.ч. с помощью портала), то это совершенно не означает, что он будет ее решать сам. Я бы сказал, что это вопрос психологического свойства: кому-то интересно копаться в компьютерных/программных примочках, а кому-то нет. Для пользователя, занятого кучей собственных дел, не включающих интереснейший серфинг по ссылкам портала, самостоятельно заниматься решением своей маленькой проблемки может быть просто неинтересно. А ведь еще есть такой фактор, как “неположено по должности”. Так что пользователь скорее обратится в сервисдеск по телефону или даже электронной почте и будет ожидать устранения неисправности с помощью ИТишников (которым за это, между прочим, деньги платят), вместо портала путешествуя по интернету.

    От себя могу порекомендовать разместить на портале перечень типовых проблем по вашему перечню услуг, чтобы простые вопросы, типа подключения принтера и т.п., были снабжены четкой и простой инструкцией (условно говоря, “пара кликов”), которую способен выполнить любой пользователь в вашей организации (здесь, правда, были бы полезны знания о квалификации пользователей, но это сама по себе интересная и может быть даже обширная тема)
    Также можно было бы дополнить форму заполнения заявки подсказкой типа “А знаете ли Вы как?”, где можно давать ссылку на ту же самую инструкцию по решению типовых проблем. Разумеется, подсказки лучше показывать не просто случайным образом, а с учетом информации сервисдеска о полученных обращениях.

    2. Тут однозначного ответа быть не может, кому-то будет удобно, кому-то нет. Пользователи – они люди, да к тому же разные. И многое к тому же зависит от принятой в организации культуры использования ИТ (как ИТ средств, так и ИТ персонала), а также масштаба организации.
    Возможно, если бы пользователь видел не только и не столько перечень всех сервисов, а только “своих” + перечень разрешенных именно ему, и оставалось бы только нажать кнопку “Подключиться” (= заказать), и ему за это ничего не было бы, а только польза в решении каких-то своих повседневных задач (и даже пояснено каких). Тут соблазн получить в пользование что-то полезно вырос бы многократно. Но что-то я размечтался…

    3. нет

    P.S. Портал, кстати, мне понравился ))) Чем-то напоминает панель управления в Windows

    • Вадим

      хотя нет, по 3-му пункту есть пару слов, правда конкретно по ноутбукам
      вы ведь их выдаете, обслуживаете, настраиваете, ремонтируете (либо отвозите в ремонт), заменяете

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

      аналогичное замечание по “времени на изменение сервиса”? непонятно, что “изменяется в сервисе”? или имеется в виду время на замену ноутбука?
      в этом случае я бы еще сделал приписку о том, включает ли замена сохранение/перенос данных пользователя на новый компьютер, если это актуально, конечно.

      P.S. кстати, у вас на страничке (в меню, в заголовке) написано “ноТУбуки”, это специально так?

      • Вадим

        пардон
        следует читать “мне казалось, что времена на эти операции требуются разные“

      • Anna Lobova

        Вадим, спасибо, что нашли ошибку, исправлю!
        “Время восстановления сервиса” – время за которое будет устранен сбой (incident)
        “Время изменения сервиса” – время на внесение изменений в сервис (RFC)

        • Вадим

          ваши “восстановление/изменение” скорее всего ничего не говорят пользователям в терминах того, что они могут/должны получать.
          вот у вас сервис называется “ноутбуки” и в чем мог бы заключаться инцидент? клавиша на клавиатуре западает?
          по изменениям отдельная песня – что вносится в смысле изменений в сервис? одну клавиатуру на другую поменять, или диск, блок питания и т.п.?

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

          • Anna Lobova

            Да, наверное лучше переименовать.
            “время восстановления” -> “время устранения сбоев”
            “время изменения” -> ?что предложите?

            • Вадим

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

              да и со сбоями не все понятно. у вас ведь разделяются ноутбуки и системное и прикладное ПО? что есть сбой по отношению сервису “ноутбуки”

              • Anna Lobova

                Разделено, чтобы можно было отдельно заказать.

  • Anna Lobova

    Вадим, спасибо за 2-й пункт, это Вы хорошо придумали! Было бы круто. Причем некоторые базовые сервисы должны быть априори включены в перечень “своих”.

    • Вадим

      Анна, это не придумка – это жизнь ))) куда-то туда же можно было бы поместить кнопку “Проблемы с сервисом”, а уже “внутри” нее “известные/типовые” проблемы и “что-то новенькое” (т.е. нетиповое)

  • Pavel Solopov

    А вы под Базой знаний что понимаете? Только описание сервиса или также и описания всяких “известных ошибок” и способов их решения? На скриншоте увидел только описание.

    В остальном, не могу быть экспертом, выскажу только своё личное ощущение.
    Группировка сервисов вызывает вопросы, не факт. что может быть однозначно понята с первого раза. Если весь список помещается на одной странице, как у вас, то в принципе нормально, но если надо будет раскрывать группы, чтобы проверить нет ли там нужного сервиса, то меня, как пользователя это начало бы раздражать, особенно если бы сервисы не находились в той группе, в которую я их хочу отнести.
    Поэтому хорошо бы сделать поиск по ключевым словам, но с подбором ключевых слов надо тщательно поработать, а то результаты поиска, которые выдают не то, что ищешь раздражают ещё больше.
    Аналогичный вопрос с восприятием описания сервисов. У меня вот, например, вызвал вопрос пункт “изменение сервиса” – что это? не знаю как вашим пользователям, возможно им понятно.

    Вообще лучше было бы вам ен у нас спрашивать, а у них. 🙂 Это было бы результативней, пожалуй.

    • Anna Lobova

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

  • Alexey Krutikov

    По первому вопросу: А кому должно быть удобно? 50-летней бухгалтерше? Да ей уже и номер бы сервис-деска запомнить (хотя практика показывает, что запоминает и, к сожалению, только его).
    Возможные проблемы:
    От ИТ (под БЗ я понимаю набор публикаций по решению различных проблем):
    “мы же вам создали базу знаний – смотрите там!!!”
    и не факт, что эта фраза будет произноситься к месту. К примеру, пользователю не интересно как добавить новый принтер, он не хочет забивать себе голову этой ерундой. 100% будут звонки, которые нужно обработать (занести в базу запросов, поставить в очередь +30 минут). А если сам сделал, те через портал, то -15 минут к сроку окончания. И ни дай бог рассказать вам об этом пользователям!! Они сами увидят, что почему-то те запросы, что приходят через портал, выполняются быстрее…
    Все запросы, даже через телефон, должны регистрироваться (письмом: ответственному (да хоть себе) и тому, кто звонил)

    От слишком умных пользователей:
    “А я использовал вашу инструкцию, и у меня теперь ничего не работает” (фигня, что пару пунктов пропущено было).
    Результат – пользователь потратил час своего времени для настройки чего-то, +10 минут админа, пока он откатился и +2 минуты пока админ сделал все заново, но время работник потратил. ))
    Все утрировано, но… Все должны заниматься своим делом.
    Дело в том, что бухгалтерия вела, ведет, будет вести свою БЗ на бумаге или “где-то у себя под рукой” и дЕла ей до вашей ИТ БЗ нет.
    2. Если будет меньше 3-х переходов (на третьем окне нужно закончить оформление заказа), то есть шанс успешного внедрения. Оптимально все умещать на один экран (а бухгалтера слЯпые, им 20 шрифт подавай…).
    3. Кстати, что нет туалетной бумаги (шутка), тоже можно сюда вставить и сразу на АХО, впрочем, как и замена лампочки )). Это может увеличить используемость и полезность портала.
    Нужно приучить их к тому, что это есть. Список должны составлять ваши пользователи и это вопрос не одного опросника и не одной недели, если не месяца. И ситуация “out of service” решается не всегда в вашу пользу, так что готовьтесь к вопросам “А кто за это отвечает” – и ответ “не мы” очень плохой – вам нужно знать “правильный” ответ )), к примеру “АХО”! ))
    А на самом деле, это полезное начинание, только нужно не переборщить, те не загромоздить портал.

    • Anna Lobova

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

  • Альберт

    По п. 1,2 ответ удобно, при условии, что вы приучите пользователей к этому порталу и не будете его кардинально менять каждый месяц.
    По п. 3. Если речь идет именно о портале самообслуживания я бы разделил его как минимум на 3 части
    1. Заказ сервисов (запросом на изменение лучше его не называть) из каталога, убрав оттуда:
    а. Сервисы не касающиеся напрямую пользователей,
    б. Сервисы предоставляемые как неотъемлемая часть другого сервиса. Например: заказ компьютера подразумевает установку на него операционной системы и стандартного программного обеспечения, т.е. стандартное ПО и ОС убираем из каталога.
    в. Ссылку на сигнал бедствия в случае проблем в работе сервиса.
    При этом обязательно должна быть элементарная функция согласования заказанного сервиса удобная для всех.
    2. Раздел регистрации инцидентов, где указать всевозможные способы связи с техподдержкой (форма обратной связи на портале, телефоны, mailto и т.д.).
    3. Раздел поиска по базе знаний. Просто обычный поиск, если уж сервисов совсем много, можно разбить на поиск по категориям. Не стоит заставлять пользователя бродить по каталогу в поисках ответа. Пусть за него это делает поисковик. Сюда-же ссылки на FAQ и обучающие материалы.

    Оцените это в зависимости от количества пользователей и количества предоставляемых им сервисов.
    Насколько я понимаю, вы хотите сэкономить время. Посчитайте, (например в FTE Full-time equivalent), какой выигрыш по времени вам даст этот портал и сколько вы потеряете при переходе на более серьезную систему?

    • Anna Lobova

      Альберт, спасибо за критику и советы! Да, База Знаний имеет свою центральную точку входа, где можно не затрагивая каталог сервисов найти интересующий раздел или поискать по глоссарию. С системой согласования пока туго, к сожалению у меня видимо нет должного уровня знаний, чтобы к вики-страницам приделать форму согласования, которая бы в АД смотрела кто у кого руководитель. Особенно туго при матричной системе руководства. Но мы пока этим не заморочились)

  • Андрей В.

    Хотелось бы поделиться своим опытом в реализации определенной части портала самообслуживания пользователей.
    Речь идет именно о 100% самообслуживании пользователей без какого либо привлечения специалистов 1/2.. уровней поддержки,
    например, установка ПО на рабочий компьютер сотрудника.

    В нашем случае имеется подобное приведенному выше представление (визуально также похожее на панель управления windows 🙂 на базе MS SharePoint, называемое “Каталог продуктов”.
    Пользователь выбирает необходимый ему софт из доступного (опубликованного ПО), далее в информационной системе Service Desk (OMNITRACKER) автоматически создается Запрос на обслуживание, назначается на автоматического исполнителя (робота).
    В системе управления ПО (MS SCCM) создается задание на ПК пользователя, выполняется удаленная установка выбранного ПО.
    По окончании установки Запрос на обслуживание автоматически закрывается.

    Было бы неплохо узнать как сделано подобное в других местах 🙂

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

    • Anna Lobova

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

      • Андрей В.

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

        Есть следующая “полуавтоматическая” автоматизация согласования, при переводе Service Request в статус Approval Needed система Service Desk сама вычисляет начальника пользователя и отправляет ему соответствующую нотификацию “мол вот, подтверди что твои люди просят”. Начальник отвечает, и его ответ прикрепляется к обращению, и статус обращения возвращается в предыдущий.

        • Anna Lobova

          ..а можете показать скриншот на Ваш “Каталог продуктов”? Интересно!

        • Кирилл Федулов

          Андрей, отличный кейс. Я правильно понимаю, что Вы в MS SCCM передаете имя компьютера? У нас очень похожий кейс реализован в рамках одного проекта.
          Плюсуюсь к скриншоту “Каталога”!

          • Андрей В.

            Кирилл,
            да, так и есть.

            Расскажете про себя? 🙂

    • Кирилл Федулов

      Анна, на многие вопросы Вам уже ответили, поэтому я просто дополню свое видение того, что может быть еще в портале самообслуживания:
      1. Набор предоставляемых услуг и параметров их предоставления (пользователь должен знать, чем он пользуется и по каким правилам)
      2. Общий список услуг, которые ИТ / Компания может предоставлять данной категории пользователя (категория может определяться согласно штатной структуре, должности или быть субъективным параметром на уровне системы автоматизации) с возможностью заказа этой услуги
      3. Персонализированные новости, в соответствии со всей той же категорией пользователя, либо, правильнее, набором его услуг (бегущая ли это строка или просто блок – вопрос реализации)
      4. Возможность участия в процессе обработки запроса (переписка по почте, добавление комментариев, файлов, выставление оценки при подтверждении выполнения)
      5. Согласования пользователя (аналогичный списку запросов)
      6. Общие или категоризованные опросы.
      7. Доска почета сотрудников службы поддержки или доступ к общей информации о коллегах из ИТ (ФИО, фото с улыбкой и т.д.)

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

  • Владимир У.

    Большую часть, конечно же уже разжевали, но вставлю и свои 5 копеек:
    – Чем глубже структура, тем меньше охоты по ней лазить (как правило дальше двух кликов – народу уже влом)
    – Ссылки на самые часто используемые вещи можно вынести на главную.
    – Поиск тоже надо делать с умом, к примеру, если не работает Офис, а поиск мне в первую очередь выдает описание его, да и издевательски так – хотите себе? – впечатление уже будет портиться.
    – Отпинывать в базу насильно нельзя ни в коем случае, можно заметить позже, что с ее помощью пользователь может решить аналогичную ситуацию быстрее и проще (а если нет, то он в нее и не пойдет), то есть мотивировать его.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.