Проект КИС предприятия и управление проектом

Поможем в ✍️ написании учебной работы

Имя

Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

Нажимая кнопку "Продолжить", я принимаю политику конфиденциальности

Проект КИС предприятия и управление проектом

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

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

Управление проектами отличают:

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

• необходимость формирования команды проекта;

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

• оценка трудоемкости этапов, процессов, процедур.

Управление проектом — это процесс применения знаний, навыков, методов, средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта (A Guide to the Project Management Body of Knowledge. PM I Standards Committee. 2000 Edition).

Управление проектом включает планирование, организацию, мониторинг и контроль всех аспектов проекта в ходе непрерыв-ного процесса достижения его целей (ISO/TR 10006: 1997. Quality Management — Guidelines to quality in project management).

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

Модели ЖЦ КИС. V-модель.

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

Модели ЖЦ КИС. RAD модель

В 1980-х гг. компания IBM начала применять метод быстрой разработки приложений (Rapid Application Development, RAD).

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

Характерной чертой метода RAD является короткое время перехода от определения требований до создания полной системы.

Модель RAD включает следующие фазы:

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

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

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

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

Преимущества модели RAD

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

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

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

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

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

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

• основное внимание уделяется не документации, а кодиро-ванию (программированию), при этом поддерживается принцип «получаете то, что видите» (What you see is what you get, WYSIWYG);

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

• повторное использование компонентов уже существующих программ.

Недостатки модели RAD

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

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

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

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

Концепции КИС. MRP и MRP II

Концепция MRP

В конце 1960-х гг. в работах О. Уайта и Американского об-щества по управлению запасами и управлению производством (APICS, American Production and Inventory Control Society) были сформулированы алгоритмы планирования, которые получили название MRP (Material Requirements Planning — планирование материальных потребностей). Методология MRP возникла как потребность формализовать бизнес-процессы, связанные с уп-равлением запасами.

Автоматизированные информационные системы, реализую-щие методологию MRP, получили название MRP-систем. Ос-новными задачами MRP-систем являются:

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

• расчет сроков, к которым они должны быть поставлены.

Специфика MRP-систем проявляется в следующем:

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

б) автоматическая поддержка уникальных идентификаторов объектов и использование их во всех подсистемах ИС;

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

Концепция MRP II

MRPII- это методология управления всеми производственны-ми ресурсами предприятия.

В состав систем класса MRPII входят следующие функцио-нальные блоки:

1. Бизнес-планирование (Business Planning, ВР). Формиро-вание долгосрочного плана предприятия в стоимостном выра-жении.

2. Планирование продаж и деятельности предприятия в це-лом (Sales and Operations Planning, S&OP). Преобразование биз-нес-плана в планы продаж основных видов продукции. Произ-водственные мощности учитываются лишь укрупненно. План носит среднесрочный характер.

3. Планирование производства (Production Planning, РР). План продаж по видам продукции преобразуется в объемный или объемно-календарный план производства видов продукции.

4. Разработка графика выпуска продукции (Master Production Scheduling, MPS). План производства преобразуется в график выпуска продукции, определяющий количество конкретных из-делий (или партий) с указанием сроков их изготовления. План носит среднесрочный характер

5. Планирование материальных потребностей (Material Require-ments Planning, MRP). Определение потребности в ма-териальных ресурсах, необходимых для обеспечения графика вы-пуска продукции, в количественном выражении и с учетом вре-менных параметров.

6. Планирование производственных мощностей (Capacity Requirements Planning, CRP). Определение и сравнение имею-щихся и требуемых производственных мощностей.

7. Различные системы оперативного управления производ-ством. Формирование оперативных планов-графиков работы.

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

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

Внедрение систем MRPII выявило ряд недостатков, свой-ственных системам данного класса.

1. Слабая интеграция с системами автоматизированного про-ектирования и конструирования продукции.

2. Слабая интеграция с автоматизированными системами проектирования технологических процессов и автоматизации производства.

3. Отсутствие связи с процессами управления финансами и кадрами.

Концепции КИС. ERP, ERP II

Концепция ERP

ERP-системы являются интегрированным (корпоративным) инструментом управления производственными процессами на предприятии, который:

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

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

• содержит описание тысяч стандартных бизнес-процессов;

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

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

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

• предоставляет актуальную, достоверную и непротиворе-чивую информацию для принятия управленческих решений;

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

• создает инфраструктуру для электронного обмена данными предприятия с поставщиками и потребителями;

• поддерживает Internet/Intranet/Extranet-технологии;

• обеспечивает высокую масштабируемость (несколько ты-сяч пользователей);

• поддерживает системы стандартов на проектирование ин-формационных систем;

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

• поддерживает клиент-серверную архитектуру и реализует-ся как открытые системы.

Базовые функции ERP-систем описаны в стандарте ISO / IEC 2382-24:1995. К ним относятся:

• управление финансовыми ресурсами (Financial Manage-ment);

• управление персоналом (Human Resources);

• ведение портфеля заказов (Customer Orders);

• управление запасами (Inventory Management);

• управление складами (Warehouse Management);

• управление закупками (Purchasing); ■

• управление продажами (Sales);

• управление сервисным обслуживанием (Service);

• прогнозирование объема реализации и продаж (Forecasting);

• объемное планирование (Master Production Scheduling);

• расчет потребностей в материалах (Materials Requirement Planning);

• оперативно-производственное планирование (Finite Scheduling);

• оперативное управление производством (Production Activity Control);

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

• расчет себестоимости продукции и затрат (Cost Accounting);

• управление транспортировкой готовой продукции (Trans-portation).

Концепция ERPII

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

Согласно концепции ERPII дальнейшее развитие прикладных систем для предприятий планируется по следующим на-правлениям.

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

2. Упрощение создания специализированных отраслевых ре-шений, интегрированных с базовыми функциями ERP-систем.

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

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

Внедрение КИС класса ERPII повышает конкурентоспособ-ность предприятий на рынке, синхронизируя и оптимизируя внутренние и внешние бизнес-процессы.

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

Концепции КИС. CIM.

Гибкая производственная система — «...управляемая средствами вычислительной техники совокупность технологического обору-дования, состоящего из разных сочетаний гибких производственных модулей и (или) гибких производственных ячеек, автома-тизированной системы технологической подготовки производства и системы обеспечения функционирования, обладающая свойством автоматизированной переналадки при изменении программы производства изделий» (ГОСТ 26228—90).

Внедрение ГПС позволяло:

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

• снизить зависимость производства от человеческого фактора;

• увеличить эффективность использования оборудования;

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

• оперативно реагировать на потребности рынка;

• повысить качество выпускаемой продукции.

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

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

• интеграция производственных бизнес-процессов на основе использования единых баз данных;

• создание интегрированной автоматизированной системы управления (ИАСУ) предприятием посредством интеграции всех подсистем планирования и управления (управления снабжением, проектированием и подготовкой производства; планирования и изготовления; управления производственными участками и цехами; управления транспортно-складскими системами; управления обеспечением оборудованием, инструментом и оснасткой; систем обеспечения качества, сбыта, а также финансовых подсистем).

Концепции КИС. CALS.

Аббревиатура CALS (Computer-aided Acquisition and Logistics Support) означала — компьютерная поддержка процесса поставок и логистики.

CALS-технологии позволяют:

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

• хранение данных в стандартных форматах;

• стандартизацию интерфейсов и электронного обмена ин-формацией между всеми участниками проекта.

Разработка новой концепции сохранила ту же аббревиатуру — CALS, но привнесла более широкую трактовку — Continuous Acquisition and Life circle Support — непрерывные поставки и информационная поддержка непрерывного жизненного цикла продукции. При этом первые две буквы аббревиатуры (СА — Continuous Acqusition — непрерывные поставки) означает не-прерывность информационного взаимодействия с заказчиком в ходе формализации его потребностей, формирования заказа, процесса поставки и т.д.

Третья и четвертая буквы — LS (Life Cycle Support — поддер-жка жизненного цикла изделия) означают системность подхода к информационной поддержке всех процессов жизненного цикла изделия, в том числе процессов эксплуатации, обслуживания, ремонта, утилизации и т.д.

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

Жизненный цикл (ЖЦ) продукции (изделия) — это совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворе-ния этих потребностей и утилизации продукции

Национальные стандарты

Государственным комитетом РФ по стандартизации и метрологии в 1989—1990 гг. документа под названием «Комплекс стандартов и руководящих документов на автоматизированные системы (ГОСТ 34.201—89, ГОСТ 34.602—89, РД 50- 682-89, РД 50-680-88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.698-90, ГОСТ 34.003-90, РД 50-34.119-90)»

В ГОСТах описаны все этапы создания автоматизированных систем, используемых в различных сферах деятельности, а также виды, наименование и комплектность документации, относящейся к каждому этапу ЖЦ системы.

ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств. Принят и введен в действие Госстандартом РФ в 1999 г. Стандарт устанавливает общую структуру и описывает лишь архитектуру процессов ЖЦ программных средств, но не определяет детали реализации или выполнения работ и задач, входящих в данные процессы.

Состав процессов жизненного цикла.

1. Основные процессы:

1.1. Процесс заказа. Определяет работы заказчика.

1.2. Процесс поставки. Определяет работы поставщика.

1.3. Процесс разработки. Определяет работы разработчика программного продукта.

1.4. Процесс эксплуатации. Определяет работы организации, которая обеспечивает эксплуатационное обслуживание И С в заданных условиях.

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

2. Вспомогательные процессы:

2.1. Процесс документирования. Определяет работы по описанию информации, выдаваемой в процессе ЖЦ.

2.2. Процесс управления конфигурацией.

2.3. Процесс обеспечения качества.

2.4. Процесс верификации.

2.5. Процесс аттестации.

2.6. Процесс совместного анализа. Определяет работы по оценке состояния и результатов какой-либо работы.

2.7. Процесс аудита. Определяет работы по определению соответствия требованиям, планам и договору.

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

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

Этапы внедрения КИС

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

Этап I. Тестирование. В результате фазы разработки создается бета-версия (бета-релиз) системы. На протяжении фазы внедрения выполняется бета-тестирование, которое позволяет собрать мнения пользователей о системе.

При планировании тестирования на фазе внедрения внимание уделяется следующим направлениям:

• продолжение проектирования и реализации тестов для поддержки дальнейшей разработки КИС;

• регрессионное тестирование (тестирование заново всей системы или отдельной функции системы);

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

В ходе тестирования решаются задачи:

• проверка стабильности работы системы;

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

• оценка качества системы;

• оценка тестов с точки зрения соответствия их целям тес-тирования.

Для определения момента завершения фазы внедрения ис-пользуются количественные показатели40.

1. Показатели, характеризующие выявление и устранение дефектов:

• сколько новых дефектов обнаруживается ежедневно;

• сколько дефектов исправляется ежедневно.

2. Показатели тестирования:

• количество выполненных тестов;

• количество ожидаемых новых дефектов,

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

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

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

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

• анализ потребности в дополнительных площадях для раз-вертывания системы;

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

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

• анализ потребностей в расширении вычислительной сети;

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

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

• анализ системы администрирования;

• конвертирование рабочих баз данных.

Этап 5. Оформление акта о внедрении. Перед оформлением акта о внедрении проводится приемочное тестирование вне-дряемой системы.

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

Известны следующие стратегии проведения приемочного тестирования.

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

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

• тесты тщательно планируются и проектируются с большой степенью детализации;

• исключается отклонение от выбранных и утвержденных прецедентов тестирования;

• процесс приемки может быть полностью автоматизирован;

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

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

Для неформальной приемки характерны следующие особен-ности:

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

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

• отсутствуют прецеденты тестирования;

• тестировщик самостоятельно определяет набор прецеден-тов тестирования;

• процесс тестирования более субъективен и менее автома-тизирован;

• выполняется организацией — конечным пользователем.

3. Бета-тестирование — проверка соответствия программной

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

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

Итак, в начале фазы внедрения необходимо:

• сформировать методологию внедрения;

• выбрать стратегию внедрения;

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

• выявить риски, характерные для фазы внедрения.

Основными видами работ в ходе реализации фазы внедрения являются:

• выполнение одного или более бета-тестирования внедря-емой системы;

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

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

• подготовка площадки для развертывания системы;

• конвертирование данных из старой системы в новую;

• оформление соглашения со всеми заинтересованными сто-ронами о том, что предприятие/компания готово для разверты-вания системы и что система соответствует критериям оценки, определенным в концепции (требованиям к системе);

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

[ЕС1]

[ЕС2]