Systems Engineering Thinking Wiki - Вклад участника [ru]

Цепочки ценности

2025-02-06T16:12:19Z

Admin:

'''Цепочка ценности''' (англ. Value chain) — это инструмент [[Стратегирование|стратегического]] анализа, направленный на подробное изучение деятельности организации с целью стратегического планирования. Идея цепочки ценности была предложена Майклом Портером в книге «Конкурентное преимущество» для выявления источников конкурентного преимущества с помощью анализа отдельных видов деятельности компании. Цепочка ценности «разделяет деятельность компании на стратегически важные виды деятельности с целью изучить издержки и существующие и возможные средства дифференциации». Конкурентное преимущество компании возникает как результат выполнения этих стратегических видов деятельности лучше конкурентов.

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

[[Файл:value-chain.png|center]]

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

== Основные виды деятельности ==
В большинстве компаний, вне зависимости от того, в какой отрасли она работает, присутствуют пять групп основных видов деятельности:
# '''Входящая [[логистика]]''' (Inbound Logistics) — связана с приёмом и хранением материальных ресурсов, учётом и расписанием поставок;
# '''[[Операционный менеджмент|Операции]]''' (Operations) — все виды деятельности, направленные на превращение входящих потоков ресурсов в готовую продукцию: [[производство]], упаковка, сборка, обслуживание оборудования, [[Проверки и приемки|проверка]] на брак;
# '''Исходящая логистика''' (Outbound Logistics) — связана с подготовкой готовой продукции и транспортировкой её покупателю;
# '''[[Маркетинг]] и [[продажи]]''' (Marketing And Sales) — все мероприятия, которые информируют покупателей о предложениях компании и делают возможным совершение покупки;
# '''Сервис''' (Service) — виды деятельности по сохранению ценности продукта для покупателя: установка, [[ремонт]], обучение и обеспечение запасными частями.

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

== Вспомогательные виды деятельности ==
Вспомогательные виды деятельности отличаются от основных тем, что они обеспечивают деятельность одного или нескольких основных этапов, не работают непосредственно над продуктом и не взаимодействуют с клиентами. Выделяют четыре категории вспомогательных видов деятельности:
* '''снабжение''' — в отличие от входящей логистики, связано с процессом приобретения материальных ресурсов, а не непосредственно с самими ресурсами. К ресурсам относятся все материальные ценности, необходимые для функционирования предприятия, включая оборудование, недвижимость, офисные принадлежности и другие ресурсы.;
* '''[[развитие]] технологий''' — каждый вид деятельности в цепочке по-своему, но использует технологию, будь то ноу-хау, установленный регламент или технология, по которой работает оборудование. Виды деятельности в процессе развития технологий можно разделить на две группы:
** действия по улучшению продукта
** вспомогательные процессы
* '''[[HR|управление человеческими ресурсами]]''' — мероприятия по подбору, отбору, обучению, развитию и мотивации всех сотрудников организации. Вопросы, связанные с человеческими ресурсами, возникают на протяжении всей цепочки, поэтому некоторые действия распространяются на все элементы цепочки;
* '''инфраструктура компании''' — общий менеджмент, планирование, финансы, [[бухгалтерский учёт]], [[управление качеством]], решение юридических вопросов и [[GR|взаимодействие с государственными органами]]. В отличие от большинства вспомогательных видов деятельности, инфраструктура присутствует на всей цепочке и не относится ни к одному из этапов. Несмотря на репутацию центра затрат, инфраструктура может также являться источником конкурентного преимущества, так как бесперебойное функционирование всех систем компании приводит к более низким материальным и транзакционным издержкам и может выгодно отличать компанию от конкурентов.

== См. также ==
* [[Стратегирование]]
* [[OMG VDML]]

[[Категория: Технологии]]

Файл:Value-chain.png

2025-02-06T16:09:46Z

Admin:

S&TT

2024-04-17T09:59:54Z

Admin:

'''Strategic & Tactic Tree''' (дерево стратегии и тактики) – логическая диаграмма, включающая в себя все логические объекты и связи между ними, которые необходимы и достаточны для достижения цели [[предприятие|организации]]. Цель построения деревьев стратегии и тактики – выявить и устранить конфликты, возникающие из-за нарушения соотношения между деятельностью организации и ее целями. Предложена Элияху Голдраттом в 2002 году.

== Ссылки ==
* [https://www.tocico.org/page/strat_tact_portal Theory of Constraints International Certification Organization]
* [http://www.deming.ru/TehnUpr/PostrDerStrTak.htm Перевод варианта методики 2006 года на русский]

== См. также ==
* [[Архитектура предприятия]]

[[Категория: Концепции]]

Бережливое строительство

2024-04-16T03:16:51Z

Admin: Новая страница: «'''Бережливое строительство''' (Lean Construction) — управленческая стратегия в духе концепции «б…»

'''Бережливое строительство''' (Lean Construction) — управленческая стратегия в духе концепции «бережливого производства» в строительной отрасли, направленная на повышение эффективности всех этапов строительства.

Бережливое строительство предложено в 1992 году финским специалистом Лаури Коскела.

В 1997 году основан Институт бережливого строительства (LCI, Lean Construction Insitute).

== Инструменты бережливого строительства ==
В бережливом строительстве применяют ряд отраслевых инструментов, среди которых:
* система pull-планирования,
* интегрированная реализация строительных проектов,
* [[BIM|технология информационного моделирования зданий]],
* [[LastPlanner]]

Также используют общие инструменты бережливого производства:
* [[VSM|Карты потока создания ценности]],
* Диаграмму спагетти,
* Дерево целей,
* [[5S|Систему организации безопасного и эффективного рабочего места 5S]],
* Kaizen Events – мероприятие, направленное на решение проблемы в сжатые сроки с целью совершенствования процесса или системы.

[[Категория:Бережливое производство]]

LastPlanner

2024-04-16T03:15:46Z

Admin:

'''LastPlanner''' примененяется к управлению проектами концепций [[Бережливое строительство|бережливого строительства]] (lean construction) и производства (lean manufacturing), развитие идей Toyota.

== Особенности ==
* Множество академических работ.
* Широкое использование в строительстве, международное признание.
* Успешность сравнима с использованием [[TOC]]/[[CCPM]]
* Акцент на коммуникации участников проекта – цикл «запрос-обещание-отчёт-подтверждение» (см. [[DEMO]]), коллаборативное планирование людьми, ведущими работы – «последними планировщиками»
* Конкретные методики планирования:
** Предписанные уровни разбиения работ (проект, фаза, операция, процесс, шаг)
** Поздний старт работ – pull
** Скользящее окно планирования, составление графиков по фазам проекта

[[Категория:Стандарты управления проектами]]
[[Категория:Бережливое производство]]

Категория:Бережливое производство

2024-04-16T03:01:38Z

Admin: /* Отраслевые варианты */

'''Бережливое производство''' (от англ. lean production, lean manufacturing — «тощее производство») — концепция управления производственным предприятием, основанная на постоянном стремлении к устранению всех видов потерь. Бережливое производство предполагает вовлечение в процесс оптимизации бизнеса каждого сотрудника и максимальную ориентацию на потребителя. Возникла как интерпретация идей производственной системы компании Toyota американскими исследователями её феномена.

== Основные принципы ==
Бережливое производство как процесс включает пять этапов:
# Определить ценность конкретного продукта.
# Определить поток создания ценности для этого продукта.
# Обеспечить непрерывное течение потока создания ценности продукта.
# Позволить потребителю вытягивать продукт.
# Стремиться к совершенству.
Среди других принципов выделяются:
* достижение превосходного качества (сдача с первого предъявления, система «ноль дефектов», обнаружение и решение проблем у истоков их возникновения),
* гибкость,
* установление долговременных отношений с потребителями (путём деления рисков, затрат и информации).

Производственная система Toyota основывается на двух базовых принципах:
# «точно вовремя» - необходимые для сборки детали должны поступать на производственную линию строго в тот момент, когда это нужно, и строго в необходимом количестве с целью сокращения складских запасов,
# принцип автономизации (autonomation).

Впоследствии в рамках концепции бережливого производства было выделено множество элементов, каждый из которых представляет собой определённый метод, а некоторые (например, [[Кайдзен]]) сами претендуют на статус самостоятельной производственной концепции:
* поток единичных изделий
* [[Канбан]]
* [[TPM]] (англ. total productive maintenance, всеобщий уход за оборудованием)
* [[5S]]
* [[SMED]] (быстрая переналадка)
* [[Кайдзен]]
* Пока-ёкэ («защита от ошибок» и бака-ёкэ — «защита от дурака») — метод предотвращения ошибок.

== Отраслевые варианты ==
'''Бережливая логистика''' (лин-логистика) — вытягивающая система [[Логистика|логистики]], объединяющая всю цепь поставщиков, задействованных в потоке создания ценности, в которой происходит частичное пополнение запасов небольшими партиями, основной показатель такой системы — Совокупная логистическая стоимость (англ. total logistics cost, TLC).

'''Бережливое здравоохранение''' — концепция сокращения затрат времени медицинского персонала, не связанной непосредственно с помощью пациентам.

'''Lean-почта''' — в почтовом ведомстве Дании в рамках осмысления концепции бережливого производства проведена масштабная стандартизация всех предлагаемых услуг для повышения производительности труда, ускорения почтовых пересылок, для идентификации и контроля почтовых услуг введены «карты поточного создания их ценности», разработана и внедрена система мотивации почтовых служащих.

'''[[Бережливое строительство]]''' — управленческая стратегия в духе концепции «бережливого производства» в строительной отрасли, направленная на повышение эффективности всех этапов строительства.

'''Бережливая разработка программного обеспечения''' — адаптация принципов «бережливого производства» для разработки программного обеспечения.

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

== Литература ==
* [http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/ref=sr_1_1?ie=UTF8&qid=1415178117&sr=8-1&keywords=Lean+from+the+Trenches '''Lean from the Trenches: Managing Large-Scale Projects with Kanban''' by Henrik Kniberg] - история масштабирования одного крупного проекта;
* [http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ '''Scaling Lean & Agile Development''' by Craig Larman] - если у вас работает больше одной команды и вам надо синхронизировать их работу;
* Running Lean: Iterate from Plan A to a Plan That Works (2012);
* The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (2011);
* Lean Analytics: Use Data to Build a Better Startup Faster (2013);
* The Lean Entrepreneur: How Visionaries Create Products, Innovate with New Ventures, and Disrupt Markets (2013);
* Lean UX: Applying Lean Principles to Improve User Experience (2013);
* The Principles of Product Development Flow: Second Generation Lean Product Development (2009);
* Lean Software Development: An Agile Toolkit (2003);
* Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (2010);
* Implementing Lean Software Development: From Concept to Cash (2006);

[[Категория:Практики организационного развития]]

V-диаграмма

2024-04-11T06:10:52Z

Admin:

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

[[File:V-diagramm_ШСМ.png|center]]

На рисунке горизонтальная пунктирная линия отделяет [[Практика|практики]] и [[Работа|работы]] системной инженерии (сверху) от практик и работ предметной/прикладной инженерии (снизу). Так что из диаграммы видно, что практики системной инженерии встречаются главным образом на начальных и конечных стадиях проекта, а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями.

== Особенности ==
V-диаграмма поясняет самые общие черты системноинженерного процесса/метода/жизненного цикла:
* Фундаментальную разницу между практиками определения системы (работы с информацией), реализации системы (работы с веществами и полями), а также использованием системы. В том числе на V-диаграмме показывается основная идея системной инженерии “восемь раз отмерь, один раз отрежь”: рекомендуется максимизировать трату ресурсов на более ранних стадиях, чтобы потом экономить трату много больших ресурсов на более поздних стадиях.
* Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация).
* Ведущие практики жизненного цикла (дисциплины-рабочие продукты- инструменты).
* Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и “обычными” инженерными практиками, имеющие дело с частями системы.
* Взаимодействие между практиками: работа идёт отнюдь не по той практике-стадии, которой соответствует точка времени на диаграмме! Нет, одновременно задействована вся “вертикаль” практик — архитектор общается и с инженерами по требованиям, и с занимающимися рабочим проектированием, а инженер-интегратор общается и с эксплуатационщиками, и с производителями оборудования.

Должно быть так: «что определяли, то и воплотили» - это обеспечивают практики [[Проверки и Приемки|проверки и приёмки]] (validation, verification).

[[File:V-diagramm.png]]

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

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

== Модификации ==
* [http://en.wikipedia.org/wiki/Dual_Vee_Model Dual V-model]

[[Категория:Модели ЖЦ]]

Файл:V-diagramm ШСМ.png

2024-04-11T06:10:39Z

Admin: Admin загрузил новую версию Файл:V-diagramm ШСМ.png

Файл:V-diagramm ШСМ.png

2024-04-11T06:09:24Z

Admin:

Воплощение системы

2024-04-08T10:03:24Z

Admin: /* Дисциплины */

'''Воплощение системы''' (system realization, буквально: вынос в реальность) — это [[Единство научного знания|4D]]-воплощение системы в материалом мире, организованное в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.

Альфой воплощения системы занимается системный инженер.

== Дисциплины ==
:[[Производство]]:
:# изготовление отдельных частей (System Implementation)
:# [[Комплексирование|сборка]] (System Integration)
:# [[Верификация|проверки]] (Verification)
:# [[Валидация|приемки]] (Validation)

== Состояния ==
[[OMG Essence]] определяет следующие состояния для альфы "Воплощение системы" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:

{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold; width:4%" | №
! style="text-align: center; font-weight: bold; width:10%" | Состояние
! style="text-align: center; font-weight: bold; width:10%" | State
! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
! style="text-align: center; font-weight: bold; width:60%" | Контрольные вопросы
|-
| 1
| style="font-weight: bold;" | В виде сырья
| as a raw material
| материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей системы
| ❑ Материалы для воплощения системы наличествуют и позволяют создать детали с нужными характеристиками.

❑ Оборудование для переработки материалов в детали наличествует.

❑ График производства и логистики частей системы согласован.

❑ Возможны работы по изготовлению частей.
|-
| 2
| style="font-weight: bold;" | В виде частей
| as a parts
| части воплощения системы созданы и/или закуплены и проверены; график интеграции/сборки/монтажа/строительства из частей согласован; возможны работы по интеграции/сборке/монтажу/строительству
| ❑ Части системы созданы и/или закуплены и проверены.

❑ График интеграции (сборки, монтажа, строительства) из частей согласован.

❑ Возможны работы по интеграции (сборке, монтажу, строительству).
|-
| 3
| style="font-weight: bold;" | Демонстрируемо
| demonstrable
| воплощение системы может быть опробовано в отдельных функциях и ключевые характеристики могут быть измерены; ключевые характеристики могут быть продемонстрированы внешним проектным ролям; критические интерфейсы системы были продемонстрированы; система готова к проверке; необходимые внешние проектные роли согласны, что систему нужно проверять
| ❑ Система может быть опробована в её отдельных функциях и её ключевые характеристики могут быть измерены.

❑ Ключевые характеристики системы могут быть продемонстрированы.

❑ Критические интерфейсы были продемонстрированы.

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

❑ Необходимые стейкхолдеры согласны, что систему нужно проверять.
|-
| 4
| style="font-weight: bold;" | Готово
| ready
| функциональность протестирована; уровни дефектов для внешних проектных ролей приемлемы; установочная и другая пользовательская и операторская документация доступна; представители/исполнители внешних проектных ролей удовлетворены системой; состав передаваемой системы известен; представители/исполнители внешних проектных ролей готовы эксплуатировать систему; эксплуатационная поддержка наличествует
| ❑ Функциональность, обеспечиваемая системой, протестирована.

❑ Уровни дефектов приемлемы для стейкхолдеров.

❑ Установочная и другая пользовательская документация доступна.

❑ Представители стейкхолдеров принимают систему, как удовлетворяющую своему назначению.

❑ Состав передаваемой стейкхолдерам системы известен.

❑ Представители стейкхолдеров хотят принять систему в эксплуатацию.

❑ Эксплуатационная поддержка наличествует.
|-
| 5
| style="font-weight: bold;" | Эксплуатируется
| operational
| доступна внешним проектным ролям для эксплуатации в рабочем окружении; есть как минимум один пример работающей системы; поддерживается на согласованном уровне сервиса
| ❑ Система сделана доступной стейкхолдерам, которые намерены её использовать.

❑ Есть как минимум один пример полностью работающей системы.

❑ Система полностью поддерживается на согласованном уровне сервиса.
|-
| 6
| style="font-weight: bold;" | Выведено из эксплуатации
| retired
| Воплощение системы заменено или прекращено в использовании; система больше не поддерживается; нет «официальных» внешних проектных ролей, которые до сих пор используют систему; доработки/доделки системы больше не будут производиться; все материальные компоненты системы либо повторно используются, либо надлежащим образом уничтожены
| ❑ Воплощение системы было заменено или прекращено в использовании.

❑ Система больше не поддерживается.

❑ Нет «официальных» стейкхолдеров, которые до сих пор используют систему.

❑ Доработки /доделки системы больше не будут производиться.

❑ Все материальные компоненты системы либо повторно используются, либо надлежащим образом ликвидированы.
|}

[[Категория:Концепции]]
[[Категория: Альфы]]

Определение системы

2024-04-08T09:55:53Z

Admin: /* См. также */

'''Определение системы''' или '''Описание системы''' (system definition) — информация о [[Воплощение системы|воплощении системы]].

Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что “неопределено” (задача “пойди туда, не знаю куда, найди то, не знаю что” — это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырёхмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, “определить” её).

Альфой определения системы занимается системный инженер.

Описания системы легко отличить от [[Воплощение системы|воплощений системы]] и [[Документация системы|документов системы]] — '''они не занимают места в физическом мире''', у них нет объёма и координат в этом мире, они абстрактны, «идеальны», нематериальны как противоположность материальному/физическому. Системы и системные документы (документы о системах) материальны, они занимают место в физическом мире.

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

== Основные подальфы ==
Определение системы как альфа включает в себя основные подальфы (это только основные подальфы, их может быть много больше):
* [[Требования]] (определение системы как “чёрного ящика”) - "[[техническое задание]]"
* [[Архитектура]] (важнейшие инженерные решения, определяющие систему как “прозрачный ящик”) - "эскиз", "[[Проектная документация|проектная документация]]"
* [[Неархитектурная часть проекта]] (все инженерные решения, которые будут сочтены не самыми важными) — “[[рабочая документация|рабочая документация]]”.

Часто выделяют проект/design как совокупность архитектурной и неархитектурных частей (вся архитектура — это design, но не весь design это архитектура). А ещё есть “исполнительная документация” — это описание системы “как построено/изготовлено” ('''as built''') в отличие от “[[Проектная документация|проектной документации]]” ('''as designed''').

== Рабочий продукт ==
[[Документация системы]]

== Дисциплины ==
* [[Инженерия требований]],
* [[Проектирование]] и [[конструирование]] (включающие работу с архитектурой системы).

== Практики ==
'''Практики описания системы''' — это просто практики записи, они не подразумевают какого-то выдумывания описываемой системы.

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

Эти практики описания не нужно путать с практиками инженерии ([[Инженерия требований]], [[Инженерия системной архитектуры]], [[Проверки и приемки]]):
* '''Практики инженерии''' учат тому, как придумать соответствующие определения системы (альфы).
* '''Практики описания''' — как создать рабочие продукты, документирующие принятые при определении системы инженерные решения. Писарь, пишущий под чужую диктовку знакомыми ему иероглифами — это не инженер. Это писец. Инженер — это тот, кто придумывает инженерные решения, которые потом (обычно сам!) записывает иероглифами соответствующих нотаций, плюс потом инженер ещё и воплощает придуманное.

== Обобщение ISO 42010 на определение системы ==
'''Описания''' — это [[Рабочий продукт|рабочие продукты]], которые выражают определение системы.

[[Метод описания|Группа описаний]] (view) группирует отдельные [[Модель|модели]]/отдельные описания (model). Так, финансовая группа описаний может группировать баланс и отчёт о прибылях и убытках, архитектурная группа описаний может группировать компонентные, модульные и описания размещения, а также какие-то гибридные описания. Каждая группа описаний имеет свой [[Метод описания|метод описаний]] (viewpoint). Тематический метод описания задаёт тематическую группу описаний по определенной тематике.

Любые группы описаний существуют только потому, что есть [[Стейкхолдер|стейкхолдеры]], заинтересованные в системе в той части, которая этими описаниями описываются. Если нет стейкхолдера, которому это описание нужно, то описания просто не должно быть — зачем трудиться для создания того, что не будет никем использовано? Если заинтересованный стейкхолдер есть, но нет нужного ему описания — большая вероятность, что интересы стейкхолдера не будут учтены (помним, что успешной системой называется та, которая удовлетворяет стейкхолдеров.

[[Воплощение системы]] удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы.

== Состояния ==
[[OMG Essence]] определяет следующие состояния для альфы "Определение системы" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:

{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold; width:4%" | №
! style="text-align: center; font-weight: bold; width:10%" | Состояние
! style="text-align: center; font-weight: bold; width:10%" | State
! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
! style="text-align: center; font-weight: bold; width:60%" | Контрольные вопросы
|-
| 1
| style="font-weight: bold;" | Замыслено
| Concieved
| внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.
| ❑ Ясно, что будет считаться успехом для новой системы

❑ Методы описания системы согласованы

❑ Способ согласования описаний со стейкхолдерами согласован

❑ Механизмы управления конфигурацией описаний согласованы
|-
| 2
| style="font-weight: bold;" | Непротиворечиво
| Coherent
| описания системы документированы, и документация доступна команде и стейкхолдерам; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система принимается внешними проектными ролями как заслуживающая воплощения.
| ❑ Описания документированы и доступны команде и стейкхолдерам

❑ Происхождение описаний ясно

❑ Описания проверяются

❑ Противоречивые описания идентифицированы и ими занимаются

❑ Команда понимает описания и соглашается их воплотить

❑ Система, соответствующая описаниям, принимается стейкхолдерами как заслуживающая воплощения
|-
| 3
| style="font-weight: bold;" | Используется для изготовления
| In use for manufacturing
| изготавливающая систему часть команды считает, что описаний хватает для начала изготовления; технологии изготовления описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.
| ❑ Подготовлено достаточное количество описаний системы, чтобы начать изготавливать систему

❑ Технологии изготовления определены

❑ Часть команды, изготавливающая систему, признаёт описания достаточными для изготовления системы

❑ Возникающие при изготовлении проблемы приводят к переработке и актуализации определения системы
|-
| 4
| style="font-weight: bold;" | Используется для проверки и приёмки воплощения
| In use for V&V
| есть все описания, нужные для проверки и приёмки; испытания, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний.
| ❑ Нет частей определения системы, без которых проверки невозможны

❑ Проверки, критерии их успешности и способ их проведения определены

❑ Стейкхолдеры согласны с объемом проверок
|-
| 5
| style="font-weight: bold;" | Используется для эксплуатации
| In use for operations
| описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации.
| ❑ Определение системы используется для сбора информации о состоянии эксплуатируемого воплощения системы

❑ Определение системы наряду с информацией о состоянии эксплуатируемой системы используется для принятия решений о техобслуживании, ремонтах, модернизации
|-
| 6
| style="font-weight: bold;" | Используется для вывода из эксплуатации
| In use for retirement
| используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.
| ❑ Определение системы используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации

❑ Определение системы демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе системы из эксплуатации

❑ Определение системы используется для планирования и проведения работ по ликвидации и/или переработке воплощения системы
|}

== См. также ==
* [[Конфигурация системы]]

[[Категория: Концепции]]
[[Категория: Альфы]]

DEMO

2024-04-04T08:56:18Z

Admin: /* Концепция */

'''[http://www.demo.nl/ DEMO]''' (Design and Engineering Methodology for Organisations) — методология проектирования и инжиниринга [[предприятие|организаций]].

DEMO описывает положения теории речевых актов в отношении к [[Инженерия предприятия|инженерии предприятий]].

{{youtube|jx7WH_ur_94|500}}

== Концепция ==
В DEMO все действия различаются на:
* '''производственные''' (действия по изменению вещества или информации),
* '''координационные''' (поручения работы, обещания выполнить работу, сообщение о выполнении работы, подтверждение выполнения работы, отказ от выполнения или приёмки работы).

Исполнители работ в DEMO называемые '''actor''' (актёр, исполнитель) имеют как [[Компетенция|компетенции]] по выполнению производственных действий (или отказу от них), так и полномочия по выполнению координационных действий. Каждое действие в DEMO называется '''трансакцией''' и проходит по следующему циклу:
# инициатор трансакции желает получить какие-то результаты,
# инициатор запрашивает их у выполнителя работ,
# выполнитель работ обещает выдать результаты,
# выполнитель производит их,
# выполнитель объявляет о готовности результатов работы,
# инициатор работ принимает результат работы,
# инициатор использует результаты работы в своей части производства.

[[Файл:DEMO-basic_transaction_pattern.png|500px|center]]

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

=== Конструктивная модель ===
* Определяет суть предприятия: организационные роли и транзакции между ними (кто что для кого делает).
* Основная трудность в понимании: что такое организационная роль (роль – это не подразделение, не должность, не конкретные люди, не функции).
* Полностью абстрагирована от реализации
* реализация – назначение организационных ролей организационным местам, затем заполнение этих мест конкретными людьми, затем делегирование этими людьми отдельных внутри транзакционных действий другим людям.
* Для мелких предприятий помещается на лист A4, для очень крупных – лист A0.

=== Модель процессных шагов ===
* DEMO: бизнес-процессы (социальные вопросы: запросов-обещаний, т.е. бизнеса).
* Не-DEMO процессные модели айтишников ([[IDEF0]], Dataflow, Document flow и т.д.) – это «какие-то процессы», точно не бизнес-процессы, они не ухватывают социальную суть организации.

=== Модель состояний (производственного мира) ===
* Спецификация всех возможных состояний и изменений состояний производственногот мира:
** Типы бизнес-объектов (часто хитро формулируемых: «членство», «займ»)
** Бизнес-факты (что сделано)
** Законы состояний мира производства (как связаны между собой бизнес-объекты)
** Законы изменения состояний мира производства (например что чему должно предшествовать). Тут связь с процессной моделью (производственный и координационный миры связаны через транзакции).
* Язык моделирования: [[ORM]] (язык спецификации данных), возможен [[Gellish]].
* модель состояний DEMO — это описание видов учитываемой информации: то, что обязательно следует записывать («информационные банки» для производственных фактов). Затем эта информация будет предоставляться и запрашиваться при выполнении транзакций.

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

== Инструментарий ==
Коммерческий софт:
* Essential Business Modeler (http://xprise.com);
* Моделлер Bizzdesign (http://bizzdesign.com).

Собственные разработки организаций:
* модуль к Metis (http://troux.com) в Rijkswaterstaat;
* «ручка и бумажка» ввиду чрезвычайной компактности диаграмм;
* таблицы в MS Excel.

== Литература ==
* Jan L. G. Dietz (русск.: Дитц). Enterprise Ontology: Theory and Methodology. — B., Heidelberg, N. Y.: Springer, 2006 (ISBN-10 3-540-29169-5)
* A. S. H. P. van Renssen. Gellish, A Generic Extensible Ontological Language: Design and Application of a Universal Data Structure. — Delft: Delft University Press, 2005 (ISBN 90-407-2597-4).

== Ссылки ==
* [http://www.techinvestlab.ru/files/504456/demo_praxos_1.doc Подход DEMO. Метод архитектурного описания организаций. PraxOS 1.0]

[[Категория:Подходы]]

DEMO

2024-04-04T08:55:33Z

Admin: /* Концепция */

'''[http://www.demo.nl/ DEMO]''' (Design and Engineering Methodology for Organisations) — методология проектирования и инжиниринга [[предприятие|организаций]].

DEMO описывает положения теории речевых актов в отношении к [[Инженерия предприятия|инженерии предприятий]].

{{youtube|jx7WH_ur_94|500}}

== Концепция ==
В DEMO все действия различаются на:
* '''производственные''' (действия по изменению вещества или информации),
* '''координационные''' (поручения работы, обещания выполнить работу, сообщение о выполнении работы, подтверждение выполнения работы, отказ от выполнения или приёмки работы).

Исполнители работ в DEMO называемые '''actor''' (актёр, исполнитель) имеют как [[Компетенция|компетенции]] по выполнению производственных действий (или отказу от них), так и полномочия по выполнению координационных действий. Каждое действие в DEMO называется '''трансакцией''' и проходит по следующему циклу:
# инициатор трансакции желает получить какие-то результаты,
# инициатор запрашивает их у выполнителя работ,
# выполнитель работ обещает выдать результаты,
# выполнитель производит их,
# выполнитель объявляет о готовности результатов работы,
# инициатор работ принимает результат работы,
# инициатор использует результаты работы в своей части производства.

[[Файл:DEMO-basic_transaction_pattern.png]]

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

=== Конструктивная модель ===
* Определяет суть предприятия: организационные роли и транзакции между ними (кто что для кого делает).
* Основная трудность в понимании: что такое организационная роль (роль – это не подразделение, не должность, не конкретные люди, не функции).
* Полностью абстрагирована от реализации
* реализация – назначение организационных ролей организационным местам, затем заполнение этих мест конкретными людьми, затем делегирование этими людьми отдельных внутри транзакционных действий другим людям.
* Для мелких предприятий помещается на лист A4, для очень крупных – лист A0.

=== Модель процессных шагов ===
* DEMO: бизнес-процессы (социальные вопросы: запросов-обещаний, т.е. бизнеса).
* Не-DEMO процессные модели айтишников ([[IDEF0]], Dataflow, Document flow и т.д.) – это «какие-то процессы», точно не бизнес-процессы, они не ухватывают социальную суть организации.

=== Модель состояний (производственного мира) ===
* Спецификация всех возможных состояний и изменений состояний производственногот мира:
** Типы бизнес-объектов (часто хитро формулируемых: «членство», «займ»)
** Бизнес-факты (что сделано)
** Законы состояний мира производства (как связаны между собой бизнес-объекты)
** Законы изменения состояний мира производства (например что чему должно предшествовать). Тут связь с процессной моделью (производственный и координационный миры связаны через транзакции).
* Язык моделирования: [[ORM]] (язык спецификации данных), возможен [[Gellish]].
* модель состояний DEMO — это описание видов учитываемой информации: то, что обязательно следует записывать («информационные банки» для производственных фактов). Затем эта информация будет предоставляться и запрашиваться при выполнении транзакций.

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

== Инструментарий ==
Коммерческий софт:
* Essential Business Modeler (http://xprise.com);
* Моделлер Bizzdesign (http://bizzdesign.com).

Собственные разработки организаций:
* модуль к Metis (http://troux.com) в Rijkswaterstaat;
* «ручка и бумажка» ввиду чрезвычайной компактности диаграмм;
* таблицы в MS Excel.

== Литература ==
* Jan L. G. Dietz (русск.: Дитц). Enterprise Ontology: Theory and Methodology. — B., Heidelberg, N. Y.: Springer, 2006 (ISBN-10 3-540-29169-5)
* A. S. H. P. van Renssen. Gellish, A Generic Extensible Ontological Language: Design and Application of a Universal Data Structure. — Delft: Delft University Press, 2005 (ISBN 90-407-2597-4).

== Ссылки ==
* [http://www.techinvestlab.ru/files/504456/demo_praxos_1.doc Подход DEMO. Метод архитектурного описания организаций. PraxOS 1.0]

[[Категория:Подходы]]

Файл:DEMO-basic transaction pattern.png

2024-04-04T08:55:12Z

Admin:

Справочные списки

2022-12-25T22:21:34Z

Admin:

'''Справочный список''' — это предварительно составленный перечень категорий рисков, которые могут служить источниками индивидуальных рисков проекта, а также совокупного риска проекта.

Справочный список можно использовать как базовый перечень в качестве подспорья для команды в ходе формирования идей в процессе применения [[:Категория:Методы оценки риска#Методы идентификации риска|методов идентификации рисков]].

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

Некоторые общепринятые стратегические базовые перечни больше подходят для идентификации источников совокупного риска проекта, например:
* PESTLE (политические, экономические, социальные, технологические, правовые, экологические риски),
* TECOP (технические, экологические, коммерческие, операционные, политические риски),
* VUCA (изменчивость, неопределенность, сложность, неоднозначность).

[[Категория:Не распределенные по группам инструменты и методы PMI PMBoK]]

9.1 Планирование управления ресурсами

2022-12-25T22:12:26Z

Admin: /* Выходы */

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

== Входы ==
# [[Устав проекта]]
# [[План управления проектом]]
#* [[План управления качеством]]
#* [[Базовый план по содержанию]]
# Документы проекта
#* [[Расписание проекта]]
#* [[Документация по требованиям]]
#* [[Реестр рисков]]
#* [[Реестр заинтересованных сторон]]
# [[Факторы среды предприятия]]
# [[Активы процессов организации]]

== Инструменты и методы ==
# [[Экспертная оценка]]
# Отображение данных
#* [[Иерархические схемы]]
#* [[Матрица ответственности]]
#* Текстовые форматы
# [[Теория организации]]
# Совещания

== Выходы ==
# [[План управления ресурсами]]
# [[Устав команды]]
# Обновления документов проекта
#* [[Журнал допущений]]
#* [[Реестр рисков]]

[[Категория:Процессы планирования проекта]]

Gist

2022-12-25T22:11:07Z

Admin: Новая страница: «'''gist''' - это минималистская верхняя онтология Semantic Arts для предпр…»

'''gist''' - это минималистская верхняя [[:Категория:Онтологии|онтология]] Semantic Arts для [[предприятие|предприятия]]. Она разработана таким образом, чтобы обеспечить максимальный охват типичных бизнес-концепций с наименьшим количеством примитивов и наименьшим количеством двусмысленностей. Распространяется по лицензии Creative Commons 3.0 Attribution-ShareAlike.

== Особенности ==
Существенные особенности дизайна gist:
* gist определяет небольшое количество концепций высшего уровня, на которых базируется все остальное, как в самом gist, так и в онтологиях предприятий или приложений, использующих gist в качестве основы. Эти понятия не являются философскими абстракциями с незнакомыми терминами, такими как endurant, perdurant или qualia; это повседневные понятия с обычными именами, такими как person, organization и agreement, значения которых соответствуют ожиданиям. Эти высокоуровневые понятия служат строительными блоками для определения более конкретных понятий области в онтологии на основе gist.
* gist имеет обширную и тонкую расчлененность на самом высоком уровне для того, чтобы помочь вам избежать определенных типов логических ошибок в ваших онтологиях или данных, основанных на gist. Явно заявляя, например, что правительственные организации (такие как федеральное правительство США) не могут быть межправительственными организациями (такими как ООН), аргументатор будет жаловаться на логическую несогласованность, если что-то было типизировано как то и другое. Без разделения такие несоответствия не будут выявлены.
* gist редко использует спецификации домена и диапазона, чтобы сделать свойства более широко применимыми. Подклассы обычно определяются с помощью шаблона, который определяет, в каком смысле он специализируется на своем суперклассе.

== Ссылки ==
* [https://www.semanticarts.com/gist/ Официальный сайт]
* [https://github.com/semanticarts/gist Репозиторий GitHub]

[[Категория:Онтологии]]

Use-Case 2.0

2022-12-19T22:29:15Z

Admin:

'''Use-Case 2.0''' — масштабируемая [[Agile|гибкая]] практика, использующая [[Сценарий использования|сценарии использования]] для формирования [[требования|требований]] к системе, а также отслеживания выполнения этих требований. Предложена Иваром Якобсоном в 2011 году как развитие стандарта управления требованиями Use-Case, разработанного в 1980-х годах.

Use-Case 2.0 помогает описывать требования к системе или процессу в понятной форме, что может улучшить качество разработки и упростить процесс управления требованиями. Он также может быть полезен для [[Управление рисками|управления рисками]], так как помогает учитывать возможные ситуации, которые могут возникнуть в процессе разработки и эксплуатации системы.

== Принципы ==
# Быть проще, рассказывая истории.
# Понимать общую картину.
# Сфокусироваться на ценности.
# Разрабатывать систему по слоям.
# Поставлять систему инкрементальными обновлениями.
# Адаптироваться к нуждам [[команда|команды]].

== Литература ==
# "Mastering Use Cases: A Practical Guide to Requirements Gathering" by Alexander R. Pope
# "Use Case Modeling" by Kurt Bittner and Ian Spence
# "Use Case Driven Object Modeling with UML: Theory and Practice" by Doug Rosenberg and Kendall Scott
# "The Use Case Handbook: A Practical Guide to Requirements Gathering" by Simon Reindl and Andreas Holzinger
# "Use Case Maps for Object-Oriented Systems" by Doug Rosenberg and Kendall Scott
# "Use Case Points: Measuring and Estimating Software Development Efforts" by Juho Kettunen
# "A Use Case Method for Requirements Engineering" by C. H. Wu and Y. S. Wu
# "Use Case-Driven Requirements Engineering: A Practical Guide" by Sumeet Dua and G. Jayakumar

[[Категория:Практики]]
[[Категория:Незавершенные статьи]]

Категория:Стандарты управления рисками

2022-12-19T22:06:22Z

Admin:

Существует множество стандартов [[Управление рисками|управления рисками]], которые могут использоваться для организации работы с рисками в различных организациях. Некоторые из самых распространенных стандартов управления рисками:
* [[ISO 31000]]: Международный стандарт, который устанавливает рекомендации для управления рисками в любой организации. Он определяет термины, принципы и процессы управления рисками, а также предоставляет руководство по оценке и управлению рисками.
* [[COSO ERM]]: Стандарт управления рисками, разработанный Комитетом директоров компаний-участников (Committee of Sponsoring Organizations of the Treadway Commission, COSO). Он описывает рамки для управления рисками и обеспечивает структуру для разработки системы управления рисками.
* [[COBIT]]: Стандарт управления информационными технологиями в организациях. Он описывает рамки и принципы управления ИТ, а также предоставляет руководство по управлению рисками, связанными с ИТ.
* [[PMBOK]]: Стандарт Управления Проектами (Project Management Body of Knowledge, PMBOK) разработан Международной организацией по управлению проектами (Project Management Institute, PMI). Он описывает процессы и принципы управления проектами, а также предоставляет руководство по управлению рисками, связанными с проектами.
* [[ISO 27001]]: Международный стандарт по управлению информационной безопасностью. Он устанавливает требования для создания и поддержания системы управления информационной безопасностью (СУИБ) и предоставляет руководство по управлению рисками, связанными с информационной безопасностью. Стандарт также определяет требования для проведения аудита СУИБ и руководство по управлению инцидентами информационной безопасности.
* [[NIST CSF]]: Фреймворк кибербезопасности (Cybersecurity Framework), который разработан Национальным институтом стандартов и технологий (NIST), является общим руководством по управлению кибербезопасностью в организациях. Он описывает различные компоненты эффективного управления кибербезопасностью.
* FFIEC Cybersecurity Assessment Tool: Инструмент оценки кибербезопасности, разработанный Федеральной резервной системой США (Federal Reserve System) и Федеральной финансовой криптографической учреждений (Federal Financial Institutions Examination Council, FFIEC). Этот инструмент предназначен для оценки уровня кибербезопасности в финансовых организациях и предоставляет руководство по управлению рисками, связанными с кибербезопасностью.

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

[[Категория: Стандарты]]
[[Категория: Незавершенные статьи]]

COBIT

2022-12-19T21:58:07Z

Admin:

'''CobiT''' (Control Objectives for Information and Related Technologies — «Задачи управления для информационных и смежных технологий») — представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности. Создатели стандарта провели анализ и оценку и объединили лучшее из международных технических стандартов, стандартов управления качеством, аудиторской деятельности, а также из практических требований и опыта — всё то, что так или иначе имело отношение к целям управления.

== Структура ==
Концептуальное ядро стандарта COBIT 4.1 сформировано из 34 высокоуровневых процессов (которые покрывают порядка 200 целей контроля), сгруппированных в 4 домена (сферы деятельности):
# '''Планирование и организация''': включает стратегию и тактику, а также определение способов наиболее эффективного использования ИТ для достижения бизнес-целей. Регламентируемые процессы:
#* PO1 Разработка стратегического плана
#* PO2 Определение ИТ архитектуры
#* PO3 Определение направлений развития технологий
#* PO4 Формализация ИТ процессов, организации и взаимоотношений с бизнесом
#* PO5 Управление инвестициями в ИТ
#* PO6 Согласованное управление целями и задачами
#* PO7 Управление ИТ персоналом
#* PO8 Управление качеством
#* PO9 Оценка и управление рисками ИТ
#* PO10 Управление проектами
# '''Приобретение и внедрение''': для реализации ИТ стратегии нужно идентифицировать, разработать или приобрести соответствующие ИТ решения, которые должны быть внедрены и интегрированы в бизнес-процессы, а также внести изменения в информационные системы. Регламентируемые процессы:
#* AI1 Идентификация и выбор решений по автоматизации
#* AI2 Проектирование и разработка приложений
#* AI3 Проектирование и поддержка технической инфраструктуры
#* AI4 Обеспечение работы и использования ИС
#* AI5 Закупка ИТ ресурсов
#* AI6 Управление изменениями
#* AI7 Установка и утверждение решений и изменений
# '''Предоставление и поддержка''': включает предоставление требуемых информационных служб, в том числе обеспечение безопасности и непрерывности бизнеса, обучение, а также обработку данных прикладными системами. Регламентируемые процессы:
#* DS1 Определение и управление уровнями сервиса
#* DS2 Управление сервисами подрядчиков
#* DS3 Управление производительностью и мощностью
#* DS4 Обеспечение непрерывности сервисов
#* DS5 Обеспечение безопасности систем
#* DS6 Определение и распределение ИТ затрат
#* DS7 Обучение пользователей
#* DS8 Управление службой поддержки и инцидентами
#* DS9 Управление конфигурацией
#* DS10 Управление проблемами
#* DS11 Управление данными
#* DS12 Управление физическим оборудованием
#* DS13 Управление эксплуатацией
# '''Мониторинг и оценка''': качество и соответствие ИТ процессов требованиям контроля должны оцениваться на регулярной основе. Этот домен включает в себя надзор со стороны руководства за процессами управления в организации, а также независимый контроль со стороны внутренних и внешних аудиторов. Регламентируемые процессы:
#* ME1 Отслеживать и оценивать производительность ИТ
#* ME2 Отслеживать и оценивать внутренние контроли
#* ME3 Гарантировать соответствие регулирующим требованиям
#* ME4 Обеспечивать руководство ИТ

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

== Уровни зрелости ==
Зрелость показывает, насколько процесс управляем и предсказуем. Всего обычно рассматривают шесть уровней зрелости:
* '''0 Отсутствующий.''' Процесс не существует. Например, процесс производства колбасы в ИТ организации находится на нулевом уровне зрелости, поскольку мы не производим колбасу.
* '''1 Начальный.''' Деятельность осуществляется хаотически, от случая к случаю без единого подхода. Руководство не организовано.
* '''2 Повторяемый, но интуитивный.''' Одинаковые задачи решаются разными людьми сходными методами. Однако отсутствуют формальные процедуры и распределение ответственности. Весьма высока зависимость от отдельных сотрудников, что повышает вероятность ошибок.
* '''3 Определенный.''' Процедуры стандартизованы и документированы. Однако отклонения от процедур не всегда отслеживаются. Процедуры формализуют существующую практику.
* '''4 Управляемый и измеримый.''' Руководство контролирует и измеряет процесс и принимает меры, если процесс неэффективен. Могут использоваться инструменты автоматизации процесса.
* '''5 Оптимизируемый.''' Процесс развит до уровня хорошей практики в результате постоянных улучшений и сравнения с другими предприятиями. Соответствует целям заказчика.

[[Категория: Архитектурные подходы]]
[[Категория: Модели зрелости]]
[[Категория: Стандарты управления рисками]]

Анализ УТП

2022-12-19T21:54:23Z

Admin: Новая страница: «'''Анализ уникального торгового предложения''' (Unique Selling Proposition, USP) — это анализ, который по…»

'''Анализ уникального торгового предложения''' (Unique Selling Proposition, USP) — это анализ, который помогает определить то, что отличает ваш бизнес от конкурентов и делает его уникальным на рынке. Это может быть одно или несколько свойств вашего продукта, услуги или бизнеса, которые делают его более привлекательным для потребителей, чем у конкурентов.

Определение УТП важно для бизнеса, потому что оно помогает разработать эффективную [[конкурентные стратегии|маркетинговую стратегию]] и увеличить [[продажи]]. Это также помогает сформулировать [[бизнес-гипотеза|бизнес-гипотезу]] и определить целевую аудиторию.

[[Категория:Практики стратегирования]]

Категория:Практики маркетинга

2022-12-19T21:50:55Z

Admin: /* Практики анализа целевой аудитории */

Положительный результат реализации [[Стратегия|стратегии]] – удовлетворенные клиенты. Однако, чтобы их получить необходимо донести ценность предложения до выявленной целевой аудитории.

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

== Практики анализа целевой аудитории ==
Уточнить (сегментировать) целевую аудиторию и выявить её [[потребности]] помогают следующие практики:
* Практики, применяемые при проектировании продукта:
** [[JTBD]];
** [[Метод персонажа]];
** [[Пользовательские истории]];
* Практики, применяемые при тестировании прототипа продукта:
** [[CJM]];
** [[CusDev]];
** Карты эмпатии;
** A/B тестирование;
* Практики, применяемые на всех [[:Категория:Стадии ЖЦ|стадиях ЖЦ]] продукта:
** Конкурентная разведка (Competitive Intelligence).

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

Чтобы разобраться в отличиях данных практик необходимо понять какие [[рабочий продукт|рабочие продукты]] создаются с их помощью. Эти рабочие продукты формируют и корректируют [[требования]] к создаваемой системе, поэтому данные практики также можно назвать практиками [[инженерия требований|инженерии требований]].

== Практики допродажного взаимодействия с аудиторией ==
* Контент-маркетинг (content marketing)
* Маркетинг в социальных сетях (social media marketing)
* Платное продвижение
** контекстная реклама в поисковых запросах,
** таргетированная реклама в соцсетях,
** видеореклама на видеохостингах,
** партнерский маркетинг (использование сторонних ресурсов для привлечения трафика на свой сайт),
** нативная реклама (рекламные публикации у блогеров),
** email-рассылки.
* Омниканальность (использования различных каналов продвижения);
* Growth hacking (использование нестандартных путей для быстрого стимулирования спроса: вирусный маркетинг, бонусы за инвайты, «партизанский» маркетинг и пр.).

== Практики продаж ==
Практики [[продажи|продаж]] обеспечивают взаимодействие с конкретным контрагентом. Это может быть покупатель или множество покупателей: продажа одной штуки товара или оптом:
* B2B,
* B2C,
* B2G,
* B2B2C,
* практики прямых продаж,
* практики корпоративных продаж,
* практики продаж крупным клиентам.

== Практики сбора обратной связи ==
''Источник: [https://atlantconsult.ru/blog/why-is-important-to-collect-feedback-from-customers/ Почему важен сбор обратной связи от клиентов]''

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

Если вы не получаете фидбэк от своих клиентов и не знаете, что они думают о предлагаемых вами товарах и услугах, вы не сможете гарантировать, что они получают положительный опыт от взаимодействия с вашей компанией. Мнение потребителей – ключевая информация, которая поможет вам понять, как выглядит бренд в их глазах, а также убедиться, что вы предоставляете потребителям именно то, чего они хотят:
* '''Обратная связь помогает улучшить продукты и услуги'''. Наиболее достоверную информацию о всех достоинствах и недостатках продукта вы сможете узнать после того, как покупатели его опробуют. Кроме того, потребности и ожидания аудитории имеют свойство со временем меняться.
* '''Обратная связь оптимизирует работу отделов продаж и маркетинга'''. Она помогает выявить сильные стороны продукта, которые впоследствии могут использоваться для создания уникального торгового предложения, и понять, как продукт воспринимается аудиторией. К примеру, использовать выявленные сильные стороны в рекламных кампаниях.
* '''Обратная связь поможет удержать клиентов'''. Наиболее преданными клиентами становятся не те, у кого сложился исключительно положительный опыт использования ваших услуг, а те, кто столкнулся с проблемами и получил от вас помощь.
* '''Обратная связь показывает клиентам, что их мнение ценно для вас'''. Вы вовлекаете их в формирование вашего бизнеса и тем самым повышаете их привязанность к бренду.
* '''Обратная связь помогает принимать бизнес-решения'''. Вы сможете не только глубже понять потребности и ожидания потребителей, но также определить, куда следует направить ресурсы: на доработку продукта или же на его продвижение

[[Категория:Практики]]
[[Категория:Незавершенные статьи]]

Категория:Практики маркетинга

2022-12-19T21:48:16Z

Admin: /* Практики анализа целевой аудитории */

Положительный результат реализации [[Стратегия|стратегии]] – удовлетворенные клиенты. Однако, чтобы их получить необходимо донести ценность предложения до выявленной целевой аудитории.

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

== Практики анализа целевой аудитории ==
Уточнить (сегментировать) целевую аудиторию и выявить её [[потребности]] помогают следующие практики:
* Практики, применяемые при проектировании продукта:
** [[JTBD]];
** [[Анализ УТП]];
** [[Метод персонажа]];
** [[Пользовательские истории]];
* Практики, применяемые при тестировании прототипа продукта:
** [[CJM]];
** [[CusDev]];
** Карты эмпатии;
** A/B тестирование;
* Практики, применяемые на всех [[:Категория:Стадии ЖЦ|стадиях ЖЦ]] продукта:
** Конкурентная разведка (Competitive Intelligence).

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

Чтобы разобраться в отличиях данных практик необходимо понять какие [[рабочий продукт|рабочие продукты]] создаются с их помощью. Эти рабочие продукты формируют и корректируют [[требования]] к создаваемой системе, поэтому данные практики также можно назвать практиками [[инженерия требований|инженерии требований]].

== Практики допродажного взаимодействия с аудиторией ==
* Контент-маркетинг (content marketing)
* Маркетинг в социальных сетях (social media marketing)
* Платное продвижение
** контекстная реклама в поисковых запросах,
** таргетированная реклама в соцсетях,
** видеореклама на видеохостингах,
** партнерский маркетинг (использование сторонних ресурсов для привлечения трафика на свой сайт),
** нативная реклама (рекламные публикации у блогеров),
** email-рассылки.
* Омниканальность (использования различных каналов продвижения);
* Growth hacking (использование нестандартных путей для быстрого стимулирования спроса: вирусный маркетинг, бонусы за инвайты, «партизанский» маркетинг и пр.).

== Практики продаж ==
Практики [[продажи|продаж]] обеспечивают взаимодействие с конкретным контрагентом. Это может быть покупатель или множество покупателей: продажа одной штуки товара или оптом:
* B2B,
* B2C,
* B2G,
* B2B2C,
* практики прямых продаж,
* практики корпоративных продаж,
* практики продаж крупным клиентам.

== Практики сбора обратной связи ==
''Источник: [https://atlantconsult.ru/blog/why-is-important-to-collect-feedback-from-customers/ Почему важен сбор обратной связи от клиентов]''

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

Если вы не получаете фидбэк от своих клиентов и не знаете, что они думают о предлагаемых вами товарах и услугах, вы не сможете гарантировать, что они получают положительный опыт от взаимодействия с вашей компанией. Мнение потребителей – ключевая информация, которая поможет вам понять, как выглядит бренд в их глазах, а также убедиться, что вы предоставляете потребителям именно то, чего они хотят:
* '''Обратная связь помогает улучшить продукты и услуги'''. Наиболее достоверную информацию о всех достоинствах и недостатках продукта вы сможете узнать после того, как покупатели его опробуют. Кроме того, потребности и ожидания аудитории имеют свойство со временем меняться.
* '''Обратная связь оптимизирует работу отделов продаж и маркетинга'''. Она помогает выявить сильные стороны продукта, которые впоследствии могут использоваться для создания уникального торгового предложения, и понять, как продукт воспринимается аудиторией. К примеру, использовать выявленные сильные стороны в рекламных кампаниях.
* '''Обратная связь поможет удержать клиентов'''. Наиболее преданными клиентами становятся не те, у кого сложился исключительно положительный опыт использования ваших услуг, а те, кто столкнулся с проблемами и получил от вас помощь.
* '''Обратная связь показывает клиентам, что их мнение ценно для вас'''. Вы вовлекаете их в формирование вашего бизнеса и тем самым повышаете их привязанность к бренду.
* '''Обратная связь помогает принимать бизнес-решения'''. Вы сможете не только глубже понять потребности и ожидания потребителей, но также определить, куда следует направить ресурсы: на доработку продукта или же на его продвижение

[[Категория:Практики]]
[[Категория:Незавершенные статьи]]

Обоснование инвестиций

2022-12-19T21:44:07Z

Admin:

'''Обоснование инвестиций''' (технико-экономическое обоснование инвестиций, ТЭО) — [[Рабочий продукт|рабочий продукт]] [[Альфа|альфы]] "[[Возможности]]".

Со вступлением в силу постановления Правительства РФ "[http://pravo.gov.ru/proxy/ips/?docbody=&nd=102119991 О составе разделов проектной документации и требованиях к их содержанию]" понятия "ТЭО", "проект" и "рабочий проект", установленные ранее действовавшими нормативными документами (СНиП 11-01-95 и СП 11-101-95) не подлежат применению, а используются понятия "[[проектная документация]]" и "[[рабочая документация]]" ([http://meganorm.ru/Data2/1/4293829/4293829676.pdf см. разъяснение]).

[[Категория: Рабочие продукты]]

Бизнес-гипотеза

2022-12-19T21:39:04Z

Admin: Новая страница: «'''Бизнес-гипотеза''' — это предположение о том, как определенное действие может принести…»

'''Бизнес-гипотеза''' — это предположение о том, как определенное действие может принести прибыль или улучшить результаты бизнеса. Она используется в [[Бизнес-план|бизнес-планировании]] и [[стратегирование|стратегическом решении вопросов]], чтобы определить, стоит ли вкладывать ресурсы в определенные направления (''Источник: [https://chat.openai.com/chat ChatGPT]'').

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

[[Категория:Предпринимательские рабочие продукты]]

Канва бизнес-модели

2022-10-01T08:55:51Z

Admin: /* См. также */

'''Канва бизнес-модели''' (от англ. Business model canvas) — один из инструментов стратегического управления для предпринимателей, продвигаемый в рамках [[Бережливое производство|LEAN]], который позволяет сделать описание проекта. Автором и создателем канвы бизнес-модели являются Александр Остервальдер и Ив Пинье.

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

== Описание ==
[[Файл:bmcanvas.png|center|800px]]

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

Основные группы и блоки в рамках бизнес-модели:
# '''Инфраструктура''' – описывает как и с помощью чего компания производит ценность, по сути определяется основа производственных процессов предприятия. Состоит из трех областей:
#* Процессы – наиболее важные процессы в цепочке создания ценностей клиентам компании.
#* Ресурсы – ключевые ресурсы, которые необходимы для создания ценности клиентам компании. Ресурсы могут быть человеческие, финансовые, средства производства, интеллектуальные.
#* Партнеры – ключевые партнеры, взаимоотношения с которыми могут повлиять на процесс создания ценности для клиентов компании. Формы взаимодействия с партнерами, могут принимать различные формы, к примеру: ключевой поставщик, стратегический альянс, совместное предприятие и т.д.
# '''Предложение''' – описывает продукт или услугу, которые компания предлагает на рынке. Состоит из одной области:
#* Предлагаемая ценность – набор продуктов и услуг, которые выделяют компанию среди конкурентов на рынке и создают ценность для клиентов. Ценность продуктов и услуг предлагаемых на рынке, как правило достигается за счет следующих характеристик: новизна, производительность, гибкость и адаптируемость, комплектность, дизайн, бренд и статусность, цена, снижение рисков, доступность, удобство.
# '''Клиенты''' – описывает основные сегменты рынка либо клиентов, на обслуживании которых будет в первую очередь ориентироваться компания. А также основные процессы и способы работы с клиентами. Состоит из трех областей:
#* Клиенты – компания должна в первую очередь понять, кто будет пользоваться предлагаемыми ею продуктами или услугами, каковы их потребности и каковы особенности целевого рынка. Различные группы клиентов включают: массовый рынок, нишевые рынки, сегменты рынка, диверсификация (фокусирование одновременно на различных сегментах рынка), взаимозависимость клиентов (компания в рамках одного предложения обслуживает потребности различных клиентов).
#* Каналы сбыта – способ доставки продукта или услуги до клиента, удовлетворяющий потребностям в скорости, эффективности и стоимости.
# '''Взаимоотношения''' – каким образом будут строиться взаимоотношения с клиентами, каким образом компания будет приобретать новых клиентов, удерживать существующих и развивать отношения с ними. Различные формы построения взаимоотношения с клиентами включают:
#* Персональное обслуживание – личное взаимодействие между сотрудником компании и клиентом, как правило в офисах продаж, по телефону, в рамках онлайн-чата и т.д.
#* Эксклюзивное персональное обслуживание – схоже с персональным обслуживанием, но с выделением для каждого клиента персонального менеджера по обслуживанию.
#* Самообслуживание – клиенты самостоятельно обслуживают себя посредством предлагаемых компанией инструментов.
#* Автоматизированное обслуживание – схоже с самообслуживанием, но системы компании могут определять потребности клиента и предлагать наиболее интересные предложения.
#* Сообщество клиентов – прямое взаимодействие между клиентами компании, компания предоставляет платформу в рамках которой клиенты могут обмениваться идеями, советами и решать различные проблемы.
#* Совместная работа – клиенты непосредственно участвую в процессе создания дизайна продукта или услуги компании.
# '''Финансы''' – описание особенностей организации финансовых потоков компании, как входящих (ценообразование), так и исходящих (структура затрат). Состоит из двух областей:
#* Структура затрат – описание основных финансовых моделей и объектов инвестиций компании, которые необходимо понести для создания продукта или услуги. Основные элементы в описании структуры затрат: фиксированные расходы, переменные расходы, модели оптимизации затрат (экономия за счет масштаба, аутсорсинг непрофильных функций и т.д.).
#* Источники дохода – способ получения финансирования с каждого из рыночных сегментов, на котором она работает. Выделяют следующие источники дохода для компании: продажа товара, плата за использование, плата за подписку, сдача в аренду, лицензирование, посредничество, реклама.

== См. также ==
* [[Стратегирование]]
* [[OMG VDML]]
* [[Lean Canvas]]

[[Категория:Бережливое производство]]
[[Категория:Предпринимательские практики]]

Файл:RTM.png

2022-10-01T08:53:04Z

Admin: Admin загрузил новую версию Файл:RTM.png

Матрица отслеживания требований

2022-10-01T08:49:12Z

Admin:

'''Матрица отслеживания требований''' (Requirements Traceability Matrix) — это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов.

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

Требования к отслеживанию включают в себя, среди прочего:
* бизнес-потребности, а также благоприятные возможности, цели и задачи организации;
* цели проекта;
* содержание проекта и поставляемые результаты [[ИСР]];
* проектирование продукта;
* разработку продукта;
* стратегию и сценарии тестирования;
* детализацию от высокоуровневых до более детальных требований.

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

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

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

== Пример ==
[[Файл:RTM.png|center|700px]]

[[Категория: Документы проекта PMI PMBoK]]

Файл:Зрелость подчиненных Херси Бланшар.png

2022-08-13T12:59:02Z

Admin: Admin загрузил новую версию Файл:Зрелость подчиненных Херси Бланшар.png

Ситуационное лидерство

2022-08-13T12:50:58Z

Admin: /* Стили управления */

'''Ситуационное руководство''' или '''ситуационное [[лидерство]]''' – это подход к управлению людьми, основанный на использовании 4 стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче.

Теорию ситуационного лидерства разработали и описали в книге 1960 года «Менеджмент организационного поведения» («Management of Organizational Behavior») американские исследователи поведения Пол Херси и Кен Бланшар.

== Стили управления ==
* '''Указывающий (директивный) стиль''' (S1). Высокая ориентация на задание и низкая ориентация на отношения. Лидер, использующий указывающий стиль распределяет между подчиненными роли по своему усмотрению и постоянно диктует им, что, как и когда надо делать. Директивный стиль.
* '''Убеждающий (наставнический) стиль''' (S2). Высокая ориентация на задание и высокая ориентация на отношения. Этот стиль тоже директивный, но в нем лидер прибегает к убеждению и поддержке подчиненных. Лидер, для которого характерен убеждающий стиль, ставит перед подчиненными определенные задачи, однако, при этом в процессе наставничества уделяет внимание развитию межличностных отношений.
* '''Участвующий (поддерживающий) стиль''' (S3). Высокая ориентация на отношения и низкая ориентация на задание. Для участвующего стиля характерно стремление лидера к сотрудничеству с подчиненными и отсутствие директивности. Это консультативный или конценсусный тип лидерства, в соответствии с которым подчиненные привлекаются к участию в принятии решений.
* '''Делегирующий стиль''' (S4). Низкая ориентация на отношения и низкая ориентация на задание. При делегирующем стиле лидер стремится переложить ответственность за выполнение задач и достижение результатов на своих подчиненных, не требуя от них отчеты о проделанной работе.

[[Файл:Модель_Херси_Бланшар.png|600px|center]]

== Зрелость подчиненных ==
* '''Низкая зрелость подчиненных''' (не способен, не настроен) (R1). Когда исполнители неспособны и не хотят выполнять работу, лидеру стоит прибегнуть к директивному или автократичному указывающему стилю.
* '''Средняя зрелость подчиненных''' (не способен, настроен) (R2). Когда исполнители неспособны, но хотят выполнять работу используйте ориентированный на поддержку и развитие подчиненных убеждающий стиль.
* '''Зрелость подчиненных выше средней''' (способен, не настроен) (R3). Когда исполнители способны, но не хотят выполнять работу, подходящим окажется участвующий стиль, ориентированный на развитие межличностных отношений в группе.
* '''Высокая зрелость подчиненных''' (способен, настроен) (R4). Когда исполнители способны и хотят реализовывать задачи, лидер может вознаградить своих ответственных, самодостаточных и профессиональных подчиненных значительной долей автономии, прибегнув для этого к делегирующему стилю.

[[Файл:Зрелость_подчиненных_Херси_Бланшар.png|600px|center]]

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

Заинтересованному, но неопытному новичку нужны инструкции и сильное руководство. Затем он постепенно осваивается с работой, но первый энтузиазм начинает гаснуть – и здесь лидер стимулирует его к самостоятельности, поиску решений в конкретных ситуациях. Дальше профессионализм растет, но [[мотивация]] может уменьшаться из-за усталости или сложностей с самореализацией. Главное в этот момент – развить задатки, а не «погасить» сотрудника, то есть ему нужна поддержка. Если он почувствует, что справляется, его идеи интересны, ему удается находить правильные решения и самореализовываться, к возросшему профессионализму добавится и мотивация. Если этого не происходит, часто на этом этапе сотрудник с низкой мотивацией увольняется. Если третий этап пройден успешно, сотрудник развился до высокого профессионализма и мотивированности. На четвертом этапе он получает свой проект, начинает руководить командой отдела или проекта – и развивать ее по тем же принципам.

[[Категория:Практики]]

Ситуационное лидерство

2022-08-13T12:50:48Z

Admin: /* Зрелость подчиненных */

'''Ситуационное руководство''' или '''ситуационное [[лидерство]]''' – это подход к управлению людьми, основанный на использовании 4 стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче.

Теорию ситуационного лидерства разработали и описали в книге 1960 года «Менеджмент организационного поведения» («Management of Organizational Behavior») американские исследователи поведения Пол Херси и Кен Бланшар.

== Стили управления ==
* '''Указывающий (директивный) стиль''' (S1). Высокая ориентация на задание и низкая ориентация на отношения. Лидер, использующий указывающий стиль распределяет между подчиненными роли по своему усмотрению и постоянно диктует им, что, как и когда надо делать. Директивный стиль.
* '''Убеждающий (наставнический) стиль''' (S2). Высокая ориентация на задание и высокая ориентация на отношения. Этот стиль тоже директивный, но в нем лидер прибегает к убеждению и поддержке подчиненных. Лидер, для которого характерен убеждающий стиль, ставит перед подчиненными определенные задачи, однако, при этом в процессе наставничества уделяет внимание развитию межличностных отношений.
* '''Участвующий (поддерживающий) стиль''' (S3). Высокая ориентация на отношения и низкая ориентация на задание. Для участвующего стиля характерно стремление лидера к сотрудничеству с подчиненными и отсутствие директивности. Это консультативный или конценсусный тип лидерства, в соответствии с которым подчиненные привлекаются к участию в принятии решений.
* '''Делегирующий стиль''' (S4). Низкая ориентация на отношения и низкая ориентация на задание. При делегирующем стиле лидер стремится переложить ответственность за выполнение задач и достижение результатов на своих подчиненных, не требуя от них отчеты о проделанной работе.

[[Файл:Модель_Херси_Бланшар.png|center]]

== Зрелость подчиненных ==
* '''Низкая зрелость подчиненных''' (не способен, не настроен) (R1). Когда исполнители неспособны и не хотят выполнять работу, лидеру стоит прибегнуть к директивному или автократичному указывающему стилю.
* '''Средняя зрелость подчиненных''' (не способен, настроен) (R2). Когда исполнители неспособны, но хотят выполнять работу используйте ориентированный на поддержку и развитие подчиненных убеждающий стиль.
* '''Зрелость подчиненных выше средней''' (способен, не настроен) (R3). Когда исполнители способны, но не хотят выполнять работу, подходящим окажется участвующий стиль, ориентированный на развитие межличностных отношений в группе.
* '''Высокая зрелость подчиненных''' (способен, настроен) (R4). Когда исполнители способны и хотят реализовывать задачи, лидер может вознаградить своих ответственных, самодостаточных и профессиональных подчиненных значительной долей автономии, прибегнув для этого к делегирующему стилю.

[[Файл:Зрелость_подчиненных_Херси_Бланшар.png|600px|center]]

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

Заинтересованному, но неопытному новичку нужны инструкции и сильное руководство. Затем он постепенно осваивается с работой, но первый энтузиазм начинает гаснуть – и здесь лидер стимулирует его к самостоятельности, поиску решений в конкретных ситуациях. Дальше профессионализм растет, но [[мотивация]] может уменьшаться из-за усталости или сложностей с самореализацией. Главное в этот момент – развить задатки, а не «погасить» сотрудника, то есть ему нужна поддержка. Если он почувствует, что справляется, его идеи интересны, ему удается находить правильные решения и самореализовываться, к возросшему профессионализму добавится и мотивация. Если этого не происходит, часто на этом этапе сотрудник с низкой мотивацией увольняется. Если третий этап пройден успешно, сотрудник развился до высокого профессионализма и мотивированности. На четвертом этапе он получает свой проект, начинает руководить командой отдела или проекта – и развивать ее по тем же принципам.

[[Категория:Практики]]

Ситуационное лидерство

2022-08-13T12:50:36Z

Admin:

'''Ситуационное руководство''' или '''ситуационное [[лидерство]]''' – это подход к управлению людьми, основанный на использовании 4 стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче.

Теорию ситуационного лидерства разработали и описали в книге 1960 года «Менеджмент организационного поведения» («Management of Organizational Behavior») американские исследователи поведения Пол Херси и Кен Бланшар.

== Стили управления ==
* '''Указывающий (директивный) стиль''' (S1). Высокая ориентация на задание и низкая ориентация на отношения. Лидер, использующий указывающий стиль распределяет между подчиненными роли по своему усмотрению и постоянно диктует им, что, как и когда надо делать. Директивный стиль.
* '''Убеждающий (наставнический) стиль''' (S2). Высокая ориентация на задание и высокая ориентация на отношения. Этот стиль тоже директивный, но в нем лидер прибегает к убеждению и поддержке подчиненных. Лидер, для которого характерен убеждающий стиль, ставит перед подчиненными определенные задачи, однако, при этом в процессе наставничества уделяет внимание развитию межличностных отношений.
* '''Участвующий (поддерживающий) стиль''' (S3). Высокая ориентация на отношения и низкая ориентация на задание. Для участвующего стиля характерно стремление лидера к сотрудничеству с подчиненными и отсутствие директивности. Это консультативный или конценсусный тип лидерства, в соответствии с которым подчиненные привлекаются к участию в принятии решений.
* '''Делегирующий стиль''' (S4). Низкая ориентация на отношения и низкая ориентация на задание. При делегирующем стиле лидер стремится переложить ответственность за выполнение задач и достижение результатов на своих подчиненных, не требуя от них отчеты о проделанной работе.

[[Файл:Модель_Херси_Бланшар.png|center]]

== Зрелость подчиненных ==
* '''Низкая зрелость подчиненных''' (не способен, не настроен) (R1). Когда исполнители неспособны и не хотят выполнять работу, лидеру стоит прибегнуть к директивному или автократичному указывающему стилю.
* '''Средняя зрелость подчиненных''' (не способен, настроен) (R2). Когда исполнители неспособны, но хотят выполнять работу используйте ориентированный на поддержку и развитие подчиненных убеждающий стиль.
* '''Зрелость подчиненных выше средней''' (способен, не настроен) (R3). Когда исполнители способны, но не хотят выполнять работу, подходящим окажется участвующий стиль, ориентированный на развитие межличностных отношений в группе.
* '''Высокая зрелость подчиненных''' (способен, настроен) (R4). Когда исполнители способны и хотят реализовывать задачи, лидер может вознаградить своих ответственных, самодостаточных и профессиональных подчиненных значительной долей автономии, прибегнув для этого к делегирующему стилю.

[[Файл:Зрелость_подчиненных_Херси_Бланшар.png|center]]

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

Заинтересованному, но неопытному новичку нужны инструкции и сильное руководство. Затем он постепенно осваивается с работой, но первый энтузиазм начинает гаснуть – и здесь лидер стимулирует его к самостоятельности, поиску решений в конкретных ситуациях. Дальше профессионализм растет, но [[мотивация]] может уменьшаться из-за усталости или сложностей с самореализацией. Главное в этот момент – развить задатки, а не «погасить» сотрудника, то есть ему нужна поддержка. Если он почувствует, что справляется, его идеи интересны, ему удается находить правильные решения и самореализовываться, к возросшему профессионализму добавится и мотивация. Если этого не происходит, часто на этом этапе сотрудник с низкой мотивацией увольняется. Если третий этап пройден успешно, сотрудник развился до высокого профессионализма и мотивированности. На четвертом этапе он получает свой проект, начинает руководить командой отдела или проекта – и развивать ее по тем же принципам.

[[Категория:Практики]]

Файл:Зрелость подчиненных Херси Бланшар.png

2022-08-13T12:50:24Z

Admin:

Ситуационное лидерство

2022-08-13T12:48:30Z

Admin:

'''Ситуационное руководство''' или '''ситуационное [[лидерство]]''' – это подход к управлению людьми, основанный на использовании 4 стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче.

Теорию ситуационного лидерства разработали и описали в книге 1960 года «Менеджмент организационного поведения» («Management of Organizational Behavior») американские исследователи поведения Пол Херси и Кен Бланшар.

[[Файл:Модель_Херси_Бланшар.png|center]]

== Стили управления ==
* '''Указывающий (директивный) стиль''' (S1). Высокая ориентация на задание и низкая ориентация на отношения. Лидер, использующий указывающий стиль распределяет между подчиненными роли по своему усмотрению и постоянно диктует им, что, как и когда надо делать. Директивный стиль.
* '''Убеждающий (наставнический) стиль''' (S2). Высокая ориентация на задание и высокая ориентация на отношения. Этот стиль тоже директивный, но в нем лидер прибегает к убеждению и поддержке подчиненных. Лидер, для которого характерен убеждающий стиль, ставит перед подчиненными определенные задачи, однако, при этом в процессе наставничества уделяет внимание развитию межличностных отношений.
* '''Участвующий (поддерживающий) стиль''' (S3). Высокая ориентация на отношения и низкая ориентация на задание. Для участвующего стиля характерно стремление лидера к сотрудничеству с подчиненными и отсутствие директивности. Это консультативный или конценсусный тип лидерства, в соответствии с которым подчиненные привлекаются к участию в принятии решений.
* '''Делегирующий стиль''' (S4). Низкая ориентация на отношения и низкая ориентация на задание. При делегирующем стиле лидер стремится переложить ответственность за выполнение задач и достижение результатов на своих подчиненных, не требуя от них отчеты о проделанной работе.

== Зрелость подчиненных ==
* '''Низкая зрелость подчиненных''' (не способен, не настроен) (R1). Когда исполнители неспособны и не хотят выполнять работу, лидеру стоит прибегнуть к директивному или автократичному указывающему стилю.
* '''Средняя зрелость подчиненных''' (не способен, настроен) (R2). Когда исполнители неспособны, но хотят выполнять работу используйте ориентированный на поддержку и развитие подчиненных убеждающий стиль.
* '''Зрелость подчиненных выше средней''' (способен, не настроен) (R3). Когда исполнители способны, но не хотят выполнять работу, подходящим окажется участвующий стиль, ориентированный на развитие межличностных отношений в группе.
* '''Высокая зрелость подчиненных''' (способен, настроен) (R4). Когда исполнители способны и хотят реализовывать задачи, лидер может вознаградить своих ответственных, самодостаточных и профессиональных подчиненных значительной долей автономии, прибегнув для этого к делегирующему стилю.

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

Заинтересованному, но неопытному новичку нужны инструкции и сильное руководство. Затем он постепенно осваивается с работой, но первый энтузиазм начинает гаснуть – и здесь лидер стимулирует его к самостоятельности, поиску решений в конкретных ситуациях. Дальше профессионализм растет, но [[мотивация]] может уменьшаться из-за усталости или сложностей с самореализацией. Главное в этот момент – развить задатки, а не «погасить» сотрудника, то есть ему нужна поддержка. Если он почувствует, что справляется, его идеи интересны, ему удается находить правильные решения и самореализовываться, к возросшему профессионализму добавится и мотивация. Если этого не происходит, часто на этом этапе сотрудник с низкой мотивацией увольняется. Если третий этап пройден успешно, сотрудник развился до высокого профессионализма и мотивированности. На четвертом этапе он получает свой проект, начинает руководить командой отдела или проекта – и развивать ее по тем же принципам.

[[Категория:Практики]]

Файл:Модель Херси Бланшар.png

2022-08-13T12:48:24Z

Admin:

Стратегия

2022-08-08T23:02:40Z

Admin: /* Суперстратегии ежа и лисы */

'''Стратегия''' предприятия — это требования к предприятию, которые предприниматель считает важными. Стратегия предприятия фокусирует [[возможности]] для запуска одного или нескольких проектов.

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

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

В быстро меняющемся мире постоянно появляется новая практическая информация, поэтому стратегия как документ требует регулярного обновления. В этой связи важна не сама стратегия, а [[Стратегирование|Практика стратегирования]].

'''Основной признак наличия стратегии''' — это прохождение [[Конкурентные стратегии|теста Портера на сфокусированность]] (т.е. стратегия — это не “чем бы ещё заняться”, а наоборот: нахождение такого занятия, при котором отказываешься от многих и многих других занятий). Это и желаемое состояние мира в конце задуманного действия, и план действий, и хитрый трюк-уловка, и повторяющийся паттерн успешного действия, и выбор целевого рынка (см. 5П Мицберга).

== Стратегия 5П по Мицбергу ==
Генри Минцберг (Henry Mintzberg), проанализировав стратегии в разных компаниях, обобщил их выделив 5 аспектов:
# '''Plan''' (План, последовательность шагов) – некий вид сознательно и намеренно разработанной последовательности действий, которой придерживаются в конкретной ситуации. У стратегии-плана две существенные характеристики – она создается заранее, до начала действий и ее намеренно разрабатывают с определенной целью.
#* Инструменты: [[PEST-анализ]], [[SWOT-анализ]].
# '''Ploy''' (Прием, хитрость) – прием, который предпринимает компания, чтобы обыграть своих конкурентов в конкретной ситуации или игре.
#* Инструменты: [[Колесо фьючерсов]], [[IA|Импакт-анализ]], [[Анализ сценариев]].
# '''Pattern''' (Принцип поведения, практика) – устойчивые характеристики поведения организации. Согласно такому пониманию стратегия может быть как заранее продуманной, так и выстраивающейся по ходу развития событий, и представляет некую последовательность в поведении. В данном случае стратегия - это принцип поведения или следование некой модели поведения. Организации разрабатывают планы на будущее и выводят принципы поведения из своего прошлого. Таким образом, стратегию Plan можно назвать намечаемой, а стратегию Pattern – осуществляемой стратегией. Из опыта, очевидно, что заранее разрабатываемые стратегии не всегда превращаются в реализуемые. Но есть и третий случай — появление и развитие новой, стратегии, когда реализуется незапланированная модель поведения. Предпринимаемые шаги, один за другим, со временем выстраиваются в некую последовательность или принцип – паттерн действий.
#* Инструменты: [[Анализ УТП]], [[Анализ ключевой компетенции]], [[VRIO]]
# '''Position''' (Позиционирование на рынке) – заключается в поиске наиболее выгодной позиции компании на рыночном ландшафте. При этом выгодная позиция может расшифровываться в разных терминах: имеющая лучший потенциал прибыльности, более защищенная от конкуренции, более соответствующая ресурсам и способностям компании и т.д.
#* Инструменты: [[Пять сил Портера]], [[Алмазная модель Портера]].
# '''Perspective''' (Перспектива, корпоративная культура) – рассматривается как разделяемое членами компании видение/восприятие мира, которое реализуется через их намерения и действия.
#* Инструменты: [[Сеть культурных особенностей]], [[Модель корпоративной культуры Дила-Кеннеди]], [[Модель соответствия]]

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

== Ретроспективное придание смысла ==
По Карлу Вейку (Karl E. Weick), люди стремятся придать смысл организациям, а организации стремятся придать смысл своему окружению. Немалую роль в этом процессе играют многозначность и неопределенность, которые в теории обработки информации Вейка обозначаются понятием «двойной смысл» (equivocality). «Придание смысла подчеркивает, что люди пытаются сделать события рационально объяснимыми для себя и других».

Вейк анализирует семь свойств процесса придания смысла в организациях:
# '''Идентичность''' и идентификация имеют определяющее значение: то, как люди определяют, [[Роль|кем они являются в своем контексте]], определяет, что они воплощают и как они [[метод описания|интерпретируют события]]. Каждая из идентичностей [[индивид|индивидуума]] создает собственный смысл, поэтому индивидуумы не действуют абсолютно последовательно.
# '''Ретроспекция'''. Чтобы понять, что мы думаем, мы обращаемся к тому, что сказали ранее: «как я могу знать, что я думаю об этом, пока я не увижу результата своих действий?!» Ретроспекция дает возможность придания смысла, при этом точка во времени, в которой совершается ретроспекция, влияет на то, что именно люди замечают. Успех события является важным для его ретроспективного понимания. Любые помехи в момент ретроспекции также влияют на содержание смысла.
# '''Воплощение'''. Люди воплощают ту среду, с которой сталкиваются в диалогах и [[нарратив|нарративах]]. Когда люди говорят, они создают нарративы, которые помогают им понять, что они думают, организовать собственный опыт, контролировать и предсказывать события.
# '''Социальный контакт'''. Придание смысла — это социальная деятельность, в которой сохраняются и распространяются правдоподобные истории. При этом аудитория включает самого говорящего, а нарративы являются развивающимся результатом разговоров с собой и другими.
# '''Протяженность во времени'''. Придание смысла — это текущий, продолжающийся процесс. Индивидуумы одновременно формируют среду и реагируют на неё. Когда люди проецируют себя на свою среду наблюдают последствия, то узнают что-то новое о своей идентичности и о точности своих представлений о мире. Этот процесс предполагает обратную связь, так что даже если индивидуумы выводят свою идентичность из поведения окружающих по отношению к ним, они также пытаются повлиять на поведение окружающих. «Основная идея придания смысла состоит в том, что реальность — это свершающееся событие, возникающее из наших усилий создать порядок и ретроспективно придать смысл тому, что происходит».
# '''Подсказки'''. Люди выуживают из контекста подсказки, которые могут помочь им решить, к какой информации стоит прислушаться и какие [[объяснения]] ситуации наиболее вероятны. Извлеченные подсказки обеспечивают точки опоры для связи идей с более широкими сетями смысла и являются "простыми, знакомыми структурами, которые являются зачатками более широкого чувства того, что может происходить".
# '''Правдоподобие'''. Описывая события и контексты, люди выбирают правдоподобие в ущерб точности описания. «В двусмысленном, постмодернистском мире, пронизанном политикой интерпретаций и конфликтующих интересов и населенном людьми с множеством меняющихся идентичностей, одержимость точностью кажется бесплодной, да и практической пользы от нее немного».

== Суперстратегии ежа и лисы ==
Суперстратегии ежа и лисы описаны в книге [https://en.wikipedia.org/wiki/Good_to_Great Джима Коллинза "От хорошего к великому"], со ссылкой на эссе [https://en.wikipedia.org/wiki/The_Hedgehog_and_the_Fox Исайи Берлина].

Ёж использует один и тот же приём: чуть что, он сворачивается в клубочек и выставляет миру свои иголки. Одно и то же действие в ответ на любое изменение вовне — каждый раз. И это ежа почти каждый раз спасает, стратегия оказывается эффективна до определенного момента.

Лиса (или [https://yosha-orlow.livejournal.com/72192.html выдра]) каждый раз делает что-то новое: то хвостом помашет, то засаду устроит, то тявкать начнёт, то побежит со всех ног, и всё это в зависимости от обстоятельств. Лиса тоже добивается успеха во многих случаях, но в совсем новых обстоятельствах у неё '''появляется шанс угадать подходящее действие''' — этого шанса нет у ежа, он новое угадать не может и гарантированно проиграет. Преимущество ежа пропадает, если изменения становятся достаточно разнообразными.

== Конкурентные стратегии ==
См. [[Конкурентные стратегии]]

[[Категория: Предпринимательские рабочие продукты]]

Журнал проблем

2022-07-30T15:47:42Z

Admin: /* Пример */

'''Журнал проблем''' (Issue Log) — это документ проекта, в котором регистрируются и отслеживаются все проблемы.

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

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

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

== Пример ==
[[Файл:issuelog.png|center|600px]]

[[Категория: Документы проекта PMI PMBoK]]

Команда

2022-07-30T15:13:34Z

Admin: /* Состояния */

'''Команда инженерного проекта''' — люди с совершенно определённым набором [[Компетенция|компетенций]], нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.

== Модель Такмана ==
В 1965 г. психолог Брюс Такман (Bruce Tuckman) придумал символические термины для отображения стадий процесса создания команды:
* '''Формирование''' (Forming) — знакомство членов команды друг с другом, определение общих целей, структуры команды и обязанностей внутри структуры. На данной стадии позволительно задавать такие вопросы: «Кто эти люди?», «Каких действий ждут от меня?», «Кто будет лидером?», «Что предположительно должно произойти?».
* '''Конфронтация''' (Storming) — борьба за лидерство или влияние внутри группы. Если не пройти стадию конфликта, группа собьется с правильного пути. На этой стадии целесообразно задавать следующие вопросы: «Как мы справимся с разногласиями?», «Как мы можем найти общее решение при несовпадении точек зрения?», «Как мы можем передавать негативную информацию?», «Хочу ли я продолжать оставаться членом этой команды?».
* '''Нормирование''' (Norming) — закладываются организационные принципы будущей работы команды, налаживаются каналы взаимодействия между участниками. На этой стадии уместны такие вопросы: «Каковы нормы и ценности команды?», «Как преуспеть в командном взаимодействии?», «Как можно продемонстрировать свою поддержку другим членам группы?», «Какая польза от участия отдельного члена в группе?».
* '''Выполнение''' (Performing) — эффективное сотрудничество.

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

[[Файл:tuckman.jpg|center]]

== Дисциплины ==
* [[Лидерство]]

== Подальфы ==
* [[Член команды]],
* Подрядчик,
* Сотрудничество (которого вначале нет, а потом оно должно появиться),
* Ресурсы (которых вначале тоже может не быть).

== Состояния ==
[[OMG Essence]] определяет следующие состояния для альфы "Команда" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:
{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold; width:4%" | №
! style="text-align: center; font-weight: bold; width:10%" | Состояние
! style="text-align: center; font-weight: bold; width:10%" | State
! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
! style="text-align: center; font-weight: bold; width:60%" | Контрольные вопросы
|-
| 1
| '''Намечена'''
| Seeded
| [[Миссия]] команды ясна и знания о том, как растить команду, наличествуют.
| ❑ Миссия команды определена в терминах [[Возможности|возможностей]] и результатов.

❑ Ограничения на работу команды известны.

❑ Механизмы для роста команды наличествуют.

❑ Состав команды определён.

❑ Все ограничения, определяющие где и как будет выполняться работа, определены.

❑ Обязанности команды обрисованы в общих чертах.

❑ Уровень принятых командой обязательств ясен.

❑ Требуемые [[компетенция|компетенции]] определены.

❑ Размер команды определён.

❑ Правила контроля за деятельностью определены.

❑ Форма управления выбрана.
|-
| 2
| '''Сформирована'''
| Formed
| Команда была пополнена достаточным количеством людей с принятыми обязательствами, чтобы начать миссию.
| ❑ Индивидуальные обязанности понимаются.

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

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

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

❑ Все члены команды встретились (возможно, виртуально) и начинают узнавать друг друга.

❑ Члены команды понимают их обязанности и как они увязаны с их компетенциями.

❑ Члены команды принимают работу.

❑ Любые внешние смежники (организации, команды и индивиды) определены.

❑ Механизмы общения в команде определены.

❑ Каждый член команды принял обязательство работать в команде, как это определено.
|-
| 3
| '''Сотрудничает'''
| Collaborating
| Члены команды работают вместе как одно подразделение.
| ❑ Команда работает как одно сплочённое подразделение.

❑ Общение в команде открытое и честное.

❑ Команда сфокусирована на достижение миссии команды.

❑ Члены команды знают друг друга.
|-
| 4
| '''Производит'''
| Performing
| Команда работает результативно и эффективно.
| ❑ Команда систематически выполняет обязательства.

❑ Команда непрерывно адаптируется к изменяющемуся контексту.

❑ Команда определяет и адресует проблемы без внешней помощи.

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

❑ Работа впустую и причины для работы впустую постоянно устраняются.
|-
| 5
| '''Распущена'''
| Adjourned
| Команда больше не ответственна за выполнение своей миссии.
| ❑ Обязанности команды были переданы или прекращены.

❑ Члены команды доступны для назначения в другие команды.

❑ Командой не предпринимается дальше никаких усилий для завершения миссии.
|}

== Опросники ==
=== Общая удовлетворённость работой в компании ===
* '''Опросник удовлетворённости Спектора''' используют с 1985 года. С его помощью можно лучше понять, доволен ли работник зарплатой, карьерным ростом, руководителем, льготами и дополнительными выплатами, коллегами, информированием о происходящем в компании и тем, как выполняются договорённости внутри коллектива.
* '''Опросник вовлечённости Gallup Q12''', для создания которого были опрошены около тридцати пяти миллионов человек. С его помощью измеряют силу эмоциональной привязанности сотрудников к компании — как коллектив относится к бренду, насколько разделяет его философию.
* '''Миннесотский опросник удовлетворённости сотрудников''' даёт общее представление о взаимоотношениях сотрудников с коллегами и руководством, об условиях труда, темпах карьерного роста и возможности профессиональной реализации.

=== Лояльность и отношение к организации ===
* '''Опросник организационной лояльности Лимана Портера''' можно использовать для определения лояльности персонала идеям компании в целом или в конкретном подразделении. Результаты одного квартала можно сравнивать с другим — так динамика результатов (или её отсутствие) будут видны наглядно.
* '''Опросник отношения к организации Липпонена''' используют, когда нужно измерить, насколько сотрудник идентифицирует себя с организацией или подразделением, в котором работает. При помощи опросника узнают, как коллектив реагирует на изменения внутри компании, насколько лоялен фирме в целом и её руководству в частности.
* '''Опросник лояльности по шкале Терстоуна''' в разных формах используют с 1927 года. Нужен, если между сотрудниками участились конфликты, работники совершают много ошибок, а в коллективе не приживается конструктивная критика.

=== Микроклимат в коллективе ===
* '''Тест определения групповой сплочённости Сишора''' используют, когда нужно понять, насколько каждый работник чувствует себя частью коллектива. Обычно тест предлагают после смены руководства или перевода сотрудника в новое подразделение.
* '''Опросник Шпалинского и Шелеста''' нужен, чтобы измерить психологический климат в коллективе. Охватывает все сферы трудовой жизни сотрудников — от прихода в компанию новенького и отношения к кофебрейкам до неожиданного вызова в кабинет начальника и реакции на дисциплинарные нарушения.

[[Категория: Концепции]]
[[Категория: Альфы]]

ГОСТ 34

2022-07-26T17:32:51Z

Admin: /* Ссылки */

'''ГОСТ 34.ххх''' (Единый комплекс стандартов и руководящих документов на автоматизированные системы, ЕКС АС) — комплекс государственных стандартов СССР, межотраслевых руководящих документов и методических материалов, задуманный в конце 80х годов.

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

== Преимущества ==
* Лаконичность и доступность для непрофильных специалистов;
* Самодостаточность;
* Широкая распространенность на территории РФ и ряда стран СНГ, привычность терминологии и базовых понятий;
* Минимальный набор жестких требований и возможность адаптации требований стандартов под конкретные условия тех или иных проектов.

== Недостатки ==
* Избыточные и несовременные требования по оформлению документов.
* Стандарты не являются [[Процессный подход|процессно-ориентированными]], что лишает их перспектив развития и затрудняет использование совместно с более современными стандартами.
* Целый ряд ключевых понятий современного [[Управление проектами|управления проектами]], таких как риски, программы проектов и портфели проектов, в ГОСТах серии 34 отсутствуют вовсе, а как следствие, их проработка стандартом не предусмотрена.
* Незавершенность комплекса стандартов. Имеющиеся стандарты не образуют целостностную систему и больше не актуализируются.
* Очень поверхностно рассматриваются аспекты обслуживания внедренной автоматизированной системы: [[обучение]] персонала, выполнение регламентных процедур и т. п.

== Перечень стандартов ==
Документы входящие в ЕКС АС, разделяют на группы в соответствии с таблицей (по РД 50-682-89).
{| class="wikitable" style="text-align:center;"
|- style="font-weight:bold; text-align:left;"
! Код группы
! Наименование классификационной группы
|-
| 0
| style="text-align:left;" | Общие положения
|-
| 1
| style="text-align:left;" | Основные положения
|-
| 2
| style="text-align:left;" | Правила документирования
|-
| 3
| style="text-align:left;" | Обеспечение совместимости
|-
| 4
| style="text-align:left;" | Требования к составным частям АС
|-
| 5
| style="text-align:left;" | Требования к АС
|-
| 6
| style="text-align:left;" | Создание, функционирование и развитие АС
|-
| 7
| style="text-align:left;" | Типовые и унифицированные решения в АС
|-
| 8
| style="text-align:left;" | Прочие стандарты
|-
| 9
| style="text-align:left;" | Резерв
|}

По состоянию на 09.01.2022: 🟢 - действует 🔴 - не действует

=== Стандарты ===
* '''Группа 0'''
** 🔴 [http://sewiki.ru/images/d/d3/GOST-34.003-90.pdf ГОСТ 34.003-90 Термины и определения]
* '''Группа 2'''
** 🔴 [http://sewiki.ru/images/f/fe/GOST-34.201-89.pdf ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем]
** 🟢 ГОСТ 34.201-2020 Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
* '''Группа 3'''
** 🟢 ГОСТ Р 34.30-93 Информационная технология (ИТ). Передача данных. Интерфейс между оконечным оборудованием и аппаратурой окончания канала данных и распределение номеров контактов соединителей. Общие требования
** 🟢 ГОСТ Р 34.31-96 Информационная технология (ИТ). Микропроцессорные системы. Интерфейс Фьючебас+. Спецификации физического уровня
** 🟢 ГОСТ 34.301-91 (ИСО 6429-88) Информационная технология (ИТ). 7-битные и 8-битные кодированные наборы символов. Управляющие функции
** 🟢 ГОСТ 34.302.2-91 (ИСО 8859/2-87) Информационная технология (ИТ). Наборы 8-битных однобайтовых кодированных графических символов. Латинский алфавит N 2
** 🟢 ГОСТ Р 34.303-92 (ИСО 4873-86) Наборы 8-битных кодированных символов. 8-битный код обмена и обработки информации
** 🟢 [http://sewiki.ru/images/f/fe/GOST-34.320-96.pdf ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы]
** 🟢 [http://sewiki.ru/images/7/72/GOST-34.321-96.pdf ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных. Эталонная модель управления]
** 🟢 ГОСТ 34.340-91 (МЭК 935) ФАСТБАС. Модульная быстродействующая система сбора данных
* '''Группа 4'''
** 🟢 ГОСТ 34.401-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Средства технические периферийные автоматизированных систем дорожного движения. Типы и технические требования
** 🟢 ГОСТ 34.402-91 (ИСО 3407-83) Информационная технология (ИТ). Обмен информацией на кассете с магнитной лентой шириной 3,81 мм (0,15 дюйма) с плотностью записи 4 символа/мм (100 символов/дюйм) способом фазового кодирования при 63 переходах потоков/мм (1600 переходов потока /дюйм)
* '''Группа 6'''
** 🟢 [http://sewiki.ru/images/f/fe/GOST-34.601-90.pdf ГОСТ 34.601-90 Автоматизированные системы. Стадии создания]
** 🔴 [http://sewiki.ru/images/1/15/GOST-34.602-89.pdf ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы] (Взамен [[ГОСТ 24]].201-85)
** 🟢 ГОСТ 34.602-2020 Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
** 🟢 [http://sewiki.ru/images/f/fe/GOST-34.603-92.pdf ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем]
* '''Группа 7'''
** 🟢 ГОСТ Р 34.701.1-92 (ИСО 8632/1-87) Информационная технология (ИТ). Машинная графика. Метафайл для хранения и передачи информации об описании изображения
* '''Группа 9'''
** 🟢 ГОСТ Р 34.90-93 Информационная технология (ИТ). Передача данных и обмен информацией между системами. Протокольные комбинации для обеспечения и поддержки услуг сетевого уровня ВОС
** 🟢 ГОСТ Р 34.91-94 Информационная технология (ИТ). Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 6. Спецификация тестов протокольного профиля
** 🟢 ГОСТ 34.913.3-91 (ИСО 8802-3-89) Информационная технология (ИТ). Локальные вычислительные сети. Метод случайного доступа к шине и спецификация физического уровня
** 🟢 ГОСТ 34.913.4-91 (ИСО 8802/4-88) Информационная технология (ИТ). Локальные вычислительные сети. Метод маркерного доступа к шине и спецификация физического уровня
** 🟢 ГОСТ 34.936-91 (ИСО 10039-91) Информационная технология (ИТ). Локальные вычислительные сети. Определение услуг уровня управления доступом к среде
** 🟢 ГОСТ Р 34.950-92 (ИСО 8208-87) Информационная технология (ИТ). Взаимосвязь открытых систем. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных
** 🟢 ГОСТ Р 34.951-92 (ИСО 8348-87, ИСО 8348-87/Доп.1-87) Информационная технология (ИТ). Взаимосвязь открытых систем. Услуги сетевого уровня
** 🟢 ГОСТ 34.954-91 (ИСО 8878-87) Информационная технология (ИТ). Взаимосвязь открытых систем. Использование протокола пакетного уровня Х.25 для обеспечения услуг сетевого уровня взаимосвязи открытых систем в режиме с установлением соединения
** 🟢 ГОСТ Р 34.964-92 (ИСО 8602-87) Информационная технология (ИТ). Взаимосвязь открытых систем. Протокол транспортного уровня в режиме-без-установления-соединения
** 🟢 ГОСТ 34.971-91 (ИСО 8822-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Определение услуг уровня представления с установлением соединения
** 🟢 ГОСТ 34.972-91 (ИСО 8823-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Спецификация протокола уровня представления с установлением соединения
** 🟢 ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология (ИТ). Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)
** 🟢 ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология (ИТ). Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)
** 🟢 ГОСТ Р 34.980.1-92 (ИСО 8571/1-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 1. Общее описание
** 🟢 ГОСТ Р 34.980.2-92 (ИСО 8571/2-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 2. Определение виртуального файлохранилища
** 🟢 ГОСТ 34.981-91 (ИСО 8649-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Определение услуг сервисного элемента управления ассоциацией
** 🟢 ГОСТ Р 34.982-92 (ИСО 8650-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Определение протокола для сервисного элемента управления ассоциацией
** 🟢 ГОСТ Р 34.986.1-92 (ИСО 9041-1-90) Информационная технология (ИТ). Взаимосвязь открытых систем. Протокол основного класса виртуального терминала. Часть 1. Спецификация
** 🟢 ГОСТ Р 34.1341-93 (МЭК 1052-91) Информационная технология (ИТ). Стандартные рутины для системы ФАСТБАС
** 🟢 ГОСТ Р 34.1350-93 Информационная технология (ИТ). Интерфейсы для сопряжения радиоэлектронных средств. Основные положения (с Поправкой)
** 🟢 ГОСТ Р 34.1501.1-92 (ИСО/TR 10314-1-90) Информационная технология (ИТ). Промышленная автоматизация. Основное производство. Часть 1. Эталонная модель стандартизации и методология идентификации требований к стандартизации
** 🟢 ГОСТ Р 34.1702.3-92 (ИСО 8651-3-88) Информационная технология (ИТ). Машинная графика. Связь ядра графической системы с языком программирования АДА (с Поправкой)
** 🟢 ГОСТ Р 34.1952-92 (ИСО 8473-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Протокол для обеспечения услуг сетевого уровня в режиме без установления соединения
** 🟢 ГОСТ Р 34.1980.3-92 (ИСО 8571-3-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 3. Определение услуг виртуального файла
** 🟢 ГОСТ Р 34.1980.4-93 (ИСО 8571/4-88) Информационная технология (ИТ). Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть 4. Спецификация файловых протоколов
** 🟢 ГОСТ Р 34.1984-92 (ИСО 8832-89) Информационная технология (ИТ). Взаимосвязь открытых систем. Спецификация протокола базисного класса для передачи и обработки заданий

=== Рекомендации ===
* 🟢 Р 50-34-87 Рекомендации. Системы автоматизированного проектирования. Типовые методы геометрического моделирования объектов проектирования
* 🔴 [http://sewiki.ru/images/9/9b/%D0%A0_50-34.119-90.pdf Р 50-34.119-90 Рекомендации. Информационная технология. Комплекс стандартов на автоматизированные системы. Архитектура локальных вычислительных сетей в системах промышленной автоматизации. Общие положения]
* 🟢 [http://sewiki.ru/images/b/b1/%D0%A0_50-34.126-92.pdf Р 50-34.126-92 Рекомендации. Информационная технология. Правила проведения работ при создании автоматизированных систем]

=== Руководящие документы ===
* 🟢 РД 50-682-89 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения
* 🔴 [http://sewiki.ru/images/1/1f/RD-50-34.698-90.pdf РД 50-34.698-90 Методические указания. Автоматизированные системы. Требования к содержанию документов]

=== Криптографические стандарты ===
* 🟢 ГОСТ Р 34.10-2012 Информационная технология (ИТ). Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи
* 🟢 [http://sewiki.ru/images/5/58/GOST-34.10-2018.pdf ГОСТ 34.10-2018 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи]
* 🟢 ГОСТ Р 34.11-2012 Информационная технология (ИТ). Криптографическая защита информации. Функция хэширования
* 🟢 ГОСТ 34.11-2018 Информационная технология (ИТ). Криптографическая защита информации. Функция хэширования
* 🟢 ГОСТ Р 34.12-2015 Информационная технология (ИТ). Криптографическая защита информации. Блочные шифры
* 🟢 [http://sewiki.ru/images/f/fd/GOST_34.12-2018.pdf ГОСТ 34.12-2018 Информационная технология (ИТ). Криптографическая защита информации. Блочные шифры]
* 🟢 ГОСТ Р 34.13-2015 Информационная технология (ИТ). Криптографическая защита информации. Режимы работы блочных шифров
* 🟢 ГОСТ 34.13-2018 Информационная технология (ИТ). Криптографическая защита информации. Режимы работы блочных шифров

== Ссылки ==
* [http://sewiki.ru/images/6/6b/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BF%D0%BE%D0%BB%D0%B5%D0%B7%D0%BD%D0%BE%D0%B3%D0%BE_%D0%A2%D0%97_%D0%BF%D0%BE_%D0%93%D0%9E%D0%A1%D0%A2_34.602.pdf Разработка полезного ТЗ по ГОСТ 34.602]

[[Категория:ГОСТ]]

Файл:Разработка полезного ТЗ по ГОСТ 34.602.pdf

2022-07-26T17:31:30Z

Admin:

Категория:Требования

2022-07-25T11:16:02Z

Admin: /* Модальность */

Термин '''“требования”''' имеет два разных смысла:
* '''Определение системы как “чёрного ящика”''' — что требуется от целевой системы с точки зрения её [[стейкхолдер|стейкхолдеров]] (stakeholder requirements) и использующей надсистемы (system requirements). Обычно это спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д.).
* '''Любые определения системы''' (”чёрного ящика”, “прозрачного ящика”, на любых стадиях жизненного цикла), в которых присутствует деонтическая модальность (модальность долженствования).

Так что лучше не использовать слово “требования” (ибо непонятно, о чём идёт речь), а использовать уточняющие определения: в системной инженерии принято говорить о '''требованиях к продукту''' (требованиях стейкхолдеров) и '''требованиях к системе''' (системные требования), а всякие остальные “требования” (требования стандартов, требования системной архитектуры, требования чертежей, требования проектной документации и т.д.) просто означают, что “система должна удовлетворить этим описаниям”, но это не будет “требованиями” в смысле системной инженерии.

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

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

Каждый клиент мнит себя инженером (а иногда не мнит, а является ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать '''требования стейкхолдера''', а также '''требования к системе''', но обязательно попытается сформулировать '''конкретные инженерные решения''' “прозрачного ящика” (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование).

Формально высказывания о “прозрачном ящике” не называются требованиями, поэтому некоторые авторы предлагают называть их '''“[[Ограничение|ограничениями]]”''' (свободы творчества инженерной команды). Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования. И '''если придуманное вами инженерное решение лучше того, которое требует клиент в своих ограничениях, попытаться убедить клиента снять эти ограничения'''. Но нужно понимать, что иногда эти ограничения отражают какой-то опыт клиента, неизвестный команде, или они появляются из неинженерных (политических, финансовых, логистических и т.д.) соображений. Поэтому по поводу ограничений '''нужно каждый раз понимать, почему они были прописаны''', почему клиент без них не может обойтись (см. [[GORE]]).

Требование к требованиям стейкхолдеров: их понятность самим стейкхолдерам. Стейкхолдеры нуждаются в требованиях, которые сфокусированы их '''нуждами'''.

== Требования к системе ==
'''Требования к системе''' (system requirements) — требования, достаточные для разработки системы, которые формулируются архитекторами, проектировщиками и аналитиками на основе анализа требований к продукту и описывают:
* основные роли в системе,
* сценарии использования системы,
* информационные модели,
* модели классов, поведения, развертывания,
* прочие алгоритмы.

Их разрабатывает '''инженер по требованиям''' в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдеров и присутствует синтез системных требований).

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

=== Требования по ГОСТ 34 ===
[[ГОСТ 34]].602 устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы». '''Техническое задание''' определяет требования и порядок создания системы, в соответствии с которым проводится её разработка и приемка при вводе в действие. Техническое задание содержит следующие разделы:
# общие сведения;
# назначение и цели создания (развития) системы;
# характеристика объектов автоматизации;
# требования к системе;
# состав и содержание работ по созданию системы;
# порядок контроля и приемки системы;
# требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
# требования к документированию;
# источники разработки.

== Модальность ==
Чтобы понять природу требований, нужно разобраться с логическими модальностями высказываний о системе ([http://en.wikipedia.org/wiki/Modal_logic модальная логика]):
* '''нейтральные высказывания о мире''', суть которых непонятна без указания модальности. Например, "длина дана как 16".
* '''алетическая''' (alethic) '''модальность''', относящаяся к возможности существования: пока воплощения системы ещё нет, возможны варианты определений системы для разных возможных вариантов будущего воплощения системы. Например, "длина может быть 16".
* '''деонтическая''' (deontic) '''модальность''', относящаяся к обязыванию и дозволению. Например, "длина должна быть 16". Собственно, это и есть главная модальность “требований”, требования — это то, что должно быть, рекомендуется быть, разрешается быть, обязательно или необязательно и т.д.
* '''темпоральная''' (temporal) '''модальность''', связанная со временем. Например, "длина была 16 три года назад".
* '''доксическая''' (doxastic) '''модальность''', связанная с верой. "Я верю, что длина дана как 16". Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены — вера в то, что система соответствует её определению).

'''Требования довольно трудно формализовать именно потому, что нужно разбираться с их модальностями.'''

Требования связаны с '''инженерными обоснованиями''': они переформулируются как "декларации" (claim) разработчиков о соответствии — т.е. "я верю, что длина равна 16", а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика — это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся “как в суде” — и для этого даже заводится “дело” (assurance case, как раз от “судебного дела” — с вариантами dependability case, safety case, security case, requirement case, architectural quality case). Обзор по инженерным обоснованиям приведён тут.

== Виды требований ==
# '''Требования назначения''' (operational requirements) - относятся к назначению и целям создания системы. Совокупность этих требований должна описывать конечное состояние мира после того, как система будет развернута и начнет использоваться. Иногда их называют "требования к возможностям системы", "необходимые возможности".
#: - требования, выведенные из [[потребности|портебностей]] стейкхолдеров после анализа потребностей.
# '''Функциональные требования''' (functional requirements) - требования, определяющие функцию, которую должна быть способна выполнить система или элемент системы ([[ISO 24765]])
#: - требования, выведенные из сценариев использования. Самые распространённые практики [[Инженерия требований|инженерии требований]] — это выявление функций (поведения) системы из каких-то [[Сценарий использования|сценариев взаимодействия]] (user stories, use cases).
# '''Требования к показателям функционирования''' (performance requirements) - описывают насколько хорошо система должна выполнять предъявленные к ней требования (минимальные числовые пороговые значения).
# '''Требования к реализации''' (requirements) - требуемые характеристики и атрибуты физического воплощения системы и ограничения на ее конструкцию, внешний вид, общие свойства, вес, мощность, материал, ограничения на внешние интерфейсы.
# '''Нефункциональные''', “требования качества” (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые “-ости”, по- английски это будут “ilities” — reliability, repairability, availability, safety, etc.).

Но есть замечание Donald Firesmith, что '''“не бывает нефункциональных требований”''' — ибо все эти "требования качества" это абсолютно функциональные требования, характеризующие функции системы с точки зрения каких-то стейкхолдеров, обычно не рассматривающихся в сценариях “пользования”.

'''Главный источник ошибок в проекте''' — это неведение относительно наличия каких-то требований. Впрочем, классификация может помочь, если вы зададите себе вопрос: какие виды требований вы ещё не рассматривали для вашего проекта?

=== Свойства качества (внешние) ===
Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть [http://vniiaes.ru/HTML/RU/Docs/RuSEC%202010.rar в презентации Дональда Файерсмита] — и там же можно посмотреть на презентацию по [[Инженерия требований#Целеориентированная инженерия требований|целеориентированной инженерии требований]] Яна Александера.

== Стандарты представления требований==
([http://ailev.livejournal.com/900086.html см. подробнее])
* [[SysML]]
* [[AP 233]]
* [[RIF]]
* [[ISO 29148]]
* ITU Z.151 (URN=GRL+UCM)
* другие языки из подхода [[GORE]]: выражение оппозиции цели-средства (ends – means)
** i*
** RFLP
** [[ArchiMate]]
** MBRD
** [[OMG BMM]]
** Planguage
* [[ISO 15926]]

== Практики ЖЦ требований по [[ISO 15288]] ==
=== Жизненный цикл требований стейкхолдеров ===
# '''Подготовиться''' (идентифицировать стейкхолдеров, определить стратегию определения потребностей стейкхолдеров и требований, получить или купить обеспечивающую систему и сервисы)
# '''Определить [[потребности]] стейкхолдеров''' (определить контекст использования, идентифицировать потребности стейкхолдеров, приоритизировать и отобрать потребности, определить потребности стейкхолдеров и их обоснование)
# '''Разработать [[Концепция системы|Концепцию функционирования]] (operational concept) и другие концепции жизненного цикла''' (определить набор сценариев, определить взаимодействия пользователей и системы)
# '''Преобразовать потребности стейхколдеров в требования стейкхолдеров''' (идентифицировать ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все функции для требований качества, гармонизировать требования стейкхолдеров)
# '''Анализировать требования стейкхолдеров''' (анализировать полное множество требований стейкхолдеров, определить критические [[MOE|показатели результативности]], которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
# '''Управлять определением потребностей стейкхолдеров и требованиями''' (получить явное согласие на требования стейкхолдеров, поддерживать трассировку потребностей и требований, обеспечивать сведения по базисам)

=== Жизненный цикл требований к системе ===
# '''Подготовиться''' (определить функциональную границу системы в терминах поведения и свойств, которые нужно обеспечить, определить стратегию определения системных требований, идентифицировать и спланировать обеспечивающую систему для определения системных требований, получить или купить обеспечивающую систему)
# '''Определить системные требования''' (определить каждую функцию, которую должна выполнять система, определить необходимые реализационные ограничения, определить системные требования, которые относятся к риску, критичности системы или критические характеристики качества, определить системные требования и их обоснование)
# '''Анализировать системные требования''' (анализировать полный набор системных требований, определить критические характеристики качества, которые делают возможным оценку технического достижения, предоставить требования системы подходящим стейкхолдерам для рассмотрения, решить все возникшие проблемы с требованиями)
# '''Управлять системными требованиями''' (получить явное соглашение по системным требованиям, поддержать трассировку по системным требованиям, обеспечить информацию базиса)

== Рабочие продукты требований==
[[Рабочий продукт|Рабочие продукты]] требований могут быть самые разные — и чаще всего они не называются “требования”. Так, требования можно обнаружить в:
* разделе '''“технические требования”''' технических заданий (хотя “техническое задание” чаще всего подробно перечисляет работы — “задание на работы”, а не требования, но всё-таки какое-то описание целевой системы как “чёрного ящика” это описание содержит);
* документе '''“Опросный лист”''' (который посылается, чтобы опросить потенциальных поставщиков инженерных решений и содержит как раз основные требования к поставляемой системе);
* посылаемом в ответ на “Опросный лист” документе '''“Технико-коммерческие предложения”''';
* Различных стандартах, некоторые из которых называются '''“технические условия”''' (т.е. даже в названиях они не содержат слова “стандарт” или “требования”).

Важно понимать, что:
# требования системной инженерии — '''определения “чёрного ящика”, которые могут даже не содержать слово “требования” в своих рабочих продуктах и не содержать слов, обозначающих деонтическую модальность''' — быть без слов “должно”, “возможно”, “обязательно” и т.д.
# '''требования совсем необязательно являются бумажными документами-текстами'''. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — [[DOORS]], [[IRQA]] и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.

== Управление требованиями и инженерия требований ==
Нужно различать:
# '''[[Управление требованиями]]''' — дисциплина инженерного менеджмента (логистическая, “инженерного документооборота”), она заключается в том, чтобы предоставить средства хранения требований и сообщения о них всем тем, кто в них нуждается. Для того, чтобы управлять требованиями, нужно их сначала иметь.
# '''[[Инженерия требований]]''' — это поддисциплина системной инженерии, занимается разработкой требований. Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”.

== Требования к требованиям ==
=== Требования к требованиям по [[ISO 29148]] ===
'''Требования к группе требований:'''
# Полнота (complete)
# Согласованность с другими (consistent)
# Выполнимость (affordable, проходимы по бюджетам и срокам)
# Ограниченность (bounded)

'''Требования к одному требованию:'''
# '''Необходимость''' (necessary) - Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования.
# '''Абстрактность''' (abstract) -
# '''Недвусмысленность''' (unambiguous) - Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.
# '''Согласованность с другими''' (consistent) - Требование не противоречит другим требованиям и полностью соответствует внешней документации.
# '''Полнота''' (complete) - Требование полностью определено в одном месте и вся необходимая информация присутствует.
# '''Лаконичность''' (concise) - Требование не может быть разбито на ряд более детальных требований без потери завершённости.
# '''Достижимость''' (feasible) - Требование может быть реализовано в пределах проекта.
# '''Трассируемость''' (traceable) - Связь с вышестоящими и нижестоящими требованиями.
# '''Проверяемость''' (verifiable) - Реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

=== Другое ===
* '''Единичность''' - Требование описывает одну и только одну вещь.
* '''Актуальность''' - Требование не стало устаревшим с течением времени.

== Состояния ==
[[OMG Essence]] определяет следующие состояния для альфы "Требования" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:
{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold; width:4%" | №
! style="text-align: center; font-weight: bold; width:10%" | Состояние
! style="text-align: center; font-weight: bold; width:10%" | State
! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
! style="text-align: center; font-weight: bold; width:60%" | Контрольные вопросы
|-
| 1
| style="font-weight: bold;" | Замыслены
| Conceived
| Согласована потребность в новой системе.
| ❑ Начальное множество [[Стейкхолдер|стейкхолдеров]] согласно, что система должна быть произведена.

❑ Стейкхолдеры, которые будут использовать новую [[система|систему]], определены.

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

❑ Есть ясная возможность, которую будет адресовывать новая система.
|-
| 2
| style="font-weight: bold;" | Ограничены
| Bounded
| Назначение и тема новой системы ясны.
| ❑ Стейкхолдеры, вовлечённые в разработку новой системы определены.

❑ Стейкхолдеры согласны с назначениемновой системы.

❑ Ясно, что будет считаться [[Успешность системы|успехом]] для новой системы.

❑ Стейкхолдеры имеют одинаковое понимание пределов предлагаемого решения.

❑ [[Технология]] описания требований согласована.

❑ Механизмы управления требованиями наличествуют.

❑ Приоретизационная схема ясна.

❑ Ограничения определены и приняты во внимание.Допущения ясно сформулированы.
|-
| 3
| style="font-weight: bold;" | Непротиворечивы
| Coherent
| Требования обеспечивают непротиворечивое описание существенных характеристик новой системы.
| ❑ Требования документированы и доступны команде и стейкхолдерам.

❑ Происхождение требований ясно.

❑ Обоснование требований ясно.

❑ Противоречивые требования идентифицированы и ими занимаются.

❑ Требования сообщают существенные характеристики поставляемой системы.

❑ Наиболее важные [[Сценарий использования|сценарии использования]] системы могут быть объяснены.

❑ Приоритетность требований ясна.

❑ Влияние реализации требований понимается.

❑ [[Команда]] понимает, что должно быть обеспечено и соглашается обеспечить это.
|-
| 4
| style="font-weight: bold;" | Приемлемы
| Acceptable
| Требования описывают систему, которая будет приемлема для стейкхолдеров.
| ❑ Стейкхолдеры принимают, что требования описывают приемлемое решение.

❑ Скорость изменений к согласованным требованиям относительно низка и под контролем.

❑ Польза, обеспечиваемая реализацией требований, ясна.

❑ Части возможности, удовлетворяемые требованиями, ясны.

❑ Требования тестируемы.
|-
|
| style="font-weight: bold;" | Адресованы
| Addressed
| Достаточное количество требований было адресовано, чтобы удовлетворить потребность в новой системе способом, приемлемым для стейкхолдеров.
| ❑ Достаточное количество требований адресовано, чтобы результирующая система была приемлема для стейкхолдеров.

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

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

❑ Система, реализующая требования, принимается стейкхолдерами, как заслуживающая [[Эксплуатация|эксплуатации]].
|-
| 5
| style="font-weight: bold;" | Удовлетворены
| Fulfilled
| Требования, которые были адресованы, полностью удовлетворяют потребность в новой системе.
| ❑ Стейкхолдеры принимают требования, как аккуратно документирующие, что стейкхолдеры требуют для полного удовлетворения потребности в новой системе.

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

❑ Система, принята стейкхолдерами как полностью удовлетворяющая требованиям.
|}

[[Категория:Концепции]]
[[Категория: Альфы]]

Категория:PMI PMBoK

2022-07-23T18:18:41Z

Admin: /* Общие сведения */

'''Project Management Body of Knowledge (PMI PMBoK®)''' – самый распространенный в России стандарт, вплоть до незнания о существовании других («ксерокс фирмы кэнон»).

PMI PMBoK про управление одним проектом (а не программой – множество проектов одной организации).

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

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

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

Две главных [[Категории воздействий на предприятие|категории воздействий]]:
* [[факторы среды предприятия]] (ФСП);
* [[активы процессов организации]] (АПО).

[[Категория: Стандарты управления проектами]]

Категория:PMI PMBoK

2022-07-23T18:18:26Z

Admin:

'''Project Management Body of Knowledge (PMI PMBoK®)''' – самый распространенный в России стандарт, вплоть до незнания о существовании других («ксерокс фирмы кэнон»).

PMI PMBoK про управление одним проектом (а не программой – множество проектов одной организации).

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

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

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

Две главных [[Категории воздействий на предприятие:категории воздействий]]:
* [[факторы среды предприятия]] (ФСП);
* [[активы процессов организации]] (АПО).

[[Категория: Стандарты управления проектами]]

Категории воздействий на предприятие

2022-07-23T18:18:19Z

Admin:

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

Две главных категории воздействий:
* факторы среды предприятия (ФСП),
* активы процессов организации (АПО).

Кроме ФСП и АПО в жизненном цикле проекта значительную роль играют организационные системы.

== Факторы среды предприятия ==
'''Факторы среды предприятия''' (Enterprise Environmental Factors) — это условия, не находящиеся под непосредственным контролем команды проекта, которые влияют на проект, ограничивают или направляют его. Данные условия по отношению к организации могут быть внутренними и/или внешними. ФСП рассматриваются в качестве входов для многих процессов управления проектом, особенно для большинства процессов планирования. Эти факторы могут расширять или ограничивать варианты действий по управлению проектом. Кроме этого, эти факторы могут оказать положительное или отрицательное влияние на конечный результат.

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

=== Внутренние ФСП ===
Описанные ниже ФСП являются для организации внутренними:
* '''Организационная культура, структура и руководство'''. Примерами могут служить: видение, [[миссия]], ценности, убеждения, культурные нормы, стиль руководства, иерархия и система взаимосвязей полномочий, организационный стиль, этические нормы и кодекс поведения.
* '''Географическое распределение производственных объектов и ресурсов'''. Примерами могут служить: местоположение заводов, виртуальные команды, системы общего пользования и облачные компьютерные ресурсы.
* '''[[Инфраструктура]]'''. Примерами могут служить: производственные объекты, оборудование, каналы телекоммуникаций организации, компьютерное аппаратное обеспечение, его доступность и мощности.
* '''[[Программное обеспечение]]'''. Примерами могут служить: инструменты составления расписаний, системы управления конфигурацией, веб-интерфейсы к работающим в режиме онлайн автоматизированными системам и системы авторизации работ.
* '''Доступность ресурсов'''. Примерами могут служить: ограничения на заключение договоров и осуществление закупок, утвержденные поставщики и субподрядчики, а также соглашения о сотрудничестве.
* '''Кадровые возможности'''. Примерами могут служить: профессиональная квалификация и опыт, навыки, [[компетенции]] и специальные знания кадровых ресурсов.

=== Внешние ФСП ===
Описанные ниже ФСП являются для организации внешними:
* '''Ситуация на рынке'''. Примерами могут служить: конкуренты, доля рынка, узнаваемость бренда и товарные знаки.
* '''Социальные и культурные влияния и проблемы'''. Примерами могут служить: политический климат, кодексы поведения, этические нормы и представления.
* Юридические ограничения. Примерами могут служить: национальные или местные законы и нормативно-правовые акты в области безопасности, защиты данных, делового поведения, трудовых отношений и закупочной деятельности.
* '''Коммерческие базы данных'''. Примерами могут служить: результаты сравнительного анализа, стандартизированные сметные данные, данные изучения промышленных рисков, базы данных рисков.
* '''Научные исследования'''. Примерами могут служить: отраслевые исследования, публикации и результаты сравнительного анализа.
* '''[[Стандарты|Государственные или промышленные стандарты]]'''. Примерами могут служить: предписания и стандарты регулирующих органов в отношении продуктов, производства, природопользования, качества и квалификации.
* '''Финансовые соображения'''. Примерами могут служить: курсы обмена валют, банковские ставки, показатели инфляции, тарифы и географическое положение.
* '''Материальные элементы среды'''. Примерами могут служить: производственные условия, погодные условия и ограничения.

== Активы процессов организации ==
'''Активы процессов организации''' (Organizational Process Assets) — это планы, процессы, политики, процедуры и базы знаний, специфичные для исполняющей организации и используемые ею. Данные активы оказывают влияние на управление проектом.

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

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

Поскольку АПО являются для организации внутренними, члены команды проекта могут быть в состоянии по мере необходимости вносить обновления и дополнения в активы процессов организации на всем протяжении проекта. Их можно разбить на две категории:
* '''[[Процесс|Процессы]], политики и процедуры'''. Их обновление обычно не входит в работы по проекту. Процессы, политики и процедуры обычно устанавливаются офисом управления проектами (ОУП) или другим функциональным подразделением, внешним по отношению к проекту. Они могут обновляться только с соблюдением соответствующих политик организации, связанных с обновлением процессов, политик или процедур. В некоторых организациях команде предлагают адаптировать шаблоны, жизненные циклы и контрольные списки к проекту. В таких случаях команда управления проектом должна адаптировать эти активы с целью удовлетворения потребностей проекта.
* '''[[база знаний|Базы знаний]] организации'''. Обновляются на всем протяжении проекта за счет использования информации проекта. Например, на всем протяжении проекта постоянно обновляется информация о финансовых результатах, извлеченных уроках, метриках и проблемах исполнения, а также недостатках.

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

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

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

=== Модель руководства ===
Модель руководства — это модель, в рамках которой в организации осуществляются властные полномочия. Эта модель включает в себя, среди прочего: правила, политики, процедуры, нормы, отношения, системы, процессы. Данная модель оказывает влияние на то, как:
* устанавливаются и достигаются цели организации,
* осуществляется мониторинг и оценка рисков,
* осуществляется оптимизация исполнения.

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

[[Файл:Организационные структуры.png|center]]

[[Категория: PMI PMBoK]]

Файл:Организационные структуры.png

2022-07-23T18:17:48Z

Admin: Admin загрузил новую версию Файл:Организационные структуры.png

Категории воздействий на предприятие

2022-07-23T18:15:45Z

Admin: /* Организационные системы */

Файл:Организационные структуры.png

2022-07-23T18:15:21Z

Admin:

Категории воздействий на предприятие

2022-07-23T18:15:06Z

Admin: Новая страница: «Проекты существуют и осуществляются в среде, которая может воздействовать на них. Эти во…»

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

Две главных категории воздействий:
* факторы среды предприятия (ФСП),
* активы процессов организации (АПО).

Кроме ФСП и АПО в жизненном цикле проекта значительную роль играют организационные системы.

== Факторы среды предприятия ==
'''Факторы среды предприятия''' (Enterprise Environmental Factors) — это условия, не находящиеся под непосредственным контролем команды проекта, которые влияют на проект, ограничивают или направляют его. Данные условия по отношению к организации могут быть внутренними и/или внешними. ФСП рассматриваются в качестве входов для многих процессов управления проектом, особенно для большинства процессов планирования. Эти факторы могут расширять или ограничивать варианты действий по управлению проектом. Кроме этого, эти факторы могут оказать положительное или отрицательное влияние на конечный результат.

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

=== Внутренние ФСП ===
Описанные ниже ФСП являются для организации внутренними:
* '''Организационная культура, структура и руководство'''. Примерами могут служить: видение, [[миссия]], ценности, убеждения, культурные нормы, стиль руководства, иерархия и система взаимосвязей полномочий, организационный стиль, этические нормы и кодекс поведения.
* '''Географическое распределение производственных объектов и ресурсов'''. Примерами могут служить: местоположение заводов, виртуальные команды, системы общего пользования и облачные компьютерные ресурсы.
* '''[[Инфраструктура]]'''. Примерами могут служить: производственные объекты, оборудование, каналы телекоммуникаций организации, компьютерное аппаратное обеспечение, его доступность и мощности.
* '''[[Программное обеспечение]]'''. Примерами могут служить: инструменты составления расписаний, системы управления конфигурацией, веб-интерфейсы к работающим в режиме онлайн автоматизированными системам и системы авторизации работ.
* '''Доступность ресурсов'''. Примерами могут служить: ограничения на заключение договоров и осуществление закупок, утвержденные поставщики и субподрядчики, а также соглашения о сотрудничестве.
* '''Кадровые возможности'''. Примерами могут служить: профессиональная квалификация и опыт, навыки, [[компетенции]] и специальные знания кадровых ресурсов.

=== Внешние ФСП ===
Описанные ниже ФСП являются для организации внешними:
* '''Ситуация на рынке'''. Примерами могут служить: конкуренты, доля рынка, узнаваемость бренда и товарные знаки.
* '''Социальные и культурные влияния и проблемы'''. Примерами могут служить: политический климат, кодексы поведения, этические нормы и представления.
* Юридические ограничения. Примерами могут служить: национальные или местные законы и нормативно-правовые акты в области безопасности, защиты данных, делового поведения, трудовых отношений и закупочной деятельности.
* '''Коммерческие базы данных'''. Примерами могут служить: результаты сравнительного анализа, стандартизированные сметные данные, данные изучения промышленных рисков, базы данных рисков.
* '''Научные исследования'''. Примерами могут служить: отраслевые исследования, публикации и результаты сравнительного анализа.
* '''[[Стандарты|Государственные или промышленные стандарты]]'''. Примерами могут служить: предписания и стандарты регулирующих органов в отношении продуктов, производства, природопользования, качества и квалификации.
* '''Финансовые соображения'''. Примерами могут служить: курсы обмена валют, банковские ставки, показатели инфляции, тарифы и географическое положение.
* '''Материальные элементы среды'''. Примерами могут служить: производственные условия, погодные условия и ограничения.

== Активы процессов организации ==
'''Активы процессов организации''' (Organizational Process Assets) — это планы, процессы, политики, процедуры и базы знаний, специфичные для исполняющей организации и используемые ею. Данные активы оказывают влияние на управление проектом.

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

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

Поскольку АПО являются для организации внутренними, члены команды проекта могут быть в состоянии по мере необходимости вносить обновления и дополнения в активы процессов организации на всем протяжении проекта. Их можно разбить на две категории:
* '''[[Процесс|Процессы]], политики и процедуры'''. Их обновление обычно не входит в работы по проекту. Процессы, политики и процедуры обычно устанавливаются офисом управления проектами (ОУП) или другим функциональным подразделением, внешним по отношению к проекту. Они могут обновляться только с соблюдением соответствующих политик организации, связанных с обновлением процессов, политик или процедур. В некоторых организациях команде предлагают адаптировать шаблоны, жизненные циклы и контрольные списки к проекту. В таких случаях команда управления проектом должна адаптировать эти активы с целью удовлетворения потребностей проекта.
* '''[[база знаний|Базы знаний]] организации'''. Обновляются на всем протяжении проекта за счет использования информации проекта. Например, на всем протяжении проекта постоянно обновляется информация о финансовых результатах, извлеченных уроках, метриках и проблемах исполнения, а также недостатках.

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

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

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

=== Модель руководства ===
'''Модель руководства''' — это модель, в рамках которой в организации осуществляются властные полномочия. Эта модель включает в себя, среди прочего: правила, политики, процедуры, нормы, отношения, системы, процессы. Данная модель оказывает влияние на то, как:
* устанавливаются и достигаются цели организации,
* осуществляется мониторинг и оценка рисков,
* осуществляется оптимизация исполнения.

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

[[Файл:Организационные структуры.png|center]]

[[Категория: Категория:PMI PMBoK]]

База знаний

2022-07-23T18:04:11Z

Admin: /* Базы знаний по PMI PMBoK */

'''База знаний''' (БЗ; англ. knowledge base, KB) — база данных, содержащая правила вывода и информацию о человеческом опыте и знаниях в некоторой предметной области ([[ISO 24765|ISO/IEC/IEEE 24765-2010]], ISO/IEC 2382-1:1993). В самообучающихся системах база знаний также содержит информацию, являющуюся результатом решения предыдущих задач.

Современные базы знаний работают совместно с системами поиска и извлечения информации. Для этого требуется некоторая модель классификации понятий и определённый формат представления знаний. Иерархический способ представления в базе знаний набора понятий и их отношений называется [[онтология|онтологией]].

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

Область наук, изучающая базы знаний и методы работы со знаниями, называется [[Инженерия знаний|инженерией знаний]].

== Требования к информации ==
Двумя наиболее важными требованиями к информации, хранящейся в базе знаний интеллектуальной системы, являются:
* '''Достоверность''' конкретных и обобщённых сведений, имеющихся в базе данных;
* '''Релевантность''' информации, получаемой с помощью правил вывода базы знаний.

Некоторые из особенностей, которые могут (но не обязаны) быть у системы, оперирующей базами знаний:
* '''Автоматическое доказательство''' (вывод). Способность системы выводить новые знания из старых, находить закономерности в БЗ. Часто принимается, что база знаний отличается от базы данных именно наличием механизма вывода.
* '''Доказательство заключения'''. Способность системы после выдачи ответа «объяснить» ход её рассуждений, причем «по первому требованию».
* '''Интроспекция'''. Нахождение противоречий, нестыковок в БЗ, контроль правильной организации БЗ.
* '''Машинное обучение'''. Превращение БЗ в гибкую систему, адаптация к проблемной области. Аналогична человеческой способности «набирать опыт».

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

== Свойства базы знаний ==
Термин "''база знаний''" был придуман для того, чтобы отличить эту форму хранения знаний от более распространенного и широко используемого термина "''база данных''". В 1970-х годах практически все крупные информационные системы управления хранили свои данные в иерархических или реляционных базах данных. На этом этапе истории информационных технологий различие между базой данных и базой знаний было четким и однозначным. База данных обладала следующими свойствами:
* Табличное представление данных.
* Многопользовательский доступ.
* ACID: Атомарность, Согласованность, Изолированность и Надежность.

Первые системы, основанные на знаниях ([Экспертная система|экспертные системы]), имели потребности в данных, которые были противоположны этим требованиям к базам данных:
* Экспертная система требует структурированных данных. Не просто таблицы с числами и строками, а указатели на другие объекты, которые в свою очередь имеют дополнительные указатели. Идеальным представлением для базы знаний является объектная модель ([[онтология]]) с классами, подклассами и экземплярами.
* Экспертные системы не нуждались в многочисленных пользователях или в сложности, которая возникает при требовании ACID-свойств данных. К тому же эти требования не возможно было реализовать на доступных на тот момент технологиях.

По мере того, как экспертные системы переходили от прототипов к системам, развернутым в корпоративной среде, требования к хранению их данных быстро начали пересекаться со стандартными требованиями к базам данных для множества распределенных пользователей с поддержкой транзакций. Первоначально спрос можно было наблюдать на двух разных, но конкурирующих рынках. Из сообществ искусственного интеллекта и объектно-ориентированных технологий появились объектно-ориентированные базы данных, такие как [https://en.wikipedia.org/wiki/Versant_Object_Database Versant]. С другой стороны, крупные поставщики баз данных, такие как Oracle, добавили в свои продукты возможности, обеспечивающие поддержку требований баз знаний, таких как отношения между классами и подклассами и правила.

== Базы знаний по PMI PMBoK ==
[[:Категория:PMI PMBoK|PMI PMBoK]] относит базы знаний к [[Категории воздействий на предприятие#Активы процессов организации|активам процессов организации]].

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

== Корпоративная вики ==
''Источник: [https://www.knowledge-management-tools.net/corporate-wiki.php Corporate Wiki vs. Knowledge Base: The Best Choice for Your Business], 2019''

'''Корпоративная вики''' (англ. Enterprise wiki, Corporate Wiki) — программное обеспечение с использованием вики-технологий, предназначенное для использования в корпоративной информационной системе, прежде всего для обеспечения внутрикорпоративного [[Инженерия знаний|управления знаниями]].

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

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

По словам Уорда Каннингема ([https://en.wikipedia.org/wiki/Ward_Cunningham Ward Cunningham]), отца вики, существует множество различных вариантов использования внутренней вики в компаниях:
* '''Набор документов''', где пользователь может создать документ, предназначенный для широкого распространения.
* '''Площадка для взаимодействия''', где несколько сотрудников (часто из разных отделов или разных мест) могут одновременно работать над каким-либо вопросом.
* '''Площадка для обсуждения''', позволяющее нескольким сотрудникам высказывать свои мысли и мнения по поводу политик, процедур и документации.
* '''Всеобъемлющее хранилище документов''', где может находиться вся информация, необходимая для повседневной работы.
* '''Инструмент коммуникации''', который позволяет сотрудникам общаться по принципу "один ко многим" или "многие ко многим", не засоряя почтовые ящики.

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

Как говорится [https://helpjuice.com/blog/corporate-wiki в статье Helpjuice] о корпоративных вики и обмене знаниями, одним из главных аргументов в пользу бизнес-вики является идея "минимального надзора за содержимым". Пользователи могут изменять то, что они хотят, когда они хотят, и эти изменения действуют до тех пор, пока кто-то другой не придет и не внесет новые изменения или не вернется к предыдущей версии. Но это и её главный недостаток: предоставление нескольким сотрудникам возможности изменять информацию в корпоративной вики может способствовать возникновению конфликтов в организации.

Другие проблемы, с которыми может столкнуться компания при использовании внутренней вики:
* '''Ограниченность или отсутствие аналитики''': Вики - это не публичная страница, поэтому типичные аналитические инструменты (например, Google Analytics) обычно недоступны.
* '''Пробелы в контенте''': Когда люди обращаются к вики за темой, которой там нет, это называется пробелом в контенте (content gap). Это может быть распространенной проблемой для вики свободной формы, в которой нет меню, карты сайта или стандартного метода сообщения об отсутствующей или неверной информации.
* '''Устаревший контент''':
** Сотрудники любят добавлять информацию в вики, но не так старательно удаляют информацию, если она больше не актуальна или не точна, или обновляют ее, если что-то изменилось.
** Текучесть кадров может внести хаос в содержание внутренней вики компании. Если эксперт предметной области предоставляет или пересматривает информацию в вики, а затем покидает организацию, то эта информация будет оставаться статичной до тех пор, пока не будет найдена замена. Хотя корпоративная вики была разработана для того, чтобы знания не уходили вместе с сотрудником, на самом деле это не представляется возможным.
* '''Плохие возможности поиска''': Для того чтобы сделать поиск в вики простым и удобным для пользователя, участникам приходится проходить через множество различных препятствий. Иерархия и разделение контента, категоризация, тегирование, перекрестные ссылки и оптимизация поиска - все это необходимо для того, чтобы информацию было легко найти.
* '''Сложность освоения''': Предполагается, что система форматирования WYSIWYG проще и удобнее для пользователя, чем попытки изучить HTML-код только для того, чтобы выделить курсивом несколько ключевых слов. Но всё же при внедрении вики нужно оценивать возможность освоения WYSIWYG сотрудниками, при необходимости запланировать их обучение.
* '''Ограниченная настройка''': Изменения структуры в вики затруднены, поскольку платформа часто является довольно жесткой. Мы - цифровое общество, и нам нравится возможность персонализировать наш опыт в соответствии с нашими предпочтениями. Например, сотрудник определенного подразделения может захотеть видеть документы и страницы, относящиеся только к этой части компании. В структуре вики это невозможно. Кроме того, пользователи, как правило, не имеют практически никакой гибкости в отношении дизайна и интерфейса вики. Цвета, шрифты или ярлыки не могут быть настроены пользователем.

[[Категория:Технологии]]

База знаний

2022-07-23T18:03:57Z

Admin: /* Базы знаний по PMI PMBoK */

'''База знаний''' (БЗ; англ. knowledge base, KB) — база данных, содержащая правила вывода и информацию о человеческом опыте и знаниях в некоторой предметной области ([[ISO 24765|ISO/IEC/IEEE 24765-2010]], ISO/IEC 2382-1:1993). В самообучающихся системах база знаний также содержит информацию, являющуюся результатом решения предыдущих задач.

Современные базы знаний работают совместно с системами поиска и извлечения информации. Для этого требуется некоторая модель классификации понятий и определённый формат представления знаний. Иерархический способ представления в базе знаний набора понятий и их отношений называется [[онтология|онтологией]].

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

Область наук, изучающая базы знаний и методы работы со знаниями, называется [[Инженерия знаний|инженерией знаний]].

== Требования к информации ==
Двумя наиболее важными требованиями к информации, хранящейся в базе знаний интеллектуальной системы, являются:
* '''Достоверность''' конкретных и обобщённых сведений, имеющихся в базе данных;
* '''Релевантность''' информации, получаемой с помощью правил вывода базы знаний.

Некоторые из особенностей, которые могут (но не обязаны) быть у системы, оперирующей базами знаний:
* '''Автоматическое доказательство''' (вывод). Способность системы выводить новые знания из старых, находить закономерности в БЗ. Часто принимается, что база знаний отличается от базы данных именно наличием механизма вывода.
* '''Доказательство заключения'''. Способность системы после выдачи ответа «объяснить» ход её рассуждений, причем «по первому требованию».
* '''Интроспекция'''. Нахождение противоречий, нестыковок в БЗ, контроль правильной организации БЗ.
* '''Машинное обучение'''. Превращение БЗ в гибкую систему, адаптация к проблемной области. Аналогична человеческой способности «набирать опыт».

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

== Свойства базы знаний ==
Термин "''база знаний''" был придуман для того, чтобы отличить эту форму хранения знаний от более распространенного и широко используемого термина "''база данных''". В 1970-х годах практически все крупные информационные системы управления хранили свои данные в иерархических или реляционных базах данных. На этом этапе истории информационных технологий различие между базой данных и базой знаний было четким и однозначным. База данных обладала следующими свойствами:
* Табличное представление данных.
* Многопользовательский доступ.
* ACID: Атомарность, Согласованность, Изолированность и Надежность.

Первые системы, основанные на знаниях ([Экспертная система|экспертные системы]), имели потребности в данных, которые были противоположны этим требованиям к базам данных:
* Экспертная система требует структурированных данных. Не просто таблицы с числами и строками, а указатели на другие объекты, которые в свою очередь имеют дополнительные указатели. Идеальным представлением для базы знаний является объектная модель ([[онтология]]) с классами, подклассами и экземплярами.
* Экспертные системы не нуждались в многочисленных пользователях или в сложности, которая возникает при требовании ACID-свойств данных. К тому же эти требования не возможно было реализовать на доступных на тот момент технологиях.

По мере того, как экспертные системы переходили от прототипов к системам, развернутым в корпоративной среде, требования к хранению их данных быстро начали пересекаться со стандартными требованиями к базам данных для множества распределенных пользователей с поддержкой транзакций. Первоначально спрос можно было наблюдать на двух разных, но конкурирующих рынках. Из сообществ искусственного интеллекта и объектно-ориентированных технологий появились объектно-ориентированные базы данных, такие как [https://en.wikipedia.org/wiki/Versant_Object_Database Versant]. С другой стороны, крупные поставщики баз данных, такие как Oracle, добавили в свои продукты возможности, обеспечивающие поддержку требований баз знаний, таких как отношения между классами и подклассами и правила.

== Базы знаний по PMI PMBoK ==
[[:Категория:PMI PMBoK|PMI PMBoK]] относит базы знаний к [[Категории воздействий на предприятие|Активы процессов организации]].

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

== Корпоративная вики ==
''Источник: [https://www.knowledge-management-tools.net/corporate-wiki.php Corporate Wiki vs. Knowledge Base: The Best Choice for Your Business], 2019''

'''Корпоративная вики''' (англ. Enterprise wiki, Corporate Wiki) — программное обеспечение с использованием вики-технологий, предназначенное для использования в корпоративной информационной системе, прежде всего для обеспечения внутрикорпоративного [[Инженерия знаний|управления знаниями]].

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

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

По словам Уорда Каннингема ([https://en.wikipedia.org/wiki/Ward_Cunningham Ward Cunningham]), отца вики, существует множество различных вариантов использования внутренней вики в компаниях:
* '''Набор документов''', где пользователь может создать документ, предназначенный для широкого распространения.
* '''Площадка для взаимодействия''', где несколько сотрудников (часто из разных отделов или разных мест) могут одновременно работать над каким-либо вопросом.
* '''Площадка для обсуждения''', позволяющее нескольким сотрудникам высказывать свои мысли и мнения по поводу политик, процедур и документации.
* '''Всеобъемлющее хранилище документов''', где может находиться вся информация, необходимая для повседневной работы.
* '''Инструмент коммуникации''', который позволяет сотрудникам общаться по принципу "один ко многим" или "многие ко многим", не засоряя почтовые ящики.

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

Как говорится [https://helpjuice.com/blog/corporate-wiki в статье Helpjuice] о корпоративных вики и обмене знаниями, одним из главных аргументов в пользу бизнес-вики является идея "минимального надзора за содержимым". Пользователи могут изменять то, что они хотят, когда они хотят, и эти изменения действуют до тех пор, пока кто-то другой не придет и не внесет новые изменения или не вернется к предыдущей версии. Но это и её главный недостаток: предоставление нескольким сотрудникам возможности изменять информацию в корпоративной вики может способствовать возникновению конфликтов в организации.

Другие проблемы, с которыми может столкнуться компания при использовании внутренней вики:
* '''Ограниченность или отсутствие аналитики''': Вики - это не публичная страница, поэтому типичные аналитические инструменты (например, Google Analytics) обычно недоступны.
* '''Пробелы в контенте''': Когда люди обращаются к вики за темой, которой там нет, это называется пробелом в контенте (content gap). Это может быть распространенной проблемой для вики свободной формы, в которой нет меню, карты сайта или стандартного метода сообщения об отсутствующей или неверной информации.
* '''Устаревший контент''':
** Сотрудники любят добавлять информацию в вики, но не так старательно удаляют информацию, если она больше не актуальна или не точна, или обновляют ее, если что-то изменилось.
** Текучесть кадров может внести хаос в содержание внутренней вики компании. Если эксперт предметной области предоставляет или пересматривает информацию в вики, а затем покидает организацию, то эта информация будет оставаться статичной до тех пор, пока не будет найдена замена. Хотя корпоративная вики была разработана для того, чтобы знания не уходили вместе с сотрудником, на самом деле это не представляется возможным.
* '''Плохие возможности поиска''': Для того чтобы сделать поиск в вики простым и удобным для пользователя, участникам приходится проходить через множество различных препятствий. Иерархия и разделение контента, категоризация, тегирование, перекрестные ссылки и оптимизация поиска - все это необходимо для того, чтобы информацию было легко найти.
* '''Сложность освоения''': Предполагается, что система форматирования WYSIWYG проще и удобнее для пользователя, чем попытки изучить HTML-код только для того, чтобы выделить курсивом несколько ключевых слов. Но всё же при внедрении вики нужно оценивать возможность освоения WYSIWYG сотрудниками, при необходимости запланировать их обучение.
* '''Ограниченная настройка''': Изменения структуры в вики затруднены, поскольку платформа часто является довольно жесткой. Мы - цифровое общество, и нам нравится возможность персонализировать наш опыт в соответствии с нашими предпочтениями. Например, сотрудник определенного подразделения может захотеть видеть документы и страницы, относящиеся только к этой части компании. В структуре вики это невозможно. Кроме того, пользователи, как правило, не имеют практически никакой гибкости в отношении дизайна и интерфейса вики. Цвета, шрифты или ярлыки не могут быть настроены пользователем.

[[Категория:Технологии]]