Проектная форма IT-работ: заключительные замечания

О.В. Полянский, независимый эксперт
Методический журнал"Расчеты и операционная работа в коммерческом банке", № 9/2005 

 Внедрение проектной формы работ в кредитной организации связано с различными предпосылками, в каждом конкретном случае оно имеет свои особенности, но есть и общие черты. В статье, завершающей серию публикаций о проектной форме IT-работ1, автор останавливается на чек-листах, модели внутренней нормативной базы банка, проектном офисе.
В предыдущих публикациях мы рассмотрели базовые (с точки зрения автора) вопросы, связанные с постановкой проектной формы IT-работ в банке:
— основные нормативные документы, которые могут определять принципы проектного подхода и организацию соответствующих работ;
— ключевой состав пакета проектной документации;
— основные этапы операционного контура жизненного цикла IT-проекта и их содержание.
 

Наше рассмотрение носило «панорамный» характер: была сделана попытка с практических позиций широко и в то же время лаконично представить предмет. Этот предмет — информационно-технологический проект — многогранен с точки зрения практических приемов реализации, но однообразен по своей сути: добиться, чтобы за счет автоматизации в банке возросла производительность труда его персонала.
Завершая рассмотрение проектной формы IT-работ, сделаем ряд важных замечаний, которые могут быть также приняты во внимание в ходе постановки проектной дисциплины в банке.

Замечание первое: о проектных документах
Представим ключевые проектные документы в виде сводной таблицы.
Упомянутые в таблице проектные документы рассматривались нами ранее, за исключением контрольных листов (чек-листов) проекта, поэтому остановимся на них подробнее.
Планирование IT-проекта означает, что все проектные работы должны быть максимально возможно предопределены заранее, а ресурсы, направляемые на эти работы, должны быть «забронированы» согласно срокам выполнения проектных работ. Один из практических способов — составление сплошного (возможно, иерархического) перечня работ, определяющего сроки, ресурсы и ответственных персон. Способ понятный, привычный и наглядный. Однако при этом календарный план IT-проекта (и его бюджет) может стать весьма объемным и соответственно «тяжелым» для контроля документом.
Альтернативный способ, который имеет право на существование, заключается в том, что для каждого типового этапа жизненного цикла разрабатывается свой типовой план работ. При этом бланк типового плана этапа может содержать отметки об успешном/безуспешном завершении тех или иных работ, о возникших в связи с этим проблемах и представлять собой по сути контрольный лист этапа жизненного цикла IT-проекта. В результате общий план IT-проекта оформляется как набор чек-листов, заполняемых участниками проектной группы, ответственными за тот или иной этап. Конкретная процедура применения чек-листов, включая правила их оформления и согласования, должна быть прописана в соответствующих нормативных документах об IT-проектах банка.
Идеальной при таком подходе представляется ситуация, когда в IT-службе банка организован проектный киоск: лица, ответственные за конкретные этапы проекта, оформляют «свои» чек-листы, бланки которых доступно размещены в бумажном или электронном виде в том самом киоске (набор ячеек для бумажных бланков или база данных/веб-ресурс для бланков в электронном виде), после чего формируется общий план IT-проекта как связанный набор чек-листов. При подготовке и проведении последующих производственных совещаний, связанных с выполнением какого-либо этапа проектных работ, в качестве основного документа используется не общий план проекта, а соответствующий чек-лист, отражающий состояние дел и текущие проблемы обсуждаемого этапа. Отчасти это способствует тому, что обсуждения не выходят за грань заявленной темы (и не перерастают в дебаты общего толка о необходимости автоматизации банковской деятельности как таковой или данного проекта в частности).

Замечание второе: о внутренней нормативной базе банка
Приведение внутренних нормативных документов, регулирующих банковские технологии (банковских инструкций, порядков, технологических регламентов и т.д.), в соответствие с особенностями внедряемой системы автоматизации — крайне важный и ответственный момент. Как мы уже рассмотрели ранее, актуализация нормативной базы возможна на этапе опытной эксплуатации системы. Однако в ряде случаев все работы, связанные с нормативными технологическими документами, целесообразно выделять в отдельный этап жизненного цикла конкретного проекта. Это тем более важно, если IT-проект нацелен на внедрение новых банковских продуктов, технологий обслуживания, ранее не использовавшихся в банке, а значит, не формализованных документально.
В этой связи остановимся на основных принципах, которые могут использоваться при разработке нормативной базы (или ее части) с нуля.
Основной целью создания внутренних нормативных документов является формализация процессов, происходящих (или планируемых) в банке. Для понимания взаимного отношения этих документов уместно применить модель «пирамиды качества», оговоренную семейством международных стандартов ISO 9000.
 «Пирамида качества» иллюстрирует такую структуру совокупности внутренних нормативных документов, которая обеспечивает возможно высокое качество выполнения работ, то есть степень соответствия их результатов требованиям потребителя. Качество выполнения достигается применением регламентированных процессов, предотвращающих (или минимизирующих) нештатные ситуации при допустимом расходовании ресурсов.
Применим эти соображения для схематичного изображения системы внутренней регламентации и рассмотрим модель, представленную на рисунке.
Верхний уровень включает единственный документ — «Политику качества». Как видно из названия, это политический, декларативный внутренний нормативный документ, определяющий «пирамиду качества», назначение и суть каждого из уровней, цели и результаты, которые достигаются посредством построения «пирамиды качества». На практике «Политика качества» может носить разные названия: например, «Положение о системе внутренней регламентации» или «Политика внутренней регламентации деятельности». Чтобы подчеркнуть значимость этого вопроса для кредитной организации, отдельные положения «Политики качества» могут включаться в документы, устанавливающие стратегические основы развития банка в различных сферах его деятельности.
Следующий уровень объединяет группу внутренних нормативных документов, которые позиционируют те или иные сущности. К таковым могут быть отнесены банковские продукты (например, «Положение о кредитовании клиентов — юридических лиц»), элементы технологий, в том числе автоматизированных (например, «Положение о криптографической защите информации»), элементы структуры управления (например, «Положение об информационно-технологических проектах»), иные элементы, являющиеся неотъемлемой частью банковской деятельности.
Третий уровень — «Процедуры деятельности». Это название является собирательным и отражает документы дисциплинарного содержания. К таковым могут быть отнесены всевозможные порядки, регламенты, инструкции, стандарты, методики и т.д. Основная особенность этой группы документов — их четкая направленность на дисциплину выполнения тех или иных действий. Различия же состоят в том, что каждый из упомянутых видов документов трактует эту дисциплину в разных аспектах:
— порядок устанавливает общие правила выполнения, основных участников и их ответственность;
— регламент детализирует процесс до уровня взаимодействия и временных норм исполнения;
— инструкция ориентирована на конкретных персон и их элементарные действия;
— стандарт определяет обязательные требования к конкретным объектам — документам, оборудованию;
— методика, как правило, носит рекомендательный характер и т.д. Чтобы нивелировать эти различия, мы и применяем собирательный термин «процедура деятельности».

Последний, четвертый уровень «пирамиды качества» объединяет документы, инициирующие выполнение работ или фиксирующие (подтверждающие) их результат («Рапорты»). К таким документам могут быть отнесены различные заявки на выполнение работ, отчеты, акты, справки, контрольные листы и т.д.
Представление нашей модели в виде пирамиды позволяет проиллюстрировать следующие важные выводы:
• внутренние нормативные документы иерархичны по степени своей абстракции: от достаточно общей по содержанию «Политики качества» до абсолютно конкретных заявок и актов;
• модель является логически завершенной: идеи и принципы, заложенные в «Политике качества», реализуются через сущности и механизмы, закрепленные положениями и процедурами деятельности, что документально подтверждают «Рапорты»;
• количество документов на разных уровнях различно, что подтверждается здравым смыслом:
— не может быть нескольких «Политик качества»;
— количество сущностей, отражаемых в положениях, не больше, чем регламентированных процессов с участием этих сущностей;
— количество «Рапортов» наиболее велико, поскольку каждый из них может порождаться неоднократно в ходе выполнения того или иного процесса.

Несколько слов о разработчиках внутренних нормативных документов. В большинстве случаев основным участником является технолог — подразумевается роль, а не должность конкретного сотрудника (хотя не исключено, что так может называться и должность). Следует отметить, что выделение отдельной технологической роли в банке для разработки нормативных документов имеет свои преимущества: технолог не ангажирован каким-либо внешним по отношению к нему подразделением, а значит, разработка нормативного документа может быть выполнена наиболее объективно и непредвзято. При этом немаловажной является способность «сглаживать острые углы» и находить компромиссы без ущерба для результата при сложных, многозвенных согласованиях с различными подразделениями.
Процедуры разработки внутренних нормативных документов, как и любые иные регулярные процедуры, должны быть регламентированы.
В зависимости от специфики каждого конкретного IT-проекта актуализация внутренней нормативной базы наиболее вероятна на уровнях 2–4 «пирамиды качества». Обратим, кстати, внимание на то, что рассмотренные нами в самом начале обсуждения проектной формы IT-работ «Положение об информационно-технологических проектах», «Положение о проектной группе» и «Положение о руководителе проекта автоматизации» — типичные примеры нормативных документов, относящихся ко второму уровню этой пирамиды, планы, стандарты и методики, требования и спецификации, упоминавшиеся среди ключевых проектных документов, могут быть отнесены к третьему уровню, а проектная заявка, экспертное заключение, протоколы и акты — к четвертому.

Замечание третье: о проектном офисе
В ходе рассмотрения жизненного цикла IT-проекта мы неоднократно упоминали о проектном офисе. Для четкого понимания, что же это такое, обсудим проектный офис несколько подробнее.
В ходе постановки проектной дисциплины в банке порождаются упомянутые нами соответствующие управленческие документы (положения об IT-проектах, проектной группе и руководителе проекта автоматизации), а также некоторое количество ключевых проектных документов, отражающих выполнение первого и нескольких последующих IT-проектов. Все эти документы подлежат регистрации и ответственному хранению. На первых порах для этого может использоваться некий информационный ресурс — проектный офис, поддерживаемый одним из сотрудников банка, имеющим соответствующую квалификацию. Пока документов немного, сотрудник может совмещать ведение проектного офиса со своей основной деятельностью.
По мере формирования проектной истории, становления и закрепления на практике соответствующих управленческих и организационных правил, накопления опыта работы число документов растет. Вместе с ним растет и число функций, которые связаны с обеспечением проектной деятельности. Возникает необходимость и появляется возможность структурирования проектных портфелей, анализа допущенных операционных ошибок, синхронизации связанных работ во времени, мониторинга проектных работ по срокам (возможно, бюджетам), совершенствования управленческих проектных документов, предоставления участникам работ соответствующих стандартов, бланков, иных методических материалов, оказания консультаций и т.д. Очевидно, что все эти функции нецелесообразно возлагать на того же специалиста, который ведет базу проектных документов, хотя бы потому, что необходима более высокая квалификация. И вот тут проектный офис из категории информационного ресурса естественным образом переходит в категорию организационной единицы — отдела, сектора, иного подразделения. Возникший фронт работ требует единого управления со стороны руководителя проектного офиса, а появившиеся функции — четкого распределения между его сотрудниками. Численность проектного офиса определяется потенциальным числом IT-проектов, их масштабностью, иными факторами, учитываемыми при изменении организационной структуры банка.
Таким образом, по мере развития проектной дисциплины и проектной истории налицо развитие проектного офиса от элементарной базы данных до организационной единицы.
Если проектный потенциал банка велик, создание полноценного проектного офиса себя полностью оправдает, поскольку позволит сосредоточить в одних руках функции, общие для всех проектов, и создать своего рода методический центр поддержки и развития проектных работ в банке.

Замечание четвертое: о становлении проектной формы IT-работ
Необходимость внедрения проектной формы IT-работ не возникает ниоткуда. Всегда есть побудительные мотивы — неудовлетворенность действующими в банке технологиями управления IT-работами со стороны руководства, масштабные перестройки бизнеса и соответственно инфраструктуры его автоматизации, известный положительный опыт конкурентов, появление на рынке банковской автоматизации новых игроков с прогрессивными проектными технологиями ведения работ и т.д.
В каждом из перечисленных случаев путь становления проектной формы IT-работ в банке может иметь свои особенности. Однако все возможные пути с организационной точки зрения сводятся, по существу, к двум: эволюционному и революционному.
Эволюционный путь предполагает максимальное использование собственных сил банка для внедрения новых управленческих технологий: организацию соответствующих обучающих мероприятий для персонала банка, разработку необходимых управленческих и иных документов самостоятельно или с контрактным привлечением сторонних консультантов, бережное отношение к собственным кадрам IT-службы — их перепрофилирование, а не замену. Эволюционный путь медленен, но комфортен с точки зрения внутрибанковской трудовой и человеческой атмосферы.
Путь революционный характеризуется заменой части персонала или его пополнением высококвалифицированными специалистами в области управления IT-проектами. Новые люди (как правило, команда единомышленников) приносят с собой отработанные ранее методики и становятся основными проводниками проектных идей в банке. Зачастую реформа сопровождается значимыми организационно-структурными переменами в банке. Революционный подход позволяет сравнительно быстро перестроить работу службы автоматизации, однако может сопровождаться возникновением напряжения в коллективе.
Вряд ли существует универсальный рецепт, какой из путей выбрать банку. Отметим лишь, что важнейшим представляется некий синтетический критерий — с наименьшими финансовыми, человеческими и временными издержками выйти на новый, современный уровень автоматизации банка, адекватный его бизнес-целям и стратегическим устремлениям.
 
1 См.: 1/2005, с. 86–92; 3/2005, 87–94; 4/2005, с. 85–90; 5/2005, с. 72–79; 6 /2005, с. 67–74; 7–8/2005, с. 61–67.