Экономическая информатика. Введение в экономический анализ информационных систем. Учебник

Лугачев М.И., Анно Е.И., Когаловский М.Р., Липунцов Ю.П., Скрипкин К.Г., Смирнов С.Н., Смирнова Е.Е.

Возрастное ограничение: 0+ Жанр: Экономика Издательство: МГУ Дата размещения: 14.01.2016 ISBN: 9785392172870 Язык: Объем текста: 850 стр. Формат: epub

Оглавление

Уважаемый читатель!

Предисловие

Раздел I. Экономическая информатика и информация

Глава 1. Объект, предмет и метод экономической информатики

Глава 2. Данные, информация и знания. Измерение и применение

Глава 3. Экономическая информация как стратегический ресурс

Раздел II. Техническое и программное обеспечение информационных систем

Глава 4. Основы автоматизации обработки информации

Глава 5. Организация и функционирование компьютеров

Глава 6. Компьютерные сети

Глава 7. Программное обеспечение компьютерных систем

Раздел III. Базовые технологии информационных систем

Глава 8. Основы технологий баз данных

Глава 9. Основы технологий текстового поиска

Глава 10. Технологии Веб

Раздел IV. Основы использования информационных систем в управлении

Глава 11. Классификация информационных систем

Глава 12. Информационная система и управление

Глава 13. Реализация стратегии компании с использованием информационных технологий

Раздел V. Управление современными информационными системами

Глава 14. Управление службой информационных систем: функции, процессы, метрики

Глава 15. Оценка затрат на сопровождение и развитие информационных систем

Глава 16. Проекты развития информационных технологий и перестройка организации

Глава 17. Стандартные методики внедрения сложных ИС. Экономический анализ проекта внедрения ис, осуществляемого по стандартной методике

Глава 18. Обеспечение безопасности и надежности функционирования информационных систем

Раздел VI. Электронный бизнес

Глава 19. Основные понятия электронного бизнеса

Глава 20. Основные модели электронного бизнеса

Глава 21. Технологические решения для электронного бизнеса

Глава 22. Платежные системы электронного бизнеса

Раздел VII. Социальные и правовые аспекты применения информационных систем

Глава 23. Право и этика в применении информационных систем

Глоссарий

Для бесплатного чтения доступна только часть главы! Для чтения полной версии необходимо приобрести книгу

Глава 17.
СТАНДАРТНЫЕ МЕТОДИКИ ВНЕДРЕНИЯ СЛОЖНЫХ ИС. ЭКОНОМИЧЕСКИЙ АНАЛИЗ ПРОЕКТА ВНЕДРЕНИЯ ИС, ОСУЩЕСТВЛЯЕМОГО ПО СТАНДАРТНОЙ МЕТОДИКЕ

Как было показано, проект реинжиниринга, основанный на внедрении информационной системы масштаба предприятия, весьма сложен для исполнения и характеризуется высокой степенью риска. Естественным способом снижения сложности и риска проекта является обобщение опыта успешных проектов данного класса в стандартных методиках. В настоящее время подобные методики имеют как производители соответствующего программного обеспечения (например, SAP, Oracle), так и ведущие консалтинговые фирмы (например, PricewaterhouseCoopers, Accenture — бывшая Andersen Consulting). Хотя эти методики различаются в деталях, они имеют ряд общих черт, которые и будут рассмотрены в этой главе. За основу взята методика ASAP (Accelerated SAP) фирмы SAP. Во избежание терминологической путаницы мы будем использовать разбиение проекта по стадиям, принятое в методологии Rational Software: начальная стадия, стадия уточнения, стадия конструирования, стадия развертывания. Каждая стадия, в свою очередь, разбивается на несколько этапов, которые будут рассмотрены в соответствующих параграфах данной главы. В дополнение к этим стадиям мы рассмотрим две обязательные функции, выполняемые на всех стадиях проекта, — управление проектом и управление системой (рис. 17.1). К функциям относятся работы, выполняемые на протяжении нескольких стадий проекта. При этом следует иметь в виду, что в фирменных методиках внедрения информационных систем, например в перечисленных выше, наименования могут быть иными.

Стандартная методика внедрения обеспечивает следующие преимущества:

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

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

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

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

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

5. Методики расчета технических требований к аппаратным средствам. Позволяют рассчитать для заданного класса серверов (обычно линейка серверов того или иного производителя) необходимое быстродействие процессора, объем оперативной памяти, дискового пространства и т.д.

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

Рассмотрим применение стандартных методик для отдельных стадий проекта.

17.1. НАЧАЛЬНАЯ СТАДИЯ

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

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

Рис. 17.2. Этапы начальной стадии проекта внедрения информационной системы

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

• формулирование идеи проекта в технических терминах, а не в терминах бизнеса (например, «внедрить систему R/З», а не «упорядочить процедуры закупок»);

• излишне широкие функциональные и/или организационные рамки проекта, не позволяющие реализовать его в разумные сроки;

• выбор неадекватной технической платформы (известен случай применения системы R/3 ради получения отчетности в формате GAAP);

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

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

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

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

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

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

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

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

• недостаточность ресурсного обеспечения проекта, т.е. недостаток сотрудников в проектных группах, отсутствие помещений и т.д.;

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

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

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

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

План работ включает в себя в качестве составных частей:

• сводный календарный план-график проекта;

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

• план формирования инфраструктуры ИТ, необходимой для проекта;

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

• описание процедуры пересмотра плана на последующих этапах проекта.

На двух последних пунктах следует остановиться подробнее. План управления системой касается работ по так называемому системному ландшафту. Под системным ландшафтом понимается совокупность серверов, установленных на них копий системы, правил переноса настроек, программ и данных из одной копии в другую и т.д. Методика ASAP требует как минимум трех независимых друг от друга копий системы R/3 — для разработки, для тестирования, для промышленной эксплуатации (в терминах компании SAP — продуктивной эксплуатации). Эти копии называются средой разработки, средой тестирования и продуктивной средой соответственно. Копии должны быть полностью изолированы друг от друга, фирма SAP рекомендует размещать их на различных серверах. Перенос данных между копиями должен быть строго регламентирован: в противном случае недостаточно протестированные данные из среды разработки или среды тестирования могут попасть в продуктивную среду и привести к сбоям в работе действующих сервисов ИТ. Кроме перечисленного системный ландшафт включает в себя способы и регламент резервного копирования, правила заведения в систему новых пользователей и т.д. Таким образом, технические риски проекта во многом зависят от того, насколько верно спроектирован системный ландшафт.

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

Бюджет проекта формируется следующим образом. Затраты на программное обеспечение определяются числом закупаемых лицензий, которые, в свою очередь, вытекают из функционального объема проекта и числа рабочих мест пользователей. Затраты на аппаратное обеспечение определяются выбранным системным ландшафтом. Предложения по необходимым параметрам закупаемого оборудования и его цене предоставляются производителями оборудования на основании данных о числе рабочих мест и используемых функций системы. Эта процедура получила название сайзинга (от англ. sizing — определение размера). Наконец, затраты на консалтинг определяются посредством распределения работ, установленных планом, между сотрудниками организации и внешними консультантами. Основные варианты взаимодействия организации с последними были описаны в соответствующем разделе. Внутренние затраты (заработная плата сотрудников, участвующих в проекте, помещение, оборудование рабочих мест и т.д.) определяются исходя из числа сотрудников проектных групп и предполагаемой продолжительности проекта. Таким образом, по описанным выше причинам должна быть предусмотрена процедура бюджета проекта.

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

К рискам данного этапа относятся:

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

• отсутствие плана управления системой;

• отсутствие процедуры пересмотра плана и/или бюджета проекта.

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

17.2. СТАДИЯ УТОЧНЕНИЯ

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

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

Описание бизнес-процесса состоит из следующих основных разделов:

• функциональная модель;

• каталог документов;

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

• описание справочника.

Рис. 17.3. Этапы стадии уточнения проекта внедрения сложной информационной системы

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

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

Лугачев М.И., Анно Е.И., Когаловский М.Р., Липунцов Ю.П., Скрипкин К.Г., Смирнов С.Н., Смирнова Е.Е. Экономическая информатика. Введение в экономический анализ информационных систем. Учебник

Лугачев М.И., Анно Е.И., Когаловский М.Р., Липунцов Ю.П., Скрипкин К.Г., Смирнов С.Н., Смирнова Е.Е. Экономическая информатика. Введение в экономический анализ информационных систем. Учебник

Рассматриваются основные составляющие информационных систем, использующихся для подготовки и принятия решений в экономике и бизнесе; информационные технологии, бизнес-приложения и функциональные подсистемы, а также управление информационными системами и их элементами. Формулируются подходы к анализу экономической эффективности информационных систем.<br> Предназначен для студентов, аспирантов и преподавателей экономических факультетов университетов и экономических вузов. Также может быть полезен специалистам по информационным технологиям при подготовке хозяйственных решений.<br> Учебник подготовлен при содействии НФПК- Национального фонда подготовки кадров в рамках Программы «Совершенствование преподавания социально-экономических дисциплин в вузах» Инновационного проекта развития образования. <br><br> <h3><a href="https://litgid.com/read/ekonomicheskaya_informatika_vvedenie_v_ekonomicheskiy_analiz_informatsionnykh_sistem_uchebnik/page-1.php">Читать фрагмент...</a></h3>

Внимание! Авторские права на книгу "Экономическая информатика. Введение в экономический анализ информационных систем. Учебник" ( Лугачев М.И., Анно Е.И., Когаловский М.Р., Липунцов Ю.П., Скрипкин К.Г., Смирнов С.Н., Смирнова Е.Е. ) охраняются законодательством!