Контроль эффективности осуществленных преобразований
После начала полного использования новой технологии необходимо произвести оценку эффективности проделанных изменений. При этом, если реальный эффект существенно ниже запланированного, не стоит расстраиваться, так как эта ситуация достаточно типична. Даже если после контрольного анализа осуществленных преобразований окажется, что эффективность их крайне низка или даже стремится к нулю, то есть только окупаются затраты, - это уже хорошо, и такие преобразования должны быть признаны положительными, и их имеет смысл продолжать.
Не стоит при этом забывать о таких следствиях, которые невозможно посчитать в денежном выражении, но которые приносят важные стратегические выгоды. Речь идет об общей активизации деятельности организации, создании у работников и менеджмента ощущения перспективы, дополнительной мотивации, росте интереса к организации со стороны и т.д.
Корректировка и закрепление изменений
На основании данных по реальной эффективности, а также результатов промышленной эксплуатации бывает необходимо осуществить корректировки в деятельности или внедренной технологии. Такие корректировки представляют собой незначительные изменения и возникают вследствие того, что решить все вопросы сразу практически невозможно. Относительно закрепления, или "замораживания", модифицированного процесса уже говорилось выше.
|
|
|
Организация проекта
Рассмотрев общие вопросы управления изменениями, настало время вернуться к области информационных технологий и рассмотреть организацию проектной работы, которая, как мы уже отмечали, является логичным продолжением проектов преобразований внутри организации и своей главной целью имеет практическую реализацию механизмов развития бизнеса.
Сразу стоит оговориться, что практику проектной работы мы будем рассматривать на основе проекта замены основной информационной системы банка, как и в первой части книги, где мы уже рассматривали работу по подбору решений на этом же примере. Это связано с тем, что это направление является одним из самых объемных и сложных в ИТ. Но все сказанное ниже будет актуально и для других ИТ-проектов, таких, как развитие интернет-услуг, замена компьютерного оборудования, автоматизация новых филиалов и т.п.
Проектная работа
Иногда кажется, что не существует причины, по которой бы организация, имеющая уверенно работающие структуры, стабильную, удовлетворяющую текущим требованиям информационную систему, решилась бы на дорогостоящий проект замены своей информационной базы. Более того, основная часть сотрудников и руководства полагает, что, купив и успешно внедрив у себя однажды то или иное информационное решение, организация навсегда закрыла для себя эту проблему.
|
|
|
Но жизнь опровергает подобное заблуждение. Независимо от типа организации, программного и аппаратного обеспечения, квалификации сотрудников каждый раз повторяется один и тот же сценарий жизни программного приложения. Он длится в среднем 10-15 лет, а при стремительном изменении внешней среды, как это было в последние годы у нас, - 5-7 лет. В течение этого времени программное обеспечение многократно дорабатывается, адаптируясь к новым условиям. Появляется большое количество различных дополнительных решений, реализованных вне рамок системы. При этом решения разрабатываются различными людьми, при полном отсутствии каких-либо стандартов и документации. Потом возникает необходимость установления связей между этими доработками, и количество проблем, требующих решения, возрастает многократно, становясь нерешаемыми.
В результате возникает ситуация, когда небольшое ядро, некогда являвшееся современной и перспективной системой, обрастает неконтролируемым множеством утилит и заплаток. Простое увольнение одного из программистов (средний срок работы программиста в кредитной организации 3-5 лет) приводит к полной переработке целой области информационных задач. Надежность, защищенность подобной системы не удовлетворяет никаким требованиям. И отсутствие проблем со службой безопасности объясняется только тем, что в России службы безопасности очень редко занимаются анализом программного обеспечения в банке. Любое изменение в правилах учета и обработки информации все сложнее реализуется в установленные сроки. Даже если компания-разработчик своевременно предоставляет все доработки, служба автоматизации банка не успевает своевременно адаптировать свои решения к новым условиям.
|
|
|
Попытка решить данную задачу приводит к тому, что менеджеры организации начинают обращать внимание на новые разработки, появляющиеся на рынке, и после очередной проблемы с устаревшей информационной системой принимают решения о покупке новой, которая, по их мнению, снимет большую часть проблем.
Однако выделенные деньги и поддержка руководства не гарантируют того, что проект будет удачным. Он может быть вообще нереализован. По данным ряда зарубежных консалтинговых агентств, около 20% проектов не внедряются. Хотя, если проект будет реализован, скорее всего затраты на него будут существенно выше ожидаемых. По тем же данным, только 16% проектов реализуются в соответствии с первоначальными планами, а затраты на реализацию остальных в среднем в 1,8 раза выше утвержденных бюджетом.
|
|
|
Рассмотрим, какие шаги придется выполнить организации, чтобы минимизировать потери и увеличить шанс успешного завершения проекта. Мы уже останавливались на особенностях проектной работы в самой первой главе, где проектный подход рассматривался как один из ключевых подходов к организации ИТ-службы банка. Но настало время остановиться на этом и рассмотреть отличия проектной и традиционной форм организации работы. Прежде всего нам необходимо определиться с тем, что же такое проект. Мы будем опираться на широко распространенную за рубежом методику управления проектами РМВОК 2000.
Итак, как правило, проекты направлены на выполнение каких-либо вполне определенных задач, связанных с достижением стратегических целей организации. Это происходит потому, что стратегические цели не могут быть достигнуты посредством текущей деятельности, они требуют создания изменений, а средство создания изменений - это проект.
Проекты обычно связаны с новой, уникальной и не повторяющейся или редко повторяющейся работой в отличие от обычной деятельности, которая носит регулярный характер. Поэтому они всегда носят временный характер, ограничены четкими временными раками, операционная же работа является преимущественно постоянной.
Согласно упомянутой выше методике проект - это любая деятельность, ограниченная во времени и направленная на создание уникального нового продукта, услуги или на достижение другой цели. Деятельность, ограниченная во времени, означает, что каждый проект имеет четко обозначенные начало и конец. Проекты осуществляются на всех уровнях организации, в них могут участвовать от нескольких человек до сотен людей.
Примеры проектов:
* разработка новой услуги;
* внутренние организационные изменения;
* реинжиниринг бизнес-процессов;
* разработка и внедрение новой информационной системы;
* внедрение новой бизнес-практики или процесса;
* развитие филиальной сети;
* техническое перевооружение;
* создание позитивного рыночного имиджа.
Общим между проектной и традиционной операционной организацией работ является то, что они выполняться людьми, используют ограниченные ресурсы, планируются и контролируются менеджментом.
Первичный анализ проекта
Первым шагом любого проект является определение его истинной цели. Необходимо, чтобы каждый участник четко понимал, почему организация вкладывает в проект огромные деньги вместо того, чтобы потратить их на зарплату или выплаты акционерам, какие преимущества по отношению к текущему состоянию он получит по завершению проекта. Только в этом случае участники проекта будут выступать единой командой, и шанс на его успешную реализацию существенно возрастет.
Следующим шагом является определение области проекта. Четкое ограничение рабочей области позволит существенно сократить время на обсуждение и согласование проекта.
После того как определены цель и область проекта, можно перейти к более детальной его проработке и описать условия выполнения. Результатом этого этапа (для нашего примера - замены информационной системы) должны стать ответы на следующие вопросы:
* Какой видится идеальная система? В данном ответе необходимо собрать описания идеальной системы от различных подразделений и определить набор параметров, которым она должна соответствовать.
* Какие параметры системы критичны и их значения? В продолжение предыдущего вопроса необходимо помимо идеальных значений определить минимально допустимые параметры.
* На каком ядре должна базироваться система? Ответ на этот вопрос может дать служба автоматизации на основе имеющегося опыта, наличии системных специалистов и уже имеющихся программно-аппаратных решений. Следует помнить, что, например, смена системы управления базами данных может стоить столько же, сколько и весь остальной проект.
* Каков общий бюджет проекта и каковы максимально допустимые затраты? Это разные величины, определяемые оптимистичным и пессимистичным прогнозами. Различаться на практике, исходя из предоставленных ранее данных, они могут в среднем в 2 раза, а иногда и более. При этом рекомендуется сначала определить максимально допустимую сумму и после этого переходить к сумме бюджета.
Результатом первичного анализа должно быть повторное решение о начале проекта. Учитывая, что первичный анализ не приводит к существенным затратам, принятие решения о временном отказе от проекта не будет психологической проблемой. При принятии повторного решения рекомендуется ответить на все те вопросы, которые уже рассматривались нами в главе "Выбор решений".
Возможно, обдумав все проблемы, которые возникнут при проекте, руководство банка примет решение повременить с его началом. Но если решение не изменилось, то начинается следующий этап.
Создание проектной команды
Для того чтобы решить задачи, направленные на достижение цели проекта, необходимо создать команду проекта под управлением менеджера проекта. При этом речь идет именно о команде со всеми ее признаками: у всех одна цель, хотя каждый имеет свои задачи, все принимают участие в решении важных вопросов, бюрократия сокращена до абсолютного минимума, все подчинено достижению цели, любые поощрения даются всем участникам проекта и только за достижение цели, неформальным лидером команды является самый опытный в решении текущего вопроса, члены команды консультируют друг друга.
Данный подход позволит консолидировать усилия и знания всех участников проекта. К сожалению, в большом количестве организаций объединить сотрудников подобным образом достаточно сложно. Часто различие в статусе подразделений настолько велико, что добиться полного сотрудничества кажется невозможным. Но тем не менее это необходимо.
Преодолеть это можно путем повышения статуса менеджера проекта. Хорошо, если его ранг будет уровня заместителя председателя банка. В этом случае различия между рядовыми участниками не будут казаться столь значительными, чтобы мешать работе. Для иллюстрации рассмотрим два примера.
Первый вариант. Руководитель проекта - начальник отдела автоматизации. Участники команды: сотрудник бухгалтерии (не самый опытный, поскольку самый опытный - главный бухгалтер - не может подчиняться начальнику отдела по статусу), сотрудники отдела автоматизации, казначей (человек, отвечающий за расходы), сотрудник фронт-офиса (тоже не руководитель). При такой организации в проектной группе образуются отношения, изображенные на рис. 17.
Второй вариант. Руководитель проекта - вице-президент банка. Участники команды: главный бухгалтер, начальник отдела автоматизации, казначей (человек, отвечающий за расходы), руководитель фронт-офиса. Отношения в проектной группе при такой организации изображены на рис. 18.
Как видно из схем, если руководитель проекта по статусу стоит выше всех остальных участников команды, имеющийся человеческий потенциал организации используется максимально эффективно. Это приводит к решению большей части задач с минимальным объемом затрат или совсем без них.
"Рис. 17. Схема взаимодействия при руководстве проектом (вариант 1)"
Стоит оговориться, что менеджер проекта может обладать высоким статусом, достаточным для решения всех задач, и не являясь членом правления организации. Так, он может иметь этот статус благодаря своим знаниям и опыту, то есть быть авторитетным экспертом организации или приглашенным со стороны менеджером. Причем этот последний вариант интересен тем, что при этом достигается очень важная составляющая - менеджер является независимым.
Постоянные работники организации слишком подвержены внутренним политическим и социальным отношениям, чтобы быть беспристрастными и профессиональными в полном объеме. Поэтому иногда их действия сложно объяснить. Они могут знать, что и как нужно сделать, но по определенным личным причинам не хотеть этого. Так, часто из-за боязни обнародования неудачи внутренние менеджеры стремятся затягивать проекты на годы, при этом обстоятельно аргументируя свою позицию, прикрываясь нуждами пользователей и необходимостью сделать все в лучшем виде.
"Рис. 18. Схема взаимодействия при руководстве проектом (вариантом 2)"
Особенно стоит обратить внимание на передачу ответственности за проектные затраты казначею. Вариантом такого решения может быть установка лимита затрат на проект с последующим премированием частью сэкономленных денег всех участников проекта. Другой приемлемый вариант - сосредоточение всех финансовых вопросов в руках менеджера проекта. В обоих случаях казначей будет выполнять также роль контролера всех затрат и роль аналитика, их оптимизирующего.
Несмотря на то что вклад руководителя проекта огромен, это ни в коем случае не умаляет роли самой команды. И здесь необходимо отметить несколько моментов. Команда должна подбираться исходя из социальной совместимости ее членов. Плюс к этому участники проекта должны уметь и любить работать в команде. Это умение может значить больше, чем собственный профессионализм, так как польза от задач, выполненных большим профессионалом-одиночкой, меньше, чем потенциальный вред для проекта от разрозненности, несогласованности, отсутствия единого подхода и тяги к нововведениям и изысканиям лучшего решения. Следующий важный аспект подбора команды состоит в том, чтобы оптимально подобрать команду единомышленников, которые при этом будут обладать максимально различными знаниями и умениями. Это связано с тем, что (в нашем примере в процессе смены информационной системы банка) во время реализации проекта всегда будут возникать сложные задачи из смежных областей, и тогда наличие в команде людей с разными знаниями и возможностями позволит решать максимально широкий объем задач без потери времени на поиск нужного специалиста или совета со стороны.
Отдельной темой является наличие времени у участников проекта для его выполнения. Любая деятельность во внерабочее время связана с дополнительными затратами, прямыми или косвенными. Грамотный руководитель проекта сведет такие работы к минимуму или откажется от них вовсе. Хорошим инструментом в поиске свободного времени является поденный месячный график выполняемых задач в течение месяца, а также почасовой график выполняемых задач за день (табл. 14). Для большинства специалистов кредитной организации данные графики неравномерны: там есть и пики, и периоды затишья, которые и являются временным резервом проекта. В общем использование резерва является бесплатным для организации. Иногда следует выполнить ряд работ, как правило, связанных с автоматизацией бизнес-процессов, для увеличения свободного рабочего времени. Автоматизация каких работ дает наибольший эффект, видно из построенных временных графиков (рис. 19).
В любом случае контроль за выполняемыми работами и за загруженностью участников проекта является одной из основных задач руководителя проекта, который должен стремиться к максимально оптимальному распределению задач исходя из особенностей каждого работника, плана проекта и их критичности.
Таблица 14
Дата добавления: 2019-01-14; просмотров: 168; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!