Главная страница
Финансы
Экономика
Математика
Информатика
Начальные классы
Биология
Медицина
Вычислительная техника
Сельское хозяйство
Ветеринария
Дошкольное образование
Логика
Этика
Религия
Философия
История
Воспитательная работа
Социология
Политология
Физика
Языки
Языкознание
Право
Юриспруденция
Русский язык и литература
Строительство
Промышленность
Энергетика
Электротехника
Автоматика
Связь
Другое
образование
Доп
Физкультура
Технология
Классному руководителю
Химия
Геология
Иностранные языки
Искусство
Культура
Логопедия
География
Экология
ИЗО, МХК
Казахский язык и лит
Директору, завучу
Школьному психологу
Языки народов РФ
Социальному педагогу
Обществознание
ОБЖ
Механика
Музыка
Украинский язык
Астрономия
Психология

ответы на вопросы. 1. Основные термины и определения предметной области


Скачать 279.21 Kb.
Название1. Основные термины и определения предметной области
Анкорответы на вопросы.docx
Дата07.05.2017
Размер279.21 Kb.
Формат файлаdocx
Имя файлаответы на вопросы.docx
ТипДокументы
#2796
страница1 из 3
  1   2   3

1. Основные термины и определения предметной области. 
Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определённого продукта или услуги для потребителей. В качестве графического описания деятельности применяются блок-схемы бизнес-процессов. Автоматизированная информационная технология (АИТ) – это совокупность методов и средств сбора, регистрации, обработки, передачи, накопления, поиска и защиты информации, ориентированных на использование программно-технических средств и средств связи (телекоммуникаций), включающая совокупность способов, с помощью которых информация предлагается клиентам. Ме́неджмент (от англ. management — управление, руководство, администрирование, дирекция, умение распоряжаться, владеть, управлять) или Управление производством — разработка и создание (организация), максимально эффективное использование (управление) и контроль социально-экономических систем. Управленческие технологии — это набор управленческих средств и методов достижения поставленных целей организации, включающий методы и средства сбора и обработки информации; приемы эффективного воздействия на работников; принципы, законы и закономерности организации и управления; системы контроля. Для фирм и предприятий, различающихся по численности, организационно-правовой форме, организации технологического процесса, могут быть эффективны различные типы управленческих технологий, а именно: управление по целям; управление по результатам; управление на базе потребностей и интересов; управление путем постоянных проверок и указаний; управление в исключительных случаях; управление на базе активизации деятельности персонала; управление на базе искусственного интеллекта и др. Организационная структура— документ, схематически отражающий состав и иерархию подразделений предприятия. Организационная структура устанавливается исходя из целей деятельности и необходимых для достижения этих целей подразделений, выполняющих функции, составляющие бизнес-процессы организации. Архитектура информационной технологии или системы (АИТС) — это комплекс взаимоувязанных решений на базе основополагающих принципов выбора стандартов и технологий для создания взаимодействующих программ в ИС, а также для формирования требований к необходимым для разработки и функционирования этих программ технологическим, техническим и телекоммуникационным средствам и иным видам обеспечения.
2. Автоматизированная информационная технология. Контура управления в организационных процессах. Понятие информации.

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

Классификация АИТ

По способу реализации в АИС –

традиционные технологии 

новые информационные технологии 

По степени охвата задач управления –

электронная обработка данных 

автоматизация функций управления 

АИТ поддержки принятия решений 

электронный офис, экспертная поддержка

По классу реализуемых технологических операций –

-  работа с текстовым редактором

-  работа с табличным процессором

-  работа с СУБД

-  работа с графическими объектами

-  мультимедийные системы 

-  гипертекстовые системы

По типу пользовательского интерфейса –

АИТ рассматриваются с точки зрения возможностей доступа пользователя к информационным и вычислительным ресурсам.

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

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

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

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

Информа́ция — сведения, воспринимаемые человеком или специальными устройствами как отражение фактов материального мира в процессе коммуникации.

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

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

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

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

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

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

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

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

4. Системная инженерия. Процессы ЖЦ систем. Стандарт Р ИСО/МЭК 15288.

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

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

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

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

  • Стадия замысла.

  • Стадия разработки.

  • Стадия производства.

  • Стадия применения.

  • Стадия поддержки применения.

  • Стадия прекращения применения и списания.

В версии стандарта от 2008 года (ISO/IEC 15288:2008) примеры стадий жизненного цикла отсутствуют

5. Понятие корпоративной архитектуры (стратегические цели, бизнес-процессы, ИТ-решения). Определения Microsoft.

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

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

6. Построение корпоративных архитектур. Стандарты SADT.

Архитектура предприятия является попыткой построить систему управления предприятием «сверху вниз». Есть множество различных моделей, позволяющих выбрать наиболее оптимальный вариант осуществления подобной трансформации, часть из них предлагает разнообразные версии структуры архитектуры предприятия (метамодели), раскрытые в моделях Захмана (Zachman Framework) или в модели US Federal EA, другие описывают подход к построению архитектуры предприятия (TOGAF). Компания SAP разработала методологию ведения архитектуры предприятия SAP EAF на базе TOGAF, которая ориентирована на интерпретацию и поддержку реализации целей компании посредством планирования и ведения специализированных описаний и представлений в следующих областях: бизнес-архитектура (в том числе бизнес-процессы, организационная структура); архитектура приложений; архитектура данных; техническая архитектура. Основное назначение SAP EAF – ускорение разработки архитектуры предприятия и снижение ее трудоемкости.

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

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

  • описание спецификаций требований и функций проектируемой системы;

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

В основе пакета лежит доведенное до уровня стандарта подмножество SADT методология IDEF, состоящая из трех методологий:

  • IDEF0 функциональное моделирование;

  • IDEF1 информационное моделирование;

  • IDEF2 динамическое моделирование функций, информации и ресурсов

7. Объекты корпоративной архитектуры (список объектов: Функции, Роли, Документы, регламенты, данные, Связи т.д.).

«корпоративную архитектуру» следует рассматривать в двух аспектах:

  • как объективную реальность, существующую независимо от ее отображения в чертеже или модели5;

  • как модель – описание этой реальности различными средствами.

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

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

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

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

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

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

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

При рассмотрении бизнес-архитектуры первая задача – разделить объект и субъект управления (см. рис.3). Т.е. сам бизнес и систему управления этим бизнесом!

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

  • Маркетинг и управление продажами;

  • Управление инвестициями;

  • Бюджетное управление и управленческий учет

  • Управление персоналом;

  • Логистическое управление;

  • Производственное планирование и контроль;

  • Управление жизненным циклом продукта.

  • Управление проектами.

  • Управление знаниями и т.п.

Роль корпоративной архитектурыpic3


8. История корпоративных архитектур ( Схема Захмана, TAFIM, TOGAF, ITMRA, FEAF, FEA, GARTNER)

Принято считать, что направление корпоративных архитектур появилось в 1987 году после публикации в IBM Systems Journal статьи Захмана «A framework for information systems architecture» («Инфраструктура для архитектуры информационных систем») [Zac]. В дальнейшем Захман переименовал инфраструктуру «информационных систем» в инфраструктуру «корпоративной архитектуры». Сегодня эта инфраструктура известна как инфраструктура Захмана.

В 1994 году Министерство обороны США представило архитектуру технического обеспечения для управления информацией (Technical Architecture Framework for Information Management, TAFIM) [TAF]. Архитектура TAFIM позиционировалась как новый стандарт корпоративной архитектуры для всех оборонных работ и прошла через ряд итераций, пока не была полностью отменена в 2000 году.

Хотя архитектура TAFIM больше не используется, некоторые ее принципы нашли применение в инфраструктуре архитектуры Open Group (TOGAF). TOGAF — это инфраструктура «с открытым кодом», контролируемая консорциумом Open Group. В настоящее время используется версия 8.1 [TOG]. По всей видимости, TOGAF — это наиболее популярная на сегодняшний день инфраструктура корпоративной архитектуры из используемых в частном секторе. Несколько реже используется модель Захмана.

В 1996 году развитие корпоративных архитектур ускорилось благодаря принятию Конгрессом США акта Клингера — Коэна, называемого также Законом о реформе управления информационными технологиями (Information Technology Management Reform Act, ITMRA). Этот закон предоставляет Административно-бюджетному управлению США (OMB) широкие права «анализа, отслеживания и оценки рисков и результатов всех крупных капиталовложений в информационные системы, совершаемых органами исполнительной власти».

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

Хотя в акте Клингера — Коэна ничего не говорится о корпоративной архитектуре, OMB расценило этот закон как поручение создать универсальную инфраструктуру корпоративной архитектуры для правительства США в целом. Эта инфраструктура получила название FEAF (Federal Enterprise Architectural Framework) [FEA]. Сегодня OMB требует от всех органов исполнительной власти, от Министерства юстиции до Министерства национальной безопасности и Министерства сельского хозяйства, разработать корпоративную архитектуру и показать, каким образом эта архитектура соотносится с FEAF.

Таким образом, фактическим результатом принятия акта Клингера — Коэна стало то, что все работы, относящиеся к ИТ и проводимые правительственными учреждениями США или для правительственных учреждений США, должны (по крайней мере, теоретически) выполняться в рамках единой, общей корпоративной архитектуры.
9) Архитектура предприятия по методологии Захмана

Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Термин "архитектура" здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС). архитДля удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

10) Методология TOGAF

Методология TOGAF  представляет собой инфраструктуру архитектуры предприятия, которая появилась 20 лет назад для разработки стандарта архитектуры предприятия. Фреймворк разработан независимым консорциумом The Open Group, для установки открытых стандартов в области информационных технологий.

TOGAF включает в себя 7 частей:

  1. Введение. Описание ключевых концепций.

  2. Методы разработки архитектуры.

  3. Руководящие принципы и методы.

  4. Содержимое фреймворка архитектуры.

  5. Континуум предприятия и инструменты.

  6. Эталонная модель TOGAF.

  7. Архитектурная возможность фреймворка.

Архитектура предприятия в TOGAF разделена на четыре домена (рис. 1)

http://technology.snauka.ru/wp-content/uploads/2013/12/1-300x195.jpg

Рисунок 1. – Компоненты архитектуры предприятия по TOGAF

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

Архитектура информационных систем описывает, как устроена ИС в компании. Обычно делится на две части:

  • Архитектура данных;

  • Архитектура приложений.

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

Структура ADM включает в себе 10 этапов:

  1. Предварительная фаза.

  2. Видение архитектуры.

  3. Бизнес-архитектура.

  4. Архитектура информационных систем.

  5. Техническая архитектура.

  6. Возможности и решения.

  7. Планирование миграции.

  8. Управление реализацией.

  9. Управление изменениями архитектуры

  10. Управление требованиями.


http://technology.snauka.ru/wp-content/uploads/2013/12/2.jpg

Рисунок 2 – Схема TOGAF ADM.

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

11.Технология BPMN

Модель и нотация бизнес-процессов (BPMN, Business Process Model and Notation) – методология моделирования, анализа и реорганизации бизнес-процессов. Разработана Business Process Management Initiative (BPMI), с 2005 г. поддерживается и развивается Object Management Group (OMG) [23]. В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» (EPC) или «национального» (IDEF0) стандарта, BPMN получила «международный» статус – Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology - Object Management Group. Business Process Model and Notation».

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

По заявлению разработчиков стандарта BPMN, он вобрал в себя лучшие идеи, что имеются в следующих нотациях и методологиях моделирования:

- UML (Unified Modeling Language, Унифицированный язык моделирования):

  • Activity Diagram (диаграмма деятельности);

  • EDOC (Enterprise Distributed Object Computing, корпоративная распределенная обработка объектов) – Business Processes (бизнес-процессы);

- IDEF (SADT);

- ebXML (Electronic Business eXtensible Markup Language, расширяемый язык разметки для электронного бизнеса) BPSS (Business Process Specification Schema, схемы спецификации бизнес-процессов);

- ADF (Activity-Decision Flow, поток «деятельность-результат») Diagram;

- RosettaNet;

- LOVEM (Line of Visibility Engineering Methodology, визуальная методология проектирования);

- EPC.

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

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

- объекты потока (Flow Objects);

- данные (Data);

- зоны ответственности (Swimlanes);

- соединяющие элементы (Connecting Objects);

- артефакты (Artifacts).

12.Международные стандарты в области ИТ-проектов

Международные стандарты управления проектами:

  • ISO 21500:2012, Guidance on project management (обзор [3] [3])

  • ISO 10006:2003, Quality management systems — Guidelines for quality management in projects

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

  • ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом» (Россия)

  • ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (Россия)

  • ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой» (Россия)

  • NASA Project Management (США)

  • BSI BS 6079 (Великобритания)

  • APM Body of Knowledge (Великобритания)

  • OSCEng (Великобритания)

  • DIN 69901 (Германия)

  • V-Modell (Германия)

  • VZPM (Швейцария)

  • AFITEP (Франция)

  • Hermes method (Швейцария)

  • ANCSPM (Австралия)

  • CAN/CSA-ISO 10006-98 (Канада)

  • P2M (Япония)

  • C-PMBOK (Китай)

  • South African NQF4 (ЮАР)

  • CEPM (Индия)

  • PROMAT (Южная Корея)


Стандарты с расширенной географией применения:

  • A Guide to the Project Management Body of Knowledge (PMBOK Guide)

  • PRINCE2 (PRojects IN a Controlled Environment)

  • ISEB Project Management Syllabus

  • Microsoft Solutions Framework (MSF)

  • Oracle Application Implementation Method (AIM)

Стандарты оценки компетенции менеджера проекта:

  • ICB IPMA Competence Baseline (IPMA)

  • НТК (Национальные требования к компетентности специалистов) (Ассоциация управления проектами«СОВНЕТ», Россия)

  • PMCDF (США)

  • NCB UA (National Competence Baseline, Version 3.0) (Украина)


13) Моделирование процессов workflow\ docflow в АИС.

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

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

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

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

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

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

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

Docflow - подсистема управления документооборотом и маршрутизацией документов с отслеживанием их состояний

АИС управления потоком документов (технология «docflow»). Ориентированы на использование форм электронных документов, при разработке которых планируются маршруты прохождения этих документов через специалистов определенных отделов. Обработка, исполнение и передвижение каждого документа в организации осуществляются согласно прописанному для него маршруту. Такие системы применяются для средних и крупных предприятий и организаций с большими потоками разнообразной документации, имеющих строго регламентированные процедуры обработки. Пример популярной АИС этого класса — Documentum.
14)Построение единого информационного пространства предприятия.

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

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

Примерный порядок построения единого информационного пространства предприятия следующий:

1. Обследование предприятия

Цели и основные задачи:

  • Четкое определение задач и целей проекта;

  • Формулирование функционально-технических требований к проекту;

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

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

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

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

  • Оценка рисков проекта;

  • Разработка предварительного плана проекта, графика работ и спецификации поставок по каждому этапу и проекту в целом.

Результаты обследования:

  • Отчет с фиксацией ситуации в виде «Как есть»;

  • Предложение по созданию информационной системы в виде «Как необходимо»;

  • Предложение по «Функционально-техническим требованиям к проекту»;

  • План реализации проекта;

  • Оценка рисков проекта и предложения по их минимизации;

  • Ориентировочная стоимость пилотного проекта и конечного решения.

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

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

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

  • Опытная эксплуатация решения;

  • Интеграция с ERP-системой;

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

3.    Обучение технического персонала и пользователей.

4.    Обеспечение дополнительного функционала – работы, выделенные на этапе обследования в отдельные этапы. Сюда опционально могут быть включены следующие работы:

  • Автоматизация процессов;

  • Справочники;

  • Интеграция с CAD системами, применяемыми на предприятии;

  • и т.д.
  1   2   3
написать администратору сайта