Gap-анализ (анализ несоответствий) и модель развития элементов ИТ-архитектурыСущественным элементом рассмотренного нами ранее процесса создания архитектуры предприятия является идентификация и анализ несоответствия между существующим и желаемым состоянием архитектуры предприятия и отдельных его доменов – так называемый gap-анализ. Этот анализ является критически важным с точки зрения определения ключевых шагов и необходимых изменений в направлении целевой архитектуры. На этом этапе необходимо категоризировать идентифицированные несоответствия и собрать вместе бизнес-требования, технологические потребности, требования к информации и приложениям – для того, чтобы начать решение соответствующих проблем. При этом несоответствия могут быть связаны с вопросами культуры организации, структурными проблемами, функциональными или же процедурными вопросами. Процесс анализа на несоответствия включает следующие шаги: · идентификация различий между существующей и целевой архитектурой; · составление списка идентифицированных несоответствий с разбивкой по категориям и составление списка требуемых изменений; · идентификация уже имеющихся возможностей ИТ-систем, которые могут быть использованы для удовлетворения идентифицированных проблемных мест, и обновление списка несоответствий с учетом этого фактора; · группировка идентифицированных несоответствий по типу их влияния на деятельность предприятия (уровень предприятия в целом, уровень нескольких подразделений и функций, уровень отдельного подразделения и функции, особые случаи). Для категоризации несоответствий можно, в частности, использовать матрицу, показанную в табл. 11.1.
При этом под структурными несоответствиями понимаются несоответствия между существующим и целевым состоянием, связанные с вопросами инфраструктуры. Основное внимание здесь связано с архитектурными принципами и архитектурой отдельных доменов. Функциональные несоответствия связаны с возможностями систем по поддержке новых бизнес-процессов, которые необходимы для реализации новых бизнес-стратегий. Основное внимание должно быть уделено реализации необходимых приложений и систем, требующихся для обеспечения улучшенных или новых бизнес-процессов. Культурные несоответствия – это несоответствия между сегодняшним состоянием ИТ-департамента организации (набор навыков, компетенция и структура) и требующимися навыками, компетенциями и структурами, которые необходимы для решения проблем в первых двух областях. Процедурные несоответствия – это несоответствия между существующими и желаемыми методами управления, стратегиями сорсинга, процессами эксплуатации ИТ-сервисов и организационными процедурами. Таким образом, условно можно сказать, что существует два типа несоответствий: · " жесткие" несоответствия, которые связаны, например, с необходимостью замены ряда технологий или внедрения новых; · " мягкие" несоответствия, например, несоответствие архитектурным принципам или несоответствия между имеющейся и требуемой квалификацией персонала. После того как найденные несоответствия идентифицированы, должны быть расставлены приоритеты, а затем предложены возможные решения и проекты, которые бы " закрывали" найденные проблемные места. То есть, в конечном итоге, несоответствия " становятся" проектами, реализуемыми ИТ-департаментом и группой управления проектами. Когда организация впервые выполняет анализ на несоответствия, то не исключено, что количество найденных несоответствий окажется невелико. Это может быть, в частности, связано с тем, что будущее состояние архитектуры еще не определено с достаточной степенью детализации. Возможна и обратная ситуация, когда этот список будет слишком велик. Это признак того, что команда, ответственная за разработку архитектуры, слишком много времени потратила на начальном этапе на анализ будущего состояния (на начальном этапе следовало бы понять существующее положение дел и только в общих чертах – направления развития), либо же это означает, что в организации действительно слишком много проблем. Со временем, по мере более детальной проработки будущей архитектуры, анализ на несоответствия может выявлять сотни и более проблемных областей. Как обычно, при выборе проектов, решающих эти проблемы, действует правило 80/20, когда 20% возможных проектов решат 80% проблем. При этом необходимо учитывать, что требуются проекты в разных областях (структурные, функциональные, связанные с культурой и процедурами) и что на этапе анализа могут быть выявлены взаимозависимости, когда одни проекты, например, нельзя начинать, не реализовав предварительно другие (например, нельзя внедрять новое приложение, не обновив версию операционной системы на персональных компьютерах пользователей). Необходимым элементом в проекте развития ИТ-архитектуры является оценка существующего состояния и перспективности использования имеющихся компонент. Рассмотрение элементов ИТ-архитектуры ведется обычно в двух аспектах: а) планирование и управление ИТ-системами, и б) стандарты и общие службы (компоненты). Аспект планирования и управления включает: · направление развития ИТ – определяет среднесрочные и перспективные роли ИТ в компании с учетом требований бизнеса и выделенных приоритетов; · принципы реализации – определяют " правила" рассмотрения, внедрения и последующего управления технологиями; · динамичность – планирование внедрения технологий должно проводиться с учетом их постоянного совершенствования и появления новых технологий, а также с учетом возможного изменения требований бизнеса. Аспект стандартизации включает: · Общие ИТ-службы. Сюда относятся кросс-функциональные и служебные приложения, такие как электронная почта. · Вычислительная инфраструктура. Корпоративные стандарты на технологии и средства инфраструктуры должны базироваться на применении общепризнанных ИТ-стандартов. · Элементы архитектуры системы. Эти элементы определяются как для среднесрочных, так и для перспективных стандартов. Каждый такой элемент оценивается с учетом ситуации в отрасли, степени использования в организации, целесообразности исключения из системы в течение перспективного срока (старение) или временного сохранения, целесообразности развития, целесообразности проведения переоценки его роли в будущем для обеспечения динамичности. При определении стратегии обычно выделяются среднесрочный (9-18 месяцев) и перспективный (18-36 месяцев) периоды, хотя на основании результатов аудита могут быть сформулированы и срочные задачи, требующие решения в течение недель и месяцев. Вид такой типовой модели для каждой отдельной компоненты ИТ-системы (такой как, например, системное ПО, серверы, средства хранения данных, приложения для компании в целом или для отдельного направления бизнеса и т. п.) приведен в табл. 11.2.
Оценка перспективности развития проводится с учетом: · стратегии развития, перспективности расширения бизнеса, изменения отношений с клиентами и поставщиками; · общемировых тенденций развития информационных технологий; · выбранного направления развития ИТ-технологий в организации и стратегии реализации (срочные, среднесрочные и перспективные этапы). Такая модель в области системного программного обеспечения для некоторой гипотетической компании может иметь вид, показанный в табл. 11.3.
В данном случае, на основании анализа существующей системы могло быть выявлено, например, следующее: · большое количество эксплуатируемых приложений, использующих форматы DBF, FoxPro и MS SQL Server версии 7; · корпоративная электронная почта отсутствует, например, пользователи используют почтовые ящики на общедоступных публичных серверах; · большое количество версий эксплуатируемых операционных систем, в том числе устаревших и т.п. В рамках проекта развития информационных систем организация может принять ряд решений, в том числе: · переход в ближайшее время на Windows XP; · внедрение корпоративной электронной почты MS Exchange/Outlook; · в качестве целевой платформы СУБД и серверов приложений выбран Oracle – то есть новые приложения будут использовать СУБД Oracle, а в перспективе будут реализованы с поддержкой J2EE и выполняться на Oracle AS. В то же время существующие приложения, использующие MS SQL Server, будут сохранены; · в течение ограниченного времени будет поддерживаться и формат DBF для обеспечения интеграции с унаследованными приложениями; · организация будет периодически возвращаться к переоценке целесообразности использования среды.Net и J2EE – возможно, что выбор.Net приведет к необходимости изменения архитектуры, предполагающей ориентацию на Oracle и J2EE; · организация может отметить для себя ряд последствий, в частности, необходимость переоснащения современными рабочими станциями и развития телекоммуникационных средств. Эти связи отражаются в модели развития технического обеспечения информационных систем.
|
