Management Framework - Свежие правки [ru]

Резюме Антона Витязя

2010-09-03T04:12:28Z

← Предыдущая		Версия 04:12, 3 сентября 2010
Строка 3:		Строка 3:
	==Общая информация==		==Общая информация==

-	'''Контакты''': Anton.Vityaz@gmail.com \| +380-91-~~114~~-~~0098~~	+	'''Контакты''': Anton.Vityaz@gmail.com \| +380-50-477-4323

-	'''Соцдем''': Родился 04.12.1978 в г. Киев, женат, ~~сыну 3 года~~.	+	'''Соцдем''': Родился 04.12.1978 в г. Киев, женат, есть сын.

	==Компетенции==		==Компетенции==
Строка 24:		Строка 24:
	==История==		==История==
	===История достижений===		===История достижений===
		+	* Запуск корпоративного портала на платформе Sharepoint 2010
		+	* Автоматизация процессов - правового обеспечения, Complaince management, наблюдательного совета, документооборота, сервисных заявок
		+	* Внедрение инструментов Офиса управления проектами, проектной методики
	* Участие в создании сообщества [http://system-analyst.org.ua/ Системных аналитиков украины]		* Участие в создании сообщества [http://system-analyst.org.ua/ Системных аналитиков украины]
	* Запуск и развитие сайта [http://www.management-framework.org.ua management-framework.org.ua]		* Запуск и развитие сайта [http://www.management-framework.org.ua management-framework.org.ua]
Строка 43:		Строка 46:

	===История работы===		===История работы===
-	* '''~~Укртелеком~~''', ~~2008~~-..., начальник отдела поддержки маркетинга, ведущий специалист развития продуктов и услуг, руководитель группы CRM	+	* '''ДТЭК''', 2010-..., начальник отдела корпоративных систем управления информацией (Project, Sharepoint)
		+	* '''Укртелеком''', 2008-2010, начальник отдела поддержки маркетинга, ведущий специалист развития продуктов и услуг, руководитель группы CRM
	* '''Банкомсвязь''', 2005-2008, руководитель группы разработчиков продукта CRM, руководитель отдела CRM		* '''Банкомсвязь''', 2005-2008, руководитель группы разработчиков продукта CRM, руководитель отдела CRM
	* '''Celenia Ukraine''', 2002-2005, руководитель групп разработки Axapta, Navision, программист Navision		* '''Celenia Ukraine''', 2002-2005, руководитель групп разработки Axapta, Navision, программист Navision

Антон Витязь

2010-09-03T04:09:35Z

← Предыдущая		Версия 04:09, 3 сентября 2010
Строка 8:		Строка 8:
	'''Контакты''':		'''Контакты''':
	* e-mail: [mailto:vityaz@management-framework.org.ua vityaz@management-framework.org.ua]		* e-mail: [mailto:vityaz@management-framework.org.ua vityaz@management-framework.org.ua]
-	* mob.: +380-91-~~114~~-~~0098~~	+	* mob.: +380-50-477-4323

	Смотри также: [[Резюме Антона Витязя]].		Смотри также: [[Резюме Антона Витязя]].

Омае, Мышление стратега

2010-09-01T03:52:43Z

Новая страница: «Категория:Книга ==О книге== Кеничи Омае "Мышление стратега. Искусство бизнеса по-японски" …»

Новая страница

[[Категория:Книга]]
==О книге==
Кеничи Омае "Мышление стратега. Искусство бизнеса по-японски"
Kenichi Ohmae. The Mind of the Strategist: The Art of Japanese Business

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

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

==Содержание==
Часть I
'''ИСКУССТВО СТРАТЕГИЧЕСКОГО МЫШЛЕНИЯ'''

Глава 1. Анализ: исходная точка

Глава 2. Четыре пути к стратегическому преимуществу

Глава 3. Фокусирование на ключевых факторах

Глава 4. Использование относительного превосходства

Глава 5. Применение агрессивных инициатив

Глава 6. Использование стратегических степеней свободы

Глава 7. Секрет стратегического видения

Часть II
'''ПОСТРОЕНИЕ УСПЕШНЫХ СТРАТЕГИЙ'''

Глава 8. Стратегический треугольник

Глава 9. Стратегии, нацеленные на потребителя

Глава 10. Стратегии, нацеленные на корпорации

Глава 11. Стратегии, нацеленные на конкурентов

Глава 12. Корпоративная стратегия

Часть III
'''СОВРЕМЕННЫЕ СТРАТЕГИЧЕСКИЕ УСЛОВИЯ'''

Глава 13. Понимание экономической среды

Глава 14. Стратегические изменения

Глава 15. Япония: мифы и реальность

Глава 16. Принятие дальновидных решений

Глава 17. Формула стратегического успеха

==Дополнительная информация==
* [http://www.alpina.ru/book/570/ Сайт издательства книги alpina.ru]
* [http://community.livejournal.com/mustread/107549.html Отзыв о книге на mustread (5/10)]

==Смотри также==
* [[:Категория:Стратегическое управление]]

Главный план

2010-08-29T19:30:03Z

Новая страница: «Категория:Термин Категория:Терминология управления проектами Главный план - [[Маст…»

Новая страница

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

[[Главный план]] - [[Мастер план]].

{{Project_Roadmap}}

Мастер план

2010-08-29T19:29:50Z

Новая страница: «Категория:Термин Категория:Терминология управления проектами Мастер план ([[Главн…»

Новая страница

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

[[Мастер план]] ([[Главный план]], [[Master plan]]) - план, объединяющий в себе несколько планов посредством установления общих ресурсов, связей между проектами или между проектом и задачами мастер плана.

{{Project_Roadmap}}

Master plan

2010-08-29T19:28:24Z

Новая страница: «Категория:Термин Категория:Терминология управления проектами Master plan - [[Мастер пла…»

Новая страница

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

[[Master plan]] - [[Мастер план]]/[[Главный план]].

{{Project_Roadmap}}

Оценка в рамках горизонта планирования

2010-08-29T19:27:08Z

← Предыдущая		Версия 19:27, 29 августа 2010
(1 промежуточная версия не показана)
Строка 4:		Строка 4:

	Установка горизонта планирования помогает определить рамки четкой видимости задач проекта, опубликовать их и далее поэтапно обновлять [[план проекта]] расширяя горизонт планирования пока он не покроет весь проект.		Установка горизонта планирования помогает определить рамки четкой видимости задач проекта, опубликовать их и далее поэтапно обновлять [[план проекта]] расширяя горизонт планирования пока он не покроет весь проект.
		+
		+	Смотри также:
		+	* [http://www.pmforum.org/viewpoints/2009/PDFs/apr/Brown-Planning-Horizon.pdf "What is your project's planning horizon?", PM World Today]
		+	* [http://en.wikipedia.org/wiki/Time_horizon Wikipedia::Time horizon]


	{{Project_Roadmap}}		{{Project_Roadmap}}

Терминология управления проектами В-Д

2010-08-29T09:24:13Z

← Предыдущая		Версия 09:24, 29 августа 2010
Строка 7:		Строка 7:

	'''Г''':		'''Г''':
		+	* [[Главный план]] - [[Мастер план]] ([[Master plan]])
	* [[Горизонт планирования]]		* [[Горизонт планирования]]
	* [[Границы работ]]		* [[Границы работ]]

Терминология управления проектами К-Н

2010-08-29T09:23:42Z

← Предыдущая		Версия 09:23, 29 августа 2010
Строка 8:		Строка 8:

	'''М''':		'''М''':
		+	* [[Мастер план]] ([[Master plan]])
	* [[Матрица ответственности]] ([[Матрица распределения ответственности]]) - [[Responsibility matrix]]		* [[Матрица ответственности]] ([[Матрица распределения ответственности]]) - [[Responsibility matrix]]
	* [[Матрица рисков]] ([[Risk matrix]])		* [[Матрица рисков]] ([[Risk matrix]])

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

2010-08-29T09:21:49Z

Определение содержания и составление расписания:

← Предыдущая		Версия 09:21, 29 августа 2010
Строка 39:		Строка 39:
	* [[Разработка календарного графика проекта]]		* [[Разработка календарного графика проекта]]
	* [[Определение базового плана проекта]]		* [[Определение базового плана проекта]]
		+	* [[Определение общего плана проекта]] ([[мастер план]], [[главный план]])

	=== Оценка ===		=== Оценка ===

Оценка в рамках горизонта планирования

2010-08-29T09:20:14Z

Новая страница: «Категория:Управление проектами Категория:Метод В ряде длительных проектов …»

Новая страница

[[Категория:Управление проектами]]
[[Категория:Метод]]
В ряде длительных [[проект|проектов]] часто бывает невозможно полностью и достоверно оценить и проработать все задачи. Но при этом требуется согласовать план проекта, запустить в реализацию первые этапы проекта, опубликовать задачи. В таких ситуациях в проекте имеет смысл установить такой параметр как [[горизонт планирования]].

Установка горизонта планирования помогает определить рамки четкой видимости задач проекта, опубликовать их и далее поэтапно обновлять [[план проекта]] расширяя горизонт планирования пока он не покроет весь проект.

{{Project_Roadmap}}

Горизонт планирования

2010-08-29T09:16:05Z

Новая страница

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

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

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

{{Project_Roadmap}}

Терминология управления проектами В-Д

2010-08-29T09:11:07Z

← Предыдущая		Версия 09:11, 29 августа 2010
Строка 7:		Строка 7:

	'''Г''':		'''Г''':
		+	* [[Горизонт планирования]]
	* [[Границы работ]]		* [[Границы работ]]
	* [[График ресурса]]		* [[График ресурса]]

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

2010-08-29T09:10:30Z

Оценка:

← Предыдущая		Версия 09:10, 29 августа 2010
Строка 57:		Строка 57:
	* [[Оценка требований к ресурсам]]		* [[Оценка требований к ресурсам]]
	* [[Оценка времени и стоимости проекта]]		* [[Оценка времени и стоимости проекта]]
		+	* [[Оценка в рамках горизонта планирования]]

	=== Финансы, бюджет ===		=== Финансы, бюджет ===

Декомпозиция задачи

2010-08-29T09:08:32Z

Новая страница: «Категория:Управление проектами Категория:Метод В случае если задача не поддается точ…»

Новая страница

[[Категория:Управление проектами]]
[[Категория:Метод]]
В случае если задача не поддается точной оценке из-за сложностей с пониманием ее состава, если ее размер достаточно большой в масштабах данного проекта то имеет смысла перейти на более подробную детализацию задачи - составить полную пошаговую карту выполнения задачи. После определения подробного перечня задач необходимо расставить промежуточные результаты выполнения работы. Далее следует оценить количество задач, оценить возможность частичного [[Сжатие работ|сжатия]] количества задач.

'''Смотри также''':
* [[Декомпозиция работ]]
* [[Сжатие работ]]
* [[Расчет оптимального количества задач]]
* [[Проблемы оценки работ проекта]]
* [[Методы оценки работ]]
* [[Определение содержания проекта]]

{{Project_Roadmap}}

Сжатие работ

2010-08-29T09:05:33Z

Новая страница: «Категория:Управление проектами Категория:Метод При планировании задач часто получае…»

Новая страница

[[Категория:Управление проектами]]
[[Категория:Метод]]
При планировании задач часто получается что детализация задач является чрезмерной - количество задач, глубина детализации задач являются чрезмерными. Иногда это касается новых задач для оценки которых была выполнена полная пошаговая карта выполнения задачи - данная карта полезна для исполнителя для точного понимания порядка выполнения задач, хороша в описании работы в [[структура работ|структуре работ]] но перегружает план проекта.

В этом случае надо определить:
* Какие промежуточные результаты выполнения работы? Можно ли оставить промежуточные результаты как контрольные точки в проекте?
* Какие задачи можно объединить в одну общую задачу?
* Что является исключительно функциональными задачами которые определены в бизнес процессах и их выполнение не требуется контролировать в плане проекта?
* Можно ли выделить значительное количество важных для контроля задач в отдельный подпроект и поручить его другом менеджеру проекта? Можно ли сам проект в целом разбить на несколько проектов?

'''Смотри также''':
* [[Декомпозиция работ]]
* [[Расчет оптимального количества задач]]
* [[Проблемы оценки работ проекта]]
* [[Методы оценки работ]]
* [[Определение содержания проекта]]

{{Project_Roadmap}}

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

2010-08-29T08:44:11Z

Определение содержания и составление расписания:

← Предыдущая		Версия 08:44, 29 августа 2010
(1 промежуточная версия не показана)
Строка 27:		Строка 27:
	** [[Определение содержания продукта]] (документ [[Содержание продукта]], [[Product scope]])		** [[Определение содержания продукта]] (документ [[Содержание продукта]], [[Product scope]])
	* [[Декомпозиция работ]] (документ [[Структура работ]], [[WBS]])		* [[Декомпозиция работ]] (документ [[Структура работ]], [[WBS]])
		+	** [[Декомпозиция задачи]]
		+	** [[Сжатие работ]]
	** [[Работа, задача и операция]]		** [[Работа, задача и операция]]
	** [[Типы проектных работ]]		** [[Типы проектных работ]]

Вопросы при оценке работ

2010-08-29T08:37:42Z

Новая страница

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

Далее надо проверить данные для оценки графика выполнения задачи - когда ее можно начать, какой график выделения ресурса будет. Можно собрать и проверить следующие данные:
* Уточнить текущую загрузку у эксперта и его руководителя.
* Получить согласие на использование ресурса в указанные сроки с указанным графиком.
* Не собирается ли увольняться исполнитель в срок выполнения задачи?
* Не планируется очень срочных мероприятий и задач в подразделении сотрудника?
* Проверьте отпуск или личные планы сотрудника которые могут повлиять на его рабочий график на время выполнения задач.
* Как часто болеет исполнитель? Есть ли сезонные заболевания? Какой риск? (значение данных вопросов обостряются в осенне-зимний сезон для задач с одним исполнителем на длительный срок которого трудно заменить).

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

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

'''Смотри также''':
* [[Проблемы оценки работ проекта]]
* [[Методы оценки работ]]
** [[Метод оценки работы по аналогии]]
** [[Метод оценки работы по функциональным точкам]]
** [[Метод экспертной оценки работы]]
** [[Метод Дельфи]] ([[Delphi Technique]])
** [[Метод набегающей волны]]
** [[Оценка по трем точкам]]
** [[COCOMO]]
* [[Определение содержания проекта]]
* [[Декомпозиция работ]]

{{Project_Roadmap}}

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

2010-08-29T07:57:53Z

Оценка:

← Предыдущая		Версия 07:57, 29 августа 2010
Строка 40:		Строка 40:
	=== Оценка ===		=== Оценка ===
	* [[Методы оценки работ]]		* [[Методы оценки работ]]
		+	* [[Вопросы при оценке работ]]
	* [[Метод оценки работы по аналогии]]		* [[Метод оценки работы по аналогии]]
	* [[Метод оценки работы по функциональным точкам]]		* [[Метод оценки работы по функциональным точкам]]