МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

ДЛЯ УПРАВЛЕНИЯ ФИНАНСОВЫМИ РИСКАМИ

С.М. Авдошин,

профессор, руководитель отделения программной инженерии факультета бизнес-информатики Национального исследовательского университета «Высшая школа экономики», e-mail: savdoshin@hse.ru.

Е.Ю. Песоцкая,

кандидат экономических наук, доцент кафедры Управления разработкой программного обеспечения Национального исследовательского университета «Высшая школа экономики», e-mail: epesotskaya@hse.ru.

Адрес: г. Москва, ул. Кирпичная, д. 33/5.

Г

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

К

профессионалов.

Ключевые слова: информационные технологии, финансовые риски, риск-менеджмент, программное обеспечение.

Введение

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

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

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

=БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г.

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

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

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

Управление рисками как часть банковских процессов

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

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

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

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

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

Этапы управления риском

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

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

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

3. Количественный анализ риска предполагает численное определение величин отдельных рисков и заключается в сборе и обработке статистических данных. При этом может выполняться классификация потерь с описанием их причин. Расчет всех значений рисков основывается на первичных данных (данных о сделках и остатках по счетам за выбранный статистический горизонт). Таким образом, получаемые значения риска не зависят от принятой в банке формы стандартов бухгалтерского учета и позволяют сохранить сопоставимость результатов при переходе от РСБУ к МСФО. Такой расчет особенно эффективен при наличии статистики, организованной отчетности, возможности оперативно получать данные об операциях банка и быстрой их обработки.

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

Как правило, для каждого вида риска существует несколько основных способов воздействия.

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

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

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

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

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

Классификация рисков

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

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

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

могут подразделяться на финансовые, функциональные и внешние.

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

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

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

Кредитный риск — риск уменьшения стоимости активов Банка, в особенности кредитов в результате невыполнения обязательств заемщиками. Для анализа кредитного риска проводится анализ финансового состояния эмитентов и контрагентов, обеспечение кредита, установка лимитов на операции, резервирование.

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

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

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

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

Ценовой риск — риск потерь вследствие изменения котировок по инструментам портфеля. Для анализа ценового риска банка включаются все ценные бумаги, по которым банк ведет операции (еврооблигации, акции, векселя и пр). Для расчета ценового риска необходимы данные по сделкам и остаткам по счетам, текущим рыночным курсам, рыночным индексам. Количественной оценкой ценового риска является максимальный размер потерь в стоимости портфеля, с принятым банком доверительном уровнем, в результате изменения рыночных цен за период прогнозирования.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

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

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

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

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

В качестве основного инструмента анализа рыночного риска используются два наиболее распространенных метода: метод расчета величины риска Value-at-Risk (VaR) методом Монте-Карло и метод анализа чувствительности портфеля к изменениям параметров рынка (Stress or Sensitivity Testing).

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

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

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

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

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

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

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

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

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

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

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

Программные решения для управления финансовыми и банковскими рисками на российском рынке

Функции управления рисками используются многими российскими банками и входят в состав практически всех современных российских банковских систем (RSBank 5, Diasoft 5NT и т.п.). В основном эти функции касаются контроля позиций по валюте (риски ликвидности) и используются в казначействе.

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

SAS Risk Management (SAS) является широко признанным в мире решением в области управления рисками на уровне всего банка. SAS Risk Management имеет гибкую, открытую и расши-

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

EGAR Focus (EGAR Technology) — комплексное решение для банков и инвестиционных компаний, позволяющее осуществлять мониторинг позиций, управление рисками, оценку стоимости производных финансовых инструментов, проводить расчет прибыли и убытков в режиме реального времени .

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

Kondor+ (Reuters) наиболее полно охватывает функциональную область дилинговых управлений инвестиционных банков, кроме того используется для оценки и контроля риска ликвидности и процентного риска . Kondor+ представляет собой систему ведения позиций в режиме реального времени, с большим набором интеллектуальных и гибких средств управления сделками и широким спектром финансовых инструментов. Система позволяет анализировать прибыли и убытки, а также рассчитывать уровень риска по любому срезу торговой структуры банка и любой комбинации финансовых инструментов в режиме онлайн. На основании получаемых данных и отчетов принимаются оперативные и стратеги -ческие решения в области управления активами и пассивами банка. Дополнительный модуль KVaR+ может быть полезен для расчета и контро-

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

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

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

Методика управления финансовыми рисками, разработанная сотрудниками подразделений банка, как правило, представляет инструмент математического расчета стандартной методики (Value-at-Risk, стрессовый анализ, моделирование, анализ сценариев и пр.) объединенный с системой изменения внешних и внутренних факторов, оценки эффективности инвестиций, передачи и возврата денежных средств и пр. Качество системы управления финансовыми рисками будет зависеть от полноты и актуальности информации, которая в нее поступает.

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

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

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

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

Так, например, компания Accenture совместно с Risk Management Concepts Systems предлагает продукт, который позволяет рассматривать риски на различных уровнях детальности — от процедур и подразделений к оценке рисков предприятия в целом. Система TSA (Time Series Aggregation) позволяет агрегировать факторы риска и собирать информацию о фактических или прогнозируемых потерях. Используя «аналитический» подход система предоставляет среду для детализации факторов риска и учитывает уровень потерь по каждому подразделению и/или процессу, что делает возможным проведение анализа распределения уровня риска. Распределение рисков производится путем составления матрицы «размер ущерба/частоты возникновения» наступления рисковых событий.

Система OpVar компании PriceWaterhouseCoopers направлена на сбор и консолидацию данных по операционным потерям за предыдущие периоды, позволяет осуществлять моделирование на основе исторических данных.

Среди решений, построенных на основе интернет-технологий, стоит отметить созданную в компании Ernst & Young систему Horizon. Интернет-дизайн в соединении с функциональными возможностями обеспечивает удобство в использовании и поддерживает возможность быстрого запуска в банковских офисах по всему миру. Система позволяет идентифицировать и документировать широкий спектр рисков, принятых банковскими подразделениями, и требующих более пристального внимания. Анализ возможности уменьшения рисков и дальнейшее прогнозирование тенденций возникновения неблагоприятных событий проводится в зависимости от качественной экспертной оценки, при которой риски ранжируются и помечаются красным, желтым и зеленым цветом в зависимости от критичности.

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ

Выводы

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

что лучше, продолжать инвестировать в существующую систему и дорабатывать существующий продукт, или приобрести новый?

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

Литература

1. Литовских А.М. Финансовый менеджмент: Конспект лекций. Таганрог: Изд-во ТРТУ, 1999. 76 с.

2. Лобанов А., Чугунова А. Энциклопедия финансового риск-менеджмента. M.: «Альпина Бизнес Букс», 2009, 932 с.

3. Риск менеджмент, оценка рисков. — http://md-hr.ru/articles/html/article32645.html

4. Basel II: Revised international capital framework. — http://www.bis.org/publ/bcbsca.htm

5. Duncan. B. A Guide to the Project Management Body of Knowledge // PMBOK GUIDE.— PMI, 2004.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

7. Решения EGAR. — http://egartech.ru/

БИЗНЕС-ИНФОРМАТИКА №1(15)-2011 г

Повышенные требования к системе

Разрабатывать систему, функциональность которой определяется законодательством, не то же самое, что разрабатывать обычный софт, который должен просто автоматизировать какие-то процессы и нравиться пользователям. Например, функциональность Единой информационной системы в сфере закупок (ЕИС), которую многие эксперты признают одной из самых крупных государственных систем, определяют свыше 300 нормативно-правовых актов. Пользователям, конечно, нужны современные сервисы, помощники, гибкость системы, ее удобный интерфейс. Поэтому даже микрозадачи ЕИС необходимо проектировать с учетом всей имеющейся нормативно-правовой базы, делать предметом не просто ручного ввода, а сопоставления со всеми ранее запущенными функциями (а это, к слову, больше 20 млн строк кода).
Я уже не говорю о тех случаях, когда нормативный акт выходит сегодня, а работать должен уже завтра. Все это многократно усложняет доработку системы и предъявляет повышенные требования ко всей проектной команде: обязательна серьезная юридическая квалификация у каждого аналитика, нужны особые подходы к отслеживанию требований, необходимы гибкие методологии и автоматизированные проверки всей функциональности перед ее выпуском.
У проектов, связанных с госзаказом, есть еще ряд особенностей.
Цикличность проектов
ИТ-проекты для государства регулируются законодательством по госзакупкам. Длительных контрактов мало, и разработчики каждый год участвуют в конкурсах на одну и ту же систему, которую создали. Это приводит к тому, что итоговая стоимость проекта увеличивается, так как у исполнителя нет мотивации вкладываться в тему, которую на следующий год он может не выиграть.
На мой взгляд, более эффективная схема — это когда создание системы от самого начала (разработки концепции и архитектуры) и до ее ввода в эксплуатацию осуществляет один исполнитель. Уйти от классического «водопада» к гибким практикам реализации проектов можно — для этого я бы предусмотрел, чтобы в техническом задании на систему была определена ее основная часть (ядро) и плюс что-то вроде калькулятора. С его помощью можно было бы рассчитывать бюджеты на изменения системы. В этом случае заказчику не нужно было бы «переигрывать» конкурсы.
Практическая невозможность использования готовых коробочных решений
В мировой практике процессы подстраивают под правильно созданный софт, под то, что умеет система. В России же для крупных государственных заказчиков софт всегда подстраивается под существующие процессы или требования законодательства. Поэтому готовое решение приходится сильно переписывать, и все его преимущества теряются.
Требования по импортозамещению
Активное импортозамещение в сфере ИТ в России началось около пяти лет назад. Все новые системы для госсектора разрабатываются исключительно с таким подходом — чтобы в базовом программном обеспечении отсутствовали продукты иностранного производства.
Большой разрыв между лидерами и отстающими
Разрыв наблюдается между крупными федеральными органами исполнительной власти, столичными центрами и небольшими госпредприятиями, удаленными муниципалитетами. Инноваторы говорят о внедрении искусственного интеллекта в госсекторе, а кто-то только перешел к учету в Excel.
Существенные проблемы в базовых информационных ресурсах
Без базовых информационных ресурсов невозможно сделать крупный проект для государства. Зачастую, чтобы получить данные от органов власти, можно потратить полтора года на согласования. Сами данные между собой не синхронизированы.

На что нужно делать упор при реализации проектов в государственном секторе

• В больших и сложных проектах по созданию государственных информационных систем должна быть единая команда исполнителя (разработчика), функционального заказчика и тех, кто готовит нормативно-правовой акт. Принцип «тебе сказали — ты сделал» здесь приводит к плохим последствиям. Должен быть диалог, чтобы вместе формулировать и искать пути, как можно реализовать задачу. В процессе создания информационной системы разработчику нужно быть как можно ближе к тому, кто выпускает подзаконную нормативно-правовую базу. Все хотят гибкости, а требования на бумаге меняются достаточно часто. Разработчик должен как можно быстрее узнавать об изменениях, чтобы адаптировать под них систему.
• По государственным контрактам гибкий подход в госпроектах у нас практически невозможен (применяется только схема «водопада», этапность), но жизнь настоятельно диктует необходимость применения гибких методологий. Поэтому по договору проект выполняется по принципу «водопада», а по жизни — по Agile. Появилась в системе функция регистрации пользователей, нужно ее выдавать, чтобы пользователи начали регистрироваться, даже если, кроме этого, им в системе больше делать нечего. Появился другой сервис, пусть даже незаконченный, нужно его выдавать, чтобы его начинали тестировать, подключаться к нему. «Маленькими шажками» проекты всегда случаются.
• Нужно уделять внимание PR. В крупном государственном проекте обязательно должен быть человек, который занимается коммуникациями со всеми заинтересованными сторонами, отслеживает новости, готовит пресс-релизы, проводит мероприятия для целевых аудиторий.
• Важнейшая тема — безопасность. Если брать интернет-системы, то мы выделяем три момента, которые нас больше всего волнуют. Во-первых, дефейс: на внешней странице не должно случайно оказаться того, чего там быть не должно. Во-вторых, вопросы, связанные с DDoS-атакой. Поскольку речь идет о государственной системе, важно, чтобы она работала на территории Российской Федерации. В-третьих, утечка данных. В государственных системах могут храниться сотни миллионов персональных данных, поэтому необходимо принимать меры предосторожности против утечек.

С ростом зависимости от внедренных ИТ решений, увеличивается зависимость компании от рисков связанных с использованием ИТ. Управление ИТ-рисками становится неотъемлемой частью процессов глобального управления рисками бизнеса, а оценка и управление ИТ-рисками требуют анализа специфичных для области ИТ факторов, в том числе связанных с информационной безопасностью ( ИБ) внедренных решений.

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

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

В состав услуги построения системы Управления ИТ-рисками входит:

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

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

• Авторы
• Резюме
• Файлы
• Ключевые слова
• Литература

Усова Ю.П. 1 Чинарева О.И. 1 1 ФГБОУ ВПО «Воронежская государственная лесотехническая академия» Как показывает практика, определенные проблемы возникают в ходе реализации любого проекта. Некоторые из них имеют четкую структуру, выраженный характер и различные возможности их решения; другие, напротив, не имеют структуры, их характер определить невозможно, и, соответственно, у них нет решений. В действительности, в ходе управления проектом редко бывает достаточно информации или времени для того, чтобы объективно, с полной уверенностью выявить сущность возникающих проблем, а, следовательно, выбранный метод их решения может оказаться малоэффективным. В связи с этим первым этапом решения проблем, возникающих в ходе управления проектом, является их определение. В статье предлагается решение некоторых, наиболее острых проблем. В зависимости от своей сущности эти проблемы могут приводить к срыву проекта посредством перерасхода средств, задержек в выполнении, а также получению иного результата и полного краха проекта. 113 KB квалификация управленческого персонала. система вознаграждения программное обеспечение проблемы управление проектами 1. Ветлужских Е. Система вознаграждения: Как разработать цели и KPI. – М. : Альпина Паблишер, 2013. — 217 с 2. Гаврилов Н.Н., Козлов А.С., Матвеев А.А., Богатов А.А. «Естественный отбор» руководителя проектом. — URL: http://www.pmsoft.ru/knowledgebase/articles/detail.php?ID=1500 3. Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М. : Альпина Бизнес Букс, 2007. – 418 с. 4. Пятенко С.В. Методы анализа наиболее типичных проблем управления проектом / Элитариум: Центр дистанционного образования. — URL: www.elitarium.ru 5. A guide to the project management body of knowledge. PMBOK guide. 5th edition. – Project Management Institute, 2013. – 616 с.

Введение

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

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

Рис. 1. Проблемы и их решения в управлении проектами.

Разрешением таких проблем является внедрение программного обеспечения и повышение квалификации управленческого аппарата.

Программное обеспечение (ПО) управления проектами позволяет снизить рутинность работы и максимально облегчить и ускорить обработку данных и отчетов в ходе работы над проектом. Компьютер поможет в составлении планов, сетевых диаграмм, подготовке отчетов и во многом другом. Но, несмотря на много положительных моментов, следует отметить главный недостаток — ПО не сможет за вас управлять проектом.

Профессиональный руководитель проекта не должен следовать за ПО, «идти у него на поводу», его задача — заставить ПО работать в соответствии с его потребностями.

Большинство существующих программных средств предлагают планирование проектов по собственным методикам, зачастую не соответствующим общепринятым (стандартным) для проектного менеджмента — это и порождает множество серьезных проблем, таких как срыв сроков, перерасход бюджета и т.д.

Даже применение ПО от лидеров сегмента — MS Project, Primavera, не страхует от возможных проблем, ведь это всего лишь инструменты, эффективно работающие в руках профессионала, а не искусственный интеллект, решающий все ваши проблемы .

Понимание алгоритмов, лежащих в основе ПО, или хотя бы поверхностное знание методик, применяемых в управлении проектами, поможет вам избежать множества проблем.

Следующим способом решения выше обозначенных проблем является активное использование системы вознаграждения. Чаще всего в российских компаниях используется стандартная система вознаграждения: в небольших по длительности проектах (например, до шести месяцев) сотрудники поощряются за выполнение проекта в срок, а при более долгосрочных проектах – за завершение каждого этапа и всего проекта в срок. Причем за выполнение первого этапа проекта размер вознаграждения обычно меньше, чем за завершение всего проекта. Например, если проект состоит из трех этапов, а общее вознаграждение составляет 100%, то за завершение первого этапа выплачивается 20% от общей суммы вознаграждения, 30% – за второй и этап и за завершение всего проекта – остальные 50%.

При этом используются два варианта взаимосвязи с вознаграждением:

• вариант жесткий (одноуровневый): если этап (проект) выполнен в срок, менеджер получает вознаграждение, если нет – наказывается и остается без премии. Такой вариант используется в проектах, имеющих жесткие сроки выполнения (например: Олимпиаду нельзя перенести, все строительные объекты должны быть сданы вовремя).
• вариант более мягкий: разрабатывается таблица с пороговым значением, при котором уже возможна выплата вознаграждения.

Участники проектов вознаграждаются при достижении поставленных целей всей командой проекта, а также за выполнение в срок своих операций.

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

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

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

Свое негативное влияние оказывает и так называемый студенческий синдром: большинство людей склонны откладывать выполнение задания до последнего. Исследования показали, что менее трети задания обычно выполняется в первые две трети срока, отведенного на него, и две трети – за последнюю треть срока. Кроме того, сотрудников постоянно отвлекают на выполнение новых заданий, а многозадачность, как известно, ведет к увеличению длительности выполнения проекта. Чтобы быть хорошим в глазах руководителя, сотрудник просто обязан брать и выполнять новые задания, в результате – он перегружен, что часто приводит к стрессу и в конечном итоге еще к большему увеличению длительности проекта. Поэтому проекты редко выполняются досрочно. Если бы некоторые этапы проекта завершались сотрудниками досрочно, то возникающий запас времени мог бы использоваться на непредвиденные обстоятельства, которые всегда могут возникнуть на завершающих этапах проекта .

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

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

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

Для иллюстрации такой ситуации введем качественные показатели «требования проекта» и «квалификация руководителя проекта». Под понятием «требования проекта» будем понимать совокупный уровень знаний и навыков, необходимых для успешной реализации проекта. Под понятием «квалификация руководителя проекта» будем понимать совокупный уровень знаний и навыков, которыми обладает руководитель проекта на определенный момент времени. Требования проекта и квалификация руководителя проекта – это динамичные характеристики .

Графическая иллюстрация понятий «требования проекта» и «квалификация руководителя проекта» приведена на рисунке 2.

Рис. 2. Качественные соотношения динамики требований проекта и квалификации руководителя проекта.

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

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

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

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

Возникновение тех или иных проблем в процессе выполнения проекта — нормальное явление. Существует немало разнообразных методов их структуризации и разрешения. Выбор наиболее эффективного метода зависит от множества разных обстоятельств. Главное — работать над разрешением проблем систематически и организованно. Накопленный опыт позволяет выявить обычные ошибки при решении проблем:

• неосведомленность о проблеме;
• неверный «диагноз»;
• решение не «продано» топ-менеджменту;
• принятие решений без запланированных действий;
• действия при отсутствии рамок решения;
• неспособность действовать тогда, когда нужно;
• действия, не соответствующие принятым решениям .

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

Рецензенты:

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

Трещевский Ю.И., д.э.н., профессор, заведующий кафедрой экономики и управления организациями Воронежского государственного университета, г. Воронеж.

Усова Ю.П., Чинарева О.И. ПРОБЛЕМЫ В УПРАВЛЕНИИ ПРОЕКТАМИ И СПОСОБЫ ИХ РЕШЕНИЯ // Современные проблемы науки и образования. – 2013. – № 6.;
URL: http://www.science-education.ru/ru/article/view?id=11844 (дата обращения: 29.09.2020). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания» (Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления) «Современные проблемы науки и образования» список ВАК ИФ РИНЦ = 0.791 «Фундаментальные исследования» список ВАК ИФ РИНЦ = 1.074 «Современные наукоемкие технологии» список ВАК ИФ РИНЦ = 0.909 «Успехи современного естествознания» список ВАК ИФ РИНЦ = 0.736 «Международный журнал прикладных и фундаментальных исследований» ИФ РИНЦ = 0.570 «Международный журнал экспериментального образования» ИФ РИНЦ = 0.431 «Научное Обозрение. Биологические Науки» ИФ РИНЦ = 0.303 «Научное Обозрение. Медицинские Науки» ИФ РИНЦ = 0.380 «Научное Обозрение. Экономические Науки» ИФ РИНЦ = 0.600 «Научное Обозрение. Педагогические Науки» ИФ РИНЦ = 0.308 «European journal of natural history» ИФ РИНЦ = 1.369 Издание научной и учебно-методической литературы ISBN РИНЦ DOI

Что не так с методологией Waterfall (особенности и недостатки каскадной модели)

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

1. От начала и до конца спроектированный конечный результат.
   (Архитектурный Проект Результата)
2. Инструкция по сборке конечного результата.
   (План реализации проекта)
3. Последовательная реализация проекта.
   Анализ, проектирование, сборка, тестирование и передача в эксплуатацию
4. Сопротивление изменениям в Проекте Результата и Инструкции по сборке в процессе реализации проекта.
   Изменения в проекте
5. Результат проекта доставляется единой поставкой в конце проекта.
   Динамика сборки результата проекта

Для того, чтобы реализовать длительный проект по Waterfall со сроками более 1-2 лет нужно сделать предположения о той бизнес-среде, потребностях клиентов и компании, которые будут на момент завершения проекта (допущения связанные с бизнес-целями Проекта). Также нужно предположить и заложить ориентировочную стоимость ресурсов на каждый год жизни проекта (допущения связанные с планом реализации Проекта).
Чем больше содержание проекта, трудоемкость и сроки реализации, тем больше допущений закладывается в проект, которые могут оказаться как верными так и не верными. Самые критичные — это допущения связанные с бизнес-целями Проекта, если они оказываются не верными то все вложенные в проект ресурсы, деньги и время обесцениваются.
Попытки внести существенные изменения в Проект Конечного Результата по ходу реализации требуют цикла перепроектирования Конечного Результата и Инструкции по сборке. Существенные изменения часто не позволяют продолжать уже начатые по первоначальному плану работы и приводят к переделке того, что уже было сделано.
По этой причине команда проекта и стейкхолдеры сопротивляются существенным изменениям в проекте, только если обстоятельства и сыгравшие/обнаружившиеся риски не ставят весь проект под сомнение в необходимости его продолжать. Когда изменения всё-таки вносятся они чаще всего приводят к дополнительным затратам и удлинению сроков. Возросшая длительность опять порождает новые требования и новые изменения. Это словно замкнутый круг из которого невозможно выйти победителем. Отсюда происходит постоянное вылетание из первоначальных сроков и бюджета.
Поэтому эта Методология подходит проектам строительства зданий и сооружений, типа атомной электростанции, но не годится для разработки Продуктов под быстро меняющиеся среды, в которых они будут применяться. У которых срок жизни Продукта в изначальном виде без внесения изменений меньше 5 лет.
Идея итеративной разработки призвана устранить связанные с допущениями риски, дать возможность быстро получить обратную связь, сократить масштаб потерь от неверных бизнес допущений и внести изменения в Проект Конечного Результата на основе обратной связи полученной по окончанию очередной итерации.

Преимущества Rational Unified Process

Методология RUP была целенаправленно разработана для разработки больших программных систем.
Новация №1, заложенная в её основу, это «Бизнес-моделирование» и связанные с ним Сценарии Использования (Use Case).
Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
Главная задача при разработке корпоративной ИС обеспечить непрерывность поддерживаемого бизнес-процесса. Когда ткань бизнес-процесса рвется, то встают все следующие за ним этапы в производственной цепочке, а порой и весь бизнес объемом в десятки миллиардов рублей.

Пример остановки торгов Московской биржейНа фондовом, валютном и срочном рынках Московской биржи нештатная ситуация … Последний раз биржа приостанавливала торги 1 сентября, но это коснулось только секции «Основной рынок». Этот сбой стал четвертым за последние четыре месяца. — Lenta.ru
Поэтому в основе разработки корпоративной ИС лежит проектирование нового бизнес-процесса на основе её использования, чтобы заменить один процесс на другой и сотни людей с определенного дня начали работать по другому чем привыкли до этого. В этом главное и основное отличие разработки корпоративной ИС от других видов программного обеспечения.
Новация №2: На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
Наличие отдельных компонент позволяет их переиспользовать и заменять одни на другие. Чем больше компоненты используются совместно тем выше вероятность сломать соседний бизнес-сценарий при внесении изменений в компоненту. Также наличие общих компонент ограничивает скорость и масштаб последующих работ по развитию системы. Если одна команда занимается тем, что меняет какую-то общую компоненту, то другая не может начать работы по её изменению до тех пор пока первая не закончит работы и не отладит свой бизнес-сценарий использования.
Новация №3: Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.
В Waterfall от того нет итераций, так как порой невероятно сложно разделить функциональные требования на самодостаточные блоки и реализовывать их итерациями. Я не говорю, что этого нельзя сделать, можно, но чаще всего результатом этого будет не работающий прототип ИТ-решения, а какая-то часть будущей программы. От этого бизнесу не становится легче, работающий прототип он так и получит через год, наличие итераций здесь помогает, но не сильно.
Вот так выглядит концепт RUP в упрощенном виде:
Каждый бизнес-сценарий разворачивается в системные сценарии использования. Каждый системный сценарий — в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа…). На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы). Подсистемы разбиваются на компоненты. Компоненты содержат исполняемый код.
Основная идея RUP выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев. Так как доставка части Результата проекта (инкремента) осуществляется в конце каждой итерации, это позволяет начать получать выгоду от использования промежуточных версий Результата и возвращать вложения в проект ещё в ходе его реализации.

Как мы применили RUP

Шаг №1 — Я договорился с руководителем об использовании отличного от принятого в компании шаблона технического задания. В основу нового ТЗ легли бизнес и системные сценарии использования.
Шаг №2 — Спроектировали целевой бизнес-процесс и подготовили первую версию ТЗ. После того как получили оценки трудоемкости и длительности реализации приняли решение, что попробуем использовать RUP для этого проекта. Разбили целевой бизнес-процесс на 5 бизнес-процедур / 5 этапов реализации проекта. Первая версия ТЗ стала концепцией / дорожной картой по продвижению к целевому процессу.
Шаг №3 — Определились со стратегий автоматизации: двигаться от входной или выходной точки всего бизнес-процесса.
Первая стратегия «от входной точки» создаёт напряжение и заставляет автоматизировать все остальные этапы в цепочке. В последующие этапы бизнес-процесса перестают поступать первичные данные, которые необходимы им для работы.
Вторая стратегия «от выходной точки» не имеет этого напряжения, но и не имеет тех данных и истории, которые создаются и накапливаются на предыдущих этапах. Нужен регулярный перенос необходимой информации в КИС.
Пошли по первой стратегии. Проблему обеспечения последующих этапов необходимой информацией решили выгрузкой данных в Excel. Получили неожиданный эффект в виде растущей мотивации бизнес-пользователей полностью перейти из Excel в КИС вместе с соответствующей поддержкой и готовностью выделять время на работу с бизнес-аналитиком по проработке требований.
Шаг №4 — Подготовили ТЗ на первую часть модуля системы (вторую итерацию). Пока велась разработка первой части, готовили ТЗ на вторую часть (третью итерацию).
Первой итерацией была подготовка Концептуального Технического Задания где прописали полностью бизнес-процесс с использованием КИС, а также разработали первую версию архитектуры будущего модуля.
Шаг №5 — После выхода первой части модуля и старта его опытной эксплуатации, начали готовить дополнение к ТЗ на первую часть и ТЗ на третью часть (четвертую итерацию). В дополнение вошли те требования, что были упущены в начале и те что оказались неудачными в плане использования.
Результат — На всё про всё у нас действительно ушло 1,5 года. Работающий прототип (первая часть модуля системы) был получен спустя 6 месяцев с даты старта проекта. Остальные приходили уже через каждые 2 месяца.
С точки зрения архитектуры компоненты нового функционального модуля были заточены исключительно под него и не использовали компоненты основной ИС. Это позволило:

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

Хоть RUP напрямую ассоциируется и связан с нотациями UML, для описания бизнес и системных сценариев использования не обязательно использовать именно их, подойдут и другие нотации. Главное, чтобы используемые нотации были понятны и Бизнес-Пользователям, которые будут согласовывать-утверждать постановку, и Системным Аналитикам и Разработчикам которые будут дальше работать с Техническим Заданием переводя его в проектную-техническую документацию. Мы для описания бизнес-сценария использовали eEPC и ARIS, а также требования нотаций IDEF0/3 для задания рамок системным сценариям: вход процесса, выход процесса, исполнитель.
Статья «Каким должно быть ТЗ на корпоративную ИС?» даст представление о том, как выглядит бизнес-сценарий и системный сценарий использования. В оригинале руководства по RUP не рекомендуется делать наброски пользовательских интерфейсов при составлении системных сценариев, но мы посчитали их необходимыми так как облегчают понимание и бизнес и системного сценариев засчёт визуализации их элементов. Это было практически первым прототипом системы хотя и не кликабельным.
После этого проекта написанное ТЗ стало новым шаблоном (стандартом). Также проект повлиял на весь технологический-производственный процесс разработки ПО в компании сделав его ритмичным.

Немного теории для понимания технической стороны методологии RUP и как её применять

Каждая итерация в RUP это классический Waterfall, содержащий все 5 этапов работ по сбору требований и их анализу, проектированию, разработке, тестированию и доставке. Но RUP также вводит такое понятие как фазы для проекта: Сбор требований и Анализ, Проектирование, Построение, Внедрение.
Теперь об этом подробнее.
Первая итерация, Фаза Анализ
Посвящена сбору требований будущих пользователей к системе. Пользователи рассказывают каждый свой кусочек работы (сценарий использования системы пользователем), а Аналитик из отдельных операций и процедур пытается собрать целый рабочий процесс. Цель этой итерации выйти на бизнес-сценарий использования системы / будущий бизнес-процесс на основе ИС. Их может быть больше чем один, поэтому не стоит замыкаться на том чтобы был обязательно один.
Компания-Заказчик — это Банк. Он решает, что хочет начать предоставлять своим клиентам услугу по удаленной выдаче наличных при помощи банкоматов, установленных в офисах клиентов и на станциях метро.
Для оказания данной услуги, нужно разработать и доработать имеющееся у банка программное обеспечение. В ходе сбора требований и их анализа было выделено три крупных процедуры в бизнес-сценарии услуги:

1. Загрузка наличных в банкомат Сотрудниками банка.
2. Выдача наличных Клиенту по его запросу со счёта в банке.
3. Учет количества загруженных и выданных купюр.

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

1. Мониторинг и нотификация, направляемая банкоматом в банк, об окончании в нём наличных.
2. Мониторинг и нотификация о работоспособности банкомата или наличия на нем проблем/ошибок в работе.

Для обеспечения доступности услуги выдачи наличных в режиме 24/7.
Результатом этой итерации становятся:

1. На 90% законченные бизнес-сценарии.
2. Намеченные, но не детализированные системные сценарии использования по каждому бизнес-сценарию.
3. Собранные требования структурированы по бизнес и системным сценариям.

Третья итерация, Фаза Проектирование
Выявленным бизнес сценариям выставляются приоритеты реализации и самые важные из них становятся предметом проработки на данной итерации. В отобранных бизнес-сценариях выделяются первичные шаги-этапы, которые являются базой для всех последующих и без которых реализация остальных не имеет смысла. Для этих этапов детализируются сценарии использования системы.
Законченный результат передается Системным Аналитикам и Архитектору для моделирования того, что будет происходит внутри системы. Выделяются классы, кооперации между ними, последовательности взаимодействия. Формируется базовое представление об архитектуре будущей системы, выделяются подсистемы, компоненты системы и их распределение по узлам ИТ-решения.
Уже в этой итерации могут быть начаты работы по разработке и результатом итерации станет готовый прототип, поддерживающий выполнение первичных шагов-этапов ключевого бизнес-сценария. Его уже можно показывать пользователям для сбора обратной связи и уточнения требований.
Этот прототип не передается в опытную или промышленную эксплуатацию, так как заложенная в основу архитектура является первым пробным шаром и в последующих итерациях будет скорректирована.
Четвертая итерация, Фаза Проектирование
Стартует параллельно третьей итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.
На этой итерации происходит проработка первичных шагов-этапов остальных бизнес-сценариев. Причина по которой прорабатываются они, а не последующие шаги для ключевых бизнес-сценариев, это определение будущей архитектуры всей программы.
Каждый бизнес-сценарий может потребовать для своей реализации каких-то специфических компонент будущей системы и по этой причине архитектурные решения для каждого бизнес-сценария должны быть согласованы между собой.
Результатом этой итерации станут:

1. Архитектурные решения для каждого бизнес-сценария.
2. Согласованный проект общей архитектуры системы 1.0
3. Вторая версия прототипа с готовыми первыми шагами вторичных бизнес-сценариев в дополнение к первым шагам ключевого бизнес-сценария.

Пятая итерация, Фаза Построения
Стартует параллельно четвертой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию. Предполагается, что к моменту старта итерации уже получена обратная связь по результатам тестирования пользователями прототипа, изготовленного во время третьей итерации. Здесь происходит проработка остальных шагов-этапов ключевого бизнес-сценария и связанных с ними системных сценариев использования.
Предполагается, что к моменту начала этапа работ «Проектирование», уже будет выполнена реализация (разработка) четвертой итерации и начато тестирование второй версии прототипа.
Происходит уточнение согласованного проекта общей архитектуры системы после которого внесение каких-то концептуальных изменений в него практически сводится к нулю, но всё ещё возможно, так как остаются не реализованными полностью вторичные бизнес-сценарии.
Результатом итерации становятся:

1. Полностью реализованный ключевой бизнес сценарий.
2. Согласованный проект общей архитектуры системы 2.0
3. Третья версия системы, реализующая ключевой бизнес-сценарий и первые шаги для вторичных бизнес-сценариев.

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

1. Полностью реализованные вторичные бизнес сценарии.
2. Финальный проект общей архитектуры системы 3.0
3. Четвертая версия системы, реализующая все бизнес-сценарии.

Начинается полноценная опытная эксплуатация системы бизнес-пользователями и примерка её под промышленное использование.
Седьмая итерация, Фаза Внедрения
Здесь происходит внесение каких-то критических изменений в реализацию бизнес-сценариев, выявленных в ходе опытной эксплуатации и не позволяющих полноценно использовать систему в промышленной эксплуатации.
Восьмая итерация, Фаза Внедрения
На этой итерации проводятся работы по повышению удобства использования системы пользователями и оптимизации изготовленных решений. Пользователей в первую очередь интересует скорость и пропускная способность их участков. Происходит передача системы на поддержку. Проводятся формальные процедуры по завершению и закрытию проекта.
Подитог
Методология RUP не ставит условий по количеству итераций и их распределению по фазам. Концепт фаз и итераций введен для снижения рисков, потребности в ресурсах, задания ритма реализации проекта и предоставления возможности внести требуемые изменения при разработке большой информационной системы.
График зависимости срока проекта от времени начала выявления проблем в ИТ-продукте
Результат каждой итерации уточняет план следующей и даёт больше понимания о том понадобятся ли нам дополнительные ресурсы для следующей итерации, нужны ли будут дополнительные итерации для завершения фазы. Начать работать над проектом может минимальная команда из нескольких человек и её расширение будет обосновываться планом следующей итерации.
Результаты завершения фазы уточняют план и экономику проекта. Здесь принимаются решения продолжать ли проект, нужно ли сузить или расширить содержание проекта (объем бизнес-требований), чтобы остаться в бизнес рамках: нужного срока доставки результата проекта, его стоимости (бюджета) и доходности (рентабельности вложений).

Понимаю, что не просто поменять принятые в компании устои как реализовывать ИТ-проекты, особенно если в компании работает Проектный Офис с методологией написанной на основе PMBoK и ГОСТ-ов. Если прочитав статью понимаете что ближайшая перспектива это всё-таки Waterfall, то рекомендую попробовать реализовать следующий минимум:

1. Прописать автоматизируемый бизнес-процесс на основе использования ИС. Это больше чем на 50% готовая пользовательская документация и приемочные тесты.
2. Заложить в проект время на то, что как минимум 1 раз в течении года придётся выполнить полный комплекс работ по перепроектированию, подготовке и согласованию изменений в проектную документацию.
3. Помножить трудоемкость работ по разработке на 1,5. Так как треть сделанной работы придется выкинуть и появятся новые требования. Длительность этапа разработки тоже стоит помножить на 1,5.
4. Разделить бюджет проекта на две части: создание и развитие.
   На развитие заложить примерно 30% от всего бюджета проекта на создание. Это нужно затем, что когда закончите проект возникнет промежуточное состояние — проект реализован, но не принят на сопровождение.
   Принятие на сопровождение, как правило, сопровождается процедурами согласования и выделения бюджета и ресурсов на сопровождение. При этом после окончания проекта начинается самая горячая фаза, когда пользователи будут требовать реализации критических доработок, которые не вошли в содержание (рамки) проекта, но их точно нужно делать и из чего-то финансировать до тех пор пока система не будет принята на сопровождение и переведена на бюджет поддержки.
   Это позволит мягко договорится с Заказчиками об окончании фазы реализации проекта, выполненной согласно ТЗ.

На мой взгляд:

• Waterfall – это первая передача (первая скорость с релизом раз в год),
• RUP – вторая (релиз раз в квартал),
• Scrum – третья (релиз раз в две недели / месяц),
• Kanban вместе с автоматической сборкой обновления (Continuous Integration), автоматическим тестированием (Acceptance Test-Driven Development), автоматической доставкой и развертыванием (Continuous Deployment) – четвертая (релиз раз в день).

Что ещё почитать по теме для освоения RUP

1. Статья «Каким должно быть ТЗ на корпоративную ИС?»
   В статье делается упор на то, что после разработки и создания КИС, начнётся этап её развития. На этом этапе потребуется разработка как новых Технических Заданий на новые функциональные модули, так и внесение изменений в ранее разработанные ТЗ на существующие модули системы в связи с внесением изменений в сценарии их использования.
   Обратите внимание на комментарии под статьёй. Они шире раскрывают материал и самой статьи про ТЗ и этой статьи про RUP.
2. Книга «Унифицированный процесс разработки программного обеспечения»
   Это настольная книга в которой есть всё что нужно, чтобы понять и научиться делать проекты по RUP.
   Первая и основная сложность — это научиться проектировать не существующие бизнес-процессы / бизнес-сценарии. Чтобы подступится к ним я рекомендую научиться описывать существующие, после чего проектирование нового взамен старого уже не будет таким сложным.
   Авторы книги предлагают для моделирования бизнес-процессов использовать UML, но всё таки книга заточена на проектирование информационной системы и в меньшей степени на проектирование бизнес-процессов. Поэтому рекомендую освоить нотации IDEFx на основе Structured Analysis and Design Technique (книга на русском). Понятие процесса которое заложено в этой методологии является основой для стандартов ISO и PMI. И уже после этого расширять свои знания и умения по использованию других нотаций.
3. Изучения языка моделирования напрямую связано с необходимостью освоения какого-либо инструмента. RUP предполагает что вы будете использовать линейку продуктов Rational от IBM. Я рекомендую воспользоваться бесплатной демо-версией Business Studio. В этом видео с 12 минуты объясняется как строить модели с помощью данного инструмента.