Как пользоваться данным разделом — см. «Общие подходы к процессам».

Риск-менеджеру

Риски управления информационными технологиями обширны и многогранны. Эта вкладка – самая большая вкладка про риски. Но из песни слов не выкинешь, IT охватывает все процессы и ожидать минимума рисков явно не стоило.

Риски в области информационных технологий условно можно разделить на несколько частей: неправильный выбор стратегии, hardware (IT-инфраструктура в виде железяк. При этом потенциальные «облака» мы тоже относим сюда, так как облаками они являются только для пользователей, а физически это железяки, подключенные к сети питания), software (программное обеспечение, включая технологическое), организация управления IT на уровне бизнеса. Можно добавить риски, связанные с учетом IT-компонент. Но в целом такой учет принципиально не отличается от учета в хозяйстве главного механика или энергетика, поэтому см. соответствующий раздел про управление движением ТМЦ (единственное отличие – если электродвигатель сгорел, то он чернеет, а если сгорела CISCO, то от новой может и не отличаться).

Рекомендуемые к рассмотрению риски:

Риск

Краткое описание

Последствия

Типовые недостатки СВК

Некорректный выбор стратегии развития информационных технологий

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

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

  • в части hard – неправильный выбор между созданием собственной / аренды IT-инфраструктуры (начиная от ЦОД и заканчивая вычислительными мощностями). Если выбрали создание своего – вдруг может случиться, что через пару лет стоимость аренды за год окажется равной 1/20 от потраченного только на инфраструктуру. Если выбрали аренду – может оказаться, что стоимость реально необходимых дополнительных услуг за год сопоставима со стоимостью создания собственного серверного центра;
  • в части soft – неправильный выбор между доработкой и поддержкой собственными силами и с привлечением подрядчика. Если выбрали поддержку собственными силами – внезапно может оказаться, что изменение интерфейса ввода в соответствии с планом работ возможно только через 15 месяцев, а менее приоритетные задачи будут решены года через три. Если выбрали аутсорсинг – совершенно неожиданно можно выяснить, что стоимость аутсорсинга соответствует набору творческого коллектива из 50 собственных программистов.

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

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

Стратегия развития информационных технологий отсутствует.

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

 

Несоответствие IT-инфраструктуры потребностям бизнеса

Два варианта.

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

Вариант 2. Инфраструктура избыточна. Утилизация дискового пространства – 5%, закупка для хранения архивов 1С за лохматые годы продвинутых хранилищ (типа EMC) и прочие замечательные вещи.

Как вариант также можно рассмотреть ситуацию использования морально и физически устаревшей инфраструктуры (в 2000-х еще встречались ЕС ЭВМ), но уже лет как 10 не встречали в реальной жизни.

Прерывание бизнес-процессов.

Неокупаемые (даже с учетом рисков) инвестиции.

Снижение EBITDA.

Отсутствие регулярного мониторинга утилизации ресурсов.

Отсутствие регулярного прогноза потребности в инфраструктуре.

Отсутствие «обратной связи» по итогам расследования инцидентов.

Отсутствие квалифицированных оппонентов при защите бюджета информационных технологий

Потеря IT-инфраструктуры

Сгорело, выбило, поломалось и пр. Основные причины: нарушение температурного режима, скачки напряжения (как ни странно), заливы/потопы, кражи оборудования, диверсии (преднамеренная порча).

Необходимость замены вышедшего из строя оборудования.

Недостаточная оснащенность мест расположения IT-инфраструктуры.

Недостаточная мощность источников бесперебойного питания.

Отсутствие резервного кондиционирования.

Отсутствие сигнализации о параметрах работы оборудования (температура, наличие напряжения и пр.) с дистанционным оповещением.

Ошибки при подключении оборудования.

Недостатки охраны периметра помещений, в которых расположены элементы инфраструктуры.

Неоптимальный выбор системного интегратора

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

Отсутствие важных для бизнеса функций.

Рост трудозатрат на осуществление бизнес-процессов.

В некоторых случаях – значительные затраты на повторный проект.

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

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

Этапы внедрения проекта установлены расплывчато (не к конкретному сроку, а в зависимости от каких-либо условий).

Неоптимальный выбор программного обеспечения

«Крайние» случаи реализации риска: «забивание гвоздей микроскопом» (например, использование только функционала бухгалтерии в SAP) и «сэкономили» (взяли хреноватенькую платформу и попытались на ней сделать всё-всё-всё). Последний вариант, как правило, возникает из-за попыток продолжения существования уже усложнившегося бизнеса на одной платформе (условной 1С).

Риск в целом очень сложный с точки зрения идентификации и признания его реализации. Да, наверное, когда пытаемся использовать Microsoft Excel для ведения бухгалтерии – случай достаточно очевидный. Но как только что-то более нетривиальное – роль суждения резко возрастает. Реальный наглядный пример демонстрирует сотовый ритейл в первой половине 2010-х годов: «Евросеть» на SAP, «Связной» на 1С (при этом этих самых 1С десятки для разных целей). И то, и то – работает, что лучше (особенно с точки зрения затраты / эффективность и стоимости жизненного цикла) – неизвестно.

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

Рост трудозатрат на осуществление бизнес-процессов.

В некоторых случаях – значительные затраты на повторный проект.

Непредвиденно большая стоимость поддержки.

Недостаточный анализ преимуществ и недостатков различных рассматриваемых при выборе платформ.

Возложение выбора платформы на системного интегратора.

Отсутствие полного ТЗ на этапе выбора программного обеспечения.

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

 

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

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

Реализация данного риска традиционно выявляется в рамках внутренне-аудиторских проектов. Внезапно оказывается, что по итогам автоматизации количество экономистов не сократилось, объем дополнительной информации невелик, а доработка отчета до удобоваримого вида стоит 1 млн. руб. и занимает 5 месяцев.

Недостижение функциональности может быть и рукотворным. В далеком 2003 году один из авторов наблюдал, как после внедрения SAP в одной очень большой организации (>10 тыс. сотрудников) для внесения данных о списании материалов кладовщикам открывали доступ аж на полдня один раз в месяц. Кто не успел – тот опоздал. При этом движуха ТМЦ по складе была очень серьезной (из серии 200-250 накладных по 15-20 позиций в день). Также к рукотворному недостижению функциональности можно отнести и некорректную настройку ПО. Одна галочка (или ее отсутствие) может легко замедлить (или ускорить) работу приложения на порядок.

Непроизводительные трудозатраты.

В некоторых случаях – значительные затраты на повторный проект.

Отсутствие полного ТЗ на этапе выбора программного обеспечения.

Отсутствие конструктора отчетов в используемой информационной системе.

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

Ошибки / недочеты в работе прикладного программного обеспечения

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

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

Ошибка 2. Неправильный расчет / некорректная логика работы системы. Например, для расчета маржинальной рентабельности по продуктам используется соотношение постоянных и переменных по крупной статье 80/20, хотя на самом деле уже давно 50/50. Но, так как расчет в «черном ящике», кривых расчетов и, соответственно, неправильных решений на основании этих расчетов, можно не замечать годами.

Ошибка 3. «Шумность» результатов. Показательный пример — итоги расследования МАК (здесь, стр. 225). 22 неподтвержденных сигнала тревоги за смену – очевидно, что всякое пищание и красные лампочки на пультах становятся малополезными (а вообще с точки зрения именно автоматизации управления – очень интересный отчет).

Причины этого разные. Во-первых, на этапе постановки возможны технические ошибки на протяжении всего этапа, включая тестирование. Во-вторых, на этапе эксплуатации любое программное обеспечение становится «черным ящиком». Особенно это касается АСУТП и отчетности по МСФО. Не знаем, как так получается, но при создании новых алгоритмов / отчетов оказываются затронутыми уже существующие процедуры, хотя как вроде так быть не должно. Результат – «черный ящик» становится не просто черным ящиком, в котором никто не разбирается, но и еще работает неправильно.

Значительные затруднения в бизнес-процессах.

Принятие некорректных решений на основании неправильной информации.

В некоторых случаях – вплоть до разрушения оборудования.

Отсутствие реестра выявленных ошибок / необходимых доработок в программном обеспечении.

Отсутствие документирования изменений в программное обеспечение.

Отсутствие полноценного тестирования программного обеспечения как на этапе внедрения, так и на этапе доработки.

Невозможность / сложности при замене АСУТП (автоматизированная система управления технологическими процессами)

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

Новое программное обеспечение возможно разработать, однако техническое задание сформировать затруднительно, а время тестирования нового ПО на существующем оборудовании мало прогнозируемо.

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

В случае попытки смены АСУТП – длительные простои.

Эксплуатация АСУТП собственными силами (без привлечения поставщика АСУТП).

Внедрение / доработка / поддержка АСУТП разными поставщиками без передачи полного комплекта документации.

Отсутствие документирования изменений в АСУТП на протяжении продолжительного времени эксплуатации.

АСУТП ведет запись на миллиметровку или аналоговый носитель.

Проблемы при смене программного обеспечения (в т.ч. версионная несовместимость)

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

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

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

Простои какой-либо бизнес-функции.

Некорректная работа нового / обновленного ПО.

Необходимость восстановления «костылей» и «заплаток» в новой версии.

Финансовые потери.

Необходимость экстренной доработки новой версии / нового софта.

Эксплуатация ПО собственными силами (без привлечения поставщика).

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

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

Проблемы из-за некорректной работы IT

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

Может иметь причины, связанные как с hardware, так и с software. Причем в некоторых случаях причину тяжело установить однозначно: то ли у админа руки кривые, то ли оперативной памяти не хватает.

Денежные потери из-за прерывания бизнес-процессов.

Рост трудоемкости.

Отсутствие регулярной независимой оценки производительности систем «под нагрузкой».

SLA без прозрачного алгоритма измерения скорости работы.

Отсутствие «обратной связи» по итогам расследования инцидентов.

Неэффективная поддержка (в заявленном режиме 24/7 работает только первая линия, которая может записать проблему, предложить перезагрузиться и посочувствовать).

Потеря данных

Непредумышленная потеря данных: физическое уничтожение (как на уровне hard – сгорела серверная, так и на уровне soft – злобный вирус).

Предумышленное уничтожение: одновременное уничтожение как основной, так и резервных копий. Может быть реализовано как сотрудниками IT-подразделений, так и, при неудачном доступе, пользователями баз данных (например, увольняющийся продажник вечером построчно удаляет информацию о клиентах, в 02:00 происходит «резервное копирование» поверх предыдущего).

Необходимость восстановления учета.

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

Отсутствие политики резервирования данных.

Некорректное распределение доступа к данным между сотрудниками.

Нелицензионные версии антивирусов, ПО для межсетевых экранов и прочих защит.

Расположение основного и резервного хранилища данных в одном помещении.

Отсутствие плановых упражнений по восстановлению данных.

Утечка данных / несанкционированный доступ к информации

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

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

Отток клиентов.

Требование возмещения ущерба за раскрытие персональных данных.

Усложнение ведения бизнеса из-за наличия у конкурентов коммерческой информации.

Отсутствие регулярного тестирования на внешнее проникновение.

Нелицензионные версии антивирусов, ПО межсетевых экранов и прочих защит.

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

Отсутствие достоверной информации о состоянии системы управления информационными технологиями

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

В итоге состояние «все хорошо, прекрасная маркиза» может продолжаться достаточно долго. Когда возникнут большие проблемы, которые будут сказываться на пользователях – окажется, что ситуация запущена. Изменение IT-систем может занять более года, год нужно жить на заплатках и костылях. При этом директор по IT будет не виноват: ведь он же просил денег и на инвестиции, и на увеличение штата, а ему не давали.

Продолжительная переконфигурация IT-инфраструктуры.

В некоторых случаях – значительные затраты на повторные проекты по разработке программного обеспечения.

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

Отсутствие регулярной внешней по отношению к IT-подразделению оценки (внутренний аудит, внешний консультант) эффективности IT-функции.

Непрогнозируемый рост затрат на IT-функцию.

Традиционный риск как для любого проекта, так и для эксплуатации любой системы.

«Измеряемые» проявления: возникновение дополнительных работ (руб.), увеличение продолжительности работ (мес.).

«Неизмеряемые» проявления: необходимость отвлечения работников на продолжающееся сопровождение внедрения / доработки (совещания, заседания, испытания), превышение трудозатрат рядовых сотрудников на тестовую эксплуатацию (необходимость обучения, освоение новых интерфейсов, ручное формирование отчетов, не предусмотренных новой системой и пр.).

Превышение бюджетов (как операционных, так и инвестиционных). 

Отсутствие проектного управления в организации.

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

Рост стоимости процессов из-за автоматизации (трудоемкость, затраты)

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

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

Снижение EBITDA.

Отсутствие управления рисками при инициировании проекта.

Отсутствие в рабочей группе по внедрению улучшений представителей будущих пользователей этих улучшений.

Некорректное распределение функций между сотрудниками IT-подразделений

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

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

Простои какой-либо бизнес-функции.

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

Рост мошенничества.

Совмещение функций разработки и администрирования.

Отсутствие тестового ПО (проведение доработок на основной версии).

Зависимость от конкретных сотрудников

Большинство сотрудников стремятся, чтобы компания от них зависела максимально. Это приводит к различным ништячкам от свободного графика до завышенной зарплаты. В IT данная зависимость часто носит особенно противный характер. Связано это с тем, что некоторые представители как hard-, так и soft-поддержки являются абсолютно гениальными специалистами.

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

Простои какой-либо бизнес-функции.

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

Необходимость привлечения внешних подрядчиков для переконфигурации ПО.

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

Отсутствие проектов IT-инфраструктуры.

Отсутствие актуальных схем размещения оборудования и коммуникаций.

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

Отсутствие регулярной проверки фактов документирования изменений, схем и т.д.

Все последствия более детально описаны на сайтах www.ithappens.me, www.habrahabr.ru и аналогичных, также можно набрать в поисковике «обидели (сис)админа».

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

Постановщику СВК

Стандарты в области информационных технологий.

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

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

  1. CObIT, Control Objectives for Information and Related Technologies. Перевод википедии: «Задачи управления для информационных и смежных технологий», перевод названия в официальном издании: «Бизнес-модель по руководству и управлению IT на предприятии». Обзор можно скачать с официального сайта https://www.isaca.org/, предварительно зарегистрировавшись. Остальные книги – на английском.
  2. ITIL, IT Infrastructure Library. Переводится как «Библиотека инфраструктуры информационных технологий». Необходимо прочитать введение, знакомство с каждым процессом – желательно, но, на наш взгляд, опционально. Ищется по запросам в поисковых системах. Кроме того, есть сообщества на русском, которые поддерживают переводы наиболее важных документов на русский язык, например, http://wikiitil.ru/.
  3. Серия стандартов ИСО27000, «Информационные технологии. Методы обеспечения безопасности. Менеджмент информационной безопасности.». Ищутся по запросам в поисковых системах.
  4. Стандарт ИСО12207, «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.». Ищется по запросам в поисковых системах.

Если Вы совсем ленивы, достаточно первого пункта (введение в CObIT), там сплошные картинки.

Личное наблюдение: в какой-то момент теоретические знания достигают уровня, когда чтение подавляющего большинства статей в интернете не дает новизны. Это свидетельствует о том, что Вы процентов на 70-80 готовы к проведению IT-аудита. Дальнейшее чтение бесполезно, профессионалом можно стать только через опыт и углубленное (не чтение интернета) профессиональное развитие.

Оговорка про раздел.

Дополнительное замечание к этой вкладке: все рекомендации подготовлены для частных бизнес-компаний.

Принципиальное отличие от государевых организаций:

  • не должны функционировать в соответствии с требованиями всяческих 94-ФЗ и 223-ФЗ (если не сталкивались с таким набором цифр и букв в жизни – желаем не сталкиваться и в дальнейшем);
  • не должны функционировать в соответствии с требованиями к IT-безопасности, разработанными соответствующими профильными ведомствами. Ничто человеческое труженикам этих органов не чуждо, поэтому частенько получается, что соответствие разработанным нормам дорого и неэффективно.

Принципиальное отличие от публичных компаний: не должны соответствовать всяческим SOX. Хотя именно с точки зрения SOX IT требования очень разумные. Замечательная статья про такие соответствия – здесь, полезна не только для аудируемых, но и для проверяющих.

Соответственно, ни в этом разделе, ни в программе проверке нет разделов про соблюдение законодательства. Но, в целом, можно вспомнить про законодательство о персональных данных, но это не только тема IT.

Некоторые особенности при постановке СВК в процессе управления IT.

Соответствие IT-инфраструктуры бизнесу.

Вопрос, что такое соответствие IT-инфраструктуры бизнесу, достаточно сложный. Чтобы показать возникновение требований к IT, можно привести следующие примеры разных бизнесов:

  • продажа услуг по постановке систем внутреннего контроля. Очевидно, что перерыв в IT-сервисах самой консультационной компании легко может составить один рабочий день. Фактически наличие или отсутствие IT-сервисов на продажи не влияет, так как продажи консультационных услуг зависят, в основном, от красноречия менеджера;
  • продажа товаров в мелкорозничную торговлю (например, пива с сигаретами). Бизнес-процесс продажи: мерчендайзер обходит торговые точки и делает заказ на следующий день. Для такого бизнеса перерыв в предоставлении IT-сервисов в течение дня может сказаться уже хуже: если машины завтра не разъедутся по точкам, то и покупатели в виде индивидуальных предпринимателей будут возмущаться, и выручку можно потерять. Но, принципиально, отсутствие IT-сервиса в течение двух часов на бизнесе не скажется почти никак;
  • продажа услуг по доставке еды. Очевидно, что двухчасовое отсутствие IT-сервисов при автоматизированных заказах как минимум скажется в потере прямой маржи за эти два часа, как максимум – потребители вычеркнут сайт из избранного как неработающий и перестанут заходить на него.

Вкратце этими примерами описаны три принципиально разных бизнеса, которые предъявляют принципиально разные требования к инфраструктуре. Соответственно, постановщик СВК должен предотвратить:

  • переизбыток инфраструктуры. Не нужно делать что-либо «как в Аэрофлоте» для торговцев фанерой со складов;
  • недостаток инфраструктуры / недостаток заданного уровня сервиса. То, что устроит торговцев фанерой, не должно устраивать любую компанию с онлайн-сервисом.

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

Какие документы необходимы для СВК в процессе управления информационными технологиями.

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

Кроме того, очень рекомендуем разработать:

  • стратегию развития информационных технологий. Она может быть не очень большой, может быть в виде короткой презентации (на 10 листах). Главное, чтобы отражала принятые ключевые решения о развитии и не обходила принципиальные развилки;
  • порядок управления проектами. Ключевые моменты: формирование управляющего комитета, рабочих групп, групп тестирования (о них – ниже), порядок взаимодействия и принятия решений (в т.ч. по срокам и бюджету), полномочия и ответственность.

Менее рекомендованные, но полезные документы:

  • положения об IT-подразделениях;
  • должностные инструкции (особенно начальников).

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

Уровень формализации процессов (ТЗ, документирование изменений).

В продолжение предыдущего пункта. Необходимо определить, какого уровня документирование является достаточным. Задача не всегда тривиальная, и подходить к ее решению необходимо с учетом риска. В качестве потенциальных потерь необходимо рассмотреть прерывание бизнес-процессов. В качестве возможных мероприятий – увеличение трудоемкости, и, соответственно, стоимости документируемого IT-процесса. Так вот, оказывается, что в некоторых случаях документирование действий – практически бесполезная процедура: риски не минимизируются, а время тратится. Отдельно нужно сказать о ситуации, когда IT-поддержка всего обособленного подразделения либо же небольшого бизнеса осуществляется 1-2 IT-специалистами. Документирование всего необходимого организуется, в первую очередь, для снижения зависимости от конкретных специалистов. В случае поддержки небольшим количеством специалистов документирование может не спасти в случае конфликта работодателя с сотрудниками IT-подразделений. Последние и уйдут, и напакостничают, и документы с собой заберут, даже если они будут.

Это наблюдение касается как IT-инфраструктуры, так и разработки / доработки / поддержки программного обеспечения. По поводу последнего вспоминается анекдот «Беда в том, что программы делают не то, что нужно, а то, что написано». Как следствие – документирование совершенно не обязательно способствует достижению целей.

Если оценка через риски затруднительна, то можно подойти проще: максимальное документирование должно достигаться в IT-зависимом бизнесе (аналогичном доставке еды в первом пункте на этой вкладке) – всегда (даже если работает 5 человек), в менее IT-зависимом бизнесе (аналогичном бизнесу по продаже пива и сигарет в первом пункте на этой вкладке) – при численности от 100-200 человек, в IT-малозависимом бизнесе (аналогичном консультационному бизнесу в первом пункте на этой вкладке) – при численности от 1000-2000 человек.

Подтверждение квалификации IT-специалистов.

Мы не являемся сторонниками традиционного подбора персонала, который поддерживает большинство кадровиков. В последнее время (на начало 2017 года) многие HRы излишне возбудились от профессиональных стандартов, и даже в вакансиях стали попадаться фразы типа «Уровень квалификации не должен быть ниже 7-го, код трудовой функции «C»». Для IT-специалистов в общероссийском классификаторе занятий предусмотрена целая подгруппа №25 «Специалисты по информационно-коммуникационным технологиям (ИКТ)». Почти для каждой профессии разработаны свои стандарты: «Системный администратор информационно-коммуникационных систем», «Администратор баз данных», «Программист», «Руководитель проектов в области информационных технологий» и т.д. – почитать можно, но для интереса. Мы профессиональные стандарты не поддерживаем, начиная от формы и заканчивая содержанием. Причина – бумажку фактически можно будет купить, далее – см. здесь. Именно поэтому в программе проверки (см. следующую вкладку) нет ничего об этих стандартах.

Но, тем не менее, на что-то при приеме на работу опираться нужно. Принципиально прослеживается всего два варианта:

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

(2) проведение входного тестирования. Остерегайтесь ЕГЭ-тестирования. Идеальный вариант – кандидат либо письменно, либо устно отвечает на 10-20 вопросов по теме.

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

Организация управления проектами.

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

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

  • и отвратительная, и идеальная системы управления проектами по документам и внешне выглядят примерно одинаково: набор документов с правильными названиями и мыслями, регулярные собрания людей, диаграммы Ганта с указанием потребности в ресурсах и пр. Беда в том, что в одних случаях IT-продукт получается отвратительным, а в других – идеальным. Соответственно, риск-менеджер / внутренний контролер / внутренний аудитор, основываясь на собственном суждении, должен определить уровень развития системы управления проектами. Понятное дело, что вероятность признания системы неэффективной, если проект еще не закончен – почти нулевая, и поэтому остается только ждать статистики, то есть окончания (в некоторых случаях – прекращения) проектов. И на основании уже закончившихся проектов делать выводы о том, что работало неправильно. Увы, традиционно, хотя вроде бы очевидно, что превентивный контроль лучше последующего;
  • хочется предостеречь читателей от часто встречающейся ошибки, связанной с мнением, что если есть квалифицированная рабочая группа, сопровождающая проект, то все будет хорошо. Сопровождает – значит рассматривает концепцию, активно участвует в формировании технического задания, утверждает ТЗ, осуществляет мониторинг выполнения работ, принимает выполненные работы и прочее. Казалось бы, достаточно подобрать правильный состав и все должно пойти как по маслу. Практика показывает, что не идет. Даже с вазелином. Причина – с одной стороны, банальная, с другой – нетривиальная, а именно «синдром заложника» (корпоративное мошенничество рассматривать не будем), когда рабочая группа уже не столько за предприятие и справедливость, сколько «начинает понимать» проблемы подрядчика / разработчика и его предложения по выходу из сложившейся ситуации. Как результат – рабочей группе кажется, что сделано, в целом, нормально, хотя на самом деле это не так. Кто-то может подумать, что проектов в его организации это не коснется, потому что есть управляющий комитет, а есть рабочая группа. Не надейтесь: управляющий комитет состоит, как правило, из «больших» людей. Тестирование рабочего продукта – не царское дело (без шуток, с точки зрения эффективности использования рабочего времени топ-менеджера непосредственное тестирование финансовым директором – излишне дорого). Организационный выход с точки зрения постановки СВК в процессе: ключевые решения, а именно утверждение концепции, утверждение ТЗ и решение о приемке выполненных работ должны принимать сотрудники, не входящие в рабочую группу. Например, концепцию должен утвердить CEO, ТЗ – CFO, а приемку работы – непосредственные пользователи. В общем, «принцип четырех глаз» в действии;
  • мотивация. Традиционно измерением успеха проекта является соблюдение сроков и бюджетов, в качестве показателей качества используется Акт выполненных работ, Акт приема-передачи системы в эксплуатацию и пр. Такая мотивация принципиально снижает качество: задача трансформируется из удовлетворенности заказчика в подписание акта любой ценой. Методов выхода множество, хотя бы выплата половины бонуса в зависимости от удовлетворенности пользователей через полгода эксплуатации (заодно и «золотые наручники» возникают).

Особенности применения технических политик.

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

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

Особенность 1. В отличие от очень многих рынков, на рынке IT-оборудования практически невозможно приобрести необходимое оборудование напрямую у производителя либо его российского представительства. Достаточно вспомнить компанию Dell: если на рынке США действует принцип товарища Делла «Никогда не продавай через посредников», то на рынке России у Dell напрямую ничего купить нельзя. Результат – необходимость посредника при закупке.

Особенность 2. На рынке действует правило «кто первый клиента потанцевал, того и клиент». Выражается это в том, что при условно большом (хотя бы на $200-300 тыс.) заказе производителю нужно обязательно сказать, кому именно планируешь поставлять. Если клиент «забронирован», то дочернее общество производителя ограничивает конкуренцию. При этом ситуация может развиться вплоть до того, что потенциальному альтернативному поставщику даже не скажут цену, и он, соответственно, не сможет хотя бы представить коммерческое предложение.

Особенность 3. Рынок очень «откатоемкий». Это касается как поставки железа, так и продажи лицензий, не говоря о разработке программного обеспечения. Из-за отсутствия возможности мониторинга цен директор по информационным технологиям может одной сделкой решить все свои проблемы на ближайшие несколько лет.

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

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

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

Заключительный вопрос – а стоит ли бояться зоопарка IT-оборудования? На наш взгляд, не стоит. Причины следующие:

  • достоверная статистика того, что реализация технической политики в виде выбора одного производителя каким-то образом снижает вероятность сбоев, отсутствует. Да, IT-шники всегда говорят о том, что условные HP и Lenovo могут не подружиться. Да, очень приятно, когда на каждой железяке в серверной логотип одного производителя. Но см. особенности выше;
  • в отличие от движущейся техники, для серверов и персональных компьютеров на регулярной основе не нужны расходники и запасные части. Таким образом, стоимость жизненного цикла от момента закупки до списания близка к нулю в отличие, например, от автомобилей;
  • в IT все меняется очень быстро. Если лидеры на рынке тяжелого оборудования меняются редко (горизонт – около 10 лет), то в IT за 2-3 года может поменяться очень многое. Как результат – при фиксировании технической политики можно долгое время не пользоваться наиболее продвинутыми решениями;
  • в продолжении тезиса про быстрые изменения. Если Вы покупаете грузовик – он и через 10 лет будет грузовиком (просто старым и дорогим в эксплуатации), принципиальных отличий от новых машин не будет (как возили 5 тонн, так и возим). На горизонте 10 лет того же про IT-оборудование сказать нельзя: вспомните дискеты и прочие аналоговые накопители. То есть техническая политика может долго не прожить даже на уровне видов оборудования.

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

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

Соглашение об уровне сервиса.

Оно же SLA. Документ, безусловно, полезный. Опасаться нужно следующих вещей:

  • как правило, для всех сервисов устанавливается уровень поддержки 24х7 (либо же 24х365), то есть круглосуточный. Это приводит к завышенным требованиям (а также завышению фактического уровня сервиса). Большинство сервисов, не связанных с обслуживанием клиентов, достаточно обслуживать в режиме 8х5 (или же 16х5, в зависимости от часовых поясов);
  • как правило, не прописывается порядок измерения скорости отклика. В результате вся бухгалтерия кричит, что система «почти висит», но по отчетности об уровне сервиса вроде бы все нормально. Ошибку нужно исправить;
  • включайте в SLA возможность участия заказчика в расследовании инцидентов. В противном случае по итогам ежеквартального зависания учетных систем в момент закрытия будете получать отмазки в виде «низкая пропускная способность каналов», «не хватает оперативной памяти на персональных компьютерах», не обновили версию (кстати, может быть, и правда), регулярно DDoSят, «бухгалтерия врет», «по нашим данным, сервис не прерывался» и т.п.;
  • как правило, забывают описать, что несвоевременно выполненные заявки должны снижать цену абонентского обслуживания либо же цена снижается до уровня достигнутого показателя (то бишь если вместо уровня доступности 99,5% достигнут уровень доступности 80%, то оплата составляет 80% от цены договора). Приводит к тому, что сильно напрягаться внешнему (да и внутреннему) подрядчику как бы и не зачем: доход гарантирован. Проконтролируйте, чтобы SLA предусматривало значительное снижение оплаты даже за доли процента.

Когда поддержку осуществляют не сторонние контрагенты, а собственное подразделение, от документированного SLA целесообразно отказаться. Потому что принципиально от наличия или отсутствия SLA уровень поддержки не изменится, а лишние документы – как в соответствующем анекдоте про бухгалтерию (осторожно, мат). Ну и также необходимо отметить, что сбои могут быть даже в очень продвинутых системах и при абсолютно соответствующих занимаемой должности IT‑специалистах. Проблема в самом поддерживаемом ПО, исходный код многих программ (не говоря об операционных системах) уже давно перевалил за миллионы строк.

Организация поддержки.

Любая организация стремиться сократить собственные издержки. И передача поддержки (в широком смысле: поддержка пользователей, поддержка / доработка ПО) на аутсорсинг – как многим кажется, одна из хороших возможностей сокращения затрат. Основное соображение для постановщика СВК в процессе управления IT – каждое решение должно быть экономически обоснованно на текущий момент.

Несколько дополнительных тезисов, которые могут оказаться полезными для постановщика СВК:

  • обратите внимание на количество выставляемых трудодней от аутсорсера. Если ежемесячно на протяжении года подрядчик выставляет 400-500 часов – это повод задуматься о переходе на оказание услуг собственными силами. Кстати, большинство крупных бизнесов давно создало общие центры обслуживания в регионах с низкой стоимостью рабочей силы. Очевидно, что столь большое количество финансовых директоров не может ошибаться;
  • аргумент о том, что «качество будет выше» при аутсорсинге / выполнении работ собственными силами, как правило, от лукавого. Качество примерно одинаково – а иной тезис почему-то не сопровождается конкретными цифрами. Единственное отличие – аутсорсинг действительно снимает проблему поиска персонала, если поддержка разбегается. Но, к сожалению, если бизнес будет ждать разумного специалиста, то аутсорсер возьмет первого попавшегося, так как «кто-то же должен ходить на работу и обрабатывать заявки». При таком подходе неизвестно, что лучше: отсутствие специалиста либо же плохой специалист. Также не следует ожидать от аутсорсинга методически верного сопровождения (хотя вроде как должны быть службы качества): те же самые костыли, заплатки и прочие временные решения;
  • оценивать уровень поддержки необходимо в разрезе категорий пользователей. В противном случае средняя оценка в 4,63 может сложиться из оценок «2» за АСУТП, «3» за учетную систему и «5» ото все остальных просмотрщиков youtube и раскладывателей пасьянсов. Самая важная категория пользователей – ключевые пользователи. Не нужно думать, что ключевые пользователи информационных систем – это финансовый директор либо же директор по производству, потому что они выше в организационной структуре, чем все остальные. Ключевые пользователи – это пользователи, которые владеют критически важными бизнес-процессами (начальники соответствующих отделов, аппаратчики производства, бухгалтерия и пр. – варианты могут отличаться в зависимости от бизнеса). И для бизнеса значительно важнее, чтобы у них все было хорошо, по сравнению с тем, что мудрый помощник советника второго заместителя не смог вовремя отправить электронную почту;
  • при выборе аутсорсинга одна из самых важных задач – не попасть в зависимость. Зависимость, как правило, возникает двумя способами: (1) из-за того, что проекты превращаются в процессы. Например, проект, судя по первичным документам завершен, акт выполненных работ подписан. Но при постановке задачи забыли примерно половину. Еще до окончания проекта возникли идеи доработок еще на один проект, но помельче. Ну и т.д.; (2) подрядчики не документируют изменения. Таким образом, текущее состояние ПО – черный ящик, отказ от аутсорсинга потребует значительных разовых затрат на то, чтобы кто-то разобрался в уже содеянном. При этом потребуется перерыв в предоставлении сервиса. В принципе, ничего страшного в этом не было бы, если бы аутсорсинговые компании на каком-то этапе не бурели, пользуясь зависимостью клиента от себя любимых;
  • затраты на поддержку могут быть значительно снижены за счет создания комфортной среды для пользователей. Примеры такой комфортной среды: (1) конструктор отчетов в информационной системе. В этом случае квалифицированный пользователь создает себе нужные отчеты без привлечения сложного процесса доработки; (2) справочная информация в service-desk’е. Набор информации зависит от повторяющихся запросов: где-то нужно учить пользователя закрывать крышку принтеров, где-то устанавливать принтер по умолчанию.

Кстати, нет ничего зазорного в том, чтобы менять концепцию поддержки раз в два года: то есть в году N вы поддерживаете собственными силами, в году N+2 – 80% поддержки на аутсорсинге, в году N+4 – опять собственными силами. Главное, чтобы каждый переход был экономически эффективен (по факту, а не по плану).

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

Резервирование.

Для нормального функционирования IT-инфраструктуры необходимо резервное оборудование. Резерв может быть как «горячим» (когда не используются все мощности серверного оборудования, межсетевых экранов и т.п.), так и «холодным» (когда нужно физически заменить железяку). Вопрос о резервировании и подходах к нему – философский, сказать, сколько конкретно «вешать в граммах», практически невозможно.

Разберем банальный пример. Нужно ли резервирование электроэнергии? В принципе, всегда возможно накупить дизель-генераторов, создать запас дизтоплива (для холодных регионов – менять на летнее / зимнее / Арктику), ввести должность дежурного, который в течение 3 минут будет в любое время года выбегать на улицу и торжественно дергать за веревочку / нажимать кнопочку (в автоматический запуск генераторов как-то не очень верится). Понятное дело, что цена вопроса поддержки такой системы – фантастическая, а самое обидное то, что дежурный и проспать может, то есть генератор не запустится.

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

В общем, все очень нетривиально. Единственный случай из нашего знакомства со средним бизнесом, где совершенно точно был нужен дизель-генератор (причем не очень мощный, а для поддержки работа пульта управления производственным процессом) – это для АСУТП на металлургическом заводе.

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

Формирование бюджета затрат на информационные технологии.

Бюджетированию в целом на этом сайте посвящено отдельное описание. Некоторые особенности применительно к IT:

  • очень часто «качество» бюджетирования в IT измеряется продолжительностью и итерационностью обсуждений. Не поверите, но трудозатраты никак не коррелируют с качеством бюджета. Ключевой аспект эффективного бюджетирования – это наличие в качестве оппонента директору по IT компетентного сотрудника. Иногда может выручить банальная эрудиция, но она спасает только от «наглых» превышений. В большинстве организаций такого не наблюдается, поэтому приходится брать измором. А вообще, самая эффективная контрольная процедура в бюджетировании IT – это разумный директор по IT;
  • в период резких валютных колебаний IT-бюджеты начинают скакать. При волатильности возможно создание бюджета в долларах США и, соответственно, мониторинг осуществлять тоже по долларовому бюджету. А вот лимиты утверждать в рублях и принимать решение об исполнении на момент заключения договора с учетом новых прайс-листов поставщиков.

Управление информационной безопасностью.

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

На этапе постановки системы внутреннего контроля необходимо определить уровень жесткости планируемой СВК по отношению к сотрудникам. Примеры «жестких» и «мягких» вариантов:

  • готовы ли разрешить флешки и кому;
  • можно ли пользоваться wi-fi и кому (только посетителям / всем);
  • можно ли пользоваться традиционными бесплатными почтовыми серверами (типа mail.ru, gmail.com);
  • можно ли пользоваться удаленным доступом и к чему (почта, видеонаблюдение, мониторинг работы оборудования). Усугубляется тем, что большие руководители почему-то любят планшетки на пляжах;
  • может ли пользователь устанавливать ПО и какое;
  • работает ли АСУТП в замкнутом контуре или же нет (имеет возможность автоматического обновления);
  • кто разрешает доступ в серверные помещения (IT-специалист, IT-специалист + специалист по информационной безопасности);
  • какими будут настройки межсетевых экранов, антивирусов etc.;
  • готовы ли пользоваться нелицензионным ПО (увы, но по-прежнему правда жизни);
  • сложность паролей и регулярность их изменения (особенно с учетом того, что qwerasdf пользователь будет помнить, а сложный пароль запишет на бумажке и налепит на монитор или положит в верхний ящик тумбочки, при требованиях смены пароля раз в месяц вероятность такого поведения пользователя приближается к 100%)

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

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

Использование IT-технологий во внутреннем контроле.

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

Автоматизация внутреннего контроля hardware с помощью software.

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

Мысль 2. Любая АСУТП должна стать неисчерпаемым источником информации для внутренних контролеров и аудиторов о работе производства. В нормальной СВК функционируют отчеты обо всех нестандартных событиях. Если таких отчетов нет – срочно их дорабатывайте.

Автоматизация внутреннего контроля на уровне учетных данных.

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

В хорошо автоматизированном бизнесе с большим количеством транзакций внутренний аудит (который уже становится «непрерывным») может достичь идеала путем сплошных проверок всех транзакций. Но доработки соответствующих отчетов в «традиционной системе» занимают слишком много времени. Для нормального внутреннего контроля в этом случае нужна дополнительная приблуда в виде специального программного обеспечения для работы с big data. Опыт у авторов есть, название продукта называть не будем, если интересно — пишите. 

Работа в этом случае организуется примерно следующим образом:

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

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

Использование IT для контроля работы сотрудников.

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

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

Внутреннему аудитору

Программа проверки. 

Полная версия в формате Microsoft Excel — здесь

Подпроцесс Программа проверки Справочная информация 
Признак эффективного дизайна Признак неэффективного дизайна Рекомендуемые действия по тестированию Вероятность «поймать» что-то при тестировании
Стратегическое планирование развития информационных технологий Убедиться в коллегиальности принятия стратегических решений в области информационных технологий. Существует комитет по информационным технологиям на уровне не ниже коллегиального органа управления.
При обсуждении альтернатив используются расчеты, подтвержденные финансово-экономическим подразделением.
Комитет регулярно (не реже одного раза в год) обсуждает возможные стратегические альтернативы.
В составе комитета есть люди с соответствующими компетенциями («профессиональные оппоненты»).
Корректировки в стратегию развития вносятся ежегодно. 
Формализованная стратегия отсутствует.
Решения комитета по информационным технологиям являются рекомендательными.
Расчеты при разработке стратегии используются в минимальном объеме, превалируют подходы «я так вижу», «так — наиболее современно» и пр.
Коллегиальные органы выполняют роль «бешенного принтера», то есть утверждают предложения IT-подразделений по развитию стратегии. 
Анализ материалов к рассмотрению для принятия стратегических решений в области информационных технологий. Высокая
Убедиться в полноте рассматриваемых стратегических вопросов.  Не реже одного раза в год поднимаются вопросы достаточности существующей инфраструктуры, поддержки существующего программного обеспечения, необходимости новых проектов для развития бизнеса и пр. Рассматривается вопрос оценки стоимости IT-инфраструктуры, понесенных убытков из-за простоев систем, недоступности сервисов. IT-стратегия представляет собой концептуальный документ (как правило, объемом около 20 страниц) без конкретных решений.  Анализ полноты и достаточности рассматриваемых стратегических вопросов. Как минимум должно быть включено следующее:
— порядок управления проектами;
— функционирование IT-инфраструктуры (серверная часть, коммуникации, оборудование рабочего места);
— порядок доработки существующего ПО (собственные силы, привлечение аутсорсинга и пр.);
— обоснование использования ПО (новых проектов), планы по новым проектам в области информационных технологий
и т.д.
Изменения в IT, предусмотренные стратегией, имеют обоснование и связь со стратегией бизнеса в целом.
Средняя
Организация управления информационными технологиями Убедиться, в целом, что принцип разделения полномочий (Segregation of Duties, SoD) обеспечивается организационно-функциональной структурой.  В организационной структуре разделены отделы администрирования и отделы разработки.
Функционал разработчиков не подразумевает доступа к основной базе системы (имеется доступ к тестовой базе и среде разработки).
Функционал администраторов не подразумевает возможности внесения изменения в код. 
Организационная структура IT-подразделения организована по продуктовому принципу (например, отдел поддержки 1С или отдел поддержки АСУТП). При этом функционал подразумевает полный доступ (администрирование, изменение) у каждого сотрудника.  Анализ организационно-функциональной структуры на предмет совмещения функций разработки и администрирования.
Анализ фактически выполняемых обязанностей (в т.ч. анализ порядка выпуска релизов при отсутствии профильного администратора). 
Высокая
Убедиться, что сотрудники IT-подразделений имеет требуемую квалификацию.  Большинство сотрудников имеют техническое образование, полученное в ведущих вузах региона.
Организация проводит регулярное повышение квалификации.
Разработчики имеют соответствующие дипломы / сертификаты от поставщика программного обеспечения.
Подбор персонала осуществляется по принципу «хороший человек».
Мониторинг необходимости обучения не проводится.
Обучение носит спонтанный характер (проводится по заявке конкретного сотрудника) и может не соответствовать потребностям организации. 
Анализ квалификации и опыта работы сотрудников IT-подразделений.
Анализ порядка входного тестирования сотрудников IT-подразделений.
Анализ организации обучения сотрудников IT-подразделений.
Проверка необходимости каждого обучения. 
Низкая
Убедиться в обоснованности штатной численности и ФОТ сотрудников IT-подразделений.  Ежегодно проходит защита плановой численности и ФОТ IT-подразделений, при этом оппоненты квалифицированы. Для определения численности используется фотография рабочего дня, статистика запросов и выполняемых работ. Для определения уровня заработной платы используются исследования рынка в регионах присутствия.
Для территориально-распределенных бизнесов создан общий центр обслуживания либо используется внутренняя централизация. 
Штатная численность и ФОТ IT-подразделений сложились исторически.  Анализ динамики штатной численности IT-подразделений за 5-6 лет.
Анализ необходимости и достаточности штатной численности IT-подразделений.
Сравнение уровня заработной платы сотрудников IT-подразделений со средним по рынку. 
Высокая
Убедиться, что применяемый аутсорсинг IT-услуг оправдан. Имеется четкое обоснование, почему существующий персонал не выполняет задачи, переданные на аутсорсинг.
Дублирование функций отсутствует.
Закупка услуг сложилась исторически или исходя из политических соображений.
Сравнение стоимости услуг аутсорсеров со стоимостью выполнения работ собственными ресурсами не проводилось.
Анализ реального функционала сотрудников (анализ должностных инструкций недостаточен).
Анализ удовлетворенности реальных потребителей услуг аутсорсеров.
Анализ обоснованности выставляемых аутсорсером счетов.
Анализ документации по управленческим решениям, связанным с привлечением аутсорсеров.
Высокая
Убедиться в наличии плана действий в кризисных ситуациях.  План действий в кризисных ситуациях сформирован на основании модели угроз.
Поддержка резервирования экономически обоснована (стоимость резервирования значительно меньше потенциальных потерь от прерывания бизнес-процессов).
Регулярно проводятся тренировки по исполнению плана действий в кризисных ситуациях. 
План действий в кризисных ситуациях либо отсутствует, либо не обеспечивает достижения целей Анализ модели угроз.
Анализ плана действий в кризисных ситуациях на предмет включения в него всех критических угроз.
Анализ экономической обоснованности плана действий в кризисной ситуации.
Анализ результатов тренировок по реализацию плана действий в кризисных ситуациях. 
Средняя
Планирование бюджета на информационные технологии Убедиться в соответствии бюджета утвержденной стратегии. Стратегия развития информационных технологий поддерживается на горизонте 1,5-2 года, что позволяет определить перечень затрат на этапе планирования практически в автоматическом режиме.
Не менее 80% затрат бюджета следующего года предусмотрены IT-стратегией. 
Рассмотрение IT-стратегии происходит после или параллельно рассмотрению бюджета.
Стратегия не содержит распределение действий по годам.
Взаимосвязь между IT-стратегией и бюджетом IT не просматривается. 
Сопоставление дат утверждения стратегии развития информационных технологий и первого рассмотрения бюджета.
Построчное сравнение бюджета IT и стратегии развития информационных технологий. 
Средняя
Убедиться в коллегиальности принятия тактических решений в области информационных технологий. Кто-либо из оппонентов (финансовый директор, генеральный директор, начальник ПЭО) имеет определенный опыт в управлении IT.
Ключевые решения (как инвестиционные, так и текущие) принимаются на общем обсуждении. 
План по развитию IT на следующий год рассматривается в виде записок от директора по IT.
Коллегиально обсуждается только сумма затрат на информационные технологии, без разбивки по строкам. 
Анализ персонального состава сотрудников при обсуждении бюджета IT.
Анализ бюджета IT с точки зрения необходимости и достаточности.
Низкая
Убедиться в наличии обоснования по каждой из статей бюджета.  Инвестиционные проекты проработаны: имеется предварительное техническое задание, получены коммерческие предложения и т.д.
Стоимость текущей поддержки обоснована: выбраны оптимальные способы с учетом рисков, имеется калькуляция себестоимости и пр. 
Бюджет на информационные технологии определяется общей суммой без привязки к проектам.
Затраты по конкретным статьям затрат определяются «по аналогам» (то есть приблизительно).
Технические задания возникают только на этапе проведения конкурсов. 
Выборочный анализ обоснованности по статьям бюджета.
Сравнение стоимости поддержки инфраструктуры и программного обеспечения собственными силами и с привлечением подрядчиков. Анализ обоснованности принятых решений на основании проведенного сравнения. 
Средняя
Управление проектами Убедиться в корректности формирования рабочей группы для наиболее значимых для компании проектов.  Рабочая группа состоит из директора по IT, финансового директора, директора по производству (в случае АСУТП), принцип «четырех глаз» соблюдается. 
Рабочую группу не возглавляет директор по IT.
Рабочая группа состоит из директора по IT и его подчиненных (возможно, с привлечением 1-2 экономистов).
Окончательное решение по приемке работ принимает директор по IT.
Анализ персонального состава рабочей группы.
Анализ решений, принятых рабочей группой.
Средняя
Убедиться в корректности формирования конкурсных условий (в т.ч. в отсутствии «заточенности» под конкретного поставщика). Конкурсные условия «тестируются» на потенциальных подрядчиках.
В конкурсах принимает участие не менее 3-4 потенциальных контрагентов. 
Конкурсные условия пишет директор по IT.
В конкурсах принимает участие минимальное количество (1-2) участников. 
Анализ конкурсных условий.
Анализ количества потенциальных поставщиков, участвующих в конкурсе. 
Высокая
Убедиться в корректности выбора поставщика (в т.ч в его способности выполнить работу).  Победившие подрядчики обладают следующими характеристиками: (1) значительная выручка (вхождение в соответствующие рейтинги / рэнкинги); (2) релевантный опыт (в идеале — такая же задача в такой же отрасли); (3) большой штат программистов.
За время существования организации значимых сбоев при управлении IT-проектами не было. 
Требования к участникам конкурса детализированы недостаточно, например, общее количество проектов (без привязки к отраслям), общее количество специалистов (без указания опыта работы на конкретной платформе) и пр.
Требования к участникам избыточны, например, рассмотрение количества благодарностей, наград (типа «Лучшая компания года») и пр.
Выбор подрядчика, специализирующегося на работе с государственными структурами. 
Анализ конкурсных условий.
Запрос показателей деятельности выигравших подрядчиков.
Анализ существующих клиентов действующих подрядчиков. 
Высокая
Убедиться в полноте и достаточности формирования технических заданий.  Техническое задание сформулировано с учетом роста потребностей (как в IT-инфраструктуре, так и в функционале).
Техническое задание предусматривает конструктор отчетов на основании имеющихся данных.
При указании конкретного оборудования приводится детальное обоснование (подтвержденное финансово-экономическим подразделением). 
При проектировании IT-инфраструктуры предусматривается минимальный (20-30%) резерв по сравнению с текущей потребностью.
Техническое задание содержит только формы, используемые в текущей деятельности.
Бизнес-анализ (включая формирование технических заданий) проводится вчерашними выпускниками.
Техническое задание содержит выбор конкретного оборудования без обоснования. 
Анализ технических заданий на предмет полноты: описание всех существующих бизнес-процессов, детальность аналитики, компоненты IT-инфраструктуры, дополнительное программное обеспечение и т.д.
Анализ технических заданий на предмет достаточности и необходимости: учет возможностей роста (в т.ч. для IT-инфраструктуры), удовлетворение текущим потребностям и т.д. 
Низкая
Убедиться во всестороннем рассмотрении концепции реализации проекта.  Концепция содержит несколько вариантов развития проекта с независимо подтвержденным финансово-экономическим обоснованием.
Рассмотрение концепции проводится на самом высоком уровне (не ниже генерального директора). 
Концепция представляет собой мнение разработчика в единственном варианте.
Концепцию рассматривает и утверждает только рабочая группа. 
Анализ порядка принятия стратегических решений в отношении развития проекта.
Контроль наличия вариативности при принятии стратегических решений в отношении развития проекта. 
Средняя
Убедиться в детальности и выполнимости графика работ.  График работ формируется исходя из реальной потребности в сроках на выполнение необходимых действий.
График работ содержит измеряемые контрольные точки не реже одного раза в 1-2 недели.
График согласован без замечаний всеми участниками проекта.
Сроки разумны: поставка сложного оборудования занимает не менее 60 дней, на согласование каждого этапа отводится не менее 2 недель, основные работы по этапу занимают не менее 3 недель и пр. 
График формируется исходя из необходимости «закончить к дате».
При формировании графика возможны этапы продолжительностью месяц и более без разбиения на подэтапы (например, «Программирование в соответствии с ТЗ», 4 мес.).
Выполнимость проблематична: поставка сложного оборудования занимает менее 60 дней, согласование результатов работ запланировано за 3-5 дней, основные работы по этапу занимают 1-2 недели и пр. 
Анализ подходов к формированию графиков работ.
Анализ существующих графиков проведения работ с точки зрения выявления невыполнимых (маловероятно выполнимых) мероприятий.
Проверка достаточности контрольных точек (в т.ч. на продолжительных этапах). 
Средняя
Убедиться в комиссионной приемке результатов работ.  Комиссионная приемка осуществляется с привлечением «новых» для проекта специалистов с их правом вето на приемку работы.  Комиссионная приемка осуществляется рабочей группой.  Анализ состава рабочей группы, участвующей в приемке.  Средняя
Убедиться в наличии разумного порядка выявления и устранения выявленных недостатков.  Недостатки («баги», «глюки», недопоставка и пр.) выявляются на промежуточных этапах.
При выявлении недостатков в кратчайшее время (1-2 рабочих дня) утверждается порядок их устранения, который включается в план работ / заносится в единую таблицу.
Контроль устранения выявленных недостатков осуществляется в том же режиме (при его эффективности), что и основной пул работ. 
Недостатки начинают выявляться только при общей приемке работ.
Сводная информация о выявленных недостатках отсутствует, учет недостатков ведется в разрозненных документах (например, протоколах рассмотрения без номеров). 
Анализ времени выявления и порядка исправления недостатков, указанных в протоколах рабочих групп, переписке с подрядчиком и пр.
Анализ порядка устранения выявляемых недостатков. 
Высокая
Управление IT-инфраструктурой Убедиться в разумности состояния IT-инфраструктуры. IT-инфраструктура построена с учетом планируемого развития бизнеса.
Принципы построения инфраструктуры соответствуют лучшим практикам (CObIT).
IT-инфраструктура развивалась исторически.
На текущий момент имеются проблемы, которые затрудняют выполнение каких-либо бизнес-процессов.
Инфраструктура не может быть расширена, излишне сложна и т.п. 
Анализ существующей IT-инфраструктуры на достаточность в разные периоды (текущий момент, через 1 год, через 2 года).
Анализ инфраструктуры на предмет соответствия «хорошим практикам» CObIT (повторное использование, гибкость, открытость). 
Высокая
Убедиться в актуальности документов по размещению оборудования.  Схема размещения оборудования находится в общем доступе для всех IT-подразделений.
Не реже одного раза в неделю ответственные за перемещение актуализируют данные по размещению и подключению оборудования (в т.ч. в учетных программах). 
Схема размещения оборудования отсутствует либо не поддерживается.  Сбор информации (из бухгалтерских баз данных) об IT-оборудовании.
Выборочная проверка соответствия схем подключения фактическому подключению и размещению. 
Средняя
Убедиться в наличии защиты оборудования.  Основные и резервные хранилища данных физически разнесены в разные здания (при отсутствии возможности — резервирование осуществляется на арендованные мощности в data-центрах).
Все оборудование подключено через источники бесперебойного питания / сетевые фильтры.
Помещения серверных оснащены датчиками (дым, содержание кислорода, температура, затопление) с дистанционным оповещением.
Помещения серверных оснащены независимыми друг от друга по электропитанию кондиционерами и системой автоматического пожаротушения.
Доступ в серверные помещения ограничен. 
Серверные расположены в неприспособленных помещениях (наличие окон, отсутствие кондиционирования).
Датчики измерения параметров атмосферы отсутствуют.
Не используются источники бесперебойного питания и сетевые фильтры. 
Анализ существующих схем размещения оборудования с точки зрения пространственного разнесения основных и резервных серверов / хранилищ данных.
Анализ логики работы датчиков, установленных в помещениях серверных.
Проверка наличия и работоспособности источников бесперебойного питания.
Проверка кондиционирования (как минимум два кондиционера с независимым питанием).
Тестирование противопожарной системы (замыкание контактов) и датчиков затопления на предмет срабатывания сигнализации и выполнения предусмотренной схемы информирования (логи, смс и т.д.). 
Высокая
Убедиться в наличии резервного оборудования для поддержания работоспособности IT-инфраструктуры. «Горячий» резерв обеспечивает работоспособность IT-инфраструктуры при выходе не менее 1 физической единицы каждой единицы оборудования.
Выполнен расчет «холодного» резерва оборудования.
«Холодный» резерв поддерживается в необходимом количестве. 
«Горячий» резерв отсутствует (при выходе из строя оборудования необходимо физическое присутствие системного администратора).
Расчет необходимого «холодного» резерва отсутствует. 
Анализ утилизации основного оборудования для «горячего» резерва: серверов, хранилища данных, межсетевых экранов и пр.
Анализ необходимости и достаточности оборудования в «холодном резерве».
Анализ наличия резервного оборудования для пользователей ПК (системные блоки, мониторы, устройства печати и пр.). 
Низкая
Убедиться в своевременности устранения проблем в функционировании IT-инфраструктуры.  Срок устранения проблем не превышает установленных SLA.  Имеются случаи простоя значимого количества подразделений по полдня из-за нарушения функционирования IT-инфраструктуры.  Анализ произошедших сбоев в работе IT.
Анализ достижения показателей SLA.
Выявление причин продолжительного (свыше 2 часов) устранения проблем в функционирования IT-инфраструктуры. 
Высокая
Убедиться в разумности сроков службы используемого IT-оборудования.  Установлены (формально либо неформально) оптимальные сроки службы оборудования.
Продление оптимальных сроков службы оборудования осуществляется коллегиально. 
На критических участках имеется оборудование со сроком службы более 10 лет.
Эксплуатируется неподдерживаемое производителем оборудование при минимальном резервировании. 
Сбор информации о сроках эксплуатации оборудования. Выявление наиболее старого оборудования.
Анализ затрат на ремонт оборудования с истекшим назначенным производителем сроком службы.
Анализ возможности продолжения эксплуатации оборудования с истекшим назначенным производителем сроком службы (в т.ч. расчет окупаемости проекта) с учетом статистики отказов. 
Низкая
Убедиться в обоснованности отказа от оригинальных расходных материалов.  Оборудование, находящееся на гарантии, эксплуатируется исключительно с оригинальными расходными материалами. После окончания гарантии происходит переход на неоригинальные расходные материалы.
Выбор неоригинальных расходных материалов сделан на основании расчета, подтвержденного финансово-экономическим подразделением. 
Вариант 1. Используются самые дешевые расходные материалы.
Вариант 2. Используются только оригинальные расходные материалы (в т.ч. для старого оборудования).
Вариант 3. Для всего оборудования, в т.ч. находящегося на гарантии, используются неоригинальные расходные материалы. При этом расчеты эффективности использования данных материалов отсутствуют. 
Анализ (формализованной либо неформализованной) политики по использованию расходных материалов.
Анализ обоснованности выбора неоригинальных расходных материалов с точки зрения стоимости жизненного цикла оборудования. 
Низкая
Поддержка существующего программного обеспечения Убедиться в оптимальности распределения объема поддержки между собственными и привлеченными силами.  Принципиальные доработки (новый функционал) передаются подрядчику, при этом проводится конкурс как минимум из двух надежных поставщиков.
Незначительные доработки осуществляются собственными силами. 
Стоимость поддержки не рассчитывается.
Общий объем трудозатрат на аутсорсинг поддержки в течение года превышает 400-500 человеко-часов в месяц. 
Проверка (проведение) расчетов стоимости выполнения работ собственными силами и с привлечением подрядчиков.
Анализ оптимальности объема работ, переданных подрядчикам.
Сопоставление технических заданий подрядчику и функционала собственной службы поддержки на предмет выявления дублирования работ. 
Высокая
Убедиться в наличии актуального перечня необходимых доработок существующего ПО.  Существует общедоступная сводная таблица доработок в ПО.
Перечень актуализируется в течение 1-2 рабочих дней после получения заявки. 
Перечень необходимых заявок не является общедоступным.
Перечень необходимых доработок для следующего релиза определяет начальник отдела поддержки. 
Проведение интервью с ключевыми пользователями о качестве проводимых доработок.
Контроль наличия и актуальности перечня необходимых доработок существующего ПО. 
Низкая
Убедиться в необходимости проводимых доработок.  Приоритезация заявок осуществляется коллегиально.
При оценке осуществляется ориентировочный расчет затраты / эффективность (доработки трудоемкостью 2 человеко-месяца для получения не очень нужной информации отсутствуют).
В группу входят представители заказчика (финансово-экономическое управление / производственные подразделения и т.д.).
При отклонении заявки инициатор заявки имеет возможность высказать мнение. 
Вариант 1. Все заявки (в т.ч. которые возможно выполнить с помощью конструктора отчетов) включаются в перечень доработок без обсуждения необходимости.
Вариант 2. Решение о необходимости доработок принимает начальник отдела поддержки. При этом в качестве причин для отказа может фигурировать «избыточная трудоемкость». 
Анализ организации процесса принятия решений о необходимости доработок существующего программного обеспечения.
Анализ необходимости проведенных за продолжительный период времени доработок. 
Средняя
Убедиться в разумности сроков доработки по дополнительным техническим заданиям (заявкам пользователей). Релизы осуществляются ежемесячно.
Для включения в релиз незначительной доработки достаточно подать заявку за 10 дней до релиза.
Отсутствуют заявки, выполняемые более 3-4 месяцев.
Релизы, связанные с нарушениями информационной безопасности, выпускаются в течение 1-2 рабочих дней с момента выявления проблемы. 
Существуют заявки (пусть даже самого низкого приоритета) со сроком исполнения более полугода.
Отсутствуют внеплановые релизы для доработок, связанных с информационной безопасностью. 
Проведение интервью с ключевыми пользователями об удовлетворенности сроками проводимых разработок.
Расчет среднего срока доработок разного уровня приоритетов.
Анализ возможностей ускорения доработок. 
Средняя
Убедиться в тестировании новых релизов перед установкой на рабочую базу.  Тестирование релизов проводится на тестовых базах.
Тестовые базы / среды разработки могут имитировать реальную нагрузку. 
Тестовые базы отсутствуют, релизы тестируются на основной базе.  Анализ порядка тестирования новых релизов.
Контроль наличия тестовой базы.
Контроль отсутствия доступа к основной базе у разработчика (доступ к основной базе должен иметь только администратор). 
Высокая
Убедиться в документировании внесенных изменений.  Исходный код сохраняется в независимом файле в общепринятом формате (например, txt-файл).
Исходный код содержит комментарии, позволяющие стороннему пользователю разобраться в сути кода.
Ведется журнал внесенных изменений.
Состояние перед каждым очередным релизом сохраняется на независимом носителе продолжительное время. 
Документирование внесенных изменений не осуществляется либо осуществляется в виде хранения промежуточных версий на ПК разработчика.  Анализ подходов к документированию изменений в ПО.
Выборочное сравнение задокументированных изменений и реального кода в основной базе.
Тестовое восстановление по релизу не ранее предпредыдущего.
Высокая
Убедиться в достаточности обучения пользователей.  Обучение пользователей проводится регулярно. По итогам обучения проводится тестирование.
Пользователь имеет возможность проконсультироваться с разработчиком по телефону.
Одновременно с новым релизом всем пользователям рассылается описание проведенных обновлений. Описания хранятся в общедоступных папках.
Не позднее одного рабочего дня после выхода релиза в действующие инструкции для пользователей вносятся изменения, выделяемые цветом. 
В качестве обучения пользователей рассылается описание проведенных обновлений.
Консультации для обучения возможны только через helpdesk.
Инструкции для пользователей не актуализировались с момента внедрения системы. 
Анализ очных обучающих программ на предмет достаточности.
Анализ существующих инструкций для пользователей всех уровней с точки зрения их актуальности.
Контроль наличия описания релизов в общедоступных папках. 
Средняя
Поддержка пользователей Убедиться в регистрации инцидентов.  Существует система service-desk, заявки в которую поступают в электронном виде (кроме заявок по неработоспособности сети).  Регистрация инцидентов либо не осуществляется, либо осуществляется непосредственно IT-специалистом по итогам выполненных работ.  Расчет фактических показателей, предусмотренных SLA (в т.ч. оценка доступности и непрерывности сервисов).
Анализ причин регистрации инцидентов непосредственно сотрудниками IT-подразделений (за исключением заявок по неработоспособности сети). 
Низкая
Убедиться в разумности времени устранения инцидентов.  Срок устранения проблем по заявкам пользователей не превышает установленных SLA.  Имеются простои конкретных сотрудников в течение четырех часов и более.  Анализ сроков устранения инцидентов по заявкам пользователей.
Анализ причин устранения инцидентов свыше 4 часов. 
Средняя
Убедиться в удовлетворенности пользователей технической поддержкой.  Регулярно проводятся анонимные опросы, в которых может принять участие каждый сотрудник.
Анкеты допускают открытые ответы и дополнительные комментарии к оценкам.
Результаты опроса подводятся независимо от IT-подразделений.
Результаты опроса являются одним из КПЭ для кого-либо из руководителей IT-подразделений. 
Проводятся выборочные опросы (менее 25% пользователей).
IT-подразделение либо влияет на выбор пользователей (определяет «ключевых»), либо самостоятельно подводит итоги. 
Анализ методики проведения опроса. При неудовлетворительности методики — проведение нового опроса удовлетворенности пользователей.
Проверка расчетов по итогам проведенных опросов. 
Низкая
Убедиться в принятии мер по снижению количества обращений.  Обращения пользователей регулярно анализируются.
Для исключения повторных / наиболее частых обращений создаются инструкции, которые размещаются в общем доступе. 
Анализ повторных / множественных обращений не проводится.  Анализ причин повторных / множественных обращений (исключение — беспроводные мышки. Абсолютно во всех организациях есть любители, мыши через год начинают глючить, но любителей не остановить).
Выявление фактов некорректной работы IT-подразделения по устранению проблем пользователей. 
Высокая
Управление информационной безопасностью Убедиться в наличии «традиционных» способов: антивирусов, файрволлов, средств криптографической защиты информации (при необходимости).  Весь траффик проходит через межсетевые экраны. При этом межсетевые экраны — от ведущих производителей (например, включенных в квадрант Гартнера).
Сервера и персональные компьютеры защищают антивирусы разных производителей. 
Межсетевым экраном защищен только центральный офис.
Значимые для деятельности физически обособленные подразделения (кроме торговых точек) межсетевым экраном не защищены.
Используются условно-бесплатные антивирусы. 
Анализ обоснования выбора производителей hardware для информационной безопасности (межсетевые экраны, СКЗИ и пр.).
Анализ защищенности обособленных подразделений.
Тестирование защиты от внешнего проникновения путем попытки несанкционированного доступа к данным компании и внесения вируса извне. 
Средняя
Убедиться в регулярном обновлении программного обеспечения для защиты.  Обновление средств защиты проводится в автоматическом режиме ежедневно.  Автоматическое обновление отключено, обновления проводятся вручную и не регулярно.  Анализ логов по обновлению ПО для антивирусов, межсетевых экранов, средств криптографической защиты информации и пр.  Низкая
Убедиться в наличии основополагающих документов в области информационной безопасности.  Общее количество документов не превышает 3-5.
Общий объем документов, которые должен соблюдать пользователь, не превышает 20-30 страниц.
Документы выполнимы и не содержат условий для сотрудников, которые принципиально изменяют их обычный распорядок дня. 
Вариант 1. Количество документов по информационной безопасности, который должен знать пользователь, превышает 10-15 документов.
Вариант 2. Документы по информационной безопасности (в т.ч. разъяснения о том, что такое информационная безопасность) отсутствуют (возможно, за исключением правил внутреннего трудового распорядка). 
Анализ документов в области информационной безопасности на предмет полноты.
Анализ возможностей минимизации общего количества документов (при необходимости). 
Высокая
Убедиться в соблюдении основополагающих документов в области информационной безопасности.  Настройки информационных систем регулярно проверяются на соблюдение основополагающих документов.
Сотрудники ознакомлены с основополагающими документами в области информационной безопасности.
Регулярное тестирование сотрудников на знание документов в области информационной безопасности.
В случае выявлений неосознанных нарушений сотрудниками в области информационной безопасности службой безопасности проводится профилактическая работа.
Имеются факты увольнения сотрудников за попытки несанкционированного доступа к данным. 
Документы в области информационной безопасности разработаны, но либо не утверждены, либо не произошло ознакомление сотрудников под подпись (документы просто разосланы по электронной почте).
Регулярный мониторинг соблюдения (настройки информационных систем, действия пользователей) основополагающих документов отсутствует. 
Проверка соответствия реальных настроек информационных систем настройкам, указанным в основополагающих документах.
Проверка ознакомления сотрудников с основополагающими документами в области информационной безопасности.
Анализ механизмов контроля сотрудников на предмет соблюдения документов в области информационной безопасности.
Выборочное тестирование соблюдения ключевых ограничений на рабочих местах (примеры: отсутствие возможности записи на флэш-накопители, отсутствие пар логин/пароль на столах и в тумбочках, анализ возможности установки ПО и пр.). 
Средняя
Убедиться в эффективности проводимой в отношении сотрудников политики по предоставлению доступа к информационным системам.  При открытии доступа сотрудникам действует принцип «четырех глаз» (непосредственный руководитель сотрудника, представитель СБ).
Одновременный доступ к администрированию и использованию отсутствует.
Стандартные профили доступа (роли) для каждой должности сформированы, профили соблюдаются.
Регулярная инвентаризация по наличию доступа пользователей. 
Доступ, в том числе к администрированию, согласуется только с владельцем бизнес-процесса (например, с главным бухгалтером или директором по производству).
Профили доступа (роли) для каждой должности отсутствуют.
Инвентаризация прав доступа пользователей не проводится. 
Анализ порядка открытия доступа пользователям.
Запрос информации о профилях пользователей в разных информационных системах.
Выявление совмещения прав на администрирование и изменение информационных систем.
Контроль отсутствия несанкционированного доступа. 
Высокая
Убедиться в эффективности действий при увольнении сотрудника.  Доступ закрывается не позднее начала следующего рабочего дня после увольнения.
Регулярный мониторинг почты уволившегося сотрудника (непосредственным начальником, сотрудником СБ). 
Регулярные процедуры по сопоставлению открытого доступа и списка работающих сотрудников отсутствуют.  Анализ процедуры увольнения сотрудника (в т.ч. закрытие доступа, контроль сохранности оборудования).
Сопоставление открытых доступов в Active Directory и актуального списка сотрудников. 
Средняя
Убедиться в наличии и возможности восстановления резервных копий баз данных.  Регулярные тренировки по восстановлению баз данных (хотя бы на тестовых базах).  Бэкапы складируются в шкаф либо хранятся в хранилищах данных, попыток восстановления не проводится.  Контроль логов на предмет соблюдения установленной политики по созданию резервных копий (например, ежедневно).
Выборочное тестовое восстановление какого-либо сервиса (желательная дата — не менее 1 месяца, то есть «откатывание» на продолжительный срок). 
Высокая
Убедиться в качестве расследования инцидентов в области информационной безопасности. Инциденты в области информационной безопасности регистрируются.
Для расследования каждого инцидента назначается ответственный.
По каждому инциденту формируется отчет с рекомендациями.
Рекомендации по итогам расследования инцидентов, в основном, выполняются. 
Инциденты в области информационной безопасности только обсуждаются.  Анализ порядка регистрации инцидентов в области информационной безопасности.
Анализ порядка расследования инцидентов в области информационной безопасности.
Контроль принятия мер по итогам расследования. 
Высокая
Управление лицензиями Убедиться в наличии системы мониторинга количества используемых лицензий.  Ежегодная инвентаризация используемых лицензий.
Наличие специализированного программного обеспечения для выявления используемого ПО.
Перерасчет стоимости лицензий по итогам выявления используемого ПО. 
Информацию о лицензиях можно получить только на основании учетных данных.
Внешние аудиты выявляют значительный перерасход по количеству используемых лицензий по сравнению с оплачиваемыми. 
Анализ результатов внешних аудитов по использованию лицензий (при наличии).
Сопоставление перечня используемых лицензий и количества пользователей. 
Высокая
Убедиться в необходимости и достаточности используемых лицензий.  Проведение регулярного анализа по минимизации стоимости владения лицензиями (рассмотрение пакетных предложений; возможность отказа от лицензий, которые включены в другие пакеты; анализ необходимости дальнейшего использования лицензий, анализ количества инсталляций и пр.).
Наличие утвержденного перечня конфигурации программного обеспечения для каждого рабочего места каждой профессии.
Установка дополнительного программного обеспечения только по согласованию с руководителем профильного и IT-подразделения. 
Программное обеспечение устанавливается «по заявкам», без анализа количества уже использованных лицензий.  Анализ необходимости имеющихся лицензий.
Анализ возможностей сокращения затрат на приобретение лицензий.
Анализ достаточности закупленных лицензий для наиболее важных с точки зрения бизнеса рабочих мест. 
Высокая
Учет IT-компонент Убедиться в наличии необходимой аналитики учета.  Учетная система позволяет учитывать месторасположение IT-оборудования.
Учетная система позволяет учитывать наличие компонент в составе ОС (серверов, компьютеров). 
Учет IT-оборудования ведется в разрезе МОЛ без аналитики в привязке к месторасположению.
На основании требований бухгалтерии невозможно отразить движение компонент в составе основного средства. 
Анализ существующей аналитики учетных систем с точки зрения потребностей в учете IT-компонент.  Средняя
Убедиться в своевременности отражения движения IT-имущества.  При выдаче оборудования со склада указывается место размещения оборудования, указать место размещения может IT-специалист без привлечения сотрудников учетных подразделений.
Инвентаризация проводится ежегодно.
Неиспользуемые компоненты сдаются на склад. 
Отражение месторасположения имущества осуществляется в процессе инвентаризации.  Выборочная проверка правильности отражения в учете фактического расположения IT-компонент.
Выборочная проверка опечатывания оборудования, с которым работают пользователи.
Проведение проверки наличия комплектующих, предусмотренных поставщиком, в серверном и пользовательском оборудовании (с помощью специальных утилит). 
Высокая
Убедиться в корректности отражения нематериальных активов, связанных с управлением информационными технологиями.  Закупленное ПО отражается как нематериальный актив.
Для целей МСФО доработки ПО капитализируется. 
Доработки программного обеспечения не капитализируются.  Проверка отражения в учете программного обеспечения как нематериального актива.
Анализ порядка отражения доработок (в соответствии с РСБУ и МСФО). 
Высокая
Убедиться в эффективности работы комиссии по списанию IT-имущества. Комиссия функционирует не реже одного раза в полгода.
Необходимость списания подтверждается специалистом финансово-экономического отдела либо на основании установленных сроков службы, либо на основании справки об отсутствии поддержки (при этом подтверждение отсутствия поддержки можно увидеть на сайте производителя).
Списанное имущество продается централизованно либо уничтожается комиссионно.
Переполненные неликвидами склады отсутствуют. 
Существует склад более 20 кв. м., наполненный неликвидами до потолка.
Судьба имущества после списания не отслеживается. 
Анализ порядка ликвидации имущества.
Контроль движения списанного имущества. 
Низкая

Подходы к формированию программы.

Возможны несколько подходов к формированию программы. Если хочется «более классического» – можно использовать любую «официальную» классификацию (все картинки ниже сворованы из интернета).

Самая передовая из таких – «эталонная модель процессов CObIT»:

Кстати, для любителей подхода от «целей» («цели — риски — контрольные процедуры») CObIT также дает нужный перечень.

Можно воспользоваться моделями ITIL/ITSM.

Классика ITIL:

ITSM на примере компании «Ай-теко» (не реклама, просто одна из первых картинок в yandex):

Для анализа процесса разработки программного обеспечения можно использовать набор процессов из ГОСТ Р ИСО/МЭК 12207-2010.

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

Но, как и всё на этом сайте, представленная программа содержит авторские подходы. Как результат – почти всё полезное учтено, но c помощью других слов. И, как нам кажется, для «чайников», то есть не IT-аудиторов по основной профессии, представленная программа вкупе с другими вкладками по процессу «Управление IT» попроще и, как следствие, понятнее.

Общие комментарии.

Несколько принципиальных комментариев:

  1. Для выполнения программы необходимы именно IT-специалисты. «Обычные» аудиторы (условно, операционные или финансовые) могут сделать процентов, наверное, 80 из программы. Но самое интересное кроется в оставшихся 20%: защита периметра, настройки программного обеспечения для обеспечения информационной безопасности, корректность тестирования релизов перед переносом в основную базу, тестирование фактического восстановления и пр. Если «денег нет», то держитесь. На самом деле – раз в 2-3 года любой бизнес может позволить себе заказ данной услуги на стороне, цена вопроса «под ключ» на момент написания (2017 год) – от 2 млн. руб., привлечение консультанта на 1 месяц еще дешевле. Предотвратить можно очень многое.
  2. Как уже было сказано на вкладке для постановщика систем внутреннего контроля, в большинстве случаев в процессе управления информационными технологиями возникает значительно больше бумаг по сравнению с любым другим процессом. С одной стороны, это хорошо, с другой – плохо. Хорошо – потому что количество недостатков при регламентации процесса значительно возрастает (хорошо читаются фразы типа «в нарушении п. N.M.L. …»), внутреннему аудитору всегда есть чем заняться (большая организация обрастает макулатурой, ее чтение может занять человеко-неделю, а подробное – и человеко-месяц), отчеты растут и пр. Плохо – потому что сути проблем находки по несоблюдению документов не выявляют, а сами находки и рекомендации, вообще говоря, неинтересные (особенно с учетом потраченной трудоемкости). Поэтому, традиционно для этого сайта, рекомендуем внутреннему аудитору не столь тщательно останавливаться на compliance-соответствии процессов IT описанным в документах, а «зрить в корень». Отчет в стиле «многочисленные нарушения основополагающих документов» именно по IT (в отличие от охраны труда и техники безопасности) не проходит. Но само compliance-несоответствие вполне может быть вишенкой, которая украшает отчет.
  3. Когда будете исследовать достаточность инфраструктуры – обратите внимание на стоимость в случае, если инфраструктура явно избыточна. Типовой пример – пропускная способность интернет-канала. Стоимость канала пропускной способностью 100 Мб/с и 1 Гб/с на момент написания различается примерно на $50 в месяц. Конечно, можно и побороться за $600 в год, но, IMHO, не стОит. А вот когда под соусом «резервирования» к каждой будке вне территории ведут две независимых оптоволоконных линии или для хранения информации о продажах пятилетней давности создается сеть территориально распределенных хранилищ данных с онлайн-синхронизацией – траты нужно прекращать.
  4. Один из самых сложных вопросов – это корректность выбора платформы для автоматизации (условно, что нужно было выбрать – SAP, Axapta или 1С). Из программы проверки этот вопрос вычеркнут, потому что привести примеры эффективного и неэффективного дизайна практически невозможно. Можно привести следующие рекомендации: если численность сотрудников менее тысячи человек – 1С должно хватать, SAP – рановато. Если численность сотрудников больше 10000 человек – система должна быть «тяжелой» в случае, если есть потребность.
  5. Подход к оценке графика проведения работ при реализации проектов должен основываться на разумности. Но, так как разумность (то бишь суждение) – понятие, которое менеджмент очень любит в отношении себя и терпеть не может, если его применяет аудитор, поясним, откуда растут некоторые показатели, указанные в программе:
    • поставка сложного / нестандартного оборудования, поставка оборудования в большом объеме. Как правило, оборудование идет морем, типовой маршрут «Китай-Гамбург» занимает 45 дней только на теплоходе. Соответственно, 60 дней – это абсолютный минимум, желательно увеличить его до 75 дней. Исключение – если оборудование на территории РФ или в пути, но в этом случае возникают вопросы о выборе поставщика (понятное дело, что вопросы возникают, если речь не идет о 10 мониторах). Конечно, в некоторых случаях возможна авиадоставка (2-3 дня), но деньги нужно экономить;
    • согласование. Должно занимать не менее двух недель. Да, с одной стороны, вроде как 5 дней достаточно. Но личные наблюдения показывают, что срок в абсолютном большинстве проектов не соблюдается и, на самом деле, даже 10 рабочих дней мало;
    • разумные действия (например, формирование фундаментальных документов объемом 100 тыс. знаков и более либо программирование). Минимум – 3 недели. В противном случае есть шанс получить труд соответствующего качества (абсолютно невычитанное и баги). При этому нужно понимать, что для очень многих действий срок в 3 недели – маловат. Создание и тестирование кода даже для обычной учетной системы может занимать несколько месяцев.
  6. Как уже сказано на вкладке для постановщика СВК, по нашему мнению, документов в области информационной безопасности не должно быть много. В программе вопрос того, что именно должны содержать документы в области ИБ, не отражен из-за объемности. Перечень возможных разделов легко нагуглить, главное – смотрите, чтобы условные политика VPN, положение о сканировании уязвимостей или же порядок работы в локальной вычислительной сети были действительно нужны для Вашего бизнеса.
  7. В части учета IT-компонент программа содержит только специфические требования для IT-ресурсов. Остальное (начиная от назначения материальной ответственности и заканчивая раздельным хранением исправного и неисправного оборудования) есть в программе аудита движения ТМЦ.

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

Повышение эффективности проверки.

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

  1. Начните с анализа инцидентов. В подавляющем большинстве инциденты не случайность, а следствие некой закономерности, которую и предстоит выявить. Также можно сравнить факты инцидентов с записями об инцидентах, посмотреть протоколы расследований и пр.
  2. Посмотрите на дату создания файлов, которые придут в ответ на информационный запрос. Может оказаться, что некоторые документы не менялись последние 1-2 года, что явно неправильно (за исключением стратегий).
  3. Посмотрите на информацию на общедоступных дисках. «Помойка» в обменных папках свидетельствует о том, что информационную безопасность можно усилить. В особо удачных случаях можно найти перечень паролей какого-либо подразделения 🙂 .
  4. Проанализируйте журнал регистрации заявок. Поговорите с пользователями, которые оставляют наибольшее количество заявок, на предмет удовлетворенности работой IT-подразделений. Квалифицированный пользователь укажет на явные проблемы в организации поддержки при их наличии.
  5. Опросите сотрудников дружественных подразделений (управление рисками, внутренний контроль, безопасность, финансово-экономические подразделения) об их мнении по вопросу работы IT-подразделений. Уверяем Вас, узнаете много нового.

В заключение раздела – о природе возникновения «традиционного» отчета по итогам IT-аудита, состоящего из 100 страниц, наполненных картинками, табличками, галочками, стрелочками и крестиками. Вершина такого подхода к аудиту – четкое следование CObIT, который содержит «оценку уровня зрелости бизнес-процесса» и «оценку достижения целей процесса». Данный подход в разрезе процессов и приводит к феерическому росту не очень полезной макулатуры: ведь для каждого процесса нужно оценить все рекомендуемые компоненты. Например, сказать, что зрелость процесса «Управление подходом к управлению IT» находится между «управляемым» и «установленным» уровнем, при этом рейтинг достижения целей процесса – L, «в основном достигается». Картинки действительно красивые, отчет в виде презентации получится замечательный (почти четыре десятка страниц – по числу процессов).

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.