План обеспечения непрерывности ИТ сервисов. CIO

План обеспечения непрерывности ИТ сервисов

Основные положения

Целю данного документа является подготовка ИТ департамента компании Example к форс-мажорным случаям (выходы из строя оборудования и ПО, катастрофам, стихийным бедствиям, саботажу и т.д.), приводящим к длительному перебою в предоставлении ИТ услуг. Результатом выполнения комплекса мер, описанных в данном документе, должно быть скорейшее возобновление предоставления ИТ услуг в максимально большом объеме и с минимальными издержками.

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

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

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

ИТ-стратегия, или как формализовать неопределенность?

Презентации с конференции «ИТ-стратегия, или как формализовать неопределенность?»

 

Качать http://sdrv.ms/1cSuJXJ

Remedy SLA и список времени

Заявка	Время	Ответственный	Ожидаемый процент закрытия от всех заявок
1 уровень	1,5 часов	Иванов	80,00%
2 уровень	3  часов	Петров	16,00%
3 уровень	8 часов	Сидоров	3,00%
Экспертное решние	до момента решения	Инженеры по данному направлению	1,00%

ПЯТЬ «НЕЛЬЗЯ»

«За время работы руководителем службы поддержки мне удалось выявить пять типичных ошибок подчиненных», — делится Юрий Матвиенко, руководитель службы поддержки ИТ группы компаний «Рольф». Во-первых, эти ошибки встречались непозволительно часто, а во-вторых, сильнее всего били по имиджу ИТ-департамента. Эти ошибки легли в основу памятки сотрудника ИТ-поддержки с названием «Пять “нельзя”».

1. Нельзя объяснять клиенту, почему проблема не решена. Очень часто мы начинаем оправдываться и доказывать, что вина лежит не на нас. Если встать на место клиента, то становится понятно, что такие объяснения ничего, кроме раздражения, не вызывают. Они лишь усугубляют ситуацию. Клиент ждет ответа на вопрос «Когда проблема будет решена?», на нем и надо концентрироваться. Имеет смысл заверить пользователя, что проблема решается, можно перечислить совершенные шаги и сообщить ожидаемое время решения. Это успокоит сотрудника, он сможет спланировать деятельность до этого времени.

2. Нельзя упоминать никакие другие подразделения, «переводя на них стрелки». Самое правильное решение — позвонить тому, кого хотел бы назвать виновным, и задать ему вопрос, о котором шла речь в первом «нельзя». Возможно, после этого появятся ответы на интересующие клиента вопросы. Когда проблема несмотря ни на что будет решена, клиент станет вас рассматривать в качестве надежного партнера.

Работающей ИТ-службе необходимы работающие метрики

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

TCO и ROI для CIO

Введение

«Кстати, с айтишниками я не мог вообще никогда вести переговоры. Мне казалось, что я говорю на русском, а они – на козьем. Надо иметь человека в компании, который переводит с козьего, а нам с этим не везло абсолютно. А переводчика с их стороны практически никогда не бывало».
Е.Чичваркин

Проблема, последствия и решение

На фоне не утихающих споров о месте и роли Chief Information Officer (CIO, Прим.: Этим сокращением я далее для краткости буду называть самого главного по информационным технологиям в организации. Это может быть директор по информационным технологиям (ИТ), или приходящий ИТ-администратор. Все зависит от размера организации и роли, которую в ней играют ИТ) в мировой истории, одно остается ясным как день: большинство CIO не понимает потребностей CxO (остальные руководители), а они не понимают языка CIO. Летом 2010 года совместно с коллегами из IBM и IBS я проводил семинар для участников клуба 4CIO на тему «Расчет TCO и ROI для ИТ-проектов: математика или гадание на кофейной гуще? Считаем и думаем вместе!»

Разработка ИТ-стратегии

 

Объем и содержание документа ИТ стратегия должен быть таким,чтобы у владельцев/руководства хватило терпения дочитать его до конца и понять. Причему меня сложилось убеждение, что его сразу нужно готовить в виде презентации.
В этом документе обязательно должны быть:
1. Основные положения из бизнес-стратегии: описание организации, ее позиция в отрасли и на рынке, направление развития.
2. Взгляд бизнеса на ИТ (топ-менеджмент, руководители бизнес подразделени, пользователи) – что бизнес ожидает от ИТ
3. Укрупненные бизнес требования к ИТ с точки зрения всех трех групп

Что все-таки следует называть облачными вычислениями?

Что все-таки следует называть облачными вычислениями?

Существует множество определений, и каждая компания стремится создать собственное. Национальный институт стандартов и технологий (National Institute of Standards and Technology, NIST — одно из агентств министерства торговли США — прим. ред.) сформулировал пять характеристик облачных вычислений:

1. Это услуга по требованию, быстрый сервис самообслуживания. Если раньше заказ на оборудование и ПО требовал длительного времени на переговоры, поставку и инсталляцию, то в облаках все эти услуги могут быть предоставлены буквально через несколько минут.
2. Доступ к данным и сервисам откуда угодно.
3. Объединение ресурсов провайдера сервисов в единый пул, динамически распределяемый между заказчиками. При этом они не знают, где именно находятся ресурсы, используемые сервисами.

Управление проектами: работа над ошибками

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

Людмила Жукова

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

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

Доверим бизнес процессам!

В других статьях раздела мы писали о важности согласования маркетинговой стратегии и внедрения методики её реализации для построения эффективного бизнеса. Однако, бывает и так, что адекватная стратегия есть, меры по её воплощению в жизнь разработаны, а результата нет: достичь плановых значений показателей не удаётся. Может быть, проблемы кроются в нижнем, процедурном уровне системы управления? Давайте поговорим об оптимизации бизнес-процессов предприятия.