Все знают, что мир
меняется быстрее, чем раньше, и что информационные системы
должны успевать за этими изменениями. Но известно и другое.
Внедренную и реально используемую систему трудно (долго,
дорого, часто даже невозможно) изменять. В результате ИС
может стать или становится тормозом развития предприятия.
Причины могут быть разные, но истоки проблем - всегда в
трансформации предприятия.
Ниже рассматривается
схема и общие правила построения " 3D -предприятия"
- стратегической модели информационно-управляющей системы
(ИУС), трансформирующейся "рука об руку" с предприятием,
целям которого она служит. Формулируются требования к качеству
составления такой модели, предлагаются возможная организация
первых шагов по ее построению. Кроме того, показывается
способ перехода к дальнейшему использованию модели в проектной
практике предприятия, характеризуется совместимость модели
с другими, более формальными или специфичными моделями.
Изменения и архитектура ИС
Есть несколько известных
глобальных подходов, содержащих часть ответов на вопрос
"Как быть?" в условиях трансформации. Ответ распространенный
и правильный одновременно: реализуйте компонентный подход.
Принципы определения и реализации компонентов могут быть
разными. Это могут быть библиотеки программных процедур
и модулей с открытым описанием их интерфейсов и общей базы
данных. Это могут быть отлаженные библиотеки бизнес-классов
плюс стандартизация обменов между объектами. Такие решения
дают возможность гораздо более гибкой переналадки и развития
(расширения, изменения комплектации) систем.
Есть и известные
ограничения. Например, нет действительно "стандартных"
классов. Но не это самое неприятное. Когда такие классы
появятся, их использование в задачах вашего предприятия
неизбежно приведет к появлению нестандартных конкретизаций.
Но дело даже не в этом. Ведь такие классы, процедуры и базы
данных - это только часть разделов обеспечения и уровней
представления ИС.
В связи с этим надо
сказать о другом подходе: ориентации на стандарты открытых
систем, позволяющие так строить техническую платформу, чтобы
изменения техники или операционных систем по крайней мере
не приводили к выкидыванию всех остальных ИТ-компонентов
ИС (прикладных и общесистемных). Плановое применение этих
стандартов - еще один правильный ответ на вопрос "как
быть". К сожалению, идеал тут не достигнут, но - опять
таки - дело даже не в этом.
Оба подхода важны и
полезны, но оба решают только небольшую часть проблем, причем
даже эту часть могут решать при условии, что развитие системы
хорошо ПРОДУМАНО ЗАРАНЕЕ.
Обратим внимание на
то, что изменения ИТ-платформы подчиняются требованиям другого
масштаба и, часто, другой природы по сравнению с изменениями
в прикладных программах. Поэтому вопросы планирования серверов
или сетевой инфраструктуры, имеющей "резерв на будущее",
гораздо более понятны менеджерам разных профилей. Легко
согласиться с тем, что нужен резерв для поддержки новых
двадцати рабочих мест, которые появятся в ближайшие полгода,
легко понять, что совсем другой резерв нужен для развития
ИС при подключении новых филиалов предприятия или при изменении
политики физического размещения изделий на складах торгующих
подразделений. Поскольку hardware - гораздо более "твердая"
вещь, чем программы, связь технических ИТ-вопросов с вопросами
стратегии предприятия является более очевидной. Но конечно
же эти связи есть и у всех остальных компонентов системы.
О "плоских" схемах архитектуры
Отвлечемся на время
от трансформаций предприятия. Ограничимся рассмотрением
того, что ИУС - это не только программы, данные и коммуникации,
но также и люди (заказчики, пользователи, аналитики, конструкторы
и "реализаторы"), организационные структуры, планы-графики
работы, а также цели и стимулы предприятия и отдельных людей.
И все эти "вещи" должны быть понятным и непротиворечивым
образом соединены в одну систему. Все возрастающая сложность
и многоаспектность предприятия определяют растущую сложность
согласования его частей и аспектов работы.
Главная идея такого
согласования: его надо начинать с самых главных характеристик
предприятия, рассматривая самые главные содержательные аспекты.
И проводить его не "мысленно" и не "на словах",
а на явно изложенных описаниях предприятия, позволяющих
видеть все существенные взаимосвязи, а это значит - на его
моделях. Предыдущие два утверждения, учитываемые одновременно,
приводят к пониманию того, что привычные нотации формальных
моделей (структурных, объектных) слишком рано ведут к более
низкому уровню моделирования, чем необходимый в начале.
Здесь надо вспомнить Дж. Захмана (John A. Zachman), одного
из лидеров интеграции бизнес- и ИТ-подходов. В 1987 году
появилась статья [Zachman87], название которой можно перевести
так: "Общая схема архитектуры информационных систем".
В ней была предложена простая, но концептуально мощная схема,
показывающая различные уровни представления архитектуры
ИС, различные виды ее "обеспечения", а также их
основные взаимосвязи.
На рис. 1 показана
таблица, аналогичная схеме Захмана 1987 года. Три ее (развернутых)
столбца отражают три раздела обеспечения системы: информационное,
функциональное и коммуникационное. Или: ДАННЫЕ, ФУНКЦИИ
и СЕТЬ.
Шесть строк таблицы
отражают шесть уровней представления системы:
- реальная бизнес-среда,
- концептуальная модель,
- логическая модель,
- технологическая (физическая) модель,
- детальная реализация (часто - поблочная и выполняемая
субподрядчиком),
- представление пользователя.
Схема [Zachman87] была
признана очень полезным средством, вошла во многие монографии
по стратегическому планированию и проектированию архитектуры
ИС. И в нашей практике ее полезность была очевидной Мне
- а как я знаю, и многим другим проектировщикам - не раз
приходилось слышать слова: "архитектура ИС - это выбор
серверов, организация сети и подключения клиентских машин".
Или: "это структура главного меню системы, привязка
к нему прикладных модулей и привязка пользователей к меню
и базе данных". Понятно, что первое утверждение принадлежало
"главному инженеру проекта", а второе - "главному
программисту". И совместное обсуждение схемы, подобной
рис. 1, помогало рассматривать задачи проекта в полном контексте,
упорядочивать структуру требований к системе, правильно
определяя причинно-следственные связи.
Позднее появилось развитие
этой "плоской" модели. В [Sowa,Zachman92] рассматривалась
уже схема архитектуры предприятия. На рис. 2 показана
таблица, аналогичная этой схеме и показывающая три новых
столбца, в которых отражаются еще три раздела: побудительные
причины действий системы, события и графики выполнения действий,
а также "действующие лица" - люди и организационные
структуры. Или:
МОТИВЫ, ВРЕМЯ (операционное) и ЛЮДИ.
В результате появилось
шесть разделов, которые содержат "ответы на вопросы":
почему выполняются действия, когда выполняются и кто их
выполняет, а также что делает система, как делает и где.
При этом уровни представления, они же строки таблицы, остались
те же.
Такое расширение позволило
интегрировать потребности предприятия, способы его функционирования
и ИТ-решения, соединять предметы и действия с человеческим
фактором и операционной динамикой.
Описанные разделы и
уровни по Захману являются классификацией сущностей
предприятия и его ИС, о которой говорится как об основном
инструментально-методическом средстве таблиц.
Схема архитектуры служла
простым, но мощным инструментом по применению системного
подхода для планирования работ по созданию и использованию
ИУС и стыковки этих работ.
Захман писал, что схема
архитектуры позволяет концентрироваться на отдельных аспектах
системы и, в то же время, не терять ощущение общего контекста
или "холистической" перспективы (то есть взгляда
на предприятие как на целое). Он подчеркивал, что именно
потеря такой перспективы, в частности, разработка систем
субподрядчиками, находящимися "вне контекста",
уже около пятидесяти лет составляет причину появления неинтегрируемых
и не поддерживающих предприятие систем, которые к тому же
весьма дорого заменять. (В то же время, плоская модель Захмана
ясно показывает возможное место подобного "аутсорсинга",
названного им детальной реализацией "вне контекста".)
{Одним
из вариантов разработки, развития ИУС является переложение
субподрядных работ (детальная реализация) в обязанности
специалистов отделов автоматизации предприятия. Практический
опыт показывает, что серьезным недостатком подобной методики
является отсутствие рыночных механизмов взаимодействия составляющих
системы: работая на свое предприятие программист не участвует
в разработке конкурентно-способной системы (не существует
такой необходимости), априорно располагая знаниями о своем
предприятии, «свой» разработчик не будет учитывать банки
данных трансформирующихся «чужих» предприятий. Часто система
получается «не обучаемой», не адаптивной к изменениям. «Жизненный»
цикл такой системы мал. С другой стороны на этапе эксплуатации
системы скорость принятия решения на отклики составляющих
«3D-предприятия» (например ошибки разработчиков, изменение
внутренних условий функционирования системы) специалистов
предприятия очевидно выше программистов сторонней фирмы.
Целесообразно разделять работы по детальной реализации системы
на разработочные и эксплуатационные. С. Коньков, фирма «Пресс»
г. Хабаровск}
Баланс
между прагматикой реализации отдельных блоков и интегрированным
взглядом на систему поддерживается схемой Захмана за счет
того, что эта схема:
- облегчает понимание и общение людей, имеющих разные роли
в процессах создания, развития и - использования системы,
- ясно определяет фокус внимания на (относительно) независимых
параметрах для целей анализа, но, в то же время,
- обеспечивает поддержку контекстных взаимосвязей, важных
для сохранения целостности системы.
ЗАМЕЧАНИЕ об отличиях наших плоских
схем от схем Захмана
Уже
говорилось, что здесь был представлен аналог схемы Захмана
для построения схемы " 3D -предприятие", а не
сама схема Захмана. Укажем несколько специально сделанных
различий. Так, Захман связал с уровнями представления системы
роли тех, кто "заказывает", проектирует и реализует
систему, но из описываемого здесь развития схемы архитектуры
эти роли исключены. Представляется, что их гораздо более
продуктивно "добавлять" отдельно и позже, на этапе
планирования проектной программы (см. об этом ниже).
Также
надо заметить, что на рис. 1 нижний уровень отражает представление
пользователя о практике использования системы, а не "функционирующую
систему" по Захману. Это сделано для того, чтобы явно
показать полезность отражения разных представлений работающей
системы. Так, возможно и полезно специальное представление
с точки зрения эксплуатации системы, и это представление
сильно отличается от представления пользователя, причем
два эти представления могут меняться во времени относительно
самостоятельно. (Понятно, что подобное разделение неизбежно,
ведь нижний уровень не является действующей системой, а
лишь ее простым отображением, поэтому он всегда обязательно
будет отображением, связанным с каким-то принципом упрощения.
А это значит, что таких отображений может быть много.)
Из
предыдущего понятно, что возможно увеличение числа уровней
в схеме до семи. Но в практике применения возможно и уменьшение
числа уровней, так как в некоторых случаях применения стандартов,
готовых методик и интегрированных систем проектирования
ИС возможно объединение второго и третьего уровней или третьего
и четвертого. Хотя риски проекта при таком "ускоренном"
проектировании возрастают, но в маленьких проектах такой
подход по типу "fast track" может быть полезен.
От плоских схем к " 3D -предприятию"
В
1996 году и позже Джон Захман писал, что одной из важнейших
побудительных причин для использования новых подходов является
изменчивость предприятия. Он говорил, что его плоские схемы
моделей архитектуры - это также и средство для организации
знаний предприятия, которые очень важны в условиях усложнения
работы и приспособления к высокой степени изменчивости предприятия
во времени. Тем не менее, его плоская схема в явном виде
включает только раздел операционного времени предприятия,
а этого совершенно недостаточно для целей управления проектами
развития ИС и трансформации предприятия.
В
цикле [Зиндер95,96а-б] автор писал об изменениях в принципах
и приемах представления моделей предприятия. Введенные тогда
трехслойная модель предприятия, принцип динамической адаптации
жизненного цикла системы, другие принципы и приемы Н.С.П.
(подхода "Новое Системное Проектирование") служили
для учета высокой скорости изменений предприятия и ИС. Но
требовались и более явные средства работы с меняющимися
объектами. Эта необходимость побудила автора ввести трехмерную
схему (см. рис. 3), образовав ее добавлением к плоским схемам
оси стратегического времени. На этой оси располагаются интервалы
осуществления различных проектов и стадий развития ИС и
всего предприятия. Как элементы базовой классификации сущностей
на этой оси рассматриваются:
- стратегический анализ целей и потребностей,
детальный анализ предприятия,
- конструирование технических решений,
- детальная реализация системы решений,
- внедрение решений,
- использование (эксплуатация) системы,
- совершенствование системы.
Стратегический
и детальный анализ могут рассматриваться и как разные стадии,
что демонстрирует принцип адаптации схемы к жизненным циклам
разных типов. Характер расположения архитектурных компонентов
ИУС в этом третьем измерении отличается большим разнообразием,
поскольку в реальной жизни многие процессы трансформации
предприятия идут параллельно и итерационно. Более того,
надо осознанно управлять параллельностью, совмещая и координируя
проекты разных типов, например, проекты развития предприятия
("развитие бизнеса") или проекты разных подсистем
ИС.
Так
появилась "объемная" схема архитектуры предприятия,
его ИУС и ИС, или - схема " 3D -предприятие".
Сначала схема использовалась как рабочее средство обдумывания,
обсуждения и планирования ИС в развитии. Затем применение
" 3D -схемы" оказалось полезным расширить на разработку
целевых проектных программ разных видов. На http://www.sept.ru/gr24/
приведена общая информация о схеме и моделях " 3D -предприятие".
Модель " 3D -предприятие" на
основе соответствующей схемы
Если
схема является общей структурой для разных предприятий,
то описание архитектуры конкретного предприятия, которое
строится по общей 3D -схеме, является уже моделью "
3D -предприятия". Она строится для отражения взаимосвязей
ключевых компонентов ИУС предприятия на выбранном историческом
участке времени его развития в трех измерениях, предусмотренных
3D -схемой (также см. рис. 3):
1. ось уровня проектирования и использования ИУС;
см. на рисунке шесть "горизонтальных" уровней:
потребности и планы, бизнес-модель, логическая модель, техническая
конструкция, детальная реализация, практика использования;
2. ось раздела обеспечения и аспекта работы ИУС;
шесть "вертикальных" разделов, выделенных, но
не поименованных на рисунке: почему(цели), кто ("деятели"
системы - люди и организационные единицы), что (информация),
как (функции и процессы), когда (события и графики функционирования),
где (размещение и коммуникации);
3. ось времени, в котором развивается предприятие
и его ИУС, см. на рисунке шесть возможных (но не единственных)
стадий на "верхней грани" модели, соответствующих
(возможным) стадиям жизненного цикла системы: анализ (стратегический
может отделяться от детального), проектирование (конструирование),
реализация и ввод в действие (могут рассматриваться отдельно),
использование в работе, совершенствование (на этой оси моделируются
и другие аспекты развития ИУС).
Первые
две оси совпадают с теми, что использованы на рис. 1 и 2
в моделях, аналогичных таблицам Захмана. Третья ось позволяет
явно определять изменения, которые происходили и будут происходить
с предприятием и проектами создания ИС в процессах их развития
и трансформации.
Требования к " 3D -модели"
Создаваемое
в этих осях описание становится конкретной 3D -моделью после
того, как в элементарных "кубиках" или ячейках
модели появляются согласованные описания, то есть частные
модели. К их построению предлагаются определенные требования,
и главные из них таковы.
При
построении 3D -модели не должны использоваться никакие формализованные
нотации и узко-профессиональные жаргоны. Модель 3D -предприятия
(в развитие положений Захмана) должна быть:
- ПРОСТОЙ ДЛЯ
ПОНИМАНИЯ, не технической, доступной всем (техническим и
нетехническим) руководителям и специалистам,
- ЗАКОНЧЕННОЙ в отношении предприятия так, что каждая проблема
соотносится с предприятием в целом - и в данное время и
в его будущем.
- ОТКРЫТОЙ в отношении развития и трансформаций так, чтобы
каждая проблема или проект свободно включались в контекст
конкретных событий будущего, причем как в отношении будущего
отдельных проектов, так и предприятия в целом.
- СРЕДСТВОМ ОБЩЕНИЯ, инструментом поддержки обсуждений сложных
вопросов с использованием относительно немногих и нетехнических
слов.
- ИНСТРУМЕНТОМ ПЛАНИРОВАНИЯ, позволяющим лучше принимать
решения за счет того, что решение никогда не будет приниматься
"в пустоте".
- СРЕДСТВОМ РЕШЕНИЯ ЗАДАЧ, позволяющим работать с абстрактными
сущностями выделяя и изолируя отдельные параметры системы
без потери ощущения предприятия как развивающегося целого.
- НЕЙТРАЛЬНОЙ, полностью независимой от каких либо инструментов,
благодаря этому каждый инструмент и методология могут быть
отображены на схему или модель 3D -предприятия для того,
чтобы явно показать, что они делают и что не делают.
При
этом важно, чтобы даже самое общее описание каждой частной
модели содержало оценку состояния с точки зрения данной
модели как компонента системы.
Создаваемые
в ячейках частные модели должны быть согласованы в своих
взаимосвязях. Особенностью 3D -предприятия является описание
этих взаимосвязей не только для какого-то одного момента,
но и на концах всех отрезков оси времени, которым приписаны
начала и концы рассматриваемых проектов, стадий и работ.
Правилом
описания взаимосвязей частных моделей является явное выделение
и описание:
- связей каждой модели-ячейки с ближайшими ячейками более
высокого и более низкого уровней представления архитектуры
предприятия и ИС,
- связей каждой модели-ячейки с ближайшими ячейками, отражающими
предшествующему и будущему состоянию компонента архитектуры,
- связей каждой модели-ячейки с другими типами моделей данного
уровня.
Содержанием
описания взаимосвязей должны быть характеристики:
- соответствия потребностям и более формальным требованиям
к компоненту,
- качества и готовности,
- соответствия плановому графику работ и согласованности
различных графиков,
- достоверность и обоснованность графиков инвестиций и их
окупаемости,
- прогноз возможности изменений - самого близкого по времени
изменения потребностей, требований и обеспеченности этих
изменений ресурсами,
- смысловая целостность модели одного уровня.
Так
же, как и сущности на осях плоских схем, сущности на оси
стратегического времени в конкретных 3D -моделях могут представлять
не только развитие ИС, но и "развитие бизнеса"
предприятия. А уже результатом выполнения такого развития
или его стадий могут быть проекты создания новых (или развития
имевшихся) компонентов ИС. Так проект развития ИС вычленяется
и оформляется как подпроект проекта развития предприятия.
Организация применения схемы " 3D
-предприятие"
В
качестве примера покажем начальные работы по описанию текущего
состояния предприятия в целом и его ИУС, то есть разновидности
модели "as is", учитывающей наличие планов предприятия.
Это важное методическое положение, ведь модели "as
is" в чистом виде не бывает. Предприятие находится
в состоянии трансформации постоянно, даже если такая трансформация
существует только в виде плана или промежуточных результатов
работ по развитию.
Первым
шагом является общее обсуждение 3D -схемы руководителями
предприятия и его подразделений. Оно имеет своей целью достижение
общего понимания всех типов сущностей этой схемы как компонентов
и представлений системы в процессах их жизни - процессах
создания и последующих трансформаций.
Вторым
шагом является разделение работ по построению самой
общей модели " 3D -предприятия" между руководителями.
Координатором
всех работ может быть заместитель генерального директора
- директор по развитию. Он же может выполнять описание модели
первого уровня - уровня целей и потребностей. Но в этих
работах естественно участвовать и руководителям других специализаций:
маркетинг, финансовое управление, сбыт и связь с потребителями,
проектирование новых изделий или услуг, связь с поставщиками
и снабжение, планирование производства и др., а также информационное
обеспечение и ИТ В соответствии с реальной степенью интеграции
системы управления и ИС оправдано привлечение директора
информационной службы предприятия уже к работам первого
уровня.
ЗАМЕЧАНИЕ об использовании терминов модельного
подхода на практике
Очень
хорошо, если все указанные руководители принимают понятие
"модель" и умеют им пользоваться. К сожалению
на практике это бывает редко, поэтому чаще частные модели
обсуждаемого уровня полезно называть так, как принято называть
на предприятии документ, в котором отражается соответствующая
модель: план развития, бизнес-план, бюджет, организационная
структура, положения об отделениях и отделах, инструкции
по выполнению конкретных работ и т.п. А также планы и описания
идущих проектов развития предприятия, включая проекты создания
новых товаров, проекты захвата новых сегментов рынка, проекты
создания новых подсистем ИС.
Следующие
шаги нумеруются условно, так как осуществляться могут в
разной временной упорядоченности или частично параллельно.
Третьим
шагом является привлечение специалистов и руководителей
среднего звена с закреплением за ними конкретных "участков",
то есть областей моделирования (в одну область может входить
один элементарный кубик " 3D -предприятия" или
совокупность таких ячеек) на уровнях 3D -модели со второго
и ниже.
Четвертым
шагом является первоначальное и неформальное описание
тех частных моделей, которые актуальны для погружения в
общую модель "as is".
На
оси стратегического времени директор по развитию может самостоятельно
описывать модель только на уровне результатов самых первых
шагов стадии стратегического анализа. Обычно он подключает
к работе директора по маркетингу и финансового директора.
Роль последнего важно отразить, так как многие сущности
на оси стратегического времени являются по сути инвестиционными
проектами.
Затем
или параллельно с этим выполняются работы по общему описанию
так называемых бизнес-моделей или концептуальных моделей
ИСУ и предприятия. Работы по описанию моделей логического
и технического уровней выполняются при наличии компьютерной
информационной системы или идущего проекта ее создания.
Но при описании "as is" на уровне 3D -модели это
описание носит характер самой общей инвентаризации.
Пятым
шагом является рассмотрение совокупности частных моделей
с их взаимосвязями. Указывалось, что в 3D -предприятии эти
взаимосвязи описываются не только "на сегодня",
но и на концах отрезков оси времени, которым приписаны начала
и концы работ и проектов. Для построения временного слоя
"as is" это относится к существующим планам, работам,
проектам и их выполняемым этапам. Описание взаимосвязей
выполняется с учетом указанных ранее требований.
Построенная
таким образом модель используется далее и как основа диагностического
анализа и как средство дальнейшего планирования проектов.
Дальнейшее использование модели "
3D -предприятие"
3D
-предприятие приносит наибольшую пользу в случаях, когда
описываются несколько слоев по оси времени, явно представляющих
предприятие и его ИУС в развитии. Поэтому рассмотрим планирование
не одного проекта, а проектной программы.
По
разным причинам полезно разбивать "бесконечные"
работы по созданию или развитию ИС на короткие проекты 6-9
месяцев длительности. Одна из причин - скорость изменений
требований к ИС, из-за чего давно стала понятной необходимость
изменения подходов к построению моделей предприятия в проектах
ИС. Вспомним, что в [Зиндер96б] описан недостаток рассмотрения
двух моделей - "as is" и "to be" - и
рекомендовано перейти к рассмотрению серии моделей, которые
строятся для разных моментов времени.
В
конкретных ИС часто полезно рассматривать три очереди развития
ИС:
- "для сегодня" (идущие проекты, проекты,
планируемые к запуску в ближайшие дни или недели и завершение
которых планируется на ближайшие недели и месяцы),
- "для завтра" (проекты, которые должны
поддержать основные стратегические задачи и будут завершены
примерно через год, редко - полтора),
- "для послезавтра" (проекты, которые должны
опираться на сегодняшние и завтрашние, которые уже сегодня
должны определять требования к совместимости старых и новых
подсистем и единиц ИУС и должны завершиться через полтора
- два года, поддерживая перспективные стратегии развития
предприятия).
Каждой
очереди соответствует группа взаимосвязанных проектов, а
каждому проекту соответствует своя группа работ, захватывающая
свою область смежных во времени ячеек 3D -модели. Именно
при построении модели проектной программы, развивающейся
во времени, становится наиболее ясной польза построения
и применения общей понятийной модели предприятия, которая
может играть роль минимального средства интеграции систем
(см. [Зиндер96в]) уже начиная с составления " 3D -модели".
Кроме того, именно при построении такой модели становится
наиболее наглядной картина согласованности различных инвестиционных
акций предприятия.
Схема "мультикуб" и ее применение
Модель
" 3D -предприятие" может служить базой для перехода
к следующему, более конкретному уровню планирования при
управлении проектной программой. Для этого рассматривается
сочетание областей работ каждого проекта и нескольких дополнительных
осей:
- применяемые методы \ инструменты разработки ИС или управления,
- специализации конкретных разработчиков ИС или управленцев,
- уровень абстракции модельных компонентов и др.
На рис. 4 показан процесс соединения выделенной в архитектуре
3D -предприятия проектной программы с параметрами организации
проектов из этой программы. Добавляемые параметры (участники
проекта и инструменты проектирования) связываются с 3D -предприятием
по такой характеристике, как уровень проектной задачи.
На
http://www.tline.ru/present1/ представлена система организации
курсов профессионального обучения "Training Line System",
разработанная учебным центром "Training Line"
и фирмой "Группа 24". На этом примере конкретного
применения схемы 3D -предприятия можно видеть как модель-мультикуб
используется при планировании одного из видов проектных
программ - целевых программ обучения.
" 3D -предприятие" и другие
схемы, модели и задачи
В
3D -предприятии использован аналог схемы Захмана, а не ее
копия, причем отличия были введены специально. Так, Захман
связал с уровнями представления системы роли тех, кто "заказывает",
проектирует и реализует систему, а из описываемого здесь
развития схемы архитектуры эти роли исключены. Представляется,
что их гораздо более продуктивно "добавлять" отдельно,
на этапе перехода к модели-мультикубу для более конкретного
планирования проектной программы. Есть и другие отличия
(их характеристику, а также дополнительные подробности о
применении 3D -схемы можно будет получить из полного текста
статьи на сайтах www.sept.ru и www.tline.ru).
3D
-предприятие естественно стыкуется с другими видами схем стратегического
и архитектурного уровней. К таким схемам относятся, например,
схемы циклов маркетингового стратегического управления, или
такие схемы создания ИС и ИУС, как трехмерная архитектура
CIMOSA, схемы бизнес- и информационной платформ и архитектур
Дж. Хендерсона, схемы "здания ARIS" А. Шеера.
3D
-предприятие работает в проектах самых разных видов, и практика
показала целесообразность применения этого подхода еще до
первых шагов планирования проектов. А благодаря концептуальной
совместимости с другими схемами после описания целостной
и динамичной 3D -архитектуры можно включать в работу более
специфические или более технические инструменты и модели,
например, Turbo-BPR, Process Charter, ARIS ToolSet, UML
RRose или Oracle Designer.
Литература
[Zachman87] John A. Zachman. A Framework for Information
System Architecture. IBM System Journal, vol. 26, no. 3,
1987.
[Sowa,Zachman92] J.F. Sowa, J.A. Zachman. Extending and
Formalizing the Framework for Information System Architecture.
IBM System Journal, vol. 31, no. 3, 1992.
[Зиндер95,96а-б] Е.З. Зиндер. Новое системное проектирование:
информационные технологии и системное проектирование. //СУБД
4, 1995; 1,2, 1996.
[Зиндер96в] Е.З. Зиндер. Проектирование баз данных: новые
требования, новые подходы. //СУБД 3, 1996.
Евгений Захарович Зиндер - директор аналитического и конструкторского
бюро "Группа 24",шеф-консультант "Директора
информационной службы". Ему можно написать по адресу:
ezinder@osp.ru или gr24@sept.ru
