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

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

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

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

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

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

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

К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них.

Критически важными для внедрения являются следующие факторы:

· наличие четко сформулированных целей проекта и требований к ИС;

· наличие стратегии внедрения и использования ИС;

· проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

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

· участие высшего руководства во внедрении системы;

· проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

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

· быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе ее опытной эксплуатации.

Перед началом разработки проекта внедрения необходимо:

· максимально формализовать цели проекта внедрения ИС;

· оценить минимально необходимые затраты и статьи расхода;

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

· наделить руководителя проекта максимально возможными полномочиями;

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

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

· распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

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

· организационное управление;

· организационно-административное обеспечение;

· управление бизнес-процессами;

· управленческий, планово-финансовый и бухгалтерский учет;

· управление персоналом;

· управление документацией;

· управление материально-техническим обеспечением;

· управление связями с клиентами и внешней средой.

Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:

· системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;

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

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

· распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

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

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

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

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

· распределение полномочий и ответственности;

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

· уточнение спецификаций и ожиданий заказчика;

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

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

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

· формируется и утверждается концептуальный проект;

· достигается обязательное однозначное понимание намерений всех участников проекта относительно внедряемой ИС;

· уточняются и конкретизируются цели и задачи проекта;

· определяются размеры прототипа системы;

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

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

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

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

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

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

7. Факторы успеха и причины неудачных внедрений ИС

моделирование информационный реинжиниринг бизнес

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

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

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

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

Первое. Определите цель проекта

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

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

· отсутствие единого формата представления данных управленческого учета.

· отсутствие регламентов формирования управленческих отчетов.

· отсутствие единой информационной среды

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

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

Глубокое осмысление целей проекта может привести к отказу от его осуществления или перенесению его сроков в связи с пересмотром приоритетов.

Цели автоматизации необходимо формулировать не в терминах технических преимуществ, а с точки зрения интересов бизнеса. Они могут определяться, например, таким образом:

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

· сокращение дебиторской задолженности, за счет информационного обеспечения работы с дебиторами;

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

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

Второе. Откройте проект

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

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

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

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

Третье. Обеспечьте проект ресурсами

Основные ресурсы - это деньги и люди. Поэтому необходимо утвердить бюджет проекта.

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

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

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

Четвертое. Позаботьтесь о мотивации

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

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

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

Пятое. Поддержка руководства

Успех возможен только в случае решительной поддержки проекта высшим руководством компании. Если генеральный директор считает, что внедрение автоматизированной системы - это дело только ИТ-службы, то ничего хорошего из этого не выйдет.

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

Шестое. Разбейте проект на этапы

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

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

Переходить к очередному этапу можно только после выполнения трех условий:

· команда проекта выработала единое понимание результатов этапа;

· это понимание оформлено в виде документа;

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

Такой подход позволяет контролировать риски проекта, двигаясь поступательно к намеченной цели.

Седьмое. Управляйте целями и ожиданиями

Цели проекта могут корректироваться или даже существенно меняться в ходе работы. Это обычная практика. Меняется обстановка, меняется наше понимание ситуации, и мы приходим к выводу, что прежние наши взгляды устарели, или были ошибочными. Поэтому нужно регулярно (на каждом этапе проекта) возвращаться?к истокам? и критически рассматривать все исходные предпосылки.

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

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

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

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

Программа реализуется с 2012 года.

За это время прошли обучение несколько сотен человек из Владивостока, Екатеринбурга, Тулы, Самары, Воронежа, Сочи, Новгорода, Читы, Москвы и других городов.

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

• Руководитель проектов в области информационных технологий (Утвержден Приказом Минтруда России №893н от 18.11.2014)
• Системный аналитик (Утвержден Приказом Минтруда России № 809н от 28.10.2014)

Форма обучения:	заочная (дистанционная)
Срок обучения по программе:	8 месяцев
Выдаваемый документ:	диплом установленного образца Высшей школы экономики о профессиональной переподготовке. Диплом дает право на ведение профессиональной деятельности в сфере управления информационными технологиями
Начало занятий:	05 июня 2019 года Прием документов до 25 мая 2019 года
Условия поступления:	Лица, имеющие среднее профессиональное или высшее образование; - лица, получающие профильное (техническое, экономическое, управленческое) высшее образование.
Стоимость	136 000 рублей. Оплата производится частями. Минимальный платеж - 1 раз за 2 месяца.

Подайте заявку на обучение

ЦЕЛИ ПРОГРАММЫ

• Дать слушателям необходимые теоретические знания в области системного анализа и ИТ-менеджмента;

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

Изучить практику управления ИТ-проектами в российских компаниях и организациях;

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

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

Структура и содержание программы

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

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

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

Для задания необходимой логики изучения, а также приобретения практических навыков, программа разбита на четыре блока с соответствующими контрольными практическими заданиями (КДЗ):

1. Анализ предметной области и формирование требований к ИС

• Информатизация предприятия
• Анализ требований к автоматизированным информационным системам
• Архитектура предприятия
• Моделирование бизнес-процессов
• Оптимизация бизнес-процессов
• Контрольное домашнее задание 1.

2. Разработка и проектирование ИС

• Модели жизненного цикла и методологии разработки корпоративных систем
• Технологии и средства разработки корпоративных систем
• Проектирование информационных систем
• Применение ГОСТ 34 в проектах создания современных автоматизированных систем
• Основы проектирования реляционных баз данных
• SQL и процедурно-ориентированные языки
• Контрольное домашнее задание 2

3. Внедрение ИС

• ИТ-стратегия
• Управление внедрением информационных систем
• Гибкая процессная методология Agile
• Управление проектами в соответствии со стандартом PMI PMBOK
• Управление проектами по технологии быстрого результата
• Контрольное домашнее задание 3.

4. ВЫПУСКНАЯ АТТЕСТАЦИОННАЯ РАБОТА

Особенности заочного (дистанционного) обучения

Материалы дисциплин представлены в виде видеофильмов или электронного текста.

Возможность обучения 24ч 7 дней в неделю: обучение и контроль знаний происходят полностью дистанционно в любое время суток и в любой стране мира. Для обучения слушателям нужны только компьютер и доступ в интернет.

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

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

Контроль знаний проводится после изучения каждой темы (лекции) и после завершения изучения каждой дисциплины. Это необходимое условие аттестации. Только этим задается определенная очередность изучения материала.

Большая практическая работа слушателя , с использованием информации, бизнес-процессов компании, в которой он работает. Для освоения полученных теоретических знаний и применения их на практике, по каждому блоку дисциплин слушатели выполняю контрольное домашнее задание . КДЗ – это письменная работа, в которой слушатели раскрывают выбранную тему, при желании используя реальную информацию своей практической деятельности. Или тема КДЗ может иметь аналитический аспект. Выполняется КДЗ под руководством научного руководителя, назначаемого из преподавателей и экспертов ВШБИ НИУ ВШЭ.

Реализация

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

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

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

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

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

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

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

Обработка результатов проектирования

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

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

• имеет ли каждая сущность конструктор - функцию, создающую экземпляры сущности (create);
• есть ли ссылки на данную сущность, то есть используется ли где-либо данная сущность (references);
• имеют ли место изменения данной сущности (update);
• имеет ли каждая сущность деструктор – функцию, которая удаляет экземпляры сущности (delete).

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

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

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

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

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

Системные модули

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

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

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

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

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

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

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

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

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

Интерфейсы

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

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

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

При обработке результатов запросов данных следует также особое внимание уделить вопросам соответствия типов включающего языка и СУБД, в том числе вопросам точности числовых типов, так как представление их у разных СУБД существенно различается. Кроме того, обратите внимание на запросы к данным, которые используют функции, зависящие от операционной системы, например функции работы с байтами и словами значения атрибута (например, на Intel и SUN SPARC эти функции будут работать по-разному). Типы данных могут быть приведены или явно в запросе функциями приведения cast и встроенными в СУБД функциями, или в функции прикладной программы. Не для всех СУБД неявное преобразование типов дает один и тот же результат, поэтому если информационая система использует данные из нескольких баз данных под управлением разных СУБД, то неявных преобразований типов лучше избегать.

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

Версии базы данных

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

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

• проконтролировать, какие объекты данных и данные имеют место в объектах загрузки A и B, и загрузить в базу данных только «разницу» A и B (произвести обновление версии);
• проконтролировать, не конфликтуют ли изменения, имеющие место в объектах выгрузки C и D, по сравнению с объектом выгрузки A (произвести слияние версий).

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

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

Размещение логики обработки

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

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

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

Шаблоны

Использование шаблонов и библиотек для построения «похожих» модулей - достаточно распространенная практика. Что использовать в этом случае - объекты и классы или библиотеки - решает конкретная группа разработчиков. Диктовать способ разработки в большинстве случаев бессмысленно, потому что разработчик пишет код так, как умеет или как привык. Эти моменты обычно контролирует руководитель проекта.

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

Тестирование

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking. Подобная система обеспечивает следующие функции:

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

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

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

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

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

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

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

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

Эксплуатация и сопровождение

пытная эксплуатация перекрывает процесс тестирования. Как правило, система вводится в эксплуатацию не полностью, постепенно.

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

накопление информации;

выход на проектную мощность.

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

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

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

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

Другие подходы к разработке приложений

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

• Все внимание сконцентрировано на экранных формах, а то, что касается правил обработки данных и системных функций, остается за кадром. Есть соблазн начать работу с отчетов, в то время как отчет является не стартовым, а производным продуктом информационной системы.
• Пользователи полагают, что если вариант прототипа согласован, то модуль готов. На самом деле это может быть всего лишь картинка с набором «заглушек» для вызовов системных функций и взаимодействия с другими модулями.
• Модули проектируются изолированно друг от друга (наверное, большинство из вас сталкивались с бухгалтерскими программами, где каждый АРМ является автономным и функции часто дублируются). Следствием этого являются противоречия модулей, дублирование функций и данных, что может быть выявлено только при тестировании комплекса модулей.
• Функциональные возможности наращиваются параллельно в нескольких направлениях, значит, структура базы данных должна контролироваться жестко. При УРП схема базы данных превращается в свалку, где таблицы «лепятся» наскоро, в результате чего имеет место набор противоречивых и дублирующихся данных.
• Документация при использовании метода УРП, как правило, отсутствует, а вернее, о необходимости документировать систему забывают, поскольку создается иллюзия, что пользователь и без того понимает, что происходит. Когда же приложение начинает работать не так, как предполагает пользователь, возникает масса проблем.
• Обработка исключительных ситуаций для каждого модуля производится своя.
• Целостная система, как правило, не получается, скорее всего, это будет некий набор автоматизированных рабочих мест, наскоро связанных между собой.

Методы УРП и СРП можно использовать далеко не всегда, а лишь в том случае, если:

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

Тем не менее методом УРП лучше разрабатывать небольшие и, желательно, автономные части проекта.

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

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

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

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

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

Метафора (metaphor). Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты.

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

Простой проект (simple design). В каждый момент времени разрабатываемая система выполняет все тесты и поддерживает все взаимосвязи, определяемые программистом, не имеет дубликатов кода и содержит минимально возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз».

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

Тесты (tests). Программисты постоянно пишут тесты для модулей (unit tests). Собранные вместе, эти тесты должны работать корректно. Для этапов в итерации заказчики пишут функциональные тесты (functional tests), которые также должны работать правильно. Однако на практике это не всегда достижимо. Чтобы принять правильное решение, необходимо понять, во сколько обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки на исправление дефекта.

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

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

Вот тут-то и начинается самое интересное. Экстремальное программирование исходит из того, что переделать всегда можно, причем без особых затрат. Однако практика свидетельствует об обратном.

Программирование в паре (pair programming). Весь код проекта пишут два человека, которые используют одну настольную систему.

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

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

Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее, чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты. Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются.

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

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

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

Заказчик с постоянным участием (on-site customer). Заказчик, который в период работы над системой находится в команде разработчиков.

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

40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одну рабочую неделю. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, являются сигналом серьезных проблем, которые требуют безотлагательного решения.

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

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

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

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

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

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

КомпьютерПресс 2"2002

Подробности Опубликовано: 14.07.2018 21:24 : рассматриваются базовые этапы внедрения корпоративных информационных систем. Кроме того выполняется обзор проектных документов каждого из этапов, а также демонстрируется зависимость данных заданной фазы на документы последующих этапов.
Скачать: PDF .
Ключевые слова: документы ERP систем, документирование внедрения корпоративных информационных систем, документирование информационных систем, документы в информационной системе, проектная документация ERP систем, рабочая документация ИС, техническая документация КИС, нормативные документы информационной системы, нормативные документы по проектированию информационных систем, документы внедрения ПО, документы внедрения информационных систем, этапы и документы внедрения программного продукта, опытная эксплуатация информационных систем, ГОСТ Р 54869-2011, ANSI PMBoK.

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

Цель и задачи

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

• обзор литературы, посвященной внедрению КИС;
• рассмотрение базовых этапов имплементации КИС;
• анализ проектных документов и их зависимостей от этапов.

1. Обзор подходов внедрения корпоративных информационных систем

Корпоративная информационная система представляется совокупностью информационных систем (далее - ИС), определяющих заданную предметную область. Существует несколько подходов внедрения ИС, применимых так же для имплементации КИС (рис.1). Начнем обзор с подхода, декларированного государством. Речь идет об отраслевых стандартах, в частности, ГОСТ Р 54869-2011 , а так же международном стандарте ISO 21500 . Документы содержат описание этапов управления проектами от процесса инициализации до завершения вне зависимости от вида реализуемой системы. Поэтому возможно использование указанных стандартов для реализации технических, информационных и корпоративных систем. Свод профессиональных знаний по управлению проектами, представленный ANSI PMI PMBoK , регламентирует процессы планирования, исполнения, проверки и воздействия от этапа инициирования до завершения проекта. Аналогично ГОСТ Р 54869-2011 и ISO 21500 допускается его применение для управления внедрением различных видов систем.

Рис. 1.

Методологии Accelerated SAP (далее - ASAP) , Accenture Delivery Methods (далее - ADM) , а также Microsoft Dynamics Sure Step (далее - MDSS) используются компаниями SAP, Accenture и Microsoft соответственно при внедрении пакетированных КИС решений. Подходы ориентированы исключительно на реализацию проектов имплементации КИС. В рассмотренных выше подходах используется преимущественно каскадная схема внедрения КИС . Данная схема характеризуется строгой временной зависимостью выполнения этапов проекта. Работы на заданном этапе могут выполняться только в том случае, если реализованы все активности предыдущей фазы проекта. Наименование этапов разнится от подхода к подходу, однако, содержание работ неизменно. Поэтому вполне реально сформировать единый перечень как операций, так и подготавливаемых документов. Подытожим результат анализа подходов внедрения КИС списком типовых этапов реализации проекта (рис.2).

Рис. 2.

2. Проектные документы типовых этапов реализации проекта

В предыдущем разделе были выделены типовые этапы реализации проектов по внедрению КИС, включающие

• подготовку проекта;
• проектирование;
• реализацию;
• подготовку к опытно-промышленной эксплуатации (далее - ОПЭ);
• ОПЭ;
• переход к продуктивной эксплуатации (далее - ПЭ)

и являющиеся общими для методологий ASAP, ADM, MDSS и стандартов . Допускается отсутствие этапа ОПЭ, тогда 4-я и 5-я фазы проекта будут обеспечивать подготовку к ПЭ и ПЭ соответственно. Рассмотрим документы каждого из этапов подробнее (рис.3).

Рис. 3.

2.1. Этап подготовки проекта

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

2.2. Этап проектирования

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

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

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

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

2.3. Этап реализации

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

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

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

2.4. Этап подготовки к опытно-промышленной эксплуатации

Реализация системы выполнена, и журнал проблем содержит незначительное число замечаний. Начинается подготовка к ОПЭ. Первоочередной задачей данного этапа является обучение конечных пользователей. Готовятся инструкции конечных пользователей (в разрезе бизнес-процессов или операций). Далее на их основе формируются сценарии обучения пользователей, включаемые в окончательный план обучения. Предполагаемый план обучения был создан ранее в контексте концепции обучения. Обучение пользователей проводится в условиях близких к реальным. Поэтому необходимо подготовить список участников и присвоить им реальные роли для выполнения тестовых упражнений. Тренинги являются своего рода тестированием системы, тем самым обновляется журнал проблем.

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

2.5. Этап опытно-промышленной эксплуатации

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

2.6. Этап перехода к продуктивной эксплуатации

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

3. Зависимость подготавливаемых документов от этапов проекта

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

Рис. 4.

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

Результаты и выводы

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

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

Литература

1. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2011. – 10 с.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. – NL.: Van Haren Publishing, 2013. – 148 p.
3. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013 – 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc, 1999. – 591 p.
5. Kress R. Running IT Like a Business: A Step-By-Step Guide to Accenture"s Internal IT. – Ely: IT Governance Publishing, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
7. Проектирование информационных систем: учебное пособие / Гвоздева Т.В., Баллод Б.А. – Ростов н/Д.: Феникс, 2009. – 508 с.
8. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
9. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.208-228.
10. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.

Управление информационными системами

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

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

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

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

Технологические элементы, обеспечивающие функционирование системы:

Информационную модель предметной области;

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

Программный комплекс;

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

Аппаратно-техническую базу;

Эксплуатационно-технические кадровые ресурсы;

Управленческие элементы, обеспечивающие организацию эксплуатации системы:

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

Регламент технической и пользовательской поддержки программного комплекса;

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

Регламент использования программного комплекса и пользовательские инструкции;

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

Задача проекта внедрения информационной системы включает в себя создание (адаптацию) и запуск в продуктивную эксплуатацию всех перечисленных выше элементов. О сложности этой задачи свидетельствует известная из результатов исследований Standish Group неутешительная статистика по успешности ИТ-проектов: в 1998 году только 26% проектов завершились в срок, не превысили бюджет и обеспечили реализацию предусмотренных функций.

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

Отсутствие постановки менеджмента на предприятии;

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

Необходимость изменения технологии бизнеса в различных аспектах;

Сопротивление сотрудников предприятия;

Временное увеличение нагрузки на сотрудников во время внедрения системы;

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

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

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

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

Нарушение принципа построения системы "сверху-вниз" и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления;

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

Кардинальная переработка базовой функциональности ERP-системы;

Нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы.

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

Факторы успеха проекта внедрения

Тетодологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов - их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками; а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои бизнес-процессы, адаптируя их под "лучший опыт", зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень:

Разработки компании Microsoft - методологии "OnTarget", "MSF (Microsoft Solutions Framework)", "Business Solutions Partner Methodology";

Разработки компании SAP - методологии "Процедурная модель SAP", "ASAP (Accelerated SAP)";

Разработки компании Oracle - комплекс методологий "Oracle Method".

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

Для Заказчика информационной системы основными результатами использования методологии являются:

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

Максимально эффективное использование ресурсов проекта;

Минимизация сроков и затрат на внедрение;

Уменьшение рисков проекта.

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

Появляется методическая база для обучения новых сотрудников стандартным методам внедрения;

Сокращаются внутренние расходы на организацию и реализацию проектов;

Улучшается взаимодействие и взаимопонимание между членами проектной группы;

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

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

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

Данные проектной документации не устаревают;

После выполнения каждой фазы проекта появляется возможность уточнить или скорректировать задачи к решению на последующих фазах;

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

Оптимизируются бюджет проекта и график платежей.

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

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

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

Составляющие методологии внедрения

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

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

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

2. Построение информационно_функциональной модели деятельности предприятия (IDEF), описание и оптимизация процессов, подвергающихся автоматизации.

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

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

3. Выполнение пилотного проекта.

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

4. Адаптация системы на предприятии.

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

5. Опытная эксплуатация ERP_системы.

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

6. Ввод системы в промышленную эксплуатацию.

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

7. Сопровождение промышленной эксплуатации.

← Вернуться