Методологии проектирования информационных систем

Основные понятия

До недавнего времени под информационной системой понимали базу данных с набором приложений. Поэтому для проектирования ИС было достаточно спроектировать БД и написать приложения. Однако ИС редко создаются на пустом месте, и при их проектировании нужно было учитывать и технические возможности заказчика и требования заказчиков к различным видам документов. Процесс проектирования в этом случае охватывал три основные области:

- проектирование объектов данных, которые будут реализованы в базе данных;

- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Оба этих подхода соответствуют существующим в настоящее время стандартам и могут быть использованы для небольших компаний с ограниченным набором задач.

Как уже говорилось ранее, мы будем рассматривать информационную систему как некоторый продукт с точки зрения заказчика (управления компанией) и точки зрения создателя (IT-подразделение).

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

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

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

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

- регламент развития информационной модели и правила внесения в нее изменений;

- кадровые ресурсы (департамент развития, привлекаемые консультанты), отвечающие за формирование и развитие информационной модели;

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

- кадровые ресурсы, отвечающие за конфигурирование ПК и его соответствие утвержденной информационной модели;

- регламент внесения изменений в конфигурацию ПК и состав его функциональных модулей;

- аппаратно-техническая база, соответствующая требованиям по эксплуатации ПК (компьютеры на рабочих местах, периферия, каналы телекоммуникаций, системное ПО и СУБД);

- эксплуатационно-технические кадровые ресурсы, включая персонал по обслуживанию аппаратно-технической базы;

- правила использования ПК и пользовательские инструкции, регламент обучения и сертификации пользователей.

Рассмотрим пример:

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

1. Определение целей функционирования транспортной системы и основных ее параметров. Для чего проводится проект? Исходя из какой системы критериев будут оцениваться результаты?

2. Разработка требований по экономической эффективности, планирование политики ценообразования. Какова должна быть стоимость билетов и все прочие расходы, чтобы была возможность поддерживать и развивать инфраструктуру?

3. Реконструкция существующих дорог и/или строительство новых, соединяющих основные городские объекты. С каким покрытием целесообразно строить дороги, чтобы, с одной стороны, укладываться в узкие рамки бюджета, а с другой - позволять использовать современные автобусы?

4. Определение маршрутов, остановок и режима работы транспорта на линиях. Как не допустить негативного проявления консерватизма пассажиров при изменении (отмене) имеющихся маршрутов в результате проекта?

5. Какие автобусы следует приобретать - отечественные или импортные? Какой марке отдать предпочтение? Каков должен быть баланс между большими автобусами и "маршрутками"? На каких маршрутах приоритетна пассажировместимость, а на каких скорость доставки?

6. Что делать со старым парком автобусов? Продолжать использовать в новых условиях или списывать?

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

1. Для решения каких управленческих (производственных) задач нам нужна ИС? Как мы будем определять, справляется ли она с возложенными на нее функциями?

2. Как мы будем оценивать экономическую эффективность от внедрения? Сопоставима ли реальная экономическая отдача полной стоимости владения?

3. Какие новые бизнес-процессы необходимо внедрить, а какие реорганизовать для того, чтобы отдача от использования ИС была максимальной?

4. По каким правилам будет осуществляться управление информационными потоками в новом режиме? Не будет ли проявляться пресловутое сопротивление персонала нововведениям?

5. Какой программный комплекс приобретать: отечественный или зарубежный? Стоит ли инвестировать средства в многофункциональное и дорогостоящее решение, или пока можно обойтись компромиссным вариантом?

6. Что делать со старыми программами обработки информации и управления БД: интегрировать с приобретаемым решением или уничтожать?

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

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