Лекция 2 Стратегия развития ИТ
advertisement
ЛЕКЦИЯ 2 СТРАТЕГИЯ РАЗВИТИЯ ИТ Вопросы: Информатизация в госсекторе. Состояние и основные направления автоматизации [1]. 1. Что такое ИТ-стратегия. 2. Управление реализаций ИТ-стратегии. Тема развития ИТ-стратегии и ее взаимосвязи с общей бизнесстратегией предприятия интересна большинству руководителей информационных служб. Рассмотрим отдельные вопросы определения ИТ-стратегии, основываясь на мнениях самих CIO — ведь точка зрения заказчика важна не менее мнений поставщиков, ибо от того, что думают заказчики, во многом зависит, как будет развиваться сам рынок и его отдельные направления. ЧТО ТАКОЕ ИТ-СТРАТЕГИЯ. (НАСТОЛЬНЫЙ ЖУРНАЛ ИТРУКОВОДИТЕЛЯ «ДИРЕКТОР ИНФОРМАЦИОННОЙ СЛУЖБЫ» WWW.OSP.RU/CIO) Что должна представлять собой ИТ-стратегия? Какие цели и задачи должна преследовать разработка ИТстратегии предприятия? Как ИТ-стратегия должна соотноситься со стратегией бизнеса? Что представляет собой информационная система предприятия (ИСП): только инструмент учета и управления или нечто большее? ИТ-стратегия определяет долгосрочные цели и направление движения предприятия в области ИТ. Результатом ее применения и использования является успешное существование компании. «В современных условиях ИТ-стратегия является неотъемлемой частью общей бизнес-стратегии и должна подчеркивать и развивать ключевые факторы успеха и выигрышные особенности компании». При разработке любой стратегии используется принцип каскадирования сверху вниз, и ИТ-стратегия должна непосредственно вытекать из стратегии компании. Если стратегия всего бизнесподразделения говорит о том, что должна делать организация, чтобы достичь своих целей, ИТ-стратегия отвечает на вопрос: как, с точки зрения ИТ, она должна работать. При разработке ИТ-стратегии необходимо, в первую очередь, глубоко понимать бизнес-стратегию организации и роль ИТ в структуре предприятия. В зависимости от вида деятельности роль ИТ в организации может варьироваться от базовой поддержки и обеспечения бесперебойной работы ИТ-инфраструктуры и сервисов — до определяющей и жизненно важной в основных бизнес-процессах. ИТ-стратегия должна в полной мере отвечать целям и задачам, которые стоят перед предприятием, прежде всего, в сфере основного бизнеса, а также способствовать реализации конкурентных преимуществ предприятия на рынке. Hаиболее трудным в области разработки ИТ-стратегии является не определение и понимание направлений развития ИТ и требуемых инвестиций, а умение практически применять накопленный опыт. Сам процесс, по его мнению, определяется довольно просто: определение бизнес-цели, требования, проблемы, задачи, ИТ-решения. Основу при определении ИТ-стратегии составляет информация о пользователях, которую удается собрать при проведении анализа бизнес-процессов предприятия. Знание бизнеса и требования пользователя трансформируются в бизнес-цели ИТ-департемента и планы их достижения. Что касается самой информационной системы предприятия, то, по мнению руководителей ИТ-служб, ИСП должна быть составляющей ИТстратегии. В зависимости от задач, возлагаемых на систему, можно говорить об успешности ее применения в рамках определенной ИТстратегии компании. Но в то же время «нельзя говорить об ИСП как об основной составляющей, т. е. зачастую система не является даже ядром, вокруг которого строится стратегия. Скорее наоборот, ИСП должна органично автоматизировать некоторые бизнес-процессы. Известны случаи некоторой адаптации бизнес-процессов компании при внедрении ИСП, но их полное изменение никоим образом не должно быть связано с применением системы. Обычно такие проекты заканчиваются неудачей». «На некоторых предприятиях ИСП не позволяет даже осуществлять функции учета и контроля. А в действительности ИСП может и должна быть мощным инструментом для изменения бизнес-процессов. И примеров тому множество — от оптимизации взаимодействия между отделами до сложных реструктуризаций и слияний». Относительно учета и контроля наиболее конкретно выразился «ИСП традиционно являлась именно инструментом учета и управления. Однако в условиях трансформации бизнеса и осознания ценности накопленных знаний ИСП превращается в инструмент для управления и использования этого капитала в интересах дальнейшего развития бизнеса. Это, а также использование интернет-технологий, появление электронных инструментов бизнеса и глобализация экономики делают ИСП фундаментом для построения предприятий нового типа — digital firm в современной западной терминологии». Что прописывать? Не менее важным представляется вопрос о том, что должно быть определено в ИТ-стратегии, а что можно и должно отнести к техническим задачам по ее реализации? Понятно, что, в первую очередь, должны быть определены долгосрочные цели и направление движения компании в области информационных технологий. И эти аспекты, как наиболее важные и значимые, должны быть определены с необходимой степенью детализации. Кроме этого, по мнению Владислава Дементьева, «в стратегии должны быть учтены возможности гибкого реагирования на внешние и внутренние факторы воздействия бизнес-среды. Все остальное можно отнести к задачам по реализации». «Стратегия должна помогать принимать решения, то есть в ней должны быть сделаны некие принципиальные выборы, ответы на важнейшие вопросы, которые будут возникать в течение ближайших лет. Какие именно — зависит от конкретной ситуации». В качестве примера – сравнение с военной стратегией — например, мы решаем, что наша военная стратегия оборонительная. Это выбор, который мы сделали и который определяет общее направление. На каждом участке фронта разные схемы обороны, линии рубежей, иногда мы переходим в контратаки, но все равно придерживаемся общего принципа — обороняться. А Сергей Пегасов сформулировал ряд требований, которые должны присутствовать в «документе, определяющем ИТ стратегию предприятия: — Артикулированы стратегические задачи в сфере основного бизнеса, имеющие отношение к ИТ и реализуемые, в том числе, с их помощью. — Определены стратегические задачи ИТ — в целом, исходя из бизнес-задач и функции подразделения в компании. — Определена функция ИТ-службы в компании, проведен анализ состояния ИТ-подразделения по отношению к компании. — Определены общие подходы к реализации стратегических задач. Например: способы реализации проектов (разработка, аутсорсинг и пр.); подход к поддержке основных ИТ-сервисов (традиционный, SLA); организационные аспекты и т. д. — Даны основные критерии успешного решения основных стратегических задач ИТ. Все это должно быть сделано концептуально — не опускаясь на уровень деталей, и на языке, понятном и бизнесу, и руководителям ИТслужбы. Всю детализацию, конкретные процедуры, средства, на мой взгляд, следует отнести к техническим задачам по реализации стратегии». Финансирование Какие средства предприятие должно инвестировать в развитие ИТ, для того чтобы получить эффект? Как должны оцениваться риски неудачного внедрения? Кто за них должен нести ответственность? По мнению Владислава Дементьева, «количественные показатели зависят от каждого конкретного случая. А что касается рисков от внедрения, то их следует оценивать аналогично рискам любого проекта, и в этом смысле ИТ-проекты не являются чем-то уникальным и должны использовать методологию оценки рисков при внедрении проектов. Ответственность должна возлагаться на тех, кто определяет стратегию. Зачастую, в отсутствие позиции CIO, стратегия определяется руководством компании, а ее реализация возлагается на руководителей информационных департаментов и служб, не имеющих достаточных полномочий и не участвующих в определении общей бизнес-стратегии». А вот по мнению Александра Москвина «самая дорогая инвестиция это внимание руководства. Эффективность ИТ-проектов зависит в первую очередь от того, насколько серьезно к ним относятся руководители разных уровней и рядовые сотрудники. Зачастую, это „стоит“ для компании больше, чем прямые расходы на покупку лицензий, техники и т. п. Соответственно, ответственность за неудачное внедрение лежит на менеджерах, вовлеченных в проект — не только на руководителе проекта или CIO, но и, например, на финансовом или генеральном директоре». Вообще, к сожалению, однозначных ответов на подобные вопросы не существует. Действительно, слишком уж все индивидуально. Об этом говорит Сергей Пегасов. По его мнению «если компания работает в сфере высоких технологий, либо если ИТ лежит в основе основных бизнес-процессов компании — это одни цифры. Если бизнес компании в большей степени „традиционный“ и ИСП используется, в основном, для нужд администрирования и контроля — цифра будет другой. В мировой практике есть разные критерии оценки. Наиболее распространенная — это выделение на информатизацию предприятия от 2 до 5 процентов годового оборота компании. Что касается оценки рисков, то, как считает Сергей Пегасов, — это отдельная, большая тема для обсуждения. Однако, по его мнению, «риски внедрения должны оцениваться до начала внедрения и до покупки информационной системы (звучит тривиально — но далеко не всегда это делается именно до)». Также, на его взгляд, «к оценке рисков следует привлекать и внешние по отношению к ИТ службы (финансовую, юридическую, персонала), и сторонних экспертов. И если после оценки всех рисков решение о внедрении принято — ответственность за риски должно нести лицо, принимающее решение. В части ИТ-проектов это, скорее всего, CIO». Интересное мнение высказывает Михаил Носов. Он считает, что «для успешного решения проблемы практической реализации ИТрешений необходимо воспитывать специалистов, добиваться обоснованных инвестиций в их подготовку и обучение. И здесь на первое место выходит способность руководителя ИТ-служб обосновать необходимость внедрения новых технологий с точки зрения бизнеса, верно спрогнозировать результаты и преимущества этого процесса и, главное, суметь донести все это до высшего управляющего звена предприятия и непосредственных пользователей, не потеряв кредит доверия на будущее». Проблемы С какими же проблемами сталкиваются руководители ИТ-служб при определении ИТ-стратегии? Как они преодолеваются? Основной проблемой Владислав Дементьев считает то, что «определение ИТ-стратегии идет в отрыве от основной стратегии компании. Под ИТ-стратегией часто понимается внедрение ИСП, причем и внедрение, в свою очередь, идет без учета особенностей бизнеспроцессов компании. Не секрет, что более 50% ИТ-проектов убыточны». С ним согласен и Сергей Пегасов. На его взгляд «основной проблемой при создании ИТ-стратегии является отсутствие формализованной бизнес-стратегии и четко оформленного краткосрочного и долгосрочного бизнес-плана на многих предприятиях. При условии, что бизнес-стратегия является первичной и при условии, что бизнес-план во многом определяет развитие, в том числе, и ИТ-инфраструктуры предприятия — ИТ-стратегия, если она все-таки создается, получается умозрительной и потому неэффективной». И эти слова звучат после того, как большинство руководителей ИТ-служб подчеркнули необходимость сочетания ИТ-стратегии с общей бизнес-стратегией предприятия. Вывод, конечно же, напрашивается неутешительный — видимо, пока еще далеко до воплощения «правильной» теории в реальную практику. К другим проблемам, по мнению большинства руководителей ИТслужб, можно отнести «нестабильность и слабую развитость рынка ИТуслуг — в особенности в регионах (сейчас ситуация гораздо лучше, но пробелы по-прежнему имеют место)». Однако преодоление этих трудностей — вопрос времени. Уровень российского менеджмента сильно вырос за последнее время, стабилизирующаяся ситуация в стране дает возможность создания долгосрочных стратегий развития компаний. Рынок услуг и аутсорсинга в области ИТ также находится на подъеме — и не только в центре, но и регионах страны. Полномочия Каковы должны быть полномочия руководителя ИТ-департамента (CIO)? Каков должен быть его статус? Отвечая на этот вопрос, респонденты выразили редкую солидарность. Обобщая мнения большинства руководителей информационных служб, приведем слова Александра Москвина: «терминов есть великое множество, но CIO (ИТ-директор) по определению должен входить в высшее руководство компании, наряду с CFO (финансовым директором), CEO (генеральным директором) и другими. И шаг от „руководителя ИТ-службы“ до CIO такой же, как от главного бухгалтера до финансового директора». А Сергей Пегасов разграничил CIO на тех, которые работают в компаниях, чей бизнес связан с ИТ, и тех, у кого ИТ не являются направлением деятельности, а служат лишь инструментом для достижения оптимальных бизнес-показателей. Он, как и большинство участников, считает, что в сфере ИТ CIO должен обладать максимумом полномочий. А что касается статуса в компании, то этот аспект, по его мнению, «в первую очередь, зависит от того, какую роль играют ИТ в основных бизнес-процессах и в концепции стратегического развития компании. Для компаний и организаций, где ИТ являются базисом или же играют ключевую роль в осуществлении основных бизнес-процессов (примеры: операторы сотовой связи, провайдеры Интернета, министерство путей сообщения) — CIO должен в обязательном порядке принимать участие в принятии решений в сфере основного бизнеса. Как правило, это статус вице-президента или директора (в ранге заместителя генерального директора), постоянного участника совета директоров компании. Во всех остальных случаях — это могут быть вариации на тему менеджерских позиций (директор, руководитель службы, руководитель отдела и т. п.) — в зависимости от принятой в компании системы управления. В этом случае роль CIO в большей степени административная». Практика К сожалению, на вопросы: «Как на вашем предприятии определена ИТ-стратегия, как она соотносится с общей бизнес-стратегией и как происходит ее реализация? О решении каких задач в области ИТ на вашем предприятии можно говорить в свете реализации ИТ-стратегии?» — большинство руководителей ИТ-служб ответа не дали. Означает ли это, что на практике реализация всего вышесказанного порой происходит с существенными отличиями от теории? Не знаем… Однако Сергей Пегасов поделился с нашими читателями тем, как обстоят дела в компании ICN Pharmaceuticals. «В нашей компании, — говорит Сергей Пегасов, — существует корпоративная служба ИТ, которая определяет глобальную ИТ-стратегию компании. Роль региональных ИТ-служб (в том числе и российской) состоит в адаптации и реализации этой стратегии в соответствующем регионе. Естественно, что корпоративная ИТ-стратегия согласуется с глобальной бизнес-стратегией. А адаптация глобальной ИТ-стратегии в регионе включает в себя, в том числе, и приведение ее в соответствие со спецификой региональной бизнесстратегии. Причем отличия, диктуемые региональными условиями, зачастую могут быть довольно сильными. Например, в нашей компании корпоративный стандарт ERPсистемы отличается от российского — и в основном именно из-за региональной специфики». Закончить материал хочется словами Михаила Носова: «Итак, с одной стороны ИТ-стратеги, с другой стороны — заказчик. Самое время поиска хорошего менеджера проекта — человека, который может связать специалиста с заказчиком. При этом необходимо умение донести концепцию до заказчика достаточно грамотно и оригинально. Недостаток такого рода специалистов ведет к упущенной выгоде нереализованных профессиональных возможностей состава ИТ-служб». Не секрет, что успешное внедрение современных IT-решений может значительно повысить эффективность бизнес-процессов финансового института. В то же время комплексная автоматизация позволяет выстроить глубоко интегрированную IT-платформу для поддержки и развития эффективного бизнеса и получения необходимой. Документ «Стратегия развития Информационных технологий» (или IT-стратегия) призван четко определить соответствие между бизнес-целями компании и необходимой им технологической поддержкой, формулирует задачи развития IT и бизнес-эффекты от их решения. Топ-менеджменту Заказчика IT-стратегия позволяет объективно и адекватно оценить возможные перспективы, последовательность, длительность и объемы поэтапных инвестиций для их достижения. Методологические наработки экспертной команды RBtechnologies могут быть использованы как в проектах разработки IT-стратегии «с нуля» для Заказчиков – финансовых учреждений, так и при аудите существующих документов. ТИПОВЫЕ ЭТАПЫ ПОДГОТОВКИ IT-СТРАТЕГИИ Этап 1: Инициация проекта Этап 2. Сбор информации Этап 3. Разработка IT-стратегии. Согласование документов Этап 1: Инициация проекта Проектные команды Заказчика и RBtechnologies проводят установочную встречу и ряд рабочих совещаний для интервьюирования менеджмента Заказчика, сбора и анализа существующих материалов. По итогам этапа команда RBtechnologies готовит и согласовывает с Заказчиком следующие документы: Устав проекта – распространяется на оставшуюся часть проекта. В Уставе фиксируются: участники проекта каждой из сторон; методология и процедуры проведения работ; рамки, цели, результаты и критерии успеха проекта; зоны ответственности и порядок взаимодействия сторон. План проекта – распространяется на оставшуюся часть проекта и описывает: последовательность и длительность этапов; контрольные точки по состоянию проекта; план работ и подготовки результатов. График интервьюирования – распространяется только на второй этап («Сбор информации») проекта. При подготовке графика интервьюирования учитывается ОШС (организационно-штатная структура) компании, графики командировок ключевых специалистов Заказчика и иные индивидуальные особенности проекта. Этап 2. Сбор информации Проектная команда RBtechnologies проводит детальное интервьюирование ключевых экспертов Заказчика в соответствии с Графиком (подготовленным на предыдущем этапе). Задачей встреч является получение информации об объемах, приоритетах и планах развития по каждому бизнес-направлению компании Заказчика. Пристальное внимание при изучении уделяется департаменту информационных технологий. Этап 3. Разработка IT-стратегии. Согласование документов IT-стратегия компании готовится с ориентиром на соответствие между бизнес-стратегией и планами развития IT, получение конкретных бизнес-результатов от использования и развития IT, оптимизацию ITзатрат. Именно стратегия развития бизнеса определяет приоритеты и порядок модернизации IT-платформы, обуславливает критерии выбора оптимальных систем и решений. При подготовке IT-стратегии учитываются не только эффекты от внедрения новых решений, но и пути снижения совокупной стоимости владения и управления всей IT-инфраструктурой компании Заказчика. В итоговом документе с описанием IT-стратегии можно выделить несколько ключевых разделов: Концепция – описание общих принципов и критериев успеха ITподдержки бизнеса. Концепция определяет векторы развития бизнеса компании и соответствующие им направления модернизации IT, а также цели и критерии успеха последовательно проводимых мероприятий. Методология – описание базовых IT-решений и методик, а также конкретных способов достижения требуемых результатов. В случае территориально-распределенного бизнеса проводится разграничение задач и ответственности между центральным и местными ITподразделениями. Отдельное внимание уделяется технологической поддержке топ-менеджмента Заказчика (задачи консолидации управленческого учета и отчетности, планирование результатов деятельности и пр.). Дорожная карта развития ИТ – описание верхнеуровневых стратегических планов, способов реализации и планируемых инвестиций для модернизации и развития IT-инфраструктуры. Стратегия развития IT тесно интегрирована со стратегией бизнесразвития компании, поэтому мероприятия плана IT-развития могут являться составными частями мероприятий по развитию бизнеса и наоборот. При создании плана как правило используется подход «от общего к частному». http://www.bsconsulting.ru/services/it_consulting/it_strategy_development/ Разработка ИТ-стратегии Стратегия в области информационных технологий (ИТстратегия) — это часть общей стратегии развития компании (в том числе в части управленческого учета и бюджетирования), в которой указано, каким образом, на основе каких технологий, в какие сроки и за какой бюджет для конкретного предприятия возможно повысить эффективность бизнеса (сократить затраты или получить дополнительную прибыль). «…При выборе партнера по реализации проекта [по разработке долгосрочной стратегии развития бизнес-приложений] главными критериями для нас являлись наличие положительных отзывов состороны коллег по отрасли, а также понимание партнером нашей отраслевой специфики. По результатам конкурсного отбора мы остановили свой выбор на компании BSC» В.Ю.Джао, Генеральный директор, ЗАО «АэроМар» (По мнению специалистов BSC, первая задача ИТ-стратегии — снизить операционные расходы предприятия, а вторая задача (и наиболее важная) — превратить ИТ-службу в двигатель бизнеса (в том числе и в части управленческого учета и бюджетирования). Если для Вашего предприятия актуальны некоторые из перечисленных ниже аспектов, то Вам необходима формализованная ИТ-стратегия: Существенная зависимость бизнеса от информационных технологий (ИТ); Желание владеть информацией, то есть информационное лидерство на целевом рынке; Системный подход в реализации общих стратегических целей предприятия; Неудовлетворенность пользователей текущим состоянием их информационной поддержки; Появление новых технологий, способных увеличить эффективность основного бизнеса компании; ИТ-бюджет приобретает размеры, заметные руководству; Статус руководителя ИТ-службы повышается до уровня высшего менеджмента. Компания BSC предлагает разработку ИТ-стратегии предприятия на основе лучших мировых практик и международных стандартов (см. раздел ITIL, ITSM, CobiT). В результате предприятие получает комплексное видение развития ИТ-инфраструктуры на ближайшие несколько лет. BSC: Направления разработки ИТ-стратегии Стратегические цели и задачи в сфере основного бизнеса, имеющие отношение к ИТ и реализуемые, в том числе, с их помощью; Стратегические цели и задачи ИТ исходя из бизнес-задач (в том числе управленческого учета и бюджетирования); Функции ИТ-службы в компании; Общие подходы к реализации стратегических задач ИТ. Например: Способы реализации проектов (инсорсинг, аутсорсинг, разработка, стандартные решения и пр.); Подход к поддержке ИТ-сервисов (традиционный, SLA); Организационные аспекты и т.д. Основные этапы реализации ИТ-стратегии; Оценка бюджета реализации ИТ-стратегии; Система мотивации персонала; Конкурентные преимущества, которые получит бизнес в результате реализации ИТ-стратегии (снижение TCO, повышение информационной безопасности, увеличение прибыли и пр.); Возможные риски; Ключевые факторы успеха реализации ИТ-стратегии (Critical Success Factors, CSF); Ключевые показатели достижения целей ИТ-стратегии (Key Goal Indicators, KGI); Ключевые показатели эффективности реализации ИТ-стратегии (Key Performance Indicators, KPI). BSC: Этапы разработки ИТ-стратегии Этап 1: Аудит ИТ-службы по стандарту CobiT. Задача — понять какие ИТ-сервисы в данный момент используются и как они функционируют. Также анализируются не только технологии, но организация работы персонала и процессов. По результатам аудита дается экспертная оценка уровня развития ИТ в соответствии с моделями зрелости CobiT; Этап 2: Оценка соответствия уровня развития ИТ текущим и перспективным требованиям бизнеса. Задача — определить какие сервисы нужны для оптимального функционирования бизнеса и каков д.б. уровень зрелости ИТ через несколько лет чтобы достичь бизнесцелей; Этап 3: Разработка ИТ-стратегии. Основные задачи — определить этапы и подходы к достижению целей развития ИТ, оценить необходимый бюджет и систему мотивации персонала, разработать критерии оценки эффективности реализации ИТ-стратегии, формализовать основные преимущества, который получит бизнес. BSC: Примеры ключевых факторов успеха (CSF) реализации ИТстратегии Наличие формализованной бизнес-стратегии (в том числе в части управленческого учета и бюджетирования); ИТ-процессы cогласованы с ИТ-стратегией и бизнес-целями предприятия; Определены участники и распределение обязанностей в рамках ИТ-процессов; Участники ИТ-процессов обладают необходимой квалификацией; Осуществляется непрерывный мониторинг ИТ-процессов и повышение их эффективности; Руководство предприятия осознает важность ИТ для бизнеса (в том числе в части управленческого учета и бюджетирования); Определены цели и задачи развития ИТ; Информация доведена до всех; Управление ИТ интегрировано в процесс управления предприятием (в том числе в части управленческого учета и бюджетирования), определены направления развития ИТ, управление рисками, процесс контроля и политика безопасности. BSC: Примеры ключевых показателей достижения цели (KGI) ИТстратегии Повышена эффективность управления предприятием; Снижено влияние ИТ-рисков; Стандартизованы бизнес-процессы (в том числе в части управленческого учета и бюджетирования); Привлечены новые клиенты; Повышено качество обслуживания клиентов; Выявлены и освоены новые каналы сбыта продукции; Соответствие продукции промышленным стандартам качества и др. BSC: Примеры ключевых показателей эффективности (KPI) реализации ИТ-стратегии Увеличено качество ИТ-сервисов; Доступность ИТ-сервисов и время получения требуемой информации; Повышена эффективность использования вычислительных средств; Количество специалистов, прошедших обучение; Соотношение «себестоимость/эффективность» ИТ-процессов; Производительность труда ИТ-специалистов; и др. Количество допущенных ошибок и сумма затрат на их устранение --------------http://www.iteam.ru/publications/it/section_91/article_1921/ http://www.studenikin.ru/ITStrategy.asp Стратегия развития корпоративной информационной системы Целью проекта по разработке стратегии развития информационной системы является снижение затрат и минимизация бизнес - рисков при решении задач информационной поддержки основных бизнесов компании. В рамках проекта по созданию стратегии развития корпоративной информационной системы необходимо реализовать следующие задачи: Разработка IT-стратегии Сегодня IT - системы - это инструмент не только повышения эффективности управления предприятием, но и создания новых конкурентных преимуществ. Следовательно, развитие IT-системы неразрывно связано с бизнес-стратегией компании. Грамотно выстроенная IT-стратегия непосредственно способствует росту стоимости бизнеса и его инвестиционной привлекательности. Под ИТ-стратегией понимается формализованная система принципов, на основе которых будут развиваться все компоненты информационных систем компании. Стратегия обеспечивает интегрированный подход к автоматизации всех контуров управления предприятием и позволяет избежать типичных недостатков "кусочной автоматизации". IT-стратегия – это программа развития информационных систем в соответствии со стратегией развития предприятия, текущими и будущими потребностями бизнеса. При разработке IT-стратегии закладываются основные параметры создаваемой информационной платформы, с тем чтобы она отвечала следующим требованиям: масштабируемость, то есть система должна учитывать растущие потребности компании; гибкость, то есть система должна быть легко настраиваемой под изменения внутренних бизнес-процессов и внешней среды; стандартизация, то есть различные компоненты системы должны быть совместимыми и соответствовать требованиям информационной безопасности; экономическая эффективность, то есть использование того или иного решения должно быть оправдано экономически; независимость, то есть заказчик не должен попадать в зависимость от поставщиков решений, при этом не должна возникать необходимость в содержании собственного штата программистов. Проект разработки IT-стратегии компании включает: Подготовительные этапы Изучение, анализ и систематизация основных и вспомогательных бизнес - процессов компании; Анализ и совершенствование информации принципов управления компании. Этапы разработки IT-стратегии Аудит существующих в компании информационных систем с целью определения их соответствия функциональным задачам бизнеса на разных уровнях управления, пользовательского окружения, структуры информационных потоков, организации хранения данных и доступа к ним; Моделирование и анализ основных и вспомогательных процессов с учетом их информационной поддержки и привязки к структуре управления; Постановка целей и задач развития информационных технологий в соответствии с целями и задачами бизнеса. Выделение первоочередных задач автоматизации и выработка предложений по их реализации; Разработка системного проекта по созданию комплексной информационной системы, предполагающего интеграцию действующих и создаваемых компонент (по функциональности, структуре данных, их преобразованию и организации доступа); Технико-экономическое обоснование отдельных проектов информатизации компании на основе выделяемых факторов эффективности. Проект по разработке IT-стратегии всегда выполняется в тесном взаимодействии с представителями подразделений бизнеса на всех этапах его реализации. В проектную команду включаются не только ITспециалисты, но и менеджеры, управляющие соответствующими бизнес-процессами. Билл Гейтс в своей книге “Бизнес со скоростью мысли”, в главе “Кто должен быть хозяином электронных проектов” (стр.323), пишет: “... По мнению главного исполнительного директора Johnson & Johnson Ральфа Ларсена, источник наиболее “эффективных” провалов, кроется, как правило, в том, что руководители бизнеса самоустраняются от участия в крупных проектах – ведь это такая тяжёлая работа! – перекладывая всю ответственность на подразделения ИТ или на внешних подрядчиков. Подобное абсолютно недопустимо, - считает Ральф. – Опыт успешных проектов показывает, что все они осуществлялись под руководством специалистов в основной деятельности, а не по информационным технологиям. “Хозяином” проекта должен быть человек бизнеса, а задача службы ИТ – активно ему помогать. Проект не принадлежит внешним консультантам или службе ИТ. Он не принадлежит никому, кроме владельца предприятия”. Для успешной реализации IT-стратегии, необходимо также наличие дополнительных условий, которые можно назвать факторами успеха. Это: единодушие руководства предприятия в понимании значимости информационных технологий для достижения целей бизнеса; готовность руководства выделять время и силы на диалог; готовность менеджеров и сотрудников выделять время на освоение новых методов и форм организации труда; наличие в рабочей группе специалистов со значительной квалификацией по управлению проектами. Формирование стратегического плана (проекты и ресурсы) Разработать планы развития: бизнес-приложений, инфраструктуры, процессов управления информационными технологиями, управления IT-кадрами. Описание технической архитектуры IT-системы Разработать и формализовать принципы реализации элементов IT-архитектуры на уровне общих служб, аппаратных и программных средств, технологий, методологий и стандартов. Документ «Стратегия развития Информационных технологий» (или IT-стратегия) призван четко определить соответствие между бизнес-целями компании и необходимой им технологической поддержкой, формулирует задачи развития IT и бизнес-эффекты от их решения. Топ-менеджменту Заказчика IT-стратегия позволяет объективно и адекватно оценить возможные перспективы, последовательность, длительность и объемы поэтапных инвестиций для их достижения. Методологические наработки экспертной команды RBtechnologies могут быть использованы как в проектах разработки IT-стратегии «с нуля» для Заказчиков – финансовых учреждений, так и при аудите существующих документов. Интернет-источники: 1. Полякова М. ИТ в госсекторе: проекты тормозят. Настольный журнал ИТ-руководителя. N10, 2012. http://www.osp.ru/cio/#/home 2. Сайт сообщества .net-разработчиков. ИТ-мендежмент – что это такое. http://www.gotdotnet.ru/blogs/danielkornev/1771/ 3. Слайды «Разработка и реализация коропоративной ИТстратегии». http://www.slideshare.net/koltunova/ss2661845#btnNext 4. Сайт Михайлова А. MBA по стратегическому управлению, ген. директор компании «Консалтинг по управлению ИТ в крупнейших российских компаниях». http://www.infostrategy.ru/education/it-strategy/ 5. Сайт компании «RBtechnologies». Разработка и аудит стратегии ИТ. http://www.rbtechnologies.ru/index.php?id=16 6. Портал «Технологии корпоративного управления». http://www.iteam.ru/publications/it/section_91/article_1921/ 7. Студеникин В. Стратегия развития корпоративной информационной системы. http://www.studenikin.ru/ITStrategy.asp 8. Румянцев М. ИТ-стратегия: что в имени тебе моем. http://www.iteam.ru/publications/it/section_91/article_1921/ 9. Руководитель информационной службы в России и CIO в США. Сайт УрФУ. http://capri.ustu.ru/publications/cio.htm 10. Еловский М. Директор по информационным технологиям: мода или потребность современного бизнеса? http://www.iteam.ru/publications/it/section_53/article_2176/ ОПРЕДЕЛЕНИЕ ИТ-СТРАТЕГИИ И ИТ-АРХИТЕКТУРЫ Стратегия развития информационных систем основывается на общей стратегии развития компании (учреждения) и конкретизирует положения общей стратегии с точки зрения ИТ. Общая стратегия развития компании определяет настоящие и будущие виды деятельности, типы выпускаемой продукции и объёмы выпуска, рынки на которых работает компания и её доли на этих рынках, организационную и территориальную структуру компании. В свою очередь, ИТ-стратегия содержит основные положения использования ИТ в бизнес компания, она определяет как будет поддержана заданная стратегия развития компании средствами ИТ. При разработке ИТ-стратегии должно учитываться существующее состояние ИТ в компании, отраслевые стандарты и тенденции развития информационных технологий. Для того чтобы ИТ-стратегия соответствовала бизнес-стратегии, в ней должны быть определены: Философия развития ИТ в компаниии место ИТ-подразделений в структуре предприятия. Требования к ИТ с позиций бизнес-стратегии. Базовые принципы и направления развития ИТ. Основные направления совершенствования процессов управления ИТ. Интегральные характеристики ИТ-бюджета и списка проектов, необходимых для реализации ИТ-стратегии. Оценки качества и целевые показатели работы ИТ-системы. Возможные риски и альтернативные варианты развития ИТ. Базовые принципы и направления развития ИТ должны быть детализированы до продуктов, например: Внедрение комплексного продукта (например, системы класса ERP II) и автоматизация на его основе всех бизнес-процессов. Внедрение нескольких специализированных продуктов, каждый из которых решает отдельный класс задач, и создание единой системы посредством интеграции этих продуктов. Проведение заказной разработки одной из подсистем и интеграция её с другими продуктами в единую систему. Разработка на заказ всей информационной системы в комплексе. Автоматизация отдельных участков (или бизнес-процессов) посредством внедрения отдельных модулей, входящих в один или в разные продукты. Перечисленные примеры позволяют сделать вывод, что стратегия включает в себя ответы на ключевые вопросы о процессе внедрения и использования информационных технологий: Комплексность автоматизации. Если не предполагается комплексная автоматизация, то определение направлений деятельности, бизнес-процессов или подразделений, которые будут автоматизироваться. Порядок автоматизации, сроки отдельных этапов. Выбор используемых продуктов, систем, платформ. Применение заказных разработок. Используемые методики интеграции. Способы реализации проектов (использование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.). Способы поддержки основных ИТ-сервисов (традиционный, SLA). Также как ИТ-стратегия конкретизирует общую стратегию предприятия с точки зрения ИТ, так и ИТ-архитектура рассматривает ИТ-аспекты общей архитектуры предприятия. Определение архитектуры предприятия дано в стандарте ANSI/IEEE Std 1471-2000: «фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие». Архитектура предприятия – это концептуальное средство, которое помогает организации понять свою структуру и способы работы. Обычно архитектура предприятия имеет форму большого набора взаимосвязанных моделей, описывающих структуру и функции предприятия. Весь набор моделей архитектуры предприятия можно условно разделить на четыре категории: Бизнес-ракурс. Бизнес-ракурс описывает бизнес предприятия. Сюда включаются бизнес-стратегии и планы по переводу предприятия из текущего состояния в планируемое состояние в будущем. В типовом случае этот ракурс включает: Цели и задачи верхнего уровня. Бизнес-процессы, охватывающие всё предприятие значительную его часть. Выполняемые бизнес-функции. Основные организационные структуры. Взаимосвязи между всеми перечисленными элементами. или Бизнес ракурс распространяется на все аспекты деятельности предприятия. Сюда входит технология производства, используемые финансовые и логистические схемы, структура основных средств, классификация норм запасов сырья и комплектующих, структура контрактов с персоналом и многое другое, что характеризует конкретный бизнес. Ракурс приложений. Ракурс приложений определяет набор приложений предприятия. Обычно этот ракурс включает: Описание приложений или автоматизированных сервисов, поддерживающих бизнес-процессы. Описание взаимодействия и взаимозависимостей (интерфейсов) прикладных систем предприятия. Планы разработки новых и переработки существующих приложений, основывающиеся на целях и задачах предприятиях, а также на эволюции технологических платформ. В ракурсе приложений должны быть представлены службы, информация и функциональность, необходимые в масштабах всего предприятия, используемые пользователями различной квалификации, выполняющими разные функции, для достижения общих бизнес-целей. Ракурс информации. Ракурс информации описывает, какая информация необходима организации для функционирования (выполнения её бизнес процессов). Этот ракурс включает: Стандартные модели данных. Политики управления данными. Описание шаблонов создания и использования информации в организации. Ракурс информации также содержит описание того, как данные связаны с потоками работ, включая структурированные хранилища данных, такие как базы данных, и неструктурированные хранилища данных, такие как базы документов, таблиц и презентаций, которые используются всей организацией. Технологический ракурс. Технологический ракурс рассматривает аппаратное и программное обеспечение, используемое в организации. Этот ракурс включает (но не только): Аппаратные средства серверов и рабочих станций. Операционные системы. Средства сетевого доступа. Принтеры. Модемы. Технологический ракурс обеспечивает логическое, независимое от вендоров описание инфраструктуры и системных компонентов, которые необходимы, чтобы поддержать ракурс приложений и ракурс информации. С этого ракурса определяется набор технологических стандартов и сервисов, необходимых для выполнения бизнес-миссии. Хотя архитектура предприятия может содержать и большее число ракурсов, у каждого предприятия имеется только одна архитектура, которая описывает перспективу его развития. Значение архитектуры предприятия не определяется каким-то одним частным ракурсом, а состоит в определении взаимоотношений, взаимодействий и взаимозависимостей между различными ракурсами. ИТ-архитектура предприятия (организации), являющаяся частью общей архитектуры, включает в себя ракурс приложений и технологический ракурс. Поэтому, рассматривая соответственно ИТ-архитектуру, мы можем говорить об архитектуре приложений и технологической архитектуре предприятия (организации). Как архитектура приложений, так и технологическая архитектура состоят из концептуального представления, логического представления и физического представления. Концептуальное представление является наиболее абстрактным и тяготеет к описанию в терминах, которые более понятны пользователям системы, не являющимся ИТ-профессионалами. Концептуальное представление используется для определения функциональных требований и для построения бизнес-модели на основе представления бизнес-пользователей приложений. Для построения описания ключевых бизнес-процессов и используемых ими данных используются такие техники концептуального моделирования, как анализ юскейсов, диаграммы деятельности, моделирование бизнессущностей и т.д. Всё это направлено на то, чтобы удовлетворить бизнесцели и бизнес-требования и не зависит от технологий реализации. Логическое представление показывает основные функциональные компоненты и их взаимосвязи внутри системы без определения технических деталей реализации необходимой функциональности. Архитекторы создают модели приложений, которые являются логическим представлением бизнес-моделей, поскольку они определяют как удовлетворить бизнес-цели и бизнес-требования. Модели приложений представляют собой логические представления архитектуры приложений. Архитекторы в данном случае работают с общей структурой приложений. Они решают, как будет отображаться управление данными и шаги бизнес-процессов, они проектируют взаимодействие между компонентами модели в терминах логических сообщений и последовательностей, и они определяют, какие данные и состояния может содержать модель. Физическое представление – является наименее абстрактным и иллюстрирует специфику реализации компонентов и взаимосвязей между ними. Каждый элемент физического представления реализуется в процессе проектирования и разработки как программный или аппаратный компонент. Каждый элемент модели приложения должен быть поставлен в соответствие элементам реально существующих технологий. Этим способом модели приложений преобразовываются в модели реализации. Часть этих задач выполняется во время традиционной разработки, когда программисты прописывают детальную бизнес-логику в виде программного кода, но множество действий по реализации хорошо классифицируются как действия по применению специализированной среды. Это такая техника разработки, в которой множество элементов инфраструктуры распределённых приложений и управления данными поддерживается специализированной средой, которая расширяет пользовательскую логику приложений и декларативные структуры управления. Применение специализированной среды скрывает от разработчика множество сложностей, например, поддержку асинхронного режима приёма-передачи сообщений, а также позволяет разработчику с невысоким профессиональным уровнем реализовывать сложные проекты. После того, как мы дали определение ИТ-архитектуре, проанализируем взаимосвязь между ИТ-стратегией и ИТ-архитектурой. Эта взаимосвязь адекватна взаимосвязи между общей стратегией развития предприятия и архитектурой предприятия. Стратегия имеет более общий характер, не так детально рассматривает отдельные аспекты, как архитектура. И в отличие от архитектуры стратегия продолжительна во времени. На оси времени архитектура отражает какой-то конкретный момент, а стратегия – период. Можно сказать, что стратегия описывает последовательность преобразования архитектуры во времени. При этом каждая конкретная архитектура в этой последовательности рассматривается не детально, а только в общих чертах. Однако ИТ-стратегия не сводится к описанию последовательности преобразований ИТ-архитектуры. Описание в ИТ-стратегии процесса развития ИТ-архитектуры во времени требует, чтобы в составе стратегии было дано общее направление этого развития, разработаны общие принципы развития, определены критерии достижения заданной цели и требуемые ресурсы. СОСТАВ РАБОТ ПО РАЗРАБОТКЕ ИТ-СТРАТЕГИИ И ИТ-АРХИТЕКТУРЫ РАЗРАБОТКА ИТ-СТРАТЕГИИ Разработка ИТ-стратегии может осуществляться как в сочетании с последующей детальной разработкой ИТ-архитектуры на ближайшую перспективу, так и без этого этапа. Состав работ по разработке собственно ИТ-стратегии: Разработка философии развития ИТ в компании и определение места ИТ-подразделений в структуре предприятия. Разработка требований к ИТ с позиций бизнес-стратегии. Разработка оценок качества и целевых показателей работы ИТсистемы. Определение альтернативных вариантов развития ИТ и анализ возможных рисков. Определение базовых принципов и направлений развития ИТ. Определение основных направлений совершенствования процессов управления ИТ. Определение интегральных характеристик ИТ-бюджета Определение списка проектов, необходимых для реализации ИТстратегии, их последовательности и сроков. Определение типовых способов реализации проектов (использование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.). Определение способов поддержки основных ИТ-сервисов (традиционный, SLA). Эскизная разработка ИТ-архитектуры на ближайшую перспективу, включая архитектуру приложений и технологическую архитектуру. Эскизная разработка ИТ-архитектуры на долгосрочную перспективу, включая архитектуру приложений и технологическую архитектуру. РАЗРАБОТКА АРХИТЕКТУРЫ ПРИЛОЖЕНИЙ В настоящее время для используются два подхода: разработки архитектуры приложений Разработка архитектуры на основе интеграции приложений (концепция Enterprise Application Integration – EAI). Разработка сервисо-ориентированной архитектуры (Service Oriented Architecture – SOA). SOA - это новая парадигма проектирования распределенных интегрированных систем. Согласно SOA любые части информационных систем, имеющие функциональность, рассматриваются как службы (service providers, провайдеры служб), которые предоставляют свою функциональность другим частям системы посредством обмена сообщениями. Сервисы обеспечивают бизнес-логику и средства управления состояниями, относящиеся к проблеме, для решения которой они предназначены. В связи с тем, что поставщики корпоративных приложений ещё только ведут работы по переводу своих продуктов на SOA, а пока все большие продукты поставляются в виде монолитных корпоративных приложений, возможны различные варианты рассматриваемой услуги: Разработка архитектуры на основе концепции EAI, что в настоящее время больше применимо при построении системы на основе готовых существующих приложений. Разработка сервисо-ориентированной архитектуры (SOA), что в настоящее время больше применимо при построении системы на основе заказных разработок или при внедрении продуктов, уже построенных на основе принципов SOA. Разработка сервисо-ориентированной архитектуры (SOA) с преобразованием используемых унаследованных приложений к SOA. В этом случае процесс разработки самой архитектуры аналогичен предыдущему варианту, поэтому мы рассмотрим только этап преобразования используемых унаследованных приложений к SOA. Разработка архитектуры приложений на основе концепции EAI Очень укрупнённо, методику разработки архитектуры приложений на основе концепции EAI, в случае, когда осуществляется полное перепроектирование, можно представить следующим образом: Обследование предприятия, определение основных функциональных требований к приложениям. Выбор базового полнофункционального пакета, удовлетворяющего сформулированным требованиям. Проектирование методов интеграции выбранной на этапе 2 базовой системы с уже используемыми унаследованными системами, оценка затрат на интеграцию. Определение типов дополнительных систем, которые необходимо будет дополнительно внедрить, чтобы полностью удовлетворить потребности, выявленные на первом шаге. Выбор этих систем. Проектирование методов интеграции выбранной на этапе 2 базовой системы с дополнительными системами, определёнными на этапе 4, оценка затрат на интеграцию. Если затраты (сроки, деньги) на интеграцию сопоставимы с затратами на внедрение более тяжёлого пакета, необходимо вернуться на этап 2, повторив процесс выбора с анализом более тяжелых систем. Определение последовательности внедрения модулей выбранной комплексной системы, внедрения дополнительных систем и интеграции с уже используемыми системами. Разработка требований к технологической архитектуре на основе разработанной архитектуры приложений. В тех случаях, когда базовый пакет заранее предопределён, или даже уже частично внедрён и не подлежит замене, может проводиться неполный комплекс работ по уточнению или развитию имеющейся архитектуры приложений (этапы 3, 4, 5, 7 или некоторые из них). Разработка сервисо-ориентированной архитектуры приложений (SOA) В процессе проектирования сервисо-ориентированной архитектуры приложений в первую очередь должно быть разработано концептуальное представление. В ходе его разработки должны быть определены: Сервисы. При проектировании сервисов основная задача состоит в том, чтобы эффективно инкапсулировать логику и данные, связанные с процессами в реальном мире. Значительные интеллектуальные усилия требуются для принятия решений, что можно объединить, а что должно быть реализовано отдельными сервисами. Сообщения. Сервисы взаимодействуют между собой, обмениваясь сообщениями. Должны быть полностью определены сообщения, которые порождают и принимают сервисы, включая требования к последовательности этих сообщений. Контракты. Каждый контракт описывает метод взаимодействия двух сервисов. В это описание входит: перечень посылаемых каждым сервисом сообщений, их форматы, методы отправки, последовательность обмена сообщениями, перечень принимаемых каждым сервисом сообщений и способы приёма. Политики. Политики должны давать возможность влиять на работу приложений, т.е. устанавливать и изменять правила, действующие во время выполнения, которые определяют методы работы сервисов и их взаимодействие. Разработка политик в ходе процесса проектирования ведёт к увеличению гибкости и управляемости приложений. Состояния. Сервисы управляют состояниями и состояния, часто, являются главной причиной их существования. Состояние – это то, что хранится в некоторой долгосрочной среде, такой как файловая система или база данных. Сервисы гарантируют посредством своей бизнес-логики, содержательность, непротиворечивость и точность сохраняемых состояний. В процессе работы сервисы будут получать запросы от других сервисов, извлекать некоторые состояния из этой среды длительного хранения и строить ответы или корректировать эти состояния. Процессы. Каждый процесс управляет последовательностью действий при выполнении некоторой работы, постепенно переводя систему из одного состояния в другое. В сервисоориентированной архитектуре должны быть спроектированы бизнес-сервисы, построенные по традиционным принципам, и процессные сервисы, которые будут координировать выполнение бизнес-сервисов. Приложения. Приложения объединяют процессные сервисы, бизнес-сервисы и сервисы пользовательских интерфейсов. Бизнессервисы обычно проектируются в четыре слоя: сервисы фасада, сервисы бизнес-процессов, сервисы бизнес-сущностей и сервисы представления данных. Такая модель работоспособна как для традиционных типов приложений, которые имеют интерфейс для взаимодействия пользователей с бизнес-сервисами, так и для сервисов, взаимодействующих с другими сервисами. Помимо концептуального представления при проектировании сервисоориентированной архитектуры должны быть спроектированы логическое представление и физическое представление. Мы не будем на них подробно останавливаться поскольку они в существенно меньшей степени отличаются от соответствующих представлений при проектировании традиционной архитектуры. Преобразование унаследованных приложений к сервисоориентированной архитектуре (SOA) Процесс преобразования существующей архитектуры информационных систем в сервисо-ориентрованную архитектуру состоит из семи шагов и представлен схемой на рисунке 1. увеличить Рис. 1 Схема процесса преобразования имеющейся архитектуры информационной системы в сервисо-ориентированную архитектуру. Шаг 1а – Декомпозиция предметной области. Определение бизнеспроцессов, подпроцессов, юскейсов. Шаг 1b – Анализ существующих не объектно-ориентированных систем и преобразование их к компонентной архитектуре. Шаг 2 – Создание дерева целей сервисной модели для тестирования полноты сервисной модели. Каждой подцели в дальнейшем будет соответствовать определённый сервис. Шаг 3 – Анализ подсистем – это определение того, какие UML-юскейсы реализуются какими компонентами системы, анализ взаимодействия компонентов и влияния нефункциональных требований на архитектуру системы. Шаг 4 – Определение, какие компоненты отвечают за какие сервисы., определение сервис-провайдеров и сервис-потребителей. Шаг 5 – Определение интерфейсов каждого компонента. Шаг 6 – Структуризация компонентов и сервисов на основе применяемых шаблонов архитектуры. Шаг 7 – Определение программных и технических средств спомощью которых будет реализован каждый сервис. РАЗРАБОТКА ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРЫ Технологическая архитектура включает в себя следующие компоненты: сетевую архитектуру; архитектуру хранения; архитектуру инфраструктуры приложений; архитектуру управления; архитектуру безопасности. Работы по разработке технологической архитектуры должны начинаться с обследования имеющейся ИТ-инфраструктуры предприятия (учреждения) и определения её соответствия требованиям архитектуры приложений. Далее для каждого из перечисленных компонентов технологической архитектуры должны быть выполнены: разработка концептуального представления; разработка логического представления; разработка физического представления. Информатизация в госсекторе. Состояние и основные направления автоматизации [1]. Уровни информатизации федеральных и региональных органов управления существенно различаются, стимулируют же выравнивание ситуации инициативы сверху Длительное время информационные системы в органах власти создавались в основном для внутриведомственного использования. И, по мнению экспертов, у большинства системы разрозненны, устарели, часто не пригодны к модернизации или доработке, не имеют единой базы документов. Обмен между системами даже внутри ведомств порой организован плохо, а иногда и вовсе отсутствует. Преодоление накопившихся проблем, а также внедрение систем электронного документооборота и организация архивов — основные направления автоматизации. При этом цель не столько в оптимизации внутренней работы ведомств, сколько в удовлетворении требований, предъявляемых к системам в рамках МЭДО и СМЭВ. Отставание России от развитых государственных систем в области ИТ активно сокращается. Согласно анализу ООН («E-Government Survey 2012: E-Government for the People»), по итогам 2011 года наша страна находится по средневзвешенному показателю на 27-м месте, переместившись за два года с 59-го места (в отдельных группах в рейтинге 2010 года страна занимала с 39-го по 86-е места). Изменения к лучшему в сфере информатизации органов власти признают и большинство экспертов, замечая при этом, что, к сожалению, такой прорыв был осуществлен в основном за счет давления сверху — инициатив руководства страны по организации электронного взаимодействия и обмена, а не собственного желания ведомств оптимизировать свою работу. Среди наиболее заметных — национальный проект «Электронное правительство», практически проваленный, и система МЭДО, уже местами работающая, реализуемый проект «Информационное общество» и запущенная в эксплуатацию СМЭВ, действующий портал «Госуслуги». Эти инициативы позволили сдвинуть информатизацию органов власти в целом по стране с мертвой точки, хотя степень участия разных ведомств федерального и регионального уровня в информатизации оценивается экспертами как «средняя температура по больнице». Среди действительно успешных проектов эксперты отмечают создание Единой медицинской информационноаналитической системы Минздрава, создание электронного кадастра недвижимости Росреестра, внедрение систем видео-конференц-связи для удаленного судопроизводства Верховного суда РФ и арбитражных судов РФ. Универсальная электронная карта — единый документ, объединяющий в себе полис обязательного медицинского страхования, страховое свидетельство обязательного пенсионного страхования и другие функции, в том числе платежного средства, — тестируется в нескольких регионах, в частности, в Курской области еще к началу года была подготовлена инфраструктура для приема заявлений и выдачи универсальных карт, хотя срок начала выдачи отложен до 2013 года. ГИБДД обеспечила запись граждан на техосмотр и регистрацию через портал госуслуг, а московская ГИБДД — доступ к информации о штрафах через портал (включая SMS-уведомления и сообщения по электронной почте). Система электронного обслуживания охватила все региональные подразделения ГИБДД и была создана на имеющихся ИТресурсах без дополнительных затрат на приобретение серверного оборудования и ПО. Решение вопросов взаимодействия ведомств между собой и с гражданами, по мнению экспертов, является основным стимулом развития ИТ в органах власти как регионального, так и федерального уровня. Эти задачи по-прежнему остаются важными, хотя система МЭДО должна уже давно функционировать, а обеспечить работу системы межведомственного электронного взаимодействия (СМЭВ), чтобы предоставлять гражданам услуги в режиме «одной точки входа», нужно было к 1 июля 2012 года. Несмотря на все усилия, полноценный запуск СМЭВ пока не состоялся. Согласно официальным данным, к СМЭВ подключились все субъекты, и средняя готовность региональных ведомств к такому переходу, по данным Минкомсвязи, составляет около 60%, так как не во всех регионах готовы сервисы для электронного взаимодействия. Однако эксперты полагают, что эта степень готовности относится, скорее, к федеральным органам власти, а готовность регионов подключиться к возможностям центра варьируется от 0 до 68%. Согласно статистике обращения субъектов РФ к электронным сервисам федеральных органов исполнительной власти с 1 июля по 30 сентября 2012 года, общее количество обращений составило 9 513 989, причем 99,99% обращений приходится на 48 регионов из 83, а на пятерку регионов-лидеров (Челябинская область, Москва, ЯмалоНенецкий АО, Еврейская АО, республика Мордовия) — около 70% общего числа обращений. И если Москва генерирует более 1,5 млн обращений, то из Московской области поступило чуть более одной тысячи. Эта информация не отражает в полной мере ситуацию, так как реальную картину можно будет увидеть, посчитав не число обращений, а число оказанных услуг. По данным на 30 сентября об электронных сервисах федеральных органов исполнительной власти, по которым организуется межведомственное взаимодействие с региональными органами власти, 31 ведомство разработало 71 веб-сервис, необходимый для предоставления государственных и муниципальных услуг, но и из них готово к эксплуатации только 48 сервисов. Причина низкого использования возможностей, по мнению экспертов, не только в неготовности органов управления, низком уровне финансирования, проблемах взаимодействия с Ростелекомом, но и в том, что лишь небольшая часть населения страны готова к переходу на электронные способы взаимодействия с государством. Переход на СМЭВ влечет реинжиниринг услуг, их администрирование, создание многофункциональных центров, количество которых непрерывно растет. Например, несколько МФЦ заработало в Хабаровском крае. Регионы все больше услуг переводят в электронный вид. В Башкортостане до конца 2012 года 24 государственные и муниципальные услуги должны стать доступны для граждан, перевод десяти госуслуг в электронный вид уже завершен. В Архангельской и Ростовской областях реализованы проекты по созданию регионального сегмента электронного правительства на промышленной платформе Oracle, объединяющие три подсистемы: региональный портал государственных и муниципальных услуг, региональную СМЭВ и систему исполнения регламентов. Основная деятельность Еще один тормоз на пути развития — ведомственные системы. Сегодня госструктуры используют достаточно широкий спектр ИТ для решения внутриведомственных задач. При этом каждое ведомство развивало информационные системы в меру своего представления о том, как они должны функционировать (если таковое вообще было). Поэтому многие ИТ-комплексы построены на различных платформах (под каждую задачу используется своя), решают узкий круг задач, не интегрированы — и, как следствие, чтобы удовлетворить требования государства, нужны немалые усилия. Такая ситуация наблюдается и на федеральном, и на региональном уровнях. Но есть и исключения: федеральные органы власти, регионы и муниципалитеты, которые строят единые ведомственные системы, реализуют стратегию развития информатизации. Основная деятельность сотрудников государственных органов исполнительной власти связана с обработкой разного рода документов, поэтому первый шаг на пути автоматизации процессов — это обычно организация электронного документооборота. Поскольку федеральные ведомства давно реализовали такие проекты, внедрение ЭДО сегодня по большей части приходится на региональный и муниципальный уровни. Внедрив ЕСМ-систему Directum, в правительстве Ярославской области добились того, что более 90% исходящих документов готовятся и согласовываются в электронном виде с использованием квалифицированной электронной подписи, до 50% всей входящей корреспонденции поступает в электронном виде. Этой же системой для комплексного решения задач воспользовались в администрации Костромы. Межрегиональное управление Федеральной службы по оборонному заказу по Северо-Западному федеральному округу автоматизировало документооборот с помощью «Е1 Евфрат». Систему «Евфрат» для более эффективной и быстрой работы с документами и организации архива выбрала и Донская государственная инспекция пробирного надзора. Чтобы сократить трудозатраты на ведение кадрового документооборота, администрация Воронежа внедрила систему «БОСС-Кадровик» на платформе Microsoft SQL Server, облегчив учет служебной и организационно-распорядительной документации и подготовку регламентированной отчетности для ПФР и Росстата. Наличие единой базы — единого информационного поля — существенно упрощает решение проблем взаимодействия, поэтому органы власти активно двигаются в этом направлении. Развивая СЭД на базе Directum, правительство Тюменской области объединило в одну базу 29 отдельных серверов, и теперь вся работа с электронными документами осуществляется в единой системе по единым правилам — департаменты области перевели с локального документооборота на работу по единым процессам и объединили данные в единую базу. Чтобы сохранить и затем вести единую базу архивных и текущих документов, в Управлении ГИБДД УМВД по ХМАО — Югре завершился проект создания СЭД на платформе Optima-WorkFlow на базе Linux с миграцией данных из старой СЭД в новую. Оптимизировав непосредственную работу сотрудников, ведомства обычно переходят к автоматизации задач, связанных с работой ведомства в целом, внедрению ERP-систем или их аналогов, модулей этих систем. Правда, средства на такие проекты обычно изыскивают только федеральные органы власти. Минпромторг РФ оптимизировал работу с помощью решения SAP Business ONE, объединив технические службы административного департамента в единое информационное пространство, предоставив возможности контроля и коррекции ключевых бизнес-процессов, создав инструменты анализа и планирования взаимодействия с сотрудниками и поставщиками. Минэнерго РФ построило единую ведомственную информационную систему, интегрированную с продуктом компании «1С». В Росреестре, объединившем в 2009 году Росрегистрацию, Роснедвижимость и Роскартографию, создана информационная система управления основными средствами на базе продукта «Парус», обеспечивающая решение задач финансово-экономического и контрольно-ревизионного управлений, управления комплексного развития, отдела материальнотехнического обеспечения, управления мониторинга деятельности и управления делами. В главном управлении МВД России по Московской области создается комплексная информационная система на базе «Парус — Бюджет 8», охватывающая процессы бюджетного учета, расчета заработной платы и денежного довольствия, санкционирования расходов, учета заявок от подразделений и формирование на их основе плана закупок, учета и контроля исполнения договоров и государственных контрактов, складского учета вооружения, вещевого имущества и хозяйственного инвентаря, а также планирования в режиме реального времени. Перспективы Эксперты признают, что СЭД, средства виртуализации, централизованные ЦОД и многие другие технологии уже используются государственными структурами. Но объемы использования электронных документов все нарастают, поэтому потребуется решить проблему долговременного хранения юридически значимых документов, создать государственные и муниципальные электронные архивы. Среди перспективных направлений развития систем — поддержка работы мобильных сотрудников и создание портальных ИТ-решений, которые позволяют руководителям органов власти и самоуправления работать на расстоянии. В частности, над мобильным клиентом сегодня работает Минэнерго РФ. Некоторые полагают, что все чаще будут востребованы облачные технологии, связанные с использованием централизованных инфраструктурных ресурсов, сокращением затрат на ПО, и аутсорсинг. Например, для поддержания необходимого уровня защиты Роскомнадзор аккредитовал компанию «АйТи» на проведение плановых и внеплановых проверок по защите персональных данных негосударственных информационных систем, используемых оператором при осуществлении своей непосредственной деятельности. Главным же сдерживающим фактором эксперты считают персонал — отсутствие у многих госструктур достаточного количества ИТ-кадров, его низкую квалификацию и слабую мотивацию. Госсектор и облака: дело в доверии Государственный сектор существенно отстает от коммерческого в плане использования облачных технологий. Во многом это связано с более жесткими требованиями, предъявляемыми при реализации проектов. В результате облака зачастую даже не рассматривались в качестве одного из вариантов организации инфраструктуры. По данным KPMG, лишь 12% ИТ-руководителей государственных учреждений говорят о том, что хотя бы десятая часть их ИТ-расходов в 2011 году была направлена на построение облачных структур. В частном секторе такие организации встречаются в два раза чаще. Тем не менее ситуация может разительно измениться уже в ближайшее время. Как ожидают аналитики, к концу 2012 года доля государственных организаций с существенной частью инвестиций в облака вырастет до 28%. Правительственные организации все четче понимают, что внедрение облачных систем помогает радикально снизить стоимость оказываемых гражданам государственных услуг. В эпоху вынужденного аскетизма госструктур облака могут быстро стать ключевым элементом при построении ИТ-систем. Как показывают результаты опроса, 73% руководителей предприятий госсектора готовы к переходу в облака, если этот шаг будет гарантировать значительное сокращение издержек. Размещая государственные услуги на облачной платформе, организации обнаруживают, что не просто экономят. Не менее важно, что они обеспечивают гражданам более удобный доступ к интересующей их информации, а значит — лучшую прозрачность. Тем не менее безопасность при этом критически важна, особенно когда речь идет о персональных данных. Как отметили 47% респондентов, безопасность становится наиболее сложной проблемой при миграции услуг и процессов на облачные платформы. И чем крупнее ведомство, тем выше его опасения. Однако важно отметить, что 80% опрошенных признают важность сертификации решений. Они готовы доверять системам, сертифицированным уполномоченными органами. Государственные организации часто являются хранителями ценной информации и потому регулярно становятся объектами хакерских атак. ИТ-руководители таких учреждений должны быть уверены в надежности провайдера, прежде чем доверять ему свои данные и системы. При сложившейся ситуации почти треть предприятий госсектора предпочли бы инфраструктуру частного облака. В потенциал публичных облаков пока верят лишь 22%.
