|
|||||||
Система принятия решений – бюрократизм: хорошо или плохо? или "пришел, увидел, подписал"
Автор: www.spiderproject.com
Компания: Технологии Управления Спайдер Украина
Руководитель проекта "N" наделен максимумом обязанностей при минимальных полномочиях. Требования Заказчика изменились с момента начала проекта. Команда проекта до сих пор состояла из одного только Руководителя проекта. Правила, по которым вынужден играть Руководитель проекта, оставляют желать лучшего в части эффективности и оперативности. Сам проект несет в себе массу неопределенностей. Имеет ли проект "N" шансы на успех? Какие условия для этого нужны?
Система принятия решений – бюрократизм: хорошо или плохо? или "пришел, увидел, подписал"
4 октября в рамках Недели "Конкурентных бизнес-моделей в управлении проектами", все желающие смогут принять участие в новом специализированном проекте "8 часов Концентрированной практики". Предлагаем Вашему вниманию второй кейс, который будет представлен в ходе проекта "8 часов Концентрированной практики". Каждый из участников проекта может выбрать тематическое направление группы. Работа в каждой из групп будет направлена на решение одной из практических задач.
Введение. История – как все начиналось. Для того, чтобы принять окончательное решение, Александр зарылся в архив проекта, составленный его предшественником. Выяснилось, что проект тянется уже несколько лет. Предпосылкой его возникновения стала практика использования большого числа баз данных в каждом из отделов организации. Вследствие этого получение сводных отчетов было сложным и длительным процессом. Собственник проекта пришел к пониманию и убедил руководство в том, что Компании необходимо не только накапливать информацию в разных системах, но иметь возможность эту информацию применять с пользой для себя. Это не только обеспечит Компанию информацией о текущем положении дел в режиме реального времени, но также улучшит скорость принятия решений и станет существенным конкурентным преимуществом. На этом, по имеющимся данным, роль Собственника в судьбе проекта "N" и закончилась. Первоначальной целью проекта "N" было создание общей аналитической системы Компании, которая бы аккумулировала данные из первичных систем, использующихся в разных подразделениях организации, которая бы обеспечивала всех сотрудников актуальной аналитической информацией – о клиентах, акциях, продажах, услугах и т.д. По сути, задумывалось создать единую базу данных Компании, с разным уровнем доступа к информации, мощными возможностями по формированию аналитических отчетов в соответствии с потребностями Пользователей. Однако из беседы с заинтересованными лицами Компании Александр вынес понимание того, что на сегодняшний день не существует единого видения конкретных задач проекта всеми его участниками. Собственник проекта, его Заказчик и внутренний Исполнитель вкладывают каждый свой смысл в формулировку цели и задач проекта. У Собственника и идейного вдохновителя проекта было свое понимание того, какой продукт должен получить пользователь от этого проекта. Пользователи, они же Заказчики проекта – слабо представляют себе как они будут использовать общую аналитическую систему. Какие именно данные будут отбираться для формирования отчетов, и как эти данные анализировать – остается для них "черным ящиком" в силу недостатка квалификации. Технические специалисты вообще остались в стороне, так как по внешне непонятным причинам для технической реализации идеи была приглашена компания-Подрядчик без соответствующего опыта работы. Первым руководителем проекта был назначен ИТ-специалист – человек прекрасно разбирающийся в своем деле, но не обладающий необходимыми управленческими качествами и опытом в моделировании аналитических систем. Он не "выбил" для себя полномочия формировать Команду проекта, привлекать ее к участию в работах и решать оперативные проблемы. Помимо этого оказалось, что в проекте сложилась очень сложная инфраструктура. Заказчиком в проекте выступает один из отделов Компании. Его представители должны определить, что должно получиться в итоге, т.е. ставить стратегические задачи перед Командой проекта. Отдел финансов решает все финансовые вопросы в том числе и вопросы, касающиеся взаиморасчетов. Отдел ИТ, как водится, отвечает за техническую реализацию проекта. Все эти участники проекта хотят оставить за собой решающее слово по любому из вопросов. Получается, что все важные действия Руководитель проекта должен согласовать с этими тремя сторонами, которым совсем не просто договориться между собой о компромиссе. Полный вариант кейса и его решения (оптимальные информационные потоки между участниками (бизнес-процесс и диаграмма), схема мотивации членов команды проекта) будут представлены 4 октября в рамках недели "Конкурентных бизнес-моделей в управлении проектами" Лучшие решения будут опубликованы на сайте www.spiderproject.com.ua 18.10.05.
Пресс-релизы компании Технологии Управления Спайдер Украина:
26 сентября 2005 Успех демо-тура превзошел все ожидания!
22 сентября 2005 Spider Project в Гонконге!
Читайте другие пресс-релизы:
Успех демо-тура превзошел все ожидания! [Технологии Управления Спайдер Украина]
Тренинг-Микс для внутренней и внешней коммуникации [КГ "Живое Дело"]
37 эффективных секретарей за два дня [КГ "Живое Дело"]
За последнюю неделю Центр "Спикер" выиграл 3 тендера на проведение корпоративного обучения! [Training center СПИКЕР]
Spider Project в Гонконге! [Технологии Управления Спайдер Украина]
');
|
|||||||