Е. З. Зиндер, директор фирмы "Группа 24"
gr24@sept.ru или ezinder@osp.ru
(Данный материал является более полным вариантом статьи автора в журнале-приложения к еженедельнику Computerworld Россия, № 4 за 2000 год.)
Все знают, что мир меняется быстрее, чем раньше, и что информационные системы должны успевать за этими изменениями. Но известно и другое. Внедренную и реально используемую систему трудно (долго, дорого, часто даже невозможно) изменять. В результате ИС может стать или становится тормозом развития предприятия. Причины могут быть разные, но истоки проблем - всегда в трансформации предприятия.
Ниже рассматривается схема и общие правила построения "3D-предприятия" - стратегической модели информационно-управляющей системы (ИУС), трансформирующейся "рука об руку" с предприятием, целям которого она служит. Формулируются требования к качеству составления такой модели, предлагаются возможная организация первых шагов по ее построению. Кроме того, показывается способ перехода к дальнейшему использованию модели в проектной практике предприятия, характеризуется совместимость модели с другими, более формальными или специфичными моделями.
Есть несколько известных глобальных подходов, содержащих часть ответов на вопрос "Как быть?" в условиях трансформации.
Ответ распространенный и правильный одновременно: реализуйте компонентный подход. Принципы определения и реализации компонентов могут быть разными. Это могут быть библиотеки программных процедур и модулей с открытым описанием их интерфейсов и общей базы данных. Это могут быть отлаженные библиотеки бизнес-классов плюс стандартизация обменов между объектами. Такие решения дают возможность гораздо более гибкой переналадки и развития (расширения, изменения комплектации) систем.
Есть и известные ограничения. Например, нет действительно "стандартных" классов. Но не это самое неприятное. Когда такие классы появятся, их использование в задачах вашего предприятия неизбежно приведет к появлению нестандартных конкретизаций. Но дело даже не в этом. Ведь такие классы, процедуры и базы данных - это только часть разделов обеспечения и уровней представления ИС.
Например, еще есть ИТ-платформа (сервера различного назначения, ОС, СУБД, оборудование АРМов, а также сеть). Во многих своих частях она не может меняться с той же степенью "мелкой грануляции", что программные компоненты или базы данных. Понятно, что добавление каждой пары столбцов в таблицу БД или пары модулей выдачи отчетов не может выполняться с синхронным расширением дискового пространства или добавлением процессоров в сервер.
В связи с этим надо сказать о другом подходе: ориентации на стандарты открытых систем, позволяющие так строить техническую платформу, чтобы изменения техники или операционных систем по крайней мере не приводили к выкидыванию всех остальных ИТ-компонентов ИС (прикладных и общесистемных). Плановое применение этих стандартов - еще один правильный ответ на вопрос "как быть". К сожалению, идеал тут не достигнут, но - опять таки - дело даже не в этом.
Оба подхода важны и полезны, но оба решают только небольшую часть проблем, причем даже эту часть могут решать при условии, что развитие системы хорошо ПРОДУМАНО ЗАРАНЕЕ.
Обратим внимание на то, что изменения ИТ-платформы подчиняются требованиям другого масштаба и, часто, другой природы по сравнению с изменениями в прикладных программах. Поэтому вопросы планирования серверов или сетевой инфраструктуры, имеющей "резерв на будущее", гораздо более понятны менеджерам разных профилей. Легко согласиться с тем, что нужен резерв для поддержки новых двадцати рабочих мест, которые появятся в ближайшие полгода, легко понять, что совсем другой резерв нужен для развития ИС при подключении новых филиалов предприятия или при изменении политики физического размещения изделий на складах торгующих подразделений. Поскольку hardware - гораздо более "твердая" вещь, чем программы, связь технических ИТ-вопросов с вопросами стратегии предприятия является более очевидной. Но конечно же эти связи есть и у всех остальных компонентов системы.
Отвлечемся на время от трансформаций предприятия. Ограничимся рассмотрением того, что ИУС - это не только программы, данные и коммуникации, но также и люди (заказчики, пользователи, аналитики, конструкторы и "реализаторы"), организационные структуры, планы-графики работы, а также цели и стимулы предприятия и отдельных людей. И все эти "вещи" должны быть понятным и непротиворечивым образом соединены в одну систему. Все возрастающая сложность и многоаспектность предприятия определяют растущую сложность согласования его частей и аспектов работы.
Главная идея такого согласования: его надо начинать с самых главных характеристик предприятия, рассматривая самые главные содержательные аспекты. И проводить его не "мысленно" и не "на словах", а на явно изложенных описаниях предприятия, позволяющих видеть все существенные взаимосвязи, а это значит - на его моделях. Предыдущие два утверждения, учитываемые одновременно, приводят к пониманию того, что привычные нотации формальных моделей (структурных, объектных) слишком рано ведут к более низкому уровню моделирования, чем необходимый в начале.
Здесь надо вспомнить Дж. Захмана (John A. Zachman), одного из лидеров интеграции бизнес- и ИТ-подходов. В 1987 году появилась статья [Zachman87], название которой можно перевести так: "Общая схема архитектуры информационных систем". В ней была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее "обеспечения", а также их основные взаимосвязи.
На рис. 1 показана таблица, аналогичная схеме Захмана 1987 года. Три ее (развернутых) столбца отражают три раздела обеспечения системы: информационное, функциональное и коммуникационное. Или:
ДАННЫЕ, ФУНКЦИИ и СЕТЬ.
Шесть строк таблицы отражают шесть уровней представления системы:
Схема [Zachman87] была признана очень полезным средством, вошла во многие монографии по стратегическому планированию и проектированию архитектуры ИС. И в нашей практике ее полезность была очевидной Мне - а как я знаю, и многим другим проектировщикам - не раз приходилось слышать слова: "архитектура ИС - это выбор серверов, организация сети и подключения клиентских машин". Или: "это структура главного меню системы, привязка к нему прикладных модулей и привязка пользователей к меню и базе данных". Понятно, что первое утверждение принадлежало "главному инженеру проекта", а второе - "главному программисту". И совместное обсуждение схемы, подобной рис. 1, помогало рассматривать задачи проекта в полном контексте, упорядочивать структуру требований к системе, правильно определяя причинно-следственные связи.
Позднее появилось развитие этой "плоской" модели. В [Sowa,Zachman92] рассматривалась уже схема архитектуры предприятия. На рис. 2 показана таблица, аналогичная этой схеме и показывающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также "действующие лица" - люди и организационные структуры. Или:
МОТИВЫ, ВРЕМЯ (операционное) и ЛЮДИ.
В результате появилось шесть разделов, которые содержат "ответы на вопросы": почему выполняются действия, когда выполняются и кто их выполняет, а также что делает система, как делает и где. При этом уровни представления, они же строки таблицы, остались те же.
Такое расширение позволило интегрировать потребности предприятия, способы его функционирования и ИТ-решения, соединять предметы и действия с человеческим фактором и операционной динамикой.
Описанные разделы и уровни по Захману являются классификацией сущностей предприятия и его ИС, о которой говорится как об основном инструментально-методическом средстве таблиц.
Схема архитектуры служла простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию ИУС и стыковки этих работ.
Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и, в то же время, не терять ощущение общего контекста или "холистической" перспективы (то есть взгляда на предприятие как на целое). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися "вне контекста", уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие систем, которые к тому же весьма дорого заменять. (В то же время, плоская модель Захмана ясно показывает возможное место подобного "аутсорсинга", названного им детальной реализацией "вне контекста".)
Баланс между прагматикой реализации отдельных блоков и интегрированным взглядом на систему поддерживается схемой Захмана за счет того, что эта схема:
Уже говорилось, что здесь был представлен аналог схемы Захмана для построения схемы "3D-предприятие", а не сама схема Захмана. Укажем несколько специально сделанных различий. Так, Захман связал с уровнями представления системы роли тех, кто "заказывает", проектирует и реализует систему, но из описываемого здесь развития схемы архитектуры эти роли исключены. Представляется, что их гораздо более продуктивно "добавлять" отдельно и позже, на этапе планирования проектной программы (см. об этом ниже).
Также надо заметить, что на рис. 1 нижний уровень отражает представление пользователя о практике использования системы, а не "функционирующую систему" по Захману. Это сделано для того, чтобы явно показать полезность отражения разных представлений работающей системы. Так, возможно и полезно специальное представление с точки зрения эксплуатации системы, и это представление сильно отличается от представления пользователя, причем два эти представления могут меняться во времени относительно самостоятельно. (Понятно, что подобное разделение неизбежно, ведь нижний уровень не является действующей системой, а лишь ее простым отображением, поэтому он всегда обязательно будет отображением, связанным с каким-то принципом упрощения. А это значит, что таких отображений может быть много.)
Из предыдущего понятно, что возможно увеличение числа уровней в схеме до семи. Но в практике применения возможно и уменьшение числа уровней, так как в некоторых случаях применения стандартов, готовых методик и интегрированных систем проектирования ИС возможно объединение второго и третьего уровней или третьего и четвертого. Хотя риски проекта при таком "ускоренном" проектировании возрастают, но в маленьких проектах такой подход по типу "fast track" может быть полезен.
В 1996 году и позже Джон Захман писал, что одной из важнейших побудительных причин для использования новых подходов является изменчивость предприятия. Он говорил, что его плоские схемы моделей архитектуры - это также и средство для организации знаний предприятия, которые очень важны в условиях усложнения работы и приспособления к высокой степени изменчивости предприятия во времени. Тем не менее, его плоская схема в явном виде включает только раздел операционного времени предприятия, а этого совершенно недостаточно для целей управления проектами развития ИС и трансформации предприятия.
В цикле [Зиндер95,96а-б] автор писал об изменениях в принципах и приемах представления моделей предприятия. Введенные тогда трехслойная модель предприятия, принцип динамической адаптации жизненного цикла системы, другие принципы и приемы Н.С.П. (подхода "Новое Системное Проектирование") служили для учета высокой скорости изменений предприятия и ИС. Но требовались и более явные средства работы с меняющимися объектами. Эта необходимость побудила автора ввести трехмерную схему (см. рис. 3), образовав ее добавлением к плоским схемам оси стратегического времени. На этой оси располагаются интервалы осуществления различных проектов и стадий развития ИС и всего предприятия. Как элементы базовой классификации сущностей на этой оси рассматриваются:
Стратегический и детальный анализ могут рассматриваться и как разные стадии, что демонстрирует принцип адаптации схемы к жизненным циклам разных типов. Характер расположения архитектурных компонентов ИУС в этом третьем измерении отличается большим разнообразием, поскольку в реальной жизни многие процессы трансформации предприятия идут параллельно и итерационно. Более того, надо осознанно управлять параллельностью, совмещая и координируя проекты разных типов, например, проекты развития предприятия ("развитие бизнеса") или проекты разных подсистем ИС.
Так появилась "объемная" схема архитектуры предприятия, его ИУС и ИС, или - схема "3D-предприятие". Сначала схема использовалась как рабочее средство обдумывания, обсуждения и планирования ИС в развитии. Затем применение "3D-схемы" оказалось полезным расширить на разработку целевых проектных программ разных видов. На http://www.sept.ru/gr24/ приведена общая информация о схеме и моделях "3D-предприятие".
Если схема является общей структурой для разных предприятий, то описание архитектуры конкретного предприятия, которое строится по общей 3D-схеме, является уже моделью "3D-предприятия". Она строится для отражения взаимосвязей ключевых компонентов ИУС предприятия на выбранном историческом участке времени его развития в трех измерениях, предусмотренных 3D-схемой (также см. рис. 3):
Первые две оси совпадают с теми, что использованы на рис. 1 и 2 в моделях, аналогичных таблицам Захмана. Третья ось позволяет явно определять изменения, которые происходили и будут происходить с предприятием и проектами создания ИС в процессах их развития и трансформации.
Создаваемое в этих осях описание становится конкретной 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-схемы можно будет получить из полного текста статьи на сайтах 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