Оптимизация процесса работы с требованиями на внесение изменений в информационные системы финансовой организации

Рябухин М.А.

Выпускник группы MBA CIO-54

Школа IT-менеджмента

РАНХиГС при Президенте РФ

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

Информационные технологии лежат в самой основе процессов функционирования любого, в том числе и коммерческого банка, так как если абстрагироваться от обычных, “физических” процессов, связанных с офисным взаимодействием и с обеспечением сохранности ценностей, то процессы движения денег в банке сводятся к манипуляциям с записями в базах данных, регистрах и производных от них информационных ресурсах, а также к приему, передаче и обработке такой информации от других контрагентов.

За последние 70 лет все новые возможности, появляющиеся ранее и продолжающиеся появляться в наши дни благодаря зародившихся еще в 19 веке методам обработки информации, а затем и благодаря стремительному прогрессу электроники с середины 20 века, - такие возможности, дающие выигрыш в эффективности, очень быстро берутся на вооружение прежде всего двумя отраслями - финансами и телекоммуникациями. Эти две отрасли являются лидерами и наиболее зрелыми участниками процессов проникновения информационных технологий в нашу жизнь.

Поэтому не будет преувеличением сказать, что информационные системы и вообще информационные технологии являются точно такими же производственными системами для банка, как например конвейер для автомобильного завода или мартеновские печи для металлургии.

Скорость появления новых возможностей и поэтому переходы, даже скачки на новые качественные уровни ведения бизнеса в банках неуклонно учащаются. Вот только несколько примеров.  Применение больших ЭВМ-мэйнфреймов в крупных банках в 70-е годы 20-го века. Появление персональных компьютеров в 80-е. Развертывание локальных сетей персональных компьютеров в 90-е. Проникновение Интернет и появление веб-сайтов в конце 90-х, пакетной коммуникации в сетях передачи данных на прикладном уровне в начале 2000-х. Массовое распространение мобильной связи в начале-середине 2000-х и дальнейшая трансформация мобильных телефонов в смартфоны с мобильными приложениями и постоянным доступом в Интернет в конце 2000-х и начале 2010-х. Наконец, появление в конце 2000-х технологии блокчейн и ее проникновение в  массовое сознание в 2017.

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

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

Всё это приводит банки к необходимости ускорения внедрения новых и изменению существующих информационных комплексов, а значит и к оптимизации процесса изменений.

Для оптимизации описанного выше процесса управления требованиями (неосознанного) мы рассмотрим методы анализа и решения сформулированной проблемы - это выбор процессного подхода к управлению изменениями (и вообще управлению) ИТ, а также выбор правильной методологии разработки или же синтез методологий  (в том числе и Agile).

Были рассмотрены современные работы, методологии и подходы в части управления информационными технологиями, работы по бизнес-анализу, возможные варианты подходов для работы с требованиями, материалы по подготовке технических заданий, отчечественные и зарубежные.

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

Рассмотрены в сравнении последовательные подходы к разработке программного обеспечения (водопадная модель) и гибкие подходы к разработке (agile software development).

Изложена информация о профиле и структуре рассматриваемого объекта ЮжноКредитПромСтройБанк. Департамент ИТ имеет подразделение разработки, которое занимается сопровождением и внесением постоянных изменений в разработанную собственными силами внутри банка автоматизированную банковскую систему. Парадоксально, но несмотря на это общую степень ИТ-зрелости банка нельзя оценить даже как среднюю. Она существенно ниже средней.

Проанализированы методы инициации требований на рассматриваемом объекте. Даны рекомендации по изменению методов коммуникаций. В частности, рекомендовано заменить применяемые принципы бумажного документооборота, механически перенесенные в документооборот с криптографической защитой информации.

В качестве замены предложено поэтапное внедрение процессного подхода (ITSM) в управлении согласно библиотеке ITIL. Первым этапом рекомендовано внедрение процесса Incident management для организации регистрации заявок и прочих обращений, причем не только внутренних сотрудников, но и для внешних клиентов банка. Далее на фундаменте внедренного Incident management рекомендовано внедрять процессы Problem Management, и затем Change Management и Release Management.

На основании приведенных рабочих документов произведено выделение заинтересованных сторон и оценен баланс между конфликтующими за ресурсы факторами – доступного времени, желаемого объема функциональности, имеющихся рабочих ресурсов. В качестве оптимального решения предложено стремиться уменьшать объемы изменений до минимально возможного объема функционала за одно изменение. Если весь объем изменений разбивать на достаточно небольшие кусочки, то даже при чисто математическом подходе к оптимальному покрытию площади фигуры (в пределах заданных графически линиями ограничений ресурсов) наиболее оптимально наполнять эту фигуру маленькими кусочками, большие не всегда могут в этой фигуре помещаться или оставят большее незаполненное пространство, то есть покроют фигуру не оптимально.

Рекомендованы к внедрению подходы к описанию требований по Карлу Вигерсу.

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

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

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

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

Подробно рассмотрены вопросы работы с документацией при примененеии методологии SCRUM.

Описано понятие резерва проекта и рассмотрены варианты расстановки приоритетов для его отдельных элементов.

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

Нужно быть готовым к неизбежным изменениям в ходе разработки. И потому критически важно поддерживать управление требованиями в проектах. Рекомендуется использовать средство для управления проектами Atlassian JIRA.

В завершении рассмотрены подходы к моделированию, классификации моделей, языки описания моделей. Рекомендуется к внедрению методология моделирования IDEF1X ERD (сущность-связь), а также инструмент Visual Paradigm.