Главная

Статьи

Библиотека статей

Методология бизнес-инжиниринга

"3D-предприятие" - модель стратегии трансформирующейся системы

Е. З. Зиндер, директор фирмы "Группа 24" [email protected] или [email protected]

(Данный материал является более полным вариантом статьи автора в журнале-приложения к еженедельнику Computerworld Россия, № 4 за 2000 год.)

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

Ниже рассматривается схема и общие правила построения "3D-предприятия" - стратегической модели информационно-управляющей системы (ИУС), трансформирующейся "рука об руку" с предприятием, целям которого она служит. Формулируются требования к качеству составления такой модели, предлагаются возможная организация первых шагов по ее построению. Кроме того, показывается способ перехода к дальнейшему использованию модели в проектной практике предприятия, характеризуется совместимость модели с другими, более формальными или специфичными моделями.

Есть несколько известных глобальных подходов, содержащих часть ответов на вопрос "Как быть?" в условиях трансформации.

Ответ распространенный и правильный одновременно: реализуйте компонентный подход. Принципы определения и реализации компонентов могут быть разными. Это могут быть библиотеки программных процедур и модулей с открытым описанием их интерфейсов и общей базы данных. Это могут быть отлаженные библиотеки бизнес-классов плюс стандартизация обменов между объектами. Такие решения дают возможность гораздо более гибкой переналадки и развития (расширения, изменения комплектации) систем.

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

Например, еще есть ИТ-платформа (сервера различного назначения, ОС, СУБД, оборудование АРМов, а также сеть). Во многих своих частях она не может меняться с той же степенью "мелкой грануляции", что программные компоненты или базы данных. Понятно, что добавление каждой пары столбцов в таблицу БД или пары модулей выдачи отчетов не может выполняться с синхронным расширением дискового пространства или добавлением процессоров в сервер.

В связи с этим надо сказать о другом подходе: ориентации на стандарты открытых систем, позволяющие так строить техническую платформу, чтобы изменения техники или операционных систем по крайней мере не приводили к выкидыванию всех остальных ИТ-компонентов ИС (прикладных и общесистемных). Плановое применение этих стандартов - еще один правильный ответ на вопрос "как быть". К сожалению, идеал тут не достигнут, но - опять таки - дело даже не в этом.

Оба подхода важны и полезны, но оба решают только небольшую часть проблем, причем даже эту часть могут решать при условии, что развитие системы хорошо ПРОДУМАНО ЗАРАНЕЕ.

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

Отвлечемся на время от трансформаций предприятия. Ограничимся рассмотрением того, что ИУС - это не только программы, данные и коммуникации, но также и люди (заказчики, пользователи, аналитики, конструкторы и "реализаторы"), организационные структуры, планы-графики работы, а также цели и стимулы предприятия и отдельных людей. И все эти "вещи" должны быть понятным и непротиворечивым образом соединены в одну систему. Все возрастающая сложность и многоаспектность предприятия определяют растущую сложность согласования его частей и аспектов работы.

Главная идея такого согласования: его надо начинать с самых главных характеристик предприятия, рассматривая самые главные содержательные аспекты. И проводить его не "мысленно" и не "на словах", а на явно изложенных описаниях предприятия, позволяющих видеть все существенные взаимосвязи, а это значит - на его моделях. Предыдущие два утверждения, учитываемые одновременно, приводят к пониманию того, что привычные нотации формальных моделей (структурных, объектных) слишком рано ведут к более низкому уровню моделирования, чем необходимый в начале.

Здесь надо вспомнить Дж. Захмана (John A. Zachman), одного из лидеров интеграции бизнес- и ИТ-подходов. В 1987 году появилась статья [Zachman87], название которой можно перевести так: "Общая схема архитектуры информационных систем". В ней была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее "обеспечения", а также их основные взаимосвязи.

На рис. 1 показана таблица, аналогичная схеме Захмана 1987 года. Три ее (развернутых) столбца отражают три раздела обеспечения системы: информационное, функциональное и коммуникационное. Или:
ДАННЫЕ, ФУНКЦИИ и СЕТЬ.

Шесть строк таблицы отражают шесть уровней представления системы:

1. реальная бизнес-среда,

2. концептуальная модель,

3. логическая модель,

4. технологическая (физическая) модель,

5. детальная реализация (часто - поблочная и выполняемая субподрядчиком),

6. представление пользователя.

Схема [Zachman87] была признана очень полезным средством, вошла во многие монографии по стратегическому планированию и проектированию архитектуры ИС. И в нашей практике ее полезность была очевидной. Мне - а как я знаю, и многим другим проектировщикам - не раз приходилось слышать слова: "архитектура ИС - это выбор серверов, организация сети и подключения клиентских машин". Или: "это структура главного меню системы, привязка к нему прикладных модулей и привязка пользователей к меню и базе данных". Понятно, что первое утверждение принадлежало "главному инженеру проекта", а второе - "главному программисту". И совместное обсуждение схемы, подобной рис. 1, помогало рассматривать задачи проекта в полном контексте, упорядочивать структуру требований к системе, правильно определяя причинно-следственные связи.

Позднее появилось развитие этой "плоской" модели. В [Sowa,Zachman92] рассматривалась уже схема архитектуры предприятия. На рис. 2 показана таблица, аналогичная этой схеме и показывающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также "действующие лица" - люди и организационные структуры. Или:
МОТИВЫ, ВРЕМЯ (операционное) и ЛЮДИ.

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

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

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

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

Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и, в то же время, не терять ощущение общего контекста или "холистической" перспективы (то есть взгляда на предприятие как на целое). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися "вне контекста", уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие систем, которые к тому же весьма дорого заменять. (В то же время, плоская модель Захмана ясно показывает возможное место подобного "аутсорсинга", названного им детальной реализацией "вне контекста".)

Баланс между прагматикой реализации отдельных блоков и интегрированным взглядом на систему поддерживается схемой Захмана за счет того, что эта схема:

• § облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы,

• § ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа, но, в то же время,

• § обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы.

Уже говорилось, что здесь был представлен аналог схемы Захмана для построения схемы "3D-предприятие", а не сама схема Захмана. Укажем несколько специально сделанных различий. Так, Захман связал с уровнями представления системы роли тех, кто "заказывает", проектирует и реализует систему, но из описываемого здесь развития схемы архитектуры эти роли исключены. Представляется, что их гораздо более продуктивно "добавлять" отдельно и позже, на этапе планирования проектной программы (см. об этом ниже).

Также надо заметить, что на рис. 1 нижний уровень отражает представление пользователя о практике использования системы, а не "функционирующую систему" по Захману. Это сделано для того, чтобы явно показать полезность отражения разных представлений работающей системы. Так, возможно и полезно специальное представление с точки зрения эксплуатации системы, и это представление сильно отличается от представления пользователя, причем два эти представления могут меняться во времени относительно самостоятельно. (Понятно, что подобное разделение неизбежно, ведь нижний уровень не является действующей системой, а лишь ее простым отображением, поэтому он всегда обязательно будет отображением, связанным с каким-то принципом упрощения. А это значит, что таких отображений может быть много.)

Из предыдущего понятно, что возможно увеличение числа уровней в схеме до семи. Но в практике применения возможно и уменьшение числа уровней, так как в некоторых случаях применения стандартов, готовых методик и интегрированных систем проектирования ИС возможно объединение второго и третьего уровней или третьего и четвертого. Хотя риски проекта при таком "ускоренном" проектировании возрастают, но в маленьких проектах такой подход по типу "fast track" может быть полезен.

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

В цикле [Зиндер95,96а-б] автор писал об изменениях в принципах и приемах представления моделей предприятия. Введенные тогда трехслойная модель предприятия, принцип динамической адаптации жизненного цикла системы, другие принципы и приемы Н.С.П. (подхода "Новое Системное Проектирование") служили для учета высокой скорости изменений предприятия и ИС. Но требовались и более явные средства работы с меняющимися объектами. Эта необходимость побудила автора ввести трехмерную схему (см. рис. 3), образовав ее добавлением к плоским схемам оси стратегического времени. На этой оси располагаются интервалы осуществления различных проектов и стадий развития ИС и всего предприятия. Как элементы базовой классификации сущностей на этой оси рассматриваются:

1. стратегический анализ целей и потребностей, детальный анализ предприятия,

2. конструирование технических решений,

3. детальная реализация системы решений,

4. внедрение решений,

5. использование (эксплуатация) системы,

6. совершенствование системы.

Стратегический и детальный анализ могут рассматриваться и как разные стадии, что демонстрирует принцип адаптации схемы к жизненным циклам разных типов. Характер расположения архитектурных компонентов ИУС в этом третьем измерении отличается большим разнообразием, поскольку в реальной жизни многие процессы трансформации предприятия идут параллельно и итерационно. Более того, надо осознанно управлять параллельностью, совмещая и координируя проекты разных типов, например, проекты развития предприятия ("развитие бизнеса") или проекты разных подсистем ИС.

Так появилась "объемная" схема архитектуры предприятия, его ИУС и ИС, или - схема "3D-предприятие". Сначала схема использовалась как рабочее средство обдумывания, обсуждения и планирования ИС в развитии. Затем применение "3D-схемы" оказалось полезным расширить на разработку целевых проектных программ разных видов. На http://www.sept.ru/gr24/ приведена общая информация о схеме и моделях "3D-предприятие".

Если схема является общей структурой для разных предприятий, то описание архитектуры конкретного предприятия, которое строится по общей 3D-схеме, является уже моделью "3D-предприятия". Она строится для отражения взаимосвязей ключевых компонентов ИУС предприятия на выбранном историческом участке времени его развития в трех измерениях, предусмотренных 3D-схемой (также см. рис. 3):

1. ось уровня проектирования и использования ИУС; см. на рисунке шесть "горизонтальных" уровней: потребности и планы, бизнес-модель, логическая модель, техническая конструкция, детальная реализация, практика использования;

2. ось раздела обеспечения и аспекта работы ИУС; шесть "вертикальных" разделов, выделенных, но не поименованных на рисунке: почему(цели), кто ("деятели" системы - люди и организационные единицы), что (информация), как (функции и процессы), когда (события и графики функционирования), где (размещение и коммуникации);

3. ось времени, в котором развивается предприятие и его ИУС, см. на рисунке шесть возможных (но не единственных) стадий на "верхней грани" модели, соответствующих (возможным) стадиям жизненного цикла системы: анализ (стратегический может отделяться от детального), проектирование (конструирование), реализация и ввод в действие (могут рассматриваться отдельно), использование в работе, совершенствование (на этой оси моделируются и другие аспекты развития ИУС).

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

Создаваемое в этих осях описание становится конкретной 3D-моделью после того, как в элементарных "кубиках" или ячейках модели появляются согласованные описания, то есть частные модели. К их построению предлагаются определенные требования, и главные из них таковы.

При построении 3D-модели не должны использоваться никакие формализованные нотации и узко-профессиональные жаргоны. Модель 3D-предприятия (в развитие положений Захмана) должна быть:

• § ПРОСТОЙ ДЛЯ ПОНИМАНИЯ, не технической, доступной всем (техническим и нетехническим) руководителям и специалистам,
• § ЗАКОНЧЕННОЙ в отношении предприятия так, что каждая проблема соотносится с предприятием в целом - и в данное время и в его будущем.
• § ОТКРЫТОЙ в отношении развития и трансформаций так, чтобы каждая проблема или проект свободно включались в контекст конкретных событий будущего, причем как в отношении будущего отдельных проектов, так и предприятия в целом.
• § СРЕДСТВОМ ОБЩЕНИЯ, инструментом поддержки обсуждений сложных вопросов с использованием относительно немногих и нетехнических слов.
• § ИНСТРУМЕНТОМ ПЛАНИРОВАНИЯ, позволяющим лучше принимать решения за счет того, что решение никогда не будет приниматься "в пустоте".
• § СРЕДСТВОМ РЕШЕНИЯ ЗАДАЧ, позволяющим работать с абстрактными сущностями выделяя и изолируя отдельные параметры системы без потери ощущения предприятия как развивающегося целого.
• § НЕЙТРАЛЬНОЙ, полностью независимой от каких либо инструментов, благодаря этому каждый инструмент и методология могут быть отображены на схему или модель 3D-предприятия для того, чтобы явно показать, что они делают и что не делают.

При этом важно, чтобы даже самое общее описание каждой частной модели содержало оценку состояния с точки зрения данной модели как компонента системы.

Создаваемые в ячейках частные модели должны быть согласованы в своих взаимосвязях. Особенностью 3D-предприятия является описание этих взаимосвязей не только для какого-то одного момента, но и на концах всех отрезков оси времени, которым приписаны начала и концы рассматриваемых проектов, стадий и работ.

Правилом описания взаимосвязей частных моделей является явное выделение и описание:

• § связей каждой модели-ячейки с ближайшими ячейками более высокого и более низкого уровней представления архитектуры предприятия и ИС,

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

• § связей каждой модели-ячейки с другими типами моделей данного уровня.

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

• § соответствия потребностям и более формальным требованиям к компоненту,

• § качества и готовности,

• § соответствия плановому графику работ и согласованности различных графиков,

• § достоверность и обоснованность графиков инвестиций и их окупаемости,

• § прогноз возможности изменений - самого близкого по времени изменения потребностей, требований и обеспеченности этих изменений ресурсами,

• § смысловая целостность модели одного уровня.

Так же, как и сущности на осях плоских схем, сущности на оси стратегического времени в конкретных 3D-моделях могут представлять не только развитие ИС, но и "развитие бизнеса" предприятия. А уже результатом выполнения такого развития или его стадий могут быть проекты создания новых (или развития имевшихся) компонентов ИС. Так проект развития ИС вычленяется и оформляется как подпроект проекта развития предприятия.

В качестве примера покажем начальные работы по описанию текущего состояния предприятия в целом и его ИУС, то есть разновидности модели "as is", учитывающей наличие планов предприятия. Это важное методическое положение, ведь модели "as is" в чистом виде не бывает. Предприятие находится в состоянии трансформации постоянно, даже если такая трансформация существует только в виде плана или промежуточных результатов работ по развитию.

Первым шагом является общее обсуждение 3D-схемы руководителями предприятия и его подразделений. Оно имеет своей целью достижение общего понимания всех типов сущностей этой схемы как компонентов и представлений системы в процессах их жизни - процессах создания и последующих трансформаций.

Вторым шагом является разделение работ по построению самой общей модели "3D-предприятия" между руководителями.

Координатором всех работ может быть заместитель генерального директора - директор по развитию. Он же может выполнять описание модели первого уровня - уровня целей и потребностей. Но в этих работах естественно участвовать и руководителям других специализаций: маркетинг, финансовое управление, сбыт и связь с потребителями, проектирование новых изделий или услуг, связь с поставщиками и снабжение, планирование производства и др., а также информационное обеспечение и ИТ В соответствии с реальной степенью интеграции системы управления и ИС оправдано привлечение директора информационной службы предприятия уже к работам первого уровня.

ЗАМЕЧАНИЕ об использовании терминов модельного подхода на практике.

Очень хорошо, если все указанные руководители принимают понятие "модель" и умеют им пользоваться. К сожалению на практике это бывает редко, поэтому чаще частные модели обсуждаемого уровня полезно называть так, как принято называть на предприятии документ, в котором отражается соответствующая модель: план развития, бизнес-план, бюджет, организационная структура, положения об отделениях и отделах, инструкции по выполнению конкретных работ и т.п. А также планы и описания идущих проектов развития предприятия, включая проекты создания новых товаров, проекты захвата новых сегментов рынка, проекты создания новых подсистем ИС.

Следующие шаги нумеруются условно, так как осуществляться могут в разной временной упорядоченности или частично параллельно.

Третьим шагом является привлечение специалистов и руководителей среднего звена с закреплением за ними конкретных "участков", то есть областей моделирования (в одну область может входить один элементарный кубик "3D-предприятия" или совокупность таких ячеек) на уровнях 3D-модели со второго и ниже.

Четвертым шагом является первоначальное и неформальное описание тех частных моделей, которые актуальны для погружения в общую модель "as is".

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

Затем или параллельно с этим выполняются работы по общему описанию так называемых бизнес-моделей или концептуальных моделей ИСУ и предприятия. Работы по описанию моделей логического и технического уровней выполняются при наличии компьютерной информационной системы или идущего проекта ее создания. Но при описании "as is" на уровне 3D-модели это описание носит характер самой общей инвентаризации.

Пятым шагом является рассмотрение совокупности частных моделей с их взаимосвязями. Указывалось, что в 3D-предприятии эти взаимосвязи описываются не только "на сегодня", но и на концах отрезков оси времени, которым приписаны начала и концы работ и проектов. Для построения временного слоя "as is" это относится к существующим планам, работам, проектам и их выполняемым этапам. Описание взаимосвязей выполняется с учетом указанных ранее требований.

Построенная таким образом модель используется далее и как основа диагностического анализа и как средство дальнейшего планирования проектов.

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",шеф-консультант "Директора информационной службы". Ему можно написать по адресу: [email protected] или [email protected]

Источник: www.bigspb.ru

Коротко о системе Е-МАСТЕР

Е-МАСТЕР® — система управления корпоративной информацией. Е-МАСТЕР® включает в себя возможности систем класса ECM (Enterprise Content Management). Система обеспечивает: Совместное создание и согласование документов Каждый документ может быть обсужден как при помощи прикрепленного к нему мини-форума, так и в главном форуме Разработанный документ может быть направлен на согласование по указанному маршруту Хранение документов любых форматов Хранение и передача документов в зашифрованном виде Встроенные системы восстановления после сбоев и резервного копирования Поиск документов Возможность поиска по ключевым словам и другим атрибутам документов (автор, дата создания…) Возможность поиска с помощью навигации по рубрикам Управляемый доступ к документам Возможность установки доступа к документам для различных категорий пользователей Возможность введения ограничений на работу с документами Функциональный интерфейс пользователя Веб-интерфейс, позволяющий просматривать карточки и скачивать файлы из системы хранения документов Удаленный доступ или работа пользователя из любой точки мира (при условии подключения к Интернету). Подробнее о Е-МАСТЕР >>

Система FLAMORY™

FLAMORY™ — уникальный программный продукт, позволяющий сохранять историю действий пользователя на компьютере, таких, например, как работа в приложениях Windows, посещения сайтов и д.р. Сохраненные последовательности действий, далее, можно просмотреть, сохранить в файл и передать коллегам. FLAMORY позволяет аккумулировать и делиться знаниями. Работая с FLAMORY, обмен опытом, обучение новых сотрудников, обсуждения технологий, становятся, как никогда ранее, простой и удобной, в практических аспектах, задачей. FLAMORY™ разрабатывается при участии специалистов KMSOFT. Скачать бета-версию можно по этой ссылке.

Версия для печати  |  Пользовательское соглашение