Архитектура управления ИС предприятия

1. Перечень проектных документов для комплекса автоматизированных подсистем ИТ управления кампуса

Слово Campus имеет латинское происхождение (обозначало «поле», «открытое пространство»). Впервые кампусом назвали территорию Принстонского университета в XVIII веке. Университетские кампусы, как правило, имеют автономную администрацию, иногда выборную.

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

Проектные документы делятся на три группы:

-я группа - документы непосредственно по управлению проектом (Устав проекта, паспорт проекта, календарный план проекта, ресурсный план проекта, отчет о статусе проекта и т. д.).

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

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

Перечень основных документов при создании и завершении проекта

1. Техническое задание. В нем фиксируется назначение и цели создания системы, характеристика объекта внедрения, требования к системе, перечень разрабатываемых на ИС документов и т. д. Значение этого документа в проекте сложно переоценить.

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

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

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

наименование работы;

дату начала и окончания работы;

наименование подразделения - участника работы;

фамилию и должность ответственного исполнителя;

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

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

. Акт приемки в опытную эксплуатацию.

. Приказ о начале опытной эксплуатации (ее частей).

Документ содержит:

наименование АС в целом (или ее частей), проходящей опытную эксплуатацию;

наименование организации-разработчика, организаций-соисполнителей;

сроки проведения опытной эксплуатации;

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

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

. Приказ о составе приемочной комиссии. Документ содержит:

наименование принимаемой АС в целом или ее частей;

сведения о составе комиссии;

Виды испытаний автоматизированных систем.

основание для организации комиссии;

наименование организации-заказчика;

наименование организации-разработчика, организаций-соисполнителей;

назначение и цели работы комиссии;

сроки начала и завершения работы комиссии;

указание о форме завершения работы комиссии.

. Протокол испытаний. Документ содержит:

наименование объекта испытаний;

список должностных лиц, проводивших испытания;

цель испытаний;

сведения о продолжительности испытаний;

перечень пунктов технического задания на создание АС, на соответствие которым проведены испытания;

перечень пунктов «Программы испытаний», по которым проведены испытания;

сведения о результатах наблюдений за правильностью функционирования АС;

сведения об отказах, сбоях и аварийных ситуациях, возникающих при испытаниях;

сведения о корректировках параметров объекта испытания и технической документации.

. Приказ о вводе в промышленную эксплуатацию.

Документ содержит:

состав функций АС или ее частей, технических и программных средств, принимаемых в промышленную эксплуатацию;

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

порядок и сроки введения новых форм документов (при необходимости);

порядок и сроки перевода персонала на работу в условиях функционирования АС.

. Руководство по эксплуатации ИС.

. Руководство пользователей ИС (в соответствии с функциональными ролями).

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

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

. Протоколы коллегиальных органов, контролирующих реализацию проекта.

. Акты сдачи-приемки работы (в соответствии с договором внедрения СЭД).

. Счета, счета-фактуры (в соответствии с договором внедрения СЭД).

. Приказ о завершении проекта. Приказом фиксируется окончание проекта.

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

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

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

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

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

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

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

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

Таким образом, сертификация по TL 9000 более понятна пользователям, чем договоры SLA. Соответственно, она вполне подходит для тех провайдеров, которые предоставляют массовые услуги, а вот для «канальных» операторов национального и мирового уровня, скорее всего, самым подходящим инструментом являются договоры SLA.

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

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

Уровни архитектуры предприятия:

Архитектура организации и бизнес-процессов фирмы;

Архитектура ИТ-сервисов;

Архитектура приложений;

Архитектура ИТ-инфраструктуры;

Архитектура среды ИТ.

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

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

Основные понятия технических архитектур

Сервисы - все внутренние и внешние сервисы

Приложения - всё прикладное ПО, непосредственно решающее задачи бизнеса, включая покупное, заказное и собственные разработки

Инфраструктура - мейнфреймы, серверы, сетевое оборудование, СУБД, SAN (Storage Area Network), NAS (Network Attached Storage), системное ПО, утилиты, резервное копирование, межсетевые экраны, среды разработки и тестирования, ПО управления ИТ и т.д.

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

Данные - все данные и информация, где бы они ни были, включая тестовые данные.

Рассмотрим признаки и особенности архитектурной проблемы.

Признаки:

Результаты функционирования системы существенно определяются согласованностью её частей

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

С каждой частью связаны значимые издержки переключения

Рис. 1. Взаимоотношения ИТ-архитектур

Особенности:

Сложность - речь идет о множестве объектов с многочисленными и разнообразными связями между ними

Динамика - каждый объект развивается, причем, периоды жизненного цикла объектов не совпадают

Неопределенность - неполная информация о перспективных требованиях к объектам и технологиях, которые смогут эти требования удовлетворить.

Факторы изменений:

Изменения среды бизнеса, например, в результате глобализации, повышения цен на энергоносители, внимания к экологии и корпоративной этики, в частности, закона Сарбанеса - Оксли (SOX);

Изменения требований клиентов (например, требования к обслуживанию 24*7, например, при электронных трансакциях; требования к мобильному обслуживанию; Требования к персонализации продуктов и услуг);

Изменения модели бизнеса (например, интернет-торговля и банкинг; создание глобальных цепей поставок; появление новых технологий, например, Flash-накопителей, Wi-Fi и Wi-Max-сетей, DECT-телефонии).

Рис. 2. Архитектурные компромиссы

Игнорирование этих факторов ведет к «феодализации» ИТ.

Факторы, препятствующие изменениям:

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

Издержки совместной работы: более сложное и дорогое сопровождение (например, более сложное и дорогое взаимодействие с поставщиками);

Затраты, связанные с разрешением инцидентов, связанных с совместимостью;

Ценовая политика вендоров;

Ограниченность сервисных активов - несоответствие наличных сервисных активов новым требованиям бизнеса;

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

Игнорирование этих факторов ведет к дорогим и/или ненадежным ИТ-сервисам.

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

Рис. 3.

Экономические характеристики ИТ-платформы представим в табл. 1.

Таблица 1 Экономические характеристики ИТ-платформы