Внедрение информационных систем. Внедрение информационной системы как способ совершенствования бизнес-процессов предприятия

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.

курсовая работа , добавлен 25.04.2012


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

дипломная работа , добавлен 20.07.2014


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

курсовая работа , добавлен 14.11.2017


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

презентация , добавлен 07.04.2013


Обзор принципов построения и эффективного применения систем управления базами данных, CASE-средств автоматизации проектирования. Анализ возможностей методологии и инструментальных средств. Разработка модели бизнес-процессов гостиницы в среде All Fusion.

курсовая работа , добавлен 28.12.2012


Наличие экономической информационной системы. Матрица организационных проекций. Разработка системы базы данных. Современные CASE-средства. Основные этапы разработки информационных систем. Абсолютный показатель и индекс снижения стоимостных затрат.

курсовая работа , добавлен 14.03.2011


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

курсовая работа , добавлен 07.04.2015


Роль инструментальных средств проектирования в создании информационной системы. Преимущества CASE-средств разработки Bpwin и Erwin, системы поиска, исправления ошибок модели данных Model Validator. Разработка модели процессов документооборота предприятия.

контрольная работа , добавлен 24.06.2012

Жизненный цикл информационных систем

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

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

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта приня­то разделять на фазы (стадии, этапы}.

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

Можно выделить следующие фазы развития информационной системы:

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

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

формирование ключевой команды проекта;

изучение мотивации и требований заказчика и других участников;

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

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

сравнительную оценку альтернатив;

представление предложений, их экспертизу и утверждение;

разработка технического задания. Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы:

• разработка основного содержания проекта, базовой структуры проекта;

  разработка и утверждение технического задания;

  планирование, декомпозиция базовой структурной модели проекта:

  составление сметы и бюджета проекта, определение потребности в ресурсах;

  разработка календарных планов и укрупненных графиков работ;

  подписание контракта с заказчиком;

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

проектирование. На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характер­ные работы этой фазы:

выполнение базовых проектных работ;

разработка частных технических заданий;

выполнение концептуального проектирования;

составление технических спецификаций и инструкций;

представление проектной разработки, экспертиза и утверждение.

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

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

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

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

схема программы отображает последовательность операций в программе;

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

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

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

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

выполнение подготовки к внедрению системы;

контроль и регулирование основных показателей проекта.

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

комплексные испытания;

подготовка кадров для эксплуатации создаваемой системы;

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

сопровождение, поддержка, сервисное обслуживание;

оценка результатов проекта и подготовка итоговых документов;

разрешение конфликтных ситуаций и закрытие работ по проекту;

накопление опытных данных для последующих проектов, анализ опыта, состо­яния, определение направлений развития.

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

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

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

ошибки в определении интересов заказчика;

концентрация на маловажных, сторонних интересах;

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

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

неполнота функциональных спецификаций (системных требований);

ошибки в определении требуемых ресурсов и сроков;

редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

9.4. Методология и технология разработки информационных систем

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

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

обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по авто­матизации деловых процессов;

гарантия создания системы с заданными параметрами в течение заданного вре­мени в рамках оговоренного заранее бюджета;

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

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

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

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

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

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

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

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

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

данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

методическими материалами, инструкциями, нормативами и стандартами;

программными и техническими средствами;

исполнителями.

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

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

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

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

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

технология должна обеспечивать возможность ведения работ по проектирова­нию отдельных подсистем небольшими группами (3-7 человек). Это обуслов­лено принципами управляемости коллектива и повышения производительно­сти за счет минимизации числа внешних связей;

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

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

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

9.4.1. CASE-технологии

CASE (Computer-Aided Software/System Engineering) как новое направление в программировании сформировалось за последние 10-15 лет.

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

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

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

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

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

Эта технология изменяет все стадии разработки ИС, более всего отражаясь на этапах анализа и проектирования

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

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

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

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

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

Помимо автоматизации структурных методологий CASE обладают следующими основными достоинствами:

улучшение качества создаваемого ПО за счет средств автоматического контроля;

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

ускорение процесса проектирования и разработки;

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

поддержка развития и сопровождения разработки.

В настоящее время CASE-технологии - одно из наиболее динамично развивающихся отраслей информатики, объединяющие сотни компаний. Из имеющихся на рынке CASE-технологий можно выделить: Application Development Workbench (ADW) фирмы Knowlegge Ware, BPwin (Logic Works), CDEZ Tods (Oracle), Clear Case (Alria Softwere), Composer (Texas Instrument), Discover Development Information System (Software Emancipation Technology).

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

Средства CASE-технологий делятся на две группы:

встроенные в систему реализации - все решения по проектированию и реализации привязаны к выбранной системе управления базами данных (СУБД);

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

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

диаграммы потоков данных (DFD - data dfow diagrams) совместно со словарями данных и спецификациями процессов;

диаграммы «сущность-связь» (ERD - entity relationship diagrams), являющиеся инфологической моделью предметной области;

диаграммы переходов состояний (STD - state transition diagrams), учитывающие события и реакцию на них системы обработки данных.

Другой класс CASE-технологий поддерживает только разработку программ, включая:

автоматическую генерацию кодов программ на основании их спецификаций;

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

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

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

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

Большинство специалистов считают, что хорошее инструментальное средство CASE должно обладать следующими качествами:

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

простота использования в сочетании с мощными функциями;

поддержка коллективной работы;

удобный просмотр иерархии классов;

возможность "нелинейной" разработки программ;

ввод программного кода в диаграмму с последующим ее обновлением;

наличие функции контроля версий;

распечатка больших диаграмм на стандартных страницах;

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

наличие анимации, с помощью которой можно наглядно моделировать поведение системы;

наличие хороших средств контроля ошибок, в том числе проверку на наличие логических ошибок;

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

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

Возможность генерации кода;

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

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

поддержка сложных моделей, в частности моделей финансовых потоков, деловой и производственной активности;

приемлемая цена.

Классификация CASE-средств по типам отражает их функциональную ориентацию в технологическом процессе.

Анализ и проектирование, создание спецификаций системы поддерживают следующие системы: CASE. Аналитик; Excelerator (Index Technology); Design-Aid (Nastec); Analist/Designer (Yourdon); Design/IDEF (Meta Software); SELECT (Select Software Tools); System Architech (Software&Systems) и др. На выходе продуцируются спецификации компонентов системы и интерфейсов, связывающих эти компоненты, а также предварительная архитектура системы; детальная проработка проекта, включающая алгоритмы и определение структур данных.

Проектирование баз данных и файлов предполагает использование следующих CASE-средств: ERWin (Logic Works); S- Designer (SDR), Designer/2000 (Oracle), Silverrun (Computer, Systems Advisers и др. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в 3НФ, автоматическую генерацию схем БД и описание форматов файлов на уровне программного кода.

Программирование. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полную документированную выполняемую программу: СOBOL 2/Workbench (MicroFocus); DECASE (DEC); NETRON/CAP (Netron), APS (Sage Software). Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики.

Сопровождение и реинжинеринг. К таким средствам относятся документаторы, анализаторы программ, средства реконструирования и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL & Super Structure (Computer Data Systems), Inspector/Recoder (Language Technology). Их целью является корректировка, изменение, анализ, приобретение и реинжениринг существующей системы.

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

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

динамические анализаторы (обычно компиляторы и интерпретаторы с встроенными отладочными возможностями);

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

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

средства доступа к спецификациям, их модификации и генерации нового (модифицированного кода);

средства реверсного инжиниринга, транслирующие коды в спецификации.

Окружение. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам Multi/Cam (AGS Management Systems), Sylva Foundry (Cagware).

Управление проектом – средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).

CASE-средства классифицируются также по категориям . Такая классификация определяет уровень интегрированности по выполняемым функциям и включает:

вспомогательные программы (tools) - решают небольшую автономную задачу, принадлежащую проблеме более широкого масштаба;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновление.

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

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

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

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

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

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

Подробности Опубликовано: 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.