В дополнение, несколько парадигм, которые мне помогали:
1. Постановка задачи предполагает наличие базовых компетенций.
Требование для сотрудника – определить, что цель установлена именно ему и перенаправление профессиональных вопросов его уровня компетенций обратно на уровень руководства «не приветствуется».
Требование для руководителя – необходимо учитывать наличие базовых компетенций у сотрудника при постанове цели.
2. При возникновении отклонения следует незамедлительное извещение инициатору запроса.
Требование для сотрудника – при возникновении отклонения необходимо предотвратить задержку принятия корректирующих действий руководителем.
Требование для руководителя – при возникновении отклонения требуется минимизировать время для корректировки декомпозиции выполнения или для постановки новой задачи.
3. Увеличение сущностей при решении задачи запрещено.
Минимизация не нужных действий сотрудника.
В бытность проекта по запуску первого лунохода на Луну подразделения под управлением Королева С.П. решали вопрос о составе почвы на спутнике Земли. Из-за возникших споров проект никак не мог стартовать. Одни были убеждены в том, что почва на Луне состоит из космической пыли и поэтому необходима соответствующая конструкция и форма колес. Другие настаивали на каменистости спутника и убеждали всех в альтернативном решении вопроса.
В один из дней, когда все пришли на работу, на стене компании был прибит лист со следующей формулировкой: «Луну считать твердой. (с) Королев С.П.»
Споры были прекращены и проект успешно стартовал, завершившись запуском лунохода. Как потом выяснилось, почва и правда была каменистой, но главный вывод в том, что при принятии парадигмы удалось сдвинуть проект с мертвой точки.
Ваша «Демократура» не что иное, как прерогатива руководителя вводить новые парадигмы управления. Я правильно понял?
Определение необходимых KPI для достижения поставленных целей очень важно на каждом уровне управления. И лучше отталкиваться именно от постановки целей на каждом уровне иерархии в компании, чем от критических факторов достижения успеха для неё в целом. На каждом уровне и у каждого направления деятельности компании разные KPI. Но кроме KPI есть и просто PI, которые необходимы для операционной статистики. Всё это важно различать…
У меня простое предложение — оставить на андроид только lite приложение (без антивируса и без расширенных функций). Это снизит стоимость разработки и повысит уровень лояльности пользователей. Причины называть не буду…
Думаю, что такой подход коллег обусловлен направлением потока обработки данных. Посредством Hadoop можно подключить большое количество сырых источников данных и после их очистки и подготовки к дальнейшей обработке перевести их (данные) в специализированные системы учета…
CRM необходима для помощи руководителю в достижении поставленных целей. Вывод — нет целей и нет CRM. Цели устанавливаются исходя из стратегии. Нет стратегии — нет целей. Всё просто.
«Предоставить инструменты для обработки полученных заказов» — сковородку, что-ли?) Софт использовался какой? Самописный или заказной? Мы тут опытом делимся… Детали реализации в студию.
Сервисы других подразделений автоматизировали на MS SharePoint, но затем стали все переводить на Pega Systems. Вторая хорошо держит нагрузку, а первая дешевле и проще в освоении…
ИТ не должны работать с не ИТ-инцидентами. Уже лет пять как в Сбере подключили сервисы АХО и СБ в единую систему HP Sevice Desk (after HP Service Manager) Запросы АХО обрабатывали сотрудники АХО, а запросы в СБ — сотрудники СБ. ИТ — предоставлял доступ и помогал с отчетами. А так статья хорошая!
Приветствую!
Большинство согласно, что 80% времени работы PM — коммуникации (а то и все 90)! Коммуникации с командой, с заказчиками, с другими стейкхолдерами проекта. А основные задачи в ходе проекта — управление рисками (намерено упустил этап подготовки)! Если рисков нет то и PM нам без надобности…
Как в Техносерве расставляют приоритеты для управления рисками проекта? Какие инструменты используют? Вот, собственно, что хотелось бы услышать.)
1. Постановка задачи предполагает наличие базовых компетенций.
Требование для сотрудника – определить, что цель установлена именно ему и перенаправление профессиональных вопросов его уровня компетенций обратно на уровень руководства «не приветствуется».
Требование для руководителя – необходимо учитывать наличие базовых компетенций у сотрудника при постанове цели.
2. При возникновении отклонения следует незамедлительное извещение инициатору запроса.
Требование для сотрудника – при возникновении отклонения необходимо предотвратить задержку принятия корректирующих действий руководителем.
Требование для руководителя – при возникновении отклонения требуется минимизировать время для корректировки декомпозиции выполнения или для постановки новой задачи.
3. Увеличение сущностей при решении задачи запрещено.
Минимизация не нужных действий сотрудника.
В один из дней, когда все пришли на работу, на стене компании был прибит лист со следующей формулировкой: «Луну считать твердой. (с) Королев С.П.»
Споры были прекращены и проект успешно стартовал, завершившись запуском лунохода. Как потом выяснилось, почва и правда была каменистой, но главный вывод в том, что при принятии парадигмы удалось сдвинуть проект с мертвой точки.
Ваша «Демократура» не что иное, как прерогатива руководителя вводить новые парадигмы управления. Я правильно понял?
Большинство согласно, что 80% времени работы PM — коммуникации (а то и все 90)! Коммуникации с командой, с заказчиками, с другими стейкхолдерами проекта. А основные задачи в ходе проекта — управление рисками (намерено упустил этап подготовки)! Если рисков нет то и PM нам без надобности…
Как в Техносерве расставляют приоритеты для управления рисками проекта? Какие инструменты используют? Вот, собственно, что хотелось бы услышать.)