Основные понятия КИС и проблемы их создания и
реклама
1 Корпоративные информационные системы. Подборка материалов к семинару “Автоматизация организационной деятельности”. Составители: В.Н.Негода, В.В.Шишкин КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ................................................................................................. 1 1. ОСНОВНЫЕ ПОНЯТИЯ КИС И ПРОБЛЕМЫ ИХ СОЗДАНИЯ И ЭКСПЛУАТАЦИИ .......................................... 1 1.1. 1.2. 2. ОСНОВНЫЕ ПОНЯТИЯ КИС .............................................................................................................................................. 1 ПРОБЛЕМЫ РАЗВИТИЯ И ВНЕДРЕНИЯ КИС НА РОССИЙСКИХ ПРЕДПРИЯТИЯХ:................................................................ 2 ОРГАНИЗАЦИЯ КАК ОБЪЕКТ АВТОМАТИЗАЦИИ................................................................................................. 3 2.1. 2.2. 2.3. ЧТО ТАКОЕ ОРГАНИЗАЦИЯ ................................................................................................................................................ 3 КАК СТРОИТСЯ ПРОЦЕСС РЕОРГАНИЗАЦИИ ...................................................................................................................... 3 СООБРАЖЕНИЯ ПО РЕОРГАНИЗАЦИИ ИНФОРМАЦИОННОЙ СЛУЖБЫ ................................................................................ 4 3. КОРПОРАТИВНЫЕ СЕТИ И БАЗЫ ДАННЫХ ............................................................................................................ 4 4. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ КОРПОРАТИВНЫХ СИСТЕМ ............................................................. 11 4.1. С.Д.ПАРОНДЖАНОВ, КОМПАНИЯ АРГУССОФТ. МЕТОДОЛОГИЯ СОЗДАНИЯ КОРПОРАТИВНЫХ ИС.............................. 11 4.1.1. Введение ................................................................................................................................................................. 11 4.1.2. Основные составляющие методологии .............................................................................................................. 12 4.1.3. Итерационная спиральная модель жизненного цикла ИС. ............................................................................... 12 4.1.4. Комплекс развивающихся систем согласованных моделей .............................................................................. 13 4.1.5. Методология анализа ИС на основе бизнес-процессов ..................................................................................... 13 4.1.6. Методология проектирования от данных ......................................................................................................... 16 4.1.7. Комплекс согласованных инструментальных средств ..................................................................................... 17 4.1.8. Заключение ............................................................................................................................................................ 17 4.2. ЕВГЕНИЙ ЗИНДЕР. О МАСТЕРСКОЙ И МАСТЕРСТВЕ........................................................................................................ 17 4.2.1. Для малых предприятий, ...................................................................................................................................... 18 4.2.2. Для средних проектов........................................................................................................................................... 18 4.2.3. Мастера особой квалификации -......................................................................................................................... 18 4.2.4. Предупреждение ................................................................................................................................................... 19 4.2.5. Результаты такого подхода ............................................................................................................................... 20 4.2.6. О мастерстве высшего класса и мастерской ................................................................................................... 20 4.3. ДВА ПОДХОДА К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ .............................................................................. 20 4.3.1. Два подхода к проектированию. ......................................................................................................................... 20 4.3.2. Применение процессного подход. Цели проекта ............................................................................................... 21 4.3.3. Базовые, общие и перспективные технологии ................................................................................................... 21 4.3.4. Состав прикладных задач .................................................................................................................................... 23 4.3.5. Концептуальная модель ИИС............................................................................................................................... 23 4.3.6. Состав и модели процедур документооборота, обеспечивающих информационное взаимодействие автоматизированных рабочих мест Компании ................................................................................................................ 24 4.3.7. Заключение ............................................................................................................................................................ 25 1. Основные понятия КИС и проблемы их создания и эксплуатации По материалам беседы с академиком РАЕН Лазебником Евгением Романовичем КомпьютерПресс N1 1999, с. 90-98. Корпоративные информационные системы в России: вчера, сегодня, завтра.. 1.1. Основные понятия КИС КИС – среда информационной поддержки целенаправленной коллективной деятельности. Главная задача КИС – эффективное управление всеми ресурсами предприятия(материально-техническими, финансовыми, технологическими и интеллектуальными) для получения максимальной прибыли и удовлетворения материальных и профессиональных потребностей всех сотрудников предприятия . КИС по своему составу - «совокупность различных программно-аппаратных платформ, универсальных и специализированных приложений различных разработчиков, интегрированных в единую информационно-однородную систему, которая наилучшим образом решает в некотором роде уникальную задачу каждого конкретного предприятия». То 2 есть, «КИС – человеко-машинная система и инструмент поддержки интеллектуальной деятельности человека, которая под его воздействием должна: Накапливать определенный опыт и формализованные знания; Постоянно совершенствоваться и развиваться; Быстро адаптироваться к изменяющимся условиям внешней среды и новым потребностям предприятия.» «Не человек должен приспосабливаться к возможностям КИС и всех ее составляющих, а КИС, в разумных пределах, должна соответствовать насущным потребностям человека, его опыту, знаниям и психологии.» 1.2. Проблемы развития и внедрения КИС на российских предприятиях: 1. В 99 случаях из 100 полностью отсутствует какая бы то ни было здравая политика или стратегия построения КИС на пром. предприятиях. Решения по выбору технологической платформы формирования КИС и партнера по ее созданию подавляющее большинство руководителей принимает под эмоциональным напором продавцов «готовых» решений, активно ссылающихся на удачные опыты внедрения этих платформ в авторитетных фирмах. При этом потребитель полностью лишен возможности предварительно «пощупать», оценить, объективно сопоставить предлагаемые решения с аналогичными конкурентными предложениями других продавцов применительно к своим проблемам, чтобы сделать единственно правильный выбор. Практически покупается «кот в мешке». При этом потребитель вынужден купить полный комплект аппаратуры(компьютеры, сетевое оборудование) и системное и программное обеспечение, все это развернуть и установить и только через несколько месяцев возможно получит возможность ощутить реальную отдачу. Основными отрицательными последствиями такого подхода являются: Простаивающее и морально устаревающее компьютерное оборудование и купленное в прок дорогостоящее ПО; Принятая от системного интегратора в эксплуатацию КИС, но так и не решившая проблем потребителя; Потерянные значительные денежные средства и время; «мелкая дрожь» при одном только упоминании от ИТ и КИС. 2. Решения о выделении средств и об их расходовании на ИТ и создание КИС в большинстве случаев принимает чиновник, далекий от проблем данной области. При этом рассматривается вопрос не о создании КИС применительно к решению поставленных задач, а о закупке компьютеров, ОС, СУБД и прочего у вполне определенных поставщиков. Дружественные к Чиновнику фирмы-поставщики, системные интеграторы и проектные организации готовят ТЭО проекта КИС, определяют состав и стоимость покупаемых компонентов, подготавливают экспертное заключение. При этом ни сам чиновник, ни фирмы участницы проекта не отвечают за конечный результат и окупаемость израсходованных средств. 3. Хорошо зарекомендовавшие себя на западе дорогостоящие решения не дают ожидаемого эффекта на российских предприятиях по следующим основным причинам: Во-первых, западные решения разрабатывались под конкретную инфраструктуру организационного и технологического управления(менеджмента) и корпоративный стандарт одного или нескольких стратегических инвесторов крупного или среднего бизнеса. Во-вторых, эти решения создавались в эволюционном порядке 10-15 лет, и к настоящему времени их архитектура устарела вместе с заложенными в них технологиями. В-третьих, принципиально невозможно в России использовать все предлагаемые решения в области систем управления предприятиями, рассчитанные на эксплуатацию только в условиях стабильного социально-экономического и нормативно-правового пространства в достаточно длительные временные интервалы. Российскому бизнесу до этой стабильности далеко. В-четвертых, у основной массы российских управленцев отсутствуют необходимые знания, опыт и культура в сфере менеджмента. На наших предприятиях отсутствуют корпоративная культура и корпоративный стандарт. Без них невозможно управлять предприятием в условиях рынка. В-пятых, все предлагаемые сегодня российскому бизнесу решения в области создания КИС навязывают их потребителям либо западный(зачастую непригодный для российских условий) стандарт организации деятельности в конкретных сферах, либо субъективный взгляд программистов-разработчиков отдельных программ, весьма далеких от предметных областей и нужд профессиональных специалистов. В-шестых, большинство предлагаемых на рынке приложений бизнес-класса западных разработчиков(системы управления предприятием, CAD/CAM-системы и т.д.), используемых, по утверждению их поставщиков, известными западными фирмами, являются лишь некоторыми универсальными в своем классе базовыми платформами. Фирмыпотребители этих систем вложили десятки и сотни миллионов долларов в разработку на этих платформах специализированного ПО, которое и решает весь необходимый для данного бизнеса круг задач, является их ноу-хау и инструментом выживания в конкурентной борьбе и, естественно, никому не продается. 4. Руководители и инженерный состав предприятий не готовы работать по тем технологиям, которые упорно навязывают им большинство системных интеграторов. 5. В прессе практически отсутствуют публикации об отрицательном опыте создания КИС. В результате системные интеграторы и специалисты предприятий лишены возможности учиться на чужих ошибках и объем воспроизводства этих ошибок велик. 6. Практически все фирмы, берущие на себя роль создания КИС, рассматривают ее как некоторую совокупность частных решений и компонентов их реализации, в числе которых: Единая БД хранения информации, формируемая различными и не связанными между собой программами и прикладными системами; 3 Множество прикладных систем, созданных разными фирмами и по разным технологиям(финансы, материальнотехнический учет, конструкторско-технологическая подготовка производства, документ, аналитика и т.п.); Менеджмент, без четкой постановки которого невозможно управление предприятием. Эта составляющая при внедрении КИС чаще всего является обособленным компонентом и для системного интегратора выступает удобным аргументом оправдания отсутствия отдачи от КИС. При таком подходе конечный потребитель получает несколько не связанных между собой компонентов – само предприятие, КИС, менеджмент, управление техпроцессами и т.д., со всеми вытекающими последствиями. Это очень удобная позиция для системных интеграторов, т.к. все неудачные реализации можно списать на любые вышеперечисленные компоненты. 7. На государственном уровне не существуют основополагающих принципов создания КИС как инструмента эффективного управления социально-экономическими процессами на всех уровнях, а также инструмента формирования, накопления и эффективного использования информационных ресурсов ка стратегического компонента развития и безопасности государства. Вся деятельность всевозможных государственных , внутриведомственных, отраслевых, региональных органов, комитетов и прочих структур сводится к порождению множества бумаг и распределению(а скорее перераспределению в своих интересах) средств, выделяемых на цели информатизации. Как правило, эти средства направляются ими на поддержку западной индустрии ИТ и созданию там дополнительных рабочих мест. Большинство руководителей и ведущих специалистов этих структур, освоив с десяток общепринятых ключевых терминов из области ИТ, формируют так называемую государственную и отраслевую политику информатизации. При этом стиль и методы проведения этой политики меняются в зависимости от ситуации, сознательно вводя в заблуждение тех, кто действительно нуждается в объективной информации об ИТ, прогрессивных и технологичных подходах и т.д. Например, поднятый в качестве флага информационной политики термин «Единое информационное пространство»(ЕИП), включающий в себя представление о целом комплексе методологий и технологий реализации и эксплуатации КИС, выхолащивается и сознательно подменяется на практике понятием о приобретении инструментов создания системы баз данных и реализации частных решений. 2. Организация как объект автоматизации По матириалам статьи А.Н. Рассказова - заместитель начальника Управления информации и автоматизированных систем РАО "Норильский Никель", 2.1. Что такое организация У организации есть две стороны: внешняя и внутренняя. Организация извне - это производимые ею товары (или оказываемые услуги), клиенты, поставщики сырья и оборудования, а также идеология отношений с внешним миром, взаимоотношения с властью и тому подобное. Организация изнутри - это совокупность четырех основных составляющих: стратегия предприятия, организационная структура, процессы, персонал. Стратегия определяет цели и задачи предприятия, направления достижения этих целей, выделяет наиболее важные сегменты продуктов и клиентов, подчеркивает конкурентные преимущества, которыми должно обладать предприятие. Главная ценность стратегии - заданность правил игры, определение, пусть и в самом общем виде, что есть хорошо, а что есть плохо. Стратегия выдвигает ряд критериев, которые помогают выбирать лучшие решения при построении организационной структуры, подбирать людей и выстраивать процессы. Организационная структура это прежде всего организационная схема - схема подчиненности (подотчетности) подразделений. Важными параметрами структуры являются также глубина и ширина управления, то есть количество уровней структуры и количество подчиненных на каждом уровне, а также степень централизации/децентрализации. Процессы бывают вертикальными и горизонтальными. Вертикальные процессы помимо оперативного управления охватывают вопросы планирования и бюджетирования. Горизонтальные процессы суть технология работы, которая определяет способы разделения труда между работниками, порядок взаимодействия по входам-выходам между функциональными блоками, выполнение функций контроля. Персонал нужно подбирать, расставлять по рабочим местам, обучать и переобучать, планировать карьеру. Можно выстроить подобие ГУЛАГа, ориентируясь на дешевую рабочую силу, без особых устремлений и самоличностных ценностей, или, другая крайность, устроить полную анархию под неким развесистым и пушистым знаменем. Наверное, истина где-то посередине. 2.2. Как строится процесс реорганизации Грамотный процесс реорганизации разворачивается так, что последовательно захватывает все перечисленные компоненты именно в том порядке, как перечислено: сначала формулируется новая стратегия, затем формируются контуры новой структуры, затем выстраиваются новые основные технологические цепочки и, наконец, ключевые люди занимают ключевые посты. Можно, конечно, действовать и в обратном порядке, но обычно это не приводит к вразумительным результатам: когда вы наконец готовы сформулировать стратегию, выясняется, что вы располагаете совсем не теми людьми, которые способны ее реализовать, процессы не могут ее поддержать, а структура направлена на достижение прямо противоположных целей. В принципе изложенная последовательность шагов является правильной как для предприятия в целом, так и для составляющих его подразделений. Процесс реорганизации должен быть устроен итерационно: сначала прорисовывается верхний уровень, затем происходит детализация нижних уровней. В определенный момент времени перед директором или главным руководителем информационной службы встает вопрос об устройстве своего "государства в государстве". 4 Очень важно правильно угадать этот момент, особенно если учесть, что положение руководителя этой службы имеет свои уникальные особенности, не характерные для других подразделений. Понятно, что процесс реорганизации не ограничивается исполнением цепочки "стратегия - структура - процессы - ключевые персоны". Вслед за этим наступает черед следующих шагов, а именно: "информационная система - управленческий учет - система поощрения труда - обучение персонала". Каким-то из этих шагов уделяется больше внимания, каким-то меньше, но новые требования к информационной системе возникают всегда, что вновь поднимает вопрос о реорганизации самой службы. Таким образом, ИС-руководителю приходится заниматься реорганизацией дважды - один раз вместе со всеми, второй раз персонально. Бороться с этим можно, только занимая активную позицию, и прежде всего правильно диагностируя текущую ситуацию. 2.3. Соображения по реорганизации информационной службы 1. Если предприятие не выработало общую стратегию своего развития либо в период активных обсуждений по этому вопросу не достигнут консенсус, то не имеет смысла заниматься информационной стратегией. Если попытаться вынести разработанную в таких условиях "стратегию" на суд руководства предприятия, то немедленно произойдет подмена вопроса: вместо стратегии развития информационных систем в действительности будет обсуждаться стратегия развития предприятия, причем без предварительной проработки вопроса, и цель достигнута не будет. Если же информационная стратегия не выносится на обсуждение руководства предприятия, тогда она не является утвержденной и, следовательно, не имеет фактической силы. 2. На практике тезис о наличии общей стратегии как необходимого условия для выработки частной стратегии осознается руководством далеко не всегда. Руководство требует представить стратегию, не обращая внимания на аргументы в духе вышеизложенного тезиса. В этих условиях не остается ничего другого, как поддержать игру, предложенную руководством, и под видом информационной стратегии вынести на рассмотрение руководства, например, перечень конкретных проектов. Обсуждение проектов будет - как минимум - предметным, что хорошо уже само по себе, а также дает некоторые ориентиры для решения вопросов по структуре и персоналу. 3. Если все же руководство предприятия выработало общую стратегию, то тогда можно разрабатывать контуры информационной стратегии, а доработку окончательных деталей отложить до момента утрясания структуры предприятия. Причина здесь в том, что изменения структуры могут коренным образом изменить состав подразделений - клиентов информационной службы. Скажем, руководство посчитает необходимым произвести децентрализацию информационных ресурсов или по максимуму задействовать аутсорсинг. 4. Структурой службы целесообразно заниматься сразу после назначения ключевых фигур на ключевые посты предприятия. Как мы помним, начиная с этого момента происходит новый виток повышения интереса к информационным системам. При этом часть новых требований удается закрыть просто назначением персонального менеджера по тому или другому направлению или созданием отдельной группы по данному направлению. Главное не возвращаться снова к мучительному процессу переделки стратегии, что может повлечь за собой серьезную перетряску организационной структуры. Нет необходимости заниматься этим дважды в году, достаточно одного раза. 5. Процессами и персоналом информационной службы можно заниматься в автономном режиме, но только после того, как решены вопросы со стратегией и структурой. При скоропостижном увольнении кого-либо из ключевых сотрудников лучше всего решать этот вопрос через продвижение людей по служебной лестнице. 3. Корпоративные сети и базы данных Виктор Олифер, Центр Информационных Технологий Эпитет "корпоративный" часто используется для характеристики продуктов вычислительных систем. Корпоративными могут быть названы почти все типы элементов вычислительной системы, от концентраторов и маршрутизаторов до серверов и операционных систем - разве что сетевые адаптеры редко удостаиваются такой чести. Эта характеристика также применяется и к системам управления базами данных : Oracle, Informix, Sybase, DB2 - все это примеры СУБД, которые часто называются корпоративными. Среди специалистов и производителей существуют различные толкования этого термина (равно, как и любого другого), поэтому иногда бывает трудно понять, почему производитель называет свое детище корпоративным, а продукцию конкурентов - нет. Интуитивно с прилагательным "корпоративный" связывается образ чего-то крупного, мощного, производительного и надежного. Тем не менее, хочется иметь более твердую почву под ногами, и основания для этого есть. Имеется несколько устоявшихся признаков корпоративности, и их можно применять универсально, как к аппаратуре, так и к программным продуктам, в том числе и базам данных. Наличие этих признаков гарантирует хорошую работу продуктов в корпоративной сети. Эти признаки тесно связаны с особенностями и спецификой корпоративных сетей, поэтому для четкого формулирования требований к корпоративным базам данных необходимо ясное понимание особенностей корпоративных сетей. Корпоративные сети интересны для специалистов, занимающихся системами управления базами данных и по другой причине. В широком смысле вычислительная сеть тождественна вычислительной системе - к ней относятся компьютеры, коммуникационное оборудование, операционные системы, системы управления базами данных и приложения. Сеть в узком смысле - это программно-аппаратный комплекс, организующий надежную и быструю доставку сообщений между взаимодействующими приложениями. Для базы данных сеть является универсальной транспортной платформой, которая берет на себя выполнение рутинных коммуникационных задач, подобно тому, как файловая система освобождает СУБД от необходимости заниматься низкоуровневыми вопросами форматирования диска, физическими и логическими аспектами организации файлов и т.п. 5 Многие СУБД для достижения высоких эксплуатационных показателей могут подменять и "исправлять" существующие операционные системы. Например, создавать на свободном разделе диска файловую систему такой структуры, при которой достигается высокая скорость специфических для базы данных операций поиска и сортировки записей небольших размеров. Ускорение достигается за счет специализации функций файловой или операционной систем на операциях определенного вида. Аналогичным образом некоторые СУБД поступают и с коммуникационными функциями операционных систем. Примерами здесь могут служить такие компоненты баз данных как Oracle SQL*Net или Ingres Net, в которых реализованы популярные транспортные протоколы. Понятно, что дублирование транспортных функций ОС дополнительными компонентами СУБД происходит не от хорошей жизни, а от ограниченности сетевых возможностей универсальных операционных систем: отсутствия тех или иных протоколов или низкоскоростной их реализации. Однако, использование специализированных реализаций транспортных средств влечет за собой не только положительные, но и отрицательные последствия. СУБД - отнюдь не единственное приложение в сети, способное поддерживать собственные средства транспортировки, такие средства могут быть встроены и в другие приложения - почту, системы коллективной работы, графические системы автоматизированного проектирования и т.д. и т.п. У администратора в этом случае прибавляется забот по поддержанию разнородных продуктов, выполняющих одну и ту же функцию, но по-своему. Очевидно, что использование единой транспортной системы для всех приложений вычислительной системы облегчило бы жизнь и пользователям, и администраторам. И в этом направлении корпоративные сети быстро развиваются, позволяя своим пользователям отказаться от транспортных услуг отдельных, хотя и очень важных приложений и использовать общие средства. Итак, что же такое корпоративные сети? В англоязычной литературе этот вид сетей чаще называется "enterprise-wide networks" (дословно - сеть масштаба предприятия), а в нашей стране прижился другой термин иностранного происхождения - корпоративные сети, что, на наш взгляд, больше соответствует самой сути таких сетей. Термин "корпоративная" отражает с одной стороны величину сети, так как корпорация - это крупное, большое предприятие. С другой стороны, этот термин несет в себе смысл объединения, то есть корпоративная сеть - это сеть, получившаяся в результате объединения нескольких, как правило, разнородных сетей. Кроме того, дух корпоративности - это дух некоего единства, общности, и в этом смысле корпоративные сети - это сети, в которых неоднородные компоненты живут в счастливом согласии. Появление корпоративных сетей - это хорошая иллюстрация известного философского постулата о переходе количества в качество. При объединении отдельных сетей крупного предприятия, имеющего подразделения в различных городах и странах, в единую сеть, многие количественные характеристики объединенной сети часто превосходят некоторый критический порог, за которым начинается новое качество. При этом число пользователей и компьютеров может измеряться тысячами, число серверов - превышать несколько сотен, число записей в базе данных - несколько миллионов, а расстояния между сетями могут оказаться такими, что использование глобальных связей становится необходимостью. Кроме того, непременным атрибутом такой сложной и крупномасштабной сети является гетерогенность - нельзя удовлетворить потребности тысяч пользователей с помощью однотипных элементов и однородных структур. В корпоративной сети обязательно будут использоваться различные типы компьютеров - от мейнфреймов до персоналок, 3-5 типов операционных систем, с десяток различных коммуникационных протоколов, несколько СУБД и множество других приложений. Превышение количественными изменениями некоторой критической массы и породило новое качество - корпоративную сеть. Термин "корпоративность" связывает описанный вид сетей с принадлежностью их одному предприятию, причем крупному. Этот признак не является главным, а просто отражает тот факт, что крупномасштабная, гетерогенная и хорошо интегрированная сеть чаще всего получается в результате усилий предприятия при объединении своих отдельных сетей в единую информационную систему. Поэтому, если сеть обладает отмеченными выше особенностями, но не принадлежит одной корпорации, то ее все равно можно назвать корпоративной. Корпоративные сети возникли не на пустом месте. Сначала на предприятиях создавались небольшие локальные сети, используемые только небольшой группой сотрудников - так называемые сети рабочих групп, затем они вырастали в сети отделов и кампусов (площадок). Сети рабочих групп и отделов - используются небольшой группой сотрудников, решающих общие задачи. Главной целью сети отдела является разделение локальных ресурсов, таких как приложения, данные, лазерные принтеры и модемы. Сети отделов обычно не разделяются на подсети. Сети кампусов - соединяют несколько сетей отделов внутри отдельного здания или внутри одной территории предприятия. Эти сети являются все еще локальными сетями, хотя и могут покрывать территорию в несколько квадратных километров. Сервисы такой сети включают взаимодействие между сетями отделов, доступ к базам данных предприятия, доступ к факс-серверам, высокоскоростным модемам и высокоскоростным принтерам. Сети отделов или рабочих групп используются группой людей, объединенных решением общей задачи, такой, например, как бухгалтерский учет или маркетинг. Главной целью сетей отделов является разделение ресурсов, таких как приложения, данные, лазерные принтеры и, возможно, низкоскоростные модемы. Обычно сети отделов имеют один или два файловых сервера и не более чем 30 пользователей. Сети отделов, как правило, не разделяются мостами на подсети (сегменты). Даже когда сети отделов соединены в корпоративную сеть, большая часть трафика локализуется в сети отдела, потому что именно в ней выполняется большая часть работы. Как правило, пользователи в 80% случаев обращаются к локальным ресурсам, а в 20% случаев - к удаленным ресурсам. Сети рабочих групп и отделов обычно создаются на основе какой либо одной сетевой технологии - Ethernet, Token Ring, или, если в рабочей группе происходит обмен большими объемами информации (например, мультимедийными файлами), то высокоскоростные протоколы, такие как FDDI, Fast Ethernet или 100VG-AnyLAN. 6 Такая сеть обычно использует одну или максимум две сетевые ОС. Чаще всего это сеть с выделенным сервером NetWare 3.x или Windows NT, или же одноранговая сеть, например сеть Windows for Workgroups. Все пользователи рабочей группы или отдела пользуются СУБД одного типа, чаще всего настольными СУБД типа dBase, Paradox или FoxPro, пользующимися файловым сервером для хранения разделяемых данных. Сети отделов не требуют сложного управления, так как решаемые на этом уровне задачи поддержания сети относительно просты. В функции администратора входит добавление новых пользователей, устранение простых отказов, инсталляцию новых узлов и установку новых версий программного обеспечения. Сложные задачи, такие как установка принципиально нового программного обеспечения, выполняются консультантами или представителями фирм- поставщиков. Средства управления сетей отделов хорошо отработаны и разнообразны, также, как и сами сети отделов, уже давно применяющиеся и достаточно отлаженные. Такой сетью может управлять сотрудник, посвящающий обязанностям администратора только часть своего времени. В большинстве случаев администратор сети отдела не имеет специальной подготовки, но чаще всего он является тем человеком в отделе, который лучше всех разбирается в компьютерах и само- собой получается так, что он занимается администрированием сети. В нашей стране большинство сетей относится именно к этому типу.Основными признаками сети рабочей группы или отдела являются таким образом, однородность и небольшой масштаб. Пользователи и администраторы сетей отделов вскоре осознают, что они могут улучшить эффективность своей работы путем получения доступа к информации других отделов своего предприятия. Если сотрудник, занимающийся продажами, может получить доступ к характеристикам конкретного продукта и включить их в презентацию, то эта информация будет более свежей и будет оказывать большее влияние на покупателей. Если отдел маркетинга может получить доступ к характеристикам продукта, который еще только разрабатывается инженерным отделом, то он может быстро подготовить маркетинговые материалы сразу же после окончания разработки. Итак, следующим шагом в эволюции сетей является объединение локальных сетей нескольких отделов в единую сеть здания или группы зданий. Такие сети называют сетями кампусов. Сети кампусов могут простираться на несколько километров, но при этом глобальные соединения не требуются. Сети кампусов имеют позвоночник (backbone) или главную сеть, и подсети, подобные ребрам. Для повышения производительности предприятия иногда используют маршрутизаторы, однако чаще подсети присоединяются к позвоночнику с помощью мостов или быстродействующих многопортовых мостов нового поколения - коммутирующих концентраторов (switching hubs). В сети кампуса в каждом отделе осуществляется администрирование своими серверами, но сотрудники отдела получают доступ к некоторым файлам и ресурсам сетей других отделов. Услуги, предоставляемые сетями кампусов, не ограничиваются простым разделением файлов и принтеров, а часто включают доступ и к серверам других типов, например, к факс-серверам и к серверам высокоскоростных модемов. Важным сервисом, предоставляемым сетями кампусов, стал доступ к корпоративным базам данных, независимо от того, располагаются ли они на серверах баз данных или на миникомпьютерах. Именно на уровне сети кампуса начинаются проблемы интеграции. В общем случае, отделы уже выбрали для себя компьютеры и приложения (а, следовательно, и сеть), которые подходят им наилучшим образом. Однако, то, что подходит отделу продаж, может не подойти, например, отделу разработчиков. Типы компьютеров, сетевых операционных систем, сетевого аппаратного обеспечения могут отличаться в каждом отделе. Например, инженерный отдел может использовать операционную систему UNIX и сетевое оборудование Ethernet, отдел продаж может использовать операционные среды DOS/Novell и оборудование Token Ring. Очень часто сеть кампуса соединяет разнородные компьютерные системы, в то время как сети отделов используют однотипные компьютеры. Часто сети кампусов оказываются соединенными случайным образом. Например, два отдела, которые работают вместе, могут соединить свои компьютерные системы, а уже затем к ним захочет присоединиться третий отдел. Отсюда вытекают сложности управления сетями кампусов. Администраторы должны быть в этом случае более квалифицированными, их нужно специально обучать. В случае сбоев и отказов администратору уже недостаточно проверить надежность соединения разъема. Нужны более изощренные средства оперативного управления сетью. Сеть кампуса содержит в себе многие признаки корпоративной сети - ей не хватает только масштабности и наличия глобальных связей. Корпоративная сеть - это объединения сетей нескольких кампусов, а сеть кампуса - это объединение сетей рабочих групп и отделов. Чем больше количество объединяемых сетей, тем более ярко выражены новые качественные признаки. В результате, многие существующие методы и подходы к решению традиционных задач сетей меньших масштабов для корпоративной сети оказались непригодными. На первый план вышли такие задачи и проблемы, которые в сетях рабочих групп, отделов и даже кампусов либо имели второстепенное значение, либо вообще не проявлялись. Например, простейшая для небольшой сети задача ведения учетной информации о пользователях выросла в сложную проблему для сети масштаба предприятия. Использование глобальных связей заставило специалистов по локальным сетям выйти в новый для них мир телекоммуникаций. Особое значение приобрели задачи преодоления гетерогенности - в сети появились многочисленные шлюзы, обеспечивающие согласованную работу различных ОС и сетевых системных приложений. Для обеспечения совместной работы в сети различных коммуникационных протоколов стали широко использоваться многопротокольные маршрутизаторы и транслирующие мосты. Расширился и круг услуг, предоставляемых конечному пользователю: кроме традиционных сервисов локальных сетей - разделения файлов и принтеров - в джентльменский набор сервисов корпоративной сети обычно входят почтовая служба, средства коллективной работы, поддержка удаленных пользователей, факс-сервис, обработка голосовых сообщений, организация видеоконференций и пр. и пр. Важное значение приобретает время реакции приложений в корпоративной сети - при динамичном рынке для успешной борьбы с конкурентами решения необходимо принимать в реальном масштабе времени, что требует соответствующей организации корпоративной сети и ее приложений, в том числе СУБД, способной оперативно отрабатывать 7 запросы к данным (поддержка режима On Line Transaction Processing, OLTP). В то же время в большой корпоративной сети обеспечить хорошее время реакции особенно сложно - этому мешает высокая интенсивность потока запросов, создаваемых сотнями и тысячами сотрудников корпорации, необходимость производить поиск данных в базах колоссальных размеров, невысокая скорость глобальных линий связи между отделениями корпорации, замедление скорости взаимодействия в шлюзах, согласующих неоднородные компоненты различных подсетей. В корпоративных системах предыдущих поколений с таким положением вещей мирились - особенно крупные базы данных хранились централизованно на мейнфреймах и обеспечивали доступ к данным в пакетном режиме, не дающем быстрой реакции на запрос. Теперь же требования работы в реальном времени стали для корпораций насущной необходимостью и одним из основных требований, предъявляемых к корпоративным сетям и корпоративным приложениям. Корпоративные сети состоят из продуктов, часть из которых можно назвать корпоративными. Понятие "корпоративности" продукта включает в себя несколько аспектов, среди которых важнейшими являются: масштабируемость, то есть способность одинаково хорошо работать в большом диапазоне различных количественных характеристик сети, совместимость с другими продуктами, то есть способность работать в сложной гетерогенной среде интерсети в режиме plug-and-play. Очевидно, в корпоративной сети могут использоваться не только продукты класса корпоративных, но и продукты уровня отделов и рабочих групп. Корпоративные продукты используются на магистрали сети, там, где они организуют разделение ресурсов между большим количеством пользователей, в пределе - между всеми пользователями корпорации. Продукты же рабочих групп предоставляют свои ресурсы в основном только членам своей рабочей группы, поэтому их производительность, надежность и другие свойства могут быть гораздо более скромными, чем у корпоративных продуктов. Поэтому в одной и той же сети успешно справляются со своими обязанностями и СУБД Access компании Micosoft, работающая на 486-х персоналках и СУБД Oracle, работающая на суперсерверах компаний Digital, HewlettPackard или Tricord. Access обеспечивает, например, разделение данных только для 12 сотрудников небольшого вспомогательного отдела, а Oracle предоставляет доступ к жизненно важной для корпорации информации (о выпускаемых ею продуктах, объемах продаж, производственных планах и т.п.) для всех сотрудников корпорации, в том и для упомянутых сотрудников вспомогательного отдела. Oracle может выполнить эту задачу, так как является корпоративным продуктом, а Access с ней бы не справился, так как это продукт уровня рабочей группы, он и не разрабатывался для поддержки большого числа пользователей и больших массивов данных. Соответственно возможностям различаются и цены корпоративных продуктов и продуктов рабочих групп. Корпоративные сети хорошо справляются со своими обязанностями не только из-за того, что включают корпоративные аппаратные и программные продукты, но и за счет особой организации и наличия специфических компонент, отсутствующих в небольшой сети. В рамках одного доклада трудно рассмотреть все особенности корпоративных сетей во всех аспектах, поэтому ограничимся рассмотрением некоторых специфических особенностей только некоторых служб и подсистем корпоративной сети. Подобно большой организации, корпоративная сеть нуждается в централизованном хранении как можно более полной справочной информации о самой себе (начиная с данных о пользователях, серверах, рабочих станциях и кончая данными о кабельной системе). Естественно организовать эту информацию в виде базы данных специального системного назначения. Данные из этой базы могут быть востребованы многими сетевыми системными приложениями, в первую очередь системами управления и администрирования. Кроме этого, такая база полезна при организации электронной почты, систем коллективной работы, службы безопасности, службы инвентаризации программного и аппаратного обеспечения сети, да и для практически любого крупного бизнес- приложения, в том числе и СУБД. Чем больше возможностей по хранению данных о элементах сети предоставляет справочная служба сетевой операционной системы, тем меньше потребности в отдельной системе администрирования СУБД, хотя пока потребность в последней сохраняется, и в одной корпоративной сети одновременно работает несколько администраторов - каждый из них администрирует свой слой сети - коммуникационное оборудование, серверы, операционные системы, базы данных и т.п. База данных, хранящая справочную информацию, предоставляет все то же многообразие возможностей и порождает все то же множество проблем, что и любая другая крупная база данных. Она позволяет осуществлять различные операции поиска, сортировки, модификации и т.п., что очень сильно облегчает жизнь как администраторам, так и пользователям. Но за эти удобства приходится расплачиваться решением проблем распределенности, репликации и синхронизации. В идеале сетевая справочная информация должна быть реализована в виде единой базы данных, а не представлять собой набор баз данных, специализирующихся на хранении информации того или иного вида, как это часто бывает в реальных операционных системах. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая используется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение низкоуровневых адресов: WINS - устанавливает соответствие Netbios- имен IP-адресам, справочник DNS - сервер имен домена - оказывается полезным при подключении NT-сети к Internet, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Ближе к идеалу находятся справочные службы, поставляемые фирмой Banyan (продукт Streettalk III) и фирмой Novell (NetWare Directory Services), предлагающие единый справочник для всех сетевых приложений. Справочная служба Streettalk уже давно выпускается компанией Banyan и является наиболее отработанным продуктом этого типа. Многие третьи фирмы купили у компании Banyan лицензию и используют службу Streettalk в своих системах. 8 Наличие единой справочной службы для сетевой операционной системы - один из важнейших признаков ее корпоративности. Важным свойством любого корпоративного приложения является поддержка такой справочной службы, то есть возможность пользоваться имеющимися в ней данными о пользователях, серверах и принтерах и не заводить своих собственных дублирующих справочников. В этом случае администратор имеет дело с одним хранилищем и одним представлением пользователей и ресурсов системы, и ему не приходится заводить одного и того же пользователя в нескольких справочниках - например, операционной системы, СУБД и почты, что неминуемо приводит к путанице и головной боли. Другим характерным примером специфики корпоративных сетей является подход к построению и поддержке распределенных приложений. Сетевые распределенные приложения строятся, как известно, в модели клиент-сервер. При этом, в небольших сетях наибольшее распространение получила двухзвенная схема этой модели: на сервере выполняется часть приложения, связанная с выполнением запросов к базе данных и к файловому сервису, а на клиентских машинах - часть, реализующая логику обработки данных приложения, а также организующая интерфейс с пользователем. Большинство современных корпоративных систем управления базами данных представляют собой классический пример двухзвенной модели клиент-сервер: клиентская часть генерирует запросы на поиск данных в некоторой стандартной форме, чаще всего на языке SQL, и реализует логику обработки данных, а СУБД отрабатывает получаемых от клиентов запросы, осуществляя поиск данных в своих таблицах. Именно этот вариант модели клиент-сервер часто считается единственно возможным, а файловому серверу отказывают в титуле "клиент-сервер", хотя на самом деле здесь есть и клиент, и сервер, просто распределение функций между ними иное - сервер выполняет централизованное хранение и поиск файлов, а клиент - все остальное. Закрепление титула "клиент-сервер" за СУБД, выполняющей на сервере функции поиска записей, имеет основание - при этом резко сокращается трафик между клиентскими и серверными компьютерами, а также уменьшаются требования к вычислительной мощности клиентских компьютеров, правда, только для приложений с простой логикой обработки данных. Однако, в корпоративных сетях обязательно имеются и сложные приложения, требующие для реализации логической обработки данных большой вычислительной мощности. Для них более подходящей является многозвенная схема, позволяющая разделить приложение на большее число частей. Например, приложение будет выполняться более эффективно, если освободить файл-сервер от выполнения запросов к базе данных и перенести СУБД на отдельный, более мощный компьютер. Из этих же соображений часто оказывается целесообразным перенести обработку логики приложения с персональных компьютеров также на отдельный компьютер большой вычислительной мощности - сервер приложений, так как вычислительная часть общих для корпорации программных систем может быть слишком емкой и неподъемной для рабочих станций клиентов. Сервер приложений должен базироваться на мощной аппаратной платформе (мультипроцессорные системы, часто на базе RISC-процессоров, специализированные кластерные архитектуры). ОС сервера приложений должна обеспечивать высокую производительность вычислений, а значит поддерживать многонитевую обработку, вытесняющую многозадачность, мультипроцессирование, виртуальную память и наиболее популярные прикладные среды (UNIX, Windows, MS-DOS, OS/2). В этом отношении сетевую ОС NetWare трудно отнести к корпоративным продуктам, так как в ней отсутствуют почти все требования, предъявляемые к серверу приложений. В то же время хорошая поддержка универсальных приложений в Windows NT собственно и позволяет ей претендовать на место в мире корпоративных продуктов. При построении распределенных приложений важным является способ взаимодействия частей - синхронный или асинхронный. Синхронный способ, при котором часть приложения, выдавшая запрос, блокируется на время его выполнения, а серверная часть, получив запрос, должна немедленно заняться его выполнением, мало подходит для корпоративных приложений. Так как из-за больших расстояний (нередко с включением глобальных связей) время выполнения запроса может оказаться слишком большим, то клиентская часть приложения может быть приостановлена на долгое время, с другой стороны, большая интенсивность и случайный характер потока запросов может дезорганизовать работу сервера. Поэтому корпоративные приложения эффективнее строить с применением асинхронной связи между отдельными частями. В этом случае необходимо иметь дополнительную службу (относящуюся к так называемому классу middleware), которая принимала бы запросы от клиентской части приложения, вела бы очередь таких запросов (желательно на диске для повышения отказоустойчивости) и планировала бы загрузку сервера. Асинхронный способ взаимодействия предъявляет менее жесткие требования к устойчивости физической связи между клиентом и сервером, что особенно важно для коммутируемых глобальных каналов, которые в общем случае всегда могут разделять части приложений в корпоративной сети. Примерами продуктов, которые поддерживают асинхронную передачу сообщений между клиентами и серверами, являются системы DECmessage Q от Digital Equipment, Message Express от Momentum Software и Copernicus от New Paradigm Software. В корпоративных сетях для связи клиентских и серверных частей приложений кроме используются и ряд других средств, относящихся к классу middleware, а не только упомянутые средства асинхронной обработки сообщений (message-oriented midleware, MOM). Широко используемые в сетевых операционных системах и сетевых утилитах средства удаленного вызова процедур RPC также относятся к классу middleware. Кроме того, в этот класс входят мониторы обработки транзакций (transaction processing monitors, TP), осуществляющие прием потока запросов транзакций от клиентов и осуществляют балансировку этих потоков при передаче их на серверы баз данных, постановку их в очередь, архивацию и восстановление после сбоев. Перспективным, но пока еще не нашедшими практического воплощения являются средства брокеров запроса объектов (object request broker, ORB), которые работают подобно средствам асинхронной обработки запросов, но только с привлечением концепции объектно-ориентированной технологии. 9 Использование средств класса middleware в корпоративных сетях связано с необходимостью упорядочить хаотический поток запросов от огромного числа клиентов к большому количеству серверов, создать некоторые регулирующие эти потоки механизмы, подобно регулировщикам движения на оживленных городских магистралях. Важную роль в обеспечении необходимых свойств корпоративной сети играет структура транспортной системы и ее согласованность. Транспортная система корпоративной сети должна обеспечивать: передачу пакетов через разнородные сети с совершенно различными принципами организации транспортных операций, многоуровневое иерархическое построение (наличие магистрали сети, к которой присоединяются транспортные артерии нижних уровней), хорошую структуризацию за счет разделения сети на подсети небольшого размера с регулярными связями, поддержку быстрых протоколов, таких как FDDI, Fast Ethernet и 100VG- AnyLAN, для устранения узких мест. Объединение транспортных потоков отдельных сетей в корпоративной сети происходит за счет использования общего для всех сетей магистрального протокола сетевого уровня модели OSI, который правильнее было бы назвать межсетевым. Введение сетевого уровня позволяет соединять сети, в которых работают различные протоколы канального уровня, при этом при передаче пакета из сети в сеть пакет сетевого уровня освобождается от оболочки канального уровня одного вида и заменяется оболочкой канального уровня другого вида. Информацией, на основе которой делается эта замена, является номер сети и номер узла в сети, которая не меняется при переходе пакета из сети в сеть. К сожалению, существует большого количество протоколов сетевого уровня, равно как и протоколов канального уровня. Все они решают одну задачу, но несколько разными способами, поэтому сетевым интеграторам и администраторам приходится в больших сетях иметь дело одновременно с несколькими сетевыми протоколами. Очень популярными протоколами сетевого уровня, использующимся для объединения сетей, входящих в корпоративную сеть, является протоколы IP и Novell IPX. Протоколы сетевого уровня не являются протоколами только локальных сетей. С их помощью можно создавать интерсети, включающие как локальные, так как и глобальные сети. В каждой из этих сетей действуют свои правила внутренней доставки пакетов, а их совместная работа становится возможной благодаря наличию общего протокола сетевого уровня. В последнее время роль объединяющего протокола сетевого уровня все чаще выполняет сетевой протокол IP, ведущий свое происхождение от сети Internet и операционной системы Unix. Для этого протокола существуют стандарты его использования над всеми основными протоколами канального уровня локальных сетей, таких как Ethernet, Token Ring, FDDI, Fast Ethernet и 100VG- AnyLAN, а также над протоколами глобальных сетей - X.25, frame relay, PPP. Уже имеется спецификация для использования IP над протоколами таких перспективных сетей как АТМ - так называемая спецификацией Classical IP. Важным достоинством IP является его высокая эффективность при работе на относительно низкоскоростных глобальных линиях связей. Протокол IPX фирмы Novell был изначально разработан для объединения небольшого числа локальных сетей, поэтому он расточительно использует полосу пропускания линий связи и не так хорошо работает на магистралях корпоративных сетей, как IP, хотя Novell в последнее время предпринимает немало усилий для улучшения своего стека коммуникационных протоколов. Структуризация транспортной подсистемы корпоративной сети и ее иерархическое многоуровневое построение это взаимосвязанные понятия. Структуризация - это деление крупной системы на отдельные взаимосвязанные подсистемы, а иерархическое многоуровневое дерево - это наиболее часто используемый тип структурирования транспортных связей в корпоративной сети. Сеть, предоставленная самой себе, имеет свойство разрастаться хаотически. Такая стихийно создаваемая сеть плохо управляема и подвержена частым сбоям и отказам. Проблемы ранних сетей Ethernet, которые росли таким образом, хорошо известны: отсутствие технического обоснования проводимых изменений, их неполная документированность приводили к слишком большим затратам сил и времени на поиск причин возникающих отказов и сбоев. Масштабные же системы нужно особенно тщательно планировать и структурировать, выбирая для каждой сети соответствующие типы кабельных систем, протоколы и устройства соединения сетей - повторители, мосты, маршрутизаторы и шлюзы. Целью вычислительной сети является предоставление пользователям доступа ко всем ресурсам сети. Но не всем пользователям нужен постоянный доступ ко всем ресурсам. В большинстве случаев им нужен доступ к ресурсам сети их отдела, и только изредка - доступ к удаленным ресурсам. Поэтому сеть предприятия часто реализуется как совокупность подсетей. Большинство сетей разрабатывается на основе структуры с позвоночником, к которому через мосты и маршрутизаторы присоединяются подсети. Эти подсети обслуживают различные отделы. Подсети могут делиться и далее на сегменты для обслуживания рабочих групп. Деление сети на подсети уменьшает общий трафик, повышает гибкость, увеличивает защиту данных и облегчает управление сетью. Сегментация уменьшает общий сетевой трафик. При достижении трафиком границы 30%-40% от полной пропускной способности, пользователи сети Ethernet начинают чувствовать значительное уменьшение производительности сети из-за постоянных коллизий. В сетях Token Ring также при достижении трафиком границы 20%-30% от предельной пропускной способности, конкуренция за доступ к кольцу начинает приводить к заметным задержкам. Пользователи взаимодействуют в основном с пользователями и ресурсами своего отдела. Здесь применимо правило 80/20 - около 80% трафика является локальным, а 20% идет в удаленные сегменты. Путем сегментации сети на подсети отделов можно значительно уменьшить трафик, проходящий через всю сеть, и тем самым повысить производительность сети. 10 Подсети увеличивают гибкость сети. При построении сети как совокупности подсетей каждая подсеть может быть адаптирована к специфическим потребностям рабочей группы или отдела. При этом эти подсети могут взаимодействовать. Подсети повышают безопасность данных. Помещая пользователей на различные физические сегменты можно запретить доступ к некоторым ресурсам. Это уменьшает частоту появления пользовательских ошибок и внутреннего разрушения данных. С помощью сегментации можно обеспечить, например, циркуляцию трафика только в пределах финансового отдела. Устанавливая различные логические фильтры на мосты и маршрутизаторы, можно контролировать доступ к ресурсам. Мосты обеспечивают минимум средств управления доступом, маршрутизаторы обладают большими возможностями. Подсети упрощают управление сетью. Побочным эффектом уменьшения уровня трафика и повышения безопасности данных является упрощение управляемости сети. Проблемы локализуются внутри сегмента. Как и в случае структурированной кабельной системы проблемы одной подсети не оказывают влияния на другие подсети. Подсети образуют логические домены управления сетью. Сети должны проектироваться на двух уровнях: физическом и логическом. Логическое проектирование определяет места расположения ресурсов, приложений и способы доступа пользователей к ресурсам. Физическое проектирование определяет точное задание типов устройств (марку и модель), мест прокладки кабеля, типов глобальных сервисов (протокол, тип передающей среды, типы модемов и т.д.). Соотношение между логическим и физическим уровнями проектирования в некотором смысле аналогично соотношению между функциональной и принципиальной электрическими схемами. Например, использование повторителя создает в сетях стандартов 10Base-T, 10Base-F и Token Ring физические сегменты - отрезки кабеля, соединяющие по схеме "точка-точка" станции. Однако логически эти отрезки представляют по прежнему один сегмент, моноканал в случае Ethernet'а и логическое кольцо для сетей Token Ring. Применение же мостов, маршрутизаторов и шлюзов приводит к появлению логических сегментов, локализующих трафик внутри себя. Как уже было сказано выше, наиболее часто встречающейся структурой коммуникационных связей в корпоративной сети является многоуровневая иерархическая структура. В чистом виде такая структура часто используется на уровне сетей кампусов, когда в корне сети располагается мощный модульный корпоративный концентратор, выполняющий функции и маршрутизатора и моста и коммутатора по отношению к подключенным к нему сегментам сетей. Магистраль кампуса может в этом случае образовываться внутренней высокопроизводительной шиной корпоративного концентратора с пропускной способностью в несколько гигабит в секунду. Сети, подключаемые к центральному концентратору, образуются с помощью концентраторов масштаба отделов и рабочих групп. Для объединения сетей кампусов глобальными связями используются, как правило более нерегулярные структуры например, ячеистая структура, отражающая географию отделений корпорации и интенсивность трафика между ними. Но и здесь часто выделяется центральная, наиболее скоростная сеть, которая служит магистралью всей корпоративной сети, а сети остальных отделений присоединяются к ней менее скоростными линиями. Особую важность приобретают для корпоративной сети вопросы безопасности данных. С одной стороны, в крупномасштабной сети объективно существует больше возможностей для несанкционированного доступа - из-за децентрализации данных и большой распределенности "законных" точек доступа, из-за большого числа пользователей, благонадежность которых трудно установить, а также из-за большого числа возможных точек несанкционированного подключения к сети. С другой стороны, корпоративные бизнес-приложения работают с данными, которые имеют жизненно важное значение для успешной работы корпорации в целом. И для защиты таких данных в корпоративных сетях применяется весь спектр имеющихся средств защиты - избирательные или мандатные права доступа, сложные процедуры аутентификации пользователей, программная и аппаратная шифрация, локализация трафика и т.п. Те же причины обуславливают и повышенные требования к высокой готовности и отказоустойчивости системы. Основные средства достижения этих свойств - избыточность аппаратуры и данных на всех уровнях: кабельных связей, источников питания, процессоров, компьютеров, маршрутизаторов, репликация баз данных, кластеризация вычислений. Как можно заметить, каждое из этих свойств корпоративной сети может быть важно и для сети небольшого масштаба. Например, можно найти такую область применения, для которой и для небольшой локальной сети очень важны требования безопасности данных и высокой готовности. Но для небольших сетей эти требования могут быть важными или не очень, в зависимости от характера выполняемых ею задач. Для корпоративных же сетей выполнение этих требований обязательно всегда. Создать крупномасштабную гетерогенную среду для проверки свойств корпоративности не только сложно, но и накладно. Поэтому существуют специальные лаборатории, которые занимаются тестированием и сертификацией продуктов на предмет пригодности их для работы в корпоративной сети. В частности, такие услуги и потребителям и производителям оказывает американская фирма The Tolly Group, которая с помощью специального оборудования может создавать сложную гетерогенную среду, соответствующую требованиям заказчика, и испытывать в ней новое оборудование или программную систему. Клиентами The Tolly Group являются и компании-призводители, заинтересованные в получении лого "Enterprise Ready", причем не только новички, завоевывающие рынок, но и такие гранды как Cisco, IBM, Motorola-Codex, 3Com, Wellfleet и многие другие. Иногда бывает полезно подняться над деревьями и посмотреть на лес с общих позиций. Поскольку корпоративные сети - это частный случай больших систем, то к их организации применимы те общие методы и принципы, которые были сформулированы в теории больших систем: деление системы на подсистемы, многоуровневое иерархическое построение, сочетающее принципы централизации и децентрализации при сохранении единства системы, принцип необходимого разнообразия, говорящий о том, что сложная по функциям система не может иметь простую структуру и однотипные элементы. Если внимательно присмотреться ко всем службам и подсистемам корпоративной сети (например, 11 к описанным в этой статье), то легко заметить использование в них всех этих общих принципов и подходов. Справедливо и обратное: если эти признаки отсутствуют, то вряд ли изучаемый предмет можно отнести к классу корпоративных. 4. Методология проектирования корпоративных систем 4.1. С.Д.Паронджанов, Компания Аргуссофт. Методология создания корпоративных ИС 4.1.1. Введение Цель методологии создания информационных систем (ИС) заключается в организации процесса построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решение которые должна обеспечивать методология создания корпоративных ИС (вместе с соответствующим набором инструментальных средств) являются следующие задачи: обеспечивать создание корпоративных ИС, отвечающих предъявляемым к ним требованиям по автоматизации деловых процессов и отвечающих целям и задачам организации; гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета; поддерживать удобную дисциплину сопровождения, модификации и наращивания системы, чтобы ИС могла отвечать быстро изменяющимся требованиям работы компании; обеспечивать создание корпоративных ИС, отвечающих требованиям открытости, переносимости и масштабируемости; обеспечивать использование в разрабатываемой ИС задела в области информационных технологий, существующего в организации (ПО, баз данных, средств вычислительной техники, телекоммуникаций, технологий). Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и точного описания этого процесса и применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации. В 90-ые годы в мире произошли кардинальные изменения как на рынках товаров и услуг, так и в информационных технологиях (ИТ). Современные корпоративные ИС становятся основным фактором успешной работы корпораций на рынке. Для выполнения своего назначения они должны решать значительно более сложные задачи, чем раньше. В соответствии с высокой динамикой изменения ситуации на рынке становятся очень жесткими требования как к функциям, выполняемым ИС, так и к процессу создания ИС. Резко ужесточились требования ко времени разработки отдельных приложений и системы в целом. Появилась необходимость в изменении требований в процессе разработки с тем, чтобы система отвечала требованиям организации на момент конца разработки, а не на момент начала. Достижения в области ИТ позволили преодолеть принципиальные технические и программно- инструментальные проблемы создания корпоративных ИС. Появились современные аппаратно- программные платформы архитектуры клиент-сервер, средства для проведения распределенных параллельных вычислений и управления вычислительным процессом в гетерогенных сетях, методы и средства разработки программ и баз данных, обеспечивающие возможности создания открытых, переносимых, масштабируемых приложений и баз данных, возможности быстрой разработки и т.д. (Об этом свидетельствуют и многочисленные публикации в журнале СУБД.) Практика показывает, что для успешного создания сложных системы, к которым относятся корпоративные ИС, недостаточно иметь только современные платформы и средства, а прежние методологии создания ИС, созданные в 70 80-е годы и ориентированные на мэйнфрэймы и однородную среду, устарели и оказались непригодны в новых условиях. Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994г, неудачными оказались более 30% проектов общей стоимостью более чем 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета. Анализ показал, что большинство неудач было связано с отсутствием или неправильным применением методологии проектирования ИС. Мощные импульсы развитию методологий дало появление двух принципиально новых подходов к созданию корпоративных ИС: информационного инжиниринга и реинжиниринга бизнес-процессов (BPR). Предлагаемые в них методы позволили описывать, анализировать и проектировать структуру и деятельность корпораций подобно техническим системам. Каждый из этих подходов породил свой класс методологий, обладающих общими характеристиками. В настоящее время продолжается активный процесс развития и совершенствования методологий создания корпоративных ИС. В этой области работают многие ведущие специалисты во всем мире. В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной основе разрабатывает проекты стандартов, методы и методологию быстрого создания приложений (ИС). В консорциуме участвуют и российские компании. Таким образом, с появлением инструментальных средств нового поколения роль методологии при создании ИС не только не снизилась, - она возросла. По данным опроса, проведенного в 1994 г, большинство американских специалистов считают методологию, наряду с архитектурой клиент- сервер, двумя наиболее важными факторами для успешной разработки своих ИС. Сегодня в нашей стране недостаточно оценивается роль и значение методологии (в отличии от средств проектирования прикладного программного обеспечения). В предстоящие годы задача создания корпоративных ИС на базе современных методологий встанет перед многими отечественными организациями. (При этом заметим, что на Западе ме- 12 тодологии по-прежнему считают стратегической продукцией. Многие из них представляют собой ноу-хау и по сей день.) 4.1.2. Основные составляющие методологии Целью работы является описание методологии, обеспечивающей решение перечисленных выше основных задач. Предлагаемая методология создания корпоративных ИС состоит из двух основных взаимосвязанных частей: методологии анализа ИС, включающей описание деятельности организации и формирование требований к ИС на основе бизнеспроцессов, и методологии проектирования от данных, предназначенной для проектирования и быстрой разработки программного и информационного обеспечения ИС. Предлагаемая методология строится на основе итерационной спиральной модели жизненного цикла ИС. Принципиальной особенностью этой методологии является то, что охватывая все этапы жизненного цикла ИС, она делает основной упор на поддержку начальных этапов создания корпоративных ИС, главной задачей которых является формирование требований к ИС, точно отвечающих целям и задачам организации. В соответствии с подходом информационного инжиниринга, который Джеймс Мартин определяет как "применение взаимосвязанного набора формальных технологий (моделей) для планирования, анализа, проектирования и создания информационных систем на уровне корпораций или отдельных ее частей ...", процесс создания ИС строится как процесс построения и развития моделей. Реализация методологии базируется на применении комплекса согласованных между собой инструментальных средств, обеспечивающих высокий уровень автоматизации всех процессов, выполняемых в соответствии с методологией на протяжении ЖЦ ИС. Таким образом, фундамент предлагаемой методологии составляют: итерационная спиральная модель жизненного цикла ИС; комплекс развивающихся систем согласованных моделей; методология анализа ИС на основе бизнес-процессов; методология проектирования от данных; комплекс согласованных инструментальных средств 4.1.3. Итерационная спиральная модель жизненного цикла ИС. Методология описывает процесс создания и сопровождения информационных систем в виде жизненного цикла (ЖЦ) ИС, представляя его в виде последовательности стадий, каждая из которых разбита на этапы, и выполняемых на них процессов. Для каждого этапа определяются последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом. Жизненный цикл ИС, определяемый методологией, приведен на рис.1. Он включает стадии анализа, проектирования, разработки, тестирования и интеграции, внедрения, сопровождения и развития ИС. На рисунке приведены также перечень основных этапов для каждой стадии ЖЦ и процессы, выполняемые на протяжении всего ЖЦ - процессы управления и интегральные процессы. Эти процессы в той или иной степени присутствуют на каждом из этапов. Процессы организации и управления проектом: планирование, управление, контроль ПроектироваИнтеграция и теСопровожАнализ Разработка Внедрение ние стирование дение *Интеграция и * Обследование *Концептуальн тестирование при*Обучение *Регистраци и создание моделей *Разработка, ое проектирование ложений в составе пользователей я, диагностика деятельности оргапрототипирование *Разработка архисистемы *Развертывание и локализация низации и тестирование тектуры ИС *Оптимизация при- системы на месте ошибок *Анализ (моделей) приложений *Проектирование ложений и баз дан- эксплуатации *Внесение изсуществующих ИС *Разработка интеобщей модели ных *Инсталляция менений и те*Анализ моделей и грационных тестов данных *Подготовка эксбаз данных стирование формирование тре*Разработка поль*Формирование плуатационной до- *Эксплуатация *Управление бований к ИС зовательской дотребований к прикументации *Проведение режимами ра*разработка плана кументации ложениям *Тестирование си- ПСИ боты ИС создания ИС стемы Интегральные процессы: управление конфигурацией, документирование, проверки, интеграция Рис. 1. Жизненный цикл ИС Процесс создания ИС представляет из себя процесс построения и последовательного преобразования согласованных моделей на всех этапах ЖЦ. Эти модели сохраняются и накапливаются в репозитории проекта. С помощью CASEсредств модели создаются, преобразуются и контролируются. Основными результатами на каждом этапе ЖЦ являются модели определяемых на данном этапе объектов (организации, требований к ИС, проекта ИС, требований к приложениям и т.д.). Характер выполняемых процессов и организация работ в представленной модели ЖЦ основаны на подходе информационного инжиниринга и отличаются от классической каскадной модели ЖЦ, несмотря на внешнюю схожесть. При традиционной обработке данных разработка велась строго последовательно. Требования ТЗ утверждались в начале раз- 13 работки, а их выполнение проверялось в конце. Переход от стадии к стадии, от этапа к этапу допускался только после полного выполнения всего перечня работ и получения всех запланированных результатов. ЖЦ ИС, предлагаемый в новой методологии определяется следующими особенностями. Современные средства CASE, 4GL, СУБД и др. предоставляют возможности быстрого проектирования, прототипирования, разработки и тестирования приложений и баз данных на основе построенных моделей. Методология предполагает активное участие заказчиков на всех этапах создания ИС, поскольку модели, создаваемые на каждом этапе, понятны и разработчику и заказчику. Эти особенности определяют возможности оперативного и быстрого пересмотра требований и разработанных решений на основе современных средств, возможности неравномерной, параллельной разработки различных частей проекта, возможности возврата на предыдущие этапы по отдельным частям проекта при необходимости внесения изменений. Методология предусматривает и версионный характер изменения проекта или его частей при поддержке CASEсредств. Все это определяет итерационный, спиральный характер предлагаемой модели жизненного цикла. 4.1.4. Комплекс развивающихся систем согласованных моделей Методология определяет процесс создания корпоративных информационных систем как процесс построения и последовательного развития систем согласованных моделей, начиная от системы моделей, описывающих деятельность организации, и заканчивая готовой информационной системой. Модели должны создаваться, преобразовываться и контролироваться с помощью соответствующих CASE-средств и сохраняться в репозитории. Отправной точкой процесса создания ИС являются модели бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Если построена компьютерная модель организации, описанная в терминах бизнес-процессов и бизнес-функций, то из этой модели может быть получено большинство важнейших требований к информационной системе. Это фундаментальное положение методологии позволяет абсолютно объективно подойти к выработке требований и проектированию информационной системы. Создается система моделей описания требований к ИС, которая затем преобразуется в систему моделей, описывающих проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция. На рис.2 представлен комплекс развивающихся систем согласованных моделей (КРССМ), который показывает состав и последовательность развития систем моделей, создаваемых в процессе построения ИС. Развитие и преобразования моделей происходит в соответствии со схемой преобразования моделей, представленной на рис.3, обеспечивающей полноту и согласованность на каждом уровне преобразования моделей, что обеспечивает корректное формирование и реализацию всех требований к ИС. Архитектурные рамки для развития систем согласованных моделей, определяемые схемой преобразования моделей, основаны на модели Закмана. 4.1.5. Методология анализа ИС на основе бизнес-процессов Целью начальных этапов создания ИС, выполняемых на стадии анализа, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации. Чтобы описать процесс создания ИС, отвечающей целям и задачам организации, нужно выяснить в чем заключаются эти цели и задачи. Нужно выяснить требования заказчиков к ИС и преобразовать их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации. Современные средства позволяют достаточно быстро создавать ИС по готовым требованиям. Но как отмечалось выше, очень часто оказывается, что эти системы не удовлетворяют заказчиков. Их приходится постоянно дорабатывать, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС. И это не случайность. Как правило, заказчики не могут правильно и точно сформулировать требования к ИС. Более того, они зачастую не могут точно определить основные цели и задачи своей организации. Задача разработчиков заключается в том, чтобы извлечь эту информацию из заказчиков. Проблема формирования требований к ИС остается до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении конечного результата. Предлагаемая методология определяет, какие виды данных должны собираться в организации в процессе обследования и какие модели строиться для того, чтобы сформировать требования к ИС. Основу деятельности любой организации составляют ее деловые процессы, или бизнес-процессы, которые определяются целями и задачами организации. Процессы обеспечивают реализацию всех видов деятельности организации, связанных с производством товаров и/или услуг, которые корпорация либо производит, либо продает и поставляет, либо делает все это в совокупности. Каждый бизнес-процесс характеризуется четко определенными во времени началом и концом, внешними интерфейсами, которые либо связывают его с другими бизнес - процессами внутри организации, либо описывают выход во внешнее окружение, последовательностью выполняемых работ и правилами их выполнения (бизнес -правилами). Для каждой работы, входящей в бизнес-процесс, определены временные характеристики, определяющие ее место в общей последовательности работ, условия инициации и время выполнения. В отличии от описания организации на основе иерархической функциональной структуры, которую невозможно объективно оценить, описание на основе процессов позволяет точно представить цели, характеристики (в том числе, динамические) и конечный результат каждого вида деятельности организации. 14 Исходя из того, что основные бизнес-процессы реализуют по своей природе цели и задачи организации, методология предлагает строить описание деятельности организации, как процесс создания и развития систем согласованных моделей, основанных на моделях бизнес-процессов. В процессе детализации моделей и их последующей интеграции должно обеспечиваться сохранение всех функциональных свойств, отражающих цели и задачи организации, и согласованности моделей. Такая согласованность обеспечивается методологией и поддерживающими ее современными CASEсредствами. В процессе описания организации и ее деятельности формируются три основных системы моделей организации: стратегическая, укрупненная и детальная. Все эти системы моделей, описывая основные аспекты организации и ее деятельности, базируются на бизнес-процессах. В систему моделей описания организации добавлена также дополнительная система моделей, для того чтобы можно было учесть аспекты, не связанные с бизнес-процессами, но необходимые при создании ИС. Стратегическая система моделей организации. Процесс создания и развития систем согласованных моделей, описывающих деятельность организации, начинается с построения стратегической системы моделей организации, которая описывает основные аспекты деятельности организации на стратегическом уровне. Главное назначение стратегической системы моделей заключается, во-первых, в определении основных целей и задач организации, и во-вторых, в формировании моделей бизнес-процессов, описывающих основные виды деятельности организации и реализующих ее стратегические цели и задачи. При построении моделей бизнес-процессов на стратегическом уровне не рассматривается иерархическая структура организации, описывающая "вертикальное" представление организации, и устанавливающая функциональные и административные границы между подразделениями. Бизнес -процессы определяют прохождение потоков работ независимо от иерархии и границ подразделений и организаций, которые их выполняют, и показывают взаимодействие, как внутренних, так и внешних (т.е. взаимодействующих с внешним окружением) бизнес-процессов. Модели, входящие в стратегическую систему моделей, строятся при обследовании организации путем опроса экспертов на уровне высшего руководящего персонала, определяющего стратегию организации, а также на базе основных документов организации. Эти модели хранятся в репозитории проекта. Все создаваемые далее модели организации строятся на базе построенных бизнес-процессов по результатам обследования деятельности организации, проводимого на уровне подразделений. Модели строятся с помощью CASE-средств, и сохраняются в репозитории проекта. Построение этих моделей допускает распараллеливание работ при проведении обследования и при построении моделей. Дальнейшее развитие систем согласованных моделей происходит на базе схемы преобразования моделей, представленной на рис.3, которая описывает развитие согласованных моделей по основным аспектам, определяющим деятельность организации (данные, функции, люди, сеть, время, правила). Каждая строка таблицы соответствует системе согласованных моделей данного уровня и раскрывается в виде частных моделей по каждой группе характеристик. Переход от строки к строке показывает развитие системы моделей в процессе описания организации, а правила перехода определяются методологией и обеспечивают полноту и согласованность при построении моделей. 15 уровень описания / группы характеристик - моделей функции список бизнесУкруппроцессов и ненная сибизнесстема мофункций орделей оргаганизации низации Детальная система моделей организации данные списки документов списки объектов люди сеть время правила (мотивация) Список целей и задач перечень организации структурных подструктурная мосписок ра- критерии и разделений и дель организации бот во времени правила вывнешних органиполнения заций бизнеспроцессов функциовременная информацилогическая мональные момодель выполонная модель структурные мо- дель сетей подраздели подразнения бизнесорганизации дели подразделений, делений организаделений: диапроцессов и (концептуальроли персонала ции и внешних граммы потобизнесная модель) связей ков данных функций Требования требовак данным; ния к функТребования к ретребования к структуры данСистема циям; диагламенту и интер- сетевой архитекных концептумоделей грамма потофейсу пользователей туре системы альная модель требований ков данных данных к ИУС Критерии выполнения бизнесфункций; бизнесправила Требования Требовак временным ния к реглахарактеристи- менту работы кам функции ИС Детализация проекта Функционирующая система функции данные Пользователи коммуникации зависимость Правила Рис. 3. Схема преобразования моделей Укрупненная система моделей организации. Основными задачами описания организации на уровне укрупненной системы моделей являются отображение основных бизнес-процессов, которые описаны на стратегическом уровне, исходя из основных целей и задач организации (без привязки к ее структуре), на реальную иерархически - функциональную структуру организации, а также выделение основных функций подразделений и уточнение состава и характеристик бизнес -процессов. На этом этапе проводится обследование подразделений, в результате которого выявляются выполняемые в них основные функции, их вход и выход. Эти функции распределяются по бизнес- процессам, проходящим через каждое подразделение. В результате формируются и уточняются общие списки бизнес-процессов и функций по подразделениям, списки входных и выходных документов и другие характеристики, и вся эта информация наполняет каждый бизнеспроцесс конкретным содержанием. Таким образом, бизнес-процессы становятся путеводителями через иерархически функциональную структуру организации, определяющими функциональные и информационные связи между различными подразделениями. В процессе отображения бизнес-процессов по уровням организационной иерархии формируется и уточняется общий список бизнес-процессов, и могут появиться новые бизнес-процессы. 16 Детальная система моделей организации. Главными целями создания детальной системы моделей является построение концептуальной модели данных и функциональной модели организации. Для достижения этих целей проводится детализация описания деятельности организации от уровня описания реализации общих бизнес- процессов в организации и списковых моделей в подразделениях до уровня детальных моделей подразделений, позволяющих выделить все функции подразделений, обрабатываемые документы, основные данные, описать регламент работы персонала и создать в итоге функциональную модель организации и концептуальную модель данных. Выявленные в процессе обследования подразделения функции распределяются по бизнес- процессам этого подразделения, наполняя их конкретными работами данного подразделения. При этом описания бизнес-процессов могут дополняться и уточняться. В моделях описываются и детализируются бизнес-процессы, функции, информационные потоки, входные и выходные документы, взаимодействие внутри организации и с внешними объектами, данные, бизнесправила, роли персонала и регламент, их взаимосвязи, временные и прочие характеристики. Описание деятельности организации с помощью бизнес-процессов и бизнес-правил позволяет определить где, когда и кем выполняется каждая функция, какие данные, информационные и функциональные взаимосвязи для этого нужны, и откуда эти данные поступают. Построенная системы моделей организации может использоваться для трех целей. Во-первых, построенные модели могут быть использованы для формирования требований к ИС. Во-вторых, система моделей может быть использована для анализа деятельности организации с целью ее улучшения, путем проведения инжиниринга или реинжиниринга организации в зависимости от результатов анализа. И, наконец, на основании анализа построенных систем моделей, а также существующих в организации ИС, формируется стратегический план создания, развертывания, сопровождения и развития информационной системы. Система моделей описания требований к ИС Главной целью формирования системы моделей описания требований к ИС является обеспечение корректного перехода от моделей описания организации к системе моделей ИС, описывающих конкретные компоненты проекта, такие как приложения, базы данных, общесистемное ПО, средства вычислительной техники и телекоммуникации, при котором обеспечивается отображение целей и задач организации (выраженных через ее бизнес-процессы, данные, функции и другие модели) в функции и компоненты ИС. Для перехода от системы моделей организации к системе моделей ИС необходимо сформировать систему моделей, описывающих требования к ИС и связать эти требования с проектируемыми компонентами. Система моделей, описывающих требования к ИС, формируется путем отображения системы моделей организации, построенных на этапе обследования. Отображение задается матрицей преобразования, определяемой схемой преобразования моделей. В результате итерационного уточнения формируются основные модели требований к ИС, отражающие цели и задачи организации и включающие требования к архитектуре ИС, к данным, к интерфейсу, к регламенту работы пользователей, к реализуемым функциям и к управлению системой. В системе моделей требований к ИС могут быть отражены также требования, связанные с необходимостью полной или частичной интеграции существующих информационных систем и/или баз данных в новую систему. По итогам анализа построенных моделей должен быть окончательно сформирован план создания, развертывания, сопровождения и развития информационной системы, соответствующий целям, задачам и стратегии развития организации. Из полного набора требований к ИС для дальнейшего анализа и проектирования мы выделим требования к программному и информационному обеспечению и к интерфейсу с пользователями, оставляя в стороне требования к архитектуре и средствам вычислительной техники и телекоммуникаций. 4.1.6. Методология проектирования от данных Поскольку данные составляют основу деятельности любой организации и являются наиболее стабильной ее составляющей (функции и структура организации меняются гораздо чаще), то при построении корпоративной ИС наиболее адекватным решаемым задачам является подход к проектированию, основанный на данных. Такой подход обеспечивает наилучшее архитектурное решение при разбиении системы на приложения, а также простоту и согласованность при интеграции приложений. В основу процессов проектирования и разработки ПО и ИО положены методология проектирования от данных DATARUN, которая была разработана в компании CSA (США) для проектирования и быстрой разработки программного и информационного обеспечения переносимых распределенных ИС в архитектуре клиентсервер. Эти возможности основаны на использовании современных инструментальных средств моделирования, быстрого прототипирования и разработки. Методология DATARUN основана на моделях. Она поддерживает принципы формирования и развития моделей, заложенные в КРССМ. Модель требований к ПО и ИО базируется на бизнес- процессах и формируется на основе системы моделей требований к ИС. Процесс проектирования основан на извлечении всех данных из моделей бизнес-процессов, построении и развитии моделей данных (концептуальной модели данных, модели архитектуры ИС, полной реляционной модели данных и т.д., вплоть до моделей, определяющих приложения). Эти модели взаимоувязаны и интегрированы друг с другом и определяют множество уровней спецификаций для каждого этапа разработки. В процессе проектирования модели данных развиваются от простой начальной версии в законченную спецификацию приложения, используемую для генерации. При этом полная реляционная модель данных может быть разделена на подмодели (подсхемы), представляющие разные части системы, которые могут быть распределены по сети в окружении клиент-сервер в соответствии с архитектурой ИС. 17 По нашему мнению методология DATARUN объединяет лучшие черты реляционного проектирования, объектноориентированной технологии и подхода RAD (быстрого создания приложений). В общем ЖЦ ИС методология DATARUN охватывает этапы ЖЦ формирования требований к ПО и ИО и все этапы стадий проектирования, разработки, интеграции и тестирования и внедрения системы (в части ПО и ИО). Дальнейшие шаги по созданию ИС, выполняемые на стадиях сопровождения и развития ИС, не раскрываются в данном докладе. Методология их выполнения базируется на тех же основных принципах, что и описанные методологии. Эти шаги продолжают описанный выше процесс развития систем моделей, представленных в комплексе развивающихся систем согласованных моделей. 4.1.7. Комплекс согласованных инструментальных средств Предлагаемая методология создания ИС поддерживается комплексом согласованных между собой инструментальных средств, который обеспечивает непрерывный цикл автоматизации процессов, выполняемых на всех этапах ЖЦ ИС.. Согласованность этих средств обеспечивается наличием интерфейсов для прямого взаимодействия и поддержкой общепринятых стандартов открытых систем. Комплекс средств такого рода позволяет строить модели, описывающие деятельность организации, формировать требования к ИС, быстро переходить от моделей требований к ИС к проекту приложений и баз данных. Он обеспечивает поддержку быстрой итеративной разработки приложений, их тестирование и интеграцию в систему. Заложенные в методологию и поддержанные этими инструментальными средствами принципы, основанные на использовании моделей и повторном использовании спецификаций, обеспечивают возможность быстрого внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития. Созданные на базе этого набора средств распределенные ИС (приложения и БД) могут быть реализованы как в двухзвенной, так и в трехзвенной архитектуре клиент-сервер. Этот же набор средств позволяет переносить приложения и базы данных на различные платформы без перепрограммирования. Приложения, созданные на базе этого набора средств, являются открытыми и масштабируемыми. В состав набора входят средства реинжиниринга, позволяющие автоматически восстанавливать модель существующей системы. В соответствии с проектом эта модель может быть использована для построения моделей новой системы. Методология и поддерживающий ее набор инструментальных средств обеспечивают полный контроль и гибкое управление ходом разработки, включая: поддержку коллективной разработки с возможностью параллельного и распределенного выполнения различных работ; возможность перехода к следующему этапу (шагу), не дожидаясь полного завершения предыдущего; применение методов контроля качества и постоянный контроль полученных результатов; поддержку итеративного характера разработки (возможность пересмотра полученных результатов и возврата на любой из предыдущих этапов; возможность быстрого внесения изменений в требования в процессе разработки; управление конфигурацией. 4.1.8. Заключение Для создания корпоративной информационной системы, отвечающей целям и задачам организации нужна специальная методология, которая бы во-первых, помогла сформировать требования к ИС, отвечающие целям и задачам организации, и во-вторых, спроектировать и разработать систему, отвечающую этим требованиям, с учетом их изменений в процессе разработки. Наличие такой методологии является решающим фактором успеха при создании корпоративных ИС. В статье предложена методология, обеспечивающая создание корпоративных ИС, отвечающих целям и задачам организации, предъявляемым к ним требованиям по автоматизации деловых процессов, и обеспечивающая выполнение основных требований к процессу разработки (по срокам, качеству и т.д). При создании корпоративных информационных систем необходимым слагаемым успеха помимо методологии, является также и комплекс согласованных инструментальных средств, поддерживающий эту методологию и обеспечивающий автоматизацию процессов, выполняемых на всех этапах ЖЦ создания ИС. Эти средства должны поддерживать быстрое построение корпоративных ИС, отвечающих целям и задачам организации и удовлетворяющих основным требованиям (открытости, переносимости и масштабируемости и т.д.), а также обеспечивать поддержку процессов управления проектом. Такой набор согласованных инструментальных средств, поддерживающих предлагаемую методологию, и приведен в докладе. Предложенная методология обеспечивает снижение сложности процесса создания ИС. Заложенные в методологию и поддержанные инструментальными средствами принципы, (разработка на основе моделей, проектирование от данных, повторное использование спецификаций и др.) упрощают разработку и обеспечивают возможность быстрого внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития. 4.2. Евгений Зиндер. О мастерской и мастерстве Появляются новые инструменты и методики проектирования, прикладные пакеты и общесистемные комплексы. И директору с его специалистами постоянно приходится принимать решения. Что использовать, а от чего отказаться? Какие программы обучения планировать? Наконец, как организовывать технологию проектирования систем? Сегодня правила решения этих проблем меняются. Кроме того, правила и сами проблемы сильно зависят от масштаба проекта или предприятия. 18 Полезно договариваться о понятиях. Тем более, когда они по большей части хаотически проникают из User guides или White Papers через сленг и дурные переводы. Слово Shop в терминах IT Shop или IS Shop, встречающихся в англоязычных публикациях, можно перевести и как "магазин", и как "мастерская". Но есть принципиальная разница между этими вариантами. Когда вы попадаете в Магазин средств создания информационно-управляющих систем (ИУС), вам предлагают огромный выбор СУБД, средств программирования, прикладных программ, услуг по их установке и настройке, обучению и т.д. Но все купить нельзя, да и не нужно, даже если вы - фирма-разработчик. Надо обустроить свою Мастерскую, а это - другое дело. 4.2.1. Для малых предприятий, где работает два-три компьютерных специалиста, в Мастерской ИУС часто имеется всего два-три любимых инструмента (не считая приложений), обычно не самых сложных, но опробованных в деле, подогнанных по руке мастеров. Однако число необходимых инструментов будет расти. Все чаще и в такой небольшой Мастерской станут появляться инструменты компоновки и средства промежуточного слоя, предназначеные для "сшивания" разных прикладных блоков и подсистем в одну действующую систему. Но вполне оправданно сохранение и традиционных средств программирования. Ведь быстрая доработка прикладной системы именно для своих частных нужд - это та изюминка, которая не только даст нужный комфорт пользователям, но и поможет выгодно выделить фирму в глазах заказчиков. В условиях такого предприятия настоящим мастером и высоким профессионалом является не "чистый" программист, а специалист, который смотрит на ИУС в контексте всей деятельности предприятия и своими разработками отвечает на вопрос, как можно усовершенствовать и продвинуть вперед дело фирмы. Подробнее см. статью Р. Гарнер в этом выпуске. 4.2.2. Для средних проектов и предприятий дело обстоит сложнее. Больше решается задач, задействовано больше технологий основного производства и видов рабочих мест пользователей ИУС. Растет штат мастеров и число их проблем - проблем самого проектирования. Соответственно в Мастерской должны появляться новые инструменты, но какие именно? Вот несколько вопросов. Должна ли применяться единая СУБД? Надо ли начинать использовать объектные СУБД? Нужна ли CASE-система? Если да, то какая и с какой целью: анализ предприятия, моделирование ИУС, генерация программ? Целесообразно ли ограничиться единственной CASE-системой и методикой проектирования? При поиске ответа на такие вопросы между разработчиками одного предприятия часто существуют разногласия. Как их разрешать? Вернемся к понятию "Мастерская" - оно само, при правильном использовании, может помочь. Мастерская включает в себя не только то, что используется каждый день, но и особый инструментарий, применяемый реже и в меньшем объеме, без которого, тем не менее невозможно решать сложные задачи. И этот инструментарий должен быть <на ходу>, а мастера должны владеть им в полной мере. К таким особым инструментам относятся CASE-системы, другие средства моделирования предприятий и их ИУС. Чтобы посмотреть, как обстоит дело с использованием таких средств, обратимся к обзору Мириам Уильямсон. Этот обзор, скорее всего, основан на опросе, проведенном среди более крупных предприятий, чем организации, представленные в исследовании Рошель Гарнер. В ответах появляются <тяжелые> пакеты комплексной автоматизации предприятий, в список СУБД входят DB2 и Oracle. Но если мы посмотрим, как рынок СШA голосует за средства разработки, то увидим нечто удивительное. Есть много запросов на VisualBasic и Visual C++, затем - по убывающей - на PowerBuilder и Oracle Developer/2000, но совсем нет запросов на какие-либо средства моделирования, на ERwin/BPwin, Oracle Designer/2000 или на другие CASE-системы, будь то интегрированные или класса Upper-CASE, легкие <рисовалки> или Rational Rose. Можно предположить, что это является результатом влияния массовой профессиональной культуры, которая и в США в большой степени опирается на "прямое" программирование. Однако уже в проектах среднего масштаба (а это обычно 20-40 участников) средства моделирования необходимы. Основные причины известны и многократно описаны. Выделим только три момента, относящихся к развитию ИУС: система обязательно будет дополняться пристройками, отличающимися по целям, стилю и средствам изготовления; требуется длительная поддержка согласованного состояния проектной информации всех видов; уже сделанные блоки и подсистемы будут совершенствоваться на уровне их кода; нужно иметь поддержку содержательной стороны управления таким развитием; при этом состав разработчиков всех специализаций будет меняться. Если не пользоваться средствами моделирования, управление развитием ИУС теряется, убытки труднопрогнозируемы. Почему же CASE-системы не используются повсеместно? 4.2.3. Мастера особой квалификации вот что требуется для использования этих средств. Вопрос понимания специалистами делового контекста ИУС становится не только одним из ключевых, но и самым важным, поскольку моделирование захватывает и анализ основной деятельности предприятия, и отображение моделей этой деятельности на модели реализации ИУС. Поскольку создание ИУС связано со многими аспектами или свойствами предприятия, требуется построение моделей разных сторон как 19 предприятия, так и самой ИУС. А это возвращает нас к проблемам формирования Мастерской и обсуждению уровня мастерства. Что есть высокий класс мастерства? Поговорим об этом на примере средств моделирования. Тем более что статья Сергея Панащука дает для этого хорошую почву. Часто рассматривается и навязывается мастерам дилемма: либо использовать модели структурного подхода, либо работать с "новыми", объектными типами моделей и новыми инструментами. (Правда, о новизне можно говорить только в кавычках. В связи с этим приятно видеть в данных Уильямсон среди востребованных языков старый добрый Smalltalk.) Но предложенный выбор некорректен. Более того, неверно считать универсальным правило: "выбрали систему моделирования, изучили приложенную к нему методику и делаем на них все наши проекты". Причина в том, что очень часто возможностей одного подхода и одной системы моделирования не хватает по существу, поскольку объект моделирования представлен моделями этого инструмента недостаточно полно, или недостаточно неудобно для людей, работающих с моделями, или то и другое вместе. Заметим, что модели важны в первую очередь для облегчения непосредственного восприятия людей: пользователей, бизнес-аналитиков, проектировщиков ИУС, затем - для согласования их мнений и фиксации результатов этого согласования, а уже потом - для автоматизации программирования. Очень часто можно обойтись одной CASE-системой и одной методикой. Но часто опытный специалист чувствует, что эта методика или CASE-система начинают <жать>. Правда, полностью оценить последствия может только мастер высокого класса, который знает, какие беды подстерегают ИУС через месяц, полгода и год после начала эксплуатации, чем эти беды можно ослабить и что для этого надо делать на стадиях анализа и проектирования. Одно это - признак мастера высшего класса. Здесь нужно учитывать то, о чем пишет С. Панащук: об отсутствии механистических процедур на всех уровнях проектирования и о том, что может быть полезно применять сочетания моделей и методов разных подходов (это к тому же значит - сочетать средства разных фирм и течений). Одно из следствий: решение типа "посадим двадцать дешевых студентов или дюжину специалистов средней квалификации, зато недорогих" приводит к результату-дешевке! Но этого недостаточно. Надо вспомнить три правила нового системного проектирования: схема организации проектных работ планируется как адаптивная, причем адаптация может производиться не только в начале проекта, но и по ходу его выполнения; методы и инструменты создания ИУС и компоненты действующей ИУС сливаются; перечень работ и методов является открытым. Поскольку адаптация схемы работ затрагивает их перечень и порядок, она оказывает влияние и на выбор средств создания системы. В свою очередь, это влияет на выбор решений при разработке и уточнении профилей стандартов проекта. Таким образом, мы должны говорить здесь не только о моделях и CASE-системах, все эти правила относятся к самому разному инструментарию и представителям всех специальностей: бизнес-аналитикам, проектировщикам баз данных и систем коммуникаций, конструкторам приложений и др. Мастер в этих условиях должен: иметь свободу для владения достаточным, а с позиций какого-то одного проекта - избыточным набором инструментов и методов; не только владеть ими, но вполне понимать ограниченность каждого из них, а также цели, возможности и способы их применения в сочетаниях; иметь свободу выбирать и применять в каждом проекте нужные инструменты по необходимости, а не по когда-то принятой методике; совершенствовать систему инструментов так, чтобы их совместное применение требовало минимума ручных доработок, а разрывы устранялись <автоматизированно>, то есть с поддержкой работы самого мастера; делать все перечисленное не только для анализа и дизайна, предшествующих стадиям реализации ИУС, но и для поддержки процессов эксплуатации и развития системы. Конечно, мастер будет пользоваться свободой как вполне осознанной необходимостью, обосновывая и документируя свои решения. А современные стандарты поддерживают такой подход. 4.2.4. Предупреждение Будьте готовы к тому, что, на взгляд менеджера-администратора или финансового директора проекта, такой набор инструментов и методов будет избыточным всегда и в любом отношении, а не только в рамках одного проекта. Учтите: владеть двумя альтернативными средствами - значит иметь минимум полуторные расходы на их содержание (по сравнению с владением одним средством). Это определяется не столько стоимостью техподдержки, сколько обучением, работой по адаптации частных методик, по интеграции разных средств. Доводы за такое владение должны быть вескими, они должны определяться особенностью ваших ближайших проектов. На основе этих особенностей надо строить доказательную аргументацию, а с ее помощью убеждать заказчиков, финансистов и, что тоже бывает нужно, своих коллег в пользе и конечной выгоде такого подхода. Надо стремиться к тому, чтобы расходы на владение уменьшались, были действительно не двойными, а полуторными, например, за счет самостоятельного изучения средств и различных форм кооперации со специалистами других предприятий. Работа с несколькими альтернативными инструментами не должна превращаться в самоцель и создавать дыру в бюджете. 20 4.2.5. Результаты такого подхода С точки зрения успеха проекта вы избежите необходимости <переламывать> заказчика (внутреннего или внешнего), разрыв между его стандартами и предпочтениями и вашим подходом окажется меньше, а устранять его вам будет гораздо легче. Большее число пользователей охотнее и эффективнее включатся в процесс обсуждения, проектирования и внедрения системы, внедрение пройдет легче, объем доработок при этом будет минимален. Все это переносится и на стадии использования и развития системы. Профессионалы и фирмы, достигшие такого уровня мастерства, выгодно отличаются от множества других, условный пример которых таков: фирма, продающая CASE-ABC, работает именно на CASE-ABC и по методике ABC, фирма, продающая CASE-XYZ, работает на CASE-XYZ, - и т.д. Если выберешь первую фирму из-за ее опыта в создании сетей, то должен тем самым принимать и CASE-ABC с соответствующей методикой проектирования, а это может быть совсем ни к чему. Для крупных проектов проблемы не только организационного, но и, в первую очередь, содержательного управления разработкой часто становятся определяющими. Формирование мастерской и уровня мастерства специалистов становится самостоятельным проектом. Но это - тема для отдельного рассмотрения. 4.2.6. О мастерстве высшего класса и мастерской Создание хороших систем основано на таком качестве мастера, как "понимание" - в дополнение к "знанию" и "умению". Таких мастеров мало, но именно их уровень должен задавать тон всей проектной работе. Это и есть путь, на котором и набор инструментов в Мастерской, и процессы проектирования систем будут не заемным прокрустовым ложем, а естественным результатом движения ко все более высоким уровням зрелости и совершенства. 4.3. Два подхода к проектированию информационных систем Владимир Ивлев, Татьяна Попова, Юрий Чекаленко. Фирма СофтСервис. Важнейшим фактором успешной деятельности предприятия является умение его руководства чувствовать рынок и ориентироваться на него. Перед любой компанией стоят две основные задачи: уметь заботиться о себе и видеть окружающую действительность. “Заботиться о себе” — значит наводить порядок в технологиях деятельности, процедурах документооборота, организационно-штатной структуре. Одним из механизмов решения задачи наведения порядка является постановка на предприятии методологии управленческого учета, применение которого даст ответы на вопросы: “что”, “где”, “когда”, “как”, “почему”, “сколько”, “в чем причина” и т.д. Наведение порядка на предприятии приведет к повышению внутренней эффективности предприятия. Однако успешная внутренняя жизнь предприятия — это необходимое, но не достаточное условие выживания, а тем более для занятия ведущих позиций на рынке. Чтобы повысить внешнюю эффективность, следует адаптироваться к требованиям окружающего мира, потребностям рынка, научиться управлять поставщиками и заказчиками. Возможность правильно и своевременно реагировать на внешнюю среду позволяет стратегически мыслить. В последнее время отчетливо проявляется тенденция перехода от детального управления внутренней деятельностью к управлению заказчиками и поставщиками. Конкурентоспособность компании все больше зависит от способности создавать и углублять взаимоотношения с другими компаниями (партнерами, конкурентами, заказчиками или поставщиками). Причинами этого являются: расширение экономического пространства, на котором функционируют предприятия; появление нового стратегического ресурса — информации; необходимость учитывать фактор времени. Для решения вышеперечисленных задач необходимо иметь эффективную систему управления предприятием, включающую систему менеджмента качества, и информационную систему ее поддержки. 4.3.1. Два подхода к проектированию. Можно выделить два основных подхода к проектированию систем управления предприятием и информационных систем их поддержки: структурный и процессный. Первый подход основан на использовании организационной структуры компании, когда проектирование системы идет по структурным подразделениям. Технологии деятельности в этом случае описываются через технологии работы структурных подразделений, а взаимодействие структурных подразделений — через модель верхнего уровня. Если компания представляет собой сложную структуру типа холдинга, или предприятие-сеть, то необходимо также иметь модель взаимодействия всех входящих в него элементов, в которой будут отражены не только технологические, но также финансовые и юридические моменты. Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения. О важности и структуре Системного проекта авторы уже писали в статье “Реорганизация АСУ промышленных предприятий” (КомпьютерПресс № 7’97) и в статье “Методологический подход проектирования корпоративной информационной системы предприятия” (материалы конференции “Корпоративные системы’96”, компания “СофтСервис”). Хорошо, если на предприятии есть обученные специалисты, способные быстро и качественно актуализировать этот документ. Но это 21 только начало! Ведь актуализировать надо также и саму информационную систему! Как правило, это достаточно трудоемкий, длительный и утомительный процесс. Несколько по-иному обстоит дело при процессном подходе. Этот подход ориентирован не на организационную структуру, а на бизнес-процессы. С точки зрения авторов, он наиболее перспективен. Бизнес-процессы, в отличие от организационной структуры, меняются реже. Как правило, основных бизнес-процессов на предприятии немного, обычно не более десяти. Процессный подход подводит к необходимости перехода на так называемое тощее производство или тощую ресурсосберегающую организационную структуру (Lean production). Основными чертами такой реорганизации являются: широкое делегирование полномочий и ответственности исполнителям; сокращение количества уровней принятия решения; сочетание принципа целевого управления с групповой организацией труда; повышенное внимание к вопросам обеспечения качества продукции или услуг, а также работы предприятия в целом; автоматизация технологий выполнения бизнес-процессов. Далее мы рассмотрим, каким образом процессный подход был применен при проектировании информационной системы одного из предприятий пищевой промышленности (далее “Компании”). 4.3.2. Применение процессного подход. Цели проекта Основными целями проектирования интегрированной системы Компании являлись: проведение системного анализа бизнес-процессов и моделирование рациональных технологий работы Компании; разработка перспективной организационной структуры центрального офиса и филиала с вариантом распределения между структурными подразделениями элементов рациональных технологий работ; разработка положения по организации управления Компании (центрального офиса и филиала); разработка системного проекта интегрированной информационной системы Компании (центрального офиса и филиала). 4.3.3. Базовые, общие и перспективные технологии В результате анализа деятельности Компании были выявлены шесть базовых технологий работы и четыре общих, а также выделены четыре перспективных технологии работы Компании. К базовым технологиям, которые необходимо автоматизировать, относятся: поставка оборудования; поставка пищевых добавок и продуктов питания импортного производства; поставка и внедрение упаковки; гарантийное и техническое обслуживание оборудования; выдача лицензий; разработка технических условий. Общие технологии — это функциональные модули, описывающие законченный процесс, который повторяется не менее чем в двух базовых технологиях и существует только совместно с ними. Рис 1. Взаимодействие базовых и общих технологий работы Компании 22 Общие технологии, являющиеся неотъемлемыми частями базовых, включают: консультирование; растаможивание/затаможивание товаров; рекламу и маркетинг; сертификацию. Текущий этап развития информационной системы Компании предусматривает автоматизацию консультирования, сертификации, а также рекламы и маркетинга. Взаимодействие базовых технологий работы Компании с общими представлено на рис.1. Из рисунка видно, что базовые технологии работы включают не менее одной общей технологии. Стрелки указывают на те базовые технологии, в процессе выполнения которых непременно используется данная общая технология. С учетом стратегии развития деятельности Компании, перспективными технологиями ее работы являются: строительство производственных мощностей; производство продуктов питания; контроль качества продукции; реализация продуктов питания собственного производства. Подробно базовые и общие технологии работы Компании, а также модель верхнего уровня рациональной технологии ее работы, обычно описываются в функциональноинформационно-стоимостных моделях рациональных технологий деятельности Компании (например, в стандартах IDEF0/SADT и ABC). Фрагменты одной из моделей представлены на рис. 2-3. Технологии работы определяются характером деятельности Компании и существуют независимо от ее организационно-штатной структуры. Каждая технология работы состоит из последовательно и параллельно выполняющихся функций, которые могут различным образом конфигурироваться под любого исполнителя и любое должностное лицо посредством механизма полномочий. Полномочия регулируют доступ пользователей к прикладным задачам, к информации базы данных и к обобщенным данным, характеризующим состояния процессов деятельности Компании. Рис. 2. Фрагмент функционально-информационной модели Рис. 3. Фрагмент функционально-информационной модели (прод.) 23 Прикладная задача представляет собой программный модуль, поддерживающий некий логически законченный процесс, направленный на учет данных и облегчение выполнения пользователями их обязанностей в рамках технологии работы. Любая технология работы Компании включает несколько прикладных задач, логически увязанных между собой путем использования в каждой следующей прикладной задаче результатов задач предыдущих, хранящихся в корпоративной базе данных. 4.3.4. Состав прикладных задач Состав прикладных задач формируется на основе рациональных технологий деятельности Компании, которые представлены в функционально-информационных моделях. Функционально-информационные модели представляют собой иерархическую структуру функций, связанных между собой с помощью интерфейсных дуг (см. рис. 2-3). Моделирование выполняется по принципу “сверху-вниз”. Первые диаграммы модели описывают наиболее общие функции, которые постепенно декомпозируются вплоть до самого “нижнего” уровня “элементарных” функций. В качестве примера приведем прикладные задачи по базовой технологии поставки оборудования. К ним относятся: учет клиентов компании (поддержание справочника клиентов в актуальном состоянии); учет оборудования и его спецификаций (поддержание справочника оборудования в актуальном состоянии); подготовка прайс-листов на оборудование; учет заявок на закупку оборудования; подготовка коммерческих предложений; поддержка процесса согласования с клиентом предмета сделки; формирование, учет и контроль исполнения бизнес-плана на поставку оборудования; формирование, учет и контроль схемы оплаты за оборудование; формирование схемы линии (перечень требуемого оборудования); формирование, учет и контроль состояний договоров (приложений) на поставку, производство, сертификацию, доставку и страхование оборудования; обеспечение расчетов с клиентами компании; учет информации и документов по этапам поставки оборудования (заказ оборудования, производство, сертификация, страхование, доставка, монтаж, наладка, сдача в эксплуатацию и обучение персонала заказчика выпуску на нем продукции); учет платежей клиентов компании; поддержка процесса гарантийного обслуживания; подготовка материалов, поддерживающих процесс обучения; поддержка документооборота между автоматизированными рабочими местами должностных лиц. 4.3.5. Концептуальная модель ИИС Интегрированная информационная система (ИИС) Компании представляет собой разветвленную сеть, объединяющую локальные и удаленные рабочие места пользователей. Концептуальная структура ИИС Компании приведена на рис. 4. Основными элементами ИИС являются: локальная вычислительная сеть (ЛВС) центрального офиса Компании; ЛВС филиала; интегрированная база данных. ЛВС Центрального офиса Компании и филиала реализуется на основе архитектуры “клиент/сервер”, объединяющей автоматизированные рабочие места сотрудников служб и подразделений. Рис. 4. Концептуальная структура ИИС Компании Группы автоматизированных рабочих мест (АРМ) выделяются по функциональному признаку, с учетом выполнения выделенных базовых, общих и перспективных бизнеспроцессов, перспективной организационной структуры Компании, и ориентируются на дерево функций перспективной деятельности Компании. Состав АРМ перспективной ИИС Компании имеет следующий вид: 24 АРМ руководителя: АРМ директора; АРМ заместителей директора (начальников служб); АРМ коммерческой службы: АРМ группы оборудования; АРМ группы пищевых добавок; АРМ группы упаковки; АРМ отдела продуктов питания; АРМ группы ВЭС и растаможивания; АРМ технической службы: АРМ группы ТУ и патентов; АРМ группы сертификации; АРМ группы рекламы и маркетинга; АРМ финансовой службы: АРМ бухгалтера; АРМ финансового отдела; АРМ экономического отдела; АРМ службы обеспечения: АРМ юриста; АРМ специалиста по работе с персоналом; АРМ общего отдела; АРМ отдела безопасности; АРМ отдела информатизации; АРМ службы логистики: АРМ службы клиентов; АРМ транспортного отдела; АРМ склада; АРМ службы производства: АРМ службы технического обслуживания; АРМ группы строительства; АРМ производственного отдела; АРМ группы качества продукции. ______________________________________________________________________________________________ 4.3.6. Состав и модели процедур документооборота, обеспечивающих информационное взаимодействие автоматизированных рабочих мест Компании Анализ разработанных рациональных функционально-информационных моделей технологий работ Компании позволяет систематизировать и сформировать группы документов по типовым алгоритмам прохождения между должностными лицами и исполнителями. В процессе выполненного объединения потоков входящих и исходящих документов сформированы четыре типовые группы документов: договорные документы; первичные бухгалтерские документы; документы поддержки бизнес-процессов; отчетные документы. Каждая группа документов в зависимости от технологии работы характеризуется уникальным, присущим только ей, перечнем документов. Например, для технологии поставки оборудования входящими и исходящими документами будут следующие: договорные документы; первичные бухгалтерские документы; документы поддержки бизнес-процессов. Операции над документами, выполняемые должностными лицами и исполнителями, описываются в функциональноинформационных моделях рациональных технологий деятельности Компании, функциональных и информационных спецификациях автоматизированных рабочих мест и процедурах документооборота. Процедуры документооборота предназначены для автоматизации процессов разработки, согласования и исполнения документов между службами и должностными лицами Компании. Каждая процедура документооборота определяет схему взаимодействия АРМ по каждой группе входящих и исходящих документов, а также этапность и направленность действий исполнителей и должностных лиц. 25 4.3.7. Заключение Процессный подход к анализу и моделированию бизнес-процессов, а также к последующей разработке требований к информационным системам позволяет оперативно сопровождать (изменять и дорабатывать) описанные рациональные технологии работ, безболезненно (параллельно с эксплуатацией) для пользователей модернизировать информационную систему Компании, наращивать мощность базы данных и поддерживать ее в актуальном состоянии. Другим важнейшим преимуществом применения процессного подхода является возможность формализации технологии выполнения работ по реорганизации деятельности предприятий и проектированию информационных систем поддержки рациональных бизнес-процессов. На основе формализации были созданы методическое обеспечение и соответствующая ему автоматизированная технология выполнения работ по бизнес- и ИТ-консалтингу. Данная технология была успешно применена при выполнении проектов для компаний, функционирующих в различных вертикальных нишах рынка, где и используется в настоящее время. В свою очередь, применение автоматизированной технологии привело к необходимости по-новому взглянуть на классификацию и использование прикладных программных средств реализации информационных систем на основе материалов системного проекта. Основными классификационными критериями стали трудоемкость настройки, внесение изменений и возможности функционального расширения, степень независимости ИТ-менеджеров компаний от разработчиков Системного проекта и программных средств его реализации при внесении изменений в проект, и, конечно же, стоимость работ по консалтингу, внедрению и сопровождению. О результатах проведенной классификации программных средств мы расскажем в другой статье. Здесь можно только констатировать, что на российском рынке есть свои собственные программные средства реализации информационных систем, обладающие оптимальными значениями по вышеперечисленным критериям. Применение одной из таких систем позволило осуществить проектирование и внедрение ИИС Компании пищевой промышленности в течение трех месяцев.
