Этапы внедрения информационной системы. Разработка информационной системы

Основные фазы внедрения информационной системы

Фаза «Предварительные работы по подготовке проекта внедрения ИС». В ходе предпроектного обследования предприятия происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза «Подготовка проекта». После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

  • формирование проектной и экспертной групп;
  • распределение полномочий и ответственности;
  • определение организационно-технических требований к процессу внедрения;
  • уточнение спецификаций и ожиданий заказчика;
  • обучение группы внедрения, состоящей из специалистов предприятия-заказчика.

Фаза «Концептуальная проработка проекта». В течение этой фазы:

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

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

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

Фаза «Реализация проекта». Во время проведения основных работ по внедрению создается, устанавливается и конфигурируется системная среда, определяются процедуры системного администрирования, устанавливаются основные программно-аппаратные комплексы и приложения. В системе настраиваются организационно-штатные и организационно-функциональные структуры предприятия с использованием таких организационных единиц, как филиал, департамент, отдел, рабочая группа и т. д.

Рис. 2.17. Примерное содержание репозитория проекта внедрения

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

Отрабатываются системные вопросы безопасности работы системы в многопользовательском режиме. Создаются приложения, шаблоны, отчеты, клиентские формы доступа, распределяются полномочия пользователей. Проводится «прогонка» всех систем в «боевом режиме» с участием всех заинтересованных сторон.

Рис. 2.18. Примерный состав документации по процессу внедрения ИС

После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Контрольные вопросы и задания

  1. Что такое "открытая информационная система"?
  2. Перечислите основные свойства открытых систем.
  3. Охарактеризуйте суть современного процессного подхода к управлению деятельностью предприятия и использования этого подхода при разработке ИС.
  4. Что включает в себя понятие "Реинжиниринг бизнес-процессов"?
  5. Какие модели и каким образом используются при проектировании информационных систем?
  6. Какие программные средства используются для моделирования процессов при разработке информационных систем?
  7. На основании каких данных и информации разрабатываются модели состояния AS IS и AS TO BE?
  8. Кто в компании занимается вопросами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?
  9. Назовите основные этапы проектирования информационных технологий.
  10. Перечислите этапы жизненного цикла информационной системы.
  11. На каком этапе разработки и внедрения ИС производится обучение персонала компании?
  12. Перечислите основные фазы внедрения ИС.

Глава 3. Программные средства компьютерных информационных технологий

3.1. Общая характеристика программных средств компьютерных информационных технологий

Для компьютерных информационных технологий в качестве средств управления техническим комплексом (компьютерных систем) выступают программные средства (программное обеспечение).

Вопросы разработки и использования программного обеспече­ния вообще достаточно хорошо проработаны и широко освещены в научной и учебно-практической литературе. Но необходимы некоторые уточнения.

Так, общее определение содержания понятия «программное обеспечение» включает в себя совокупность программ системы об­работки данных и программных документов, необходимых для экс­плуатации этих программ. Данная трактовка в общем случае мо­жет быть использована, особенно если речь идет о проблемах соб­ственно разработки и эксплуатации программных комплексов как таковых. Но с точки зрения пользователей в рамках соответствующих технологий следует выделить из состава их программного обеспечения эксплуатационные документы, поскольку в соответствии со структурой средств и методов информационных технологий они относятся к организационно-методическому обеспечению.

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

В составе программного обеспечения выделяются (рис. 3.1):

Системное программное обеспечение;

Инструментальное обеспечение разработки программ;

Прикладное программное обеспечение.

Рис.3 .1. Структура программного обеспечения информационных технологий

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

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

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

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

3.2. Жизненный цикл программных средств компьютерных информационных технологий

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

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

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

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

· определение потребности в определенном виде программных средств для реализации конкретной функции офисной технологии;

· выбор конкретного программного продукта для реализации конкретной офисной технологии;

· приобретение промышленного программного продукта, его модернизация или разработка уникального программного продукта;

· установка программного продукта на имеющуюся вычислительную систему офиса;

· эксплуатация программного продукта;

· оценка эффективности применения программного продукта;

· модернизация программного продукта;

· демонтаж программного продукта.

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

Выбор конкретного программного продукта должен осуществляться на основе совместного рассмотрения следующих факторов:

· наличие промышленных программных продуктов, реализующих функции конкретной информационной технологии;

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

3.3. Сущность и основные понятия систем управления базами данных

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

При всем разнообразии упомянутых методов и средств можно выделить общие признаки, характеризующие работу с данными:

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

· сами данные разбиты на определенные компоненты, различным образом связанные друг с другом, т. е. они структурированы и упорядочены;

· имеются определенные методы поиска и извлечения (выборки) необходимой информации и ее представления.

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

При значительных объемах информации, хранящейся в БД, или при существенной ее значимости для деятельности возникает проблема надежности и скорости обработки данных. Эта проблема во многом может быть решена за счет использования компьютерных технологий. Соответствующие СУБД получили довольно широкое распространение, и значительную их часть составляют системы, основывающиеся на реляционном подходе.

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

Рассмотрим пример. Данные о сотрудниках некоторой проектной организации включают в себя:

· табельный номер сотрудника;

· фамилию, имя и отчество;

· дату рождения;

· домашний адрес;

· домашний телефон;

· дату поступления на работу;

· место работы;

· служебный телефон;

· должность;

· надбавку за стаж работы;

· проект, в котором участвует сотрудник;

· надбавку за участие в проекте.

Эти данные можно представить в виде таблицы, в которой каждому виду данных соответствует свой столбец, а каждому конкретному сотруднику - строка).

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

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

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

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

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

Для исключения хранения излишней информации из таблицы необходимо убрать поля, касающиеся свойств объектов, отличных от персонала, и создать для них свои отношения: например таблицы «Отдел», «Проект» и «Надбавки».

Описанные действия по представлению данных в теории и практике создания БД называют нормализацией.

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

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

Представленные выше отношения в таблицах связаны друг с другом через отдельные поля: отношения «Персонал» и «Отдел» - через поле «Номер отдела» (соответственно вторичный и первичный ключи); отношения «Персонал» и «Проект» - через поле «Название проекта» (соответственно вторичный и первичный ключи). Связь отношений «Персонал» и «Надбавки» осуществляется через поля «Дата поступления на работу» (составной вторичный ключ) и «Стаж работы» (первичный ключ), но не непосредственно, а через процедуру вычисления стажа работы по значению даты поступления на работу.

Представленное в описанном примере структурирование и упорядочивание данных в целом характерно для всех систем управления БД и для различных программ отличается в деталях.

3.4. Компьютерные системы управления базами данных

Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей БД, используемой для решения множества задач. Подобные системы служат для поддержания БД в актуальном состоянии и обеспечивают эффективный доступ пользователей к содержащимся в ней данным в рамках предоставленных пользователям полномочий.

К наиболее популярным СУБД для вычислительных систем класса персональных компьютеров относятся dBASE IV, Microsoft Access, FoxPro, Paradox. Для более мощных систем предназначены СУБД Oracle, Informix. В определенной степени возможности управления данными имеются и у большинства современных табличных процессоров.

По степени универсальности различают два класса СУБД:

· системы общего назначения;

· специализированные системы.

СУБД общего назначения не ориентированы на какую-либо предметную область или на информационные потребности какой- либо группы пользователей. Каждая система такого рода реализуется как программный продукт, способный функционировать на некоторой модели ЭВМ в определенной операционной системе.

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

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

Рассмотрим основные характеристики некоторых СУБД – лидеров на рынке программ, предназначенных как для разработчиков информационных систем, так и для конечных пользователей.

Наглядное представление этапов внедрения.

Более подробная схема см. приложение №2.

Этап 1: диагностика

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

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

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

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

Заключительный набор задач состоит в планировании проекта - определение ресурсов, время и бюджет для развертывания решения.

В данном этапе требуется оценить бизнес-требования, объем и рамки проекта, а также план проекта, и по этим данным определить, что лучше использовать - быстрое или полное внедрение Microsoft Dynamics.

Основные результаты стадии:

  • * Предложение относительно работы над проектом:
  • * описание содержания проекта;
  • * предварительный план проекта.
  • * Оценка инфраструктуры.

Результаты стадии:

Клиент принимает предложение на внедрение, подписывает контракт, включая предполагаемый объем и рамки проекта, а также ознакомляется с предварительным дизайном системы.

Этап 2: анализ.

Аналитический этап начинается с действий, направленных, в первую очередь, на создание проектной команды - и со стороны разработчика и со стороны агентства. Необходимо обратить особое внимание на встречу перед началом проекта, на которой участники коллектива проектной команды должны быть представлены и ожидания и взгляды, как проект продолжится - скоординированы.

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

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

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

Когда анализ всех требований будет завершен, собранная информация агрегируется и на ее основе создается документ «Функциональные требования», который заказчик проверяет, одобряет и подписывает.

Основные результаты этапа:

  • * Устав проекта.
  • * Тренинги ключевых пользователей.
  • * Детальный анализ бизнес-процессов:
    • o анализ разрывов требований с базовой функциональностью;
    • o оценка устранения разрывов;
    • o описание интерфейсов.
  • * План миграции данных.
  • * План проекта.
  • * Функциональные требования:
    • o инфраструктура, функциональность и безопасность;
    • o интеграция.
  • * Требования к контролю качества и тестированию.

Основные вехи этапа:

  • * Проведено совещание по запуску проекта.
  • * Заказчик утверждает Устав проекта.
  • * Проводится обучение по проектируемой ИС для ключевых пользователей.
  • * Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных.
  • * Заказчик утверждает обновленный план-график проекта.

Этап 3: дизайн.

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

  • * Создать или обновить полный дизайн проекта и соответствующих документов, которые будут требоваться, чтобы решение соответствовало функциональным требованиям.
  • * Чтобы создать верхнеуровневую спецификацию для каждой модификации системы, приспособлена обработка, определенные отчеты и интеграция определенная в документе «Функциональные Требования».
  • * Создать подробное описание требований к преобразованию данных, которые были определены во время анализа и планирования миграции данных в аналитической стадии.
  • * Получить одобрение от заказчика верхнеуровнего плана миграции данных и спецификации дизайна решения перед началом созданием подробной спецификации дизайна и выполнения заключительных оценок.
  • * Создать подробную спецификацию дизайна решения на основе верхнеуровневой структуры дизайна, одобренного клиентом.
  • * Выполнить и представить заказчику оценки созданию модификаций, контроля, интеграции и миграции данных.
  • * Получить, одобренные заказчиком дизайном, технические требования модификаций системы, дизайн миграции данных и оценки всех перечисленных операций.

Основные результаты стадии:

  • * Спецификация дизайна решения:
  • * функциональный дизайн;
  • * техническая характеристика.
  • * Дизайн интеграции с внешними системами.
  • * Дизайн миграции данных и определение соблюдения структур данных.
  • * План и сценарии тестирования.

Главные этапы стадии:

  • * Клиент одобряет спецификацию дизайна решения, дизайна интеграции с внешними системами и дизайна миграции данных.
  • * Клиент одобряет время развития и оценку расходов.

Этап 4: разработка.

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

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

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

Циклы развития и тестирования продолжаются, пока результаты тестирования не отвечают критериям тестирования определенным ранее и не удовлетворят клиента. На этой стадии проекта такие процессы как управление объемом и структурой проекта и управление изменениями крайне важны.

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

Основные результаты стадии:

  • * Настройка решения проектируемой ИС.
  • * Подготовка документации относительно решения проектируемой ИС
  • * Развитие дополнительной функциональности (настройки).
  • * Контроль и тестирование миграции данных.
  • * Тестирование интеграции (включая интеграцию с внешними системами).

Главные этапы стадии:

  • * Миграция данных выполнена.
  • * Тестирование интеграции выполнено.
  • * Клиент принимает созданное решение, результаты тестирования и документации.

Этап 5: развертывание.

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

Основные результаты стадии:

  • * План начала и контрольный список.
  • * План тестирования системы.
  • * План обучения пользователей.
  • * Обучение пользователей.
  • * Рабочая система.

Главные этапы стадии:

  • * План старта и контрольный список.
  • * План тестирования системы.

Этап 6: эксплуатация.

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

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

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

После закрытия проекта передачи знания и пост-стартового совместного анализа проекта рекомендуется выполнять поддержку проекта. Это - прекрасная возможность обсудить проект и вывести из него соответствующие уроки.

По этому вопросу взаимодействие с клиентом проводится в пределах ранее скоординированной поддержки продукта (с подписанием соответствующего контракта). Команда консультанта переключается на следующий проект.

Основные результаты стадии:

  • * Принятие системы клиентом.
  • * Документы для закрытия проекта.
  • * Соглашение по поддержке системы.

Главные этапы стадии:

  • * Клиент признает, что спроектированный ЯВЛЯЕТСЯ и подписывает акт входа в коммерческой операции.
  • * Клиент формально закрывает проект.
  • * Клиент подписывает контракт поддержки.

Модель методологии проектируемой ИС также определяет две дополнительные стадии, которые можно реализовать после запуска решения

Проектируемая ИС в рабочей среде клиента:

Цель стадии оптимизации: создание структуры управления процессами, происходящими после процедуры Go-Live. Эта стадия также позволяет поддерживать отношения с клиентом после оригинального проекта введения или может стать первым шагом на способе предоставить услуги новому клиенту.

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

Стадия оптимизации - отражение процесса полного внедрения. Эта стадия включает перечисленные ниже действия:

  • * Аналитические действия, направленные на сбор информации о процессе, контроле и производительности.
  • * Предложения относительно объема работ.
  • * Работа над выполнением и расширением оптимизации.

Необходимость полного внедрения, в следствии сложности обновления, определяется в ходе анализа. В рамках обновления выполняются следующие действия:

  • * анализ;
  • * планирование;
  • * определение оптимизации;
  • * расширение оптимизации;
  • * эксплуатационные операции.

Обновление.

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

Потребность полного внедрения, вызванного сложностью обновления, определённого во время анализа. Это начинается со стадии диагностики.

В рамках обновления следующие действия могут быть выполнены:

  • * анализ;
  • * планирование;
  • * обновление работы;
  • * тестирование;

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

Каждая стадия методологии Sure Step Methodology включает ряд определенных операций и задач. Результат выполненной работы в рамках операции, как правило, отражен в конечных результатах с рекомендациями и инструкциями о дальнейших шагах процесса внедрения.

Вопрос: «Кто осуществит внедрение информационной системы?», чрезвычайно важен в каждом из случаев запуска проекта автоматизации.

Данный тезис неоспорим, по нескольким причинам:

  • Внедрение информационных – очень дорогое удовольствие;
  • Не достаточно качественный подход к реализации проекта способен парализовать работу предприятия, иногда на длительное время;
  • В ходе внедрения могут и должны подвергнуться изменению существующие ;
  • Может измениться и сама структура предприятия.

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

Внедрение информационных систем в основном происходит по одной из следующих схем:

    Внедрение осуществляет компания-внедренец;

  1. Собственный отдел информационных технологий;
  2. Привлекается фрилансер, который выполняет функцию руководителя проекта.

Рассмотрим каждый вариант подробнее.

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

Нюансы работы с крупной компанией внедренцем:

    Внедрение информационной системы поставлено на поток;

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

    Неудача на «небольших» проектах мало влияет на общую репутацию компании и отношения к таким проектам соответствующее;

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

    Стоимость услуг – самая высокая из всех рассматриваемых вариантов.

Альтернативный вариант – небольшая компания:

    Проект может стать приоритетной задачей для специалистов компании;

    Для таких компаний на мой взгляд характерно проявление жадности. Так как сфера информационных технологий пока не является самой конкурентной отраслью экономики. Небольшие компании могут получить значительный проект по внедрению информационных систем. В то время как основные силы компании уже заняты на проектах, недостаток пытаются восполнить ускоренным набором новичков, естественно желая сэкономить на зарплатах. Разработку передают самым дешевым аутсорсерам, тогда как сами за час работы программиста берут достаточно много. Маржа может достигать 75%. Эти проекты характеризуются постоянной сменой руководителя, чехардой консультантов, странными техническими решениями, срывом сроков.

    Успех проекта полностью зависит от квалификации сотрудников компании и в первую очередь менеджера проекта;

    Обходятся значительно дешевле чем.

Собственный отдел информационных технологий (ИТ).

На первый взгляд кажется оптимальным вариантом, свои сотрудники, контролируемые затраты, гарантия сохранения информации. Однако мировой опыт говорит случаи реализации проектов внедрения информационных систем таким методом – единичны! Характерным элементом таких проектов являются затянутые сроки реализации, причем затянутые на годы. Такие проекты переходят в операционную деятельность.

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

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

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

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

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

Но никто не гарантирует, что данный специалист сможет стойко преодолевать менеджерские проблемы которые были описаны в предыдущем пункте.

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

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

Делая выводы из всего вышесказанного, хочется зафиксировать:

  • Привлечение крупной компании внедренца – прерогатива крупных компаний, успех проекта с которыми будет иметь имиджевую составляющую для внедренца;
  • Небольшая компания лучше подходит для не самых крупных внедрений, однако надо чутко следить за ходом внедрения информационной системы;
  • Внедрение силами собственного ИТ подразделения, при данной схеме крайне высок риск перевода проектной деятельности в операционную, проект будет длится годами, а цели будут постоянно меняться;
  • Фрилансер – интересный подход к реализации, но требует кропотливого подхода к выбору персоны консультанта. К сожалению, руководителям инициировавшим внедрение информационной системы трудно определить уровень компетентности ИТ специалиста, ввиду отсутствия опыта проектной деятельности в ИТ сфере. Кроме того, ключевым фактором данной схемы может быть уровень возлагаемых на специалиста компетенций.

Исходя из того, что предложенные способы не идеальны.

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

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

С чего начинать внедрение информационной системы?

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

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

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

Такой важный момент, как стратегический план внедрения и выбор типа взаимоотношений с внедренцами информационной системы, важен, но не является единственным критерием. Эффективность внедрения информационной системы на предприятии зависит от нескольких факторов и готовности персонала учитывать их в работе. Специалисты выделяют несколько основных правил, игнорирование которых с большой вероятностью приведет к печальным последствиям:

  • Осознание необходимости внедрять современные технологические инструменты и готовность к внедрению всех сотрудников;
  • Изучение основ построения системы;
  • Грамотный выбор подходящей системообразующей программы и команды, отвечающей за ее внедрение;
  • Выделение квалифицированных кадров для контроля проекта со стороны заказчика;
  • Последовательная и четкая организация проекта;
  • Желание меняться к лучшему.

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



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

Если компания хочет не просто «для галочки» внедрить ИС, а действительно эффективно пользоваться всеми ее возможностями, предстоят следующие этапы:

  1. В первую очередь необходимо определить цель внедрения. Многие руководители высшего звена поверхностно относятся к этому этапу, но на самом деле он задает направление всему внедрению ИС;
  2. Обследование бизнес-процессов компании. В этот этап входят интервью с менеджментом, рядовыми сотрудниками, составление схем по каждому процессу. На выходе получается уточнение целей внедрения и возможность предварительно оценить объем работ и стоимость;
  3. Составление проекта, технического задания и регламента. В этих документах должны быть описаны все бизнес-процессы, участвующие во внедрении ИС. Старайтесь составлять проект внедрения максимально подробно, с указанием необходимых данных, их структуры, алгоритмов действий, рабочих мест;
  4. Подготовка специалистов. Сотрудники компании при начале внедрения должны знать, что от них требуется, чтобы не задерживать выполнение работы. Также администраторы и разработчики компании должны начать разбираться в информационной системе. То есть сотрудники расширяют свои знания на благо компании;
  5. Настройка информационной системы в соответствии со спецификой предприятия. В этот этап включается:
    • Разграничение прав на функционал системы для сотрудников;
    • Начальное заполнение данных;
    • Настройка алгоритмов расчетов, создание необходимых отчетов.
  6. Тестирование информационной системы. На этом этапе могут обнаружиться проблемы внедрения в разрезе алгоритмов или необходимость в новых отчетах;
  7. Опытная эксплуатация с реальными данными. Чаще всего на этом этапе многие сотрудники компании выполняют больше работы. Им приходится не только работать, как раньше, но и отражать свои действия в информационной системе. Требуется максимальная дисциплина и сосредоточение усилий всех участников внедрения. Конечным результатом должно стать совпадение данных информационной системы с реальным положением дел;
  8. Промышленная эксплуатация. На этом этапе осуществляется переход сотрудников на полноценную работу в информационной системе. Должна быть организована техническая поддержка пользователей;
  9. Завершение проекта. Основным результатом этапа являются подписанные должностные инструкции, разграничение обязанностей подразделений и их взаимодействия. Корпоративная информационная система запущена на предприятии.

Только согласованные усилия сотрудников компании на всех уровнях гарантируют продолжительную успешную работу информационной системы на предприятии.

Стратегия построения информационной системы

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

В общем виде три основных стратегии должны быть рассмотрены при выработке подхода к разработке системы управления проектами в организации:

· Разработка собственной специализированной системы или настройка существующих систем.

· Использование унифицированных систем календарного планирования и управления проектами, доступных на рынке.

· Интеграция существующих подсистем по функциям и по данным.

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

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

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


Что же нужно знать пользователю о предлагаемом программном обеспечении и собственных потребностях для того, чтобы сделать правильный выбор?

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

· только планирование или планирование и контроль хода проекта;

· планирование и контроль лишь сроков выполнения работ;

· планирование и контроль финансовых вложений без детального планирования использования ресурсов;

· детальное планирование использования ресурсов;

· многопроектное планирование и управление.

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

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

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

Разработка информационной системы

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

· Изучение и анализ возможностей автоматизации процедур управления;

· Проектирование и разработка системы;

· Тестирование и подготовка документации.

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

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

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

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

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

Проектирование включает разработку функциональной спецификации, спецификации обмена данными, технической спецификации, описывающей архитектуру системы, описание критериев и процедуры приемки системы.

Разработка включает поставку и настройку стандартных пакетов, доступных на рынке; разработку специализированных подсистем; поставку необходимого оборудования; интеграцию системы в целом.

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

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

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

Внедрение системы

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

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

Можно сформулировать несколько наиболее часто встречающихся ошибок планирования внедрения систем для управления проектами, которые являются причинами неудач освоения подобных систем:

· Цели проекта и ожидаемые результаты не определены заранее или определены не в полном объеме. Жесткие временные ограничения, нетерпеливость или непоследовательность руководства могут не позволить реализовать цели проекта в полном объеме.

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

· Планирование перевода сразу всей организации на использование системы для управления проектами. Это подобно попытке связать сразу всех сотрудников крупной организации в локальную вычислительную сеть. вместо того, чтобы осуществлять подключение пользователей последовательно, отдел за отделом.

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

· Последовательное внедрение в использование функций планирования и управления от простого к сложному. Рекомендуется начать с планирования и контроля временных параметров, затем освоить функции стоимостного планирования и контроля и только после этого переходить к ресурсному планированию. К интеграции системы управления проектами с другими системами лучше переходить после того, как процедуры использования основных ее функций освоены.

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

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

Литература

[I]. Л Guide to the Project Management Body of Knowledge (PMBOK), PMI, 1994.

. Andersen E, Grude K, Haug T, Turner J, Goal Directed Project Management, Kogan Page, 1995.

. Morris P, Managing Project Interfaces - Key Points for Project Success, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988.

. Meredith J., Mantel S., Project Management, Managerial Approach, Wiley, 1989.

. The Implementation of Project Management: The Professional Handbook, Wesley, 1991.

[б]. Полковникова Е.В., Полковников А.В., Планирование и управление проектами с использованием Time Line, Диалог-МИФИ, 1994.

. Thuman J, Development and Implementation of Project Management Systems, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988.

. Badiru A, Whitehouse G, Computer Tools, Models and Techniques for Project Management, TAB Professional and Reference Books, 1989.

. Levine H A, Project Management Using Microcomputers, McGraw Hill, 1986.

. Wall A, Project Planning and Control Using Micros, NCC Publications, 1988.


SQL (Structured Query Language) - стандартный, структурированный язык построения запросов к базам данных.

ODBC (Open Data Base Connectivity) - стандарт доступа к базам данных различных форматов.

Web - всемирная сеть, построенная по технологии Internet.

ASCII - формат сруктурированного текстового файла.