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

Cибирский банк Сбербанка России стал четырнадцатым в реестре ISO 20000

Опубликовано 24 декабря 2010
Рубрики: ISO 20000, ITSM, Аудит, Практический опыт
Комментарии

В Сибирском банке завершена сертификация по международному стандарту ISO 20000. Для прохождения сертификации, начиная с 2007 года, в банке проводились мероприятия по внедрению и развитию процессов системы управления информационными сервисами (СУИС).

Результатом успешно пройденной сертификации стало получение банком документа о соответствии действующей системы управления IT-сервисами требованиям стандарта ISO/IEC 20000-1:2005 в области оказания услуг по эксплуатации и сопровождению автоматизированных банковских систем, предоставляемых структурным подразделениям Сибирского банка.

Сертификацию осуществлял Британский Институт Стандартов (British Standards Institution) крупнейший международный орган по сертификации, который проводит оценку и регистрацию систем управления ведущих мировых компаний для улучшения эффективности бизнеса и снижения возможных рисков.

Сведения о сертификации занесены в Единый реестр организаций Российской Федерации и стран СНГ, прошедших сертификацию на соответствие международному стандарту ISO 20000-1:2005.

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

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

  • Не думаю, что за уходящие дни этого года мы узнаем о новых достижениях-сертификациях, поэтому можно подвести краткие итоги 2010.

    А они таковы — в этом году шесть организаций вступили в ряды сертифицированных по ISO 20000. Много это или мало? В абсолютном значении вроде не впечатляет, но в относительном — почти удвоение!

    Будем надеяться, что даже без обязательных мер по наличию сертификата ISO 20000 для конкурсов, тендеров и прочих ЦБ, число сертифицированных компаний будет расти не меньшими темпами. И мы уже не сможем сказать «Недооценённый стандарт» — www.realitsm.ru/2010/05/n...ndart-iso-20000/

  • old fuddy-duddy

    Если взглянуть в реестр клиентов BSI, то помимо Сибирского банка мы обнаружим там еще пяток других сберовских банков, сертифицированных по ISO 20000. «Пушка! Они заряжают пушку! Зачем?» (Капитан Смолет, мультфильм «Остров сокровищ»). А действительно, зачем они сертифицируются, зачем внутренней ИТ-службе такой сертификат?

    • Это известная история...

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

      Правда, с тех пор четыре буквы на флаге заменили на Lean, но сертификация продолжается, наверное уже по инерции 🙂

      • old fuddy-duddy

        Это ответ на вопрос «почему?», но в данном случае он не дает ответа на вопрос «зачем?». А в свете темы про недооцененность стандарта, мне страшно интересно: зачем Сберу когда-то понадобилась сертификация по ISO 20000, даже если теперь надобность и отпала.

        • Возможно, чтобы «затвердить достижения».

          Люди старались, работали. Много времени и сил потратили. Наверное, и денег тоже.

          Независимая оценка того, что сделано, может дать определённую уверенность что сделано близко к ITSM и не зря. Нет?

          • old fuddy-duddy

            Так цель была сделать «близко к ITSM», или улучшить управление ИТ-сервисами? Во втором случае, по идее, результат должен быть и так явно заметен, например, уменьшение количества инцидентов, сокращение времени простоев и т.п. и т.д.

          • old fuddy-duddy

            Опять же интересно, зачем банки сертифицируются по отдельности, ведь это бОльшие затраты на саму сертификацию и на ее последующую поддержку, не логичнее ли было бы сертифицировать разом Сбер в целом, например через центральный аппарат, или в каждом банке построили свой оригинальный ITSM?

            • Вот вариант ответа.

              Если СУИС сертифицирована как единое целое, очередной аудит в, например, Хабаровске должен/может проверить исправление несоответствий, выявленных в прошлый раз в, скажем, Калининграде. Маловероятно, чтобы даже очень зрелая организация обеспечила сначала необходимую для этого синхронность несоответствий, а потом — такую же синхронность корректирующих действий.

              Вот более простой вариант ответа.

              Несмотря на усилия всех территориальных банков, им удается обеспечить соответствие требованиям стандарта не одновременно.

              Вот еще один.

              В случае единой СУИС финансирование сертификации выполнялось бы центральным аппаратом, а так — самими территориальными банками...

              Любые совпадения с реальными обстоятельствами случайны.

              • old fuddy-duddy

                А какие особенные несоответствия аудитор может найти в Хабаровске или в Калининграде, если в организации единая СУИС, а то как выполняются общие для всех правила, можно посмотреть в системе автоматизации?

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

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

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

                  И главное — вполне возможно, что реально работающие системы управления в самом деле ограничены территориально. Зачем их искусственно объединять для (при) сертификации?

                  • old fuddy-duddy

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

                    • Первое, что приходит в голову — внутренняя политика, повышение статуса ИТ в компании.

                      Второе — получение независимого экспертного подтверждения соответствия СУИС внутренним требованиям. Теоретически возможно, что бизнес-задачи требуют от ИТ процессов 4 уровня зрелости — если не всех 13 процессов стандарта, то, скажем 10 из них. Тогда «лишние» три процесса могут быть искусственно дотянуты до соответствия за разумные деньги. «Разумные» — это такие, при которых имиджевые плюсы от сертификации перевесят ту часть затрат, которая не поддерживает бизнес-требований, а перекрывает их. И не только имиджевые: появляется и возможность независимого контроля...

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

                      Каковы причины и цели в Сбербанке, мне неизвестно.

      • old fuddy-duddy

        «затверждение» как цель, достижение которой стоит немалых затрат, в случае со Сбером не очень понятна.


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

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

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT