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

Колесник Д. Н.
выпускник группы MBA CIO-28b
Школа IT-менеджмента
РАНХиГС при Президенте РФ

ЗАО «Прогноз»
Руководитель проектов
г. Москва

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

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

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

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

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

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

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

Место Системы в процессе управления и ИТ-архитектуре предприятия

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

• организационной структуры предприятия;
• порядка принятия управленческих решений;
• принятого порядка и норм процесса учета и планирования на предприятии.

Взаимосвязь групп работ элементов организационной составляющей проектьа отражена на Рис.1.

Рис. 1 - Организационная составляющая проекта
Место системы управления в ИТ-архитектуре предприятия может быть очень разным: от витрины над одним или несколькими информационными источниками с небольшим набором отчетных форм до части комплексного решения, включающего в себя информационные системы источников, ЦХД, MDM-системы.   
Кроме целей и назначения Системы ее место в ИТ-архитектуре определяется типом ИТ-архитектуры, который варьируется от «лоскутного оделяла» до «сервисно-ориентированной среды». 
Результаты анализа соответствия целей и задач проекта внедрения и «зрелости» архитектуры ИТ могут служить руководителю проекта дополнительной информацией, помогающей определить завышенные ожидания или со стороны бизнеса или со стороны ИТ. 

Проблемные области проекта

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

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

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

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

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

Рис. 2–Группы рисков проекта
Можно отметить, что подобный перечень и группировка рисков может быть применима и к другим типам ИТ-проектов, которые сопровождаются рядом организационных изменений на предприятии.

Ключевые риски проекта

Первая группа – организационные риски.
Организационные риски можно также разбить на следующие группы:

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

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

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

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

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

Рекомендации

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

Список использованных источников

• Беркун С. «Искусство управления IT-проектами», Питер, СПб, 2010 г.
• «Внедрение сбалансированной системы показателей», Horvath&Partners, 2006.
• Джестон Д., Нелис Й. «Управление бизнес-процессами», Символ плюс, Москва, 2008.
• Забелина Н.В., Материалы лекций «Управление по показателям», Москва, 2011 г.
• «Концепция контроллинга. Управленческий учет, система отчетности, бюджетирование», Horvath&Partners,  Москва, 2008.
• Соколова Г.Н., Материалы лекций «Бюджетирование. Управленческий учет», Москва, 2011.
• Спирли  Э. «Корпоративные хранилища данных», Вильямс, Москва, 2001.
• Тейлор Д., Рэйден Н. «Почти интеллектуальные системы», Символ, Москва, 2009.
• Томсетт Р. «Радикальное управление ИТ-проектами», Москва, 2007.
•  Чернов А.,  Материалы лекций  «Архитектура и стратегия ИТ», Москва, 2011.