Задачи и внедрение Бизнес-стратегия Стратегия в области ит основные тенденции развития ит (стр. 45 из 98)
На основании концептуальной модели определяется порядок взаимодействия между подразделениями. Проводится наложение бизнес-процессов предоставления услуг на предлагаемую схему работы. Определяются регламентирующие документы и нормативные акты, управляющие рассматриваемыми процессами.
Далее производится заключительная детализация модели до элементарных бизнес-операций и технологических решений по их реализации. Параллельно производится корректировка модели в соответствии с возможностями ее реализации и техническими возможностями.
Модель "Как должно быть" также проходит несколько стадий согласований и после этого подлежит утверждению высшим руководством банка.
После описания перспективной технологии, ее корректировки и окончательного утверждения во всех деталях необходимо разработать детальный план внедрения новой технологии с распределением сроков, контрольных точек и ответственных лиц. Такой план может содержать следующие пункты:
* разработка новых должностных инструкций в соответствии с измененными обязанностями исполнителей;
* корректировка учетной политики банка, других внутренних регламентов;
* обучение сотрудников новой технологии;
* прием экзаменов по результатам обучения;
* разработка или настройка программного обеспечения и т.д.;
* запуск новой технологии в опытную эксплуатацию;
* переход на полное промышленное использование новой технологии.
Все эти процедуры должны быть по возможности распараллелены и сопряжены по срокам для меньшей затраты времени на реализацию проекта в целом. Для представления сложных громоздких проектов и осуществления контроля за ними удобно использовать современные инструментальные средства управления проектами.
Достаточно простым примером такого средства может служить программный продут компании Microsoft - MS Project. Этот продукт позволяет автоматизировать распределение ресурсов, контроль выполнения отдельных этапов проекта и связанных задач, общее планирование. Он обладает возможностями планирования и распределения людских ресурсов, мониторинга нагрузок, построения сетевых графиков и Гант-диаграмм, гибкой системой отчетных форм, а также многими другими возможностями. Данный программный продукт в конечном счете облегчает непростую задачу управления проектами с десятками и даже сотнями подзадач, большинство из которых связаны различным образом с другими работами и большим количеством исполнителей. Внешний вид интерфейса данного программного продукта представлен на рис. 16.
"Рис. 16. Вид интерфейса программного продукта Microsoft Project"
He менее важно заранее составить и утвердить бюджет преобразований, в котором будут запланированы все расходы, связанные с реализацией плана реинжиниринга. С учетом того что подавляющее число подобных проектов не укладываются в первоначальный бюджет и испытывают нехватку ресурсов, необходимо заранее на стадии бюджетного планирования заложить специальный резерв в размере 20-25% для покрытия возможных перерасходов.
Контроль эффективности осуществленных преобразований
После начала полного использования новой технологии необходимо произвести оценку эффективности проделанных изменений. При этом, если реальный эффект существенно ниже запланированного, не стоит расстраиваться, так как эта ситуация достаточно типична. Даже если после контрольного анализа осуществленных преобразований окажется, что эффективность их крайне низка или даже стремится к нулю, то есть только окупаются затраты, - это уже хорошо, и такие преобразования должны быть признаны положительными, и их имеет смысл продолжать.
Не стоит при этом забывать о таких следствиях, которые невозможно посчитать в денежном выражении, но которые приносят важные стратегические выгоды. Речь идет об общей активизации деятельности организации, создании у работников и менеджмента ощущения перспективы, дополнительной мотивации, росте интереса к организации со стороны и т.д.
Корректировка и закрепление изменений
На основании данных по реальной эффективности, а также результатов промышленной эксплуатации бывает необходимо осуществить корректировки в деятельности или внедренной технологии. Такие корректировки представляют собой незначительные изменения и возникают вследствие того, что решить все вопросы сразу практически невозможно. Относительно закрепления, или "замораживания", модифицированного процесса уже говорилось выше.
Рассмотрев общие вопросы управления изменениями, настало время вернуться к области информационных технологий и рассмотреть организацию проектной работы, которая, как мы уже отмечали, является логичным продолжением проектов преобразований внутри организации и своей главной целью имеет практическую реализацию механизмов развития бизнеса.
Сразу стоит оговориться, что практику проектной работы мы будем рассматривать на основе проекта замены основной информационной системы банка, как и в первой части книги, где мы уже рассматривали работу по подбору решений на этом же примере. Это связано с тем, что это направление является одним из самых объемных и сложных в ИТ. Но все сказанное ниже будет актуально и для других ИТ-проектов, таких, как развитие интернет-услуг, замена компьютерного оборудования, автоматизация новых филиалов и т.п.
Иногда кажется, что не существует причины, по которой бы организация, имеющая уверенно работающие структуры, стабильную, удовлетворяющую текущим требованиям информационную систему, решилась бы на дорогостоящий проект замены своей информационной базы. Более того, основная часть сотрудников и руководства полагает, что, купив и успешно внедрив у себя однажды то или иное информационное решение, организация навсегда закрыла для себя эту проблему.
Но жизнь опровергает подобное заблуждение. Независимо от типа организации, программного и аппаратного обеспечения, квалификации сотрудников каждый раз повторяется один и тот же сценарий жизни программного приложения. Он длится в среднем 10-15 лет, а при стремительном изменении внешней среды, как это было в последние годы у нас, - 5-7 лет. В течение этого времени программное обеспечение многократно дорабатывается, адаптируясь к новым условиям. Появляется большое количество различных дополнительных решений, реализованных вне рамок системы. При этом решения разрабатываются различными людьми, при полном отсутствии каких-либо стандартов и документации. Потом возникает необходимость установления связей между этими доработками, и количество проблем, требующих решения, возрастает многократно, становясь нерешаемыми.
В результате возникает ситуация, когда небольшое ядро, некогда являвшееся современной и перспективной системой, обрастает неконтролируемым множеством утилит и заплаток. Простое увольнение одного из программистов (средний срок работы программиста в кредитной организации 3-5 лет) приводит к полной переработке целой области информационных задач. Надежность, защищенность подобной системы не удовлетворяет никаким требованиям. И отсутствие проблем со службой безопасности объясняется только тем, что в России службы безопасности очень редко занимаются анализом программного обеспечения в банке. Любое изменение в правилах учета и обработки информации все сложнее реализуется в установленные сроки. Даже если компания-разработчик своевременно предоставляет все доработки, служба автоматизации банка не успевает своевременно адаптировать свои решения к новым условиям.
Попытка решить данную задачу приводит к тому, что менеджеры организации начинают обращать внимание на новые разработки, появляющиеся на рынке, и после очередной проблемы с устаревшей информационной системой принимают решения о покупке новой, которая, по их мнению, снимет большую часть проблем.
Однако выделенные деньги и поддержка руководства не гарантируют того, что проект будет удачным. Он может быть вообще нереализован. По данным ряда зарубежных консалтинговых агентств, около 20% проектов не внедряются. Хотя, если проект будет реализован, скорее всего затраты на него будут существенно выше ожидаемых. По тем же данным, только 16% проектов реализуются в соответствии с первоначальными планами, а затраты на реализацию остальных в среднем в 1,8 раза выше утвержденных бюджетом.
Рассмотрим, какие шаги придется выполнить организации, чтобы минимизировать потери и увеличить шанс успешного завершения проекта. Мы уже останавливались на особенностях проектной работы в самой первой главе, где проектный подход рассматривался как один из ключевых подходов к организации ИТ-службы банка. Но настало время остановиться на этом и рассмотреть отличия проектной и традиционной форм организации работы. Прежде всего нам необходимо определиться с тем, что же такое проект. Мы будем опираться на широко распространенную за рубежом методику управления проектами РМВОК 2000.
Итак, как правило, проекты направлены на выполнение каких-либо вполне определенных задач, связанных с достижением стратегических целей организации. Это происходит потому, что стратегические цели не могут быть достигнуты посредством текущей деятельности, они требуют создания изменений, а средство создания изменений - это проект.
Проекты обычно связаны с новой, уникальной и не повторяющейся или редко повторяющейся работой в отличие от обычной деятельности, которая носит регулярный характер. Поэтому они всегда носят временный характер, ограничены четкими временными раками, операционная же работа является преимущественно постоянной.