Задания. Департамент образования, науки и молодежной политики Воронежской области Государственное бюджетное профессиональное образовательное учреждение Воронежской области Лискинский промышленнотранспортный техникум имени А. К. Лысенко

• Название: Департамент образования, науки и молодежной политики Воронежской области Государственное бюджетное профессиональное образовательное учреждение Воронежской области Лискинский промышленнотранспортный техникум имени А. К. Лысенко
• Дата: 25.11.2022
• Размер: 7.79 Mb.
• Имя файла: Задания.doc
• Тип: Документы; #811196
• страница: 10 из 30

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



Рис.8. Матричная структура управления по проектам

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



Рис. 9. Проектная структура

Преимущества

1. 
   Комплексный подход к реализации проекта, решению проблемы;
   
2. 
   Концентрация усилий на решении одной задачи, на выполнении одного конкретного проекта;
   
3. 
   Большая гибкость структуры;
   
4. 
   Активизация деятельности руководителей проектов и исполнителей в результате формирования проектных групп;
   
5. 
   Усиление личной ответственности конкретного руководителя как за проект в целом, так и за его элементы.
   

Недостатки

1. 
   При наличии нескольких организационных проектов или программ проектные структуры приводят к дроблению ресурсов и заметно усложняют поддержание и развитие производственного и научно-технического потенциала компании как единого целого;
   
2. 
   От руководителя проекта требуется не только управление всеми стадиями жизненного цикла проекта, но и учет места проекта в сети проектов данной компании;
   
3. 
   Формирование проектных групп, не являющихся устойчивыми образованиями, лишает работников осознания своего места в компании;
   
4. 
   При использовании проектной структуры возникают трудности с перспективным использованием специалистов в данной компании;
   
5. 
   Наблюдается частичное дублирование функций.
   

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

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

- относительно большая самостоятельность руководителей дивизионов,

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



Рис.10. Дивизиональная структура управления

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

- быстрая реакция на изменения рынка,

- освобождение высших руководителей фирмы от оперативных и рутинных решений,

- снижение конфликтных ситуаций вследствие гомогенности целей в дивизионе.

К числу недостатков этой структуры относят:

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

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

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

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

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

по теме: «Разработка и оформление предложений по расширению функциональности информационной системы»
Цель: научиться разрабатывать и оформлять предложения по расширению функциональности информационной системы
По завершению практического занятия студент должен уметь: разрабатывать и оформлять предложения по расширению функциональности информационной системы

Продолжительность: 4 аудиторных часа (180 минут)
Необходимые принадлежности

Проектирование информационных систем: метод. указания к

лабораторным работам / сост. С.В. Капустина, А.В. Паршаков; ФГОУ ВПО

“СФУ”. – Красноярск, 2008. – 80 с.

Задание

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

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

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

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

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

1. 
   Функциональная модель бизнес-процесса.
   
2. 
   Описание бизнес-процесса и функциональные требования к процессу в целом (содержательная часть, в т. ч. цель, задачи, требования к исполнению и контролю, распределение ответственности, входная и выходная информация, требования к безопасности).
   
3. 
   Перечень и описание функций/процедур бизнес-процесса
   
4. 
   Описание требований к функциональности ИС по всем функциям/процедурам бизнес-процессов.
   
5. 
   Список входных и выходных документов.
   

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

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

6.7.3. Работы при выборе и обосновании продуктового решения

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

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

Основными недостатками заказной разработки являются следующие положения:

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

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

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

• 
  системы управления ресурсами предприятия (Enterprise Resource Planning, ERP - планирование ресурсов предприятия / Manufacturing Requirement Planning, MRP II - планирование производственных ресурсов/ Material Requirements Planning, MRP -- планирование материальных ресурсов);
  
• 
  системы управления активами и фондами (Enterprise Asset Management, EAM);
  
• 
  системы управления взаимоотношениями с клиентами (Customer Relationship Management, CRM);
  
• 
  системы управления цепочками поставок (Supply Chain Management, SCM);
  
• 
  системы управления персоналом (Human Resources Management, HRM);
  
• 
  системы документационного обеспечения управленческой деятельности;
  
• 
  системы управления эффективностью бизнеса (Business Performance Management, BPM);
  
• 
  системы интеллектуального бизнес-анализа (Вusiness Intelligence BI);
  
• 
  системы управления данными об изделии (Product Data Management, PDM).
  

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

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

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

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

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

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

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

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

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

В состав документа "Запрос предложения", как правило, включают следующую информацию:

1. 
   Общие сведения об организации.
   
2. 
   Цели организации, задачи, стратегический план (необходимые выдержки).
   
3. 
   ИТ-стратегию или тактический план (необходимые выдержки).
   
4. 
   Ожидаемые результаты проекта.
   
5. 
   Требования к программному продукту, включая требования к функциональности.
   
6. 
   Требования к поставщику решения.
   
7. 
   Требования по оформления и документарному составу предложения. Стандартные формы.
   
8. 
   Критерии и методику оценки предложений.
   
9. 
   Модель ценообразования.
   
10. 
    Основные договорные требования / проект договора.
    
11. 
    Контакты.
    
12. 
    Сроки и место представления предложений.
    

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

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

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

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

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

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

1. 
   Функциональные возможности.
   
2. 
   Архитектура: техническая инфраструктура, необходимая для поддержки решения.
   
3. 
   Устойчивость продукта: оценка в трех измерениях - финансы, структура и рынок.
   
4. 
   Цена: средняя стоимость приобретения, инсталляции, обновления версий и технической поддержки программного продукта.
   
5. 
   Сервис и поддержка: уровень технической поддержки, который обеспечивают поставщик и его партнеры.
   
6. 
   Концепция и видение: прогнозы поставщика относительно тенденций развития отрасли; действия поставщика в плане функциональности и стратегии развития продукта в свете этих прогнозов.
   

Поставщик оценивается в двух аспектах - стабильность и полнота концепции.

В настоящее время компанией Gartner Inc. запатентована методика "Magic Quadrant" (Магический Квадрант), которая заключается в подготовке отчета с графическим представлением определенного рынка продукции за некоторый период времени. Этот отчет сравнивает компании по набору критериев, разработанных для данного рынка, и отражает мнение исследовательской компании. В "Магическом квадранте" компании оцениваются по полноте видения рынка (completeness of vision) и по способности к практической реализации этого видения (ability to execute). В соответствии с этими критериями системы различных производителей располагаются в четырех квадрантах: "лидеры" (leaders), "провидцы" (visionaries), "бросающие вызов" (challengers) и "нишевые игроки" (Niche Players). К сектору лидеров компания Gartner Inc. относит поставщиков, которые успешно ведут свою деятельность, имеют четкую концепцию работы на рынке и активно совершенствуют свои возможности для реализации этой концепции и удержания своих лидирующих позиций,

Исследования компании Gartner Inc. предоставляют один из источников информации для проведения сравнительного анализа и не являются окончательной рекомендацией выбирать только того производителя, который оценен как "Лидер".

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

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

Следует отметить, что разработка состава критериев оценки программных продуктов по функциональности зависит от класса, к которому принадлежат рассматриваемые программные решения. Например, один из подходов к сопоставлению ERP-систем по функциональности разработан аналитической компанией Arlington Software Corporation в рамках проекта ERP Evaluation Center.

ERP Evaluation Center является ресурсом компании TEC Group, целью которого является анализ и сравнение, представленных на рынке ERP-систем. Согласно разработанному подходу для оценки функциональности используется дерево критериев, содержащее более 3600 частных критериев. Критерии нижнего уровня входят в критерии более высокого уровня со своими весовыми коэффициентами. Вершина дерева представляет собой комплексную численную оценку функциональности системы. В рамках проекта разработана таблица весов критериев и программные средства для решения многокритериальных задач. Помимо критериев функциональности для ERP-систем разработаны иерархии частных критериев для отдельных систем: CRM (более 1100 критериев), PLM (Product Lifecycle Management -управление жизненным циклом продукции, более 1300 критериев), SCM (более 2200 критериев), BI (более 1300 критериев).

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

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

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

Стандартное аппаратное и программное обеспечение, информационные системы имеют свои особенности как предмет конкурса.

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

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

Особенности информационной системы как предмета конкурса определяются следующими положениями:

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

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

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

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

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

Практическое занятие: