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

- kbrbank

Внедрение проектной формы работ в кредитной организации связано с разными предпосылками, в каждом конкретном случае оно имеет собственные особенности, но имеется и неспециализированные черты. В статье, завершающей серию статей о проектной форме IT-работ 1, создатель останавливается на чек-страницах, модели внутренней нормативной базы банка, проектном офисе. //О.В. Полянский, свободный специалист. Методический издание операционная работа и Расчёты в коммерческом банке.№ 9/2005

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

Революционный подход разрешает относительно быстро перестроить работу работы автоматизации, но может сопровождаться происхождением напряжения в коллективе.

Вряд ли существует универсальный рецепт, какой из дорог выбрать банку. Отметим только, что наиболее значимым представляется некоторый синтетический критерий — с мельчайшими денежными, людскими и временными издержками выйти на новый, современный уровень автоматизации банка, тождественный его бизнес-стратегическим устремлениям и целям.

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.

Видеоурок по английскому языку: Значения глагола GET

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: