facebook
twitter
vk
instagram
linkedin
google+
tumblr
akademia
youtube
skype
mendeley
Wiki
Global international scientific
analytical project
GISAP
GISAP logotip

РОЛЬ АНТИЦИПАТИВНОГО УПРАВЛЕНИЯ В РЕАЛИЗАЦИИ ПРОЕКТОВ

Автор Доклада: 
Габышева А.М.
Награда: 
РОЛЬ АНТИЦИПАТИВНОГО УПРАВЛЕНИЯ В РЕАЛИЗАЦИИ ПРОЕКТОВ

РОЛЬ АНТИЦИПАТИВНОГО УПРАВЛЕНИЯ В РЕАЛИЗАЦИИ ПРОЕКТОВ

Габышева Аина Михайловна, бакалавр
Российский университет дружбы народов

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

Не секрет, что в течение всего жизненного цикла проекта его участники решают совместные проблемы, согласовывают планы, стратегии, идут на компромиссы, пытаются понять друг друга и добиться цели. На всех проектах длительностью от полугода, представители подрядчика и заказчика успевают установить товарищеские отношения. Как правило, подобные отношения устанавливают руководители проектов, а также представители команды проекта, активно вовлеченные в проектную работу. Такие товарищеские отношения полезны для проекта, они повышают мотивацию, эффективность, кроме того, общаясь между собой, члены команды получают знания и опыт друг друга, повышая уровень квалификации, но иногда подобные отношения могут принести вред. Так, рассмотрим ситуацию.
В одной компании, скажем в проектно-ориентированной ИТ-компании, было принято решение о внедрении новой ERP системы. К вопросу подошли серьезно, был проведен анализ существующих систем, конкурс на выбор системы и внедряющей компании, GAP анализ и проект оказался на стадии внедрения.
И вот, наконец, наступает момент технического тестирования заказчиком. В ходе тестирования, один из аналитиков выяснил, что хотя тестируемая им часть и работает в соответствии с техническим заданием, но ее можно модифицировать и сделать работу значительно более эффективной. Он подошел с этим вопросом к менеджеру проекта. Перед менеджером проекта встала проблема выбора. С одной стороны – улучшения очевидны, согласовать их с конечными пользователями можно, с другой – в связи с долгим процессом согласования запросов на изменения руководством, последующей оценкой запроса подрядчиком, регрессионным тестирование и т.п., произойдет затягивание сроков проекта и увеличение бюджета. Он решил посовещаться с менеджером проекта со стороны подрядчика.
В результате совещания, менеджеры проекта со стороны заказчика и исполнителя пришли к выводу, что внести изменения стоит, а вот оформлять формально нет. Т.к. изменение системы было минимальным, разработчик подрядчика через пару часов прислал небольшой программный патч, вносящий эти изменения менеджеру проекта подрядчика, а тот передал его на диске заказчику. Патч был установлен на отдельную тестовую среду (ее удалось создать за пару дней) и проверен. Система работала так, как было необходимо. Во время пользовательского тестирования, пользователи очень обрадовались изменениям, т.к. они упрощали работу. Систему сдали (установив на боевую среду патч), проект успешно завершился, все счастливы. За одним исключением.
Через три месяца работы системы в промышленной эксплуатации были выявлены расхождения в отчетности и реальном положении дел. Потратив еще порядка недели на расследование инцидента, выяснилось, что благодаря внесенным изменениям, система все-таки работает неверно. Округления. Система выполняет округления не так, как было заявлено в техническом задании. Это не было заметно во время тестирования, т.к. тестирование проходило все-таки на небольшом объеме данных, но когда состоялся запуск системы в промышленную эксплуатацию, расхождения накопительным итогом, полученные в результате округлений, достигли значительных сумм. Выяснилось, что в системе до установки патча, округления происходили верно. Ошибка была заявлена в техническую поддержку компании подрядчика, однако, вскоре был получен ответ, что согласно условиям договора, поддерживается поставленная в компанию версия системы, без доработок заказчика, а ошибка, заявленная в службу технической поддержки, возникла в результате изменения кода заказчиком. Подрядчик согласился исправить ошибку за дополнительную плату, но при этом терялась новая функциональность и, если требовалось исправить некорректные данные, то стоимость их исправления была высокой. Заказчику ничего не оставалось, как оплатить исправления.
Поспешные решения легко могут принести вред. Ошибка была не только в решении разработчика внести изменения в код, но и в том, что заказчик попросил провести изменения неформально, не согласовав со всеми членами команды. Данный пример показывает, что некачественный анализ ситуации, экономия времени и финансовых средств на какой-либо стадии могут принести серьезные потери как для проекта и самой компании, так и для пользователей. Малейшая ошибка может разрушить всю систему работы и привести к провалу проекта. В данном случае, менеджеры не применили соответствующую антиципативную технологию антикризисного управления, что привело, по крайней мере, к потере финансовых ресурсов компании.
В следующей ситуации рассмотрим насколько может положительно повлиять антиципативное управление в проекте. Как правило, запоминаются негативные моменты, но от положительного опыта пользы для будущих проектов больше, чем от отрицательного.
Часто, во время проектов внедрения информационных систем недооценивается роль ключевых пользователей и службы технической поддержки для успеха проекта. Очень важно уделять внимание ключевым пользователям и службе технической поддержки.
В одной компании открыли крупную и амбициозную программу. Программа подразумевала открытие нового направления бизнеса, под который необходимо было, в том числе, приобрести и внедрить новую ИТ систему. Проект по внедрению системы благополучно инициировали, наняли консультантов, провели тендер, выбрали систему и приступили к внедрению. Разумеется, внедрить крупную систему без доработок невозможно. Поэтому, был внедрен этап анализов разрыва (GAP analysis) между функциональностью системы и требованиям бизнеса. На каждый найденный разрыв была написана техническая спецификация, а на настройки самой системы – техническое задание. С момента написания технического задания на проекте активно использовалась группа сотрудников, выступавших экспертами в своих областях. Эти эксперты планировались как ключевые пользователи системы. Именно они должны были обучиться работе в системе и в будущем, составить некий центр экспертизы компании по ИТ системе. Так оно и получилось. Момент обучения работе в системе предшествовал утверждению технических спецификаций и технического задания, поэтому у группы сформировалось понимание работы системы до того, как она была доработана и запущена.
Обучение группы ключевых пользователей системы проводилось в два этапа. Первый этап подразумевал обучение пользователей стандартной функциональной системы. Уже на этом этапе возникло большое количество вопросов и список разрывов был пополнен. Результатом данного обучения стало понимание принципов работы системы, того что в ней реализуемо, а что нет. На втором этапе, обучение проходило на прототипе системы, созданном для компании. На данном этапе обучения «всплыли» тонкие нюансы и достаточно сумбурное понимание функционирования системы, полученное в результате первого обучения, структурировалось. В результате, команда экспертов в различных областях бизнеса компании превратилась в экспертов по системе. Они не лезли в дебри технологий и технических нюансов, но отлично понимали настройки системы и знали тонкости использования функционала. Кроме того, побочным эффектом длительного совместного обучения явилось сплочение команды, возникновение командного духа, интереса к внедрению. Впоследствии, эти ключевые пользователи стали опорой в своих подразделениях в части внедряемой системы. Они выполняли функции аналитиков и консультантов, перекладывали требования своих бизнес подразделений на функциональные требования к системе, обучали пользователей, продумывали возможное будущее развитие системы. После внедрения, приказом генерального директора, эти ключевые пользователи были назначены лицами, ответственными за различные функциональные области системы.
Вторым фактором успешного внедрения стало раннее подключение команды технической поддержки производителя системы. Переход проекта на стадию технической поддержки, как правило, болезненный процесс. Руководитель проекта уже снял с себя полномочия и ответственность, пользователи уже начали находить ошибки в системе, а техническая поддержка еще не имеет экспертизы в доработках системы. Так обычно происходит. На данном проекте было сделано немного иначе. Команду технической поддержки со стороны заказчика начали привлекать к проекту еще со стадии написания технического задания (правда, в весьма умеренном объеме), со стороны производителя – со стадии тестирования системы. Раннее привлечение команд технической поддержки к работам над системой позволило оперативно исправлять выявленные пользователями ошибки (количество которых, к окончанию проекта, удалось снизить благодаря тщательному тестированию системы), а также регламентировать все спорные административные моменты, которые не были прописаны в соглашении об уровне сервиса.
Таким образом, наличие грамотных, обученных системе ключевых пользователей, имеющих экспертизу во всех областях бизнеса компании, привлечение их и служб технической поддержки на ранних стадиях проекта явилось ключевыми факторами успешного внедрения. Систему не только внедрили, но внедрили в рамках требований, и в соответствии с ожиданиями пользователей. Такое внедрение показывает, что роль антиципативной технологии антикризисного управления является очень важной для любого проекта. В данном случае, компания может и потратила больше средств на обучение персонала, однако это явилось ключевым фактором успеха. Ведь в будущем, ей не придется каждый раз приглашать экспертов со стороны, когда как они есть внутри компании. А это является очень ценным ресурсом.
Таким образом, рассмотретние данной проблемы позволяет сделать вывод, что необходимо научиться применять антиципативную технологию во всех проектах. Нужно видеть дальше, понимать глубже и не экономить финансовые средства на управление человеческими ресурсами, исследование и тестирование системы на начальном этапе, т.к. чем меньше мы уделяем этому внимания, тем больше у нас риск наступления кризиса в будущем. Новый тип мышления, новый подход к управлению может в корне изменить всю ситуацию.

Литература:

  • 1. Журнал «Управление проектами» №1, 2010. Алексей Ким, «Усвоенные уроки проектов», стр. 22-25
  • 2. Лекция к.э.н., старшего преподавателя, Роенко Е.А., «Технология преодоления кризисных явлений на предприятии», Российский университет дружбы народов, 2010 
9.28571
Ваша оценка: Нет Средняя: 9.3 (14 голосов)

вопрос

"Здравствуйте, Аина! После прочтения Вашей статьи у меня возник следующий вопрос: на ком лежит ответственность за проведение анцитипативных процедур?"

Алена Васильевна, спасибо за

Алена Васильевна, спасибо за вопрос. Данная статья затрагивает проблему относительности наших познаний и шаблонности нашего обучения, вследствие чего мы совершаем (казалось бы, мелкие) ошибки, которые приводят к неожиданным (часто масштабным и затратным) последствиям. Это касается каждого из нас, любого дела. Но так как в данной статье я рассмотрела роль антиципативных мер в рамках управления проектами, то ответственность лежит непосредственно на менеджеров проекта (со стороны заказчика и исполнителя).
Партнеры
 
 
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
image
Would you like to know all the news about GISAP project and be up to date of all news from GISAP? Register for free news right now and you will be receiving them on your e-mail right away as soon as they are published on GISAP portal.