WWW.KNIGA.LIB-I.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Онлайн материалы
 

«Information Management Н а у ч н о - м е то д и ч е с к и й ж у р н а л д л я п р о ф е с с и о н а л о в И Т # Управление — это ...»

Information Management

Н а у ч н о - м е то д и ч е с к и й ж у р н а л д л я п р о ф е с с и о н а л о в И Т

#

Управление —

это цикл вечного возвращения

Подписывайтесь на

Information Management!

Я подобе

ия дают н хо р о ш е

Вложения в знан й губке,

потому ч

прибыль. то впиты

самую большую ваю идеи а потом и, клин спользую Бенджамин Фран их.

Большин ство мои х идей изначаль но прина длежит другим лю дям...

Томас Эди сон Журнала без читателя не существует.

Как не существует птицы без воздуха на который она опирается. И будет ли жить Information С 2012 года журнал будет Management — решать вам. Не распространяться только просто читателям -- нашей опоре.

по подписке.

Подписку можно оформить на сайте Как базовую мы предлагаем электронную версию infomanagement.rucio.ru журнала (pdf). Однако, если вы предпочитаете бумажную в разделе Подписка.

–  –  –

Обращение к коллегам ИТ-директорам К оллеги, российские ИТ-директора! К сожалению, ландшафт идей и подходов в области ИТ, который представлен в России, не соответствует мировой практике. Масса важнейших идей, подходов и методик остается вне нашего поля зрения. И, прежде всего, в двух важнейших областях: ИТ-стандарты и исследования в области ИТ.

ИТ-стандарты. Коллеги, все вы знаете, что положение с ИТ-стандартами в России очень плачевное.

У нас их не только на порядок меньше, чем в развитых странах, но и скорость их ввода в несколько раз ниже общемировой — мы все больше и больше отстаем! И это при том, что ИТ-стандарты:



• это опыт и знания, признанные всеми и утвержденные «де юре»;

• это экономия времени и сил для творчества и инноваций;

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

В результате такого положения дел ИТ-стандартами в России нередко приходится тратить свое время и интеллект наших сотрудников не на инновации, а на «изобретение велосипедов»!

Исследования. За последние 15–20 лет в мире проведено огромное количество исследований, посвященных важнейшим аспектам использования ИТ. Были сделаны важнейшие открытия и выводы, разработаны соответствующие методологии, однако, они практически неизвестны в России. Серьезные издания, в которых они публиковались, увы, почти не доходят до России. Но без этих знаний сегодня невозможно эффективно управлять развитием ИТ в компании.

Если мы профессионалы — мы должны это знать!

К сожалению, российские ИТ-журналы уделяют мало внимания этим областям знаний. Что же делать?

Решение в нашей с вами общности. Если все ИТ-директора объединяться, они смогут решить эту задачу.

Именно с такой идеей создается новый научно-методический журнал Information Management.

Давайте объединимся вокруг этого полезного начинания!

Призываем Вас присоединиться к нам, поддержать это начинание и подписаться на журнал.

–  –  –

Уважаемые читатели журнала Information Management!

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

Почему же вопросы управления ИТ, внедрение современных методик и международных стандартов сегодня становятся особо актуальными для нас? Сфера ИТ всегда была интернациональна.





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

Достаточно упомянуть о знаменитом «34-м» ГОСТе.

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

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

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

–  –  –

К сожалению, из-за сложности объекта – ИТ-службы – единая классификация стандартов для CIO невозможна.

Весь управленческий цикл CIO охватывают два стандарта: CoBIT (Control Objectives for Information and Related Technology, «Задачи информационных и смежных технологий») и ISO 38500.

Признанное международным сообществом знание о процессах создания и эксплуатации автоматизированных систем и их программных компонентов изложено в группе из трех стандартов: ГОСТ Р ИСО/МЭК 15288, ГОСТ Р ИСО/МЭК 15289 и ГОСТ Р ИСО/МЭК 12207.

Комплексное обследование объекта автоматизации, а также разработку концепции и мониторинг его развития полезно основывать на двух стандартах: на стандарте де-факто – Zachman Enterprise Architecture Framework («Общей схеме архитектуры предприятия Дж. Захмана») и на стандарте ГОСТ Р ИСО 15704:2008 Требования к стандартным (референсным) архитектурам и методологиям предприятия.

–  –  –

Обзор стандарта ISO 20000-1.

Информационная технология.

Управление услугами. Спецификация Стандарт ISO 20000-1 дает модель процессов управления, состоящую из 13 процессов, объединенных в пять групп.

Это существенно меньший набор процессов управления ИТ-услугами, чем в других международных практиках в области ITSM (ITIL v3 описывает 27 процессов, COBIT 4.1 – 34 процесса). Стандарт определяет то, что обязательно должно быть в любой организации, задает минимальный уровень, который надо достичь.

–  –  –

Область применения стандарта ISO/IEC 27031:2011 охватывает все события и инциденты (в том числе связанные с безопасностью), которые могут повлиять на ИТ и привести к сбоям, влияющим на непрерывность выполнения критически-важных деловых функций. Стандарт включает в себя практику управления и реакции на инциденты и нештатные ситуации, а также планирование готовности ИТ к таким событиям.

Готовность ИТ к обеспечению непрерывности бизнеса (ICT Readiness for Business Continuity, IRBC) — это важная составляющая часть внедрения и функционирования системы управления непрерывностью бизнеса.

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

Стандарт ISO/IEC 27031:2011 содержит сильную привязку к циклу PDCA. По сути цикл PDCA – это стержень всего стандарта ISO/IEC 27031:2011, он проходит через него красной нитью.

–  –  –

Обследование более 10 тыс. компаний в разных странах в 1995–2000 годах показало отсутствие замет¬ной корреляции между расходами на ИТ и ростом производительности компании, выраженным в EVA, либо каким либо иным ключевым показателем эффективности бизнеса, вроде рентабельности капитала, рентабельности активов или прибыльности.

Хотя почти 100 % сотрудников «информационного труда» к 2000 году используют компьютеры, большинство из них не в состоянии делать работу за меньшее время и более дешево, чем раньше.

С 1990 по 2000 годы инвестиции в ИТ не смогли уменьшить средние объемы чистых активов, необходимых для генерации доходов.

С 1990 по 2000 годы американские компании в среднем так и не смогли уменьшить расходы, связанные с управлением и администрированием.

–  –  –

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

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

«Парадокс производительности» охватывает лишь определенный период времени от появления инновационного изобретения – как показывает история электричества и ИТ, около 30-35 лет. И к началу 21 века «парадокс производительности» в ИТ был преодолен.

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

–  –  –

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

Мониторинг это только часть контроля. Важная, но не единственная. Самое важное, что отличает контроль — это принятие управляющих воздействий. Если у вас нет рычагов влияния на проект, то не надо себя обманывать — вы зани¬маетесь мониторингом, а не контролем. Это дело тоже почетное и уважаемое, но все таки не контроль.

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

Как же выстроить такую систему? Для построения системы контроля нужно последовательно ответить на 4 основных вопроса: зачем контролировать, что брать за эталон, как влиять и какие инструменты использовать?

–  –  –

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

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

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

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

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

–  –  –

Инновации — это великое дело для организации. Это основа ее развития, жизни и смерти.

Мощь — это умение применять тактику, сообразуясь со стратегией развития.

Инновационный проект — это путь, на котором для достижения результата не стоит раскрывать все карты.

–  –  –

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

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

В статье приводятся несколько неформальных и нестрогих классификаций стандартов для CIO, а также даются краткие описания содержания основных стандартов. Список стандартов ГОСТ Р может быть полезным для создания официальных, государственно утвержденных нормативных документов, опора на которые нужна для установления стандартизованных требований ко всем поставщикам и соисполнителям.

–  –  –

Что понимается под стандартом?

Уточним трактовку слова «стандарт». Согласно широко распространенному пониманию, будем относить к стандартам документы разных происхождений и названий — вовсе не обязательно стандарты ISO и даже не обязательно имеющие слово «стандарт» в названии. Важно другое: чтобы документ излагал характеристики, правила, методы и/ или требования в целях их «многократного использования» (в соответствии с ФЗ 184 «О техническом регулировании»).

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

–  –  –

• ISO/IEC 38500:2008 Corporate governance of information technology.

• CoBIT, Control Objectives for Information and Related Technology (v.4.1).

• ГОСТ Р ИСО/МЭК 12207:1999 Процессы жизненного цикла программных средств.

• ГОСТ Р ИСО/МЭК 15288:2005 Процессы жизненного цикла систем.

–  –  –

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

–  –  –

Охват операционной деятельности О перационная (регулярная) деятельность описывается серией стандартов ISO/IEC

20000. В настоящее время серия ISO 20000 состоит из следующих пяти частей:

• ISO/IEC 20000-1:2011 Information technology — Service management — Part 1:

Specification. (Часть 1. Спецификация);

• ISO 20000-2:2005 — Part 2: Code of practice (Часть 2. Свод практических рекомендаций1), который в скором времени будет заменен на ISO/IEC FDIS 20000-2 Information technology — Service management — Part 2: Guidance on the application of service management systems (Часть 2 Руководство по применению системы управления услугами)2;

• ISO/IEC TR 20000-3:2009 Information technology — Service management — Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1 (Часть 3.

Руководство по определению области оценки соответствия и применимости ISO 20000-1);

• ISO/IEC TR 20000-4:2010 Information technology — Service management — Part 4:

Process reference model. (Часть 4. Референсная модель процессов);

• ISO/IEC TR 20000-5:2010. Information technology — Service management — Part 5:

Exemplar implementation plan for ISO/IEC 20000-1. Часть 5. Образец плана внедрения для ISO 20000-1).

Кроме того, имеются два национальных стандарта:

• ГОСТ Р ИСО/МЭК 20000-1:2010 Информационная технология Менеджмент услуг.

Спецификация.

• ГОСТ Р ИСО/МЭК 20000-2:2010 Информационная технология Менеджмент услуг.

Кодекс практической деятельности.

ГОСТ Р ИСО/МЭК 20000-1:2010 сделан как перевод предыдущей версии первой части стандарта — ISO/IEC 20000-1:2005. Он содержит рекомендации в части управления орерационной деятельностью ИТ-службы, используется для тактического и оперативного управления и организации рабочих ИТ-процессов. Включенная в стандарт модель совершенствования процессов основана на цикле PDCA. Вторая часть стандарта, ГОСТ Р ИСО/МЭК 20000-2:2010, сделана как перевод ISO/IEC 20000-2:2005. Она содержит практические рекомендации по процессам, требования к которым сформулированы в первой части3.

–  –  –

работки, согласования и утверждения ТЗ, а также поучительное приложение, описывающее побудительные мотивы разработчиков ГОСТ 34.

6. ГОСТ 34.603-92. Виды испытаний автоматизированных систем. Стандарт устанавливает виды испытаний автоматизированной системы на стадии ввода в действие с целью проверки соответствия создаваемой системы требованиям ТЗ, а также определяет общие требования к организации и проведению испытаний разных типов. Может быть сравнительно легко адаптирован, для определения требований к испытаниям на промежуточных фазах создания или модернизации системы, и к контролю промежуточных продуктов проекта.

7. ГОСТ 24.202.80 Требования к содержанию документа «Технико-экономическое обоснование создания АСУ». Так как полагается разрабатывать технико-экономическое обоснование проектов, ГОСТ 34 опирается на стандарт ГОСТ 24.202.80. Этот небольшой документ в своих принципиальных положениях работоспособен и сейчас.

Международные процедурные стандарты, в основном ориентированные на проекты П ризнанное международным сообществом знание о процессах создания и эксплуатации автоматизированных систем и их программных компонентов изложено в группе из трех стандартов: ГОСТ Р ИСО/МЭК 15288, ГОСТ Р ИСО/МЭК 15289 и ГОСТ Р ИСО/МЭК 12207.

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

В любом случае нужно учитывать, что, хотя все три стандарта могут применяться и в режиме «как есть», они все же являются рамочными, требуют дополнения шаблонами документов, рекоменПринципиально более полная версия ISO/IEC дуемыми показателя

–  –  –

Стандарты архитектуры предприятия К омплексное обследование объекта автоматизации (в частности, собственного предприятия), а также разработку концепции и мониторинг его развития с применением автоматизированных систем полезно основывать на двух стандартах: на стандарте де-факто — Zachman Enterprise Architecture Framework («Общей схеме архитектуры предприятия Дж. Захмана») и на стандарте ГОСТ Р ИСО 15704:2008 Требования к стандартным (референсным) архитектурам и методологиям предприятия.

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

Начинать настройку работы ИТ-службы на комплексное понимание главного заказчика и объекта приложения сил — своего предприятия, полезно с применения лаконичной схемы Захмана, более десяти лет сохраняющей признание в качестве стандарта де-факто. Летом 2011 года была опубликована третья версия Zachman Enterprise Architecture Framework, нацеленная на более строгое толкование понятий и аспектов архитектуры, но использующая для этого более абстрактные представления. Вместе с тем, начинать освоение схемы Захмана стоит с более конкретных и привычных ИТ-специалистам, бизнес-аналитикам и менеджерам представлений, описанных в первой и второй версиях.

Стандарт ГОСТ Р ИСО 15704:2008 выполнен переводом стандарта ISO Industrial automation systems — Requirements for enterprise-reference architectures and methodologies 1999 года с добавлением 2000 года, представляет собой всестороннюю и глубоко структурированную разработку и служит базой для определения последующих стандартов, например недавНачинать настройку работы ИТ-службы на него стандарта моделирования предприятия. Он создан комплексное понимание главного заказчика техническим комитетом ISO — своего предприятия, полезно с применеTC 184, который ответственен не за ИТ, как таковые, а за ния лаконичной схемы Захмана, более десяавтоматизацию предприятий, и нацелен на последовательти лет сохраняющей признание в качестве ное применение архитектурстандарта де-факто.

ного подхода для интеграции всех типов ресурсов предприятия, всех подразделений и технологий в цельное и гармонично функционирующее, динамично развивающееся предприятие. Область применения ГОСТ Р ИСО 15704 — программы и проекты видов:

a) создание предприятия;

b) выполнение работ по реструктуризации (реинжинирингу) предприятия;

c) изменения предприятия, выполняемые в эволюционном стиле и распространяющиеся только на части жизненного цикла предприятия, но на предприятие в целом.

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

–  –  –

Обзор стандарта ISO 20000-1.

Информационная технология. Управление услугами. Спецификация 26 Information Management 01-2011 Стандарт ISO/IEC 20000-1:2005 Information technology — Service management — Part 1: Specification был принят в 2005 году.

В конце 2010 года был утвержден и введен в действие стандарт ГОСТ Р ИСО/МЭК 20000-1:2010 «Информационная технология. Менеджмент услуг. Часть 1. Спецификация» сделанный на основе и идентичный международному стандарту ISO 20000А в 2011 году ISO обновила стандарт выпустив версию ISO 20000-1:2011. Таким образом, в России в качестве ГОСТ принята устаревшая (и сильно отличающая от новой редакции) версия стандарта ISO 20000-1. Далее мы отдельно расскажем об обеих версиях ISO 20000-1:2005 (ГОСТ Р ИСО/МЭК 20000-1:2010) и ISO 20000-1:2011

–  –  –

Стандарт дает модель процессов управления, состоящую из 13 процессов, объединенных в пять групп (рис. 1). Надо сказать, что cтандарт ISO 20000 содержит существенно меньший набор процессов управления ИТ-услугами, чем другие международные практики в области ITSM (ITIL v3 описывает 27 процессов, COBIT 4.

1 — 34 процесса). Не беремся судить насколько это оптимально, однако, он определяет то, что обязательно должно быть в любой организации. Стандарт задает минимальный уровень, который надо достичь. Если у компании нет этих видов деятельности — она не управляет услугами так, как этого требует международно-признанный стандарт. Кроме того, такой минимальный набор процессов управления ИТ-услугами дает возможность быстрее приступить к построению системы управления ИТ-услугами, а также провести аудит ИТ-подразделения на соответствие принципам ITSM.

Скажем несколько слов о логике группировки процессов и вообще, рисунка 1. Прежде всего она отражает отнесение процессов либо к операционному, либо к тактическому уровню.

В ITIL v2 это разделение отражено в объединении процессов в 2 группы:

Service Support и Service Delivery. Соответственно, в стандарте выделяются «Процессы предоставления услуг» (Service Delivery) относящиеся к тактическому планированию и управлению, и процессы операционного слоя (поддержки услуг), обеспечивающие возможности для предоставления услуг пользователям (управление релизами, инцидентами, проблемами и поставщиками). Заметим, однако, что эта логика разнесения процессов плохо работает в отношении группы «Процессов отношений». Процесс управления отношениями с бизнесом все-таки, частично должен относиться к тактическому уровню.

Наконец, хотя в ITIL v2 процессы управления конфигурациями и изменениями относятся к уровню поддержки услуг, по всей видимости, с точки зрения авторов стандарта процессы управления конфигурациями и изменениями, нельзя однозначно отнести ни к операционному, ни к тактическому уровню. На схеме они находятся посередине, что полностью соответствует методологии ITSM компании НР, которая еще более 10 лет назад определила именно эти процессы в качестве стержня управлениям ИТ-услугами.

–  –  –

Всегда ли услуги снижают риски и специфические затраты?

Предоставление услуг несет ценность, путем улучшения результатов которые заказчик хочет достичь. И строго говоря, предоставление услуг должно снижать риски и уменьшать специфические затраты. Но, всегда ли услуги снижают риски и стоимость или нет, тут очевидно, нет единого мнения. Простой пример, я выполнил за кого-то определенную простую работу. Услуга оказана, я помог заказчику достичь результата. Однако, взял ли я на себя риски и снизил ли по стоимости взяв на себя специфические затраты — это вопрос. Есть весьма простые, технические услуги, не ведущие ни к развитию, ни к инновациям. И они могут выполняться совсем не дешевле и не менее рискованно. Вполне возможно, в этом случае провайдер не специализируется на этом виде деятельности, ведь если бы он специализировался, то услуга была бы оказана дешевле, надежнее и т.д. Но всегда ли так происходит? Строго говоря, с точки зрения стандарта, если услуги выполняются ни дешевле, ни менее рискованно, это, тем не менее, можно считать услугой.

Обзор стандарта ISO 20000-1

4. Четко перечислены те элементы, которые входят в систему управления услугами (рис. 4). Если у того, кто хочет оценить себя на соответствие стандарту в системе управления этих элементов нет, значит, его система управления услугами как минимум не полна. Система управления услугами должна состоять из следующих элементов:

1. «Ответственность топ-менеджмента» и этот раздел в стандарте ISO 20000-1:2011 существенно расширен. Это стыковка со стандартом ISO 9000 — именно топменеджмент должен взять на себя ответственность за управление качеством и обеспечить это в своей компании. Появились требования к топ-менеджменту в отношении политики управления услугами, а также к представителю топ-менеджмента в управлении сервис-провайдером.

2. «Руководство процессами, которые выполняются другими сторонами».

3. «Управление документами».

4. «Управление ресурсами», которые подразделяются на людские, технические, информационные и финансовые. Вынося управление ресурсами на самый верхний уровень системы управления, авторы утверждают, что это важнейший элемент Рис. 4.

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

Система управления

5. Использование цикла PDCA для постоянного улучшения системы управления услугами.

услугами по ISO Стандарт ISO 20000-1:2011 четко определяет использование цикла PDCA для постоянного улучшения системы управления услугами. В отличие от аналогичного подхода ISO 20000-1:2005 в стандарте 2011 года основные требования существенно переформулированы и гораздо более отточены и четки. Поэтому мы приведем их на рис. 5.

–  –  –

О ступенях аудита Отметим, что в стандарт введена важнейшая функция — внутренний аудит (контроль). Такая функция крайне полезна. Это сближает стандарт с COBIT, требованиями Basel II и других стандартов. Заметим, что речь идет именно о внутреннем аудите (контроле), который делается либо самими членами команды менеджеров, либо специальным подразделением внутри компании. К сожалению, в России существует устойчивое понимание аудита именно как внешнего, осуществляемого внешней компанией. Однако мировая практика напротив, наибольшее значение придает внутреннему контролю. Такой контроль можно рассматривать как первую ступень аудита, когда инструменты и методы внутреннего контроля использует сам руководитель, для того чтобы контролировать как работает система управления услугами. Внутренний контроль, выполняемый специализированным внутренним подразделением. можно рассматривать как вторую ступень аудита, а уже всем привычный внешний аудит — как третью.

Обзор стандарта ISO 20000-1 О функции В стандарте нет определения функции. Функции существовали всегда и они также несли ценность. Но при выполнении функции сотрудники никоим образом не думают, как улучшить предоставление функции и сделать ее более ценной. При выполнении функции действует другой принцип — выполнить в рамках регламента. Само понятие услуги предполагает не просто помощь в чем-то, но при этом включает в себя понимание заказчика и его желаемых результатов. В стандарте понятия «функция» просто нет. Возможно, стандарт не обращает на это внимание, потому что в «западном» менталитете понятие функция уже давно заменено понятием услуга, и они привыкли мыслить именно такими категориями.

Также в стандарте ISO 20000-1:2011 сделано множество частных, но от этого не менее важных улучшений. Серьезно расширены термины и определения, причем термины гармонизированы с другими стандартами, прежде всего с ISO 9000.

Перечислим еще несколько важных изменений в ISO 20000-1:2011 по сравнению с версией 2005 года:

1. Управление релизами теперь отнесено к группе «Процессов контроля» вместе с управлением изменениями, что гораздо логичнее, чем было в ISO 20000-1:2005.

2. Кардинально переработан и изменен раздел «Разработка и преобразование новых или измененных услуг». Это отзвуки от жизненного цикла услуги, определенного в ITIL v3. Однако, стандарт 2011 года не определяет жизненный цикл услуги, так как его определяет ITIL v3. И хотя идея жизненного цикла услуги никем не ставится под сомнение, тем не менее, ISO 20000-1:2011 поступает более осторожно. Очевидно, это означает, что жизненный цикл услуги еще обсуждается сообществом. Поэтому он не получил полного отражения, но тем не менее, сделан важный шаг вперед в фиксации идей непрерывного улучшения услуг.

3. Существенно расширен раздел «Управление непрерывностью и доступностью услуг».

4. Существенно расширен раздел «Бюджетирование и учет затрат на услуги».

5. В подраздел «Управление поставщиками» раздела «Управление отношениями»

включен список того, что должен содержать контракт внешнего поставщика с сервиспровайдером.

В стандарте ISO 20000-1:2011 сделано множеСущественно перерабоство небольших, но от этого не менее важных тан раздел «Управление инцидентами». Определен улучшений. Серьезно переработаны и расшистандартный перечень процедур, раздел расширены требования по каждому из процессов рился и стал ближе к ITIL v3. И управление инциуправления ИТ-услугами. Кардинально перерадентами включило в себя ботан раздел «Разработка и преобразование управление запросами на обслуживание (service новых или измененных услуг».

request). Это давняя дискуссия, что есть запрос на обслуживание? Если инцидент — это срыв предоставления услуги или угроза срыва предоставления услуги, то запрос на обслуживание — это угроза или не угроза? Если запрос не выполнен, то, наверное, угроза. На самом деле это вопрос философский, дискуссии не прекращаются уже лет десять. Но многие практики сходились к тому, что они должны быть в рамках одного процесса. И стандарт закрепляет эту практику.

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

–  –  –

Заметим, что стандарт ISO/IEC 20000 становится особенно необходимым при росте роли ИТ-аутсорсинга и облачных технологий, при формировании цепочки поставщиков, которыми уже невозможно управлять в соответствии только с собственным опытом и пониманием ситуации.

Ответственность руководства компании Отметим одну важную особенность стандарта ISO/IEC 20000. Стандарт прямо требует ответственности руководства (Management responsibility) за управление ИТ-услугами. Возможно, это поможет развеять массовую иллюзию, что ИТ могут развиваться и управляться независимо от руководства компании, когда ИТ-директор шестым чувством угадывает, что топ-менеджмент компании хочет и ждет от ИТ. Стандарт ISO/ IEC 20000-1:2011 четко описывает обязательства, которые должен брать на себя топменеджмент компании. Стандарт формулирует требования к участию руководства в формировании политики и целей ИТ, расстановке приоритетов, контроле выполнения планов, обеспечении ресурсами и управлении внешними подрядчиками. Эта его часть может быть использована для установления эффективного взаимодействия ИТ с руководством компании.

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

Непрерывное развитие Наконец, как и всякий стандарт ISO 20000 отражает текущее состояние отрасли и продолжает развиваться и совершенствоваться. Поэтому после выполнения его требований важно не останавливаться на достигнутом, а постоянно совершенствовать процессы управления ИТ. Без постоянного внимания процессы имеют тенденцию «ухудшаться» по мере использования. В области управления ИТ, если стоишь на месте, то неизбежно катишься назад. Стандарты и в частности ISO 20000 являются одним из двигателей, которые заставляют нас не стоять на месте.

Стандарт должен быть использован:

• Компаниями — заказчиками ИТ при формировании стратегии организации, стратегии ИТ, разработке целевой модели архитектуры предприятия, создания корпоративных стандартов в области ИТ.

• Компаниями — поставщиками ИТ при проектировании и развитии бизнес-процессов, формировании организационной структуры, стратегическом и оперативном планировании, взаимодействии с заказчиками на различных стадиях.

• Компаниями — консультантами и аудиторами как шаблон для контроля и оценки ИТ и подготовке рекомендация по улучшению управления ИТ.

–  –  –

На рисунке:

Модель скорострельного автоматического орудия, придуманная Леонардо Да Винчи.

Обзор стандарта ISO 27031.

Информационные технологии.

Методы и средства обеспечения безопасности. Руководство по готовности ИТ к обеспечению непрерывности бизнеса 38 Information Management 01-2011

–  –  –

Управление непрерывностью бизнеса и аварийное восстановление Надо сказать, что в представлении бизнеса, а зачастую и ИТ-специалистов, понятие управление непрерывностью бизнеса нередко отождествляется с аварийным восстановлением после катастроф (Disaster Recovery). Однако основной целью управления непрерывностью бизнеса является поддержание в актуальном состоянии достаточного количества структур, операций и ресурсов (активов), необходимых для стабильного функционирования организации в чрезвычайных ситуациях. Это существенно отличается от понятия аварийного восстановления после катастрофы, которое тесно, если не исключительно, связывается с ИТ.

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

Фрагмент из книги С.А. Петренко, А.В. Беляев, «Управление непрерывностью бизнеса.

Ваш бизнес будет продолжаться». Москва, 2011.

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

Наибольшую известность приобрели: BS25999 (PAS 56), ASIS SPC.1-2009, ISO/DIS 22399:2008, ISO/IEC 22301:2008, NIST SP800-34, NFPA 1600, CSA Z1600, AS/NZS 5050 (HB 292:2006),SS540:2009 (TR19:2004), SI 24001:2007, ISO/IEC 27002:2005 (BS ISO/IEC 17799:2005) (14 раздел), High Level Principles for Business Continuity (2006), COBIT, ITIL и MOF в части BCM и др. Между этими стандартами наблюдается определенное противостояние, прежде всего между американской и европейской школой. Стандарт ISO/IEC 27031:2011 впитал в себя все эти лучшие практики (прежде всего BS25999) и одновременно постарался устранить противоречия.

Роль ИТ в управлении непрерывностью бизнеса Г отовность ИТ к обеспечению непрерывности бизнеса (ICT Readiness for Business Continuity, IRBC) – это важная составляющая часть внедрения и функционирования системы управления непрерывностью бизнеса (наряду с политиками, процедурами и людьми). В результате эффективная система управления непрерывностью бизнеса часто зависит от готовности ИТ гарантировать, что цели организации могут продолжать достигаться при серьезных поломках или разрушениях.

В целом, ИТ, готовое к обеспечению непрерывности бизнеса, должно обеспечивать:

a) ответ на постоянно изменяющиеся риски среды;

b) гарантию непрерывности критических бизнес-операций, поддерживаемых ИТ-услугами;

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

d) реакцию и восстановление после инцидентов/бедствий и отказов.

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

infomanagement.rucio.ru40 Information Management 01-2011

История понимания непрерывности бизнеса Исторически непрерывность бизнеса предполагала, прежде всего, меры защиты от маловероятных, но серьезных событий, таких как пожар, наводнение и другие стихийные бедствия. Однако для современных технологически оснащенных предприятий, функционирующих в реальном масштабе времени, так называемых предприятий реального времени (RTE — real-time enterprise), даже малейшие нарушения в непрерывности бизнес-процессов могут иметь самые серьезные проблемы для бизнеса в целом. Поэтому программы BCM на протяжении последних лет претерпели существенные изменения (рис. 1).

–  –  –

Рис 1. Временная шкала развития подходов к BCM.

В начале 1990-х программы BCM подразумевали восстановление после катастрофы, а также защиту от стихийных бедствий и масштабных отказов путем перехода в течение 72 часов на другой вычислительный центр. В середине 1990-х появились планы восстановления, аналогичные планам восстановления для центров телефонной поддержки клиентов. В преддверии проблемы 2000 года программы BCM были пересмотрены, и оказалось, что традиционные планы восстановления с 72-часовым периодом восстановления стали неадекватны требованиям бизнеса. Потребовалось сокращение периодов восстановления до 4–24 часов.

Появление электронной коммерции и предприятий реального времени потребовало очередного пересмотра периодов восстановления в сторону уменьшения. Дело в том, что простой вычислительных мощностей в течение 4–24 часов для многих предприятий RTE означал бы непоправимые убытки и даже, возможно, крах своей успешной бизнес деятельности. Поэтому потребовались программы BCM, позволяющие обеспечить готовность ИТ-сервисов в режиме 247 (24 часа в день, 7 дней в неделю). Технологически это означает, что такие показатели, как целевое время восстановления (RTO — recovery time objective, определяет, насколько быстро ИТ-сервисы способны вернуться в работоспособное состояние после инцидента) и точка восстановления (RPO — recovery point objective, определяет последнюю по времени резервную копию, с которой будет происходить восстановление), были сокращены и приближены к показателям реального времени.

Террористические акты 11 сентября 2001 года в США и осенью 2004 года в Москве, ряд крупных энергетических кризисов: в 1996 году в западных штатах США, в 2002 году в Буэнос-Айресе, в 2003 году в США и Канаде;, в 2006 году в Москве, в 2009 году в России на Саяно-Шушенской ГРЭС заставили предприятия пересмотреть свои программы BCM, так как большинство предприятий оказались не способными справиться с подобными событиями. Предприятия стали больше внимания уделять человеческому фактору, антикризисному управлению и планированию на случай сценариев гибели людей, отсутствия транспорта и полного физического разрушения активов.

Фрагмент из книги С.А. Петренко, А.В. Беляев, «Управление непрерывностью бизнеса. Ваш бизнес будет продолжаться». Москва, 2011.

Обзор стандарта ISO 27031

–  –  –

Управление непрерывностью бизнеса и CIO Как правило, на вопросы непрерывности бизнеса первым обращает внимание ИТ-зависимый бизнес как более зрелый с точки зрения организации и ведения бизнеса. Понятно, что обеспечение непрерывности бизнеса не является исключительно задачей ИТ. Но зачастую именно ИТ-специалисты становятся локомотивами процессов обеспечения непрерывности бизнеса в организации. Отчасти ситуация обусловлена тем, что они являются вечными «стрелочниками»: вина за любой сбой в работе организации, связанный с информационными системами, автоматически ложится на ИТ-службу. Во многих компаниях большая часть рисков переносится руководством в ИТ-сферу, что далеко не всегда правомерно, но, к сожалению, в настоящее время это довольно распространенная практика.

Фрагмент из книги С.А. Петренко, А.В. Беляев, «Управление непрерывностью бизнеса.

Ваш бизнес будет продолжаться». Москва, 2011.

–  –  –

Место стандарта ISO/IEC 27031:2011 в пирамиде управления Стандарты, связанные с ИТ, можно разделять по трем уровням: стратегическому, операционному и техническому уровню. Стандарт ISO/IEC 27031:2011 явно не относится к техническому уровню -- он не содержит технических деталей, которые есть в MOF, или скажем в методологии IBM. Стандарт специально не затрагивает технические детали, чтобы не заходить на территорию производителей. При этом стандарт так же практически не охватывает стратегический уровень. Несмотря на то, что стандарт содержит раздел «Выходы и преимущества от IRBC», уровень бизнеса он не затрагивает. То есть влияние принятых мер на бизнес-показатели компании и другие KPI стандарт ISO/IEC 27031:2011 не описывает. В основном стандарт сосредоточен на операционном уровне.

При этом надо понимать, что при реализации стандарту ISO/IEC 27031:2011 крайне необходим верхний, стратегический уровень. Меры и действия, предложенные в стандарте, должны проистекать из стратегии бизнеса, стратегии информационной безопасности и стратегии управления непрерывностью бизнеса (BCM), поддержанной соответствующими показателями и KPI.

–  –  –

О терминах Традиционно в российской практике говорили не о непрерывности и аварийном восстановлении, а об отказоустойчивости, устойчивости и живучести. И с точки зрения русского языка, наверное, так правильнее. Надо сказать, что у нас еще в 2002 году на уровне ГОСТ были определены понятия отказоустойчивости, устойчивости и живучести. Также было определено понятие «критическая важная структура» или «критический важный объект». В 2004 году на федеральном уровне в России была попытка принять ФЗ, который так и назывался «Устойчивость и безопасность функционирования критически важных объектов» (этот ФЗ не был принят). Тем не менее, с начала 2000 годов, в основном под влиянием западных консалтинговых компаний, распространились и активно используются термины непрерывность и аварийное восстановление.

Обзор стандарта ISO 27031 Управление непрерывностью бизнеса на практике Начнем с инцидента.

–  –  –

Наверняка, почти всем ИТ-директорам знакома такая или очень похожая ситуация.

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

Комплексное и системное решение подобных проблем возможно только в рамках программы построения ИТ, обеспечивающего непрерывность бизнеса (ICT Readiness for Business Continuity, IRBC). И в стандарте ISO/IEC 27031:2011 дана четкая структура действий по построения таких ИТ (рис 5), на которую необходимо опиратьопирать ся. Самое первое, Комплексное и системное решение проблем, что надо сделать — провести оценсвязанных с влиянием ИТ-инцидентов на бизнес ку влияния потенкомпании, возможно только в рамках программы циальных инцидентов на бизнес построения ИТ, обеспечивающего непрерывность (Business Impact Analysis) и опребизнеса (ICT Readiness for Business Continuity, IRBC).

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

–  –  –

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

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

• выработать требования к ИТ;

• разработать стратегию построения ИТ, обеспечивающего непрерывность бизнеса;

• внедрить эту стратегию, составить план построения ИТ, обеспечивающего непрерывность бизнеса, а также другие необходимые планы;

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

• совершенствовать как процессы, так и саму ИТ-поддержку непрерывности бизнеса.

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

–  –  –

Таблица. 2.

Примерный план создания и внедрения корпоративной программы управления непрерывностью бизнеса Как придти к необходимости управления непрерывностью бизнеса?

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

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

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

3. Выполнение требований нормативных актов. Обеспечение непрерывности бизнеса диктуется не только внутренней необходимостью, но и рядом законодательных норм. В западной практике, которая объективно на полтора-два десятилетия раньше столкнулась с проблемами непрерывности бизнеса, спектр законодательных норм очень обширен. К сожалению, отечественная законодательная и нормативная база в области управления непрерывностью бизнеса только формируется. Сегодня разработан только ряд единичных общих и отраслевых стандартов, касающихся этой темы. Четкие требования регулятора есть только от Банка России.

4. Устранение замечаний аудиторов. Любая внешняя аудиторская проверка обращает внимание на необходимость разработки и внедрения корпоративной программы управления непрерывностью бизнеса. Особое внимание уделяется «Плану обеспечения непрерывности бизнеса», «Плану антикризисного управления» и «Плану аварийного восстановления».

Information Management Н а у ч н о - м е то д и ч е с к и й ж у р н а л д л я п р о ф е с с и о н а л о в И Т

–  –  –

Пол Страссман — признанный гуру в области информационных технологий, известен в США своими исследованиями в области экономики информатизации.

Книги и статьи Пола Страссмана практически не переведены на русский язык.

Поскольку, на наш взгляд, их знание необходимо любому профессионалу, связанному с инвестициями в ИТ, мы начинаем цикл статей, кратко и реферативно знакомящий вас с находками и идеями Пола Страссмана. Реферат составил Константин Зимин.

Пол Страссман Получил степень магистра менеджмента в Массачусетском Технологическом Ин ституте. В течение долгих лет был руководителем ИТслужб крупных предприятий.

В 19601969 годах был CIO компаний General Foods и Kraft. В 1969 году пришел в Xerox, с 1972 по 1976 годы был CIO этой компании а с 1976 по 1978 годы — дирек тором, отвечающим за ИТ и административные функции. После ухода из Xerox кон сультировал такие компании, как AT&T, Citicorp, Digital Equipment, General Electric, General Motors, IBM, ING, Shell Oil, Sun Microsystems и Texas Instruments.

В 1990 Пол Страссман пришел в Министерство Обороны США на недавно создан ную должность Director of Defense Information и по 1993 год руководил созданием корпоративной информационной системы и перестройкой всей информационной инфраструктуры Министерства Обороны. В 2002 году снова поступил на государ ственную службу став CIO NASA. В 2003 году ушел на пенсию, за улучшение ИТ архитектуры и сервисов получив награду NASA Exceptional Service.

Основав собственную компанию, он посвятил себя анализу того, чему служил всю жизнь — влияния инвестиций в ИТ на бизнес.

К мнению Пола Страссмана прислуши ваются государственные и правительственные структуры США и Великобритании:

он неоднократно выступал в Сенате, Палате представителей и правлении ФРС США, а также Палате общин Великобритании. Член Federal Advisory Board for Information Management Министерства Обороны США. Профессор Information Sciences в уни верситете Джорджа Мейсона. Автор более 250 статей и целого ряда книг.

В книге «The Squandered Computer» («Разоряющий компьютер»), вышедшей в 1997 году, используя огромную статистическую базу публичных компаний, Пол Страссман убедительно показал, что никакой явной корреляции между размером инвестиций в информационные технологии и прибыльностью предприятия не существует.

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

Основные из них:

• Strassmann, Paul A. «Information Payoff, The Transformation of Work in the Electronic Age.» The Free Press, 1985.

• Strassmann, Paul A. «The Squandered Computer — Evaluating the Business Alignment of Information Technologies.» Information Economics Press, 1997.

• Strassmann, Paul A. «The Business Value of Computers — An Executive’s Guide.» Information Economics Press, 1997.

• Strassmann, Paul A. «Information Productivity — Assessing the Information Management Costs of U. S. Industrial Corporations.» Information Economics Press, 1999.

• Thomas Pisello, Paul Strassmann «IT Value Chain Management — Maximizing the ROI from IT Investments» The Information Economics Press, 2003.

–  –  –

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

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

Компьютерный парадокс Роберта Солоу

–  –  –

Исследование McKinsey Global Institute В 2001 г. консалтинговая компания McKinsey опубликовала результаты исследований, посвященных влиянию расходов, связанных с ИТ, на эффективность. Доклад «Рост производительности труда в США в 1995–2000» был издан научным центром McKinsey Global Institute и является результатом годовой работы, проводившейся при поддержке комиссии экспертов, возглавляемой все тем же Робертом Солоу. Исследователи исполь зовали правительственные статистические данные о занятости и расходах на ИТ, пытаясь количественно определить выгоды и выявить связь между расходами и ростом эффек тивности компаний. Были проанализированы самые разные отрасли, но взаимосвязи в целом, найдено не было.

Вот некоторые итоги этого исследования:

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

2. Зависимость между ИТ и производительностью статистически не прослеживается.

3. За исключением редких случаев совершенствование ИТ не дает заметного роста производительности труда.

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

–  –  –

EVA = EBIT x (1T) — WACC x CE Где EBIT — величина доходов до уплаты налогов и процентов;

T — ставка налога на прибыль (в долях единицы);

WACC (Weighted Average Cost of Capital) — средневзвешенная цена капитала;

CE (Capital Employed) — сумма инвестированного капитала с учетом эквивалентов собственного капитала.

Этот показатель представляется собой сумму стоимости всех активов, относящихся в оперативном управлени, за вычетом краткосрочных операционных обязательств (коммерческих кредитов, задолженностей перед бюджетом и т. п.). Таким образом, произведение WACC x CE — это плата за акционерный капитал.

Реферат работ Пола Страссмана Расходы на ИТ и производительность компании Т езис № 1, который считается само собой разумеющимся — использование ИТ увели чивает производительность труда в компании в целом.

Детальные исследования, проведенные на основе данных из финансовых отчетов и вышеприведенной методологии, дают обескураживающие результаты. Обследование более 10 тыс. компаний в разных странах показало отсутствие заметной корреляции между расходами на ИТ и ростом производительности компании, выраженным в EVA, либо какимлибо иным ключевым показателем эффективности бизнеса, вроде рента бельности капитала, рентабельности активов или прибыльности (рис 1). C макроэко номической точки зрения те, кто тратит на ИТ больше других, далеко не всегда доби ваются преимущества в продуктивности. Более 40 % исследованных компаний вообще не могут добиться положительной рентабельности капитала. Компании с наименьшими ИТбюджетами в расчете на одного сотрудника имеют такие же шансы получить поло жительную рентабельность капитала, что и компании, тратящие на ИТ очень много.

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

Налицо отсутствие взаимосвязи между расходами на ИТ и производительностью компа нии. «Компьютерный парадокс» подтверждается.

–  –  –

Интенсификация труда «информационных»

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

Первоначальные инвестиции в ИТ были сконцентрированы на «механизации» повто ряющихся задач офисных и административных работников. Это привело к уменьшению требуемого количества такого персонала. Так, с 1983 по 1999 годы количество офисных и административных работников в США увеличилось лишь на 14,2 %. Тогда как количе ство менеджеров и руководящих работников — выросло на 83,6 %2. Широкое распро странение компьютерных систем привело к падению соотношения между количеством менеджеров и руководящих работников и офисных и административных на 20 %. При сохранении тех соотношений, которые были в 1983, к 2000 году потребовалось бы дополнительно 9.7 миллиона офисных сотрудников, и около 400 млрд. долл. допол

–  –  –

В 1990 году Пол Дэвид опубликовал работу The Dynamo and the Computer: An

Historical Perspective on the Modern Productivity Paradox («Генератор и компьютер:

современный парадокс продуктивности в исторической перспективе»). В этой работе впервые (насколько это известно нам) проводится анализ аналогий между ИТ и электричеством. Как показывает Пол Дэвид исторических параллелей, между развитием электричества в начале 20 века и ИТ в его конце, достаточно много. И прежде всего, эти исторические параллели позволяют объяснить парадокс производительности, сформулированный Робертом Солоу в 1987 году: «мы видим компьютеры везде, кроме статистики производительности». Пол Дэвид один из первых смог нащупать пути объяснения этого парадокса. Реферат составил Константин Зимин.

–  –  –

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

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

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

Является ли ИТ «технологией общего назначения» — вопрос не такой простой, хотя большинство экономистов придерживаются именно такой точки зрения.

Но, как мини мум, очевидны некоторые параллели:

• использование ИТ, как и электричества требует создания сложных распределенных сетей, порождающих проблемы совместимости и стандартизации; ИТ как и элек тричество важно не само по себе, а как важная, но не единственная часть очень сложных технических взаимодействий, операций и процессов;

• в ИТ как и в электричестве мы можем проследить долгий путь постепенных техни ческих усовершенствований;

• в ИТ как и в электричестве наблюдается процесс постепенного проникновения технологии в бизнессреду компаний;

• в ИТ как и в электричестве происходит активное слияние с другими потоками тех нических инноваций.

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

–  –  –

Причины запаздывания роста производительности Причина №1: наложение технологических режимов История электрификации начиная с 1900 года во многом свидетельствует о спра ведливости тезиса «о наложении технологических режимов», сформулированного Кристофером Фриманом и Карлоттой Перес в 1990 году. Они предположили, что рост производительности замедляется и остается на низком уровне в результате возник новения нового техникоэкономического режима и его противоборства со старым.

Становление нового режима может оказаться долгим и подверженным множеству исто рических случайностей. Конечно, преобразование промышленных процессов под воз действием электротехнических инноваций было затяжным, и до настоящей автомати зации тогда было далеко. Новый режим набрал понастоящему мощный импульс в США не раньше 1914–1917 годов.

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

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

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

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

Подобное наложение новой технической системы на предшествующий уровень — обычное явление в истории переходов от одних технологических парадигм к другим.

Причина №2: необходимость серьезных изменений в инфраструктуре и кадрах Было бы ошибкой полагать, что потенциальные выгоды, связанные с электрификаци ей заводов, можно было бы реализовать уже в начале 20 столетия, просто благодаря наличию дальновидных инженеровэлектротехников, осознающих возможную эконо мию от внедрения гибкой системы передачи электроэнергии по проводам, и замене механических трансмиссионных передач на индивидуальные электроприводы. Когда, индивидуальные электроприводы стали использоваться, для заводов это обернулось множеством дополнительных преимуществ и проблем.

Дело в том, что после того как отпала нужда в креплениях, поддерживавших тяжелые валы и системы ременных приводов, инфраструктура заводов претерпела огромные изменения.

Это позволило:

• уменьшить вложения в основной капитал, поскольку инфраструктура заводов стала более легкой;

• уделить большее внимание оптимизации обработки материалов и реконфигурирова нию размещения производственного и погрузочноразгрузочного оборудования.

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

–  –  –

Объекты контроля для ИТ-проекта Ч то можно контролировать в проекте? Очевидно, что в проекте, как и в реальной You cannot plan everything, жизни, можно контролировать все. Точнее, можно попытаться контролировать but plan everything you все. Но только в реальности это не получится — например, вам не удастся собрать plan to control.

всю необходимую информацию. Или вы ее соберете, но она уже устареет. Или вы ее соберете, она не устареет, но вы не успеете с ней до конца разобраться изза ее объема.

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

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

Так что приходится выбирать… С формальной точки зрения для целей контроля проект можно представить как состоящий из работ и результатов. Развивая эту нетривиальную мысль можно отметить, что работы разделяются на работы по управлению проектом и на работы по собственно созданию результатов (работы предметной области) (рис 4).

–  –  –

Определения инновационного проекта

Определение проекта, которое дает PMBOK 2004, следующее:

Проект — это временное предприятие, осуществляемое для создания уникального продукта или услуги.

Определение проекта по стандарту BS 6079:2000 немного другое:

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

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

В своей деятельности в «Оргкомитете Сочи 2014», я взял за основу определение, которое в явном виде вводит некоторое ограничение (рис.5):

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

–  –  –

Зачем необходимо контролировать проект?

Э Истинное знание — то главный вопрос. Даже если вы руководитель проектного офиса и в вашей знание причин.

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

Чтото приходится контролировать более плотно, чтото менее детально. Гдето необ ходимо участвовать в приемке результатов, гдето достаточно только просматривать отчеты. Кудато надо прийти с аудитом, а комуто стоит просто послать контрольный список для самостоятельной проверки. Не ответив на вопрос «зачем?» невозможно понять, насколько глубоко необходимо погружаться в проект.

–  –  –

• контрольные точки;

• отчеты проекта;

• собрания;

• встречи один на один.

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

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

Замечу, что, определив инструмент, следует определить и периодичность его исполь зования.

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

1. Уровень запроса. От кого поступил запрос на контроль: если от топменеджмента, то это один приоритет, если запроса не было, то другой.

2. Стратегическая важность и срочность проекта. Стратегический проект требует большего внимания, низкоприоритетный — меньшего.

3. Сложность и масштаб проекта. Очевидно, что в проекте высокой сложности больше подводных камней и больше опасность провала. Необходим более плотный контроль.

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

Эти моменты, характеризующие окружение и природу самого проекта, необходимо както оценить. Можно дать качественную оценку (высокая важность / низкая важность).

А можно формализовать, построив оценочную таблицу: например, по каждому из кри териев проставить оценку от 1 до 3, и смотреть на итоговый балл по проекту. Чем выше балл — тем важнее проект с точки зрения контроля, тем больше инструментов нужно применять и тем глубже надо вникать в проект.

Дополнительные критерии, которые могут повлиять на решение о необходимости контроля, а также глубине контроля:

• величина бюджета проекта;

• длительность проекта;

• численность проектной команды;

–  –  –

контроль. Если все плотно контролиро вать, члены проектной команды пере стают чувствовать свою ответствен ность за результаты работы и теряют мотивацию. Контролировать так, чтобы никто не вздохнул, — это, похоже, чисто российское изобретение и сильнейший Глубина контроля демотивирующий фактор. Особенно это гибельно для проектных менеджеров — придавленный, несамостоятельный руководитель проекта — уже совсем не руководи тель проекта. Руководителем проекта de facto становитесь вы.

Втретьих, контроль несет за собой необходимость принимать решения и, соответ ственно, нести ответственность за результаты этих решений. Исчезает возможность сказать: «Ну вот, они тут все напортачили. Меня на них не было…».

Учитывая все это, стоит сильно задуматься, насколько вам нужен этот самый контроль.

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

При этом эффективность контроля и все связанные с ним риски и выгоды.

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

–  –  –

Я несколько раз слушал лекции/семинары Игоря Альтшулера. И каждая из этих встреч запускала серию длительных раздумий. «Я занимаюсь апгрейдом мозгов…», — написал во вступлении к своей книге «Записки консультанта» Игорь Альтшулер. Чем бы ни занимался Игорь Альтшулер, бизнес-анализом и консультациями, преподаванием, писанием книг или стихов, «апгрейд мозгов» у него получается стратегический — не просто переход на новую версию, а на совсем новую платформу.

Именно поэтому в первом выпуске нашего журнала я посчитал необходимым сделать интервью с Игорем Альтшулером. Оно состоялось в небольшой комнатке кафедры «Системы управления бизнес-процессами» Академии народного хозяйства. (Большое спасибо Татьяне Соколовой, заместителю директора Школы ИТ-менеджмента Российской академии народного хозяйства и государственной службы при Президенте РФ, где преподает Игорь Альтшулер, за то, что приютила нас.) «Апгрейд мозгов» ведь дело тонкое, он не любит трибун и больших пространств.

Игорь Альтшулер Работал инженером и начальником отдела автоматизации на предприятиях г.

Горького. Затем был директором по развитию, советником генерального директора, вице-президентом нескольких ИТ и консалтинговых компаний. Вицепрезидент Первой Нижегородской гильдии профессиональных консультантов, член Правления российской Ассоциации консультантов по управлению и организационному развитию. В различное время был членом совета директоров компаний «Галактика», «Синтез», «Дзержинское оргстекло». С 2002 по 2009 годы член, затем председатель Совета директоров ОАО «Труд».С 2003 член, затем председатель Правления фирмы «Солвер». С 2010 года член Наблюдательного совета ОАО «Импульс», с 2011 года член Совета директоров ОАО «Совхоз им.Кирова». Преподавал в Шведском институте менеджмента IFL. Доцент кафедры общего и стратегического менеджмента «НИУ-ВШЭ Нижний Новгород». Доцент кафедры «Системы управления бизнес-процессами» Российской академии народного хозяйства и государственной службы при Президенте РФ.

Пишет стихи и рассказы. Увлекается классической музыкой, живописью, литературой, шахматами, фотографией. Личный сайт www.altshuler.ru

–  –  –

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

Аналогия прямая: топ-менеджер — это его клиент, которому надо помочь.

Здесь встает вопрос профессионализма ИТ-директора. Конечно, ИТ-директор, который записывает все слова своего клиента — это не профессионал, потому что клиент — это создание весьма бессвязное. ИТ-директор, который диктует клиенту, что ему надо — это тоже не профессионал, потому что востребовано это не будет. Можно бежать впереди паровоза, только очень недолго.

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

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

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

менеджера на грамотное целеполагание.

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

Поэтому главная задача ИТ-директора — подготовка клиента, формирование его ожиМиф первый: любой руководитель нуждается в информации (из книги И.Альтшулера «Практика бизнеса. Записки консультанта») Оборонный завод до сих пор из последних сил произво- опытным дипломатом. «Я могу сказать одно, — отведит некую нужную военным продукцию. На мой вопрос: тил он, — и директор по производству, и финансовый «когда Минобороны последний раз оплачивало эту про- директор — мои ближайшие помощники, я не первый год дукцию?» — директор ответил: «Да года два назад. с ними работаю и полностью им доверяю».

Но мы не сдаемся. Пока хоть один рабочий на предпри- Стали разбираться и выяснили, что одни службы живут ятии есть, будем делать то, что умеем». Количество по декадному циклу, а другие — по недельному, что одни работников на славном некогда заводе сократилось бо- считают проданной продукцию, выехавшую за ворота лее чем в 10 раз, более половины территории сдается завода, а другие — лишь ту, по которой поступила оплав аренду различным торговым фирмам, а директор про- та и т. д. Директор же, получая заведомо «несводимую»

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

щания генералов, отсутствие маркетологов и т. п. Может ли помочь такому руководителю любая инфорПару лет назад мы проводили семинар на одном из заво- мационная система? Думается, что нет. Ибо у рукодов Нижегородской области. И в ходе семинара я задал водителей подобного типа просто нет желания восего участникам простой, как мне казалось, вопрос: какой принимать и анализировать внешнюю информацию, объем продаж у вас был в апреле? Финансовый директор что-то менять в своей работе, заставлять договарисказала: «790 тысяч рублей», директор по производ- ваться других людей. Они сознательно загоняют себя в ству — «1 миллион 200 тысяч». Удивившись, я обратил- условия «острой информационной недостаточности», ся к генеральному директору: «Так сколько же все-таки и итог их деятельности в условиях рынка практически продукции вы продали в апреле?». Генеральный оказался предопределен.

–  –  –

Энтузиаст, прагматик, скептик, старик и фанатик Константин Зимин: К ИТ-директорам мы еще вернемся, а сейчас давайте пого- …он в кругу.

Он во вращенье.

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

• энтузиаст: «ИТ — это совершенно необходимая вещь, без них сейчас никак нельзя»; рад бы он прервать

• прагматик: «ИТ — неплохой инструмент, но применять надо только там, где это движенье, разумно»; пролетел — и не успел.

• скептик: «ИТ — это всё модные «западные» игрушки, не до них, надо делом заниИ Альтшулер.

маться»;

• старик: «ИТ — слишком заумные штуки, это пугает, лучше быть подальше от них».

Естественно, наиболее сбалансированное и трезвое отношение к ИТ у «прагматика».

А «энтузиаст» все-таки немного поддается влиянию моды, своего интереса к новым технологиям и т. д. «Скептик» же, напротив, приобрел основной опыт управления раньше, чем стали активно применяться ИТ. Согласны вы с такой моделью?

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

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

Возникает не просто прозрачность, а упорядоченность отношений и возможность контроля, возникает определенная дисциплина.

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

Целеполагание и целеполучение Яркий пример: не буду называть компанию, но в ней директор пожелал, чтобы все совещания записывались на видео. ИТ-директор исполнил, это не сложно. Но потом директор попросил: «а найди, что мы там говорили три недели назад». ИТ-директор объяснил, что это не база данных и он не знает, как найти нужный фрагмент совещания. «Зачем же ты записывал?» — удивился директор.

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

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

–  –  –

Миф второй: чем больше информации тем лучше (из книги И.Альтшулера «Практика бизнеса. Записки консультанта») Очень часто «фанатики» впадают в крайность — Руководитель боится делегировать полномочия информационное «обжорство». Пример из соб- вниз (не хочет терять власть, не уверен в собственной консультационной практики. На столе ственных замах, и тем более — в среднем зверуководителя крупного комбината — кипы пер- не управленцев, не умеет отделять главное от вичной документации, ее приносят снабженцы, второстепенного), а управленцы более низких сбытовики, основные и вспомогательные произ- уровней боятся ответственности и стремятся водства. По 3–4 часа в день руководитель просма- переложить, делегировать ее наверх, «как бы чего тривает эти «залежи», выхватывает какие-то не вышло». В результате наверху возникают наотдельные цифры, вызывает к себе сотрудников, туральные «пробки», директор ежедневно занимаустраивает им разносы. Ассортимент даже гото- ется решением множества управленческих задач вой продукции (около 200 позиций) слишком велик, не своего уровня — например, разбирается, почему чтобы уловить взаимосвязи и тенденции в этом какой-то поставщик прислал не то, что ему захаосе, поэтому директор пытается чем-то управ- казывали. Естественно, времени на решение стралять, но реально мало что получается. тегических вопросов при этом не остается.

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

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

О целеполагании Константин Зимин: Давайте вернемся к проблеме целеполагания. Ведь непра- Необходима цель вильное целеполагание — самая распространенная ошибка руководства. стране и человеку, Игорь Альтшулер: Согласен, это классическая ошибка. Возьмем проблему: не Минуте, дню и веку необходима цель.

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

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

Константин Зимин: Но даже если ИТ-директор понимает это, исправить положение очень сложно. Что сказать директору — «подожди, ты ерунду говоришь, надо снасна чала найти реальную проблему»?

Директор должен сформулировать цель, Опасно… ИТ-директор, немного «пободавшись», Игорь Альтшулер: Опасно.

Но еще раз повторяю — ИТ-директор принять ее.

Это классические функции:

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

сказать по сути все то же самое, но гораздо аккуратней и вежливей.

Например, «я не уверен, что система документооборота решит эту проблему, может быть нам попробовать вот это». То есть попытаться аккуратно натолкнуть директора на другие варианты решения. И лучше всего, приводя примеры. «Соседи, потратив массу денег и времени на систему документооборота, не получили того результата, который хотели, поэтому стоит ли нам идти лишь этим путем? А нельзя ли вместе с этой темой рассмотреть еще и вот эту, эта мера может усилить ту, которую вы, как директор, гениально уловили и обозначили». Чистая дипломатия.

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

–  –  –

Красивые «сказки» об ИТ Константин Зимин: Но кроме неспособности ИТ-директоров презентовать руководству результаты и возможные выгоды от использования ИТ, здесь есть еще один аспект. Подавляющее большинство выгод и эффектов от ИТ носят не объективноколичественный характер, а субьективно-качественный. Собственно весь маркетинг поставщиков ИТ строится не на объективных количественных данных, а на красивых «сказках», обрамленных правильными, но крайне размытыми словами о прозрачности, едином информационном пространстве, повышении управляемости и т. д. Объективных количественных данных об эффективности инвестиций в ИТ практически нет. Что в таком случае презентовать руководству? Повторять те же красивые «сказки» — как-то стыдно это пересказывать для думающего человека… …Здесь мы вынуждены прерваться. Читайте продолжение интервью с Игорем

Альтшулером в следующем номере:

• Красивые «сказки» об ИТ

• Миф третий: предприятие может и должно работать как часы

• Типы ИТ-директоров

• Научить ИТ-директора кататься • «Айтишник» на совете директоров

–  –  –

Более двух тысячелетий назад, примерно в V веке до н. э. был написан классический трактат Сунь-цзы «Искусство войны». В настоящее время доступна четвертая версия свода рекомендаций по управлению проектами PMBOK. Сравнив трактат и стандарт, вы найдете немало общего, хотя между ними более двух тысячелетий. Поэтому я сделал интерпретацию текста трактата «Искусство войны» применительно к управлению проектами и назвал ее «PMBOK от Сунь-цзы».

Мне пока неизвестны подобные интерпретации, хотя не я первый, увлеченный идеями Сунь-цзы, пытался интерпретировать текст трактата по отношению к другим областям деятельности, связанными с борьбой, противостоянием, соперничеством:

«Сунь-цзы и искусство бизнеса» (М. Макнилли), «Искусство войны для менеджеров»

(Д. Михаэльсон), «Искусство войны и искусство управления» (Г. Галиарди).

Алексей Головин

–  –  –

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

2. Поэтому в ее основу кладут пять явлений [ее 2. В основе проекта лежат пять явлений.

взвешивают семью расчетами и этим определяют положение].

Существует достаточно много переводов трактата Сунь-цзы «Искусство войны». Оригинал написан на древнекитайском языке, поэтому и толкований и интерпретаций текста столько же, сколько и переводов. Мной использован перевод, выполненный советским академиком Н.И. Конрадом в 1950 году. Данный перевод основывается на классической версии, и с моей точки зрения менее других подвергся осовремениванию. Хотя для лучшего понимания идей Сунь-цзы я пользовался и другими переводами.

–  –  –

Текст трактата краток. Мысли Сунь-цзы часто носят сжатый и абстрактный характер. Это потому, что он излагает некий канон, который не нужно объяснять — ему надо следовать. Тем не менее Сунь-цзы не устает повторять, что используя правила не нужно бояться отступать от них — и это тоже правило.

8. Во время войны государство беднеет оттого, что 8. Лучше выполнять проект на собственные средвозят далеко провиант. Когда провиант нужно ства и по возможности собственными силавозить далеко, народ беднеет. ми. Нанятые консультанты и заемные средства дороги.

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

10. Силы подрываются, средства иссякают, у себя 10. Дорогой проект может оказаться разорительв стране — в домах пусто; имущество народа ным для организации, пострадают и работники уменьшается на семь десятых; имущество прави- и руководство.

теля — боевые колесницы поломаны, кони изнурены; шлемы, панцири, луки и стрелы, рогатины и малые щиты, пики и большие щиты, волы и повозки — все это уменьшается на шесть десятых.

11. Поэтому умный полководец старается кор- 11. Поэтому умный руководитель проектов стамиться за счет противника. При этом один фунт рается добиться скидок от поставщика, готов пищи противника соответствует двадцати фунтам предоставить поставщику свои маркетинговые своей; один пуд отрубей и соломы противника услуги (референс-визиты, публикации) в обмен соответствует двадцати пудам своей. на скидки.

12. Вы можете не только убить врага, но и лишить 12. Если у проекта есть противники, противодейего сил. Для того чтобы неприятель лишился сил, ствовать им можно, завладев ресурсами (финандостаточно завладеть его припасами. совыми, человеческими).

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

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

–  –  –

«Искусство войны» состоит из тринадцати глав, каждая из которых посвящена конкретной теме. Главы относительно самостоятельны, поэтому не следует рассматривать первую главу как введение, а последнюю — как заключение. В следующем номере читайте:

Часть 3. Стратегия ведения проекта.

Часть 4. Тактика ведения проекта.

В следующем номере Information Management (№2 2011) читайте:

Information Management. Стандарты Проблемы применения стандартов в РФ и пути их решения. Через пропасть стандартов — в два прыжка.

Обзор Евгения Зиндера.

Обзор стандарта ISO/IEC 20000-2. Information technology - Service management — Part 2: Code of practice и ГОСТ Р 20000-2:2010 «Кодекс практической деятельности». Обзор новой версии стандарта ISO/IEC 20000-2, которая находится на стадии финального голосования.

Обзор российского стандарта по проектному управлению, который готовится к принятию — ГОСТ «Проектный менеджмент. Требования к управлению проектом. Рекомендации по его использованию в компаниях».

Information Management. Исследования и методологии Четыре объяснения «парадокса продуктивности ИТ». Обзор исследований эффективности инвестиций в ИТ. Реферат работы Эрика Бринйолфсона.

Затраты на ИТ и выручка компании. О чем говорит показатель ИТ-бюджет/выручка? Реферат работ Пола Страссмана.

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

Information Management. Приложения Типология ИТ-директоров и коктейль из надежд, угроз и результатов. Окончание интервью с Игорем Альтшулером.

Искусство ведения проектов. PMBOK от Сунь-цзы. Искусство ведения проектов. Главы 3 и 4. Интерпретация

Похожие работы:

«ОРГАНИЗАЦИЯ A ОБЪЕДИНЕННЫХ НАЦИЙ ГЕНЕРАЛЬНАЯ АССАМБЛЕЯ Distr. GENERAL A/HRC/WG.6/2/TON/2 7 April 2008 RUSSIAN Original: ENGLISH СОВЕТ ПО ПРАВАМ ЧЕЛОВЕКА Рабочая группа по универсальному периодическому обзору Вторая сессия Женева, 5-16 мая 2008 года ПОДБОРК...»

«ВЫПУСК 3 ИМПЕРИЯ, ЭТНОСЫ, НАЦИОНАЛИЗМ, ПЛЮРАЛЬНАЯ АНТРОПОЛОГИЯ Москва Евразийский Союз Молодежи ББК 60.5;63.5 Э 91 Гл а в н ы й р е д а к т о р д. пол. н. А. Г. Дугин Редактор-составитель Бовдунов А. Л. Н ау ч н о р ед а к ц и о н н а я кол л е г и я Д. ист. н. В. Э. Багда...»

«АДМИНИСТРАЦИЯ ПЕТРОВСКОГО МУНИЦИПАЛЬНОГО РАЙОНА САРАТОВСКОЙ ОБЛАСТИ РАСПОРЯЖЕНИЕ от 26 января 2017 года № 29-Р г.Петровск О закреплении территорий за образовательными учреждениями Петровского муниципального района Саратовской области В соответствии с Федеральным законом...»

«1 Председателю Верховного суда РФ Лебедеву В. М. ЖЕРТВА нарушения Конституции и Европейской Конвенции по правам человека Иванова Ирина Александровна, Проживающая по адресу: FRANCE: 6, place du CLAUZEL app 3, 43000 Le Puy en Velay, + 33 4 71 09 61 77 Электронный адрес –электронная подпись : irina.merrypoppins444@gmail.com ЗАЯВЛЕНИЕ о пе...»

«А. В. Подосинов МЕСТО ЛАТИНСКОГО ЯЗЫКА В ЦИКЛЕ ГУМАНИТАРНОГО ШКОЛЬНОГО ОБРАЗОВАНИЯ Аннотация В европейской образовательной традиции классическая гимна зия, в которой изучают древние языки, до сих пор остается куз...»

«Игровое занятие в виде суда "Кто победил в Бородинской битве?" Автор разработки: Клепикова В.В. (сайт egevmeste.ru) Предлагаемый материал представляет собой вариант урока-игры на тему “Бородинская битва”. Урок-суд "Кто победил...»

«IN70 Series Руководство пользователя Перед настройкой проектора прочитайте инструкции по технике безопасности. Распаковка коробки 1 В коробке имеется: Компакт-диск Проектор Пульт дистанционного управления Кабель композитного видео Шнур питания M1-DA – HDMI (IN78) Установите батарейки в п...»

«33 1 (190), 2015 ISSN 2076-4855 УДК 070:004.738.5(476) А.А. Градюшко ИНТЕРНЕТ-ВЕРСИЯ РАЙОННОЙ ГАЗЕТЫ В УСЛОВИЯХ КОНВЕРГЕНЦИИ МЕДИАПРОСТРАНСТВА В статье рассмотрены творческие инновации региональной веб-журналистики Белар...»

«Какие травы пить при простуде, какие травы помогают при простуде эти вопросы задает себе каждый в сезон заболевания ОРЗ. На самом деле, лечение травами простуды довольно распространенный способ. Не каждому хочется глотать таблетки. При лечении травами важно соблюдать дозиро...»

«Ассаулюк Анатолий Дмитриевич "Катюш" ракетные залпы Я родился 26 ноября 1923 года в селе Жежелев, Казатинского района, Винницкой области, украинец. Среднюю школу окончил в 1941 году в Тамбовской области на станции Оборона в райцентре Мордово. Чувствовали ли мы приближение войны? Да, по многим признакам. В марте 1941 года вызвали меня в военко...»

«УТВЕРЖДЕН УТВЕРЖДЕН приказом министерства приказом Юго-Восточного управления имущественных отношений министерства образования и науки Самарской области Самарской области ЛЛ. РЦ.2 от о нщ то ёдяминжк%а Врио щЖ# \ V ЛТЛбладшнова Е.Ю.Баландина ИН^СИ 1 СО И С по Крзсноглинскому району г.Самары Д н п я ц О Г.йипРТРПЬСТВО О госу решенной р е...»

«Сырные магазины (Fromageries). Три продукта: хлеб, вино и сыр – составляют основу французской гастрономии. И кто бы сомневался, что потребление этих продуктов – есть та самая здоровая еда, которую "ищут" в последнее время практичес...»

«Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Академия Русского балета имени А.Я.Вагановой ОТЧЕТ Об организации и проведении творческих мероприятий, посвященных юбилею Академии Русского балета имени А.Я.Вагановой г.Санкт-Пе...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего профессионального образования "СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ" Утверждаю Ректор СФУ _ Е.А Ваганов "" _ 2012 г. Основная про...»

«Татьяна Юрьевна Степанова ДНК неземной любви Текст предоставлен издательством http://www.litres.ru/pages/biblio_book/?art=421082 ДНК неземной любви: Эксмо; М.; 2010 ISBN 978-5-699-44244-7 Аннотация Такого странного, загадочного дела в практике МУРа не было никогда. По ночам на мос...»

«Глава первая Мишна первая,,.,,, ) (,.,, ЗА СЕМЬ ДНЕЙ ДО ЙОМ-КИПУРА ОБОСОБЛЯЮТ ПЕРВОСВЯЩЕННИКА ОТ ЕГО ДОМА В ПАЛАТУ ПАЛГЕДРИН И ПОД ГОТОВЛЯЮТ ЕМУ ДРУГОГО КОГЕНА ВМЕСТО НЕГО ВДРУГ СЛУЧАЙНО СТАНЕТ ОН НЕПРИГОДНЫМ. РАБИ ЙЕГУДА ГОВОРИТ: ТАКЖЕ ДРУГУЮ ЖЕНУ ПОДГОТОВЛЯЮТ...»

«Календарнотематическое планирование уроков литературы в 9 классе Кол № Тема урока -во п/п Основное содержание Дата ТП БУ Нестандарт час ные уроки ов Первый триместр ( с по ) сент 1-2. Введение. Образ – послание ав...»

«ВІСНИК МАРІУПОЛЬСЬКОГО ДЕРЖАВНОГО УНІВЕРСИТЕТУ СЕРІЯ: ЕКОНОМІКА, 2011, Вип. 2 Выявленные в работе данного автора факторы успеха являются сигнификатными для владельцев микропредприятий в Германии. Список использованной литературы 1. Amtsblatt der Europischen Union L 124, Empfehlung 2003 / 361 / EG der Kommission, S. 36...»

«MILKOTESTER Прибор для анализа молока Модель: Master Eco Содержание жиров, сухого обезжиренного молочного остатка, белков, лактозы, воды, температура (°C), точка замерзания, соли, плотность, уровень pH ULTRASONIC PORTABLE MILK ANALYZER ВНИМАНИЕ! Данный прибор работает под н...»

«Страница 1 из 5 CODEX STAN 130-1981 СТАНДАРТ НА СУШЕНЫЕ АБРИКОСЫ CODEX STAN 130-1981 ОБЛАСТЬ ПРИМЕНЕНИЯ 1. Настоящией стандарт распространяется на сушеные плоды Armeniaca vulgaria Lam. (Prunus armeniaca L.), подвергнутые соответствующей технологической или иной обработке и предназначенные для конечного потребления. Стандарт также распространяется на сушеные...»

«AURORA AGRICALTURAL MACHINERY HIGH QUALITY MINI-TILLERS ДВИГАТЕЛЬ БЕНЗИНОВЫЙ AURORA ИНСТРУКЦИЯ ПО ЭКСПЛУАТАЦИИ Модели: AE 7 AE 7D AE 9 AE 9D AE 14 AE 14D Официальный сайт AURORA в России: aurora-online.ru СОД...»

«ParkCity DVR HD 430 Цифровой автомобильный видеорегистратор Руководство пользователя DVR HD 430 Содержание Предисловие Общие сведения Особенности Внешний вид и органы управления Подключение дополнительной камеры Функции кнопок Подготовка к работе Автомобильный адаптер питания Установка и извлечение карты памяти Включение...»

«1 Электронная тайга Югры 2008, № 23, 15 июля Содержание: Лесные пожары – 2008 Валентина Целищева. Наследство для потомков. Здоровый лес, или ворох ошибок и проблем (по итогам семинара в Нягани) В...»

«Содержание Глава 1 Вначале о мышке и клавиатуре 1.1. Начинаем с мышки 1.2. Полезные упражнения с мышкой 1.3. Поговорим о клавиатуре Глава 2 Windows – дружественная оболочка компью...»

«П Р О Ф Е С С И О Н А Л Ь Н О Е О Б РА З О В А Н И Е М. В. ПолеВая, а. Н. ТреТьякоВа уПраВлеНие ПерсоНалоМ В госТиНичНоМ серВисе учебНик Рекомендовано Федеральным государственным бюджетным образовательным учреждением высшего профессионального о...»

«МОНИТОРИНГ СМИ//ПРИЛОЖЕНИЕ 02.08.12 СОДЕРЖАНИЕ: РЕГИОНАЛЬНЫЕ ПРОГРАММЫ//НОВОСТИ ЧЕЧЕНСКАЯ РЕСПУБЛИКА Проблему энергоснабжения труднодоступных районов Чечни намерены решать с помощью альтернативной генерации...»

«Томас Манн МАЛЕНЬКИЙ ГОСПОДИН ФРИДЕМАН Виною всему была кормилица. Напрасно госпожа консульша Фридеман, едва ощутив подозрение, увещевала ее бороться с этим пороком. Напрасно этой особе, кроме питательного пива, ежед...»

«ПАРАЗИТОЛОГИЯ, XVIII, i, УДИ 576.895.121 : 591.4 УЛЬТРАСТРУКТУРА ЦИСТИЦЕРКОИДОВ FIMBRIARIA FASCIOLARIS (HYME NOLEPIDIDAE) Г. П. Краснощекое, JI. Т. Плужников Описана ультраструктура циклоцерков F. fasciolaris и проведено ее сравнение с личинками других цестод сем....»

«Дайджест новостей Проблема межзвездных перелетов №06 (01.11.2014-31.12.2014) Общие аспекты МП 2 Пост о большом-большом космосе и нашем месте в нем 2 6 мест в космосе, где могло бы поселиться человечество 2 Ошибки фантастов или размышления о том, почему остановилась космонавт...»

«ЗАО Анти-Плагиат Руководство пользователя Руководство студента корпоративной версии системы "Антиплагиат.ВУЗ" Руководство пользователя Аннотация Руководство студента по работе с корпоративной версией системы "Антиплагиат.ВУЗ". Содержание 1. Введение 1.1. Термины и определения 1.2. Назначение и услови...»








 
2017 www.kniga.lib-i.ru - «Бесплатная электронная библиотека - онлайн материалы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.