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

Определение «производительности»

Елена предлагает нам на растерзание еще одного ложного друга переводчика спрашивает:


В поисках экспертного мнения по определению термина "Производительность услуги" предлагаю обсудить состоятельность следующей трактовки:

" Производительность услуги – это возможность (или способность) обеспечения согласованного уровня предоставления запрашиваемого объема услуги при установленных параметрах нагрузки на ресурсы."

Ваше мнение?


Елена, уточните в комментариях, пожалуйста — ваш вопрос про Performance?

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • Елена

    Добрый день, перефразируйте вопрос про Perfomance.

    Я написала на форум только один вопрос — об определении производительности услуги.

    Кстати, сохраните мой вопрос для чистоты экперимента в первоначальном виде. О ложном переводе я не писала. Определение в "не разведенном" английском виде в Глоссарии ITIL и терминах ISO 20000 не нашла.

    • Добрый день, перефразируйте вопрос про Perfomance.

      Не стоит, вопрос уже снят;)

      Кстати, сохраните мой вопрос для чистоты экперимента в первоначальном виде.

      Текст между чертами. Иллюстрацию убираем для чистоты.

      Определение в "не разведенном" английском виде в Глоссарии ITIL и терминах ISO 20000 не нашла.

      В ITIL есть, например: "Производительность (Performance) Мера того, что достигнуто или выработано системой,

      человеком, командой, процессом, или ИТ-услугой". Не подойдет? 

  • Елена

    Спасибо за вариант, Константин. Мне нужны еще варианты. Я хочу формализовать меру измерения этой величины.

  • Елена

    Чем в предложенном варианте производительность отлична от объема оказанных услуг? 

    • Под предложенный в ITIL вариант попадают, например, счета, которые выставляются заказчикам услуги. Они же не входят в объем предоставленной услуги? )))

  • Елена

    Константин, спасибо за прозрачный ответ. 

    • Не за что. Дело не в счетах, конечно же, а в том, что услуга кроме полезности (автоматизации вычислений) создает еще и специфические результаты: отчеты, техническую документацию, регламенты, протоколы и прочее. А нужны эти результаты для того, чтобы прогнозировать ее производительность не только при "установленных параметрах нагрузки на ресурсы", но и прогнозировать уровень производительности при любых сочетаниях нагрузки и самих ресурсов.

      Учитывая комментарий Павла ниже, ваше определение я бы упростил:

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

      • Производительность — максимально возможный объем предоставления услуги в единицу времени.

        Моя против. Дело в том, что производительность — это не отдельный параметр, это более общее понятие. В частности, производительность традиционно имеет как минимум четыре формы: 1) количество выполненных операций / сформированных резльтатов в единицу времени (для систем это часто назывется пропускная способность), 2) допустимое количество одновременно выполняемых операций или исполнителей, 3) время выполнения операции (как частный случай — время реакции для асинхронных операций) и 4) время, к которой операции должны быть завершены (в иностранной литературе это понятие cut-off time). Четвертый вариант особенно важен для услуг, идентифицированных на базе бизнес-процессов, например "Вермя завершения автоматизированных регламентных операций в рамках процедуры End Of Day".

        Поэтому на мой взгляд ввести один измеримый параметр "Производительность услуги" в общем сучае нельзя. А четыре параметра производительности, описанные мной, для услуг так и формулируются (и так и измеряются):

        1. Объем потребления услуги. Пример: количество документов обрабатываемых в сутки.

        2. Объем потребления услуги (другая форма). Пример: количество одновременно работающих потребителей услуги.

        3. Длительность выполнения операции. Пример: среднее время формирования отчета.

        4. Время завершения операции (cut-off time). Пример: время завершения автоматизированной обработки кредитных заявок.

        Для первой и второй величин характерно предельное значение. Для третьей и четвертой — целевое и граничные значения.

        Причем, я не претендую на полноту — это просто то, что встречалось в моей практике.

  • Pavel Solopov

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

    Вообще производительность это количество продукции произведённое в единицу времени. Соответственно у производительности должен быть субъект, который что-то производити объект — то, что производится.

    Что у нас будет субъектом, а что объектов в случае "производительности услуги"?

    Но однозначно Производительность это не "возможность (или способность) обеспечения". "Возможность обеспечения", это скорее надёжность.

    • Grigory Kornilov

      Услуга печати ппредоставляется с 4.12.2013г.

      Технические характеристика — возможна печать до 1000 страниц с час.

      Фактическое использование — напечатано 5000 страниц за 4.12.2014, 6000 страниц за 5.12.2013, предоставление услуги продолжается и 6.12.2013.

      Павел, какова производительность в этом примере, достаточно ли для ее вычисления данных?

       

      • Pavel Solopov

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

        А вот если услуга "ИТ-обеспечение процесса оценки благонадёжности заёмщика".

        Целевая характеристика — отсутствие перерывов в БП длительностью более 20 минут.

        Что будет производительностью здесь?

        • Grigory Kornilov

          Павел,

           

          1. Вы так и не ответили свое имхо какова производительность в приведенном мною примере. Имхо — 1000 в час

          2. Услуга "ИТ-обеспечение процесса оценки благонадёжности заёмщика" ... из чего это реально состоит, это бизнес приложениие, разработанное и поддерживаемое IT и помогающее оценить благонадежность (поиском в black листах и тп) или ?

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

          Например:

          Бизнес кейс использования услуги: пользователь вводит ФИО и на выходе в среднем через 5 минут ожидает получить вердикт занесен ли такой-то в черные списки. Если запрос обрабатывается за 10 минут, то считается, что бизнес приложение работает неприемлемо медленно.

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

          Если 100 запросов, которые пользователи запустят за 5 минут будут гарантировано обработаны менее, чем за 10 минут каждый, а при запуске за 5 минут 110 запросов возможно часть будет выполнена более, чем за 10 минут, то это повод посчитать, что производительность услуги в это бизнес кейсе (а бизнес кейсов может быть много) равна 100 за 5 минут.

          • Павел Солопов

            1000 листов в час это у вас производительность по документам, так сказать. фактическая производительность 6000 в день, сколько там в час, затрудняюсь сказать.

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

          • Pavel Solopov

            Проразмышляв все выходные над этим вопросом, я понял, что меня смущает в выражении "производительсность услуги".

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

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

  • Елена

    Павел, Константин спасибо за активное обсуждение. Я попала в правильное место — команда гениев! Успехов и новых открытий для нас, которые на старте!

  • Nargiza Suleymanova

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT