Intelligent Enterprise №20 (176), 17 декабря 2007 года
Марина Аншина, начальник управления ИТ ОАО «СИБУР — Русские шины», председатель правления Фонда ФОСТАС
Марина Аншина, начальник управления ИТ ОАО «СИБУР — Русские шины», председатель правления Фонда ФОСТАС
Совершенно очевидно, что не всякое типовое решение подходит тому или иному предприятию. На то есть как объективные причины, так и субъективные, связанные с естественным отторжением коллективом всяческих нововведений. При выборе типовых решений редко уделяется внимание тому, насколько они встраиваемы в архитектуру компании. И прежде всего дело здесь в том, что само понятие архитектуры не слишком известно руководителям бизнеса. Тем не менее одно из важнейших условий успешного внедрения типового решения — его соответствие существующей архитектуре предприятия.
1. Готовые прикладные системы:
1. Есть возможность выбора на основе оценки результатов внедрения на других предприятиях. Мы можем использовать чужой опыт, например посмотреть, каков результат, каковы риски и т. д. Конечно, всё это с определенной долей вероятности, но тем не менее в этом очень привлекательная сторона типового решения для бизнес-руководства. Возможность перенять уникальный опыт лидеров — очень сильный стимул, хотя тут не все так просто и очевидно.
2. Возможность привлечь к внедрению внешних консультантов, получать квалифицированную поддержку на протяжении всего жизненного цикла решения. Вообще информационные технологии внедряются трудно. Легко разработать — внедрять тяжело. И уникальный опыт внедрения — это тоже очень привлекательная составляющая типового решения. Тем более, что собственных внедренцев даже в крупных компаниях маловато. И поставщики типовых решений поняли это очень давно: сейчас любая серьезная ERP-система обязательно имеет в своем составе развернутую методологию внедрения.
3. Процессы выбора внедрения и сопровождения управляемы, прежде всего с точки зрения бюджетирования и оценки рисков. В случае собственной разработки нам очень трудно предсказать, сколько времени это займет, какой бюджет мы потратим, каковы окажутся риски и как это потом будет сопровождаться. При собственной разработке ответы на эти вопросы, как правило, не известны. А вот в случае типового решения есть возможность оценить все эти моменты.
4. Наличие методологий, в частности по выбору инфраструктуры, оценке необходимых мощностей, управлению проектом внедрения. Типовое решение внедряется на многих предприятиях, поэтому все эти параметры уже определены и опробованы. Поставщики понимают, что это одно из значительных преимуществ.
Однако все эти достоинства существуют скорее в виде возможностей, чем в форме твердых гарантий. Неправильный подход предприятия и прежде всего руководства к выбору, внедрению и сопровождению типового решения приводит к тому, что все эти преимущества превращаются в серьезные недостатки.
Обычно неверный подход связан с тем, что прилагательное «типовое» воспринимается на предприятии как синоним простоты и руководство уверено в том, что типовые решения внедряются сами по себе, без каких-либо усилий с их стороны, разве что с участием ИТ-подразделений. Результатом такого заблуждения является выбор продуктов, абсолютно не подходящих конкретному предприятию; управление его внедрением превращается исключительно в отслеживание сроков и бюджета; использование методологий сводится к излишней бюрократии, а все упреки за неудачу проекта (которая весьма вероятна при таком подходе) сваливаются на внешних консультантов.
Руководству предприятия, которое собирается внедрять типовое решение, следует настроиться на серьезную общекорпоративную работу, оно должно осознанно и коллегиально провести работу по выбору решения и активно руководить проектом. И одно из важнейших условий успешного внедрения при этом — соответствие продукта существующей архитектуре предприятия.
По степени связности архитектурных компонент можно выделить следующие типы архитектур.
1. Монолитная. Это архитектура, в которой выделяется отдельный сильный компонент, чаще всего ERP-система. А на этот основной компонент «наращиваются» остальные — путём тесной интеграции с ним (например, написанием дополнительных программ). Такую архитектуру иногда называют интегрированной, она весьма распространена на предприятиях.
2. Слабосвязанная. Эту архитектуру формируют отдельные архитектурные компоненты, не зависящие друг от друга. Взаимосвязи между компонентами не устанавливаются или проводятся с помощью «мостов», позволяющих, например, обмениваться файлами или сообщениями. Иногда такую архитектуру называют федеративной или дискретной, а в обыденной речи — «винегретом». С моей точки зрения это наиболее популярная архитектура на российских предприятиях.
3. Сбалансированная. Обычно состоит из лучших в своем классе решений (best of breed), которые связаны между собой в одном или нескольких архитектурных слоях, чаще всего с помощью интеграционной платформы. Это архитектура, основанная на сервисных технологиях, и именно к ней, я надеюсь, мы сейчас идем, а некоторые компании уже ведут инновационные проекты в этой области.
Надо сказать, что в реальной жизни такие архитектуры и их промежуточные состояния часто возникают вне зависимости от того, каков характер основной деятельности в компании, стиль управления и корпоративная культура. Все может определяться другими факторами (например, историей развития ИТ на предприятии, имеющимся бюджетом, личными пристрастиями руководства в области автоматизации и др.).
Прежде всего выделим три показателя, которые будем анализировать. Их описание приведено в табл. 1. Кроме того, типовые решения также можно классифицировать по трём типам архитектур: постепенно уходящие с рынка клиент-серверные, распределенные (сервер приложения или базы данных, тонкий клиент) и сервисные. И в табл. 2 приведены варианты внедрения различных типовых решений в разные архитектуры предприятия.
Надо сказать, что приведённые значения параметров являются моими экспертными оценками. Причем в конкретной ситуации они могут зависеть от многих факторов, в частности от технологической основы типового решения, особенностей архитектуры предприятия и т. д. Например, слабосвязанная архитектура позволяет использовать типовое решение практически сразу. То есть типовое решение можно внедрять независимо от других проектов. Возможно, в ходе внедрения или в дальнейшем придётся написать несколько мостов для организации «слабой» связи. Однако хотя подобный подход сейчас наиболее распространен в российских компаниях, такое «независимое» внедрение не позволит получить максимальную отдачу от типового решения.
Монолитная архитектура, если она основана на типовом решении, весьма эгоистична. Она обычно не предполагает использование другого типового решения. И если (как нередко бывает на практике) такое другое решение все же внедряют, то архитектура может превратиться в слабосвязанную. В любом случае типовое решение для такой архитектуры является дестабилизирующим фактором.
Сбалансированная архитектура обычно представляет собой набор компонентов, среди которых важную часть занимают типовые решения, связанные друг с другом с помощью современной интеграционной платформы. Желательно, чтобы выбор типового решения определялся тем, какую платформу оно поддерживает. В этом случае надо быть особенно осторожным как с выбором самого решения, так и с проектом его внедрения. Однако при грамотном подходе внедрение типового решения в такую архитектуру в целом ведет к ее укреплению и развитию, и внедренная система в этом случае используется максимально эффективно.
Может показаться, что этот вид архитектуры наиболее естественно подходит для использования сервисно-ориентированного типового решения. Однако положительный эффект работающей ИС в этом случае может быть получен далеко не так быстро, как в случае слабосвязанных систем. Кроме того, не всегда совпадают версии интеграционной платформы предприятия и той, что предусмотрена в типовом решении. И если интеграционная платформа и прикладное решение делались разными разработчиками, то они часто развиваются не синхронно.
Все это показывает, насколько сложен выбор, и табл. 2 может оказать определенную помощь ИТ-руководителю предприятия в этом вопросе.
Уровень зрелости архитектуры предприятия определяется по совокупности следующих признаков:
Говоря об эффектах, я не имею в виду экономический эффект. Мое твердое убеждение состоит в том, что экономический эффект от внедрения типовых решений посчитать трудно, а иногда и просто невозможно. Но в любом случае выгоды от проекта есть, и они очевидны.
Ситуация, когда какие-то архитектурные компоненты развиваются и дополняются с помощью типового решения, представляет собой наиболее обоснованный вариант его использования. Но при этом возможны и противоречия, и тогда придётся либо что-то менять в существующей архитектуре, либо выбирать другое типовое решение. Наконец, если типовое решение плавно включается в архитектурную модель, качество которой не меняется, значит, велика вероятность того, что оно приживется. А внедрять незрелое типовое решение в зрелую архитектуру вообще не стоит. На мой взгляд, срок жизни незрелого типового решения в зрелой архитектуре относительно невелик.
Как видно из табл. 3, типовое решение может стать двигателем развития архитектуры в том случае, если уровень его технологической и методологической зрелости выше, чем уровень зрелости корпоративной архитектуры. «Дом» не перестраивается, а рядом с ним строится новый, куда потом переезжают «жители». Именно таким образом слабосвязанные архитектуры переходят к монолитным. Но хотя многие опытные консультанты и ИТ-менеджеры знают, что развитие архитектуры является мощным стимулом для внедрения типового решения, об этом редко задумываются и редко используют такой довод в качестве аргумента при выборе варианта решения задач автоматизации. А по-моему, это очень правильный подход.
Вообще вопросы перехода между архитектурами сложны и недостаточно изучены. В последнее время все большую популярность приобретает технология преобразования архитектур Architecture Enterprise Management. В соответствии с нею существует два принципиально разных варианта перехода от одного типа архитектуры к другому: мягкий, постепенный, и кардинальный, революционный (реинжиниринг архитектуры). Какой из них следует выбрать, зависит от общей зрелости ИТ в компании, от имеющихся ресурсов и от того, насколько быстро нужно получить отдачу. Такой взгляд позволяет нарисовать целевую модель архитектуры, увидеть, как она отличается от существующей, и затем посмотреть, какое типовое решение наилучшим образом подходит для тех функциональных областей, которые мы планируем развивать.
Наконец отмечу, что существует множество других классификаций — как для типовых решений, так и для корпоративных архитектур. Путём анализа соответствий можно существенно облегчить выбор продукта для конкретного предприятия и упростить процедуру подготовки технических требований.
ИТ-ландшафт на предприятии
Прикладная архитектура современной компании представляет собой сложную систему, находящуюся в постоянном развитии. Это обязательная составляющая любого предприятия, которая может быть не описана, иногда даже не осознаваема, но она есть всегда. В такой архитектуре могут соседствовать следующие элементы.1. Готовые прикладные системы:
- готовое к использованию ПО, не требующее дополнительной разработки;
- типовые решения, в той или иной степени измененные (настроенные) под потребности предприятия.
- относящиеся к так называемым унаследованным системам, которые были разработаны на предприятии давно, но все еще необходимы ему (обновление таких систем трудно, а иногда и невозможно из-за их слабой задокументированности и нередко отсутствия авторов разработки);
- продукты, решающие уникальные задачи предприятия, когда, с одной стороны, процессы необходимо автоматизировать, а с другой — нужных типовых решений нет, а если и есть, то они совершенно расходятся с тем, как предприятие планирует эти задачи решать, и не остается ничего другого, как писать собственные программные системы;
- экономные» системы, то есть такие, в которые по ряду соображений предприятие не стало вкладывать значительные средства.
Плюсы типовых решений
С другой стороны, чем привлекательны типовые решения? С моей точки зрения можно выделить четыре основных их преимущества.1. Есть возможность выбора на основе оценки результатов внедрения на других предприятиях. Мы можем использовать чужой опыт, например посмотреть, каков результат, каковы риски и т. д. Конечно, всё это с определенной долей вероятности, но тем не менее в этом очень привлекательная сторона типового решения для бизнес-руководства. Возможность перенять уникальный опыт лидеров — очень сильный стимул, хотя тут не все так просто и очевидно.
2. Возможность привлечь к внедрению внешних консультантов, получать квалифицированную поддержку на протяжении всего жизненного цикла решения. Вообще информационные технологии внедряются трудно. Легко разработать — внедрять тяжело. И уникальный опыт внедрения — это тоже очень привлекательная составляющая типового решения. Тем более, что собственных внедренцев даже в крупных компаниях маловато. И поставщики типовых решений поняли это очень давно: сейчас любая серьезная ERP-система обязательно имеет в своем составе развернутую методологию внедрения.
3. Процессы выбора внедрения и сопровождения управляемы, прежде всего с точки зрения бюджетирования и оценки рисков. В случае собственной разработки нам очень трудно предсказать, сколько времени это займет, какой бюджет мы потратим, каковы окажутся риски и как это потом будет сопровождаться. При собственной разработке ответы на эти вопросы, как правило, не известны. А вот в случае типового решения есть возможность оценить все эти моменты.
4. Наличие методологий, в частности по выбору инфраструктуры, оценке необходимых мощностей, управлению проектом внедрения. Типовое решение внедряется на многих предприятиях, поэтому все эти параметры уже определены и опробованы. Поставщики понимают, что это одно из значительных преимуществ.
Однако все эти достоинства существуют скорее в виде возможностей, чем в форме твердых гарантий. Неправильный подход предприятия и прежде всего руководства к выбору, внедрению и сопровождению типового решения приводит к тому, что все эти преимущества превращаются в серьезные недостатки.
Обычно неверный подход связан с тем, что прилагательное «типовое» воспринимается на предприятии как синоним простоты и руководство уверено в том, что типовые решения внедряются сами по себе, без каких-либо усилий с их стороны, разве что с участием ИТ-подразделений. Результатом такого заблуждения является выбор продуктов, абсолютно не подходящих конкретному предприятию; управление его внедрением превращается исключительно в отслеживание сроков и бюджета; использование методологий сводится к излишней бюрократии, а все упреки за неудачу проекта (которая весьма вероятна при таком подходе) сваливаются на внешних консультантов.
Руководству предприятия, которое собирается внедрять типовое решение, следует настроиться на серьезную общекорпоративную работу, оно должно осознанно и коллегиально провести работу по выбору решения и активно руководить проектом. И одно из важнейших условий успешного внедрения при этом — соответствие продукта существующей архитектуре предприятия.
Архитектура предприятия
Чтобы выявить закономерности в соответствии архитектуры компании и типового решения, прежде всего необходимо определить, как делятся предприятия по типу архитектур. Здесь существует огромное количество классификаций, и одна из них связана с понятием «архитектурной компоненты». Под архитектурной компонентой следует понимать набор сильно интегрированных элементов архитектуры (бизнес-процессы, оборудование, база данных, серверы приложений и Web-серверы, совокупность прикладных программ поддержки конкретных бизнес-функций, клиентские места, методологическая основа), которые могут предоставлять пользователям один или несколько ИТ-сервисов. Причем элементы эти находятся на различных уровнях — на уровне инфраструктуры, прикладных программных систем, ИТ-сервисов. Понятие архитектурной компоненты тесно связано с понятием бизнес-компоненты — набора операций и ресурсов, которые необходимы предприятию для выполнения отдельных бизнес-функций. И бизнес-компонента может состоять из нескольких ИТ-сервисов и объединять в себе несколько архитектурных компонент.По степени связности архитектурных компонент можно выделить следующие типы архитектур.
1. Монолитная. Это архитектура, в которой выделяется отдельный сильный компонент, чаще всего ERP-система. А на этот основной компонент «наращиваются» остальные — путём тесной интеграции с ним (например, написанием дополнительных программ). Такую архитектуру иногда называют интегрированной, она весьма распространена на предприятиях.
2. Слабосвязанная. Эту архитектуру формируют отдельные архитектурные компоненты, не зависящие друг от друга. Взаимосвязи между компонентами не устанавливаются или проводятся с помощью «мостов», позволяющих, например, обмениваться файлами или сообщениями. Иногда такую архитектуру называют федеративной или дискретной, а в обыденной речи — «винегретом». С моей точки зрения это наиболее популярная архитектура на российских предприятиях.
3. Сбалансированная. Обычно состоит из лучших в своем классе решений (best of breed), которые связаны между собой в одном или нескольких архитектурных слоях, чаще всего с помощью интеграционной платформы. Это архитектура, основанная на сервисных технологиях, и именно к ней, я надеюсь, мы сейчас идем, а некоторые компании уже ведут инновационные проекты в этой области.
Надо сказать, что в реальной жизни такие архитектуры и их промежуточные состояния часто возникают вне зависимости от того, каков характер основной деятельности в компании, стиль управления и корпоративная культура. Все может определяться другими факторами (например, историей развития ИТ на предприятии, имеющимся бюджетом, личными пристрастиями руководства в области автоматизации и др.).
Соответствие архитектуры предприятия и типового решения
Может показаться, что для использования типового решения наиболее естественно подходит первый вид архитектуры и именно оно должно служить ядром такой модели. Однако в действительности всё гораздо сложнее.Прежде всего выделим три показателя, которые будем анализировать. Их описание приведено в табл. 1. Кроме того, типовые решения также можно классифицировать по трём типам архитектур: постепенно уходящие с рынка клиент-серверные, распределенные (сервер приложения или базы данных, тонкий клиент) и сервисные. И в табл. 2 приведены варианты внедрения различных типовых решений в разные архитектуры предприятия.
Надо сказать, что приведённые значения параметров являются моими экспертными оценками. Причем в конкретной ситуации они могут зависеть от многих факторов, в частности от технологической основы типового решения, особенностей архитектуры предприятия и т. д. Например, слабосвязанная архитектура позволяет использовать типовое решение практически сразу. То есть типовое решение можно внедрять независимо от других проектов. Возможно, в ходе внедрения или в дальнейшем придётся написать несколько мостов для организации «слабой» связи. Однако хотя подобный подход сейчас наиболее распространен в российских компаниях, такое «независимое» внедрение не позволит получить максимальную отдачу от типового решения.
Монолитная архитектура, если она основана на типовом решении, весьма эгоистична. Она обычно не предполагает использование другого типового решения. И если (как нередко бывает на практике) такое другое решение все же внедряют, то архитектура может превратиться в слабосвязанную. В любом случае типовое решение для такой архитектуры является дестабилизирующим фактором.
Сбалансированная архитектура обычно представляет собой набор компонентов, среди которых важную часть занимают типовые решения, связанные друг с другом с помощью современной интеграционной платформы. Желательно, чтобы выбор типового решения определялся тем, какую платформу оно поддерживает. В этом случае надо быть особенно осторожным как с выбором самого решения, так и с проектом его внедрения. Однако при грамотном подходе внедрение типового решения в такую архитектуру в целом ведет к ее укреплению и развитию, и внедренная система в этом случае используется максимально эффективно.
Может показаться, что этот вид архитектуры наиболее естественно подходит для использования сервисно-ориентированного типового решения. Однако положительный эффект работающей ИС в этом случае может быть получен далеко не так быстро, как в случае слабосвязанных систем. Кроме того, не всегда совпадают версии интеграционной платформы предприятия и той, что предусмотрена в типовом решении. И если интеграционная платформа и прикладное решение делались разными разработчиками, то они часто развиваются не синхронно.
Все это показывает, насколько сложен выбор, и табл. 2 может оказать определенную помощь ИТ-руководителю предприятия в этом вопросе.
Зрелость архитектур предприятия и типовых решений
На мой взгляд, есть еще одна важная характеристика, которую надо учесть при выборе типового решения, — это зрелость. Многие проблемы типовых решений обусловлены несоответствием их качества и существующей на предприятии архитектуры. Поэтому полезно выяснить, какими качествами зрелости должны обладать как компания, намеревающаяся внедрить то или иное типовое решение, так и само это решение для его эффективного использования на предприятии.Уровень зрелости архитектуры предприятия определяется по совокупности следующих признаков:
- соответствие архитектуры стратегическим и операционным целям предприятия;
- наличие и использование корпоративных стандартов;
- зрелость этих стандартов;
- качество описания архитектуры;
- использование описания в текущей деятельности ИТ-подразделения.
- технологическая основа;
- количество успешных внедрений или работающих экземпляров типового решения;
- срок развития типового решения;
- соответствие стандартам;
- уровень зрелости методологической основы.
Говоря об эффектах, я не имею в виду экономический эффект. Мое твердое убеждение состоит в том, что экономический эффект от внедрения типовых решений посчитать трудно, а иногда и просто невозможно. Но в любом случае выгоды от проекта есть, и они очевидны.
Ситуация, когда какие-то архитектурные компоненты развиваются и дополняются с помощью типового решения, представляет собой наиболее обоснованный вариант его использования. Но при этом возможны и противоречия, и тогда придётся либо что-то менять в существующей архитектуре, либо выбирать другое типовое решение. Наконец, если типовое решение плавно включается в архитектурную модель, качество которой не меняется, значит, велика вероятность того, что оно приживется. А внедрять незрелое типовое решение в зрелую архитектуру вообще не стоит. На мой взгляд, срок жизни незрелого типового решения в зрелой архитектуре относительно невелик.
Как видно из табл. 3, типовое решение может стать двигателем развития архитектуры в том случае, если уровень его технологической и методологической зрелости выше, чем уровень зрелости корпоративной архитектуры. «Дом» не перестраивается, а рядом с ним строится новый, куда потом переезжают «жители». Именно таким образом слабосвязанные архитектуры переходят к монолитным. Но хотя многие опытные консультанты и ИТ-менеджеры знают, что развитие архитектуры является мощным стимулом для внедрения типового решения, об этом редко задумываются и редко используют такой довод в качестве аргумента при выборе варианта решения задач автоматизации. А по-моему, это очень правильный подход.
Вообще вопросы перехода между архитектурами сложны и недостаточно изучены. В последнее время все большую популярность приобретает технология преобразования архитектур Architecture Enterprise Management. В соответствии с нею существует два принципиально разных варианта перехода от одного типа архитектуры к другому: мягкий, постепенный, и кардинальный, революционный (реинжиниринг архитектуры). Какой из них следует выбрать, зависит от общей зрелости ИТ в компании, от имеющихся ресурсов и от того, насколько быстро нужно получить отдачу. Такой взгляд позволяет нарисовать целевую модель архитектуры, увидеть, как она отличается от существующей, и затем посмотреть, какое типовое решение наилучшим образом подходит для тех функциональных областей, которые мы планируем развивать.
Наконец отмечу, что существует множество других классификаций — как для типовых решений, так и для корпоративных архитектур. Путём анализа соответствий можно существенно облегчить выбор продукта для конкретного предприятия и упростить процедуру подготовки технических требований.
***
В заключение ещё раз скажу, что проект внедрения типового решения нельзя рассматривать изолированно от существующей архитектуры предприятия, что нередко делают консультанты по внедрению. Даже самые грамотные из них часто из-за нехватки времени ограничивают рассмотрение корпоративной архитектуры той ее частью, которая «ближе» к внедряемому типовому решению, не учитывая общей картины. А ведь все параметры проекта: сроки, стоимость, ресурсы, риски — зависят не только от самого решения, но и от того, в какую архитектурную среду оно попадает. 
Комментариев нет:
Отправить комментарий