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

ITSM и SaaS: ближе, чем принято думать

В обсуждении заметки о принципах Service Desk 2.0 мы, мне кажется, ушли довольно далеко от изначальной мысли автора, переметнувшись в сторону мирового зла Гугла вперемежку с общим недоверием к теме – как это пользователи будут знать об ИТ-услугах больше, чем ИТ-специалисты? Да кто же им даст самостоятельно комбинировать потребление нескольких услуг, чтобы обеспечивать свои бизнес-операции? Это где ж такое видано?

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

Как обычно нескромно проиллюстрирую на собственном примере.

В своей ежедневной работе я использую не так много приложений – полтора десятка, наверное. Сколько из них располагается в нашей "корпоративной ИТ-инфраструктуре"? Думаю, что два: наша внутренняя ERP-CRM-управленческо-учётная-система-планирования-ресурсов, да 1С, куда же без неё. Всё остальное – за пределами. Сдача отчётности в налоговую, ПФР и прочие структуры? Веб-приложение. Клиент-банк и все платежи-выписки? Веб-приложение. Проведение вебинаров? Веб-приложение. Списки рассылки, аналитика сайтов, контекстная реклама, поручения, задачи, управление продажами? Ну, вы поняли. Чего уж там, даже обычная электропочта хостится у провайдера, а не на своём оборудовании – зачем?

Ограничения приведённого примера очевидны – размер нашей компании весьма скромен. Было бы у нас 10 000 сотрудников – собственные корпоративные системы занимали бы более значительную долю. Но кто сказал, что ITSM – это только для больших?

Внимательный читатель может предположить, что "вес" систем разный – одно дело наша ERP, другое – обычный планировщик задач и выставляльщик поручений. Хочу заверить внимательного читателя – пару дней без, например, клиент-банка нам будет не менее сложно, чем без данных о наборе на следующий учебный курс по Service Desk. Так что и маленькие программки могут быть критичными.

Теперь предположим, что мы в нашей компании отошли от принципа "минимум балласта" и у нас появился специальный ИТ-человек. Выделенный, извините за оборот. Чем он может мне помочь с этими далёкими системами? Быть "прокладкой" между мной и той поддержкой – безусловно. Помочь разобраться с базовыми вещами – как данные из одной системы залить в другую? Наверное. Да и всё, пожалуй. Хороший Service Desk получается! Полезный! Будет ли он знать об используемых мною приложениях больше, чем я сам? Или же самый важный навык оператора первой линии будет производным от глагола "to google"?

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

Или я снова слишком категоричен? 🙂

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Анатолий Павлюченко

    Выделенный человек не нужен. Вы же знаете куда обращаться, если забился слив? 🙂

  • “Это не будущее, это настоящее, и имя ему давно известно — приложения за пределами корпоративной ИТ-инфраструктуры.”

    Я думаю, главный вопрос не в том, где расположены приложения (в или за пределами корпоративной ИТ-инфраструктуры), а за что отвечает ИТ-подразделение. Электронная почта хостится у провайдера? Не важно, если за обеспечение возможности её использования отвечает ИТ-подразделение. И так далее по списку. Решают не границы инфраструктуры, а границы ответственности (или, на языке ITIL, границы услуги).

    Если же за что-то ИТ-подразделение не отвечает (пользователи начали самостийно применять Google Docs), то хорошим тоном, на мой взгляд, является готовность помогать, хоть и без предоставления соответствующих гарантий. Это должна быть готовая, заученная, ясно декларируемая пользователям позиция: “Мы работаем для Вас и стараемся помочь, даже если формально не обязаны”.

    Почему без гарантий? Рискованно отвечать за то, чем ты не управляешь. Неразумно отвечать за результаты бурной творческой деятельности “сотен тысяч стартапов”. У любой ответственности есть границы. Поэтому будущее уже наступило в тех компаниях, в которых случилось маленькое чудо: ИТ-менеджеры, по своей инициативе осознали бизнес-ценность тех или иных внешних приложений, включили их поддержку в границы своей ответственности, донесли эту информацию и до потребителей, и до подчинённых и обеспечили уровень поддержки, удовлетворяющий пользователей.

    • Складно звонишь…

      Удивительно, но состояние “Не важно, если за обеспечение возможности её использования отвечает ИТ-подразделение. И так далее по списку. Решают не границы инфраструктуры, а границы ответственности (или, на языке ITIL, границы услуги).” – это ровно то, чего ТРЕБУЕТ наш любимый обновлённый ISO20000. То есть как бы не далёёёкая цель, а must have для всякого уважающего себя поставщика ИТ-услуг.

      Почему же тогда это звучит так утопично фантастически?

      • “Почему же тогда это звучит так утопично фантастически?”

        Давай уточним. Утопически фантастичным я нахожу только последний абзац – про регулярный анализ потребностей (в том числе с учётом SaaS-возможностей) и “добровольное” расширение границ ответственности ИТ-подразделения. Причём не просто декларативное (наружу “Мы готовы!”, своим – “Гуглите, если что”), а с организацией труда и контролем результатов. Но стандарт этого нигде не требует. Разве что очень косвенно – разделами 7.1 и 4.5.4. А поддержка ИТ-услуг с внешним хостингом – это, конечно, никакая не фантастика, а напротив – текущее состояние большинства известных мне компаний.

        Так что утопичны не требования стандарта (соблюдение формальных обязательств), а партнёрство с бизнесом и клиентоориентированность. Всё, как в твоей истории про good & best practice. Good practice есть не у всех и это фишка. Требования стандарта ISO 20000 – это, конечно, не best, а всего лишь good practice. И это есть у многих.

        • Ну я-то имел ввиду требования стандарта не к соблюдению формальных обязательств, а к руководящей роли сервис-провайдера в процессах подрядчиков… то есть раздел 4.2 Governance of processes operated by other parties

          Как-то мне не кажется, что это есть у многих.

          • А как ты себе на практике представляешь реализацию 4.2 по отношению, например, к тем же Google Docs (или тем более к сотне тысяч стартапов, речь-то в основном идёт именно о подобных услугах). Сформулируй, пжл.

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

            • Никак не представляю – потому и говорю, что “утопично фантастически”. Я уже как-то делился своими сомнениями по этому поводу – http://www.itsmportal.com/columns/dark-side-web-services-expansion.
              Я же не спорю с тобой. Я лишь говорю, что в условиях, когда пользователи все меньше нуждаются во внутреннем ИТ-подразделении (поскольку качество и доступность решений, предлагаемых бесплатно в интернете их устраивают), этому подразделению сложнее не только демонстрировать свою ценность, но и соответствовать требованиям стандарта. Потому что некоторые из этих требований становятся невыполнимы на практике.

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

                Тут надо внести одно важное уточнение. Правильно так: “этому подразделению сложнее демонстрировать свою ценность ИЛИ соответствовать требованиям стандарта”. Если это применяется, да, вопрос закрыт.

    • “Я думаю, главный вопрос не в том, где расположены приложения (в или за пределами корпоративной ИТ-инфраструктуры), а за что отвечает ИТ-подразделение.”

      Это очень связанные вопросы, т.к. важно не только где расположено приложение, но и откуда оно взялось и знает ли вообще о нём ИТ-подразделение. Чтобы использовать SaaS-систему нужен только браузер. Какой-нибудь маркетолог за 10 минут покупает (неважно как) подписку и начинает вовсю закачивать данные и использовать в ежедневной работе, да ещё и с коллегами . ИТ-отдел продолжает считать маркетологов балбесами, не достойными ничего, кроме Outlook, находясь в счастливом заблуждении.

      • Pavel Solopov

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

        В словах чувствуется неодобрение такого поведения ИТ-отдела. А какое поведение должно быть правильным по вашему мнению?

    • Pavel Solopov

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

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

  • Вадим

    Олег, у меня вопрос: если не секрет, сколько вы платите за освоение, настройку, использование, неработоспособность и т.п. этих маленьких программулек?
    (глагол “платить” в данном контексте используется не в смысле “платить денег”, а “тратить времени”)

    Также вопрос: какие риски в этом случае (если вдруг программулька не работает) возникают, как они отрабатываются?

    • Хорошие и правильные вопросы, Вадим.

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

      Думаю, что на борьбу с Windows Vista я за три года потратил больше времени, чем на освоение, настройку и решение проблем суммарно со всеми моими web-приложениями. Понимаю, что пример лукавый, зато из жизни 🙂

      Риски тоже аналогичны. Различаются мои действия в случае проблем – в те редкие случаи, когда не работает наша ERP/CRM, я обращаюсь к Дмитрию Исайченко. А когда не работает веб-приложение – я просто жду час, и оно в большинстве случаев заработает, так уж устроен этот сегмент рынка. Опять же, случаи каких-то больших сбоев я припомнить не могу ни со внутренним приложением, ни с “внешними”.

      • Вадим

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

        с **** однако, дело попроще обстоит. но ведь тоже есть риски?…

        • Вадим

          звездочки – это были веб …. и нары

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

            • “Наверное, в среднесрочной перспективе такая реакция клиентов приведет к тому, что на рынке останутся предложения приемлемого качества”

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

              На примере вэбинаров: крупных более-менее рабочих российских провайдеров всего два. Не сильно увлечёшься выбором…

              • Pavel Solopov

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

                • “Тут надо ещё понимать, что и спрос у нас меньше.”

                  Не соглашусь.
                  Пример – электронная SaaS-бухгалтерия “Эльба”, используют 150 000 организаций.

                  “Мое дело” тоже заявляют о 150 000 пользователей.

                  Итого 300 000 малых и средних предприятий (по информации от разработчиков) пользуются онлайн-бухгалтерией.

                  Понятно, что активных из них сильно меньше, однако масштаб – не единицы и не десятки.

                  • Вадим

                    300000 – капля в море

                    помню во времена начала расцвета (начало 90-х) фирма 1С заявляла о каком-то неимоверном росте количества пользователей. мой коллега не поленился посчитать, что по декларируемым тогдашним ценам на 1С:бухгалтерию вся прибыль от продаж (и наверное от поддержки тоже – не помню) элементарно не покрывала маркетинговых затрат. так что цифры – это надо проверять, или у нас джентльменам верят на слово?

                    • “300000 — капля в море”

                      Пересчёт в первом квартале 2011 года показал, что в России было зарегистрировано 230,9 тысячи малых предприятий. Из них, видимо, существенная часть – полуживые конторы, открытые не для бизнеса, а чтобы схемы какие-нибудь крутить. Но пересчёт вроде бы не учитывал средний бизнес, так что порядок – сходится.

                      “цифры — это надо проверять, или у нас джентльменам верят на слово?”

                      Конечно, надо. Конечно, не верят. Но зачем в данном случае проверять? Даже если они приврали в три раза, всё равно много пользователей получается.

                    • Вадим

                      есть такой анекдот (не очень приличный), но все же:
                      пришел мужик к врачу и грит:
                      – у меня проблемы с Этим
                      – какие проблемы?
                      – я могу только один-два раза за ночь и по две-три минуты, да и то не каждый день…
                      – а в чем проблема? ваши показатели вполне обычные
                      – но вот сосед рассказывает, что он может 5-6 раз по полчаса.
                      – так в чем проблема: и вы тоже рассказывайте…

      • Вадим

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

        (даже предположим, что естественное желание ИТишника получить четкое ТЗ на эту тему удалось быстро, т.е. без особых потерь, удовлетворить)

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

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

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

          • Вадим

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

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

            • “думаю, что редкий ИТишник, не решающий в повседневной работе подобных задач, справится с этой непростой задачей”

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

              Получается, что суммы с большим числом нулей им доверить можно, а вот $25/месяц – нельзя?

            • Про во-первых и во-вторых

              Вадим, а чём Вы видите здесь специфику web-решений на сторонних площадках?

              Требования бизнеса формируются до начала проекта и как правило не в терминах системы (кто это делает – три варианта, если хотите, обсудим). В зарубежной практике требования эти фиксируются в документе BRD. Далее ИТ-подразделение ищет оптимальный способ реализации – развитием существующих систем, внедрением новых продуктов, настройкой штатных возможностей и так далее. На этом анализе выполняется анализ альтернатив, выполняется первичная архитектурная проработка, даются предварительные оценки по срокам и ресурсам. На основании этих оценок проектный комитет принимает решение “go/no go”.

              Кто такой Ваш “ИТишник, не решающий в повседневной работе подобных задач”? Откуда он взялся?

              • Вадим

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

                P.S. ИТишник, о котором я писал, – эксплуатационщик, если угодно, эникейщик.

        • Могу ответить в стиле Анатолия (см.выше), но на примере: некоторое время назад я поручал нашему администратору подобрать нам контору, которая возьмётся катать наших сотрудников по г.Москве по безналичному расчёту, в просторечии – такси. Справилась наша администратор, без проблем, нашли и договор заключили.

          Чем маленькое интернет-приложение отличается?

          • Вадим

            да в общем-то ничем…
            есть бизнес задача, есть требования, ищущий да обрящет…
            вопрос в индивидуализированности ищущего. мы (т.е. вы) исходно говорите о SD2, когда пользователь по своим соображениям что-то для своей работы подбирает сам себе. или я уже что-то с чем-то спутал?

            по-моему, в этом случае ИТишник по своей инициативе не может (и/или не должен) захотеть найти подходящее такому пользователю без формулировки задачи (при поиске такси она-таки была :о))) да к тому же такси – это более бытовой уровень, понятный обычному человеку, нежели пусть даже некий планировщик (мало ли что и как вам в нем надо): “поручения, задачи, управление продажами”… ну вы поняли… :о)))

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

            ну а остальное уже в статье написано…

        • Pavel Solopov

          Если человек вменяемый, то справится. А если невменяемый, то не справится, даже если будет каждый день заниматься этой деятельностью.
          Но тут надо учитывать другой фактор. Все облачные приложения как правило предоставляют возможность демодоступа, всяких гайдов и тьюториалов. Т.е. их можно быстро посмотреть, пощупать, попробовать в деле. Поэтому выбрать приложение самому проще, чем просить кого-то (не важно будь это ИТ-ишник или нет). Как минимум не придётся тратить время на формулировку требований, да и есть некоторые требования, которые имеют некий интутитивно-эмоциональный характер и не подлежат формализации.
          Но тут надо отметить, что мы говорим о некоторых нишевых приложениях, которые нужны маркетологу, сейлу, финансисту, тренеру, консультанту и т.д.
          А вот если рассматривать некие комплексные системы, класса ERP или близкие к ним, тот тут уже всё не так просто. Такую систему одному человеку выбрать не получится, как минимум, ему придётся согласовать свой выбор со специалистами других направлений.
          Вы вот всё больше поминаете про то, кто будет поддерживать всякие облачные программки, которые сами юзеры будут выгугливать из тысяч стартапов. А мне кажется это не самая большая головная боль для ИТ-шников. Головная боль для них начнётся когда юзеры придут к ним с просьбой интегрировать эти программки между собой. Хотя возможно недалёк тот день, когда появится стандарт данных, который позволит пргорамкам без труда интегрироваться между собой и самим.
          Собственно такие стандарты уже существуют, вопрос в том получат ли они широкое распространение.
          Вот, кстати, у колеги можно в блоге на эту тему почитать: http://mxsmirnov.wordpress.com/

          • Вадим

            справится-справится (мы же невменяемых на работу не берем, не так ли?)
            с тезисом “не придется тратить время на формулировку требований” не согласен. поручИте кому-нибудь что-нибудь найти – и убедитесь!

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

            • Pavel Solopov

              Вадим, Вы не внимательно читаете.
              Я написал:
              Поэтому выбрать приложение самому проще, чем просить кого-то. Как минимум не придётся тратить время на формулировку требований.

              Или вы под поручИте кому-нибудь что-нибудь найти — и убедитесь!
              Имеете в виду что-то другое?

              • Вадим

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

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

                кстати, ведь бизнес пользователь обычно не сильно разбирается во всяких базах, структурах данных, типах связей и т.п. ИТишной фигне. в результате он ведь “не умом будет выбирать, а сердцем”, то бишь по картинкам (скриншотам)…

                P.S. а читать я вообще не умею))) чукча, панимаиш, писатель…

          • “Головная боль для них начнётся когда юзеры придут к ним с просьбой интегрировать эти программки между собой.”

            Трудно не согласиться. Для нас это пока не очень большая проблема, но передача данных, как правило, идёт через Excel, поэтому его приходится осваивать всё лучше и лучше.

            Вот и важное требование к Service Desk 2.0: хорошо знать Excel, уметь “вытаскивать” данные из выгрузки и преобразовывать в другой формат для загрузки в другое приложение.

            • Для сотрудников Service Desk (не важно какой версии) это очень сомнительное требование. Не только с точки зрения соответствия назначению (доступность контакта), но и с точки зрения полномочия в системах. Загрузка данных в любую систему – довольно серьёзная операция: по нагрузке на систему, по логике загрузки (при этом иногда приходится отключать часть системных проверок, некоторые правила бизнес-логики – это риски, это требует полномочий, знаний).
              Если только отдать Service Desk’у готовую процедуру – взял из этого формата, привёл к такому формату, нажал на такую-то кнопку. Но это не соответствует исходной постановке вопроса.

              • Если на первой линии сидят операторы, принимающие обращение и всё – согласен. Пусть выполняют только штатные, документированные и сто раз проверенные запросы.

                Но никто не отменял экспертный Service Desk.

                Мне почему-то кажется, что барышни, говорящие “алё, записываю!”, будут всё больше и больше оставаться в прошлом. Их вполне успешно заменяют веб-формы и email.

                • “Но никто не отменял экспертный Service Desk.”

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

              • Pavel Solopov

                Говоря про ИТ-шников я не имел в виду только Сервис деск, чем возможно и отклонился от темы. Но ведь поддержка не заканчивается не первой линии.

  • Я вот, немного подумав, пожалуй соглашусь с главным тезисом: “ITSM и SaaS ближе, чем принято думать”. Ведь по сути сервисные отношения, описанные в книгах ITIL (особенно ITIL v3) являются рыночными отношениями. А для развития рыночных отношений очень важна конкуренция. Именно она толкает повышать качество услуг, искать новые способы предоставления ценности заказчикам, считать и снижать себестоимость услуг, то есть делать всё то, что описано в основном в книгах SS и CSI.
    В ситуации внутреннего ИТ-подразделения, когда одновременно присутствуют признаки и монополии, и монопсонии, у сервисных отношений есть очень серьёзное препятствие – отсутствие конкуренции как между поставщиками, так и между потребителями. При этом целый ряд причин – и культурных, и технологических (обсуждали здесь: http://www.realitsm.ru/2011/11/why_does_business_need_sla/) – мешает бизнес- и ИТ- подразделениям воспринимать друг друга, как равноправных участников рыночных отношений. Именно поэтому процессный подход, как внутренний инструмент ИТ-руководителей, применяется гораздо чаще, чем сервисный.
    Бум SaaS такую конкуренцию будет постепенно стимулировать (прежде всего для небольших компаний) за счёт предоставления бизнес-подразделениям альтернатив в виде внешних поставщиков ИТ-услуг. А значит будет содействовать развитию сервисных отношений (в том числе и со “своим” ИТ-подразделением). С крупными организациями (менее гибкими, более регламентированными и неповоротливыми) всё, конечно сложнее.

    • Pavel Solopov

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

      • “Бум аутсорсинга не слишком поспособствовалразвитию сервисных отношений.”

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

        • И опять же аутсорсингом занимается в основном крупняк, а там темпы изменений совсем другие – всё как в замедленном кино. SaaS же скорее всего будет более востребован именно в SMB. Поэтому у этих явлений разные “точки приложения”.

        • Pavel Solopov

          «одновременно присутствуют признаки и монополии, и монопсонии»

          Это опять же касается крупняка. Аутсорсинг в SMB всё же ближе к идеальной модели. В тех нечастых случаях, когда он применяется, конечно.

  • Мне кажется, стоит взглянуть на проблему под другим углом. Для бизнеса любая ИТ-система – инструмент, у которого показатель “эффективность” максимален в текущих условиях (в идеале 🙂 ). Но помимо прямой эффективности выполнения бизнес-действия не менее важна стоимость сопровождающих операций. Попробуйте ответить на следующие вопросы:
    “Сколько стоит обучения нового сотрудника конкретному ИТ-решению?”
    “Что будет, если сотрудник увольняется – как передать данные другому сотруднику?”
    “Сколько повторяющихся операций приходится делать разным сотрудникам из-за разных ИС, автоматизирующих жизненный цикл одной сущности?” (на Почте России адрес, индекс и штрих-код вбивается не менее 3 раз, вместо того, чтобы один раз вбить и использовать только ШИ)
    “Сколько стоит время, которое будет потрачено из-за сбоя в ПО? Сколько, если провайдер вдруг исчезнет?”
    Все это показывает, что ИТ давно уже ушло “точечной застройки” – предоставления локальных услуг. Услуг, которые ИТ предоставляет, должны быть объединены в одну архитектуру, каждое приложение должно иметь свое место в ней и точки взаимодействия с другими приложениями. Задачей ИТ в будущем я вижу именно нахождение правильного места нового приложения в ИТ-архитектуре и решения указанных выше вопросов. И “запрет маленькой программульки” воплне при этом возможен, если предложена альтернатива.
    Основные плюсы SaaS – возможность быстрого внедрения услуги и низкая стоимость входа (получения). Но на вопрос “как должна быть автоматизирована бизнес-деятельность” все равно будет отвечать ИТ.


Добавить комментарий для Pavel SolopovОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM